[00:44] <etank> bug 2311
[00:44] <ubotu> Launchpad bug 2311 in gst-ffmpeg "divx videos not working" [Medium,Invalid] https://launchpad.net/bugs/2311
[00:47] <pygi> hello
[00:57] <rledge21> I'm wanting to learn how to write a desktop applet, anyone point me to a tutorial or anything to get me started?
[01:36] <lamont> anyone around with the right access to tell me if queue-builder is running, and if so ETA to finished?
[03:57]  * lamont wonders if anyone knows how to take apart and iPod nano...
[03:57] <StevenK> I can make it be in pieces ...
[03:57] <StevenK> Probably not what you're after. :-P
[03:57] <lamont> no, she kinda wants it back together at the end.
[03:57] <lamont> or at least running on power.
[03:58]  * ScottK is REALLY good at taking stuff apart. ;-)
[03:58] <StevenK> lamont: I didn't think you could?
[04:14] <lamont> StevenK: done. :-0)
[04:15] <StevenK> Heh
[04:15] <StevenK> lamont: So you should document the process and then get Apple lawyers to hate you
[04:16] <lamont> google is love
[04:17] <StevenK> Ah
[05:49] <dholbach> good morning
[05:50] <ion_> Hi
[05:51] <dholbach> hey ion_
[06:08] <TheMuso> 5~5~/c
[06:08] <TheMuso> argh
[06:10] <cjwatson> TheMuso: there isn't really a great choice for where to file the bug, but ubuntu-meta (assuming it's the Ubuntu seeds) will probably do
[06:10] <cjwatson> TheMuso: BTW, you have a stray identity; you might want to visit https://launchpad.net/people/+requestmerge?field.dupeaccount=luke-themuso
[06:11] <TheMuso> hmm ok thanks
[06:11] <TheMuso> cjwatson: And, crimsun took care of the seed change.
[06:11] <cjwatson> ok
[06:24] <StevenK> elkbuntu: Back home?
[06:24] <elkbuntu> StevenK, yep, got back on sunday night
[06:24] <StevenK> elkbuntu: Sorry I missed you. :-(
[06:24] <elkbuntu> yeah :(
[06:25] <posingaspopular> hey elkbuntu
[06:25] <elkbuntu> hobbsee's car went pop, so i didnt even get to catch up with her :(
[08:05] <pitti> Good morning
[08:06] <StevenK> Morning pitt
[08:06] <StevenK> Err
[08:06] <StevenK> pitti :-)
[08:07]  * Fujitsu drops StevenK into a pit.
[08:09] <sivang> hi all
[08:09] <pitti> hey StevenK
[08:09] <pitti> sivang! Long time no see
[08:09] <sivang> yeah :)
[08:09] <sivang> how are you my dear friend?
[08:10] <pitti> pretty well, and you?
[08:10] <pitti> married, happy, and busy :)
[08:11] <StevenK> Fujitsu: In terms of WoW, I'm in one ... crawling with level 48-50 insects. *shiver*
[08:11] <sivang> pitti: I'm trying to find toolchain-source (actually to install it) but it has no installation candidate, I also checked and it appears it does not appear in the lenny/sid repositories, do you have any idea ?
[08:12] <pitti> sivang: what should that be? it was removed in feisty
[08:21] <sivang> pitti: ah I see
[08:21] <sivang> pitti: this is a package that holds sources for binutils and gcc needed for cross compilation of stuff
[08:21] <pitti> sivang: I'm not sure, but maybe the normal gcc-4.2 source package supports this now?
[08:22] <sivang> where can I find the log for toolchain-source's deprecation or removal ?
[08:24] <sivang> is there a channel for ubuntu embedded now? I mgiht ask there
[08:24] <sivang> and possibly contribute back my findings on the AU1550 amd based box ;)
[08:24] <sivang> (debian runs beautifully on it)
[08:25] <pitti> http://people.ubuntu.com/~ubuntu-archive/removals.txt
[08:26] <sivang> never mind , need to run
[08:26] <sivang> laters all, wonderful day to you all
[08:30] <geser> morning
[08:37] <mdke> does anyone know if newz is on holiday or otherwise off work at the moment?
[08:38] <soren> Well, he's in the US, so he's probably asleep, but apart from that, I think he should be around.
[08:39] <mdke> soren: yes, I meant in general, thanks
[08:39] <tjaalton> what's happening with gtk+/glib-1.2 in hardy? fvwm is uninstallable because it refuses to install libglib1.2
[08:41] <persia> tjaalton: Library transition: http://people.ubuntu.com/~ubuntu-archive/NBS/libglib1.2 still need a rebuild.
[08:41] <tjaalton> persia: yeah, I dug a bit more
[08:41] <soren> mdke: np :)
[08:43] <seb128> persia: how come that we have a libglib1.2 transition now and why debian doesn't?
[08:44] <\sh> keescook, jdstrand thx for taking care about the cve uploads....
[08:50] <geser> seb128: Debian has also libglib1.2ldbl (we have the same revision) and when at least gtk-engines got a binary NMU for it
[08:52] <persia> seb128: As geser said, Debian does have the transition (with 1.2.10-18).
[09:02] <pitti> geser, persia: I hope you are using a script for the rebuilds?
[09:02] <pitti> (such as http://people.ubuntu.com/~pitti/scripts/update-maintainer-transition)
[09:02]  * persia has only done a few, and didn't script it
[09:03] <persia> pitti: Should we be batch-scripting and pushing them, or looking at them independently?
[09:03]  * StevenK has a script for mass-rebuilds, but it's fairly fragile, and doesn't cope with Maintainer changes needing to be done.
[09:04] <persia> StevenK: Isn't that only the case for the remaining few hundred cases where we have Ubuntu variation and no Ubuntu maintainer?
[09:04] <StevenK> persia: I've hit at least one during the last few mass rebuilds I've done, so I think I should update the script.
[09:05] <persia> StevenK: Makes sense.  I keep meaning to quash some of them, and might take advantage of pitti's script to hit a few when I next have a few hours open.
[09:05]  * TheMuso has done a few rebuilds for libglib, and most were to satisfy depends issues for ubuntustudio.
[09:08] <geser> pitti: The rebuilds I did were all manual, I will look into your script. Thanks.
[09:08]  * TheMuso is also looing into the script.
[09:08] <TheMuso> looking
[09:17] <mvo> Amaranth: I think we are good to upload the git HEAD compiz to hardy, the only outstanding issue I have is that in plugins-main 02_fix_edge is crashing and needs to be ported or disabled. do you see anything else that is left to be done?
[09:18] <tjaalton> umm, using "-vversion" for debuild makes it segfault on gutsy
[09:18] <Amaranth> mvo: I thought that was upstreamed already
[09:19] <tjaalton> nevermind
[09:19] <tjaalton> forgot the epoch..
[09:20] <mvo> Amaranth: last I heard they consider it too much of a hack to include it into the regular tree
[09:21] <Amaranth> oh, we'll figure that out later i guess
[09:21] <Amaranth> heh, your changes to compiz where stuff i had locally and forgot to push
[09:22] <Keybuk> which ungodly hack is that?
[09:22] <Amaranth> disable wall edges unless you're dragging a window
[09:22] <Amaranth> so they don't stop you from clicking on things in corners/edges
[09:24] <Amaranth> mvo: everything else looks good
[09:24] <mvo> Amaranth: cool, I think I upload later today and use it a bit until then to see if there is other obvious breakage
[09:24] <Amaranth> well, there is one bad breakage i get with it
[09:25] <Amaranth> xmoto pops out of fullscreen as soon as it gets the cursor
[09:25] <Amaranth> but that's small
[09:26] <mvo> heh :) I should try this
[09:38] <geser> mvo: command-not-found is missing a build-dependency on python-gdbm. Do you want a debdiff for it?
[09:40] <mvo> geser: if you have it at hand, yes. I noticed the b-d failure mail a couple of minutes ago
[09:43] <geser> mvo: http://members.ping.de/~mb/c-n-f.debdiff
[09:45] <mvo> geser: thanks!
[09:48] <mvo> geser: I used to be a member of ping.de too in my good old times
[09:52] <geser> pitti: please give-back extace
[09:53] <geser> pitti: another two package FTBFS because of the dh_strip bug: dvi2tty and flexml
[09:57] <geser> pitti: please give-back g15daemon-audacious
[10:03] <geser> pitti: please give-back gnome-iconedit
[10:04] <tkamppeter> pitt, hi
[10:04] <tkamppeter> pitti, hi
[10:18] <pitti> geser: kicked; dh_strip> can you please mention the packages in the pkg-create-dbgsym bug? I'll give them back once it's fixed
[10:18] <pitti> hi tkamppeter
[10:19] <pitti> hey seb128
[10:19] <seb128> hello pitti
[10:25] <tkamppeter> pitti, I have re-uploaded the debdiff on for bug 153152, I accidentally deleted it when preparing the SRU in bug 149511.
[10:25] <ubotu> Launchpad bug 153152 in hplip "[Gutsy SRU request] Fax utility not adding files to job." [Undecided,Fix committed] https://launchpad.net/bugs/153152
[10:25] <ubotu> Launchpad bug 149511 in ubuntu-meta "[Gutsy SRU request] hplip is needed by HPIJS" [Medium,Fix released] https://launchpad.net/bugs/149511
[10:25] <pitti> tkamppeter: no problem, that SRU is already in -proposed
[10:25] <pitti> so no new upload necesasry
[10:26] <pitti> tkamppeter: I buess bdmurray only updated hplip for testing, not hpijs?
[10:26] <geser> pitti: I've already added a comment for both packages in the bug
[10:26] <pitti> geser: ah, thanks
[10:27] <sladen> who the heck let through that message to ubuntu-devel-announce@lists.ubuntu.com
[10:27] <Fujitsu> sladen: We were wondering that yesterday.
[10:27] <geser> pitti: should I mentioned further packages affected in the bug (if I find others)?
[10:28] <pitti> geser: yes, please
[10:28] <pitti> geser: oh, how evil
[10:28] <pitti> geser: dvi2tty has debian/compat '4', but uses debian/tmp
[10:29] <pitti> argh, and uses DH_COMPAT=1 in debian/rules
[10:29] <pitti> this is so evil
[10:31] <soren> pitti: compat 4 and debian/tmp is not kosher? Why?
[10:31] <pitti> ah, so DH_COMPAT should trump debian/compat
[10:31] <pitti> soren: debian/tmp is compat level 1 only
[10:31] <soren> Eh?
[10:32] <Chipzz> pitti: hrrrm, as far as I understand debian/tmp is used as a temporary directory for moving files to different subdirs of debian/ (and hence different packages)?
[10:32] <soren> pitti: Ok, we're clearly talking about different things :)
[10:32] <Chipzz> or am I horribly mistaken?
[10:32] <pitti> Chipzz, soren: man debhelper  /V1
[10:32] <tkamppeter> pitti, I have done addtional tests on bug 153152. The fix works perfectly on Hardy, but on an old laptop which I updated to Gutsy, Python errors appear, so it seems that there is a second fax bug which occurs only in Gutsy.
[10:32] <ubotu> Launchpad bug 153152 in hplip "[Gutsy SRU request] Fax utility not adding files to job." [Undecided,Fix committed] https://launchpad.net/bugs/153152
[10:33] <pitti> soren, Chipzz: in mode 1, debian/tmp *is* the package directory of the first package in debian/control
[10:33] <soren> pitti: Right, ok. You left that bit out :)
[10:33] <pitti> not just a temporary place where to move files to debian/<packagename>/
[10:33] <pitti> soren: well, geser knew :)
[10:33] <pitti> tkamppeter: ah, too bad; please test SRUs on gutsy, too
[10:34] <pitti> tkamppeter: if you want to prepare another update, feel free to sneak in the dependency fix you mentioned
[10:34] <Chipzz> pitti: ah ok; I see that in the man-page
[10:34] <pitti> geser: ok, I got it fixed for dvi2tty, testing the other ones now
[10:35] <Chipzz> pitti: but debian/tmp can still be used as an intermediary place to install files to, which will later be moved to the correct dirs, right?
[10:35] <tkamppeter> pitti, if you want to see what happens, do the TEST CASE steps on a Gutsy.
[10:35] <pitti> Chipzz: right, that's common and good practice
[10:35] <Chipzz> (ie as in 'make install DESTDIR=debian/tmp')
[10:35] <Chipzz> and use dh_install to move the files in debian/tmp to the correct dirs
[10:38] <Chipzz> pitti: under V3 I read: dh_makeshlibs makes the postinst and postrm scripts call ldconfig. But since we now use dpkg triggers, shouldn't that be clarified which DH_COMPAT level should be used to rely on that?
[10:39] <pitti> Chipzz: that's orthogonal to triggers; those are implemented at the dpkg level and within ldconfig itself
[10:39] <pitti> Chipzz: read /sbin/ldconfig to see the magic
[10:54] <tkamppeter> pitti, the problem of bug 153152 is non-trivial, I will ask the HP guys to fix it.
[10:54] <ubotu> Launchpad bug 153152 in hplip "[Gutsy SRU request] Fax utility not adding files to job." [Undecided,Fix committed] https://launchpad.net/bugs/153152
[11:21] <adrian15> Hello. I am trying to boot an ubuntu cd with grub. Is there any boot option that am I missing? Is there any boot option that it is not written in isolinux.cfg? It is very strange that there is not any root= option.
[11:27] <adrian15> does not anyone try to build ubuntu cdroms in their own ?
[11:36] <sladen> adrian15: the initramfs contains 'casper' which goes to hunt for the rest of the LiveCD system to boot
[11:38] <mvo> ogra: can we have a quick chat about the edubuntu-two-cd changes? I'm currently pondering how this is going to be implemented in the release-upgrader
[11:38] <ogra> mvo, indeed
[11:38] <ogra> here or pm ?
[11:38] <adrian15> sladen: my problem is that I use grub for trying to load it with: kernel /casper/vmlinuz file=/cdrom/preseed/ubuntu.seed boot=casper quiet > splash -- ENTER initrd  /casper/initrd.gz ENTER boot                                      and I finish with an initramfs shell
[11:38] <mvo> ogra: pm sounds appropriate, I don't think its that interessting :)
[11:40] <adrian15> sladen: you have an screenshot here: http://adrian15.raulete.net/ficheros/u710_chainloaded_isolinux.png
[11:40]  * Hobbsee waves
[11:49] <pitti> hey Hobbsee
[11:49] <mvo> Riddell: could you please have a look at https://wiki.ubuntu.com/LTSUpgrades? there is a question about kde in the "Outstanding issues" section. it would be nice if you could add a comment there
[11:49] <pygi> hello everyone
[11:50] <Hobbsee> heya pitti!
[11:54] <pitti> tkamppeter: ah, seems that Mark Purcell does quite some maintenance on hplip now (we regularly autosync from Debian); does the cooperation in svn work?
[11:56] <Riddell> mvo: jcastro was looking into that
[11:57] <mvo> Riddell: nice. if he could just add something to the wiki, that would be cool
[12:06] <sladen> adrian15: you could look at some of the commandline parameteres in the directory: http://www.paul.sladen.org/ubuntu/qemu-livecd/
[12:10] <adrian15> sladen: root=/dev/ram taht's what I suspected
[12:11] <adrian15> sladen: but what I don't understand is why isolinux is not able to boot it. (my modified version of isolinux)
[12:11] <adrian15> sladen: And I will bet these are the mkisofs options
[12:11] <adrian15> sladen: I will try these ones: https://help.ubuntu.com/community/LiveCDCustomization#head-ab8f641f4bbc6cbafbe1699b580c06668bf7a484
[12:15] <attunix> I customized my Ubuntu Server distro installation to have a python script run on startup from /etc/rc.local . How do I make this installed distribution into a Live or Install CD?
[12:16] <sladen> adrian15: is http://uck.sourceforge.net/  (Ubuntu Customisation Kit) any use
[12:16] <sladen> adrian15: sorry I can't easily tell more from this distance
[12:17] <attunix> ok. thank you
[12:18] <cjwatson> attunix: https://help.ubuntu.com/community/InstallCDCustomization and https://help.ubuntu.com/community/LiveCDCustomization should help you
[12:18] <attunix> thank you :)
[12:33] <soren> mvo: You think bug 141601 could be apt's fault?
[12:34] <ubotu> Launchpad bug 141601 in tasksel "tasksel packages stays at 100%" [Undecided,New] https://launchpad.net/bugs/141601
[12:34] <mvo> pitti: would you be ok with http://paste.ubuntu.com/2454/ until we have a better fix? this way I can continue testing the upgrade
[12:35] <mvo> soren: it can certainly be a apt problem
[12:35] <pitti> mvo: works for me (please check it into bzr)
[12:36] <mvo> soren: I look at it after lunch
[12:37] <soren> mvo: Cool. Thanks!
[12:45] <cjwatson> soren: could also be debconf-apt-progress
[12:45] <cjwatson> soren: which is sort of suggested by the zombie apt
[12:46] <cjwatson> I rather hoped we'd nailed all of those though
[12:47] <cjwatson> soren: strace -f -s 1024 and then stare at the output a lot tends to be the only real way to attack this
[12:48] <mvo> cjwatson: it looks like a issue in apts internal dpkg-log code, there is a fix in gutsy-proposed for this, I ask if he can install this version and see if that fixes the issue
[12:48] <cjwatson> mvo: you think? OK ... how would a bug in apt lead to a zombie apt-get lying around though?
[12:48] <cjwatson> or is it that it's writing garbage down the status fd and confusing d-a-p that way?
[12:49] <cjwatson> I vaguely remember discussing something like that with you, now that you mention it
[12:49] <soren> cjwatson: Yes, I've noticed that too.
[12:49] <cjwatson> debconf-apt-progress is extraordinarily delicate :-/
[12:49] <mvo> soren: a strace would definitely be good to have
[12:50] <soren> I think it's debconf-apt-progress. I have a fix I want to test out.
[12:50] <cjwatson> soren: I wrote that code and would be interested in reviewing a patch
[12:50] <mvo> ok, I may be wrong, is this reproducable?
[12:50] <soren> mvo: Yes, apparantly so.
[12:50] <soren> mvo: Just tasksel install dns-server or something.
[12:51] <mvo> soren:  ok, thanks. after lunch then :)
[12:51] <soren> cjwatson: Gimme a few minutes.
[12:52] <cjwatson> yes, I see the same bug here
[12:53] <cjwatson> soren: off for lunch soonish anyway
[12:53] <mvo> pitti: http://paste.ubuntu.com/2455/ <- bzr does not like me today
[12:53] <mvo> cjwatson: I would be interessted if the apt in gutsy-proposed fixes it or not
[12:54] <soren> cjwatson: It gets stuck in the select call.
[12:54] <soren> cjwatson: Or so says strace.
[12:54] <cjwatson> perhaps it's selecting on no fds
[12:54] <cjwatson> I'll look after lunch if you don't beat me to it :)
[12:56] <pitti> mvo: hm, regression in 1.0?
[12:58] <crimsun> StevenK: thanks for the -meta refresh & upload
[13:01] <soren> Hehe..
[13:01] <soren> I think I got it.
[13:02] <pitti> mvo: u-m processed in gutsy-proposed FYI
[13:03] <pitti> StevenK, Mithrandir: hm, the mobile packages are still native (no orig.tar.gz) and have funny version numbers like 3.0-sardine1ubuntu2; will that be fixed at some point?
[13:05] <soren> cjwatson: http://people.ubuntu.com/~soren/debconf-apt-progress.diff   fixes it, but not being familiar with the code, I'm not convinced it's actually a correct fix.
[13:05]  * emgent heya
[13:14] <StevenK> pitti: Yes, there will be an on-going effort to clean up the packaging, since some of it is really shocking
[13:15] <StevenK> pitti: And I'm well aware what native means. :-)
[13:21] <somerville32> Dear Ubuntu, today I won't be in to work today because I have 30cm of snow outside to enjoy. kthxbi :P
[13:22] <Amaranth> somerville32: Yay, you can get a head start on hug day :)
[13:22] <somerville32> \o/
[13:22] <somerville32> I was thinking about going outside for once but I guess I'll do hug day instead :P
[13:23] <Amaranth> I should probably do my hug day stuff today as well, I suspect I'll be rather intoxicated tomorrow (it's my 21st birthday)
[13:23]  * somerville32 cheers
[13:24] <somerville32> Amaranth, I'll have a drink for you tomorrow than
[13:24] <jdong> Dear Unnamed Ubuntu Developers With The Day Off:
[13:24] <jdong> SCREW YOU.
[13:24] <jdong> JUST SCREW YOU.
[13:24]  * Amaranth passes the bottle to jdong
[13:24] <persia> jdong: Everyone is entitled to their separate holidays.
[13:24] <Amaranth> Oh, that's illegal
[13:24]  * Amaranth takes it back
[13:25] <jdong> persia: yeah only if they're separate, but equal duration holidays ;-)
[13:25] <somerville32> lol
[13:25]  * somerville32 is in a jolly mood today and decides to eat another poptart (strawberry)
[13:25] <persia> jdong: I disagree (but I moved to the country with the most public holidays, so perhaps I'm biased)
[13:25] <somerville32> lol
[13:25] <jdong> persia: hahaha
[13:26] <somerville32> I wonder if I could convince work that OSS is a religion :P
[13:27] <somerville32> "Umm yea, sorry, can't work today - hug day :P"
[13:27] <jdong> somerville32: just point them to some of Theo De Raadt's quotes. OSS is more than a religion.
[13:27] <jdong> :D
[13:27] <somerville32> :D
[13:27] <somerville32> "Blessed isth the man who is open sourced."
[13:28] <Amaranth> Ugh I need to stop staying up all night
[13:28] <somerville32> Amaranth, Yea, today is the first day my sleep schedule normalized
[13:29] <Amaranth> It's just that I have a LUG meeting tonight that I'm going to sleep through at this rate
[13:37] <tkamppeter> pitti, Mark Purcell has started this recently by syncing back my newest Ubuntu HPLIP package to Debian. My package is much simpler and much more maintainable as the Debian packages from HMH. So Marc abandoned the CVS from HMH and started a new SVN with my package. Then he asked me whether we should collaborate and he gave me write access to the SVN.
[13:37] <jdstrand> Keybuk: I am just diving into upstart and read http://upstart.ubuntu.com/getting-started.html.  I'd like some clarification on the statement 'Jobs will be run alongside the init scripts for that runlevel'
[13:37] <pitti> tkamppeter: right, I read that much on the ML; I was just curious about how well it works
[13:37] <jdstrand> Keybuk: eg start on runlevel 2
[13:38] <jdstrand> Keybuk: will the job start before sysvinit scripts for 2, after or anytime during when those scripts are started
[13:38] <jdstrand> ?
[13:38] <tkamppeter> pitti, currently, where HP did not release for some time, there is no movement, but I think on the next release the two distros will quickly update.
[13:38] <jdstrand> s/are started/are being started/
[13:40] <tkamppeter> pitti, did you also already know that HP upstream also uses the Launchpad as bug tracking system? This is nice, as if someone reports a bug to Ubuntu and it is an upstream, problem, one can move it easily and bring the reporter into direct contact with the HP guys.
[13:40] <pitti> tkamppeter: I noticed that they are quick on replying, yes
[13:41] <pitti> tkamppeter: do they actually read all the Ubuntu bugs, or only those which we create an upstream task for?
[13:41] <tkamppeter> pitti, for example on this failed SRU I have simply added an upstream task to tell HP that it needs more love from them.
[13:41] <pitti> tkamppeter: ah, cool; yes, that's how it's supposed to work in LP
[13:42] <Keybuk> jdstrand: alongside
[13:42] <pitti> nice to see that it actually does :)
[13:42] <StevenK> pitti: TheMuso will probably be your new best friend tomorrow.
[13:42]  * pitti hugs TheMuso
[13:42] <pitti> StevenK: ?
[13:43] <StevenK> pitti: TheMuso is doing libglib1.2 NBS work
[13:43] <jdstrand> Keybuk: heh, yes, I guess I am being thick-- that was the word I wanted clarification on. So it will be started *sometime* during when rc2 scripts are being run?
[13:43] <TheMuso> pitti: Getting ready to do a rebuild run to catch any lingering FTBFS ssues overnight, and a double check that the packages being changed actually need the change.
[13:43] <pitti> aah, right, we talked about htat this morning (and about scripting it)
[13:43] <jdstrand> Keybuk: so I can't depend on a certain order
[13:43]  * StevenK has grabbed the gsl NBS stuff
[13:43] <kervala> hi there :)
[13:43] <tkamppeter> pitti, one HP guys is in the bug contacts of the HPLIP package, and I have ususally subscribed some more HP guys (before HP upstream used Launchpad), and then they usually reacted quickly and did the fix in the following release (HPLIP releases every 1 or 2 months). After a freeze I asked for patches and got them quickly, too.
[13:44] <TheMuso> pitti: Yep with your maintainer script tweaked, the libglib1.2 rebuild work is done, bar a few ones I had to do manually.
[13:44] <pitti> tkamppeter: awesome!
[13:44] <pitti> TheMuso: \o/
[13:44] <TheMuso> Now. To get this shared rebuild script built, and get the two boxes building, and then bed.
[13:44] <TheMuso> s/built/written/
[13:45] <tkamppeter> pitti, so in the sense of Linux support HP printers are the most recommended to buy.
[13:45] <kervala> i have some problems with my PPA (related to missing .mo files in generated .deb) :) who could help me please ? :)
[13:45] <persia> kervala: You might get help on #launchpad
[13:46] <persia> Do PPAs run pkgbinarymangler?
[13:46]  * StevenK grumbles, only getting 23KB/s from archive.u.c
[13:46] <StevenK> persia: I daresay they do
[13:46] <jdstrand> Keybuk: maybe if I am more direct.  I'd like to start a script before any run-level scripts.  it sounds like 'start on runlevel 2' is not for me.  will 'start on started rcS' then be guarnateed to run before runlevel 2, for example?
[13:46] <kervala> persia> thanks, i will see there :) there are too many channels :p
[13:46] <Keybuk> jdstrand: the job will be started at exactly the same time that the /etc/init.d/rc script is started to run through the scripts in /etc/rc2.d
[13:47] <Keybuk> jdstrand: started rcS happens before starting rc2 due to the way those scripts work
[13:47] <jdstrand> Keybuk: ok, so 'start on runlevel 2' is kinda like a 00foo initscript
[13:47] <jdstrand> in terms of timing
[13:48] <jdstrand> Keybuk: ok thank you for the clarification
[13:49] <Keybuk> jdstrand: no
[13:49] <cjwatson> soren: I'm not convinced either
[13:50] <Keybuk> jdstrand: 00foo is run by rc, and has guaranteed ordering based on 01aa or 00aa
[13:50] <soren> cjwatson: It makes sense that it should break the loop when either of the involved parties eof.
[13:50] <cjwatson> soren: seems like that'll always drop the last messages on either one or the other of the status and debconf command fds
[13:50] <soren> cjwatson: ...the question is whether it will have any ill side effects.
[13:50] <cjwatson> it's supposed to break the loop when both of them are closed, not just one
[13:50] <Keybuk> jdstrand: an "on runlevel 2" upstart job may be run before, at the same time as, after or even pre-emptively with any job in rc2
[13:50] <Keybuk> depending on your kernel, time sharing, etc.
[13:50] <soren> cjwatson: Ok.
[13:52] <jdstrand> Keybuk: ah-- by 'started at exactly the same time', you just meant upstart will begin going through its 'start on runlevel 2' jobs at the same time it begins the first rc2 script
[13:53] <soren> cjwatson: Ok, so the loop gets progress from apt and sends it to debconf's frontend.. Is that right?
[13:53] <soren> No, that doesn't smell right.
[13:54] <soren> cjwatson: I get confused by the fact that we're checking DEBCONF_COMMAND_*READ* to see if it's *wrtiable*.
[13:54] <jdstrand> Keybuk: you said 'started rcS happens before starting rc2 due to the  way those scripts work
[13:55] <cjwatson> soren: the loop takes progress-type messages from both apt's status fd and a debconf fd passed through apt, and translates them into the appropriate debconf commands to send to its own frontend
[13:56] <jdstrand> Keybuk: does that mean that if I use 'start on started foo', that all I am guaranteed is that foo will begin executing, and then my script will start, whether foo is finished or not?
[13:56] <soren> cjwatson: Oh.. So there's two debconfish things involved.
[13:57] <jdstrand> Keybuk: or am I reading too much into your statement
[13:57] <jdstrand> ?
[13:57] <soren> cjwatson: Er... I'll shut up now, and actually read the code.
[13:57] <cjwatson> yes, the apt process called by tasksel is configured such that packages it installs will start up an independent debconf 'passthrough' frontned
[13:57] <cjwatson> frontend
[13:57] <cjwatson> which means "send stuff to this fd please rather than starting up your own UI"
[13:57] <Keybuk> jdstrand: correct
[13:58] <soren> cjwatson: Oh, ok.
[13:58] <Keybuk> jdstrand: all "start on started foo" guarantees is that foo has at least started before you are run
[13:58] <Keybuk> it does not guarantee that it hasn't since stopped again
[13:59] <jdstrand> Keybuk: is there a 'start before runlevel 2' directive?
[13:59] <jdstrand> Keybuk: or would that just be better served by using a 00.. initscript?
[13:59] <Keybuk> jdstrand: you want your job to start as rc2 attempts to start, and your job has to complete before rc2 is allowed to continue starting?
[13:59] <jdstrand> Keybuk: yes
[13:59] <Keybuk>   start on starting rc2
[13:59] <Keybuk> (and make sure you don't use the word "service" or "respawn" in your job)
[13:59] <cjwatson> soren: the only fd being selected on is DEBCONF_COMMAND_READ
[14:00] <jdstrand> Keybuk: ok cool
[14:00] <Keybuk> (frankly, since you care about runlevels, I think you'll be better served by writing it as an ordinary init script)
[14:00] <soren> cjwatson: When it's hanging?
[14:00] <cjwatson> soren: yeah
[14:00] <soren> cjwatson: Yes, that sounds right.
[14:00] <soren> cjwatson: apt seems to terminate just fine.
[14:00] <cjwatson> (determined by looking through the trace of d-a-p's startup)
[14:01] <cjwatson> ok, so why is the other end of that pipe not being closed?
[14:01] <soren> I've not used debconf much, but isn't there something about it not letting go of certain file descriptors when it finishes?
[14:02] <cjwatson> that shouldn't apply when it actually *exits*
[14:02] <cjwatson> anyway, meeting, will get back later
[14:02] <jdstrand> Keybuk: ok, now thank you for clarifying this for me :)
[14:03] <soren> cjwatson: Sure.
[14:08]  * Hobbsee pokes infinity with a big stick
[14:17]  * lamont grumbles at curl, amarok, tuxtype, abiword, aalib, and nspr for build-depend looping
[14:18] <Hobbsee> they do?
[14:22] <lamont> Hobbsee: I know they were dep-wait looping on hppa.  or at least they seemed to be...
[14:22] <Hobbsee> lamont: ahhh
[14:22] <lamont> I threw them in the cellar and stomped on them last night
[14:22] <Hobbsee> hehe
[14:23] <lamont> I fat-fingered it though: nspr wound up at 199 instead of 100 with the rest
[14:24] <soren> cjwatson: Hm.. strace reveals that DEBCONF_COMMAND_READ gets file descriptor 9, but apt is only told to keep fd's 5 and 6 (and use 4 for status messages).
[14:37] <tkamppeter> pitti, system-config-printer seems to hang in the queue and does not upload. The bugs still did not auto-close and the LP still shows the old version.
[14:38] <pitti> tkamppeter: ah, I bet I know why; you forgot to build with -sa, I reuploaded, and forgot to remove the .upload file
[14:38] <Riddell> dholbach: do you know about dh_icons?
[14:38] <dholbach> Riddell: what do you want to know?
[14:38] <pitti> tkamppeter: uploading again
[14:38] <ogra> oooh. soren you go the same path as i did in gutsy with my ltsp udeb :) book a place in the nearest asylum in advance :) i think the only person not going insane about this debconf fd stuff is actually cjwatson :)
[14:38] <Riddell> dholbach: we seem to have found a bug in it, and I'm curious why it hasn't affected others
[14:39] <Riddell> dholbach: bug 173770
[14:39] <ubotu> Launchpad bug 173770 in kdelibs "kdelibs-data is un-uninstallable" [Undecided,New] https://launchpad.net/bugs/173770
[14:39] <tkamppeter> pitti, I have a rev1772 which is more complete, should I give you that one?
[14:40] <soren> ogra: My head is spinning a bit, yes :)
[14:40] <pitti> tkamppeter: too late now, I already uploaded
[14:41] <ogra> soren, i tried for a while and then reverted to the old ugly behavior (i'm running two instances of debconf in two stacked chroots ... which actually isnt possible and i didnt find any way around it)
[14:42] <StevenK> pitti: You mentioned in the bug libfakekey can be promoted, does that mean it has been or will be?
[14:43] <pitti> StevenK: 'can be', once we actually need it in main
[14:43] <dholbach> Riddell: which part of the postrm is it that fails?
[14:43] <dholbach> Riddell: one example I found on my machine: http://pastebin.ubuntu.com/2460/
[14:43] <pitti> StevenK: if it helps you in any way I can promote it right now, but that might make it harder for people like Adilson who aren't core-devs
[14:43] <StevenK> pitti: Fair enough. I will work on some of the problems tomorrow
[14:43] <StevenK> pitti: No no, just curious
[14:44] <StevenK> Adilson isn't even a MOTU
[14:44] <StevenK> lool isn't a core-dev, though
[14:46] <Riddell> dholbach: well the "update-icon-caches /usr/share/icons/crystalsvg" line
[14:46] <Riddell> dholbach: your one looks quite different
[14:47] <dholbach> Riddell: it seems they changed it in debian
[14:47] <dholbach> I filed a bug report once to get the     || true     added
[14:47] <dholbach> seems it got removed again
[14:48] <dholbach> or  update-icon-caches  fixed to not fail at all
[14:51] <Riddell> dholbach: do you know who's best to contact in debian to ask what's going on?
[14:51] <dholbach> lool: Josselin does dh_icons, right?
[14:51] <cjwatson> soren: DEBCONF_COMMAND_READ is debconf-apt-progress' private side of it. DEBCONF_COMMAND_WRITE (the other half of the pipe) is duped onto fd 6.
[14:53] <tkamppeter> pitti, thanks for the upload, I have seen the bugs auto-closing now.
[14:53] <cjwatson> soren: I think I might see the problem
[14:56] <cjwatson> soren: oh, hmm, no
[14:57] <soren> cjwatson: I'm a bit confused. I see a few calls to nocloexec, but in strace, all I see is a whole bunch of "fcntl(various_fd's, F_SETFD, FD_CLOEXEC)".
[14:57] <pitti> ah, the joys of Debian and upstream accepting patches -- the sudo merge finally is a breeze now
[14:57] <cjwatson> that's what nocloexec does ...?
[14:58] <soren> I expected it to unset FD_CLOEXEC?
[14:58] <soren> Rather than set it.
[14:58] <cjwatson> oh, sorry
[14:58] <cjwatson> 14988 fcntl64(4, F_SETFD, FD_CLOEXEC)   = 0
[14:58] <cjwatson> 14988 fcntl64(4, F_GETFD)               = 0x1 (flags FD_CLOEXEC)
[14:58] <cjwatson> 14988 fcntl64(4, F_SETFD, 0)            = 0
[14:58] <cjwatson> that's the sort of thing I see
[14:58] <cjwatson> the first SETFD is internal to perl
[14:59] <soren> cjwatson: Oh, you're right.
[14:59] <cjwatson> soren: OK. I think what's happening is that the apt-get subprocess dies, but doesn't actually get reaped until debconf-apt-progress' loop terminates.
[14:59] <cjwatson> soren: apt-get probably explicitly closes its status fd, but doesn't close the reserved debconf passthrough fds.
[14:59] <cjwatson> soren: so the write end of DEBCONF_COMMAND_* doesn't get cleaned up fully until the zombie apt-get is reaped by debconf-apt-progress
[15:00] <lool> dholbach: I'm not sure; I think Joey Hess + Josselin did
[15:00] <cjwatson> soren: the fix, I think, is to have a proper SIGCHLD handler which sets a flag that we can use to reap apt-get
[15:01] <cjwatson> soren: or possibly even just $SIG{CHLD} = 'IGNORE';
[15:01] <lool> dholbach: But I don't want to touch this; they basically ignore my comments   :-/
[15:01] <cjwatson> though, well, we do care about the exit status, so not IGNORE
[15:01] <dholbach> Riddell: ^ what lool said :-/
[15:02] <cjwatson> soren: you need to be fairly careful when writing a SIGCHLD handler (or indeed any signal handler) in perl, though.
[15:02] <cjwatson> or in any language :-)
[15:02] <cjwatson> perlipc(1) may help
[15:03] <lool> The very thing I asked was to encapsulate the list of directories for which to run gtk-u-ic in some place as to allow us to re-run it or fix stuff in these dirs
[15:06] <cjwatson> soren: in fact, since select() is interrupted when SIGCHLD arrives, you could just try waitpid $pid, WNOHANG and if you get a child back then save its status for later. You still need to process any remaining input from the pipes, but now the other end of DEBCONF_COMMAND_* should be properly closed and you'll break out at the right time.
[15:07] <robertj> is anyone intimately familiar with system-config-printer? I added a printer using it to my local machine and the remote print server then lost its association between printers & windows printer drivers. Its probably on the remote end by I'm trying to figure out what it could have done to trigger that.
[15:08] <soren> cjwatson: I realise that this would fix it, but it it really doesn't seem like the right approach. If the other end is supposed to let go of the file descriptor but doesn't, then something must be wrong?
[15:08] <Riddell> lool: can you fix it in ubuntu?
[15:08] <robertj> server is to my best guest held together by voodoo & duct-tape but I'm still trying to figure out what kicked it into action
[15:08] <cjwatson> soren: no, it's right - the other end doesn't let go until the process is actually cleaned up properly
[15:09] <cjwatson> this is how Unix works, it's fine
[15:09] <cjwatson> soren: something like http://paste.ubuntu.com/2461/ (untested, meeting now)
[15:09] <kagou> hi
[15:10] <lool> Riddell: I didn't read about the problem yet
[15:10] <cjwatson> soren: and we really should reap the process ASAP anyway
[15:10] <lool> Riddell:  bug 173770?
[15:10] <ubotu> Launchpad bug 173770 in kdelibs "kdelibs-data is un-uninstallable" [Undecided,New] https://launchpad.net/bugs/173770
[15:11] <Riddell> lool: yes
[15:11] <cjwatson> we might need to do it each time round the loop as well, since the SIGCHLD won't necessarily interrupt the select
[15:11]  * soren could have sworn fd's got close()d when exit was called.
[15:12] <pitti> asac: can you please open a MIR bug for xulrunner? (changed process, see the note on the top of UbuntuMainInclusionPage and MainInclusionProcess)
[15:12] <cjwatson> they might do, but I suspect the other end doesn't get an exception from select until it's reaped
[15:12] <asac> pitti: i opened a MIR bug :) ... let me see
[15:13] <pitti> asac: ah, ok; I just saw your Queue wiki page change
[15:13] <asac> pitti: its named at the bottom
[15:13] <soren> cjwatson: That doesn't make sense.
[15:13] <cjwatson> soren: seems to match what's happening :-)
[15:13] <asac> pitti: ok subscribing ubuntu-mir
[15:13] <pitti> asac: ah, splendid; thanks
[15:13] <soren> cjwatson: Got me there. :)
[15:13] <cjwatson> select is weird
[15:14]  * soren looks at strace output some more
[15:15] <pitti> asac: yay xulrunner :)
[15:15] <asac> pitti: now that we track it through bugs ... do we still need the wiki pages?
[15:15] <pitti> asac: the MIRs, yes, but not the Queue page
[15:15] <asac> e.g. filling out the template in summary?
[15:15] <asac> ah ok
[15:15] <pitti> asac: well, if you want you can also put the actual MIR into the bug, I don't mind much
[15:16] <pitti> but wiki formatting is nicer to read for long reports, and for changes (IMHO)
[15:16] <pitti> asac: no editmoin for LP bugs :)
[15:18]  * ogra thought the queue page is obsolete
[15:18] <pitti> asac: I smell a MIR for ffox 3, too, I guess
[15:18] <pitti> ogra: it is
[15:18] <pitti> ogra: that's what we just said
[15:18] <ogra> oh, blind me
[15:20] <lool> Riddell: Looking at the postinst snippet, I think it should test for the dir before trying to run this command; I'm checking with Josselin
[15:22] <lool> Riddell: Josselin said it's a bug; I'm confirming where he wants to fix it, and will upload the same fix
[15:24] <Riddell> lool: thanks.  let me know when it's in the archive and I'll rebuild kdebase against it
[15:24] <lool> Riddell: You wont need to; the fix should be applied to the script in libgtk2.0-bin it seems
[15:24] <Riddell> oh, lovely
[15:31] <faheem__> Hi. I have a package that needs postgres 8.1 or later on Debian. However, Ubuntu doesn't seem to want to install 8.1. I want to use the same packaging (rules/control files) on both Debian and Ubuntu. Any suggestions?
[15:32] <faheem__> Well, it complains about 8.1, anyway.
[15:38] <seb128> Riddell: dh_icons is a debhelper script, not a gtk+ thing
[15:39] <lool> Riddell: Can you check the new script (copy it over from debian/ to /usr/bin) and sponsor the upload if it works?  http://people.ubuntu.com/~lool/packages/gtk+2.0/2.12.2-1ubuntu1/hardy/gtk+2.0_2.12.2-1ubuntu1.dsc
[15:39] <lool> Riddell: I'm not finished uploading
[15:39] <seb128> lool: ?
[15:39] <lool> seb128: The bug can be fixed in the snippet or in the wrapper script in Gtk+; Josselin wants to fix it in Gtk+
[15:39] <seb128> lool: do you speak about bug #173770?
[15:39] <ubotu> Launchpad bug 173770 in debhelper "kdelibs-data is un-uninstallable" [Undecided,New] https://launchpad.net/bugs/173770
[15:39] <lool> seb128: Check #gnome-debian or my latest commit
[15:39] <lool> seb128: Yes
[15:40] <lool> Riddell: Upload complete now
[15:40] <seb128> lool: we are in sync with Debian for gtk+2.0, no need to do an hardy upload to ask a sync then
[15:40] <seb128> lool: better to just wait for the new revision to be uploaded in Debian
[15:41] <lool> Riddell: ^^^
[15:41] <lool> seb128: Depends how long this can wait
[15:42] <seb128> there is no hurry imho, it's a corner case
[15:42] <Riddell> yeah, nobody removes kde once they have it installed :)
[15:42] <lool> Please discuss what's best; I don't want to upload to Debian nowish though
[15:43] <seb128> I would say "do nothing and wait for the next upload to debian"
[15:43] <seb128> we got one bug about that and the bug is likely there for months
[15:43] <seb128> so I don't think it's an urgent issue
[15:44] <dragon76> hello all.
[15:44] <dragon76> tested 2.6.24-1 kernel in hardy last night and kdm doesn't want to start
[15:45] <dragon76> is there anyway I can help troubleshoot
[15:46]  * lamont looks around for an RM/archive god
[15:47] <lamont> https://edge.launchpad.net/ubuntu/+source/curl/7.17.1-1ubuntu1/+build/461099
[15:47] <lamont> there is no way to tell launchpad to not decide that since libssh2-1-dev is in universe, that it should free the dep-wait
[15:47] <lamont> it'd be nice to get those fixed (there are about 5 such packages atm)
[15:52] <Riddell> lool: that does fix it by the way
[15:55] <lool> Riddell: Cool
[16:01] <soren> cjwatson: It doesn't add up. Even if I call _exit in the child and don't reap it, the select call still returns.
[16:09] <cjwatson> soren: select will return no matter what - that's what happens when you get a signal, it interrupts the syscall
[16:09] <soren> cjwatson: Even if I run it again, it will return right away because the child is gone and there's an eof waiting for me.
[16:13] <Zic> hi, I can see their is some « restricted/multiverse » code in main/universe at http://packages.ubuntu.com/cgi-bin/search_contents.pl?word=iwlwifi&searchmode=searchword&case=insensitive&version=gutsy&arch=i386
[16:13] <Zic> the question is why ?
[16:15] <soren> cjwatson: Oohh..
[16:16] <soren> cjwatson: Glancing around in /proc reveals that the pipe is still connected to one of the daemons that got started as a result of installing the task.
[16:17] <soren> cjwatson: Well, if I can expect  pipe:[6280851]  to uniquely identify the pipe, at least.
[16:21] <cjwatson> soren: aha
[16:21] <cjwatson> sounds plausible
[16:21] <cjwatson> yes, you can
[16:21] <soren> cjwatson: I thought so.
[16:21] <cjwatson> I see that sort of as a bug in said daemon
[16:21] <soren> I'm curious why bind doesn't close superfluous fd's, though.
[16:21] <cjwatson> but perhaps we can work around it ...
[16:21] <soren> Something is not setting CLOEXEC, but should.
[16:22] <soren> There's just too much stuff involved here for me to figure out which component is to blame. :)
[16:24] <soren> Some sort of tool that could track the life of file descriptors would have been quite helpful here. "strace -f" is confusing :)
[16:25] <cjwatson> can't set CLOEXEC on this
[16:25] <cjwatson> that fd has to go all the way to the postinst
[16:27] <cjwatson> maybe we do just have to ignore trailing stuff on the debconf command fd
[16:35] <cjwatson> soren: in that case maybe something like 'while (not $status_eof)' would be better, with a honking comment
[16:36] <cjwatson> but it's unfortunate that bind is going to have that fd hanging around
[16:36] <soren> cjwatson: Yeah, you'd think that a piece of software that old would have fixed that sort of thing by now.
[16:36] <cjwatson> well
[16:36] <cjwatson> packages that use debconf are expected to have to deal with this
[16:37] <cjwatson> but bind9 doesn't actually use debconf itself
[16:37] <soren> It does not.
[16:37] <cjwatson> so historically it wouldn't have shown up in Debian
[16:40] <soren> With my limited knowledge of the intimate details of debconf, apt and dpkg and how they work together it doesn't seem unreasonable to assume that the last thing to be closed would be the status fd?
[16:41] <lamont> soren: bind or bind9?
[16:42] <soren> lamont: bind9
[16:42] <lamont> grumble
[16:43] <lamont> oh. right.  no debconf usage in bind9.
[16:43] <lamont> I win.
[16:43] <soren> Well... It would be kind of nice if it close()d the superfluous file descriptors.
[16:43] <lamont> or do I need to fix something>?
[16:44] <soren> Sure, we should fix our end of things, too, but still.
[16:46] <lamont> I expect it's a case of "don't run it with extra fds, why should we waste our time running through all the possible fds closing them?" sort of responses from upstream.
[16:46]  * soren sighs
[16:46] <lamont> if we started up debconf just long enough to end it, would that solve the issue?
[16:47] <lamont> so far, bind9 has happily managed to avoid using debconf
[16:47] <soren> *G*
[16:50] <lamont> the other bug I need to stare at in bind9 is bug 453765
[16:51] <lamont> hrm  I wonder if I should say debbug 453765 or debian bug 453765
[16:51] <ubotu> Debian bug 453765 in bind9 "bind9 stops during upgrade" [Normal,Open] http://bugs.debian.org/453765
[16:58] <cjwatson> lamont: starting up debconf will not help
[16:59] <cjwatson> lamont: I think bind should close stray fds (aiui, it's fairly standard practice for daemons to do so), but it's not critical
[16:59] <cjwatson> soren: yeah, I think that's probably right
[16:59] <lamont> cjwatson: true enough.
[17:00] <cjwatson> soren: try it out?
[17:00]  * lamont wanders afk for a while
[17:00] <soren> cjwatson: I'm sure it works. It's effectively the same as my original suggestion :)
[17:01] <soren> cjwatson: I'm just asking for advice as you're more familiar with the possible corner cases, we could come across.
[17:01]  * soren is assuming that "try it out" referred to just checking for $status_eof
[17:02] <cjwatson> yes
[17:02] <cjwatson> I think it's probably equivalent in practice but more accurate in theory
[17:02] <cjwatson> it works for me
[17:02] <cjwatson> http://paste.ubuntu.com/2464/ <- what I used
[17:04] <soren> Makes sense.
[17:06] <cjwatson> suggestions for a comment?
[17:06] <cjwatson> (sorry, very little mental bandwidth today)
[17:08] <soren> cjwatson: "STATUS_READ should be the last fd to close"?
[17:08] <cjwatson> maybe combined with "DEBCONF_COMMAND_WRITE may end up captured by buggy daemons, so terminate the loop even if we haven't hit $debconf_command_eof."
[17:08] <soren> You win.
[17:09] <cjwatson> I included both :)
[17:09] <cjwatson> is there a bug number for this?
[17:09] <soren> Yes. Hang on.
[17:10] <soren> There's more than one, actually.
[17:11] <soren> bug 165165, bug 141601 at least.
[17:11] <ubotu> Launchpad bug 165165 in tasksel "tasksell install lamp-server hangs" [Undecided,New] https://launchpad.net/bugs/165165
[17:11] <ubotu> Launchpad bug 141601 in tasksel "tasksel packages stays at 100%" [Undecided,New] https://launchpad.net/bugs/141601
[17:11] <soren> I believe ther'es more.
[17:12] <cjwatson> I'll refer to 141601; please dup the others
[17:12] <cjwatson> soren: r2249 in svn://svn.debian.org/svn/debconf/trunk/src/debconf
[17:13] <cjwatson> committed with your name :)
[17:13] <soren> cjwatson: Excellent. Thanks for helping with this!
[17:13] <cjwatson> soren: could you deal with getting it into Ubuntu?
[17:13] <soren> cjwatson: Er.. We should sync it automatically?
[17:13] <soren> Do we have a debconf delta?
[17:13] <cjwatson> a gutsy SRU might make sense
[17:13] <soren> Oh.
[17:13]  * soren sighs
[17:13] <cjwatson> then at least affected people could be given a fixed CD image
[17:14] <soren> Sure. i'll add it to my todo list.
[17:14] <cjwatson> I agree, for hardy it should just be synced
[17:15] <cjwatson> I'll see about a Debian upload at some point, though there's also a teletype frontend bug I'd like to clear up
[17:15] <soren> Mkay. Some time before alpha 2?
[17:15] <cjwatson> remind me in case I suck
[17:16] <cjwatson> thanks very much for finding this, I was too close to see the problem
[17:16] <soren> cjwatson: Always a pleasure. Now I won't be quite as lost if I have to deal with debconf again.
[17:17] <soren> \o/
[17:17] <cjwatson> maybe you can draw a diagram for the next guy :)
[17:17] <cjwatson> did I explain sufficiently how all the bits slot together?
[17:17] <soren> Honestly, no :)
[17:17] <soren> Just enough to figure out why this was broken.
[17:18] <cjwatson> doc/passthrough.txt would be a reasonable thing to read
[17:18] <soren> cjwatson: Does tasksel use debconf as a frontend somehow?
[17:18] <cjwatson> "confmodule" maps to your average .config or .postinst, "frontend" is the debconf process that implements both the database and (for non-passthrough) the UI
[17:18] <cjwatson> soren: oh my, yes
[17:19] <soren> If so, I think I've got the gist of it.
[17:19] <cjwatson> tasksel is a debconf confmodule itself
[17:19] <cjwatson> though an unusually written one
[17:19] <cjwatson> a debconf application if you like
[17:19] <soren> Ok.
[17:19] <soren> Got it.
[17:20] <cjwatson> though actually, there are two bits
[17:20] <cjwatson> if you run tasksel in interactive mode, it acts as a debconf confmodule and asks you a multiselect question about which tasks to install
[17:21] <cjwatson> in the 'tasksel install dns-server' type case, it doesn't start up debconf itself, but runs aptitude under the control of debconf-apt-progress
[17:21] <cjwatson> and in that case debconf-apt-progress is the debconf confmodule
[17:21] <soren> Alright.
[17:22] <cjwatson> so you get debconf (frontend displaying actual UI) --- debconf-apt-progress (confmodule) --- apt-get --- dpkg --- debconf (frontend passing everything through) --- postinst (confmodule)
[17:22] <soren> Right. Got it.
[17:22] <cjwatson> dpkg doesn't actually start up debconf directly itself, but that's the conceptual layout
[17:22] <cjwatson> you really do need paper to figure out the file descriptor plumbing though
[17:23] <soren> Yeah, I think I got the gist of that, but there certainly details that are a bit opaque still.
[17:24] <cjwatson> oh, one further wart
[17:25] <cjwatson> in the installer, it's even more complicated, because the whole thing is running under an existing cdebconf UI
[17:25] <cjwatson> so in that case debconf-apt-progress is ALSO doing passthrough
[17:25] <soren> cdebconf is an alternative implementation of the debconf spec, I presume?
[17:25] <cjwatson> yep
[17:25] <cjwatson> it has a few deviations, but mostly the same
[17:25] <cjwatson> mostly things that aren't in the spec ...
[17:26]  * ogra shudders ...
[17:26] <cjwatson> this is what makes it possible for packages being installed in the /target chroot to ask questions using the same interface
[17:27] <cjwatson> and it's how we got rid of the two-stage installer
[17:27] <ogra> unless you call another debconf in a subsequent chroot insode /target :( then it gets tricky
[17:27] <cjwatson> ogra: it's not easy, but that *is* what tasksel does
[17:27] <cjwatson> (indirectly)
[17:27] <ogra> yeah
[17:28] <cjwatson> you have to be careful to use a separate database for the inner debconf
[17:28] <cjwatson> otherwise they clash on the same lock
[17:28] <ogra> i guess i have to wrap my mind around it again for hardy ... if ltsp goes on -alternate
[17:28] <soren> cjwatson: Ok, let's agree that I'll remind you of this some time before alpha 2, and you'll remind me about the sru when you upload this. :)
[17:28] <cjwatson> ogra: did you ever try using debconf-apt-progress?
[17:28] <ogra> no, i didnt even know about it
[17:28] <ogra> i tried to get the fd's right
[17:29] <cjwatson> because it does the database stuff you need to start an inner debconf process - along with a bunch of other stuff
[17:29] <cjwatson> if you're inside debconf and want to call apt, debconf-apt-progress should normally be involved
[17:29] <ogra> i'll look at it
[17:29] <ogra> (currently i have higher prio stuff though)
[17:30] <cjwatson> at least if you want the installed packages to be able to interact
[17:30] <cjwatson> ogra: of course, I know about that :)
[17:30] <ogra> :)
[17:30] <ogra> crurently what we have is ugly but works ... its all about cosmetics
[17:30] <cjwatson> aye
[17:31] <soren> cjwatson: Thanks for the tutorial :)
[17:31] <cjwatson> soren: any time
[18:29] <bdmurray> tkamppeter: in regards to bug 153152 the gutsy-proposed package does not fix it - is that correct?
[18:29] <ubotu> Launchpad bug 153152 in hplip "[Gutsy SRU request] Fax utility not adding files to job." [High,Confirmed] https://launchpad.net/bugs/153152
[19:11] <tkamppeter> bdmurray, about bug 153152, that is correct, HP's patch generates the file now, but when the generation of the file has completed, hp-sendfax crashes. There is also another bug. I have reported this back to HP.
[19:11] <ubotu> Launchpad bug 153152 in hplip "[Gutsy SRU request] Fax utility not adding files to job." [High,Confirmed] https://launchpad.net/bugs/153152
[19:13] <bdmurray> tkamppeter: so verification is no longer needed for that one then?
[19:14] <tkamppeter> Yes.
[19:14] <tkamppeter> bdmurray, I have removed the tag now.
[19:15] <bdmurray> tkamppeter: okay, thanks!
[19:27] <bpl> sudo apt-get build-dep karm -> E: Build-dependencies for karm could not be satisfied.
[19:27] <bpl> anybody know how I can get a list of what's missing?
[19:31] <geser> bpl: is it a versioned dependency?
[19:35] <bpl> geser: I don't know, that's the problem.  The error message isn't very useful.  How can I find out what build-dependencies cannot be satisfied?
[19:36] <bpl> Right now I'm trawling through the build-depends line in it's debian/control manually, so I suppose I'll eventually find the problem
[19:37] <elmo> apt-get -o debug::pkgproblemresolver=1 build-dep blah
[19:39] <azeem> neato
[19:39]  * azeem has been feeding those packages to sbuild to get some more info
[19:39] <bpl> thanks, that found my problem.  Now I'll head over to #kubuntu for more help.
[19:39] <geser> bpl: sudo apt-get -s build-dep karm works in my hardy chroot
[19:39] <nxvl_work> is there any way to report bugs for spanish speakers?
[19:41] <bpl> I'm using gutsy, but I think the problem might be one of my own making, so I'll be quiet until I can confirm that.
[19:48] <seb128> mdke: hi. The ubuntu layout patch for yelp doesn't apply to the new 2.21 version, could you or don have a look at updating it?
[19:49] <bpl> thanks all, problem fixed. I apt-get remove'd the conflict (which came from a private repo). Was relatively easy once I knew what the problem was.  I suggest that -o debug::pkgproblemresolver=1 be made default for build-dep or at least added to the man page
[20:08] <mdke> seb128: thanks for pointing that out. I'll work with Don on that, sure
[20:09] <seb128> mdke: thank you
[21:07] <mdomsch> any apt developers around?
[21:07] <mdomsch> odd apt package version comparison question
[21:08] <mdomsch>  dpkg --compare-versions a09-1 "<" a09-1
[21:08] <mdomsch>   returns 0
[21:08] <mdomsch> yet, apt-get and aptitude repeatedly replaces packages with such versions with another copy of itself
[21:09] <Kmos> cjwatson: bug 173474
[21:09] <ubotu> Launchpad bug 173474 in ubuntu "daily live cds not available for powerpc" [Undecided,New] https://launchpad.net/bugs/173474
[21:09] <azeem> mdomsch: 1. it
[21:09] <azeem> oops
[21:10] <mdomsch> azeem, 1.a09 ?
[21:10] <azeem> mdomsch: 1. it's unclear why you think only apt developers know the answer 2. this is a dpkg question
[21:10] <mdomsch> azeem, fair enough on both points
[21:11] <mdomsch> except that dpkg --compare-versions gets it "right"
[21:11] <mdomsch> which is why I'd think it odd in apt
[21:19] <ajmitch> mdomsch: is it in a PPA?
[21:23] <mdomsch> ajmitch, no, it's the Dell BIOS payload debs I've been working on
[21:23] <mdomsch> firmware-tools and firmware-addon-dell are in a PPA
[21:25] <ajmitch> ok, because I was going to say that there's a soyuz bug  https://bugs.edge.launchpad.net/soyuz/+bug/165230 about the issue, with the generated package indexes
[21:25] <ubotu> Launchpad bug 165230 in soyuz "PPA generates an endlessly upgrading package" [Undecided,In progress]
[21:26] <mdomsch> ah, thanks
[21:27] <mdomsch> I'm rebuilding all the packages now, with 0.version  if they're version a09 or so, or if they're using the new sane version scheme, 1.3.3 for package version 1.3.3 :-)
[21:27] <mdomsch> there's a _slight_ chance a system with a bios version a09 would get updated such that the newer version is 1.3
[22:06] <mdomsch> fwiw, prepending 0. didn't solve it for me
[22:06] <mdomsch> must be something else