[04:20] <mwhudson> is there a x86_64-apple-darwin binutils hiding in the archive somewhere?
[06:55] <dholbach> good morning
[08:20] <pitti> Good morning
[09:00] <pitti> rbasak: what's the status of juju 1.23 for vivid? ISTR that last week you were about two packaging bugs away from it, right?
[09:00] <pitti> rbasak: it's universe and not on any images, so we could potentially land it on Wed even, or SRU it too without much damange either
[09:01] <rbasak> pitti: there have been some regressions found in the current 1.23 beta, so upstream are holding the release right now and we don't want to upload it.
[09:02] <pitti> rbasak: ack, thanks; so I'll move the milestone of bug 1409639
[09:02] <ubottu> bug 1409639 in juju-core (Ubuntu Vivid) "juju needs to support systemd for >= vivid" [High,In progress] https://launchpad.net/bugs/1409639
[09:02] <rbasak> pitti: upstream are pulling some new 1.23 features into a feature flag which should eliminate the regressions. But that means that 1.23 may need to land in an SRU.
[09:02] <pitti> it's got a MRE, so shouldn't pose any problem
[09:03] <rbasak> pitti: we're waiting on upstream who are working on resolving this at the moment.
[09:03] <rbasak> Ack.
[09:03] <pitti> rbasak: right; there's little pressure here, I just want to sanitize the 15.04 milestone so that we have something sensible to work against
[09:03] <pitti> rbasak: thanks for confirming!
[09:05] <pitti> Riddell: hey Jonathan, how are you?
[09:06] <pitti> Riddell: do you still want to land bug 1372920 for vivid? if so, now is the time :)
[09:06] <ubottu> bug 1372920 in kipi-plugins (Ubuntu Vivid) "kipi-plugins should depend on libkqoauth" [Undecided,Fix committed] https://launchpad.net/bugs/1372920
[09:06] <pitti> apw: I suppose there won't be another kernel upload for vivid final, so should bug 1439706 be moved to vivid-updates, or to w-series?
[09:06] <ubottu> bug 1439706 in linux (Ubuntu) "FFE: Ubuntu FAN networking support (for linux, iproute2 and ubuntu-fan)" [High,Fix committed] https://launchpad.net/bugs/1439706
[09:11] <pitti> jdstrand: do you still want to remove the aa-easyprof workaroud for vivid final in bug 1378823 ?
[09:11] <ubottu> bug 1378823 in apparmor-easyprof-ubuntu (Ubuntu) "apparmor denial for bind on name="org.freedesktop.Application"" [Low,Triaged] https://launchpad.net/bugs/1378823
[09:12] <pitti> jdstrand: if so, please upload it today
[09:35] <rbasak> Can seeds do alternatives?
[09:36] <ogra_> alternatives are a postinst thing ...
[09:36] <rbasak> "ubuntu-minimal lists ntpdate as a dependency, such that ubuntu-minimal is uninstalled if you try to replace ntpdate with ntpd."
[09:36] <rbasak> ogra_: I mean Depends: a | b
[09:37] <infinity> rbasak: ntpdate and ntp don't conflict...
[09:37] <rbasak> As in "sbuild --resolve-alternatives"
[09:37] <rbasak> infinity: I hadn't noted that. Thanks.
[09:37] <infinity> rbasak: It's perfectly reaonable (and, IMO, correct) to have both installed.
[09:38] <rbasak> I've just seen https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/583994 and am thinking about how that might influence my plans to make ntpd default on (at least) server.
[09:38] <ubottu> Launchpad bug 583994 in ubuntu-meta (Ubuntu) "Consider replacing ntpdate calls by 'ntpd -g'" [Medium,Triaged]
[09:38] <infinity> rbasak: ntpdate on boot for a (potentially large) jump to mostly correct, and ntpd to fix jitter.
[09:38] <rbasak> With ntpdate deprecated, we should be calling ntpd only in either "keep running" or "fix once and stop" mode, with an optional "big jumps are OK" flag.
[09:38] <ogra_> i thought we'd switch to systemds timesyncd anyway
[09:39] <infinity> ogra_: Ick.
[09:39] <infinity> rbasak: So, yeah, if ntpdate is going away, I'd argue that it should just depend on ntp and still have init scripts that invoke the ntpd one-shot behaviour.
[09:39] <ogra_> infinity, well, i think it is default in snappy already ...
[09:40] <rbasak> When I last looked, I saw no justification for timesyncd existing at all. The only documentation was the check in.
[09:40] <infinity> ogra_: That's nice.
[09:40] <ogra_> and i doubt we want to maintainh both long term
[09:40] <infinity> ogra_: "It's the default in snappy" doesn't inform my server decisions much. :P
[09:40] <infinity> ogra_: We're never getting rid of ntpd, because people actually need ntp servers.
[09:40] <ogra_> oh, sure, but we'll likely get rid of ntpdate in if-up.d
[09:41] <infinity> ogra_: *shrug*
[09:41] <rbasak> If we want to move away from ntpd by default, I'd really like to see an actual justification of why the alternative is better. "systemd does it" is not enough for me.
[09:41] <ogra_> i'm only talking abouot the client side here
[09:41] <infinity> ogra_: The "maintaining both" argument should treat tinesyncd as the "extra" copy here, not ntpd.
[09:41] <rbasak> I also don't want to delay ntp by default on server because some people want timesyncd with no real technical justification.
[09:41] <infinity> rbasak: timesyncd is arguably a slightly better (as in faster) one-shot client, but we need ntpd regardless, so meh.
[09:42] <rbasak> Oh - it's one-shot only?
[09:42] <infinity> Oh, it might also do ongoing client fun, not sure.
[09:42] <infinity> But it's not ntpd, as in it can't act as a stratum server.
[09:42] <ogra_> rbasak, being the default of our now chosen init system isnt enough technical justification ... or "we get it for free anyway" isnt either ?
[09:42] <infinity> So, ntpd won't die.
[09:43] <infinity> ogra_: No, neither of those is a valid argument.
[09:43] <infinity> ogra_: It also needs to not be crap.
[09:43] <rbasak> ogra_: AIUI, the whole decision in Debian that made systemd the default deliberately did not pull the world of systemd in with it.
[09:43] <infinity> ogra_: We're not using networkd either.
[09:43] <rbasak> ogra_: it was an "init system only" discussion.
[09:43] <infinity> ogra_: Just because it's in the systemd source tree doesn't mean we should use it.
[09:43] <rbasak> ogra_: so in my mind if we're going to pull other components in, they need an independent justification.
[09:44] <ogra_> rbasak, oh, indeed it didnt pull the world with it ... but it will be a lot harder to stay diverged and do our own thing
[09:44] <infinity> We're not "diverged".
[09:44] <infinity> ntpd is not going away.  Period.
[09:44] <ogra_> i'm still talking about ntpdate :)
[09:44] <infinity> So, it's a question between maintaining two things, or maintaining just one and turning off timesyncd.
[09:44] <infinity> ogra_: ntpdate == ntpd, going forward.
[09:45] <infinity> Which is what the bug is about.
[09:45] <infinity> rbasak: Though, to be fair, a 5-year old bug claiming ntpdate is going away upstream is a bit hard to believe when it's still not happened...
[09:46] <pitti> rbasak, ogra_: FTR, timesyncd was requested by snappy, to have a small and unintrusive ntp thingy
[09:46] <rbasak> infinity: well, the new functionality exists already. So if we're going to overhaul things, we should probably use it.
[09:46] <pitti> but it will not start if ntpd (or friends) are installed
[09:46] <rbasak> infinity: for ntpd by default on server, do I want ntpdate + ntpd, or just ntpd?
[09:46] <rbasak> I presume just ntpd?
[09:47] <rbasak> Maybe start with the -g option to allow large time steps.
[09:47] <infinity> rbasak: Well, you need a clean migration path anyway.
[09:47] <infinity> rbasak: So, empty out ntpdate, make it depend on ntp, and make the ifup/etc hooks call it in one-shot-and-large-skew mode.
[09:47] <infinity> rbasak: That seems sensible to me, ish.
[09:47] <rbasak> infinity: right
[09:47] <infinity> rbasak: Ideally, with coordination with the Debian ntp maintainer(s), so we don't end up with a messy delta of doom.
[09:48] <rbasak> Yep
[09:49] <rbasak> I'm not sure if I can call one-shot-and-large-skew mode if ntpd (daemon) is already running.
[09:49] <rbasak> Maybe I can kick it though. The hooks could be clever about which to do.
[09:49] <infinity> rbasak: ntp has a few more deps, but nothing that looks crazy for places where you wanted ntpdate installed anyway.
[09:49] <pitti> infinity, rbasak: so FTR, I wouldn't mind if we dropped ntpdate from the seeds entirely, at least not for desktop
[09:49] <rbasak> pitti: what, in favour of timesyncd?
[09:50] <pitti> rbasak: WFM
[09:50] <pitti> that one is just fine for snappy and desktop
[09:50] <rbasak> I wonder what server users would want.
[09:50] <infinity> rbasak: The current hook already stops ntp, runs ntpdate, and starts ntp.  Not sure if that's actually correct, though.
[09:50] <pitti> servers might want some more elaborate one like ntpd, of course
[09:50] <infinity> rbasak: Since ntpd in non-skew mode will just exit hard, it's fair to assume that if it's running, the time is correct.
[09:50] <rbasak> If they're serving time, sure.
[09:50] <pitti> and that's fine, timesyncd will not run then
[09:51] <rbasak> If they're just consuming time, do server users want to use ntpd or timesyncd?
[09:52] <infinity> rbasak: Depends on how well timesyncd deals with jitter, or if it's coarse-grained, like ntpdate.
[09:52] <infinity> rbasak: Server users want precise time (especially NFS users), so whatever will give them that is "good enough".
[09:53] <pitti> infinity: timesyncd adapts the update cycles according to the current drift
[09:54] <pitti> infinity: i. e. it starts with waking up often (every 30s) and then depending on how good/bad your clock is it exponentially reduces the wakeups
[09:54] <pitti> and it listens to net device up events, so if it never ran it does ntp on up'ing an interface, similar to ifup.d/ntpdate
[09:55] <rbasak> That's useful, thanks.
[09:55] <rbasak> Especially as I can't find this stuff documented anywhere/
=== hyperair is now known as m4
=== m4 is now known as hyperair
[11:10] <didrocks> mvo: hey! We have a small question from the desktop sprint: let's imagine we want to install ubuntu-core with snappy on a laptop for testing purpose (or on an usb drive), is there any doc for this?
[11:10] <ogra_> iirc there were discussions on the snappy-devel ML
[11:11] <ogra_> (about that topic)
[11:12] <seb128> ogra_, didrocks, https://lists.ubuntu.com/archives/snappy-devel/2015-March/000375.html ?
[11:12] <ogra_> yeah
[11:12] <ogra_> (there was also another one "running snappy on bare metal" or so)
[11:13] <didrocks> thanks!
[11:13] <ogra_> https://lists.ubuntu.com/archives/snappy-devel/2015-March/000378.html is the key though
[11:15] <seb128> didrocks, http://www.ubuntu.com/things says
[11:15] <seb128> wget http://cdimage.ubuntu.com/ubuntu-core/releases/alpha-3/ubuntu-core-WEBDM-alpha-03_armhf-bbb.img.xz
[11:15] <seb128> unxz -c ubuntu-core-WEBDM-alpha-03_armhf-bbb.img.xz | dd of=/dev/sdX bs=32M
[11:15] <seb128> sync
[11:16] <ogra_> probably not with the armhf beaglebone image though :)
=== MacSlow is now known as MacSlow|lunch
=== MacSlow|lunch is now known as MacSlow
=== plars is now known as plars-
[13:22] <rbasak> diwic: seb128 suggests that I mention bug 1445358? Sounds like it should be release critical to me.
[13:22] <ubottu> bug 1445358 in pulseaudio (Ubuntu) "Pulseaudio fails to run when system's language is in certain non-English locales" [High,Confirmed] https://launchpad.net/bugs/1445358
[13:22] <diwic> rbasak, ok, looking
[13:22] <rbasak> Thanks.
[13:22] <rbasak> Looks like a fairly trivial and not-too-impactful fix if it's valid.
=== Anupkumar is now known as d3v1l
=== d3v1l is now known as Anupkumar
[13:50] <diwic> rbasak, it's valid. Question is if I should try to upload something, or wait for an SRU
[13:52] <Anupkumar> hi, I am working on a bug related to udisks, can anyone tell me is it a right place to ask questions related to bugs on udisks here?
=== Anupkumar is now known as Anup
=== Anup is now known as Anupkumar
[13:56] <shadeslayer> slangasek: ping
[13:57] <shadeslayer> slangasek: Could you help me with the skype package? I'm trying to recompile it, but it doesn't seem to want to spit out skype-bin
=== pgraner-afk is now known as pgraner
[14:12] <rbasak> diwic: I think there's still time to upload a fix. Check in #ubuntu-release though.
[14:12] <diwic> yup. Already there
[14:14] <rbasak> Oh yes, sorry. Just got back to my screen and I looked at the highlighted channels first.
[14:17] <shadeslayer> slangasek: nvm
[15:52] <Ionic> I'm setting "{debupstream}-0~{revno}" as the debian version... should that be automatically expanded?
[15:52] <Ionic> if yes, it doesn't do that for vivid, leading to build failures
[15:52] <Ionic> (older versions are working fine)
[15:55] <Ionic> or maybe that was very old news
[15:56] <Ionic> yeah I guess... nevermind, sorry
[15:56] <Ionic> 2012
[15:57] <Ionic> likely some layer 8 error back then
[16:01]  * infinity glares at rbasak for moving files and making him hand-compare the diffs.
[16:02] <rbasak> Sorry
[16:02] <rbasak> I moved it because it needed renaming anyway to work with dh_install
[16:02] <rbasak> Without having to use dh-exec
[16:03] <infinity> rbasak: Yeah, I understand the rationale, just sucks to review.  I'll quit whining. :P
[16:03] <rbasak> Oh, OK :)
[16:03] <infinity> patchutils needs a utility to check if -file1/+file2 are identical.
[16:03] <rbasak> git's rename detection is very good
[16:04] <rbasak> Then the diff output shows the changes across the rename, which is nice.
[16:05] <infinity> rbasak: Hah.  And they're not the same.
[16:05] <rbasak> +  * d/additions/source_mysql-5.6.py: attach new configuration files and
[16:05] <infinity> Ahh, and the changelog notes that.
[16:05] <rbasak> +  * directories.
[16:05] <infinity> Right.
[16:05] <rbasak> Apart from extra *. Whoops.
[16:06] <rbasak> I noted that we get an apport hook error if for example /etc/mysql/mysql.conf.d/ is deleted. But I think that's OK for now at least, since that error will appear in the apport report and the triager will know something's up.
[16:07] <rbasak> It certainly makes things no worse from previous, since users could still delete all of /etc/mysql.
[16:07] <rbasak> This kind of thing seems to be more common than I might've expected.
[16:07] <infinity> rbasak: Yeah, checking for existence of the bits before attempting to list-and-attach would be nice.
[16:08] <rbasak> One day I'll overhaul the whole thing.
[16:08] <infinity> rbasak: Especially for optional things, which .d dirs are.
[16:08] <rbasak> For now I just wanted to get something, which is infinitely better than nothing.
[16:08] <infinity> rbasak: But yeah, it was equally broken before, so this isn't a regression, per se.
[16:41] <pitti> wgrant: bug 1436937
[16:41] <ubottu> bug 1436937 in ubiquity (Ubuntu Vivid) "Temporary OEM user not removed after end user setup" [High,Triaged] https://launchpad.net/bugs/1436937
[17:30] <wgrant> jibel: https://launchpad.net/~wgrant/+archive/ubuntu/experimental/+build/7343935
[17:36] <jibel> wgrant, verification passed :)
[17:50] <wgrant> hallyn_: What's the status of the subuid patches for shadow? The above bug is in fact dodgy error handling in our version of them, so I'm wondering if there's somewhere I should be submitting the fix.
[17:59] <stgraber> wgrant: it's a bit of a mess IIRC. Eric wrote the patches for us, we were the first to carry them as distro patches, then they got included upstream (https://github.com/shadow-maint/shadow), we did a few more fixes on our side which Debian picked up later and may have now gotten upstream.
[18:07] <wgrant> stgraber: Ah, indeed, broken upstream as well AFAICS. Will try to reproduce on that and submit upstream.
[18:26] <hallyn_> what's broken upsream?
[18:26] <hallyn_> stgraber: all fixes should be upstream.
[18:27] <stgraber> hallyn_: bug 1436937
[18:27] <ubottu> bug 1436937 in shadow (Ubuntu Vivid) "Temporary OEM user not removed after end user setup" [High,Fix committed] https://launchpad.net/bugs/1436937
[18:28] <stgraber> hallyn_: did upstream also switch to 65536 uid and gid by default for non-system users? I believe that change was a bit controversial when I made it and I got push back from Debian about taking that. Haven't checked the state of things in Debian + upstream recently though.
=== rickspencer3_ is now known as rickspencer3
[18:32] <hallyn_> stgraber: i don't see tha tin git log, it's probably still ubuntu delta, might stay that way.  THough if you send a github pull request we can discuss again
=== doko_ is now known as doko
[19:01] <doko> xnox, still planning to update boost when opening the w-series?
[19:12] <dobey> doko: hi. when do you expect w archive to be opened?
[19:12] <ogra_> what ? it isnt open yet ?!?
[19:12] <ogra_> :P
[19:14] <dobey> heh
[19:15] <dobey> of course, then we'll have to wait for CI to get stuff set up for w
[19:16] <doko> dobey, I doubt it will be open for everybody before the weekend
[19:17] <dobey> doko: ok. hopefully CI can get all their bits updated to allow landing in it on Monday too.
[19:19] <ogra_> dobey, what do you want to land ?
[19:19] <ogra_> so urgently ...
[19:20] <dobey> ogra_: all the many things that people on my team have been working on, that aren't critical bug fixes :)
=== arges_ is now known as arges
[20:27] <arges> hallyn_: updated bug 1444057, if you are happy let me know and I can upload into W next week and sru into V
[20:27] <ubottu> bug 1444057 in qemu (Ubuntu) "gdb remote target of a guest VM fails to continue" [High,In progress] https://launchpad.net/bugs/1444057
[20:28] <arges> (or whatever is easiest)
[20:38] <hallyn_> arges: i'm happy, and frankly i'm happy to have you upload it now
[20:40] <hallyn_> stgraber: ^ qemu in vivid currently can't be used with gdb to trace the guest;  building with --debug fixes it;  i think it's worth a last-minute upload to fix that.  What do you think?
[20:42] <stgraber> hallyn_: upload it to the queue. It can then be pulled in if we rebuild the server image before release (as it's seeded in there)
[20:42] <stgraber> hallyn_: that's assuming you've confirmed --debug doesn't cause significant performance regressions or other change in behavior
[20:42] <arges> stgraber: i've only tested boot times
[20:43] <arges> stgraber: any particular benchmarking you'd like to see?
[20:44] <stgraber> arges: I expect the server folks can take your qemu for a spin on some crazy openstack scaling run to make sure this isn't slowing things down
[20:44] <arges> stgraber: i'll build it in a PPA then
[20:45] <arges> and ask for testing
[20:45] <stgraber> ok, cool.
[20:45] <stgraber> I have no idea what --debug may do for qemu but that sounds like the kind of option where a performance regression test would be worth it :)
[20:47] <arges> stgraber: disable-strip just does 'strip_opt=no'; enable-debug adds that plus 'debug_tcg=yes,debug=yes' i'll also look through the code to see what changes specifically and put that that info into the bug
[20:50] <hallyn_> i would've assumed boot times would've shown perf regressions
[22:22] <arges> hallyn_: one last note. building qemu with --enable-debug disables adding -O2 to CFLAGS. I'm guessing that might be reason enough to not build with enable-debug...
[22:28] <arges> so that might be a 'wont fix' and just document it
[23:34] <hallyn_> dunno, if it doesn't actually affect perf...
[23:35] <hallyn_> but ok, let's leave it for w i guess