Stories tagged Debian:RSS Feed

topgit; tags=Debian, Programmieren, VCS

Nachdem auf der Team-ML der Debian Games Gruppe, in der ich zufällig mitarbeite, die Verwendung von topgit für alle git-verwalteten Pakete vorgeschlagen wurde um quilt-patches zu erzeugen habe ich mich spontan entschlossen mein Paket «xwelltris» zu konvertieren.

Read More

-- Christoph Egger <christoph@christoph-egger.org> Mo, 24 Nov 2008 17:43:37 +0100

PPAs; tags=Debian, Programmieren

Wie man meinem privaten Launchpad PPA ansieht verwende ich selbiges doch recht ausgiebig. Der Nutzen liegt, in meinen Augen, unter anderem darin, bereits vor dem offiziellen Release mit den aktiven Benutzern der Software auf Fehlerzuche gehen zu können.

Solchige Software könnte sonst lediglich in Debians «experimental» landen, würde das ganze aber für mich ausbremsen da mit einfach die Upload-Rechte (noch) fehlen und gerade für kleinere Projekte kann man in einem solchigen experimental-Updload auch Resourcenverschwendung sehen.

Read More

-- Christoph Egger <christoph@christoph-egger.org> Di, 16 Dez 2008 17:13:44 +0100

Webserver; tags=Debian, Hier, Web

Server konfigurieren ist keine einfache Angelegenheit. Soweit klar. Allerdings kann es doch immer wieder überraschend sein wie schwer es manchmal sein kann.

Dieser Server lief lange Zeit mit SuSE 10.2 -- verhältnismäßig alt, es ist schwer irgendetwas neues zu installieren und die alte Administrationssoftware für unsere Webkunden war auch nicht das wahre. Ein Update kam nicht in Frage, niemand im Team hat die Erfahrung mit SuSE im generellen und die Konfiguration war vom Anbieter voreingestellt.

Read More

-- Christoph Egger <christoph@christoph-egger.org> Fr, 26 Dez 2008 14:57:20 +0100

LVM; tags=Debian

LVM ist eine großartige Sache. Dynamische Volumes lassen sich jederzeit nach Bedarf vergrößern. Nie mehr raten, wie viel Platz für was nötig ist, einfach die Partitionen mitwachsen lassen.

Klingt alles nach einer netten Angelegenheit, warum also nicht für die neue USB-Festplatte verwenden? An sich eine Gute Idee. Falsch gemacht steht man allerdings schnell ratlos da.

Read More

-- Christoph Egger <christoph@christoph-egger.org> So, 28 Dez 2008 17:37:57 +0100

Auf der Suche nach freien Texturen; tags=Debian, Programmieren, Web, FOSS

Freite Texturen finden kann ja nicht so schwer sein oder? Blender Nation hat ja regelmäßig neue Blogeinträge mit neuen Quellen für freie Texturen, es gibt hunderte Seiten online, ...

Wirklich freie Texturen (frei wie in DFSG zu finden ist aber in wirklichkeit viel schwerer. Denn: Was mache ich mit Texturen, die frei für kommerzielle und nicht-kommerzielle Verwendung sind (ohne weitere Erklärung)? Viele texturseiten bieten die Textur an, schließen aber Weitergabe (mit außnahme von Druckwerken) aus.

Sollte tatsächlich ein OpenSource Künstler auf diese Seite stoßen, bitte gebt uns eure Links ;)


-- Christoph Egger <christoph@christoph-egger.org> Fr, 30 Jan 2009 19:15:14 +0100

Nocheinmal TopGIT; tags=Debian, Programmieren, VCS

Nachdem ich bereits über TopGIT geschrieben habe wurde diese Seite ziel einiger Google-Suchen nach dem String 'topgit'.

Da dieses Thema scheinbar eine Menge Menschen interessiert und mein Weblog unter dem Top Hits in Google erscheint habe ich dann beschlossen mein Mini-Review aus dem Debian Games Team hierher zu übernehmen. Alle Angaben beruhen auf meinen Vermutungen und erheben weder den Anspruch komplett noch richtig zu sein.

Das Original war in Englisch verfasst daher gibt es hier jetzt eine Übersetzte und überarbeitete Version davon. Wer die Debian Spezifischen Teile lesen will sei auf das Original verwiesen.

Das erste Mini-Review entstand, da ich TopGIT beim Paketieren von XWelltris ausprobiert habe und dann von einigen Menschen im Debian Games Team darum gebeten wurde.

XWelltris selbst ist kein besonders komplexes Paket und hat in Debian aktuell nur 2 Patches die mit TopGIT verwendet werden sollten. Das mitlerweile ebenfalls umgestellte SFML ist da um einiges komplexer.

Read More

-- Christoph Egger <christoph@christoph-egger.org> Sa, 31 Jan 2009 21:26:54 +0100

Erledigt: RC Bug; tags=Debian, FOSS

#514416 erledigt -- unfreeze vorhanden. Heißt aber auch, dass ich jetzt erstmal genug davon habe, freie Bilder, Sounds zu suchen.

Nebenbei habe ich dann auch die ein oder andere Quelle zur Freedesktop Games Team Resourcen Liste hinzugefügt. Was wohl hier noch eine gute Möglichkeit wäre, ist die Zusammenarbeit/Zusammenlegung mit Freegamedev.


-- Christoph Egger <christoph@christoph-egger.org> Mo, 09 Feb 2009 14:37:16 +0100

OHLOH; tags=Debian, Spaceshooter, Programmieren, Web, VCS, Unknown-Horizons, FOSS

Um Unknown Horizons weiter zu verbreiten habe ich jetzt ein ohloh.net Projekt angelegt und gleich noch einen Account für mich angelegt.

Ohloh lobt dann auch gleich das Projekt für ein aktives, großes Entwicklerteam und gute Dokumentation, kann also gar nicht so schlecht sein.

Ganz überrascht bin ich auch, wie weit ich es mit meinen bisherigen Projekten bereits geschafft habe ... Ohloh profile for Christoph Egger

TODO: Einträge über NM und Debconf


-- Christoph Egger <christoph@christoph-egger.org> Fr, 17 Apr 2009 17:09:16 +0200

Debian GNU/kFreeBSD; tags=Debian, Programmieren, FOSS, kFreeBSD

Gute Nachrichten vorneweg: Debian GNU/kFreeBSD funktioniert bereits halbwegs und ist mehr oder weniger verwendbar. Zumindest für meine Zwecke. Und trotzdem wird mein Notebook vorerst weiter mit Debian GNU/linux betrieben. Ist einfach die stabilere Variante.

Das heißt jetzt natürlich nicht, kFreeBSD einfach zu ignorieren und daher habe ich eine Installation in QEMU laufen. Im folgenden ersteinmal ein paar Screenshots:

Debian kFreeBSD mit Iceweasel und urxvt auf fluxbox Desktop

Während der X Server weitgehen funktioniert -- neueste Kernel Version vorausgesetzt und mitunter etwas nachhelfen an den HAL fdi Dateien -- ist das mit den Desktops etwas schwieriger. Fluxbox, wie oben zu sehen, funktioniert dabei einwandfre und auch awesome scheint zu funktionieren:

Debian kFreeBSD mit Iceweasel auf awesome Desktop

Während ich persönlich mit Fluxbox bisher immer ganz gut zurecht gekommen bin und mir awesome in der QEMU ziemlich gut gefällt (muss ich wohl nochmal auf dem Notebook direkt ausprobieren), ist meine erste Empfehlung an Linux Neulinge normalerweise LXDE. Und da fangen die Probleme an.

Zuerst schon lässt sich lxde, und sogar lxde-core nicht direkt installieren, nicht erfüllbare Abhängigkeiten. Glücklicherweise lässt sich das für lxde-core relativ einfach beheben: für pcmanfm ist der hal build auf nicht-Linux Architekturen (Hurd, BSD) deaktiviert. Schaltet man ihn an, baut das ganze frühlich das pcmanfm Packet.

lxpanel ist etwas komplizierter, lässt sich aber auch beheben. Das Packet hängt zwar für den Bau von libasound2-dev und libiw-dev ab, die (noch) nicht auf kFreeBSD portiert wurden, allerdings erkennt der configure script das automatisch und baut dann halt ohne. Nur das erkennen der BSD Kernels funktioniert nicht ganz, auf GlibC BSDs definiert GCC nämlich __FreeBSD_kernel__ statt __FreeBSD__. Passt man die entsprechende Zeile im Quellcode an funktioniert zumindest der Build. lxmusic müsste ich mir 'mal ansehen, auch hier gibt es unerfüllte Build-Abhängigkeiten.

Versuch, lxterminal in LXDE auf Debian GNU/kFreeBSD zu öffnen

Auf dem Screenshot ist schon ganz gut eines der Probleme zu sehen: Der Dekorator will irgendwie nicht so recht. Und in Live oder auf einem Video könnte man auch das zweite Phenomen erkenne: Das halbdekorierte Fenster wandert langsam immer weiter den Bildschirm hinunter.

GNOME und/oder KDE konnte ich nicht so einfach testen. Sowohl gnome-core, als auch kde4-minimal wollten sich wegen nicht erfüllter Abhängigkeiten nicht installieren lassen und für GNOME/KDE fehlt mir auch ersteinmal die Motivation etwas tiefer zu graben.

Zu guter letzt bleibt noch zsh. Hier hängt der Build auf den Debian Autobuildern im test Status. Abhilfe schafft ein lokaler Build, für den die Tests auskommentiert sind (leider unterstützt das Packet kein DEB_BUILD_OPTIONS="notest".

Jetzt steht eigentlich die Installation auf echter Hardware an, allerdings braucht der PC, den mir der Lukas freundlicherweise überlassen hat, wohl ersteinmal noch ein BIOS update um mit Linux und/oder BSD Kernels zurechtzukommen.

Für alle, die neugierig geworden sind, gibt es eine Mailing Liste und einen IRC Channel sowie (leider nicht ganz aktuelle Informationen auf Alioth.


-- Christoph Egger <christoph@christoph-egger.org> Di, 01 Sep 2009 18:18:00 +0200

Open Game Art did it right; tags=Debian, Web, Unknown-Horizons, FOSS

Open Game Art is a newly started site for exchanging free Artwork. While one can easily get the impression that there are loads of such sites around, Open Game Art is one of the very few that actually is done right.

As a Member of the Debian Games Team and the Unknown Horizons Project I was way too often in the need for good artwork searching around the web. I've also already reported once about my trouble.

There are quite some sites like Free Sounds around offering free artwork -- but only free as in beer as the saying goes, not as in speech which of course is really unhelpfull for FOSS projects. And even most of the sites that have free content often only tell you the license on some special pice of arts details page.

Open Game Art is quite different from that. All the license you may choose as a contributor are free (both in Debian and in FSF terms) and the license is available through a search filter so you can find stuff that fits you project's licensing policy. This list, and that's another thing I really like about that site, is the availability of choice among common licenses including, next to the copyleft class of licenses a fair share of more liberal licenses like my personal favourite, the zlib License.

And because such a site is just as good as it's amount and quality of data I've started sharing some recordings. I'm currently really new to audio recording so I guess it'll take some time for me to become really good. I'm considering putting some of my experiences and stuff I've learned here.


-- Christoph Egger <christoph@christoph-egger.org> Fr, 19 Mär 2010 19:23:33 +0100

Another piece of well done software; tags=Debian, Spaceshooter, Programmieren, FOSS

As I really liked saying why I think Open Game Art is a good project I decided to start a small serie of well done free (well not only software) projects. This time SFML got to be the one.

SFML is, as the name already tells, a Simple and Fast Multimedia Library written in C++ but providing bindings for a whole bunch of other languages like Python, Ruby, C, D and others. Debian currently provides the original library as well as the C and Python bindings maintained by the Games Team and myself. On a side remark, SFML also uses my favourite License, zlib.

What I really like about SFML is the readable code all through the project. Every time I was unsure what some function does having a look at the actual implementation (and some OpenGL and X11) knowledge turned out to be quite satisfactory. This is, of course, aided by the fact that SFML's development is driven by a single Developer, Laurent Gomila.

On the rather weak points I'm still hoping the to-be-released 2.0 Version of SFML will introduce something like a stable API which it currently lacks (although the API has settled and there are no such huge changes as from 1.2 to 1.3 in recent updates any more). SFML also uses hand-made Makefiles for building (now supporting DESTDIR at least -- in some non-standard way) and has the usual load of embedded libraries which results in it's current load of patches.

For a nice time burner make sure you take a look at the python binding's snake-like clone. It clearly misses some important aspects to form a full game but it's nice nontheless. I have a (not-quite) small SFML based Project myself, a forward ported game from my old DirectX days, however it's unfortunately not yet playable again und rather stalled at the moment due to lack of time.

So much for SFML. If you feel like it feel free to join me on writing about well done pieces of software or just about pieces on how you think it should™ be done and tell us where you found it happening.


-- Christoph Egger <christoph@christoph-egger.org> Mi, 31 Mär 2010 21:45:53 +0200

[Review] AI Touchbook; tags=Debian, Linux, FOSS, Uni

Having my primary working Computer, a Lenovo Thinkpad, going into repair at the end of December I finally got up to ordering on of those TouchBook ARM based netbooks I was looking at for some time. After some processing time it finally got shipped in April and arrived here last Monday, time to write up my first impressions.

Some words about the Hardware. The TouchBook ships with a so called "Beagle Board" featuring a OMAP3 Processor, ARM Cortex A8 running at 600MHz, 512MiB of RAM and a 8GiB SD Card for storage. It has a 8.9" touch screen and comes with USB and Bluetooth Sticks for wireless connectivity. The Display part contains all the needed Hardware and is detachable from the bottom that is just a keyboard sitting on the secondary Battery. You can open the Top to get at 4 intern USBs (3 USB-A and one Mini-USB) where 2 of these spots are occupied already for wireless networking and Bluetooth.

First experience

The TouchBook comes with an US Power Adaptor only so when I got the device I was running for some tiny Adaptor to get the plug into a normal EU Power Outlet (it's incredibly hard to get one for this Direction while it's easy to get some travelling stuff to plug EU Hardware into various different Outlets!).

When I finally booted it the first thing you'll notice is the touch interface for the bootloader. That's quite a difference to all-text-based old grub! The shipped SD Card offers 3 Operating Systems, one custom Linux that might well be interesting to the average User, a Ubuntu Karmic that really OK for a Debianoid Hacker- both running a XFCE Desktop - and a Android that is really slow and doesn't seem to be good at anything. Needless to say I sticked with the Ubuntu for now.

What to not expect

Well this is a 600MHz CPU with half a Gig of RAM running of a SD Card. So don't expect it to be good at anything that can profit from today's High-End Hardware.

The good Points

First of all, I have to admit that the touch screen is a neat interface, way superior to the Touchpad Area you'll normally find on a Notebook - at least if you use the stylus. It's quite different from the inside-the-keyboard trackball the thinkpads have of course.

The Website claims 10h of Battery life and while I've emptied the battery much faster under certain workloads (e.g. Playing cards) it does hold that promise with emacs fired up in org-mode, IRCing on a server over SSH and the mandatory wireless working. Same for a always-on on campus day which just works.

Again putting the screen on the keyboard the wrong way 'round will give you a touchscreen tablet with the keyboard out of your way, an ideal configuration for playing. And I have to admit playing games like gtkballs or aisle riot real fun. So much fun actually I'm currently thinking on whether it would be feasible to get openpandora working on it.

What I'm really missing

There are two Properties that are really lacking from the device which would make it (in my personal opinion at least) a whole lot better: A simple Ethernet controller I could use to go online when sitting in the server room doing some maintenance without taking my WRT with me and some slot to store the stylus when not using it where it's easy to get out (currently I'm having it in my wallet).

Then there's something (maybe a Kernel Bug): The Wireless is unable to find any new Access Point after disconnecting from some and walking out of reach from that. Force-unloading the kernel module and waiting 30 minutes worked for me multiple times but that's purely inacceptable.

Finally there are some minor glitches. The shiny red cover just gets dirty every time you touch the thing and the Keyboard is really small (what a surprise on a 9" device) and has some of the special Keys (like the Home key) located at unusual spots (Page-Up/Down only available through the FN modifier). Shift and End at the right side are also labeled opposite from their actual function (at least on Ubuntu).

The last ugliness is the top part battery only charging when the device is running, which means you"ll have the TouchBook running all night to get the battery charged and the Battery Monitor not working at all (at least in the current version of the operating systems).

Where to go now

I've not yet come around to really play with the operating system (apart from installing wicd, urxvt-unicode and awesome getting the most needed of my working environment). As I'm a Debian Developer I'll definitely need a Debian running on it (although I was told it'll be slow with software compiled for armv4te) and, as it needs to be running all night anyway, I'll try out gentoo pending another SD Card for experiments.

Secondly there's currently no useable conforming Common Lisp Implementation in Debian for armel as far as I can tell. As arm was already working it shouldn't be that hard, let's see if I can change that but feel free to join me!

Final Notes

I was thinking of some mobile-ish note-taking device and remote ssh terminal for University which the device clearly can do even for 10h away from any power plug while being some non-standard non-x86 device to toy on (It's actually my second armel next to the sheeva plug mounted on my window board.

As a final Remark: This blogpost was written on the TouchBook hacking some markdown into emacs while traveling by train to Erlangen where I study on Sunday Night after having read some chapters of Cory Doctorow's Little Brother on my E-Slick E-Book reader and finished later in my Room.

Maybe I'll find some time to write a review for this device as well one day!


-- Christoph Egger <christoph@christoph-egger.org> Mo, 26 Apr 2010 10:32:35 +0200

Debian GNU/kFreeBSD; tags=Debian, Programmieren, FOSS, kFreeBSD

So when I was travveling to my parent's for christmas it looked like I'd have limited computer access. My Netbook is quite OK for reading mail but not really useable for any real hacking. And my trusty Thinkpad (Z61m) was oopsing when X was running so not much useable either. But as some Live CDs placed here were working well I decided that this would be fixed by an reinstall. And as I was reinstalling anyway I decided I could just choose kfreebsd-amd64. Turned out to be a quite entertaining decision with lots of stuff to hack away with

wireless

Bad news: there's no wireless support on Debian GNU/kFreeBSD at the moment. This problem is tracked as Bug #601803 so for wireless internet you will need a (plain) Freebsd chroot. Haven't tried this myself yet -- busy figuring other stuff out.

SBCL

Having a FreeBSD chroot I decided to give SBCL on GNU/kFreeBSD another try after having failed to get it working in a VM some time ago. With quite some help on SBCL's IRC channel I managed to build a patch that enables building (you need to force a :os-provides-dlopen to the feature list additionally).

There's currently no multi-threading working so I hae a project for the rest of the hoidays (well lots of other stuff to do as well ;))

Audio

Some more user-related stuff now. As it is this time of the year I wanted to listen to some 27c3 streams so I needed working audio. However there's no OSS device available. Turned out you just need to kldload the right module (here snd_hda) to get sound working.

Volume was rather low although hardware controls of the soundcard where at max. As that's all OSS there's no point looking for alsamixer. Turns out aumix can do that here.

IPv6 aiccu stuff

Installing aiccu, copying the config in and starting did not work out as well. I already tried to do that from within the FreeBSD chroot already (which doesn't work for some reason) until I discovered just loading the if_tun kernel module solves the aiccu on Debian issue quite well. To get a default route up the last step was finding /lib/freebsd/route again -- /sbin/route is a wrapper around that abstracting differences in BSD route but not supporting IPv6.


-- Christoph Egger <christoph@christoph-egger.org> Mi, 29 Dez 2010 00:57:37 +0100

CSSH but without X; tags=Debian, Linux, FOSS, HowTo

There are many ways to run some commands simultaneously on multiple hosts like cssh or dsh. They come handy for example when you are installing software updates on a set of hosts.

dsh is a rather simple comandline tool allowing to execute a command over ssh on multiple hosts. However it doesn't allow any interactive input -- so you can't look at the potentially upgrading packages and press y to accept and you can't go through debconf promts or similar.

This is solved by cssh which opens a XTerm for every host and a input area that is broadcastet to all of them. this is working really well -- you can execute your update on all hosts and still do individual adjustments just as needed: switch focus from the broadcasted input to one of the terminal windows and anything you type just goes there.

Now cssh has a big disadvantage: it requires a running X server (and doesn't do too well with a fullscreen windowmanager). Requiring X is quite a blocker if you need to run that ssh multiplexer on a remote host, for example if the firewalling doesn't allow direct connections. Fortunately you can make tmux behave as we want -- in a simple terminal:

First you need a script spawning the ssh sessions in separate tmux panes and direct input to all of them -- here called ssh-everywhere.sh (you could also write a tmux config I guess):

#/bin/sh
# ssh-everywhere.sh
for i in $HOSTS
do
  tmux splitw "ssh $i"
  tmux select-layout tiled
done
tmux set-window-option synchronize-panes on

Now start the whole thing:

tmux new 'exec sh ssh-everywhere.sh'

And be done.

Update

If you want to type in just one pane (on one host) you can do that as well: C-b : set-window-option synchronize-panes off and moving to the right pane (C-b + Arrow keys)


-- Christoph Egger <christoph@christoph-egger.org> So, 20 Feb 2011 17:23:04 +0100

Trying GNU/Hurd; tags=Debian, HowTo, Hurd, Porting

So this is a collection of things I came about when trying to get a Debian GNU/Hurd virtual machine running with kvm. Most of it is properly documented if you manage to find that particular piece of information.

Kernel Version

Due to a bug in linux 2.6.37 and .38 hurd will only boot if you supply -no-kvm-irqchip which is not that easy if you are using libvirt. A wrapper `kvm` script in the PATH will do, as will using a 2.6.39 kernel.

sudo

sudo will hang before returning from executing some command. I'm now using screen and sudo -i which keeps you a working tty gets you root and hasn't caused mayor trouble yet

sshd

openssh-server won't come up complaining about missing PRNG – and indeed there's no /dev/{u,}random in the default install. fix is to install random-egd from ports.


-- Christoph Egger <christoph@christoph-egger.org> Fr, 06 Mai 2011 00:02:24 +0200

Thouhts on secure software archives; tags=Debian, Web, Linux, FOSS, Security

From the java point of view

Recently I had to get some Scala Tool working correctly. Unfortunately there are basically no packages in the Debian Archive at all so I had to use maven to install these (or download + install manually). Being a highly paranoid person downloading and executing code from the internet without any cryptographic verification at all one after the other practically drove me nuts. Looking a bit deeper I noticed that some of the software in maven's repository have some signatures next to them -- signed by the author or release manager of this specific project.

Why secure sources matters

With my experience in mind I got some Input from other people. One of the things I was told is that some scala tools just aren't security critical -- they're only installed and used as the current user. In my opinion this is, for my desktop system, totally wrong. The important things on my private Computers are my GPG and SSH keys as well as my private data. For messing with these no super user access is needed at all.

Comparing to the Common Lisp situation

Being a Common Lisp fan of course I noticed basically the same problem for installing Common Lisp libraries. Here the situation in Debian is quite a bit better -- and I'm working in the pkg-common-lisp Team to improve this even more. Common Lisp has some maven-alike tool for downloading and installing dependency trees called quicklisp -- without any cryptographic verification as well. However there's light at the end of this tunnel: There are plans to add GPG verification of the package lists really soon.

Comparing the maven and the quicklisp model

So there are basically two different approaches to be seen here. In maven the software author confirms with his signature the integrity of his software while in quicklisp the distributor confirms all users get the same software that he downloaded. Now the quicklisp author can't and won't check all the software that is downloadable using quicklisp. This won't be doable anyway as there's way to much software or a single person to check.

Now in some kind of perfect World the maven way would be vastly superior as there's a End-To-End verification and verification of the full way the software takes. However there's a big problem: I don't know any of these Authors personally and there's no reason I should just trust any of them.

Now comparing this to the Distribution / quicklisp model. Here I would just have to trust one person or group -- here the quicklisp team -- to benefit from the crypto which might be possible based on karma inside the using community. However here I don't gain the possibility that the software is integer.

However idealized if some of these pieces of software was forged between upstream and the quicklisp team and attacker would also intercept me downloading the software from the same address so I get the source from upstream matching the checksum from quicklisp -- assuming the quicklisp team does indeed know the correct website. Additionally I get the confirmation that all other quicklisp users get the same source (if the quicklisp guys are fine of course) so no-one inside the community complaining is a good indication the software is fine. For this to work there's of course a relevant user-base of the distributor (quicklisp) necessary.

Relevance for Debian

So how do conventional Linux Distributions like Debian fit in here. Ideally we would have maintainers understanding and checking the software and confirming the integrity using their private key or at least know their upstreams and having at least a secured way getting the software from upstream and a trust relationship with them. Of course that's just illusionary thinking of complex and important software (think libreoffice, gcc or firefox for example). Maintainers won't fully understand a lot simpler pieces of software. And loads of upstream projects don't provide a verified way of getting the correct source code though that's a bit better on the real high-impact projects where checksums signed by the Release Manager are more common than in small projects.

A misguided thought at the end

As I'm a heavy emacs user I like to have snapshots from current emacs development available. Fortunately binary packages with this are available from a Debian guy I tend to trust who is also involved upstream so adding the key from his repository to the keyring apt trusts. Now my first thoughts were along the lines "It would be really nice if I could pin that key to only the emacs snapshot packages" so this guy can't just put libc packages in his repository and my apt would trust them. Now thinking of it again a bogus upload of the emacs snapshot package could just as well put some binary or library on the system at some place in front of the real on in the system path which would be rather similar bad.

b

-- Christoph Egger <christoph@christoph-egger.org> Do, 12 Mai 2011 21:19:49 +0200

Maintaining kFreeBSD buildds since one month; tags=Debian, FOSS, kFreeBSD, Porting

At April 30, I took over maintenance of of Debian's kFreeBSD autobuilders. Means getting something like 4,5k e-Mails this month (gladly no need to sign all those 4k successful builds any more!), filling nearly 30 RC Bugs (quite a lot of which got fixed just within hours after filling, wow!), investigating some of the more strange build failures and such stuff. In general it turned out to be quite some fun.

Quite interesting which libraries turn out to be rather central to the Archive. I wouldn't have guessed that a uninstallable libmtp would prevent a reasonable fraction of the builds to fail -- including packages like subversion.

Packages builds failing because the disk space is exhausted may be something most of us have already witnessed, especially those here that use one of these small notebook hard drives. Build failures caused by a lack of RAM might certainly be imaginable as well, especially on highly parallel builds. But have you ever seen gcc fail because the virtual address space was exhausted on 32 bit architectures?

Also there's a interesting lot of packages with misspelled build dependencies which sbuild can't find and therefore can't build the package. Maybe having a lintian check for some of these problems would be a good idea?

I'm also regularly seeing build failures that look easy enough to fix -- like some glob in a *.install for some python package matching lib.linux*. I try to fix some of these as I see them but my time is unfortunately limited as well. Someone interested in quick&easy noticed about these kind of issues? I could put URLs to build-logs on identi.ca or somewhere on IRC.

There are also some really strange failures like llvm, which builds flawlessly on my local kFreeBSD boxes all the time, inside and outside schroot but hangs all the time in the same testcase when building on any of the autobuilders (any hints welcome!) or perl failing on kfreebsd-amd64 selectively but all the time.


-- Christoph Egger <christoph@christoph-egger.org> Mo, 30 Mai 2011 15:54:23 +0200

Marking all closed bug reports "read" in a Maildir; tags=Debian, FOSS, HowTo

#!/usr/bin/python

from btsutils.debbugs import debbugs
import mailbox
import re
import sys

mailbox =  mailbox.Maildir(sys.argv[1], factory=False)
bts = debbugs()

for key in mailbox.keys():
    message = mailbox[key]
    if not 'S' in message.get_flags():
        if message['X-Debian-PR-Message']:
            try:
                bugnr = message['X-Debian-PR-Message'].split()[1]
            except IndexError:
                continue
        else:
            test = re.search('Bug#(\d{6})', message['Subject'])
            if test:
                bugnr = test.group(0)[4:]
            else:
                continue

        try:
            bug = bts.get(bugnr)
        except AttributeError:
            print bugnr
            continue

        if bug.getStatus() == u'done':
            message.set_flags(message.get_flags() + 'S')
            mailbox[key] = message


mailbox.flush()

Run it like python cleanbugsmail.py ~/Maildir/.debian.bugs. Anyone aware of a better solution?


-- Christoph Egger <christoph@christoph-egger.org> So, 12 Jun 2011 16:53:11 +0200

Debconf11; tags=Debian, Linux, FOSS, kFreeBSD

debconf banner I'm coming as well! Really looking forward to meet the people from Debconf9 again. Also people from the Games Team and the buildd and kfreebsd folks. And ideally there will be some more people interested in (Common) Lisp as well, we'll see


-- Christoph Egger <christoph@christoph-egger.org> Mi, 29 Jun 2011 22:44:41 +0200

A week of Debian GNU/kFreeBSD; tags=Debian, Programmieren, FOSS, kFreeBSD

While other people are squashing RC bugs I was using this week to fix (or investigationg) some more kFreeBSD issues -- mostly looking at failed build logs and trying to fix the problems and after some nice fish for dinner writing things up.

  • First issue this week was #639178 a build failure in tar I had reported earlier and didn't manage to process the response. After sending some findings to the bug I noticed Petr was faster and did actually find out a lot more detail. Short story: success in that test suite requires linux behavior and the failure on kfreebsd is covered by what POSIX allows
  • #640156 multiarch related changes resulting in a nonfunctional ldd breaking clutter-gst build
  • #640012 postfix is hard-coding kFreeBSD versions … up to 7 and therefore won't build on a 8.2 kernel. It also doesn't handle absence of NIS on Hurd and kFreeBSD #545970
  • #640159 iozone3 just needed a bit of massaging to combine the FreeBSD backend with the linker flags needed for kFreeBSD
  • Installing the build depends for openjdk-* resulted in a installation failure for some time. Looking closer it turned out a minimal testcase was installing menu and python2.6 together. Turned out dash's test builtin wasn't working #640334 because it was relying on the intuitive but not POSIX mandated behavior of the faccessat syscall #640325
  • #640341 ed decided not to build on kfreebsd-i386 in the 40 minutes between -2 and -3 upload. Without any actual source changes. Just trying agan tricked it to build again but probably someone should look what went wrong actually
  • #640378 leveldb needed enabling the FREEBSD_OS kind of build with the linux style of linker flags (additional -lrt)
  • #640385 owfs was failing to some symbol difference (but otherwise building although being a *fs ;))
  • the gcc family of packages still has some heisenbug repeatedly failing when doing regular builds on the buildds. Independent which one. Multiple times in a row. Building on my test VM or my notebook doesn't show that problem (but takes ~10h). Building on the same buildd in the same chroot with the same sbuild flags and it's still building fine.

-- Christoph Egger <christoph@christoph-egger.org> So, 04 Sep 2011 23:07:12 +0200

Systemd pitfalls; tags=Debian, Linux, FOSS

If you just updated systemd and ssh to that host seems to hang, that's just a known Bug (Debian Bug #770135). Don't panic. Wait for the logind timeout and restart logind.

restart and stop;start

One thing that confused me several times and still confuses people is systemctl restart doing more than systemctl stop ; systemctl start. You will notice the difference once you have a failed service. A restart will try to start the service again. Both stop and start however will just ignore it. Rumors have it this has changed post jessie however.

sysvinit-wrapped services and stop

While there are certainly bugs with sysvinit services in general (I found myself several times without a local resolver as unbound failed to be started, haven't managed to debug further), the stop behavior of wrapped services is just broken. systemctl stop will block until the sysv initscript finished. It will even note the result of the action in its state. However systemctl will return with exitcode 0 and not output anything on stdout/stderr. This has been reported as Debian Bug #792045.

zsh helper

I found the following zshrc snipped quite helpful in dealing with non-reported systemctl failures. On root shells it will display a list of failed services as part of the prompt. This will give proper feedback whether your systemctl stop failed, it will give feedback if you still have type=simple services and if the sysv-init script or wrapper is broken.

precmd () {
    if [[ $UID == 0 && $+commands[systemctl] != 0 ]]
    then
      use_systemd=true
      systemd_failed="`systemctl --state=failed | grep failed | cut -d \  -f 2 | tr '\n' ' '`"
    fi
}

if [[ $UID == 0 && $+commands[systemctl] != 0 ]]
then
  PROMPT=$'%{$fg[red]>>  $systemd_failed$reset_color%}\n'
else
  PROMPT=""
fi

PROMPT+=whateveryourpromptis

zsh completion

Speaking of zsh, there's one problem that bothers me a lot and I don't have any solution for. Tab-completing the service name for service is blazing fast. Tab-completing the service name for systemctl restart takes ages. People traced down to truckloads of dbus communication for the completion but no further fix is known (to me).

type=simple services

As described in length by Lucas Nussbaum type=simple services are actively harmful. Proper type=forking daemons are strictly superior (they provide feedback of finished initialization and success thereof) and type=notify services are so simple there's no excuse for not using them even for private one-off hacks. Even if you're language doesn't provide libsystemd-daemon bindings:

(defun sd-notify (event-string)
  (let ((socket (make-instance 'sb-bsd-sockets:local-socket :type :datagram))
        (name (posix-getenv "NOTIFY_SOCKET"))
        (bufferlen (length event-string)))
    (when name
      (sb-bsd-sockets:socket-connect socket name)
      (sb-bsd-sockets:socket-send socket event-string bufferlen))))

This is a stable API guaranteed to not break in the future and implemented in less than ten lines of code with just basic socket functions. And if your language has support it becomes actually trivial:

    try:
        import systemd
        systemd.daemon.notify("READY=1")
    except ImportError:
        pass

Note that in both cases there is no drawback at all on systemd-free setups. It has the overhead of checking the process' environment for NOTIFY_SOCKET or for the systemd package and behaves like a simple service otherwise.

Actually the idea of separating the technical aspect (daemonizing) from the semantic aspect of signalizing "initialization finished, everything's fine" is a pretty good idea and hopefully has the potential to reduce the number of services signalizing the "everything's fine" too early. It could even be ported to non-systemd init systems easily given the API.


-- Christoph Egger <christoph@christoph-egger.org> Fr, 07 Aug 2015 22:17:21 +0200


valid XHTML, CSS -- Django based -- ©2008 Christoph Egger