[01:03] <ion> foomatic-filters (main) seems to recommend colord (universe).
[01:04] <RAOF> colord's MIR is in progress.
[01:04] <ion> alright
[01:17] <RAOF> ion: It's bug #823185 if you're interested.
[01:26] <ion> raof: Thanks, had already found it.
[01:37]  * slangasek wonders where the 300K for the new packages is supposed to come from
[01:41] <RAOF> I think the plan was to upload a sentient virus to change all the CD burning software in the world to allow an extra 300K overburn.
[01:42] <lifeless> slangasek: -Os ?
[01:42] <ion> Write the note “please send a terminator back in time to change the CD standard to be 300 kilobytes larger” and put it into a time capsule titled “to be opened when we have terminators and time travel technology”.
[01:57] <slangasek> lifeless: I'll get right on that :)
[01:59] <RAOF> We'll actually get some space back once we switch off the cairo-gl backend, since that's pulling in an EGL stack.
[04:30] <micahg> cjwatson: MoM seems to be broke again
[04:40] <mvo> micahg: it appears its having trouble with tar.xz
[04:41] <micahg> mvo: ok, anything I can do to help fix it?
[04:42] <lifeless> mvo: good morning
[04:42] <lifeless> mvo: we noticed a regression in your merge of apt from experimental; that one was fixed but there may be others - just a heads up
[04:43] <mvo> micahg: I ask the admins to install xz-utils, that may be enough already
[04:43] <mvo> lifeless: what kinds of issus exactly?
[04:43] <micahg> mvo: thanks
[04:44] <mvo> lifeless: the install crash regression is fixed I believe?
[04:44] <lifeless> mvo: the fix for bug 816606 was backed out, but the changelog entry for it kept.
[04:44] <lifeless> mvo: and yes, the fix has been reapplied; just letting you know in case whatever caused that has affected other things we had
[04:45] <mvo> lifeless: uhh, ok, I check it out, this looks like it was not merged into the ubuntu bzr branch ? and thus got lost on the upload :/
[04:45] <lifeless> mvo: well the debian/changelog entry for it was kept.
[04:45] <lifeless> mvo: which is really weird :)
[04:46] <mvo> indeed
[04:46] <lifeless> at least according to LP
[04:46]  * mvo checks his code
[04:51] <mvo> lifeless: hrm, so bzr log lp:ubuntu/apt|head gives me 0.8.15.1ubuntu2, and the vcs-bzr header of the upload points to the debian branch, so infinity could not know that there is actually a lp:~ubuntu-core-dev/apt/ubuntu branch. I fixed the vcs header now and will manually merge the upload into this branch now
[04:51] <mvo> lifeless: thanks for the heads up
[04:52] <lifeless> no worries
[05:44] <micahg> cjwatson: unping, mvo filed a ticket
[06:23] <slangasek> does anyone here understand this warning from g-ir-scanner?:
[06:23] <slangasek> peas-extension.c:190: Warning: Peas: peas_extension_callv: argument args: Unresolved type: 'GIArgument*'
[06:23] <slangasek> (I'm trying to resolve totem consistently segfaulting on amd64; looks like a failure to pass arguments in a 64-bit-clean fashion, and that's one of the few warnings in any build logs that look promising)
[06:23] <micahg> sounds like an --as-needed failure
[06:24] <slangasek> micahg: how would --as-needed be involved?  This is gobject-introspection...
[06:24] <slangasek> and it's a failure to resolve a type, not a symbol
[06:25] <slangasek> (you could be right, I just don't understand how - gobject-introspection is pretty opaque to me)
[06:25] <micahg> well, does the linker do the same thing with types as it does symbols?
[06:27]  * micahg apologizes if the question is silly
[06:27] <slangasek> micahg: no, because the linker doesn't have visibility to anything that's not a symbol
[06:28] <slangasek> note that this is the output of running g-ir-scanner on the source; doesn't actually invoke binutils or gcc at all
[06:28] <micahg> ah, ok, well, then I should probably be quiet as I don't know how g-ir-scanner works
[06:29] <slangasek> AIUI, g-ir-scanner is part of the toolchain that outputs a language-neutral description of the interfaces, including details like argument types, sizes etc
[06:30] <slangasek> that description gets compiled into an architecture dependent 'typelib' file
[06:31] <slangasek> you'd think it would still figure out the right thing to do with a generic pointer argument... but who knows
[06:37] <micahg> is there a missing include somewhere?
[06:39] <slangasek> probably :)
[07:00] <slangasek> oh, the problem is much simpler
[07:00] <slangasek> GPOINTER_TO_UINT
[07:00] <slangasek> stab
[07:01] <slangasek> why does that macro even exist
[07:12] <slomo> slangasek: because of the inverse macro... GUINT_TO_POINTER
[07:12] <slomo> slangasek: http://developer.gnome.org/glib/unstable/glib-Type-Conversion-Macros.html has an explanation why this macro is necessary at all
[07:13] <slangasek> slomo: right - so where do people get the idea that this is the right thing to use for casting to GType?
[07:13] <slangasek> this is the single most common 64-bit error I find in GNOME software over the past few years
[07:14] <slangasek> so someone is perpetuating stupid-broken code, and I'd like to get to the bottom of where that's coming from
[07:14] <slomo> slangasek: i don't know, i never saw this error and the docs of these macros have warnings everywhere to prevent people from doing stupid things like this :)
[07:14] <slangasek> sigh
[07:14] <slangasek> slomo: ok, thanks :/
[07:14] <slangasek> I think part of the problem is that GType is deliberately set up as an opaque integer type
[07:15] <slangasek> so it's not obvious to the novice that it shouldn't be treated as a uint
[08:06] <pitti> Good morning
[08:08] <micahg> hi Pici
[08:08] <micahg> oops
[08:08] <micahg> hi pitti
[08:09] <ajmitch> morning pitti
[08:15] <euroford> good afternoon -:)
[08:17] <micahg> is it ok to close bugs in a meta upload?  I know the changelog isn't usually modified manually
[08:17] <pitti> micahg: sure
[08:17] <pitti> micahg: it's totally fine to adjust the changelog
[08:18] <micahg> pitti: ok, thanks, and thanks for fixing cups in the common seed
[08:18] <micahg> I was going to ask about foomatic, but I noticed that cups is now a recommends on all those packages instead of a depends
[08:32] <kural> How is it decided that X version of Ubuntu will be LTS ? Any info folks
[08:33] <micahg> kural: discussion at UDS generally
[08:34] <kural> micahg : thanks
[08:35] <kural> I was porting some personal app , was wondering whether oneric would be LTS ?
[08:37] <StevenK> kural: Oneiric will not be an LTS
[08:38] <kural> StevenK: thanks . So i guess i should stick to 10.04
[08:40] <micahg> kural: maybe I misunderstood the question, there's an LTS release every 2 years, 12.04 will be the next one
[08:41] <kural> most likely my question was not asked properly. But you gave me the answer. Thanks . Thanks all.
[08:45] <matttbe> Hello,
[08:45] <matttbe> I'm looking for a sponsor in order to upload 3 packages before the feature freeze (sorry to be a bit late :-/) in universe: cairo-dock, cairo-dock-plug-ins and latexila.
[08:45] <matttbe> All these 3 packages are beta versions (they are almost stable but perfectly usable!) and their stable versions are expected for September.
[08:45] <matttbe> I've opened 3 bug reports linked to 3 bzr branches with 3 merge proposals:
[08:45] <matttbe> LP: #823513
[08:46] <matttbe> https://bugs.launchpad.net/ubuntu/+source/cairo-dock/+bug/823513
[08:46] <matttbe> https://bugs.launchpad.net/ubuntu/+source/cairo-dock-plug-ins/+bug/823514
[08:46] <matttbe> https://bugs.launchpad.net/ubuntu/+source/latexila/+bug/823566
[08:47] <matttbe> 'bzr merge-upstream' has been used to commit these revisions on these bzr branches and they should be ready to be uploaded on universe.
[08:47] <matttbe> I've compiled them with pbuilder and test it on Ubuntu Oneiric with a liveUSB
[10:13] <jamespage> good morning
[10:14] <jamespage> if there is an archive admin around please could the NEW binary packages for maven-hpi-plugin be accepted into oneiric.
[10:50] <jml> cjwatson: btw, re that apt-file Contents location thing. Should I file a bug somewhere? (If so, where?)
[10:57] <cjwatson> jml: I guess apt-file to start with, since we probably don't have time to fix this in LP before beta
[10:58] <cjwatson> jml: it'd be good to track down the relevant bit of apt-file changelog, as well as the exact change made to dak
[10:58] <jml> cjwatson: ok. thanks.
[11:12] <dupondje> jml: whats the issue with apt-file ?
[11:13] <jml> dupondje: it seems to be looking for Contents files underneath component directories, but they don't exist in the Ubuntu archive.
[11:13] <dupondje> that got fixed ?
[11:13] <jml> when?
[11:13] <jml> it's possible I'm running days-old code
[11:14] <dupondje> https://launchpad.net/ubuntu/+source/apt-file/+changelog last change :)
[11:16] <jml> dupondje: right. I guess I am running days old code :)
[11:16] <jml> dupondje: thanks for the fix
[11:16] <dupondje> np
[11:16] <dupondje> it went wrong after the last accidential sync :)
[11:17] <dupondje> reported a bug in debian also to make a patch so it has a fallback in debian, so we can sync again
[12:41] <jjardon> Hi, in oneiric, gconf is compiled with or without orbit support?
[12:41] <pitti> jjardon: without, I think, it's using dbus now
[12:42] <jjardon> pitti: great, do you detect any special bug?
[12:43] <jjardon> I'd like to propose dbus by default upstream
[12:43] <pitti> jjardon: not that I noticed
[12:43] <pitti> it largely went unnoticed, I'd say
[12:43] <jjardon> those are good news, thanks pitti !
[12:53] <chrisccoulson> jjardon, yeah, i switched on dbus support a few weeks ago
[12:53] <chrisccoulson> i don't think anybody really noticed ;)
[12:54] <dupondje> mmm cjwatson, you synced 'pino', but it seems still not visible on launchpad? Wasn't the delay quite minimal ?
[12:54] <cjwatson> mterry: do you think I might be able to go ahead and promote ndisc6 for bug 806723?  I've uploaded a fix to address Kees' concerns
[12:54] <cjwatson> dupondje: flushing the syncs is a separate step and sometimes it takes me a while to come back to the relevant window
[12:55] <dupondje> ah ok :)
[12:55] <cjwatson> I'll do so in a moment, there's just one of the syncs I want to check
[12:56] <dupondje> btw, little remark, for pino there was a sync requested of 0.2.11-7 , but now in debian there is 0.2.11-9, so this got synced. This isn't an issue now, but could be for some other syncs.
[12:56] <cjwatson> yes *shrug*
[12:56] <cjwatson> I looked at it and verified that it was OK
[12:56] <cjwatson> I can't easily sync non-current versions
[12:57] <cjwatson> and I also can't go back in time and arrange to have done the sync run earlier
[12:58] <dupondje> héhé ok :)
[12:59] <cjwatson> flushing the syncs now
[12:59] <dupondje> thanks for the work :)
[12:59] <mterry> cjwatson, let me look
[13:01] <mterry> cjwatson, sure
[13:10] <cjwatson> mterry: great, thanks
[13:13] <zyga> mvo, could we somehow split c-n-f bugs from c-n-f database inaccuracy bugs?
[13:28] <mterry> doko, ping, got a MIR reasonability question to bounce off you
[13:28] <mterry> kees, oh you're here too
[13:29] <mterry> kees, doko: it seems like a giant red flag to me, but just to make sure I'm not being too harsh, wanted to know what ya'll thought of a package embedding its own (apparently modified) copy of libusb instead of using the system one
[13:29] <mterry> I can't find any security history for libusb, so it doesn't seem like a particularly dangerous library, but still.  I imagine it could have problems
[13:32] <baltix-linux> ev: hi, could you tell me how you build wubi executables for windows? It seems you are building wubi, I found wubi.exe at your page - http://people.canonical.com/~evand/wubi/lucid
[13:33] <ev> baltix-linux: bzr branch lp:wubi; cd wubi; make
[13:34] <baltix-linux> I need to build wubi for Lucid based distro, I do bzr branch lp:~ubuntu-installer/wubi/lucid , right?
[13:35] <doko> mterry: as long as it's not used for the build ...
[13:35] <baltix-linux> ev: I need to build wubi for Lucid based distro, I do bzr branch lp:~ubuntu-installer/wubi/lucid , right?
[13:36] <ev> yes
[13:36] <baltix-linux> ev: I  get lots of Wine dialogs, I should just press next and finish ?
[13:38] <infinity> mterry: If it's in the source, that's no big deal, if it's being statically linked in the build, then yes, that's a big no-no.
[13:38] <mterry> doko, it is used for the build
[13:38] <mterry> infinity, that's what I thought
[13:39] <infinity> A big no-no that's probably easily fixed, but they should fix it before we move it to main, not after. :P
[13:42] <baltix-linux> ev: hehe, wubi buiding doesn't work if LANG=lt_LT.UTF-8 but when I set LANG to en_US then make works almost without errors :)
[13:42] <baltix-linux> ev: I get only one error:   File "Z:\home\mantas\Atsiuntimai\wubi\build\version.py", line 2
[13:42] <baltix-linux>    revision =                ^ SyntaxError: invalid syntax
[13:43] <ev> did you edit that by hand?
[13:43] <baltix-linux> ev: no, I just changed max_iso_size=3900000000 and min_disk_space_mb=4000 in data/isolist.ini
[13:45] <baltix-linux> ev: sorry, I understand where is the problem - I've copied sources to another folder and didn't copied hidded .bzr folder ;)
[13:45] <ev> ah, yeah, it needs to be in a bzr branch to determine the version number
[13:47] <baltix-linux> ev: thanks for helping, I tried dpkg-buildpackage command and this didn't work :)
[13:48] <ScottK> slangasek: I needed exactly your hplip fix on scribus today.  Thanks for making it easy.
[13:49] <slangasek> ScottK: sure :)
[13:49] <ev> baltix-linux: sure thing
[14:42] <SpamapS> slangasek: If you have a moment some time today, the upstart package branch needs, I think, some love..  I'm not sure if we can keep the current one .. may need to back up and start over with import-dsc's.
[14:57] <zyga> how can I aggregated my blog on planet.ubuntu.com
[14:58] <highvoltage> zyga: instructions are on https://wiki.ubuntu.com/PlanetUbuntu
[14:58] <zyga> highvoltage, thanks
[15:11] <ogra_> cjwatson, another livecd-rootfs question, my build fails with "ls: cannot access vmlinu?-*: no such file or directory" ... looking at the code, you added:
[15:11] <ogra_> KVERS="$( (cd "binary/$INITFS"; ls vmlinu?-*) | sed -n "s/^vmlinu.-\\([^-]*-[^-]*-$FLAVOUR\\)$/\\1/p" )"
[15:11] <ogra_> to me that looks like it searchs for the versioned vmlinuz file in /
[15:11] <ogra_> or do i misread that code ?
[15:12] <hallyn> micahg: hey, regarding kvm-pxe and ipxe.  If it's meant to replace kvm-pxe, then should we (a) mark it as conflicting with kvm-pxe, and then (b) copy the roms into the same places where kvm-pxe puts them?
[15:13]  * ogra_ would expect /boot somewhere in either the cd or the ls
[15:13] <cjwatson> all I can tell you is it worked at the time :)
[15:13] <hallyn> (Then we can mark qemu-kvm as depending on ipxe;  right now, you have to manually specify the option rom location on kvm command line for it to work)
[15:13] <ogra_> heh, k
[15:13] <cjwatson> feel free to extend as long as you keep x86 working
[15:13] <cjwatson> maybe it needs to check /boot on some architectures, indeed
[15:15] <ogra_> ah, infinity just educated me, seems $INITFS is supposed to contain boot/
[15:18] <hallyn> rsalveti: hey, on bug 823711, what do you mean by repo out of sync?  do you think a rebuild will succeed?
[15:19] <kirkland> barry: ping
[15:20] <rsalveti> hallyn: yeah, I'll try to rebuild it in a few hours once my panda is up, will post the result at the bug
[15:20] <hallyn> rsalveti: cool, thanks
[15:24] <kirkland> doko: barry: could one of you guys look at: https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/816169 ?
[15:24] <kirkland> doko: barry: this is blocking some other work in a strange way
[15:26] <barry> kirkland: that sure looks weird.  my plate's a bit full, but i can look at this later today
[15:28] <kirkland> barry: thanks
[15:28] <kirkland> barry: it's affecting iamfuzz and adam_g;  I'm playing triage/go-between here
[15:29] <kirkland> barry: can you just do one quick thing ... crack open /usr/lib/python2.7/encodings/__init__.py and look at lines 123-133 ... do you see any syntactical errors there?
[15:30] <barry> kirkland: it looks ugly, but legal, and...
[15:31] <barry> % python2.7 -c 'import encodings; print encodings.__file__'
[15:31] <barry> /usr/lib/python2.7/encodings/__init__.pyc
[15:31] <kirkland> barry: okay ... thanks
[15:31] <barry> oh, that may not be a good test, but yeah, it looks legal to me
[15:34] <ogra_> cjwatson, hmm somehow the merge of alisons usb image seeds makes greminate explode for me with a key error 'usb-langsupport'
[15:34] <ogra_> *germinate
[15:43] <cjwatson> ogra_: yes, I just fixed that
[15:43] <cjwatson> er
[15:43] <cjwatson> for real this time.  try again
[15:43] <ogra_> heh, k
[15:44] <ogra_> nope
[15:44] <ogra_> not on sycamore at least
[15:44] <ogra_> same key error
[15:45] <cjwatson> it might take a few minutes to sync
[15:45] <ogra_> (dunno, it seems to pull from internal)
[15:45] <ogra_> yeah, thats what i thought
[15:45] <cjwatson> try now, it looks like it's synced
[15:45] <ogra_> i'll give it 10min
[15:45] <ogra_> ok
[15:45] <cjwatson> it pulls from http://people.canonical.com/~ubuntu-archive/seeds/, which is on a */5 cron job
[15:46] <ogra_> oh, new error now
[15:46] <ogra_> grr, why cant i copy/paste from w3m
[15:47] <ogra_> Germinate.tsort.GraphCycleError: Cycle in graph .... hmm, thats cut off
[15:47] <cjwatson> wow
[15:48] <cjwatson> been a while since I saw that error
[15:48] <cjwatson> I'll get the failure mail and will look at it
[15:48] <ogra_> well, i'm playing with ubuntu-server-ac100 on sycamore if you want to see the whole traceback
[15:48] <ogra_> ah, indeed
[15:48] <cjwatson> copy/paste from w3m> it has mouse support of its own; hold shift for c/p
[15:48] <ogra_> forgot the mails
[15:48] <cyphermox> bryceh_: around?
[15:48] <ogra_> oh
[15:49]  * ogra_ hugs cjwatson, you just filled a 10 year old gap !
[15:50] <cyphermox> someone care to sponsor/review https://code.launchpad.net/~mathieu-tl/ubuntu/oneiric/ntrack/libnl3-build/+merge/70978 ?
[15:50] <cyphermox> (please) ;)
[15:52] <micahg> hallyn: well, I did check what Debian has done on the ipxe side, I just noticed the removal request
[15:53] <micahg> s/did/didn't/
[15:53] <hallyn> micahg: but as far as you're concerned, yo uwouldn't mind if we did that?
[15:56] <micahg> hallyn: I honestly don't know enough about it to say, I never touched etherboot, just noticed that it needed merging and found out it was going to be removed
[16:00] <hallyn> micahg: thx
[16:31] <jtaylor> mterry: the soya sru you sponsored on 1. Aug has not reached proposed yet, is there something wrong?
[16:36] <mterry> jtaylor, looking
[16:37] <SpamapS> we're behind on SRU reviews
[16:38] <SpamapS> I'll be doing a bunch shortly.. nearly done with my pre  FF stuff for the day. :)
[16:38] <ahasenack> I guys, I have a question about an upload failure error: "File convoy_0.2.0~bzr14-0landscape2~bzr7~lucid1.tar.gz already exists in LDS Trunk, but uploaded version has different contents."
[16:38] <Daviey> SpamapS: That sounded like an invitation for some more pre-FF work you need?
[16:38] <ahasenack> it's from a launchpad recipe build: https://code.launchpad.net/~landscape/+recipe/convoy-lds-daily
[16:39] <ahasenack> there were no changes to either branch (lp:convoy and lp:~landscape/convoy/debian-packaging
[16:39] <ahasenack> )
[16:39] <ahasenack> I'm thinking the changelog got included in the tarball, and that has an automatically generated entry by the recipe, so that could explain why the tarball has different contents
[16:39] <SpamapS> Daviey: I'd be more than happy to stuff MySQL 5.5 into the NEW queue before tomorrow.. :-D
[16:50] <mterry> jtaylor, yeah, as SpamapS says, it was uploaded and is just waiting on approval
[16:51] <jtaylor> k
[16:53] <tgardner> is 'apt-get trap divide error' a known problem with the oneiric installer? it happens consistently in base-installer/kernel
[17:17] <azop> tgardner: looks that way
[17:17] <azop> fixed in apt 0.18.16-exp5ubuntu3 according to #8232777
[17:25] <slangasek> SpamapS: import-dsc> are there inconsistencies in the contents wrt what's been uploaded, or is it just the pristine-tar data missing for 1.3 that you're concerned about?
[17:26] <slangasek> SpamapS: currently attempting another merge-upstream null-merge, which should be enough to get on with I think
[17:33] <tkamppeter> mterry, hi
[17:34] <achiang> when does debian import freeze normally occur within a release cycle?
[17:34] <achiang> oh, i found it -- https://wiki.ubuntu.com/OneiricReleaseSchedule
[17:34] <mterry> tkamppeter, hi.  I saw your libicc request.  I'm getting to it
[17:35] <tkamppeter> mterry, OK.
[17:59] <bryceh_> @pilot out
[18:00] <bryceh> @pilot out
[18:25] <mdeslaur> pitti: so, does anything still use gksu on the desktop cd?
[18:25] <mdeslaur> pitti: I just noticed software-properties doesn't anymore
[18:27] <brendand> hi
[18:27] <brendand> anyone else not able to login on oneiric?
[18:27] <micahg> mdeslaur: gparted?
[18:29] <mdeslaur> micahg: hmm...that's on the cd?
[18:29]  * micahg thought it was
[18:59] <kees> hallyn: hi! do you mind if I build qemu-kvm with PIE?
[19:03] <hallyn> kees: will it break?  :)
[19:03] <kees> hallyn: I don't think so -- testing now
[19:03] <mdeslaur> hallyn: well, it'll be secure :P
[19:03] <hallyn> bullocks :)
[19:03] <mdeslaur> lol
[19:03]  * hallyn points to that big ugly graphics driver over thar
[19:04] <hallyn> kees: i've got no objection, thx.  i'm curious if it'll slow anything down
[19:05] <ara> barry, we are preparing a checkbox upload, will you be able to sponsor it?
[19:05] <barry> hi ara; i could do it
[19:05] <ara> thanks barry!
[19:05] <ara> barry, I will let you know when it is ready
[19:06] <barry> sounds good!
[19:11] <kees> lamont: say, can you get dnssec validation into bind9? it'd be nice to have that in oneiric by default...
[19:12] <kees> lamont: (i.e. by tomorrow...)
[19:14] <micahg> mdeslaur: checkbox is also using gksu
[19:15] <mdeslaur> micahg: ah, thanks
[19:22] <bdmurray> so looking at bug 450347 we can see 'pycentral pkginstall: not overwriting local files' - that's not really our (Ubuntu's) fault is it?
[19:28] <lamont> kees: by tomorrow?
[19:28] <lamont> sigh
[19:28] <kees> lamont: hehe
[19:28] <lamont> hate you all
[19:29] <kees> lamont: it's just one small stanza :)
[19:29] <lamont> kees: got a diff for me?
[19:29] <kees> lamont: yeah, it's in the debian bug that has been open for 8 months. ;)
[19:29] <lamont> cool
[19:29] <lamont> I should read that
[19:29] <kees> hehe
[19:30] <kees> lamont: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516979
[19:31] <kees> lamont: s/8 mon/2.5 years/ ;)
[19:31] <lamont> those are nearly equal, no?
[19:49] <ara> sorry barry, it is taking a bit longer than expected (fails to build), we are fixing it
[19:49] <barry> no problem ara
[19:50] <ara> just to have everything prepared, as lp:ubuntu/checkbox is sync with lp:checkbox, once we have lp:checkbox ready to be merge, do we need to open a sync bug?
[19:50] <ara> or just tell you that it is good to go?
[19:50] <barry> ara: once those two branches are sync'd, i think we're good to go
[19:51] <ara> OK, thanks
[19:51] <mdeslaur> pitti: gaaah...you can't launch a setuid binary from a .desktop file...pkexec won't run :P
[19:51] <mdeslaur> pitti: I guess I need a wrapper
[21:40] <cr3> when requesting a candidate for upload in main, should reporting a bug against the ubuntu project and requesting a merge request be sufficient, or should I also subscribe ubuntu-sponsors to the bug?
[21:47] <micahg> cr3: merge proposal against an ubuntu branch is a sponsorship request, as long as the branch is linked to the bug, no need to subscribe sponsors to it
[21:48] <slangasek> cr3: more details: https://wiki.ubuntu.com/SponsorshipProcess
[21:48] <SpamapS> slangasek: I'm not sure I understand what a null merge is..
[21:49] <SpamapS> slangasek: but it would be nice if there were a documented way to resolve the missing pristine-tar bit
[21:52] <slangasek> SpamapS: stitching in the upstream tarball without (in theory) changing the current branch state.  In this case, since the upstream bzr branch had also been merged and only the pristine-tar was missing, the command looks like this: bzr merge-upstream --last-version=0.9.7 --version 1.3 /mirror/ubuntu/pool/main/u/upstart/upstart_1.3.orig.tar.gz
[21:52] <cr3> thanks folks!
[21:53] <SpamapS> slangasek: *OH*
[21:53] <SpamapS> slangasek: thats quite useful information.. I always wondered how to do that. :)
[21:54] <slangasek> SpamapS: I say in theory because the batch of merge conflicts it spit out led me to accidentally commit something that didn't quite match what should've been, so there are two commits where there should've been one :P
[22:22] <lifeless> bdmurray: ping
[22:22] <lifeless> bdmurray: whats the test for 'filed by apport' ?
[22:31] <bdmurray> lifeless: tag = apport-bug or apport-package or apport-crash
[22:32] <lifeless> bdmurray: any of ?
[22:32] <bdmurray> lifeless: so searchTasks with tags 'apport-crash' and 'natty'
[22:32] <bdmurray>             tasks = ubuntu.searchTasks(status=STATI, tags=search_tags,
[22:32] <bdmurray>                 tags_combinator='All', created_since=release_date)
[22:33] <lifeless> ok, hang a sec
[22:33] <bdmurray> I've actually got to run soon
[22:34] <bdmurray> and STATI = any status
[22:35] <lifeless> ah, they are tags not series tasks ?
[22:35] <lifeless> do you need up to minute, or will staging data be ok ?
[22:37] <bdmurray> staging would be fine, thanks
[22:43] <lifeless> bdmurray: sent to the list.
[23:08] <ScottK> lamont: FYI there was whining about no multi-instance support in Debian/Ubuntu on postfix-users today.  You know which release team member to ask about an exception, right?
[23:08] <lamont> ScottK: you?
[23:08] <ScottK> If you want it approved, yes.
[23:08] <ScottK> ;-)
[23:09] <ScottK> It would be nice to get in and making it reasonably regression safe ought to be doable.
[23:09] <ScottK> Alternately upload before 1800 UTC tomorrow and then bugfix as needed ...
[23:11] <matttbe> Hello,
[23:11] <matttbe> I'm looking for a sponsor in order to upload 3 packages before the feature freeze (sorry to be a bit late :-/) in universe: cairo-dock, cairo-dock-plug-ins and latexila.
[23:11] <matttbe> 3 bzr branches have been created. 'bzr merge-upstream' has been used to commit these revisions on these bzr branches and they should be ready to be uploaded on Universe.
[23:12] <lamont> ScottK: I have bind9 tonight, and will look at postfix either tonight or sunday
[23:12] <micahg> matttbe: it's in the sponsorship queue, asking in multiple channels per hour, I don't know how helpful that is
[23:12] <ScottK> lamont: Very cool.  Thanks.
[23:12] <matttbe> micahg: ok sorry for that
[23:15] <slangasek> wendar: I'm surprised to see component mismatches in connection with the new USB seed (audacity, anjuta, frozen-bubble, wesnoth) - and don't remember those having been part of the discussion at UDS... can I drop those from the seed in the short term so we have something testable?
[23:15] <cjwatson> FWIW the CD builder will just ignore stuff that's out of the components it's been told to look at
[23:15] <slangasek> ah
[23:16] <slangasek> ok, then I'm just left wondering about the rationale for the packages being promoted to main and put on the image :)
[23:30] <RAOF> slangasek: Are you having problems installing libc6:i386?  Apt refuses to install it, and I find the debug messages inscrutable.
[23:31] <slangasek> RAOF: it's a regression, doko accidentally dropped the M-A: same field in the latest merge from Debian
[23:31] <slangasek> RAOF: we basically should just revert that part of the merge
[23:31] <RAOF> Aha.
[23:31] <slangasek> (Debian has dropped it over concerns about certain biarch+multiarch collisions causing libs in /lib to be overwritten... no one has reported this problem yet in Ubuntu, and the fix is known, so we should just roll with it)
[23:52] <slangasek> RAOF: if you want to fix eglibc up for this, you have my blessing; otherwise it probably has to wait for doko's morning
[23:53] <RAOF> slangasek: I'm happy to remain not TIL on eglibc.  It's not urgent.
[23:53] <slangasek> ok :-)
[23:54] <slangasek> barry: btw, how do you feel about me making libpython2.7 multi-arch: same this cycle ;P