[00:09] <mdeslaur> This is weird: bug 855171
[00:10] <mdeslaur> I just hit that bug also
[00:10] <RAOF> As did I.p
[00:10] <mdeslaur> ROAF: do you have your dpkg.log to figure out what common packages we both upgraded?
[00:10] <Nafai> Hey RAOF.  Feeling the last few week's crunch?
[00:11] <RAOF> mdeslaur: Yup.
[00:11] <RAOF> Nafai: I currently have three different systems up.  It's busy :)
[00:11] <Nafai> :)
[00:18] <htorque> mdeslaur: the package upgrade causing it is ca-certificates. ;-)
[00:20] <mdeslaur> htorque: how can you tell?
[00:20] <mdeslaur> bbl
[00:21] <htorque> touch /usr/lib/x86_64-linux-gnu/libnss3.so ; sudo apt-get install --reinstall ca-certificates → that fails and libnss3.so is gone
[00:21] <htorque> mdeslaur: my report is actually a dupe of the others, i just didn't see the java stacktrace
[00:24] <Lirodon> RAOF, I'm going back into inkscape on those GRUB 2 mockups: you said you wanted Recovery stuff in its own menu?
[00:24] <cyphermox> htorque: can't reproduce with that command
[00:25] <htorque> :-/
[00:25] <RAOF> Lirodon: Yup.  And less technical detail in general (ie: I don't think we need the kernel version number on the main screen).
[00:25] <RAOF> htorque: Reproduced here.
[00:26] <Lirodon> RAOF, hmm, but maybe "Boot with previous Linux kernel" could be a good option with a good "If a recent update to the Linux kernel powering Ubuntu has caused issues, you may boot with a backup copy of a previous one"
[00:26] <RAOF> Lirodon: Absolutely.  Under the recovery options ?
[00:27] <Lirodon> Yeah
[00:28] <RAOF> Hm.  do_cleanup () ? rm -r $nssjdk/libnss3.so ?
[00:29] <Lirodon> But hmm, do you think that having an explanation at all of GRUB's parameter/command line is needed?
[00:30] <Lirodon> I had proposed patching the shortcuts to require a CTRL in them
[00:32] <slangasek> RAOF: yeah, that's the culprit :P
[00:32] <jcastro> mdeslaur: that nss missing bug just hit me too
[00:32] <RAOF> slangasek: Is it?  I looks suspicious, but I'm not sure yet that it's actually what's killing it.
[00:32] <slangasek> RAOF: it definitely is
[00:33] <jcastro> ah, looks like I joined at the right time. :)
[00:34] <RAOF> slangasek: You're on it, then?
[00:34] <broder> does anybody have access to the @ubuntustatus account?
[00:34] <jcastro> I believe I do, on it
[00:35] <slangasek> RAOF: ish
[00:35] <slangasek> RAOF: would help if someone else could work on fixing the code while I'm sounding the alarm
[00:37] <RAOF> slangasek: Ok.  I'll see what I can do to hunt it down.
[00:42] <Lirodon> RAOF, now, I wonder, while there were objections to moving ALL the recovery tools into the Recovery menu, what SHOULd be in there?
[00:44] <doko_> slangasek, there was a suggestion to drop the libdir setting in nss.cfg. openjdk does have the multiarch path on the default libpath.
[00:45] <doko_> the other safety check would be to check both arguments for -n before comparing
[00:46] <doko_> both in the hook and the postinst
[00:47] <cyphermox> RAOF: found the issue, I think
[00:47] <slangasek> doko_: that last sounds sensible to me
[00:47] <cyphermox> which dpkg-query --version fails every time
[00:48] <RAOF> Well, and it's looking for libnss3.so which doesn't exist, rather than libnss3.so.1d, which does.
[00:48] <slangasek> good enough for now
[00:48] <slangasek> cyphermox, RAOF: which> that's a bug but not the bug
[00:49] <cyphermox> ok
[00:49] <slangasek> cyphermox: this is being triggered in the hook, not the postinst; the hook doesn't call which
[00:49] <cyphermox> ok
[00:50] <slangasek> libnss3.so which doesn't exist> er, you mean doesn't exist /any more/, I guess?
[00:50] <RAOF> Right.  The hook looks for libnss3.so in libnss3-1d, doesn't find it, and hence merrily symlinks the real libnss3.
[00:50] <Lirodon> okay, what would be the best name for a "run level 3"-type mode? "Boot without graphical desktop"?
[00:50] <doko_> cyphermox, "which dpkg-query --version fails every time", what do you mean?
[00:50] <slangasek> RAOF: ah
[00:50] <RAOF> slangasek: No, it's looking for libnss3.so in libnss3-1d, and libnss3-1d contains libnss3.so.1d
[00:50] <slangasek> doko_: the postinst calls 'which dpkg-query --version'; "which" takes a single argument
[00:51] <RAOF> Which is why it compares an empty string with /usr/lib/x86_64-linux-gnu, merrily symlinks libnss3 to itself, then deletes it.
[00:51] <RAOF> Actuall, that doesn't make sense.
[00:52] <doko_> slangasek, I don't get it, sorry. exits with 0 with or without argument
[00:52] <slangasek> $ which dpkg-query --version
[00:52] <slangasek> /usr/bin/dpkg-query
[00:52] <slangasek> $ echo $?
[00:52] <slangasek> 1
[00:52] <slangasek> doko_: ^^
[00:52] <RAOF> Oh, no.  That does make perfect sense.  It's deleting libnss3.so from libnss3, rather than libnss3.so.1d from libnss3
[00:52] <slangasek> but I don't think that's the issue
[00:54] <cyphermox> it's not
[00:55] <RAOF> So, what I think the issue is: nsspkg=$(dpkg-query -L libnss3-1d | sed -n 's,\(.*\)/libnss3\.so$,\1,p') is always empty, so the query against nss.cfg is always false, so ?ln -sf $nsspkg/libnss3.so $nssjdk/? always happens (which symlinks to itself), then do_cleanup kills $nssjdk/libnss3.so, which just happens to be /usr/lib/x86_64-linux-gnu/libnss3.so
[00:55] <micahg> right, that's a transitional package now
[00:55] <micahg> that should be libnss3
[00:56] <RAOF> Or it should be looking for libnss3\.so\.1d$
[00:56] <RAOF> One or the other.
[00:57] <slangasek> doko_: ^^ that analysis seems correct to me; so we should update the dpkg-query for the correct package name, and we should add a guard in do_cleanup() to make sure we don't remove anything if either nsspkg or nssjdk is empty?
[00:57] <Lirodon> RAOF, "Boot using previous Linux kernel", "If an update to the Linux kernel has caused hardware issues or other problems, you may boot using a backup of the previous kernel."
[01:00] <RAOF> Lirodon: Probably better to do that in #ayatana.
[01:00] <Lirodon> hmm
[01:00] <doko_> slangasek, RAOF http://paste.ubuntu.com/694144/
[01:00] <doko_> ahh, package name ...
[01:01] <slangasek> doko_: yep, nearly identical to what I have here, except for fixing the pkg name check in the hook
[01:01] <slangasek> doko_: bug #855171 for your changelog, btw
[01:02] <slangasek> doko_: http://paste.ubuntu.com/694145/ is mine, if you want to compare / steal
[01:02] <RAOF> doko_: ?if dpkg-query >/dev/null; then? is going to consistently fail, isn't it?  dpkg-query when called with no arguments returns an error.
[01:02] <doko_> gahh, the postinst has it right
[01:03] <doko_> RAOF, it's which dpkg-query
[01:03] <slangasek> doko_: you changed two calls; one had 'which' in front (in the postinst), the other did not (in the hook)
[01:03] <slangasek> RAOF: good catch
[01:03] <RAOF> What slangasek said :)
[01:03] <doko_> slangasek, go ahead, use your version
[01:05] <doko_> I think I do more harm now ...
[01:05] <slangasek> doko_: ok, uploading - thanks for your help
[01:06] <slangasek> doko_: I think you can sleep easily now :)
[01:06] <doko_> slangasek, will do, good night :-)
[01:12] <doko_> infinity, ready for review
[01:14] <Viper550> RAOF, Even though this may be better in a design channel, I still think that anything involving the bootloader/startup can be relevant in here
[01:15] <RAOF> But what you're after is design feedback, right?
[01:15] <Viper550> design, and functionality, and feasibilitiy
[01:16] <RAOF> Well, it looks perfectly feasible to me.
[01:20] <jcastro> slangasek: ok so I get the recovery instructions right, will a normal upgrade after this upload fix it or is there something else the user needs to do?
[01:25] <Viper550> speaking of recovery ... I cannot believe there aren't GUI-based disk cloning programs on Linux
[01:27] <slangasek> jcastro: if they've been hit by the fix, they should manually reinstall the libnss3 package
[01:27] <slangasek> er, hit by the bug
[01:27] <slangasek> we can look at doing a no-change rebuild of libnss3, but that will take *much* longer
[01:27] <jcastro> ok so just dpkg -i it from the local archive?
[01:27] <slangasek> yes
[01:27] <slangasek> 'apt-get install --reinstall libnss3' *SHOULD* work, but is failing consistently for me and others
[01:28] <jcastro> failed for me too
[01:28] <RAOF> ?apt-get install --reinstall libnss3:i386 libnss3? worked for me.
[01:28] <slangasek> RAOF: oh, clever
[01:28] <RAOF> (And on i386 just apt-get install --reinstall libnss3 worked for me)
[01:29] <RAOF> When apt does something weird, guess that it's multiarch fallout and kick it in the foreign-arch ?
[01:29] <slangasek> 'apt-get install --reinstall libnss3:i386 libnss3' should also work on i386, fwiw, so it's probably safe to give everyone that command
[01:29] <slangasek> RAOF: heh :)
[01:29] <jcastro> got it, I'll put the word out on that
[01:29] <slangasek> RAOF: btw, what's wrong with your quote characters :)
[01:33] <jcastro> ok so that apt-get install command hits the network, which is impossible for people who are broken
[01:33] <jcastro> so reinstalling the deb from /var/cache is probably the best way to go for those people?
[01:34]  * RAOF 's network wasn't broken.
[01:34] <jcastro> nor mine, but apparently it broke other people
[01:34] <RAOF> But, yeah.  If the network is broken hope that the deb's in /var/cache.
[01:34] <jcastro> do you have the exact version of the deb handy?
[01:34] <slangasek> or boot from the liveCD you keep lying around when you're running betas
[01:35] <slangasek> jcastro: 3.12.9+ckbi-1.82-0ubuntu5
[01:38]  * ajmitch wonders how it could break the network enough for apt-get to not work
[01:39] <RAOF> ajmitch: Because all sorts of things link to libnss3
[01:39] <RAOF> network manager components, ecryptfs-*, ?
[01:39] <ajmitch> I didn't think that apt would have been one of those
[01:39] <ajmitch> ah right
[01:40] <RAOF> I noticed this because logging in immediately dropped me back to unity-greeter.
[01:40]  * ajmitch is too used to having a working network without n-m :)
[01:40] <RAOF> Because it was no longer possible to mount my ecryptfs home.
[07:26] <sgnb`> debian bug #620031 is present in natty... is it possible to fix it? the fix is trivial and non intrusive...
[07:41] <sgnb> actually, it has been reported in Ubuntu as well... #696706
[08:35] <doko> jtaylor, do you have an opinion/suggestion about dlr-languages?
[08:44] <jamespage> doko: branch proposed for FTBFS for shrinksafe - which should fix the dojo build failure as well once published
[08:44] <doko> jamespage, \o/
[08:44] <jamespage> bug 831366
[08:45] <jamespage> got to know rhino AST quite well :-)
[08:55] <ricotz> doko, hello, do you know what happened to x264 v116?
[08:56] <ricotz> the binaries arent available in the repos anymore
[08:56] <doko> ricotz, what should I know?
[08:56] <doko> which source package?
[08:57] <ricotz> doko, i was hoping so since you commented on the mir of x264
[08:57] <ricotz> https://launchpad.net/ubuntu/+source/x264/2:0.116.2042+git178455c-1ubuntu1
[08:57] <ricotz> http://archive.ubuntu.com/ubuntu/pool/universe/x/x264/
[09:05] <doko> ricotz, it's in the archive. what are you looking for?
[09:05] <ricotz> doko, thank, i hope you can look at it
[09:06] <ricotz> it isnt available for download
[09:06] <ricotz> ok, now it is, again
[09:08] <ricotz> looks like a glitch of some kind, but it really wasnt there a moment ago, sorry
[09:08] <ricotz> E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/universe/x/x264/libx264-116_0.116.2042+git178455c-1ubuntu1_amd64.deb: 403  Forbidden [IP: 91.189.88.45 80]
[09:08] <ricotz> i thought there went something wrong with the main transition
[09:09] <ricotz> ok now it is gone again :\
[09:09] <ricotz> doko, please look at http://archive.ubuntu.com/ubuntu/pool/universe/x/x264/
[09:33] <lool> Hmm a debmirror on ubuntu fails on natty-updates with:
[09:33] <lool> [GNUPG:] BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
[09:33] <lool> many other pockets have a good signature though
[09:33] <lool> I've retried this and it failed again, so it doesn't seem to be temporary skew
[09:33] <lool> I can wait one hour for the next run, but it seems odd that we'd be publishing invalid sigs
[09:35] <lool> if I download natty-updates' Release and Release.gpg it gives a good signature, hmmm
[09:37] <lool> apparently this was really a temporary skew, sorry for the noise; it just lasted surprisingly long as I had the time to fetch many suites 3 times with some inconsistency each time
[09:44] <soren> Uh oh.
[09:58] <tseliot> pitti: any ideas on bug #855396 ? I don't know what's going on. I have attached a patch which makes things a little better but the driver still doesn't show up
[10:01] <pitti> tseliot: hey
[10:01] <pitti> tseliot: looking
[10:01] <tseliot> pitti: thanks
[10:01] <pitti> tseliot: I also just got another interesting one in bug     855175
[10:01] <pitti> tseliot: seems it's picking up fglrx:i386 and showing that as a separate handler
[10:02] <tseliot> pitti: I think we can create a subclass to catch that and make it fail so that it doesn't show up
[10:03] <tseliot> pitti: that = fglrx:i386
[10:03] <pitti> tseliot: I'd just fix it in OSLib to filter out the ones with non-matching arches
[10:07] <tseliot> pitti: I don't see fglrx:amd64 (my current arch) but only fglrx and fglrx:i386 so maybe we can filter out anything with ":" in their name?
[10:08] <pitti> tseliot: right
[10:09] <pitti> I just need to ponder how to reproduce this, but shouldn't be too hard with a slight hack
[10:10] <pitti> tseliot: hm, might that be the same issue?
[10:10] <pitti> that> your bug
[10:11] <tseliot> pitti: in my bug though, we can't get fglrx-updates but only fglrx and fglrx:i386
[10:13] <pitti> tseliot: so your patch supplies an xorg_driver name
[10:13] <pitti> tseliot: does that actually work, i. e. does it help to set a driver "fglrx_updates" in xorg.conf?
[10:13] <pitti> tseliot: I thought we aren't supposed to actually set that any more, as otherwise we break the automatic fallback to ati
[10:16] <tseliot> pitti: no, that's just for the kernel module
[10:17] <tseliot> pitti: as the module alias would be fglrx_updates
[10:17] <pitti> tseliot: oh, of course, I misread; that looks correct, nvidia.py does that as well
[10:17] <pitti> tseliot: can you please commit that?
[10:18] <tseliot> pitti: sure
[10:18] <pitti> tseliot: I'll have a deeper look at this in a bit then
[10:19] <tseliot> pitti: thanks
[10:23] <s1aden> cjwatson: (last person to touch console-setup, noting console-terminus).  Do you know what the default font loaded for the VGA/framebuffer is.  Is it terminus.  I can't work out where in the initscripts the font loading is actually taking place.  (kirkland's colour setting is in vtrgb in console-setup)
[10:25] <tjaalton> pitti: i filed a bug against jockey about removing the choice of installing "experimental nouveau 3d support", which is now installed by default anyway. should probably be targeted for oneiric release
[10:25] <pitti> tjaalton: ah, thanks; which bug #?
[10:26] <tjaalton> bug 839533
[10:26] <pitti> tjaalton: thanks
[10:29] <cjwatson> s1aden: locale-dependent
[10:30] <sladen> locale-dependent
[10:30] <cjwatson> sladen: /var/lib/dpkg/info/console-setup.config, search for CODESET and FONTFACE
[10:30] <tjaalton> pitti: thank you :)
[10:31] <pitti> tseliot: I think I'll compare the apt cache's package object .architecture() against c['xserver-xorg-core'].installed.architecture; that sounds most correct?
[10:31] <sladen> cjwatson: oh, right.  So this is first-time install dependent/
[10:31] <pitti> tseliot: in the crazy case that someone actually installs the :i386 xorg-server on an amd64 machine :)
[10:32] <pitti> tseliot: ah no, we also have non-X drivers; I'll ask dpkg about the native arch instead
[10:34] <tseliot> pitti: I haven't looked into the apt code after the work on multi-arch but I guess that would be correct
[10:35] <tseliot> pitti: BTW I've just pushed my patch
[10:36] <cjwatson> sladen: yes
[10:36] <cjwatson> or dpkg-reconfigure console-setup
[10:37] <sladen> cjwatson: got everything I needed.  thank you!
[10:39] <pitti> tseliot: seems you pushed an empty changelog?
[10:39] <pitti> tseliot: want me to add it for you?
[10:40] <tseliot> pitti: yes, sorry, I'm used to write the changelog only before the release
[10:40] <tseliot> *writing
[10:42] <tseliot> pitti: but I also pushed the actual patch
[10:42] <pitti> tseliot: yup, I saw, thanks! changelog committed as well
[10:42] <pitti> tseliot: I usually write them right away and then use debcommit to construct an appropriate bzr commit changelog
[10:43] <tseliot> pitti: oh, I see. In git I simply push commits and then use git-dch to fill the changelog
[10:44] <tseliot> I'll keep in mind the debcommit command
[10:44] <pitti> tseliot: that's fine
[10:47] <pitti> tseliot: hah, your's is an easy one: fglrx-updates does not have any Modaliases: :)
[10:49] <tseliot> pitti: oh, it's definitely easy to fix then. I wonder how it happened. BTW your bug seems to be fixed here
[10:50] <pitti> tseliot: I updated the bug and added an fglrx-updates task
[10:50] <tseliot> pitti: thanks
[10:54] <tseliot> pitti: the code in fglrx-updates looks fine though. I have both XB-Modaliases: ${modaliases} in debian/control and the relevant code in debian/rules. I wonder why I didn't get any modaliases in the package
[10:54] <pitti> tseliot: it seems to work fine for nvidia-*-updates, anyway
[10:54] <pitti> tseliot: I suspect it's identical to the code in fglrx?
[10:55] <pitti> tseliot, tjaalton: jockey fixes uploaded, will go in right after b2
[10:55] <tseliot> pitti: well, the code in fglrx and fglrx-updates is the same. I can check nvidia-*-updates but it should be the same
[10:59] <tjaalton> pitti: nice, thanks
[11:28] <Sweetshark> tyhicks: could you take over nannying bug 745836?
[11:28] <Sweetshark> tyhicks: that would be great.
[11:41] <tkamppeter> pitti, hi
[11:43] <pitti> hey tkamppeter
[11:44] <Laney> ricotz: did you get any answerS?
[11:44] <Laney> it seems to affect more packages than just that one
[11:46] <elleuca_> seb128, https://bugs.launchpad.net/ubuntu/+source/gnome-utils/+bug/855460
[11:47] <seb128> elleuca_, yes?
[11:48] <elleuca_> seb128, GNOME font viewer and thumbnailer are no longer installed by oneiric, package build issue
[11:48] <tkamppeter> pitti, it is about bug 855445 and bug 855026. It is a CUPS crash which happened to me yesterday and today, when creating a print queue. I have submitted the automatic reports hoping to get a stack trace for an upstream bug report. Unfortunately, Apport refuses to retrace as it seems to not have the correct dbgsym packages on the server (and my system was always up-to-date). Can this be a bug in Apport?
[11:49] <pitti> tkamppeter: oh, I think that's fixed with the update I uploaded this moring
[11:50] <pitti> ah, ignore me
[11:50] <pitti> it's  acrash, not _cups_strcasecmp() not existing, sorry
[11:50] <seb128> elleuca_, see bug #839407
[11:51] <pitti> tkamppeter: yeah, sorry about that; seems our debug symbols are very far behind, so the retracer can't get an useful trace out of it
[11:51] <tkamppeter> pitti, yes, it is a crash. Has nothing to do with the Natty->Oneiric update. My box is a daily-grown Oneiric.
[11:51] <Sweetshark> pitti: does the retracer retry later?
[11:52] <pitti> Sweetshark: no; why should it work better later on?
[11:52] <pitti> some ddebs seem to be missing
[11:52] <Sweetshark> pitti: ah, ok. I misunderstood that.
[11:54] <elleuca_> seb128, ok, sorry for duplicate, it seems I performed a bad search before opening mine
[11:54] <seb128> elleuca_, no worry ;-)
[11:54] <pitti> seems to affect a lot of crashes; I'll try whether I can fish out some lost ddebs
[12:05] <tkamppeter> pitti, that is bad for the development, as one cannot make use of Apport's retracer during the development period. pitti, is there a chance that I can retrace these bugs later, and how do I trigger a new retrace?
[12:06] <pitti> tkamppeter: you need to reuplaod the crash, I'm afraid
[12:07] <pitti> tkamppeter: but right now it won't make too much sense, it won't be any better
[12:08] <tkamppeter> pitti, you need the file in /var/crash? How long do I have to wait?
[12:09] <pitti> tkamppeter: I'm re-running ddeb-retriever to fetch all ddebs from teh last 7 days; that might help a bit; I'll ping you when it's done
[12:36] <ricotz> Laney, hi, no, i didnt get a real answer -- good that you can confirm this problem
[12:36] <ricotz> they are just disappear from time to time
[12:37] <Laney> jpds is fixing it
[12:37] <ricotz> ok :)
[13:08] <barry> pitti: ping
[13:09] <pitti> hey barry
[13:09] <barry> pitti: hi.  i wonder if you have any ideas about a weird problem i'm having with gtimelog 0.6.1.  i've added the ppa you mentioned, and built a pkg from trunk's 0.6.1, but something very strange is happening
[13:10] <barry> pitti: when i run 'gtimelog' say from a shell, none of the key presses get sent to the app.  e.g. ctrl-q doesn't work, but neither does alt-1 or alt-2, etc.  when i run it from lp:gtimelog via ./gtimelog, everything works fine.
[13:11] <pitti> barry: right, compiz/unity currently has a bug with eating keypresses
[13:11] <pitti> F10 and Alt+Letter also don't work anywhre
[13:11] <pitti> barry: you can work around it with UBUNTU_MENUPROXY= gtimelog
[13:11] <barry> pitti: oh wow, trying!
[13:11] <pitti> that'll use the per-app menu instead of the global menu bar
[13:12] <barry> pitti: bingo.
[13:12] <barry> pitti: but why does it work when running from source but not when running from an installed pkg?
[13:12] <pitti> barry: hah!
[13:13] <pitti> barry: it's because trunk prefers pygtk
[13:13] <pitti> barry: we have a "force-gi" patch which makes it use pygi
[13:13] <pitti> barry: if you apply it to trunk (the "raise ImportError"), it's the very same
[13:13] <barry> pitti: wait though, that patch was installed upstream, so it shoudl be the same (remember, i'm running a pkg built from trunk and both are 0.6.1)
[13:14] <pitti> barry: no, it wasn't; upstream said they prefer using pygtk
[13:14] <barry> oh wait
[13:14] <barry> right, it was the other gi patch that was added upstream
[13:14] <barry> pitti: well, i think by default i am now the upstream maintainer :)  should i just go ahead and apply force-gi?
[13:15] <pitti> barry: it's not a nice upstreamable patch, as it effectively just totally disables pygi
[13:15] <pitti> barry: for upstream it should rather swapa around the try/except ImportError:
[13:15] <pitti> barry: i. e. try to import the GI bits, and if that fails, fall back to pygtk
[13:16] <pitti> barry: force-gi is just a minimally intrusive hack which is easy to maintain in our packages
[13:16] <pitti> barry: at some point we should just drop the pygtk bits, though, which will make the code a whole lot easier
[13:17] <barry> pitti: that makes sense.  thanks for the explanation.  let me look at doing exactly that.  do you happen to have a bug # handy for the compiz/unity keypress gluttony?
[13:17] <pitti> didrocks: ^ do you happen to know?
[13:18]  * didrocks backlogs
[13:19] <didrocks> yep, one sec
[13:20] <didrocks> the is bug #849732 for Alt + key
[13:21] <didrocks> F10 should work now though since last release
[13:21] <barry> didrocks: thanks. note that if this is the bug affecting gtimelog, it's not just alt that gets eaten, but ctrl too
[13:22] <barry> didrocks: i'll add a comment to the bug
[13:22] <didrocks> Ctrl + w/q, those weren't reported, I think it's the same than the alt one, adding some news
[13:23] <didrocks> barry: retitled
[13:23] <barry> didrocks: ack
[13:44] <kelemengabor> tedg: hi, do you have a minute to review the proposed branch to bug #853130?
[13:46] <tedg> kelemengabor, Hmm, it's merged, not sure why LP didn't pick that up..  http://bazaar.launchpad.net/~indicator-applet-developers/indicator-datetime/trunk/revision/132
[13:47] <hrw> someone know which package I need to isntall for "from gi.repository import AppIndicator3 as AppIndicator"?
[13:48] <seb128> hrw, gir1.2-appindicator3-0.1
[13:48] <kelemengabor> tedg: no, it isn't, this is the same problem in another file
[13:48] <kelemengabor> and another bug too
[13:48] <tedg> kelemengabor, Ah, okay.  Sorry.
[13:49] <hrw> thx
[13:50] <tedg> kelemengabor, Done
[13:51] <kelemengabor> thanks!
[13:52] <kelemengabor> mvo: ping, got a few minutes to review some proposed branches in bug #853231?
[13:54] <pitti> barry: "we'll actually have a working app"> oh, is my 0.6.0 upload broken?
[13:56] <pitti> barry: but with 0.6.1 we should be down to just the force-gi patch, so that's nice :)
[13:57] <barry> pitti: no, i'm sorry, my comment was misleading.  i merged your gi-fixes patch to upstream 0.6.1
[13:57] <pitti> ah, that'd be a working upstream release indeed
[13:58] <barry> pitti: right!  i'm going to rework the gi-by-default patch for upstream 0.7 too (it'll be overridable from an envar)
[13:58] <pitti> barry: simply swapping around the imports seems easiest, though? i. e. first try GI, then try static?
[13:59] <barry> pitti: yep, with just a tiny bit of goo to read an envar first.  or do you think that's not worth it?  (i.e. upstream should always default to gi).  would someone ever want pygtk if gi were available?
[14:00] <pitti> barry: I don't know; pygtk and gtk2 are dead in my view of the world, but some other people might still use it; but _if_ they have gtk 3 and GI, I can't think of why they wouldn't use it
[14:01] <barry> pitti: fair enough.  you know i have the same general rule (e.g. python3, though py2 is still twitching in my world.  :).  i'll make it unconditional and let bug reports drive any further change.  thanks!
[14:02] <pitti> barry: the only thing that actually works better with pygtk2 is the dynamic adaption of the panel tray icon (it looks bad with Radiance)
[14:02] <pitti> with indicators that hack doesn't seem to work any more
[14:02] <pitti> (pygtk mode doesn't use indicators)
[14:03] <barry> pitti: and this bug ;) https://bugs.launchpad.net/ubuntu/+source/computer-janitor/+bug/806574
[14:03] <pitti> barry: does that affect gtimelog, too?
[14:06] <pitti> barry: ah, not introspectable as the array has an unknown size
[14:06] <pitti> barry: hm, I thought I've seen that before
[14:06] <pitti> right, I even followed up there :)
[14:07] <barry> pitti: :)
[14:07] <barry> pitti: but tbh, i don't think anyone actually *likes* cj so i'm not particularly motivated to fix it ;)
[14:08] <pitti> I'm actually using it occasionally, as it's quite good at picking up some cruft
[14:08] <pitti> but yeah, it's become a step child
[14:08] <barry> pitti: i kind of like it too, but i think some people have had catastrophes with it
[14:10] <pitti> barry: perhaps the reordering could just be disabled
[14:11] <barry> pitti: that's probably a fine solution, since i really don't know how useful the feature is
[14:33] <jml> stgraber: hello. For ARB submitted apps, what's the process like for submitting a new version of an app?
[14:34] <stgraber> jml: same process as for getting it in initially though you can skip the screenshots and logo step if they're the same. Code review is usually easier as we usually just check the delta.
[14:35] <jml> stgraber: thanks. I guess https://wiki.ubuntu.com/PostReleaseApps/Process is the relevant doc?
[14:36] <stgraber> jml: yep
[14:37] <jml> stgraber: thanks!
[14:49]  * mneptok reboots and prays libnss3 is back where it should be
[14:50] <pitti> mneptok: hang on
[14:50] <pitti> mneptok: it won't come back automatically
[14:50] <pitti> mneptok: we just fixed the bug that kills it
[14:50] <pitti> mneptok: you have to reinstall libnss3 if it got zapped
[14:50] <mneptok> pitti: i brought up eth0 by hand, used --reinstall, and then update && upgrade && dist-upgrade
[14:51] <mneptok> pitti: my nm-applet icon is back, Chrome is launching (depends on libnss3-0d) and all seems well.
[14:52] <mneptok> i guess i should have said "prays libnss3 is back where it should be, *AFTER* a manual --reinstall"  :)
[14:56] <doko> #include <Python.h>
[14:56] <doko> namespace sf {
[14:56] <doko> #include <cstddef>
[14:56] <doko> }
[14:56] <doko> #include <stddef.h>
[14:56] <doko> typedef ptrdiff_t GLintptr;
[14:56] <doko> g++ -c -I/usr/include/python2.7 foo.cc
[14:56] <doko> foo.cc:9:9: error: 'ptrdiff_t' does not name a type
[14:57] <mneptok> doko: can i blame you for the broken ca-certificates-java issue? mind you, i don;t care if you are actually responsible. i just want a blame target. O:)
[14:58] <slangasek> mneptok: you're meant to blame me, it's all multiarch's fault
[14:58] <doko> mneptok, blame as you can ...
[14:58] <doko> I just did upload it, didn't approve it ;-P
[14:59] <mneptok> slangasek: drat. if i blame you, The Mighty Missus Slangasek will beat me to a pulp. less because she's burly and mostly because i'm a wuss.
[15:05] <mneptok> doko: in better news, with the certs update Pidgin no longer warns about AOL servers being untrusted when trying to enable an AIM account. that's quite nice.
[15:45] <hyperair> ScottK: could you ack my upload of banshee to oneiric please? no FFe required. just a new upstream bugfix release from an unstable version to a stable.
[15:55] <tkamppeter> pitti, is are the dbgsyms of Apport up-to-date now?
[16:09] <dpm> mvo, I can't remember, does app-install-data-ubuntu contain translation for the descriptions of all desktop files in the Ubuntu archive, regardless of whether the packages containing them are in main, universe, etc?
[16:12] <mvo> dpm: yeah, I'm not sure though if those are striped during build
[16:16] <kirkland> mterry: ping
[16:16] <kirkland> mterry: i have an ecryptfs-verify script here
[16:16] <dpm> mvo, let me ask pitti: Martin, do you happen to know if the descriptions from non-main/restricted package are striped from app-install-data-ubuntu at build time?
[16:16] <kirkland> mterry: i was wondering if you might help with a bit of testing
[16:23] <mterry> kirkland, oooh, ok
[16:23] <infinity> @pilot in
[16:24] <kirkland> mterry: give me a minute, i'll get you a branch
[16:24] <infinity> Aaaaand, topic overflow.
[16:31] <kirkland> mterry: bzr branch lp:ecryptfs, r566.  see: src/utils/ecryptfs-verify
[16:31] <kirkland> mterry: you can run it in place
[16:31] <mterry> kirkland, k
[16:31] <kirkland> mterry: ie, no need to build/install
[16:31] <kirkland> mterry: i've tested it a bit here, works for my test cases
[16:46] <jtaylor> mterry: can you reproduce bug 745119?
[16:46] <mterry> jtaylor, I think so.  I believe it has to do with activating View->Refresh
[16:47] <jtaylor> k, gotta go now, if you ahve more information please post it in the bug, I'll have a look when I'm back. thx
[16:47] <jtaylor> also if oneiric is still affected, natty has a very buggy -dev version
[16:49] <mterry> kirkland, it seems to report 0 (ecryptfs enabled) on a user that isn't using it
[16:49] <kirkland> mterry: doh
[16:49] <kirkland> mterry: can you pastebin the output?
[16:49] <mterry> kirkland, though I'm running as a user that is.  (src/utils/ecryptfs-verify -u tester) where tester is the username
[16:49] <mterry> kirkland, "INFO: Configuration valid" is all I get
[16:49] <kirkland> mterry: hrm, okay, let me reproduce
[16:50] <kirkland> mterry: can you pastebin the sh -x ?
[16:51] <mterry> kirkland, ah, I didn't give it any tests to run.  Sorry, should have read --help first
[16:51] <kirkland> mterry: oh, good call though -- i should error out in that case
[16:52] <mterry> kirkland, maybe add a quiet mode too, for ease of calling without redirecting output to /dev/null?
[16:52] <mterry> kirkland, though that's not hard to do
[16:52] <kirkland> mterry: i thought about that, and I could ... however, I figured >/dev/null was pretty simple?
[16:52] <mterry> kirkland, yeah, that's fine
[16:53] <kirkland> mterry: it's not hard for me to do, though
[16:53] <mterry> kirkland, eh, don't listen to me trying to feature creep this simple utility
[16:53] <kirkland> mterry: :-)
[16:53] <mterry> kirkland, ok, works for me
[16:54] <kirkland> mterry: stdout and stderr are seperate too
[16:54] <kirkland> mterry: so you can filter one or the other or both
[16:54] <mterry> cool
[16:55] <kirkland> mterry: pull r567, and see that the no-checks-given error gets you
[16:56] <mterry> kirkland, yup
[16:56] <kirkland> mterry: sweet, i'll release and upload as soon as the archive thaws
[16:56] <mterry> kirkland, thank you!
[16:57] <kirkland> mterry: np, thanks for the reminder
[17:17] <ahasenack> hi guys, can someone please take a look and hopefully approve the landscape-client packages which are in the upload queue for maverick and natty?
[17:17] <ahasenack> https://launchpad.net/ubuntu/maverick/+queue?queue_state=1 and https://launchpad.net/ubuntu/maverick/+queue?queue_state=1
[17:34] <ScottK> hyperair: It doesn't need a pre-upload approval, but we're frozen for beta 2, so it won't be looked at until after.
[17:34] <hyperair> ScottK: alright. it's already uploaded, and waiting in the queue.
[17:49] <slangasek> apw: bug #855764 filed on linux about the grub->linux flicker that persists here; insight welcome
[17:53] <SpamapS> slangasek: question on multiarch..
[17:53]  * slangasek hides under an ld.so.conf
[17:53] <SpamapS> slangasek: my binary only printer drivers from canon are i386 only as well.. they depend on libpopt0 .. which only exists in /lib
[17:54] <SpamapS> slangasek: so effectively, they are now uninstallable.. where before they actually worked fine with my amd64 libpopt
[17:54] <slangasek> SpamapS: libpopt0 is still shipped in ia32-libs for this reason (and others)
[17:54] <slangasek> ehm, how do you mean "worked fine"?
[17:54] <SpamapS> slangasek: works fine
[17:54] <SpamapS> I can extract the binaries and use it.. it runs
[17:54] <slangasek> you mean it depends on libpopt0 but doesn't use the library?
[17:54] <slangasek> right
[17:54] <slangasek> so you can install with --force-depends
[17:55] <SpamapS> heh.. I didn't think of that. :-P
[17:55] <slangasek> rather, you *need* to install with --force-depends... and whether you bother to fix up the libpopt.so.0 dependency by installing ia32-libs afterwards is up to you
[18:00] <slangasek> mvo: if I search for skype in software-center on oneiric, it offers to install it for me from natty-partner even though the i386 package is now available in oneiric-partner... I guess something needs updating to know about oneiric-partner?
[18:18] <slangasek> bjf: http://reports.qa.ubuntu.com/reports/boot-speed/dell-latitude-e6510/2011-09-20_00-00-03/bootchart.png shows a lot of time spent in /usr/lib/update-notifier/update-motd-updates-available, which wouldn't be the case on a typical boot.  Should/could we correct for this somehow, possibly by making sure there's an 'apt-get update' as part of what's run on the system before the boot test?
[18:19] <bjf> slangasek, that's a good point
[18:22] <bjf> slangasek, i normally 1. install the daily iso, and reboot, 2. install bootchart and modify /etc/default/grub and update-grub, 3. reboot for speed test
[18:23] <bjf> slangasek, there is an 'apt-get update' before installing bootchart (step 2)
[18:32] <slangasek> bjf: hmm, I guess we need to dig into that then to find out why update-motd-updates-available is still doing work after an apt-get update
[18:35] <mvo> slangasek: yeah, that needs a update, there is a bzr branch already, I will upload tomorrow morning latest
[18:38] <slangasek> bjf: I notice too that in some of these, ureadahead looks like it's reprofiling the boot; do we need an additional reboot in there, to make sure we're measuring with an up-to-date ureadahead pack?
[18:39] <slangasek> mvo: aha - thanks, man :)
[18:39] <bjf> slangasek, could be
[19:02] <slangasek> I wonder why we call dbus-uuidgen at boot when we also call it in the postinst
[19:06] <mvo> slangasek: new app-install-data-partner with multiarch skype is up
[19:06] <slangasek> mvo: huzzah :)
[19:14] <broder> slangasek: i think livecd-rootfs removes the dbus uuid, so there isn't actually one at install time
[19:14] <broder> (and you wouldn't want there to be, anyway, because then it makes for a crappy universally unique id :-p)
[19:15] <slangasek> broder: that seems like something ubiquity should fix up as part of the install to disk, though, not something we should do on every boot
[19:15] <broder> slangasek: i looked into this once; my recollection is that it short-circuits fairly quickly if the uuid is there
[19:16] <slangasek> broder: it's actually popping up on my radar because it's showing up in boot charts as taking a non-trivial amount of time :)
[19:16] <broder> yeah, that was why i was looking at it :)
[19:18] <broder> but +1 from me to fixing this in the installer and dropping it from the upstart job
[19:18] <slangasek> kirkland: do you know why setvtrgb seems to take .25s to 1s to do its thing at boot?  it's possible it's just stuck waiting on the kernel and has no impact on boot speed, but it's strange that it should take this long
[19:42] <ryoohki> would this be the place to ask for help with pbuilder?
[19:47] <Daviey> ryoohki: depending on the volume, yes - #ubuntu-motu is another very good place for things like that.
[19:53] <infinity> @pilot in
[19:55] <smoser> hey all.
[19:55] <smoser> i'm looking at https://code.launchpad.net/~menesis/ubuntu/oneiric/paste/oneiric/+merge/75584
[19:59] <Daviey> smoser: if it gets rid of that annoying warning every time i invoke python, great
[19:59] <ximion> hi! I would love to see bug 847815 - I get messages about duplicates, but I don't have the required rights to see this bug :(
[19:59] <ximion> if someone would be so kind to make it public... :P
[19:59] <infinity> smoser: Can you test if building the Debian paste on oneiric fixes the bug?  If so, I say we just sync instead of merging that patch.
[19:59] <Daviey> ximion: looking
[20:00] <infinity> smoser: Oh, except that ours already has changes.  What are those?  *looks*
[20:01] <Laney> yeah, we already have .1-2
[20:01] <infinity> Yeah, indeed.
[20:01] <Daviey> ximion: public.
[20:01] <infinity> So, ScottK's comment stops making sense to me at this point. ;)
[20:02] <infinity> smoser: Nevermind me.  I was assuming ScottK's comment on the bug made sense. :P
[20:02] <ScottK> What bug?
[20:02] <infinity> https://bugs.launchpad.net/ubuntu/+source/distribute/+bug/810019
[20:03] <Laney> that bug affects Debian too
[20:04] <ximion> Daviey: thanks!
[20:04] <Laney> ah, already there
[20:04] <ScottK> It was a drive by comment based on the one before, so indeed, there's no guarantee it makes sense.
[20:05] <smoser> ok. i can verify this
[20:05] <smoser> i built binaries of the ubuntu version and the proposed
[20:05] <smoser> http://paste.ubuntu.com/694722/
[20:05] <smoser> is the diff
[20:05] <ximion> Daviey, I still don't have permission... But maybe LP is just slow today...
[20:05] <smoser> and installed, and it doesn't give the issue anymore
[20:06] <Daviey> ximion: odd, try now.
[20:06] <smoser> so, to me, its a straight forward fix.
[20:06] <Daviey> smoser: well it looks safe, but does it work? :)
[20:06] <smoser> but i really dont know what the namespace_packages.txt does
[20:06] <ximion> Daviey: works now, thanks again! :)
[20:06] <smoser> yes, verified it works.
[20:06] <ximion> oh nooo, it's Russian :D
[20:07] <Daviey> ximion: hug google translate.. feel free to add your own words to the description.
[20:08] <ScottK> Considering the paste maintainer is also the dh_python2 author, I think the chances of a bad dh_python2 conversion are low.
[20:08] <Daviey> ScottK: well seems something is wrong he missed.
[20:09] <ScottK> Perhaps.
[20:09] <ScottK> I'd run it by him first.
[20:09] <ximion> Daviey: Apparently he asks if he can write russian text there :D
[20:10] <ScottK> IIRC automatic handling of namespaces is one thing that's changed.
[20:10] <Daviey> So, the big task is against distribute, not paste
[20:10] <Daviey> but we only see this issue when paste is installed.
[20:10] <Daviey> s/big/bug
[20:10] <smoser> no
[20:10] <smoser> see the debian bug
[20:10] <smoser> it affects other python packages too
[20:12] <Daviey> The Debian bug is pretty stale.
[20:13] <Daviey> barry: do you have thoughts on this?
[20:13]  * barry reads back
[20:17] <Laney> he explicitly touched that line when doing the dh_python2 conversion
[20:19] <jtaylor> you get the same working with argparse installed btw
[20:19] <jtaylor> warning
[20:20] <smoser> jtaylor, thank you.
[20:20] <smoser> jtaylor, wait..i dont think so
[20:20] <Laney> jtaylor: i can't reproduce that. how?
[20:21] <smoser> i have argparse, and i have the proposed fix installed for paste, and i no longer see any warnings with
[20:21] <smoser>  python -c 'import pkg_resources'
[20:22] <jtaylor> I get it when starting ipython qtconsole
[20:22] <ScottK> I think the fix is wrong.
[20:22] <Daviey> jtaylor: i don', without touching paste
[20:22] <jtaylor> it seem sconnected with pygments
[20:22] <ScottK> With dh_python2 we shouldn't have to extend sys.path.
[20:22] <jtaylor>  /usr/lib/python2.7/dist-packages/pygments/plugin.py:39: UserWarning: Module argparse was alrea...
[20:23] <ScottK> The current package has /usr/share/pyshared/Paste-1.7.5.1-nspkg.pth
[20:23] <jtaylor> ah because that includes pkg_resources
[20:23] <ScottK> So I think the actual problem is that file getting installed.
[20:23] <barry> so, interestingly enough, piotr originally suggested removal of *.pth files, but then backtracked
[20:23] <barry> (this was in reference to flufl.lock getting into debian)
[20:24] <barry> actually i think it was jakub who said:
[20:24] <ScottK> AIUI his debian/rules tries to remove it, but fails.
[20:24] <jtaylor> neither argparse nor pygments install pth files
[20:24] <barry> which would make sense because i don't think either provides a namespace
[20:24] <ScottK> If I manually remove the pth file, the warning doesn't happen.
[20:25] <Laney> indeed
[20:26] <barry> jtaylor: so you're getting two pkg_resources?
[20:27] <smoser> ScottK, you're saying if you remove /usr/lib/python2.7/dist-packages/Paste-1.7.5.1-nspkg.pth the problem goes away ?
[20:27] <smoser> because i do not see that.
[20:27] <ScottK> Yes.
[20:27] <ScottK> Actually, not quite.
[20:27] <jtaylor> barry: I only see one
[20:28] <ScottK> I removed rm /usr/share/pyshared/Paste-1.7.5.1-nspkg.pth
[20:28] <Laney> smoser: http://paste.debian.net/131463/
[20:28] <smoser> http://paste.ubuntu.com/694741/
[20:28] <jbicha> yesterday's ca-certificates bugfix doesn't actually restore libnss3 to those who lost it, would a libnss3 rebuild help?
[20:29] <barry> indeed, after installing python-paste, and importing pkg_resources, it's getting it from where i'd expect
[20:29] <smoser> jbicha, only those who did a fresh install were affected. i assume you're one of them.
[20:30] <smoser> so, Laney, what did i do wrong ?
[20:30] <barry> it's very disconcerting that you get a warning about module Paste when you don't even import it
[20:30] <infinity> jbicha: Yes, but ideally not in the middle of a freeze.
[20:30] <Laney> the find line fails to remove the pth file
[20:30] <jtaylor> pkg_resources does some weird stuff when you import it
[20:30] <Laney> find /srv/home/laney/temp/paste-1.7.5.1/debian/python-paste -name '*.pth' -or -name 'namespace_packages.txt' -print -delete
[20:30] <Laney> /srv/home/laney/temp/paste-1.7.5.1/debian/python-paste/usr/lib/python2.6/dist-packages/Paste-1.7.5.1.egg-info/namespace_packages.txt
[20:30] <ScottK> Laney: Yes.  That's what needs fixing.
[20:31] <jbicha> smoser: no, not a fresh install, anyone who had been using Oneiric & happened to upgrade to the broken ca-certificates yesterday
[20:32] <barry> yeah, try turning on -v to see the imports that happen as a result of pkg_resources.  zope, then lazr, and it's there i get the warning
[20:33] <barry> ScottK: so you're saying that it's python-paste that needs fixing?  if so, i think i agree :)
[20:33] <jbicha> infinity: people's systems are quite broken, and it's easier to tell people to update then for them to find a random .deb to install
[20:33] <doko> barry, you can give back cardstories on the regular buildds
[20:33] <ScottK> barry: Yes, but I think someone should also talk to POX before fixing it.
[20:33] <Laney> just needs some parens
[20:34] <jtaylor> in my argparse case it comes after lazr
[20:34] <barry> doko: build retried
[20:34] <ScottK> I don't agree that the proposed change is correct.
[20:34] <Laney> find /srv/home/laney/temp/paste-1.7.5.1/debian/python-paste \( -name '*.pth' -or -name 'namespace_packages.txt' \) -print -delete
[20:34] <Laney> like that
[20:36] <barry> ScottK: i asked pox for his opinion of bug 810019 on #debian-python
[20:36] <ScottK> OK.  Thanks.
[20:37] <barry> he may not be around now though
[20:37] <barry> well, i subscribed him to the lp bug
[20:38] <jbicha> infinity: thanks
[20:38] <ScottK> It's just (IIRC) part of supported, so we can get this fix in when it's ready.
[20:38] <ScottK> No need to sweat the beta 2 milestone.
[20:38] <smoser> jbicha, i dont think you're right though
[20:38] <smoser> because i upgraded to the busted openssl
[20:39] <smoser> and i'm not broken
[20:39] <infinity> smoser: And by "openssl", you mean "ca-certificates"?
[20:39] <jbicha> smoser: it was ca-certificates and I had to manually install libnss3
[20:40] <smoser> so, Laney ScottK if i remove those .pth files, my problem does not go away.
[20:40] <smoser> i'm on updated to the moment-ish oneiric
[20:40] <smoser> granted i do have some ppas installed for openstack
[20:40] <doko> jelmer, do you want to propose heimdal 1.5 for the final release?
[20:40] <ScottK> You may have more than one package installed with the same issue.
[20:40] <jtaylor> so got a way to reproduce argparse issue: mkdir -p external/argparse; touch external/__init__.py; echo "import argparse > external/argparse/__init__.py"; python -c import external.argparse; import pkg_resources"
[20:40] <jtaylor> not related to any pth files
[20:41] <smoser> ScottK, but it is still paste that complains
[20:41] <smoser> or, is complained of
[20:41] <ScottK> Hmmm.
[20:43] <Daviey> smoser: what file did you rm?
[20:43] <smoser> see pastebin, daviey
[20:43] <smoser> http://paste.ubuntu.com/694741/
[20:43] <Daviey> /usr/share/pyshared/Paste-1.7.5.1-nspkg.pth ?
[20:43] <smoser> yes.
[20:44] <Laney> smoser: do you have /usr/lib/python2.7/dist-packages/PasteDeploy-1.5.0-nspkg.pth ?
[20:44] <Laney> seems pastedeploy has the same issue
[20:44] <smoser> i was just suspecting that.
[20:44] <barry> from #debian-python:
 barry: well, I am actually *not* removing this damn Egg stuff  [16:42]
 will fix in next upload
[20:44] <barry>  
[20:44] <Laney> confirm/deny plz
[20:44] <smoser> sudo rm $(dpkg -L python-pastedeploy | grep pth$)
[20:44] <Daviey> smoser: it also doesn't help me
[20:44] <smoser> that fixed my problem
[20:45] <Laney> right, so pastedeploy has it too
[20:45] <smoser> Daviey, you also have paste-deploy probably
[20:45] <smoser> yeah
[20:45] <Laney> which is unsurprising because it has exactly the same line in its rules file
[20:45] <Daviey> smoser: confirmed
[20:45] <Laney> barry: can you pass that info to POX?
[20:45] <barry> Laney: sorry, which info exactly?
[20:45] <ScottK> barry: Since POX was heading to bed, why don't you file some nice bug reports in Debian once this is sorted?
[20:45] <infinity> barry: That if his find syntax was correct, this would all be working. ;)
[20:46] <Laney> that python-pastedeploy needs fixing too
[20:46] <ScottK> barry: That paste-deploy is broken too
[20:46] <ScottK> err, that one.
[20:46] <Daviey> seems to be evil, /usr/share/pyshared/*.pth
[20:46] <ScottK> Yes.
[20:46]  * Laney has NFI what .pth files actually are :-)
[20:47] <barry> Laney: http://docs.python.org/library/site.html#module-site
[20:47] <jtaylor> I don't think removing the pth file is a proper solution
[20:47] <jtaylor> or is my argparse example somehow wrong?
[20:48] <jtaylor> that method is quite important to ipython
[20:48] <barry> so, sounds like pox will fix those in the next debian uploads
[20:48] <barry> (of paste*)
[20:48] <Daviey> jtaylor: Nobody else has been able to reproduce your argpath example?
[20:48] <Laney> does he agree with our assessment?
[20:48] <doko> I'll disallow imports from /ust/share/pyshared directly for the p-series
[20:48] <Laney> i.e. should we upload fixes like that?
[20:48] <jtaylor> Daviey: https://bugs.launchpad.net/ubuntu/+source/distribute/+bug/810019/comments/9
[20:49] <doko> jtaylor, did you see my dlr-languages question?
[20:49] <jtaylor> no
[20:49] <Daviey> jtaylor: dropping the .pth files breaks ipython?
[20:50] <ScottK> since POX says he'll upload fixed versions tomorrow, my recommendation is just wait and sync that.
[20:51] <Daviey> smoser / jtaylor: removing the pth files does break ipython
[20:51] <barry> okay, so pox is going to upload fixed versions tomorrow.  we'll need to sync that once it's uploaded and then our problem should be fixed
[20:51] <jtaylor> no
[20:51] <Daviey> infact, it breaks paste.
[20:51] <Daviey> you can't import paste full stop, without the pth files.
[20:51] <smoser> well, thats hardly of concern.
[20:51] <smoser> i dont want to see the error!
[20:51] <smoser> :)
[20:52] <barry> exactly.  installing paste should not cause that warning for unrelated modules
[20:54] <jtaylor> ah ok now I get it, the argparse issue is caused by paste ._.
[20:55] <jtaylor> doko which dlr-languages question?
[20:56] <barry> doko: dang.  cardstories 1.0.6-1 still ftbfs, but it builds fine for me locally.  i'll keep digging
[20:57] <OdyX> tkamppeter: is your foomatic-db patch upstream'ed ?
[20:57] <doko> jtaylor, ahh, sorry, that was Laney, not you
[20:57] <Laney> regarding my email?
[20:57] <doko> will remove it now
[20:57] <ryoohki> Daviey: thanks!
[20:58] <doko> Laney, yes, I do not want to care about the whole dlr stack, and ironpython is now part of that (mess)
[20:58] <Laney> :-)
[21:03] <Laney> can it be split up?
[21:04] <doko> I didn't check anymore. let's address this for p
[21:04] <Laney> no probs
[21:20] <jelmer> doko: are you asking whether that's what I had planned, or requesting I do so?
[21:20] <doko> jelmer, have you been a diplomat in your former life?
[21:21] <jelmer> doko: Sorry :)
[21:21] <jelmer> doko: I didn't have any plans to upload the final 1.5 release into oneiric.
[21:21] <doko> jelmer, no, was a question what should be supported, and if the changes are worth (the risk) including it
[21:22] <doko> ok
[21:30] <doko> Laney, could you have a look at bug 756121?
[21:30] <Laney> doko: we are removing it
[21:31] <Laney> i thought directhex filed the rm bug
[21:31] <Laney> but no, I will do it now
[21:33] <doko> jelmer, what's the status about bug 831375
[21:36] <Laibsch> I have added http://paste.debian.net/131459/ to my pbuilderrc s suggested in http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html#altcompiler to build with gcc 4.4 (4.6 has a bug on my CPU), but logging in to the pbuilder and doing "gcc --version" still show 4.6.1.  What's wrong?
[21:39] <doko> Laney, same for bug 831373
[21:43] <jelmer> doko: it's on my todo list, I'm hoping to address it before the end of the week (as well as some other bzr-hg issues)
[21:48] <Laney> looking
[21:49] <Laney> doko: debian bug #642361 for nemerle
[21:49] <Laney> fire ze missiles
[21:57] <doko> Laney, thanks, fired
[21:57] <Laney> ivkm looks like a missing --exclude-modeuleref
[22:01] <slangasek> does anyone here see plymouth crashes on boot?
[22:02] <slangasek> ever?
[22:02] <slangasek> we get plenty of bug reports about it... but it's a deep bug that needs to be reproduced locally to fix
[22:09] <RAOF> What would a plymouth crash look like?
[22:11] <slangasek> RAOF: an apport pop-up :)
[22:11] <RAOF> Heh.  So, no, none of my systems do that :)
[22:14] <slangasek> somewhere there's a reference counting bug in the event loop code, but my eyes can't find it.... I need to get at a gdb session, but the retracer helpfully scrubs all core files from the bugs before it shows them to me :P
[22:35] <tkamppeter> OdyX, the upstream repo for foomatic-db is still down, I will upstreamize the patch as soon as it gets possible.