=== maclin1 is now known as maclin
cpaelzernacc: I assume that came up on triage?05:30
cpaelzernacc: I usually do Author + Original-Author (in case they differ)05:31
cpaelzernacc: the former the one who writes the patch for the deb the latter being the one who originally wrote the code05:31
cpaelzernacc: as that usually starts with a git format patch most data is already around05:31
cpaelzernacc: but that reporter is from STS, he should know now more on patch style recommendations - I just gave him some early hints05:32
=== koza|away is now known as koza
=== JanC_ is now known as JanC
cpaelzerpitti: hi are you around for bug 169311509:10
ubottubug 1693115 in libvirt (Ubuntu) "apparmor denial: qemu cannot read /proc/*/cmdline " [Undecided,Incomplete] https://launchpad.net/bugs/169311509:10
pitticpaelzer: hello, how are you?09:11
cpaelzerpitti: great and I hope you are even greater09:11
cpaelzerpitti: good to see you around09:11
pitticpaelzer: I am, thanks!09:11
pitticpaelzer: ah yes, thanks for following up, I'll respond ASAP09:12
cpaelzerpitti: I was just answering the bug realizing that I could just as well ask you :-)09:12
cpaelzerpitti: thank you09:12
pittiI just found a regression in freeipa-client too09:12
pittiyay for starting to run integration tests on 17.04 (so far we only ran on 16.04)09:12
cpaelzerpitti: just want to check asap if it is a regression-update (which it hopefully isn't, but especially then I want to check)09:12
pitticpaelzer: 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 there09:13
cpaelzerpitti: it wants to tell people who shut it down09:13
cpaelzerpitti: I fixed that already09:13
cpaelzerpitti: but the proximity of my fix and your report made me suspicious09:14
pitticpaelzer: oh -- I built that image last week, it doesn't yet have the fix for #168038409:14
cpaelzerpitti: I put it in the bug09:14
cpaelzerpitti: yeah exactly - if you miss that then that is the explanation09:14
cpaelzerpitti: once you updated on your next run you can update and hopefully close the bug as fix released or dup09:15
pitticpaelzer: yes, I'll verify that -- upgrade the package on my test image, and re-run09:15
cpaelzerpitti: what is the interval you update your images?09:15
cpaelzerah sounds like on trigger, ok09:16
pitticpaelzer: normally ~weekly, but it's the first one ever, so I can rebuild one at will09:16
cpaelzerpitti: I saw you to avocado based test in cockpit, for a long time I was thinking of that but as usually you beat me09:16
cpaelzerpitti: one day I might copy a few bits from there09:16
pittithe test/verify/ ones are much more interesting though  :)09:17
cpaelzeryou mean the ones you run outside of autopkgtests for their complexity?09:17
pittiyep, I have 2.5.0-3ubuntu509:17
cpaelzerok, 5.1 should fix it for you then09:17
pitticpaelzer: right, I don't yet have an autopkgtest wrapper for test/verify09:17
pittijust a simple one09:17
pitticpaelzer: followed up, ♥09:20
cpaelzerthank you a lot pitti09:21
cpaelzerpitti: actually did you mean pro-actively instead of "retro" ?09:23
rbasakpdeee, 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 prepare09:40
jamespageany of the MIR team around? I need a review on https://bugs.launchpad.net/ubuntu/+source/vine/+bug/168809109:48
ubottuLaunchpad bug 1688091 in vine (Ubuntu) "[MIR] vine" [High,New]09:48
jamespagethat's holding most of OpenStack Pike b1 in proposed in artful right now09:48
rbasakbdmurray: did you intentionally not accept Trusty in bug 1690730?09:54
ubottubug 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/169073009:54
=== led2 is now known as led1
bdmurrayrbasak: No, it was not intentional.13:59
=== acheronuk is now known as acheronUK
nacccpaelzer: yeah -- is Original-Author a DEP3 header?15:19
rbasakdep3 just says to use Author multiple times as required.15:35
naccrbasak: right15:37
naccApplied-Upstream seems new15:38
mdeslaurrbasak: any progress from upstream about the mysql-5.7 autopkgtest failure?15:39
rbasakSkuggen: ^?15:40
naccrbasak: fyi, snap should be updated with your queue fix(es)15:42
naccrbasak: and figured out the two import failures, just refactor errors15:46
bmwrbasak: just now seeing your message about testing15:51
bmwbiggest thing is just running our unit tests included in the packages15:51
bmwthere's close to 100% coverage there15:51
rbasakbmw: can I do that from an installed system, rather than from the source tree?15:52
rbasakbmw: this is to catch packaging errors, for example if something's in the source tree but fails to end up in the deb.15:52
bmwgood 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 them15:53
bmwI'll see if he's around15:53
rbasakbmw: we can automate as-installed testing like this too - we call it dep8 (after our spec for how it works).15:55
rbasakbmw: 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:55
bdmurrayrbasak: I'll review mysql for Trusty now.15:59
bdmurrayrbasak: or maybe I mean postgresql - one of those database things16:00
naccbdmurray: that is what you meant :)16:01
naccrbasak: sigh, have time for a  HO after the certbot stuff?16:04
Skuggenrbasak: I mentioned the test fix for mysql 5.7 before (if it's the same failure)16:09
Skuggenmdeslaur:^ If it's the mysql_not_windows test failure?16:09
SkuggenOn Artful16:10
mdeslaurSkuggen: yeah, that's the one16:10
mdeslaurSkuggen: you mentioned it where?16:11
SkuggenMySQL package maintainer channel16:11
mdeslaurSkuggen, rbasak: is one of you going to do an upload, or do you want me to do it?16:13
nacccyphermox: is there a reason src:nplan contains a .git directory?16:15
cyphermoxI may have failed at uploading?16:15
* cyphermox sighs16:15
cyphermoxnacc: you can disregard...16:16
Skuggenmdeslaur: 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 first16:16
nacccyphermox: yeah, but it's there now and i need to think about how to handle it :)16:16
nacccyphermox: our importer gets pretty confused :)16:16
cyphermoxnacc: not sure I understand what you mean16:16
mdeslaurSkuggen: it's blocking other things from migrating, so I would prefer that16:17
Skuggenrbasak: ^16:17
SkuggenI don't have upload rights :)16:17
cyphermoxnacc: do as you prefer, it won't be there in next upload. Seems like an instance that ought to be handled anyway16:17
nacccyphermox: 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 it16:17
nacccyphermox: yep, needs to be handled16:17
mdeslaurSkuggen: I can sponsor your two commits that add the patch and the changelog if you want16:17
cyphermoxnacc: 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 already16:18
Skuggenmdeslaur: Sounds good to me16:18
mdeslaurok, will do in a few minutes16:18
mdeslaurthanks Skuggen, rbasak16:18
nacccyphermox: yep, it falls under the umbrella of 'thou shall not fail' (where thou is the importer) and 'import everything' :)16:19
cyphermoxnacc: 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 it16:19
nacccyphermox: yep16:20
nacccyphermox: just need to think about how, since we are also a .git directory :)16:20
naccs/are also/also have/16:20
cyphermoxwhat I'm saying is you'll get other instances than just nplan16:21
nacccyphermox: yep  agreed16:21
nacci wonder what dgit does16:21
cyphermoxwell, the issue in this case is that I should have used gbp to build the source package16:21
cyphermoxthat rips out .git from the source.16:22
naccah i see, dgit does that for imports too16:23
naccdgit: warning: removing from source package: ./.git16:23
cyphermoxnacc: and I agree nplan probably ought to be a 3.0 (native) rather than 1.0 format package.16:23
cyphermoxnacc: and that looks like it will avoid the issue in the future16:26
nacccyphermox: yep, i think so16:26
nacccyphermox: and i think at the same time, i'll push this fix to follow dgit's lead and remove .git/ from srcpkgs on import16:26
cyphermoxhrm, that seems wrong16:27
cyphermoxI mean, it's going to make things work, but then what you'll import won't actually be precisely what was in the upload16:27
nacccyphermox: 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:28
nacccyphermox: 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
cyphermoxnacc: 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 directory16:29
rbasakmdeslaur: thanks!16:29
nacccyphermox: ah i see what you mean16:29
cyphermoxnacc: the right solution would be setting GIT_DIR to something else for the imports.16:29
nacccyphermox: no, it's worse than that16:29
rbasakSkuggen: also thanks!16:29
nacccyphermox: what should `git clone` do?16:29
rbasaknacc: HO?16:29
naccrbasak: yes please16:30
rbasaknacc: standup URL?16:30
cyphermoxnacc: explode in flames? ;)16:30
nacccyphermox: yeah :)16:30
naccrbasak: yep16:30
cyphermoxnacc: I thought you used a tool to clone too16:30
nacccyphermox: right, but then that tool is now different than `git clone` which should always work too16:31
nacc(and is the default on LP)16:31
cyphermoxnacc: if there's no other way around, I suppose removing .git on import is the lesser evil16:31
naccrbasak: for context, LP: #169329016:31
ubottuLaunchpad bug 1693290 in usd-importer "Unable to import nplan (May 29, 2017)" [Undecided,New] https://launchpad.net/bugs/169329016:31
cyphermox(but you might want to ask others for their opinion)16:31
naccyep, and we're not necessarily doing this change forever16:32
cyphermoxnacc: well, yeah, for any source package that includes it..16:32
cyphermoxI wonder if you couldn't just fudge things by making britney very much dislike .git directories in source ;)16:32
nacccyphermox: tbh, this is the first srcpkg with this issue :)16:32
cyphermoxnacc: heh16:33
cyphermoxI'm happy to reupload if it makes your life easier.16:33
nacccyphermox: well, the history is still there, so it's ok :)(16:33
cyphermoxright, it won't solve history16:33
ddstreetcyphermox 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
ubottubug 1573272 in vlan (Ubuntu Artful) "default gateway route not installed for bond interfaces through reboot" [Medium,In progress] https://launchpad.net/bugs/157327216:37
ddstreeti can work on getting it sru'ed once it's in artful16:37
=== grumble2 is now known as grumble
cyphermoxddstreet: ok16:53
=== JanC_ is now known as JanC
bmwrbasak: while it's not exactly pretty, here's a pretty decent one line test that certbot and its plugins and dependencies are installed correctly17:25
bmwcertbot plugins --prepare | grep -q apache && certbot --help nginx | grep -q nginx-ctl17:25
keesinfinity: https://outflux.net/ubuntu/hardening/i386/ now being gathered/graphed. delta to amd64 wrt PIE is amd64:80% PIE, i386:55% PIE17:27
infinitykees: 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
infinitykees: (As in, I would have expected that delta to be higher)17:29
keesinfinity: 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
keesi.e. all-library package is counted as PIE17:30
keesand to distinguish from the stricter count ("has ET_DYN executable"), I left BINDNOW as it was counted before.17:31
keesso the difference between bindnow and pie is roughly the difference between packages with ET_DYN executables and packages without ET_EXEC.17:31
infinitykees: PS: The i386 graphs say "amd64" on the Y axis. ;)17:32
infinityWe'll call that the axis of evil.17:32
infinitykees: 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:34
keesgraph data!17:36
keesI could include the scan log?17:36
infinitykees: 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:36
keeswhen 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:37
kees- you don't use any scary functions, so nothing is replaced with ..._chk() version to be detected by the scanner17:38
infinityAhh.  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
infinityBuilt 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:38
infinityThat'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:39
keessure is. having "compiler flags" in some ELF note in binaries would be nice, but bloaty17:40
infinityThere's also "you build without optimisation because you're a bad person", but I want to know about those ones.17:40
keesoooh yes17:40
keesthat too!17:40
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:41
infinityBut 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:43
keesyup. but that's why I made it default-enabled in the compiler. ;)17:44
infinitykees: is this just main or all components?17:44
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:47
infinitykees: ^-- Do you recall if that hack included -Os?  s isn't technically "higher" than 2, more complementary.17:48
keesinfinity: this is all components17:48
infinityAlso holy crap, 8.10... That was eons ago.  We were both young and virbant humans, full of promise for the future.17:49
keesinfinity: I don't know -- it's entirely handled by the glibc header files, IIRC17:50
infinityOh, right.  I guess I could answer my own question there.17:50
infinity    && __GNUC_PREREQ (4, 1) && defined __OPTIMIZE__ && __OPTIMIZE__ > 017:52
infinitySo, the gcc manpage might be a lie.17:52
infinityLooks like it flips it on for -O > 017:52
keesor it's changed in the last 9 years :P17:54
infinityWell, yes, I meant it's currently a lie. ;)17:55
keesah, yes :)17:55
keeshttps://outflux.net/ubuntu/hardening/i386/main/  <- main-only17:55
infinityOh, 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
infinityI was expecting it to have useful information.17:55
infinityBut whatever.17:55
infinitykees: http://paste.ubuntu.com/24646078/17:58
infinitySo, that's nice.17:58
keesinfinity: oh, cute. I really don't think that used to be the case.17:59
rbasakbmw: thanks! I'll use that.17:59
infinitykees: 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:03
infinityHrm, nope.18:04
infinityAhh, replacing it with a string literal "1" optimises it away.18:05
infinityNeed a smarter compiler.18:06
infinitykees: http://paste.ubuntu.com/24646299/ <-- Better test that actually compiles with -O0 to show how things work today.18:20
infinitykees: Is it possible that maybe gcc changed the meaning of __OPTIMIZE__?  Cause the glibc code in question hasn't changed since 2005.18:24
infinity(Or maybe the Ubuntu gcc manpage has been lying since forever)18:25
=== sergiusens_ is now known as sergiusens
dokojbicha, 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 screen20:54
jbichadoko: isn't that how the scrollbar in Firefox works? I believe Thunderbird 52 switched to gtk320:56
jbichadon't you use other gtk3 apps?20:57
dokojbicha: no, but that definitely is a change in some recent update20:57
dokowondering why we get this in a stable release ...20:58
jbichayou're seriously wondering why we don't leave Thunderbird at version 45 forever?20:59
dokojbicha: was this a recent change in thunderbird, or in some gnome library?21:00
jbichaI believe the change is because Thunderbird 52 builds with gtk3 now21:00
dokoahh, ok. that might explain it21:00
dokocan this behaviour be configured?21:01
dokohmm, probably not. at least it's gnome3 :-/21:01
jbichaI think it is configurable, but this should affect all gtk3 apps I would think…21:01
jbichadoko: try https://wiki.archlinux.org/index.php/GTK%2B#Legacy_scrolling_behavior21:02
dokoahh, ok21:03
wxli 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
wxlbug 1251495 that is21:12
ubottubug 1251495 in mailman (Ubuntu Trusty) "Lists with topics enabled can throw unexpected keyword argument 'Delete' exception." [High,Triaged] https://launchpad.net/bugs/125149521:12
infinitywxl: backports are for bringing whole new versions back.  SRUs are for fixing bugs.  This is a single-char typo, clearly an SRU candidate.21:35
wxlk great thx :)21:37
Unit193jbicha: 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
ubottuDebian bug 863288 in deluge "deluge: Recommend python-appindicator" [Wishlist,Open] http://bugs.debian.org/86328822:39
jbichaUnit193: it's not entirely unmaintained in Debian, see Mike Gabriel's libdbusmenu and NEW uploads this week22:41
Unit193Right, those are forks.22:41
jbicharight, that's what I intend to talk to Mike about :)22:42
Unit193> #arctica22:42
jbichabecause indicators are not really maintained in Ubuntu either…22:42
sarnold"congratulations mike you're the new indicators maintainer, pls rename your packages" ? :)22:42
jbichasarnold: :)22:43
Unit193sarnold: He's stripping out the Canonical/Ubuntu specific bits, I think Ubuntu would object. :P22:43
jbichahe might have been stripping those because the Ubuntu packages were being actively maintained at the time, but not with the features he wanted22:44
dasjoeJust out of interest, why is https://login.launchpad.net/ not showing the same data as https://launchpad.net/~dasjoe?22:50
dasjoeMy profile lists my full name, login.launchpad.net does not. Also, login.launchpad.net does not show my second (and preferred) email address at all22:50
cjwatsonFor better or worse, you have to set those separately in SSO (login.*)22:51
cjwatsonThere's some linkage between the two systems but it doesn't extend to synchronising that sort of data22:51
dasjoeI can't add the second email address, the token link shows chrome's (?!) 40422:52
cjwatsonShould probably report that as a bug against canonical-identity-provider22:52
dasjoecjwatson: thanks, filed23:00
nicolas17hi, is there a channel for Ubuntu infrastructure/sysadmins?23:16
naccrbasak: 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?23:39

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!