[07:33] <Logan> cjwatson: regarding https://launchpadlibrarian.net/257940143/buildlog_ubuntu-yakkety-amd64.eclipse-titan_5.4.1-1_BUILDING.txt.gz - it looks like the requirement of hardening-wrapper is due to the Ubuntu vendor module for dpkg that you wrote
[07:34] <Logan> cjwatson: now that hardening flags are automatically exported by dpkg as of 1.16.1, it would probably be safe to remove the hardening-wrapper logic from https://anonscm.debian.org/cgit/dpkg/dpkg.git/tree/scripts/Dpkg/Vendor/Ubuntu.pm no? Lintian complains about hardening-wrapper being obsolete when I add a build dependency on it
[08:27] <mwhudson> uh why is https://launchpad.net/ubuntu/+source/golang-pretty in main?
[08:27] <mwhudson> both in a "can someone tell me" way and "can someone tell me how to find out" way
[08:28] <mwhudson> oh i think it's on a chain of build depends that ends up at juju-core or something
[08:40] <zyga> brendand: hey :)
[08:40] <brendand> zyga, hey
[08:41] <zyga> brendand: how are you doing? settling in in the new role?
[08:42] <brendand> zyga, getting to know maas
[08:42] <brendand> yeah
[08:42] <zyga> cool, it's great to have you back :)
[08:43] <Logan> mwhudson: if you do an advanced search on bugs for the package and allow "Fix Released," you'll see Bug 1267393
[08:44] <Logan> (there should always be an MIR bug associated with a package that was moved to main)
[08:44] <mwhudson> ah yes
[08:44] <mwhudson> i guess an advanced search for "MIR" would be even more direct
[08:44] <Logan> true :)
[08:44] <mwhudson> oh well, i hope i didn't just break juju by syncing that package from debian :-)
[08:45] <mwhudson> (in fact it seems juju already ftbfs thanks to other things i did in debian...)
[08:45] <Logan> looks like it has a depwait anyway
[08:47] <Logan> oh, golang-text needs to make it through the NEW queue first before it'll build
[08:48] <Logan> in any case, ideally there's an autopkgtest for juju that would fail if these new Go packages caused a regression
[08:50] <cjwatson> Logan: while hardening-wrapper is obsolete, I'm reluctant to change that behaviour until it's actually gone.  In this case this is just a clear bug in eclipse-titan; it's using DEB_BUILD_OPTIONS but with the syntax and semantics documented for DEB_BUILD_MAINT_OPTIONS (see dpkg-buildflags(1))
[08:51] <cjwatson> and DEB_BUILD_OPTIONS should not be set by packages anyway
[08:51] <cjwatson> Logan: I'll fix this case and forward to Debian
[08:53] <Logan> cjwatson: if DEB_BUILD_OPTIONS isn't supposed to be set by packages, and it doesn't have "hardening" by default, I don't see the point of maintaining that behavior (because when will it ever be set to that?)
[08:54] <Logan> thanks for the clarification, though! and I appreciate you fixing/forwarding the bug
[08:54] <Logan> actually I guess a user could just set it as an environment variable - is that the edge case you're supporting?
[08:55] <cjwatson> Logan: The behaviour was specifically to help users setting that
[08:55] <Logan> gotcha :)
[08:56] <Logan> hmm, maybe dpkg-buildflags(1) should be more explicit about the difference between DEB_BUILD_MAINT_OPTIONS and DEB_BUILD_OPTIONS
[08:56] <Logan> it just lists both of them as serving the same purpose but happens to use the MAINT one in the examples
[08:56] <cjwatson> so I'm not totally disagreeing that we should eventually drop this behaviour from Dpkg::Vendor::Ubuntu
[08:56] <Logan> I guess it *should* be self-explanatory that the MAINT one is for package maintainers
[08:56] <cjwatson> I'm just not quite sure about the timing, and it's not the right way to fix this particular bug
[08:57] <Logan> oh never mind about the documentation part, it's clarified later on in the manpage
[08:58] <Logan> but yeah, agreed - the best way to fix this for now is to make sure the proper variable is being set in this package
[08:58] <Logan> the logic in the dpkg module should probably only be removed once hardening-wrapper is killed off
[08:58] <cjwatson> yeah
[08:59] <Logan> thanks again!
[09:02] <Logan> cjwatson: btw, while I have you, nobody has merged my fix for the ubuntu-policy FTBFS yet (I wanted to make sure it was reflected in the repo instead of just uploading to universe): https://code.launchpad.net/~logan/debian-policy/fix-ftbfs/+merge/289853
[09:02] <Logan> and you seem like a likely candidate to review, even though you haven't touched it since 2009: http://bazaar.launchpad.net/~ubuntu-core-dev/debian-policy/ubuntu/changes
[09:03] <cjwatson> yikes, I really must merge that thing properly
[09:03] <Logan> (although we should probably just get rid of this package because it's so obsolete)
[09:03] <Logan> (or that)
[09:03] <cjwatson> well it does actually have differences that are still applicable
[09:03] <cjwatson> but I'll merge your thing for now, thanks
[09:04] <Logan> sure thing
[09:08] <cjwatson> oh nice, ffmpeg sorted out, thanks doko
[09:08] <cjwatson> (and others I'm sure)
[10:50] <rbasak> apt bug? Bug 1571174.
[12:10] <pitti> Good morning
[12:50] <LocutusOfBorg> doko, I tried a lot with something like DEB_BUILD_OPTIONS=harderning=-pie but I don't see any -no-pie flag injected
[12:52] <LocutusOfBorg> how can I have that flag injected automatically?
[12:53] <LocutusOfBorg> "export DEB_BUILD_MAINT_OPTIONS=hardening=-pie,-pic,-format,-bindnow" <-- virtualbox now
[13:33] <rbasak> Laney: thank you for spying on us :)
[13:33] <rbasak> (please continue)
[13:33] <rbasak> I'm struggling to follow how everything fits together.
[13:33] <rbasak> Where are manually maintained packagesets kept?
[13:34] <Laney> hi rbasak
[13:34] <Laney> they are 'kept' in Launchpad
[13:34] <rbasak> That makes sense. So they are manipulated only through launchpadlib, or is there a UI?
[13:34] <Laney> there's a list here http://people.canonical.com/~ubuntu-archive/packagesets/yakkety/
[13:35] <Laney> typically you use the edit-acl script in lp:ubuntu-archive-tools to manipulate them
[13:35] <rbasak> Ah
[13:35] <rbasak> Somebody told me that already, but I've been looking in ~developer-membership-board only. Thanks :)
[13:36] <Laney> nod
[13:36]  * Laney is here for advice if needed
[13:36] <rbasak> Appreciated :)
[13:36] <rbasak> DOes Launchpad keep a revision history of ACL changes?
[13:37] <Laney> Don't think so
[13:37] <rbasak> (that would make touching this a little less scary)
[13:37] <rbasak> OK
[13:37] <Laney> it's probably edit-acl -P ubuntu-mate -p flexiondotorg -S yakkety remove
[13:38] <Laney> and then -p ubuntu-mate-uploaders ... add
[13:38] <Laney> after you make the team
[13:38] <Laney> (It might be that this a TB action - some things are, but I forget exactly what)
[13:39] <rbasak> I'd like to follow what's going on, but I think infinity made the initial change so it might be better for him to look at this particular change.
[13:39] <rbasak> Just to avoid any confusion.
[13:39] <Laney> 'k
[13:39] <flexiondotorg> Laney, rbasak I think infinity add me as an uploader to the MATE packages in xenial and yakkety last week.
[13:39] <rbasak> flexiondotorg: Laney suggests doing it differently: https://lists.ubuntu.com/archives/devel-permissions/2016-May/000922.html
[13:40] <rbasak> flexiondotorg: it shouldn't make any difference to your actual access I believe.
[13:47] <rbasak> Querying myself (or presumably any core dev) is interesting as it basically lists everything.
[14:23] <xnox> pitti, cyphermox - http://packages.ubuntu.com/search?suite=yakkety&section=all&arch=any&keywords=ntp&searchon=contents
[14:23] <xnox> that's where original dhcp sets ntp server settings i am guessing
[14:23] <xnox> via /etc/dhcp/dhclient-exit-hooks.d/ntp
[14:24] <xnox> i am shocked that ntp cannot be set in /etc/networking/interfaces =(
[15:07] <pitti> bdmurray, arges: do you have some time to review my systemd SRU? we're getting more SRU requests, so would be nice to unblock this
[15:08] <arges> pitti: i'll have time this afternoon if bdmurray doesn't get to it first
[15:21] <bdmurray> pitti: I'll look shortly
[15:27] <seb128> mdeslaur, hey, bug #1578576 seems a regression from the recent samba-regression-fix security update :-/
[15:28] <mdeslaur> yeah, that's nice
[15:28] <seb128> mdeslaur, sorry :-( (just pointing it because I review recent reports and crossed it)
[15:28] <mdeslaur> samba regression whack-a-mole
[15:29] <mdeslaur> seb128: thanks
[15:30] <seb128> mdeslaur, yw!
[16:25] <hallyn> pitti: hey, if/when you have a minute, http://paste.ubuntu.com/16241500/
[16:25] <hallyn> pitti: ^ at line 195 is my check which does do a deb-system-helper disable libvirtd.service,
[16:25] <hallyn> but later on is debhelper-added code which appears to reenable it
[16:26] <hallyn> (starting line 264)
[16:26] <hallyn> do i need to do another step to tell it "no really, i want it disabled"?  is that what 'mask' would do?
[16:32] <hallyn> maybe i should just re-mask it
[16:34] <hallyn> or i could manually move the libvirt-bin.masked dir to libvirtd.masked i suppose
[16:55] <hallyn> pitti: ok but surely http://paste.ubuntu.com/16242185/ ought to work.
[17:00] <hallyn> maybe i need an update-state in there?
[17:02] <hallyn> nope, doesn't help.  i'm at a loss.
[17:02] <hallyn> some food may help.
[17:20] <hallyn> maybe i just need to find the right time to move /var/lib/systemd/deb-systemd-helper-enabled/libvirt-bin.service.dsh-also to /var/lib/systemd/deb-systemd-helper-enabled/libvirtd.service.dsh-also
[17:21] <hallyn> really there should be a dh_systemd command for that
[17:26] <chiluk> cyphermox: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1569567
[17:27] <cyphermox> yay
[17:41] <cyphermox> cjwatson: what are your thoughts on this? https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1569567/comments/6
[17:57] <JordiGH> sabdfl logged in 4 weeks ago last time. Was he around here?
[18:05] <cyphermox> JordiGH: you're probably better off sending an email.
[18:06] <JordiGH> I don't want to contact him. Honestly just want to know if he comes around.
[18:18] <dobey> yes, he is on irc plenty
[18:18] <dobey> he travels a lot more than most of us though
[18:20] <JordiGH> I see. Interesting.
[19:06] <hallyn> mbiebl_: hey - are you around by chance?
[19:06] <hallyn> mbiebl_: end of https://git.launchpad.net/~libvirt-maintainers/ubuntu/+source/libvirt/tree/debian/libvirt-daemon-system.postinst?h=2016-05-02/yakkety
[19:07] <hallyn> i've added 'echo disabling >> /tmp/debug' to the postinst when it should disable it.  It is calling the deb-systemd-helper disable libvirtd.service
[19:07] <hallyn> but then the service is running anyway.
[19:07] <hallyn> is there anything else i should do?  i don't understand the 'update-state' or 'mask' or 'unmask' options...  maybe onf of those, except i've tried them blindly with no apparent success
[19:46] <cjwatson> cyphermox: haven't read the whole bug; I agree that 2) and 3) are likely good changes, at least; not quite sure why /etc/default/grub needs to be "[moved] to be early in /etc/default/grub.d" as I thought it was already always sourced first
[19:46] <cyphermox> cjwatson: either or
[19:47] <cyphermox> cjwatson: if we don't carry the values, then moving /etc/default/grub to grub.d will make it more obvious that there may be something to override what you've set
[19:47] <cyphermox> I may have written that all wrong
[19:48] <cjwatson> cyphermox: I'm very wary about moving configuration files around; not only is it inherently fiddly but there's a long tail of documentation and random web pages and such.  I think that should be avoided unless absolutely necessary
[19:48] <cyphermox> I agree
[19:49] <cyphermox> I would just fix curtin/maas/whatever to keep the values already sourced unless it's really not possible
[19:49] <cyphermox> hrm, for some reason, I don't have the key repeat settings doing the right thing here.
[19:50] <cjwatson> so yeah, if grub.d files are unconditionally clobbering settings when they could reasonably append, I consider that a clear bug in those packages
[20:01] <hallyn> pitti: mbiebl_: so https://git.launchpad.net/~libvirt-maintainers/ubuntu/+source/libvirt/tree/debian/libvirt-daemon-system.postinst?h=2016-05-02/yakkety doesn't quite work but at least doesn't fail so i'll look at other failures until one of you can loan me a clue :)  thx
[20:01] <arges> bdmurray: i take it you reviewed systemd already?
[20:23] <pitti> arges: yes, he did
[20:24] <arges> ah good
[21:46] <doko> Logan, please fokllow-up on the library transitions you just started
[21:46] <Logan> sure, I was waiting for them to clear the NEW queue :)
[22:19] <Logan> doko: does the transition tracker need to be poked to update from the repo?
[22:23] <doko> Logan, transition tracker is all manual :-/
[22:23] <Logan> I know
[22:23] <Logan> I added new ben files in the repo 20 minutes ago, but the transitions haven't shown up on the site
[22:24] <Logan> (and I'm pretty confident I formatted them correctly)
[22:43] <clivejo> hi folks, what vervion of libc is yakkety using?
[22:44] <sarnold> looks like 2.23-0ubuntu3  https://launchpad.net/ubuntu/+source/glibc
[22:46] <clivejo> libc6 ?
[22:46] <sarnold> yeah
[22:46] <Logan> it's had that SOVERSION for a long time
[22:47] <sarnold> libc5 is .. shrouded in mists. I for one can only vaguely recall those times.. dark times they were.
[22:47] <sarnold> of course legends tell of libc4, grim and meagre.
[22:48] <clivejo> what does error: ‘sqrt’ is not a member of ‘std’ mean?
[22:48] <Logan> doko: sorry to bug you again, but how exactly should dependency levels factor into which packages I transition first?
[22:49] <Logan> as far as I can tell, they all directly depend on the older version...
[22:49] <doko> first do level 1, wait until these are published, and then go on with the next level
[22:49] <Logan> what is the reasoning behind it, though? what do dependency levels mean?
[22:49] <Logan> clivejo: it means that you haven't included the necessary header for std::sqrt
[22:50] <Logan> (which appears to be <cmath>)
[22:50] <sarnold> clivejo: feels like you forgot the #include <cmath> header: http://en.cppreference.com/w/cpp/numeric/math/sqrt
[22:50] <sarnold> clivejo: .. but it might be something more subtle/annoying like a misused "use" statement or something.
[22:51] <Logan> I think glibc 2.23 removed a lot of implicit includes
[22:51] <clivejo> its KDE software and is building on other distro's, just cant get it to build on yakkety
[22:51] <Logan> link? I can take a look
[22:51] <clivejo> https://launchpadlibrarian.net/258045993/buildlog_ubuntu-yakkety-i386.plasma-desktop_4%3A5.6.3-0ubuntu1~ubuntu16.10~ppa3_BUILDING.txt.gz
[22:51] <clivejo> sure
[22:52] <clivejo> package is in https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/staging-plasma
[22:53] <Logan> looking
[22:54] <Logan> doko: pinging for above question (right after you replied to me)
[22:56] <Logan> clivejo: boom https://quickgit.kde.org/?p=plasma-desktop.git&a=commit&h=3a3bbc39d5cba8d77c89f6652c5b9c24c9980497
[22:57] <Logan> cherrypick that commit, and you should be golden
[22:57] <clivejo> I could kiss you Logan!!  Thanks so much!
[22:57] <Logan> hahaha no problem!
[23:02] <doko> Logan, packages on higher levels may depend on packages in lower levels
[23:02] <sarnold> Logan: boom :) nice find
[23:03] <Logan> doko: ahh, gotcha
[23:03] <Logan> sarnold: thanks :)
[23:03] <Logan> now you all are required to endorse my imminent core dev application ;P
[23:04] <sarnold> \o/
[23:04] <Unit193> Logan: G'luck!
[23:04] <clivejo> +1 from me :)
[23:04] <Logan> thanks :) trying to time it properly
[23:05] <Logan> I've had a few people tell me I should apply
[23:42] <Logan> ew, why does ubuntu-touch-meta depend on a shared library?
[23:44] <Logan> I shouldn't have to mess with germinate for a library transition
[23:45] <Logan> gah sil2100 left just as I said that
[23:54] <Logan> could a core dev please merge this so that I can push an update to ubuntu-touch-meta? https://code.launchpad.net/~logan/ubuntu-seeds/ubuntu-touch-tinyxml2/+merge/293955