[02:01] <retro89> hellow
[04:07] <dholbach> good morning
[04:08] <StevenK> dholbach: It's what, 5am?
[04:08] <dholbach> StevenK: I didn't sleep very well, so I thought "why not get up and do some work?" - YAWN
[04:09] <Hobbsee> morning dholbach!
[04:09] <dholbach> hi Hobbsee
[04:11] <Hobbsee> wow.  since when does hppa only have 8 pending builds for intrepid?
[04:11] <StevenK> Hobbsee: Since the other 5,000 failed
[04:11] <Hobbsee> StevenK: ahh.  that'd do it.
[04:18] <TheMuso> oheh. If one sees an FTBFS mail, one can almost be 100% sure that it is hppa that has failed.
[04:19] <ajmitch> do you have spam filters to throw them away?
[04:25] <dholbach> james_w: congratulations!
[04:26]  * Darklock is still up, celebrating the fall of the CSU in bavaria :->
[04:50]  * Hobbsee beats dholbach with a herring
[04:50] <Hobbsee> dholbach: yes, 6 mails later, I understand that james_w is a MOTU!  :P
[05:04] <Darklock> Master Of The Universe?
[05:04] <Darklock> it is......
[06:38] <pitti> Good morning
[06:38] <wgrant> Hi pitti.
[06:41] <Hobbsee> pitti!
[06:41]  * Hobbsee waves the "we love pitti" flag around, and drapes it over pitti's shoulders
[06:43] <Hobbsee> (thanks to the we love pitti fanclub for the flag, which got borrowed)
[06:43]  * pitti blushes
[06:44] <pitti> BenC: I sub'ed you to bug 271956, I'd like to get your "still works" ack before uploading this; thanks in advance!
[06:47] <nxvl> heh
[06:47] <nxvl> i will bring a "we love pitti" flag to UDS
[06:47] <nxvl> :D
[06:49] <StevenK> pitti: So, wgrant and I found two things that aren't in NBS, and should be. lib{32,64}ffi4
[06:51] <wgrant> StevenK: Ah, thanks - I'd forgot about those!
[06:51] <pitti> StevenK: oh? libffi4 was NBS, and removed a while ago
[06:52] <StevenK> pitti: lib32ffi4 is still listed on amd64
[06:52] <StevenK> Filename: pool/universe/g/gcc-4.2/lib32ffi4_4.2.3-2ubuntu7_amd64.deb
[06:52] <pitti> $ asrc gcc-4.2|grep Binary.*ffi
[06:52] <pitti> $
[06:52] <wgrant> lib{32,64}ffi4 are very arch-specific, definitely NBS, but not in NBS.
[06:52] <pitti> sorry, asrc = apt-cache show-src
[06:53] <wgrant> Right.
[06:53] <wgrant> They're not built any more.
[06:53] <wgrant> Their source is long gone.
[06:53] <wgrant> They're still published.
[06:53] <wgrant> But they're not in the generated NBS lists.
[06:53] <StevenK> Built from gcc-4.2, which is currently 4.2.4-3ubuntu2
[06:54] <wgrant> http://launchpad.net/ubuntu/intrepid/amd64/lib32ffi4
[06:55] <wgrant> It could be because they're arch-specific, or because their source is published in another distroseries, or blah blah blah...
[06:55] <persia> I've seen this previously, which arch-specific stuff.  Is there maybe a way to tweak the NBS finder to find things like this?  The last I found was some leftover linux-meta stuff.
[06:56] <persia> s/which/with/
[06:56] <pitti> I'm not entirely sure how the NBS finder works
[06:56] <wgrant> Do we have the source?
[06:59] <pitti> wgrant: for the reverse depends checker yes, but the list of stale packages is created by a soyuz script, which isn't too useful without the corresponding database, etc.
[07:00] <wgrant> pitti: Ahh, so it is a Soyuz bug after all.
[08:37] <seb128> to whoever build retried gnome-python-extras that didn't work because pygtk is out of sync between arch all and any pacakges due to xvfb being broken
[08:39] <pitti> seb128: oh, indeed, I was going to ask you about pygtk
[08:39] <pitti> seb128: I sponsored that trivial fix for the example hashbang, and it FTBFSed all over the place
[08:39] <pitti> seb128: oh, first: bonjour!
[08:40] <pitti> seb128: some failed due to xvfb, amd64 failed due to "extension "RANDR" missing on display ":99.0""
[08:41] <RAOF> That's an awesome FTBFS error in so many ways :)
[08:41] <seb128> pitti: guten tag ;-)
[08:41] <pitti> seb128: so I could maybe try the workaround with the mesa build dep, too?
[08:41] <seb128> pitti: we could, would be nice if the xorg guys were fixing xvfb though
[08:41]  * directhex hands pitti cake
[08:48] <persia> I don't see a bug on that.  Does it need one?
[08:54] <pitti> persia: well, not really; we need to get the damn thing building; if that's tricky to do, we could use a bug as discussion place, of course
[08:54] <pitti> I'll set up an intrepid chroot somewhere; it locally built fine
[08:55] <persia> pitti: Makes sense.  I was thinking one against xvfb, as I was also looking at pygtk today.
[08:55] <pitti> oh, xvfb, indeed
[08:56] <seb128> pitti: just do the workaround for pygtk I would say
[08:56] <pitti> seb128: will that also help for the xrandr thing?
[08:57] <pitti> seb128: I can do a test build on i386, but I currently don't have an amd64 pbuilder at hand
[08:57] <seb128> pitti: that seems to be a random xvfb error, dunno about it but it might
[08:57] <slangasek> lool: ping
[08:57] <lool> slangasek: pong
[08:57] <seb128> pitti: other option is to comment the xvfb-run call in debian/rules, it's just to call the testsuite
[08:57] <lool> What did I break /again/
[08:58] <lool> :-P
[08:58] <seb128> pitti: or try the xvfb workaround on your ppa quickly?
[08:58] <pitti> seb128: hm, test suite iz good
[08:58] <pitti> seb128: oh, ppa, right!
[08:58] <seb128> pitti: ppa are great ;-)
[08:58] <lool> pitti: I'm not the RANDR stuff is a failure
[08:59] <slangasek> lool: :-)  I see that elisa-plugins-good recommends: gtreamer0.10-ffmpeg and gstreamer0.10-plugins-ugly, both of which are in universe; I think those need to be demoted to Suggests?
[08:59] <lool> slangasek: Good point; I'll demote them for Ubuntu
[08:59] <slangasek> lool: (I'm trying to track down why ffmpeg stuff is being wrongly pulled onto the livefs; elisa itself isn't to blame for this, but I might as well mention it :)
[09:00] <pitti> seb128: uploaded to my ppa, crossing fingers
[09:01] <lool> slangasek: Hmm which verison of elisa-plugins-good are you looking at?
[09:01] <slangasek> lool: 0.3.5-2; is that not current?
[09:01] <seb128> no, currents didn't build
[09:01] <lool> No, the current one doesn't build because a package needs promotion to main and the MIR is pending since 10 days
[09:01] <slangasek> ah
[09:01] <slangasek> oh, well then
[09:01] <slangasek> :)
[09:02] <lool> I have in my TODO "* Find out who's processing MIR and ping them"
[09:02] <StevenK> lool: ubuntu-mir ; pitti and doko
[09:02] <lool> But also "* write a MIR for python-cssutil"
[09:02] <lool> Of course the latter before the former  :-P
[09:26] <seb128> pitti: bah, the pygtk builds failed in your ppa too
[09:26] <pitti> ah, same problem
[09:32] <slangasek> pitti: dunno if you saw, I followed up to the console-kit-daemon crasher bug; the log certainly doesn't tell me anything, and the crashes are still happening
[09:33] <pitti> slangasek: ah, I hoped it would have a truncated log, or at least tell me at which precise point it crashes (when writing a session open or close log, or so)
[09:36] <lool> I reproduce the pygtk FTBFS in pbuilder
[09:36] <slangasek> pitti: did there end up being any problems with langpack generation (bug #273489)? You suggested during the meeting to follow up on #-devel, not sure whether that's happened yet
[09:36] <slytherin> seb128: sorry to bug you again, but do you plan to update gst-plugins-base to latest prerelease? This is regarding DVD playback blocked with resindvd plugin.
[09:37] <pitti> slangasek: I did followup with jtv; apparently the rosetta export crashes for ominous reasons, he is investigating
[09:37] <slangasek> ok
[09:38] <seb128> slytherin: not likely before beta now, no
[09:38] <lool> pitti: Re: python-dateutil MIR; there's an embedded storm copy in elisa which is the code which relies on python-dateutil
[09:38] <seb128> ups
[09:38] <lool> I don't know how easy it would be for storm to move to python-tz; I'll try to ask them, but it's unlikely that it happens in time for intrepid
[09:38] <seb128> somewhat I manage to close xchat-gnome tabs while switching workspaces sometimes
[09:39] <slytherin> seb128: Ok. So should I try backporting the fix form upstream cvs? I will do that sometime tonight.
[09:39] <seb128> slytherin: if you want to, I'll try to update the version after beta
[09:39] <lool> Ok, I think xvfb-run exits because it tries to kill Xvfb which already exited
[09:40] <lool> (the program is set -e and the kill clearly fails)
[09:40]  * slytherin looks through intrepid schedule
[09:50] <pitti> lool: so eliza actually uses the time zone db in python-dateutil?
[09:50] <pitti> lool: I guess it's much easier in the end to make p-dateutil use the system tzdata than trying to convert storm
[09:50] <lool> pitti: elisa uses storm which uses dateutil for db dates I guess
[09:51] <lool> pitti: Got the same comment on #storm that it'd be simpler to fix python-dateutil
[09:54] <shingara> there are no way to get list of all package with name of /package/version upstream/ubuntu version/ ?
[09:55] <shingara> apt-cache send me the full version, no separate upstream version and ubuntu version
[09:55]  * lool tries a pygtk build with -s -noreset
[09:59] <lool> Cool, pygtk actually liked that
[10:01] <lool> slangasek, pitti: could you please look at pygtk 2.13.0-0ubuntu5 waiting for approval?  It fixes a FTBFS similar as the one on the buildds for me (in pbuilder here though)
[10:01] <lool> (Well it wasn't processed yet I guess)
[10:03] <lool> seb128: I think I pushed a fixed pygtk
[10:03] <lool> seb128: Are other packages likely affected?
[10:03] <seb128> lool: the change you mentionned was one of the workaround listed on #ubuntu-x the other day
[10:04] <lool> Too bad I had to search for it then
[10:04] <lool> seb128: How come it wasn't applied?
[10:04] <seb128> lool: well, gnome-python-extras, I opted for the libgl1-mesa-dri build-depends which was supposed to workaround that too, let's see if it builds after pygtk
[10:04] <lool> It's not the same failure
[10:04] <seb128> ok so ignore my comment ;-)
[10:04] <mvo> shingara: there is a debian project for getting the upstream version based on debian/watch files
[10:05] <shingara> what project ?
[10:05] <broonie> ddpo
[10:06] <seb128> lool: thanks for fixing it, there is still a xvfb bug though?
[10:08] <wgrant> shingara: Everything before the last - in a version should be the upstream version, or close to it.
[10:09] <shingara> xserver-xorg-driver-all_1:7.3+10ubuntu10
[10:09] <shingara> and this package is the exception?
[10:09] <wgrant> There's no upstream version for that.
[10:09] <wgrant> It's a native metapackage.
[10:09] <lool> seb128: Well it's a Xvfb design issue
[10:09] <shingara> ah
[10:09] <lool> Rather xvfb-run
[10:10] <lool> seb128: xvfb-run <cmd> seems to assume only one client will connect, it seems
[10:10] <seb128> lool: which is not the case there?
[10:11] <seb128> lool: the issue you tracker was a different one indeed, the other one was a loop due to swrast_dri.so not being available
[10:11] <lool> seb128: I think I had to add bdeps to pygtk already to fix this IIRC
[10:11] <lool>   * Build-dep on xauth and xfonts-base as xvfb-run needs these and also bdep
[10:11] <lool>     on libgl1-mesa-dri for now until Xvfb can start without AIGLX support or
[10:11] <lool>     this dep is added to the package.
[10:11] <lool> pygtk 2.13.0-0ubuntu1
[10:12] <seb128> ah right
[10:12] <lool> seb128: I think what happens is that "make check" starts multiple individual commands (one per test) and each test connects and disconnects from the DISPLAY
[10:12] <seb128> that one is a xvfb bug then ;-)
[10:12] <lool> Well, it's made to run a "client" not a command starting multiple clients
[10:13] <lool> And the flag to not close after the first client is the one I added
[10:13] <lool> It might be that we were trying to run multiple tests but in fact were only running one!
[10:13] <seb128> lool: ok, so that was not what we discussed the other day, thanks for fixing this one ;-)
[10:13] <lool> I'm not too happy with xvfb-run in general, but here I think it's ok that we have to pass this special fla
[10:14] <lool> flag
[10:14] <seb128> right, it's just weird that things were working without that before
[10:14] <lool> Well TBH I'm not sure how they did
[10:15] <lool> Perhaps make check was completing really quickly because of the closed Xorg connection and kill had still something to kill
[10:15] <lool> No idea  :-/
[10:15] <seb128> lool: did you upload the fixed version to intrepid?
[10:16] <lool> Yes
[10:16] <seb128> thanks
[10:16] <lool> I pinged slangasek and pitti to unblock it
[10:17] <lool> I should have pushed to my ppa to make sure
[10:18] <seb128> the bug fix explanation makes sense and if you verified in pbuilder that should be good enough ;-)
[10:22] <pitti> lool: rock, thank you
[10:26] <lool> pitti: I think we should act on the python-dateutil situation one way or the other; it seems the only doable solution is to fix python-dateutil to use tzdata; I don't want to keep elisa non-buildable and non-installable further, so could you either demote elisa to universe or promote python-dateutil to main until we sort it out?
[10:27] <lool> I have no idea of the time budget to fix python-dateutil, but I have an idea of my time availability and I fear that nobody will step up before the intrepid release to fix it, so I prefer that we get at least some elisa testing, even if it's universe, or live with the tzdata copy in main
[10:29] <Adri2000> can I upload a main package directly to -proposed or should I wait for the ubuntu-sru ack?
[10:29] <cjwatson> it's held in -proposed until the bug is approved anyway ...
[10:30] <Adri2000> ok, I guess I can upload then
[10:32] <lool> james_w: Congrats
[10:32] <james_w> thanks lool
[10:33] <lool> seb128, pitti: pygtk failed ot build in ppa and ubuntu; it's a new error again
[10:33] <seb128> gra
[10:34] <pitti> bah, and all that just to fix an example script :/
[10:35] <lool> Now it's "Xvfb failed to start"; it does start with the same command-line in my pbuilder though
[10:35] <lool> xvfb-run -s -noreset /usr/bin/make -C build-2.5 check
[10:35] <lool> make[1]: Entering directory `/tmp/buildd/pygtk-2.13.0/build-2.5'
[10:35] <lool> ...
[10:35] <lool> xvfb-run -s -no-reset /usr/bin/make -C build-2.5 check
[10:35] <lool> Xvfb failed to start
[10:35] <lool> make: *** [build-2.5/build-stamp] Error 1
[10:35] <lool> dpkg-buildpackage: failure: debian/rules build gave error exit status 2
[10:36] <lool> (first is my pbuilder, second it buildd)
[10:36] <lool> Now it might need some love from someone using sbuild
[10:38] <slangasek> lool: so the pygtk in the queue shouldn't be accepted?
[10:38] <lool> slangasek: No use to, it will ftbfs
[10:38] <slangasek> :/
[10:38] <lool> Hmm I suspect XVFBARGS might get overwritten with -s
[10:39] <lool> Not sure how this affects Xvfb
[10:39] <lool> Anyone could do a test build in sbuild?  Or should I throw at my ppa?
[10:39] <lool> I'd like to change '-s -no-reset' to '-s "-no-reset -screen 0 640x480x8"'
[10:40] <seb128> lool: ppa will be faster to try
[10:40] <jcristau> lool: i'd be surprised if that was the problem
[10:40] <lool> jcristau: Any idea what it could be?
[10:41] <lool> GRAH
[10:41] <lool> I typoed the one I uploaded
[10:41] <lool> to my ppa
[10:41] <jcristau> lool: i'm tempted to change the default ERRORFILE in xvfb-run...
[10:42] <seb128> oh, yeah, there is an extra "-"
[10:42] <lool> yeah
[10:42] <pitti> lool: accepted pygtk, let's cross fingers
[10:43] <lool> jcristau: Wow this would certainly help debugging indeed!
[10:48] <pitti> lool: looking into -dateutil now
[10:58] <lool> Status: Successfully built
[10:58] <lool> woohoo
[10:58] <lool> So the typo in my ppa upload was the only issue, sorry for the confusion
[10:58] <lool> jcristau: And sorry for bothering :)
[10:59] <lool> The second ppa upload with the proper flag name built fine
[10:59] <pitti> lool: I think I fixed -dateutil
[10:59] <lool> pitti: woah
[10:59] <lool> pitti: Well thanks
[11:00] <lool> pitti: So I do owe you some beverage
[11:00] <pitti> lool: at least I broke the test suite after removing the tarball, and it runs fine again with my fix
[11:01] <xyz> could someone have a look at bug 231407
[11:01] <xyz> it's still present in intrepid beta
[11:01] <xyz> no sound for VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller
[11:02] <lool> jcristau: I kind of wonder whether this kill isn't racy in all cases: here we have multiple commands, so it's obvious why it might fail, but even for a single client, it's not impossible that Xvfb shuts down before the kill is reached
[11:02] <jcristau> lool: why would Xvfb exit?
[11:03] <lool> jcristau: When X client disconnects
[11:03] <jcristau> only if you pass -terminate
[11:04] <lool> jcristau: I thought this was the default; I'm puzzled as to why -noreset helps if -terminate isn't the default
[11:05] <lool> jcristau: Aha, the default is -reset
[11:06] <jcristau> the default is to regen (shut down clients and screens, and re-init everything)
[11:06] <lool> jcristau: I suspect the server restarts between commands
[11:06] <lool> Hmm is this a good default
[11:07] <lool> jcristau: Heh the xprint backend has dispatchExceptionAtReset = 0
[11:08] <lool> Since 2006; don't know how to check earlier history
[11:11] <lool> jcristau: https://bugs.freedesktop.org/show_bug.cgi?id=764 seems to be related to Xprt
[11:11] <lool> dd831c7a5c1b0c540a78350aadaeb34a8aa67395 in changelog
[11:12] <lool> The rationale for xprint is slowness, and the fact that resources need to be configured again
[11:13]  * jcristau pretends Xprt doesn't exist
[11:14] <lool> Xpfrt!
[11:16] <lool> jcristau: I can't come up with an use case of xvfb-run where one wants to reset the server for multiple clients though: the script inherently suggests you're running a single command to do some stuff
[11:16] <lool> So even if the Xvfb default has some rationale behind it, xvfb-run could pass -noreset by default I think
[11:36] <pitti> mvo: oh, you dropped the "remove landscape-client stub" update-manager code? IMHO this should still be present, we only install landscape-common by default
[11:36] <pitti> mvo: maybe you can drop that change from 1:0.93.18 and reupload (same version number is ok)? I'll accept it afterwards, so that we'll get hte xorg driver transition in time for beta
[11:37] <mvo> pitti: thanks, I can fix this after lunch
[11:37] <mvo> sorry, there seems to have been some confusion about the right handling of this
[11:37] <pitti> mvo: right, there was; this is the current approach now (isntall -common by default, but not -client)
[11:37] <pitti> mvo: I rejected the current upload; please ping me after you uploaded the new version, for immediate processing; thanks! *hug*
[11:38] <StevenK> pitti: Can you have a look at linux-lpia?
[11:38] <StevenK> pitti: It is mainly so we can switch back to aufs
[11:39] <pitti> StevenK: accepted, doesn't really affect ubuntu desktops
[11:41] <StevenK> pitti: Thanks
[11:46]  * persia tries harder to make the lpia alternate CD work for installing ubuntu desktops
[11:47] <persia> ls
[11:47] <ogra>  /
[12:07] <whyking> hi
[12:15] <whyking> a package wants to install a dependency which has been renamed (libgsl0 became libgsl0ldbl), how could I fix that in the best way?
[12:16] <whyking> create an alias for that package?
[12:16] <Mithrandir> rebuild the package with the old dependenc.
[12:16] <Mithrandir> +y
[12:17] <whyking> Mithrandir, how can I rebuild that package?
[12:17] <whyking> and where should I get the old dependency?
[12:17] <whyking> or maybe, is there a way to ignore that dependency? because it is already installed
[12:17] <persia> whyking: You don't need the old dependency: rebuilding should pull the new dependency.
[12:18] <Mithrandir> hmm?  You have package foo that depends on libgsl0.  So you download the source, rebuild it using dpkg-buildpackage and install using dpkg.
[12:20] <whyking> can't I just tell apt-get to ignore the broken dep?
[12:20] <whyking> sth like --ignore-missing
[12:20] <Mithrandir> because you don't have it installed?
[12:21] <whyking> Mithrandir, I have
[12:21] <whyking> everything is in place.. but he wants to install the old dependency.. the new one is installed
[12:21] <Mithrandir> no, you don't.  libgsl0ldbl and libgsl0 are two distinct libraries.
[12:22] <whyking> Mithrandir, are they? so why was libgsl0 deleted?
[12:22] <Mithrandir> because it was superseded by libgsl0ldbl
[12:22] <Mithrandir> but they are not completely compatible.
[12:22] <Mithrandir> so you need to rebuild any applications depending on libgsl0
[12:22] <whyking> ok, but it should work nonetheless then
[12:22] <whyking> mhh
[12:23] <whyking> I'd rather not :-/ its a huge source
[12:23] <whyking> no other way?
[12:24] <persia> whyking: Rebuild anything depending on libgsl0ldbl with libgsl0, but that's the reverse of what everyone else will be doing.
[12:24] <whyking> persia, alright.. I guess I'll have to wait for upstream to fix it then
[12:24] <whyking> thanks
[12:38] <slangasek> apachelogger: why is libksquirrel marked i386-only?
[12:47] <geser> slangasek: should packages in main have a -dbg or -dbgsym package or is it only nice to have?
[12:48] <slangasek> geser: -dbgsym packages are autogenerated; -dbg packages get in the way of this more than anything, so I wouldn't call them nice to have at all
[12:48] <siretart> slangasek: they 'get in the way'?
[12:48] <geser> slangasek: libselinux has neither, and I wonder if it's important or only a wishlist bug
[12:49] <slangasek> siretart: some packages are known to do things in the creation of their -dbg packages which breaks the -dbgsym extraction
[12:49] <persia> slangasek: What about cases where -dbgsym autogeneration fails?
[12:49] <soren> slangasek: From http://revu.ubuntuwire.com/details.py?package=libksquirrel: - Only build on i386 for now, have to talk to upstream about fixing amd64 build.
[12:49] <cjwatson> -dbg is only useful if the package needs a second pass to build useful debugging
[12:49] <cjwatson> if it doesn't, then a request for -dbg is neither important not wishlist, it's invalid
[12:49] <cjwatson> (or wontfix I suppose)
[12:49] <cjwatson> s/not/nor/
[12:49] <cjwatson> if -dbgsym autogeneration fails, it should probably be fixed :-) ask pitti
[12:50]  * siretart wonders if he should make ffmpeg and xine stop building -dbg package in ubuntu
[12:50] <cjwatson> there's no need to introduce diffs to stop building -dbg packages
[12:50] <slangasek> make them stop building -dbg packages in Debian :P
[12:50] <cjwatson> contrariwise, there's no need to put any effort into building them either
[12:50] <geser> the problem is libselinux doesn't use debhelper so dh_strip isn't used and the trigger to build the -dbgsym doesn't get called
[12:50] <slangasek> geser: ah, yes, heh
[12:50] <cjwatson> exceptions are things like python modules which need a second pass
[12:51] <cjwatson> it would be straightforward to call the dbgsym extractor, wouldn't it?
[12:51] <siretart> slangasek: I could, but I've found them rather useful. espc. for non-maintstream architectures.
[12:51] <siretart> 'mainstream', even.
[12:51] <geser> it should be possible, if such change is deemed worth it
[12:52] <cjwatson> it should be no harder than creating a separate -dbg package, and produces better results
[12:52] <siretart> slangasek: are there guidelines in debian when and when not to provide -dbg packages?
[12:52] <slangasek> siretart: no, unfortunately
[12:53] <siretart> :(
[12:53] <slangasek> so we have awesomeness like -dbg packages for firewall tools
[12:53] <slangasek> soren: hmm, and the revu page doesn't show the reason for the build failure... but ok, thanks
[13:06] <pitti> re
[13:07] <pitti> what's up wrt. -dbgsym breakage?
[13:07] <pitti> seb128: looking into the camera bug now
[13:07] <seb128> pitti: thanks
[13:08] <seb128> pitti: what dbgsym breakage?
[13:08] <pitti> discussed half an hour ago here, between slangasek, siretart, and cjwatson
[13:08] <geser> pitti: not a breakage, but only a question how important it is if a package in main has no -dbgsym (or -dbg) package
[13:08] <geser> pitti: see bug 275082
[13:08] <pitti> geser: oh; well, if it's a package which gets a lot of crash reports, we should fix it; otherwise I wouldn't waste too much time on it
[13:09] <cjwatson> pitti: turns out it's a package that doesn't use debhelper. I guess it's fairly easy to call the helper by hand too
[13:09] <slangasek> seb128: hi, do you have any idea about the gstreamer0.10 build failure?
[13:09] <siretart> pitti: does ffmpeg/xine-lib break the apport retracer by providing -dbg packages? both are using debhelper
[13:09] <seb128> slangasek: oh, no, I wanted to ask lool or slomo about those
[13:10] <pitti> yes, it is: pkg_create_dbgsym debian/foo
[13:10] <pitti> siretart: ATM the retracer doesn't consider -dbg packages
[13:11] <pitti> lool, seb128: yay, pygtk built everywhere
[13:11] <siretart> pitti: that didn't answer my question ;)
[13:12] <pitti> siretart: ok, then; to literally answer your question: "no" :)
[13:12] <siretart> excellent :)
[13:13] <siretart> seb128: did you hear any news from the TB regarding my inquiry about ffmpeg?
[13:13] <pitti> siretart: "break" in the sense of "non-symbolic result if no -dbgsym is available": yes, "-dbg are merely available/present" -> no
[13:13] <seb128> siretart: no
[13:13] <siretart> seb128: FYI, an updated ffmpeg package is currently in debian NEW
[13:13] <siretart> pitti: okay, that means users have to retrace themselves. okay
[13:15] <slangasek> lool, slomo: ping?  Do you know what's up with the gstreamer.10 ftbfs?: http://launchpadlibrarian.net/17880819/buildlog_ubuntu-intrepid-i386.gstreamer0.10_0.10.20.2-1_FAILEDTOBUILD.txt.gz
[13:24] <geser> pitti: have you some time to help me on the fdi file for some smart card readers?
[13:25] <pitti> geser: oh, sure; what's the issue?
[13:25] <slangasek> pitti: do you think that the fdi file in 267682 is a right solution, and ready fo upload?
[13:26] <pitti> slangasek: I think it's a reasonable workaround for intrepid, yes; it's not a long-term correct solution (we should clean up that entire mess in jaunty)
[13:27] <pitti> slangasek: it was tested by a couple of thinkpad users now AFAICS
[13:27] <slangasek> pitti: ok.  Can you prepare the upload to add the fdi file to wherever is the appropriate place, or should I ask someone else about this?
[13:28] <pitti> slangasek: I think the most correct place would be the -evdev driver, wrt. correct behaviour of backported packages (i. e. we should not ship it in hal)
[13:28] <geser> inspired by kirkland's work I started to write a similar file to grant access to smart card readers. I got it nearly working. I'm currently stuck at the point that it only works if I hardcode the device file name into the fdi file.
[13:28] <pitti> slangasek: yes, I can prepare the upload
[13:28] <slangasek> pitti: ok, thanks
[13:28] <geser> see http://paste.ubuntu.com/50012/ for my current fdi and policy file and the lshal output for the smart card reader
[13:28] <pitti> geser: you mean access to the raw device?
[13:29] <pitti> geser: do you know that a while ago StevenK already prepared this for all removable block devices?
[13:29] <geser> pitti: to e.g. /dev/bus/usb/001/002
[13:30] <geser> pitti: it's to finally close bug 57755 which got stuck as it used a new group (scard) for it in the udev rules
[13:31] <pitti> geser: oh, right, I misunderstood what you meant with smartcards, nevermind
[13:31] <geser> pitti: does it matter that the smart card reader appears as a character device and not as a block device?
[13:32] <pitti> geser: yes, it does; I mixed it up with "SD card"
[13:33] <geser> I mean those to read a OpenGPG card
[13:33] <pitti> geser: right, I know now
[13:34] <pitti> geser: so, the tricky bit is to find out that a particular device is in fact an sd card reader
[13:35] <geser> would it be possible to use the product id and vendor id? like in the proposed udev rules from that bug
[13:35] <mdz> asac: one-liner patch for you in ~mdz/network-manager/ubuntu.0.7/
[13:37] <pitti> geser: yes, that's always a possibility, if there's a reasonably small list
[13:37] <pitti> geser: some devices have a particular device or interface class, but if that's not the case, there's no other way than to use vendor/product ID lists
[13:37] <mvo> pitti: update-manager uploaded
[13:39] <pitti> geser: btw, hal supports int_outof="0x001;0x002;0x003", that makes the rules shorter to write
[13:39] <geser> pitti: currently it's only a small list, 2 or 3 devices from SCM which gpg supports natively
[13:40] <geser> so the user needs access to the device file
[13:40] <pitti> mvo: and accepted, thanks
[13:40] <pitti> geser: if the list gets longer, the fdi should probably be autogenerated during build, but for now, a static one seems ok to me
[13:41] <pitti> geser: allow_inactive should be false, though, otherwise several user sessions race for grabbing the device
[13:41] <seb128> Hobbsee: bouh
[13:42] <pitti> geser: otherwise your paste looks quite good to me
[13:42] <Hobbsee> seb128: i'm sorry?
[13:42] <Hobbsee> seb128: (oh, and re: the last ping, i figured it out, thanks)
[13:42] <seb128> Hobbsee: nice to mail about not testing uploads to upload an anjuta which can't built
[13:42] <Hobbsee> seb128: yeah, well.
[13:43] <geser> pitti: do you have an idea why it only works if I hardcode the device file into the fdi?
[13:43] <seb128> Hobbsee: we need the new anjuta version, huat is working on it
[13:43] <geser> if I use the copy-property line I get no acl for it
[13:43] <Hobbsee> seb128: at least i found about it pretty quickly.  And i'm not sure why no one in debian's reported the same problem yet.
[13:43] <Hobbsee> seb128: yes, so he said.
[13:44] <seb128> Hobbsee: anjuta 2.24 has been uploaded to debian
[13:44] <Hobbsee> seb128: yes, it has, and there's a grave bug about it.
[13:45] <Hobbsee> seb128: however, it's not passed to unstable yet, and i'm surprised that the unstable version hasn't been rebuilt at all - given that it should be uninstallable by now?
[13:45] <Riddell> mvo: could the upgrader be set to purge kdm-kde4 ?
[13:45] <pitti> geser: why do you copy it from the device's parent, and not from the device itself?
[13:45] <seb128> Hobbsee: I can't parse that
[13:45] <pitti> geser: the device you pasted already has linux.device_file, which seems to be the correct one?
[13:46] <geser> pitti: good question, I tried looking at how the other files do it
[13:46] <pitti> geser: drop the @info.parent:
[13:46] <seb128> Hobbsee: I'll fix anjuta, I'm talking regularly to huat about it for some days now
[13:47] <geser> pitti: still no acls (I've restarted hal and also issued a ck-launch-session)
[13:48] <Hobbsee> seb128: cool.  I've seen some action on the bug.
[13:48] <Hobbsee> oh, interesting.  according to debian packages, libgdl-gnome-1-0 still exists - but an old version.
[13:49] <slangasek> it's uninstallable and NBS
[13:49]  * slangasek sharpens the axe while he waits for python-gnome2-extras to build
[13:50] <seb128> Hobbsee: right, nbs is not cleaned if there is still some packages depending on the binaries
[13:50] <geser> pitti: is /usr/share/hal/fdi/policy/10osvendor/ the correct location for my fdi file?
[13:50] <Hobbsee> seb128: in debian, it appears.  It's gone in ubuntu, apparently.
[13:51] <seb128> slangasek: I kicked the builds after pygtk built, now you might want to ask pitti to score higher those
[13:51] <pitti> prio bumped to 5000
[13:51] <seb128> pitti: danke
[13:51]  * Hobbsee want's pitti's version of buildd.py.
[13:51] <pitti> geser: yes, looks good
[13:52] <asac> mdz: committed (rev2902) thx
[13:52] <pitti> Hobbsee: hm, you are right; it doesn't actually *work*
[13:52] <Hobbsee> pitti: good.  so i'm not going mad!
[13:54]  * Hobbsee sighs at seb.  I get build failure mails for a reason.
[13:54] <Hobbsee> Install failures, however....
[13:54] <Hobbsee> ah well.
[13:59] <mdz> pitti: I was looking at network-manager crashes, and noticed there were several which have been retraced but are still marked private.  is it a manual process to make them public after retracing?
[14:00] <pitti> mdz: yes, it is; until someone inspected them, we cannot guarantee that there are no sensitive information in the stack trace; also, we just generally keep them private, in order to not clutter the bug mail recipients so much
[14:00] <pitti> slangasek: I applied it in hal in the end; rationale in bug updated, and uploaded
[14:01] <slangasek> pitti: great, thanks
[14:01] <pitti> slangasek: want to review, or shall I ack myself?
[14:02] <mvo> Riddell: sure, purge, not remove? I put that into bzr
[14:03] <slangasek> pitti: having already tested the fdi file and trusting that you know better than I where it needs to go in the package, I'm ok with you acking yourself if you don't think you need another pair of eyes
[14:03] <pitti> slangasek: I'm reasonably sure, but best would be to test it again with the actual .deb from the repos
[14:03] <pitti> (I don't have a thinkpad here)
[14:04]  * slangasek nods
[14:05] <james_w> hey ema
[14:06] <ema> hey james_w
[14:06] <ema> james_w: congrats for becoming a MOTU :)
[14:06] <james_w> thanks ema. How are you?
[14:07] <ema> I'm fine, but very busy with work any uni unfortunately
[14:07] <geser> pitti: found the problem: it's "copy_property" and not "copy-property" and I had to use @info.parent:linux.device_file
[14:08] <geser> pitti: it works now :)
[14:08] <pitti> geser: still curious, since the hal device you pasted had both the vendor/product IDs and the device file; but if it's conceptually correct to use the parent's, sure
[14:09] <geser> pitti: the next question would be, which is the best package to include the fdi (and policy) file as both gnupg and gnupg2 can use it (perhaps also libccid)
[14:10] <pitti> geser: is there a smartcard library which both use/
[14:10] <pitti> ?
[14:11] <geser> pitti: no, both gnupg and gnupg2 support it natively, they don't need any special lib for it
[14:11] <pitti> geser: I guess then we should put it in hal; it has become the dumping ground for all sorts of stuff already, but *shrug*
[14:12] <pitti> geser: it should be integrated into the existing device access fdi/policy then, maybe upstream will even tak eit
[14:12] <pitti> take it
[14:13] <geser> pitti: I'll prepare then a debdiff and let you know for review
[14:14] <pitti> geser: cool, thanks (NB that I just uploaded a hal, thus bzr is newer than apt-get source)
[14:15] <seb128> re
[14:15] <seb128> lool: so gnome-python-extras fails the same way than pygtk now
[14:15] <pitti> wb seb128
[14:27] <soneca> helo folks, i am working on Pidgin. There is an issue on Blocked users. Even when the contact is blocked, he also can send messages to user, and vice-versa. So, i want to help the team, making a patch to this issue, in libpurple and pidgin. Anyone else is working with this?
[14:29] <stefanlsd> soneca: is it an ubuntu specific problem, or rather a problem with pidgin?
[14:29] <TheMuso> cjwatson: I had a look at the Ubuntustudio seeds today, following the steps for tasksel that you outlined last Friday, and got no errors at all. This was on intrepid, with intrepid's version of bzr.
[14:29] <soneca> it's a pidgin problem. Sorry post in this channel
[14:30] <soneca> I've posted on pidgin channel now
[14:30] <stefanlsd> soneca: your best bet will be to work with upstream.  Try #pidgin  :)
[14:31] <soneca> thanks, it's an control-V issue. Copied from other channel and pasted in the wrong place ;)
[14:38] <lool> seb128: Hmm ok, we don't have the xvfb-run call in pkg-gnome so I didn't find it
[14:38] <seb128> lool: right, we didn't sync this one for a while
[14:38] <lool> seb128: Would have been nice to send that part to Debian
[14:38] <lool> It's there since sep 2007
[14:40] <Riddell> mvo: actually I'm not sure about that purge, it shares file with kdm in intrepid which we don't want removed
[14:40] <lool> dpatch...
[14:42] <seb128> lool: yes, we didn't sync this cycle because the package has been splitted in debian and has dbg variants in ubuntu and the sync is not trivial and I've been too busy to do it and nobody else picked on the job
[14:43] <lool> I pushed a similar fix (adding -noreset Xvfb flag) for gnome-python-extra to my ppa and intrepid
[14:43] <seb128> lool: thanks!
[14:44] <pitti> tedg1: good morning
[14:45] <ogra> seb128, do you know if there is a way to preseed timed-login from d-i for gdm ? (i know there is for autologin, but that doesnt help if a user logs out)
[14:45] <seb128> no clue
[14:45] <pitti> seb128: so, do you agree about the "do nothing" approach for bug 274146? I don't see any correct approach to that
[14:46] <seb128> pitti: I'm not happy about that but I prefer to not do anything than to do something broken
[14:46] <pitti> seb128: me too
[14:47] <tedg1> Morning pitti
[14:47] <pitti> seb128: ok, then AFAICS desktop team is down to bug 274140 (tedg1), bug 258083 (me), and bug 274085 (unassigned); do you see anything else critical for beta?
[14:47] <seb128> pitti: Scott opened the bug, let's stay on the "do nothing" for now and wait for him to comment if he disagrees
[14:48] <pitti> tedg1: how is that going, btw? (fusa suspend/resume), need any help?
[14:48] <pitti> tedg1: we need to get the fixes in today in order to get the release out in time
[14:48] <seb128> Hobbsee: replying here to you gdl question, that's an upstream change
[14:49] <seb128> Hobbsee: and why I synced the new version, because that's a GNOME 2.24 tarball
[14:49] <seb128> Hobbsee: what is still using it in intrepid?
[14:49] <mterry> superm1, persia: I attached a debdiff to bug 269540 to fix the issue with the BT wizard in bluez-gnome 0.28
[14:50] <tedg1> pitti: In testing.  Is there a particular time you need them?
[14:50] <persia> mterry: Does it work with keyboards on intrepid?
[14:50] <pitti> tedg1: ah, good to hear; no, just "today" would be good
[14:50] <mvo> Riddell: hm, ok. let me know when you have decided what to do with it
[14:51] <mterry> persia: I don't have a keyboard to test.  But what I remember you saying is that they were broken in 0.25 anyway?  This wouldn't fix that
[14:51] <Hobbsee> seb128: it *was* anjuta, but that became uninstallable, as the binary was pulled.
[14:51] <persia> mterry: Oh well.  Thanks for that.  If we don't move to 4.x, it's probably worth applying.
[14:51] <seb128> Hobbsee: yes, anjuta has to be uploaded to 2.24 too, but to update anjuta we had to upload gdl first because anjuta 2.24 depends on the new gdl
[14:51] <Hobbsee> seb128: i can understand that the new version got synced, but i would have expected the old version of the obsolete binary to stay, and not automatically vanish, but show up on the NBS lists?
[14:51] <tedg1> pitti: Okay, I'll finish catching up on e-mail from the weekend then :)
[14:53] <seb128> Hobbsee: the lib didn't vanish, it's just not installable because it doesn't match the libgdl-1-common current version
[14:53] <Hobbsee> seb128: ah.  I must have misread it, in the general churn of trying to make things installable again.  My error.
[14:54] <seb128> no problem, sorry about the installability issue late in the cycle
[14:54] <Hobbsee> seb128: hopefully it'll be fixed soon :)
[14:54] <seb128> today for sure
[14:54] <cjwatson> TheMuso: did you use the current revision, or the one before I worked around the problem?
[15:01] <lool> seb128: gpe successfully built, can you accept?
[15:01] <lool> (in my ppa)
[15:01] <lool> https://edge.launchpad.net/~lool/+archive/+build/726045
[15:01] <seb128> pitti: can you?
[15:01] <seb128> pitti: gnome-python-extras in intrepid fixes the build correctly thanks to lool
[15:02] <pitti> seb128: can what?
[15:02] <seb128> lool: is you accent circonflexe broken too in intrepid?
[15:02] <seb128> pitti: accept -g-p-e
[15:02] <pitti> I already accepted g-p-e from unapproved
[15:02] <seb128> ah ok
[15:02] <seb128> thanks
[15:03] <lool> seb128: Rebooting to make sure, but it worked in xterm
[15:03] <lool> pitti: ty
[15:04] <Riddell> mvo: if it's going to remove files even though they now belong to kdm then it shouldn't br purged
[15:18] <amikrop> Can I tell distutils not to place my data_files in /usr/foo but in /etc/foo? The docs do not refer anything about it.
[15:19] <pitti> amikrop: just set the destination dir to an absolute path
[15:19] <amikrop> pitti: Alright, thank you. :-)
[15:20] <pitti> amikrop: 'share/foo' will land in prefix, '/etc/foo' will be absolute
[15:20] <amikrop> thanks ;)
[15:21] <Hobbsee> amikrop: any *particular* reason you stuck that in 2 channels, simultaneously?
[15:28] <lool> seb128: Yeah, ê is broken in gtk+
[15:28] <lool> not in xterm though
[15:34]  * ogra ands lool a ö ... just cut out the right side, make a connection between the dots and it *nearly* looks the same 
[15:34]  * Hobbsee hands ogra an h
[15:34] <ogra> heh
[15:34] <Hobbsee> :)
[15:35] <ogra> Hobbsee, i'm speaking to french people ... the h is builtin :P
[15:35]  * ogra hides
[15:35] <Hobbsee> ogra: riiiiight...
[15:41] <apachelogger> slangasek: FTBFS on anything but i386 IIRC
[15:43] <persia> apachelogger: even lpia?
[15:45] <apachelogger> persia: can't remember TBH, it isn't of much use without ksquirrel anyway
[15:45] <lool> ogra: Hans hat ein hohes Haus im Hamburger Haffen
[15:45] <lool> The h is for Germans
[15:45] <ogra> Ha Ha :)
[15:45] <lool> We have oi ou oï
[15:45] <mvo> lool: alter! du kennst hans :) ?
[15:46] <apachelogger> Oo
[15:46] <apachelogger> ...germans...
[15:46] <Koon> mvo: aptitude recommends libparse-debianchangelog-perl (which results now in a set of extra packages being included in standard seed). As far as I can tell it doesn't use it at all... am I missing something obvious ?
[15:47] <mvo> Koon: let me check
[15:47] <persia> apachelogger: OK.  I think I nearly have the alternate CDs working for lpia, and suspect that as more of the shiny little toys come out, it may be an interesting target for your stuff, although this is probably not a sane target for intrepid at this point.
[15:48] <mvo> Koon: it will use it for its internal changelog display widget to make version numbers more pretty, but it should work just fine without it
[15:49] <Koon> mvo: hm. then I missed where in the code it calls it :)
[15:49] <mvo> Koon: let me re-check, maybe it got removed again
[15:50] <Koon>  mvo: got it
[15:51] <Koon> mvo: calls "parsechangelog" without calling any perl. Sorry for thenoise
[15:51] <mvo> Koon: no problem
[15:51] <Koon> was fooled into thinking libparse-debianchangelog-perl would only contain perl modules :)
[15:51] <mvo> Koon: it should work without it afaics
[15:52] <mvo> Koon: :)
[15:52] <lool> mvo: Nah klar kenn ich him, und auch Fischer Fritz and seine frische Fische  :-P
[15:52] <mvo> lol
[15:53] <lool> seb128: So what's that ê regression ?  gtk+ with latin1 layouts again?
[15:53] <jcristau> lool: s/him/ihn/?
[15:53] <lool> geez
[15:53] <seb128> lool: no idea, it's not a multiple layout thing I've only an french one configured
[15:53] <lool> I just spoke to my german grandmother and I kept mixing english and german
[15:53] <lool> is hardz
[15:54] <lool> seb128: Me too
[15:54] <lool> seb128: But that's the closest thing which came to my mind
[15:55] <mrooney> is there a guide for making patches in the Ubuntu kosher way? I tried diff -crB but it isn't giving me something comparable to the original patch I was working with
[15:55] <apachelogger> persia: yes, since KDE is doing a lot of work towards MIDs, this might be a good target for jaunty(+1)
[15:56] <persia> apachelogger: I suspect you'll be able to get Kubuntu/lpia working for jaunty.  Whether you can get a kubuntu-mobile or kubuntu-mid flavour by then probably depends a lot more on upstream.
[15:56] <ogra> cjwatson, can i assume that if i simply add "buildlive ubuntu-mobile ;for-project ubuntu-mobile build-image-set" to the crontab on antimony it will just DTRT ? (assuming there is a recent livecd-rootfs that knows abotu ubuntu-mobile)
[15:56] <persia> Given device availability, I'd recommend chasing kubuntu-mobile before kubuntu-mid.
[15:57] <apachelogger> persia: I think all the core KDE packages already build on lpia, NCommander did quite some work in this direction.
[15:59] <persia> apachelogger: In that case, you might try to see if a kubuntu-lpia image works.  I'd recommend waiting for ubiquity 0.10.1, but I think that's the last piece you need.
[15:59] <ogra> cjwatson, oh, i see build-image-set nedds to be taught about it
[15:59] <apachelogger> persia: ok, thanks :)
[16:03] <cjwatson> ogra: check with StevenK, as he's been working on fixing that stuff up
[16:03] <geser> pitti: can you review and sponsor the hal debdiff in bug 57755?
[16:03] <pitti> geser: not before the beta release (unless you get slangasek's permission); can you please assign it to me?
[16:03] <ogra> cjwatson, well, i try to wrap my head around it first
[16:04] <ogra> (beyond the fact thats 1am for him)
[16:04] <StevenK> ogra: Nope, it won't
[16:05] <StevenK> cjwatson: There's a bug to remove multiseat -- it contains a udeb, is there anything I need worry about wrt d-i that uses it?
[16:05] <geser> pitti: assigned, it's not that important that it can't wait after beta release
[16:05] <ogra> StevenK, yeah, i see buildlive is the first thing needing to learn about ubuntu-mobile ... then build-image-set, then build-mobile and in the end build-mobile-img, did i miss something ?
[16:05] <geser> pitti: and thanks for your help with it
[16:06] <pitti> geser: thanks
[16:06] <StevenK> ogra: publish-mobile
[16:06] <ogra> yeah and purge ...
[16:06] <ogra> i wanted to get something building forst before publishng or purging :)
[16:07] <ogra> *first even
[16:09] <cjwatson> StevenK: multiseat> no
[16:29] <bdmurray> \sh: It looks like some stuff is still missing for bug 271550.
[16:30] <bdmurray> \sh: I think they are libqtgui4, libqtcore4 and libqt4-xml
[16:48] <sistpoty|work> pitti: Hobbsee already rejected gnome-iconedit ;) (and yes, it was deleted on the very same day where I later fixed it... .not some months ago ;)
[16:48] <Keybuk> ?! Sorry, the program "bzr" closed unexpectedly
[16:49] <Keybuk> damned right it was unexpected, I wasn't _running_ bzr!
[16:49] <YokoZar> I uploaded wine-gecko a while ago, and I forgot to mention that it needs to go into multiverse and not universe
[16:50] <pitti> Keybuk: but you should!
[16:50] <pitti> sistpoty|work: ah, ok
[16:51] <Keybuk> pitti: I don't normally run it while reading e-mail ;)
[16:52] <Nafallo> Keybuk: you don't have your mails in bzr? :-O
[16:52] <Keybuk> no
[16:55] <ScottK> Keybuk: Last week while I was offline you said something to me about changing a 3 year old bug from fix released to incomplete.  I've looked back over my bugmail and can't find anything that looks relevant.  If you still recall the issue and can point me at the bug, I'll be glad to have a look and clarify the situation.
[16:56] <Keybuk> I commented on it, maybe you hadn't subscribed?
[16:56] <Keybuk> I don't have the bug# to hand
[16:57] <ScottK> Perhaps.  I don't recall doing that, but I was totally offline for a week, so my brain pretty well purged that kind of stuff.  If you figure it out, let me know.
[16:58] <Keybuk> np
[17:00] <ion_> !away
[17:07] <cjwatson> cody-somerville: FYI I'm working on fixing up the Xubuntu powerpc CD building problem
[17:07] <cjwatson> better get it sorted before beta
[17:11] <cody-somerville> cjwatson, thank you
[17:23] <kees> doko, Keybuk: when doing an install of glibc from apt, I an error (this didn't happen when I installed it locally with dpkg)
[17:23] <kees> init:io.c:724: Assertion failed in nih_io_message_send: message != NULL
[17:25] <Keybuk> kees: it doesn't fail though, right?
[17:26] <kees> Keybuk: doesn't seem to, no.  and init is running afterwards... is this some "hey, reload" msg being sent to upstart?
[17:26] <Keybuk> yeah
[17:26] <Keybuk> which obviously has no reply, since upstart drops the connection to telinit ;)
[17:26] <kees> heh
[17:27] <kees> I can reproduce it every time with   sudo apt-get --reinstall install libc6
[17:27] <Keybuk> you can reproduce it with just "telinit u"
[17:27] <kees> yes
[17:27] <kees> ah, this is a recent change to upstart.  whew.  I couldn't even begin to imagine how my glibc patch would have caused it
[17:27] <Keybuk> well
[17:28] <Keybuk> it's a bug in glibc's postinst that after a security upgrade, it never restarted upstart
[17:28]  * kees nods
[17:28] <Keybuk> so upstart would still have the old libc open on the root filesystem
[17:28] <Keybuk> so you couldn't remount that ro
[17:28] <kees> "u" is reload?  (not in the manpage)
[17:28] <Keybuk> so I monkey-patched "init u" support in the quickest way I could to paper over that
[17:33] <kees> Keybuk: so upstart had been ignoring "u" before now?
[17:33] <Keybuk> kees: err, well, it wasn't implemented
[17:34] <Keybuk> it would have replied "unknown runlevel" or something
[17:36] <kees> ah-ha found it
[17:36] <kees> libc.postinst:(init u ; sleep 1)
[17:36] <kees> sleep 1.  very exacting.  ;)
[17:37] <Keybuk> heh
[17:37] <Keybuk> I like the way it's done in a sub-shell
[17:38] <kees> so, why didn't the "unknown runlevel" stderr show up prior to now?
[17:38] <Keybuk> no idea
[17:39] <Keybuk> actually, I may have been silently ignoring u
[17:39] <kees> yeah, looking at your patch, it seems so
[17:39] <Keybuk> i silently ignore anything I vaguely saw in a manpage but couldn't be bothered to implement at the time ;)
[17:39] <kees> heh
[17:39] <kees> so the fix is to exit(0) instead of break ?
[17:39] <Keybuk> yeah
[17:40] <Keybuk> "But that's a critical feature, you can't remove that!"
[17:40] <Keybuk> "How long have you been using Ubuntu?"
[17:40] <Keybuk> "Every release since warty!"
[17:40] <Keybuk> "So you haven't had that critical feature for the last two years, and you haven't noticed until I tell you? :p"
[17:41] <kees> heheh
[17:41] <sabdfl> apachelogger: yowser, good stuff on the 5-a-day front
[17:43] <kees> Keybuk: oooh, I'll bet this not-ro-/ bug is what kept corrupting my XFS root partitions so many moons ago
[17:43] <kees> (well, really that's an XFS bug, but this was triggering it)
[17:43] <Keybuk> no, that was just XFS
[17:43] <kees> heh
[17:43] <Keybuk> XFS likes to trash filesystems every now and then
[17:44] <sebner> sabdfl: but afaik he got rejected as core-dev O_o
[17:44] <Keybuk> it's like a dog weeing on the carpet
[17:44] <Keybuk> it's just letting you know it's still there
[17:44] <kees> Keybuk: btw, the "u" crash was filed as 275958
[17:45] <sebner> Keybuk: no we know how jaunty will boot faster ^^
[17:45] <Keybuk> sebner: I'm going to comment out the entire boot sequence
[17:45] <Keybuk> and only uncomment bits people complain about it
[17:45] <kees> Keybuk: okay, so you're uploading a fixed upstart for beta?
[17:45] <sebner> Keybuk: hrhr. bad boy :D
[17:46] <Keybuk> kees: it's not really beta freeze critical?
[17:46] <sabdfl> sebner: i'm sure just deferred, not denied :-)
[17:46] <Keybuk> it's a scary warning
[17:46] <sabdfl> crimsun: also, amazing work there
[17:46] <kees> Keybuk: I guess not, but it sure is alarming
[17:46] <Keybuk> kees: I could replace it with a less scary warning
[17:46] <Keybuk> "GLIBC DETECTED!"
[17:46] <sebner> sabdfl: hopefully. he just ROCKS :D
[17:47] <kees> Keybuk: "YOUR MACHINE HAS BEEN ERASED!  just kidding"
[17:47] <Keybuk> kees: I still want to write something that detects glibc, and outputs "*** glibc detected ***" to let you know
[17:48] <kees> hahaha
[17:48] <kees> make sure it writes it to /dev/tty instead of stderr so you have to dig through the source to figure out how to redirect it.
[17:48] <Keybuk> :)
[17:50] <ion_> Hehe
[18:21] <bddebian> lamont: ping? (about palo)
[18:22] <lamont> which freedom-hating aspect thereof?
[18:27] <pitti> tedg1: need to leave for Taekwondo; can you please ask one of the US folks for sponsoring the fusa fix?
[18:27] <pitti> tedg1: (seems seb128 is already out as well)
[18:28] <bddebian> lamont: Heh, just curious if you were going to fix it in Debian?  It appears you fixed in in Ubuntu? (BTS #464262)
[18:28] <tedg1> pitti: Yes.
[18:28] <apachelogger> sabdfl: hehe, doing my best ;-)
[18:29] <lamont> bddebian: I think someone fixed it in ubuntu
[18:29] <lamont> I've been ignoring it
[18:29] <lamont> the assertion was that it was broken glibc headers somewhere
[18:29] <bddebian> Oh, slangasek uploaded the fix in Ubuntu
[18:30] <sebner> apachelogger: hehe \o/
[18:30] <lamont> last time I mentioned it in the parisc channel, there were other ideas about fixing it, so I left it in their hands.
[18:30] <lamont> OTOH, dunno
[18:33] <apachelogger> sebner: btw, when do you apply for MOTU?
[18:34] <sebner> apachelogger: not in this month and not in the next one. why?
[18:36] <apachelogger> sebner: just wanted to know, I am currently at 698 unread mails, and KDE 4.1.2 packaging is still gonna take a while, so I will probably have one month of lag in reading mails ;-)
[18:37] <sebner> apachelogger: oh. didn't know that you really consider to comment. otherwise I'd let you know when I send the mail
[18:38] <apachelogger> sebner: commenting might be time consuming, but for you I consider taking the effort :P
[18:39]  * sebner feeds apachelogger with cookies :P
[18:39] <apachelogger> (:
[18:39] <sebner> apachelogger: so it only make sense if it's a postive comment :P
[18:39] <apachelogger> sebner: will be a short commen then :P
[18:39] <apachelogger> +t
[18:40] <geser> apachelogger: you're cheap :)
[18:40] <sebner> apachelogger: perfect. you save time and I have a postive comment :P
[18:40] <apachelogger> geser: :P
[18:41] <sebner> geser: I still have a secret weapon :D
[18:41]  * sebner gives apachelogger a captain :D
[18:42] <apachelogger> hm
[18:42] <apachelogger> sebner: KDE release packaging > captain
[18:43] <sebner> apachelogger: gnome > kde :P
[18:43] <sebner> apachelogger: and think of your poor padawans. R.I.P :P
[18:43] <apachelogger> sebner: mac > gnome :P
[18:43] <sebner> apachelogger: gnu > mac :P
[18:44]  * apachelogger mentions darwin and hides
[18:44]  * sebner slaps apachelogger with hurd :P
[18:47] <jdong> apachelogger: lol I've seen someone running more or less Darwin with GNU CLI stuff onboard
[18:48] <jdong> apachelogger: I guess just taking "think different" a step or 10 too far.
[18:48] <apachelogger> hehe
[18:48] <jdong> oh the things people go through to look cool.
[18:53] <ahasenack> does anybody know what causes this? http://pastebin.ubuntu.com/52169/
[18:53] <ahasenack> some post calling debconf again?
[18:54] <ahasenack> that's on intrepid, btw
[18:54] <ahasenack> (if it matters)
[18:57] <mvo> ahasenack: is that on your system?
[18:57] <mvo> ahasenack: or in a VM?
[18:57] <ahasenack> mvo: no, it was reported by somone in launchpad
[18:58] <ahasenack> mvo: https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/275615
[18:59] <mvo> ahasenack: aha, ok. I have seen reports with that as well, but I haven't had anything conclusive yet, it might be cause by someone running dpkg-reconfigure something (ee.g. console-setup) in another window
[18:59] <ahasenack> mvo: ok, I see
[19:00] <ahasenack> mvo: thanks!
[19:01] <infinity> mvo: Doesn't dpkg-reconfigure check the dpkg lockfile?
[19:01] <infinity> mvo: You'd think it would...
[19:01] <infinity> mvo: s/check/check, touch, and remove/
[19:02] <mvo> infinity: indeed, but it seems like it does not, dpkg-reconfigure console-setup (and leaving it) and then dpkg -i /tmp/foo.deb does work, just debconf does not
[19:03] <mvo> infinity: I guess that would be the bug then :)
[19:06] <infinity> mvo: Yeah, given that dpkg-reconfigure is executing maintainer scripts, it's effectively a dpkg-like process, so should definitely lock.
[19:07] <infinity> mvo: Of course, as soon as you change it to lock, you'll discover some (utterly broken, IMO) package that uses dpkg-reconfigure in it's own maintainer scripts. :P
[19:07] <infinity> mvo: (Hypothetical, but I'll give good odds that SOMEONE's done it)
[19:07] <mvo> infinity: heh :) let them burn!
[19:08] <cjwatson> infinity: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=469354
[19:10] <stgraber> Am I the only one with passwd behaving strangely ?
[19:11] <stgraber> When changing my password and not entering the same password twice, it tells me:
[19:11] <stgraber> Sorry, passwords do not match
[19:11] <stgraber> passwd: password updated successfully
[19:11] <stgraber> and returns 0
[19:12] <slangasek> stgraber: there's a bug on pam about that
[19:13] <slangasek> I need to look at it for intrepid, but not before beta
[19:13] <stgraber> ok
[19:14] <james_w> bug 272232
[19:29] <slytherin> any archive admin around?
[19:33] <infinity> slytherin: Several.
[19:34] <slytherin> can anyone please fix the bug #272866? I am waiting for it to work on rdepends and reverse-build-depends
[20:13] <tedg1> Can someone sponsor a couple of packages to main for me please?  In my PPA, gnome-power-manager_2.24.0-0ubuntu3 and fast-user-switch-applet_2.24.0-0ubuntu2.  http://launchpad.net/~ted-gould/+archive
[20:18] <bryce> tedg1: have you gotten a beta-freeze exception?
[20:18] <tedg1> bryce: Well one is a beta-freeze milestone thingy.  Is that an exception?
[20:19] <slytherin> tedg1: Why not add debdiff to the bugs that are fixed by these packages?
[20:20] <tedg1> slytherin: Because the person that would have to turn them into a package is me :)
[20:20] <slytherin> tedg1: I don't understand. You are asking for sponsorship. Do you expect people to take package form your PPA and sponsor it?
[20:21] <tedg1> slytherin: I thought they could copy it?
[20:21] <tedg1> Isn't that one of the new LP features?
[20:21] <slytherin> tedg1: Could or could not, that is not how it works.
[20:22] <slytherin> tedg1: You have to add debdiff to the bug. Then subscribe ubuntu-main-sponsors to the bug. Someone will take that debdiff, verify and then sponsor.
[20:27] <ogra> bryce, tjaalton, is there any way for me to not have to install the evtouch .fdi files into /etc/hal/fdi/policy ? if i put them into /usr/share/hal/fdi/policy/10osvendor they seem to be overwritten by mouse settings ... but it somehow feels wrong to put them into /etc
[20:30] <slangasek> tedg1: as far as ppa copying is concerned, I didn't think that was going to (initially?) be available to anyone but archive admins
[20:32] <bryce> tedg1: yeah if I were to sponsor a package from a ppa, I'd normally convert it into a debdiff
[20:32] <bryce> even with ppa copying, i'd still want to see the debdiff for review purposes
[20:33] <bryce> ogra, could it go into hal itself?  we've put a few fdi files into there so far
[20:33] <cody-somerville> Launchpad generates the diff automatically
[20:33] <ogra> bryce, upstream nearly flamed me when i asked ...
[20:34] <ogra> danny kukawa doesnt want driver specific fdi'd in hal
[20:34] <bryce> ogra, we've generally worked with pitti on these sorts of issues
[20:34] <ogra> *fdi's
[20:34] <ogra> well, you need the driver package installed anyway, so i dont think the attempt is to wrong
[20:34] <ogra> the only prob i have atm is the forced install location
[20:34] <slangasek> apachelogger: so I had to fix a cross-arch libksquirrel FTBFS, and along the way I've fixed the amd64 build failure too since that's what I have to hand as a dev env; I haven't changed the architecture: field, though
[20:35] <superm1> TheMuso, something I didn't see mentioned in that pulseaudio bug, check and see whether users were setting up automatic login and how that affects the pulseaudio daemon that gets spawned (since automatic login is easy to setup now in oem-config or ubiquity)
[20:35] <ogra> i'm not sure why they get ignored in /usr/share either
[20:35] <slangasek> lool, slomo_: gar, this gstreamer0.10 build failure is evil, it never fails if I run the command by hand :(
[20:36] <bryce> slangasek: friday seb128 mentioned an xvfb fbs issue, that I offered to look into today, yet I can't find a mention of it in launchpad.  Do you know more about what the issue is and where I could find an error log or bug report?
[20:36] <bryce> (I've been hoping seb128 would pop online but I guess he's done for the day)
[20:37] <bryce> I'm assuming it's something that gets triggered during a 'make test' kind of a thing in some package(s)
[20:37] <slangasek> bryce: last-but-one builds of pygtk or gnome-python-extras show the error; it has to do with xvfb -noreset or something, it was discussed extensively in scrollback here this morning (around 4am or so, IIRC)
[20:38] <slangasek> I don't know if it's still regarded as an Xvfb bug; the package builds are fixed
[20:40] <slangasek> tedg1: oh, bug #274681 fixed, awesome
[20:41] <tedg1> slangasek: Yes, except that the reason it was broken was entirely my fault :)
[20:41] <slangasek> sure, it's still awesome that it's fixed before I had a chance to report it :-)
[20:41] <bryce> slangasek: hrm, wonder if I should spend time investigating or not
[20:41] <slangasek> bryce: I vote "no" for now :)
[20:42] <bryce> wish someone had filed a bug on it so it'd be easier to tell
[20:43] <slangasek> bryce: the immediate issue was the build failure, which I understand has been fixed without having to drop the test suite out
[20:47] <bryce> slangasek: ok, looks like look did this to fix the build failure:
[20:47] <bryce> pygtk (2.13.0-0ubuntu5) intrepid; urgency=low
[20:47] <bryce>   * Pass no -s -no-reset to xvfb-run to prevent Xfvb from exiting when the
[20:47] <bryce>     last client disconnects and hence allow xvfb-run to kill it.
[20:47] <bryce>  -- Loic Minier <lool@dooz.org>  Mon, 29 Sep 2008 10:53:49 +0200
[20:53] <Edulix> hi
[20:53] <Edulix> I've noticed that NEtworkManager leaks memory in 8.04, is that fixed in 8.10 ?
[20:57] <bryce> slangasek: ok you're right.  It looks like the issue was that xvfb by design assumes a single client, and exits after that client exits.  According to lool's analysis, the pygtk testsuite was attempting to use a single xvfb instance with multiple clients (individual tests), which was causing the breakage.  Having to include the -no-reset flag appears to be a correct fix and not just a workaround
[21:11] <slangasek> calc: gstreamer0.10-plugins-good (+base, which it depends on) gives you all the codecs and formats that are supported by everything in main
[21:11] <slangasek> calc: if OOo users need something outside that set, well, there are Larger Reasons why we don't install them by default :/
[21:13] <slangasek> (and no, it's not just theora/vorbis - at least flac, qtdemux, speex are there)
[21:14] <slangasek> tedg1: fwiw, fusa can't do a source build after a binary build, it leaves generated .png files around
[21:14] <slangasek> (clean target should be fixed)
[21:15] <tedg1> slangasek: The uudecoded ones?
[21:15] <slangasek> yes
[21:15] <slangasek> they should be removed in clean
[21:19]  * tedg1 is a little curious what make is going to do with that.  Since they're a data tag, I'm curious if they'll be built to be deleted....
[21:22] <slangasek> if you mean automake 'DATA', it shouldn't
[21:23] <tedg1> Yeah, it doesn't cool.
[21:38] <kees> slangasek: should I upload a fix for 273761 before beta?
[21:40] <slangasek> kees: sorry, I'm on my way out the door so can't look that up right now; but it doesn't hurt to upload and have it sit in the queue, regardless
[21:41] <slangasek> (unless it hurts you to do the work, I guess :)
[21:42] <kees> slangasek: no, the fix is trivial. when discussing it with Keybuk earlier, it seemed like it wasn't important to fix (amd64 handles it more gracefully).  but it seems that i386 segv's triggering apport.  (38 dups in 6 days)
[21:42] <sbeattie> kees: you verified it addresses the issue for i386?
[21:42] <kees> sbeattie: waiting for the compile to finish, but it fixes it for amd64.  a few more moments...
[21:43] <kees> sbeattie: confirmed to fix it on i386.
[21:44] <kees> I have no idea where Keybuk keeps the actual _code_ for upstart's ubuntu branch, his bzr tree is packaging only and I can't commit to it.
[21:48] <sbeattie> kees: okay. So long as we're sure it won't get lost in a future upstart update.
[21:49] <kees> sbeattie: I don't think so.
[21:51] <kees> doko: I don't know why, but PPC glibc isn't building (it's failing in tests, and I'm pretty sure my change isn't the cause).  any idea?
[21:54] <doko> kees: which test?
[21:55] <kees> doko: I just retry'd the build.  none of the other archs fail.
[21:56] <kees> doko: http://launchpadlibrarian.net/18052012/buildlog_ubuntu-intrepid-powerpc.glibc_2.8~20080505-0ubuntu7_FAILEDTOBUILD.txt.gz
[21:56] <kees> GCONV_PATH=/build/buildd/glibc-2.8~20080505/build-tree/powerpc-libc/iconvdata LC_ALL=C   /build/buildd/glibc-2.8~20080505/build-tree/powerpc-libc/elf/ld.so.1 --library-path /build/buildd/glibc-2.8~20080505/build-tree/powerpc-libc:/build/buildd/glibc-2.8~20080505/build-tree/powerpc-libc/math:/build/buildd/glibc-2.8~20080505/build-tree/powerpc-libc/elf:/build/buildd/glibc-2.8~20080505/build-tree/powerpc-libc/dlfcn:/build/buildd/glibc-2.8~20080505/bu
[21:56] <kees> /bin/sh: Syntax error: Bad fd number
[21:56] <doko> I'll retry on the other buildd
[21:56] <kees> make[3]: *** [/build/buildd/glibc-2.8~20080505/build-tree/powerpc-libc/nptl/tst-cleanup0.out] Error 2
[21:56] <kees> ieee
[21:56] <kees> sorry, that was a much longer paste
[21:57] <kees> than I was expecting.  :)
[21:57] <kees> doko: how do you push it to another buildd?
[21:57] <doko> setting the other to manual
[21:57] <kees> heh
[21:57] <infinity> They both use the same chroot...
[21:57] <infinity> I see no way that something like FD breakage would change from one host to another.
[21:58] <doko> but today is Monday
[21:58] <kees> I'd seen this error the very first time I built glibc locally the ("Bad fd number") stuff, and suspected maybe I was running out of disk space.  I cleaned up, and it went away.
[21:58] <doko> hmm
[21:58] <infinity> Which host was the failure on?
[21:58] <kees> Builder:   ross (powerpc)
[22:01] <calc> slangasek: oh i don't disagree that it shouldn't be pulled in by default (i had forgotten about the recommends bit) just that only installing the good set won't be of too much use for cross platform office document viewing
[22:04] <ogra> cjwatson, i still end up with epiphany in the mobile build :/
[22:05] <ogra> so adding the task didnt really solve it it seems, unless my preseeding is wrong
[22:08] <sbeattie> kees: whoops, sorry for the bug editing collisions.
[22:08] <cjwatson> ogra: point me to the build logs?
[22:09] <ogra> not sure they are mirrored already
[22:10] <ogra> log/ubuntu-mobile/intrepid/daily-20080929.7.log
[22:10]  * ogra looks at people.u.c
[22:10] <cjwatson> I meant the livefs log
[22:10] <ogra> oh
[22:10] <ogra> indeed
[22:10] <cjwatson> http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/intrepid/ubuntu-mobile/latest/livecd-20080929.1-i386.out?
[22:11] <ogra> argh, my FF is broken
[22:11] <ogra> likely -2
[22:11] <ogra> if there is one
[22:13] <kees> sbeattie: no problemo :)
[22:14] <cjwatson> ogra: wouldn't you need http://paste.ubuntu.com/52238/ in order to actually use the task?
[22:14] <ogra> asac, http://people.ubuntu.com/~ogra/FF_no_button_text.png
[22:14] <ogra> cjwatson, oh, sigh, indeed, i forgot about that one
[22:15] <ogra> not for mid though, they dont want a task i was told
[22:15] <ogra> lool, ^^^
[22:15] <cjwatson> ogra: actually, make that http://paste.ubuntu.com/52239/
[22:16] <ogra> yeah
[22:16] <ogra> the preseed already has mobile-mobile
[22:17] <ogra> cjwatson, sorry for wasting your time :(
[22:17] <norsetto> asac: just uploaded new versions for gnome-mplayer/gecko-mediaplayer to mentors if you want to sponsor ...
[22:18] <cjwatson> ogra: it's ok
[22:18] <cjwatson> it took almost no time since I suspected that was the problem from the start :)
[22:18] <cjwatson> ogra: do you want that ubuntu-mobile crontab entry added to the live crontab?
[22:19] <slavik> any chance of evolution 2.26 in ibex?
[22:19] <ogra> cjwatson, i already added it, i suppose someone needs to activate it ?
[22:19] <cjwatson> hence "live crontab"
[22:20] <cjwatson> done
[22:20] <ogra> cjwatson, oh, well, the cdimage entry calls "buildlive ubuntu-mobile; for-project ubuntu-mobile build-image-set"
[22:21] <ogra> so i should drop the "buildlive ubuntu-mobile;" i suppose ?
[22:21] <cjwatson> ogra: what? not that sort of live
[22:21] <ogra> oh, k
[22:21] <cjwatson> ogra: editing the crontab requires running the crontab command to update it
[22:21] <ogra> ah
[22:21] <cjwatson> ogra: I've done it now
[22:21] <ogra> live as in actual :)
[22:21] <ogra> heh
[22:21] <asac> ogra: not properly restarted after upgrade?
[22:21] <ogra> i totally misunderstood ... we actually meant the same ... live confused me
[22:21] <ogra> asac, rebooted
[22:22] <asac> ogra: LANG? en-us?
[22:22] <ogra> de_DE
[22:22] <ogra> de_DE.UTF-8 actually
[22:28] <ogra> humm, cjwatson can you let the livecd-rootfs package through ? (and probably as well xf86-input-evtouch)
[22:30] <asac> ogra: maybe language changes something?
[22:30] <ogra> asac, let me try
[22:32] <ogra> asac, hmm, gone now
[22:32] <ogra> cant reproduce it
[22:32] <asac> ogra: yeah .. you didint properly restart :-P
[22:33] <ogra> well, i'd expect a reboot to be a proper restart :)
[22:33] <ogra> but well
[22:33] <ogra> all fine now
[22:33] <cjwatson> ogra: both done
[22:33] <ogra> gracias
[22:34] <ogra> i wonder if it makes it until 2:45UTC ...
[22:34] <asac> ogra: i agree ... if you see it again, let me know.
[22:34] <ogra> will do
[22:34] <seb128> slangasek: I've sponsored a gnome-build upload which fixes the previous screwed update we synced on debian, could you consider accepting before beta? only anjuta uses it and it's not installable right now due to the gdl changes, once this gnome-build is built we can sync anjuta 2.24 which fixes the installability issue
[22:35]  * ogra calls it a day
[22:36] <asac> ogra: enjoy
[22:50] <slavik> is openchange going to be in ibex?
[22:52] <asac> cjwatson: slangasek: i have uploaded latest NM with the wizard. its network-manager, -applet, -pptp, -vpnc and -openvpn. thanks.
[22:53] <slavik> cjwatson: does it honor the /etc/network/interfaces settings?
[22:54] <asac> slavik: you probably ask me?
[22:54] <slavik> bah ...
[22:54] <slavik> yes
[22:54] <lool> ogra: Sorry, don't quite get why you say mid doesn't want the task?  You mean the mobile one?  Or is this about the task headers?
[22:55] <asac> slavik: it honours them if you append the ,ifupdown plugin to the nm-system-settings.conf
[22:55] <slavik> ty
[22:55] <slavik> asac: will that be default?
[22:55] <asac> slavik: the fix for the /etc/network/interfaces bug will be fixed individually
[22:55] <slavik> there's a bug associated with that?
[22:56]  * slavik is not aware of anything
[22:56] <slavik> also, any idea of the best place to track the e1000e regression in the kernel?
[22:56] <asac> slavik: well, there is bug 256054
[22:58] <asac> slavik: look in the mailing list archives. i think there was mail that referred to a bug id
[22:58] <slavik> k
[22:58] <slavik> asac: any idea about the openchange mapi plugin for evolution?
[22:58] <asac> slavik: why do you have so many questions ;)
[22:58] <slavik> I know gnome 2.26 will have it ... but any chance 2.24 to have it?
[22:59] <slavik> asac: asking questions is what I do
[22:59] <asac> slavik: i am not the gnome maintainer ;)
[22:59] <asac> slavik: bug 263555
[22:59] <slavik> it's the best way to learn things (and to annoy people, too)
[23:00]  * norsetto calls it
[23:20] <TheMuso> cjwatson: Oh right, I'll have another look today then.
[23:20] <mathiaz> slangasek: openchange is already available in the intrepid archive.
[23:20] <mathiaz> slangasek: hm - sorry - not for you
[23:30] <superm1> TheMuso, the bzr tree for alsa-lib is missing your last few uploads.  don't forget to merge them back in
[23:31] <TheMuso> superm1: I am well aware of that.
[23:32] <superm1> TheMuso, okay wasn't sure, just a friendly reminder.  I was pushing a bzr branch out for merging and noticed i had more changelog entries than i should in my commit
[23:43] <MaximLevitsky> I suggest you add glipper to base install, bacause it is very awkward to deal with the disapperance of clipboard when you close an app
[23:44] <MaximLevitsky> Or at least something that does that
[23:55] <seb128> TheMuso: hi, could you look at http://bugzilla.gnome.org/show_bug.cgi?id=535827, basically at-spi has a schemas which is not installed in ubuntu
[23:55] <TheMuso> seb128: I've been made aware of it by the orca lead developer, will take a look once I've processed email for the morning.
[23:56] <seb128> TheMuso: ok, they subscribed me to the bug so I was just forwarding the information