[02:25] <blkperl> infinity: you missed one s/saucy/trusty/ in the topic :)
[03:39] <dupingping> Hi
[03:39] <dupingping> whare is mterry?
[03:39] <dupingping> Now he is sleeping?
[03:53] <Unit193> henrix: Howdy.  Alive?
[09:20] <jtaylor> I guess we can't do srus yet as U isn't open?
[10:10] <xnox> jtaylor: sure we can.
[10:10] <jtaylor> doen't they need fixing in +1 first?
[10:11] <xnox> jtaylor: they do, but +1 isn't open yet. when it opens we copy trusty+trusty-updates into it.
[10:11] <xnox> jtaylor: we already have 10 or so packages in trusty-updates.
[10:11] <jtaylor> k thx
[10:12] <jtaylor> what about packages in -proposed when u opens?
[10:12] <xnox> jtaylor: follow normal sru process though in terms of version number, sru bug #, sru bug template with test case.
[10:12] <xnox> packages in -proposed (the non-sru ones) are moved to u-proposed and continue try to get into release pocket
[10:12] <jtaylor> oh right we have devel proposed now
[10:13] <xnox> well, devel-* are aliases..... so we still need a codename to open the series.
[12:01] <bigon> hi
[12:01] <bigon> https://bugs.launchpad.net/ubuntu/+source/selinux << shouldn't this pkg be dropped in ubunt?
[12:01] <bigon> ubuntu?
[12:04] <bigon> this pkg is ubuntu specific and I'm not sure it is still releavant
[13:12] <dupingping> seyon is what program?
[13:44] <xnox> bigon: not sure, ask #ubuntu-hardened people about it.
[13:45] <ncopa> hi
[13:45] <ncopa> since ubuntu LTS is 3.13, I assume that ubuntu will maintain the 3.13 kernel?
[13:45] <ncopa> any chence that ubuntu will do that via kernel.org?
[13:45] <ncopa> so kernel.org can announce 3.13 as longterm?
[14:24] <psusi> xnox, did the dmraid -> mdadm transition not get finished?  I've now seen at least two bugs where an isw array is still being activated by dmraid instead of mdadm and something is broken with it so the installer crashes
[14:28] <hallyn> i assume 'any' (i.e. python:any) works just fine in trusty/
[14:37] <xnox> hallyn: yes.
[14:37] <xnox> psusi: one can install using either dmraid or mdadm, and mount using either.
[14:37] <xnox> psusi: please point me to bugs.
[14:38] <hallyn> xnox: thanks
[14:38] <psusi> xnox, I just tagged them with "dmraid-transition"... I subscribed you to the first one a few days ago and asked if you had any thoughts on it
[14:38] <psusi> I thought the plan was for new installs to use mdadm, not dmraid?
[14:38] <psusi> you certainly must not try to activate it with both at the same time
[14:40] <xnox> psusi: that was the plan, however the way it's implemented the user is asked twice i believe (once to activate with mdadm and once to activate with dmraid) that's in d-i. I didn't test if the second prompt gets supressed if one chooses mdadm. I should retest that with trusty final.
[14:40] <xnox> psusi: right, i'll check my bug mail when i'll be back at work on tuesday.
[14:40] <psusi> xnox, you don't see those prompts in ubiquity though
[14:41] <xnox> psusi: correct. ubiquity has it's own raid activation script, which should still default to dmraid, i didn't switch that one.
[15:19] <hallyn> hi, if someone on sru team could approve the device-tree-compiler upload for precise-proposed, i could verify it today (but otherwise am out all next week)
[15:19] <stgraber> hallyn: let me take a look
[15:21] <stgraber> hallyn: bad version number
[15:21] <stgraber> hallyn: your upload has a version number higher than that of quantal
[15:21] <hallyn> did i really do that?
[15:22] <stgraber> precise is 1.3.0-2, quantal is 1.3.0-2build1, you uploaded 1.3.0-2ubuntu1
[15:22] <stgraber> trying to figure out what would be an appropriate version in this case though :)
[15:22] <hallyn> 1.3.0-2.12.04.1 ok?
[15:23] <hallyn> no, needs ubuntu, /me checks the security wiki page
[15:23] <stgraber> you'd usually use ubuntu0.1 but that'll still be higher than quantal
[15:23] <stgraber> actually, I guess I could just pretend I didn't see this and accept it, quantal is going EOL anyway
[15:24] <stgraber> so quantal users will have to upgrade to 13.10 at least by the time this hits -updates which will solve the problem
[15:25] <hallyn> or i can upload 1.3.0-2.12.04.ubuntu1
[15:25] <hallyn> not sure if the pkging would be happy with that placement of ubuntu
[15:25] <hallyn> or 1.3.0-2build1~12.04 :)
[15:26] <stgraber> nah, let's use the cleaner version and pretend quantal already doesn't exist anymore, way easier :)
[15:26] <hallyn> ok
[15:27] <stgraber> accepted into proposed
[15:27] <hallyn> technically we could just use the verbatim pkg from quantal
[15:27] <hallyn> it's a shame that didn't get sru'd when it originally hit quantal
[15:37] <jibel> bdmurray, wrt. bug 1309484 I think it's against because there are packages from xrog-edgers ppa and libglapi-mesa cannot be upgraded
[15:37] <jibel> s/against/again/
[15:47] <bdmurray> jibel: ah, thanks. I tested with unity8 and didn't recreate it.
[15:50] <jibel> bdmurray, I reviewed the upgrade reports today and clearly the winners are xorg-edgers PPA and cinnamon. I found only 1 real upgrader bug with non-ascii strings in srouces.list
[15:52] <bdmurray> jibel: I saw that and plan on having a look at it next
[15:52] <bdmurray> jibel: thanks for the help
[15:52] <jibel> yw
[15:59] <jibel> bdmurray, however bug 1309499 is a real one I think, in the transition to samba-libs in trusty
[16:03] <bdmurray> jibel: is that the same a bug 1308657?
[16:05] <jibel> bdmurray, I don't think so, because only the amd64 version is installed.
[16:07] <jibel> bdmurray, the problem is somewhere in http://paste.ubuntu.com/7276754/ libsmbclient-raw0 shouldn't be MarkKeep
[16:08] <bdmurray> jibel: can you view the aptclonesystemstate file?
[16:10] <xnox> stgraber: yeah cause 1.3.0-2build1~0ubuntu0.1 is way too ugly.
[16:10] <jibel> bdmurray, no it is corrupted
[16:11] <stgraber> xnox: yeah :)
[16:12] <bdmurray> jibel: did you see the end of main.log? 2014-04-18 14:16:58,385 DEBUG blacklist expr 'update-manager' matches 'update-manager'
[16:13] <bdmurray> 2014-04-18 14:16:58,385 DEBUG The package 'update-manager' is marked for removal but it's in the removal blacklist
[16:22] <jibel> bdmurray, yes it's because notification-daemon cannot be installed, but without the pre-upgrade status of the system it is difficult to find why
[16:35] <bdmurray> How does one restart libvirt or lxc?
[16:36] <stgraber> bdmurray: for libvirt you need to shutdown all the VMs, then restart libvirt-bin and then start them all up again (unless the change you want to apply doesn't affect the kvm instances in which case you can just restart the upstart job)
[16:37] <stgraber> bdmurray: for lxc, if all the containers are auto-started, "stop lxc && start lxc" will shut them all down and start them all again
[16:37] <stgraber> if you have containers which you manually started, then you'll need to manually stop and start them again
[16:38] <hallyn> is it ok for qemu in main to recommend ovmf which is in multiverse?  or does that need to be suggests?
[16:38] <hallyn> (it's a new recommends coming from debian)
[16:38] <stgraber> needs to be suggest, recommends will attempt to pull it in main
[16:39] <hallyn> ok, thx
[16:39] <hallyn> then lemme fix that in the debian git tree first
[16:41] <Quintasan> Hi, I'm trying to further debug https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1309611 any ideas what else I should provide?
[16:49] <hallyn> infinity: i'm finishing up the 2.0.0+dfsg-2ubuntu1 for trusty-proposed, fwiw.  pkg is just about ready, time to start testing.  letting you know as i'm not sure what schedules look like or how exactly how this will be handled
[16:53] <hallyn> http://paste.ubuntu.com/7277057/  the debdiff
[16:53] <hallyn> zul: ^
[16:54] <infinity> hallyn: It'll be handled like any other SRU, more or less, except I'll be a bit more slack about the feature/bugfix ratio.
[16:54] <infinity> hallyn: I do hope that diff is at least readable, though...
[16:54]  * infinity looks.
[16:55] <infinity> -Provides: ${sysprovides:arm}, ${sysprovides:arm64}
[16:56] <infinity> +Provides: ${sysprovides:arm}
[16:56] <infinity> That seems suspect.
[16:57] <hallyn> infinity: sysprovides:arm64 doesn't exist
[16:57] <hallyn> iiuc
[16:57] <hallyn> bc we moved all of arm64 into arm
[16:58] <infinity> hallyn: Okay.  So, my plan here will be to fairly carefully review the packaging changes to see if they're all sane, then baroadly review the upstream changes.
[16:59] <infinity> hallyn: An upstream ChangeLog would be nice (I don't see one, maybe a git log between rc1 and final would be nice to go over?)
[16:59] <hallyn> infinity: sure, where shoudl i put it?
[16:59] <infinity> hallyn: Not necessarily in the package, but perhaps tossed in whatever bug we close with this upload.
[16:59] <hallyn> infinity: fwiw i'm out all next week, so trying to finisih this up today as much as possible
[16:59] <hallyn> (else i'll hand over to , i dunno, zul :)
[17:00] <hallyn> ok, i'll post it to bug 1309452
[17:04] <hallyn> (posted the diff)
[17:04] <hallyn> hm, ihave a doubt
[17:04] <hallyn> oh nm
[17:59] <hallyn> build went fine, running qrt
[18:15] <kenvandine> @pilot in
[18:41] <hallyn> infinity: checks all pass, so unless you have comments, i'll push?
[18:42] <infinity> hallyn: I haven't had the time to have comments.
[18:42] <infinity> hallyn: (As in, I haven't been looking at it at all since you first brought it up)
[18:43] <hallyn> that's how i read it :)
[18:43] <infinity> hallyn: But if you want to push it at the queue, I guess I can reject if I have comments. :P
[18:43] <hallyn> infinity: that sounds, thanks.  hopefully in that case rharper will pick it up and address the comments
[18:44] <hallyn> i'm also sort of hoping it fixes win7 on smp, but we'll have to see
[19:16] <Logan_> infinity: I just set up an ifttt recipe to text me if sabdfl adds a new post to his blog :P
[19:21] <infinity> Logan_: Hah.
[21:13] <kenvandine> @pilot out