[00:00] <infinity> Having it automated when they're, in fact, equal, seems perfectly reasonable.
[00:01] <stgraber> slangasek: for the full report on all supported releases: http://paste.ubuntu.com/1338655/
[00:01] <stgraber> slangasek: maybe that kde langpack should be copied to precise-updates, looks like it was removed in quantal
[00:30] <ScottK> slangasek and xnox: I guess I should modify and say 'sane patches welcome' wrt PyQt4 split.  I'm particularly interested in a sane way to determine appropriate dependencies since we're doing a more fine grained split than upstream.  FWIW, I agree with doko re CMake and Pytyon stuff.
[00:37] <slangasek> stgraber: right, kde-l10n-kn copied
[06:53] <pitti> Good morning
[06:59] <jaaso> Allways get this error while trying to build ubuntu unity http://paste.ubuntu.com/1339148/, I am following this guide http://unity.ubuntu.com/getinvolved/development/unity/    :/
[07:16] <sarnold> jaaso: is that the first error in the build output?
[07:17] <jaaso> Yes
[07:17] <sarnold> drat, there goes the usual easy first response :) hehe
[07:17] <pitti> ev: ddebs.u.c.'s precise indexes ought to be better now, FYI
[07:17] <jaaso> I tried to build unity yesterday on fresh ubuntu install, and have same error
[08:00] <dholbach> good morning
[08:05] <didrocks> bonjour dholbach
[08:06] <dholbach> didrocks, bonjour mon ami - comment ça va?
[08:08] <didrocks> dholbach: bien occuppé, mais ça va! et toi? :)
[08:08] <dholbach> oui - la même chose ici
[08:08] <dholbach> :)
[08:44] <jaaso> omg, fixed previous error, now I get this http://paste.ubuntu.com/1339290/. So annoying
[08:46] <jaaso> I this DECLARE_LOGGER(logger, "unity.bghash"); should be in unity namespace. ...../unity/trunk/unity-shared/BGHash.cpp file
[09:17] <pitti> Riddell, ScottK: FYI, I filed the PyKDE4 crash as bug 1075891
[09:19] <ev> pitti: Thanks!
[09:28] <apw> cjwatson, so i think i have .signature support prototyped out ok, but grub is picking them up as kernels; do we want to rethink the naming or fix grub
[09:33] <apw> pitti, are you still the main man on .ddeb handing, and particularly reaping ?
[09:33] <pitti> apw: yeah, I am
[09:34] <cjwatson> apw: inclined to fix grub since I think any renaming would have to be obscurantist otherwise
[09:35] <apw> pitti, so we seem to have lost the ddebs for 3.2.0-32 which is -security,-updates in preceise
[09:35] <apw> cjwatson, we could consider having /boot/signature/vmlinuz-.....efi
[09:36] <xnox> pitti: Riddell, ScottK: it's a bug in python3.3
[09:36] <pitti> xnox: DLFCN is supposed to exist?
[09:36] <cjwatson> apw: we could; do you think it's worth it?
[09:36] <pitti> apw: looking
[09:36] <cjwatson> I suppose it might look cleaner or something
[09:36] <xnox> pitti: yes, it's /usr/lib/python2.7/plat-linux2/DLFCN.py & /usr/lib/python3.2/plat-linux2/DLFCN.py
[09:36] <apw> cjwatson, i dislike both really for various reasons
[09:37] <xnox> pitti: but completely missing in python3.3. There is an upstream bug that it was not being built on plat-linux3 (3.X kernels) but that was fixed.
[09:37] <cjwatson> do we have to change grub anyway for this scheme to work?  I guess not ...
[09:37] <xnox> pitti: I am guessing that DLFCN.py should be in a multi-arch location in python3.3 but I can't find it anywhere.
[09:38] <apw> no as it stands we still make .signed kernels as kernels
[09:38] <apw> and they get picked up as one would hope
[09:38] <apw> the signature is just noise, and generally not even usable by the user without effort
[09:39] <cjwatson> Maybe it shouldn't be in /boot at all?
[09:39] <cjwatson> It's not needed at boot time
[09:39] <xnox> pitti: there is /usr/lib/python3.3/plat-x86_64-linux-gnu/IN.py in the package libpython3.3-stdlib ....
[09:39] <cjwatson> So strictly it should be in /usr or something
[09:40] <pitti> xnox: ah, so the multiarch handling works in general, just not for DLFCN?
[09:40] <xnox> pitti: yeah.... nor for CDROM nor TYPES
[09:40] <apw> thats a fair statement indeed -- it could go almost anywhere
[09:47] <pitti> apw: do you know when it disappeared?
[09:48] <apw> pitti, i don't, smb has an email informing us
[09:48] <smb> pitti, Not really I just saw an email complaining about it from a user yesterday
[09:48] <pitti> apw: hm, only the armel ones are left indeed
[09:48] <pitti> meh
[09:49] <apw> its an odd combination indeed
[09:49] <pitti> apw, smb: they were built more than 7 days ago though, so I'm afraid there's nothing I can do now
[09:50] <pitti> we just have to stop the madness of how we currently handle ddebs :(
[09:50] <pitti> apw: 33 is there, when is that due for release?
[09:50]  * smb guesses maybe two more weeks
[09:50] <apw> pitti, 'real soon now' i believe
[09:50]  * pitti hopes we can get ddebs into Launchpad librarian soon
[09:51] <pitti> infinity: ^ do you know how we can/should test this? uploading a new pkg-create-dbgsym to staging and doing a test build there? or would that not suffice?
[09:51]  * pitti is a bit afraid to break LP when uploading it to raring
[09:52] <apw> pitti, heh yeah that sounds like a bit of a nightmare
[09:53] <apw> pitti, if by magic we had a copy would you be able to reinsert them and then perhaps figure out why they went missing ?
[09:53] <pitti> apw: we can reinsert them, yes
[09:53] <pitti> apw: as for why they went AWOL, I'm not sure
[09:54] <pitti> apw: the whole mechanics how this archive is created is insanely brittle and slow
[09:54] <apw> pitti, ahh i guess they may not have appeared even
[09:55] <apw> pitti, so they must have been there as carbou has a copy
[09:56] <pitti> ddebs@macquarie:~$ ping carbou.canonical.com
[09:56] <pitti> ping: unknown host carbou.canonical.com
[09:56] <pitti> hmm
[09:56] <pitti> apw: can you toss me an URL?
[09:57] <apw> pitti, heh caribou is someone in L3 who keeps copies against loss like this
[09:57] <apw> pitti, working on getting them somewhere
[09:57] <pitti> oh, mind the "i" :)
[09:58] <apw> pitti, ok we seem to have some general issue here ... smb is telling me we have a number of older ones there, but generally the ones in -security are missing
[09:58] <apw> pitti, if what smb is saying in my ear is right then we might be keeping the right number but the wrong ones
[09:58] <smb> Seems at least true for Oneiric and Lucid
[09:59] <pitti> hm, my cron jobs have all -updates and -security pockets
[09:59] <smb> 2.6.32-44.98 (has only versatile), 3.0.0-26.43 (only has omap)
[10:00] <smb> pitti, Could it miss a "not"? :) We seem to have kept all we don't care about and deleted the ones we do...
[10:00] <apw> pitti, ok if you look just at 2.6.32-* (http://ddebs.ubuntu.com/pool/main/l/linux/) we have like every abi from release to now other than the one in -updaes or something ?
[10:00] <pitti> smb: I'm fetching the Packages.gz from the archive and find out which ddeb needs to go in which index by comparing pkgname + '-dbgsym' and version numbers
[10:00] <pitti> there's no negation involved
[10:01] <smb> pitti, Just nagging. ;) Otherwise nothing would be left in some way
[10:01] <pitti> but yeah, it looks strange
[10:02] <pitti> it might be due to the fact that we never really NBS out old ABIs in stables?
[10:02] <caribou> pitti: apw smb I have been mirroring them on a server in Mtl for a while. Not sure if everything is there though
[10:03] <apw> caribou, yeah great, we may want some of those indeed
[10:04] <xnox> doko: so there are two python3.3 bugs now: https://bugs.launchpad.net/ubuntu/+source/python3.3
[10:11] <smb> caribou, could you get together with pitti and let him know how to access the copies?
[10:13] <doko> xnox, cute
[10:14] <caribou> smb: ok
[10:14] <xnox> doko: yeah =/  enjoy multi-arch?!
[10:14]  * xnox really needs to get hardware to build gcc/python quickly.
[10:17] <xnox> doko: the DLFCN one is important, the DLDLIBRARY is a nice to have type of thing.
[10:44] <caribou> smb: regarding Bug #1064475, I'll speak with arges later on. Don't know why he got it
[10:45] <caribou> pitti: ddebs for 3.2.0-32 are here : http://people.canonical.com/~lbouchard/precise_ddebs/
[10:45] <pitti> caribou: cheers!
[10:46] <caribou> pitti: just let me know if you need more, got 400Gb of them :-)
[10:47] <smb> caribou, Just want to make sure he and I spent time on it and I was hoping to get that completed soon. So yeah, I will try to talk to him too
[10:48] <caribou> smb: what was the outcome of the Ubuntu specific module ? do we want it submitted upstream or we just drop it ?
[10:50] <smb> caribou, There is not really an outcome there. As far as I know it got in for ps3 stuff. Not sure one would still need it. I would leave it in for now and thought to get in touch with Ben. But given the unclear heritage I thought it would not really be useful to approach him without being able to fill in a bit of background,.
[10:53] <caribou> pitti: regarding ddebs mirroring, I only mirror {flavor} & {flavor}-updates. Should I include the security bits ?
[10:53] <pitti> caribou: in many cases they should be identical; it certainly cannot hurt to mirror them
[10:53] <pitti> caribou: at least until we get ddebs into the LP librarian
[10:53] <caribou> pitti: ok, I will see if I have enough diskspace to get them
[10:57] <smb> caribou, pitti, Sorry if I missed the info in the various thread, but if the reason for the disappearance is found, can you also bring back the Lucid and Oneiric ddebs from updates/security (both the same in those cases)
[10:58] <jaaso> Should I bulid anything else except nux for latest unity, unity.ubuntu.com/getinvolved/development/unity/#build-unity. Still have damn problem with this line of code from BGHash.cpp  "DECLARE_LOGGER(logger, "unity.bghash");"
[11:06] <cjwatson> jaaso: #ubuntu-unity might be more likely to contain experts
[11:06] <jaaso> cjwatson, thanks.
[11:07] <apw> cjwatson, this signing data, so reading the FHS i think /usr/lib/linux might be an appropriate place, as the signatures are architecture specific and overlap i386/amd64
[11:08] <apw> cjwatson, now ... that brings up a question, now that the kernel is multi-arch are the binary names in /boot wrong as they can clash across multi-arch architectures
[11:08] <pitti> apw, caribou: put the 3.2.0-32.51 .ddebs back to http://ddebs.ubuntu.com/pool/main/l/linux/, thanks! I'm rebuilding package indexes now and then see what is wrong with that
[11:08] <apw> pitti, great ...
[11:09] <cjwatson> apw: The kernel is only Multi-Arch: foreign, not Multi-Arch: same, so doesn't have to worry about coinstallation across multiple architectures
[11:10] <apw> cjwatson, ahh ok, of course
[11:10] <cjwatson> (Or is it even that?  It perhaps should be, but linux-image-3.5.0-18-generic doesn't seem to have that header here)
[11:10] <cjwatson> Anyway, it's multiarch-installable, which is more about the kernel's dependencies than the kernel itself
[11:11] <cjwatson> apw: I agree that /usr/lib/linux is reasonable if you don't have any other suitable existing directory
[11:11] <apw> cjwatson, is it reasonable to use a srcpackage prefix in /usr/lib ?
[11:11] <cjwatson> Yes
[11:11] <cjwatson> It only matters that it not clash with other stuff
[11:11]  * apw rechecks
[11:11] <cjwatson> And /usr/lib/linux/ is unused
[11:12] <cjwatson> So you should be fine there
[11:12] <apw> i suppose i could dump it in the /lib/modules/<version> directory too
[11:13] <apw> bu then we'd have to worry about clashes with kmod thinking on the meanings
[11:13] <apw> why is naming the hardest part
[11:13] <cjwatson> I don't see any reason this would need to be in /lib
[11:14] <apw> no there would be no reason to need it early
[11:14] <cjwatson> /boot is needed by the boot loader, and /lib is needed during early boot; this is only needed when installing the package, so /usr
[11:14] <apw> sold to the man in the hat
[11:14] <cjwatson> And it's architecture-dependent as you say so /usr/lib
[11:14] <cjwatson> Seems like fairly solid reasoning :)
[11:39] <pitti> apw, smb: they are back in http://ddebs.ubuntu.com/dists/precise-security/main/binary-amd64/Packages as well now
[11:39] <pitti> so something is wrong with the cleanup apparently
[11:39] <pitti> they do appear, and then disappear after some time
[11:52] <apw> pitti, want us to look at the logic ?
[11:54] <pitti> apw: if you want, sure; it's on my list for today as well, just finishing up with gvfs
[11:54] <pitti> but more eyes are always better
[11:54] <apw> heh except when they arn't :)
[11:55] <pitti> http://bazaar.launchpad.net/~pitti/+junk/ddeb-retriever/files
[11:55] <pitti> hm, I ought to add quantal for ports, argh
[12:03] <mlankhorst> hm so maybe I picked up something from uds after all :(
[12:42] <scott-work> is there a convention to mark blueprints for previous releases as 'obsolete' or otherwise?
[12:59] <mdeslaur> @pilot in
[13:02]  * dholbach hugs mdeslaur
[13:02]  * mdeslaur hugs dholbach back
[13:18] <caribou> smb: can I drag you in a mumble discussion with arges on crash ?
[13:18] <caribou> s/on crash/about crash/
[13:38] <menace> is there any document which describes the various codewords in release-files in .deb-repositories?
[13:38] <menace> like FakeCodename, Origin, Suite, Pull or stuff like that?
[13:39] <herton> @pilot in
[13:40] <cjwatson> Never heard of either FakeCodename or Pull
[13:40] <pitti> xnox: OOI, what does http://launchpadlibrarian.net/122171219/ubuntu-drivers-common_1%3A0.2.71ubuntu1_1%3A0.2.71ubuntu2.diff.gz do?
[13:42] <pitti> xnox: also, I'll drop the ${python3:Depends} again; nvidia-common is a transitional pacakge, and dh-modaliases is perl
[13:42] <menace> cjwatson: we need that because of building against codename, but distributing than for codename/x.y.z AND codename/x.v.z... problems are reoccurring with that. :)
[13:43] <pitti> xnox: --shebang isn't documented in dh_python3, and I haven't seen it before
[13:44] <cjwatson> I actually can't find any particularly obvious documentation of the Release file right now
[13:44] <pitti> xnox: ah, so previously it said #! /usr/bin/python3.3
[13:45] <cjwatson> Some of it is sort of documented indirectly in apt_preferences(5)
[13:45] <menace> where do you look for it? i already tried to look through the blueprints, but there are too much with "repository" in it :D
[13:45] <cjwatson> Actually fairly directly
[13:45] <OdyX> menace, cjwatson: Debian #671503
[13:46] <cjwatson> under "Determination of Package Version and Distribution Properties"
[13:46] <cjwatson> menace: The Release file format predates Ubuntu, so there's no point looking for it in Ubuntu bluepritns
[13:46] <cjwatson> *blueprints
[13:46] <cjwatson> 'man apt_preferences' is the best I can find
[13:47] <menace> ah, that are a few starting points, thx :)
[13:47] <OdyX> menace: in particular, jak's http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671503#67
[13:48] <OdyX> menace: which then leads to http://wiki.debian.org/RepositoryFormat
[13:48] <cjwatson> Ah, excellent, yes
[13:49] <OdyX> :)
[13:50] <menace> Thank you, that looks quite right! :-)
[13:56] <pitti> update-initramfs: Generating /boot/initrd.img-3.5.0-18-generic
[13:56] <pitti> WARNING: could not open /tmp/mkinitramfs_OiW40C/lib/modules/3.5.0-18-generic/modules.builtin: No such file or directory
[13:57] <pitti> apw: ^ should this worry me?
[13:57] <pitti> apw: it's (one of two) reasons why ubuntu-drivers-common's autopkgtest currently fails
[13:58] <apw> pitti, no not really, it is wrong, it is a bug in initramfs-tools which i thought infinity had a fix for
[13:58] <pitti> so is it okay to leave that as a failure for now?
[13:58] <pitti> instead of ignoring, I mean
[13:58] <apw> it is wrong but not the end of any worlds, we should have that file in there but we can live without
[13:58] <apw> yeah, i recon
[13:59]  * pitti uploads the other half of the fix in bcmwl
[14:21] <cjwatson> can anyone reproduce the python-apt/raring-proposed build failure?
[14:21] <cjwatson> I can't make it happen in a local sbuild
[14:27] <xnox> pitti: yeah need to open a bug about documentation. It's not in the manpage, but it is in the dh_python3 --help
[14:29] <xnox> pitti: sorry about extra ${python3:Depends} dpkg-gencontrolled complained about unused substitute variables, maybe dh_python3 should be run with "-pubuntu-drivers-common" or something.
[14:29] <xnox> pitti: feel free to revert any bits, as long as the shebang end's up as python3 on the python scripts =)
[14:29] <pitti> xnox: yep, I kept that bit and committed it to git
[14:29] <pitti> doing a few other fixes now
[14:30] <xnox> cool.
[14:30] <Laney> cjwatson: yeah, fails that way here
[14:30] <Laney> @pilot in
[14:30] <Laney> herton: mdeslaur: How can we avoid colliding? :-)
[14:31] <mdeslaur> Laney: uhm, let's just say here what we're looking at
[14:31] <mdeslaur> herton, Laney: I'm working on vim and rhythmbox
[14:31] <herton> Laney, don't worry about me, I can just look on kernel bugs
[14:31] <Laney> ok
[14:31] <Laney> I'll start from the bottom
[14:32] <cjwatson> Laney: any chance I could impose on you to figure out what's going wrong, since it's hard to do so without a reproducer?
[14:32] <herton> s/just/only
[14:34] <Laney> cjwatson: piloting now, but I will later if and when I get the chance
[14:36] <xnox> pitti: jodh: bug 1075976
[14:36] <xnox> have fun =)))) I'm stuck.
[14:50] <jodh> xnox: looking...
[15:02] <cjwatson> Laney: I'm trying with one of the official chroots now to see if it's some tedious discrepancy at that level
[15:02] <Laney> cjwatson: mine were created with mk-sbuild FWIW
[15:02] <cjwatson> So were mine
[15:03] <Laney> ho hum
[15:25] <mdeslaur> Laney: I'll take php5 LP: #1069529
[15:26] <cjwatson> Laney: I can't even reproduce this with the official i386 chroot :-(
[15:33] <Daviey> cjwatson: you grabbed the chroot from LP?
[15:35] <cjwatson> Yes
[15:35] <Daviey> cjwatson: I had a FTBFS last year that i could not reproduce locally using the locally generated chroot with either pbuilder or sbuild.. Grabbing the one from LP, i could reproduce with one of the build tools.. but not both.. can't remember which now.
[15:39] <infinity> pinky: Merging initramfs-tools will fix that, I'll get to that today.
[15:40] <cjwatson> guessing you mean pitti
[15:41] <pinky> me too
[15:41] <infinity> pitti: ^
[15:41] <infinity> cjwatson: I sure did.
[15:41]  * infinity has never made that tab-completion mistake before...
[15:53] <tazz> Hey, in unity if my application uses the system notification which requires user action, would i be able to do that?
[15:56] <xnox> tazz: app-development on ubuntu -> #ubuntu-app-devel . And yes, a gtk fallback dialog with buttons will be shown instead of a translucent bubble.
[15:56] <xnox> tazz: in general don't do that, instead color your indicator read and have a red menu/action item there.
[16:07] <doko> are CFLAGS etc still exported by dpkg-buildpackage?
[16:07] <cjwatson> Not as of quantal
[16:07] <cjwatson> specifically dpkg 1.16.1.2ubuntu8
[16:09] <doko> but by dh_auto_build apparently :-/
[16:09] <doko> $ DH_VERBOSE=1 debian/rules build
[16:09] <doko> dh build --buildsystem=autoconf
[16:09] <doko>    debian/rules override_dh_auto_build
[16:09] <doko> make[1]: Entering directory `/home/packages/python/3.3/mpdecimal-2.3'
[16:09] <doko> env | grep CFLAGS
[16:09] <doko> CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security
[16:09] <doko> dh_auto_build
[16:09] <doko>         make -j1
[16:09] <doko> make[2]: Entering directory `/home/packages/python/3.3/mpdecimal-2.3'
[16:10] <doko> gcc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -c basearith.c
[16:10] <doko> In file included from basearith.c:36:0:
[16:10] <doko> typearith.h:251:4: error: #error "need platform specific 128 bit multiplication and division"
[16:10] <doko> make[2]: *** [basearith.o] Error 1
[16:11] <xnox> doko: but you can set an option for those to be exported.
[16:11] <cjwatson> doko: debhelper 9?
[16:11] <cjwatson> if so that's a feature
[16:11] <doko> gah ... how to turn this off?
[16:11] <xnox> cjwatson: rm -rf /etc/apt/preferences.d/ && debuild => fail like in the build log.
[16:12] <xnox> cjwatson: the error appears to be comming on stderr from apt itself since it's printed even after a $ apt-get update
[16:12] <cjwatson> doko: you can set DEB_CFLAGS_MAINT_STRIP in debian/rules to remove individual exports
[16:12] <cjwatson> xnox: huh, I thought I'd tried that
[16:12] <xnox> cjwatson: in a raring sbuild chroot.
[16:12] <xnox> I think I had the same weirdness with test-suite of apt-clone or something like that....
[16:14] <cjwatson> ok, I'll give it another go, thanks
[16:14] <cjwatson> although the LP chroots contain /etc/apt/preferences.d/ (empty)
[16:16] <xnox> same here... but deleting it here, made the error appear.... dunno what's going on.
[16:17] <doko> cjwatson, not that useful, if the flags are taken in the configure step, upstream adds something to these, and then they are overwritten in the build step. I think I'll just use v8 and do the multiarch stuff myself
[16:18] <doko> DEB_CFLAGS_MAINT_STRIP is for removing stuff in an export, not removing the export afaics
[16:20] <ogra_> jono, poke
[16:20] <cjwatson> doko: just export an empty CFLAGS then?
[16:20] <jono> hey ogra_
[16:20] <jono> (otp)
[16:20] <cjwatson> doko: if the environment variable exists (not just is non-empty), debhelper won't touch it
[16:20] <ogra_> jono, ping me when you are free
[16:20] <jono> ogra_, will do, feel free to type ina  msg and I will respond when I can
[16:22] <ogra_> jono, so i have this blueprint ... https://blueprints.launchpad.net/ubuntu/+spec/desktop-r-rebuild-gl-games-for-gles which is rather "get the community to pick low hanging fruit and make ubuntu prettier" than anything else ... the spec is currently desktop- but i think it would fit better under the community- umbrella
[16:23] <xnox> ogra_: isn't it motu stuff?
[16:23] <ogra_> xnox, surely that as well
[16:24] <ogra_> i think its bigger than just motu
[16:24] <ogra_> after all it will stretch into main as well as debian
[16:25] <ogra_> (i.e. the "Add good C/C++ practise to developer.ubuntu.com" likely is more than jst motu)
[16:25] <infinity> cjwatson: What chroot-related failure were you and Laney looking at?  I'm having no luck with backscroll.
[16:25] <cjwatson> infinity: python-apt/raring-proposed
[16:25] <Laney> python-apt ftbfs
[16:25] <doko> cjwatson, yes but it doesn't help, it's already configured by the upstream configury
[16:25] <cjwatson> doko: uh, I mean at the top level of debian/rules
[16:25]  * infinity likes that it succeeds on the one arch that always fails.
[16:26] <cjwatson> since that runs before configure there's no "already"
[16:31] <cjwatson> infinity: I guess that might indicate I could try throwing it against the wall a few times ...
[16:31] <infinity> cjwatson: If it's a race, it should probably be hunted down.
[16:32]  * infinity thinks the contents of /etc/apt/preferences.d is a red herring, since it's the same on all arches.
[16:32] <cjwatson> Yeah
[16:36] <Laney> cjwatson: so I just managed to reproduce it on a cloud instance
[16:36] <Laney> raring on quantal didn't reproduce, but precise did
[16:37] <Laney> raring on precise, that is
[16:37] <cjwatson> wtf
[16:37] <Laney> I can just authorized_keys you up if you like
[16:37] <cjwatson> please
[16:37] <xnox> cjwatson: I am raring on raring.
[16:37] <cjwatson> Laney: racy or every time?
[16:38] <Laney> only tried once
[16:38]  * Laney does again
[16:38] <Laney> I tried thrice or so on my system here though, failed every time
[16:39] <Laney> ssh ubuntu@10.55.63.164
[16:41] <Laney> yeah, just failed again
[16:42]  * cjwatson tries
[16:45] <cjwatson> argh, other sbuild instances have the normal upstream default of purging the session on failure :)
[16:46] <xnox> cjwatson: schroot, then build... =))))))
[16:46] <cjwatson> Or I could just use -p never --purge-session never
[16:47] <Laney> just change .sbuildrc
[16:47] <Laney> this is the one that mk-sbuild auto-generates :-)
[16:47] <cjwatson> *shrug* my second build's already in progress so y'all can stop bikeshedding me :)
[16:48]  * Laney slinks off back to the queue
[16:57] <cjwatson> So /etc/apt/preferences.d/ is indeed definitely a red herring; creating that directory in the test environment makes no difference apart from silencing the warning
[17:01] <xnox> cjwatson: and the tests still fail? interesting.
[17:22] <mterry> stgraber, hello!  As discussed before 12.10's release, deja-dup now has separate metapackages for its supported backends, and the ubuntuone backend is not installed by default.  So edubuntu can seed the backend it prefers (I assume deja-dup-backend-s3)
[17:22] <mterry> stgraber, oh shoot
[17:22] <mterry> stgraber, it wasn't edubuntu...  it was gnome3 I think.    ^ jbicha
[17:24] <stgraber> mterry: yeah, sounds like gnome3, we have ubuntuone in edubuntu :)
[17:24] <mterry> stgraber, and no deja-dup I believe  :)
[17:25] <stgraber> mterry: hmm, no, we should have it, we inherit from ubuntu-desktop
[17:25] <mterry> oh.  seeded-in-ubuntu deja-dup only gave me the daily-live
[17:25] <jbicha> mterry: yeah, edubuntu-desktop depends on ubuntu-desktop
[17:26] <stgraber> mterry: ah yeah, seeded-in-ubuntu doesn't know that we seed it as edubuntu didn't get a succesful dvd build yet for raring
[17:26] <mterry> ah fair enough
[17:26] <mterry> jbicha, anyway, hopefully the gnome3 seeds can be done more nicely now wrt deja-dup
[17:34] <SpamapS> slangasek: Where do we stand with upstart jobs alongside init scripts in Debian packages?
[17:43] <superm1> can an archive admin axe the build of mythtv in raring proposed?  looking over the build log, something is wrong with it - it shouldn't be producing a NEW libmyth 0.27 binary package - it should be a NEW libmyth 0.26, so I need to investigate a little closer what went wrong with the build scripts
[18:01] <Laney> diwic: is bug #973014 comment #76 the thing to sponsor there?
[18:01] <Laney> and is it fixed in R?
[18:02] <Laney> actually, I'd like some information about the origin of the patch in DEP3 headers if you can provide that
[18:02] <SpamapS> Specified release (raring) not known to debootstrap
[18:02] <slangasek> SpamapS: the infrastructure is all in place so that you can put them in the Debian package and debhelper (and friends) will DTRT; the only outstanding bit is that if someone happens to actually be running upstart in Debian, it will probably break for them
[18:03] <SpamapS> shouldn't we have already SRU'd that to quantal? :p
[18:03] <Laney> we did
[18:03] <SpamapS> slangasek: oh.. thats unfortunate.
[18:03] <slangasek> SpamapS: (because upstart in Debian is still ancient, for a little while longer, and therefore uninteresting for anyone to run)
[18:03]  * SpamapS checks for updates
[18:03] <Laney> not been promoted to updates yet
[18:03] <SpamapS> slangasek: I'm just thinking to resolve package deltas
[18:04] <SpamapS> Laney: ahhh
[18:04] <Laney> maybe it should be done early though, given the amount people are complaining
[18:04]  * SpamapS now wonders why he's not running -proposed
[18:04] <slangasek> SpamapS: at this point I think you should probably feel free to push those jobs to Debian
[18:04] <SpamapS> slangasek: sweet!
[18:05] <SpamapS> slangasek: that was the last bit preventing resolving the delta for mysql. :)
[18:05] <slangasek> SpamapS: because as soon as my udev NMU goes in (currently in DELAYED), I'll upload the new upstart and we'll be good
[18:06] <SpamapS> slangasek: Seems I'll finally be able to switch my Debian VM to upstart! :)
[18:11] <Laney> @pilot out
[18:12] <mdeslaur> @pilot out
[18:17] <GunnarHj> herton: Hi Herton!
[18:17] <GunnarHj> herton: Saw that you are piloting... I have a few items in the sponsorship queue, and the most urgent are the MP + SRUs at http://pad.lv/875435, since they affect quite a few Asian users. It's really the SRUs that are interesting, but I suppose we should do it in the right order. Do you have time to take a look? The MP is reviewed and approved.
[18:18] <herton> GunnarHj, sorry, I can only look into kernel bugs
[18:18] <GunnarHj> herton: Aha, didn't know that. Guess it has to wait til tomorrow, then.
[18:22] <herton> @pilot out
[18:44] <bdmurray> @pilot in
[18:47] <sarnold> GunnarHj: pssst new pilot arrived :)
[18:48] <GunnarHj> sarnold: Thanks! :)
[18:49] <sarnold> :)
[18:59] <GunnarHj> bdmurray: Hi Brian!
[18:59] <GunnarHj> bdmurray: Saw that you are piloting... I have a few items in the sponsorship queue, and the most urgent are the MP + SRUs at http://pad.lv/875435, since they affect quite a few Asian users. It's really the SRUs that are interesting, but I suppose we should do it in the right order. Do you have time to take a look? The MP is reviewed and approved.
[19:01] <bdmurray> GunnarHj: sure, just a moment
[19:01] <GunnarHj> bdmurray: Great! :)
[19:02] <sarnold> GunnarHj :)
[19:02] <GunnarHj> sarnold: Your tip was fruitful. Thanks again! ;-)
[19:23] <bdmurray> GunnarHj: okay, I've had a look and it seems fine
[19:24] <GunnarHj> bdmurray: Great. Do you have upload right?
[19:25] <bdmurray> GunnarHj: I do indeed
[19:26] <GunnarHj> bdmurray: Then, could you upload both to raring and to -proposed for the stable releases?
[19:27] <bdmurray> GunnarHj: right, I'll do that
[19:27] <GunnarHj> bdmurray: I prepared separate branches for O, P and Q.
[19:44] <darkxst> bdmurray, are you able to take a look at this sru https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1073724?
[19:51] <bdmurray> darkxst: for the SRU to be considered for quantal the bug first needs to be fixed in the development release (raring in this case)
[19:52] <bdmurray> darkxst: otherwise the bug description looks good
[19:55] <bdmurray> darkxst: also did you try to determine why that patch was added and exists in the package?
[19:56] <darkxst> bdmurray, that patch does the sticky edges in unity
[19:58] <darkxst> i.e. pointer barriers with a velocity threshold
[20:07] <darkxst> bdmurray, I will test it under raring then
[20:10] <bdmurray> darkxst: you might also check with the X developers in #ubuntu-x
[20:14] <darkxst> bdmurray, ok, will do
[20:18] <yofel> cjwatson: hi, did you have a chance to look at the kubuntu packageset update?
[20:26] <dobey> can sokmeone confirm for me that the only thing depending on desktopcouch in quantal/raring, is dmedia?
[20:27] <diwic> Laney, thanks for having a look - when I made the SRU for Q and P the R archive wasn't opened
[20:29] <micahg> dobey: yes, you can also use reverse-depends from ubuntu-dev-tools
[20:30] <diwic> Laney, still around?
[20:30] <dobey> micahg: right; just wanted secondary confirmation. :)
[20:31] <dobey> micahg: for this: https://bugs.launchpad.net/ubuntu/+source/dmedia/+bug/1076123 :)
[20:33] <dobey> actually; i wonder if we could remove them from quantal also? :)
[20:33] <micahg> dobey: no
[20:33] <dobey> bribes with fun dip? :)
[20:34] <micahg> dobey: I've ack'd dmedia and desktopcouch is in your packageset, so you can go ahead and subscribe ubuntu-archive
[20:35] <dobey> dmedia is in my packageset?
[20:36] <micahg> dobey: that's not what I said...
[20:36] <dobey> oh
[20:39] <dobey> actually, i should add couchdb-glib to that too, probably
[20:40] <dobey> couchdb-glib isn't in the u1 packageset though
[20:41] <infinity> dobey: How does couchdb-glib relate?
[20:42] <dobey> infinity: it includes a C binding to desktopcouch. just realized removing desktopcouch might break that, so we should remove it as well (as nothing is using it any more, since apparently evolution-couchdb was already removed in quantal)
[20:42] <infinity> Yeah, nothing depends on it, not in Debian, etc.  Check.
[20:43] <dobey> so, frabjous day! :)
[20:45] <infinity> dobey: Done.
[20:45] <dobey> infinity: thanks much
[21:32] <barry> cr3: ping
[21:34] <cjwatson> yofel: done now
[21:35] <yofel> cjwatson: all there now, thanks a lot!
[21:44] <xnox> @pilot in
[21:48] <cr3> barry: pong, wazap?
[21:48] <barry> cr3: hi.  i think i answered my own question.  checkbox was ported to python3 in quantal, right?
[21:49] <cr3> barry: yep
[21:49] <barry> cr3: awesome!  i was just doing some blueprint gardening.  thanks
[21:49] <cr3> barry: we're really happy to have done our part in that effort
[21:49] <barry> cr3: very much appreciated
[21:50] <cr3> barry: we'll be migrating to go during raring
[21:50] <barry> cr3: :(
[21:51] <cr3> barry: j/k, wanted to see your reaction :)
[21:51]  * barry uncocks the hammer
[21:51]  * cr3 walks back slowly
[21:51] <barry> :-D
[22:34] <bdmurray> @pilot out
[23:00] <xnox> @pilot out
[23:36] <mightyiam> hiiiiiiiii why does 'do-release-upgrade -d' on quantal doesn't give me a new release?
[23:36] <slangasek> bdmurray: ^^ metarelease update needed?
[23:37] <slangasek> mightyiam: do-release-upgrade queries a central server to find out about the availability of releases and their release/support status; it seems the server needs updated
[23:38] <mightyiam> thanks, steve
[23:38] <chilicuil> mightyiam: however you can replace 'quantal' for 'raring' in your /etc/apt/sources.list file to upgrade to raring
[23:39] <mightyiam> chilicuil, just like a good 'ole release upgrade in debian? even since ubuntu i'm using the upgrader tool. ok. thanks
[23:40] <slangasek> the release-upgrader is Strongly Recommended™, but particularly this early in the cycle a plain dist-upgrade should work fine
[23:47] <slangasek> janimo: hey there!  how come you're using a native package for linux-nexus7?  is there no "upstream" tarball to preserve?
[23:51] <bdmurray> slangasek: I'll have a look at metarelease