[00:15] <juliank> Seriously? My upload was rejected with "Symbolic link for debian/copyright not allowed", but it syncs fine from Debian?
[00:15]  * juliank is annoyed
[00:15] <juliank> I guess I go back to no debian/copyright at all
[00:16] <juliank> (No, it's not required to have one. apt never had one, it installed COPYING instead. Now I made copyright a symlink to that)
[00:20] <juliank> I mean: Why? I don't want to have that file twice in the package, and a symlink is better than just installing the file in the upstream part.
[00:23]  * juliank uploaded a fixed build now, tomorrow we'll see if something breaks
[00:23]  * juliank goes to bed
[00:37] <cyphermox> ahoneybun: I don't think it *has* to be that size, but the aspect ratio for things matter, since they really should show in that panel size -- the size of the slideshow shouldn't vary from slide to slide, or from flavor to flavor
=== stokachu_ is now known as stokachu
=== juliank_ is now known as juliank
[02:20] <ahoneybun> cyphermox: at the moment ours is broken since Qt4 dropped Webkit
=== salem_ is now known as _salem
[05:22] <cpaelzer> good morning
[06:38] <doko> juliank, apt test failures on ppc64el
=== davidcalle|afk is now known as davidcalle
[06:59]  * xnox only 16 more merges to go....
=== hikiko is now known as hikiko|afk
[08:09] <juliank> doko: Thanks, I'm about to look into this
[08:10] <doko> juliank, this is likely LP: #1473674. but at this time, we couldn't distill a test case.  maybe you see the same when building with -O3 on amd64
[08:10] <ubottu> Launchpad bug 1473674 in apt (Ubuntu Wily) "apt fails a test from the testsuite on ppc64el when built with gcc-5 and -O3" [High,Confirmed] https://launchpad.net/bugs/1473674
[08:12] <juliank> doko: Probably. There's also a real bug in the stringview tests, though (comparing data() with to_string(), where data() might not be nul-terminted). I accidentally turned the test suite to actually fail the build at build time with the cmake switch; I think I'm going to revert this. Too much inexplicable noise on exotic platforms
[08:14] <juliank> Well, I can also switch ppc64el to -O2 in addition
[08:15] <juliank> doko: Oh, your -O2 rebuild even hid the real test failure
[08:16] <doko> juliank, a test case would be nice. still not convinced that this is a compiler issue
[08:23] <juliank> doko: Well, there are only two previous returns in the function called before it sets the InfoDir variable. and I don't see how those could fail. I guess I'd have to look at the binaries, but I don't really speak much ppc64el
[08:24] <juliank> Well, and we don't have any, obviously, because the -O3 build failed due to the test suite ...
[08:31] <doko> The following tests FAILED:
[08:31] <doko>           1 - AptTests (Failed)
[08:32] <doko> juliank, ^^^ on amd64 with -O3
[08:33] <juliank> doko: Same failure? (MIght need to set CTEST_OUTPUT_ON_FAILURE=1 if you're running manually)
[08:34] <juliank> I'm letting it build at -O3 now too
[08:40] <juliank> doko: I cannot reproduce this on Debian at least (with gcc 6.1.1-11), still have to try in my yakkety env.
[08:50] <juliank> doko: In the Ubuntu env (with gcc -10ubuntu11), I see test failures with -O3, but not in CDROM. Basically the string_view thing I already mentioned, and some weird random failures I don't know what to think about
[08:51] <doko> juliank, the only difference should be PIE turned on by default. ok, so the CDROM thing is ppc64el specific, as it was already before
[08:55] <LocutusOfBorg> please somebody ignore systemd/ppc64el autopkgtestsuite, for gnutls30, and retry the network-manager one
[08:58] <juliank> doko: I had a DSL reconnect, what was the last line that arrived?
[09:13] <Unit193> < juliank> doko: In the Ubuntu env.....
[09:13] <juliank> Ah OK
[09:13] <Unit193> (And he responded.)
[09:14] <juliank> I can say with -11ubuntu12 things look a bit better even
[09:14] <juliank> Unit193: anything interesting in the response?
[09:33] <ginggs> [10:50:28] <juliank> doko: In the Ubuntu env (with gcc -10ubuntu11), I see test failures with -O3, but not in CDROM. Basically the string_view thing I already mentioned, and some weird random failures I don't know what to think about
[09:33] <ginggs> [10:51:16] <doko> juliank, the only difference should be PIE turned on by default. ok, so the CDROM thing is ppc64el specific, as it was already before
[09:34] <juliank> Thanks ginggs
[09:38] <Unit193> Sorry.
[09:55] <ogra_> any archive admins around ? i need the score bumped on https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel/+build/2796
[10:00] <xnox> they all are cleaning, looks suspicious.
[10:02] <ogra_> xnox, the arm arches are slow since last friday ... (and often lie in the estimated time ... telling you "starts in 20min" for multiple hours)
[10:02] <xnox> ogra_, i'm not sure why, i've just uploaded a package and it started to build on armhf....
[10:02] <xnox> i guess i jumped the queue somehow?
[10:02] <xnox> Build score:2510 (What's this?)
[10:02] <xnox> Start in 8 minutes (2505) What's this? -> that's you
[10:03]  * xnox ponders why you are 5 points lower
[10:04] <ogra_> because i'm a snap perhaps
[10:04] <ogra_> or because i build against a PPA
[10:11] <cjwatson> snaps are all 2505 + <relative_build_score of archive>
[10:13] <cjwatson> maybe it would be fairer to have the baseline be 2510 these days, because most uploads are priority: medium
[10:13] <cjwatson> urgency=medium I mean
[10:13] <xnox> yeah
[10:14] <cjwatson> so the effect ogra_ is seeing is probably mainly that the queue of .dsc builds to perform is rarely empty, and that snaps effectively only get to build after all of those
[10:14] <cjwatson> ditto recipes and livefses
[10:15] <cjwatson> ogra_: I've bumped that build's score and I'll look at making the defaults a bit fairer
[10:15] <ogra_> can https://code.launchpad.net/~snappy-dev/+snap/canonical-snapdragon-linux/+build/2797 be bumped too please ?
[10:15] <ogra_> cjwatson, thanks !
[10:16] <cjwatson> ogra_: done
[10:16] <ogra_> merci :)
[10:19] <ogra_> uhm, oh
[10:19] <ogra_> bzr: ERROR: Invalid url supplied to transport: "bzr+ssh://bazaar.launchpad.net/~ogra/+junk/canonical-snapdragon-linux-snap": no supported schemes
[10:19] <ogra_> (https://code.launchpad.net/~snappy-dev/+snap/canonical-snapdragon-linux)
[10:20] <ogra_> i assume the team cant use my personal branch here ?
[10:21] <ogra_> so lets try that again with me as the snap owner
[10:22] <xnox> ogra_, +git, not +junk
[10:22] <ogra_> :P
[10:22]  * xnox trolling
[10:23] <ogra_> yeah, i'll switdh all that stuff to git eventually ...
[10:23] <cjwatson> it should be fine with +junk branches; but you deleted that snap before I could look at what the problem was
[10:23] <dbarth> hey guys, i'm trying to get an SRU for account-plugins to -proposed
[10:23] <ogra_> cjwatson, i only switched the name ...
[10:23] <dbarth> it's sitting in the UNAPPROVED queue, as silo 062
[10:23] <ogra_> cjwatson, https://launchpad.net/~ogra/+snap/canonical-snapdragon-linux/+build/2797
[10:24] <dbarth> the reference bug is: https://bugs.launchpad.net/gnome-control-center-signon/+bug/1565772
[10:24] <ubottu> Launchpad bug 1565772 in gnome-control-center-signon (Ubuntu Xenial) "[SRU] Allow plugins to decide which username to set on new accounts" [Critical,Confirmed]
[10:24] <cjwatson> ogra_: that looks like either a transient failure or a firewall bug
[10:24] <ogra_> oh+
[10:24] <cjwatson> I doubt that the path has anything to do with it
[10:24] <ogra_> well, the bzr login stuff above the error made me thing the account is related
[10:25] <cjwatson> I suspect you thought wrong
[10:25] <cjwatson> buildds obviously don't have an actual Launchpad login to use
[10:26] <ogra_> for that snap it isnt that important who owns it, it will be re-named once we get a proper name ... and will then get its own project ... new buuild is triggered, lets see if it was transient
[10:26] <cjwatson> so you should generally expect to see that warning
[10:26] <ogra_> ok
[10:26] <cjwatson> (well, perhaps that isn't obvious, but it's nevertheless true)
[10:36] <doko> seb128, Laney: are you planning a gedit merge? if not then we need a no-change upload for nbs
[10:42] <ogra_> cjwatson, worked the second time
[10:42] <cjwatson> ok, must be terrible presentation by bzr of a transient error, I guess
[10:43] <juliank> Can we please fix the upload queue thing to allow packages where debian/copyright is a symlink? It works for syncs, I really don't want to cp my target to debian/copyright before doing an ubuntu-specific upload. And no, I neither want to ship copyright information twice in apt, nor do I only want it in debian/. We previously had no debian/copyright at all and that produced less issues than this symlink :(
[10:44] <juliank> That is, apt ships it's copyright info in the top-level COPYING file
[10:44] <juliank> (aka upstream part, if we ever get non-native)
[10:44] <cjwatson> juliank: can't do straight away, please file a bug against Launchpad; at the time we wrote it I'm pretty sure our check matched Debian ftpmaster so we need to check what the current one is
[10:47] <juliank> cjwatson: Sure https://bugs.launchpad.net/launchpad/+bug/1612612
[10:47] <ubottu> Launchpad bug 1612612 in Launchpad itself "Should not reject packages where debian/copyright is symlink" [Undecided,New]
=== hikiko|afk is now known as hikiko
[11:52] <seb128> doko, jbicha is looking at it but he's blocked by gspell test issues
[12:17] <sitter> mvo: yo. python-apt changes I mentioned in Heidelberg, was wondering if you have some thoughts on the direction https://github.com/apachelogger/python-apt/commits/aptsources-distro-os-release also I have no clue how one would propose them for inclusion in the debian repo :S
[12:23] <juliank> sitter: Basically just say something and mvo or I will merge them
[12:23] <sitter> that's easy then. thanks
[12:24] <juliank> I really need to get a 1.1 release out at some point, apt is already at 1.3 ...
[12:25] <juliank> It's just fairly annoying work to port this away from the deprecated API to the new one, so we end up with the "beta" (aka still using deprecated stuff) releases
[12:26] <mvo> sitter: what juliank said
[12:27] <mvo> sitter: from a quick look looks fine, there is a debug print() in there still
[12:27] <mvo> sitter: (but I guess you know that :)
[12:28] <sitter> yeah. it's basically the working tree I abandoned in favor of the simpler workaround ;)
[12:30] <juliank> doko: I revised your apt workaround a bit to take care of noopt, and prepend instead of append, and arrived at https://github.com/Debian/apt/compare/master...julian-klode:bugfix/gcc?expand=1
[12:31] <juliank> Probably going to merge this for RC2
[12:35] <juliank> sitter: Should probably use the official VERSION_CODENAME instead of / in addition to UBUNTU_CODENAME
[12:37] <juliank> see bug #1598212
[12:38] <ubottu> bug 1598212 in base-files (Ubuntu) "/etc/os-release: Please specify VERSION_CODENAME" [Undecided,New] https://launchpad.net/bugs/1598212
[12:39] <sitter> *nod*
[12:40] <juliank> Someone needs to fix fakeroot? dlsym(acl_get_file): /usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so: undefined symbol: acl_get_file
[12:40] <juliank> This breaks a lot of the APT test suite in the glibc migration
[12:41] <juliank> I have no clue what's going on there.
[12:41] <juliank> I already saw this in the build logs that night
[12:42] <juliank> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830912
[12:42] <ubottu> Debian bug 830912 in fakeroot "fakeroot complains about missing acl_* symbols" [Normal,Open]
[12:42] <juliank> glibc fixes "Report dlsym, dlvsym lookup errors using dlerror [BZ #19509]"
[12:44] <juliank> meh, I guess I'll take a look at it. Most apt bugs are fixed now anyway, so I have time
[13:16] <juliank> Well, it was a good idea, but it hang up my system
[13:18]  * juliank hopes schroot will use cgroups at some point, so the chroot processes can be grouped and killed reliably
=== JanC is now known as Guest34729
=== JanC_ is now known as JanC
[13:20] <sitter> juliank: I did some minor polishing, should be good for merge now https://github.com/apachelogger/python-apt/commits/aptsources-distro-os-release
[13:21] <sitter> mvo: FWIW, that's what the software-properties side of things will look like http://bazaar.launchpad.net/~apachelogger/software-properties/python-apt-is-like/revision/970 (basically restricting the match further by requiring that the the local distro `is_like` the distro of the PPA)
[13:25] <mvo> sitter: thanks
[13:25] <juliank> sitter: Can you squash those commits together?
[13:28] <juliank> I cannot reproduce the fakeroot warning issue in my yakkety system, but it seems like that should work around it: https://paste.ubuntu.com/23049438/
[13:28] <sitter> juliank: done
=== _salem is now known as salem_
[13:32] <juliank> sitter: Some more stuff, use line.split("=", 1) in case there are multiple = - Your ID_LIKE use does not match the spec/manpage: ID_LIKE should be ID_LIKE="ubuntu debian", not unquoted.
[13:33] <juliank> Relevant quotes: (1) Variable assignment values must be enclosed in double or single quotes if they include spaces
[13:33] <juliank> (2) Example: for an operating system with "ID=centos", an assignment of "ID_LIKE="rhel fedora"" would be appropriate
[13:34] <sitter> hm
[13:34] <juliank> I know, right?
[13:34] <sitter> worse yet, that is actually the production os-release file from kde neon, so it is actually broken there ^^
[13:43] <cjwatson> ogra_: https://code.launchpad.net/~cjwatson/launchpad/fairer-build-scores/+merge/302807 FYI
[13:43] <juliank> I uploaded a work around for the tons of fakeroot warnings now
[13:43] <ogra_> cjwatson, yay, thanks !
[13:43] <juliank> It's not optimal as it just hides the errors again, but better than having them printed in every build and test log (and making the apt testsuite fail)
[13:45] <sitter> juliank: I pushed fixes for both
[13:49] <juliank> sitter: Fails on Debian unstable: aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for debian/None
[13:50] <juliank> Probably because VERSION_* is not specified
[13:51] <sitter> juliank: yes
[13:51] <sitter> probably should fall back to LSB if a field is None
[14:01] <sitter> juliank: http://paste.ubuntu.com/23049533/ any objections to this solution? reads both, then gets os-release value unless it is None, in which case it gets the value from lsb_release
[14:03] <juliank> doko: <DonKult> juliank: so, I tried building apt on the pcc64el porterbox… and I can reproduce the -O3 thing there. And I can fix it… e.g. by adding "CD = CD;" in apt-pkg/cdrom.cc at line 68 (<- right after we might have set InfoDir). Haven't played much more yet, but if that isn't screaming compiler bug I don't know what is.
[14:06] <juliank> sitter: You can use this.get(key) or that.get(key) instead of this.get(key) if this.get(key) else that.get(key)
[14:24] <sitter> juliank: cool. pushed
[14:47] <cyphermox> juliank: did the way apt reports progress on Status-Fd change recently?
[15:01] <juliank> cyphermox: Well, rc1 in proposed might report some more stuff
[15:01] <juliank> But apart from that, I'm not sure
[15:04] <juliank> sitter: Still fails, though - not sure why: aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for debian/sid
[15:07] <sitter> juliank: template's are case sensitive, ID supposedly is lowercase in os-release. so it should be Debian/sid but is debian/sid
[15:07] <juliank> Ah, right
[15:07] <sitter> I am thinking either the template system should be case indepdnent or os-release on debian needs changing. former sounds more appropriate xD
[15:08] <juliank> hmm, that's work :(
[15:08] <sitter> ID actually is specified as lower case, so yeah, template lookup needs changing :/
[15:09] <sitter> hm
[15:11] <sitter> juliank: http://paste.ubuntu.com/23049655/ should be as trivial as this if I am understanding the code correctly
[15:12] <juliank> sitter: Well, try it out. Run PYTHONPATH=$PWD ./tests/test_all.py (or ./tests/test_aptsources.py)
[15:12] <juliank> same problem should happen on Ubuntu too
[15:13]  * juliank did not check that yet :D
[15:14]  * juliank is about to start cooking and also fixing apt bugs or at least merging the commits he did earlier
[15:15] <cyphermox> juliank: ok, because it looks like progress percentage is now reported on Status-Fd is localized
[15:15] <cyphermox> ie. percentage may be 33.333 or 33,333
[15:16] <cyphermox> hrm, maybe it's not apt
[15:25] <doko> juliank, yes, but trying to reduce this to a simple reproducer doesn't look that easy. Can you come up with a test case which doesn't involve the library?
[15:27] <juliank> doko: DonKult is looking into it
[15:28] <doko> infinity, fakeroot probably needs an update for dropped (?) glibc symbols?
[15:29] <juliank> doko: I updated fakeroot to silence the warning
[15:29] <juliank> doko: glibc now added error reporting to dlsym() which was not there before
[15:29] <juliank> The acl symbols mentioned were never in libc in the first place
[15:30]  * juliank is not sure what the right course of action for this is longer term
[15:31] <juliank> This at least brings is back to the 2.23 state.
[15:31]  * juliank mostly cares because it breaks the apt tests ...
[15:35] <doko> juliank, one more thing: https://bugs.launchpad.net/bugs/1584118  how is a package selected when I only install the virtual name?
[15:35] <ubottu> Launchpad bug 1584118 in openjdk-9 (Ubuntu) "16.04 incorrectly installs openjdk-9 to satisfy java8-runtime dependency" [Undecided,Incomplete]
[15:35] <sitter> juliank: lower on both sides makes test_aptsources pass with ID=ubuntu. That's however not actually useful at all. e.g. I also noticed the if-wall in get_distro() is comparing with "Ubuntu" etc.. So I am thinking this either needs a concious API compatibility break in that distro ids get downcased consistently and file mapping/matching ignores case, or we do a weird hack and use os-release NAME instead of ID (which IMO would defeat the purpose
[15:35] <sitter> and require random splitting), or we change the patch to only grab is_like out of os-release and continue to take the rest from lsb (least invasive)
[15:36] <sitter> If we assume os-release is the long-term target I doubt a compatibility break will be avoidable
[15:36] <juliank> doko: I don't really know in detail. I guess it just fits the first package it sees
[15:37] <doko> ok
[15:37] <doko> mvo, ^^^
[15:38] <juliank> doko: I'd simply create a real package with the virtual name and let it depend on the preferred one. This has guaranteed semantics
[15:39] <juliank> Relying on APT's implementation details is not such a good idea.
[15:39] <infinity> doko: IIRC, it picks the virtual provider with the highest sort order (cf: the time when libfooN-dev used to provide libfoo-dev, and we wanted "Build-Depends: libfoo-dev" to usually pick the highest)
[15:40] <infinity> doko: But, as juliank says, relying on even that is a poor substitute for forcing the issue.
[16:03] <infinity> juliank: You referenced the Debian bug in your fakeroot upload, but didn't forward the patch to the Debian bug? :P
[16:07] <juliank> infinity: Not yet at least, but the idea was mentioned in that bug
=== danwest_ is now known as danwest
[16:09] <infinity> juliank: Yeah.  But a quick "submittodebian" turning Aurelien's suggestion into an actual patch is always nice. :)
[16:10] <juliank> infinity: Right. Later on. I just wonder: Did I really leave the Bug-Ubuntu field with <bugnumber> int it?
[16:10] <juliank> I have no idea how that happened
[16:10] <infinity> juliank: Yes, you really did. ;)
[16:11] <infinity> juliank: I wasn't going to point that out. :P
[16:13] <juliank> I have to cook now, but I'll try to send the patch out
[16:18] <juliank> infinity: done
[17:35] <tyhicks> bdmurray: hey - are you ok with me re-adding the verification-done tag to bug 1528230 after the last two comments that I left?
[17:35] <ubottu> bug 1528230 in apparmor (Ubuntu Xenial) "[ADT test failure] linux: ubuntu_qrt_apparmor.test-apparmor.py -- ONEXEC - check current 'unconfined' != expected" [Medium,Fix committed] https://launchpad.net/bugs/1528230
[17:53] <juliank> doko: that seems to be the culprit: https://paste.debian.net/788746/
[17:53] <juliank> For whatever reasons DirectoryExists() had __attribute__((const))
[17:53] <juliank> Still not sure how the compiler completely optimises that away, though
[17:54] <juliank> It must think that DirectoryExists(<string constant ".disk">) always is false
[17:54] <juliank> or rather, that it must be false at some point
[18:02] <juliank> I think because it is a string literal, the compiler assumes that because we cannot know the address of the literal, we cannot make a defined choice in DirectoryExists(), and thus drops the whole part
[18:17] <dobey> sigh
[18:43] <juliank> Apparently the code is not dropped, but the input is some garbage instead of the actual value.
[18:44] <juliank> Which makes sense: If the function is const and takes a reference, and you pass it one constant, it must have the same result if I replace the constant with garbage.
[18:44] <juliank> s/constant/literal/
[19:15] <juliank> Did something change on the autopkgtest systems? It seems as if  acquire::https::proxy is set to "direct" - APT does not understand this, only "DIRECT".
[19:15] <juliank> The apport tests thus fail with Unsupported proxy configured: direct:
[19:19] <juliank> Nevermind, apport test suite is broken and we now added a check for invalid proxy methods...
[19:19] <juliank> Will upload fixed apport in a few minutes
[19:26] <juliank> should be fixed in -0ubuntu6
[19:59] <slangasek> mterry: hrm, why is /etc/lightdm/lightdm.conf.d/90-phablet.conf being injected by livecd-rootfs, instead of being shipped in the lxc-android-config package?
[20:04] <mterry> slangasek: I'm not sure; I likely made it originally though.  It should probably move
[20:09] <slangasek> ah, I see, this file is 3 years old already, I thought it was added in the latest upload :)
[20:10] <slangasek> but yes, your name is on the original commit also :)
[20:16] <bdmurray> tyhicks: yes, that makes sense to me
[20:17] <tyhicks> bdmurray: ok, thank you
=== salem_ is now known as _salem