=== maclin1 is now known as maclin
[05:30] <cpaelzer> nacc: I assume that came up on triage?
[05:31] <cpaelzer> nacc: I usually do Author + Original-Author (in case they differ)
[05:31] <cpaelzer> nacc: the former the one who writes the patch for the deb the latter being the one who originally wrote the code
[05:31] <cpaelzer> nacc: as that usually starts with a git format patch most data is already around
[05:32] <cpaelzer> nacc: but that reporter is from STS, he should know now more on patch style recommendations - I just gave him some early hints
=== koza|away is now known as koza
=== JanC_ is now known as JanC
[09:10] <cpaelzer> pitti: hi are you around for bug 1693115
[09:10] <ubottu> bug 1693115 in libvirt (Ubuntu) "apparmor denial: qemu cannot read /proc/*/cmdline " [Undecided,Incomplete] https://launchpad.net/bugs/1693115
[09:11] <pitti> cpaelzer: hello, how are you?
[09:11] <cpaelzer> pitti: great and I hope you are even greater
[09:11] <cpaelzer> pitti: good to see you around
[09:11] <pitti> cpaelzer: I am, thanks!
[09:11] <cpaelzer> good
[09:12] <pitti> cpaelzer: ah yes, thanks for following up, I'll respond ASAP
[09:12] <cpaelzer> pitti: I was just answering the bug realizing that I could just as well ask you :-)
[09:12] <cpaelzer> pitti: thank you
[09:12] <pitti> I just found a regression in freeipa-client too
[09:12] <pitti> yay for starting to run integration tests on 17.04 (so far we only ran on 16.04)
[09:12] <cpaelzer> pitti: just want to check asap if it is a regression-update (which it hopefully isn't, but especially then I want to check)
[09:13] <pitti> cpaelzer: well, if so, it doesn't seem to be completely broken -- qemu seems to do well enough with out reading cmdline, not sure what it tries to check there
[09:13] <cpaelzer> pitti: it wants to tell people who shut it down
[09:13] <cpaelzer> pitti: I fixed that already
[09:14] <cpaelzer> pitti: but the proximity of my fix and your report made me suspicious
[09:14] <pitti> cpaelzer: oh -- I built that image last week, it doesn't yet have the fix for #1680384
[09:14] <cpaelzer> pitti: I put it in the bug
[09:14] <cpaelzer> pitti: yeah exactly - if you miss that then that is the explanation
[09:15] <cpaelzer> pitti: once you updated on your next run you can update and hopefully close the bug as fix released or dup
[09:15] <pitti> cpaelzer: yes, I'll verify that -- upgrade the package on my test image, and re-run
[09:15] <cpaelzer> pitti: what is the interval you update your images?
[09:16] <cpaelzer> ah sounds like on trigger, ok
[09:16] <pitti> cpaelzer: normally ~weekly, but it's the first one ever, so I can rebuild one at will
[09:16] <cpaelzer> pitti: I saw you to avocado based test in cockpit, for a long time I was thinking of that but as usually you beat me
[09:16] <cpaelzer> pitti: one day I might copy a few bits from there
[09:17] <pitti> the test/verify/ ones are much more interesting though  :)
[09:17] <cpaelzer> you mean the ones you run outside of autopkgtests for their complexity?
[09:17] <pitti> yep, I have 2.5.0-3ubuntu5
[09:17] <cpaelzer> ok, 5.1 should fix it for you then
[09:17] <pitti> cpaelzer: right, I don't yet have an autopkgtest wrapper for test/verify
[09:17] <pitti> just a simple one
[09:20] <pitti> \o/
[09:20] <pitti> cpaelzer: followed up, ♥
[09:21] <cpaelzer> thank you a lot pitti
[09:23] <cpaelzer> pitti: actually did you mean pro-actively instead of "retro" ?
[09:23] <pitti> retroprogressawesomely!
[09:40] <rbasak> pdeee, bmw: as I prepared updated packages for 0.14.1, what can I do to make sure they're working?
[09:40] <rbasak> *as I prepare
[09:48] <jamespage> any of the MIR team around? I need a review on https://bugs.launchpad.net/ubuntu/+source/vine/+bug/1688091
[09:48] <ubottu> Launchpad bug 1688091 in vine (Ubuntu) "[MIR] vine" [High,New]
[09:48] <jamespage> that's holding most of OpenStack Pike b1 in proposed in artful right now
[09:54] <rbasak> bdmurray: did you intentionally not accept Trusty in bug 1690730?
[09:54] <ubottu> bug 1690730 in postgresql-9.6 (Ubuntu) "New upstream microreleases 9.3.17, 9.5.7 and 9.6.3" [High,Triaged] https://launchpad.net/bugs/1690730
=== led2 is now known as led1
[13:59] <bdmurray> rbasak: No, it was not intentional.
=== acheronuk is now known as acheronUK
[15:19] <nacc> cpaelzer: yeah -- is Original-Author a DEP3 header?
[15:35] <rbasak> dep3 just says to use Author multiple times as required.
[15:37] <nacc> rbasak: right
[15:38] <nacc> Applied-Upstream seems new
[15:39] <mdeslaur> rbasak: any progress from upstream about the mysql-5.7 autopkgtest failure?
[15:40] <rbasak> Skuggen: ^?
[15:42] <nacc> rbasak: fyi, snap should be updated with your queue fix(es)
[15:44] <rbasak> Thanks!
[15:46] <nacc> rbasak: and figured out the two import failures, just refactor errors
[15:51] <bmw> rbasak: just now seeing your message about testing
[15:51] <bmw> biggest thing is just running our unit tests included in the packages
[15:51] <bmw> there's close to 100% coverage there
[15:52] <rbasak> bmw: can I do that from an installed system, rather than from the source tree?
[15:52] <rbasak> bmw: this is to catch packaging errors, for example if something's in the source tree but fails to end up in the deb.
[15:53] <bmw> good question, our debian packager always tracks us down when unit tests fail for him but to be honest I'm not sure how he runs them
[15:53] <bmw> I'll see if he's around
[15:55] <rbasak> bmw: we can automate as-installed testing like this too - we call it dep8 (after our spec for how it works).
[15:55] <rbasak> bmw: essentially I just need something to run after the packages are installed that'll give me a yes or no. This might involve an extra binary package with the test suite, for example.
[15:59] <bdmurray> rbasak: I'll review mysql for Trusty now.
[16:00] <bdmurray> rbasak: or maybe I mean postgresql - one of those database things
[16:01] <nacc> bdmurray: that is what you meant :)
[16:04] <nacc> rbasak: sigh, have time for a  HO after the certbot stuff?
[16:09] <Skuggen> rbasak: I mentioned the test fix for mysql 5.7 before (if it's the same failure)
[16:09] <Skuggen> mdeslaur:^ If it's the mysql_not_windows test failure?
[16:10] <Skuggen> On Artful
[16:10] <mdeslaur> Skuggen: yeah, that's the one
[16:11] <mdeslaur> Skuggen: you mentioned it where?
[16:11] <Skuggen> https://anonscm.debian.org/cgit/pkg-mysql/mysql.git/commit/?h=mysql-5.7/lars/ubuntu&id=2f13c610e43b89566e0bd0501c19d4edf9258f59
[16:11] <Skuggen> MySQL package maintainer channel
[16:13] <mdeslaur> Skuggen, rbasak: is one of you going to do an upload, or do you want me to do it?
[16:15] <nacc> cyphermox: is there a reason src:nplan contains a .git directory?
[16:15] <cyphermox> I may have failed at uploading?
[16:15]  * cyphermox sighs
[16:16] <cyphermox> nacc: you can disregard...
[16:16] <Skuggen> mdeslaur: I'm working on a more complete merge from debian as well, but that's not ready yet, but maybe it's a good idea to get the current Ubuntu package working on Artful first
[16:16] <nacc> cyphermox: yeah, but it's there now and i need to think about how to handle it :)
[16:16] <nacc> cyphermox: our importer gets pretty confused :)
[16:16] <cyphermox> nacc: not sure I understand what you mean
[16:16] <cyphermox> ah
[16:17] <mdeslaur> Skuggen: it's blocking other things from migrating, so I would prefer that
[16:17] <Skuggen> rbasak: ^
[16:17] <Skuggen> I don't have upload rights :)
[16:17] <cyphermox> nacc: do as you prefer, it won't be there in next upload. Seems like an instance that ought to be handled anyway
[16:17] <nacc> cyphermox: i swore that the debian manual somewhere said src packages shouldn't contain .git, so we weren't handling that case. But i'm not finding it now. Ther eis 3.0 (git), though, so we need to consider it
[16:17] <nacc> cyphermox: yep, needs to be handled
[16:17] <mdeslaur> Skuggen: I can sponsor your two commits that add the patch and the changelog if you want
[16:18] <cyphermox> nacc: fwiw, importing netplan isn't a bit deal though, it's a native package and one that we're upstream for. the real git repo is in launchpad already
[16:18] <Skuggen> mdeslaur: Sounds good to me
[16:18] <mdeslaur> ok, will do in a few minutes
[16:18] <mdeslaur> thanks Skuggen, rbasak
[16:19] <nacc> cyphermox: yep, it falls under the umbrella of 'thou shall not fail' (where thou is the importer) and 'import everything' :)
[16:19] <cyphermox> nacc: I think regardless of configuration the importer should be able to handle an existing .git directory in a source package, or at least not barf on it
[16:20] <nacc> cyphermox: yep
[16:20] <nacc> cyphermox: just need to think about how, since we are also a .git directory :)
[16:20] <nacc> s/are also/also have/
[16:20] <cyphermox> sure
[16:21] <cyphermox> what I'm saying is you'll get other instances than just nplan
[16:21] <nacc> cyphermox: yep  agreed
[16:21] <nacc> i wonder what dgit does
[16:21] <cyphermox> well, the issue in this case is that I should have used gbp to build the source package
[16:22] <cyphermox> that rips out .git from the source.
[16:23] <nacc> ah i see, dgit does that for imports too
[16:23] <nacc> dgit: warning: removing from source package: ./.git
[16:23] <cyphermox> nacc: and I agree nplan probably ought to be a 3.0 (native) rather than 1.0 format package.
[16:26] <cyphermox> nacc: and that looks like it will avoid the issue in the future
[16:26] <nacc> cyphermox: yep, i think so
[16:26] <nacc> cyphermox: and i think at the same time, i'll push this fix to follow dgit's lead and remove .git/ from srcpkgs on import
[16:27] <cyphermox> hrm, that seems wrong
[16:27] <cyphermox> I mean, it's going to make things work, but then what you'll import won't actually be precisely what was in the upload
[16:28] <nacc> cyphermox: that's true, but for our import-comparison function it will be (since it will always be looking at the tree-hash without the .git directory)
[16:29] <nacc> cyphermox: otherwise, i'd need to do a lossless rename of either our .git directory or teh srcpkg -- the latter of which is messy and has the same issue (matching the upload)
[16:29] <cyphermox> nacc: that's fine, but it won't fix the issue that if you build a new upload based on that import you'll have an extra diff of a removed .git directory
[16:29] <rbasak> mdeslaur: thanks!
[16:29] <nacc> cyphermox: ah i see what you mean
[16:29] <cyphermox> nacc: the right solution would be setting GIT_DIR to something else for the imports.
[16:29] <nacc> cyphermox: no, it's worse than that
[16:29] <rbasak> Skuggen: also thanks!
[16:29] <nacc> cyphermox: what should `git clone` do?
[16:29] <rbasak> nacc: HO?
[16:30] <nacc> rbasak: yes please
[16:30] <rbasak> nacc: standup URL?
[16:30] <cyphermox> nacc: explode in flames? ;)
[16:30] <nacc> cyphermox: yeah :)
[16:30] <nacc> rbasak: yep
[16:30] <cyphermox> nacc: I thought you used a tool to clone too
[16:31] <nacc> cyphermox: right, but then that tool is now different than `git clone` which should always work too
[16:31] <nacc> (and is the default on LP)
[16:31] <cyphermox> nacc: if there's no other way around, I suppose removing .git on import is the lesser evil
[16:31] <nacc> rbasak: for context, LP: #1693290
[16:31] <ubottu> Launchpad bug 1693290 in usd-importer "Unable to import nplan (May 29, 2017)" [Undecided,New] https://launchpad.net/bugs/1693290
[16:31] <cyphermox> (but you might want to ask others for their opinion)
[16:32] <nacc> yep, and we're not necessarily doing this change forever
[16:32] <cyphermox> nacc: well, yeah, for any source package that includes it..
[16:32] <cyphermox> I wonder if you couldn't just fudge things by making britney very much dislike .git directories in source ;)
[16:32] <nacc> cyphermox: tbh, this is the first srcpkg with this issue :)
[16:33] <cyphermox> nacc: heh
[16:33] <cyphermox> I'm happy to reupload if it makes your life easier.
[16:33] <nacc> cyphermox: well, the history is still there, so it's ok :)(
[16:33] <cyphermox> right, it won't solve history
[16:37] <ddstreet> cyphermox hi, sorry to bug you, i have a bug 1573272 that i need to get into artful, it's a small change to the vlan pkg, since ifupdown/vlan is deprecated in artful it should hopefully be an easy/safe upload, could you take a look and maybe sponsor?
[16:37] <ubottu> bug 1573272 in vlan (Ubuntu Artful) "default gateway route not installed for bond interfaces through reboot" [Medium,In progress] https://launchpad.net/bugs/1573272
[16:37] <ddstreet> i can work on getting it sru'ed once it's in artful
=== grumble2 is now known as grumble
[16:53] <cyphermox> ddstreet: ok
=== JanC_ is now known as JanC
[17:25] <bmw> rbasak: while it's not exactly pretty, here's a pretty decent one line test that certbot and its plugins and dependencies are installed correctly
[17:25] <bmw> certbot plugins --prepare | grep -q apache && certbot --help nginx | grep -q nginx-ctl
[17:27] <kees> infinity: https://outflux.net/ubuntu/hardening/i386/ now being gathered/graphed. delta to amd64 wrt PIE is amd64:80% PIE, i386:55% PIE
[17:29] <infinity> kees: Curious.  Is that 55% because lots of people now build with hardening=+all/+pie, or because you count PIC libs and non-ELF packages as a yes?
[17:29] <infinity> kees: (As in, I would have expected that delta to be higher)
[17:30] <kees> infinity: the data collection was adjusted to have a source package be seen as "PIE" if it has ELF objects but no ET_EXEC in any binary package.
[17:30] <kees> i.e. all-library package is counted as PIE
[17:31] <kees> and to distinguish from the stricter count ("has ET_DYN executable"), I left BINDNOW as it was counted before.
[17:31] <kees> so the difference between bindnow and pie is roughly the difference between packages with ET_DYN executables and packages without ET_EXEC.
[17:32] <infinity> kees: PS: The i386 graphs say "amd64" on the Y axis. ;)
[17:32] <kees> whoops
[17:32] <infinity> We'll call that the axis of evil.
[17:33] <kees> ahah
[17:34] <infinity> kees: Hahaha.  So I was going to ask if there's a better breakdown of this data so I can see what actually needs fixing.  Then I saw "pie.data" and excitedly clicked on it to find it has... A single line.
[17:35] <kees> :)
[17:36] <kees> graph data!
[17:36] <kees> I could include the scan log?
[17:36] <infinity> kees: Any idea why the FORTIFY_SOURCE count is so low?  I refuse to believe that 33% of our ELF objects don't link to glibc, nor do I believe that 33% of maintainers intentionally turn it off, so that seems a bit suspect.
[17:37] <kees> when I've looked into that in the past, it was mainly due to a few situations. if you build with fortify enabled, there are some possible results:
[17:38] <kees> - you don't use any scary functions, so nothing is replaced with ..._chk() version to be detected by the scanner
[17:38] <infinity> Ahh.  Yeah, that would do it.
[17:38] <kees> - you DO use scary functions, but their use can be entirely validated at compile time, so no ..._chk() versions to be detected...
[17:38] <infinity> Built with doesn't imply it actually gets the macros inserted.
[17:38] <kees> - and you use scary functions, can't be compile-time validated, so _chk() versions exist to be detected (this is graphed)
[17:39] <infinity> That's a bit irksome for post-build analysis, but oh well.
[17:39] <kees> - last case, which I've never seen: you use scary functions but they can be neither validated at runtime nor compile time, so no _chk()
[17:40] <kees> sure is. having "compiler flags" in some ELF note in binaries would be nice, but bloaty
[17:40] <infinity> There's also "you build without optimisation because you're a bad person", but I want to know about those ones.
[17:40] <kees> oooh yes
[17:40] <kees> that too!
[17:41] <infinity> (And then the as-stated above "your ELF object doesn't link to glibc", but other than some other-libc compilers, freestanding toolchains, and bootloaders, there should be precious few of those)
[17:43] <infinity> But yeah, the "macros isn't used because it's just not needed" cases probably cover most of the mysterious gap.  Just sucks that it's really hard to tell for sure that's the reason for the gap.
[17:44] <kees> yup. but that's why I made it default-enabled in the compiler. ;)
[17:44] <infinity> kees: is this just main or all components?
[17:47] <infinity> "NOTE: In Ubuntu 8.10 and later versions, -D_FORTIFY_SOURCE=2 is set by default, and is activated when -O is set to 2 or higher."
[17:48] <infinity> kees: ^-- Do you recall if that hack included -Os?  s isn't technically "higher" than 2, more complementary.
[17:48] <kees> infinity: this is all components
[17:49] <infinity> Also holy crap, 8.10... That was eons ago.  We were both young and virbant humans, full of promise for the future.
[17:50] <kees> infinity: I don't know -- it's entirely handled by the glibc header files, IIRC
[17:50] <infinity> Oh, right.  I guess I could answer my own question there.
[17:52] <infinity>     && __GNUC_PREREQ (4, 1) && defined __OPTIMIZE__ && __OPTIMIZE__ > 0
[17:52] <infinity> So, the gcc manpage might be a lie.
[17:52] <infinity> Looks like it flips it on for -O > 0
[17:54] <kees> or it's changed in the last 9 years :P
[17:55] <infinity> Well, yes, I meant it's currently a lie. ;)
[17:55] <kees> ah, yes :)
[17:55] <kees> https://outflux.net/ubuntu/hardening/i386/main/  <- main-only
[17:55] <infinity> Oh, and __OPTIMIZE__ is just set to 1 for any -O that's not 0.
[17:55] <kees> (and evil axis less evil now)
[17:55] <infinity> I was expecting it to have useful information.
[17:55] <infinity> But whatever.
[17:58] <infinity> kees: http://paste.ubuntu.com/24646078/
[17:58] <infinity> So, that's nice.
[17:59] <kees> infinity: oh, cute. I really don't think that used to be the case.
[17:59] <rbasak> bmw: thanks! I'll use that.
[18:03] <infinity> kees: More curiously, I would expect printf(__STATIC_DEFINE__) would be optimisable away.  Maybe it's because I got clever and put the newline in.
[18:04] <infinity> Hrm, nope.
[18:05] <infinity> Ahh, replacing it with a string literal "1" optimises it away.
[18:06] <infinity> Need a smarter compiler.
[18:20] <infinity> kees: http://paste.ubuntu.com/24646299/ <-- Better test that actually compiles with -O0 to show how things work today.
[18:24] <infinity> kees: Is it possible that maybe gcc changed the meaning of __OPTIMIZE__?  Cause the glibc code in question hasn't changed since 2005.
[18:25] <infinity> (Or maybe the Ubuntu gcc manpage has been lying since forever)
=== sergiusens_ is now known as sergiusens
[20:54] <doko> jbicha, chrisccoulson: did the scrollbar behaviour in thunderbird on 16.04 did change by intent? clicking in the portion below the slider now scrolls to the relative position of the slider, not to the next screen
[20:56] <jbicha> doko: isn't that how the scrollbar in Firefox works? I believe Thunderbird 52 switched to gtk3
[20:57] <jbicha> don't you use other gtk3 apps?
[20:57] <doko> jbicha: no, but that definitely is a change in some recent update
[20:58] <doko> wondering why we get this in a stable release ...
[20:59] <jbicha> you're seriously wondering why we don't leave Thunderbird at version 45 forever?
[21:00] <doko> jbicha: was this a recent change in thunderbird, or in some gnome library?
[21:00] <jbicha> I believe the change is because Thunderbird 52 builds with gtk3 now
[21:00] <doko> ahh, ok. that might explain it
[21:01] <doko> can this behaviour be configured?
[21:01] <doko> hmm, probably not. at least it's gnome3 :-/
[21:01] <jbicha> I think it is configurable, but this should affect all gtk3 apps I would think…
[21:02] <jbicha> doko: try https://wiki.archlinux.org/index.php/GTK%2B#Legacy_scrolling_behavior
[21:03] <doko> ahh, ok
[21:12] <wxl> i don't know that i've ever quite understood the difference between SRUs and backports. that said, which direction to go with for 1251495?
[21:12] <wxl> bug 1251495 that is
[21:12] <ubottu> bug 1251495 in mailman (Ubuntu Trusty) "Lists with topics enabled can throw unexpected keyword argument 'Delete' exception." [High,Triaged] https://launchpad.net/bugs/1251495
[21:35] <infinity> wxl: backports are for bringing whole new versions back.  SRUs are for fixing bugs.  This is a single-char typo, clearly an SRU candidate.
[21:37] <wxl> k great thx :)
[22:39] <Unit193> jbicha: Re: Debian 863288.  The indicator stack is entirely unmaintained, orphaned, and unused in Debian.  The release is from 2012, and since then there have either been no releases, or very Ubuntu centric.  It doesn't make sense to recommend that in Debian.  https://anonscm.debian.org/cgit/users/unit193-guest/deluge.git/commit/?id=d65670c15990838b8b1b1447ac99ca5f5194fd23 is a much better option.
[22:39] <ubottu> Debian bug 863288 in deluge "deluge: Recommend python-appindicator" [Wishlist,Open] http://bugs.debian.org/863288
[22:41] <jbicha> Unit193: it's not entirely unmaintained in Debian, see Mike Gabriel's libdbusmenu and NEW uploads this week
[22:41] <Unit193> Right, those are forks.
[22:42] <jbicha> right, that's what I intend to talk to Mike about :)
[22:42] <Unit193> > #arctica
[22:42] <jbicha> because indicators are not really maintained in Ubuntu either…
[22:42] <sarnold> "congratulations mike you're the new indicators maintainer, pls rename your packages" ? :)
[22:43] <jbicha> sarnold: :)
[22:43] <Unit193> sarnold: He's stripping out the Canonical/Ubuntu specific bits, I think Ubuntu would object. :P
[22:44] <jbicha> he might have been stripping those because the Ubuntu packages were being actively maintained at the time, but not with the features he wanted
[22:50] <dasjoe> Just out of interest, why is https://login.launchpad.net/ not showing the same data as https://launchpad.net/~dasjoe?
[22:50] <dasjoe> My profile lists my full name, login.launchpad.net does not. Also, login.launchpad.net does not show my second (and preferred) email address at all
[22:51] <cjwatson> For better or worse, you have to set those separately in SSO (login.*)
[22:51] <cjwatson> There's some linkage between the two systems but it doesn't extend to synchronising that sort of data
[22:52] <dasjoe> I can't add the second email address, the token link shows chrome's (?!) 404
[22:52] <cjwatson> Should probably report that as a bug against canonical-identity-provider
[23:00] <dasjoe> cjwatson: thanks, filed
[23:16] <nicolas17> hi, is there a channel for Ubuntu infrastructure/sysadmins?
[23:17] <wxl> #canonical-sysadmins
[23:17] <wxl> oops
[23:17] <wxl> #canonical-sysadmin
[23:17] <nicolas17> thanks
[23:39] <nacc> rbasak: if you could look at http://paste.ubuntu.com/24648967/, first draft of the doc -- and maybe we can discuss tmrw after the team mtg?