naccslangasek: doko: php-rrd failure is an obvious thinko in debian ... bug filed00:43
naccPharaoh_Atem: can you look at the php7.0 failures on armhf and s390x? (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html)00:43
naccslangasek: doko: i think i can fix imagick, it looks to be another relatively obvious issue with debian's package, will work on it tmrw01:10
naccbut i think most of the php7.0 excuses are now covered01:10
=== juliank_ is now known as juliank
cpaelzergood morning06:09
pittiGood morning06:56
dholbachgood morning07:51
=== davidcalle_afk is now known as davidcalle
LocutusOfBorggood morning!08:28
pittistgraber: oh, looking forward to learn what the replacement of lxc-clone/ephemeral will be :)08:34
darkxstdholbach, did it occur to you that its beta1 release eve, how was I going to pilot! anyway I moved it to next week ;)08:56
dholbachdarkxst, I'm just putting together a rough schedule as a reminder08:59
dholbachif I took into account all local holidays, freeze dates and everything else, it'd take me weeks to put together :-)08:59
dholbachthanks for moving to another day08:59
darkxstdholbach, ha, yeh, didnt think of it like that ;)09:00
darkxstanyway no problem09:00
darkxstits been a bumpy beta1 ;(09:00
dholbachluckily there's still some time to fix bugs09:02
* darkxst waiting on upload to migrate so I can re-spin images and hopefully fix 4 or so bugs09:03
pittislangasek, infinity, doko, Laney: please be aware of http://bazaar.launchpad.net/~ubuntu-release/britney/britney2-ubuntu/revision/57909:09
pittihttp://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html is updated for that now09:09
pittislangasek, infinity, doko, Laney: TL/DR: hinted regressions are now shown in yellow as "Ignored failure", so all red "Regressions" are "real"09:09
Laneypitti: nice09:09
pittimakes the output much easier to read, no more searching for the "ignored failure foo" 20 lines below09:10
pittiand makes retry-autopkgtest-regressions more useful09:10
pittias it won't retry the known-failing ones09:10
pittiand e. g. http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#python-numpy is much easier to read now09:14
infinitypitti: Nice.09:29
=== vrruiz_ is now known as rvr
=== Chipaca` is now known as Chipaca
StevenK /wii pitti10:13
dokoLocutusOfBorg, ping on llvm3.8 rc3?10:16
LocutusOfBorgping sylvestre, I never packaged a new upstream release10:17
LocutusOfBorgI already pinged him about llvm-3.710:17
FourDollarscyphermox: 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:27
dholbachFourDollars, sure, adding it to my TODO list :)10:28
FourDollarsdholbach: Thx a lot.10:28
LocutusOfBorgFourDollars, ^^^ maybe you want to add them to the wiki page10:29
LocutusOfBorgso your sponsor knows what they sponsored to you :)10:30
FourDollarsLocutusOfBorg: 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:30
FourDollarsLocutusOfBorg: Please also check Ubuntu Sponsorship Miner <-10:31
FourDollarsLocutusOfBorg: Maybe I should raise it up. Thx.10:31
LocutusOfBorgoh... I found it10:32
LocutusOfBorgsorry then :)10:32
FourDollarsLocutusOfBorg: np. I should put it in the first line so people can easily find it.10:33
LocutusOfBorgI didn't change the link in my MOTU application10:34
LocutusOfBorgso it was "searchable" with find tool10:34
FourDollarsI see.10:36
FourDollarsLet me refine my wiki page.10:37
jamespageinfinity, changed my mind on using the dpdk binary by default as it also requires hugepages to be configured otherwise it borks11:42
jamespagecpaelzer, hey - are you working on the underlinking issue in dpdk?11:48
cpaelzerjamespage: yes11:50
cpaelzerjamespage: I have this one fixed along with a few others, there are some itches left11:51
jamespagecpaelzer, awesome! I've uploaded ovs with dpdk enabled and requested that ovs-dpdk be removed from the archive11:51
cpaelzerjamespage: if things go well I'll prepare an upload for review today - if not I hope tomorrow11:51
cpaelzerjamespage: I've seen the bug updates seeing dpdk pulled into main by that - huge thanks for that11:52
* cpaelzer hugs jamespage11:52
jamespagecpaelzer, no problem - thanks for the dpdk work11:52
jamespagecpaelzer, I decided not to enable by default based on cpu features...11:52
cpaelzerjamespage: the underlinking itself will be fixed for sure, it is just not certain yet how much more I can fix in this one upload11:52
cpaelzerjamespage: so is it !default in general (because we are afraid of regressions) or is it "default = sse3 ? openvswitch-dpdk : openvswitch"11:53
jamespagecpaelzer, no - you just install openvswitch-switch and then switch between versions using alternatives11:54
jamespageso no extra package11:54
jamespagecpaelzer, its really ssse3 + hugepages configured correctly11:54
jamespageI guess we could do that but I'd rather make it a little more explicit for now11:54
cpaelzerjamespage: I clearly prefer not being the default as long as it needs to mature so much IMHO11:55
jamespagecpaelzer, agreed11:58
jamespagecpaelzer, https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/openvswitch12:01
jamespageI've updated the Vcs fields in the repo - they will go with the next upload12:02
cpaelzerjamespage: cool, I did the same for DPDK already which will be in the next upload as well (VCS)12:04
cpaelzerjamespage: 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
jamespagecpaelzer, I did for xenstore and pcap - but I hit a dl one when backporting atm12:05
jamespage(that's on 14.04 only)12:05
cpaelzerjamespage: ok we can try that with the new version then as soon as I'm done with it12:06
jamespagecpaelzer, ok12:06
rbasakdoko: 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:10
rbasakAlso libecap is only used by squid. It's barely a shared library.12:11
dokorbasak, don't do that12:11
rbasakdoko: OK, well can you merge libecap then please?12:11
dokorbasak, symbols files are a requirement for MIRs12:11
rbasakA 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
dokorbasak, it belongs to the server team, so it's your task12:11
dokorbasak, why?12:12
rbasakIt's only used by squid, so is barely a shared library at all. It might as well be static.12:12
rbasakAnd, 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
rbasakSo what's the point?12:13
dokoand you mean just because you update squid every two years, it's not necessary?12:13
hrwcan someone remove linux-chromebook from archive for me?12:13
hrwI am still listed as maintainer when no one is using this package and I do not even have hardware for it.12:14
cjwatsonhrw: Could you file a bug against it with an explanation, and subscribe ubuntu-archive?12:14
rbasakI 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
cjwatsonGives us an audit trail12:14
hrwcjwatson: thanks, will do12:14
rbasakdoko: if you disagree, then please explain how the symbols file could be useful in this case.12:14
=== _salem is now known as salem_
cjwatsonapw: ^- do you agree with hrw's request above, since you uploaded it yesterday?12:15
dokorbasak, it will remind you when a soname bump is needed, or a package rename is needed if upstream dops symbols without changing the soname12:15
dokoand I probably didn't forward the patch to debian, because it was outdated12:16
dokodebian had the new version for a long time12:16
rbasakdoko: 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
apwcjwatson, 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 package12:16
hrwcjwatson: https://bugs.launchpad.net/ubuntu/+source/linux-chromebook/+bug/154978212:17
ubottuLaunchpad bug 1549782 in linux-chromebook (Ubuntu) "Please remove it from archive" [Undecided,New]12:17
dokorbasak, so the savings is just for you, because you don't care to rename the package for these cases?12:17
rbasakdoko: as I said, it is only squid that uses it.12:17
hrwapw: as the only maintainer of it I would love to see it gone ;d12:17
rbasakdoko: and we don't know what the formal ABI is, anyway.12:17
apwhrw, works for me, it is anchient12:17
dokosorry, I don't get it why we have this discussion. no, you can't know if external software uses it12:18
hrwapw: it was when got added but at that time it was acceptable solution12:18
rbasakWhich is fine, but what am I supposed to do when the symbols file flags an ABI difference?12:18
rbasakEveryone else seems to just change the symbols file.12:18
rbasakdoko: because you don't care> and you didn't care to send the change to Debian, so what's the difference?12:20
rbasakdoko: 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:20
dokorbasak, you're wrong. I couldn't send anything to debian, because the versions didn't match12:21
rbasakdoko: unless you want to take the merge?12:21
cjwatsonhrw: subscribe, not assign :)  (fixing)12:21
hrwcjwatson: long time since I used launchpad ;D12:21
dokorbasak, that's blackmailing12:21
rbasakdoko: and you're just creating work for me with no justification.12:22
rbasak(I would really like someone else to chime in here, please)12:22
rbasakI'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
rbasakLook at the history of libecap uploads in Ubuntu.12:22
rbasakI 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
cjwatsonhrw: done12:23
hrwcjwatson: thanks a lot12:24
hrwapw: thanks for reminding me (by upload) that this package still exists12:24
apwhrw, heh you are very welcome :)12:25
pittidoko, 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 soname12:29
pittidoko, 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 only12:29
rbasakpitti: sure, I understand that. I think I'm saying that "maintaining" a symbols file in an Ubuntu delta is pointless.12:29
pittiif it's just one consumer, then there's little point to even pretend that it woudl be a generally usable library12:30
pittirbasak: it's not12:30
pittirbasak: if you build a shared library, you make a commitment and a promise12:30
pittiand if you don't want to keep that, don't build a shared library12:30
rbasakpitti: sure. Sorry, I mean in this specific case, not the general case.12:30
rbasakpitti: 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
pittirbasak: exactly my point :)12:31
rbasakThat's what I'm saying is pointless. Given that we're doing this, why maintain the symbols file at all?12:31
rbasakI'll accept that not shipping a shared library the right answer, but unfortunately we're just downstream of Debian here.12:31
pittiit's not pointless, it's pointing you towards the real error: your library broke ABI12:31
pittiwell, then file an RC bug against Debian and let it get auto-removed, or something12:32
rbasakI 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
pittichanging 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 dependencies12:32
dokorbasak, 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 others12:32
pittibut that's what a static library is for then12:32
pittidoko: *nod*12:33
rbasakpitti: incidentally the ABI change was historical and in libecap2. They've had a soname bump now.12:33
rbasakSo I can't really file an RC bump now, seeing as they have bumped the soname.12:33
rbasakAn RC bug that is.12:33
pittirbasak: ah, if they did, what's the problem then?12:33
pittion a soname bump it's totally legitimate to update the symbols files12:34
rbasakpitti: I feel that I'm recreating the symbols file again for no real reason.12:34
rbasakpitti: given the history of symbols files being arbitrarily changed.12:34
pittiwell, changing symbols files without soname bump -> don't do that12:34
pittichangign symbosl files with a soname bump -> normal operation12:34
rbasakpitti: 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
pittiwell, I disagree12:35
rbasak(like you said, it'a a symptom)12:35
rbasakIf 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
pittiif we have a package in main and want that to work properly, then things like symbols files are a great help to avoid breaking stuff12:35
pittiand an FTBFS due to symbols mismatch is infinitely better than having to scrape off apport crash reports after the fact12:36
dokorbasak, symbols files are part of the packaging, not about upstream12:36
dokosome upstreams have symbol versioning12:36
pittiand if it's FTBFS due to a symbols mismatch, the consequence is *not* to just adjust the symbols file :)12:36
dokointroducing tens of diffs dropping php swig support, and discussing a symbols file for 20min ...12:37
rbasakThe 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:37
dokorbasak, sure, we should just drop all symbols files for that reason12:38
pittiwell, *shrug*, you asked for another opinion, I gave it, not going to repeat it as that would just annoy you more :)12:38
rbasakpitti: 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
rbasakAnd I'll bring this up again if/when we get an FTBFS similar to the libecap2 ones.12:39
pittirbasak: just to avoid doubt, that was for a soname bump, right?12:39
rbasakpitti: yes, libecap2->312:39
pittirbasak: and it's totally useful to send that to debian12:39
rbasakdoko mentioned that he couldn't before due to some mismatch. How would I check for this?12:40
pittiarch specific symbols files are very rare for C; they are unfortunately the norm for C++, if it uses that12:40
pittiif you send the delta right after mering, that should by definition be current12:40
pittimerging, even12:40
dokorbasak, wrong. I said that we had an older libecap in the archive12:40
rbasakAh, OK, thanks.12:41
rbasakhttp://paste.ubuntu.com/15196806/ is what I have right now.12:41
pittiah, C++12:41
rbasakI used 1.0.1-2~ since -1 was prior to the gcc 5 transition12:41
rbasakSo presumably the symbols were different then.12:41
pittiit 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 those12:42
rbasakDoes that make sense for Debian? Or would that be wrong for them since they published libecap3 before the GCC transition also?12:42
pittirbasak: Debian might need to adjust it then, but Debian has current g++ 5 now, so either way they need the current version of teh symbols12:43
pitti(they might need to rename it libcap3v5 then if the new g++ changed the ABI)12:43
rbasakOK, thanks.12:43
pitti(syncing that should be a no-op for us mostly, so we can do that if we want)12:44
dokorbasak, 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
pittithese can be marked as (optional) then12:44
pittiparticularly stuff which is not part of the real ABI, but just leaking from standard libraries12:45
pittiyay C++12:45
dokorbasak, this might help you, if there are too many architecture differences: http://pkg-kde.alioth.debian.org/symbolfiles.html12:45
rbasakdoko: 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/UsingSymbolsFiles12:46
pittic++filt is nice indeed, makes these actually readable and less platform specific12:46
dokorbasak, 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 batchpatch12:48
rbasakOK, thanks.12:48
dokobut the symbolshelper is not aware of the unmangled notation, afaik12:49
rbasakI'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
rbasakWell apparently not, that just FTBFS.12:50
dokohow does it fail?12:54
rbasakhttp://paste.ubuntu.com/15196904/ - I assume I'm doing something quite essential wrong.12:56
dokoyou're using c++ with the mangled names, not the unmangled ones12:57
dokoat least for the first symbol12:58
rbasakThe symbols file has unmangled names13:00
dokothe missing symbol is unmangled13:06
dokoI mean, mangled13:06
rbasakYes, that line does exist in my symbols file. Most of the lines are unmangled.13:07
rbasakSome seem to remain mangled.13:07
rbasakLine 8513:08
rbasakThat's the only one I see, so perhaps I could just leave that one mangled.13:09
Laneyrun it through c++filt and put that in its place13:09
rbasakc++filt seems to leave it unchanged13:10
* Laney plays the x-files theme13:10
Laneyso it does13:10
dokolooks like a bug13:10
dokoin the demangler13:10
dokoor mangler13:11
rbasakI left that line undemangled, and the build succeeds.13:13
rbasakI guess that's OK to upload then? I'll clean up the merge first. Thank you for your help.13:13
dokorbasak, might be https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6968713:16
ubottugcc.gnu.org bug 69687 in c++ "Buffer Overflow in libiberty" [Normal,Unconfirmed]13:16
rbasakThanks. I guess it's safe to just work around for now by not demangling that symbol?13:20
pittiinfinity, 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/144413:24
pittiinfinity, Laney: with that we enforce tests on the non-broken arches again, and don't have to constantly bump the versions for those13:25
pittiso please use that new syntax from now on13:25
rbasakLooks like i386 and powerpc failed. https://launchpadlibrarian.net/242789112/buildlog_ubuntu-xenial-i386.libecap_1.0.1-3ubuntu1_BUILDING.txt.gz13:32
rbasakSome extra symbols, some missing symbols.13:33
rbasakShould I just mark the missing ones as optional, and forget about the extra ones?13:33
rbasakdoko: ^13:34
dokoahh, 32/64bit differences13:44
dokorbasak, is it intended that you build without optimization?13:45
rbasakdoko: I haven't touched Debian's packaging in this area.13:46
rbasakLooks like the packaging just uses trivial CDBS.13:47
dokorbasak, I'll have a look, because it's likely that the symbols will change again with optimization13:47
dokomvo, does snappy build on powerpc?14:19
dokoohh, neither on s390x14:20
mvodoko: its fixed on s390x, I will upload the right today14:20
mvodoko: powerpc is a gccgo issue, I am not sure I can fix that myself14:20
pittitseliot: hey Alberto, how are you?14:39
pittitseliot: I have two other tiny bits for udev/trusty -- I suppose you want  bug 1536438 SRUed?14:40
ubottubug 1536438 in systemd (Ubuntu Trusty) "Need add uaccess tag for /dev/dri/renderD*" [Undecided,Triaged] https://launchpad.net/bugs/153643814:40
pittitseliot: would make sense to bundle those three14:40
tjaaltondoko: do you know of a llvm bug where it doesn't detect avx support on skylake properly? mesa fails llvmpipe tests if built on skylake14:42
tjaaltonwith 3.814:42
tjaaltonapparently it has issues detecting what kind of avx support it has14:43
dokotjaalton, sorry, no.14:44
ahasenackdoko: hi, could you please take a look at https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1549819 ? It has a 6 line reproducer script14:54
ubottuLaunchpad bug 1549819 in python-apt (Ubuntu) "SIGSEGV when reloading cache after setting architecture" [Undecided,New]14:54
ahasenackor point us at the current maintainer?14:54
ahasenackdoko: a landscape-client unit test started core dumping like that in xenial14:56
* doko stares at mvo ... 14:56
dokoahasenack, could you check if a python-apt rebuild helps? we recently upgraded apt. juliank might want to comment too14:59
dokohmm,not rebuilt in Debian15:00
ahasenackdoko: I'll try that15:02
ahasenackdoko: also, do you know where I can find the core dump?15:02
ahasenackubuntu@landscape-client-xenial:~$ ./foo.py15:02
ahasenackSegmentation fault (core dumped)15:02
ahasenackit's nowhere, not in /var/crash or $PWD15:02
ahasenackulimit -c says unlimited15:02
mvoahasenack: what doko said, a rebuild would be nice first, if that does not help I can have a look later15:03
ahasenackinstalling build deps...15:04
mterrymvo, 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 all15:04
mvomterry: uh, could you please comment in the bug so that I can sort it out?15:05
tjaaltondoko: it's a mesa bug after all, was fine with 11.1 but 11.2rc breaks15:06
ahasenackmvo: it still core dumps after I rebuild and reinstall python-apt15:10
ahasenackmvo: it's inside a xenial lxd, if that matters15:10
juliankThere's a bug somewhere in APT's cache generation15:11
mvoahasenack: interessing, I get http://paste.ubuntu.com/15197818/ when I run your script15:11
mvojuliank: can you redproduce the segfault?15:11
ahasenackmvo: on a real xenial host, or vm?15:11
mvoahasenack: real systemm15:12
juliankmvo: 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 backtrace15:12
ahasenackjuliank: I can't find the core dump file15:12
juliankWe probably missed a stringview that needs to be moved when the cache is moved15:12
ahasenackulimit -c is unlimited, nothing in /var/crash or $PWD15:12
juliankAny service for core dumps installed? For example, I use systemd-coredump which stores them into /var/lib/systemd/coredump15:13
juliankthere can be other handlers15:13
ahasenacklet me check15:13
ahasenackthat directory is empty here15:14
ahasenackI can remove apport15:14
juliankYou could also run it in gdb if you have the debugging symbols available.15:14
ahasenackit's a python script15:15
juliankand how is that problematic?15:15
ahasenackstill no core dump even with apport removed15:15
juliankAnyway, apt-cache gencaches should crash as well if you pass it a config file with -c that contains APT::Architecture "";15:16
juliankFor mvo, it works correctly.15:17
juliankFTR, this is likely http://bugs.debian.org/81225115:18
ubottuDebian bug 812251 in apt "apt: suddenly segfaults after "apt update"" [Important,Fixed]15:18
juliankTry this reproducer: http://paste.ubuntu.com/15197886/15:19
juliankOf course, setting Architecture to an empty string won't work, but it should at least build a cache15:19
ahasenackjuliank: that crashed here15:20
ahasenackjuliank: I'm trying to find all the dbg packages I need15:20
juliankOnly interested in libapt-pkg5.0 ddeb15:21
ahasenackthe bt isn't that great yet15:21
juliankI'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.315:22
juliankBut that seems like a bad place to crash in15:24
tseliotpitti: hi. Yes, I'd like that SRU. Where do I find the other changes?15:24
ahasenackjuliank: ok, now I have something more15:25
juliankDo bt full15:25
pittitseliot: it's bug 1473800 and bug 153525515:25
ubottubug 1473800 in systemd (Ubuntu Trusty) "restarting logind during systemd update causes screen to lock" [Undecided,Triaged] https://launchpad.net/bugs/147380015:25
ubottubug 1535255 in systemd (Ubuntu Trusty) "Inconsistency in /usr/share/initramfs-tools/hooks/udev file causes configuration failure" [Undecided,Triaged] https://launchpad.net/bugs/153525515:25
pittitseliot: but if you want I can upload the SRU for all three, your's is quite simple too15:25
ahasenackjuliank: http://pastebin.ubuntu.com/15197953/ still a few "optimized out" bits15:26
tseliotpitti: yes, please15:26
pittitseliot: ack, will do15:26
tseliotpitti: thanks15:26
stgraberpitti: lxc-copy15:28
pittistgraber: ah, thanks; I didn't see an announcement yet on the homepage15:28
juliankahasenack: I see. But it just crashes because you specified an invalid empty architecture there, AFAICT.15:28
ahasenackwell, yes15:29
juliankBut that's not really problematic.15:29
pittistgraber: 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-clone15:29
juliankWho specifies "" as an architecture in real life?15:29
juliankYou told APT that your system has no architectures.15:29
stgraberpitti: 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
ahasenackjuliank: it's something that < xenial was ok with we had it as a unit test, and it started failing15:30
stgraberpitti: we'll likely get rid of them immediately after y opens though15:30
juliankahasenack: This has to fail. But it should not crash15:30
pittistgraber: thanks for the heads-up15:30
juliankIt also does not fail on multi-arch systems15:31
ahasenackjuliank: it seems to crash only on a container, though15:32
juliankbecause they'll have the secondary architectures set from APT::Architectures15:32
ahasenackjuliank: that tells me something else is going on15:32
juliankRead what I wrote15:32
ahasenackirc lag, I'm sure you are used to it15:32
mterrybdmurray, can you add ~snappy-dev to your package-subscribers list?15:33
juliankahasenack: Should be fixed in a few mins15:34
juliankWriting a test case now15:41
ahasenackjuliank: thx a lot15:42
ahasenackI attached your reproducer and the bt full to the bug15:42
bdmurraymterry: yep15:46
seb128davmor2, 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 trick15:47
juliankahasenack: Fixed in https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=9de2fd415:48
juliankThere will be a 1.2.4 release shortly15:49
ahasenackjuliank: \o/15:49
ahasenackthx a lot15:49
davmor2seb128: nice, thanks15:50
seb128davmor2, yw15:50
juliankI'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
juliankWell, (2) might be fixed these days15:54
juliank(1) will be easy once there's a backtrace15:55
cyphermoxseb128: ack16:00
pittixnox: the cloud images are achingly fat, so it's quite a bit of a purge fest to minimize them16:13
pittixnox: the images.linuxcontainers.org are much nicer, only 1/8th the size, faster, and minimal16:13
pittixnox: right now I'm using the lxc "ubuntu" template which is similarly small16:13
pittixnox: but anyway, I do have the purge list, I mostly just didn't get around to setting this up with lxd yet16:13
xnoxpitti, horum. if they are "fat" we can trim them. I understood they have cloud-init + nested lxd, and that's it.16:15
pittixnox: this morning I accidentally had cloud-init in a container, which completely breaks them :)16:15
pitti(although with lxc plain, maybe lxd has some provision for them)16:15
nacc_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 at16:16
pittixnox: 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 container16:17
nacc_Pharaoh_Atem: ping16:20
rbasaksmoser: ^16:21
rbasakAlso kirkland ^16:21
rbasakAbout "fat" cloud images.16:21
rbasakThis 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
Odd_BlokeDoesn't belong in a container, but does belong in an Ubuntu-server-that-works-on-a-cloud image.16:21
Odd_BlokeWell, not all of those things, perhaps.16:22
rbasakThere's also a goal to make the Ubuntu experience the same regardless of whether you're using a VM or a container.16:22
Odd_Bloke(Looking at you, ppp)16:22
rbasakThis 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:22
smoserOdd_Bloke, ppp is gone i think16:23
Odd_BlokeOh, cool.16:23
smoseryeah, i dropped hat a while ago.16:23
smosercloud-image and server are now basically the same.16:25
smoserwe also dropped wireless-tools wpasupplicant and memtest86+.16:25
smoserxenial cloud imags smaller than wily16:25
smoserthats the first reduction in quite some time.16:26
pittirbasak: well, most container workloads shouldn't/don't have a "human experience"16:26
smoseri am absolutely not goign to say there is no fat. but i believe that just about everything in the seed is justifiable.16:26
pittithey should be managed completely automatically, and be as dense/efficient as possible16:26
pittiindeed, the x86 ones got trimmed recently, thanks for that; some 380 MB to 290 MB16:27
pittibut, container images are 65 MB16:27
rbasakpitti: 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
Odd_Blokepitti: Definitely; but that isn't what the cloud images are designed to be. :)16:27
pittirbasak: sure, hence the need to have either two images, or a simple way to install the "comfy" bits16:27
rbasakpitti: ultimately kirkland has to balance whose things.16:27
pittiwith a cloud-init option, or "apt-get install ubuntu-server-standard" or so16:28
rbasakthose things16:28
rbasakAIUI, 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
pittiwith "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 stuff16:28
pittirbasak: actually we do, I'm quite happy with teh images.linuxcontainers.org images16:29
rbasakIs it really a "penalize" though?16:29
Odd_BlokeThe argument for favouring the "comfy" use case is probably that anyone doing serious container stuff will be customising the images anyway.16:29
pittiit's 5x the download, HD size, unpack, upgrade size, plus the longer boot time etc.16:29
rbasakHow expensive is it really?16:29
rbasakRight, but how expensive is _that_ really? :)16:30
pittiwell, how expensive is "5x expensive" -- I'd say "5 times"? :-)16:30
Odd_Blokerbasak: A major selling point for containers is density, so it does make a substantial impact in those terms.16:30
pitti(storage space)16:30
pittiit's less well defined for dist-upgrade and boot time of course16:30
smoserwasted processor use and memory are one thing, and we can and should make packages disabler themselves if they're not in an environment where they'd be used.16:30
rbasakIt's mostly disk space. That isn't the bottleneck for container density, AIUI.16:30
pittibut it's much easier to install a metapackage to an "interactive" cloud workload where/when you actually need it (which should not be the common case)16:31
rbasak"5 times" more expensive is nothing if it's $0.00000001 to $0.00000005.16:31
pittithan maintaining an ever-growing list of packages to purge, as that's really error prone16:31
pittiwell, here's the thing:16:32
rbasak"maintaining an ever-growing list of packages to purge" is just because your use case isn't currently supported, and what you're doing is a workaround.16:32
pittiif you say that 5x the download size isn't a noticeable penalty, what's wrong with enabling the apt-get install of a "comfy" metapackage when you enable it16:32
pittias that'll download the same things, but much less often16:32
rbasakThe time is a penalty when doing interactive work.16:32
rbasakIt doesn't matter so much for non-interactive work.16:32
rbasakDeveloper time is what is most expensive.16:32
pittiwell, as I said, I'm quite happy with the images.linuxcontainers.org images16:33
pittirbasak: developer time> exactly16:33
pitticf. "maintaining an ever-growing purge list"16:33
pittiI know how brittle and maintenance-intense it is because I'm doing it16:34
pittiI have to do it for x86/ppc64el images anyway, but I don't need to for the arches where I'm currently using LXC/LXD because these already have small images16:34
pittianyway, this just started out as an explanation to xnox why I prefer the lxc images16:35
* hallyn points rbasak to the cost of bandwidth over satelite :)16:35
pittino doubt the classic "ubuntu server" experience shouldl have vim and stuff installed, as these are more geared towards humans16:35
Odd_Blokehallyn: Ah, yes, the classic cloud use case. ;)16:35
pittibut "noninteractive container/VM" and "interactive server" are quite different use cases, and unifying them will always make people unhappy16:36
Odd_BlokeI guess it does potentially go through literal clouds...16:36
hallynOdd_Bloke: i rest my case16:36
rbasakhallyn: if you're using satellite, you are presumably already caching the images. The one-off hit is still presumably insignificant.16:36
rbasakAnyway, I defer to kirkland. I understand there are use cases where "comfortable" is a pain.16:37
rbasakpitti: I don't think we're unifying them. We're just not doing the slim one right now.16:37
pittithe one package which is the most contentious one is probably cloud-init16:37
xnoxOdd_Bloke, pitti - it's just lxd images are used as "full cloud images" in e.g. openstack-lxd. And they are also used as minimal bootstrap chroots in like "juju" case or the stuff you do.16:37
xnoximho there is room for more minimalistic lxd image.16:38
hallynrbasak: i think the cost is wroth it, i just object to your over-trivialization of the cost :)16:38
pittixnox: lxd images are fairly minimal, mostly debootstrap really16:39
xnoxpitti, when i say lxd images -> i mean the lxd image we publish at cloud-images.ubuntu.com. not the stgraber image =)16:39
sergiusensbarry, hey, is a fix for this coming soon http://paste.ubuntu.com/15198707/16:40
pittixnox: ah, let's call them "cloud images" to avoid confusion16:40
sergiusensbarry, there are many other conflicts that follow the same pattern16:42
pittitseliot: I uploaded systemd to trusty-proposed with all three patches; can you still add an SRU test case to bug 1536438 please?17:01
ubottubug 1536438 in systemd (Ubuntu Trusty) "Need add uaccess tag for /dev/dri/renderD*" [Undecided,In progress] https://launchpad.net/bugs/153643817:01
pittitseliot: I meant, uploaded to the SRU review queue, of course (~ubuntu-sru still needs to review/process)17:02
barrypip 8.0.2-8 should fix those17:03
rbasakdoko: thank you for the libecap fixes.17:05
dokorbasak, I'll forward these once they are visible in the release pocket17:06
rbasakdoko: appreciated17:06
tseliotpitti: sure, I'll do it tomorrow. Thanks17:12
seb128bdmurray, arges, sru_team: is there anything blocking the wily libreoffice update to be accepted? it was supposed to be a 0 day SRU at the beginning but seems it's stucked there forever now17:50
bdmurrayseb128: I don't know but will have a look.18:00
seb128bdmurray, thanks18:04
bdmurrayseb128: it looks like wily had a security update recently :-(18:08
marlincMy GRUB broke since the latest updates, not sure why. Getting 'error: sparse file not allowed' while booting. It then jumps into the UEFI menu18:09
marlincThe only way get it to boot is to press esc so it goes into the actual GRUB screen instead of trying to boot immediately18:09
bdmurrayseb128: also fonts-stix is in universe in wily but was added to main for xenial. would that need to change?18:11
seb128bdmurray, oh, right, going to need to rebase ... or discard at this point, I'm unsure it's still worth it but I'm just wondering for the record what went wrong and why it's ignored by the SRU team since octobre18:11
seb128I guess it would18:11
jdstrandbdmurray: hey-- I wouldn't normally mention this since it has only been a couple of days, but the trusty squashfs-tools sru is important for snappy18:13
jdstrandand seb128 scared me :)18:13
bdmurrayjdstrand: are the two in the queue the same?18:15
* jdstrand looks18:15
jdstrandI uploaded one, then deleted it cause I wanted to tweak the changelog18:16
jdstrandand uploaded another18:16
bdmurrayjdstrand: I still see 2 in the queue18:17
jdstrandbdmurray: ok, somehow the first didn't get deleted.18:17
jdstrandbdmurray: I did just now. if you refresh, you should see only one18:17
bdmurrayjdstrand: okay18:18
gpiccolicyphermox: ping18:28
cyphermoxgpiccoli: hey18:28
gpiccolihello! May I pm you?18:28
nacc_lol, fun to finally figure out that imagemagick in debian/ubuntu backported a fix that was then reverted upstream18:50
nacc_slangasek: --^ that will resolve our php-imagick failures, i think18:50
barrypitti: still around?18:54
nacc_doko: for clearing out the excuses queue, do you want me to subscribe you to the bugs that fix those packages up? or should i just let it go through the normal channels?19:31
dokonacc_, both works19:32
Son_Gokunacc_: pong?19:41
nacc_Son_Goku: hey, two things19:43
nacc_Son_Goku: i pinged yesterday if you could look at those failures on non-x86 archs for php7.0?19:43
nacc_Son_Goku: and also, if you could help provide a twig testcase for php upstream?19:43
Son_Gokunacc_: I don’t have access to any non x86 hw19:43
nacc_Son_Goku: i'm pretty bogged down with just getting packages turned over19:43
nacc_Son_Goku: sure, but can you look at the logs and see if it's something obvious?19:43
Son_Gokuah, sure19:43
Son_GokuI’m unusually bogged down today, though19:44
Son_GokuI’m closing on my house19:44
nacc_Son_Goku: oh congrats -- it's fine, i just needed to delegate some of that, as i want to make more progress on the other packages19:44
Son_Gokuyeah, I’ll take a look at them19:45
nacc_Son_Goku: thanks19:46
nacc_Son_Goku: the non-x86 arch issue may not be a big deal, as it appears to have always failed there20:00
Son_Gokuwell, so it’s a “no change” situation20:00
=== alexisb is now known as alexisb-brb
=== alexisb-brb is now known as alexisb
nacc_doko: ok, subscribed you to the bugs that should unblock all but php-imagick (and php7.0, but not sure if the latter will go away automatically once the others do -- the two failures are "always failed" currently)22:34
carldaniCan anyone in here help me with a Feature Freeze Exception request? I have just created my first one and hope I didn't screw up. Any criticism or RTFM pointers are highly appreciated. https://bugs.launchpad.net/ubuntu/+source/flashrom/+bug/154714423:29
ubottuLaunchpad bug 1547144 in flashrom (Ubuntu) "[FFe] sync flashrom_0.9.9~rc1+r1942-1 from Debian unstable" [Low,New]23:29
tumbleweedcarldani: looks reasonable. A full debdiff is always good to include23:38
sarnoldperhaps a mention of testing of any dependant packages, if any -- if none, a mention of that too23:40
tumbleweedand if it's seeded on any release media23:40
tumbleweedthis has neither, so it's it's a pretty easy FFe candidate23:40
carldanitumbleweed: how do I determine whether a package is on release media?23:43
tumbleweedcarldani: seeded-in-ubuntu (in ubuntu-dev-tools)23:43
carldanioooh nice23:43
tumbleweedand reverse-depends for reverse-depnedencies :)23:43
tumbleweedI'm quite happy to dust off my release-team hat and approve that :)23:45
carldanithank you!23:45
carldanithere's one catch, though23:46
carldaniI'd rather mention it upfront23:46
sarnoldit's not done yet? :)23:46
carldaniflashrom doesn't build on s390, and AFAICS Ubuntu 16.04 will have s39023:46
tumbleweedthat's not a regression, though23:47
tumbleweedif it builds on at least those architectures, you're fine23:47
carldaniWe (flashrom developers) do have S390 support in upstream svn since a few hours, and plan to release 0.9.9 final soon which will have s390 support.23:48
tumbleweedall the more reason to do it23:48
tumbleweedcarldani: oh, if you're looking for things to talk about in FFes. Test coverage is useful, gives us an idea of risk levels23:49
carldaniarm64 and ppc64el (broken in the old 0.9.7+r1852-1.1) are compiling just fine in the package mentioned in the ffe23:50
carldanitumbleweed: thank you! that was quick. wow.23:52
tumbleweedyou happened to find a not-very-active release team member, with spare cycles, staring at IRC :)23:53
stefanctwith a very descriptive nick too ;)23:54
carldanisarnold: ah yes, and flashrom will probably never be finished... people find flash chips in so many weird locations, flashrom even has a driver for reflashing monitor firmware over i2c over vga23:56
sarnoldcarldani: that's simultaneously cool and scary :)23:56
carldanisarnold: indeed.23:57

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