[00:46] <tomswartz07> I didnt get a chance to look, but does anyone know offhand if there is a bug filed about the screen lock timeout set to 'never' immediately blanking the screen?
[00:47] <tomswartz07> specifically, after 0 seconds of inactivity, the screen fades to black (lock). Only happens when the timeout is set to 'never'.
[00:50] <mdeslaur> tomswartz07: bug 863038
[00:51] <tomswartz07> splendid thanks mdeslaur
[00:52] <tomswartz07> to avoid it, i switched to tty, and its too difficult to search launchpad using 'links'
[04:11] <pitti> Good morning
[04:12] <ajmitch> morning pitti
[05:05] <pitti> ogasawara, apw: do we need a -meta bump for the -headers-lbm stuff on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt ?
[06:55] <tkamppeter> pitti, hi
[07:03] <dholbach> good morning
[07:17] <dholbach> @pilot in
[07:41] <pitti> diwic: you can still upload a new pulse if necessary (for fixing patch application)
[07:48] <dholbach> cjwatson, regarding https://bugs.launchpad.net/ubuntu/+source/python-meld3/+bug/749880 - should I unsubscribe sponsors for now as you're handling it?
[07:48] <cjwatson> dholbach: as you like, it's actually just waiting for SRU review at this point
[07:48] <dholbach> ah ok
[07:49] <cjwatson> but if you'd prefer to get it out of the queue that's fine; I've subscribed directly now
[07:50] <dholbach__> you're right - I could've just changed the natty queue :)
[08:05] <dholbach> pitti, how do you feel about getting gnome-color-manager 3.2.0 in now? it's in universe, and while it's not 100% bugfixes only it looks like it fixes a whole bunch of bugs
[08:05] <pitti> RAOF: ^ any opinion?
[08:06] <dholbach> https://code.launchpad.net/~jbicha/ubuntu/oneiric/gnome-color-manager/3.2/+merge/77637
[08:06] <pitti> dholbach: hm, so it seems nobody packaged the further 3.1.x releases :(
[08:06] <dholbach> if you want, I can pastebin the news file
[08:06] <pitti> dholbach: I'd say, upload it, and we'll review it from the queue; unless you already see that it has new unsatisfyable build deps or so
[08:06] <dholbach> no no, it builds fine
[08:06] <pitti> NEWS is in the MP
[08:07] <dholbach> http://paste.ubuntu.com/703253/
[08:07] <dholbach> ah ok
[08:08] <dholbach> ok, will do
[08:08] <pitti> meh, who changed devscripts to use "precise" by default
[08:08] <pitti> shouldn't we only do that _in_ precise, not already in oneiric?
[08:13] <diwic> pitti, yeah, I think we should upload a new pulseaudio (if it makes it to the RC, that'd be great!), my question was more about the workflow, kinda where to apply what
[08:14] <pitti> diwic: you mean how to correctly apply the patches? I can have a look at the package, if you tell me what is wrong
[08:14] <infinity> pitti:
[08:14] <infinity> devscripts (2.11.1ubuntu2) oneiric; urgency=low
[08:14] <infinity>   * debchange: Add precise, and make it the new default upload target.
[08:14] <infinity>  -- Stefano Rivera <stefanor@ubuntu.com>  Thu, 06 Oct 2011 01:27:08 +0200
[08:15] <pitti> a bit premature IMHO; if anything, this should have switched to oneiric-proposed :)
[08:15] <pitti> anyway, not a biggie
[08:15] <infinity> pitti: Heh.
[08:15] <infinity> The default is wrong for me 99% of the time anyway.
[08:15] <infinity> Chroots, Debian vs Ubuntu, etc, etc.
[08:16] <diwic> pitti, my question is more about lp:~ubuntu-audio-dev/pulseaudio/ubuntu.oneiric - I mean, should I ignore it today and make a debdiff for you to sponsor, or should I try to import ScottK 's change to the tree, then apply my stuff on top of that?
[08:17] <pitti> hm, I really don't know
[08:58] <pitti> diwic: FYI, RC is around Monday, so still time
[08:59] <pitti> today is a good day still for targetted patches which have a very low regression risk
[09:00] <diwic> pitti, I just pushed ScottK's stuff and mine on top of that to lp:~ubuntu-audio-dev/pulseaudio/ubuntu.oneiric
[09:01] <diwic> pitti, on dtchen's recommendation
[09:01] <diwic> pitti, feel free to sponsor
[09:07] <pitti> diwic: done; looks fine, thanks
[09:19] <ev> mvo: I just had to help John Oxton recover a partial upgrade because X/compiz crashed while he was running through it.  Have you ever thought of running update-manager under xpra or some other screen-for-X like trick?
[09:20] <ev> (xpra: http://code.google.com/p/partiwm/wiki/xpra)
[09:23] <mvo> ev: that is a excellent idea
[09:23] <mvo> ev: hrm, not packaged
[09:23] <mvo> yet
[09:23] <mvo> ;)
[09:23] <mvo> ignore me, it is
[09:24] <ev> I think I did *AGES* ago
[09:47] <diwic> pitti, I don't know if you're über-busy with Oneiric today, but if you aren't, do you know https://launchpad.net/ubuntu/+source/pulseaudio/1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu14.1 hasn't reached lucid?
[09:48] <diwic> pitti, it's been sitting in lucid-proposed for months.
[09:48] <dholbach> can somebody help me mark https://code.launchpad.net/~psusi/ubuntu/natty/gnome-power-manager/fix-duplicate-battery/+merge/67466 as merged (r188)?
[09:49] <pitti> diwic: there's a lot of chatter on that bug 445849, but it seems nobody actually tested the proposed pacakge and gave feedback?
[09:51] <diwic> pitti / dholbach, is it the verification-needed -> verification-done stuff that's needed here?
[09:51] <pitti> diwic: less so the tag setting, but a report that someone actually tested teh -proposed package and confirms that it works
[09:51] <pitti> (i. e. not a local build, and someone who is affected by the bug)
[09:52] <dholbach> can somebody please reject https://code.launchpad.net/~bones/ubuntu/natty/radiotray/fix-for-722886/+merge/70107 (fixed in oneiric, sru rejected)
[09:53] <diwic> pitti, to complicate matters further, the lucid-proposed actually only fixes the bug for *some* people (i e amd64). I have one more patch to fix it for i386.
[09:54] <diwic> Would the right thing to do here, to make a new debdiff on top of the lucid-proposed one
[09:54] <diwic> and upload/test that to lucid-proposed again?
[09:54] <diwic> pitti, I think I could verify that one myself
[09:55] <pitti> diwic: depends; if the current version helps some people and doesn't regress others, we can also move it to -updates and then do another SRU
[09:55] <pitti> diwic: if it might regress for some people, better to do a new SRU on top of -proposed right away
[09:56] <diwic> pitti, I'd prefer the latter
[09:56] <pitti> ok, let's do that then
[09:57] <diwic> ok, I'll prepare a debdiff for 14.1 -> 14.2 (?), just having lunch first.
[09:57] <dholbach> pitti, regarding bug 722936 - could it be that the .pot file needs to be updated?
[09:58] <dholbach> or is that going to be a 'precise' thing?
[09:58] <pitti> dholbach: it should be auto-built during package build
[09:58] <pitti> dholbach: it's only in trunk right now (string freeze)
[09:59] <pitti> hm, wait
[09:59] <dholbach> ah, I checked the source package and it seems that the string was only in the .po and .pot files
[09:59] <pitti> right, but is still in ubuntu branch
[10:36] <pitti> cjwatson: want me to seed ubuntu-defaults-zh-cn and ask for a MIR review, so that we can build the image from main only? (to fix oversizedness)
[10:38] <cjwatson> if that's the only way
[10:43] <pitti> cjwatson: in my mail I pointed out some alternatives, but I think at that point it's the safest way
[10:46] <mvo> ev: I played with that a bit in lp:~mvo/update-manager/xpra-experiment but its not that encouraging, it seems to be a bit unstable
[10:47] <ev> mvo: oh? I never had any trouble running Pidgin under it, but that was admittedly about two years ago.
[10:47] <ev> very cool though - I'll have a look at the branch in a bit
[10:48] <pitti> didrocks: do you have a minute today to look at bug 869058?
[10:49] <didrocks> pitti: sure, will look at it
[10:49] <pitti> didrocks: merci
[10:49] <didrocks> pitti: I have a gtk2 version of glade parallely installable now
[10:49] <didrocks> pitti: will push it in the glade-3 source package soon
[10:49] <pitti> didrocks: oh, nice!
[10:49] <didrocks> will need BINNew and such…
[10:49] <pitti> didrocks: why not a separate source?
[10:50] <pitti> didrocks: or does hte current version still support gtk 2 with different configure options?
[10:50] <didrocks> pitti: glade-3 is already 3.8 (for the old gtk2 library needed with pygtk)
[10:50] <didrocks> glade is 3.10
[10:50] <pitti> oh, glade vs. glade-3
[10:50] <seb128> didrocks, pitti: why do we need glade-2 back?
[10:50] <didrocks> yeah
[10:50] <didrocks> seb128: because Quickly is using pygtk
[10:50] <didrocks> seb128: and 3.10 is gtk3 only
[10:51] <didrocks> like, it uses box and not hbox, vbox
[10:51] <seb128> oh ok
[10:51] <didrocks> and pygtk can't instantiate those
[10:51] <didrocks> so yeah, we need it back :/
[10:52] <didrocks> let me just readd a removed patch for expanding the treeview by default
[10:55] <didrocks> oh dch -r "" set "precise" now :)
[10:57] <didrocks> pitti: glade-3 pushed, will upload Quickly to dep and run the gtk2 flavor now
[10:58] <jml> has someone asked LP to rename p-series?
[11:39] <pitti> didrocks: thanks for the MIR
[11:39] <pitti> cjwatson: it's in main now, so cdimage can drop the --components argument now
[11:44] <didrocks> pitti: yw ;)
[11:45] <cjwatson> pitti: cdimage doesn't have it, it's in BuildLiveC
[11:45] <cjwatson> D
[11:46] <cjwatson> actually, is it
[11:47] <cjwatson> I can't find --components anywhere relevant; how did it work before?
[11:47] <cjwatson>         COMMAND="ubuntu-defaults-image --locale ${UBUNTU_DEFAULTS_LOCALE} --arch ${ARCH} --release ${STE}"
[12:02] <pitti> cjwatson: how are xubuntu/mythbuntu etc. built? Is there a lookup table somewhere mapping images to components?
[12:03] <pitti> no, that wouldn't affect u-d-image
[12:09] <cjwatson> pitti: that's in livecd-rootfs/live-build/auto/bconfig
[12:09] <dholbach> @pilot out
[12:37] <didrocks> pitti: just pushed the new lenses with the icon change and some other fixes
[12:37] <didrocks> pitti: FYI, you will see in the diff:
[12:37] <didrocks> -Icon=/usr/share/unity/4/lens-nav-app.svg
[12:37] <didrocks> +Icon=/usr/local/share/unity/4/lens-nav-app.svg
[12:37] <didrocks> this is fine, the config is rewritten during build
[12:46] <pitti> didrocks: ok, thanks for the warning
[12:46] <didrocks> pitti: yw, this thing pretty much depends on who make the tarball :)
[12:54] <ScottK> diwic: Thanks for fixing the pulseaudio issue.
[12:55] <pitti> didrocks: did you actually upload?
[12:55] <pitti> still not in the queue
[12:55] <pitti> didrocks: dch got changed to default to precise, maybe you stumbled over that?
[12:56] <didrocks> pitti: ahah, nice catch!
[12:56] <didrocks> probably :)
[12:56] <ev> mvo: ah, mpt fairly points out that the correct solution here is to port update-manager to use aptdaemon and handle bringing the UI back up when the user logs in again
[12:57] <ev> (on the xpra thing)
[12:57] <diwic> ScottK, np
[12:57] <diwic> ScottK, the same to you, btw. Was it phonon that depended on a three version string?
[12:57] <ScottK> phonon and skype AFAIK.  Probably more.
[12:59] <diwic> pitti, so for the old bug 445849, let's upload a new one to lucid-proposed: https://launchpadlibrarian.net/82117342/pulseaudio14.1.14.2.debdiff - and if noone really tests, I guess it's a wont fix for Lucid.
[12:59] <mvo> ev: yeah, that is indeed the right solution, there is even a ancient branch in this spirit lp:~mvo/update-manager/gui-seperation but it never got anywhere :(
[12:59] <mvo> ev: because of time/other stuff, but it would be really good to finish that
[12:59] <ev> indeed! :)
[13:16] <Riddell> kenvandine: do you use the UDD branches for the freeciv package?
[13:17] <kenvandine> Riddell, i think i did for the one upload i did
[13:17] <kenvandine> i can't remember for sure, i've only touched it once :)
[13:19] <ogasawara> pitti: linux-meta is at 3.0.0.12.4 so it should be the correct abi to match lbm.
[13:20] <pitti> ogasawara: maybe there is no metapackage for headers-lbm?
[13:20] <pitti> at least I can't see one
[13:20] <pitti> not sure how we handled that in the past
[13:20] <pitti> ogasawara: also, do we support linux-image-extra-3.0.0-12-virtual ? that's also not covered by metapackages
[13:21]  * pitti notes it is tremendously easier to have all binaries in main, otherwise SRUs will just make a mess out of components
[13:22] <ogasawara> pitti: hrm, indeed it does look like we're missing an lbm meta package.  let me investigate.
[13:22] <ogasawara> pitti: ah yes, the -extra package is new and supported.  I'll get that fixed up as well.
[13:23] <pitti> ogasawara: thanks
[13:33] <tkamppeter> pitti, am I right that if I have a source package in Main and one of its binaries is in Universe, if I want to promote this binary to Main I do NOT need a MIR?
[13:33] <kenvandine> tkamppeter, no... something in main needs to depend on it or it needs to be seeded on the CD to get promoted
[13:47] <pitti> tkamppeter: correct
[14:19] <didrocks> pitti: thanks for the u-l-f and u-l-a, sorry for the false alarm. /me shouldn't use dch -r "" anymore ;)
[14:35] <tkamppeter> pitti, kenvandine, thanks.
[15:03] <jdstrand> pitti: hi! fyi bug #868695 (I didn't see you were subscribed, so just mentioning it here)
[15:04] <pitti> jdstrand: will follow up on the bug later, thanks
[15:04] <pitti> jdstrand: btw, do you need anything else from me for bug 866049?
[15:05] <jdstrand> pitti: nope, looks great, thanks :)
[15:05] <jdstrand> pitti: as always, much appreciated
[15:19] <bdmurray> pitti: Do you ever run into "'NoneType' object has no attribute 'makefile'" with the retracer?
[15:19] <bdmurray> pitti: when using db.download in apport
[15:30] <mneptok> is use of "whois" now discouraged in Ubuntu (i rarely keep up with the "groovy new tools/way" stuff)? been using Debian for the past 3 U releases or so. my Xubuntu 11.10 laptop does not have whois in the default install.
[15:32] <stgraber> mneptok: whois simply isn't seeded by Xubuntu
[15:32] <stgraber> mneptok: it's in Ubuntu and Edubuntu because gnome-nettool depends on it
[15:33] <stgraber> and ubuntu-desktop depends on gnome-nettool
[15:33] <mneptok> ach so.
[15:34] <mneptok> i was afraid i had missed some "OMG YOU STILL USE WHOIS?!??! USE $something_hip INSTEAD!" thing. /me installs
[16:03] <ev> mneptok: seriously dude, roll your own ;)
[16:46] <jtaylor> any recommendations what to do with gtk2? bug 851383
[16:46] <jtaylor> I seem to have found the commits which fix the issue, but that probably introduces a bunch of other bugs as the code is strongly refactored in git
[16:46] <jtaylor> this is what I extracted: http://paste.ubuntu.com/703493/
[16:47] <jtaylor> I'd prefer to go back to .5 and hope upstream regains its sanity at some point
[16:48] <jtaylor> superm1: ^
[17:08] <jtaylor> or we do what debian did and add all 560 line changes
[17:09] <superm1> jtaylor, i'd defer to #ubuntu-desktop folk in this scenario, they're the ones that maintain the package mostly
[17:09] <superm1> can you check in there?
[17:21] <cyphermox> @pilot in
[17:28] <slangasek> jhunt, hallyn_, apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/818177/comments/57 clearly points to udev being idiotic with its handling of 'udevadm exit' - the command has succeeded but all the workers are left running
[17:28] <slangasek> this is a recent (oneiric) change to the initramfs -bottom script
[17:28] <apw> slangasek, i concur they are clearly there ...
[17:28] <apw> jhunt, i am up to 32 reboots without failure changing from move to bind, which would fit with those not being dead
[17:29] <slangasek> we changed from using pkill to udevadm exit in response to bug #787610 / Debian bug #624469
[17:30] <apw> slangasek, yep we swapped one fails to boot 1:10 for another
[17:30] <slangasek> yes
[17:30] <slangasek> so
[17:30] <slangasek> there are two possible fixes that I see
[17:30] <apw> slangasek, so when did we introduce the mount -o move for /dev, that is pretty new
[17:30] <slangasek> 1) fix 'udevadm exit' to reap its children (but that may not be correct vis-à-vis upstream)
[17:30] <apw> which i assume is what is exposing this new 1:10 boot failure
[17:31] <slangasek> 2) call 'udevadm exit', and then *also* call pkill udevd to reap any remaining children
[17:31]  * apw thinks 2 isn't a bad option
[17:31] <slangasek> apw: the mount -omove dates back to 2009... :)
[17:32] <apw> heh really? i thoought we only started doing that when dev became a devtmpfs
[17:32] <apw> slangasek, i thnk you should put what yo just said in the bug, the link to the ps output is key evidence
[17:32] <slangasek> yep
[17:35] <apw> slangasek, i wonder if we could also do something like this as belt-and-braces
[17:36] <apw> slangasek, mount -o move A B || mount -o bind A B
[17:46] <infinity> slangasek: Say, with an amd64 adobe-flashplugin in partner (well, in unapproved right now), do we get to undo all the crazy multiarch and plagunwrapper business for flashplugin-nonfree? ;)
[17:49]  * infinity wonders what a plagun is...
[17:55] <pitti> bdmurray: that certainly rings a bell; not sure when I saw it the last time, though, it seems to be intermittent
[17:55] <bdmurray> pitti: okay, I've hit it a few times but couldn't recreate it this morning
[18:05] <mdeslaur> infinity: yes, that would be nice
[18:06] <infinity> mdeslaur: Did you just volunteer?
[18:06] <mdeslaur> infinity: uhm, no :)
[18:07] <infinity> mdeslaur: We're in a hard freeze, I'm sure you're bored.
[18:08] <mdeslaur> infinity: security is like the post office, CVEs never stop coming in
[18:08] <mdeslaur> I'm not even sure how come I ended up holding the flash short straw in the first place
[18:11] <jdstrand> mdeslaur: you know you love it :P
[18:11]  * jdstrand dodges
[18:12]  * mdeslaur puts flash short straw in jdstrand's pocket without him noticing
[18:13]  * jdstrand notices something in his pocket and tosses it into the trash
[18:13] <slangasek> apw: I'd rather not ignore the mount -o move failures... any processes blocking the move are liable to cause trouble down the line
[18:15] <mdeslaur> jdstrand: is that a metaphor for you removing flash from the archive? \o/
[18:15] <jdstrand> I admit I have an itchy trigger finger for that one :)
[18:29] <slangasek> infinity: I don't intend to muck with that again for oneiric; but for p, sure
[18:30] <slangasek> er, I mean for precise
[18:30] <infinity> slangasek: Well, we at least need to muck enough to update the tarball bits, right?
[18:30] <slangasek> yes, but that's all the mucking I endorse at this time :)
[18:30] <slangasek> that and fixing the damn downloader to NOT CLAIM SUCCESS when it fails to install anything
[18:30] <infinity> slangasek: At which point, you could just make -downloader arch:amd64 i386, and oops, it's done. :P
[18:31] <infinity> (Well, and a couple other tweaks)
[18:35] <maco> why is xterm installed by default?
[18:47] <pitti> maco: mostly hysteric raisins, I figure; but it certainly makes a nice "if anything else goes wrong, this will still work" app?
[18:48] <maco> i dont remember it being part of the default install
[18:48] <maco> unity shows it when i search term though so i was surprised to suddenly see it
[18:49] <mdeslaur> slangasek, infinity: FYI, I plan on SRUing flash 11 (including amd64) into stable releases, most likely after oneiric releases
[18:54] <infinity> mdeslaur: You could just do it now. ;)
[18:54] <mdeslaur> infinity: slangasek will unleash his wrath at me
[18:54] <infinity> mdeslaur: He will?
[18:54] <infinity> mdeslaur: It's uninstallable right now.
[18:54] <mdeslaur> infinity: huh? how so? the old version should still be there
[18:55] <infinity> mdeslaur: If you plan to SRU the amd64 change, we may as well do it pre-release, so people aren't starting with a multi-arch plugin and switching back.
[18:55] <infinity> mdeslaur: The old version won't be there forever.  We download it from the orig in the parnet archive.
[18:55] <infinity> mdeslaur: Once I accept Flash 11 into partner, the old one goes poof.
[18:55] <infinity> mdeslaur: (And Flash 11 is in unaccepted right now)
[18:56] <mdeslaur> infinity: not anymore, we have a hack to keep the old versions in partner for that specific reason
[18:56] <infinity> unapproved, even.
[18:56] <infinity> mdeslaur: Ahh.  Well, that's silly. ;)
[18:56] <infinity> mdeslaur: But fine.  We should still do something about it.
[18:56] <mdeslaur> infinity: you do know that the flashplugin package is actually part of the installer? if you remove the old versions, people can't install anymore until I fix it
[18:57] <infinity> mdeslaur: Err, it is?
[18:57] <infinity> mdeslaur: Which installer?
[18:57] <mdeslaur> infinity: it gets installed as part of the "Install extra proprietary crap" checkbox
[18:57] <mdeslaur> infinity: ubiquity
[18:58] <mdeslaur> infinity: it's the only reason I don't get flashplugin-nonfree nuked from the archive this very minute
[18:59] <superm1> mdeslaur, for precise you should push for that checkbox to enable partner instead and install flash from there
[18:59]  * infinity is failing entirely to find this code in ubiquity.
[19:00] <mdeslaur> infinity: it installs ubuntu-restricted-something and that pulls in flash
[19:00] <mdeslaur> superm1: yes, except the partner archive isn't mirrored
[19:00] <mdeslaur> superm1: but yes, foundations should do something about it in precise
[19:00] <infinity> mdeslaur: Ah-ha.
[19:00] <infinity> mdeslaur: Still, we don't install that stuff on the CD.
[19:00] <superm1> mdeslaur, but flashplugin-nonfree pulls from partner indirectly anyway, so i think the mirroring concern is a non-starter
[19:01] <infinity> mdeslaur: So, removing old versions isn't a concern.
[19:01] <stgraber> infinity: if it's connectivity + non-free selected, it adds ubuntu-restricted-addons to the list of packages to download+install
[19:01] <infinity> mdeslaur: Cause it's pulling the most recent from the archive.
[19:01] <mdeslaur> infinity: yes, as soon as I release the new version, it works again...but I'm usually a day or two behind the partner archive
[19:02] <mdeslaur> infinity: that's why we needed to keep the old versions there for a while
[19:02] <infinity> mdeslaur: Oh, sure, I'm not saying partner shouldn't have a reaping delay (and all archives do), just that saying "it'll be there indefinitely, so we can wait" seems silly. :)
[19:02] <mdeslaur> infinity: agreed
[19:02] <infinity> mdeslaur: And every new Flash release is usually about 400 security fixes (and 200 new bugs, but whatever).
[19:03] <jdstrand> infinity has cracked the short-straw code right there
[19:04] <slangasek> mdeslaur: I'm happy for you to upload flashplugin-installer to oneiric before release, as long as you fix that darn exit 0 in the postinst along the way :)
[19:06] <mdeslaur> slangasek: so...you want to prevent users from getting security updates if for some reason their flash tarball failed to download?
[19:07] <jdstrand> oh, it's *on*
[19:07] <mdeslaur> lol
[19:09] <infinity> mdeslaur: It's general practice for postinsts to fail when they fail, yes. :P
[19:09] <infinity> mdeslaur: And in the case where a postinst is THE WHOLE PACKAGE, that seems doubly-sane, no?
[19:10] <mdeslaur> infinity: yes, I'm aware it's standard practice.
[19:10] <mdeslaur> infinity: I just _hate_ the fact that a whole bunch of users stop getting updates at some point because a package is in a failed state and update manager stops working
[19:11] <infinity> mdeslaur: Maybe our GUI tools need to learn to yell louder when that happens.
[19:11] <infinity> mdeslaur: The command-line is pretty obvious about it.
[19:12] <infinity> mdeslaur: Still, "fixing" every postinst to exit 0 unconditionally is the wrong answer.  Filing bugs on update-manager would be lovely.
[19:12] <mdeslaur> infinity: yes...we should definitely fix the gui tools (if they haven't already been fixed)
[19:12] <mdeslaur> infinity: I agree
[19:13] <mdeslaur> slangasek, infinity: ok, you win, no more exit 0
[19:14] <mdeslaur> jdstrand: I got a debian beatdown
[19:14] <jdstrand> heh
[19:24] <mdeslaur> infinity, slangasek: will apt upgrade from flashplugin-downloader:i386 to flashplugin-downloader:amd64?
[19:24] <slangasek> mdeslaur: right, I'm with infinity on this one... we need update-manager to get better at recovering from package install failures in the middle of an upgrade, but honestly it's already a lot better than it used to be, and hiding errors is the devil's work :)
[19:24] <slangasek> nope
[19:25] <infinity> There's a fix for that.
[19:25] <slangasek> if you drop the Multi-Arch: foreign from flashplugin-downloader, then the new flashplugin-installer will forcibly replace the i386 one with the amd64 one
[19:25] <infinity> Want to hear it and cry?
[19:25] <slangasek> infinity: no
[19:25] <slangasek> :)
[19:25] <infinity> Oh, that would work too.
[19:25] <mdeslaur> slangasek: oh, cool. thanks
[19:25] <infinity> (are you sure apt and dpkg will DTRT with MA bits going away again?)
[19:27] <slangasek> infinity: yes.  It is possible that apt won't actually calculate the upgrade path we *want*, but it will know "flashplugin-downloader is out of date and the new version doesn't satisfy the dependency"
[19:28] <slangasek> the question is whether it will *actually* upgrade, or if it will just try to remove stuff instead - should probably be tested in a ppa before upload :)
[19:28] <slangasek> mdeslaur: ^^
[19:28] <mdeslaur> slangasek: yeah, I'll test it
[19:28] <infinity> slangasek: Yeah.  I was going to suggest something ickier to avoid that, but... It was icky. :P
[19:28] <slangasek> I could tell ;)
[19:28] <infinity> Though, mine's guaranteed to work. ;)
[19:29] <infinity> (PS: Icky)
[19:29] <mdeslaur> slangasek: is there something better than uname -m in a postinst to get the arch?
[19:29] <infinity> mdeslaur: Eek.
[19:29] <infinity> mdeslaur: dpkg --print-architecture
[19:29] <mdeslaur> infinity: I assume that means yes :)
[19:29] <infinity> mdeslaur: uname has nothing to do with dpkg arch.
[19:29] <slangasek> uname -m is always the wrong tool
[19:29] <infinity> mdeslaur: Think i386 base on an amd64 kernel.
[19:29] <infinity> mdeslaur: For instance.
[19:30] <mdeslaur> that's what happens when I cargo cult stuff from other packages I come across :P
[19:30] <hallyn_> yeah i got that wrong with lxc-create too, stgraber set me straight :)
[19:30] <stgraber> hehe :)
[19:31] <infinity> mdeslaur: If you've found uname in another package, I'd like to know about it. :)
[19:31] <slangasek> mdeslaur: so there are two relevant "what architecture" checks you might want.  One is "what is the primary architecture of this machine" (dpkg --print-architecture), the other is "what is the architecture of this package in multiarch land" (echo $DPKG_MAINTSCRIPT_ARCH)
[19:31] <mdeslaur> infinity: I did, but I can't remember where
[19:32] <mdeslaur> slangasek: oh, so $DPKG_MAINTSCRIPT_ARCH is the arch of the package itself? hmm, I'll use that
[19:33] <slangasek> correct
[19:33] <mdeslaur> slangasek: thanks
[19:33] <slangasek> that way you don't have to munge the maintscript at build time to get that info
[19:45] <superm1> mdeslaur, stgraber , if i'm not mistaken, it's just a one line diff to fetch flash from partner directly instead of multiverse via this ugly thing at install time. http://paste.ubuntu.com/703567/
[19:46] <superm1> ubuntu-restricted-addons will already fetch adobe-flashplugin first if it's available
[19:46] <mdeslaur> ooooh
[19:47] <mdeslaur> slangasek, infinity: how about doing that and killing flashplugin-nonfree entirely?
[19:47] <mdeslaur> ^
[20:04] <slangasek> mdeslaur, superm1: blah, no
[20:04] <slangasek> opting to install flash is not the same thing as opting to enable partner
[20:05] <slangasek> if we wanted that, we should drop the package from multiarch entirely
[20:05] <slangasek> also, this would lose all the nspluginwrapper integration, which AIUI adobe has rejected
[20:06] <mdeslaur> slangasek: we don't need nspluginwrapper anymore
[20:06]  * slangasek makes a sour face :)
[20:07] <mdeslaur> slangasek: but, that's a good point, opting into that checkbox doesn't mean opting in to partner
[20:07] <mdeslaur> slangasek: why the sour face?
[20:07] <slangasek> regardless, I'm not ok with handling this via a policy change in ubiquity during final freeze
[20:07] <slangasek> mdeslaur: because not all browsers have firefox's out-of-process plugin handling... the nspluginwrapper integration is IMHO still a feature :)
[20:08] <slangasek> but yeah, technically we don't need it now
[20:08] <mdeslaur> I'm not sure how the upgrade patch would have worked anyway
[20:08] <mdeslaur> s/patch/path/
[20:08] <slangasek> yeah
[20:12] <hallyn_> doko: do you know why libnl-3 doesn't install /etc/classid?
[20:12] <hallyn_> (Makefile still appears to generate it, and libvirt with netcf wants it.)
[20:12] <cyphermox> hallyn_: I think it's an issue with whether makefile really tries to install it, or tries to install it in the right place
[20:13] <cyphermox> and I fail, I should have tried to address this a few minutes ago
[20:13] <cyphermox> hallyn_: I've seen a patch or commit on the mailing list or on git post libnl3 3.0
[20:13] <hallyn_> cyphermox: ok, so it's not being droppedon purpose?
[20:13] <hallyn_> ok, cool.
[20:14] <cyphermox> hallyn_: no, I do think it's a bug. but I also don't see what it changes (not that I looked)
[20:14] <hallyn_> cyphermox: thanks, I"ll work around it for now and file a bug later today
[20:14] <cyphermox> aside from the message I saw no effect
[20:14] <cyphermox> hallyn_: are you running into an actual bug with this?
[20:15] <hallyn_> well libvirt tests are failing, i don't know if it's because of those or not
[20:16] <hallyn_> cyphermox: yes, with the file installed the tests pass :)  so it will break libvirt build
[20:16] <hallyn_> (when netcf is enabled, hopefully very soon)
[20:17] <cyphermox> dah
[20:17] <cyphermox> the tests pass?
[20:18] <hallyn_> yes
[20:19] <cyphermox> oh, sorry, I had missed reading one of the above lines :)
[20:19] <hallyn_> np :)
[20:19] <mdeslaur> slangasek: so a apt-get dist-upgrade is holding flashplugin-installer back
[20:19] <hallyn_> now, the q, does this all actually *work* :)
[20:19] <ricotz> slangasek, hi, this seems to be a multiarch related problem -- i am trying to compile this http://paste.debian.net/plain/134701 with the included command which results in a linker error, and it works using binutils-gold
[20:19] <cyphermox> hallyn_: what's classid supposed to contain?
[20:20] <hallyn_> "ClassID <-> Name Translation Table"
[20:20] <mdeslaur> slangasek: but if I do "apt-get install flashplugin-installer", it wants to do the right thing
[20:20] <hallyn_> cyphermox: it only has three, though.
[20:20] <hallyn_> 0:0, ffff:ffff, and ffff:fff1
[20:20] <slangasek> mdeslaur: yep, those were the two possible outcomes there, drat
[20:21] <cyphermox> ah
[20:22] <slangasek> ricotz: what does working using binutils-gold have to do with multiarch?
[20:22] <ricotz> it might be a problem with the multiarched glib
[20:23] <slangasek> I see nothing that suggests that
[20:23] <ricotz> it seems the normal linker is missing a reference to -L/lib/x86_64-linux-gnu/
[20:24] <ricotz> slangasek, can you confirm the error?
[20:24] <slangasek> ricotz: I get an error; you didn't say what your original error was
[20:24] <slangasek> abstract.c:(.text+0x10): undefined reference to `g_unix_socket_address_abstract_names_supported'
[20:24] <slangasek> abstract.c:(.text+0x23): undefined reference to `g_print'
[20:25] <slangasek> abstract.c:(.text+0x34): undefined reference to `g_print'
[20:25] <slangasek> collect2: ld returned 1 exit status
[20:25] <ricotz> yes, that one
[20:25] <slangasek> nothing to do with multiarch
[20:25] <slangasek> glib2.0 broke its .pc file
[20:26] <ricotz> ok
[20:26] <slangasek> Requires: gobject-2.0,gmodule-no-export-2.0,gio-2.0
[20:26] <ricotz> so gold is adding some additional paths on its own then
[20:26] <slangasek> I'm pretty sure that's the wrong syntax
[20:47] <kees> slangasek: wow, neat. my system hung at boot waiting for my cryptswap to "be available"
[20:48] <kees> I dropped to manual recovery, and everything looked fine (it was set up and available)
[20:48] <slangasek> hmm
[20:48] <kees> in a final bid to wonder if it got set up wrong, I ran blkid /dev/mapper/cryptswap1 and instantly the system finished booting
[20:48] <sconklin> kees: have seen the same thing, exactly once, on a Natty system
[20:48] <slangasek> kees: for the moment I assume this is a duplicate of one of the other two udev bugs
[20:49] <slangasek> kees: is it random crypted swap?
[20:50] <kees> slangasek: yeah
[20:51] <Dean> nope
[20:51] <slangasek> kees: so that should've been brought up in the initramfs.  racy-racy
[20:51] <kees> slangasek: right, I assume it's the same bug too. I just hadn't seen blkid trigger udev happiness
[20:51] <kees> slangasek: right, mountall told me it was waiting for it.
[20:51] <slangasek> yeah, dunno about that
[20:53] <slangasek> oh, if it's crypted random, I guess it wouldn't be registered as a RESUME target in the initramfs setup
[20:58] <kees> slangasek: right, but it's listed in my fstab
[21:00] <slangasek> kees: yes, I'm just working through why it wouldn't necessarily be brought up via initramfs
[21:00] <slangasek> in fact, if it's not the rootfs or the RESUME target, I think cryptsetup explicitly does *not* try to bring it up in the initramfs
[21:01] <kees> ah! right, yeah, this one isn't delayed, so it's effectively crossing the initramfs/real-root udev kill boundary
[21:01] <slangasek> "isn't delayed"?
[21:01] <slangasek> what's /conf/conf.d/cryptroot in the initramfs?
[21:02] <kees> ... isn't waited for, is really what I meant.
[21:02] <slangasek> right
[21:02] <infinity> superm1: Dude, dpkg -l in your postinst?
[21:02] <slangasek> and anything that isn't waited for, AFAIK isn't *attempted* at all
[21:02] <superm1> infinity, not in the postinst, this is in a late script
[21:02] <infinity> superm1: What are you trying to determine?  If a package is installed?
[21:03] <infinity> superm1: Or, whever.
[21:03] <kees> slangasek: should be empty, let me unpack it...
[21:03] <superm1> infinity, yeah but just a quick check if it's installed to prevent badness from happening if so
[21:03] <infinity> superm1: Either eay, that's not entirely guaranteed to work the way you think it will.  And you're much better off testing for a file on the filesystem from said package, IMO.
[21:03] <superm1> infinity, really?  how can it break?
[21:04] <infinity> superm1: If anything in dpkg -l matched 'fist', for starters?
[21:04] <kees> slangasek: yeah, I don't have a /conf/conf.d/cryptroot at all
[21:04] <infinity> superm1: (plus there's the part where packages can show in dpkg -l even when not installed, you're not actually checking the status, you're just checking to see if it's listed)
[21:05] <broder> superm1: dpkg -l can also be really slow because it forces you to read the whole dpkg database off disk
[21:05] <superm1> infinity, well that's a good point for futureproofing
[21:05] <infinity> superm1: It's much saner to just test for a file that "fist" ships.
[21:05] <superm1> want to axe the upload and i'll follow the recommendation?
[21:05] <infinity> Rejecting.
[21:05] <superm1> thansk
[21:06] <slangasek> kees: ok, so it's not an initramfs issue.  There have been past reports of raciness between mountall and crypted swap; I think you'll find an open bug on mountall for this
[21:07] <kees> slangasek: okay, cool.
[21:47] <cyphermox> @pilot out
[21:48] <cyphermox> I'll be back later; for now on the road / dinner and all :)
[23:37] <cr3> is there a preferred package to get a utc timezone object in python on ubuntu? I've been using python-tz but it's not installed by default, so I'm hoping there's a recommended package more likely to be already installed
[23:46] <cr3> aha, I believe it's python-dateutil!