During current QA meeting, Amaya did a nice picture of us all.
Changes in wanna-build
During recent weeks, not only sbuild and buildd were changed, but also
wanna-build. Many changes were small and don't have direct impact, but will
ease our life in future. This includes a bunch of code cleanups. Most
changes were done by Kurt Roeckx and me, but as usual Marc Brockschmidt
and Philipp Kern were also involved.
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=building
which 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 ...
How to (not) protect privacy
Protecting our privacy is important. For example, I wouldn't like if my
mailing list subscriptions get known to anybody else (except the relevant
listmasters of course as part of their job), for the simple reason that
this is just my own decisions which lists I get mail from (and read, but
that's not necessarily the same). This is an classical example
of "personal information are handed out on a need-to-know-basis" (like
to listmasters if necessary), and is also in line with european laws (I
don't know the legal situation in other parts of the world enough).
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.
Transit network during olympic games Vancouver?
As Munich is currently trying to get the olympic games in 2018, I looked at what Vancouver did.
I could see that there is a
new streetcar operating, however the tracks aren't brand new but used to be there while I was in Vancouver
(just with not so new platforms and rails).
To Whistler there are Busses operating. Inside the city there seem to be Olympic Lanes (which of course makes
public transport faster). I'm wondering if there are new built lines at all for the games?
Backup non-NIH?
I'm currently looking for some backup tool, but each tool lacks some features.
I'd like to
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).
cups and samba
Currently samba cannot transition to testing, as cups
doesn't build on
mips* anymore. We first thought that the issue is that cups is using
PIE as build option, but even
after changing cups to not do that, and making binutils to give a specific
error message for using PIE instead of building corrupted binaries (thanks,
Matthias for the fast change), it still continues to FTBFS. No answer from
the porters yet though. And no idea what to do, at least none that I know of.
Feed of RC bug changes
In response to Andrews request for a feed of RC buggy packages
there is currently a 3 times per day changelist on http://bts.turmzimmer.net/.
Converting that list to an RSS feed shouldn't be an issue if it's helpful to people. (And if you want it, just sent me an example
how the two current top entries should look like as rss feed.)
more on the mysql-transition
One of the great things within Debian is how fast things happen if they are
important. The php5-FTBFS-bug
was fixed already yesterday. I'm now looking into more details of that
transition, as my usual strategy is first to look at packages not updated
at all architectures. Yesterday I took a deeper look into amd64-specific
packages not updated to the new library yet. A few packages are just not
uploaded yet (that's normal).
Three packages had RC bugs without patch for "doesn't build anymore" since
ages
(asterisk-addons as #534037
since June 21st,
mysql-gui-tools as #527652
since May 8th and
ulogd as #527534 since May
7th). The first two packages are as of this writing already pending
removal, the third might follow any minute.
This is one of the bad things of unhandled RC bugs: They make us way more
work, and they are really pending for removal from testing. Another few
packages got fresh RC bugs for not building. Also e.g. pike7.6
does need an upload, but with
obvious patch.
So the conclusion is: However (un)important an RC bug looks to you, it is
necessary that it is fixed as soon as possible. Please fix it.
Fix it now. There is no use in waiting, things will only get worse. And if
there are reasons for not uploading now, please document them, and make
sure there is at least a patch in your bug report.
Bugs in need of love
Currently a few larger transitions hang for different reasons: octave
together with hdf5 is blocked by bug
#542333 that the current
swig1.3-version makes gdal FTBFS, for this reason we cannot get the
necessary binNMUs for testing transition. The migration of the current
mysql5.1 is blocked by 5 RC bugs, where two are trivial (just replacement
of build dependencies), two are easily removable, but php5 now started to
FTBFS with the autoconf in testing and unstable, but still builds with the
version in stable (#542906).
And thanks to libgdal-ruby1.8 these two transitions want to glue together
to one. Fixing any of these two bugs would be very welcome.
improving kfreebsd* installability
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.)
"IPv6 as release goal"
A few days ago, some people wondered why ipv6 is still on the list of our
release goals. The answer is easy: It still doesn't fully work.
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.
forcing eglibc and gcc, breaking *glx*ia32 and lib32ffi on amd64
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-dev
This 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.
About being a press officer
Some of you know that besides Debian I'm also volunteering in the germans
national association of public transport users. A few know that I'm a press
officer for more than 15 years on the local level, and more than 10 years
on the national level. As that, I've had my fair deal (or even more) of
issues and experiences (and also seen how other organisations deal with
that). Some recent discussions have convinced me to write up my experiences,
and try to clarify some common misunderstandings - press communications is
very different from normal open source stuff.
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.
Finishing off transitions
On Sunday, Phil (mostly) and I (a bit) were finishing off some transitions:
ocaml and suitesparse went to testing (over 1000 packages involved), as well as
imagemagick (which included an upload of meta-gnome2 to
testing-proposed-updates to change the gnome-package). Both can be qualified as
quite major transitions, and I didn't expect that we could finish two at almost
the same time.
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, ...
Why I'm not commenting on the release plans ... and why the publicity members can only welcome them
I have been approached by some people why I don't comment on the decision
to commit to time-based releases.
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.
Lenny: done
It is strange to watch for the first time a debian release to happen,
without being part of a though time schedule, and with the possibilities to
sleep uninterrupted etc. And it is a good feeling to see how well it went.
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!
That time again
It seems it is that time again.
People seem to believe that Debian is actually able to ship a new stable very soon, and
so they do actions that delay it.
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!
bts.turmzimmer.net with delayed queue again
Thanks to Thomas Viehmann for the patch on both ftp-master side (aka
http://ftp-master.debian.org/deferred/
and on "client side" (and for nagging me enough to activate it),
http://bts.turmzimmer.net/details.php
shows now again when bugs are fixed in delayed. Thanks!
stale vs incomplete: xen vs kvm
Currently, I'm together with Marc Brockschmidt evaluating which
virtualization to use on our new server. We want that our virtual systems
feel like real systems, and we want an open source solution. So, vserver
and the like is out of the game, as well as VMware.
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?
ldap and webauth / kerberos
I'm currently looking for some software that user can login on the webserver,
but for the scripts, it doesn't look too different from basic auth.
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.
Why can't apache just bind against an ldap-dn?
The current apache ldap documentation explains that apache first looks up in the directory before performing an bind.
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?
Binding with ldap to attributes
I wanted to be able to not only bind with the normal dn, but also to attributes.
This means I e.g. have an attribute mail, and want the people to be able to login with their
mailaddress as username.
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.
apache, ldap and using different attributes as user names
I'm currently considering how to allow users to log on with different attributes as user names,
e.g. with their "real" user name or their mail adress. Unfortunatly as described on
http://httpd.apache.org/docs/2.2/mod/mod_authnz_ldap.html#authldapurl,
though RFC 2255 allows a comma-separated list, only the first attribute 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).
semantics in ldap - anyone out there?
Ldap seems like a good database to store accounts in:
Lots of tools can use it, it's easily integrated into pam, and lots more.
But one sometimes just hits borders in the data model of openldap:
There are no semantics available.
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.
Any good web user selfmanagemenet out there?
I'm looking for some time for a good user self management.
"Good" means: User can add their own accounts, gets approved (or not),
can recover the password, ...
Of course, there are plenty implementations of that available in the market -
most wikis have that, as well as lots of other applications.
But all of them are embedded-only, i.e. one has to use that web application
and gets "vendor-locked". Isn't there anything open source and standalone
available, following the basic unix principles of "do one thing and do it well"?
Top testing migration blockers
During the recent weeks, we started to hunt and hint large
batches of packages together to testing (and this blog is just
to show a bit of what is part of the tasks of release team members).
This started with a large jasper hint, continued with a very large
poppler / texlive / jack / abiword-hint (which moved about 75% of the
packages that were ready for testing migration in at the same time),
then moved a more recent linux-2.6 version in, and now finally ghc6 /
haskell.
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:
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.
test svn-buildpackage
A new version of svn-buildpackage has appeared in unstable now. If you use this
package, please test it, and if something bad happens, please file appropriate
bugs and alert the release team. Thanks.
Neglected RC bugs
I dived through the list of open RC issues, and found some
without any (real) activity for at least 20 days. Please remember: If we want to release Etch, we need to get rid of any such
bug prior to release.
Who is lying?
One library is lying on ia64 - it tells libtool to have a link to /usr/lib/libasound.la, but there is no dependency to that on the package.
Please compare
http://buildd.debian.org/fetch.cgi?&pkg=gcompris&ver=8.2.2-1&arch=ia64&stamp=1166917613&file=log with
http://buildd.debian.org/fetch.cgi?&pkg=gcompris&ver=8.2.2-1&arch=s390&stamp=1166227920&file=log.
Now, one needs to locate the lying package and fix it.
How to read text in somebody's text which is not there, and not meant to be there - or: dunc-tank didn't slow down Etch
That sometimes journalists have obvious reading problems,
well, isn't a too new thing. One has to deal with that, e.g. by appending more text to the cited blog entry.
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.
attr and libpng
Monday morning started with seeing lots of brand new release bugs about attr being broken so bad
that "ls -la" failed, and also buildds were affected negatively.
As a consequence, I few-hour-NMUed this package back to a sane (i.e. working) state.
As any library maintainer, please remember:
Whenever you drop a symbol - whichever this symbol is this means:
You need to bump SONAME. Or just use library versioning from the beginning.
Failing to do so can lead break any program linking to your code, which is especially bad if it is ls and cp.
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.
midterm report
This is the first of the two "larger" reports during the release management funding experiment.
I suppose I don't need to be more specific about what I did in detail - my blog postings in http://blogs.turmzimmer.net/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 ...)
Release update and more
(This blog entry is a bit delayed because I have been on the QA meeting.)
On Monday and Tuesday last week we did one important step:
We sent out the release update that etch is fully frozen now.
Preparing that, and then handling the incoming freeze requests took some of the time.
Of course, some of the regular RC bug squashing happened as well - but that is rather a routine task now.
QA Meeting-picture
During current QA meeting, Amaya did a nice picture of us all.
Reading is difficult - or why the current number of RC bugs is ok for the freeze
People who have following our release update mails have seen that we are tracking different numbers this time.
There is the total number of RC bugs relevant for etch, which is currently 122.
And there is the number of RC bugs relevant for both etch and sid (i.e. "not handled yet"-bugs), which is currently
78 - and that number was basically the only number we could track for release of sarge.
(Then there are also the numbers of bugs only in etch, and the number of aged bugs relevant for etch and sid - please
see http://bts.turmzimmer.net/graph-small.png for the full stats.)
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.
Preparing freeze
Blogging about recent Friday is a bit late now, but there you are:
On Friday, I was busy preparing the full freeze for Etch - this included
e.g. polishing the announcement mail as well as letting linux 2.6.18 finally
into Etch (and breaking some packages we cannot remove now), and of course
more RC bug squashing.
Thankfully, most of that worked out well, so we were able to freeze Etch today.
More bugs need to go away
On Monday, I sent out the next release update (which was under preparation for a few days).
Basically, Debian is doing quite well - we just have a few items left open before we can have the full
freeze.
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, ...
Bug needs help
There is a long-standing RC bug
libglide2: Reproducible segmentation fault with Voodoo2
where it is easy to reproduce this bug if you have the hardware (warning: it will crash your computer),
but - well, it just needs to be done.
What maintaining means
During my cruise through release critical bugs, one sometimes wonder
how often "team" should be translated with "toll, ein anderer macht's" (great, someone else will do it).
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.
