juliankSeriously? My upload was rejected with "Symbolic link for debian/copyright not allowed", but it syncs fine from Debian?00:15
* juliank is annoyed00:15
juliankI guess I go back to no debian/copyright at all00:15
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:16
juliankI 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:20
* juliank uploaded a fixed build now, tomorrow we'll see if something breaks00:23
* juliank goes to bed00:23
cyphermoxahoneybun: 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 flavor00:37
=== stokachu_ is now known as stokachu
=== juliank_ is now known as juliank
ahoneybuncyphermox: at the moment ours is broken since Qt4 dropped Webkit02:20
=== salem_ is now known as _salem
cpaelzergood morning05:22
dokojuliank, apt test failures on ppc64el06:38
=== davidcalle|afk is now known as davidcalle
* xnox only 16 more merges to go....06:59
=== hikiko is now known as hikiko|afk
juliankdoko: Thanks, I'm about to look into this08:09
dokojuliank, 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 amd6408:10
ubottuLaunchpad 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/147367408:10
juliankdoko: 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 platforms08:12
juliankWell, I can also switch ppc64el to -O2 in addition08:14
juliankdoko: Oh, your -O2 rebuild even hid the real test failure08:15
dokojuliank, a test case would be nice. still not convinced that this is a compiler issue08:16
juliankdoko: 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 ppc64el08:23
juliankWell, and we don't have any, obviously, because the -O3 build failed due to the test suite ...08:24
dokoThe following tests FAILED:08:31
doko          1 - AptTests (Failed)08:31
dokojuliank, ^^^ on amd64 with -O308:32
juliankdoko: Same failure? (MIght need to set CTEST_OUTPUT_ON_FAILURE=1 if you're running manually)08:33
juliankI'm letting it build at -O3 now too08:34
juliankdoko: I cannot reproduce this on Debian at least (with gcc 6.1.1-11), still have to try in my yakkety env.08:40
juliankdoko: 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 about08:50
dokojuliank, the only difference should be PIE turned on by default. ok, so the CDROM thing is ppc64el specific, as it was already before08:51
LocutusOfBorgplease somebody ignore systemd/ppc64el autopkgtestsuite, for gnutls30, and retry the network-manager one08:55
juliankdoko: I had a DSL reconnect, what was the last line that arrived?08:58
Unit193< juliank> doko: In the Ubuntu env.....09:13
juliankAh OK09:13
Unit193(And he responded.)09:13
juliankI can say with -11ubuntu12 things look a bit better even09:14
juliankUnit193: anything interesting in the response?09:14
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 about09: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 before09:33
juliankThanks ginggs09:34
ogra_any archive admins around ? i need the score bumped on https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel/+build/279609:55
xnoxthey all are cleaning, looks suspicious.10:00
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
xnoxogra_, i'm not sure why, i've just uploaded a package and it started to build on armhf....10:02
xnoxi guess i jumped the queue somehow?10:02
xnoxBuild score:2510 (What's this?)10:02
xnoxStart in 8 minutes (2505) What's this? -> that's you10:02
* xnox ponders why you are 5 points lower10:03
ogra_because i'm a snap perhaps10:04
ogra_or because i build against a PPA10:04
cjwatsonsnaps are all 2505 + <relative_build_score of archive>10:11
cjwatsonmaybe it would be fairer to have the baseline be 2510 these days, because most uploads are priority: medium10:13
cjwatsonurgency=medium I mean10:13
cjwatsonso 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 those10:14
cjwatsonditto recipes and livefses10:14
cjwatsonogra_: I've bumped that build's score and I'll look at making the defaults a bit fairer10: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:15
cjwatsonogra_: done10:16
ogra_merci :)10:16
ogra_uhm, oh10:19
ogra_bzr: ERROR: Invalid url supplied to transport: "bzr+ssh://bazaar.launchpad.net/~ogra/+junk/canonical-snapdragon-linux-snap": no supported schemes10:19
ogra_i assume the team cant use my personal branch here ?10:20
ogra_so lets try that again with me as the snap owner10:21
xnoxogra_, +git, not +junk10:22
* xnox trolling10:22
ogra_yeah, i'll switdh all that stuff to git eventually ...10:23
cjwatsonit should be fine with +junk branches; but you deleted that snap before I could look at what the problem was10:23
dbarthhey guys, i'm trying to get an SRU for account-plugins to -proposed10:23
ogra_cjwatson, i only switched the name ...10:23
dbarthit's sitting in the UNAPPROVED queue, as silo 06210:23
ogra_cjwatson, https://launchpad.net/~ogra/+snap/canonical-snapdragon-linux/+build/279710:23
dbarththe reference bug is: https://bugs.launchpad.net/gnome-control-center-signon/+bug/156577210:24
ubottuLaunchpad 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
cjwatsonogra_: that looks like either a transient failure or a firewall bug10:24
cjwatsonI doubt that the path has anything to do with it10:24
ogra_well, the bzr login stuff above the error made me thing the account is related10:24
cjwatsonI suspect you thought wrong10:25
cjwatsonbuildds obviously don't have an actual Launchpad login to use10:25
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 transient10:26
cjwatsonso you should generally expect to see that warning10:26
cjwatson(well, perhaps that isn't obvious, but it's nevertheless true)10:26
dokoseb128, Laney: are you planning a gedit merge? if not then we need a no-change upload for nbs10:36
ogra_cjwatson, worked the second time10:42
cjwatsonok, must be terrible presentation by bzr of a transient error, I guess10:42
juliankCan 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:43
juliankThat is, apt ships it's copyright info in the top-level COPYING file10:44
juliank(aka upstream part, if we ever get non-native)10:44
cjwatsonjuliank: 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 is10:44
juliankcjwatson: Sure https://bugs.launchpad.net/launchpad/+bug/161261210:47
ubottuLaunchpad bug 1612612 in Launchpad itself "Should not reject packages where debian/copyright is symlink" [Undecided,New]10:47
=== hikiko|afk is now known as hikiko
seb128doko, jbicha is looking at it but he's blocked by gspell test issues11:52
sittermvo: 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 :S12:17
julianksitter: Basically just say something and mvo or I will merge them12:23
sitterthat's easy then. thanks12:23
juliankI really need to get a 1.1 release out at some point, apt is already at 1.3 ...12:24
juliankIt'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) releases12:25
mvositter: what juliank said12:26
mvositter: from a quick look looks fine, there is a debug print() in there still12:27
mvositter: (but I guess you know that :)12:27
sitteryeah. it's basically the working tree I abandoned in favor of the simpler workaround ;)12:28
juliankdoko: 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=112:30
juliankProbably going to merge this for RC212:31
julianksitter: Should probably use the official VERSION_CODENAME instead of / in addition to UBUNTU_CODENAME12:35
julianksee bug #159821212:37
ubottubug 1598212 in base-files (Ubuntu) "/etc/os-release: Please specify VERSION_CODENAME" [Undecided,New] https://launchpad.net/bugs/159821212:38
juliankSomeone needs to fix fakeroot? dlsym(acl_get_file): /usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so: undefined symbol: acl_get_file12:40
juliankThis breaks a lot of the APT test suite in the glibc migration12:40
juliankI have no clue what's going on there.12:41
juliankI already saw this in the build logs that night12:41
juliankSee https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=83091212:42
ubottuDebian bug 830912 in fakeroot "fakeroot complains about missing acl_* symbols" [Normal,Open]12:42
juliankglibc fixes "Report dlsym, dlvsym lookup errors using dlerror [BZ #19509]"12:42
juliankmeh, I guess I'll take a look at it. Most apt bugs are fixed now anyway, so I have time12:44
juliankWell, it was a good idea, but it hang up my system13:16
* juliank hopes schroot will use cgroups at some point, so the chroot processes can be grouped and killed reliably13:18
=== JanC is now known as Guest34729
=== JanC_ is now known as JanC
sitterjuliank: I did some minor polishing, should be good for merge now https://github.com/apachelogger/python-apt/commits/aptsources-distro-os-release13:20
sittermvo: 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:21
mvositter: thanks13:25
julianksitter: Can you squash those commits together?13:25
juliankI 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
sitterjuliank: done13:28
=== _salem is now known as salem_
julianksitter: 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:32
juliankRelevant quotes: (1) Variable assignment values must be enclosed in double or single quotes if they include spaces13:33
juliank(2) Example: for an operating system with "ID=centos", an assignment of "ID_LIKE="rhel fedora"" would be appropriate13:33
juliankI know, right?13:34
sitterworse yet, that is actually the production os-release file from kde neon, so it is actually broken there ^^13:34
cjwatsonogra_: https://code.launchpad.net/~cjwatson/launchpad/fairer-build-scores/+merge/302807 FYI13:43
juliankI uploaded a work around for the tons of fakeroot warnings now13:43
ogra_cjwatson, yay, thanks !13:43
juliankIt'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:43
sitterjuliank: I pushed fixes for both13:45
julianksitter: Fails on Debian unstable: aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for debian/None13:49
juliankProbably because VERSION_* is not specified13:50
sitterjuliank: yes13:51
sitterprobably should fall back to LSB if a field is None13:51
sitterjuliank: 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_release14:01
juliankdoko: <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:03
julianksitter: You can use this.get(key) or that.get(key) instead of this.get(key) if this.get(key) else that.get(key)14:06
sitterjuliank: cool. pushed14:24
cyphermoxjuliank: did the way apt reports progress on Status-Fd change recently?14:47
juliankcyphermox: Well, rc1 in proposed might report some more stuff15:01
juliankBut apart from that, I'm not sure15:01
julianksitter: Still fails, though - not sure why: aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for debian/sid15:04
sitterjuliank: template's are case sensitive, ID supposedly is lowercase in os-release. so it should be Debian/sid but is debian/sid15:07
juliankAh, right15:07
sitterI am thinking either the template system should be case indepdnent or os-release on debian needs changing. former sounds more appropriate xD15:07
juliankhmm, that's work :(15:08
sitterID actually is specified as lower case, so yeah, template lookup needs changing :/15:08
sitterjuliank: http://paste.ubuntu.com/23049655/ should be as trivial as this if I am understanding the code correctly15:11
julianksitter: Well, try it out. Run PYTHONPATH=$PWD ./tests/test_all.py (or ./tests/test_aptsources.py)15:12
julianksame problem should happen on Ubuntu too15:12
* juliank did not check that yet :D15:13
* juliank is about to start cooking and also fixing apt bugs or at least merging the commits he did earlier15:14
cyphermoxjuliank: ok, because it looks like progress percentage is now reported on Status-Fd is localized15:15
cyphermoxie. percentage may be 33.333 or 33,33315:15
cyphermoxhrm, maybe it's not apt15:16
dokojuliank, 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:25
juliankdoko: DonKult is looking into it15:27
dokoinfinity, fakeroot probably needs an update for dropped (?) glibc symbols?15:28
juliankdoko: I updated fakeroot to silence the warning15:29
juliankdoko: glibc now added error reporting to dlsym() which was not there before15:29
juliankThe acl symbols mentioned were never in libc in the first place15:29
* juliank is not sure what the right course of action for this is longer term15:30
juliankThis at least brings is back to the 2.23 state.15:31
* juliank mostly cares because it breaks the apt tests ...15:31
dokojuliank, one more thing: https://bugs.launchpad.net/bugs/1584118  how is a package selected when I only install the virtual name?15:35
ubottuLaunchpad bug 1584118 in openjdk-9 (Ubuntu) "16.04 incorrectly installs openjdk-9 to satisfy java8-runtime dependency" [Undecided,Incomplete]15:35
sitterjuliank: 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 purpose15:35
sitterand 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:35
sitterIf we assume os-release is the long-term target I doubt a compatibility break will be avoidable15:36
juliankdoko: I don't really know in detail. I guess it just fits the first package it sees15:36
dokomvo, ^^^15:37
juliankdoko: I'd simply create a real package with the virtual name and let it depend on the preferred one. This has guaranteed semantics15:38
juliankRelying on APT's implementation details is not such a good idea.15:39
infinitydoko: 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:39
infinitydoko: But, as juliank says, relying on even that is a poor substitute for forcing the issue.15:40
infinityjuliank: You referenced the Debian bug in your fakeroot upload, but didn't forward the patch to the Debian bug? :P16:03
juliankinfinity: Not yet at least, but the idea was mentioned in that bug16:07
=== danwest_ is now known as danwest
infinityjuliank: Yeah.  But a quick "submittodebian" turning Aurelien's suggestion into an actual patch is always nice. :)16:09
juliankinfinity: Right. Later on. I just wonder: Did I really leave the Bug-Ubuntu field with <bugnumber> int it?16:10
juliankI have no idea how that happened16:10
infinityjuliank: Yes, you really did. ;)16:10
infinityjuliank: I wasn't going to point that out. :P16:11
juliankI have to cook now, but I'll try to send the patch out16:13
juliankinfinity: done16:18
tyhicksbdmurray: 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
ubottubug 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/152823017:35
juliankdoko: that seems to be the culprit: https://paste.debian.net/788746/17:53
juliankFor whatever reasons DirectoryExists() had __attribute__((const))17:53
juliankStill not sure how the compiler completely optimises that away, though17:53
juliankIt must think that DirectoryExists(<string constant ".disk">) always is false17:54
juliankor rather, that it must be false at some point17:54
juliankI 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 part18:02
juliankApparently the code is not dropped, but the input is some garbage instead of the actual value.18:43
juliankWhich 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
juliankDid 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
juliankThe apport tests thus fail with Unsupported proxy configured: direct:19:15
juliankNevermind, apport test suite is broken and we now added a check for invalid proxy methods...19:19
juliankWill upload fixed apport in a few minutes19:19
juliankshould be fixed in -0ubuntu619:26
slangasekmterry: 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?19:59
mterryslangasek: I'm not sure; I likely made it originally though.  It should probably move20:04
slangasekah, I see, this file is 3 years old already, I thought it was added in the latest upload :)20:09
slangasekbut yes, your name is on the original commit also :)20:10
bdmurraytyhicks: yes, that makes sense to me20:16
tyhicksbdmurray: ok, thank you20:17
=== salem_ is now known as _salem

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