[00:02] <jono> bryceh, thanks
[00:02] <jono> is there anything in specific I should be looking for?
[00:03] <bryceh> jono, I would look for an error message or stack trace
[00:03] <jono> looking throught he lightdm logs there are no errors
[00:03] <jono> and I dont see errors in the Xorg.0.log* files
[00:05] <jono> bryceh, it does say in the syslog that plymouth-stop terminated with status 1 and lightdm main process terminated with status 127
[00:05] <jono> not sure what those statuses mean
[00:05] <bryceh> that would be your culprit
[00:06] <jono> bryceh, what do those statuses mean?
[00:06] <bryceh> non-zero exit code generally means the program failed
[00:07] <jcastro> I don't think it's lightdm
[00:07] <jcastro> I can't plain startx at all
[00:07] <jcastro> even if I remove lightdm from the equation
[00:07] <bryceh> not that familiar with plymouth-stop, but sounds like maybe it was unable to terminate plymouth?  so then it never bothered to start X
[00:08] <cjwatson> that wouldn't explain being unable to startx manually
[00:08] <cjwatson> jono: it's often not possible to assign a specific meaning to exit codes
[00:08] <jono> cjwatson, when I run startx as a user it says the user is not authorized to run the X server
[00:08] <cjwatson> not from the exit code alone anyway
[00:08] <bryceh> cjwatson, maybe, although if something went wrong with the gpu while plymouth was running, both startx and *dm-X would fail the same way
[00:09] <slangasek> there's practically no reason that plymouth-stop should fail to stop plymouth unless something else (like a DM) has interfered with it; it's more likely that plymouth failed to start in the first place
[00:09] <cjwatson> true, but that's a hell of a lot to infer from plymouth-stop exiting 1
[00:09] <bryceh> jcastro, pastebin your output from running startx
[00:09] <slangasek> jono: is there a plymouth process running?
[00:09] <jono> slangasek, nope
[00:09] <slangasek> 'plymouthd' rather
[00:09] <broder> startx doesn't work as an unprivileged user
[00:09] <broder> but that's separate
[00:11] <jono> is there a way for my to try and boot without plymouth so I can see if that is causing the issue?
[00:12] <jono> broder, I assume running startx as root would not work either?
[00:12] <jcastro> Is plymouth used from the recovery entry on grub? because I tried that too
[00:12] <cjwatson> booting without plymouth is impossible.  you can remove 'splash' from your boot parameters and plymouth will not try to display a splash screen, however
[00:12] <jono> cjwatson, ahhh I see
[00:12] <cjwatson> which would be sufficient to eliminate it from this question
[00:13] <jono> was there a recent plymouth release over the last day?
[00:13] <cjwatson> the recovery entry does not use 'splash', so if it exhibits the same problem, it's not plymouth's fault
[00:13] <jcastro> I have the problem and I don't have "splash"
[00:13] <bryceh> jono, your /var/log/dpkg.log should show what packages were updated since yesterday
[00:14] <bryceh> was there a kernel update?
[00:14] <jono> just checking now
[00:15] <jcastro> I tried with an older kernel too. :-/
[00:15] <bryceh> hmm
[00:16] <cjwatson> plymouth hasn't changed for a month or so
[00:16] <cjwatson> I think you can safely rule it out
[00:18] <jono> there was mainly some gtk3 and initramfs updates
[00:19] <jono> new libglib too
[00:20] <bryceh> wonder what the initramfs change was
[00:20] <slangasek> initramfs-tools itself hasn't been updated; the breakage could be caused by whatever triggered an update to your initramfs though
[00:21] <jono> hmmm
[00:22] <jono> not sure if this helps, but I tried to startx from root after I rebooted into recovery mode - it says /dev/fb0: No such file or directory
[00:25] <RAOF> That's fbdev not being able to open the framebuffer device, which is entirely expected as recovery mode disables kms, leaving you without a framebuffer device :)
[00:25] <jono> aha!
[00:25] <jono> makes sense :-)
[00:25] <jono> so any suggestions, folks?
[00:25] <RAOF> Which, incidentally, means that intel and nouveau won't work from recovery mode, as they require kms.
[00:25] <jono> anything else I can do to help track the issue down?
[00:28] <bryceh> I'd suggest filing a bug report with ample logs in case there's something subtle in them a trained eye might catch
[00:28] <jono> bryceh, will do
[00:29] <bryceh> the /var/log/dpkg.log especially would be useful, since if it's a regression since yesterday it's likely going to be due to one of those updates
[00:29] <jono> no worries
[00:30] <slangasek> huh, has that always been the behavior of recovery mode?  I didn't remember 'nomodeset' being there before
[00:30] <jono> slangasek, I just tried to run startx as root from a normal session and still no luck
[00:30] <bryceh> theoretically downgrading the versions individually might reverse the error, although if slangasek's right that an initramfs update is involved, that may not help at all
[00:31] <bryceh> jono, what printed out when you ran it?  "no luck" isn't a normal X error ;-)
[00:31] <jono> bryceh, xinit: connection to X server lost
[00:31] <Sarvatt> jono: ~/.xsession-errors
[00:31] <RAOF> slangasek: It's new in oneiric, on the basis that one of the problems that people need to be able to recover from is when kms doesn't work :)
[00:31] <jono> waiting for X server to shut down: ddxSigGiveUp: Closing log
[00:32] <bryceh> the good news is if both jono and jcastro are seeing the same bug, it should be easy to reproduce
[00:32] <slangasek> RAOF: I thought kms was always supposed to work ;p
[00:32] <Sarvatt>  gnome-session: symbol lookup error: /usr/lib/gio/modules/libgiozeitgeist.so: undefined symbol: g_desktop_app_info_launch_handler_get_type
[00:32] <RAOF> Well, at least we should have a useful Xorg.0.log :)
[00:32] <jcastro> ooh, I get that same ddxgiveup thing
[00:32] <slangasek> also, the tradeoff is that now recovery mode is less useful for debugging other failures that weren't kms-related
[00:33] <slangasek> Sarvatt: should be non-fatal, just means gnome-session won't load zeitgeist integration?
[00:33] <cjwatson> slangasek: bryceh and RAOF asked me to change that at UDS
[00:33] <cjwatson> (adding nomodeset in recovery mode)
[00:33] <cjwatson> of course one can edit the boot parameters and delete that if that's not the problem ...
[00:33]  * slangasek nods
[00:34] <jcastro> RAOF: there's nothing in the Xorg.0.log, it was the first place I looked.
[00:34] <cjwatson> I feel no ownership of that boot parameter change, though - if the X team stops feeling it's appropriate, I'm happy to undo it
[00:34] <jono> my .xsession-errors has a stack of Fatal IO error 11 (resource temp unavailable) on X server :0
[00:35] <Sarvatt> X is fine, i've got X up with an xterm, its something gnome related from the looks of it
[00:35] <RAOF> slangasek: It's really about what the purpose of recovery mode is, and mode which is guaranteed (as far as possible) to bring up a display of some kind is pretty useful.
[00:36] <jono> I also see a stack of GLib-GObject-CRITICAL errors
[00:36] <slangasek> RAOF: point
[00:36] <jono> those errors seem to be in nautilus
[00:36] <slangasek> jono: can you pipe your .xsession-errors through pastebinit?
[00:36] <Sarvatt> startx is trying to start a session which is dying and quitting x
[00:37] <jono> I also see an I/O warning about failing to load external entity /home/jono/.compiz/session/<long random number>
[00:37] <jcastro> http://paste.ubuntu.com/667805/
[00:37] <jcastro> there's mine
[00:38] <slangasek> Sarvatt: I'm confused; are you experiencing other X problems, or are you reading over jono's shoulder? :)
[00:38] <slangasek> s/X/desktop/
[00:38] <Sarvatt> i reproduced it on a machine i upgraded this morning, rebooted and no desktop
[00:38] <slangasek> aha
[00:39] <Sarvatt> also the amd64 livecd from today doesnt start lightdm automatically
[00:39] <slangasek> jcastro: I don't suppose there's anything interesting in *your* /var/log/Xorg.0.log?
[00:39] <jcastro> nothing at all
[00:39] <slangasek> jcastro: nothing except for the ddxGiveUp error?
[00:39] <jcastro> yeah but that's only spit out to the console
[00:39] <jcastro> not the log afaict
[00:40] <slangasek> ah, when trying to run startx?
[00:40] <RAOF> ddxGiveUp isn't (necessarily) an error; that's what the X server says during shutdown.
[00:40] <jcastro> right
[00:40] <RAOF> So if the X server is working fine, but the session you're trying to start up quits, the server will terminate and you'll get that message.
[00:41]  * slangasek nods
[00:45] <hallyn> jbernard: hm, scratch that (above), i see where it's supposed to do it
[00:47] <jono> interestingly, if I switch my DM to gdm I see X repeatedly try to start
[00:47] <bryceh> that's just gdm trying blindly to deal with the situation by trying to start X multiple times
[00:48] <bryceh> in theory gdm should exit and drop into failsafe-x
[00:48] <jono> right, ok, I am rebooting and then putting log files on a USB stick and will file a bug
[01:08] <jcastro> ok so doing a "sudo startx" I get "No protocol specified" over and over on the first console
[01:16] <Sarvatt> jono, jcastro, bryce: it's the glib2.0 update today
[01:16] <Sarvatt> https://launchpad.net/ubuntu/+source/gnome-session/3.1.3-0ubuntu11/+build/2679219 works
[01:17] <Sarvatt> https://launchpad.net/ubuntu/+source/glib2.0/2.29.14-0ubuntu1/+build/2644910 for the amd64 packages, downgrading that makes everything work again
[01:17] <Sarvatt> err sorry, didnt mean to link gnome-session in the first one
[01:17] <jcastro> ok trying it
[01:17] <Sarvatt> https://launchpad.net/ubuntu/+source/glib2.0/2.29.14-0ubuntu1/+build/2644912 for i386
[01:18] <bryceh> Sarvatt, thanks
[01:30] <jono> Sarvatt, how do I downgrade that package?
[01:30] <bryceh> jono, jcastro, thanks; I've reproduced the bug on two machines.  Likely everyone who updates today will hit it
[01:30] <jcastro> jono: grab the debs on that page and dpkg -i them
[01:30] <bryceh> jono, download the .deb's and then do sudo dpkg -i *.deb
[01:30] <bryceh> I still had the files in /var/cache/apt/archives
[01:31] <jcastro> (I've installed them but need to wrestle with nvidia for a bit before I confirm they work for me)
[01:31] <Sarvatt> libglib2.0-0 libglib2.0-data libglib2.0-bin should be what you need
[01:32] <jono> thanks for all your help bryceh , Sarvatt , jcastro , cjwatson , RAOF
[01:32] <jono> and of course slangasek
[01:34] <bryceh> alright, I've reproduced both the bug and the workaround of downgrading glib using what is in /var/cache/apt/archives, and I have a functional desktop with unity
[01:35] <micahg> slangasek: still around?
[01:35] <slangasek> micahg: yep - what security update would you like me to break today? :)
[01:35] <micahg> slangasek: heh, firefox, natty only, from ubuntu-mozilla-security to natty-security, please
[01:35] <jono> Sarvatt, those are the AMD64 builds, where are the normal x86 builds?
[01:36] <jcastro> https://launchpad.net/ubuntu/+source/glib2.0/2.29.14-0ubuntu1/+build/2644912
[01:36] <Sarvatt> [9:17 PM] <Sarvatt> https://launchpad.net/ubuntu/+source/glib2.0/2.29.14-0ubuntu1/+build/2644912 for i386
[01:36] <jono> ahhh
[01:36] <jono> thanks
[01:36] <jono> didnt see that
[01:36] <slangasek> micahg: version 6.0+build1+nobinonly-0ubuntu0.11.04.1 ?
[01:37] <micahg> slangasek: yes please
[01:38] <slangasek> micahg: done
[01:38] <micahg> slangasek: thanks!, by the end of my day, I should have a nice list of OOPSes to throw at the LP guys for this (not that it'll make them fix it any faster)
[01:39] <slangasek> micahg: well, I understand they want us to not have to use the shell to administer the archive... and this counts :)
[01:48] <jcastro> Sarvatt: bryceh: confirming the downgrade works here
[01:54] <bryceh> jcastro, I gotta run but can you or jono file a bug against glib2.0 and make sure seb128 or one of the other gnome is aware of it?  I'll send a note to the mailing list.
[01:55] <jono> thanks bryceh , will file it now
[02:01] <jono> https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/827753
[02:01] <jono> biab
[02:20] <slangasek> RAOF: installing libgl1-mesa-glx:i386 in a chroot works ok here
[02:20] <slangasek> RAOF: however, bug #802901
[02:21] <RAOF> That's an eerily familiar error message… :)
[02:25] <slangasek> oh, no, it doesn't work ok here at all, I simply forgot to let it get to the point of attempting the install :P
[02:25] <RAOF> slangasek: Hah!
[02:25] <RAOF> Yeah, I just tried it and it failed for me.
[02:25] <RAOF> I was wondering whether you'd forgotten to install libgl1-mesa-glx:amd64 first :)
[02:26] <RAOF> But, in case it's not obvious, the problem is symmetric - if you install libgl1-mesa-glx:i386 first, then libgl1-mesa-glx:amd64 will fail to install with that error.
[02:30] <slangasek> linux-libc-dev also has a C/R/P - nice catch
[03:02] <RAOF> jono, jcastro: Do you, perchance, have libzeitgeist-gio installed?
[03:04] <jbicha> RAOF: that's not even available in my synaptic
[03:04] <RAOF> jbicha: Yeah, I know.  It *was* in Maverick, though (see bug #724199), and so upgraders might hit this.
[03:05] <RAOF> Whereas my freshly installed oneric is very happily running the latest stack.
[03:07]  * jbicha tries rebooting also
[03:10]  * TheMuso is upgrading now, will test as well.
[03:11] <jbicha> yes I rebooted just fine
[03:11]  * TheMuso is on a fresh install from a daily over the weekend so shouldn't have problems going by what you guys are saying.
[03:12] <RAOF> Ok.  I think we should upload a new glib with an explicit Breaks: on libzeitgeist-gio, and leave seb or pitti to do a more thorough fix.  Dropping 71_gio_launch_handler.patch broke ABI; I'm not sure how they want to resolve this.
[03:12] <TheMuso> Let me reboot to be 100% sure/.
[03:17] <TheMuso> Ok all fine here.
[03:19] <RAOF> Actually, I guess we've got two options: re-add 71_gio_launch_handler.patch, or add a Breaks: to libzeitgeist-gio
[03:20] <TheMuso> I guess the question is whether the patch being dropped was accidental.
[03:21] <RAOF> No, it was deliberate; there's new upstream API which does the same thing, but differently.
[03:21] <TheMuso> Ah ok.
[03:22] <RAOF> Re-adding the patch ensures that everyone's session should start up; if we just break: libzeitgeist-gio then there are potentially other failures that we don't yet know about.
[03:23] <TheMuso> Right.
[03:24] <RAOF> Hm.  There's another ABI change, but as I read it it's API that was introduced in 2.29.6, and hence is still unstable.  So hopefully nothing's using it.
[03:39] <RAOF> Oh, wow.  It's 13:30.  That's why I'm hungry!
[03:39] <TheMuso> heh
[03:52] <RAOF> Hm.  glib's testsuite needs to be parallised.
[04:08] <pitti> Good morning
[04:09] <pitti> slangasek: (ah, ricotz offline) gnome-menus is blocking a whole lot of other gnome 3.1.5 packages; but as I uploaded it, I can't NEW it
[04:10] <pitti> slangasek: but we have it in the ubutu-desktop PPA as well for staging, so it's not totally blocking everything
[04:11] <pitti> RAOF: I don't actually know about 71_gio_launch_handler.patch; I guess I'll wait until seb128 is online, discuss it with him, and then we'll fix it today
[04:12] <RAOF> pitti: Ah, ok.  My glib build re-adding that patch has finally finished the test-suite, so if you want that I can upload it now.  If not, I'll leave it to you.
[04:13] <pitti> RAOF: please go ahead
[04:14] <pitti> RAOF: so I guess the proper fix is to port libzeitgeist-io to the new upstream API?
[04:14] <slangasek> pitti: ah, in that case allow me to expedite
[04:15] <slangasek> pitti: actually, it looks like someone else may have already done so ;)
[04:15] <RAOF> pitti: No; libzeitgeist-gio has been removed from the archive.
[04:15] <RAOF> pitti: The problem was that it hasn't been removed on upgrade, and it blocks startup of anything glib-based, which means logging in is problematic :)
[04:16] <pitti> slangasek: ah, splendid
[04:16] <pitti> RAOF: oh, so a Breaks: actually sounds right?
[04:16] <RAOF> pitti: I was deciding between re-adding the patch and just adding a Breaks: on libzeitgeist-gio, and decided to unbreak the ABI instead; I don't know how many other users of that ABI there are.
[04:17] <pitti> RAOF: ok, please wait with the upload thhen
[04:17] <RAOF> And preventing {lightdm,gdm} from starting is pretty obnoxious.
[04:17] <slangasek> you want Conflicts:, not Breaks:
[04:17] <slangasek> since Breaks doesn't guarantee removal, only deconfiguration
[04:17] <pitti> I have the new version running since yesterday without any problems
[04:18] <RAOF> Yeah, but that's a new install, right?
[04:18] <pitti> it was introduced for wncksync
[04:18] <pitti> RAOF: yes, but libzeitgeist-gio actually should be cleaned up on upgrade either way
[04:18] <RAOF> I agree.
[04:18] <pitti> RAOF: and it doesn't seem to break anything else
[04:18] <pitti> it was originally introdoced for wncksync
[04:19] <pitti> but bamf works fine with the new glib, so doesn't seem to need that any more either
[04:19] <pitti> RAOF: so my gut feeling is that we should keep the upstream API now, and clean up the old cruft properly instead
[04:21] <RAOF> I was rather thinking "as well" rather than "instead"; I just wanted to unbreak everyone's systems.  Then we could clean up later, and re-drop the patch once we were sure no one was using it.
[04:21] <RAOF> You've touched glib much, much more than me, though, so now you're up I'm happy to hand off.
[04:25] <pitti> RAOF: I'll triple-check bamf, as this seems to be the only other user
[04:26] <RAOF> It'd be kinda nice for dpkg-symbols to have some sort of support for this - when you mark a symbol with an Ubuntu or Debian version it gets recorded in the dependency data…
[04:27] <pitti> RAOF: ok, so want me to add the Conflicts:, or did you already?
[04:27] <pitti> RAOF: and thanks for figuring out the cause of this!
[04:28] <poolie> Daviey, hi?
[04:28] <pitti> sorry, this didn't occur in seb128's or my testing, I guess as we both have an upgraded natty install
[04:28] <RAOF> pitti: I haven't yet done that; I can, retest, then upload though.
[04:28] <pitti> RAOF: I can take over if you want to call it a day
[04:28] <pitti> just asking if you already did to avoid double work, but I don't see new commits in bzr yet
[04:28] <RAOF> I'm not near EOD.
[04:29] <RAOF> I've got a package with the patch re-added ready, but not one with just a conflicts.
[04:29] <RAOF> That said, it'll be trivial to whip up one with the conflicts ;)
[04:30] <pitti> RAOF: glib just built yesterday, I don't think it needs a full local run just to add a Conflicts:
[04:30] <RAOF> Fair call.
[04:36] <RAOF> Hm.  bzr doesn't seem to want to push; it's just sitting there.  I wonder what it's doing.
[04:37] <RAOF> Heh.  Too impatient.  There it goes!
[04:41] <RAOF> pitti: Done.
[04:41] <pitti> RAOF: thanks
[04:52] <pitti> slangasek: so I followed your announcement to enable multiarch, and apt-get update indeed did get all the i386 indexes
[04:54] <pitti> so it's "sudo apt-get install flashplugin-installer:i386" now, right?
[04:54] <pitti> that at least seems to pull in a lot of i386 dependencies
[04:54] <StevenK> Can we purge ia32-libs now? :-)
[04:54] <pitti> I suppose we should make the firefox plugin installer clever enough for this now
[04:54] <ajmitch> StevenK: you seem eager to kill it :)
[04:54] <pitti> StevenK: parner stuff still needs it
[04:54] <pitti> ajmitch: who isn't?
[04:54] <pitti> like this little package "skype"
[04:55] <pitti> ia32-libs has been a thorn in our eyes forever
[04:55] <micahg> pitti: apparently skype doesn't need it according to slangasek
[04:55] <ajmitch> who doesn't love a large monolithic binary package that must give the security team headaches?
[04:55] <pitti> slangasek: so, congratulations! that was a great piece of work
[04:55]  * ajmitch feels sorry for whoever's had to touch it
[04:55] <micahg> ajmitch: we're not talking about chromium right now :)
[04:55] <pitti> lolo
[04:55] <ajmitch> micahg: hah
[04:56] <ajmitch> micahg: it still bundles half the world? :)
[04:56] <micahg> yep
[04:56]  * ajmitch is glad to see multiarch, thanks to those who've implemented it 
[04:57] <pitti> hmm, now I just need to tell firefox somehow that the plugin is "on the other side of the arch fence"
[04:59] <StevenK> pitti: Partner? Who uses that anyway? :-P
[05:01] <ion> A major Finnish bank uses a really nasty Java thing for web banking access that only works with sun-java6-plugin. The partner repo is a decent way to get it.
[05:43] <slangasek> pitti: yay :)  be careful though, you may need to purge the amd64 flashplugin-installer package before installing the i386 one... dpkg seems to get a bit confused when transitioning a non-multiarch-same package directly from one arch to another
[05:44] <pitti> slangasek: that's what I did, and the install went cleanly; but if ffox is supposed to pick that up, I'll just try again, I suppose
[05:44] <slangasek> oh - you still need nspluginwrapper installed
[05:45] <slangasek> did you remove it?
[05:45] <pitti> oh, indeed
[05:45] <pitti> I thought flashplugin-installer would pull it in
[05:45] <slangasek> (I still need to touch the flashplugin package to represent this in some sensible fashion)
[05:45] <pitti> didn't help, though
[05:46] <slangasek> yeah, the amd64 flashplugin-installer does, the i386 one doesn't - it may be simplest to just make it a dependency
[05:46] <pitti> ooking for plugins in /var/lib/flashplugin-installer/
[05:46] <slangasek> didn't help?
[05:46] <pitti> Update plugin /var/lib/flashplugin-installer/npwrapper.libflashplayer.so
[05:46] <pitti>   wrapper ident matches and NPAPI plugin is unmodified, skipping
[05:46] <pitti> perhaps I need to install the wrapper first, and then flashplugin-installer
[05:46] <slangasek> hmm
[05:46] <slangasek> I honestly don't know
[05:47] <pitti> if it works for you, then I guess I just did something wrong, or have some cruft on my system
[05:50] <slangasek> you could be right that nspluginwrapper needs to be installed before flashplugin-installer
[05:50] <pitti> that didn't help either, thoug
[05:51] <slangasek> hmm
[05:51] <slangasek> restarted firefox after installing?
[05:51] <pitti> yes, sure
[05:51] <slangasek> shows up in about:plugins, or no?
[05:51] <pitti> it doesn't
[05:51] <pitti> sudo dpkg -P flashplugin-installer:i386 nspluginwrapper:i386
[05:52] <pitti> and trying to reinstall both
[05:52] <slangasek> oh, you need the amd64 version of nspluginwrapper :)
[05:52] <pitti> should I clean up anythign else?
[05:52] <pitti> ah!
[05:52] <slangasek> nspluginwrapper is the bit that's the *plugin* for firefox :)
[05:52] <slangasek> so has to match arch
[05:52] <pitti> that's not installable on amd64
 it's in NEW
[05:53] <slangasek> :-)
[05:53]  * pitti just feels the urge to do some archive admin
[05:54] <micahg> in theory, we can solve the nspluginwrapper issue for firefox, but other things need nspluginwrapper
[05:56] <slangasek> only in theory; the existing plugin-container doesn't do the job because it doesn't provide an interface for registering the foreign-arch plugin w/ firefox to begin with
[06:50] <statim> general newb packaging question: would it be a really bad idea to have the build script download the original tar from somewhere, then extract, make, install? im not sure if that makes things more maintainable or not?
[06:50] <infinity> statim: Our buildds have no access to the internet.
[06:51] <infinity> statim: So, if that's destined for an archive, that's a huge "no".
[06:51] <infinity> statim: (It's also quite possibly a license violation, if it's GPL or similar, since binaries and source need to be distributed together)
[06:53] <RAOF> It's also generally a good idea for maintainability to have reproducible builds; downloading the tarball from the internet breaks that.
[06:53] <statim> infinity:  cool thanks.  im actually just trying to figure this out to make my own packages for a few things, but i should do it the best way as you suggest.  im nowhere near understanding this enough to make packages that would make it into the official repos
[06:58] <statim> i built something with pbuilder-dist, and now my ~/pbuilder/lucid_result/ has all these .deb files in it.  is there a special way to clean that out before i build something else, or just rm?  i already ran pbuilder-dist lucid clean, but that doesnt remove those deb files
[06:59] <micahg> statik: no need to remove them
[07:01] <micahg> statik: oops, tab complete failure :)
[07:01] <micahg> statim: no need to remove them
[07:01] <statim> micahg:  ok, so its just for my benefit to keep them… pbuilder doesnt care about them really, it just puts them there for me
[07:01] <micahg> statim: yep, up to you, it's just a storage dir AFAIK
[07:01] <statim> micahg: cool thanks
[07:12] <dholbach> good morning
[07:13] <Daviey> Good morning Mr Holbach!
[07:15] <ion> morning
[07:17] <dholbach> hey Daviey, hey ion
[07:34] <pitti> happy birthday, Debian! 18 years, coming of age
[07:35] <Quintasan> Good morning
[07:37] <ogra_> pitti, finally at drinking age :)
[08:01] <Laney> cjwatson: serialisation> yeah, that would be nice. TBH lpapicache has grown a lot since I was involved at its genesis (when it was genuinely just a caching wrapper) and I'm not sure of all of the moving parts at this moment in time.
[08:25] <tumbleweed> slangasek: the multi-arch: same with differing files problem I mentioned in bug 802901 was in libfontconfig1's doc (I had symlinks, package didn't). But I have no idea where that came from, so I can't reproduce it it.
[09:55] <jml> if gtk-window-decorator crashes, what's the least interfering way to get it back up?
[09:56] <pitti> Alt+F2 gtk-window-decorator
[09:56] <pitti> that worked for me
[10:05] <RAOF> If gtk-window-decorator crashes, it's saving you from it's memory leak ;)
[10:12] <jml> RAOF: hooray?
[10:12] <jml> pitti: ta
[10:12] <RAOF> jml: Indeed.
[10:27] <doko_> soren, would it be possible to disable the ubuntu-server-qa repository for some days until the test rebuild is done?
[10:34] <dholbach> barry, Riddell: can you answer https://bugs.launchpad.net/ubuntu-packaging-guide/+bug/827925?
[10:34] <ScottK> slangasek: It looks like we need to put qdbus back into some non-dev package (I'm guess it's own) and adjust dependencies.  I'll be offline most of today for $work, but can help with this in 10 or 12 hours.
[10:43] <ev> would someone be so kind as to provide peer review on this move of camerabin from gst-plugins-bad to gst-plugins-good? http://paste.ubuntu.com/668124/ http://paste.ubuntu.com/668125/
[10:45] <tseliot> cjwatson: would it be acceptable if I forced the removal of the old kernel hooks left in /etc by nvidia-common in, say, the preinst script of nvidia-common? (this should prevent the kernel installation from failing)
[10:53] <cjwatson> tseliot: which exactly?
[10:53] <tseliot> cjwatson: /etc/kernel/postinst.d/nvidia-common and  /etc/kernel/header_postinst.d/nvidia-common
[10:59] <cjwatson> tseliot: sure, if a newer version removes them then I think cleaning them up in the preinst is the right thing to do
[10:59] <tseliot> cjwatson: yes, this is exactly the case. Thanks
[11:00] <soren> doko_: Sure. Hang on.
[11:00] <soren> doko_: Done.
[11:00] <doko_> thanks!
[11:22] <RAOF> slangasek: You may be interested in bug #827950
[11:22] <RAOF> slangasek: I hope that the description is clear enough; I found it difficult to describe.
[11:40] <cjwatson> argh, I hate dpatch
[11:40] <cjwatson> I always always always forget to add new patches to debian/patches/00list
[11:40] <pitti> cjwatson++
[11:41] <seb128> heh, I used to hate quilt for the same reason :p
[11:41] <pitti> quilt does add stuff to series automatically
[11:41] <seb128> if you use the right quilt commands
[11:42] <seb128> I tend to cp the vcs diff in debian/patches
[11:42] <cjwatson> if you use the natural quilt commands for creating new patches, yes :-)
[11:42] <seb128> which "just work" with cdbs simple-patchsys
[11:42] <cjwatson> as opposed to dpatch-edit-patch, which doesn't
[11:43]  * cdbs simple-patchsys sucks when it comes to managing a gazillion patches
[11:43] <mvo> edit-patch ftw!
[11:44] <mvo> or add-patch for this matter
[11:44] <cjwatson> yeah, I got fed up and de-simple-patchsysed grub2 at some point because the process of refreshing to a new upstream version was ridiculously tedious
[11:44] <cjwatson> mvo: I probably ought to remember that, yes :)
[11:44] <seb128> mvo, ;-
[11:44] <seb128> mvo, ;-)
[11:45] <mvo> I guess cdbs/dpatch should have a debian/00list, debian/patches: *AUTOMATIC-KTHXBYE* option to add there
[11:45] <mvo> that would just use whatever is in the dir
[11:47] <cjwatson> mvo: this particular package has patches in debian/patches/ that aren't applied :-/
[11:47] <mvo> heh, there we go
[11:48] <mdeslaur> ah, debian packaging, so much fun :)
[11:51] <cdbs> compiz --replace
[11:51] <cdbs> err whoops, gnome-terminal tab fail
[12:12] <Laney> does anyone have a non-virtual ppa that they'd be willing to chuck a test build of mono's 2.10 branch at for me?
[12:12] <Laney> seeing failures on buildds but not locally or on virtual builders
[12:12] <OdyX> tkamppeter: Ping. I have a question about pyppd: does it hurt if, for all drivers, it is launched as "pyppd /usr/share/" (aka the path from there is in the pyppd-generated archive) ?
[12:13] <OdyX> tkamppeter: That would make things way easier, and avoid having to parse and handle an option
[12:17] <OdyX> (context being: dh_pyppd to be added to pyppd, in order to "just" put --with pyppd in the dh $@ line and be done with it.)
[12:28] <mdeslaur> what package is Oneiric's battery indicator from?
[12:32] <pitti> mdke: indicator-power
[12:32] <pitti> sorry
[12:32] <pitti> mdke: ignore me, wanted to respond to mdeslaur, tab failure
[12:36] <Sweetshark> doko_: ping?
[12:38] <Sweetshark> doko_: the "remove Matthias Klose who is no longer involved in this package" was not by me but by the upstream debian dev packaging 1.9.0-1 ....
[12:39] <lool> stgraber: Is it ok to commit a pastebinit paste.linaro.org to collab-maint, or should I file a bug?
[12:39] <lool> oh actually that's not upstream
[12:48]  * jdstrand wonders why his /tmp directory isn't having its directories autocleaned on boot...
[13:31] <mr_pouit> seems a few more sync mails leaked out from the test environment (debootstrap 1.0.35 and mono 2.10.4-2)
[13:31] <cjwatson> mr_pouit: those were real
[13:32] <debfx> slangasek: is it intentional that apt doesn't install recommends of foreign arch packages?
[13:32] <mr_pouit> oh, indeed
[13:32] <cjwatson> mr_pouit: I'll be announcing the new facility soonish, we're just finalising the client tool
[13:33] <cjwatson> mterry: did my netbook-launcher-efl branch look plausible?
[13:34] <mr_pouit> cjwatson: okay, nice. They have the same "incomplete" mail (without the .changes), that's why I thought they were the same ;-)
[13:34] <mterry> cjwatson, ah, sorry. I bookmarked it to get back to it.  I can review now
[13:34] <cjwatson> mr_pouit: ah, no, missing the changes is kind of inevitable for this mechanism
[13:34] <directhex> of course, mono's breaking due to a random problem that only seems to happen on the real ubuntu buildds, not locally or in a ppa. woohoo
[13:34] <cjwatson> mr_pouit: the thing that tipped me off about the aptitude one was that it was marked as signed-by somebody without Ubuntu upload privileges :-)
[13:34] <cjwatson> mr_pouit: but if you look closely you can also see that it has a link to dogfood.launchpad.net
[13:35] <cjwatson> mterry: cool, thanks
[13:35] <mr_pouit> huhuhu, ok ;-)
[13:56] <mterry> cjwatson, yeah, seems fine to me
[13:56] <mterry> cjwatson, I'm putting the change in upstream trunk too
[13:57] <cjwatson> mterry: great, thank you
[13:57]  * cjwatson chips away at the EFL stack nightmare
[13:59] <mterry> cjwatson, shall I merge to Ubuntu or will you?
[14:03] <cjwatson> mterry: don't mind, I can if you like
[14:04] <mterry> k
[14:06] <cjwatson> done and uploaded
[14:18] <tkamppeter> OdyX, no problem.
[14:18] <OdyX> tkamppeter: okay, nice.
[14:39] <bdmurray> ev: could you merge https://code.launchpad.net/~brian-murray/ubuntu/oneiric/apport/bug-828037/+merge/71901
[14:39] <ev> whoops, I still have that hat on
[14:39] <ev> sure thing
[14:39] <ev> @pilot out
[14:39] <bdmurray> heh thanks
[14:39] <ev> will do in about 5
[15:12] <ryanakca> Is there somewhere I can find a history / archive of Sources.bz2 and binary-i386/Packages.bz2 for the past few years? Similar to http://snapshot.debian.org/archive/debian/YYYYMMDD/dists/sid/main/* , where YYYYMMDD is the day you're interested in?
[15:13] <cjwatson> not as far as I know.  You can approach the problem from other angles since https://launchpad.net/ubuntu/+source/SOURCEPACKAGENAME/+publishinghistory has history for each source package
[15:23] <debfx> slangasek: turns out that flashplugin-installer didn't pull in libasound2-plugins because I had libjack-jackd2-0 installed which isn't multiarch'ified yet
[15:23] <ryanakca> cjwatson: Aye, I've been using launchpadlib to fetch source publishing histories for the past week and a half with no sign of it ending. Putting those back together and outputting Packages.bz2 and Sources.bz2 for Thursdays of every week isn't going to be very pleasant. Thanks :)
[15:24] <cjwatson> ryanakca: sorry not to be able to help more
[15:25] <ryanakca> cjwatson: No worries
[15:28] <slangasek> debfx: oh, well, doh.  I have never understood why those two libraries conflict with each other the way they do
[15:31] <tumbleweed> ryanakca: we have ubuntu upload history in a UDD table in Debian (if you have access to that. you can also download a dump). That should corrospond to source publishing history, but not binary
[15:31] <tumbleweed> hrm, I suppose that won't give you removals
[15:34] <cjwatson> tumbleweed,bdrung_vacation,Laney: any more thoughts on https://code.launchpad.net/~cjwatson/ubuntu-dev-tools/syncpackage-lp/+merge/71718 ?
[15:35] <cjwatson> there were some moderately substantial changes in the last couple of commits, I realise
[15:36] <tumbleweed> cjwatson: I'm happy with it
[15:37] <slangasek> tumbleweed: libfontconfig1> hmm, very strange; if it's not reproducible though, guess there's no action to take
[15:37] <tumbleweed> the symlinks were to ../libfontconfig1/$name, IIRC
[15:38] <slangasek> ScottK: qdbus> yep, sounds like it; I'll try to get that fixed up this morning
[15:39] <Laney> cjwatson: yeah, fine by me. We need to clean up the API in ubuntutools, but that's for another day
[15:40] <cjwatson> I think the JSON serialisation could be handled by making BaseWrapper a subclass of whatever the lazr Resource class is
[15:40] <cjwatson> but that seemed a bit intrusive to attempt in this branch
[15:40] <tumbleweed> should we change requestsync to say "you can sync yourself if you want"?
[15:41] <cjwatson> hm, yes, I can do that
[15:41] <cjwatson> at least in the manual page
[15:41] <Laney> it should Just Do It IMHO
[15:41] <tumbleweed> it should only be necessary for sponsored syncs and FFe requests now
[15:41] <Laney> or bail out with the commandline you need to run
[15:42] <cjwatson> hm, I'm not ready to do that yet
[15:42] <cjwatson> for a while, I'd prefer it to be opt-in
[15:42] <tumbleweed> sounds good
[15:42] <Laney> fair
[15:42] <cjwatson> though I agree once this has bedded down a bit
[15:42] <Laney> give a notice then
[15:42] <tumbleweed> urgh, the changelogs really are ugly without newlines
[15:44] <cjwatson> yeah, I know, sorry :-(
[15:44] <cjwatson> the import's been fixed but can't do much about the existing data
[15:44] <cjwatson> committed a change to requestsync(1)
[15:44] <cjwatson> maybe I should have requestsync itself output a line
[15:45] <tumbleweed> oh, I didn't realise those were from when the debian archive was imported
[15:45] <cjwatson> yeah
[15:45] <cjwatson> current imports are OK
[15:45] <Laney> can't a query be run over the old data to fix it up?
[15:45] <cjwatson> e.g. https://lists.ubuntu.com/archives/oneiric-changes/2011-August/006951.html came out OK
[15:45] <cjwatson> Laney: I don't know, feel free to ask
[15:45] <cjwatson> (well, OK apart from the spurious newline, I filed a bug about that)
[15:46] <slangasek> RAOF: bug #827950 answered; sorry, it's not a /great/ answer though
[15:48] <seb128> does it make sense to support static build for things like GNOME libraries nowadays? just asking because they switched some of their tarballs to default to not build the static libs
[15:48] <seb128> so I'm pondering either updating the .install to drop the .a or adding a --enable-static to configure
[15:48] <cjwatson> Laney: brief note added to requestsync
[15:49] <ryanakca> tumbleweed: Thanks
[15:49] <tumbleweed> ryanakca: don't know how helpful it'll be for what you want, though
[15:52] <slangasek> seb128: I think the "nowadays" that people normally include in that question is something of a red herring; the use case for static linking has always been a narrow one and I don't know that it's diminished significantly over time
[15:53] <seb128> slangasek, ok, worded differently "do we care about being able to do static builds on Ubuntu"
[15:53] <slangasek> seb128: we could certainly argue that .a files are a waste of archive space; if we're going to drop them, though, I think we should be systematic about it
[15:53] <seb128> right, archive space and build time
[15:54] <seb128> I wouldn't mind to get ride of the extra build gtk is doing only for static
[15:54] <stgraber> lool: patch upstream would be great. Then feel free to get that patched in Debian/Ubuntu as I don't expect a new upstream release very soon (next version will likely be a rewrite)
[15:56] <flecha> Hello! Is the a way to set a hotkey to a menu bar applet?
[15:59] <tumbleweed> cjwatson: it does concern me that +localpackagediffs lets non-archive-adimns so easily sync so many packages at once (or select the wrong package by mistake). I'd prefer individual sync buttons (or the use of the command line client). Mind you I assume it asks for confirmation?
[16:05] <cjwatson> tumbleweed: that's why I'm encouraging Ubuntu people to use the API instead :-)
[16:05] <dobey> pitti, ScottK: new release files attached to bug #817133
[16:05] <cjwatson> I really don't want people using that UI, but it's not within my power to do anything about it
[16:05] <tumbleweed> right
[16:05] <cjwatson> tumbleweed: I'm not sure what confirmation is involved; please do file bugs about UI concerns and tag them derivation ...
[16:06] <tumbleweed> sure, I'll test it next time I do a sync
[16:06] <cjwatson> IMO when we change the Ubuntu sync documentation it should just not mention that UI at all and pretend it doesn't exist
[16:06] <cjwatson> I think it was written more for Linaro than for us ...
[16:07] <tumbleweed> yeah
[16:08] <cjwatson> also, it's not possible to apply Ubuntu-specific policy in the UI
[16:08] <cjwatson> for example the specific requirement for confirmation if the version number contains 'ubuntu'
[16:10] <Laney> It probably wouldn't be unreasonable for a distro to be able to set a header on that page, though
[16:10] <Laney> like the bug reporting guidelines
[16:10] <cjwatson> yeah, but workflow is harder and unlikely to happen
[16:11] <cjwatson> I'd rather just direct people to good API tools
[16:11] <cjwatson> unless the header was "do not use this page" I suppose :-)
[16:11] <Laney> or you could ask for a policy knob to disable the UI
[16:12] <Laney> or to limit it to a certain team, or … :-)
[16:14] <Quintasan> slangasek: ping
[16:14] <Laney> or, well, see if it actually becomes a problem
[16:27] <slangasek> Quintasan: hi
[16:28] <Quintasan> slangasek: Oh hey there, I was wondering what's status of qdbus stuff
[16:30] <slangasek> Quintasan: I'm looking to split out a qdbus binary package and have libqt4-dbus depend on it; currently test-building
[16:30] <Quintasan> slangasek: That's the solution fabo proposed, right?
[16:31] <slangasek> yes
[16:31] <Quintasan> Okay, let me know if you need any help
[16:31]  * Quintasan goes back to kwin opengles
[16:31] <slangasek> Quintasan: where did you discuss this with fabo, OOI?
[16:32] <Quintasan> OOI? What's that?
[16:32] <slangasek> "out of interest" :)
[16:32] <slangasek> just the comment on the bug (825689), or was there more out-of-band discussion?
[16:32] <Quintasan> https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/825689
[16:33]  * slangasek nods
[16:33] <Quintasan> and on OFTC I think but I didn't discuss it personally
[16:33] <slangasek> just checking that there weren't any new bug reports I wasn't aware of
[17:27] <Beret> I see that debdelta support was planned for Oneiric. Does anyone know if that's still on track to happen?
[17:35] <jcastro> Beret: there's a blueprint somewhere with the status, it was discussed but not on the cards for oneiric
[17:36] <Beret> yeah I found it at https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-debdelta
[17:36] <Beret> it says "accepted for oneiric"
[17:36] <Beret> what's the mean?
[17:37] <slangasek> it means that the design was approved coming out of UDS; it doesn't guarantee that the work will land
[17:37] <Beret> got it
[17:37] <Beret> do we know if it's slated to land by 12.04 or will we find that out in Orlando?
[17:38] <Beret> I have some work dependent on it which is why I'm asking
[17:38] <Beret> just trying to get as much information as I can
[17:39] <slangasek> I currently believe it's likely to land by 12.04, but it's contingent on having an appropriate server-side implementation
[17:39] <Beret> ok
[17:39] <Beret> thanks for the info
[17:39] <Beret> that's what I was looking for
[17:43] <Laney> siretart: are you looking at the libav nbs?
[18:06] <chrisccoulson> hey jcastro, how are you?
[18:07] <jcastro> chrisccoulson: hi
[18:07] <chrisccoulson> hi jcastro, did you see my earlier ping?
[18:08] <jcastro> chrisccoulson: nope, sorry, I've been in and out, what can I do for you?
 jcastro, do you have any ideas for how we could engage more users and get them testing https://launchpad.net/~mozillateam/+archive/firefox-next (ie, the firefox beta channel)?
[18:09] <chrisccoulson> (from #ubuntu-desktop)
[18:09] <chrisccoulson> sorry if you're not the right person to ask ;)
[18:20] <siretart> Laney: yeah, sort-of. I've worked on mplayer a few hours ago: http://packages.qa.debian.org/m/mplayer/news/20110817T173341Z.html - I guess we should sync that to oneiric
[18:23] <slangasek> SpamapS: fwiw, slapd forking before listening should be fixed upstream and in oneiric now (following a horrible first at a patch landing in Debian and corrupting people's databases for a bit in squeeze)
[18:32] <Laney> siretart: I just noticed that the nbs list is pretty large
[18:37] <micahg> Laney: this might be a better guide: http://people.canonical.com/~ubuntu-archive/transitions/libav.html
[18:49] <Laney> yep, still a reasonable size
[18:53] <hallyn> slangasek: Hey - I assume bug #828262 is not possible (it's a new binary package in the lxc source package).  But since a great deal of users on natty/oneiric will want LTS in their containers, it would be awesome if it were
[18:53] <hallyn> (so I asked him to submit that, pls yell at me not him :)
[18:56] <hallyn> really all the stuff in lxcguest i should try and push into the other packages.  there'll be resistance, but...
[19:09] <SpamapS> slangasek: OH
[19:09] <SpamapS> slangasek: It didn't appear to be fixed in the latest one I pulled from oneiric
[19:32] <siretart> Laney: well, yes. and I could really need help on it. most of the patches are IME rather easy, though
[19:33] <tkamppeter> pitti, hi
[19:34] <micahg> siretart: is there a guide similar to this one for libnotify from Fedora: http://lists.fedoraproject.org/pipermail/devel/2010-November/144914.html
[19:35] <slangasek> SpamapS: patch not applied at unpack time, I suspect
[19:36] <siretart> micahg: well, there is http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=blob;f=doc/APIchanges, also installed into libavcodec53
[19:36] <siretart> micahg: if you have a specific build failure, I'm happy to take a look
[19:37] <SpamapS> slangasek: ahh right.. should have dug through that ;)
[19:37] <SpamapS> slangasek: its been taken upstream though, right?
[19:37] <slangasek> hallyn: 828262> that looks like a candidate for lucid-backports? https://bugs.launchpad.net/lucid-backports
[19:38] <slangasek> SpamapS: the patch we currently carry originates upstream, yes
[19:59] <SpamapS> woot, only 1515 lines in the mysql copyright file.. :-/
[20:18] <hallyn> slangasek: ok, thx ( SpamapS had suggested same).  i've never felt (even reading the docs) i quite groked how backports flow, but i'll try that route.
[20:45] <jbicha> slangasek: multiarch is a bit annoying in tools like Synaptic, USC does a decent job of hiding the extra data clutter
[20:46] <jbicha> is multiarch something that we should have turned on by default for everything in Ubuntu or just certain libraries & programs?
[20:51] <groundnuty> hey, is there some nice list of packages from which ubuntu (standard distrubuntion) is made of? preferably with some comments, this one do that, that one does something else. (I figgured it is best to ask here then on #ubuntu)
[20:51] <slangasek> jbicha: it's not at all trivial to "turn it on" selectively
[20:52] <jbicha> slangasek: ok, I was just thinking out loud
[20:53] <slangasek> jbicha: it's a reasonable idea, but I think this needs to be fixed by the package managers getting smarter, not by trying to filter this on the server side
[20:53] <dobey> groundnuty: list yes, descriptions in that list, no; there is a .manifest for each image on cdimage.ubuntu.com, iirc
[20:53] <slangasek> because it's just too dynamic
[20:54] <slangasek> groundnuty, dobey: you might be looking for the package seeds: https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.oneiric/
[20:54] <slangasek> (this is the source that decides what we put on the CDs)
[20:56] <groundnuty> slangasek: thx, I was generally wondering from what that ubuntu is made of - I assume you you do not chose the packages (mostly 3rd party apps) randomly ;)
[20:58] <dobey> we use darts, so there are actualy a lot of physics involved; not random at all. ;)
[21:00] <slangasek> heh
[21:00] <broder> what's the deal with the new ubuntu core thing i saw skaet mention in her interview? is it just sticking a pretty title on core+desktop-core?
[21:03] <groundnuty> dobey: some derivations of montecarlo methods? ;P
[21:05] <dobey> something like that
[21:07] <groundnuty> dobey: anyway, there arent any discussions publicly aviable? Like: "lets pick that package because... no no! thats better" ;)
[21:07] <groundnuty> I mean logs/forums
[21:08] <dobey> groundnuty: well, there are discussions at UDS for big things usually
[21:09] <slangasek> for instance, there are fairly regular discussions about which browser and groupware solution we should ship by default
[21:09] <jbicha> groundnuty: you could poke around here: https://blueprints.launchpad.net/ubuntu/oneiric
[21:09] <groundnuty> slangasek: I imagine :)
[21:10] <slangasek> most other discussions tend to be about "can we make it fit on a CD?" or "how do we make this fit on the CD?" rather than about *which* app we're going to ship
[21:10] <slangasek> since the Ubuntu desktop is 90% standard what ships with GNOME upstream
[21:11] <groundnuty> I see. Btw why you still stick with cd-s? aren they kinda deprecated?
[21:12] <slangasek> that is *also* a fairly regular discussion ;)
[21:12] <groundnuty> :)
[21:12] <slangasek> https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-great-cd-debate
[21:13] <groundnuty> imagine windows vista/7/8 shipped on the 700MB cd...
[21:13] <groundnuty> I suppose they gave up long ago.
[21:14] <groundnuty> anyway, thx for all the links I will make some tea and study them.
[21:25] <slangasek> ScottK: qdbus should be a-sorted now
[21:25] <slangasek> (with apologies to the ARM team)
[21:32] <ScottK> slangasek: Thanks.
[21:33] <bluefoxicy> I have a question
[21:33] <bluefoxicy> Has anyone ever actually tried unchecking things to install in update-manager?
[21:33] <bluefoxicy> Because it flat out doesn't work; the damn thing installs every single available update.
[21:33] <bluefoxicy> 905k to download => downloaded 1% of 18MB
[21:34] <slangasek> I do it all the time and it works as intended
[21:34] <debfx> slangasek: could you have a look at my debdiff on bug #828360
[21:37] <bluefoxicy> hmm, odd.
[21:38] <slangasek> debfx: does dh_makeshlibs not DTRT if you drop the override entirely?
[21:39] <slangasek> hmm, it seems to set an SONAME, so I guess not
[21:39] <bluefoxicy> http://img845.imageshack.us/img845/3158/screenshot4lv.png
[21:39] <bluefoxicy> this is what I get.
[21:40] <slangasek> debfx: all looks sane to me, but the proof is in the pudding :)
[21:41] <debfx> slangasek: aha, I was wondering why it treated it as a public library even though it's not in a standard path
[21:41] <statim> would anyone mind helping me with this? ive created a specific package of ruby for only my own purposes.  im trying to get the Depends, Conflicts, Replaces, Provides worked out so my own ruby package will take complete control over all things ruby.  ive tried adding all of these: ruby, ruby-dev, libruby, rdoc, ri, irb, rubygems in each form (null, 1.8, 1.9, 1.9.1) to each field of Conflicts, Replaces, Provides, but that doesnt seem to satisfy it.  any hel
[21:42] <debfx> slangasek: I have tested it with the flash context menu :D
[21:43] <slangasek> bluefoxicy: well, I unchecked a package twice today in update-manager to avoid upgrading it, so I know it works in general; file a bug?
[21:44] <bluefoxicy> hmm.
[21:45] <slangasek> statim: you cut off at the IRC line limit - but this channel is for development *of* Ubuntu, local packages that conflict with Ubuntu ones (and, quite frankly, are going to make a terrible mess of your system even if you solve your current challenge) are off topic
[21:46] <statim> slangasek:  gotcha thanks.  where would i find this kind of help? just #ubuntu or are there other specialized places?
[21:46] <slangasek> #ubuntu is the only place that comes to mind
[21:46] <statim> slangasek: k thanks
[21:46] <slangasek> but also, see above that you're going to make a mess of your system trying to do this :)
[21:48] <ajmitch> bluefoxicy: you left firefox-gnome-support checked, which depends on the updated firefox. I think update-manager would try & satisfy all dependecies rather than skip that package
[21:48] <ajmitch> still a bug if it's not making clear what it'll do
[21:48] <statim> slangasek:  yes i know … these boxes we use now adays are ephemeral though, and we have provisioning checks to make sure all our stuff works… we dont keep them indefinitely and do updates… i wouldnt recommend what im doing for everyday use haha
[21:48] <slangasek> ajmitch: I wondered about that; historically, when you uncheck a package in u-m that has reverse dependencies, those revdeps will also be unchecked for you
[21:49]  * Daviey wonders when we can finally throw dpatch on a fire.
[21:49]  * ajmitch hasn't looked to see what its intended behaviour is
[21:51] <bluefoxicy> ajmitch:  aha.
[21:51] <OdyX> tkamppeter: c2esp and epson-inkjet-printer-escpr have been migrated to cups' new trigger + dh_pyppd.
[21:51] <bluefoxicy> ajmitch:  I wasn't even looking :)
[21:55] <cjwatson> Daviey: debian-devel, algernon says he's set himself a target to deprecate it by 2017 :)
[21:56] <cjwatson> which actually is about the first realistic target I've seen this year
[21:56]  * ajmitch wonders if cdbs will ever be deprecated
[21:57] <cjwatson> now in that case nobody's convinced the maintainer yet ...
[21:57] <ajmitch> it works well for a lot of simple things, so I doubt it'll die off
[21:57] <Daviey> cjwatson: That is good news.
[21:57] <slangasek> trying to convince the maintainer to deprecate it is not how I would go about it
[21:58] <cjwatson> http://people.debian.org/~cjwatson/dhstats.png is a pretty clear pattern
[21:58] <Daviey> cdbs still has a few targets that other patch systems hasn't yet addressed.
[21:58] <cjwatson> a hard core of stuff sticking with it, almost no movement at all of the cdbs line up or down
[21:58] <slangasek> maybe I should get active on debian-mentors again and refuse to sponsor anything that's not dh(1) :)
[21:58] <cjwatson> there is no problem with dh(1) growing
[21:58] <slangasek> yeah
[21:59] <broder> cjwatson: what's debhelper 7 in that chart? is that just classic long-form debhelper with a >=7 compat level?
[22:00] <cjwatson> broder: it's Build-Depends/Build-Depends-Indep implies debhelper (>= 7)
[22:00] <broder> and the "debhelper" line is all-inclusive?
[22:00] <cjwatson> that's BD/BDI implies debhelper
[22:00] <cjwatson> and the dh(1) line is a grep of debian/rules for /^\s+dh\s+/
[22:01] <cjwatson> (well, perl regex)
[22:01] <cjwatson> probably not perfect but close enough
[22:02] <slangasek> Daviey: what patch system targets do you have in mind?
[22:02] <cjwatson> Daviey: YM build systems rather than patch systems?
[22:03] <slangasek> eew, why is all of haskell using cdbs
[22:05] <slangasek> looks like there's also a maven cdbs class, but no dh equivalent
[22:05] <Daviey> slangasek: Well not strictly patching - but the cdbs gems, things like the maven support in cdbs
[22:05] <Daviey> well, not patching at all.. but YKWIN
[22:06] <ajmitch> the langpack stuff for cdbs, was that reimplemented for dh?
[22:06] <slangasek> ajmitch: yes
[22:07] <slangasek> Daviey: I think I could be persuaded to port maven.mk to dh
[22:08] <Daviey> slangasek: you may or may not become jamespages best friend.
[22:09] <slangasek> quite a bit of magic in here, tss