
Details about the bug are in #659762. Anyone fixing that would (not only) do our buildd network a big help (and you don't need to know anything about autobuilders for fixing that).
wanna-build=> delete from packages where distribution ~ 'lenny' ; DELETE 8250 wanna-build=> delete from distribution_architectures where distribution ~ 'lenny'; DELETE 63 wanna-build=> delete from locks where distribution ~ 'lenny'; DELETE 63 wanna-build=> delete from pkg_history where distribution ~ 'lenny'; DELETE 16504 wanna-build=> delete from distributions where distribution ~ 'lenny'; DELETE 6 wanna-build=> delete from architectures where architecture in ('alpha', 'arm', 'hppa'); DELETE 3
In Zagreb, I dropped off my luggage at the train station again, and then went by tram to the parts of the city I hadn't been before (and which were more normal parts, and not the tourist-areas). Incidently I also experienced tram track works, and so had to switch to the bus; however, information was so bad that not only I didn't notice it (which wasn't too bad and unexpected - I plan with enough time as tourist) but also locals were taken by surprise.
(Many parts of) Zagreb appears to have many too wide roads, with pedestrians pushed away. Not too uncommon for some cities here as well. But sad to see if public space is not created with humans in mind. This used to be modern in the 60ies, whereas it should have now advanced to center around humans again. If one compares the situation how one feels while standing in a too far road (where the wind blows easily cold) with a decent road in any city center, one could see the difference. But as said, many german cities make the same mistake.
After arriving back at the train station, this was in time for taking the night train. Obviously there were many DDs on board. Passport checks in Hravatska went smooth but with many boarder guards. The train had an extra stop not in the official timetable so that they didn't leave their territory armed. On arriving in Slovenija the train had to stop some time. Border checks were quite strict (as this was entering the european union) and time consuming, e.g. partly cover sheets of the train were removed.
After entering Slovenija the reminder of the trip was uneventful (or at least: ignored while sleeping), so the trip ended in München as planned.
Summarising it was an interesting and nice trip. I had no problem using public transport in spite of the warnings before. Of course, as always while traveling in foreign countries one should expect the country to be more different to home than just temperature and language - i.e. one should expect a bit of the unexpected, and be able to cope with. But that's true for any place one is going to. And these areas are worth another visit another time.
I also learned more about "local" history (whereas local covers everything within 1000 kilometers around München). However, the really bad thing is when comparing Hrvatska and Bosna i Hercegovina to see how much more Bosna i Hercegovina could have advanced within the last 16 years, but didn't due to incompetent management. Thinking that the same ways of obstructing decision-making happens in this country (and the european union as a whole) as well (but isn't as visible - we hadn't had a war, but also not much advances in our infrastructure) makes me more sad. Having said this, I still enjoyed the tour quite much - it was a good decision to have done it.
Franz Ferdinand was shot here in 1914
nice building hidden by cars - should our cities be dominated that way?
After having spent the morning exploring the old part of Sarajevo and along the river, I used the time after hotel checkout to use the tram link and take a few more pictures. I arrived at the train station as planned, but the train I wanted to take didn't go that day (in spite of checking it within the hotel in the morning). So, I ended with another bus trip (this time unplanned) to Banja Luca. Again, bus trips are worse than train trips - one cannot move in the vehicle, and there are delays for every stop. The events in Banja Luca are discussed elsewhere, so nothing about that here (except that DebConf was great - I enjoyed it very much).
Right on time the train entered the station. However, we had a 30 minutes delay there without any obvious cause or communications. This train was (as well as the previous in Hrvatska) between full and overcrowded, in spite of the bad connections. I however learned soon why these carriages shouldn't go to other parts of europe: The window in our compartment was replaced, so it couldn't be opened any more (and we had no means of fresh air). That wasn't as bad as it sounded, as the train doors weren't locked, so someone opened the door while the train was moving and "locked" it with paper so we could get fresh air (and this configuration stayed all the way to Sarajevo at least, so it was that way for about 4 hours).
After leaving Mostar, there were soon signs between the train and the river that the area was mined, so one shouldn't go there. The train drives through beautiful landscape. After it got dark, the electric light within the train was not working, so we had (at best) our mobil phones to provide us with light (strange modern times).
Mine warning between the train tracks and the River Neretva
In spite (or: because?) of these technical issues, I meet a few local people from Sarajevo and from all parts of Europe. So the train trip proved to be nice and entertaining, and I learned a bit about government issues there.
Along the tracks, the signals were non-functional. The trains were directed only by flags (and hand-lights) from personal. On entering any station the train had to slow down till I got shown the relevant flag or hand-light that allowed it to leave the station again. Another heritage from the last war.
With due delay, the train arrived in Sarajevo. Due to missing information at the tram stop, I didn't know that the trams to the train station didn't run that late (but I had the information that there would be trams if the train was on time). As it was late, I shortcut that by taking a taxi to the hotel (if I were to arrive in Sarajevo again, I would walk one tram station to the main line - but well, travelling is also about experiences).
Unplanned that evening was also the Sarajevo film festival, with one stage opposite of the hotel window. As this was almost closing down when I arrived in Sarajevo, nothing to worry but to enjoy.
Into the historic city of Mostar: Visiting the Ottoman House was interesting, as well as climbing on the tower of one mosque. In the city, many houses still had effects of shelters and gun shots from the war. (At least) One of the trees in the pedestrian area had many shots as well.
river Neretva within the city of Mostar

City of Mostar from the mosque tower


Ottoman House and bird nests within
Seeing Stari Most, the old (or rather: rebuilt) bridge was nice, as well as the masses of people looking there. However, the area with many tourists was quite small. Whereas Stari Most was shoot down during the war, there was a small sister bridge which survived the war damaged but still existed. However, that bridge collapsed during one high water afterwards but had also been rebuilt.
Stari Most with tourists, sister bridge of Stari Most without tourists and houses along the river
Below Stari Most, there was an area that looked like a nice picknick-place to look at the bridge and old city, but it was obviously unmaintained since some time. Same at other places: Really great, but many of them unmaintained (as in "too less money", not as in "vandalized"). Soon in the afternoon, most tourists disappeared, so I had the chance to look at the city with only few tourists arround before I had to leave for the train.
Walking around Mostar, I meet a few people who were in Germany before, for work, studying or school. The city was quite fascinating - in some way reminded me of 20 years ago. I saw a few more nice vegetables, like kiwis.
Mostar wasn't as tourismn-oriented as I would have expected from the monuments available to see there. All people were very nice and friendly, and in the cafes around there was free wifi. A nice place, but also depressing when thinking how much better it could be.
From Ploce, the bus went parallel to the train tracks. The boarder checks were quite easy to pass - except for one passenger who needed the passport stamped, but the stamp had to be fetched from the office first. That took a few minutes, but nothing too bad either. On entering Bosna i Hercegovina, I had the feeling of a rather dark country, at least compared to Hrvatska (but might be influenced as well that it was just getting dark, and I was in Zagreb on the previous evening). The journey for this day ended in Mostar, where I found a warm welcome in the hotel (which was some 10 minutes away from the bus and train station). An additional difficulty was that the hotel booking system I used to book hotels uses Google maps, but different to openstreetmaps, Google maps doesn't really know much about Bosna i Hercegovina.
Train from Zagreb to Split in Gračac
After leaving Zagreb, the train went through nice countryside. After some time hills started - with given-up houses, walls, areas. As I learned in the meantime, this track used to be not the main line to Split but a backland-line. However, since the last war (the one from 1991-1995), the shorter and faster direct line is still cut. In Knin one could still see the reminders of the direct line which was electrified.
Landscape from within the train
The railway was a mixture of historic operations (with many people, changing switches by going there and by hand and using flags instead of signals) and directly into the 21nd century with electronic signal boxes just being built.
In spite of "the train should be an alternative to cars and busses"-speeches, as there was only one (and overcrowded) train suiteable for going to Split, priorities seem to be elsewhere (not too uncommon for politics on public transport in Europe). Also, there was obviously much more money put into the streets than into the trains.
The journey to Split should have taken about 6 hours, but the train in the opposite direction was a bit late, so I arrived late about 30 minutes. Directly on the platform there was a crowd of people trying to let appartments to tourists etc. Ignoring that, I first got rid of my luggage in the train station, bought the bus ticket for the next leg, and as having planned for late trains still had ample of time to see Split. This was my first "southern" target on this journey, so I could say Hi to fig trees (and their smell as they were blooming at that time).
Split itself has an historic center (being dated back to the Romans). One could also go up a hill and have an overview over both Split and the Adria.
All in all I found Hrvatska being compareable to other nice parts of Europe: Many tourists, overcrowded, and prices similar to Germany. Usage of public transport by tourists seems strange, and mostly only done by interrailers.
These articles cover my way to DebConf 11 through Hrvatska and Bosna i Hercegovina. After telling my initial plans to go by train (mostly) and bus (where it couldn't be avoided) on IRC, I was warned that public transport is quite bad and unreliable. Also, as I live in München, of course this part of Europe was always known as "near" and "could be visited any time" (which means "one never gets to it"; and I can still remember the time when it was Yugoslavia - there are and always were many people living here from that part of Europe; in fact, it's nearer than some parts of Germany). I plan to publish more parts of my way within the next days.
Already at home I also learned that most trains in Hrvatska (and all in Bosna i Hercegovina) are not part of the usual train information system, so it was a bit more advanced to find out the appropriate connections. And in both countries there are only a few trains running, so one shouldn't miss a train ("few" means e.g. two per day and direction - but one at most unappropriate times, so really only one suiteable).
The first day saw me boarding the Suburban train (S-Bahn) at my usual station, changing platforms and trains at München Ost station and then I was sitting in a train to Zagreb. Nothing strange there, except that the coach I had an seat reserved in was missing. I learned later on that it happens more often that the coach from Serbia is not there because it's technically too unfit to send it to Germany -- and usually, there will be more coaches added in Ljubljana. Border checks were uneventfull but at the slovenijan border my passport was stamped (not sure why, didn't happen on the way back).
After arriving in Zagreb and dropping off my luggage in the hotel, I first got some Kunas and then bought my ticket to Split for the next day (as a direct ticket from München to Split was not available). After having done that, I took a brief tour through Zagreb until it became dark, with visiting some of the tourist places.
The barrel is signed with "Schäfflertanz 2012" and "Zur Erinnerung an das Pestjahr 1517" = "To remind of the Black Death-year 1517", and should remind us that even in the darkest times, there is still hope and life goes on.
The machines are delivered only with 256M of ram, which is a bit too less
for usage. Thanks to Zugschlus (Marc Haber) I got 1g ram for both machines
going to Vienna (one buildd, one porter box), and thanks to Robert Grimm
a 160g harddisk to replace the build-in 40g in the porter box (the buildd
can cope with 40g fine). The additional ram modules and hard disk are
visible on the following picture.
eysler.debian.org is now DSAed, online and building packages (including autosigning). I will shutdown monteverdi.ayous.org which is still at my place in the next days, reinstall the system and send it to Darmstadt as another buildd for data center hosting there. After that happens all mipsel buildds are DSAed as it should be, and are running in a data center and not via some DSL line.
(In case you're looking for hardware at your place, there are a couple of loongson 2f-systems available to buy. 2f is the successor cpu of 2e. Some 2f systems get delivered with Debian installed on it, see e.g. http://www.aliexpress.com/product-gs/290632002-Yeeloong-8101-Laptop-10-inch-Debian-EU-Adaptor-version--wholesalers.html. However, for buildd usage, the 2e are fine as well, and we got them sponsored some time ago.)
What needs to be done is to change the following code to have up to n builds happening in parallel (including of getting the next package if there is a free slot).
while( 1 ) { $self->check_restart(); $self->read_config(); my ( $dist_config, $pkg_ver) = get_next_REDO($self); $self->do_build( $dist_config, $pkg_ver) if $pkg_ver; next if $pkg_ver; ( $dist_config, $pkg_ver) = get_next_WANNABUILD($self); $self->do_build( $dist_config, $pkg_ver) if $pkg_ver; next if $pkg_ver; # sleep a little bit if there was nothing to do this time $self->log("Nothing to do -- sleeping " . $self->get_conf('IDLE_SLEEP_TIME') . " seconds\n"); my $idle_start_time = time; sleep( $self->get_conf('IDLE_SLEEP_TIME') ); my $idle_end_time = time; $self->write_stats("idle-time", $idle_end_time - $idle_start_time); }
Any takers? The full code is available from git://git.debian.org/buildd-tools/sbuild.git in the file lib/Buildd/Daemon.pm (and I'm happy to try out appropriate patches).
Update The code above lives in the git branch buildd, and not master. Also, I already have one proposal in my mail.
- release critical bugs: Anyone can help here. If you are an Debian Developer, you can upload NMU bug fixes (precondition as always: the bug is already at least one week old, the fix is long enough in the bug report and the maintainer didn't disagree). Anyone (including non-Developers) can search for a proper solution of an RC bug report, or if it's not RC, downgrade the bug report to important or below. All RC bug reports are available on http://bts.turmzimmer.net/details.php, the RC bug policy is available on http://release.debian.org/squeeze/rc_policy.txt. For "how to NMU", please refer to the Developers Reference.
- bug squashing parties: organise some party in your local Debian community where you meet with other developers and users and try to crush as many bugs as possible: by having them fixed, by proposing a patch, by trying if you could reproduce the bug report.
- release notes: They have been last-minute for all the releases I have watched so far. If you are interested in getting them done in time (and this means speaking with lots of different people now, trying things out yourself etc), that'd be great. There is some work already going on, please refer to http://lists.debian.org/20100318181919.GA31714@dedibox.ebzao.info and http://lists.debian.org/20100404183801.GB1959@dedibox.ebzao.info (plus other mails around this one) for all I know about it. Please coordinate with whoever is already on it (as always).
- release management tools: bts.turmzimmer.net needs to be put on solid ground. If you are interested, please contact me. (Requires: ability to read php; ability to write in a sensible language for a webpage, i.e. python or perl)
- handling transitions: Some of the transitions waiting to happen could profit from someone checking if everything is all right. This means finding out which packages are affected, which of these need sourceful uploads and coordination with the maintainers of these packages. If it should go to testing, care needs to be taken to not entangle it with any of the other ongoing transitions. When all of that is checked and prepared, the transitioning package can be uploaded and binNMUs be scheduled; appropriate access to wanna-build could be arranged if you are a Debian Developer. To avoid many people working on the same transition, please coordinate with us in the #debian-release IRC channel first.
- finding out why packages didn't migrate to testing: Take a package in depenency toplist or top stalls from http://release.debian.org/migration/ and check why it didn't migrate. Do or ask for the proper fix (like filing RC bugs, giving back packages on the buildd, appropriate hints for britney to let a couple of packages go in together, or whatever is required)
- join the release team: If you have enough time to spare to do most of the above on a regular basis, consider if you want to join the release team. If so, please send mail before April 15th to the release mailing list.
Whatever you do: Write about what you achived. Coordinate with others in time. Have fun!
This round of changes was started with redoing our priority calculation. Up to now, any package had a fixed place in the list, and our list was built from top to bottom as far as buildd power was available (putting aside manual intervention by setting build-priority by admins). That meant of course that some packages could be stalled if buildd time isn't enough anymore, like currently on mipsen. (The queue order was determined by the following sort options: build-priority, (>= standard?), already built in the past, priority, section, name, and the first difference decided list order.) Now, of course >= standard packages are still built first, but waiting days increase priority so that old extra packages could be built before young optional package (in other words, they shouldn't stall. The new formula is about: {required: 50, important: 40, standard: 30, optional: 5}[priority] + {libs: 4, devel: 2}[section] + {contrib: -20, non-free: -40}[component] + {out-of-date: 20}[notes] + max(6, waitingdays) * 2 + manual priorities, and packages are ordered by this number, then by waitingdays, then by name.)
While adding code to add bonus for long-waiting packages, we stumbled across the fact that there were non-C dates in the database stored, which in turn means that export of the database stopped to work. For fixing that we replaced the last change field in the database by an postgres now() on insert, and converted that field to an date field (instead of freetext). Which in turn broke mkstats and a few more things, which are fixed as of now.
While doing that, we also introduced the format option, which allows to do queries like:
wanna-build --format='%t %u: %p/%v%{+b}B%B' -A mipsel --list=buildingwhich gives output like:
2010-03-03 15:24:38.642988 buildd_mipsel-mayer: cracklib2/2.8.16-1 2010-03-03 15:30:00.341313 buildd_mipsel-rem: liblouisxml/2.1.0-1+b1
Of course, there are even better possibilities what one could do with that. :) More changes are pending, like the injector for log files was changed so that we record building times in the database. This will allow us to include build time on at least a few buildds, so that large packages cannot so easily stall all buildds completely anymore. So, more to come ...
Now, publishing mailing list subscriptions hased sounds like an good idea to protect privacy. But if thinking twice, this just doesn't work. Most peoples subscription addresses could be known by other means or are even the addresses they use for sending mails (some systems even enforce this). So this is a huge privacy fail.
Getting back to debian, and speaking the obvious out: The new interface to udd is just broken and wrong. Please remove all my adresses from being displayed, either in direct or hashed form, even in restricted mode. Thanks.
- have rsync style (i.e. small) backups;
- multiple backup-from locations per host;
- backup should end on an webdav-device (but "local" in the filesystem will do for starters);
- encrypts to gnupg (multiple keys), but restoring/looking at the diffs doesn't require to either gpg-agent-export the key to the restore location nor to transfer the content to the site where the gpg-key is;
- allows to restore the version of previous days, and allows to view the differences created since then;
- "feels like unix", i.e. configuration in some text-file etc etc.
I took a deeper look at duplicity, but the encryption to gnupg means I need to copy files around. Also the webdav-uploader has some issues if backups get too large (i.e. uploads take too long).
Any other hints? Or is it worth to start to enhance duplicity?
Update: I'd like to generate the backup on the backuped system, but to manage them (i.e. purge old versions) on the backup system. And of course restore to any host within my control. Without exposing any affected gpg key, but just the one-time key(s) for the affected backup(s).
trying: libxi/kfreebsd-amd64_tpu accepted: libxi/kfreebsd-amd64_tpu ori: 127+4202: i-26:a-8:a-22:a-10:h-17:i-12:m-7:m-7:p-3:s-8:s-7:k-2129:k-2073 pre: 127+4202: i-26:a-8:a-22:a-10:h-17:i-12:m-7:m-7:p-3:s-8:s-7:k-2129:k-2073 now: 127+3326: i-26:a-8:a-22:a-10:h-17:i-12:m-7:m-7:p-3:s-8:s-7:k-1253:k-2073 all: -sibyl-installer audiere/hppa linphone/hppa sdl-mixer1.2/hppa unicap/hppa libxi/kfreebsd-amd64_tpu trying: libxi/kfreebsd-i386_tpu accepted: libxi/kfreebsd-i386_tpu ori: 127+4202: i-26:a-8:a-22:a-10:h-17:i-12:m-7:m-7:p-3:s-8:s-7:k-2129:k-2073 pre: 127+3326: i-26:a-8:a-22:a-10:h-17:i-12:m-7:m-7:p-3:s-8:s-7:k-1253:k-2073 now: 127+2463: i-26:a-8:a-22:a-10:h-17:i-12:m-7:m-7:p-3:s-8:s-7:k-1253:k-1210 all: -sibyl-installer audiere/hppa linphone/hppa sdl-mixer1.2/hppa unicap/hppa libxi/kfreebsd-amd64_tpu libxi/kfreebsd-i386_tpuThis quote from current britneys output mean that thanks to the binNMU of libxi to testing-proposed-updates (wasn't in testing yet for these two architectures at all) the uninstallability count of the two bsd-variants dropped down again by a large value (kfreebsd-amd64 from 2129 to 1253, kfreebsd-i386 from 2073 to 1210). Still much to do, but also much progress (and yes, one can now build testing chroots on the newcomers). (And please thank the porters for that, they do the hard work. I just pull the strings a bit here and there to optimize testing migration.)
Most of the issues are not debian specific. But did you every try to use nrpe (from nagios) to check an ipv6-only host? Or use the httplib python library to an ipv6-only host with an https-connect? Just to name two examples of the interessting journey with ipv6-only machines. We are just not there. "We" as the linux world at large, not only "we" as in Debian.
finish: [eglibc,gcc-4.4,alsa-lib,bzip2,gcj-4.4,gnat-4.4,readline5,ia32-libs, ecj,zlib,ncurses,libshout/alpha,openafs/alpha,acpitool/armel,aespipe/armel, calcurse/armel,consolekit/armel,dwm/armel,freej/armel,gadmin-rsync/armel, galleta/armel,geeqie/armel,gpicview/armel,halevt/armel,iec16022/armel, jinja2/armel,keytouch-editor/armel,libjavascript-minifier-xs-perl/armel, libsys-virt-perl/armel,libtest-leaktrace-perl/armel,libwant-perl/armel, libwww-curl-perl/armel,logapp/armel,luckybackup/armel,matplotlib/armel, missidentify/armel,moreutils/armel,myrescue/armel,pasco/armel,pipebench/armel, pycairo/armel,pymssql/armel,python-enable/armel,pywebkitgtk/armel, reglookup/armel,rifiuti/armel,rpy/armel,safecopy/armel,scponly/armel, scrounge-ntfs/armel,shed/armel,sleuthkit/armel,ssdeep/armel,swapd/armel, tct/armel,tmux/armel,trousers/armel,virt-manager/armel,xcftools/armel, flasm/ia64,fontforge-extras/ia64,frama-c/ia64,freecell-solver/ia64,gcom/ia64, geeqie/ia64,gpicview/ia64,gupnp-tools/ia64,heimdal/ia64,hex/ia64, janest-core/ia64,jinja2/ia64,joystick/ia64,keytouch-editor/ia64,ldm/ia64, libhtml-template-pro-perl/ia64,libjavascript-minifier-xs-perl/ia64, librep/ia64,libshout/ia64,libsys-virt-perl/ia64,libtest-leaktrace-perl/ia64, libtioga-ruby/ia64,libwant-perl/ia64,libwww-curl-perl/ia64,lua-bitop/ia64, lua-lpeg/ia64,luckybackup/ia64,lxrandr/ia64,matplotlib/ia64,mklibs/ia64, mlt/ia64,mpdscribble/ia64,mtasc/ia64,ncmpcpp/ia64,newsx/ia64, ocaml-libvirt/ia64,open-cobol/ia64,openafs/ia64,oprofile/ia64, pangomm/ia64,pari/ia64,pidgin-facebookchat/ia64,pipebench/ia64, postgresql-8.4/ia64,prelude-lml/ia64,printfilters-ppd/ia64,ptlib/ia64, pymssql/ia64,python-enable/ia64,qd/ia64,quodlibet/ia64,rasmol/ia64, reglookup/ia64,reprepro/ia64,rifiuti/ia64,rpm2html/ia64,rpy/ia64, safecopy/ia64,scponly/ia64,scrounge-ntfs/ia64,serf/ia64,shed/ia64, sleuthkit/ia64,ssdeep/ia64,structure-synth/ia64,tct/ia64, telepathy-gabble/ia64,tex-guy/ia64,timidity/ia64,tmux/ia64,transmission/ia64, trousers/ia64,util-vserver/ia64,varconf/ia64,yasm/ia64,gmp,nss-mdns] endloop: 30+15272: i-5:a-2:a-2:a-2:h-5:i-3:m-2:m-2:p-2:s-3:s-2:k-7623:k-7649 now: 34+5455: i-5:a-2:a-6:a-2:h-5:i-3:m-2:m-2:p-2:s-3:s-2:k-2725:k-2730 * amd64: fglrx-glx-ia32, lib32ffi-dev, lib32ffi5, nvidia-glx-ia32 * kfreebsd-amd64: gcj-4.4-jdk, gcj-4.4-jre, libgcj10-awt, libgcj10-dev * kfreebsd-i386: gcj-4.4-jdk, gcj-4.4-jre, libgcj10-awt, libgcj10-devThis means that we pushed eglibc and gcc-4.4 through to testing. This reduces the uninstallability count on *bsd by more than half (rather 64% gone). On the other hand, we broke 4 packages additionally on amd64, which are for the i386-compatibility stuff on amd64. Two of them are non-free and linked to the xorg-transition (and we would like to avoid waiting for that transition before we can update eglibc in testing). The other two packages are discussed in bug #533009, and not uploaded yet. After the package is fixed, it can move to testing anytime. As there weren't any reverse dependencies broken, we decided that this decision is the best for our users.
I realized also that it's quite tempting to just fix testing a bit here and there. However, I'm not intending to be back in the "need to fix testing every day"-camp. It's quite a bit of fun to do that after a long pause (and definitly very tempting), but don't expect me to do that every day again.
One of the most important things to respect as an press officer is the proper division of tasks: As press officer I'm not making the decisions nor do I communicate them to the inside. I'm "only" communicating them to the outside, and trying to get the focus of the media set right. That doesn't mean I'm not discussing afairs with the responsible persons for the decisions, and giving advise (and sometimes I'm also voicing an opinion as delegate to the national council - but that's non-public then). But in the end, they need to decide which decision is the right one. Disagreeing with a decision only allows me two ways to handle them: Either ignore my disagreement and still distribute the decision (and that means also publically welcome). Or to step back.
To avoid misunderstandings, one usually considers at the beginning how critical and how much potential for trouble a position statement has. Depending on that one decides how many people need to review a position statement before handing it out - next to no position statement goes out unreviewed. It is always recommended to let any position statement be signed off by the people responsible for the decision. (But in constrast to signed-off patches, never tell in public who did review and sign-off a position statement - either the organisation has decided it according to their internal governance process, then the decision is proper and signed off by the organisation as whole. Or it isn't, then there is no position statement.)
Asking the press officers to make their own decisions and contradicting the decisions as taken by the governancy rules is counter-productive: This will at best only lead to confusion to the outside, and unnecessary conflicts on the inside. Usually it will get way worse though.
Looking at Debians press team, I'm quite happy to say that they work in a very good way. Please continue to keep up your good work.
Some transitions didn't work though: The transition of eglibc to testing failed as ia32-libs were changed quite a bit on amd64 (where is multiarch?).
All that together was more than six hours of running our testing migration scripts, analyzing issues, changeing hints, ...
Actually, that's quite simple, and there are basically two aspects of the same reason involved. First of all, I'm no longer one of the release managers. I stepped down after a having a very good time, and agreed to hand over the power to the current release managers. A transition of powers that mostly are social engineering powers can only work if one really stops using the powers. If I am only quiet in public when I disagree with the current release managers, it would be obvious when I agree and disagree. So I must be quiet in public about release decisions all the time, at least currently (this will hopefully change some time).
That doesn't mean I'm not voicing my opinions inside the release team - there I voice them openly, and will continue to do so. But of course I respect the authority of the release managers, granted to them by the constitution, and I will base my own actions on the decisions by the persons or bodies empowered through the constitution.
Now, some people told me I could just voice my opinion as normal developer. Though this seems be true, it isn't. Anything I say will always be read as the opinion of the former release manager. I might perhaps return to that state in a few more years time, but as of now, I just cannot.
Now, my position is quite easy. I could just shut up, and not write this blog, and ignore the few people who are directly asking me. For some people inside of Debian, this is not possible. For example, the press team has the task to transport the decisions and happenings inside of Debian to the outside. So they have, no matter what there own opinions are, to send out a press announcement which is positive of the decision. Their only option for not sending out that mail would be to step back. And frankly speaking, I'm really happy with what the publicity team has done. They are doing a very good job. Thank you for that.
Please remember: It's of course ok to not like the message. But please do not shoot the messenger. And remember, the publicity team (and for that decision also the DPL) are only messenger.
I want to congratulate the people who made it happen, especially the people who worked for it for many months or even years. To avoid the pain of not mentioning someone who did lot of work, I restrict myself to congratulating my successors in the release team - a better list of people is part of a mail Marc just sent out. Thanks, and well done!
Good news is that this means: We're really quite near the release. Only some RC bugs to crack (anyone can help here, seriously), and we should be done. Let's work together and make this happen again!
The two remaining solutions we looked at are Xen and kvm.
Xen has of course the advantage of the matured. Also, we have experience with running xen servers - and with the issues that can happen, like the chances to disconnect dom0 from xend, and then reboot the server the hard way. However, the most serious disadvantage is that development has practically stalled with the 2.6.18-kernel. Of course, even of today one could install a new server based on Etch, but that doesn't really feel right. There is some development ongoing to run domUs with newer kernels (like in Lenny), but there isn't currently any new kernel available for dom0.
kvm is a more recent addition to the virtualization camp, and is basically "qemu on steroids". All looks rather promising, development happens with the recent kernels. However, kvm lacks a few features of e.g. Xen.
This includes the ability to reboot dom0 (and the hardware) and just let the domUs survive. Or to have a nice management script where one could just say "xm shutdown $domU", and have basically the power button be pressed on the virtual machine. Or to just attach and detach to the virtual console whenever one wants. Nothing of that is impossible with kvm, one could attach the command-terminal to some pipe, and the linux console to some other, and attach and distach via own scripts. But - all of that should be expected to be available from some solution that calls itself enterprise ready. (And - writing own scripts has always the possibility to make own mistakes.)
However, among all the worst possible issue is that kvm is underdocumented (or rather: There are lots of different places where some parts of the documentation is hidden - including the great remark in the man page "The other options are similar to those of qemu.").
So, what to do? Invest more time into a solution that seems like a dead end. Or put up with the incompletness of another solution?
One example of that kind is webauth, however that requires that all user accounts are in kerberos. I however want to continue to keep accounts in ldap, because that works well for most issues.
So, my next step is either to set up kerberos in a way that allows the accounts to be synced with ldap, or find another software with the same effect.
Sometimes it would be much easier if one can just tell apache "take this dn, add the supplied user name there, and there you go". Any ideas how to do that?
Stephen Gran gave me some valuable hints to using the rwm-rewriting engine.
After some time, I ended up with this setup:
overlay rwm rwm-rewriteEngine on rwm-rewriteMap ldap attr2dn "ldap://127.0.0.1/ou=myorg?dn?sub" rwm-rewriteContext bindDN rwm-rewriteRule "^anyid=([^,]*@[^,]*)" "${attr2dn(mail=$1)}" ":" rwm-rewriteRule "^anyid=([^,@]*)" "${attr2dn(uid=$1)}" ":" rwm-rewriteRule "^(uid=[^,]*)" "${attr2dn($1)}" ":" rwm-rewriteRule "^(mail=[^,]*)" "${attr2dn($1)}" ":"
The only thing that doesn't work is to make rwm using ldap version 3 to log into itself, so I had to allow read-only access to the relevant attributes from peername.ip=127.0.0.1 - but well, I can live with that.
Update: Added anyid for not thinking in client code, and made sure only the start of entries is used.
Now, of course an idea would be to specify all different attributes as a new "loginas"-type one. Another solution would be to use ldap overlay modules, and just convert them "on the fly". Better ideas would be welcome.
Update: Thanks to Faidon Liambotis (again!) one can probably use mod_authn_alias to combine authentication with user name, mail adress etc.
aba@ries:~$ grep final update_out/update.OUTPUT_py | cut -f 2 -d ' '| tr , '\n'|wc -l 901
This means 901 packages went from unstable to testing with the most recent britney run (though counting each binNMUed source package as ~12 packages here). Only about 200 packages which are otherwise ready for migration tried to go to testing, the vast majority reached testing.
Major reason for this move is that now libselinux was ready, and we were able to migrate libselinux, pango, glib2.0 and ocaml which dependend on all of them (the last transition being responsible for about 700 packages).
Good news for armel as well:
start: 61+442: i-2:a-0:a-0:a-21:h-11:i-0:m-4:m-11:p-0:s-0:s-12:a-442 end: 60+367: i-2:a-0:a-0:a-21:h-11:i-0:m-4:m-10:p-0:s-0:s-12:a-367So some progress as well - it's a steady move towards a reasonable uninstallability count (the last number being armel).
So, let me give you an example. Take e.g. the dnsZoneEntry attribute in the debian.org-ldap. Actually, one wants to allow anyone to write into that attribute in his own entry. But - and that's a big but - one wants to have two additional checks before writing: One is that one cannot claim any dns entry already used by someone else. And the other is that the format needs to comply to specific standards.
Now the question is, is there some way to use ldap with more semantics? Or does one need to write ones own backend to do that (and in all the non-plain-db*-backends, it is specified that one needs to write his own authorization code as well). Or some other recommended way to do that? (Or is the only existing incarnation of that ActiveDirectory?)
Update: Thanks to Faidon Liambotis I know now about the overlays in openldap. The standard overlays unique and constraint will probably solve the case above - of course, I have a few more complex cases, but that are at least good starters.
trying: mysql-dfsg-5.0 accepted: mysql-dfsg-5.0 ori: 71+890: i-3:a-0:a-0:a-23:h-13:i-0:m-8:m-10:p-0:s-0:s-14:a-890 pre: 71+887: i-3:a-0:a-0:a-23:h-13:i-0:m-8:m-10:p-0:s-0:s-14:a-887 now: 71+773: i-3:a-0:a-0:a-23:h-13:i-0:m-8:m-10:p-0:s-0:s-14:a-773
In other words, the transition of mysql-dfsg-5.0 to testing has reduced the uninstallability on armel from about 900 packages to less than 800. Still some way to go, but good progress.
However, now we reached a point where a few more release teamisch hints don't help anymore: The next large blocker is gcj-4.1 / gccdefaults / ecj. This is now blocked by different bugs on different architecture:
- mips* needs to have xulrunner built first to build gcj-4.1. This is discussed in bug #428582, and the porters are busy working on it.
- hppa fails for unknown reasons - probably it needs some porting. That should be discussed in bug #431865 but until now there was no answer from the hppa porters.
- arm already reached the state of being out-of-date to a degree that it needs bootstraping by hand - see http://lists.debian.org/debian-arm/2007/07/msg00014.html for reference.
Update: Aurelien Jarno informed me that gcj-4.1 had to be bootstrapped on all architectures, but it hasn't happened yet on arm due to bugs in gcj.
- libglide2: Reproducible segmentation fault with Voodoo2: Latest info is from December 1st that a driver needs forward porting
- initramfs-tools: [powerpc64] i-t tries to mount RAID/LVM stuff before the disk are up -> unbootable: Last mail from December 11st with suggestions from Sven
- libmail-mboxparser-perl: FTBFS: build times out during test (t/3_while): Possible workaround already in the bug log
- lvm2: several issues with devmapper devices: The maintainer didn't care to comment at all until now
- parted: NTFS (partition) not recreated correctly after resize:incorrect start sector: lots of discussions on December 16th, quiet since then
Now, one needs to locate the lying package and fix it.
If someone inside the Debian community fails for the same is way more disappointing for me. I have never stated that "[I] couldn't compensate this" - that is just totally wrong. I think that dunc-tank helped us with release of Etch, but the help could have been greater if some people wouldn't behave as childish as they do. And I also try to look both ways, and not be singled-minded about it.
There is another thing I learned as well during the last 12 hours - people don't appreciate if one tries to summarise openly what happened, and look both ways. Is it so wrong to look in both directions, and not only say "that and that were the improvements"? I thought at least within Debian we don't want to fall the usual management mistake of only speaking about how great everything is, but be honest to ourselfs. People starting to rip only half of the words out, citing them out of the context, and inventing new quotes don't help with that.
Rest of the day was mostly spent on further libpng-analysis. There is now a nice table on http://ries.debian.org/~aba/png.abis which symbols were exported in which version. We are progressing into resolving the libpng problems now.
I suppose I don't need to be more specific about what I did in detail - my blog postings in http://blog.ayous.org/en/debian/etch-rm/ cover that already. The thing that ate most of my time are the release critical bugs. While it is possible for me on normal days to fix one bug every few days, it was now possible to fix a couple of bugs per day. This sounds rather good, but at the same time took away most of my time for other things I should have also worked on - that even involved blogging about my work. (Also in looking back that was still a good decision to work so much an release critical bugs - it would have been just more convenient if that wasn't necessary so much.)
Looking back, I started with improving tools. I think that this was a good decision, good tools make work easier - and also, everyone can use the better tools, so they multiply their benefit. And e.g. the structural changes I did to bts.turmzimmer.net to allow "show also related bugs" were so deep that I probably wouldn't have been able to do them, unless I reserve a couple of hours in a row. In other words, being able to explicitly set some time aside for Debian which is not eaten up by the daily routine tasks (which involves reading quite much mail, BTW), is a good thing.
So, looking at the status changes during the time I spent full-time on release issues I think it worked well. Of course, not everything is perfect, but there is a clear improvement. On the other hand, there was a large disadvantage of the whole experiment: Some people who used to do good work reduced their involvement drastically. There was nothing I could do about, and that happened way before I started full-time on release, but on the global picture that still counts. So, as a first summary, I am happy with my own involvement, but that doesn't necessarily apply to the full experiment.
Update: There are media rumours floating around that "[Etch has] been delayed because some developers have deliberately slowed down their work". This doesn't reflect what I said.
I just noted that the dunc-tank experiment has positive and negative effects, and we shouldn't watch only one side - whichever that side is. The reasons for the release being delayed from the original planned date has other reasons, please read the mails on debian-devel-announce for details (also all linked on http://release.debian.org/). And, I'm quite happy with the involvement of most Developers in the release. (And this paragraph isn't part of what this blog posting should be about really, but as it is cited, it is still here ...)

So, if you look back we have written "RC bugs below 80" as precondition in our timeline. We copied that from the sarge release, were we had "~85 RC bugs" at time of freeze. During detailed planing, it became obvious that if we want to basically "go by the same numbers", that is (and can only be) the number of RC bugs applying to both etch and sid - as that was the only stats we really had during sarge release planing (please remember, we didn't had version tracking at that time, at the moment where a bug fix was uploaded to sid, the bug disappeared at all, unless someone reopened the bug report and tagged it sarge).
So, we agreed that we can and should freeze Etch as soon as the combined number is below 80, and the number of fixes waiting for transition is not out of control (and a few other issues are resolved, please see the previous mail to debian-devel-announce for that).
Please allow me also a personal remark: It is really sad when somone tries to hurt active Developers working on the release, while not contributing anything except spite. I don't think that is adequate behaviour.
Thankfully, most of that worked out well, so we were able to freeze Etch today.
Of course, I worked also on one of the preconditions, namely on RC bugs - the usual trying to reproduce, uploading fixes, encouraging other people to upload fixes, easying testing transition, ...
Looking at bugs like e.g. #399589 - asterisk-oh323: Asterisk OH-323 crashes latest asterisk package, it doesn't seem to demanding to expect also in a team-maintained environment that any of the maintainers recheck (or at least send mail) to the person reporting the bug within a week. However, the bug was reported on November 20th (that's a Monday), and nothing happend up to now from their side - means: Nothing within 11 days. Unfortunatly, there are more so buggy packages from the VoIP-Team - most can just be moved out from Etch, but it is always unsatisfactory to remove packages.
Tuesday allowed me to also upload a few more RC bug fixes. Besides of that, lots of the usual gruntwork and small items were done - nothing special to talk about, just answering couple of mails, reviewing packages, and all the rest of daily routine job (which becomes quite much shortly prior to release).
On Monday morning, the trend on the RC-Graph didn't looked too good
,
so I invested resolving RC bugs. A couple of NMUs later the graph now looks better -
but of course, there is much more that needs to be done.
Beside fixing packages, I did the "usual" small jobs, including reviewing cyrus-sasl2, answering lots of mails, and so on.
As you can see with the large graph, we did some important progress. As the small graphs show, we should try to get better again. :) So, let's work together on that, and let all three curves go down again.
After that was done, some normal RC bug squashing started - nothing special about, just "another few bugs gone".
- #397623: During build of gimp-help, xsltproc tries to download the DTD from the web address. Anyone knowing how to prevent that could probably fix the bug within minutes.
- #397636: open-iscsi: This seems to need just a new upstream version, but nothing for somebody who doesn't use open-iscsi himself. Update: Martin (zobel) will take care if the maintainer doesn't fix this bug.
- #397655: debiandoc-sgml has issues generating cjk-packages correctly.
There are a couple of more such bugs available, please feel free to visit our RC bugs list yourself.
Also, more comments on the release notes have been merged. We are now at an state where I'm happy to let users work with the release notes - though one large section still needs work: What is the appropriate order for upgrades of kernel and packages.
After that was done, I started myself with some upgrade tests to see how the packages really behave. More on that on one of the next days ...
That's good news because we want to have release notes available now as we have an Release Candidate of the installer published.
And as always, some time is spent on the thousands minor little things that are so time-expansive. But still need to be done.
- #396782: apache2.2-common: Upgrade adds "default" virtual host; breaks existing config: the problem is that apache2.2-common is new in any case, as we had apache2-common in sarge. One possible fix would be to detect if any site is active in /etc/apache2/sites-enabled (e.g. via find) and add the default site only if none is there at all.
- #396265: apache2: mod_proxy_ajp connection reuse bug: This problem is perhaps not specially easy, but - there is a patch upstream, and it seems to have some security impact as well.
- #395936: Apache2 SSL service stopped working since upgrade to 2.2.3-2: -D SSL went amiss when apache2 and apache2-ssl were merged - in case we can't fix that with reasonable effort, it should be documented in the etch release notes
- #391813: apache2.2-common: man page for apache2 missing in apache2.2-common: obvious fix
- #338472: apache2: Move /server-info and /server-status conf to mods-available: obvious fix, but that's a policy decision
Some more bugs were obviously outdated, so I closed them. I also started collecting information for the release notes about apache2.
All "good" activities, but obviously not really "working on the release", so I mark Thursday as day off, and will add another day at the end of my schedule.
In the afternoon, I worked on my mail backlog, and answered e.g. a longish mail from an journalist about release management in Debian. Not something that directly improves the release, but I believe it is also time well spent - if we get our point of view distributed better. Amazingly again how much time one can spend with writing stuff.
One also is hinted to many issue which escaped attention so far, so it involved also a round of bug severity changing.
Also, I finished working on "how does apt behave with more than one signature" for now: There is http://testmirror.turmzimmer.net/debian which has an additional signature on the sarge Release-file (thanks to Netcologne for hosting) - please feel free to just use it for any sarge system, and report errors back. I'll revisit the experiences in two weeks time.
The rest of day involved smaller issues, e.g. fixing the sort-by-bugnumber-mode on bts.turmzimmer.net (which I broke with yesterdays changes for "related" bugs), and a couple of other things. I also started to update the etch-release-page, but that needs to be continued tomorrow it seems. After I saw some more people not too happy with apache2.2 configuration changes (or rather, some modules are no longer there automatically), I decided to dedicate this Thursday to Apache.
Please feel free to try out that host as mirror for your sarge-based systems, and report any breakages that happen. The second key I used is the volatile archive key (as that was easy available) - I'll switch one day to the real Stable Release Managers key.
After that was started, I invested some time on a long-standing wishlist bug on bts.turmzimmer.net, so that one can see even the RC-bugs related to a (source) package which would be ignored otherwise if at least one bug would be shown. This required some more code cleanup first. Now everything should work.
I started the afternoon with creating a list of open tasks that are not marked as RC bugs, and dependencies between those. During that, I learned that the security teams thinks that we lost the security sparc autobuilder - not something that makes me happy, and something that needs to be fixed independent of Etch. Actually, it seems the autobuilder is just recovering, but I'll continue looking at it.
apt-keys
One item open on the list of open tasks is the final usage of apt-keys (which involves me in more than one way), so I started a testbed for having the Release-file signed by more than one key, and check whether apt is still happy. Adding another signature turned out to be quite easy with just adding it to the Release.gpg-file.
If there is more than one signature on the release-file, but not all keys are know to apt, apt warns, but doesn't stop:
W: There are no public key available for the following key IDs: 010908312D230C5F
If however there is a bad signature, apt fails, even if there is also a good signature. (And please note, if the key is unknown, the signature is not bad but unknown - this gives the interesting behaviour that removing a trusted key by apt-key my remove the need to explicitly confirm to go on with the upgrade.)
Summary on apt-keys
Current behaviour is ok, we just need to sign one file extra with each stable (point) release, and this can be done with: gpg --no-default-keyring --secret-keyring srm-secring.gpg -b --armor < etch/Release >> etch/Release.gpg (or rather, sign off-line, and append on ftp-master).
The behaviour with multiple keys might look a bit strange, but IMHO we can live with it.
I'm currently preparing to use real keys, and publish the result on some place where anybody could test it (for the latest sarge point release), and I hope we can put it on for the next point release on ftp-master.
The Amendment has a similar effect - it will definitly allow us to ship with tg3, typhoon is unclear. It also supports a decision by the release team - but well, we can also live without supporting that decision (as long as nobody overwrites it).
Summary: Any of the proposals allows us releaseing Etch soon. There is a "better" proposal upcoming, but that is not a reason to refuse the current one.
- 364038: evolution: message moved from one imap server to another vanish under certain circumstances
- 370186: hal: HAL keeps CD drive spinning constantly
- 202488: isdnvboxserver: Spool directory incorrectly renamed on upgrade
- 330084: xawtv-plugin-qt: segfaults on start recording
- 379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition (also as parted-bug, #380226, partman-partitioning, #379835)
-rw-r--r-- 1 aba aba 1381 Oct 2 10:54 etch-gr-1.txt
I'm sorry if the mistake is on my side, please tell me what to fix in case it is.
- The debian-installer has to be changed prior to release of Etch. This change alone would delay by at least 6 months, according to Joey's estimations.
- Even fonts and videos would fall into the category where we would need source - but what is the source of a font? or a video stream? (and yes, fonts are "works that are executed by other means", i.e. displayed on the screen) That is a great new place for lots of new discussions that don't really help our users, but will definitly waste lots of time.
- We would be in a very bad situation e.g. with the debian-keyring (and all other sort of crypthographic stuff) - I definitly don't plan to distribute the sources for my public key (as the sources can also be used to generate the private key).
In summary, this proposal would delay the release of Etch by at least 6 months, probably even one year. Of course, any of the pending GRs can still overrule the result of this GR, but - that is not something we should be proud about, or even plan.
On a personal basis, if this GR becomes effective would also mean that I failed to manage the release of Etch.
- All employees of the City of Munich will work on a Debian-based system. That is really just cool, especially for someone coming from Munich and living there since ever. That is even better if one is actively involved in release of Debian.
- The City makes this move for a very good reason - as part of a long-term strategy to escape vendor-lockin. The City has been known for years to make such good decisions in different areas - power, public transport, water, and now also software. That's actually one of the reasons why it is really worth living here.
So, I tried building my own kernel again. But then something happened I definitly don't want to see at all:
CC [M] drivers/net/e1000/e1000_main.o drivers/net/e1000/e1000_main.c: In function `e1000_xmit_frame': drivers/net/e1000/e1000_main.c:2919: internal compiler error: in simplify_subreg, at simplify-rtx.c:2368 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see <URL:file:///usr/share/doc/gcc-3.3/README.Bugs>. make[4]: *** [drivers/net/e1000/e1000_main.o] Error 1 make[3]: *** [drivers/net/e1000] Error 2 make[2]: *** [drivers/net] Error 2 make[1]: *** [drivers] Error 2 make[1]: Leaving directory `/usr/src/linux-source-2.6.17' make: *** [debian/stamp-build-kernel] Error 2
So I not only lost support for my printer up to now, but even waste more time debugging stuff I don't want to see.
That would be a complete overhoul of the current structure of Debian - currently, the DPL has only very limited power and cannot steer if the delegates disagree (unless he de-delegates). But I think that change would be a good change.
There are some packages that would become uninstallable by that now, and the task is to just check them and fix them: ethereal-dev, gaby, gforge-plugin-scmsvn, gnome-tasksel, gnuradio-examples, gr-audio-alsa, gr-audio-jack, gr-audio-oss, gr-usrp, gr-wxgui, guml, hplip, ifrit, ldaptor-utils, ldaptor-webui, lfm, libghc6-missingpy-dev, mboxcheck-applet, med-bio, memaid-pyqt, mock, musiclibrarian, ocfs2console, omniidl4, omniidl4-python, plywood, positron, pydict, pyftpd, pykdeextensions, pymol, pyntor, pypanel, pyrad, pyslide, python-dispatch, python-gdal, python-gdchart, python-gdchart2, python-gdk-imlib-1.2, python-glade-1.2, python-gnome-1.2, python-gnuradio, python-gtk-1.2, python-ldaptor, python-mapscript, python-metakit, python-moinmoin, python-notify, python-numeric-tutorial, python-phidgets, python-protocols, python-sip-qt3, python-turbojson, python-usrp, python-zeroc-ice, pythoncad, pytone, releaseforge, rubrica, scalemail, scanerrlog, scigraphica, snappea, snappea-dev, spikeproxy, sql-editor, viewcvs, viewcvs-query, wireshark-dev, xen-ioemu-3.0, xen-utils-3.0, xkeysw-config, yum, zeroc-ice
For example, gforge-plugin-scmsvn depends on viewcvs which needs to be converted to the new policy. Everyone can take his share - just choose any package, look why it becomes uninstallable (perhaps via a dependency becoming uninstallable) and fix it. Oh, and please set the urgency to high and make sure prior to upload that the package still works.
(This is only the list on i386, but experience has shown that once it's resolved for the first architecture, it isn't too hard to resolve it for the other architectures also.)
Update: Some packages are already in the progress, e.g. ethereal-dev depends on wireshark-dev which depends on omniidl4 which has been NMUed already. Well, like always: Check what the issue is before fixing it. And if binNMUs help, please just tell us.
2. Update: It would be really helpful if someone could take care of viewcvs.
3. Update: The most important open issues are: viewcvs, mapserver, moin (whereas viewcvs has a good version in experimental, maintainer is contacted). Also, these programs might need some love to get converted to the new standard or have otherwise real NMUs: blogtk boa-constructor codeville drpython fnorb freeloader forg fvwm-crystal gco gdebi gdeskcal gnome-btdownload python-visual gaby guml ldaptor scalemail lfm missingpy mboxcheck-applet yum mock musiclibrarian ocfs2-tools plywood positron pyftpd pyntor pyrad pyslide python-gdchart pygdchart2 libmetakit2.4.9.3 moin pythoncad pytone rubrica scanerrlog snappea spkproxy
I'm however wondering if that's really a good idea?
Today, the uninstallabilities went down even more. Istanbul has been updated from unstable, and is now installable again. So, this leaves us with:
- 0 uninstallable packages on powerpc, alpha and mips*!
- the only uninstallable package on i386, stars has been rebuilt, and should go into testing tomorrow or so - so we can expect 0 uninstallable packages on 5 arches by then.
- ia64 still has libevolution-cil uninstallable; a rebuild of evolution-sharp might solve it.
- Some of the remaining 16 packages on amd64 are connected via the uninstallability of rpm to the neon/perl-transition; the major issue there is that perl FTBFS on a couple of architectures right now. But everything looks rather smooth there, once we resolve the perl issues.
- For the other architectures, not so much progress has happened.
force-hint gnome-media/2.14.2-1 sound-juicer/2.14.4-2 nautilus-cd-burner/2.14.2-1 libsexy/0.1.8-1 rhythmbox/0.9.5-1 gnome-python-extras/2.14.0-2 gnome-system-monitor/2.14.4-1 libgtop2/2.14.1-2 libgksu/1.9.4-3 wmfire/1.2.3-2 gnome-python-desktop/2.14.0-2 totem/1.4.1-2 evolution-data-server/1.6.2-3 gnome-panel/2.14.2-1 evolution/2.6.2-4
That means that all these source packages (and associated binary packages) are put into testing independent of what they break - but we assured before that they won't break anything bad. So, the result of that was that a few packages were broken on a few architectures, but we prevented that this large transition sticked together with the next large transition.
These changes allowed us today to remove xorg-x11 (6.9) from testing, which brough uninstallabilities down to a very good level on most architectures:
- 0 uninstallable packages on mips*.
- istanbul is the only uninstallable on alpha and powerpc.
- in addition to that, i386 has also stars uninstallable, a package in contrib; ia64 has also libevolution-cil uninstallable.
- After these very good number, some not as good numbers include amd64 with 17 packages (still open from addition to testing), s390 with 21 packages, hppa with 27 packages, arm with 30 packages and sparc with 37 packages. Way behind is m68k with 183 packages.
If you are interested in the detailed stats, they are at http://ftp-master.debian.org/~aba/test-issues/. If you are a porter of a not-as-good arch, you might be interessted to work on reducing the amount of broken packages - our goal is to have none at release.
After this task is done, the next difficult one is already approaching.
Actually, we couldn't investigate in the removal matter any more until the python-gnome2-extras build issue is resolved.
(Just to prevent misinterpretations: As usually, I'm not complaining about anybody involved. I'm just not that happy with the issues we have.)
Lesson from this: If one adds a package as a fundamental part of any important system part (and python is one), one should make sure that a compatible version appears in testing as soon as possible. This is now resolved as I added an urgent-hint for python-support, but actually I would like to see maintainers more active on this.
More issues to come, on another hint I'm trying to get resolved, I detected an ICE (Internal Compiler Error) on ia64.
In sum, there is really some arch-specific pain available right now. I'm not happy with that at all.
Now, we made some fantastic success. Liboil is in testing.
However, now we get to more issues: xine-lib FTBFS on sparc with the wonderful error /tmp/ccoqKu6u.s:6222: Error: Illegal operands: There are only 32 f registers; [0-31]. Gotcha.
Also, totem now needs also the new version of rhythmnbox in testing - and rhythmbox does not only depend on totem, but also on dbus (0 days), gnome-media (which waits for nautilus-cd-burner, which has itself a bunch of issues open), and the libsexy transition.
Let's see how long it takes to sort xorg-x11 out.
Even more, the major drawback of the competiting python-support is that it refuses to handle the real issues. Of course, reality is complex. But it is way worse if one writes a tool that just breaks if a package earlier in the dependency chain decides to change from python scripts to extensions (i.e. c-code linked with python).
Furthermore, the maintainer of python-support first agreed on some common solution for both tools (i.e. the new python policy), and now suddenly removed his approval, and creates another competiting way. I'm all for competition between software, but I'm not too happy with competition of policies - because policies describe how different packages work together, that means, it is an interface description.
In the end, my summary is that I recommend to use python-central. And I'm thankful that Matthias did a careful and good analysis how this implementation is done.
Update: I learned that in python-support 0.3 the bug is fixed that changes in the dependency chain can cause breakage (as the tool adjusted partly to the results of the discussion in Mexico); this is not yet true for the version in testing (but that's only transitionary, so I don't mind so much).
To keep gnome-desktop-environment installable, totem needs to be installable, and for that, totem-gstreamer and totem-xine needs to stop depending on xlibs. This is an easy rebuild, except that xine-lib in sid was RC-buggy.
After an maintainer upload fixed that, everything seemed settled. Until we noticed that xine-lib cannot be build, as the new gstreamer0.10 version in sid prevented any builds on buildds because it couldn't work as build-dependency if there was no home directory.
This was solved by an fast maintainer reaction after this feature was marked as being in the way.
Unfortunatly, at the same time as gstreamer0.10, also gst-plugins-base0.10 was uploaded to sid. That shouldn't make any difference, except that the new totem builds also depend on the new version of gst-plugins-base0.10. As gst-plugins-base0.10 is working, that is not an issue.
However, gst-plugins-base0.10 also depends on liboil. And in unstable, there is a very technical interessting RC bug #368991. So, the next task is to resolve that bug report - any help is welcome. Let's see what is next.
Update: In none of the cases, I was complaining about the maintainers. I know that some of the bug reports are really difficult, but e.g. looking at the most recent bug report, the maintainer seems about to fix it locally in this lib (though one might want to argue that gcc should be able to get it out by itself). My intention was to show how long sometimes a rather simple thing could get. In the beginning, all was a "simply rebuild" - now we have a rather large block of packages clueing together.
Notable Changes --------------- Sudo has been changed to not propagate all environment variables to subsequent programs to avoid security risks. This change might affect software that uses sudo. Please see /usr/share/doc/sudo/README.Debian for more details. Miscellaneous Bugfixes ---------------------- This revision adds important corrections to the following packages. Most of them don't affect the security of the system, but may affect data integrity. affix-kernel Fix build failures with sarge's kernel backuppc Fix possible backup archive corruption and possible data loss when changing the configuration file cernlib License problems, repackaged cyrus-imapd Don't remove mail data on package purge cyrus21-imapd Note cyrus-imapd data loss on package purge in upgrade documentation evms Fix address stack corruption leading to possible data loss when activating degraded RAID-5 volumes exim4 Fix mail delivery problems to hosts with AAAA DNS records and unbalanced DNS f-prot-installer Adjusted to work with recent releases fai Fix setup of lo device, replaced hardcoded name of debian distribution in fai-cd, add missing packages when calling fai-mirror glibc Update timezone data, fix NPTL for x86_64 (amd64) leafnode Fix security issue (CVE 2005-1911) libchipcard Don't remove user account on package purge mutt Fix possible attachments data loss perl Fix problem with utf-8/taint interaction Fix possible malloc-to-death bug, #227621 rssh Fix security issue (CVE-2005-3345) slune Adjust to security fix in py2play, #326976 sodipodi Fix segfaults on 64-bit architectures tar Fix inability to work with remote devices on non-i386, #356657
The dak runs on wp.debian.net. Uploads happen via the normal means, with wp.debian.net as target host. The overrides are synchronised from normal debian, as well as the keyring. Please use unstable or unstable-wp as target suite. There is an autobuilder for powerpc currently running, more autobuilders might follow.
Please feel free to throw dpkg-source 2.0 packages at it.
Now that this step is done, I need to search a victim box to set up a regular dak, so that people can play a bit more with it (and of course, that dak installation will accepted any signatures from the regular keyring). Furthermore, I plan to add autobuilding for some archs to it (i386? powerpc? amd64?), so that one can really see how it behaves in a real world scenario.
Something else one should also do there one day: create an extra directory where the packages will be repacked in dpkg-source 1.0 format.
So, this sentence is correct: "Sagt mal, was ist eigentlich der Sinn hinter Clint Adams blog?!" (or as I would rather say "... Clint Adams seinem blog?!" :). And, so Clint is right.
Update: I was notified by two different people already that the current new german grammer disagrees with me. http://www.ids-mannheim.de/reform/regelwerk.pdf tells in §96 that the usage of the apostrophe is right. Well, of course I'm conservative and haven't upgraded to the new grammer. :) Besides of that, my feeling is still that the apostrophe is wrong.
Another nit-pick: The "... Clint Adams seinem blog"-style is known to be not official german. But it works quite well, and is even conformant to the new rules.
$id@verizon.net SMTP error from remote mailer after MAIL FROM:<$myid@not.so.argh.org> SIZE=2849: host relay.verizon.net [206.46.232.11]: 550 Email from your Email Service Provider is currently blocked by Verizon Online's anti-spam system. The email "sender" or Email Service Provider may visit http://www.verizon.net/whitelist and request removal of the block.
Basically, this means: unless you are a large provider, you cannot send mail to verizon's customers. Of course, mail is something in both directions: Who wants to receive mail from me should better not use a Verizon-address, otherwise, I'm just to send mail.
Also, one flaw in tiffani has been detected already. Please see this mail for more details of that bug.
aba@spohr:~$ madison glibc glibc | 2.2.5-11.8 | oldstable | source glibc | 2.3.2.ds1-22 | stable | source glibc | 2.3.5-6 | testing | source glibc | 2.3.5-6 | unstable | sourceThanks, Anthony and Steve for hand-"holding" it in. It worked. Now let's see how fast we can sort out the remaining issues (xorg-x11, gcc-4.0, ...). In other words, this is not a "let's break unstable again"-call, but rather "we progressed by one step, let's do some more steps now"-one.
That was the best answer I got till now. And you can see that this mirror admin is really devoted to Debian.
(And, BTW, please don't read this as negative about e2fsprogs - it just happens sometimes that a bad bug stays somewhere at an unfortunate time ...)
Update The main thing of this entry is the tiny rsync in the URL. With http and ftp, it's trivial. wget and lynx support it out of the box, and also all the major scripting languages. Just rsync is unsupported - which is however what I need.
<Yoe> aba: it's happening on m68k too <aba> Yoe: well, but I guess nobody calls i386 a doorstop-architecture :) <Yoe> actually, I do <Yoe> the only i386 of my own I still had at home broke down last week

... but we are in Espoo.
Using something in the data acl violates my sense of beauty. If it is possible to announce it at the start of a message, I want to do that and not do it way later in some ACL.
Of course, I might still be forced to come back to that suggestion, as I need it for my buildds pretty soon. Thanks, Wouter, for your help.
A feature that would really improve my mail configuration files would be if
exim4 could handle hosts list in conditions, so I could write something like
${if $host{$sender}{+buildds}}{100MB}{2MB}
.
Well, time'll tell when upstream (or some nice gently soul) will provide that feature.
It was quite hard to find out what ticket to use. First, I was told that there is a 2-hours ticket for 2 dollars, and a day pass for 8 dollars. Of course, the 2-hours ticket seems better with that. However, that ticket is only good for one zone, and as tourist, one usually wants also to get a bit out. Also, it's not 2 hours, but 90 minutes. Well, I learned that lesson.
Next one is: Which busses start where - and when. If you have luck, some bus stations tell you which lines go there. But that is not always accurate. Even less stations (and especially not the changing stations like Lonsdale Quay Market) tell which times a bus will go.
The most difficult one is to get an impression how the lines go. You can see a full map at the SkyTrain stations, but apart from that, only very few bus stations have a map. Actually, I was able to convince an employee to hand me over a map, but usually, people just don't get a map. And in the inner parts of the city, the map is highly inaccurate.
What bugs me about that is: The system is really great. The information is not. The effort to make the system really good useable would be quite low. But it is not done. And as someone coming from another place on the world, you don't have a real chance in getting to any information you need.
- berkley lpr: Ok, that was a nice time. But this one is just too inflexible for the current time. Any option requires a new printer. Lpr, it was nice that we meet, but your time is gone.
- lprNG: not too alive anymore
- cups: This promises to be what in German is called "eierlegende
Wollmilchsau". However, it fails ugly. It needs to be able to connect to
localhost. Running in a vserver seems
not to work, as it should connect to the ip-address of your localhost, and not
127.0.0.1. The good question is of course: Why does it need ip-networking at
all, and can't just use some socket for conversation? (Via that, it's even
secure to reuse user ids for authentication - never trust a ident server for
root or so.) Also, the way of configuring network printing is just scarry - or
should I call it overengineered? I don't doubt that it's possible to do
whatever setup I like, but it's the effort for even easy things is not too
different from something difficult. And the general bloat is not much better.
I am interessted in setting up a printer, not in getting a second webserver on
my machine.
I expected cups to be able to integrate my fax in it. However, as far as I understood, options can only select between predefined values, so that the only choice is to send the fax number as job title. That is ugly.
Such success stories for sarge and debian-installer tells us that Debian is on the right track. We are now in the area where Debian is install- and useable for everybody. Thanks to all contributing to that.
If you want to use the volatile archive, you can add the following lines to your /etc/apt/sources.list:
deb http://volatile-ftp.debian.net/debian-volatile woody-volatile main deb-src http://volatile-ftp.debian.net/debian-volatile woody-volatile main
Packages uploaded to woody-volatile are handled by a dak-based archive, and autobuilded. Kenshi Muto provides an arm-buildd, Bdale Garbee offered me a machine for the ia64 buildd, and maximum help is provided by Martin Zobel-Helas, who helps me with almost every aspect (including offering mirror space, and a machine running the wanna-build). (If you look closely, you'll see that the volatile buildds are the same as the experimental ones.)
Ok, let's see which packages qualifies next to be included in woody-volatile.
I decided this weekend that mini-dinstall (and all the other little tools) are too complicated to be configured the way I like, and so decided to install dak (aka katie) at volatile.debian.net. The installation itself was quite painless (but well, the second installation can't be so hard anymore). I also added some mappings so that even uploads to stable or woody are mapped to woody-volatile (as they should). And of course, proper NEW handling is there, as well as some staging area for the review before inclusion.
So, now everything is ready. If you have a package you think that should go in, feel free to contact me. And, autobuilding will also be added soon (probably at the same time as I add autobuilding for Ganneffs archive).
And, frankly speaking, I really like the way dak handles packages. dak is a great tool.
The main thing about this change is that any upload for *-security will go to the archive, even if the versions in e.g. stable and testing are the same. This sounds really easy. Even the detailed way (in case of an upload to proposed-updates: version larger than testing? If so, reject unless it's a security upload, and reject unless current stable version equals current testing version) doesn't sound too hard. But looking at details makes the mind spin: The information whether we upload to proposed-updates or to stable-security is lost really soon. Much worse is that the "current testing version" may have different meanings. Does it mean the version in testing, or in testing-proposed-updates, if there are both? And - how to write getting wise of this in a transparent, configurable way?
So, it took me some time, and multiple versions of the code to do it in a way where at least I can't see a flaw currently.
The first change is that there is a version-map, and during distribution-mapping, any matching version-mapping is recorded as "possible map" if there are version problems later on.
The second change is at the cross suite checks: If we detect a problem, than we check if there is a version-mapping for this upload. If not, we take the old exit. So, the new code is only entered for *-security-uploads. In the new code, there is a "generous" version detection code. If asking for a version in testing-propsed-updates, you'll get the newest version in any of testing and testing-proposed-updates. For this, there is a new "enhances" configuration item. proposed-updates enhances stable, and testing-proposed-updates enhances testing.
Now, there are all pieces together. If a package enters the new code (means: it's a security upload, and we failed some inter-suite dependencies), it is checked (in that order) whether the inter-suite dependencies fails even with the generous code (e.g. if it fails for testing, we check if it also fails for testing-proposed-updates). If it works there, we issue a warning and continue. If it fails, and the generous version is the same for the suite where the package is uploaded to and for the one it failed (e.g., if stable and testing have the same version), than the package is also targeted at the mapped extra suite (means: it may additionally go to testing-proposed-updates and even unstable for stable-security, and unstable for testing-security).
Wow. That was it. I hope that the remaining flaws are not too bad, so that this code could really be applied to katie, and we can continue with bringing amber in shape for testing-security support, which in turn is the major release blocker. For those of you who want to take a look, the patch is currently available at http://people.debian.org/~aba/dak.patch.
I planned to also play with tiffani, a proposed member to the harem. Her task would be to care about diffs, to shorten download-time for apt-get update. A test version already exists (most code by Anthony, only some glue code by me), but some small issues still need to be looked into. However, katie and jennifer took enough of my time, so I postponed it till later this week.
- First, how dare we say that "our users and the free software community are our priorities" if we do our users the great dis-service that they don't have a stable basis for their use? And, running unstable is not a good idea unless you have much insight into debian, including reading many mailing lists. For most people running servers, this is not acceptable. And please remember, our social contract speaks about users, not only about computer hackers.
- Second, we also need to release for our own sake. Preparing for a release gives us a good hint which packages need more attention, or should even be dropped at all from the distribution. A release is a tough quality control, and we need it from time to time. Also, excluding a package from testing is an easier step than dropping it directly from the archive, but it servers well as warning shot. (Not all removals from testing are meant as that, however.)