[00:32] <bdmurray> I could use a sponsor for bug 878585
[00:37] <stgraber> bdmurray: looking
[00:38] <bdmurray> stgraber: thanks
[00:42] <Keybuk> oh, now the tree goes red
[00:44] <StevenK> RAOF: MPRIS works out of the box with Quod Libet and Do in Oneiric :-)
[00:44] <RAOF> StevenK: Woot!
[00:45] <StevenK> RAOF: And it seems the music menu uses MPRIS, since it shows what is playing
[00:45] <RAOF> Yup, that's right.
[00:45] <Keybuk> ww
[00:48] <stgraber> bdmurray: uploaded
[00:51] <bdmurray> stgraber: thanks!
[00:56] <RAOF> StevenK: I guess that means I should clean up that plugin, adapt it for some of the new Do infrastructure that'll make it better, and then make a release ;)
[01:08] <StevenK> RAOF: Sounds great to me. :-)
[05:01] <ok2cqr> Hello,
[05:02] <ok2cqr> for the first time, my package got into Ubuntu repositories. But there is a bug which prevents users to use my program. Hi could I get fix to the upstream package, please?
[05:02] <ok2cqr> How could I ...
[05:38] <pitti> Good morning
[05:48] <ajmitch> morning pitti
[05:51] <didrocks> good morning
[06:35] <toshaSA> Idea. Develop to the main system that when an application is run, it checks what that application is with a server. the server returns all packages to the client to make sure that the application will run. This will benefit when running .Net throu wine. E.g.... Running COD4, it retrieves the wine package, Directx.dlls and then executes.
[06:35] <nigelb> Laney: ping, around?
[06:39] <pitti> there, all SRU queues empty again *phew*
[06:39] <nigelb> pitti: *applause* :)
[06:40] <Chipzz> toshaSA: in one word, HORRIBLE. real solution: package the application. EOT
[06:45] <RAOF> toshaSA: To some extent that's what winetricks does; that's packaged in the archive and wine Recommends it.  To turn it into a general-purpose solution you'd end up doing essentially the same work as packaging the app.
[06:47] <Chipzz> but his solution ends up reinventing apt. we already have apt.
[06:51] <dholbach> good morning
[07:07] <mvo> @pilot in
[07:08]  * dholbach hugs mvo
[07:10] <dholbach> happy birthday Ubuntu! https://lists.ubuntu.com/archives/ubuntu-announce/2004-October/000003.html :)
[07:11] <pitti> oooh! /me lights a candle
[07:12] <pitti> with TLRS!
[07:13] <didrocks> :)
[07:37] <Laibsch> pitti: SRU queue is empty?  what's missing in bug 508545? I thought I had completed all the necessary steps for it to enter the queue...
[07:47] <pitti> Laibsch: it wasn't uploaded yet
[07:47] <pitti> Laibsch: but look! there's your friendly patch pilot!
[07:47]  * pitti hugs mvo
[07:47] <pitti> and as it happens, also our apt guru
[07:48] <mvo> Laibsch: I check it out
[07:48] <Laibsch> pitti: the process changes too rapidly for me to keep up with it.  Haha.  I was just surprised by your statement "queue is empty" when I was in here yesterday complaining about my debdiff rottening away again in LP. ;-)
[07:48] <pitti> Laibsch: by "queue" I just meant stuff that was uploaded, but needs processing by SRU team
[07:49] <Laibsch> mvo: thanks.  By the way aptitude in oneiric and precise does not load changelogs with C.  There's a ticket so I guess you already know about it.  Just wanted to raise awareness of bugs dear to my hear, hehe.
[07:49] <Laibsch> bug 824708
[07:51] <Laibsch> pitti: I see.  That's what I meant by "process changes".  AFAICR, this process and responsibility for it wasn't separated in the past, or was it?
[07:51] <pitti> sponsoring and SRU review have always been distinct processes
[07:52] <pitti> but in the past the SRU team was able to keep up with uploading patches themselves (i. e. the sponsoring parts)
[07:53] <mvo> Laibsch: oh, but this other bug has no patch or anything yet, right?
[07:53] <Laibsch> pitti: I see.  I was wondering if that's why I got the perception.  Simply the same person wearing two hats at the same time.
[07:54] <Laibsch> mvo: unfortunately, no.  And I don't even have a workaround inside aptitude.  The program does seem to actually download the log, I believe, but somehow fails to display it.
[07:56] <Laibsch> mvo: indeed, my local proxy has copies of several changelogs for precise packages.  So, they must have been downloaded but fail to display.
[07:57] <Laibsch> I'll annotate the ticket
[07:58] <Laney> hi nigelb
[08:01] <nigelb> Laney: Do you often download the mbox file from lists.ubuntu.com?
[08:02] <nigelb> (I vaguely remember you having to do something with changes list)
[08:02] <Laney> yes
[08:03] <nigelb> I tried a wget and got a 403. :(
[08:03] <Laney> use rsync
[08:03] <Laney> lists.ubuntu.com::changes-mboxes
[08:03] <nigelb> aha. ok
[08:03] <nigelb> Hrm, I wanted a differnt list.
[08:04] <Laney> oh, well either bug IS to set up rsync for you or fake the referrer and risk wrath
[08:05] <nigelb> heh
[08:05] <nigelb> ah, one needs to fake referrer as well?
[08:05] <Laney> to use wget
[08:05]  * nigelb tries.
[08:06] <nigelb> Its a one-time thing, so I hope IS doesn't ban me permanently ;)
[08:11] <dholbach> pitti, is piware.de a bit overloaded? :)
[08:11] <pitti> ugh, seems so
[08:12] <dholbach> everybody, including me, wants to see those old pictures :)
[08:12] <pitti> hm, load 0.03, 0% cpu
[08:12] <nigelb> hehe
[08:12] <nigelb> I've been refreshing every few minutes :P
[08:12] <dholbach> nigelb, you're not helping :-P
[08:12] <nigelb> heh
[08:13] <nigelb> offload it to people.ubuntu.com!
[08:13]  * ajmitch wants to see old photos! :)
[08:13]  * mvo too
[08:13] <pitti> nigelb, ajmitch, dholbach: try again
[08:13] <dholbach> Waiting...
[08:14] <pitti> it's 0.5 s for me now
[08:14] <mvo> I can see them now - woah, that was a loooong time ago
[08:14] <pitti> I didn't actually have them online until today, but I thought it was worth it for the occasion
[08:14] <pitti> dholbach: thanks for pointing out, couldn't resist :)
[08:14]  * ajmitch was looking at photos from the sydney UDS the other day, these are even older :)
[08:15] <pitti> meh, ten people looking at it can't possibly bring down the box
[08:16] <geser> ajmitch: put them online (if they aren't)
[08:16] <nigelb> pitti: 10 people that you know of ;)
[08:16] <ajmitch> geser: I think any of my photos are online, I was looking at others, but at least half the links are broken these days
[08:16] <nigelb> hrm, someone needs to point out who's who.
[08:17] <nigelb> scott had a link with old pictures somewhere
[08:17] <nigelb> From the one in montreal, I think.
[08:18] <pitti> ah, netstat shows some 50 pending connections
[08:18] <nigelb> heh
[08:18] <dholbach> nigelb, on picture one, I'm not quite sure who the guy on the left is, but from left to right: ?, Fabio Massimo di Nitto, Jordi Mallach, Matt Zimmerman, Thom May and on the second one: Rob Weir, Daniel Stone, Scott James Remnant, Jeff Waugh
[08:19] <nigelb> I can't load picture one :|
[08:19] <pitti> # netstat | grep www|wc -l
[08:19] <pitti> 205
[08:19] <pitti> heck
[08:19] <nigelb> lol
[08:19] <ajmitch> just 10 people
[08:19] <ajmitch> ?
[08:20]  * Laney is reminded of http://oskuro.net/blog/freesoftware/new-project-to-discuss-2011-01-14-20-19 post
[08:20] <pitti> dholbach: ah, trying to remember his name..
[08:20] <ajmitch> Laney: ah, the dodgy email?
[08:21] <nigelb> that was a fun prank!
[08:22]  * ajmitch shouldn't have closed those tabs, can't see pictures now :)
[08:22] <nigelb> Ah. https://wiki.ubuntu.com/DeveloperSummit links to old summits and each page has their own photo links for the older ones :)
[08:22] <ajmitch> nigelb: right, not all links are still working
[08:22] <dholbach> nigelb, it's Nathaniel McCallum
[08:22] <nigelb> dholbach: You have a spectacular memory :)
[08:23] <nigelb> someone who opened photo one can mirror it elsewhere? :)
[08:23]  * ajmitch wonders who http://www.grawert.net/udu-gallery/img020.jpeg could be :)
[08:23] <nigelb> Is that dholbach!!
[08:24] <pitti> it's that hug freak dude
[08:24] <geser> ajmitch: are you trying to get the next host down? :)
[08:24] <nigelb> heh
[08:24]  * pitti hugs dholbach
[08:24]  * nigelb hugs dholbach as well
[08:24] <ajmitch> geser: I'm sure ogra's site can handle it :)
[08:24] <nigelb> geser: "DDoS all servers with old Ubuntu summit pictures" seems to be today's motto
[08:26] <pitti> nigelb: http://people.canonical.com/~pitti/photos/07%20-%20Warty%20Hack%20room.jpg
[08:26] <pitti> that's the "picture one" people talk about
[08:27] <nigelb> pitti: aha, thanks!
[08:34] <geser> and who is hiding in the background? whose hand is it?
[08:37] <seb128> geser, jordi
[08:42] <geser> I see there 4 hands on the notebooks and a 5th in the back (and Matt is sitting to far away for it to be his hand)
[08:44] <lool> Hmm how would I get in touch with people interested in CAcert and coming to UDS?
[08:45] <lool> would it be ok to bring that up on ubuntu-devel@ or is there some better forum for it?
[08:45] <glatzor> morning mvo, I wrote some lines about the PackageKit compat thingy https://blueprints.launchpad.net/ubuntu/+spec/aptdaemon-p-pkcompat
[08:46] <Daviey> lool: uds-announce@lists.ubuntu.com ?
[08:46] <Daviey> I suppose that implies you will be organising an assuring event?
[08:47] <mvo> glatzor: thanks, I will ask to get this on the agenda
[08:52] <lool> Daviey: Actually I have no experience with CAcert events, so certainly not proposing to organize one myself
[08:52] <lool> but interested in getting the conversation going
[08:59]  * dholbach hugs you all back
[09:00] <tumbleweed> lool: it's common for CACert assural to happen at keysignings. I'm an assurrer (alhtough I can't give maximum points), and I'm sure there'll be others there too. Announce it at the party, and let  people coordinate it themselves?
[09:09] <Daviey> tumbleweed: don't you need 2 x offical id's?  Without prior warning, i suspect people will only have their passport on them.
[09:10] <Daviey> lool: FOSDEM always has a good CACert turnout btw.
[09:17] <zyga> hi, I've seen some mentions of a hook that disables useless triggers (like man pages update) for pbuilders but I cannot find details on how to do so, does anyone remember how to do it off the top of their head?
[09:20] <lool> Daviey: Yup; I was hoping to start something at UDS though
[09:20] <lool> Daviey: Do you know of some CAcert people coming to UDS?
[09:20] <lool> tumbleweed: cool
[09:21] <tumbleweed> Daviey: oh fair point, warn people to bring two IDs, yes
[09:21] <Daviey> lool: nope :(.. I believe i have some points.. but largely gave up on it.
[09:21] <lool> tumbleweed: But things like driving license are accepted for most countries, right?
[09:22] <tumbleweed> yes, many countries don't have a better second ID than that (although a US visa is also a vaguely reasonable ID)
[09:25] <glatzor> mvo, there is also https://blueprints.launchpad.net/ubuntu/+spec/aptdaemon-p-threading - but I haven't written a wiki page yet, but it helps to keep track of the bugs and branches
[09:27] <mvo> glatzor: I saw this one, thanks for it too
[09:28] <geser> zyga: /usr/share/doc/pbuilder/examples/D80no-man-db-rebuild
[09:28] <zyga> geser, oh, I have not looked there, thanks :)
[09:34] <tseliot> cjwatson: what's the recommended way to permanently disable grub's fb in Ubuntu?
[09:44] <mwhudson> grrr my x220 fails to resume more than once
[09:44] <mwhudson> seems completely consistent
[09:44] <mwhudson> at least it boots fast :-)
[09:51] <mwhudson> i get a flashing caps lock key on the second resume
[09:51] <mwhudson> is this known?
[09:53] <amitk> mwhudson: kernel oops
[09:53] <mwhudson> amitk: so i gather, is there a way of finding out anything about the oops?
[10:03] <zyga> mwhudson, still up?
[10:03] <zyga> mwhudson, working for the release I guess
[10:04] <mwhudson> zyga: just hanging around, not really up
[10:47] <cjwatson> tseliot: GRUB_TERMINAL=console
[10:47] <tseliot> cjwatson: thanks a lot
[11:13] <doko> cyphermox, please merge xapian-core today, there are dep-waits
[11:15] <doko> barry, hmm, you did upload libvigraimpex with the hdf5 b-d, see http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
[11:15] <dholbach> shadeslayer, happy birthday! :)
[11:31] <cyphermox> doko: ah, okay, but I wouldn't be able to upload it anyway, it was a drive-by fix
[11:31] <cyphermox> that said, I'll be happy to do it, just can't now (in a train to get to the office)
[11:38] <doko> cyphermox, I can sponsor, or anybody else
[11:39] <cyphermox> sure, I'll do the merge as soon as I get in the office (30 min to an hour) then ping you
[11:48] <mvo> @pilot out
[11:57] <barry> doko: i am working on a patch for that.  it's more difficult than just merging in the changes from oneiric because there are many more references to hdf5 that need to be commented out, which led to a few other issues.  right now i'm working out the dpkg-gensymbols differences.
[12:03] <lool> pitti: Hey, https://code.launchpad.net/~kelemeng/pkgbinarymangler/bug855085/+merge/76296 still shows up as Approved rather than merged and I don't see the changes in the bzr history, but you confirm in the bug that they have been uploaded; should we close the mp then?
[12:06] <Daviey> lool: you just outlined a bug in ubottu :)
[12:08] <lool> erf
[12:18] <pitti> lool: thanks for pointing out, I set it to "merged"; no idea why it wasn't done automatically
[12:20] <lool> pitti: Maybe lp:ubuntu/pkgbinarymangler != lp:pkgbinarymangler?
[12:20] <pitti> ah, that might be the case, yes
[12:40] <victorp> mdz, ping
[13:02] <jamespage> is syncpackage --no-lp ... the right way todo fakesyncs?  I have a few I need to deal with due to inconsistent generation of .orig.tar.gz's from github
[13:03] <Daviey> jamespage: no, that still won't work.
[13:04] <Daviey> oh, maybe it will.
[13:04] <jamespage> its the advice from syncpackage when it encounters one - but there is a WARNING in the man page about using it
[13:04] <Laney> discouraged unless necessary
[13:04] <tumbleweed> jamespage: --no-lp is the right way, yes
[13:04] <Laney> which it sometimes is, like for fakesyncs
[13:05] <Daviey> jamespage: The warning is due to possible breakage in the users hands..
[13:05] <Daviey> I didn't know syncpackage could handle fakesync's.. i thought you had to do it manually.
[13:06] <jamespage> great - thanks for the guidance
[13:06] <tumbleweed> yeah the warning is for people using syncpackage for non-fake syncs
[13:06] <Laney> that sounds annoying though; can you write a get-orig-source to avoid it in future?
[13:07] <tumbleweed> whenever there's a get-orig-source and we leapfrog debian, there are going to be mismatches
[13:07] <Laney> not if it gives you identical output
[13:07] <Laney> sounds like using github is almost guaranteed to give you mismatches
[13:07] <tumbleweed> that too
[13:08] <tumbleweed> get-orig-source normally does some kind of repackaing, which will never give you identical output
[13:08] <Laney> no reason why it can't
[13:08] <jamespage> Laney, tumbleweed: took me a while to figure out that github was doing this
[13:08] <Laney> directhex figured out the runes some time ago
[13:08] <directhex> snuh?
[13:08] <Laney> involves gzip -n and tar --mtime iirc
[13:09] <Laney> for deterministic get-orig-source
[13:09] <directhex> oh, yes
[13:09] <tumbleweed> Laney: can we document that somewhere?
[13:09] <jamespage> it would be great if it could be added to the uscan man page - it has a specific section about using the github redirector so would fix nicely there
[13:10]  * tumbleweed added my list of gotchas to the repacking section of the packaging guide (back when it was on the wiki)
[13:11] <jamespage> I've tried to avoid this happening by using git to maintain my Debian package branches
[13:11] <Laney> pristine-tar takes care of it for you, indeed
[13:11] <jamespage> and storing the .orig.tar.gz alongside the source and packaging branches
[13:12] <Laney> you just need to make sure that debian use an identical orig if they upload second
[13:12] <jamespage> but it relies on the DD that sponsors my upload using that rather than get-orig-source
[13:12] <Laney> both using a properly deterministic get-orig-source is one way of achieving this, pristine-tar is another
[13:12] <jamespage> using both covers both bases
[13:34]  * cjwatson defeats scons.  Another three-quarters of an hour of my life lost to obtuse build systems.
[13:35] <barry> cjwatson: \o/
[13:36] <pitti> mvo: can you please reupload software-properties with -v to include https://launchpad.net/ubuntu/oneiric/+source/software-properties/0.81.13 ?
[13:36] <barry> doko, or perhaps cjwatson: here are the changes to libvigraimpex that produces a successful (local) build on precise.  could you take a quick sanity check on them before i upload?  esp. the .symbols changes: http://paste.ubuntu.com/714185/
[13:37] <cjwatson> looks plausible enough from a quick scan
[13:38] <barry> cjwatson: thanks.  i guess that's what bug reports are for, right? :)
[13:38] <tumbleweed> barry: why are we making the symbols optional, why not remove them?
[13:38] <cjwatson> ugh, has that symbols file not heard of (c++)
[13:39] <cjwatson> tumbleweed: it would make the patch submittable to Debian
[13:39] <barry> tumbleweed: because in debian, there are using (optional) all over the place, so i followed suit
[13:40] <barry> cjwatson: i wonder if debian would want this patch since it's purely a result of our main/universe b-d policy
[13:41] <tumbleweed> barry: fair enough I see what you muean
[13:42] <barry> tumbleweed: slangasek did comment on the bogosity of that, but not for us to worry about :)
[13:42]  * tumbleweed wonders what the point of a 70% optional symbols file is
[13:47] <cjwatson> barry: maybe or maybe not; sometimes it's worth a try
[13:47] <barry> cjwatson: i guess it can't hurt to submit it
[13:48] <Laney> the package is orphaned?
[13:49] <Laney> → QA upload
[14:21] <OdyX> tkamppeter: wrt http://wiki.debian.org/Teams/Printing/RethinkingTheStack#Action_1_-_Rename_printing_driver_packages what should we do with hplip, hp* ?
[15:26] <doko> dbarth, just looking with cyphermox into xapian-core. your patch is not applied
[15:26] <mneptok> anyone here familiar with debian-installer and parted stuff? i'm curious if during installation it is possible to choose a partition table format (e.g. GPT) or if MS-DOS type is the sole choice.
[15:27] <cyphermox> dbarth: ^^ the cjk tokenizer patch
[15:40] <cjwatson> mneptok: Interactive partition table type selection requires booting d-i in expert mode.  However, d-i will automatically select GPT if installing on EFI-based systems or if the disk is >2TiB.
[15:43] <jcastro> charlie-tca: 15 minute session warning!
[15:43] <charlie-tca> Got it.
[15:43] <charlie-tca> Thank you
[15:52] <dbarth> doko: uh?
[15:52] <dbarth> doko: how come?
[15:52] <dbarth> didrocks: ^^
[15:53] <didrocks> dbarth: wait, on mumble
[15:53] <dbarth> doko: without the patch, it's not supposed to be working
[15:54] <dbarth> doko: hm,, let me check the email thread; we may carry a point release that contains the cjk-support patch
[15:54] <dbarth> doko: ie, without the need for a distro-patch; i know that upstream had done something special and upstream in debian, to accommodate our case
[15:56] <doko> dbarth, ENOCLUE. I just do see that it is not applied
[15:58] <dbarth> doko: ugh, do you have a log to that build issue?
[16:02] <cyphermox> dbarth, I don't think there's anything special, added by debian or upstream in 1.2.7 to accomodate this
[16:03] <mneptok> cjwatson: my UEFI ThinkPad got an MSDOS table, probably because the rudimentary BIOS was set to "Legacy" boot during installation. that mode then fails to boot, and i'm using UEFI. not knowing about the option in d-i expert mode, i wrote a new table with the drive out and in a dock.
[16:03] <dbarth> well, i re-read http://trac.xapian.org/ticket/180#comment:29
[16:04] <dbarth> the patch was re-hashed especially for us
[16:04] <dbarth> which was cool
[16:04] <doko> dbarth, just download the package, there is nothing applied before or during the build, afaics
[16:05] <cjwatson> mneptok: right, if it's booted in legacy mode, it's a BIOS system as far as d-i is concerned
[16:07] <popey> hello! https://launchpad.net/ubuntu/oneiric/+source/policykit-desktop-privileges/0.6 "* Allow local admins to update already installed software without password"
[16:07] <popey> Does anyone have a link to where/if that was discussed?
[16:09] <didrocks> doko: dbarth: the patch is applied in the ppa, I was on vacation when cyphermox pushed it, I have no clue what's different from the version I pushed in the ppa
[16:09] <cyphermox> didrocks: same patch if you took it from the upstream bug
[16:09] <didrocks> doko: dbarth: but I confirm there is no debian/patches/series containing it
[16:10] <didrocks> cyphermox: you don't took my packaging it seems
[16:10] <didrocks> cyphermox: there is no reference of the patch in a debian/patches/series
[16:10] <didrocks> so quilt doesn't pick it up
[16:10] <cyphermox> didrocks: I had no idea you had packaging, or where the ppa was
[16:10] <cyphermox> I do realize that :P
[16:10] <didrocks> cyphermox: who asked you to push it then?
[16:11] <didrocks> (as I was on holidays with no internet connexion, I didn't track it)
[16:11] <cyphermox> might have been seb128
[16:11] <cyphermox> I don't recall
[16:11] <didrocks> would have been nice people connecting the dots :)
[16:11] <cyphermox> the weird thing is, it seems to work anyway
[16:11] <didrocks> but anyway, what is needed now is a SRU
[16:11] <didrocks> with this patch applied
[16:12] <didrocks> it's working? O_o
[16:12] <cyphermox> didrocks: I'm pretty sure things were working properly when I tested it
[16:13] <cyphermox> didrocks: plus someone else should have been testing this too, no? xapian-core was uploaded a while before the rest of the unity stuff for this CJK thing
[16:13] <seb128> didrocks, what?
[16:13] <cyphermox> (e.g. time to catch it if the upper layers don't appear to work)
[16:13] <didrocks> cyphermox: I'm not sure, not sure why I'm pinged by dbarth either, there is no context :/
[16:14] <didrocks> just the "patch is no applied"
[16:14] <didrocks> cyphermox: from what I knew, OEM tested it, not sure if it's from the ppa or oneiric proper, by yeah
[16:14] <didrocks> but*
[16:14] <cyphermox> didrocks: well, doko caught that as he was reviewing my merge of xapian-core 1.2.7-1ubuntu1
[16:15] <didrocks> cyphermox: ok, we need to ensure if it's needed or not (it seemed to be needed for at least software-center), can you sort this out or do you need help?
[16:15] <didrocks> cyphermox: basically, the fix is easy, it's adding it in debian/patches/series (but if your patch is different from the one we tested in the ppa, it needs careful testing then)
[16:15] <cyphermox> didrocks: I can sort it out; I just installed ko and jp inputs to give this testing, and software-center was what I was using
[16:16] <cyphermox> didrocks: the patch I took straight from the upstream bug, it just needs a refresh to apply properly to 1.2.7... not sure if that was required for 1.2.5 as well
[16:16] <didrocks> cyphermox: great! keep us in touch :)
[16:16] <didrocks> cyphermox: well, I'm more concerned for Oneiric right now
[16:17] <cyphermox> sure
[16:17] <cyphermox> didrocks: I'll just pick up yours from the PPA
[16:17] <mneptok> cjwatson: my rudimentary BIOS also allows "Both." i'd be interested to see what d-i chooses. someone what to buy me a 2.5" laptop drive? O:)
[16:17] <seb128> didrocks, cyphermox: is the issue https://launchpad.net/ubuntu/oneiric/+source/xapian-core/1.2.5-1ubuntu1 ?
[16:17] <didrocks> seb128: yeah
[16:17] <mneptok> s/what/want/
[16:17] <cyphermox> seb128: yup
[16:17] <seb128> what about it?
[16:17] <didrocks> cyphermox: just test without first :)
[16:17]  * mneptok pokes cr3
[16:18] <didrocks> seb128: see backlog ^
[16:18] <cyphermox> didrocks: yeah, working on it, I'm at restarting my session now, which I can't do if I need to answer things on IRC :)
[16:18] <seb128> didrocks, is that a quilt package and the patch didn't make it to the series?
[16:18] <cyphermox> seb128: correct
[16:18] <didrocks> seb128: seems so
[16:18] <seb128> ok
[16:18] <seb128> Signed-By: Michael Vogt <michael.vogt@ubuntu.com>
[16:18] <didrocks> cyphermox: reboot please
[16:18] <didrocks> :)
[16:18] <didrocks> now now! ;)
[16:18] <cyphermox> didrocks: zug zug :)
[16:19] <cr3> mneptok: yo mama, what's up?
[16:19] <seb128> cyphermox, did you provide a debdiff?
[16:19] <mneptok> cr3: PM (busy channel)
[16:19] <seb128> well dunno, it was a packaging screwup at the time th work was done
[16:19] <cyphermox> yes
[16:19] <didrocks> seb128: I guess we don't care about who did it wrong, just trying to figure out if not having the patch for Oneiric is critical right now
[16:20] <didrocks> I know that people testing it starting september and didn't notice issues
[16:20] <didrocks> so, there is hope
[16:20] <didrocks> in that case, not sure what's the xapian patch is for then
[16:21] <bdrung> jamespage, Daviey, tumbleweed: the man page should be more clear that --no-lp is the way for fakesyncs. should it fall back to --no-lp if a fakesync is detected?
[16:22] <rigved> hi everyone...can anyone tell me how to apply the patch as mentioned in the last comment on bug 849967
[16:22] <seb128> didrocks, did we ever get any complain on the bug tracker about cjk?
[16:22] <jamespage> bdrung: I think the message it give ATM is sufficient - I would probably want to take a look at why before I went down that path anyway
[16:22] <didrocks> seb128: didn't notice
[16:22] <seb128> didrocks, I guess the people who hit the issue don't interact much with us so we will not notice it
[16:22] <didrocks> right
[16:22] <seb128> didrocks, we need to check with oem teams
[16:23] <didrocks> but OEM tested oneiric in beta1
[16:23] <didrocks> IIRC
[16:23] <didrocks> when we landed everything
[16:23] <didrocks> just need to be sure they didn't take the ppa version
[16:24] <jamespage> bdrung: hrm - thats the message that syncpackage gives (not what it says in the man page)
[16:24] <jamespage> just to be clear :-)
[16:27] <Kaleo> any idea of how that could happen? http://pastebin.com/NbJ2Mite
[16:29] <cjwatson> mneptok: at any one time you can only be booted using one or the other; some Ubuntu images support both and in those cases either the firmware will pick one or it will ask you to choose
[16:30] <cjwatson> Kaleo: what version of apt?
[16:31] <Kaleo> cjwatson: one in an unstable version of oneiric, let me check
[16:32] <cjwatson> Kaleo: I expect this is bug 871731, affecting the version shipped in 11.10 beta-1 but not 11.04 and not 11.10 beta-2 - run 'apt-get install apt' and then 'apt-get update' again
[16:32] <cjwatson> it was fixed in, I believe, apt 0.8.16~exp5ubuntu9
[16:33] <Kaleo> cjwatson: 0.8.16~exp5ubuntu6
[16:33] <cjwatson> Kaleo: right, that was what was shipped in beta-1.  Your 'apt-get update' got far enough that you should be able to upgrade apt and try again.
[16:33] <Kaleo> cjwatson: it fixed it
[16:34] <Kaleo> cjwatson: you rock my world :)
[16:34] <cjwatson> Kaleo: we decided this was worth it because otherwise we'd have had to roll back several Launchpad changes and regress bandwidth costs for multiarch users
[16:34] <Kaleo> cjwatson: ok
[16:34] <Kaleo> cjwatson: what would you like for UDS?
[16:34] <Kaleo> cjwatson: beer?
[16:34] <cjwatson> which we did consider, but given that the upgrade works and is just ugly ...
[16:35] <Kaleo> I get it
[16:35] <cjwatson> Kaleo: heh, I have a two-year-old, sleep is high on the agenda ;-)  but beer rarely goes amiss
[16:35] <Kaleo> cjwatson: :)
[16:37] <didrocks> cyphermox: is it working?
[16:57] <xtian> hi everyone. i'm seeing a funny behaviour with ubuntu/precise. have set up a precise chroot (amd64) on an amd64 host
[16:58] <xtian> ...using debootstrap --arch=amd64
[16:59] <xtian> chrooted into it, added few sources, updated, selected a bunch of packages (~100), and ran apt-get upgrade
[16:59] <xtian> now apt would try to install i386 packages randomly, for about half of the packages selected
[17:00] <xtian> removed 'foreign-architecture i386' from /etc/dpkg/dpkg.cfg.d/multiarch, re-ran apt, now everything is installed as amd64
[17:00] <xtian> did not see this with oneiric, even though the i386 multiarch entry was also there
[17:15] <xtian> (i've been redirected here from #ubuntu)
[17:16] <cjwatson> xtian: it may be transient due to i386 and amd64 builds not necessarily being in perfect sync at the moment
[17:16] <cjwatson> which is slightly inevitable with development releases although unfortunate
[17:16] <cjwatson> xtian: do you have specific examples that are going wrong at the moment?
[17:17] <cjwatson> I kind of think apt-get shouldn't pick foreign-arch packages to satisfy explicit requests, but I can't remember what the spec says ...
[17:17] <cjwatson> slangasek might have a better handle on that
[17:17] <xtian> cjwatson: yeah, apt was picking i386, although amd64 packages were available
[17:18] <xtian> cjwatson: after removing the multiarch entry for i386, everything went fine
[17:18] <cjwatson> available but perhaps not installable
[17:18] <cjwatson> do you have specific examples?
[17:18] <xtian> cjwatson: not at the moment, i could do it again (afresh) and post the result
[17:19] <xtian> cjwatson: would take a little whilre
[17:19] <cjwatson> yep.  you might find the results changing from hour to hour at the moment, of course
[17:19] <xtian> cjwatson: should i open a bug for that
[17:19] <cjwatson> it probably wouldn't hurt, although I don't know how immediately addressable it would be
[17:19] <xtian> cjwatson: okay, if it is not a bug in apt/dpkg, then i'm not worired
[17:19] <xtian> *worried
[17:19] <cjwatson> it sounds like a misfeature at least
[17:20] <cjwatson> although I don't know if it's fixable without breaking other things we rely on
[17:21] <xtian> ...in the light of the respective amd64 packages available and installable, a misfeature, yes :)
[17:21] <cjwatson> (e.g. smooth transitions of biarch/traditional -> multiarch)
[17:21] <cjwatson> xtian: how do you know they were installable?  you know they were available, but ...
[17:21] <xtian> cjwatson: after removing the multiarch entry for i386, the amd64 packages were installed
[17:21] <cjwatson> my unproven hypothesis here is that apt wasn't able to resolve some dependency using only native-architecture packages, and fell back to foreign-arch
[17:22] <cjwatson> xtian: right, but you ran apt-get update in between, right?
[17:22] <xtian> cjwatson: yes
[17:22] <slangasek> xtian, cjwatson: would like to see specific commands and output of what's happening; yes, apt is meant to always prefer the native packages, but I know there's at least an issue that once it's picked *one* i386 package to satisfy a dependency, it will remain sticky to that arch when it shouldn't
[17:22] <cjwatson> so the situation might have changed in the archive
[17:23] <slangasek> i.e., whereas installing an i386 library that depends on a multi-arch: foreign package should prefer the amd64 version of that package, apt is preferring the i386 version
[17:24] <cjwatson> it doesn't sound like xtian's situation ought to have involved anything from i386, though
[17:24] <xtian> slangasek, cjwatson: i've searched all regular files in the chroot, and all ELF objects were amd64 after removing the multiarch entry
[17:24] <slangasek> xtian: much easier to run dpkg -l '*:i386' :)
[17:25] <slangasek> bug #877681 is the apt bug about wrong m-a: foreign packages being chosen
[17:25] <xtian> slangasek: true... but i wanted to be sure and see what's actually *there* (didn't trust dpkg at that moment) :)
[17:25] <slangasek> dpkg is trustworthy in this regard
[17:26] <slangasek> if you ever found that it wasn't, that'd be a critical bug
[17:26] <xtian> slangasek: ok, convinced... :)
[17:26] <slangasek> cjwatson: right, so bug #877681 describes the one issue I know where there's an apt bug; I agree that xtian's situation sounds more like transient archive skew
[17:27] <cjwatson> slangasek: right, I'm unconvinced that transient archive skew ought to be allowed to lead to this though
[17:28] <xtian> slangasek, cjwatson: okay, i'll keep an eye on it, just wanted to make sure it is not apt/dpkg/... failing somewhere
[17:28] <slangasek> cjwatson: right; it may be difficult to enforce though
[17:28] <cjwatson> ah, well, that is sort of that apt bug
[17:28] <xtian> slangasek, cjwatson: thanks for your insight, i'll also check out #877681
[17:29] <cjwatson> (maybe)
[17:33] <xtian> slangasek, cjwatson: will it be worth it to file a bug, if only for the record?
[17:33] <xtian> then again, it's always a pain searching in a bug-db, so not sure how much good a report could do
[17:33] <slangasek> xtian: probably only worth filing a bug if you can provide apt-get output showing the issue in question
[17:33] <slangasek> when you can do so, yes, please file a bug on apt
[17:34] <slangasek> (without the output, I'm sure it's too vague to ever get actioned)
[17:34] <xtian> slangasek: i can just set up the chroot again (freshly) and provide the commands and their output
[17:34] <slangasek> xtian: if it's reproducible this way, then that would definitely warrant a bug report, thanks :)
[17:35] <xtian> slangasek: as i'm thinking i see it cjwatson's way that even if there's rumble on the archive, apt should not prefer a foreign arch over it's native one, if the packages are available
[17:36] <xtian> (in native format, that is)
[17:36] <slangasek> the problem is in deciding what to do when the foreign arch package is installable and the native one isn't
[17:37] <slangasek> our choices are a) install the foreign arch one or b) hold the package back; both have drawbacks
[17:39] <xtian> hum, i've just checked, sources.list has oneiric and precise, in that order
[17:39] <xtian> maybe, after removing i386 multiarch, apt fell back to oneiric and used amd64 packages from there
[17:40] <slangasek> that could be it indeed
[17:40] <xtian> while, with the i386 multiarch in-place, it was seeing newer i386 packages in precise and used them
[17:41] <xtian> (amd64 not yet built or something)
[17:41] <xtian> .oO( live and learn... )
[17:43] <tumbleweed> anyone have any ideas why ubiquity might hang on "Detecting file systems" ? I see someone filed a similar bug, but it's light on information (bug 801223)
[17:45] <xtian> slangasek, cjwatson: thanks again, i think the apt mystery is solved
[17:46] <slangasek> xtian: I think a bug report against apt showing the specifics would still be worthwhile; preferably including 'apt-cache policy $pkg' output, with multiarch enabled, for one of the packages that apt picks the i386 version for
[17:47] <xtian> slangasek: okay, will do.
[17:48] <slangasek> bdmurray: I don't know how many people will really be trying to upgrade from lucid to precise at this stage, but bug #878960 is an issue to watch out for (could get reported against arbitrary packages, key word is '--warning=no-timestamp' in DpkgTerminalLog)
[17:49] <xtian> slangasek: will take some time, i'll start out with a fresh chroot and put precise sources in it only, let's see what happens
[17:49] <xtian> slangasek: quitting time first, EOD... at least, for work :)
[17:49] <slangasek> xtian: ah, enjoy :)
[17:50] <xtian> slangasek: thanks, cu tomorrow, when i have my bug report done
[17:51]  * xtian -> ~.
[18:01] <stgraber> pitti: ping
[18:01] <cjwatson> slangasek: well, let's minimise the window for that; fix uploaded.  I knew I'd forgotten something, as I had seen that thread on debian-devel ...
[18:02] <slangasek> cjwatson: :)
[18:02] <slangasek> thanks
[18:12] <tkamppeter> OdyX, hi
[18:13] <slangasek> $ time dput ia32-libs_20090808ubuntu28_source.changes
[18:13] <slangasek> [...]
[18:13] <slangasek> real	0m5.877s
[18:13] <slangasek> user	0m0.420s
[18:13] <slangasek> sys	0m0.136s

[18:16] <james_w> \o/
[18:37] <debfx> http://bugs.debian.org/644412 is quite annoying, it would be good to have dpkg 1.16.1.1 merged soon :)
[18:46] <simple_user> I installed the python-qt4-doc package on my system for PyQt4 docs, but don't know how to access the docs.  Where are they located on my system (oneric)
[18:56] <jtaylor> simple_user: /usr/share/doc/python-qt4-doc/html/index.html its probably registered under docbase too http://wiki.debian.org/doc-base
[18:57] <simple_user> jtaylor, thank you
[19:24] <bdmurray> Is casper supposed to be installed / installable? bug 821445
[19:41] <bdmurray> stgraber: I've run into an issue with the test you provided in bug 787212
[19:42] <stgraber> bdmurray: ah?
[19:43] <bdmurray> /etc/dhcp/dhcpd.conf line 25: IPv6 addresses are only available in DHCPv6 mode.
[19:43] <bdmurray> option dhcp6.name-servers 2001:
[19:44] <stgraber> bdmurray: why do you have a dhcp6.name-servers in /etc/dhcp/dhcpd.conf? you're supposed to have that in /etc/dhcp/dhcpd6.conf
[19:49] <bdmurray> stgraber: okay sorted
[20:08] <bdmurray> stgraber: okay now it is failing to start because it is not configured to listen on any interfaces
[20:09] <stgraber> bdmurray: right, you need to actually have an IP in the subnet you defined in your dhcpd.conf/dhcpd6.conf for the daemon to start
[20:10] <bdmurray> stgraber: or I could change the subnet to include the IP I have correct?
[20:12] <stgraber> bdmurray: indeed
[20:12] <bdmurray> stgraber: not having used ipv6 before how can I sort that out?
[20:13] <stgraber> bdmurray: ip -6 addr add <ipv6>/64 dev eth0
[20:13] <stgraber> that should add the IPv6 to the interface, making dhcpd happy
[20:13] <stgraber> if you want something more permanent you can use:
[20:14] <stgraber> iface eth0 inet6 static
[20:14] <stgraber>     address <address>
[20:14] <stgraber>     netmask 64
[21:16] <jo-erlend> guest users cannot use IM because they don't have a keyring. How do I report bugs like that?
[21:17] <cjwatson> debfx: yep, I hope to merge dpkg tomorrow
[21:18] <jo-erlend> I mean.. What is the "guest user package"?
[21:21] <doko> chrisccoulson, firefox hangs again on powerpc. please could you investigate the reason before new uploads? this blocks the powerpc builds again and again
[21:22] <cjwatson> heh, snap
[21:22] <cjwatson> (#-release)
[21:42] <jo-erlend> perhaps someone can just fix it then, so it doesn't remain unfixed forever. I have no idea how to even find out how to report a bug for bugs like that. The list is growing fairly long. Sort of feels like testing and QA is worthless.
[22:18] <SpamapS> doko: FYI, we were holding off merging PHP 5.3.8 because of a regression it introduces in many PHP apps
[22:19] <doko> SpamapS, I didn't see an issue filed about that
[22:19] <doko> nor a ntification that it shouldn't be merged
[22:20] <SpamapS> I didn't know how to make any such notification. :-P
[22:21] <SpamapS> 5.3.9 will revert the problem
[22:21] <SpamapS> no idea when its supposed to release
[22:21] <doko> at least email me that you'll care about the merge (and MoM does offer some kind of commenting)
[22:22] <SpamapS> Yeah that would have been good
[22:22] <SpamapS> zul and I usualy take care of it. :-P
[22:22] <doko> hmm, at least not about the ftbfs in oneiric ;-P
[22:24] <SpamapS> anyway, will try and figure out from upstream if 5.3.9 is expected soon
[22:24] <SpamapS> Otherwise http://pear.php.net/bugs/bug.php?id=18749&thanks=3 will break all apps that depend on PEAR
[22:24] <SpamapS> so we may have to revert back to 5.3.7
[22:24] <SpamapS> err
[22:24] <SpamapS> 5.3.6
[22:24] <SpamapS> anyway
[22:24] <SpamapS> have to run..
[22:25] <SpamapS> doko: no hard feelings, the effort is of course always appreciated :)
[22:25] <doko> SpamapS, I know now, and I'll pester you from now on, instead of doing merges myself ;)
[22:54] <bdmurray> I could use a sponsor for a debdiff in bug 787212
[22:56] <StevenK> When I tell my machines to reboot via the menu in the top right, it drops back to the login screen only. When I attempt to reboot via that menu, there is no effect, what am I missing?
[22:58] <penguin42> I've sene a few bug reports like that
[22:58] <penguin42> seen
[22:59] <slangasek> StevenK: do you have another login going at the same time?  The old "You have multiple accounts logged in, type admin password to force shutdown" integration seems to be broken; I've filed a bug but don't remember where
[23:00] <slangasek> bdmurray: looking
[23:01] <StevenK> slangasek: No, just me, once.
[23:01] <slangasek> dunno then
[23:01] <penguin42> StevenK: Even via ssh?
[23:01] <slangasek> might still be consolekit breakage of some kind
[23:02] <StevenK> Any logs or anything I can paw through?
[23:02]  * slangasek defers to the desktop team
[23:02] <StevenK> I'll ask seb when he appears, he owes me a favour. :-)
[23:04] <slangasek> bdmurray: uploaded
[23:04] <bdmurray> slangasek: thanks
[23:04] <slangasek> n/p!
[23:22] <bdmurray> slangasek: the grub tasks in bug 816036 seem invalid to me. do you agree?
[23:23] <bdmurray> yes of course not valid there but in bug 816035?
[23:29] <slangasek> bdmurray: if it's already fixed in linux, I guess it's probably invalid on grub, yeah
[23:29] <bdmurray> right thanks
[23:38] <slangasek> hallyn: I'm a bit surprised to see qemu-kvm-spice as a separate source package (looking at NEW queue) - did spice get shot down for an MIR?
[23:40] <slangasek> hallyn: bug #878162... doesn't look like it was ever really considered, I guess the dependency chain is too messy.  But then, why is it worth having a separate qemu-kvm-spice build?
[23:55] <bdrung> doko: will precise get multiarch support for openjdk?
[23:55] <bdrung> doko: i want to install an 32 bit libreoffice on an amd64 system
[23:56] <doko> bdrung, it already does have it. get lo to use it
[23:57] <bdrung> doko: really. i tried with openjdk 7 and it complains
[23:57] <bdrung> s/really./really?/
[23:58] <doko> bdrung, please file a report. hope, Sweetshark will care about it. didn't check with 7 myself