| mwhudson | is there a x86_64-apple-darwin binutils hiding in the archive somewhere? | 04:20 |
|---|---|---|
| dholbach | good morning | 06:55 |
| pitti | Good morning | 08:20 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| pitti | Riddell: hey Jonathan, how are you? | 09:05 |
| 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:06 |
| 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:11 |
| pitti | jdstrand: if so, please upload it today | 09:12 |
| rbasak | Can seeds do alternatives? | 09:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| rbasak | Yep | 09:48 |
| 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:49 |
| 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:50 |
| rbasak | If they're just consuming time, do server users want to use ntpd or timesyncd? | 09:51 |
| 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:52 |
| pitti | infinity: timesyncd adapts the update cycles according to the current drift | 09:53 |
| 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:54 |
| rbasak | That's useful, thanks. | 09:55 |
| rbasak | Especially as I can't find this stuff documented anywhere/ | 09:55 |
| === hyperair is now known as m4 | ||
| === m4 is now known as hyperair | ||
| 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:10 |
| ogra_ | (about that topic) | 11:11 |
| 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:12 |
| didrocks | thanks! | 11:13 |
| ogra_ | https://lists.ubuntu.com/archives/snappy-devel/2015-March/000378.html is the key though | 11:13 |
| 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:15 |
| ogra_ | probably not with the armhf beaglebone image though :) | 11:16 |
| === MacSlow is now known as MacSlow|lunch | ||
| === MacSlow|lunch is now known as MacSlow | ||
| === plars is now known as plars- | ||
| 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. | 13:22 |
| === Anupkumar is now known as d3v1l | ||
| === d3v1l is now known as Anupkumar | ||
| diwic | rbasak, it's valid. Question is if I should try to upload something, or wait for an SRU | 13:50 |
| 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? | 13:52 |
| === Anupkumar is now known as Anup | ||
| === Anup is now known as Anupkumar | ||
| shadeslayer | slangasek: ping | 13:56 |
| 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 | 13:57 |
| === pgraner-afk is now known as pgraner | ||
| rbasak | diwic: I think there's still time to upload a fix. Check in #ubuntu-release though. | 14:12 |
| diwic | yup. Already there | 14:12 |
| rbasak | Oh yes, sorry. Just got back to my screen and I looked at the highlighted channels first. | 14:14 |
| shadeslayer | slangasek: nvm | 14:17 |
| 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:52 |
| Ionic | or maybe that was very old news | 15:55 |
| Ionic | yeah I guess... nevermind, sorry | 15:56 |
| Ionic | 2012 | 15:56 |
| Ionic | likely some layer 8 error back then | 15:57 |
| * infinity glares at rbasak for moving files and making him hand-compare the diffs. | 16:01 | |
| 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:02 |
| 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:03 |
| rbasak | Then the diff output shows the changes across the rename, which is nice. | 16:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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 | 16:41 |
| wgrant | jibel: https://launchpad.net/~wgrant/+archive/ubuntu/experimental/+build/7343935 | 17:30 |
| jibel | wgrant, verification passed :) | 17:36 |
| 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:50 |
| 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. | 17:59 |
| wgrant | stgraber: Ah, indeed, broken upstream as well AFAICS. Will try to reproduce on that and submit upstream. | 18:07 |
| hallyn_ | what's broken upsream? | 18:26 |
| hallyn_ | stgraber: all fixes should be upstream. | 18:26 |
| 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:27 |
| 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. | 18:28 |
| === rickspencer3_ is now known as rickspencer3 | ||
| 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 | 18:32 |
| === doko_ is now known as doko | ||
| doko | xnox, still planning to update boost when opening the w-series? | 19:01 |
| 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:12 |
| dobey | heh | 19:14 |
| dobey | of course, then we'll have to wait for CI to get stuff set up for w | 19:15 |
| doko | dobey, I doubt it will be open for everybody before the weekend | 19:16 |
| dobey | doko: ok. hopefully CI can get all their bits updated to allow landing in it on Monday too. | 19:17 |
| ogra_ | dobey, what do you want to land ? | 19:19 |
| ogra_ | so urgently ... | 19:19 |
| dobey | ogra_: all the many things that people on my team have been working on, that aren't critical bug fixes :) | 19:20 |
| === arges_ is now known as arges | ||
| 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:27 |
| arges | (or whatever is easiest) | 20:28 |
| hallyn_ | arges: i'm happy, and frankly i'm happy to have you upload it now | 20:38 |
| 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:40 |
| 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:42 |
| arges | stgraber: any particular benchmarking you'd like to see? | 20:43 |
| 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:44 |
| 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:45 |
| 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:47 |
| hallyn_ | i would've assumed boot times would've shown perf regressions | 20:50 |
| 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:22 |
| arges | so that might be a 'wont fix' and just document it | 22:28 |
| hallyn_ | dunno, if it doesn't actually affect perf... | 23:34 |
| hallyn_ | but ok, let's leave it for w i guess | 23:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!