=== tyhicks` is now known as tyhicks === shuduo-afk is now known as shuduo === stub` is now known as stub [03:44] why would "mk-sbuild xenial" fail with "E: Failed getting release file http://archive.ubuntu.com/ubuntu/dists/xenial/Release" [05:37] good morning [06:38] Good morning [06:42] doko: well, I had a look, but it's obvious that the new release breaks its tests and the current xenial one works, so this isn't any infra problem [06:44] doko: mailed sgclark (as she isn't on IRC) [06:47] I had a look at it last week and couldn't sort it out. [06:47] I thought it might be missing test deps, but even adding the (optional) binaries it complains about doesn't change things, so they really are optional. [06:54] infinity: you mean epstool and fig2dev? (as there are warnings about those in the log) [06:54] no warning about those in the passed tests indeed [06:55] pitti: Yeah, installing those didn't help. [06:56] pitti: So, red herring. [06:56] stgraber: apparently manually created lxd images not get auto-cleaned after n days (http://paste.ubuntu.com/15908394/); is there some way how adt-build-lxd can mark the older images for auto-cleanup after building a current one? [06:57] stgraber: I don't want to remove the previous one right away, this might confuse some running tests === ttx_ is now known as ttx [07:39] pitti: I don't believe we expose a way to set the cached property over the API, no reason why we shouldn't though [07:40] stgraber: right, I didn't see anything in the properties of the original ubuntu image which sounds like that [07:41] stgraber: or the other way around, would it always be safe to delete the previous adt image after creating a new one? [07:41] stgraber: i. e. could there be running containers from that image, with snapshots or dir/btrfs/zfs which would break? [07:43] pitti: lxd does internal ref counting as needed [07:43] pitti: so it's always safe to remove the image [07:43] pitti: if it's still needed, lxd will renamed it to a delete/... path (on zfs) and then wipe it when refcount hits 0 [07:43] stgraber: ah, nice; I guess then I'll do just that === jibel_ is now known as jibel === ackkk is now known as ackk [09:44] morning europe [09:44] why would "mk-sbuild xenial" fail with "E: Failed getting release file http://archive.ubuntu.com/ubuntu/dists/xenial/Release" (new xenial install) [09:48] mwhudson: missing proxy setting perhaps? [09:48] * rbasak is guessing [10:04] rbasak: i don't *think* so [10:04] it's possible [10:04] basic debootstrap works [10:05] (well, gets past that point at least) [10:06] * mwhudson runs bash -x ... [10:06] oh wait, out of date proxy settings in ~/.mk-sbuild.rc [10:10] mwhudson: btw, I did hit 1569400 on xenial the other day. Simple workaround. Though you may not hit it unless you use Etc/UTC too. [10:11] it seems to be working so far [10:12] well, i made a xenial schroot and trusty is grinding away === davmor2_ is now known as davmor2 === henrix_ is now known as henrix === uaa is now known as Guest42832 === Beret- is now known as Beret === DrKranz is now known as DktrKranz === freeflying__ is now known as freeflying === Trevinho_ is now known as Trevinho === superm1_ is now known as superm1 === davidcalle__ is now known as davidcalle_ === Ursinha_ is now known as Ursinha === Guest42832 is now known as az === infinity_ is now known as infinity === dgadomski_ is now known as dgadomski === bigon_ is now known as bigon === mhall119_ is now known as mhall119 === _salem is now known as salem_ === jrwren_ is now known as jrwren === hikiko is now known as hikiko|ln === fginther` is now known as fginther === josepht` is now known as josepht === hikiko|ln is now known as hikiko === ogra_` is now known as ogra_ === dgadomski is now known as dgadomski_ === dgadomski_ is now known as dgadomski === dgadomski is now known as dgadomski_ === dgadomski_ is now known as dgadomski === plars_ is now known as plars [13:48] anyone know what could cause things to get into this state? http://paste.ubuntu.com/15913154/ [13:49] Running apt-get update in this schroot seems to get errors like this: [13:49] W: No sandbox user '_apt' on the system, can not drop privileges [13:49] W: GPG error: http://ports.ubuntu.com/ubuntu-ports xenial InRelease: Could not execute 'apt-key' to verify signature (is gnupg installed?) [13:49] W: The repository 'http://ports.ubuntu.com/ubuntu-ports xenial InRelease' is not signed. === PaulW2U_ is now known as PaulW2U [14:00] seb128, Laney: is xterm-256color set by default now as TERM variable? [14:01] urg, I don't even know what that variable is and what sets it, I'm really not the person to ask about that, but maybe Laney knows... [14:02] doko: this has changed a while ago already, at vivid or wily or so [14:03] * pitti noticed when his own nick suddendly switched to white in weechat :) [14:03] ogra@styx:~/all-snaps/rpi3$ env |grep TERM [14:03] TERM=xterm [14:03] doko: usually your terminal client sets that and its carried forward by ssh or wahtever. So it would be gnome-terminal or ubuntu-terminal or whatever. Each will set a TERM. Its not a system wide setting. [14:03] pitti: but inside screen, you get now screen.xterm-256color, which is not functional [14:03] not for me ... [14:03] seems it doesnt get migrated on updates ? [14:03] yes, this is in libvte [14:03] that really seems like something screen should fix [14:04] configure.ac:VTE_DEFAULT_TERM=xterm-256color [14:04] (in vte2.91) [14:04] screen.xterm-256color does exist though [14:04] gnome bug 168251 [14:04] Gnome bug 168251 in general "add support for 256 colors terminals" [Enhancement,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=168251 [14:05] sorry, no, this was much older [14:05] ahh, only if I change into a chroot inside screen [14:05] gnome bug 740641 [14:05] Gnome bug 740641 in general "Change default to TERM=xterm-256color" [Enhancement,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=740641 [14:05] it was added in ncurses 20150627 [14:05] changed in https://git.gnome.org/browse/vte/commit/configure.ac?id=82a8b0697dd9 [14:05] + comment-out "screen.xterm" entry, and inherit screen.xterm-256color [14:06] from xterm-new (report by Richard Birkett) -TD [14:06] so perhaps wouldn't work with older ncurses-term [14:06] seb128: FYI, broadly it describes to bash, curses programs or anything else that runs in a terminal what capabilities a terminal has [14:06] ncurses-term is missing there [14:07] seb128: like "can it show colors" and how many [14:07] seb128: that's used by things like pstree, mc, or others to decide whether to use fancy characters, colors, etc. or not [14:07] pitti, k [14:08] well, vte&co is not something I usually look at, larsu and La_ney have been the ones doing the changes/updates in recent cycles [14:08] so maybe we should add this entry to ncurses-base, instead of ncurses-term? [14:09] dunno the rationale for that particular split [14:09] size? [14:09] sure, but the positioning forof it [14:09] *of it [14:09] if it were me I'd consult Sven (Debian ncurses maintainer) [14:32] * Laney nod [14:35] infinity, https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1571684 [14:35] Launchpad bug 1571684 in libisoburn (Ubuntu) "libisoburn fails to build on powerpc" [High,Confirmed] [14:38] even the version 1.4.2-3 in the archive fails this way === tkamppeter_ is now known as tkamppeter [14:46] infinity, hi [14:58] doko: That looks like the same thing Steve mangles in lua. [15:24] infinity, yes, it does the same === smoser` is now known as smoser [15:42] Pharaoh_Atem: can you test with xenial latest? (in case you haven't already) -- should be up to your version, just would like a verification from you [15:47] argh, and the same in llvm :-/ [16:00] libdm0 is apparently superceded in Xenial, but I can't find the dmapi that replaces it. [16:00] any ideas? [16:26] pitti: ok thanks for commenting on the bug #1571353. it's a bit like I suspected but decided to ask anyway. steve retried the faulty autopkgtest in the morning for bzoltan_. we had another one last week and will certainly ping you also the next time. [16:26] bug 1571353 in Auto Package Testing "test requests sometimes get lost and stay "in progress" forever" [Undecided,Incomplete] https://launchpad.net/bugs/1571353 [16:30] Mirv: right, I'd rather get to the bottom of this [16:42] bdmurray, on the daily e.u.c xenial report it seems like half of the entries don't have function names/symbols, do you know if we have issues with apport/gdb/retracers still in xenial? [16:42] argh, LP timing out again [16:42] pitti, ^ [16:42] seb128: obviously we do have an issue then; I haven't looked into this yet (wasn't aware of that) [16:43] seb128: I've been looking into it a bit with a cdparanoia crash, but haven't found the issue. [16:46] pitti, well, not "obviously", often it turns out that retracing fails because of packages -dbgsym are missing, or buggy, or version got deprecated or whatsoever [16:47] I'm just wondering if there is an infra problem [16:47] or if we are just dealing with a stack of individual unrelated issues [16:47] I guess the answer is "nobody looked enough to say" [16:47] bdmurray, pitti, thanks [16:50] seb128: I think we'll be in better shape if we fix bug 1517257 [16:50] bug 1517257 in apport (Ubuntu) "apport-retrace should install and use gdb for target release" [Medium,Triaged] https://launchpad.net/bugs/1517257 [16:50] oh, that's still not fixed? [16:51] I though you identified that as an issue earlier in the cycle and said it was due to be fixed a bit after that [16:51] could be the issue there then? [16:52] I don't recall saying it was going to be fixed, and that may help. === muktupavels is now known as muktupavels_ [16:53] k, maybe I mixing that with some other issues [16:53] Once we get past the release I'll look at fixing that though. [16:54] xnox: http://paste.ubuntu.com/15916692/ [17:03] bdmurray: does the retracer for e.u.c not install PPAs that packages might be installed from, to retrace against? ie, for landing silos, for example? [17:04] dobey: it only install packages from the overlay PPA [17:05] bdmurray: would it be terribly difficult to enable installing packages from other PPAs that might be enabled? [17:06] dobey: iirc it wouldn't be that difficult, but I don't think that is the problem. [17:07] bdmurray: not which problem? it is certainly the problem i am asking about. :) [17:08] bdmurray: i didn't mean to imply it was related to some other problem with e.u.c [17:08] dobey: oh, okay! I think slangasek had some concerns about enabling every PPA for retracing. [17:10] hey. someone systemd boot knowledgable want to take a gander at https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1571761 [17:10] Launchpad bug 1571761 in zfs-linux (Ubuntu) "zfs-import-cache.service slows boot by 60 seconds" [High,Confirmed] [17:14] bdmurray: not sure what the concerns were, and i wouldn't want them all enabled all the time, but if we could include non-private PPA sources.list identifiers somehow, (maybe just a listing of /etc/apt/sources.d/*.list) and enable some to be installed for retracing when needed, that would be nice; even if we limited it to PPAs owned by ci-train-ppa-service or something [17:15] bdmurray: i guess maybe i should file a bug about it? [17:15] dobey: please about the daisy project [17:16] yep, will do [17:23] nacc: okay, thanks, will check [17:30] Pharaoh_Atem: thanks! [17:30] bdmurray: bug #1571777 [17:30] bug 1571777 in Daisy "Crashes in packages from PPAs are often invalid" [Undecided,New] https://launchpad.net/bugs/1571777 [17:41] dobey, bdmurray: the concern is whether a hostile ppa could feed the retracers bad symbols that break gdb and compromise the retracer env. I do not assume that gdb has been well-hardened against hostile input [17:43] slangasek: right, but i presume we can assume the landing silo PPAs to be safe in that regard, since we do binary copies from them to archive when landing [17:44] dobey: yes, we can rely on that being safe [17:45] slangasek: does my proposed solution in comment 1 of the aforementioned bug sound reasonable to you in that respect? ie, implement as a whitelist until we can ensure the other concerns are resolved? [17:50] dobey: "implement a whilelist" would be ok, but I don't expect we're going to get someone to audit gdb for this use case [17:51] slangasek: well, perhaps; but then we'll just have a whitelist forever, which is probably fine too. should make it easier if we need to add more landing silos or such in the future too [17:57] you'll need to bear in mind the near-future ephemeral PPA use case too [18:01] cjwatson: i guess the PPA will exist until things have landed or been abandoned, right? i think my suggested implmentation would work for that, since it's not to always enable all those PPAs, but to include a listing in the crash report, and have the retracer decide based on that, and the crash, whether to enable a PPA and install stuff from it [18:05] dobey: right, but it does mean that we want to think about ensuring that it isn't a manually-maintained whitelist of individual PPAs [18:05] dobey: it might be acceptable to have it be a whitelist of either PPA owner or full PPA reference (e.g. [~ci-train-ppa-service, ~ubuntu-toolchain-r/ubuntu/test]) [18:06] cjwatson: sure [18:06] sounds reasonable [18:10] if a bug in ubuntu is fixed in unstable debian (and we just sync the package, no ubuntu changes) then in the bug, do we just request a sync of the package ? (Versus applying an upstream fix via debdiff) ? [18:11] slangasek: thanks for the clarification [18:29] nacc: I have a php7 regression bug in cacti [18:30] nacc: bug 1571432 [18:30] bug 1571432 in cacti (Ubuntu) "Cacti package is incompatible with PHP7 on Xenial" [High,Confirmed] https://launchpad.net/bugs/1571432 [18:30] solution is simple: [18:30] line 66 of install/index.php needs an addition "i" [18:30] mysql -> mysqli [18:31] I'll add you to the bug [18:31] elbrus_: thanks, i've actually had a few bugs come in that are private right now with cacti [18:32] * elbrus_ should be able to see private bugs [18:32] elbrus_: will provide a debdiff and fix for cacti today [18:32] elbrus_: ok, one sec [18:32] hmm, don't see any with cacti [18:33] elbrus_: they are gainst php7.0 right now [18:33] elbrus_: because it's a SEGV :/ [18:33] nacc: a, ok [18:33] elbrus_: LP: #1569202 and LP: #1569993 [18:33] Error: Launchpad bug 1569202 could not be found [18:33] Error: Launchpad bug 1569993 could not be found [18:34] * elbrus_ is checking [18:35] nacc: your understanding of the suhosin is similar to mine: it shouldn't matter [18:36] nacc: interestingly 202 is using mysqlnd [18:38] elbrus_: ack, i don't know enough about cacti to know what exactly is happening, but didn't see anything upstream in php7.0 to indicate that it had been "fixed" obviously :) [18:38] and so does the other bug... maybe good to check if this goes away with the php-mysql driver [18:39] * elbrus_ added php-mysqlnd way later on request (Debian bug 744067) [18:39] Debian bug 744067 in cacti "cacti: Cacti should support php5-mysqlnd as alternative to php5-mysql" [Wishlist,Fixed] http://bugs.debian.org/744067 [18:39] elbrus_: ack, would you be able to comment that into the bug (i've duped them together right now, i think that's correct based upon the traces, that the root-cause is the same, but feel free to undupe if you disagree) [18:41] is it possible that a python3 package has a python2 reference in the source? specifically python3-lazr.restfulclient calling urllib.urlencode directly (rather than urllib.parse.urlencode)? [18:43] nm, bug already exists :) [18:43] LP: #1425609 [18:43] Launchpad bug 1425609 in lazr.restfulclient (Ubuntu) "urllib.urlencode() does not exist for python3" [Undecided,Fix committed] https://launchpad.net/bugs/1425609 [18:44] cjwatson: i guess you own the above :) [18:51] nacc: stacktrace p item of item #4 of LP: #1569202 looks weird to me, is that normal ? (/me has never seen a php stacktrace before) looks like memory allocation issues [18:51] Error: Launchpad bug 1569202 could not be found [18:53] elbrus_: note that i think i also duped the bugs because they were from the same person :) [18:54] elbrus_: sorry, 'stacktrace p item' ? [18:54] https://i253407377.restricted.launchpadlibrarian.net/253407377/Stacktrace.txt?token=79F8Snh3qfhwqHbcT8v9CXLk2Ld57CmG [18:54] item #4 [18:55] p= .... [18:55] elbrus_: ah, reading [18:55] elbrus_: hrm, that does look like corruption? [18:55] or the string getting fubar'd :) [18:55] absolutely not sure, but it looks weird [18:55] that [18:56] elbrus_: let me pull up the source === elbrus_ is now known as elbrus [18:57] * elbrus removed an underscore... [18:59] elbrus: yeah, if you look at #7 to #4, it seems like query -> p gets ocrrupted (and the length got modified) [18:59] indeed [19:00] I mean, query in #7 I recognize [19:01] elbrus: yep [19:06] elbrus: hrm, i'm not even sure what p is! it gets copied to but then is unused :) [19:06] let me look upstream [19:08] elbrus: upstream's code is different, trying to see why, as it claims to not have been changed since october :/ [19:11] elbrus: nm, that's what's pending in 7.1.0, i think (quite extensive rewrite) [19:11] slangasek: I think what teward is looking for is a clear understanding of the rules around packages whose sources are in main. I think he's looking for you to say that it's fine for a source package in main to now build depend on a package in universe that results in a binary package that is in universe to have a dependency on a binary package that is in universe :) [19:11] * teward was pinged [19:12] slangasek: basically, what rbasak said (me without coffee doesn't word things clearly apparently) [19:12] rbasak: isn't that what I just said? [19:12] rbasak: thanks for interpreting the question :) [19:13] slangasek: I don't think you literally said that. I interpret what you said to mean this but I also understand why teward still isn't sure :) [19:13] not counting the coffee issue, yes :P [19:13] (you said it won't impact main, which isn't the same thing as "you're allowed") [19:13] teward: you're allowed :-) [19:13] indeed [19:13] rbasak: thanks for being the interpreter :) [19:14] heh :) [20:11] * elbrus is afk === fginther` is now known as fginther [21:08] infinity, all llvm builds fixed, except for 3.6: https://launchpadlibrarian.net/254390499/buildlog_ubuntu-xenial-powerpc.llvm-toolchain-3.6_1%3A3.6.2-3ubuntu2_BUILDING.txt.gz any idea about that one? === alexlist` is now known as alexlist [21:40] erm, what happened to http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntustudio.xenial/ ? (seeded-in-ubuntu's crawling is complaining) [22:24] tumbleweed: I've fixed the seed bug that caused that [22:24] nacc: grah, guess I'll have to poke that in the distro tomorrow [22:25] cjwatson: thanks, i just hit it using launchpadlib which is why i noticed, i haven't yet looked to see if the referenced tree has the correct fix; i don't think the one mentioned in the bug applies any longer (but the correct fix is to just do what other urllib imports did already, and then i think we can delete `import urllib`) itself [22:32] tjaalton, freeipa (4.3.1-0ubuntu1) "Sync from Debian" ??? === salem_ is now known as _salem [22:37] nacc: which is what was done upstream [22:38] cjwatson: ah ok, i hadn't looked yet, thanks! [22:42] xnox, infinity: lz4 now built. the fuzzer tests works with a random seed, so this is a random test failure. Looks like a real bug for some seed values [22:45] Hey people, my suspend at my Laptop isnt working at the moment. Everytime i wake my laptop up, my filesystem is crashing. Can someone help me? [22:45] Already tried alot. [22:46] denlud: support in #ubuntu [22:46] ok [22:46] doko: did I read that correctly? lz4's build-test fuzzer found something? [22:46] sarnold, yes [22:47] doko: crazy; that feels like hitting a sha-1 collision by chance :) [22:47] sarnold, look at the failed build in the test rebuild for the seed value [22:49] tych0: bug #1571082> /var/log/lxd, I have lxd.log and juju-b43656cd-a9d3-4c92-80ac-599997219ad7-machine-0/; did you want one or the other or both? [22:49] bug 1571082 in juju-core (Ubuntu) "autopkgtest lxd provider tests fail for 2.0" [Critical,Triaged] https://launchpad.net/bugs/1571082 [22:50] slangasek: lxd.log and $container/lxc.log are good, thanks! [22:50] the second one might not exist, not sure [22:50] depends on how far things ogt [22:55] The reproducible builds people will love that. [22:56] rbasak: oh? [22:56] I suppose if the binary is stable... [22:56] tych0: sorry, I meant about lz4 above. [22:56] oh :) [22:58] rbasak: hah [22:58] it shouldn't affect the output packages though [22:58] just build logs === sergiusens65 is now known as sergiusens