[00:02] bryceh, thanks [00:02] is there anything in specific I should be looking for? [00:03] jono, I would look for an error message or stack trace [00:03] looking throught he lightdm logs there are no errors [00:03] and I dont see errors in the Xorg.0.log* files [00:05] bryceh, it does say in the syslog that plymouth-stop terminated with status 1 and lightdm main process terminated with status 127 [00:05] not sure what those statuses mean [00:05] that would be your culprit [00:06] bryceh, what do those statuses mean? [00:06] non-zero exit code generally means the program failed [00:07] I don't think it's lightdm [00:07] I can't plain startx at all [00:07] even if I remove lightdm from the equation [00:07] 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] that wouldn't explain being unable to startx manually [00:08] jono: it's often not possible to assign a specific meaning to exit codes [00:08] cjwatson, when I run startx as a user it says the user is not authorized to run the X server [00:08] not from the exit code alone anyway [00:08] 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] 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] true, but that's a hell of a lot to infer from plymouth-stop exiting 1 [00:09] jcastro, pastebin your output from running startx [00:09] jono: is there a plymouth process running? [00:09] slangasek, nope [00:09] 'plymouthd' rather [00:09] startx doesn't work as an unprivileged user [00:09] but that's separate [00:11] is there a way for my to try and boot without plymouth so I can see if that is causing the issue? [00:12] broder, I assume running startx as root would not work either? [00:12] Is plymouth used from the recovery entry on grub? because I tried that too [00:12] 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] cjwatson, ahhh I see [00:12] which would be sufficient to eliminate it from this question [00:13] was there a recent plymouth release over the last day? [00:13] the recovery entry does not use 'splash', so if it exhibits the same problem, it's not plymouth's fault [00:13] I have the problem and I don't have "splash" [00:13] jono, your /var/log/dpkg.log should show what packages were updated since yesterday [00:14] was there a kernel update? [00:14] just checking now [00:15] I tried with an older kernel too. :-/ [00:15] hmm [00:16] plymouth hasn't changed for a month or so [00:16] I think you can safely rule it out [00:18] there was mainly some gtk3 and initramfs updates [00:19] new libglib too [00:20] wonder what the initramfs change was [00:20] initramfs-tools itself hasn't been updated; the breakage could be caused by whatever triggered an update to your initramfs though [00:21] hmmm [00:22] 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] 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] aha! [00:25] makes sense :-) [00:25] so any suggestions, folks? [00:25] Which, incidentally, means that intel and nouveau won't work from recovery mode, as they require kms. [00:25] anything else I can do to help track the issue down? [00:28] 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] bryceh, will do [00:29] 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] no worries [00:30] huh, has that always been the behavior of recovery mode? I didn't remember 'nomodeset' being there before [00:30] slangasek, I just tried to run startx as root from a normal session and still no luck [00:30] 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] jono, what printed out when you ran it? "no luck" isn't a normal X error ;-) [00:31] bryceh, xinit: connection to X server lost [00:31] jono: ~/.xsession-errors [00:31] 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] waiting for X server to shut down: ddxSigGiveUp: Closing log [00:32] the good news is if both jono and jcastro are seeing the same bug, it should be easy to reproduce [00:32] RAOF: I thought kms was always supposed to work ;p [00:32] gnome-session: symbol lookup error: /usr/lib/gio/modules/libgiozeitgeist.so: undefined symbol: g_desktop_app_info_launch_handler_get_type [00:32] Well, at least we should have a useful Xorg.0.log :) [00:32] ooh, I get that same ddxgiveup thing [00:32] also, the tradeoff is that now recovery mode is less useful for debugging other failures that weren't kms-related [00:33] Sarvatt: should be non-fatal, just means gnome-session won't load zeitgeist integration? [00:33] slangasek: bryceh and RAOF asked me to change that at UDS [00:33] (adding nomodeset in recovery mode) [00:33] of course one can edit the boot parameters and delete that if that's not the problem ... [00:33] * slangasek nods [00:34] RAOF: there's nothing in the Xorg.0.log, it was the first place I looked. [00:34] 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] my .xsession-errors has a stack of Fatal IO error 11 (resource temp unavailable) on X server :0 [00:35] X is fine, i've got X up with an xterm, its something gnome related from the looks of it [00:35] 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] I also see a stack of GLib-GObject-CRITICAL errors [00:36] RAOF: point [00:36] those errors seem to be in nautilus [00:36] jono: can you pipe your .xsession-errors through pastebinit? [00:36] startx is trying to start a session which is dying and quitting x [00:37] I also see an I/O warning about failing to load external entity /home/jono/.compiz/session/ [00:37] http://paste.ubuntu.com/667805/ [00:37] there's mine [00:38] Sarvatt: I'm confused; are you experiencing other X problems, or are you reading over jono's shoulder? :) [00:38] s/X/desktop/ [00:38] i reproduced it on a machine i upgraded this morning, rebooted and no desktop [00:38] aha [00:39] also the amd64 livecd from today doesnt start lightdm automatically [00:39] jcastro: I don't suppose there's anything interesting in *your* /var/log/Xorg.0.log? [00:39] nothing at all [00:39] jcastro: nothing except for the ddxGiveUp error? [00:39] yeah but that's only spit out to the console [00:39] not the log afaict [00:40] ah, when trying to run startx? [00:40] ddxGiveUp isn't (necessarily) an error; that's what the X server says during shutdown. [00:40] right [00:40] 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] jbernard: hm, scratch that (above), i see where it's supposed to do it [00:47] interestingly, if I switch my DM to gdm I see X repeatedly try to start [00:47] that's just gdm trying blindly to deal with the situation by trying to start X multiple times [00:48] in theory gdm should exit and drop into failsafe-x [00:48] right, ok, I am rebooting and then putting log files on a USB stick and will file a bug === kenvandine_ is now known as kenvandine === dendro-afk is now known as dendrobates [01:08] ok so doing a "sudo startx" I get "No protocol specified" over and over on the first console [01:16] jono, jcastro, bryce: it's the glib2.0 update today [01:16] https://launchpad.net/ubuntu/+source/gnome-session/3.1.3-0ubuntu11/+build/2679219 works [01:17] 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] err sorry, didnt mean to link gnome-session in the first one [01:17] ok trying it [01:17] https://launchpad.net/ubuntu/+source/glib2.0/2.29.14-0ubuntu1/+build/2644912 for i386 [01:18] Sarvatt, thanks === dendrobates is now known as dendro-afk === yofel_ is now known as yofel [01:30] Sarvatt, how do I downgrade that package? [01:30] jono, jcastro, thanks; I've reproduced the bug on two machines. Likely everyone who updates today will hit it [01:30] jono: grab the debs on that page and dpkg -i them [01:30] jono, download the .deb's and then do sudo dpkg -i *.deb [01:30] I still had the files in /var/cache/apt/archives [01:31] (I've installed them but need to wrestle with nvidia for a bit before I confirm they work for me) [01:31] libglib2.0-0 libglib2.0-data libglib2.0-bin should be what you need [01:32] thanks for all your help bryceh , Sarvatt , jcastro , cjwatson , RAOF [01:32] and of course slangasek [01:34] 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 === dendro-afk is now known as dendrobates [01:35] slangasek: still around? [01:35] micahg: yep - what security update would you like me to break today? :) [01:35] slangasek: heh, firefox, natty only, from ubuntu-mozilla-security to natty-security, please [01:35] Sarvatt, those are the AMD64 builds, where are the normal x86 builds? [01:36] https://launchpad.net/ubuntu/+source/glib2.0/2.29.14-0ubuntu1/+build/2644912 [01:36] [9:17 PM] https://launchpad.net/ubuntu/+source/glib2.0/2.29.14-0ubuntu1/+build/2644912 for i386 [01:36] ahhh [01:36] thanks [01:36] didnt see that [01:36] micahg: version 6.0+build1+nobinonly-0ubuntu0.11.04.1 ? [01:37] slangasek: yes please [01:38] micahg: done [01:38] 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] micahg: well, I understand they want us to not have to use the shell to administer the archive... and this counts :) === asac_ is now known as asac [01:48] Sarvatt: bryceh: confirming the downgrade works here [01:54] 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] thanks bryceh , will file it now [02:01] https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/827753 [02:01] Ubuntu bug 827753 in glib2.0 (Ubuntu) "libglib 2.29.16-0ubuntu1 breaks desktop session - downgrade fixes" [Undecided,New] [02:01] biab [02:20] RAOF: installing libgl1-mesa-glx:i386 in a chroot works ok here [02:20] RAOF: however, bug #802901 [02:20] Launchpad bug 802901 in apt (Ubuntu) ""E: Internal Error, Could not early remove linux-libc-dev" in multiarch chroot" [Undecided,Confirmed] https://launchpad.net/bugs/802901 [02:21] That's an eerily familiar error message… :) [02:25] 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] slangasek: Hah! [02:25] Yeah, I just tried it and it failed for me. [02:25] I was wondering whether you'd forgotten to install libgl1-mesa-glx:amd64 first :) [02:26] 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. === dendrobates is now known as dendro-afk [02:30] linux-libc-dev also has a C/R/P - nice catch [03:02] jono, jcastro: Do you, perchance, have libzeitgeist-gio installed? [03:04] RAOF: that's not even available in my synaptic [03:04] jbicha: Yeah, I know. It *was* in Maverick, though (see bug #724199), and so upgraders might hit this. [03:05] Launchpad bug 724199 in libzeitgeist "Remove libzeitgeist GIO module - zeitgeist-datahub does the same now" [Medium,Fix released] https://launchpad.net/bugs/724199 [03:05] 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] 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] 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] Let me reboot to be 100% sure/. [03:17] Ok all fine here. === dendro-afk is now known as dendrobates [03:19] Actually, I guess we've got two options: re-add 71_gio_launch_handler.patch, or add a Breaks: to libzeitgeist-gio [03:20] I guess the question is whether the patch being dropped was accidental. [03:21] No, it was deliberate; there's new upstream API which does the same thing, but differently. [03:21] Ah ok. [03:22] 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] Right. [03:24] 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] Oh, wow. It's 13:30. That's why I'm hungry! [03:39] heh [03:52] Hm. glib's testsuite needs to be parallised. === dendrobates is now known as dendro-afk [04:08] Good morning [04:09] 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] slangasek: but we have it in the ubutu-desktop PPA as well for staging, so it's not totally blocking everything [04:11] 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] 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] RAOF: please go ahead [04:14] RAOF: so I guess the proper fix is to port libzeitgeist-io to the new upstream API? [04:14] pitti: ah, in that case allow me to expedite [04:15] pitti: actually, it looks like someone else may have already done so ;) [04:15] pitti: No; libzeitgeist-gio has been removed from the archive. [04:15] 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] slangasek: ah, splendid [04:16] RAOF: oh, so a Breaks: actually sounds right? [04:16] 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] RAOF: ok, please wait with the upload thhen [04:17] And preventing {lightdm,gdm} from starting is pretty obnoxious. [04:17] you want Conflicts:, not Breaks: [04:17] since Breaks doesn't guarantee removal, only deconfiguration [04:17] I have the new version running since yesterday without any problems [04:18] Yeah, but that's a new install, right? [04:18] it was introduced for wncksync [04:18] RAOF: yes, but libzeitgeist-gio actually should be cleaned up on upgrade either way [04:18] I agree. [04:18] RAOF: and it doesn't seem to break anything else [04:18] it was originally introdoced for wncksync [04:19] but bamf works fine with the new glib, so doesn't seem to need that any more either [04:19] RAOF: so my gut feeling is that we should keep the upstream API now, and clean up the old cruft properly instead [04:21] 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] You've touched glib much, much more than me, though, so now you're up I'm happy to hand off. [04:25] RAOF: I'll triple-check bamf, as this seems to be the only other user [04:26] 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] RAOF: ok, so want me to add the Conflicts:, or did you already? [04:27] RAOF: and thanks for figuring out the cause of this! [04:28] Daviey, hi? [04:28] sorry, this didn't occur in seb128's or my testing, I guess as we both have an upgraded natty install [04:28] pitti: I haven't yet done that; I can, retest, then upload though. [04:28] RAOF: I can take over if you want to call it a day [04:28] just asking if you already did to avoid double work, but I don't see new commits in bzr yet [04:28] I'm not near EOD. [04:29] I've got a package with the patch re-added ready, but not one with just a conflicts. [04:29] That said, it'll be trivial to whip up one with the conflicts ;) [04:30] RAOF: glib just built yesterday, I don't think it needs a full local run just to add a Conflicts: [04:30] Fair call. [04:36] Hm. bzr doesn't seem to want to push; it's just sitting there. I wonder what it's doing. [04:37] Heh. Too impatient. There it goes! [04:41] pitti: Done. [04:41] RAOF: thanks [04:52] slangasek: so I followed your announcement to enable multiarch, and apt-get update indeed did get all the i386 indexes [04:54] so it's "sudo apt-get install flashplugin-installer:i386" now, right? [04:54] that at least seems to pull in a lot of i386 dependencies [04:54] Can we purge ia32-libs now? :-) [04:54] I suppose we should make the firefox plugin installer clever enough for this now [04:54] StevenK: you seem eager to kill it :) [04:54] StevenK: parner stuff still needs it [04:54] ajmitch: who isn't? [04:54] like this little package "skype" [04:55] ia32-libs has been a thorn in our eyes forever [04:55] pitti: apparently skype doesn't need it according to slangasek [04:55] who doesn't love a large monolithic binary package that must give the security team headaches? [04:55] slangasek: so, congratulations! that was a great piece of work [04:55] * ajmitch feels sorry for whoever's had to touch it [04:55] ajmitch: we're not talking about chromium right now :) [04:55] lolo [04:55] micahg: hah [04:56] micahg: it still bundles half the world? :) [04:56] yep [04:56] * ajmitch is glad to see multiarch, thanks to those who've implemented it [04:57] hmm, now I just need to tell firefox somehow that the plugin is "on the other side of the arch fence" [04:59] pitti: Partner? Who uses that anyway? :-P [05:01] 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] 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] 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] oh - you still need nspluginwrapper installed [05:45] did you remove it? [05:45] oh, indeed [05:45] I thought flashplugin-installer would pull it in [05:45] (I still need to touch the flashplugin package to represent this in some sensible fashion) [05:45] didn't help, though [05:46] yeah, the amd64 flashplugin-installer does, the i386 one doesn't - it may be simplest to just make it a dependency [05:46] ooking for plugins in /var/lib/flashplugin-installer/ [05:46] didn't help? [05:46] Update plugin /var/lib/flashplugin-installer/npwrapper.libflashplayer.so [05:46] wrapper ident matches and NPAPI plugin is unmodified, skipping [05:46] perhaps I need to install the wrapper first, and then flashplugin-installer [05:46] hmm [05:46] I honestly don't know [05:47] if it works for you, then I guess I just did something wrong, or have some cruft on my system [05:50] you could be right that nspluginwrapper needs to be installed before flashplugin-installer [05:50] that didn't help either, thoug [05:51] hmm [05:51] restarted firefox after installing? [05:51] yes, sure [05:51] shows up in about:plugins, or no? [05:51] it doesn't [05:51] sudo dpkg -P flashplugin-installer:i386 nspluginwrapper:i386 [05:52] and trying to reinstall both [05:52] oh, you need the amd64 version of nspluginwrapper :) [05:52] should I clean up anythign else? [05:52] ah! [05:52] nspluginwrapper is the bit that's the *plugin* for firefox :) [05:52] so has to match arch [05:52] that's not installable on amd64 [05:53] it's in NEW [05:53] :-) [05:53] * pitti just feels the urge to do some archive admin [05:54] in theory, we can solve the nspluginwrapper issue for firefox, but other things need nspluginwrapper [05:56] 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 === smb` is now known as smb [06:50] 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] statim: Our buildds have no access to the internet. [06:51] statim: So, if that's destined for an archive, that's a huge "no". [06:51] 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] It's also generally a good idea for maintainability to have reproducible builds; downloading the tarball from the internet breaks that. [06:53] 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] 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] statik: no need to remove them [07:01] statik: oops, tab complete failure :) [07:01] statim: no need to remove them [07:01] 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] statim: yep, up to you, it's just a storage dir AFAIK [07:01] micahg: cool thanks === Amaranthus is now known as Amaranth [07:12] good morning [07:13] Good morning Mr Holbach! [07:15] morning [07:17] hey Daviey, hey ion === tkamppeter_ is now known as tkamppeter [07:34] happy birthday, Debian! 18 years, coming of age [07:35] Good morning [07:37] pitti, finally at drinking age :) [08:01] 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] 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. [08:26] Launchpad bug 802901 in apt (Ubuntu Oneiric) ""E: Internal Error, Could not early remove linux-libc-dev" in multiarch chroot" [High,Confirmed] https://launchpad.net/bugs/802901 === pedro__ is now known as pedro_ [09:55] if gtk-window-decorator crashes, what's the least interfering way to get it back up? [09:56] Alt+F2 gtk-window-decorator [09:56] that worked for me [10:05] If gtk-window-decorator crashes, it's saving you from it's memory leak ;) === seb128_ is now known as seb128 [10:12] RAOF: hooray? [10:12] pitti: ta [10:12] jml: Indeed. [10:27] soren, would it be possible to disable the ubuntu-server-qa repository for some days until the test rebuild is done? [10:34] barry, Riddell: can you answer https://bugs.launchpad.net/ubuntu-packaging-guide/+bug/827925? [10:34] Ubuntu bug 827925 in Ubuntu Packaging Guide "How to handle a merge" [Undecided,New] [10:34] 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] 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] 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] tseliot: which exactly? [10:53] cjwatson: /etc/kernel/postinst.d/nvidia-common and /etc/kernel/header_postinst.d/nvidia-common [10:59] 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] cjwatson: yes, this is exactly the case. Thanks [11:00] doko_: Sure. Hang on. [11:00] doko_: Done. [11:00] thanks! [11:22] slangasek: You may be interested in bug #827950 [11:22] Launchpad bug 827950 in dpkg (Ubuntu) "Multiarch: dpkg gets confused when installing new packages with the same version" [Undecided,New] https://launchpad.net/bugs/827950 [11:22] slangasek: I hope that the description is clear enough; I found it difficult to describe. [11:40] argh, I hate dpatch [11:40] I always always always forget to add new patches to debian/patches/00list [11:40] cjwatson++ [11:41] heh, I used to hate quilt for the same reason :p [11:41] quilt does add stuff to series automatically [11:41] if you use the right quilt commands [11:42] I tend to cp the vcs diff in debian/patches [11:42] if you use the natural quilt commands for creating new patches, yes :-) [11:42] which "just work" with cdbs simple-patchsys [11:42] 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] edit-patch ftw! [11:44] or add-patch for this matter [11:44] 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] mvo: I probably ought to remember that, yes :) === dendro-afk is now known as dendrobates [11:44] mvo, ;- [11:44] mvo, ;-) [11:45] I guess cdbs/dpatch should have a debian/00list, debian/patches: *AUTOMATIC-KTHXBYE* option to add there [11:45] that would just use whatever is in the dir [11:47] mvo: this particular package has patches in debian/patches/ that aren't applied :-/ [11:47] heh, there we go [11:48] ah, debian packaging, so much fun :) [11:51] compiz --replace [11:51] err whoops, gnome-terminal tab fail [12:12] 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] seeing failures on buildds but not locally or on virtual builders [12:12] 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] tkamppeter: That would make things way easier, and avoid having to parse and handle an option [12:17] (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] what package is Oneiric's battery indicator from? [12:32] mdke: indicator-power [12:32] sorry [12:32] mdke: ignore me, wanted to respond to mdeslaur, tab failure [12:36] doko_: ping? === dendrobates is now known as dendro-afk [12:38] 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] stgraber: Is it ok to commit a pastebinit paste.linaro.org to collab-maint, or should I file a bug? [12:39] oh actually that's not upstream [12:48] * jdstrand wonders why his /tmp directory isn't having its directories autocleaned on boot... === dendro-afk is now known as dendrobates [13:31] seems a few more sync mails leaked out from the test environment (debootstrap 1.0.35 and mono 2.10.4-2) [13:31] mr_pouit: those were real [13:32] slangasek: is it intentional that apt doesn't install recommends of foreign arch packages? [13:32] oh, indeed [13:32] mr_pouit: I'll be announcing the new facility soonish, we're just finalising the client tool [13:33] mterry: did my netbook-launcher-efl branch look plausible? [13:34] cjwatson: okay, nice. They have the same "incomplete" mail (without the .changes), that's why I thought they were the same ;-) [13:34] cjwatson, ah, sorry. I bookmarked it to get back to it. I can review now [13:34] mr_pouit: ah, no, missing the changes is kind of inevitable for this mechanism [13:34] 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] 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] mr_pouit: but if you look closely you can also see that it has a link to dogfood.launchpad.net [13:35] mterry: cool, thanks [13:35] huhuhu, ok ;-) === dendrobates is now known as dendro-afk [13:56] cjwatson, yeah, seems fine to me [13:56] cjwatson, I'm putting the change in upstream trunk too [13:57] mterry: great, thank you [13:57] * cjwatson chips away at the EFL stack nightmare [13:59] cjwatson, shall I merge to Ubuntu or will you? [14:03] mterry: don't mind, I can if you like [14:04] k [14:06] done and uploaded [14:18] OdyX, no problem. [14:18] tkamppeter: okay, nice. === doko_ changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: Feature Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ev [14:39] ev: could you merge https://code.launchpad.net/~brian-murray/ubuntu/oneiric/apport/bug-828037/+merge/71901 [14:39] Ubuntu bug 71901 in Ubuntu "wrong order in /etc/rc2.d between kdm and nvidia-kernel" [Undecided,Fix released] [14:39] whoops, I still have that hat on [14:39] sure thing [14:39] @pilot out === udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: Feature Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [14:39] heh thanks [14:39] will do in about 5 === pedro__ is now known as pedro_ [15:12] 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] 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] 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] 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] ryanakca: sorry not to be able to help more [15:25]