[00:30] <nacc> cyphermox: someone in #ubuntu is indicating the grub update hard-froze several of their systems similar to https://ubuntuforums.org/showthread.php?t=2330915 's report. Any ideas?
[01:13] <halvors> Hi.
[01:14] <halvors> Where can i submit a request for the strongswan package to be updated to the newest upstream version? The current version is 5.5.0 the version on the repositories is 5.3.0
[01:15] <halvors> I mean of course for the yakkety tree,
[01:15] <halvors> three*
[01:16] <sarnold> halvors: I think the requestsync program will do the right thing
[01:35] <nacc> halvors: it needs to be merged, not sync'd
[01:35] <nacc> sarnold: --^
[01:35] <sarnold> ahh
[07:41] <sil2100> tjaalton: hello!
[07:41] <sil2100> tjaalton: I wanted to poke you about bug LP: #1585942
[07:42] <sil2100> tjaalton: we're doing some xenial-arm64 based work for ubuntu touch and this blocks us as it is causing certain unit tests to fail during build
[07:42] <sil2100> tjaalton: (so we can't get all arm64 binaries that we need)
[07:43] <tjaalton> sil2100: ok, it's in yak now but the pkg is in NEW. and you need it for xenial too
[07:46] <sil2100> tjaalton: is that mesa 12.0.1-3ubuntu1 ?
[07:46] <tjaalton> ys
[07:46] <tjaalton> +e
[07:47] <sil2100> tjaalton: I see it's a new upstream release as well, will we need all of it in that case?
[07:47] <tjaalton> no
[07:47] <tjaalton> just that "devel first" wasn't true until this :)
[07:55] <tjaalton> sil2100: the other components of the bug don't need updates for xenial?
[08:03] <tjaalton> sil2100: uploaded
[08:03] <tjaalton> i'll worry about a new point-release after vacation.. hoping 11.2.2 would be out by then
[09:42] <rbasak> tinoco: your debdiffs in bug ssh-rsa
[09:42] <rbasak> AAAAB3NzaC1yc2EAAAADAQABAAACAQDirUcwitpDz3WNArkqGco7pSv1BQPuSxPwcqxojMMMVflpDGjj8GYlIERLnAn2o2WZsQSBQ1TmD0O6evb2otwhW1m6xegj2/hv/CFVSy3UjjE7QVyewCUbA8JJkPRbnLo80yuuw+mbq4YXYphSmZoptnGxPXHC/HAnryzY9uqjr7u5cCMMUG8Ien74KKzRf2/P4ghJTkjdBttta/qlz1Iz9kH3CxYjXFAgTFaD7MQld7NOKx95Hp2WkMkiJXDMHXoSf7RNgrPuh65gGQVlsIrswrEBbSUGmzn1OPTCFeGmneekI1F8lB4447uaSsUQa+UiODbyhhNz9fU2c7lppOZoKxAPPpwnQgEcxOU2FL3IXkb5azk94Fqw
[09:43] <rbasak> Kxvljo13IkuUvFDqGP0kLiWqh7k79v9tjR9fwI9krRJ4N6iz3RosjAxPS3ff9xs3lnSf2GxVootdUC564x98iT2CYJEqrCmoMdtiivnsIrRjUVjGO6xSAoIqYi+A+5ljTJwKAGqjQ0bkJwi0Rn++CnL44VnsHTWbQ7UtdRJZo0lvKY+1vXIcCApTD8wcb1uD/6nuS9HDy5xwOuxbamR1fqfKzsuuxwbzcO75Azu+q+2tIWnQKxbn56dWQTcY7QG2Q9CDWxsiRoHPl2ADx+7qcZGm7M7prDK/C6G0sxgseG/i6OZChAx1PQ== CPaelzer@Launchpad-RSA # ssh-import-id lp:paelzer
[09:43] <rbasak> Uh, sorry.
[09:43] <rbasak> cpaelzer: ^ :)
[09:43] <rbasak> tinoco: your debdiffs in bug 1570678 look fine, but may I also add "to fix crash on ppc64el" to the changelog? Users review changelogs, so I think it's useful to summarise the justification for the SRU itself in them.
[09:44] <rbasak> tinoco: otherwise it sounds like just a performance thing.
[09:45] <rbasak> tinoco: also the trusty debdiff version is wrong - it should end 0.14.04.2.
[10:18] <sil2100> tjaalton: thanks!
[10:24] <sil2100> tjaalton: hm, did you upload mesa to xenial?
[10:25] <sil2100> tjaalton: ah! Yes, I see it in the unapproved queue, thanks!
[10:25] <sil2100> tjaalton: I checked it before but somehow my eyes missed it, ignore me ;)
[10:25] <sil2100> Thanks again!
[10:40] <Odd_Bloke> Grr, sbuild is unmounting my encrypted home directory when I build trusty packages.
[11:22] <rbasak> darkxst: please could you re-review/sponsor the patch in bug 1550210? I have been cherry-picking from the sponsorship queue today, but am not confident in following what you said.
[11:31] <tinoco> rbasak: sure.. would u fix it during sponsorship or you would like me to change debdiffs and re-attach ?
[11:47] <cjwatson> pitti: Would you mind having a look at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-019/xenial/ppc64el/u/ubuntu-system-settings-online-accounts/20160718_054019@/log.gz ?  I've tried playing around in chdist and can't work it out.
[11:51] <rbasak> tinoco: I'm happy to fix during sponsorship. I'll do it today.
[11:51] <tinoco> rbasak: tks!! i'll verify isc-dhcp-server sru then.
[12:37] <cpaelzer> The policy doc isn't entirely clear to me - can .symbols files hold comments?
[12:38] <cpaelzer> There is some rather uncommon behaviour that I'd like to add as comment so the next one looking at it doesn't have to go all the way again
[12:38] <ogra_>        Note that you can put comments in symbols files: any line with ‘#’ as
[12:38] <ogra_>        the first character is a comment except if it starts with ‘#include’
[12:38] <ogra_>        (see section Using includes).  Lines starting with ‘#MISSING:’ are
[12:38] <ogra_>        special comments documenting symbols that have disappeared.
[12:38] <ogra_> http://man7.org/linux/man-pages/man1/dpkg-gensymbols.1.html
[12:39] <cpaelzer> thanks ogra_!
[12:39] <ogra_> :)
[12:40] <cpaelzer> a lot of documentation is great until you won't find it due to all the docs :-)
[14:53] <infinity> tinoco: Any progress on isc-dhcp?
[15:15] <pitti> cjwatson:
[15:15] <pitti> Broken ubuntu-system-settings:ppc64el Depends on powerd [ ppc64el ]
[15:15] <pitti>  powerd | 0.16+16.04.20160204.1-0ubuntu1         | xenial/universe  | source, amd64, armhf, i386
[15:15] <pitti>  powerd | 0.16+16.04.20160204.1-0ubuntu2~xenial1 | yakkety/universe | source
[15:15] <pitti> cjwatson: it's not just because there is no powerd on ppc64el?
[15:16] <ogra_> powerpc is power(d)less !
[15:17] <pitti> powerd is really broken in yakkety
[15:17] <pitti>  powerd | 0.16+16.04.20160204.1-0ubuntu2~xenial1 | yakkety/universe | source
[15:17] <pitti>  powerd | 2016.06+16.10.20160706.1-0ubuntu1      | yakkety/universe | all
[15:18] <pitti> or rather, the source is not building any binaries any more, and powerd is a transitional package; although in the overlay they reverted that and brought back powerd
[15:18] <pitti> so, not a clue, being on a sprint, something for later..
[15:19] <cjwatson> pitti: Yeah, but when I try it with chdist and the right set of archives for this test, it picks gnome-settings-daemon instead
[15:19] <cjwatson> pitti: (the dependency is powerd | gnome-settings-daemon or some such)
[15:24] <pitti> indeed, and it doesn't seem to like that either
[15:24] <pitti> I'll keep a tab for the log
[15:36] <tinoco> infinity: im doing it right now
[15:49] <ricotz> jamespage, hi, I guess something went wrong with ceph since it doesn't get stripped
[16:00] <jamespage> ricotz, yeah I'm baffled
[16:00] <jamespage> apparently I've forgotten all of the important stuff about distro devel
[16:01] <jamespage> hmm override_dh_strip is still in .PHONY
[16:02] <ricotz> jamespage, this might help https://anonscm.debian.org/cgit/pkg-mate/plank.git/commit/?id=fdf38328bea736e64c906f2c3cefecf232622df2
[16:02] <mdeslaur> kees, infinity, stgraber: tech board meeting now
[16:24] <tinoco> infinity: done. lp1529815 verified.
[16:24] <tinoco> sorry for taking so long, i had to steal some HW in the lab
[16:29] <jamespage> ricotz, thanks for the pointer
[16:29] <jamespage> tomorrows work
[16:53] <slangasek> cjwatson: snappy is making use of grub2's loopback and squash4 modules to access kernel/initramfs from inside the kernel snap package at boot time.  I've just noticed neither of these are in the signed EFI binary.  Do you have any concerns about either of these being signed for SB?
[16:54] <cjwatson> slangasek: seems reasonable
[16:57] <slangasek> cjwatson: ok.  any particular level of auditing you think is needed on these, or should I just add them?
[16:58] <cjwatson> slangasek: loopback should be trivial.  squash4, may be worth doing a general sanity audit of the code looking for places where a corrupt filesystem might convince it to jump into space
[16:58] <slangasek> that was my intuition as well, though I had hoped I was wrong ;)
[16:59] <slangasek> ok, will look for someone sane to audit
[16:59] <cjwatson> It's not *too* long
[16:59] <slangasek> :)
[16:59] <cjwatson> Thanks
[17:39] <teward> bugs with commands such as `tail` should be filed against coreutils, right?
[17:40] <nacc> teward: looks like it (at least for tail)
[17:42] <teward> nacc: that's what I thought
[17:42] <teward> ('tail -n #' no longer prints just that number of items, like its manpage says, in yakkety)
[17:44] <teward> nacc: see #1604511
[17:44] <teward> if you're curious :P
[17:46] <nacc> teward: doesn't seem like the current delta shoudl have that effect (or if it does, undocumented). Wonder if it's an upstream regressin/change
[17:46] <teward> nacc: indeed.  That said, this is a ***massive*** change
[17:46] <teward> because `tail -n` has always been there
[17:46] <nacc> teward: yeah, seems unintentional :)
[17:46] <cjwatson> I don't buy it.
[17:46] <teward> cjwatson: that it's a change or that the bug exists?
[17:46] <cjwatson> The version of coreutils in yakkety is the same as that in xenial.
[17:46] <infinity> I can't reproduce.
[17:46] <teward> hmm
[17:47] <teward> *nukes server, starts again*
[17:47] <cjwatson> It works fine in xenial, and coreutils by nature has very few external dependencies.
[17:47] <teward> cjwatson: yeah, this is making me scratch my head, because this is *new* behavior
[17:47] <infinity> teward: It can *look* like it's behaving that way if you lose all your line endings to some weird binary corruption.
[17:47] <cjwatson> What does "tail -n /var/log/apt/history.log | wc -l" say?
[17:47] <infinity> But I definitely can't reproduce your example.
[17:48] <teward> oh you know what...
[17:49] <teward> it looks like this is a problem with the system i'm connecting from to the server - its SSH client uses hard breaks instead of soft wraps for when data goes over the line
[17:49] <teward> my bad.
[17:49] <teward> as a result, one to many lines listed >.>
[17:49] <teward> this is why i hate NOT having my ubuntu system for testing things
[17:49] <teward> (Bug invalid)
[17:50]  * teward grumbles
[17:50] <teward> i should've checked that, sorry for noise
[17:51] <teward> i asked rbasak to peek, but anyone else want to do a review of a merge debdiff for any blaringly evil screwups I may have made?  Not uploading immediately, but would like to get a review before I PPA build it for testers to test it.
[17:52] <teward> (see debdiffs on https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1580252 if you care to, otherwise i can wait)
[17:58] <infinity> - This is a dependency package to install either nginx-core (by default),
[17:58] <infinity> - nginx-full, nginx-light, or nginx-extras.
[17:58] <infinity> + This is a dependency package to install either nginx-full (by default) or
[17:58] <infinity> + nginx-light.
[17:58] <infinity> teward: You undid that change, looks like.
[17:58] <nacc> teward: might be my own ignorance, but it's kind of hard to follow that all the delta has been accounted for with each ubuntu version, as the stuff that (presumably) has been dropped isn't explicitly mentioned (e.g., 1.9.15-0ubuntu1 mentions adding a build-dep, and it's mentioned as being carried forward in 1.10.0-0ubuntu1, but 1.10.1-0ubuntu1 makes no mention of it?
[17:58] <infinity> teward: And some php5/php7 stuff.
[17:58] <teward> oops
[17:59] <teward> this is why i need eyes on things :P
[18:00] <infinity> teward: I don't have the patience right now to go over the meat of the merge, though.
[18:00] <teward> not a problem :P
[18:00] <teward> :) *
[18:00] <infinity> It's complicated enough that it's one of those "the best way to review would be for me to do my own merge and then compare" situations.
[18:00] <teward> nacc: the readd of libluajit-5.1-dev as a build-dep is less of a delta.
[18:00] <teward> infinity: ack
[18:00] <teward> nacc: Debian already ahd it
[18:00] <teward> has*
[18:00] <teward> nacc: 'readd' was 'drop the delta'
[18:01] <nacc> teward: i see; i guess my practice is to have each changelog mentioned in a previous version accounted for, that's all i meant
[18:01] <nacc> *each changelog entry
[18:01] <teward> ahhh ok
[18:01] <teward> I only have ever documented the remaining changes between the merge and *debian*, but eh
[18:02] <teward> infinity: it's a PITA, this one, because Debian implemented their 'hybrid' packages.  that said, the packaging needs to update ahead of anything openssl 1.1.0 ever being available, to prevent future FTBFS
[18:02] <teward> (i.e. 1.11.x at least in the interim non-LTS releases)
[18:02] <teward> no clue on the 1.1.0 openssl timelines though
[18:02]  * infinity nods.
[18:02] <nacc> teward: sure, that makes sense too, i think; since i'm still relatively new, it's more of future-proofing that i've not forgotten something :)
[18:02] <teward> there's HTTP/2 fixes i want in there too
[18:03] <teward> s/I want/that should be/
[18:03] <teward> i've got a case of the lazies / work-busys so it's one of those things I can let sit a few days
[18:08] <teward> nacc: indeed.  I actually grab the last "Remaining changes:" section, and run a checklist to see if it's already been dropped in the changelogs between, or if there's anything new, etc.
[18:09] <teward> so to each their own, being overly verbose doesn't hurt.  I just prefer saying "These are the differences"
[18:09] <teward> ... that reminds me, thanks infinity for the php stuff, that's missing from the delta changelog
[18:18] <nacc> hrm, trying to figure out why icinga failed to build on on non-amd64 (https://launchpad.net/ubuntu/+source/icinga/1.13.3-2ubuntu1). I just ran sbuild locally with and without proposed in a i386 schroot and it build fine in both. My delta shouldn't have resulted in any real changes, and it's already been rebuilt once in yakkety (so it's not a binary copy-forward).
[18:19] <infinity> nacc: How did you call sbuild?
[18:20] <nacc> infinity: http://paste.ubuntu.com/20067963/
[18:20] <infinity> nacc: It has nothing to do with "non-amd64" it's "not building arch:all in the same pass".
[18:20] <infinity> nacc: Get rid of -A, watch it fail.
[18:22] <nacc> infinity: ah i see
[18:22] <nacc> infinity: thank you
[18:23] <nacc> infinity: fwiw, the existing yakkety version also ftbfs w/o -A, so did a default flag change in the builders?
[18:23] <infinity> nacc: No.
[18:23] <infinity> nacc: But dpkg-buildpackage changed to require policy-required targets, and call them.
[18:23] <nacc> infinity: ah, ok
[18:24] <infinity> nacc: So, you're likely missing build-arch/build-indep
[18:24] <nacc> infinity: yep, digging into that now, looks to also already be filed as a debian bug
[18:29] <nacc> infinity: thanks, have a fix now, will send it in and to debian
[18:51] <nacc> rbasak: ok, icinga with the latest version should !FTBFS again, and all our delta has been submitted to debian
[19:39] <rbasak> nacc: may I add "to fix FTBFS" to your changelog entry? In case a merge turns out to be needed, knowing why will help.
[19:41] <nacc> rbasak: sure!, thanks
[19:41] <nacc> rbasak: sorry, i thought about that, but wasn't sure it was applicalbe given that it was only in -proposed, but in retrospect it obviously is
[19:41] <rbasak> np
[19:41] <nacc> rbasak: ideally, debian will take it via that bug (to which i sent the debdiff)
[20:13] <nacc> rbasak: ok, upon review, and talking to tgm4883 a bit, i'm ont sure there is an easy way to do what you want. The 'defaultfor' implementation in puppet takes as input a hash (not a condition) and just tests for (in the case of an array) membership. I don't think there's any way for me to test for non-membership (which is what you were usggesting).  The systemd_spec.rb chagne is for testing only
[20:13] <nacc> (afaict), so maybe is less urgent. I think if upstream does take this change (https://github.com/puppetlabs/puppet/pull/5069) we could add a regex, but ubuntu's versions don't lend themselves to a clean (all versions greater than 15.04 regex that i can think of)
[20:23] <rbasak> nacc: what I don't understand is that surely this logic already applies but in reverse, and that's what the bug is? It's defaulting to upstart on Ubuntu (but presumably not other distros), except for particular releases where it defaults to systemd. Why can this not be reversed using the primitives that already exist?
[20:30] <rbasak> nacc: do you see what I'm saying? What am I missing?
[20:36] <nacc> rbasak: i see what you're saying now
[20:39] <nacc> rbasak: doesn't mean i know how to do it yet :) but yeah
[20:44] <nacc> rbasak: ah i see where the confusion is, i think
[20:44] <nacc> rbasak: so in the version in yakkety, there is no such 'default'
[20:44] <nacc> rbasak: it's all version-specific (upstart or systemd)
[20:50] <nacc> rbasak: http://paste.ubuntu.com/20088025/
[20:50] <nacc> rbasak: the issue is the 16.04 version is not specific to that
[20:50] <nacc> sorry, the 16.04 puppet does not have those version-specific changes, so the default for all "ubuntu" is upstart still
[20:57] <rbasak> nacc: what does 16.04 do
[20:57] <rbasak> ?
[20:59] <nacc> rbasak: http://paste.ubuntu.com/20089298/
[20:59] <nacc> rbasak: note, i just tried something, i installed the current yakkety version
[20:59] <rbasak> nacc: OK, so can we make Yakkety do what Xenial is doing but in reverse?
[21:00] <valorie> hello folks, yofel put out the tester call last night: 16.04.1 candidates are out: http://iso.qa.ubuntu.com/qatracker/milestones/363/builds
[21:00] <rbasak> nacc: I think it's fine to deviate from upstream on this as it's clearly less broken this way. In fact, IMHO that's exactly what upstream should do, too.
[21:00] <nacc> rbasak: hrm, i see what you're saying
[21:00] <valorie> however all links seem to be broken - zsync, rsync, wget from http, straight from http
[21:00] <nacc> rbasak: except if upstream did that, then they couldn't test their upstart support on 14.04 with the latest puppet
[21:01] <rbasak> nacc: why not? upstart on 14.04 would have upstart defined as defaultfor 14.04, no?
[21:01] <valorie> http://paste.ubuntu.com/20013301/
[21:01] <valorie> if this is not the proper place to report, where is?
[21:02] <rbasak> nacc: upsteam defaultfor 12.04, 14.04 and maybe 15.10, and systemd default for everything else ubuntu.
[21:02] <rbasak> (also 10.04 if wanted)
[21:02] <nacc> rbasak: one sec
[21:03] <nacc> rbasak: let me try and write out what I understand
[21:04] <infinity> valorie: s,daily,xenial/daily, and you're good to go.
[21:04] <infinity> stgraber: I'd love you forever if there's an easy way to fix all those that doesn't involve hand-editing every project. :/
[21:05] <valorie> infinity: the test site should be fixed though?
[21:05] <infinity> valorie: Ideally, yes.  See above complaint to stgraber.
[21:05] <valorie> good
[21:07] <valorie> that did indeed work, so I'll spread the fix around #kubuntu-devel
[21:07] <valorie> thanks
[21:07] <infinity> valorie: Ta.
[21:10] <nacc> rbasak: ok, now i'm really confused; the test script that sdeziel provided *only* fails on 16.04 if you have the upstart package installed ...
[21:10] <infinity> valorie: FWIW, a fresh respin is in progress as we speak.
[21:13] <infinity> nacc: I'm not entirely caught up on backscroll, but testing distros and versions of distros to determine the init system is just plain wrong.
[21:13] <infinity> nacc: Assuming that's what's happening.
[21:13] <infinity> nacc: [ -d /run/systemd/system/ ] is the way to know you're using systemd, for instance.
[21:14] <nacc> infinity: might be well and true, but i assume that's something i'd just file with puppet and let them figure out? / it's their choice to do it wrong, if they so choose?
[21:14] <rbasak> infinity: even worse, 16.10 is hardcoded to be systemd. My objection is that it'll explode as soon as Yakkety+1 opens.
[21:14] <infinity> nacc: Sure, it's their choice to be stupid, I guess, but it's our choice as downstream to be less stupid.
[21:14] <rbasak> Which IMHO is worse than hardcoding.
[21:15] <infinity> And if people use upstream puppet on Ubuntu, it's in our best interest to make upstream be as not stupid as we are.
[21:15] <rbasak> than *just* hardcoding, that is.
[21:15] <nacc> well, i'm trying to figure out *if* we're broken at all
[21:15] <nacc> rbasak: i think there might be a bug in that if you have the upstart package installed (not necessarily configured to be your init-system, afaict), puppet does the wrong thing
[21:15] <rbasak> nacc: I did think the logic was "default to upstart, except for *these* releases". If that's wrong then I don't object so much.
[21:15] <nacc> but by default it seems to be controlling services correctly
[21:15] <stgraber> infinity: I probably have a script or some sql somewhere that I used for trusty
[21:16] <nacc> rbasak: so roughly, ubuntu 16.04's code-logic: everyting ubuntu is upstart; ubuntu 16.10's code logic: these releases are upstart, these releases are systemd.
[21:16] <infinity> stgraber: If you could do that again, that would be lovely.
[21:16] <stgraber> infinity: basically the tracker knows about the pattern for the current dev release (no series name) and then this can be overriden per-series
[21:16] <nacc> rbasak: but i'm still trying ot understand exaclty what checks for that and where and why :)
[21:16] <stgraber> infinity: let me check, I "think" there is a "copy-downloads" script on limequat for that
[21:17] <infinity> stgraber: Yeah, I know.  But editing each one by hand sucks. ;)
[21:17] <infinity> Anyhow, I need drugs and sleep.
[21:17] <rbasak> nacc: in 16.10, what happens if the release doesn't match?
[21:18] <nacc> rbasak: that's what i'm trying to figure out now (and also why it seems to "work" in 16.04 w/o any patches)
[21:18] <rbasak> OK
[21:21] <nacc> infinity: ah! i think upstream puppet does what you're suggesting on debian, but not ubuntu; not sure why ...
[21:22] <nacc> infinity: also, this is purely about hte 'default's, i think it still checks for presence somewhere else
[21:25] <stgraber> infinity: done, I think
[21:25] <stgraber> I messed things up twice while doing the change but looks like yakkety and xenial links are plausibly right now
[21:30] <infinity> stgraber: Danke.