[01:26] <cyphermox> flexiondotorg: I was having dinner by the time you pinged, and carried on to watch tv. it is for ubuntu-mate-settings?
[01:26] <cyphermox> I can review that now if it's been adjusted to follow some of the recommendations
[04:21] <ScottK> doko__: It didn't work on all architectures.
[04:22] <ScottK> Upstream only supports the functionality that needs LLVM on some archs.
[06:25] <pitti> Good morning
[06:25] <pitti> sbeattie: no, powerd was just right; I proposed a fix for that weeks ago already, but I just uploaded it last night; I restarted the system-settings-o-a test
[06:26] <pitti> sbeattie: systemd tests> I'm on them, yesterday it was due some changes in autopkgtest
[06:27] <pitti> doko__: beanstalkd> queueing, will fix
[06:29] <pitti> sbeattie: and here it's green again
[06:31] <sbeattie> pitti: awesome, thanks for digging in to it.
[06:39] <pitti> Launchpad where are thou?
[06:40] <pitti> ah, it's back
[06:55] <pitti> infinity: as slangasek didn't get around to it, do you have an opinion on bug 1427654?
[06:55] <pitti> if we do it, I'd rather do it earlier than later, and not on a Friday
[07:08] <pitti> cyphermox: fixed NM's autopkgtest FYI
[07:13] <tjaalton> pitti: nfs-utils is fixed now? whee
[07:13] <pitti> tjaalton: well, I just uploaded it
[07:13] <tjaalton> i need to set up kerberized nfs pronto then :)
[07:13] <pitti> and I need another followup upload to fix an important issue and add an autopkgtest
[07:14] <tjaalton> still
[07:15] <pitti> tjaalton: testing with krb is very much appreciated, I didn't do that
[07:15] <tjaalton> yeah, need to fix mount options to use that, otherwise things should be set here..
[07:31] <pitti> sbeattie: ah, the remaining failure is that /var/log/syslog (and all other rsyslog files) ceased to exist
[07:32] <pitti> sbeattie: looking into that now, not sure if the latest cloud-inits do something funky there
[07:40] <pitti> smoser`, Odd_Bloke: I just filed bug 1428495; cloud images broke ssh?
[08:01] <dholbach> good morning
[08:15] <SpamapS> jamespage: Hi, any chance you or robie are working on an upload of MySQL 5.5.42 to vivid?
[08:16] <pitti> I thought 5.5 was slated to die, as soon as 5.6 actually makes it into vivid?
[08:16] <pitti> (it's been stuck in -proposed on some uninstallability for weeks)
[08:34] <SpamapS> pitti: ah that would explain 5.5.42 not having been uploaded.
[08:34] <pitti> rbasak: what's the status of landing 5.6, OOI?
[08:35] <pitti> according to http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt it sitll makes the percona-* bits uninstallable?
[08:36] <SpamapS> Yeah I believe 5.6 introduces the idea of the mysql-commmon package becoming fork-specific.
[08:36] <SpamapS> So percona server might have to figure that out. :-P
[08:37]  * SpamapS recedes back into the shadows
[09:42] <jamespage> SpamapS, pitti: rbasak is technically on holiday this week - I'll take a look and see
[09:42] <pitti> jamespage: oh, then he'll be on holiday practically too :)
[09:42] <pitti> "hopefully"
[09:43] <pitti> jamespage: thanks
[09:43] <jamespage> SpamapS, ah yes I remember - the galera bits for percona ftbfs on a number of archs - georgelorch is working on that
[09:43] <jamespage> pitti, he's been around still
[09:43] <pitti> there, an autopkgtest for NFS
[10:01] <doko> xnox, do you have a new boost package?
[10:02] <xnox> doko: no =) i can do that on a my buildbot at home, but it's not on at the moment and cannot power it on remotely.
[10:03] <xnox> doko: you wanna open new series with 1.57? I can prepare that.
[10:06] <doko> xnox, yeah, I think opening with 1.57 makes sense, or maybe 1.58. and I want to upload it to my test rebuild ppa too
[10:12] <xnox> doko: ack.
[10:15] <xnox> doko: right, i'm not sure when 1.58 will be ready. It's "4 weeks late" cause it should have been first monday in february... i'm guessing it should be last monday in april now e.g. april 27th
[10:15] <xnox> doko: i think i should prepare 1.57 and if 1.58 is release before open upgrade to that.
[10:41] <sitter> didrocks: hey, any progress on bluez5?
[10:41] <didrocks> sitter: unfortunately, still blocked on touch kernel enablement
[10:42] <sitter> didrocks: still planned this cycle though?
[10:42] <didrocks> sitter: hopefully, I can't ensure you though that it will be ready or that the FFe will be accepted :/
[10:43] <ogra_> sitter, it is planned soon ... once we branched off the phone stuff into the production tree again bluez5 is free to land for desktop
[10:44] <sitter> ok. not landing bluez5 means we have no bluetooth gui in kubuntu so that has me quite a bit worried :/
[10:59] <Saviq> lool, hey, are you landing vivid silo 22 any time soon?
[11:03] <pitti> doko: FYI, beanstalkd fixed, patch sent to debian bug 779831
[11:05] <Odd_Bloke> pitti: Hm, that sounds like snappy behaviour bleeding in to the normal world; I'll let smoser` chime in as I wasn't particularly involved with the snappy cloud-init changes.
[11:06] <didrocks> Saviq: I guess he is at mwc
[11:06] <pitti> Odd_Bloke: ah, so ssh is supposed to still stay enabled? (that would make a lot of sense, given that it's your only foot into the door on clouds :) )
[11:06] <Saviq> didrocks, right, and the silo is there since Jan, so unlikely to land ;)
[11:06] <didrocks> Saviq: I saw his shadows on some photos :)
[11:07] <Odd_Bloke> pitti: Yeah, disabling SSH would be just a little user-hostile. ;)
[11:18] <Odd_Bloke> pitti: Oh, in fact, cloud-init 0.7.7~bzr1076-0ubuntu1 merged snappy support in so that will definitely be the problem.
[11:36] <flexiondotorg_> Anyone here who could do some sponsor for package updates in Ubuntu MATE please?
[13:07] <infinity> pitti: My opinion is "yes, we should do it" and agreed that it should be a Monday, so we have time to deal with fallout and/or revert.
[13:08] <infinity> pitti: I'll look at the bug when I'm not completely messed up, sleep-wise. :/
[13:35] <infinity> pitti: Also, was quite happy to see no pushback from guillem on the .dsc addition.  Just a bit of bikeshedding, then we can go JFDI the implementation.
[13:48] <pitti> infinity: right, he generally seemed happy about it
[13:48] <pitti> infinity: ack, so Monday it will be
[13:49] <pitti> infinity: so I could write the u-d-a@ warning about that now, if we'll do it?
[13:49] <pitti> to get the warning out a bit ahead of time
[13:59] <siretart> doko: I see that you already uploaded a fixed package, thanks. with "upstream support" I guess you mean aarch64?
[13:59] <infinity> pitti: Bug commented on.
[14:00] <pitti> infinity: ack, thanks; I'll send the warning then and prepare the two uploads
[14:00] <pitti> doesn't help that much that I'll be on vac 1.5 weeks from March 16 on, but we have a full week, and I have didrocks as my deputy :)
[14:01] <siretart> doko: looking at the upstream git, yes, it seems that there are in fact a number of aarch64 optimizations applied. I'll work on a new snapshot for experimental and sync it to vivid. thanks for pointing this out to me
[14:02] <infinity> pitti: A week should be more than enough to determine if it's completely effed up.
[14:02] <pitti> infinity: right, and a lot of people are running it already anyway
[14:02] <infinity> pitti: Rough edges that need filing off may take more time, but should generally be less urgent.
[14:03] <pitti> also, it's one small upload to switch back
[14:03] <pitti> heh, /me saw lots of those rough edges
[14:05] <cjwatson> juju still doesn't support it; it might be worth mentioning that.
[14:06] <cjwatson> (it's in progress, but not done)
[14:06] <pitti> right, same wit maas
[14:07] <cjwatson> I don't know whether juju on a systemd host with trusty lxc containers using upstart works.
[14:35] <smoser`> Odd_Bloke, not intended. we will fix. its easy to user-data turn it back.
[14:36] <smoser`> sorry. i rushed that change in :(
[14:55] <smoser> pitti, did you file a bug ?
[14:58] <pitti> smoser: yes, bug 1428495
[14:58] <pitti> smoser: Odd_Bloke said that disabling ssh by default isn't even intended (which makes sense as it's the only way to talk to a cloud instance really..)
[14:59] <smoser> pitti, thnaks.
[15:01] <flexiondotorg_> Anyone here who could do some sponsor for package updates in Ubuntu MATE please?
[15:02] <Laney> Can't you put them in the queue?
[16:19] <bluesabre> not sure what icon transmission is expecting on first run, but it is missing in adwaita, humanity, elemenary-xfce... http://i.imgur.com/g3SmBwM.png
[16:29] <lfrlucas> Hi. Why some package versions are so old in recent ubuntu versions. E.g. Why is ubuntu using polkit-0.105 ? A newer version 0.112  is out
[16:30] <mlankhorst> in general nobody packaged it yet :)
[16:31] <lfrlucas> hmmm
[16:32] <mitya57> I think pitti packaged it for Debian experimental.
[16:34] <lfrlucas> Recently I filled a bug on policykit and fixed version 0.105 with their last commit: https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/1417637 . It was already released on vivid. It wouldn't be better to upgrade policykit to latest version instead of creating additional patches on ubuntu packages?
[16:34] <mitya57> Or, rather, other pkg-gnome members (pitti did only the last upload). And it is there for a long time, parallel with 0.105 in unstable.
[16:37] <Laney> bluesabre: good question, looks like a gtk bug?
[16:37] <Laney> same in utopic afaics - those dialogs aren't supposed to have an icon
[16:38] <pitti> lfrlucas, mitya57: mostly because I really really hate the javascript based policies; this is nuts
[16:38] <pitti> so we essentially kept it at the old declarative text file policies
[16:41] <rbasak> SpamapS, jamespage, pitti: 5.6 is blocked on percona-xtradb-cluster-5.6, which is blocked on percona-galera-3 FTBFS on non-Intel architectures. Percona are looking into it.
[16:41] <rbasak> (it's all in vivid-proposed)
[16:41] <jamespage> rbasak, thanks for confirming - that's what I thought
[16:42] <mitya57> pitti, thanks, that explains it
[16:43] <lfrlucas> pitti: Ok. Now I understand .
[16:43] <pitti> besides, it's not like polkit would still be alive upstream, it's in low-maintenance mode
[16:44] <pitti> thus having 105 or 112 doesn't matter much in terms of maintainability
[16:44] <pitti> I'm sure one of these days systemd will suck this in :)
[16:44] <mitya57> :)
[16:49] <flexiondotorg_> Laney, they are in the queue :)
[17:01] <pitti> flexiondotorg_: I'm patch piloting tomorrow, I'll have a look
[17:01] <pitti> (meeting now, then EOD)
[17:52] <bdmurray> shadeslayer: could you please update bug 1375786 with SRU information?
[18:02] <flexiondotorg_> pitti, Thanks.
[18:21] <cmagina> i want to propose a change for the trusty systemd package. i thought i should propose it against the bzr branch, however, there does not appear to be a branch for the trusty-updates version of systemd
[18:28] <strikov> cmagina: i'm not an expert, so this opinion might be completely wrong. How about looking for latest .dsc for systemd package in trusty (you may look at one in -proposed); dget it; do changes; debuild -S and debdiff; open bug against the package and attach debdiff to it;
[18:29] <strikov> cmagina: That's the .dsc you probably want: https://launchpad.net/ubuntu/+archive/primary/+files/systemd_204-5ubuntu20.11.dsc That's for package in -proposed
[18:33] <cmagina> strikov: yeah, i know that method, just figured the bzr branch would be the appropriate way. thanks though
[18:33] <mitya57> Mirv, will you include the one-line fix for bug 1426942 in your 5.4.1 packages?
[18:34] <mitya57> http://code.qt.io/cgit/qt/qtbase.git/commit?id=ef22739f47857c18
[18:34] <tjaalton> is there a tag for systemd-as-init related bugs?
[18:34] <strikov> cmagina: in case of one of my packages, changes in -security and -proposed were not transferred to bzr branch
[18:34] <strikov> cmagina,
[18:35] <tjaalton> "systemctl stop apache2.service; systemctl start apache2" fails
[18:35] <strikov> cmagina: it means that i was not able to do correct update via bzr, only manual method
[18:35] <cmagina> strikov: ah, interesting, so there are no bzr branchs kept for all changes made post-release then?
[18:36] <cmagina> strikov: i'll just use the dsc method, thnaks
[18:36] <strikov> cmagina: i don't know for sure, that was indeed so for squid3
[18:36] <cmagina> thanks even
[18:36] <strikov> cmagina: you know about sru and friends, right?
[18:37] <mitya57> pitti: please look at tjaalton's question above (if you are still here)
[18:38] <tarpman> cmagina: maybe check http://package-import.ubuntu.com/status/ for systemd
[18:39] <tjaalton> mitya57: I'll file a bug
[18:39] <cmagina> strikov: what do you mean by sru and friends?
[18:39] <tjaalton> I've seen this with debian too, when testing freeipa.. the installer does exactly that after configuring the service
[18:40] <strikov> cmagina: trusty is stable release and you need to file SRU request for it: https://wiki.ubuntu.com/StableReleaseUpdates
[18:40] <mitya57> tjaalton, if you think it's a blocker, please comment on the FFe
[18:40] <tjaalton> it should be fixable, just don't know how :)
[18:41] <tjaalton> stop exits too early
[18:41] <strikov> cmagina: basically prove that your change is indeed required i.e. can add more profit than pain
[18:41] <cmagina> strikov: yes, i know that, do it often enough these days for the kernel :)
[18:41] <strikov> cmagina: heh, lucky you :)
[18:41] <cmagina> strikov: the new part for me is this being a package versus the kernel
[18:41] <dobey> cmagina: lp:ubuntu/trusty-proposed/systemd is probably the branch to base on
[18:41] <dobey> assuming it didn't have an import failure
[18:43] <cmagina> dobey: i would, except that tracks the utopic branch
[18:44] <cmagina> there was a change made to the trusty-updates package i want to extend, but that change does not appear in any systemd branch
[18:44] <dobey> cmagina: no it doesn't
[18:45] <dobey> cmagina: there is a change in -proposed which is not yet in -updates; your changes will have to go through -proposed first, so if -proposed exists, it is generally the thing you should base your chagnes off of
[18:45] <cmagina> dobey: what does "stacked on" mean for bzr then? the trusty-proposed branch lists stacked on utopic
[18:46] <cmagina> dobey: that makes sense, but i have a problem with that branch, it lacks the changes i am trying to extend
[18:46] <dobey> cmagina: the utopic branch is the "current stable release"
[18:47] <dobey> cmagina: the stacking in launchpad is a bit weird sometimes, you can probably just ignore that; you'll need to propose your changes into the trusty-proposed branch/pocket anyway
[18:47] <dobey> cmagina: however, the lp branch seems to be out of date
[18:48] <dobey> cmagina: so you'll need to grab the sources from the trusty-proposed pocket using the dsc that strikov linked to
[18:48] <cmagina> dobey: yeah, that does seem to be the issue
[18:49] <cmagina> dobey: yeah, that is what i was planning on doing. just attach the debdiff to the sru bug
[18:53] <cmagina> dobey: thanks for the help
[18:53] <dobey> no problem :)
[20:05] <rlaager> I'm testing systemd in vivid with an eye toward making sure that root-on-ZFS will still work (at least as well as it did pre-systemd). It was suggested to me by someone with a lot of systemd-on-Fedora experience that cron.service should Wants=local-fs.target (possibly by some implicit mechanism). I'm not seeing that dependency. As a result, cron is starting before /var/spool is mounted. Likewise
[20:05] <rlaager> for atd. Postfix has the same issue with /var/spool. I'm new to systemd. Any thoughts?
[20:07] <sarnold> hey rlaager :)
[20:12] <sarnold> rlaager: you may find some information on https://wiki.ubuntu.com/SystemdForUpstartUsers -- you may need to talk with pitti, I believe he's done much of the systemd work so far; he's typically on "very early" european time
[20:12] <rlaager> sarnold: Yeah, I've read that whole thing a couple times. I'm still not sure if this is a bug in cron.service or not.
[20:13] <sarnold> rlaager: it -feels- like a bug, the way you defscribed it...
[20:13] <rlaager> I suppose if I could reproduce this with a separate ext4 filesystem mounted at /var/spool, everyone would agree it's a bug.
[20:14] <rlaager> Is vivid expected to ship with systemd by default, or not, or has that not been decided yet?
[20:14] <sarnold> rlaager: I believe the plan is for vivid to ship with systemd barring something surprising...
[20:25] <ScottK> rlaager and sarnold: the plan is to switch to systemd default on Monday.
[23:47] <shadeslayer> bdmurray: will do
[23:51] <bdmurray> shadeslayer: thanks