[01:03]  * lamont wonders where his launcher went
=== freeflyi1g is now known as freeflying
=== vorian is now known as v
[04:59] <pitti> Good morning
[05:24] <pitti> ScottK: I replied to the wl bug with some details, and subscribed so that I'll see your response immediately
=== highvolt1ge is now known as highvoltage
[06:32] <geser> good morning
[06:45] <dholbach> good morning
[06:53] <pitti> hey dholbach
[06:54] <dholbach> hey pitti
[06:54] <dholbach> pitti, I was near your home town (or at least where you used to live before) over the weekend :)
[06:55] <dholbach> it was a very nice trip :)
[06:55] <dholbach> how are you doing?
[06:55] <pitti> dholbach: ah, nice! where did you go exactly?
[06:55] <pitti> dholbach: I'm quite fine, thanks! had a nice weekend (although fairly rainy)
[06:55] <dholbach> pitti, hiking in the area around Bad Schandau :)
[06:55] <pitti> sehr schoen
=== smb` is now known as smb
[07:44] <g0uZ> [22/04/2013 09:30] <xnox> g0uZ: pinging slangasek on #ubuntu-devel irc channel might be better. Or email ubuntu-devel-discus mailing list. // slangasek, there ?
[07:44] <mlankhorst> is upgrading to quantal still supported after 12.04.3 ?
[07:45] <g0uZ> I'm searchinf for a clean solution to have audit support in libpam0 for ubuntu precise 12.04 LTS
[07:46] <mlankhorst> I'm worried a bit because libdrm is going to have to break, and if upgrading to quantal is still supported we'd need to offer a way to downgrade libdrm to the quantal version before upgrading..
[07:46] <g0uZ> its related to https://bugs.launchpad.net/ubuntu/+source/pam/+bug/937005
[07:46] <ubottu> Launchpad bug 937005 in pam (Ubuntu) "pam_tty_audit.so is missing in oneiric/precise" [Undecided,Fix released]
[07:47] <stgraber> mlankhorst: I think our standard statement is that 12.04 => 12.10 is a supported upgrade path so long as 12.10 is supported, so yeah, I think 12.04.3 => 12.10 should somehow work and not end up giving you packages that don't exist in the target release
[07:47] <mlankhorst> stgraber: it can work, but libdrm will need to be downgraded
[07:48] <stgraber> mlankhorst: I guess in general we want upgrades from 12.04+enablement-stack to somehow remove all the enablement bits and then upgrade to whatever is in the target release
[07:48] <mlankhorst> no, upgrading from enablement stack is unsupported
[07:48] <mlankhorst> I don't have to worry about that case
[07:49] <stgraber> hmm, that seems suboptimal... so we're basically telling people installing 12.04.2/12.04.3 that they can't upgrade to anything after that? that sounds kinda wrong to me
[07:49] <mlankhorst> they can upgrade to the next lts, that has already been decided
[07:50] <mlankhorst> https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/1171340
[07:50] <ubottu> Launchpad bug 1171340 in libdrm (Ubuntu) "Please update dh-exec, llvm-3.2 and libdrm for lts-raring" [Undecided,New]
[07:50] <mlankhorst> is what I'm worried about
[07:53] <maxb> ooi, and semi-related, is it technically supported to upgrade from N->O->P after O EOLs?
[07:54] <stgraber> mlankhorst: am I looking at the wrong PPA? the one I'm looking at as the same version of libdrm as quantal, so wouldn't require a downgrade (so long as you make sure to use lower packaging version numbers)
[07:54] <stgraber> maxb: no
[07:55] <stgraber> maxb: it's still likely to work though (you may have to change to old-releases.ubuntu.com depending on how quick we are to archive the series)
[07:55] <mlankhorst> stgraber: you're looking at the right ppa, and that version was already causing issues..
[07:56] <stgraber> mlankhorst: ah, so you're planning on moving to the raring version of it then?
[07:56] <mlankhorst> stgraber: it's required for the lts-raring stack, yes
[07:59] <diwic> pitti, "ImportError: No module named apport" <- has something been renamed recently in apport?
[07:59] <maxb> I suppose there's the possibility of 2.4.39-0ubuntu1~really2.4.43ubuntu1, but ugh
[07:59] <mlankhorst> maxb: that would be ineffective if that x-updates ppa was installed
[08:00] <stgraber> mlankhorst: and why can't we do the usual trick to copy that raring libdrm backport under a different name? (sorry, as you may have noticed I didn't look much into the implementation of that stuff since when we first specced it at UDS)
[08:00] <mlankhorst> and since the steam instructions still contain that, it's going to be a support nightmare
[08:00] <mlankhorst> stgraber: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1086345
[08:00] <ubottu> Launchpad bug 1086345 in libdrm (Ubuntu Precise) "Quantal-LTS-stack: Showing low-resolution screen on shutdown/reboot" [Critical,Fix released]
[08:02]  * maxb wonders how evil a no-change SRU to quantal to help the numbers sequence right would be
[08:03] <mlankhorst> not that evil
[08:03] <mlankhorst> but some might have xorg-edgers which will disturb things too
[08:04] <stgraber> mlankhorst: right... so we're indeed left with two options there, either change the dist-upgrader to allow downgrading when moving to quantal and potentially regressing the system (who knows what other bugs got fixed by the new version) or SRU the raring version to quantal and then to precise
[08:04] <stgraber> my assumption being that you already need to support people using the quantal enablement stack on precise and who will have the raring libdrm, so having the same combo in one more series shouldn't be too much pain
[08:05] <mlankhorst> true
[08:06] <mlankhorst> and upgrading libdrm is generally not a pain, only thing causing some issues was nouveau soname bump, but that only affects precise builds of xserver/ddx-nouveau/mesa, and has already been dealt with
[08:07] <stgraber> ok, so I'd recommend talking to the SRU team about pushing the raring version to both quantal and precise. You'll obviously need serious testing but I guess you already have that anyway ;) then the TB will have to grant a one time MRE for the quantal upload, but I'm happy to do that.
[08:08] <mlankhorst> sure
[08:09] <mlankhorst> fortunately libdrm is quite boring, the api is mostly a c wrapper around kernel syscalls, so we haven't had to deal with many bugs there :)
[08:10] <diwic> pitti, hmm, or is it rather so that all packages installing apport hooks need to (runtime) depend on python-apport ?
[08:13] <pitti> diwic: what did you do to get this error?
[08:13] <pitti> diwic: might also be python-apport vs. python3-apport ?
[08:14] <diwic> pitti, I made a dkms package (with my own framework), which had an error in it. When I tried to install it, the build failed, and then this error came up
[08:14] <pitti> the apport module name has never changed
[08:14] <mlankhorst> infinity: ping?
[08:14] <diwic> pitti, but it turned out python-apport was not installed
[08:14] <pitti> diwic: right, it's not supposed to; we install python3-apport
[08:14] <pitti> and stuff is supposed to use python3
[08:15] <pitti> perhaps there's some script in dkms which hasn't been moved to py3 yet
[08:15] <infinity> mlankhorst: Sup?
[08:16] <mlankhorst> see discussion above :) I had to talk with the sru team about backporting libdrm from raring to quantal and precise
[08:17] <infinity> mlankhorst: Renamed source and binaries, or updating the current packages?
[08:17] <mlankhorst> updating
[08:17] <mlankhorst> renaming has led to problems before, and is quite impossible
[08:17] <infinity> mlankhorst: Yeah, I recalled that, which was why I asked about the intent. :)
[08:18] <infinity> mlankhorst: I have no problems in theory with backporting libdrm, so long as you test heavily that it doesn't break 3.2.x and 3.5.x kernels.
[08:18] <infinity> (Which it shouldn't, AFAIK, but best to get solid statistics)
[08:18] <mlankhorst> that's kernel drm, libdrm is the userspace abi
[08:18] <diwic> pitti, hmm, okay, I'm trying to look...
[08:18] <infinity> mlankhorst: Yes, but libdrm talks to kernel drm syscalls.
[08:18] <infinity> mlankhorst: But it should be all backward compat unless someone effed up, so..
[08:18] <diwic> pitti, if anything starts with #!/usr/bin/python, that means python2, right?
[08:18] <mlankhorst> yeah :)
[08:18] <pitti> diwic: right
[08:19] <infinity> mlankhorst: I have no problems with it, just want to see seriously heavy testing.
[08:19] <mlankhorst> sure
[08:19] <pitti> diwic: that either needs to be converted to py3, or depend on python-apport
[08:19] <infinity> mlankhorst: Have there been any drastic packaging changes, or just upstream bits?
[08:19] <mlankhorst> actually 2.4.39 -> 2.4.43 hasn't seen much change, was digging through changelog
[08:19] <infinity> mlankhorst: Good, good.  That's comforting.
[08:20] <mlankhorst> mostly things like minor bugfixes, and adding support for new hardware
[08:21] <mlankhorst> and some radeon SI tiling changes, but SI support wasn't in quantal or precise
[08:24] <infinity> mlankhorst: Alright.  That's all quite comforting.  Go ahead and prep the SRUs and toss 'em in the queue.
[08:24] <mlankhorst> thanks
[08:25] <infinity> -0ubuntu0.1 and -0ubuntu0.1.1 or something.  Or throw some 12.xx in there.  Whatever.
[08:25] <mlankhorst> I'll do the former form. :)
=== KRF_ is now known as KRF
=== doko__ is now known as doko
[08:56] <mlankhorst> stgraber: do you want a formal application to TB for libdrm?
[09:00] <stgraber> mlankhorst: nope, I'll just add the exception to the wiki
[09:01] <mlankhorst> ok thanks :)
[09:02] <stgraber> mlankhorst: done
[09:07] <mlankhorst> stgraber: what about dh-exec? It requires a newer version to build llvm-3.2 succesfully
[09:10] <stgraber> mlankhorst: so you'd backport 0.6?
[09:10] <mlankhorst> if possible :)
[09:11] <stgraber> ok, 0.5 basically changes nothing, looking at the 0.6 diff now
[09:11] <stgraber> sounds safe to me. I'll add that to the MRE
[09:12] <stgraber> I guess you could have worked around this by renamming the .install in the other source, but that'd just be working around a bug, so we may as well fix it
[09:13] <stgraber> I'm not even sure you'd need an MRE for that one as all the changes from 0.4 are trivial to test, but I'll add it anyway so it's less confusing to the SRU team :)
[09:13] <mlankhorst> oh 0.3 is enough
[09:15] <mlankhorst> but the version in precise is 0.2, which is definitely too old :)
[09:15] <stgraber> ah so you don't need to update quantal then, just precise?
[09:15] <mlankhorst> yeah
[09:15] <stgraber> one problem though is that dh-exec in precise is in universe, so you won't be able to build-dep on that
[09:16] <mlankhorst> since llvm-3.2 seems to require it, I fear it will have to be pulled into main then :S
[09:17] <stgraber> well, you could just do the same thing as dh-exec directly in debian/rules
[09:17] <Mirv> slangasek: FYI I pushed a test build of the (Qt4) qtwebkit-source 2.3.1 in to qt5-beta-proper PPA. if it goes fine, I'll contact Kubuntu people about it.
[09:20] <mlankhorst> I don't see where it's using dh_exec though..
[09:20] <mlankhorst> maybe it could simply be dropped entirely
[09:22] <stgraber> that would make things much simpler ;)
[09:22] <mlankhorst> I only see it as build-dep, weird..
=== ckpringle_ is now known as ckpringle
[09:34] <mlankhorst> seems to build fine without after I removed dh-exec on my system, I'll do a build in my ppa to confirm.
[10:26] <cjwatson> seb128: should friends-identica (+ accounts-plugin-identica) be seeded, or dropped to universe?
[10:26] <cjwatson> It's not recommended by friends-dispatcher, unlike friends-{facebook,twitter}
[10:28] <seb128> cjwatson, I'm not sure, let's check with Ken when he gets online (shouldn't be in too long)
[10:28] <cjwatson> OK
[10:39] <mlankhorst> stgraber: ok mre for dh-exec can be removed, llvm builds just fine without dh-exec :)
[10:39] <stgraber> mlankhorst: good
=== MacSlow is now known as MacSlow|lunch
=== security is now known as megha
=== megha is now known as baba
=== tkamppeter_ is now known as tkamppeter
=== MacSlow|lunch is now known as MacSlow
=== ritz__ is now known as ritz
=== seb128_ is now known as seb128
[12:41] <ScottK> pitti: Thanks.
=== ckpringle_ is now known as ckpringle
[13:30] <mlankhorst> ogasawara: I'm going to do the same arch support for x with lts-raring, libdrm I'll update for all archs, but everything else including llvm-3.2 will only build for amd64 or i386.
[13:31] <ogasawara> mlankhorst: ack
[13:32] <mlankhorst> I'm just finishing up on a test build, I believe it should be possible to land the lts-raring x stack any time, depending on a sru admin willing to review it. :-)
[13:34] <ogasawara> mlankhorst: I don't think there is any hurry at the moment (12.04.3 isn't till August).  but we should probably start to think about staging both the lts-raring x and kernel packages in a PPA.
[13:34] <mlankhorst> yeah
[13:34] <ogasawara> mlankhorst: maybe we can sync about it next week at the sprint
[13:34] <mlankhorst> I can't make it, sadly
[13:35] <ogasawara> mlankhorst: boooo :(
[13:35] <mlankhorst> but we could use https://launchpad.net/~ubuntu-x-swat/+archive/r-lts-backport again, wouldn't be hard.
[13:35] <ogasawara> mlankhorst: works for me, I'll coordinate with my team
[13:39] <mlankhorst> it should be a lot easier now at least, I only need the libdrm sru done and then I should be ready for uploading everything :)
[13:39] <ogasawara> mlankhorst: and actually now that I check, tim's already been uploading our raring kernel to the r-lt-backport PPA
[13:45] <mlankhorst> ah good
=== wedgwood_away is now known as wedgwood
=== kentb-out is now known as kentb
=== mmrazik is now known as mmrazik|otp
=== sforshee` is now known as sforshee
=== mmrazik|otp is now known as mmrazik
[14:39] <mlankhorst> infinity: can you accept libdrm? :)
[14:39] <infinity> mlankhorst: I can.  But will I?
[14:39] <ogra_> mlankhorst, now ... if you were coming to the sprint you could bribe him
[14:41] <mlankhorst> so that just means I can't bribe ;)
[14:41] <stgraber> ogra_: maybe you can order some voucher for the Trappist, then you don't need to be there in person ;)
[14:41] <ogra_> haha
[14:42] <infinity> I approve of this plan.
[14:43] <ScottK> That or convince someone who is present to provide the bribe.
[14:44] <ogra_> proxybribing ....
[14:45] <mlankhorst> but then it wouldn't be me bribing, it would be me ordering a bribe
[14:45] <infinity> The route is less important than the packet getting there.
[14:47] <mlankhorst> how can you be sure it's really my bribe then
[14:48] <infinity> You could sign it.
[14:49] <ScottK> Some variant on the RFC 5518 VBR protocol could probably handle it.
[14:49] <ScottK> Just bribes instead of email.
[14:52] <mterry> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Frozen for Final Release | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry
[14:54] <mlankhorst> I think having a verifiable trace about a bribe would defeat the purpose of said bribe
[15:01] <xnox> how would I crash ext4 filesystem such that next mount would require a journal replay? is there a way to toggle such a flag in the ext4 superblock?
[15:02] <ogra_> dd some crap into it while its not mounted ?
[15:05] <xnox> ogra_: any suggestions at resonable amounts of "crap" to dd and offsets? =)))))
[15:05] <ogra_> not really ... but thats what i would try ...
[15:06] <ogra_> just dont overwrite the superblock :)
[15:06] <nemo> I wonder if umount -fi would freak it out
[15:06] <nemo> (while it was doing writes)
[15:08] <xnox> nemo: sounds more interesting. Let me try scripting something here around that =)
[15:09] <nemo> xnox: you know. if it is in a VM, you could just power it off while it is doing writes
=== _salem is now known as salem_
[15:09] <nemo> probably a better real world sim anyway
[15:09] <nemo> well. you could do it on physical too, but ew
[15:10] <ogra_> heh, yeah, just pull the power  of the disk
[15:20] <nemo> ogra_: hm. yanking a flash drive probably less damaging
[15:21] <nemo> xnox: ooh. yeah. journaled ext4 parition on a thumb drive, yank that?
[15:21] <mlankhorst> where's the fun in that ;)
[15:21] <dunkel2> -j unity3d
[15:21] <nemo> heck. writing to it over USB1 would make yanking it while writing really easy :)
[15:21] <nemo> well. I guess just using /dev/urandom would work too
=== ckpringle_ is now known as ckpringle
=== racarr_ is now known as racarr
[15:36] <smoser> slangasek, ping
[15:36] <smoser> or jodh
[15:37] <jodh> smoser: hi
[15:37] <smoser> i'm looking / hoping for something on bug 1124384 or bug 1103881
[15:37] <ubottu> bug 1124384 in cloud-init (Ubuntu) "reload-configuration can confuse upstart" [High,Confirmed] https://launchpad.net/bugs/1124384
[15:37] <ubottu> bug 1103881 in upstart (Ubuntu) "cloud-final is never executed if upstart is upgraded during initialization of the image " [High,Confirmed] https://launchpad.net/bugs/1103881
[15:37] <smoser> if this upgrade issue isn't fixed, we're going to see people do really stupid things like suggested here:
[15:37] <smoser> https://codereview.appspot.com/8648047/
[15:37] <smoser> (ie, specifically handle upgrade on 13.04 differently then anywhere else)
[15:38] <jodh> smoser: working on it as fast as I can :)
[15:39] <jodh> smoser: any update from the kernel team on the fix for the original problem (bug 882147)?
[15:39] <ubottu> bug 882147 in coreutils (Ubuntu) "overlayfs does not implement inotify interfaces correctly" [Undecided,In progress] https://launchpad.net/bugs/882147
[15:39] <smoser> jodh, well, that is only half the problem. and i doubt it will fixed any time in near future. overlayfs has lots of shortcomings.
[15:40] <smoser> the larger issue is upgrade of upstart loses state.
[15:41] <smoser> the only real solution i have for that is to hold upstart.
[15:42] <jodh> smoser: the bug has been around for a long time seemingly as nobody has ever tried to reload whilst booting. It's a ref-counting issue, but somewhat delicate.
[15:43] <smoser> it is not present in 12.10
[15:44] <jodh> smoser: using your lxc testcase the behaviour is seen in 12.10.
[15:44] <smoser> i can avoid 'reload-configuration' , and have disabled that code in cloud-init 12.10
[15:44] <smoser> er... in 13.03
[15:44] <smoser> er... in 13.04
[15:44] <smoser> so we don't 'reload-configuration' now when an upstart job is written.
[15:45] <smoser> but i can't avoid a potential upgrade to upstart.
[15:46] <smoser> i assumed that i'd be impossible/unlikely to fix 'apt-get upgrade upstart' without fixing 'initctl reload-configuration'
[15:46] <smoser> as i assumed that the former is "heavier" than the latter.
[15:49] <xnox> smoser: are you allowed to "reboot"? write the new jobs out, reboot "for real" and clean-up / finish initialisation.
[15:49] <xnox> smoser: another possibility is to step down run-levels until it's safe to reload configuration, and step up again, at which point a reboot would be cleaner.
[15:49] <smoser> xnox, i dont want to reboot.
[15:50] <xnox> ack.
[15:50] <smoser> i'm thinking right now of holding upstart
[15:50] <smoser> and un-holding later.
[15:51] <smoser> but i really dont want to expose such sillyness to juju (or anyone else using ubuntu).
[15:52] <smoser> ie, i really do not want code like that in juju.
[15:58] <smoser> jodh, you have feelings on the above ? my suggestion is to hold upstart prior to cloud-init initialized upgrade, and then unhold it in "final" (rc.local level).
[15:59] <smoser> and to continue as we're doing right now, not reload-configuration on addition of an upstart job.
[16:03] <jodh> smoser: slightly confused - this bug isn't related to stateful re-exec - it's just a "reload whilst jobs and event are in-flight" issue.
[16:07] <smoser> jodh, 2 bugs.
=== jasoncwarner__ is now known as jasoncwarner
[16:07] <smoser> bug 1103881 is a result of stateful reexec (as a result of upgrade)
[16:07] <ubottu> bug 1103881 in upstart (Ubuntu) "cloud-final is never executed if upstart is upgraded during initialization of the image " [High,Confirmed] https://launchpad.net/bugs/1103881
[16:08] <smoser> bug 1124384 is 'reload-configuration' confuses upstart.
[16:08] <ubottu> bug 1124384 in cloud-init (Ubuntu) "reload-configuration can confuse upstart" [High,Confirmed] https://launchpad.net/bugs/1124384
[16:08] <smoser> i had assumed that reload-configuration was a subset of stateful reexec.
[16:08] <jodh> smoser: they are completely different.
[16:09] <ScottK> pitti: Replied in the bcmwl/jockey bug.  Please let me know what you think.
[16:09] <smoser> ok. then i suggest that 1103881 is significantly more critical.
[16:11] <jodh> smoser: so, if holding + no reload can be made to work for you, yes I'd do that for now until we can fix these issues.
[16:12] <smoser> jodh, i can do that. the only problem is that that works around the issue for a very small percentage of ubuntu users.
[16:12] <smoser> do you have a feeling as to how bad this is ? at what points is a upgrade of upstart safe?
[16:13] <smoser> or will all users lose state the first time we SRU upstart to 13.04
[16:13] <mgz> just as a note, juju does not restart machines as part of the boot
[16:14] <mgz> so, if there's any upstart upgrade on top of the 13.04 release image that will break like this, we need some kind of solution that doesn't involve manual interventions
[16:14] <jodh> smoser: your scenario is the only upgrade issue I'm aware of.
[16:16] <smoser> jodh, but what is that scenario?
[16:16] <smoser> afaik it is "user runs apt-get upgrade"
[16:21] <smoser> jodh, do you know the scope of the problem? such that i could reduce my work around to that? or possibly you could add a work around into upstart
[16:21] <smoser> something like "can't upgrade self now, add a task to do it later"
[16:22] <cjwatson> Given that we know the area of upstart code involved in this failure, I think it would be more appropriate to focus on fixing it properly in an early SRU than in spending time on hacky workarounds
[16:41] <smoser> cjwatson, i had generally accepted that, and assumed it would get fixed.
[16:42] <smoser> but given the choice of "work around it in cloud-init" and "let juju, heat, puppet, chef, salt, insert-service-orchestration-tool-here", i'd rather do it in cloud-init than all of those. and rather do it in upstart than cloud-init.
[16:45] <smoser> it seems that at least some people understand the scope of the problem. i'd like to have such information so i can try to work around.
[16:48] <smoser> i'm not trying to be a jerk. i'm rying to come up with a solution so as to avoid juju having to know about this.
[16:50] <bdmurray> tjaalton: are you planning on working on the sru for bug 1095052?
[16:50] <slangasek> smoser: like cjwatson, I think it's counterproductive here to focus on a workaround when the correct fix is in progress.
[16:50] <ubottu> bug 1095052 in gnutls26 (Ubuntu Precise) "Client certificate authentication fails" [Medium,In progress] https://launchpad.net/bugs/1095052
[16:54] <smoser> slangasek, i'm not following.
[16:54] <smoser> are you suggesting that cloud-init not try to work around? or upstart not try to work around?
[16:54] <smoser> how about juju ?
[16:56] <smoser> having zero workaround in place (that would then have to be backed out, possibly languishing well beyond their necessity) is clearly the best case scenario. but doing that means juju and cloud-init are broken anytime there is an upstart upgrade.
[16:57] <smoser> if i'm told "there will be no SRUs of upstart to 13.04 that do not fix this problem, and fix it in-place", then thats acceptable.
[17:01] <smoser> i realize now that the hold of upstart is insufficient as i'd have to dpkg-hold libc6 and all other dependencies also. :-(
=== cjohnston_ is now known as cjohnston
[17:22] <seb128> cjwatson, oh, btw, kenvandine says that friends-identica and accounts-plugin-identica should go to universe
[17:23] <cjwatson> seb128,kenvandine: Righto, thanks - done
[17:23] <seb128> cjwatson, thanks
[17:23] <kenvandine> cjwatson, thanks
=== G4MBY is now known as PaulW2U
=== deryck is now known as deryck[lunch]
[17:42] <tjaalton> bdmurray: yeah, about to upload it after a test build
[17:45] <bdmurray> tjaalton: cool, thanks
[17:48] <tjaalton> bdmurray: built fine, uploaded
[17:58] <slangasek> smoser: things are already broken on upstart upgrade right now, and as has been noted, this is not a new bug; the timeline for the proper fix in upstart here should be measured in days, not weeks; and yes, there aren't going to be other SRUs of upstart into 13.04 prior to this fix landing
=== deryck[lunch] is now known as deryck
[18:26] <mterry> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Frozen for Final Release | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[18:46] <ScottK> doko: The handbrake update that you sync'ed from experimental (a month ago) is depwait due to missing libav bits.  Should we just remove it from -proposed or is there some other solution?
[18:46] <cjwatson> The plan was to move it to s-proposed once that's possible
[18:46] <cjwatson> It'll be fine in S once we do the libav9 transition
[18:49] <cjwatson> And it's not vital that -proposed be empty for release - we should just understand everything in it
[18:51] <ScottK> It'll never be buildable in raring though.
[18:51] <cjwatson> Yeah, but we can delete it out of raring once we've moved it to S, no?
[18:51] <ScottK> OK.  Makes sense.
[18:51] <cjwatson> Daviey,zul: Should cinder-backup, quantum-lbaas-agent, and quantum-plugin-midonet be moved to universe, or should they be seeded?
[18:51] <cjwatson> Those are the last three (I moved python-pybabel to universe, since it's a transitional package)
[18:52] <zul> cjwatson: seeded please
[18:52] <cjwatson> OK.  Could you do that somewhere appropriate?
[18:52] <zul> sure
[18:52] <cjwatson> Thanks.
[18:52] <zul> cjwatson:  as in the server seed?
[18:53] <Daviey> zul: platform not cd please.
[18:53] <zul> Daviey:  ack
[18:53] <cjwatson> That's unlikely to be appropriate.  The server seed is automatically installed on every server installation.
[18:53] <cjwatson> That> the server seed I mean
[18:55] <Daviey> zul: supported-server, lp:~ubuntu-core-dev/ubuntu-seeds/platform.raring
[18:55] <Daviey> err
[18:55] <Daviey> supported-misc-servers
[18:56] <Daviey> next cycle, we should probably bust that out into a dedicated openstack seed file.
[19:00] <tjaalton> slangasek: hey, is the new plymouth job good enough for raring?
[19:00] <slangasek> tjaalton: yes, I think so - we're in SRU territory at this point, however
[19:00] <tjaalton> slangasek: right, sure
[19:01] <slangasek> tjaalton: so this is less urgent than some other stuff that's going on - but if you could fix up the bug info to get it on track for SRU, that would help
[19:02] <tjaalton> slangasek: yep I'll do that tomorrow and upload to -proposed(?)
[19:02] <tjaalton> same for lightdm
[19:02] <slangasek> tjaalton: sound sgreat
[19:03] <tjaalton> I'll add some other *dm's too
[20:04] <Gundarr> I have one question.  It is quick and requires the expertise knowledge of our hallowed Ubuntu dev's.  It is not a question asking for support.  I just want to know:  Does the Linux 3.5.x kernel and the "xserver-xorg-video-radeon-lts-quantal" software packages drop support for the legacy AMD FGLRX proprietary graphics driver (FGLRX version 8.960)?  I'm trying to make an informed decision before I perform a potentially ris
[20:04] <Gundarr> ky 'apt-get' action.
[20:06] <Gundarr> .............................?
[20:07] <cjwatson> IRC is asynchronous; it is expected to need to wait perhaps some time
[20:08] <cjwatson> But you might try #ubuntu-kernel or #ubuntu-x (I'd suggest picking one rather than crossposting) as more specialist channels
[20:09] <mlankhorst> for the record, I believe it does..
[20:36] <slangasek> bryce: are you still able to reproduce bug #1080701?
[20:36] <ubottu> bug 1080701 in ubiquity (Ubuntu Raring) "After 'Preparing to install Ubuntu' screen, raring installation hangs" [Critical,Confirmed] https://launchpad.net/bugs/1080701
=== seb128_ is now known as seb128
[20:58] <bryce> slangasek, I haven't seen it so far this year
[21:01] <jtaylor> I had it when I tried to install raring a few weeks back, though I don'T have more to add than already is in the bug report
[21:03] <jtaylor> I could try it again if you need some specific information
[21:06] <slangasek> bryce: hmm, alrighty
[21:07] <slangasek> jtaylor: well, we need someone who can actively reproduce it, to work with the QA team to turn it into a reproducible test case
[21:07] <slangasek> jtaylor: so if you can still reproduce it, I guess plars would like to have info about your disk layout (partition table, etc)
[21:07] <plars> jtaylor: what kind of system was this on?
[21:08] <jtaylor> its like most other reports, lots of partitions, mix of real, lvm and one of them is windows
[21:08] <jtaylor> + an external ntfs and ext4, which caused issues in the past, but unplugging them did not help this time
[21:09] <slangasek> jtaylor: the devil is likely in the details here... if we could get an exact partition table, plus enough info to set up a matching set of filesystems, that would probably go a long way
[21:10] <lifeless> cjwatson: how much of the start of each disk did you need for my grub-fails-to-recognise-raid6+lvm bug ?
[21:10] <jtaylor> let me download a fresh iso and check if I can actually still reproduce it
[21:10] <slangasek> jtaylor: thanks very much
[21:10] <plars> jtaylor: and did it at least get to the popup asking if you wanted to unmount? or did you not even mount any of those before trying to continue the install? That bit seems to be mixed in the bug
[21:10] <jtaylor> I get it with nothing mounted
[21:11] <jtaylor> when I mounted the stuff I got the umount dialog
[21:11] <jtaylor> but still hang
[21:11] <plars> ok, some said they reproduced it by mounting one of the drives, I even tried doing that and holding a file open, but the unmount works fine for me
[21:23] <jtaylor> seems like I can still reproduce it
[21:24] <xnox> jtaylor: can you dd the whole hard-drive somewhere to preserve the reproducer? =))) is it a VM?
[21:24] <jtaylor> no its my regular system
[21:25] <xnox> jtaylor: is your main system 64 or 32 bit, how are you booting 64-bios/64-uefi/64-secureboot/32-bit images? via cd or usb?
[21:26] <jtaylor> 64 bit, I think msdos partition table, no uefi (to my knowledge) usb 64 bit image
[21:26] <xnox> jtaylor: what else is installed? are all partitions / filesystems clean and fsck reports nothing? Do you have obscure filesystems, left-over lvm metadata?
[21:28] <jtaylor> I didn't fsck them all in a long time
[21:28] <jtaylor> how do I check for leftover lvm metadata?
[21:31] <xnox> jtaylor: well vgscan -ay && vgs
[21:31] <xnox> and maybe it will print something.
[21:34] <jtaylor> no nothing
[21:35] <xnox> jtaylor: would you be able to follow this http://paste.ubuntu.com/5593864/ and collect /var/log/syslog & /var/log/partman
[21:36] <jtaylor> hm whenI opened gparted I got a message that it found a invalid gpt on sdb
[21:36] <xnox> jtaylor: that's ok. our cdimages have broken gpt table on them.
[21:37] <xnox> (known bug opened against cdimage)
[21:37] <xnox> bug 1062737
[21:37] <ubottu> bug 1062737 in libisofs (Ubuntu) "hybrid images do not include a valid GPT" [Medium,Triaged] https://launchpad.net/bugs/1062737
[21:45] <jtaylor> xnox: will starting ubiquity with --debug be enough?
[21:45] <jtaylor> not sure how I boot the image with debut-ubiquity
[21:46] <tonyyarusso> I take it the odds of a non-critical merge request being reviewed anytime until after the 25th are pretty much zilch, huh?
[21:46] <xnox> jtaylor: --debug & debug-ubiquity is the same.
[21:47] <xnox> tonyyarusso: depends on the bugs it fixes, if it's a leave package it can still get in. Or any bugs can go in as 0day SRU.
[21:48] <jtaylor> ok whats the best way to send you the logs?
[21:48] <jtaylor> paste.ubuntu?
[21:48] <xnox> jtaylor: paste.ubuntu.com is great =)
[21:48] <tonyyarusso> xnox: Not expecting it to get into this release at all frankly - just a question of whether anyone has time to review it.  It's a fairly trivial improvement to update-notifier.  (Attached to Bug #1167621)
[21:48] <ubottu> bug 1167621 in update-notifier (Ubuntu) "apt_check.py can't be used as a module" [Undecided,New] https://launchpad.net/bugs/1167621
[21:49] <xnox> tonyyarusso: there is apt/dpkg nagios plugin out of the box on debian & ubuntu systems that also works with icinga and check_mk.
[21:50] <xnox> tonyyarusso: or are you trying to improve it? also look into python-apt & aptdaemon both of which have api and provide middle & higher level apis.
[21:50] <jtaylor> xnox: syslog http://paste.ubuntu.com/5593912/
[21:50] <jtaylor> xnox: partman http://paste.ubuntu.com/5593917
[21:51] <tonyyarusso> xnox: Well, this started from finding a shortcoming in the nagios plugin stemming from a faulty assumption about the repository structure, then in the process of trying to figure out the best alternate approach found this.  :)
[21:51] <jtaylor> xnox: installer/debug  http://paste.ubuntu.com/5593919
[21:51] <xnox> Apr 22 21:44:38 ubuntu ubiquity: mount: unknown filesystem type 'LVM2_member'
[21:52] <jtaylor> anything else you need?
[21:52] <xnox> hmmm....
[21:52] <tonyyarusso> xnox: (The nagios plugin looks at whether a package came from -security, but -security gets mirrored to -updates, so after the first couple hours the security update detection breaks.)
[21:53] <xnox> also your ubiquity/d-i connection got lost, as there are loads of "Apr 22 21:42:01 ubuntu ubiquity: Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/Debconf/DbDriver/File.pm line 44." quite early on.
[21:54] <xnox> jtaylor: it would be better to have syslog with "/bin/partman" edited to have "set -x" as a second line and only go past prepare step in ubiquity after that is in-place.
[21:55] <jtaylor> k
[21:55] <xnox> tonyyarusso: better to use launchpad api for queriying that. But I see your point.
[21:56] <xnox> tonyyarusso: can you open a bug report against nagios / nagios-plugins saying that security updates check is broken?
[21:57] <jtaylor> xnox: syslog relevant part  http://paste.ubuntu.com/5593942
[21:58] <tonyyarusso> xnox: Sure - getting to that.  Figured I'd start with the more responsive upstream first.
[21:58] <jtaylor> I'll put -x in the initial thing too
[22:00] <tonyyarusso> xnox: Looks like someone beat me to it.  Bug #1031680
[22:00] <ubottu> bug 1031680 in nagios-plugins (Ubuntu) "check_apt always report 0 critical updates" [Medium,Triaged] https://launchpad.net/bugs/1031680
[22:01] <xnox> tonyyarusso: well, I can recommend to use landscape =) it reports critical updates correctly. But yeah, it's serious bug, I'll try to look into fixing it, thanks for flagging it up.
[22:02] <tonyyarusso> xnox: np :)
[22:04] <xnox> jtaylor: hmm... what comes after/before the last line in that syslog? can you compress and send all of it to me?
[22:06] <jtaylor> I'm just trying to track where ita ctually stops by adding -x everywhere ._.
[22:19] <jtaylor> it goes to hang on an infifo
[22:19] <jtaylor> but the problematic lvm partition seems to be my lvm-swap partition
[22:20] <jtaylor> I wonder if it works when I delete it
[22:21] <xnox> jtaylor: can you please
[22:21] <xnox> jtaylor: get me the tarball of /var/lib/partman/devices ?
[22:21] <xnox> as is right now?
[22:21] <jtaylor> before the echo or after?
[22:22] <jtaylor> the partition before it hangs is a ext4 partition with debian on it
[22:22] <jtaylor> could also be that one
[22:22] <xnox> jtaylor: shouldn't matter. Did echo cause it to progress by the say?
[22:22] <xnox> s/say/way/
[22:22] <jtaylor> the syslog progressed a bit
[22:22] <jtaylor> it hang on an cat in the outfifo
[22:23] <xnox> jtaylor: send the the syslog (hopefully timestamps should indicate when you echoed it"
[22:23] <xnox> jtaylor: and the /var/lib/partman/devices  (that's just the state of all connected hard-drives as viewed by the the installer)
[22:23] <jtaylor> after the echo it printed  -d lvm-root (precise) and now it hangs on a infifo
[22:24] <xnox> can you $ apt-get install pastebinit and pastebinit the whole thing?
[22:25] <xnox> (the thing being syslog =) )
[22:25] <jtaylor> its 12MB now :/
[22:25] <jtaylor> how can I reset it?
[22:26] <jtaylor> been restartint ubiquity a few times so there is lots of garbage in it
[22:27] <xnox> jtaylor: cat /var/log/syslog | gzip -9 > /tmp/syslog.gz
[22:27] <xnox> jtaylor: but then you need to mount somtething to copy it across, or like email to my-irc-nick @ubuntu.com
[22:27] <xnox> jtaylor: or run ubuntu-bug ubiquity
[22:27] <xnox> and see if that files a bug with the whole-lot =)
[22:28] <xnox> jtaylor: it should print a url which you can paste / copy /retype here. (upto the end of UUID) or pastebinit the url =)
[22:32] <jtaylor> I'm just trying a few things first
[22:33] <xnox> ok.
[22:37] <achernya> Hi -- I've been trying to find documentation on what sort of security support universe and multiverse are supposed to get. (I understand it's volunteer MOTUs and best-effort). Is it 3 or 5 years for LTS?
[22:39] <xnox> achernya: better contact security team at #ubuntu-hardened. But in general 0-security support is guaranteed, but security uploads on volunteer basis are accepted as long as -security pocket is open, which is 5 years for precise. So contributions are welcome.
[22:40] <xnox> for -universe and -multiverse that is.
[22:40] <jdstrand> achernya: tbh, it is up to the people doing the contributing. if the security team is given good, well tested patches, we'll sponsor them
[22:40] <xnox> achernya: main and restricted receive guaranteed 5 years LTS security support on precise.
[22:41] <achernya> xnonx, jdstrand: Thanks, that's what I expected.
[22:41] <jdstrand> in practice, people tend to not contribute to an older LTS. eg, people give us more patches for 12.04 than 10.04, but that isn't policy-- that is just what people tend to do
[22:46] <xnox> jtaylor: I'm off to sleep. If you have anything more posted to the bug report bug 1080701
[22:46] <ubottu> bug 1080701 in ubiquity (Ubuntu Raring) "After 'Preparing to install Ubuntu' screen, raring installation hangs" [Critical,Confirmed] https://launchpad.net/bugs/1080701
[23:43] <jtaylor> xnox: it hangs after closing 15reuse or 25replace, randomly, syslog: http://paste.ubuntu.com/5594150/
[23:44] <jtaylor> closing dialog in 15/25
[23:45] <jtaylor> as its random its possibly some kind of race
[23:45] <jtaylor> < offline back tomorrow evening