=== cody-somerville_ is now known as somerville32 === RAOF_ is now known as RAOF [00:44] bug 2311 [00:44] Launchpad bug 2311 in gst-ffmpeg "divx videos not working" [Medium,Invalid] https://launchpad.net/bugs/2311 [00:47] hello [00:57] 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] anyone around with the right access to tell me if queue-builder is running, and if so ETA to finished? === chuck is now known as zul [03:57] * lamont wonders if anyone knows how to take apart and iPod nano... [03:57] I can make it be in pieces ... [03:57] Probably not what you're after. :-P [03:57] no, she kinda wants it back together at the end. [03:57] or at least running on power. [03:58] * ScottK is REALLY good at taking stuff apart. ;-) [03:58] lamont: I didn't think you could? [04:14] StevenK: done. :-0) [04:15] Heh [04:15] lamont: So you should document the process and then get Apple lawyers to hate you [04:16] google is love [04:17] Ah === stu1 is now known as stub === macd_ is now known as macd [05:49] good morning [05:50] Hi [05:51] hey ion_ === cjwatson_ is now known as cjwatson [06:08] 5~5~/c [06:08] argh [06:10] 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] TheMuso: BTW, you have a stray identity; you might want to visit https://launchpad.net/people/+requestmerge?field.dupeaccount=luke-themuso [06:11] hmm ok thanks [06:11] cjwatson: And, crimsun took care of the seed change. [06:11] ok [06:24] elkbuntu: Back home? [06:24] StevenK, yep, got back on sunday night [06:24] elkbuntu: Sorry I missed you. :-( [06:24] yeah :( [06:25] hey elkbuntu [06:25] hobbsee's car went pop, so i didnt even get to catch up with her :( [08:05] Good morning [08:06] Morning pitt [08:06] Err [08:06] pitti :-) [08:07] * Fujitsu drops StevenK into a pit. [08:09] hi all [08:09] hey StevenK [08:09] sivang! Long time no see [08:09] yeah :) [08:09] how are you my dear friend? [08:10] pretty well, and you? [08:10] married, happy, and busy :) [08:11] Fujitsu: In terms of WoW, I'm in one ... crawling with level 48-50 insects. *shiver* [08:11] 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] sivang: what should that be? it was removed in feisty [08:21] pitti: ah I see [08:21] pitti: this is a package that holds sources for binutils and gcc needed for cross compilation of stuff [08:21] sivang: I'm not sure, but maybe the normal gcc-4.2 source package supports this now? [08:22] where can I find the log for toolchain-source's deprecation or removal ? [08:24] is there a channel for ubuntu embedded now? I mgiht ask there [08:24] and possibly contribute back my findings on the AU1550 amd based box ;) [08:24] (debian runs beautifully on it) [08:25] http://people.ubuntu.com/~ubuntu-archive/removals.txt [08:26] never mind , need to run [08:26] laters all, wonderful day to you all [08:30] morning [08:37] does anyone know if newz is on holiday or otherwise off work at the moment? [08:38] Well, he's in the US, so he's probably asleep, but apart from that, I think he should be around. === \sh_away is now known as \sh [08:39] soren: yes, I meant in general, thanks [08:39] what's happening with gtk+/glib-1.2 in hardy? fvwm is uninstallable because it refuses to install libglib1.2 [08:41] tjaalton: Library transition: http://people.ubuntu.com/~ubuntu-archive/NBS/libglib1.2 still need a rebuild. [08:41] persia: yeah, I dug a bit more [08:41] mdke: np :) [08:43] 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] 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] seb128: As geser said, Debian does have the transition (with 1.2.10-18). [09:02] geser, persia: I hope you are using a script for the rebuilds? [09:02] (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] 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] StevenK: Isn't that only the case for the remaining few hundred cases where we have Ubuntu variation and no Ubuntu maintainer? [09:04] 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] 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] 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] looking [09:17] 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] umm, using "-vversion" for debuild makes it segfault on gutsy [09:18] mvo: I thought that was upstreamed already [09:19] nevermind [09:19] forgot the epoch.. [09:20] Amaranth: last I heard they consider it too much of a hack to include it into the regular tree [09:21] oh, we'll figure that out later i guess [09:21] heh, your changes to compiz where stuff i had locally and forgot to push [09:22] which ungodly hack is that? [09:22] disable wall edges unless you're dragging a window [09:22] so they don't stop you from clicking on things in corners/edges [09:24] mvo: everything else looks good [09:24] 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] well, there is one bad breakage i get with it [09:25] xmoto pops out of fullscreen as soon as it gets the cursor [09:25] but that's small [09:26] heh :) I should try this [09:38] mvo: command-not-found is missing a build-dependency on python-gdbm. Do you want a debdiff for it? [09:40] geser: if you have it at hand, yes. I noticed the b-d failure mail a couple of minutes ago [09:43] mvo: http://members.ping.de/~mb/c-n-f.debdiff [09:45] geser: thanks! [09:48] geser: I used to be a member of ping.de too in my good old times [09:52] pitti: please give-back extace [09:53] pitti: another two package FTBFS because of the dh_strip bug: dvi2tty and flexml [09:57] pitti: please give-back g15daemon-audacious [10:03] pitti: please give-back gnome-iconedit [10:04] pitt, hi [10:04] pitti, hi [10:18] 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] hi tkamppeter [10:19] hey seb128 [10:19] hello pitti [10:25] pitti, I have re-uploaded the debdiff on for bug 153152, I accidentally deleted it when preparing the SRU in bug 149511. [10:25] 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] Launchpad bug 149511 in ubuntu-meta "[Gutsy SRU request] hplip is needed by HPIJS" [Medium,Fix released] https://launchpad.net/bugs/149511 [10:25] tkamppeter: no problem, that SRU is already in -proposed [10:25] so no new upload necesasry [10:26] tkamppeter: I buess bdmurray only updated hplip for testing, not hpijs? [10:26] pitti: I've already added a comment for both packages in the bug [10:26] geser: ah, thanks [10:27] who the heck let through that message to ubuntu-devel-announce@lists.ubuntu.com [10:27] sladen: We were wondering that yesterday. [10:27] pitti: should I mentioned further packages affected in the bug (if I find others)? [10:28] geser: yes, please [10:28] geser: oh, how evil [10:28] geser: dvi2tty has debian/compat '4', but uses debian/tmp [10:29] argh, and uses DH_COMPAT=1 in debian/rules [10:29] this is so evil === lc is now known as lcstudio [10:31] pitti: compat 4 and debian/tmp is not kosher? Why? [10:31] ah, so DH_COMPAT should trump debian/compat [10:31] soren: debian/tmp is compat level 1 only [10:31] Eh? [10:32] 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] pitti: Ok, we're clearly talking about different things :) [10:32] or am I horribly mistaken? [10:32] Chipzz, soren: man debhelper /V1 [10:32] 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] 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] soren, Chipzz: in mode 1, debian/tmp *is* the package directory of the first package in debian/control [10:33] pitti: Right, ok. You left that bit out :) [10:33] not just a temporary place where to move files to debian// [10:33] soren: well, geser knew :) [10:33] tkamppeter: ah, too bad; please test SRUs on gutsy, too [10:34] tkamppeter: if you want to prepare another update, feel free to sneak in the dependency fix you mentioned [10:34] pitti: ah ok; I see that in the man-page [10:34] geser: ok, I got it fixed for dvi2tty, testing the other ones now [10:35] 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] pitti, if you want to see what happens, do the TEST CASE steps on a Gutsy. [10:35] Chipzz: right, that's common and good practice [10:35] (ie as in 'make install DESTDIR=debian/tmp') [10:35] and use dh_install to move the files in debian/tmp to the correct dirs [10:38] 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] Chipzz: that's orthogonal to triggers; those are implemented at the dpkg level and within ldconfig itself [10:39] Chipzz: read /sbin/ldconfig to see the magic [10:54] pitti, the problem of bug 153152 is non-trivial, I will ask the HP guys to fix it. [10:54] Launchpad bug 153152 in hplip "[Gutsy SRU request] Fax utility not adding files to job." [Undecided,Fix committed] https://launchpad.net/bugs/153152 === cprov-out is now known as cprov === pbn_ is now known as pbn [11:21] 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] does not anyone try to build ubuntu cdroms in their own ? [11:36] adrian15: the initramfs contains 'casper' which goes to hunt for the rest of the LiveCD system to boot [11:38] 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] mvo, indeed [11:38] here or pm ? [11:38] 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] ogra: pm sounds appropriate, I don't think its that interessting :) [11:40] sladen: you have an screenshot here: http://adrian15.raulete.net/ficheros/u710_chainloaded_isolinux.png [11:40] * Hobbsee waves === dholbach_ is now known as dholbach [11:49] hey Hobbsee [11:49] 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] hello everyone [11:50] heya pitti! [11:54] 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] mvo: jcastro was looking into that [11:57] Riddell: nice. if he could just add something to the wiki, that would be cool [12:06] adrian15: you could look at some of the commandline parameteres in the directory: http://www.paul.sladen.org/ubuntu/qemu-livecd/ [12:10] sladen: root=/dev/ram taht's what I suspected [12:11] sladen: but what I don't understand is why isolinux is not able to boot it. (my modified version of isolinux) [12:11] sladen: And I will bet these are the mkisofs options [12:11] sladen: I will try these ones: https://help.ubuntu.com/community/LiveCDCustomization#head-ab8f641f4bbc6cbafbe1699b580c06668bf7a484 [12:15] 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] adrian15: is http://uck.sourceforge.net/ (Ubuntu Customisation Kit) any use [12:16] adrian15: sorry I can't easily tell more from this distance [12:17] ok. thank you [12:18] attunix: https://help.ubuntu.com/community/InstallCDCustomization and https://help.ubuntu.com/community/LiveCDCustomization should help you [12:18] thank you :) [12:33] mvo: You think bug 141601 could be apt's fault? [12:34] Launchpad bug 141601 in tasksel "tasksel packages stays at 100%" [Undecided,New] https://launchpad.net/bugs/141601 [12:34] 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] soren: it can certainly be a apt problem [12:35] mvo: works for me (please check it into bzr) [12:36] soren: I look at it after lunch [12:37] mvo: Cool. Thanks! [12:45] soren: could also be debconf-apt-progress [12:45] soren: which is sort of suggested by the zombie apt [12:46] I rather hoped we'd nailed all of those though [12:47] 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] 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] mvo: you think? OK ... how would a bug in apt lead to a zombie apt-get lying around though? [12:48] or is it that it's writing garbage down the status fd and confusing d-a-p that way? [12:49] I vaguely remember discussing something like that with you, now that you mention it [12:49] cjwatson: Yes, I've noticed that too. [12:49] debconf-apt-progress is extraordinarily delicate :-/ [12:49] soren: a strace would definitely be good to have === asac_ is now known as asac [12:50] I think it's debconf-apt-progress. I have a fix I want to test out. [12:50] soren: I wrote that code and would be interested in reviewing a patch [12:50] ok, I may be wrong, is this reproducable? [12:50] mvo: Yes, apparantly so. [12:50] mvo: Just tasksel install dns-server or something. [12:51] soren: ok, thanks. after lunch then :) [12:51] cjwatson: Gimme a few minutes. [12:52] yes, I see the same bug here [12:53] soren: off for lunch soonish anyway [12:53] pitti: http://paste.ubuntu.com/2455/ <- bzr does not like me today [12:53] cjwatson: I would be interessted if the apt in gutsy-proposed fixes it or not [12:54] cjwatson: It gets stuck in the select call. [12:54] cjwatson: Or so says strace. [12:54] perhaps it's selecting on no fds [12:54] I'll look after lunch if you don't beat me to it :) [12:56] mvo: hm, regression in 1.0? [12:58] StevenK: thanks for the -meta refresh & upload [13:01] Hehe.. [13:01] I think I got it. [13:02] mvo: u-m processed in gutsy-proposed FYI [13:03] 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] 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] pitti: Yes, there will be an on-going effort to clean up the packaging, since some of it is really shocking [13:15] pitti: And I'm well aware what native means. :-) === Shely is now known as MJ086 === pedro is now known as pedro_ [13:21] Dear Ubuntu, today I won't be in to work today because I have 30cm of snow outside to enjoy. kthxbi :P [13:22] somerville32: Yay, you can get a head start on hug day :) [13:22] \o/ [13:22] I was thinking about going outside for once but I guess I'll do hug day instead :P [13:23] 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] Amaranth, I'll have a drink for you tomorrow than [13:24] Dear Unnamed Ubuntu Developers With The Day Off: [13:24] SCREW YOU. [13:24] JUST SCREW YOU. [13:24] * Amaranth passes the bottle to jdong [13:24] jdong: Everyone is entitled to their separate holidays. [13:24] Oh, that's illegal [13:24] * Amaranth takes it back [13:25] persia: yeah only if they're separate, but equal duration holidays ;-) [13:25] lol [13:25] * somerville32 is in a jolly mood today and decides to eat another poptart (strawberry) [13:25] jdong: I disagree (but I moved to the country with the most public holidays, so perhaps I'm biased) [13:25] lol [13:25] persia: hahaha [13:26] I wonder if I could convince work that OSS is a religion :P [13:27] "Umm yea, sorry, can't work today - hug day :P" [13:27] somerville32: just point them to some of Theo De Raadt's quotes. OSS is more than a religion. [13:27] :D [13:27] :D [13:27] "Blessed isth the man who is open sourced." [13:28] Ugh I need to stop staying up all night [13:28] Amaranth, Yea, today is the first day my sleep schedule normalized [13:29] It's just that I have a LUG meeting tonight that I'm going to sleep through at this rate [13:37] 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] 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] tkamppeter: right, I read that much on the ML; I was just curious about how well it works [13:37] Keybuk: eg start on runlevel 2 [13:38] Keybuk: will the job start before sysvinit scripts for 2, after or anytime during when those scripts are started [13:38] ? [13:38] 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] s/are started/are being started/ [13:40] 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] tkamppeter: I noticed that they are quick on replying, yes [13:41] tkamppeter: do they actually read all the Ubuntu bugs, or only those which we create an upstream task for? [13:41] 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] tkamppeter: ah, cool; yes, that's how it's supposed to work in LP [13:42] jdstrand: alongside [13:42] nice to see that it actually does :) [13:42] pitti: TheMuso will probably be your new best friend tomorrow. [13:42] * pitti hugs TheMuso [13:42] StevenK: ? [13:43] pitti: TheMuso is doing libglib1.2 NBS work [13:43] 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] 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] aah, right, we talked about htat this morning (and about scripting it) [13:43] Keybuk: so I can't depend on a certain order [13:43] * StevenK has grabbed the gsl NBS stuff [13:43] hi there :) [13:43] 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] 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] tkamppeter: awesome! [13:44] TheMuso: \o/ [13:44] Now. To get this shared rebuild script built, and get the two boxes building, and then bed. [13:44] s/built/written/ [13:45] pitti, so in the sense of Linux support HP printers are the most recommended to buy. [13:45] i have some problems with my PPA (related to missing .mo files in generated .deb) :) who could help me please ? :) [13:45] kervala: You might get help on #launchpad [13:46] Do PPAs run pkgbinarymangler? [13:46] * StevenK grumbles, only getting 23KB/s from archive.u.c [13:46] persia: I daresay they do [13:46] 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] persia> thanks, i will see there :) there are too many channels :p [13:46] 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] jdstrand: started rcS happens before starting rc2 due to the way those scripts work [13:47] Keybuk: ok, so 'start on runlevel 2' is kinda like a 00foo initscript [13:47] in terms of timing [13:48] Keybuk: ok thank you for the clarification [13:49] jdstrand: no [13:49] soren: I'm not convinced either [13:50] jdstrand: 00foo is run by rc, and has guaranteed ordering based on 01aa or 00aa [13:50] cjwatson: It makes sense that it should break the loop when either of the involved parties eof. [13:50] 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] cjwatson: ...the question is whether it will have any ill side effects. [13:50] it's supposed to break the loop when both of them are closed, not just one [13:50] 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] depending on your kernel, time sharing, etc. [13:50] cjwatson: Ok. [13:52] 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] cjwatson: Ok, so the loop gets progress from apt and sends it to debconf's frontend.. Is that right? [13:53] No, that doesn't smell right. [13:54] cjwatson: I get confused by the fact that we're checking DEBCONF_COMMAND_*READ* to see if it's *wrtiable*. [13:54] Keybuk: you said 'started rcS happens before starting rc2 due to the way those scripts work [13:55] 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] 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] cjwatson: Oh.. So there's two debconfish things involved. [13:57] Keybuk: or am I reading too much into your statement [13:57] ? [13:57] cjwatson: Er... I'll shut up now, and actually read the code. [13:57] yes, the apt process called by tasksel is configured such that packages it installs will start up an independent debconf 'passthrough' frontned [13:57] frontend [13:57] which means "send stuff to this fd please rather than starting up your own UI" [13:57] jdstrand: correct [13:58] cjwatson: Oh, ok. [13:58] jdstrand: all "start on started foo" guarantees is that foo has at least started before you are run [13:58] it does not guarantee that it hasn't since stopped again [13:59] Keybuk: is there a 'start before runlevel 2' directive? [13:59] Keybuk: or would that just be better served by using a 00.. initscript? [13:59] 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] Keybuk: yes [13:59] start on starting rc2 [13:59] (and make sure you don't use the word "service" or "respawn" in your job) [13:59] soren: the only fd being selected on is DEBCONF_COMMAND_READ [14:00] Keybuk: ok cool [14:00] (frankly, since you care about runlevels, I think you'll be better served by writing it as an ordinary init script) [14:00] cjwatson: When it's hanging? [14:00] soren: yeah [14:00] cjwatson: Yes, that sounds right. [14:00] cjwatson: apt seems to terminate just fine. [14:00] (determined by looking through the trace of d-a-p's startup) [14:01] ok, so why is the other end of that pipe not being closed? [14:01] 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] that shouldn't apply when it actually *exits* [14:02] anyway, meeting, will get back later [14:02] Keybuk: ok, now thank you for clarifying this for me :) [14:03] cjwatson: Sure. === mathiaz_ is now known as mathiaz [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] they do? [14:22] Hobbsee: I know they were dep-wait looping on hppa. or at least they seemed to be... [14:22] lamont: ahhh [14:22] I threw them in the cellar and stomped on them last night [14:22] hehe [14:23] I fat-fingered it though: nspr wound up at 199 instead of 100 with the rest === BenC__ is now known as BenC [14:24] 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). === cprov is now known as cprov-lunch === asac_ is now known as asac [14:37] 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] tkamppeter: ah, I bet I know why; you forgot to build with -sa, I reuploaded, and forgot to remove the .upload file [14:38] dholbach: do you know about dh_icons? [14:38] Riddell: what do you want to know? [14:38] tkamppeter: uploading again [14:38] 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] dholbach: we seem to have found a bug in it, and I'm curious why it hasn't affected others [14:39] dholbach: bug 173770 [14:39] Launchpad bug 173770 in kdelibs "kdelibs-data is un-uninstallable" [Undecided,New] https://launchpad.net/bugs/173770 [14:39] pitti, I have a rev1772 which is more complete, should I give you that one? [14:40] ogra: My head is spinning a bit, yes :) [14:40] tkamppeter: too late now, I already uploaded [14:41] 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] pitti: You mentioned in the bug libfakekey can be promoted, does that mean it has been or will be? [14:43] StevenK: 'can be', once we actually need it in main [14:43] Riddell: which part of the postrm is it that fails? [14:43] Riddell: one example I found on my machine: http://pastebin.ubuntu.com/2460/ [14:43] 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] pitti: Fair enough. I will work on some of the problems tomorrow === BenC__ is now known as BenC [14:43] pitti: No no, just curious [14:44] Adilson isn't even a MOTU [14:44] lool isn't a core-dev, though [14:46] dholbach: well the "update-icon-caches /usr/share/icons/crystalsvg" line [14:46] dholbach: your one looks quite different [14:47] Riddell: it seems they changed it in debian [14:47] I filed a bug report once to get the || true added [14:47] seems it got removed again [14:48] or update-icon-caches fixed to not fail at all [14:51] dholbach: do you know who's best to contact in debian to ask what's going on? [14:51] lool: Josselin does dh_icons, right? [14:51] 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] pitti, thanks for the upload, I have seen the bugs auto-closing now. [14:53] soren: I think I might see the problem [14:56] soren: oh, hmm, no [14:57] 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] ah, the joys of Debian and upstream accepting patches -- the sudo merge finally is a breeze now [14:57] that's what nocloexec does ...? [14:58] I expected it to unset FD_CLOEXEC? [14:58] Rather than set it. [14:58] oh, sorry [14:58] 14988 fcntl64(4, F_SETFD, FD_CLOEXEC) = 0 [14:58] 14988 fcntl64(4, F_GETFD) = 0x1 (flags FD_CLOEXEC) [14:58] 14988 fcntl64(4, F_SETFD, 0) = 0 [14:58] that's the sort of thing I see [14:58] the first SETFD is internal to perl [14:59] cjwatson: Oh, you're right. [14:59] 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] soren: apt-get probably explicitly closes its status fd, but doesn't close the reserved debconf passthrough fds. [14:59] 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] dholbach: I'm not sure; I think Joey Hess + Josselin did [15:00] 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] soren: or possibly even just $SIG{CHLD} = 'IGNORE'; [15:01] dholbach: But I don't want to touch this; they basically ignore my comments :-/ [15:01] though, well, we do care about the exit status, so not IGNORE [15:01] Riddell: ^ what lool said :-/ [15:02] soren: you need to be fairly careful when writing a SIGCHLD handler (or indeed any signal handler) in perl, though. [15:02] or in any language :-) [15:02] perlipc(1) may help [15:03] 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]