| === tyhicks` is now known as tyhicks | ||
| === shuduo-afk is now known as shuduo | ||
| === stub` is now known as stub | ||
| mwhudson | why would "mk-sbuild xenial" fail with "E: Failed getting release file http://archive.ubuntu.com/ubuntu/dists/xenial/Release" | 03:44 |
|---|---|---|
| cpaelzer | good morning | 05:37 |
| pitti | Good morning | 06:38 |
| 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:42 |
| pitti | doko: mailed sgclark (as she isn't on IRC) | 06:44 |
| 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:47 |
| 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:54 |
| infinity | pitti: Yeah, installing those didn't help. | 06:55 |
| 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:56 |
| pitti | stgraber: I don't want to remove the previous one right away, this might confuse some running tests | 06:57 |
| === ttx_ is now known as ttx | ||
| 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:39 |
| pitti | stgraber: right, I didn't see anything in the properties of the original ubuntu image which sounds like that | 07:40 |
| 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:41 |
| 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 | 07:43 |
| === jibel_ is now known as jibel | ||
| === ackkk is now known as ackk | ||
| 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:44 |
| rbasak | mwhudson: missing proxy setting perhaps? | 09:48 |
| * rbasak is guessing | 09:48 | |
| mwhudson | rbasak: i don't *think* so | 10:04 |
| mwhudson | it's possible | 10:04 |
| mwhudson | basic debootstrap works | 10:04 |
| mwhudson | (well, gets past that point at least) | 10:05 |
| * mwhudson runs bash -x ... | 10:06 | |
| mwhudson | oh wait, out of date proxy settings in ~/.mk-sbuild.rc | 10:06 |
| 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:10 |
| mwhudson | it seems to be working so far | 10:11 |
| mwhudson | well, i made a xenial schroot and trusty is grinding away | 10:12 |
| === 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 | ||
| plars | anyone know what could cause things to get into this state? http://paste.ubuntu.com/15913154/ | 13:48 |
| 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. | 13:49 |
| === PaulW2U_ is now known as PaulW2U | ||
| doko | seb128, Laney: is xterm-256color set by default now as TERM variable? | 14:00 |
| 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:01 |
| pitti | doko: this has changed a while ago already, at vivid or wily or so | 14:02 |
| * 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| * Laney nod | 14:32 | |
| 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:35 |
| doko | even the version 1.4.2-3 in the archive fails this way | 14:38 |
| === tkamppeter_ is now known as tkamppeter | ||
| tkamppeter | infinity, hi | 14:46 |
| infinity | doko: That looks like the same thing Steve mangles in lua. | 14:58 |
| doko | infinity, yes, it does the same | 15:24 |
| === smoser` is now known as smoser | ||
| 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:42 |
| doko | argh, and the same in llvm :-/ | 15:47 |
| cking | libdm0 is apparently superceded in Xenial, but I can't find the dmapi that replaces it. | 16:00 |
| cking | any ideas? | 16:00 |
| 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:26 |
| pitti | Mirv: right, I'd rather get to the bottom of this | 16:30 |
| 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:42 |
| bdmurray | seb128: I've been looking into it a bit with a cdparanoia crash, but haven't found the issue. | 16:43 |
| 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:46 |
| 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:47 |
| 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:50 |
| 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:51 |
| bdmurray | I don't recall saying it was going to be fixed, and that may help. | 16:52 |
| === muktupavels is now known as muktupavels_ | ||
| 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:53 |
| stgraber | xnox: http://paste.ubuntu.com/15916692/ | 16:54 |
| 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:03 |
| bdmurray | dobey: it only install packages from the overlay PPA | 17:04 |
| dobey | bdmurray: would it be terribly difficult to enable installing packages from other PPAs that might be enabled? | 17:05 |
| bdmurray | dobey: iirc it wouldn't be that difficult, but I don't think that is the problem. | 17:06 |
| dobey | bdmurray: not which problem? it is certainly the problem i am asking about. :) | 17:07 |
| 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:08 |
| 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:10 |
| 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:14 |
| dobey | bdmurray: i guess maybe i should file a bug about it? | 17:15 |
| bdmurray | dobey: please about the daisy project | 17:15 |
| dobey | yep, will do | 17:16 |
| Pharaoh_Atem | nacc: okay, thanks, will check | 17:23 |
| 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:30 |
| 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:41 |
| 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:43 |
| slangasek | dobey: yes, we can rely on that being safe | 17:44 |
| 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:45 |
| 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:50 |
| 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:51 |
| cjwatson | you'll need to bear in mind the near-future ephemeral PPA use case too | 17:57 |
| 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:01 |
| 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:05 |
| dobey | cjwatson: sure | 18:06 |
| dobey | sounds reasonable | 18:06 |
| 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:10 |
| teward | slangasek: thanks for the clarification | 18:11 |
| elbrus_ | nacc: I have a php7 regression bug in cacti | 18:29 |
| 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:30 |
| 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:31 |
| * 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:32 |
| 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:33 |
| * elbrus_ is checking | 18:34 | |
| elbrus_ | nacc: your understanding of the suhosin is similar to mine: it shouldn't matter | 18:35 |
| elbrus_ | nacc: interestingly 202 is using mysqlnd | 18:36 |
| 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:38 |
| * 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:39 |
| 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:41 |
| 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:43 |
| nacc | cjwatson: i guess you own the above :) | 18:44 |
| 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:51 |
| nacc | elbrus_: note that i think i also duped the bugs because they were from the same person :) | 18:53 |
| 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:54 |
| 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:55 |
| nacc | elbrus_: let me pull up the source | 18:56 |
| === elbrus_ is now known as elbrus | ||
| * elbrus removed an underscore... | 18:57 | |
| 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 | 18:59 |
| elbrus | I mean, query in #7 I recognize | 19:00 |
| nacc | elbrus: yep | 19:01 |
| 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:06 |
| nacc | elbrus: upstream's code is different, trying to see why, as it claims to not have been changed since october :/ | 19:08 |
| 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:11 | |
| 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:12 |
| 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:13 |
| slangasek | heh :) | 19:14 |
| * elbrus is afk | 20:11 | |
| === fginther` is now known as fginther | ||
| 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? | 21:08 |
| === alexlist` is now known as alexlist | ||
| tumbleweed | erm, what happened to http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntustudio.xenial/ ? (seeded-in-ubuntu's crawling is complaining) | 21:40 |
| 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:24 |
| 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:25 |
| doko | tjaalton, freeipa (4.3.1-0ubuntu1) "Sync from Debian" ??? | 22:32 |
| === salem_ is now known as _salem | ||
| cjwatson | nacc: which is what was done upstream | 22:37 |
| nacc | cjwatson: ah ok, i hadn't looked yet, thanks! | 22:38 |
| 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:42 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:49 |
| 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:50 |
| rbasak | The reproducible builds people will love that. | 22:55 |
| 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:56 |
| sarnold | rbasak: hah | 22:58 |
| sarnold | it shouldn't affect the output packages though | 22:58 |
| sarnold | just build logs | 22:58 |
| === sergiusens65 is now known as sergiusens | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!