[00:43] slangasek: doko: php-rrd failure is an obvious thinko in debian ... bug filed [00:43] Pharaoh_Atem: can you look at the php7.0 failures on armhf and s390x? (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html) [01:10] slangasek: doko: i think i can fix imagick, it looks to be another relatively obvious issue with debian's package, will work on it tmrw [01:10] but i think most of the php7.0 excuses are now covered === juliank_ is now known as juliank [06:09] good morning [06:56] Good morning [07:51] good morning === davidcalle_afk is now known as davidcalle [08:28] good morning! [08:34] stgraber: oh, looking forward to learn what the replacement of lxc-clone/ephemeral will be :) [08:56] dholbach, did it occur to you that its beta1 release eve, how was I going to pilot! anyway I moved it to next week ;) [08:59] darkxst, I'm just putting together a rough schedule as a reminder [08:59] if I took into account all local holidays, freeze dates and everything else, it'd take me weeks to put together :-) [08:59] thanks for moving to another day [09:00] dholbach, ha, yeh, didnt think of it like that ;) [09:00] anyway no problem [09:00] its been a bumpy beta1 ;( [09:02] luckily there's still some time to fix bugs [09:02] yes [09:03] * darkxst waiting on upload to migrate so I can re-spin images and hopefully fix 4 or so bugs [09:09] slangasek, infinity, doko, Laney: please be aware of http://bazaar.launchpad.net/~ubuntu-release/britney/britney2-ubuntu/revision/579 [09:09] http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html is updated for that now [09:09] slangasek, infinity, doko, Laney: TL/DR: hinted regressions are now shown in yellow as "Ignored failure", so all red "Regressions" are "real" [09:09] pitti: nice [09:10] makes the output much easier to read, no more searching for the "ignored failure foo" 20 lines below [09:10] and makes retry-autopkgtest-regressions more useful [09:10] as it won't retry the known-failing ones [09:14] and e. g. http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#python-numpy is much easier to read now [09:29] pitti: Nice. === vrruiz_ is now known as rvr === Chipaca` is now known as Chipaca [10:13] /wii pitti [10:13] Ah [10:16] LocutusOfBorg, ping on llvm3.8 rc3? [10:17] ping sylvestre, I never packaged a new upstream release [10:17] I already pinged him about llvm-3.7 [10:27] cyphermox: cjwatson: pitti: dholbach: mdeslaur: I would like to apply to become a MOTU. Could you help to endorse me on https://wiki.ubuntu.com/ShihYuanLee/MOTUApplication? Thx. [10:28] FourDollars, sure, adding it to my TODO list :) [10:28] dholbach: Thx a lot. [10:29] https://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=&sponsor_search=email&sponsoree=fourdollars%40gmail.com&sponsoree_search=email [10:29] https://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=&sponsor_search=name&sponsoree=Shih-Yuan+Lee&sponsoree_search=name [10:29] FourDollars, ^^^ maybe you want to add them to the wiki page [10:30] so your sponsor knows what they sponsored to you :) [10:30] LocutusOfBorg: I leave http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=&sponsor_search=name&sponsoree=Shih-Yuan+Lee*&sponsoree_search=name on the wiki. [10:31] LocutusOfBorg: Please also check Ubuntu Sponsorship Miner <- [10:31] LocutusOfBorg: Maybe I should raise it up. Thx. [10:32] oh... I found it [10:32] sorry then :) [10:33] LocutusOfBorg: np. I should put it in the first line so people can easily find it. [10:34] I didn't change the link in my MOTU application [10:34] https://wiki.ubuntu.com/GianfrancoCostamagna/MOTUApplication [10:34] so it was "searchable" with find tool [10:34] :) [10:36] I see. [10:37] Let me refine my wiki page. [11:42] infinity, changed my mind on using the dpdk binary by default as it also requires hugepages to be configured otherwise it borks [11:48] cpaelzer, hey - are you working on the underlinking issue in dpdk? [11:50] jamespage: yes [11:51] jamespage: I have this one fixed along with a few others, there are some itches left [11:51] cpaelzer, awesome! I've uploaded ovs with dpdk enabled and requested that ovs-dpdk be removed from the archive [11:51] jamespage: if things go well I'll prepare an upload for review today - if not I hope tomorrow [11:52] jamespage: I've seen the bug updates seeing dpdk pulled into main by that - huge thanks for that [11:52] * cpaelzer hugs jamespage [11:52] cpaelzer, no problem - thanks for the dpdk work [11:52] cpaelzer, I decided not to enable by default based on cpu features... [11:52] jamespage: the underlinking itself will be fixed for sure, it is just not certain yet how much more I can fix in this one upload [11:53] jamespage: so is it !default in general (because we are afraid of regressions) or is it "default = sse3 ? openvswitch-dpdk : openvswitch" [11:54] cpaelzer, no - you just install openvswitch-switch and then switch between versions using alternatives [11:54] so no extra package [11:54] cpaelzer, its really ssse3 + hugepages configured correctly [11:54] I guess we could do that but I'd rather make it a little more explicit for now [11:55] jamespage: I clearly prefer not being the default as long as it needs to mature so much IMHO [11:58] cpaelzer, agreed [12:01] cpaelzer, https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/openvswitch [12:02] I've updated the Vcs fields in the repo - they will go with the next upload [12:04] jamespage: cool, I did the same for DPDK already which will be in the next upload as well (VCS) [12:05] jamespage: btw the underlinking and other changes should (tm) not change anything for you or did you address the "static" linking in openvswitch-dpdk already? [12:05] cpaelzer, I did for xenstore and pcap - but I hit a dl one when backporting atm [12:05] (that's on 14.04 only) [12:06] jamespage: ok we can try that with the new version then as soon as I'm done with it [12:06] cpaelzer, ok [12:10] doko: I'm going to drop the symbols file delta you added to libecap so it's just a sync. You hadn't sent that to Debian, and based on https://launchpad.net/ubuntu/+source/libecap/0.2.0-1ubuntu5 it looks like we're just ignoring any disappearing symbols anyway. Any objection? [12:11] Also libecap is only used by squid. It's barely a shared library. [12:11] rbasak, don't do that [12:11] doko: OK, well can you merge libecap then please? [12:11] rbasak, symbols files are a requirement for MIRs [12:11] A symbols file that is useful, or a symbols file that is present only to meet the wording of a MIR and actually serves no purpose? [12:11] rbasak, it belongs to the server team, so it's your task [12:12] rbasak, why? [12:12] It's only used by squid, so is barely a shared library at all. It might as well be static. [12:13] And, when symbols disappeared, all we did was ignore them. The symbols file caught it, it FTBFS, and we update the symbols file to match. [12:13] So what's the point? [12:13] hello [12:13] and you mean just because you update squid every two years, it's not necessary? [12:13] can someone remove linux-chromebook from archive for me? [12:14] I am still listed as maintainer when no one is using this package and I do not even have hardware for it. [12:14] hrw: Could you file a bug against it with an explanation, and subscribe ubuntu-archive? [12:14] I mean that the symbols file appears to be to be providing no benefit or protection, so is busywork for the sake of it and is pointless to do. [12:14] Gives us an audit trail [12:14] cjwatson: thanks, will do [12:14] doko: if you disagree, then please explain how the symbols file could be useful in this case. === _salem is now known as salem_ [12:15] apw: ^- do you agree with hrw's request above, since you uploaded it yesterday? [12:15] rbasak, it will remind you when a soname bump is needed, or a package rename is needed if upstream dops symbols without changing the soname [12:16] and I probably didn't forward the patch to debian, because it was outdated [12:16] debian had the new version for a long time [12:16] doko: except that upstream dropped symbols without changing the soname, and we just updated the symbols file to match. See https://launchpad.net/ubuntu/+source/libecap/0.2.0-1ubuntu5. I know I did it in that case, but since that was the outcome, the symbols file didn't help us there. [12:16] cjwatson, linux-chromebook, if you want it gone that makes my life easier -- i was simply trying to fix the module-init-tools deps i do not care about the package [12:17] cjwatson: https://bugs.launchpad.net/ubuntu/+source/linux-chromebook/+bug/1549782 [12:17] Launchpad bug 1549782 in linux-chromebook (Ubuntu) "Please remove it from archive" [Undecided,New] [12:17] rbasak, so the savings is just for you, because you don't care to rename the package for these cases? [12:17] doko: as I said, it is only squid that uses it. [12:17] apw: as the only maintainer of it I would love to see it gone ;d [12:17] doko: and we don't know what the formal ABI is, anyway. [12:17] hrw, works for me, it is anchient [12:18] sorry, I don't get it why we have this discussion. no, you can't know if external software uses it [12:18] apw: it was when got added but at that time it was acceptable solution [12:18] Which is fine, but what am I supposed to do when the symbols file flags an ABI difference? [12:18] Everyone else seems to just change the symbols file. [12:20] doko: because you don't care> and you didn't care to send the change to Debian, so what's the difference? [12:20] doko: I'm just going to sync this, as I want to make progress and I don't see the downside. I'll take input from others if anyone else wants to chime in. [12:21] rbasak, you're wrong. I couldn't send anything to debian, because the versions didn't match [12:21] doko: unless you want to take the merge? [12:21] hrw: subscribe, not assign :) (fixing) [12:21] cjwatson: long time since I used launchpad ;D [12:21] rbasak, that's blackmailing [12:22] doko: and you're just creating work for me with no justification. [12:22] (I would really like someone else to chime in here, please) [12:22] I'm happy to accept it if I'm wrong, but I would like someone to actually consider what I'm saying. I don't feel that you are. [12:22] Look at the history of libecap uploads in Ubuntu. [12:23] I have a symbols file here ready to go if needed, but given the previous history, I expect it to immediately FTBFS on other architectures and create more work to fix it. [12:23] hrw: done [12:24] cjwatson: thanks a lot [12:24] apw: thanks for reminding me (by upload) that this package still exists [12:25] hrw, heh you are very welcome :) [12:29] doko, rbasak: IMHO, that changing of symbols files is merely the symptom -- the real cause is upstream not maintaining a stable ABI or properly maintaining their soname [12:29] doko, rbasak: so the only two sane options that I see are to either beat some sense into upstream for proper versioning, or drop the shlib and provide a -dev package with a static lib only [12:29] bye [12:29] pitti: sure, I understand that. I think I'm saying that "maintaining" a symbols file in an Ubuntu delta is pointless. [12:30] if it's just one consumer, then there's little point to even pretend that it woudl be a generally usable library [12:30] rbasak: it's not [12:30] rbasak: if you build a shared library, you make a commitment and a promise [12:30] and if you don't want to keep that, don't build a shared library [12:30] pitti: sure. Sorry, I mean in this specific case, not the general case. [12:31] pitti: I mean "maintaining", not maintaining. We're just paying lip service if in reality we just update the symbols file every time symbols change. [12:31] rbasak: exactly my point :) [12:31] That's what I'm saying is pointless. Given that we're doing this, why maintain the symbols file at all? [12:31] I'll accept that not shipping a shared library the right answer, but unfortunately we're just downstream of Debian here. [12:31] it's not pointless, it's pointing you towards the real error: your library broke ABI [12:32] well, then file an RC bug against Debian and let it get auto-removed, or something [12:32] I think the answer is: 1) stop creating extra work for ourselves, since that makes less time available to fix it properly; and 2) explain upstream and ask them nicely to fix it properly. [12:32] changing ABI without soname bump for sure is an RC bug, as it will cause squid to crash on partial updates, unless they manually craft their dependencies [12:32] rbasak, pitti: In the of a static lib, you have to communicate to the security team, that thy need to update squid together with libecap. static libs come for a price as well. maybe you save some work, but you increase the work for others [12:32] but that's what a static library is for then [12:33] doko: *nod* [12:33] pitti: incidentally the ABI change was historical and in libecap2. They've had a soname bump now. [12:33] So I can't really file an RC bump now, seeing as they have bumped the soname. [12:33] An RC bug that is. [12:33] rbasak: ah, if they did, what's the problem then? [12:34] on a soname bump it's totally legitimate to update the symbols files [12:34] pitti: I feel that I'm recreating the symbols file again for no real reason. [12:34] pitti: given the history of symbols files being arbitrarily changed. [12:34] well, changing symbols files without soname bump -> don't do that [12:34] changign symbosl files with a soname bump -> normal operation [12:35] pitti: in fact I'd go a bit further and say that in general having a symbols file in an Ubuntu delta to meet MIR requirements is a bit pointless too for this reason. A stable ABI is for upstreams to maintain; we can't maintain that in an Ubuntu delta. [12:35] well, I disagree [12:35] (like you said, it'a a symptom) [12:35] If there is no symbols file, then that suggests that there isn't a stable ABI, and _that_ is the problem, not the lack of the symbols file. [12:35] if we have a package in main and want that to work properly, then things like symbols files are a great help to avoid breaking stuff [12:36] and an FTBFS due to symbols mismatch is infinitely better than having to scrape off apport crash reports after the fact [12:36] rbasak, symbols files are part of the packaging, not about upstream [12:36] some upstreams have symbol versioning [12:36] and if it's FTBFS due to a symbols mismatch, the consequence is *not* to just adjust the symbols file :) [12:37] introducing tens of diffs dropping php swig support, and discussing a symbols file for 20min ... [12:37] The problem with that is that without knowing the actual public ABI (as opposed to a list of symbols), we don't know whether the public ABI inadvertently changed or not. [12:38] rbasak, sure, we should just drop all symbols files for that reason [12:38] well, *shrug*, you asked for another opinion, I gave it, not going to repeat it as that would just annoy you more :) [12:39] pitti: I appreciate your opinion, thanks. Based on that I'll just add the symbols file and adjust for other archs if needed I guess. [12:39] And I'll bring this up again if/when we get an FTBFS similar to the libecap2 ones. [12:39] rbasak: just to avoid doubt, that was for a soname bump, right? [12:39] pitti: yes, libecap2->3 [12:39] rbasak: and it's totally useful to send that to debian [12:40] doko mentioned that he couldn't before due to some mismatch. How would I check for this? [12:40] arch specific symbols files are very rare for C; they are unfortunately the norm for C++, if it uses that [12:40] if you send the delta right after mering, that should by definition be current [12:40] merging, even [12:40] rbasak, wrong. I said that we had an older libecap in the archive [12:41] Ah, OK, thanks. [12:41] http://paste.ubuntu.com/15196806/ is what I have right now. [12:41] ah, C++ [12:41] I used 1.0.1-2~ since -1 was prior to the gcc 5 transition [12:41] So presumably the symbols were different then. [12:42] it often (but not always) works to demangle them, then one can often avoid the per-arch symbols files; but I don'thave too much experience with those [12:42] Does that make sense for Debian? Or would that be wrong for them since they published libecap3 before the GCC transition also? [12:43] rbasak: Debian might need to adjust it then, but Debian has current g++ 5 now, so either way they need the current version of teh symbols [12:43] (they might need to rename it libcap3v5 then if the new g++ changed the ABI) [12:43] OK, thanks. [12:44] (syncing that should be a no-op for us mostly, so we can do that if we want) [12:44] rbasak, on a first look I don't see anything arch specific. it could be that some symbols are missing on ppc64el due to -O3. [12:44] these can be marked as (optional) then [12:45] particularly stuff which is not part of the real ABI, but just leaking from standard libraries [12:45] yay C++ [12:45] rbasak, this might help you, if there are too many architecture differences: http://pkg-kde.alioth.debian.org/symbolfiles.html [12:46] doko: you mean I should use those tools? They're not KDE specific? I was looking at sed 's/ $_.*$ $.*$/ (c++)"\1" \2/' libfoo.symbols | c++filt from https://wiki.debian.org/UsingSymbolsFiles [12:46] c++filt is nice indeed, makes these actually readable and less platform specific [12:47] :w [12:48] rbasak, it's not KDE specific. you create a symbols file using pkgkde-symbolshelper create, then upload, download all the build logs and update using pkgkde-symbolshelper batchpatch [12:48] OK, thanks. [12:49] but the symbolshelper is not aware of the unmangled notation, afaik [12:50] I'm finding this quite confusing. Lots of information from different sources rather than a single set of steps to follow. If I just use c++filt for now, will that be OK? [12:50] Well apparently not, that just FTBFS. [12:54] sure [12:54] how does it fail? [12:56] http://paste.ubuntu.com/15196904/ - I assume I'm doing something quite essential wrong. [12:57] you're using c++ with the mangled names, not the unmangled ones [12:58] at least for the first symbol [13:00] The symbols file has unmangled names [13:06] the missing symbol is unmangled [13:06] I mean, mangled [13:07] Ah [13:07] Yes, that line does exist in my symbols file. Most of the lines are unmangled. [13:07] Some seem to remain mangled. [13:07] http://paste.ubuntu.com/15196979/ [13:08] Line 85 [13:09] That's the only one I see, so perhaps I could just leave that one mangled. [13:09] run it through c++filt and put that in its place [13:10] c++filt seems to leave it unchanged [13:10] * Laney plays the x-files theme [13:10] so it does [13:10] looks like a bug [13:10] in the demangler [13:11] or mangler [13:13] I left that line undemangled, and the build succeeds. [13:13] I guess that's OK to upload then? I'll clean up the merge first. Thank you for your help. [13:14] sure [13:16] rbasak, might be https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687 [13:16] gcc.gnu.org bug 69687 in c++ "Buffer Overflow in libiberty" [Normal,Unconfirmed] [13:20] Thanks. I guess it's safe to just work around for now by not demangling that symbol? [13:24] infinity, Laney: I taught britney about force-badtest hints for a specific arch but all versions now: http://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/revision/1444 [13:25] infinity, Laney: with that we enforce tests on the non-broken arches again, and don't have to constantly bump the versions for those [13:25] so please use that new syntax from now on [13:32] Looks like i386 and powerpc failed. https://launchpadlibrarian.net/242789112/buildlog_ubuntu-xenial-i386.libecap_1.0.1-3ubuntu1_BUILDING.txt.gz [13:33] Some extra symbols, some missing symbols. [13:33] Should I just mark the missing ones as optional, and forget about the extra ones? [13:34] doko: ^ [13:44] ahh, 32/64bit differences [13:45] rbasak, is it intended that you build without optimization? [13:46] doko: I haven't touched Debian's packaging in this area. [13:47] Looks like the packaging just uses trivial CDBS. [13:47] rbasak, I'll have a look, because it's likely that the symbols will change again with optimization [14:19] mvo, does snappy build on powerpc? [14:20] ohh, neither on s390x [14:20] doko: its fixed on s390x, I will upload the right today [14:20] doko: powerpc is a gccgo issue, I am not sure I can fix that myself [14:39] tseliot: hey Alberto, how are you? [14:40] tseliot: I have two other tiny bits for udev/trusty -- I suppose you want bug 1536438 SRUed? [14:40] bug 1536438 in systemd (Ubuntu Trusty) "Need add uaccess tag for /dev/dri/renderD*" [Undecided,Triaged] https://launchpad.net/bugs/1536438 [14:40] tseliot: would make sense to bundle those three [14:42] doko: do you know of a llvm bug where it doesn't detect avx support on skylake properly? mesa fails llvmpipe tests if built on skylake [14:42] with 3.8 [14:43] apparently it has issues detecting what kind of avx support it has [14:44] tjaalton, sorry, no. [14:44] alright [14:54] doko: hi, could you please take a look at https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1549819 ? It has a 6 line reproducer script [14:54] Launchpad bug 1549819 in python-apt (Ubuntu) "SIGSEGV when reloading cache after setting architecture" [Undecided,New] [14:54] or point us at the current maintainer? [14:56] doko: a landscape-client unit test started core dumping like that in xenial [14:56] * doko stares at mvo ... [14:59] ahasenack, could you check if a python-apt rebuild helps? we recently upgraded apt. juliank might want to comment too [15:00] hmm,not rebuilt in Debian [15:02] doko: I'll try that [15:02] doko: also, do you know where I can find the core dump? [15:02] ubuntu@landscape-client-xenial:~$ ./foo.py [15:02] Segmentation fault (core dumped) [15:02] it's nowhere, not in /var/crash or $PWD [15:02] ulimit -c says unlimited [15:03] ahasenack: what doko said, a rebuild would be nice first, if that does not help I can have a look later [15:04] installing build deps... [15:04] mvo, looking at the ubuntu-snappy MIR, those golang packages don't have the right naming schemes. Which means when Debian adds packages for them, we won't be in sync at all [15:05] mterry: uh, could you please comment in the bug so that I can sort it out? [15:06] doko: it's a mesa bug after all, was fine with 11.1 but 11.2rc breaks [15:10] mvo: it still core dumps after I rebuild and reinstall python-apt [15:10] mvo: it's inside a xenial lxd, if that matters [15:11] There's a bug somewhere in APT's cache generation [15:11] ahasenack: interessing, I get http://paste.ubuntu.com/15197818/ when I run your script [15:11] juliank: can you redproduce the segfault? [15:11] mvo: on a real xenial host, or vm? [15:12] ahasenack: real systemm [15:12] system [15:12] mvo: Have not tried it, but there's still some seg fault in the cache generation not fixed yet, so I'd love to get a complete backtrace [15:12] juliank: I can't find the core dump file [15:12] We probably missed a stringview that needs to be moved when the cache is moved [15:12] ulimit -c is unlimited, nothing in /var/crash or $PWD [15:13] Any service for core dumps installed? For example, I use systemd-coredump which stores them into /var/lib/systemd/coredump [15:13] there can be other handlers [15:13] let me check [15:14] that directory is empty here [15:14] I can remove apport [15:14] You could also run it in gdb if you have the debugging symbols available. [15:15] it's a python script [15:15] and how is that problematic? [15:15] still no core dump even with apport removed [15:16] Anyway, apt-cache gencaches should crash as well if you pass it a config file with -c that contains APT::Architecture ""; [15:17] For mvo, it works correctly. [15:18] FTR, this is likely http://bugs.debian.org/812251 [15:18] Debian bug 812251 in apt "apt: suddenly segfaults after "apt update"" [Important,Fixed] [15:19] Try this reproducer: http://paste.ubuntu.com/15197886/ [15:19] Of course, setting Architecture to an empty string won't work, but it should at least build a cache [15:20] juliank: that crashed here [15:20] Great [15:20] juliank: I'm trying to find all the dbg packages I need [15:21] Only interested in libapt-pkg5.0 ddeb [15:21] the bt isn't that great yet [15:21] http://pastebin.ubuntu.com/15197906/ [15:22] I'm not sure where the dbgsym are in the archive, but this one should be it: https://launchpad.net/ubuntu/xenial/amd64/libapt-pkg5.0-dbgsym/1.2.3 [15:24] But that seems like a bad place to crash in [15:24] pitti: hi. Yes, I'd like that SRU. Where do I find the other changes? [15:25] juliank: ok, now I have something more [15:25] Do bt full [15:25] tseliot: it's bug 1473800 and bug 1535255 [15:25] bug 1473800 in systemd (Ubuntu Trusty) "restarting logind during systemd update causes screen to lock" [Undecided,Triaged] https://launchpad.net/bugs/1473800 [15:25] bug 1535255 in systemd (Ubuntu Trusty) "Inconsistency in /usr/share/initramfs-tools/hooks/udev file causes configuration failure" [Undecided,Triaged] https://launchpad.net/bugs/1535255 [15:25] tseliot: but if you want I can upload the SRU for all three, your's is quite simple too [15:26] juliank: http://pastebin.ubuntu.com/15197953/ still a few "optimized out" bits [15:26] pitti: yes, please [15:26] tseliot: ack, will do [15:26] pitti: thanks [15:28] pitti: lxc-copy [15:28] stgraber: ah, thanks; I didn't see an announcement yet on the homepage [15:28] ahasenack: I see. But it just crashes because you specified an invalid empty architecture there, AFAICT. [15:29] well, yes [15:29] But that's not really problematic. [15:29] stgraber: OOI, will lxc-clone remain in xenial? I wonder if I need to teach autopkgtest's lxc runner to get along with both, or whether it can just continue to call lxc-clone [15:29] Who specifies "" as an architecture in real life? [15:29] You told APT that your system has no architectures. [15:30] pitti: we will keep lxc-clone and lxc-start-ephemeral around in Xenial, yes. Removing them now would cause too much breakage I think. [15:30] juliank: it's something that < xenial was ok with we had it as a unit test, and it started failing [15:30] pitti: we'll likely get rid of them immediately after y opens though [15:30] ahasenack: This has to fail. But it should not crash [15:30] stgraber: thanks for the heads-up [15:30] right [15:31] It also does not fail on multi-arch systems [15:32] juliank: it seems to crash only on a container, though [15:32] because they'll have the secondary architectures set from APT::Architectures [15:32] juliank: that tells me something else is going on [15:32] Read what I wrote [15:32] irc lag, I'm sure you are used to it [15:33] bdmurray, can you add ~snappy-dev to your package-subscribers list? [15:34] ahasenack: Should be fixed in a few mins [15:41] Writing a test case now [15:42] juliank: thx a lot [15:42] I attached your reproducer and the bt full to the bug [15:46] mterry: yep [15:47] davmor2, cyphermox, those upgrade issues with fontconfig look like the binary is updated before the lib and the cache update fails on missing symbol, updating the libfontconfig shlibs would likely do the trick [15:47] cheers [15:48] ahasenack: Fixed in https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=9de2fd4 [15:49] There will be a 1.2.4 release shortly [15:49] juliank: \o/ [15:49] thx a lot [15:50] seb128: nice, thanks [15:50] davmor2, yw [15:54] I'm still hoping I can reproduce (1) the other APT crash when building the cache and (2) the messed up index files sometime (part of last line is repeated) [15:54] Well, (2) might be fixed these days [15:55] (1) will be easy once there's a backtrace [16:00] seb128: ack [16:13] xnox: the cloud images are achingly fat, so it's quite a bit of a purge fest to minimize them [16:13] xnox: the images.linuxcontainers.org are much nicer, only 1/8th the size, faster, and minimal [16:13] xnox: right now I'm using the lxc "ubuntu" template which is similarly small [16:13] xnox: but anyway, I do have the purge list, I mostly just didn't get around to setting this up with lxd yet [16:15] pitti, horum. if they are "fat" we can trim them. I understood they have cloud-init + nested lxd, and that's it. [16:15] xnox: this morning I accidentally had cloud-init in a container, which completely breaks them :) [16:15] (although with lxc plain, maybe lxd has some provision for them) [16:16] slangasek: so twig is unlikely to build (test) for a bit, as i think it triggers an actual bug in php7.0, which is then going to gate symfony and php-doctrine-bundle. Any recommendations? I've filed the PHP bug, but not sure how quickly it'll get looked at [16:17] xnox: ah, maybe the s390 ones are smaller? x86 cloud images have apt-xapian-index, cryptsetup, ureadahead, lxc, lxd, lvm2, mdadm, ppp, w3m, vim, and loads of other stuff that doesn't belong into a container [16:20] Pharaoh_Atem: ping [16:21] smoser: ^ [16:21] Also kirkland ^ [16:21] About "fat" cloud images. [16:21] This comes up every so often. Either we want them to be slim or we want them to be "comfortable". We cannot have both. [16:21] Doesn't belong in a container, but does belong in an Ubuntu-server-that-works-on-a-cloud image. [16:22] Well, not all of those things, perhaps. [16:22] There's also a goal to make the Ubuntu experience the same regardless of whether you're using a VM or a container. [16:22] (Looking at you, ppp) [16:22] This comes at the cost of having some stuff that doesn't make sense in a particular environment, but the win is that users don't get surprises switching from mode to another. [16:23] Odd_Bloke, ppp is gone i think [16:23] Oh, cool. [16:23] yeah, i dropped hat a while ago. [16:25] cloud-image and server are now basically the same. [16:25] http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.xenial/revision/2413 [16:25] we also dropped wireless-tools wpasupplicant and memtest86+. [16:25] xenial cloud imags smaller than wily [16:26] thats the first reduction in quite some time. [16:26] rbasak: well, most container workloads shouldn't/don't have a "human experience" [16:26] i am absolutely not goign to say there is no fat. but i believe that just about everything in the seed is justifiable. [16:26] they should be managed completely automatically, and be as dense/efficient as possible [16:27] indeed, the x86 ones got trimmed recently, thanks for that; some 380 MB to 290 MB [16:27] but, container images are 65 MB [16:27] pitti: I think there are a bunch of different desires that work against each other here. No single answer will suit everyone. A container you describe is certainly useful, but so is a fat one. [16:27] pitti: Definitely; but that isn't what the cloud images are designed to be. :) [16:27] rbasak: sure, hence the need to have either two images, or a simple way to install the "comfy" bits [16:27] pitti: ultimately kirkland has to balance whose things. [16:28] with a cloud-init option, or "apt-get install ubuntu-server-standard" or so [16:28] those things [16:28] AIUI, we don't ship the minimal thing you want right now, and I'm not aware of any plans to do so, apart from "core" as it used to be called. [16:28] with "one size fits it all" you either provide a really bad "interactive" experience, or you penalize every container/juju workload by shipping tons of unnecessary stuff [16:29] rbasak: actually we do, I'm quite happy with teh images.linuxcontainers.org images [16:29] Is it really a "penalize" though? [16:29] sure [16:29]