[00:59] <bkerensa> slangasek: Would iputils have some reason for lacking manpages?
[02:13] <slangasek> bkerensa: packages may lack manpages for many reasons :)
[02:27] <slangasek> bkerensa: but I don't see what you mean here; iputils-ping has manpages, as does iputils-tracepath
[04:59] <pitti> Good morning
[05:20] <bkerensa> slangasek: <blkperl> [03:38:01] where did steve go. (in loco channel)
[05:58] <hyperair> bug #930938 ← i can has sponsor please?
[06:01] <RAOF> @pilot in
[06:02] <RAOF> Huh, not final freeze yet?  This piloting session is going to be more interesting than I thought :)
[06:22] <pitti> ev: did you see the whoopsie FTBFS due to test failure on arm?
[06:57] <dholbach> good morning
[07:03] <RAOF> hyperair: Did you test that debdiff?  Is the infinite-scrolling that I see *really* the behaviour you want? :)
[07:03] <hyperair> RAOF: yes i did. what infinite scrolling?
[07:03] <hyperair> RAOF: or do you have CoastingFriction set to 0 by any chance?
[07:04] <RAOF> I've got whatever are the defaults; presumably that includes CoastingFriction set to 0
[07:04] <hyperair> can you do synclient -l | grep CoastingFriction?
[07:04] <hyperair> it should be 50 by default
[07:04] <RAOF> 50, apparently.
[07:05] <hyperair> hmmm
[07:05] <hyperair> lemme check
[07:05] <RAOF> Yet if I do a 2 finger scroll in evolution it never stops.
[07:05] <hyperair> hmmmmm yeah you're right
[07:05] <hyperair> it doesn't stop in evince either
[07:05] <RAOF> (And also carries over if I do alt-tab, which is stupidly wrong behaviour that's stupid and wrong and is why this needs to be in gtk)
[07:05] <hyperair> =(
[07:05] <hyperair> it's in gtk.
[07:05] <hyperair> partilaly
[07:05] <hyperair> partially*
[07:06] <hyperair> for some reason the kinetic scrolling doesn't kick in
[07:06] <hyperair> i checked via gdb
[07:09] <hyperair> RAOF: do you get infinite scrolling without the patch? (very slow infinite scrolling, if you do a really fast flick)
[07:10] <RAOF> No.  I get a couple of ticks of extra scroll, and then it stops.
[07:11] <hyperair> hmm
[07:11] <hyperair> oaky
[07:11] <hyperair> i guess we can't include this patch then
[07:12] <RAOF> Yeah, I'll nak it.
[07:13] <RAOF> Although if you find that there's a follow-up patch or two which actually implements sane behaviour, we could still get that in :)
[07:14] <hyperair> sure
[07:18] <RAOF> Oh, man, that behaviour is terribly annoying.
[07:58] <hyperair> RAOF: okay, it looks like priv->scroll.coast_speed_y is getting set to an absurdly high value. it's not that it scrolls forever, it just takes forever to stop.
[08:00] <hyperair> RAOF: but you can stop scrolling by touching the touchpad, so it's not like it's not easily worked around
[08:01] <RAOF> Right, but that's not exactly the most elegant default behaviour.
[08:04] <hyperair> RAOF: it's a good stopgap that removes the regression from oneiric until gtk gets proper kinetic scrolling
[08:05] <RAOF> Urrr...
[08:05] <hyperair> er, i really meant the fixed patch
[08:05] <hyperair> which i'm working on now
[08:05] <hyperair> i think i've naild this
[08:05] <hyperair> nailed*
[08:05] <RAOF> :)
[08:05] <RAOF> Ah, ok.
[08:05] <RAOF> That makes more sense.
[08:06] <hyperair> :)
[08:06] <hyperair> should i merge this into the patch, or make this a separate patch?
[08:06] <RAOF> You probably want to make a separate patch, because you'll be sending it upstream, right?
[08:06] <RAOF> :)
[08:07] <RAOF> And the initial patch you've added is a cherry-pick from upstream.
[08:12] <mpt> bkerensa, I made two suggestions in the bug report: "Landscape" or "Landscape Administration". I didn't include "Service" because three words ("Landscape Management Service") would wrap to three lines, making the window taller, and because "Service" doesn't add any meaning.
[08:14] <bkerensa> mpt: ok I will fix my merge proposal and resubmit then should I ping you for review or just let sponsors handle?
[08:14] <hyperair> RAOF: it's not a cherry-pick actually, it's not committed yet
[08:15] <mpt> bkerensa, I guess my review wouldn't hurt, and it would take all of ten seconds :-)
[08:19] <bkerensa> mpt: https://code.launchpad.net/~bkerensa/ubuntu/precise/landscape-client/fix-for-962974/+merge/101839
[08:20] <bkerensa> mpt: diff preview is still updating but only change was from Landscape Management Service to Landscape Administration
[08:20] <mpt> bkerensa, reviewed, thanks :-)
[08:20] <bkerensa> k
[08:22] <hyperair> has anyone noticed that killall doesn't function with long process names any more?
[08:24] <jamespage> @pilot in
[08:25] <hyperair> RAOF: okay, it works. and i've uploaded the fixed patch.
[08:25] <hyperair> bug #930938
[08:26] <bkerensa> mpt: I dont think we will get a exception for the merge though
[08:32] <RAOF> hyperair: whot's said that he's committed it :)
[08:39] <jamespage> RAOF, any specific areas you are focussing on from the sponsorship report this morning?
[08:40] <RAOF> jamespage: I was looking at the top of the queue and picking off things which looked reasonable, but mostly I've been testing hyperair's synaptics patch.
[08:41] <jamespage> RAOF, OK - just wanted to make sure I was not looking at the same stuff as you
[08:42] <RAOF> I'm looking at 805509 and 930938
[08:42] <RAOF> And then it'll probably be time to stop :)
[08:44] <ev> pitti: yes - jumping on a porter box and digging at it is on my list for today :)
[08:44] <ev> re whoopsie arm failure
[08:44] <jamespage> RAOF, guess as final freeze was yesterday we need to limit sponsoring to high priority + for main and universe>
[08:45] <RAOF> I'm clearly timezone deficient; I haven't seen final freeze annoncement.
[08:45] <jamespage> hmm
[09:06] <pitti> well, the topic says "Archive: frozen"
[09:07] <pitti> but if that's too confusing, lets change it
[09:45] <brendand> does anyone know what the gconf key is to prevent the screen from turning off?
[09:45] <dupondje> jibel: care fixing https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/946709 ? :) i'm updating my 'devbox' and got this bug ...
[09:45] <dupondje> if you need some debugging :)
[09:46] <Whoopie> jamespage: do you have time to discuss bug 898003? The new package is to avoid a regression in precise.
[09:47] <jamespage> Whoopie, lemme just read the bug report
[09:47] <Whoopie> jamespage: sure, thanks
[09:48] <Whoopie> jamespage: I didn't attach a debdiff as it's 2 MB because the whole folder structure has changed in version 1.1.1.
[09:49] <brendand> or is it gsettings now?
[10:00] <jamespage> Whoopie, not sure I understand why you have dropped usbip-source - is the kernel module no longer required?
[10:01] <Whoopie> jamespage: it's in kernel staging and enabled since 3.2.0-22.35 in the ubuntu kernel.
[10:01] <jamespage> Whoopie, right - I think I understand then
[10:03] <jamespage> Whoopie, I think that overall the approach you have taken looks sensible
[10:03] <jamespage> Whoopie, questions:
[10:03] <jamespage> 1) have you discussed this with the debian maintainer of this package?
[10:03] <Whoopie> no
[10:06] <Whoopie> jamespage: have to jump to a meeting, but will be back in 1 hour. If you have further questions, I'll try to answer them all later.
[10:06] <Whoopie> BTW, I'll contact the debain maintainer.
[10:06] <jamespage> Whoopie, I'll stick some feedback in the bug report
[10:06] <Whoopie> jamespage: great, thanks.
[10:07] <Whoopie> jamespage: but if it's not possible to get it into debian and then sync the package, could it be added to precise?
[10:07] <jamespage> Whoopie, I think so but we should try to get some agreement on approach from the DM
[10:07] <Whoopie> ok
[10:08] <RAOF> @pilot out
[10:08] <tumbleweed> considering that Debian and Ubuntu ship different kernel versions, there's a fair chance that that package couldn't stay in sync
[10:08] <tumbleweed> but yes, talking to the debian maintainer is always a good idea :)
[10:08] <jamespage> Whoopie, you have pretty much change most of the packaging - we would normally try to keep the ubuntu delta to a minimum
[10:08] <dupondje> is there a way to get more debug info from do-release-update ? :)
[10:09] <tumbleweed> apt logs?
[10:09] <jamespage> tumbleweed, agreed - but it should be a temp delta not a permanent fork so discussing with DM is important in this case
[10:10] <tumbleweed> jamespage: yeah. Or at least the same approach+packaging, but maybe different upstream versions.
[10:10] <dupondje> nothing usefull in it :( trying to debug why I get "E:Couldn't configure pre-depend libc6 for libnih1, probably a dependency cycle."
[10:10] <jamespage> tumbleweed, yes - that would make sens
[10:10] <jamespage> e
[10:11] <hyperair> RAOF: really? i don't see it in the upstream git tree
[10:11] <RAOF> hyperair: Yeah, neither do I, actually.
[10:11] <hyperair> git a commit hash?
[10:12] <hyperair> *got
[10:13] <RAOF> No; I just read whot's post on xorg-devel.
[10:14] <RAOF> Anyway, it's now pushed to precise-proposed.
[10:15] <hyperair> okay, thanks
[10:18] <dupondje> slangasek: could you check https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/946709 ? Could be caused by some change you did.
[10:23] <shnatsel> pitti: hello! I have a question about https://launchpad.net/~apport. I'm deploying Apport in elementary Project, and it seems we need the same retracing bot; so I have two questions: first, where to find the sources for the bot so we can set it up for our projects, and second, how to make Apport subscribe our bot to the reports instead of ~apport?
[10:24] <tjaalton> chrisccoulson: hey, do you have time updating enigmail to 1.4.1? it fixes bug 968122
[10:24] <chrisccoulson> tjaalton, it will be updated with the regular 6 week releases (ie, with Thunderbird 12)
[10:25] <pitti> shnatsel: the retracer bot in our DC has no additional code, it just runs straight out of lp:apport
[10:25] <pitti> shnatsel: you need to supply it with a couple of config dirs, though
[10:25] <pitti> shnatsel: http://paste.ubuntu.com/927711/ is the crontab which regularly invokes crash-digger for i386 and amd64 and dup checking
[10:26] <tjaalton> chrisccoulson: ah, ok
[10:26] <pitti> shnatsel: it's a bit more difficult there as this is a lucid box and we do that in a porter dchroot (which has python-launchpadlib and the other necessary pacakges installed)
[10:26] <pitti> shnatsel: as for the "apport" subscription, that's currently hardcoded in apport/crashdb_impl/launchpad.py like 174
[10:26] <pitti> shnatsel: err, "line 174"
[10:27] <pitti> shnatsel: please feel free to open a bug to make this a config option in /etc/apport/crashdb.py
[10:27] <pitti> shnatsel: line 178, too
[10:27] <shnatsel> pitti: thanks a lot!
[10:27] <shnatsel> I take it nobody ever used a custom Apport bot then? :)
[10:28] <pitti> shnatsel: either that, or they just changed that locally and didn't tell me :) I wasn't really aware of that hardcoding
[10:28] <shnatsel> pitti: one more question. Where can I find samples of those config dirs or documentation on writing them?
[10:29] <shnatsel> those config dirs include bug patters, I presume?
[10:29] <pitti> shnatsel: it's described in "man apport-retrace"
[10:29] <shnatsel> pitti: thanks! Will dig :)
[10:29] <pitti> shadeslayer: no, this is just the config for the apt sources for the sandboxes
[10:30] <pitti> shnatsel: http://paste.ubuntu.com/927719/
[10:30] <pitti> shnatsel: those are two configs from our bot
[10:30] <pitti> shnatsel: they really all look alike
[10:31] <pitti> shnatsel: the only oddity is that we include ddeb apt sources for previous releases, due to the really hackish way ddebs.u.c. works
[10:31] <pitti> (long story, just do it :) )
[10:31] <shnatsel> okay! xD
[10:32] <maxb> Do the amd64 buildds run multiarch-enabled for oneiric and precise?  (Because debootstrap sets up a new chroot that way, which surprised me)
[10:32] <shnatsel> pitti: thanks a lot! I'll report back if when deploy it (or fail to)
[10:33] <pitti> shnatsel: I suggest you check out lp:apport, then create a config dir for a release you are intersted in, and start with manually calling apport-retrace and see how that goes
[10:33] <pitti> shnatsel: once that works, you can use crash-digger to iterate over all pending bugs
[11:16] <dupondje> bleh, to bad upgrade from oneiric still fails :(
[11:41] <shnatsel> one more question: are *-dbgsym packages at ddebs.ubuntu.com the same as -dbg packages in main archive, or that's something different?
[11:42] <cjwatson> they are different
[11:42] <cjwatson> *-dbgsym: automatically stripped debugging symbols
[11:42] <cjwatson> *-dbg: may be debugging symbols in some cases, but can also be entirely separate debugging builds (e.g. python2.7-dbg)
[11:44] <shnatsel> cjwatson: thanks! So if I make a package with automatically stripped debugging symbols in a somewhat main archive (PPA), shall I call it -dbg or -dbgsym? Also, is it OK for Apport to have only -dbg and not -dbgsym?
[11:44] <shnatsel> for apport-retrace I mean
[11:44] <cjwatson> I don't know the answer to your apport question
[11:45] <dupondje> somebody wants to look at https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/946709 ? :)
[11:45] <dupondje> quite annoying, as it blocks my upgrade :(
[11:45] <cjwatson> If you generate a package in your own packaging rules, it should be -dbg; -dbgsym should only be generated by pkg-create-dbgsym
[11:46] <shnatsel> cjwatson: thanks a lot!
[11:46] <shnatsel> pitti: one more question: is it OK for Apport to have only -dbg packages and not -dbgsym?
[11:46] <pitti> shnatsel: you won't get very good results
[11:46] <broder> pitti: are you ok with me cherry picking http://cgit.freedesktop.org/upower/commit/?id=6fb36eb5eb85386d2e1c5d9fb760d68053d8afc5 onto upower? (i'm open to doing it as an sru if that's preferable)
[11:47] <pitti> shnatsel: i. e. for packages which don't have a -dbg, you won't get any symbols, and most likely also stack traces which fail in the middle because of missing symbols, etc.
[11:47] <pitti> broder: I'd rather apply it to Debian, too, to avoid getting out of sync
[11:48] <broder> pitti: ok. that would be awesome if you could - i got bitten by the broken behavior a couple of times in the last week before finally hunting down the bug
[11:49] <pitti> broder: is there a bug # for it? at this point we should have them for release tracking
[11:49] <broder> would a bts bug as a reminder be easiest?
[11:49] <broder> no, i haven't done anything yet
[11:49] <broder> i'll open an lp bug
[11:49] <pitti> just curious that there is no existing bug at all about it
[11:49] <pitti> it mighth be against gnome-power-manager, or a different package
[11:49] <broder> err, there might be. i didn't look - i just figured out what was going wrong
[11:50] <broder> there are a handful of moving parts that lead to the brokenness
[11:50] <dupondje> slangasek: around ?
[11:50] <shnatsel> pitti: I take it Ubuntu ddeb archive has -dbgsym for all packages, so to use -dbg instead I'll have to make sure all my custom packages have -dbg, otherwise retracing will fail?
[11:51] <broder> pitti: i kind of suspect that any bug that starts with "my laptop doesn't suspend when i close the lid" immediately gets shuffled off to die in kernel purgatory
[11:53] <pitti> shnatsel: don't you base your project on top of an ubuntu release?
[11:54] <pitti> shnatsel: if you don't, you need to ensure to build -dbg packages for teh things you care about, yes
[11:54] <shnatsel> Pici: well, we do... but we need newer libs than are present in Ubuntu sometimes
[11:54] <shnatsel> Pici: sorry
[11:54] <shnatsel> pitti: ^
[11:56] <broder> pitti: bug #980746
[12:01] <shnatsel> reported making apport bot name configurable as bug #980726
[12:02] <broder> pitti: thanks for taking a look. i need to go to sleep, but let me know if i can help and i'll look at it tomorrow
[12:02] <pitti> broder: bug 948485 ?
[12:03] <broder> hmm, yeah, sounds like the same bug, though it's hard to tell for sure with the given information. i'll post a followup comment and find out
[12:04] <infinity> shnatsel: For your custom packages, there's nothing stopping you from also doing dbgsym extraction (ie: by building with pkg-create-dbgsyms installed)
[12:05] <pitti> broder: hm, that bug could also be a dupe of bug 682262
[12:06] <broder> moral of the story: docking stations are evil
[12:06] <pitti> broder: anyway, I'll cherry-pick it, unless you want do do a debdiff, etc.
[12:06] <pitti> broder: no, they are awesome!
[12:06] <broder> only when they work :)
[12:07] <broder> i don't need to get credit for the upload. whichever is easier and fastest for you to deal with
[12:08] <pitti> broder: ok, I'll just thank you in the changelog then?
[12:08] <broder> pitti: works for me
[12:09] <shnatsel> infinity: will that allow building normal -dbg packages, etc etc? Since we use PPAs as our only repositories we [probably] can't set something as a dependency for all packages, and I have an automated script to enable -dbg packages anyway, so I'd rather patch packaging to enable -dbg than -dbgsym
[12:09] <infinity> broder: Oh, hey.  Before you go to bed.  What's the name of your lintian host again?
[12:09] <pitti> shnatsel: no, -dbg must be done manually in the packaging
[12:09] <broder> infinity: odo.tribbl.es
[12:10] <pitti> shnatsel: that's why I wrote pkg-create-dbgsym, so that we don't have to modify packages
[12:10] <pitti> shnatsel: i. e. to build -dbgsym packages for all packages
[12:10] <pitti> shnatsel: you could do a hack and e. g. upload a debhelper version to your PPA which depends on pkg-create-dbgsym
[12:10] <pitti> shnatsel: ah, no, scratch that; I don't think PPAs have support for ddebs
[12:11] <pitti> shnatsel: we have a rather hideous hack to publish them for the normal ubuntu archive, but that's not available for PPAs
[12:11] <infinity> pitti: I thought the PPA ddeb support was added a while back for OEM?
[12:12] <dupondje> ia32-libs-multiarch is uninstallable ?
[12:12] <pitti> is it? so much the better; but they have magic PPAs
[12:12] <infinity> Oh, yeah, it might not be on for all PPAs.
[12:12] <pitti> shnatsel: I guess you could just try it with one package and see what happens
[12:12] <pitti> if LP accepts them, you could at least grab the .ddebs from the LP page
[12:12] <pitti> I doubt they will be published to the PPA archive, though
[12:13] <shnatsel> pitti: thanks, I'll keep that in mind if I ever need -dbgsym. I wrote an automated script that enables -dbg packages in packaging, so we can live without -dbgsym for now :)
[12:13] <pitti> shnatsel: it's mostly adding the -dbg package to debian/control and telling dh_strip about it in debian/rules, so it's indeed not hard
[12:14] <pitti> shnatsel: if it's only for 5 or so packages, that's definitively easier than trying to write something around LP to get a ddeb archive
[12:14] <shnatsel> pitti: yes, exactly. It's very simple: http://bazaar.launchpad.net/~elementary-os/elementaryos/packaging-scripts/view/head:/simple-case-add-dbg-package
[12:15] <pitti> hah
[12:20] <shnatsel> By the way, regarding magic PPAs - I hear there are some PPAs which can build ARM packages; elementary has an ARM strategy, is there any way they could get access to one? Not now, but someday in the future - we'll probably use custom build farm and repos for testing since those PPAs are non-virtualized or something like that...
[12:20] <seb128> shnatsel, pitti: launchpad got dbgsym support in some way for ppas, dx-system mentioned it and didrocks said it got enabled for the unity ppa (though that's a non virtual ppa, not sure if that's specific to those)
[12:23] <infinity> shnatsel: We still only offer ARM PPAs to Canonical employees and specific partners we have contracts with (entirely because they're insecure).  We're working on making them more widely available with virtualized builders, but it's not quite there yet.
[12:24] <shnatsel> infinity: thanks! Hopefully they will be public by the time elementary needs them :)
[12:24] <infinity> shnatsel: No idea is that'll be true.
[12:25] <shnatsel> well, then we'll need a contract with Canonical :)
[12:25] <shnatsel> never mind, and thanks for all the info
[12:26] <jamespage> @pilot out
[13:04] <dobey> Riddell, ScottK: either of you ever hit any instance of bug #334757 before? It's a 3.5 year old bug, and seems to be popping up a lot more with ubuntuone-control-panel and ubuntu-sso-client-qt using pyqt :-/
[13:05] <ScottK> dobey: Not that I recall.  We should move that the python-qt4 in any case then.
[13:07] <dobey> ScottK: there's a bug against ubuntu-sso-client with the same crash, which has enough duplicates it's starting to cause lp to timeout occasionally :(
[13:08] <ScottK> dobey: I see there's a reduced test cae in the bug.
[13:08] <ScottK> case
[13:08] <ScottK> dobey: Are you subscribed to the upstream PyQt mailing list?
[13:09] <dobey> yeah, alecu just posted that after looking into the bug against ubuntu-sso-client
[13:09] <dobey> i am not
[13:21] <mterry> @pilot in
[14:03] <jdstrand> kees, cjwatson: hmm. I just noticied this: /dev/tty[1-6] went from root:root 0600 to root:tty 0660 between oneiric and precise. I think it is because of util-linux commit 3aa6b68f7e19fa3e1c2bba75bee921a98b7b46af
[14:03] <jdstrand> kees, cjwatson: and I'm trying to decide if that is a problem
[14:03] <jdstrand> thoughts?
[14:04] <infinity> jdstrand: They were root:root at some point?
[14:04] <jdstrand> infinity: yes, in oneiric
[14:04] <infinity> And only oneiric?
[14:05] <jdstrand> oneiric and ealier
[14:05] <infinity> That's patently untrue.
[14:05] <jdstrand> well, let me check
[14:05] <infinity> Says the man looking at a bunch of root:tty TTYs on lucid.
[14:05] <jdstrand> it is certainly true on lucid
[14:05] <jdstrand> note I said [1-6]
[14:06] <infinity> Oh, just the VCs.
[14:06] <infinity> Check.
[14:06] <infinity> I'm not sure I see that as a problem.
[14:06] <infinity> But maybe I'm not sure why they didn't have tty access before. :P
[14:07] <jdstrand> yes, it was root:root going all the way back to hardy
[14:08] <jdstrand> I'm not sure it is a problem either, hence the question :)
[14:18] <jdstrand> kees, cjwatson: fyi, I filed bug 980835 so it doesn't get lost
[14:25] <infinity> jdstrand: It goes 600 as soon as you log in anyway.
[14:25] <infinity> jdstrand: So the tty group only has access to unallocated TTYs, which seems reasonable.
[14:28] <jdstrand> re 0600> yes. that is why I wasn't sure I cared. I still find it odd that the change was made
[14:28] <jdstrand> it has something to do with suse wanting to port mingetty stuff to util-linux
[14:29] <jdstrand> but mingetty doesn't do this (at least not on 11.10)
[14:30] <infinity> Also, the bit you hilighted has not much to do with it.
[14:31] <infinity> jdstrand: Note that, until you run a getty, all TTYs are root:tty.  For some reason, agetty used to change them to root:root, and now doesn't.
[14:31] <infinity> And man, launchpad needs better options for pasting code.
[14:31] <jdstrand> infinity: that is a good point
[14:33] <jdstrand> mingetty doesn't do it on precise
[14:33] <infinity> Doesn't change perms?
[14:33] <jdstrand> yes
[14:33] <jdstrand> if I chown and chmod it to root:root 0600 then fire it up, it is unchanged
[14:34] <jdstrand> I think I don't care based on your observation of the other ttys
[14:34] <jdstrand> actually, the other ttys are 0620 (like the udev rule says)
[14:34] <jdstrand> hmm
[14:36] <infinity> Right, the code you hilighted is making them 660.
[14:36] <infinity> The code I hilighted (or the removal) is making them remain root:tty.
[14:37] <infinity> If there's a valid argument for the udev rule being 620, we could make util-linux mirror that.
[14:37] <jdstrand> I would tend to agree
[14:43] <jdstrand> it was changed to 0620 in udev (from 0666) back in 2007
[14:44] <jdstrand> debian bug 244751 discusses this outside of udev (from 2004)
[14:44] <jdstrand> (when they had 0666)
[14:57] <lamont> so after the "zomg something bad happened" poppup steals focus and I hit return and lose it, how do I see why it popped up?
[14:58] <lamont> seb128: I blame you everytime somethinge steals focus at a bad moment.  just sayin'. :D
[14:58] <davmor2> lamont: /var/crash/ maybe?
[14:59] <lamont> davmor2: ta
[14:59] <lamont> /var/crash/_usr_lib_indicator-messages_indicator-messages-service.2501.crash
[15:00] <lamont>  Segfault happened at: 0x6117c0 <dirname>:      add    %al,(%rax)
[15:03] <lamont> turns out that the indicator-messages-service hates passwd entries in nssdb
[15:08] <slangasek> dupondje: hey there
[15:08] <dupondje> hi :)
[15:09] <seb128> lamont, seems like worth reporting ;-)
[15:10] <lamont> yeah - working through that little bit of pain now
[15:10] <lamont> fortunately, it died again for me, so I have a nice user experience
[15:11] <dupondje> was able to upgrade my system manually now, but maby its good to have that bug fixed
[15:16] <slangasek> dupondje: hmm, context?
[15:22] <dupondje> slangasek: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/946709
[15:28] <mterry> @pilot out
[15:30] <bdmurray> Is there some archive admin who could approve my update-manager in oneiric proposed?
[15:37] <ScottK> Did the SRU team approve it already?
[15:41]  * dholbach hugs mterry
[15:41] <barry> mvo: ping
[15:43] <barry> slangasek: can you approve foundations-q-python-version blueprint?
[15:43] <mterry> :)
[16:04] <pitti> barry: https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-python-version does not exist
[16:05] <barry> pitti: oops, typo: https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-python-versions
[16:05] <barry> (plural at the end)
[16:06] <pitti> barry: for 12.10!
[16:06] <pitti> barry: accepted for sprint and q
[16:06] <barry> pitti: awesome!
[16:07] <pitti> speaking of which, what's Quarreling Quail really going to be called like?
[16:07] <pitti> sabdfl: ^ :-)
[16:07] <sabdfl> qqqqqqqq
[16:07] <sabdfl> well
[16:07] <sabdfl> qu....
[16:07] <pitti> we soon need the name to put it into lintian, vim, and a few other places
[16:07] <barry> pitti: qwazy quahog!
[16:09] <pitti> barry: that makes baby jesus qwy
[16:09] <barry> pitti: :-D :-D
[16:09] <barry> pitti: that is going on my twitterfeed right now
[16:20] <slangasek> dupondje: 946709> how did you do the manual upgrade?
[16:23] <slangasek> dupondje: that's a duplicate of bug #850264
[16:24] <slangasek> dupondje: any chance you'd be interested in preparing an oneiric SRU for that?  It's on my list, but I haven't gotten to it yet
[16:26] <nigelb> pitti: haha, that was awesome :)
[16:31] <cjwatson> slangasek: did mvo manage to come up with a non-ABI-changing version of that?
[16:32] <cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel/2012-February/034694.html
[16:32] <cjwatson> oh, wait, maybe that's a different bug
[16:36] <slangasek> oh phew, I was going to be sad
[16:51] <dupondje> slangasek: I changed the sources.list, then apt-get upgrade, then upgrade of some other packages, and then dist-upgrade untill it was all set :)
[16:52] <slangasek> ok
[16:52] <slangasek> yeah, that would bypass this bug
[16:53] <dupondje> apt-pkg/depcache.cc: prefer native providers over foreigns even if the chain is foreign.
[16:53] <dupondje> only this need backport ?
[17:02] <slangasek> dupondje: I believe so, yes
[17:07] <hyperair> hmm scrolling using a touchpad is broken in gtkmm 3.0
[17:08] <hyperair> case in point gnome-system-monitor
[17:11] <jtaylor> doko: is it still possible to merge numpy -7 for a fix of debian bug 664672?
[17:17] <dupondje> slangasek: http://bazaar.launchpad.net/~donkult/apt/experimental/diff/2193 -> this is the diff containing the change in depcache.cc, so just backport this :)
[17:17] <dupondje> going to check that ou
[17:17] <dupondje> out*
[17:17] <hyperair> hang on, it's not broken in just gtkmm. it's broken in everything suddenly. weird.
[17:21] <slangasek> dupondje: sure - any chance you can cherry pick that into a bzr merge proposal against oneiric and subscribe me?
[17:21] <slangasek> dupondje: (sorry, in the middle of a few other things at the moment so can't pick it up directly without a stack overflow)
[17:22] <dupondje> i'll check that later :) no much experience with bzr :) else I just do a debdiff
[17:23] <hyperair> weird, it all works again. i wonder what that was.
[17:25] <slangasek> dupondje: ok, debdiff is fine too; in that case please just attach it to the bug
[17:52] <slangasek> jibel: 979350> does that really establish that it's specific to amd64, or just that the memory thresholds are different for i386 vs. amd64?
[17:53] <slangasek> I'm not convinced that the memory usage of ubiquity itself is the key here
[17:55] <doko> jtaylor, sure, why not. it's not on any iso image
[18:44] <dobey> hey all. what user do package builds happen as under pbuilder?
[18:45] <tumbleweed> the pbuilder user
[18:45] <cjwatson> file:///usr/share/doc/pbuilder/pbuilder-doc.html#nonrootchroot
[18:45] <cjwatson> (public service announcement: use sbuild instead)
[18:47] <infinity> I was waiting for that.
[18:47] <infinity> cjwatson: You should probably get t-shirts printed for UDS.
[18:48] <cjwatson> "stop unpacking pointless tarballs: use sbuild"
[18:49] <dobey> https://wiki.ubuntu.com/UbuntuDevelopment/FAQ#Packaging
[18:49] <dobey> "sbuild" occurs nowhere on that page :)
[18:50] <cjwatson> I can't help it if people are wrong
[18:50] <cjwatson> to be fair, sbuild was probably less usable outside buildd contexts at the time
[18:50] <dobey> anyway, whatever. the information doesn't help solve my problem :-/
[18:51] <dobey> which is to say, this: https://launchpadlibrarian.net/100003195/buildlog_ubuntu-lucid-i386.ubuntuone-dev-tools_3.1%2Br60-15~lucid1_FAILEDTOBUILD.txt.gz
[18:52]  * cjwatson wonders how pbuilder is even relevant, then
[18:53] <cjwatson> since the buildds don't use it
[18:53] <dobey> ok, well i don't know that
[18:53] <dobey> i don't maintai nthe buildds
[18:53] <cjwatson> I'm telling you now
[18:53] <dobey> i know i'm pretty smart, but there are actually things i don't know :)
[18:53] <dobey> ok
[18:54] <dobey> does sbuild build the packages as root?
[18:54] <cjwatson> no
[18:54] <infinity> dobey: So.  The builds run as 'buildd'.
[18:54] <infinity> dobey: Not that you should hardcode or rely on such a thing.  Your build should just work as any unprivileged user.
[18:54] <dobey> ok, so still likely not the relevant piece of information to the problem
[18:54] <cjwatson> it would be less frustrating if you could tell us what would be relevant
[18:55] <cjwatson> I feel like I'm playing twenty questions here
[18:55] <dobey> infinity: it doesn't. the exact same build works on all the newer versions of ubuntu
[18:55] <cjwatson> where's the .dsc for this?
[18:55] <dobey> i don't know what's relevant. i'm looking at a black hole trying to see what the problem is
[18:55] <Laney> can someone mash this? https://launchpad.net/ubuntu/+source/gnome-settings-daemon/3.4.0-0ubuntu7/+build/3400563
[18:55] <cjwatson> I'll be happy to try it locally
[18:55] <dobey> cjwatson: in the ppa source i guess. it's a lp recipe build
[18:55] <cjwatson> and then explain how you can try it locally
[18:56] <infinity> Laney: Mashed.
[18:56] <cjwatson> dobey: URL please, I have no idea what that build log corresponds to
[18:56] <Laney> infinity: thanks
[18:56] <dobey> https://launchpad.net/~ubuntuone/+archive/nightlies/+files/ubuntuone-dev-tools_3.1%2Br60-15%7Elucid1.dsc
[18:57] <dobey> cjwatson: does sbuild let you specify a ppa to use to satisfy build-deps, for a single build, vs. for all builds as pbuilder requires?
[18:58] <cjwatson> you could do it with --pre-build-command if nothing else
[18:58] <cjwatson> er --pre-build-commands
[19:00] <infinity> dobey: Could it just be that you're doing something incompatible with lucid's squid?
[19:01] <infinity> dobey: Every other release is 3.1.x, lucid's 3.0... Could relate.  Dunno.
[19:01] <dobey> infinity: i guess not, as branch lp:ubuntuone-dev-tools on lucid and running ./run-tests with all the build-deps installed, works just fine. it's clearly an environment difference
[19:01] <cjwatson> hm, maybe not --pre-build-commands, doesn't support shell metacharacters - still, quick to switch back and forward
[19:08] <cjwatson> dobey: hmm; builds fine in a local sbuild
[19:09] <cjwatson> so it's not the building tool that matters, I think
[19:09] <infinity> The lucid chroot could be a bit wonky.
[19:10] <dobey> hrmm
[19:10] <infinity> Or it could be that old versions of squid REALLY want external DNS for some reason, or similar issues.
[19:10] <cjwatson> dobey: you could probably help yourself by having that exception also dump out stdout/stderr from squid
[19:11] <dobey> cjwatson: well, i was only asking about the user as it was a theory presented where squid couldn't access certain directories.
[19:11] <dobey> cjwatson: yeah, am having someone fix that as well
[19:11] <cjwatson> sure - but if squid is failing to start, I expect that it says why on stderr :)
[19:11] <cjwatson> which would save on speculation
[19:12] <dobey> sure. thanks anyway. i didn't mean to have it turn into a discussion about pbuilder vs sbuild or further speculation. :)
[19:13]  * cjwatson nods
[19:21] <SpamapS> did anything ever come of the effort to backport dh_python2 to lucid?
[19:21] <SpamapS> I have an ever-growing list of non-backportable packages that require special effort just to get onto lucid.. :-/
[19:21] <tumbleweed> SpamapS: no
[19:36] <dobey> SpamapS: dealing with dh_python2 vs. lucid in a package is very easy, actually
[19:36] <dobey> SpamapS: one second and i'll show you how :)
[19:37] <dobey> SpamapS: http://bazaar.launchpad.net/~ubuntuone-control-tower/dirspec/packaging-dailies/files
[19:37] <dobey> SpamapS: see rules and a few | deps in control.
[19:38] <dobey> or well, i guess the one | dep :)
[19:38] <dobey>  python-all (>= 2.6.6-3) | python-support (>= 0.6.4),
[19:38] <slangasek> yes, which means you get to build packages for lucid with all the bugs of python-support :/
[19:38] <dobey> yes well
[19:38] <dobey> at least it's not python-central
[19:39] <dobey> the other option of course is "don't build packages for lucid"
[19:39] <dobey> can we just EOL it a year early? :)
[19:39] <dupondje> slangasek: seems like there is more then that patch needed for fixing apt
[19:39] <dupondje> that patch seems to depend on other patches
[19:45] <slangasek> dobey: the option we wanted to take was to backport dh_python2
[19:46] <slangasek> I'm not saying you've done anything wrong, just that the workaround being "easy" doesn't make it a great one
[19:48] <dobey> slangasek: understood, but it's not done, and waiting until EOL for it to get done isn't helpful either. also if it only ends up in backports and not as an SRU, it will still only have very limited value.
[19:49] <slangasek> well, we had agreement to SRU it, but
[19:49] <slangasek> anyway
[19:49] <tumbleweed> given the progress on it, I'm not expecting it to ever happen
[19:49] <slangasek> dupondje: are you following through on the other patches?
[19:50] <dobey> tumbleweed: exactly :)
[20:35] <SpamapS> dobey: thanks.. I knew about that. But having to introduce a bunch of cruft in new packages just so I can get them back to lucid is pretty annoying.
[20:38] <dobey> SpamapS: i don't know if i'd call ~5 lines total "cruft" :)
[20:39] <dobey> but yes, i agree it's not the best thing. but it works quite well
[20:39] <SpamapS> dobey: and server has 3 years left for lucid, not 1 :)
[20:39] <dobey> you can of course also have a separate packaging branch for lucid
[20:39] <dobey> oh, right :(
[20:41] <SpamapS> dobey: the separate branch is what I do now
[20:41] <SpamapS> but every time somebody pokes a new package dep into something I want to support on all releases.. I have to branch the packaging or install the workaround you noted
[20:42] <SpamapS> having precise out will help ease the desire to keep pushing things back to lucid.. but that will take another year really.
[20:42] <dobey> yes well. i'd say maintaining multiple packaging branches is more cruft :)
[20:42] <SpamapS> dobey: its cruft that goes away automatically, which I like.
[20:45] <dobey> *shrug* :)
[21:04] <cjwatson> barry: any luck with bug 848915 yet?
[21:04] <ScottK> barry: Before we can reliably carry both python3.2 and python3.1 as supported versions, dh_python3 probably needs to grow a way to deal with modules with different code for different python versions.
[21:05] <barry> cjwatson: nope.  bdmurray did you have some additional information on that one?
[21:05] <barry> ScottK: yeah, that's what piotr mentioned quite often.
[21:06] <ScottK> barry: OK.  Since you mention you want 3.2/3.3 for "Q", be sure to write down doing that bit of work too.
[21:06] <barry> ScottK: i don't think we'll have to worry about 3.1 and 3.2, but 3.2 and 3.3
[21:06] <ScottK> Agreed.
[21:06] <cjwatson> barry: I thought we'd agreed a plausible hack to help track it down - did that not yield anything?
[21:06] <ScottK> 3.1 was a typo
[21:07] <barry> cjwatson: i've been working on other stuff first.  e.g bug 873468
[21:07] <bdmurray> barry: nope, no info
[21:07] <barry> ScottK: /me nods
[21:07] <barry> bdmurray, cjwatson: i'll take another look at 848915 when i finish with 873468
[21:08] <cjwatson> barry: I'm installing an oneiric desktop now to see if that will help
[21:08] <cjwatson> glad you're working on 873468 :)
[21:08] <barry> cjwatson: cool :)
[21:09] <cjwatson> down to five >=high rls-p-tracking bugs for foundations, counting stuff in -proposed ...
[21:09] <cjwatson> so the mess that is http://people.canonical.com/~rspencer/rls_bugs.svg isn't all our fault ;-)
[21:18] <slangasek> SpamapS: so.... we never got to the lvm2 merge, did we
[21:19] <slangasek> SpamapS: how far did you get with that in practice?  I'm interested to know if the new upstream version fixes bug #874774
[21:20] <SpamapS> slangasek: I tried and failed 3 times to resolve the merge
[21:20] <slangasek> blast
[21:20] <slangasek> ok
[21:20] <SpamapS> slangasek: the problem is, we have patches, debian has patches, and upstream has half of most of them applied
[21:21] <slangasek> yep
[21:21] <slangasek> any relevant notes from the experience, so that when we try the merge next cycle we might get there?
[21:21] <SpamapS> its like trying to separate the linguine from the fettucini in a bowl of spaghetti, blindfolded
[21:21] <cjwatson> see also: why we haven't merged plymouth
[21:21] <SpamapS> slangasek: I think with a strong, focused effort it will be doable
[21:22] <SpamapS> Its just my other 40 plates kept falling off their sticks, so I had to keep them spinning and let this one fall
[21:36] <dupondje> slangasek: we going to get the cryptsetup bugs down :)
[21:37] <slangasek> dupondje: that's the only one of them I'm worried about right now, and it looks like it might be an lvm2 bug ;)
[21:41] <dupondje> i'm already happy we don't have the uber prehistoric version we had a month ago :)
[21:43] <slangasek> yep, just a prehistoric lvm
[21:46] <dupondje> well thats to late to merge now I guess
[21:46] <slangasek> quite
[21:48] <dupondje> we should have ubuntu sid imo :) a rolling release would be cool
[21:49] <cjwatson> which would somehow magically create effort to merge things ...? ;-)
[21:50] <dupondje> if you are in the mood for a merge, and then its just FF :p
[21:50] <slangasek> that's what staging bzr branches are for
[21:52] <slangasek> pitti: hey, on the 'sudo doesn't preserve proxy vars' saga... do you know if there's a good reason sudo doesn't itself invoke pam_env?
[21:53] <slangasek> (su does, for comparison)
[21:53] <xee> Hi, I'd like to as what library gnome uses to display contents of an iphone so well when one is plugged in.
[21:55] <xee> Unity/Gnome I mean, in default Ubuntu setup.
[22:05] <dupondje> When are FFe syncs/merges accepted when they are ACK'ed ?
[22:06] <tumbleweed> dupondje: the ack on the bug just gives you permission to go ahead and sync/upload
[22:07] <dupondje> tumbleweed: I can't sync/upload myself :)
[22:08] <tumbleweed> right, so you subscribe the sponsors
[22:33] <dupondje> slangasek: https://launchpadlibrarian.net/101769525/apt.debdiff
[22:43] <xee> turns out it's gvfs itself
[22:43] <xee> thanks
[23:13] <astraljava> Does anyone have a bit of time to explain to me whether we'd run into problems with adding dssi-host-jack into our seeds, still (we would be Ubuntu Studio). Back in the day it was dropped, and I'm not exactly sure why.Then there was the dssi-vst problem with multiarch ia32-libs, germinate and all that, and since dssi-host-jack builds from the same source, I'm a little unsure whether adding it to the
[23:13] <astraljava> seeds will cause issues with the image spinning or not.
[23:14] <astraljava> Furthermore, would it require a FFe?
[23:14] <astraljava> And yet again, how quick/painless it is to refresh seeds to affect the image spinning?
[23:14] <astraljava> is it*
[23:15] <cjwatson> the problem with dssi-vst was that on amd64 it depended on i386-only packages
[23:16] <cjwatson> I don't see anything like that in dssi-host-jack
[23:16] <astraljava> cjwatson: That's what I started to realize after reading your mail on ubuntu-release in November last year.
[23:17] <cjwatson> so I don't see any issue there and I don't think it requires an FFe as long as you have the time to test it; but the package description suggests that it's only an example, so is it really much use?
[23:17] <astraljava> cjwatson: Ok, so what about the seeds thing, then? I'm asking because one of our apps in the seeds won't run out-of-the-box without any dssi hosts installed. I talked about this with quadrispro, and it seems this would be the sanest solution.
[23:18] <cjwatson> if you want it as a directly-seeded entry rather than as a dependency of something else, it's a matter of committing to the seeds and then refreshing/uploading ubuntustudio-meta
[23:19] <astraljava> cjwatson: I actually already put it in the seeds, but then became uncertain because of the whole ia32-libs thing (many hours before) and reverted it.
[23:19] <cjwatson> you can unrevert it then :)
[23:20] <astraljava> cjwatson: Right, thank you so much. :) I'll just ask here for the refresh/upload of -meta when it's back in the seeds, then?
[23:20] <cjwatson> and I can upload ubuntustudio-meta for you once you've done that, although if I do that then another member of the release team will have to deal with approving it
[23:20] <astraljava> So -release would be a better place to ask, so it's all there for the other member?
[23:21] <cjwatson> *shrug* I expect they're all here anyway
[23:23] <astraljava> cjwatson: Ok, rev. 1322 of ubuntustudio.precise has the unrevert fix. :) If you'd be so kind.
[23:28] <cjwatson> astraljava: running
[23:29] <astraljava> Thanks!
[23:29] <cjwatson> barry: stealing assignment of bug 848915
[23:30] <cjwatson> figured you probably wouldn't mind :)