=== tyhicks` is now known as tyhicks
=== shuduo-afk is now known as shuduo
=== stub` is now known as stub
[03:44] <mwhudson> why would "mk-sbuild xenial" fail with "E: Failed getting release file http://archive.ubuntu.com/ubuntu/dists/xenial/Release"
[05:37] <cpaelzer> good morning
[06:38] <pitti> Good morning
[06:42] <pitti> 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] <pitti> doko: mailed sgclark (as she isn't on IRC)
[06:47] <infinity> I had a look at it last week and couldn't sort it out.
[06:47] <infinity> 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] <pitti> infinity: you mean epstool and fig2dev? (as there are warnings about those in the log)
[06:54] <pitti> no warning about those in the passed tests indeed
[06:55] <infinity> pitti: Yeah, installing those didn't help.
[06:56] <infinity> pitti: So, red herring.
[06:56] <pitti> 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] <pitti> 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] <stgraber> 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] <pitti> stgraber: right, I didn't see anything in the properties of the original ubuntu image which sounds like that
[07:41] <pitti> stgraber: or the other way around, would it always be safe to delete the previous adt image after creating a new one?
[07:41] <pitti> stgraber: i. e. could there be running containers from that image, with snapshots or dir/btrfs/zfs which would break?
[07:43] <stgraber> pitti: lxd does internal ref counting as needed
[07:43] <stgraber> pitti: so it's always safe to remove the image
[07:43] <stgraber> 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] <pitti> 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] <mwhudson> morning europe
[09:44] <mwhudson> 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] <rbasak> mwhudson: missing proxy setting perhaps?
[09:48]  * rbasak is guessing
[10:04] <mwhudson> rbasak: i don't *think* so
[10:04] <mwhudson> it's possible
[10:04] <mwhudson> basic debootstrap works
[10:05] <mwhudson> (well, gets past that point at least)
[10:06]  * mwhudson runs bash -x ...
[10:06] <mwhudson> oh wait, out of date proxy settings in ~/.mk-sbuild.rc
[10:10] <rbasak> 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] <mwhudson> it seems to be working so far
[10:12] <mwhudson> 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] <plars> anyone know what could cause things to get into this state? http://paste.ubuntu.com/15913154/
[13:49] <plars> Running apt-get update in this schroot seems to get errors like this:
[13:49] <plars> W: No sandbox user '_apt' on the system, can not drop privileges
[13:49] <plars> W: GPG error: http://ports.ubuntu.com/ubuntu-ports xenial InRelease: Could not execute 'apt-key' to verify signature (is gnupg installed?)
[13:49] <plars> W: The repository 'http://ports.ubuntu.com/ubuntu-ports xenial InRelease' is not signed.
=== PaulW2U_ is now known as PaulW2U
[14:00] <doko> seb128, Laney: is xterm-256color set by default now as TERM variable?
[14:01] <seb128> 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] <pitti> 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_> ogra@styx:~/all-snaps/rpi3$ env |grep TERM
[14:03] <ogra_> TERM=xterm
[14:03] <jrwren> 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] <doko> pitti: but inside screen, you get now screen.xterm-256color, which is not functional
[14:03] <ogra_> not for me ...
[14:03] <ogra_> seems it doesnt get migrated on updates ?
[14:03] <pitti> yes, this is in libvte
[14:03] <cjwatson> that really seems like something screen should fix
[14:04] <pitti> configure.ac:VTE_DEFAULT_TERM=xterm-256color
[14:04] <pitti> (in vte2.91)
[14:04] <cjwatson> screen.xterm-256color does exist though
[14:04] <pitti> gnome bug 168251
[14:04] <ubottu> 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] <pitti> sorry, no, this was much older
[14:05] <doko> ahh, only if I change into a chroot inside screen
[14:05] <pitti> gnome bug 740641
[14:05] <ubottu> 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] <cjwatson> it was added in ncurses 20150627
[14:05] <pitti> changed in https://git.gnome.org/browse/vte/commit/configure.ac?id=82a8b0697dd9
[14:05] <cjwatson>         + comment-out "screen.xterm" entry, and inherit screen.xterm-256color
[14:06] <cjwatson>           from xterm-new (report by Richard Birkett) -TD
[14:06] <cjwatson> so perhaps wouldn't work with older ncurses-term
[14:06] <pitti> seb128: FYI, broadly it describes to bash, curses programs or anything else that runs in a terminal what capabilities a terminal has
[14:06] <doko> ncurses-term is missing there
[14:07] <pitti> seb128: like "can it show colors" and how many
[14:07] <pitti> seb128: that's used by things like pstree, mc, or others to decide whether to use fancy characters, colors, etc. or not
[14:07] <seb128> pitti, k
[14:08] <seb128> 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] <doko> so maybe we should add this entry to ncurses-base, instead of ncurses-term?
[14:09] <cjwatson> dunno the rationale for that particular split
[14:09] <doko> size?
[14:09] <cjwatson> sure, but the positioning forof it
[14:09] <cjwatson> *of it
[14:09] <cjwatson> if it were me I'd consult Sven (Debian ncurses maintainer)
[14:32]  * Laney nod
[14:35] <doko> infinity, https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1571684
[14:35] <ubottu> Launchpad bug 1571684 in libisoburn (Ubuntu) "libisoburn fails to build on powerpc" [High,Confirmed]
[14:38] <doko> even the version 1.4.2-3 in the archive fails this way
=== tkamppeter_ is now known as tkamppeter
[14:46] <tkamppeter> infinity, hi
[14:58] <infinity> doko: That looks like the same thing Steve mangles in lua.
[15:24] <doko> infinity, yes, it does the same
=== smoser` is now known as smoser
[15:42] <nacc> 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] <doko> argh, and the same in llvm :-/
[16:00] <cking> libdm0 is apparently superceded in Xenial, but I can't find the dmapi that replaces it.
[16:00] <cking> any ideas?
[16:26] <Mirv> 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] <ubottu> 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] <pitti> Mirv: right, I'd rather get to the bottom of this
[16:42] <seb128> 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] <pitti> argh, LP timing out again
[16:42] <seb128> pitti, ^
[16:42] <pitti> seb128: obviously we do have an issue then; I haven't looked into this yet (wasn't aware of that)
[16:43] <bdmurray> seb128: I've been looking into it a bit with a cdparanoia crash, but haven't found the issue.
[16:46] <seb128> 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] <seb128> I'm just wondering if there is an infra problem
[16:47] <seb128> or if we are just dealing with a stack of individual unrelated issues
[16:47] <seb128> I guess the answer is "nobody looked enough to say"
[16:47] <seb128> bdmurray, pitti, thanks
[16:50] <bdmurray> seb128: I think we'll be in better shape if we fix bug 1517257
[16:50] <ubottu> bug 1517257 in apport (Ubuntu) "apport-retrace should install and use gdb for target release" [Medium,Triaged] https://launchpad.net/bugs/1517257
[16:50] <seb128> oh, that's still not fixed?
[16:51] <seb128> 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] <seb128> could be the issue there then?
[16:52] <bdmurray> I don't recall saying it was going to be fixed, and that may help.
=== muktupavels is now known as muktupavels_
[16:53] <seb128> k, maybe I mixing that with some other issues
[16:53] <bdmurray> Once we get past the release I'll look at fixing that though.
[16:54] <stgraber> xnox: http://paste.ubuntu.com/15916692/
[17:03] <dobey> 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] <bdmurray> dobey: it only install packages from the overlay PPA
[17:05] <dobey> bdmurray: would it be terribly difficult to enable installing packages from other PPAs that might be enabled?
[17:06] <bdmurray> dobey: iirc it wouldn't be that difficult, but I don't think that is the problem.
[17:07] <dobey> bdmurray: not which problem? it is certainly the problem i am asking about. :)
[17:08] <dobey> bdmurray: i didn't mean to imply it was related to some other problem with e.u.c
[17:08] <bdmurray> dobey: oh, okay! I think slangasek had some concerns about enabling every PPA for retracing.
[17:10] <smoser> hey. someone systemd boot knowledgable want to take a gander at https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1571761
[17:10] <ubottu> Launchpad bug 1571761 in zfs-linux (Ubuntu) "zfs-import-cache.service slows boot by 60 seconds" [High,Confirmed]
[17:14] <dobey> 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] <dobey> bdmurray: i guess maybe i should file a bug about it?
[17:15] <bdmurray> dobey: please about the daisy project
[17:16] <dobey> yep, will do
[17:23] <Pharaoh_Atem> nacc: okay, thanks, will check
[17:30] <nacc> Pharaoh_Atem: thanks!
[17:30] <dobey> bdmurray: bug #1571777
[17:30] <ubottu> bug 1571777 in Daisy "Crashes in packages from PPAs are often invalid" [Undecided,New] https://launchpad.net/bugs/1571777
[17:41] <slangasek> 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] <dobey> 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] <slangasek> dobey: yes, we can rely on that being safe
[17:45] <dobey> 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] <slangasek> 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] <dobey> 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] <cjwatson> you'll need to bear in mind the near-future ephemeral PPA use case too
[18:01] <dobey> 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] <cjwatson> 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] <cjwatson> 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] <dobey> cjwatson: sure
[18:06] <dobey> sounds reasonable
[18:10] <rharper> 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] <teward> slangasek: thanks for the clarification
[18:29] <elbrus_> nacc: I have a php7 regression bug in cacti
[18:30] <elbrus_> nacc: bug 1571432
[18:30] <ubottu> bug 1571432 in cacti (Ubuntu) "Cacti package is incompatible with PHP7 on Xenial" [High,Confirmed] https://launchpad.net/bugs/1571432
[18:30] <elbrus_> solution is simple:
[18:30] <elbrus_> line 66 of install/index.php needs an addition "i"
[18:30] <elbrus_> mysql -> mysqli
[18:31] <elbrus_> I'll add you to the bug
[18:31] <nacc> 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] <nacc> elbrus_: will provide a debdiff and fix for cacti today
[18:32] <nacc> elbrus_: ok, one sec
[18:32] <elbrus_> hmm, don't see any with cacti
[18:33] <nacc> elbrus_: they are gainst php7.0 right now
[18:33] <nacc> elbrus_: because it's a SEGV :/
[18:33] <elbrus_> nacc: a, ok
[18:33] <nacc> elbrus_: LP: #1569202 and LP: #1569993
[18:33] <ubottu> Error: Launchpad bug 1569202 could not be found
[18:33] <ubottu> Error: Launchpad bug 1569993 could not be found
[18:34]  * elbrus_ is checking
[18:35] <elbrus_> nacc: your understanding of the suhosin is similar to mine: it shouldn't matter
[18:36] <elbrus_> nacc: interestingly 202 is using mysqlnd
[18:38] <nacc> 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] <elbrus_> 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] <ubottu> 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] <nacc> 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] <nacc> 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] <nacc> nm, bug already exists :)
[18:43] <nacc> LP: #1425609
[18:43] <ubottu> Launchpad bug 1425609 in lazr.restfulclient (Ubuntu) "urllib.urlencode() does not exist for python3" [Undecided,Fix committed] https://launchpad.net/bugs/1425609
[18:44] <nacc> cjwatson: i guess you own the above :)
[18:51] <elbrus_> 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] <ubottu> Error: Launchpad bug 1569202 could not be found
[18:53] <nacc> elbrus_: note that i think i also duped the bugs because they were from the same person :)
[18:54] <nacc> elbrus_: sorry, 'stacktrace p item' ?
[18:54] <elbrus_> https://i253407377.restricted.launchpadlibrarian.net/253407377/Stacktrace.txt?token=79F8Snh3qfhwqHbcT8v9CXLk2Ld57CmG
[18:54] <elbrus_> item #4
[18:55] <elbrus_> p= ....
[18:55] <nacc> elbrus_: ah, reading
[18:55] <nacc> elbrus_: hrm, that does look like corruption?
[18:55] <nacc> or the string getting fubar'd :)
[18:55] <elbrus_> absolutely not sure, but it looks weird
[18:55] <elbrus_> that
[18:56] <nacc> elbrus_: let me pull up the source
=== elbrus_ is now known as elbrus
[18:57]  * elbrus removed an underscore...
[18:59] <nacc> elbrus: yeah, if you look at #7  to #4, it seems like query -> p gets ocrrupted (and the length got modified)
[18:59] <elbrus> indeed
[19:00] <elbrus> I mean, query in #7 I recognize
[19:01] <nacc> elbrus: yep
[19:06] <nacc> elbrus: hrm, i'm not even sure what p is! it gets copied to but then is unused :)
[19:06] <nacc> let me look upstream
[19:08] <nacc> elbrus: upstream's code is different, trying to see why, as it claims to not have been changed since october :/
[19:11] <nacc> elbrus: nm, that's what's pending in 7.1.0, i think (quite extensive rewrite)
[19:11] <rbasak> 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] <teward> slangasek: basically, what rbasak said (me without coffee doesn't word things clearly apparently)
[19:12] <slangasek> rbasak: isn't that what I just said?
[19:12] <teward> rbasak: thanks for interpreting the question :)
[19:13] <rbasak> 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] <teward> not counting the coffee issue, yes :P
[19:13] <rbasak> (you said it won't impact main, which isn't the same thing as "you're allowed")
[19:13] <rbasak> teward: you're allowed :-)
[19:13] <teward> indeed
[19:13] <teward> rbasak: thanks for being the interpreter :)
[19:14] <slangasek> heh :)
[20:11]  * elbrus is afk
=== fginther` is now known as fginther
[21:08] <doko> 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] <tumbleweed> erm, what happened to http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntustudio.xenial/ ? (seeded-in-ubuntu's crawling is complaining)
[22:24] <cjwatson> tumbleweed: I've fixed the seed bug that caused that
[22:24] <cjwatson> nacc: grah, guess I'll have to poke that in the distro tomorrow
[22:25] <nacc> 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] <doko> tjaalton, freeipa (4.3.1-0ubuntu1) "Sync from Debian" ???
=== salem_ is now known as _salem
[22:37] <cjwatson> nacc: which is what was done upstream
[22:38] <nacc> cjwatson: ah ok, i hadn't looked yet, thanks!
[22:42] <doko> 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] <denlud> 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] <denlud> Already tried alot.
[22:46] <teward> denlud: support in #ubuntu
[22:46] <denlud> ok
[22:46] <sarnold> doko: did I read that correctly? lz4's build-test fuzzer found something?
[22:46] <doko> sarnold, yes
[22:47] <sarnold> doko: crazy; that feels like hitting a sha-1 collision by chance :)
[22:47] <doko> sarnold, look at the failed build in the test rebuild for the seed value
[22:49] <slangasek> 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] <ubottu> bug 1571082 in juju-core (Ubuntu) "autopkgtest lxd provider tests fail for 2.0" [Critical,Triaged] https://launchpad.net/bugs/1571082
[22:50] <tych0> slangasek: lxd.log and $container/lxc.log are good, thanks!
[22:50] <tych0> the second one might not exist, not sure
[22:50] <tych0> depends on how far things ogt
[22:55] <rbasak> The reproducible builds people will love that.
[22:56] <tych0> rbasak: oh?
[22:56] <rbasak> I suppose if the binary is stable...
[22:56] <rbasak> tych0: sorry, I meant about lz4 above.
[22:56] <tych0> oh :)
[22:58] <sarnold> rbasak: hah
[22:58] <sarnold> it shouldn't affect the output packages though
[22:58] <sarnold> just build logs
=== sergiusens65 is now known as sergiusens