| nacc | slangasek: doko: php-rrd failure is an obvious thinko in debian ... bug filed | 00:43 |
|---|---|---|
| nacc | 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) | 00:43 |
| nacc | 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 |
| nacc | but i think most of the php7.0 excuses are now covered | 01:10 |
| === juliank_ is now known as juliank | ||
| cpaelzer | good morning | 06:09 |
| pitti | Good morning | 06:56 |
| dholbach | good morning | 07:51 |
| === davidcalle_afk is now known as davidcalle | ||
| LocutusOfBorg | good morning! | 08:28 |
| pitti | stgraber: oh, looking forward to learn what the replacement of lxc-clone/ephemeral will be :) | 08:34 |
| darkxst | 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:56 |
| dholbach | darkxst, I'm just putting together a rough schedule as a reminder | 08:59 |
| dholbach | if I took into account all local holidays, freeze dates and everything else, it'd take me weeks to put together :-) | 08:59 |
| dholbach | thanks for moving to another day | 08:59 |
| darkxst | dholbach, ha, yeh, didnt think of it like that ;) | 09:00 |
| darkxst | anyway no problem | 09:00 |
| darkxst | its been a bumpy beta1 ;( | 09:00 |
| dholbach | luckily there's still some time to fix bugs | 09:02 |
| darkxst | yes | 09:02 |
| * darkxst waiting on upload to migrate so I can re-spin images and hopefully fix 4 or so bugs | 09:03 | |
| pitti | slangasek, infinity, doko, Laney: please be aware of http://bazaar.launchpad.net/~ubuntu-release/britney/britney2-ubuntu/revision/579 | 09:09 |
| pitti | http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html is updated for that now | 09:09 |
| pitti | slangasek, infinity, doko, Laney: TL/DR: hinted regressions are now shown in yellow as "Ignored failure", so all red "Regressions" are "real" | 09:09 |
| Laney | pitti: nice | 09:09 |
| pitti | makes the output much easier to read, no more searching for the "ignored failure foo" 20 lines below | 09:10 |
| pitti | and makes retry-autopkgtest-regressions more useful | 09:10 |
| pitti | as it won't retry the known-failing ones | 09:10 |
| pitti | and e. g. http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#python-numpy is much easier to read now | 09:14 |
| infinity | pitti: Nice. | 09:29 |
| === vrruiz_ is now known as rvr | ||
| === Chipaca` is now known as Chipaca | ||
| StevenK | /wii pitti | 10:13 |
| StevenK | Ah | 10:13 |
| doko | LocutusOfBorg, ping on llvm3.8 rc3? | 10:16 |
| LocutusOfBorg | ping sylvestre, I never packaged a new upstream release | 10:17 |
| LocutusOfBorg | I already pinged him about llvm-3.7 | 10:17 |
| FourDollars | 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:27 |
| dholbach | FourDollars, sure, adding it to my TODO list :) | 10:28 |
| FourDollars | dholbach: Thx a lot. | 10:28 |
| LocutusOfBorg | 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 |
| LocutusOfBorg | 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 |
| LocutusOfBorg | FourDollars, ^^^ maybe you want to add them to the wiki page | 10:29 |
| LocutusOfBorg | so your sponsor knows what they sponsored to you :) | 10:30 |
| FourDollars | 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:30 |
| FourDollars | LocutusOfBorg: Please also check Ubuntu Sponsorship Miner <- | 10:31 |
| FourDollars | LocutusOfBorg: Maybe I should raise it up. Thx. | 10:31 |
| LocutusOfBorg | oh... I found it | 10:32 |
| LocutusOfBorg | sorry then :) | 10:32 |
| FourDollars | LocutusOfBorg: np. I should put it in the first line so people can easily find it. | 10:33 |
| LocutusOfBorg | I didn't change the link in my MOTU application | 10:34 |
| LocutusOfBorg | https://wiki.ubuntu.com/GianfrancoCostamagna/MOTUApplication | 10:34 |
| LocutusOfBorg | so it was "searchable" with find tool | 10:34 |
| LocutusOfBorg | :) | 10:34 |
| FourDollars | I see. | 10:36 |
| FourDollars | Let me refine my wiki page. | 10:37 |
| jamespage | infinity, changed my mind on using the dpdk binary by default as it also requires hugepages to be configured otherwise it borks | 11:42 |
| jamespage | cpaelzer, hey - are you working on the underlinking issue in dpdk? | 11:48 |
| cpaelzer | jamespage: yes | 11:50 |
| cpaelzer | jamespage: I have this one fixed along with a few others, there are some itches left | 11:51 |
| jamespage | cpaelzer, awesome! I've uploaded ovs with dpdk enabled and requested that ovs-dpdk be removed from the archive | 11:51 |
| cpaelzer | jamespage: if things go well I'll prepare an upload for review today - if not I hope tomorrow | 11:51 |
| cpaelzer | 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 | |
| jamespage | cpaelzer, no problem - thanks for the dpdk work | 11:52 |
| jamespage | cpaelzer, I decided not to enable by default based on cpu features... | 11:52 |
| cpaelzer | 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:52 |
| cpaelzer | jamespage: so is it !default in general (because we are afraid of regressions) or is it "default = sse3 ? openvswitch-dpdk : openvswitch" | 11:53 |
| jamespage | cpaelzer, no - you just install openvswitch-switch and then switch between versions using alternatives | 11:54 |
| jamespage | so no extra package | 11:54 |
| jamespage | cpaelzer, its really ssse3 + hugepages configured correctly | 11:54 |
| jamespage | I guess we could do that but I'd rather make it a little more explicit for now | 11:54 |
| cpaelzer | jamespage: I clearly prefer not being the default as long as it needs to mature so much IMHO | 11:55 |
| jamespage | cpaelzer, agreed | 11:58 |
| jamespage | cpaelzer, https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/openvswitch | 12:01 |
| jamespage | I've updated the Vcs fields in the repo - they will go with the next upload | 12:02 |
| cpaelzer | jamespage: cool, I did the same for DPDK already which will be in the next upload as well (VCS) | 12:04 |
| cpaelzer | 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 |
| jamespage | cpaelzer, I did for xenstore and pcap - but I hit a dl one when backporting atm | 12:05 |
| jamespage | (that's on 14.04 only) | 12:05 |
| cpaelzer | jamespage: ok we can try that with the new version then as soon as I'm done with it | 12:06 |
| jamespage | cpaelzer, ok | 12:06 |
| rbasak | 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:10 |
| rbasak | Also libecap is only used by squid. It's barely a shared library. | 12:11 |
| doko | rbasak, don't do that | 12:11 |
| rbasak | doko: OK, well can you merge libecap then please? | 12:11 |
| doko | rbasak, symbols files are a requirement for MIRs | 12:11 |
| rbasak | 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 |
| doko | rbasak, it belongs to the server team, so it's your task | 12:11 |
| doko | rbasak, why? | 12:12 |
| rbasak | It's only used by squid, so is barely a shared library at all. It might as well be static. | 12:12 |
| rbasak | 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 |
| rbasak | So what's the point? | 12:13 |
| hrw | hello | 12:13 |
| doko | and you mean just because you update squid every two years, it's not necessary? | 12:13 |
| hrw | can someone remove linux-chromebook from archive for me? | 12:13 |
| hrw | I am still listed as maintainer when no one is using this package and I do not even have hardware for it. | 12:14 |
| cjwatson | hrw: Could you file a bug against it with an explanation, and subscribe ubuntu-archive? | 12:14 |
| rbasak | 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 |
| cjwatson | Gives us an audit trail | 12:14 |
| hrw | cjwatson: thanks, will do | 12:14 |
| rbasak | doko: if you disagree, then please explain how the symbols file could be useful in this case. | 12:14 |
| === _salem is now known as salem_ | ||
| cjwatson | apw: ^- do you agree with hrw's request above, since you uploaded it yesterday? | 12:15 |
| doko | 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:15 |
| doko | and I probably didn't forward the patch to debian, because it was outdated | 12:16 |
| doko | debian had the new version for a long time | 12:16 |
| rbasak | 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 |
| apw | 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:16 |
| hrw | cjwatson: https://bugs.launchpad.net/ubuntu/+source/linux-chromebook/+bug/1549782 | 12:17 |
| ubottu | Launchpad bug 1549782 in linux-chromebook (Ubuntu) "Please remove it from archive" [Undecided,New] | 12:17 |
| doko | rbasak, so the savings is just for you, because you don't care to rename the package for these cases? | 12:17 |
| rbasak | doko: as I said, it is only squid that uses it. | 12:17 |
| hrw | apw: as the only maintainer of it I would love to see it gone ;d | 12:17 |
| rbasak | doko: and we don't know what the formal ABI is, anyway. | 12:17 |
| apw | hrw, works for me, it is anchient | 12:17 |
| doko | sorry, I don't get it why we have this discussion. no, you can't know if external software uses it | 12:18 |
| hrw | apw: it was when got added but at that time it was acceptable solution | 12:18 |
| rbasak | Which is fine, but what am I supposed to do when the symbols file flags an ABI difference? | 12:18 |
| rbasak | Everyone else seems to just change the symbols file. | 12:18 |
| rbasak | doko: because you don't care> and you didn't care to send the change to Debian, so what's the difference? | 12:20 |
| rbasak | 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:20 |
| doko | rbasak, you're wrong. I couldn't send anything to debian, because the versions didn't match | 12:21 |
| rbasak | doko: unless you want to take the merge? | 12:21 |
| cjwatson | hrw: subscribe, not assign :) (fixing) | 12:21 |
| hrw | cjwatson: long time since I used launchpad ;D | 12:21 |
| doko | rbasak, that's blackmailing | 12:21 |
| rbasak | doko: 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 |
| rbasak | 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 |
| rbasak | Look at the history of libecap uploads in Ubuntu. | 12:22 |
| rbasak | 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 |
| cjwatson | hrw: done | 12:23 |
| hrw | cjwatson: thanks a lot | 12:24 |
| hrw | apw: thanks for reminding me (by upload) that this package still exists | 12:24 |
| apw | hrw, heh you are very welcome :) | 12:25 |
| pitti | 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 |
| pitti | 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 |
| hrw | bye | 12:29 |
| rbasak | pitti: sure, I understand that. I think I'm saying that "maintaining" a symbols file in an Ubuntu delta is pointless. | 12:29 |
| pitti | if it's just one consumer, then there's little point to even pretend that it woudl be a generally usable library | 12:30 |
| pitti | rbasak: it's not | 12:30 |
| pitti | rbasak: if you build a shared library, you make a commitment and a promise | 12:30 |
| pitti | and if you don't want to keep that, don't build a shared library | 12:30 |
| rbasak | pitti: sure. Sorry, I mean in this specific case, not the general case. | 12:30 |
| rbasak | 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 |
| pitti | rbasak: exactly my point :) | 12:31 |
| rbasak | That's what I'm saying is pointless. Given that we're doing this, why maintain the symbols file at all? | 12:31 |
| rbasak | I'll accept that not shipping a shared library the right answer, but unfortunately we're just downstream of Debian here. | 12:31 |
| pitti | it's not pointless, it's pointing you towards the real error: your library broke ABI | 12:31 |
| pitti | well, then file an RC bug against Debian and let it get auto-removed, or something | 12:32 |
| rbasak | 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 |
| pitti | 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 |
| doko | 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 |
| pitti | but that's what a static library is for then | 12:32 |
| pitti | doko: *nod* | 12:33 |
| rbasak | pitti: incidentally the ABI change was historical and in libecap2. They've had a soname bump now. | 12:33 |
| rbasak | So I can't really file an RC bump now, seeing as they have bumped the soname. | 12:33 |
| rbasak | An RC bug that is. | 12:33 |
| pitti | rbasak: ah, if they did, what's the problem then? | 12:33 |
| pitti | on a soname bump it's totally legitimate to update the symbols files | 12:34 |
| rbasak | pitti: I feel that I'm recreating the symbols file again for no real reason. | 12:34 |
| rbasak | pitti: given the history of symbols files being arbitrarily changed. | 12:34 |
| pitti | well, changing symbols files without soname bump -> don't do that | 12:34 |
| pitti | changign symbosl files with a soname bump -> normal operation | 12:34 |
| rbasak | 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 |
| pitti | well, I disagree | 12:35 |
| rbasak | (like you said, it'a a symptom) | 12:35 |
| rbasak | 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 |
| pitti | 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:35 |
| pitti | and an FTBFS due to symbols mismatch is infinitely better than having to scrape off apport crash reports after the fact | 12:36 |
| doko | rbasak, symbols files are part of the packaging, not about upstream | 12:36 |
| doko | some upstreams have symbol versioning | 12:36 |
| pitti | and if it's FTBFS due to a symbols mismatch, the consequence is *not* to just adjust the symbols file :) | 12:36 |
| doko | introducing tens of diffs dropping php swig support, and discussing a symbols file for 20min ... | 12:37 |
| rbasak | 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:37 |
| doko | rbasak, sure, we should just drop all symbols files for that reason | 12:38 |
| pitti | well, *shrug*, you asked for another opinion, I gave it, not going to repeat it as that would just annoy you more :) | 12:38 |
| rbasak | 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 |
| rbasak | And I'll bring this up again if/when we get an FTBFS similar to the libecap2 ones. | 12:39 |
| pitti | rbasak: just to avoid doubt, that was for a soname bump, right? | 12:39 |
| rbasak | pitti: yes, libecap2->3 | 12:39 |
| pitti | rbasak: and it's totally useful to send that to debian | 12:39 |
| rbasak | doko mentioned that he couldn't before due to some mismatch. How would I check for this? | 12:40 |
| pitti | arch specific symbols files are very rare for C; they are unfortunately the norm for C++, if it uses that | 12:40 |
| pitti | if you send the delta right after mering, that should by definition be current | 12:40 |
| pitti | merging, even | 12:40 |
| doko | rbasak, wrong. I said that we had an older libecap in the archive | 12:40 |
| rbasak | Ah, OK, thanks. | 12:41 |
| rbasak | http://paste.ubuntu.com/15196806/ is what I have right now. | 12:41 |
| pitti | ah, C++ | 12:41 |
| rbasak | I used 1.0.1-2~ since -1 was prior to the gcc 5 transition | 12:41 |
| rbasak | So presumably the symbols were different then. | 12:41 |
| pitti | 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 |
| rbasak | Does that make sense for Debian? Or would that be wrong for them since they published libecap3 before the GCC transition also? | 12:42 |
| pitti | 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 |
| pitti | (they might need to rename it libcap3v5 then if the new g++ changed the ABI) | 12:43 |
| rbasak | OK, thanks. | 12:43 |
| pitti | (syncing that should be a no-op for us mostly, so we can do that if we want) | 12:44 |
| doko | 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 |
| pitti | these can be marked as (optional) then | 12:44 |
| pitti | particularly stuff which is not part of the real ABI, but just leaking from standard libraries | 12:45 |
| pitti | yay C++ | 12:45 |
| doko | rbasak, this might help you, if there are too many architecture differences: http://pkg-kde.alioth.debian.org/symbolfiles.html | 12:45 |
| rbasak | 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 |
| pitti | c++filt is nice indeed, makes these actually readable and less platform specific | 12:46 |
| pitti | :w | 12:47 |
| doko | 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 |
| rbasak | OK, thanks. | 12:48 |
| doko | but the symbolshelper is not aware of the unmangled notation, afaik | 12:49 |
| rbasak | 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 |
| rbasak | Well apparently not, that just FTBFS. | 12:50 |
| doko | sure | 12:54 |
| doko | how does it fail? | 12:54 |
| rbasak | http://paste.ubuntu.com/15196904/ - I assume I'm doing something quite essential wrong. | 12:56 |
| doko | you're using c++ with the mangled names, not the unmangled ones | 12:57 |
| doko | at least for the first symbol | 12:58 |
| rbasak | The symbols file has unmangled names | 13:00 |
| doko | the missing symbol is unmangled | 13:06 |
| doko | I mean, mangled | 13:06 |
| rbasak | Ah | 13:07 |
| rbasak | Yes, that line does exist in my symbols file. Most of the lines are unmangled. | 13:07 |
| rbasak | Some seem to remain mangled. | 13:07 |
| rbasak | http://paste.ubuntu.com/15196979/ | 13:07 |
| rbasak | Line 85 | 13:08 |
| rbasak | That's the only one I see, so perhaps I could just leave that one mangled. | 13:09 |
| Laney | run it through c++filt and put that in its place | 13:09 |
| rbasak | c++filt seems to leave it unchanged | 13:10 |
| * Laney plays the x-files theme | 13:10 | |
| Laney | so it does | 13:10 |
| doko | looks like a bug | 13:10 |
| doko | in the demangler | 13:10 |
| doko | or mangler | 13:11 |
| rbasak | I left that line undemangled, and the build succeeds. | 13:13 |
| rbasak | I guess that's OK to upload then? I'll clean up the merge first. Thank you for your help. | 13:13 |
| doko | sure | 13:14 |
| doko | rbasak, might be https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687 | 13:16 |
| ubottu | gcc.gnu.org bug 69687 in c++ "Buffer Overflow in libiberty" [Normal,Unconfirmed] | 13:16 |
| rbasak | Thanks. I guess it's safe to just work around for now by not demangling that symbol? | 13:20 |
| pitti | 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:24 |
| pitti | 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 |
| pitti | so please use that new syntax from now on | 13:25 |
| rbasak | Looks like i386 and powerpc failed. https://launchpadlibrarian.net/242789112/buildlog_ubuntu-xenial-i386.libecap_1.0.1-3ubuntu1_BUILDING.txt.gz | 13:32 |
| rbasak | Some extra symbols, some missing symbols. | 13:33 |
| rbasak | Should I just mark the missing ones as optional, and forget about the extra ones? | 13:33 |
| rbasak | doko: ^ | 13:34 |
| doko | ahh, 32/64bit differences | 13:44 |
| doko | rbasak, is it intended that you build without optimization? | 13:45 |
| rbasak | doko: I haven't touched Debian's packaging in this area. | 13:46 |
| rbasak | Looks like the packaging just uses trivial CDBS. | 13:47 |
| doko | rbasak, I'll have a look, because it's likely that the symbols will change again with optimization | 13:47 |
| doko | mvo, does snappy build on powerpc? | 14:19 |
| doko | ohh, neither on s390x | 14:20 |
| mvo | doko: its fixed on s390x, I will upload the right today | 14:20 |
| mvo | doko: powerpc is a gccgo issue, I am not sure I can fix that myself | 14:20 |
| pitti | tseliot: hey Alberto, how are you? | 14:39 |
| pitti | tseliot: I have two other tiny bits for udev/trusty -- I suppose you want bug 1536438 SRUed? | 14:40 |
| ubottu | bug 1536438 in systemd (Ubuntu Trusty) "Need add uaccess tag for /dev/dri/renderD*" [Undecided,Triaged] https://launchpad.net/bugs/1536438 | 14:40 |
| pitti | tseliot: would make sense to bundle those three | 14:40 |
| tjaalton | 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 |
| tjaalton | with 3.8 | 14:42 |
| tjaalton | apparently it has issues detecting what kind of avx support it has | 14:43 |
| doko | tjaalton, sorry, no. | 14:44 |
| tjaalton | alright | 14:44 |
| ahasenack | 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 |
| ubottu | Launchpad bug 1549819 in python-apt (Ubuntu) "SIGSEGV when reloading cache after setting architecture" [Undecided,New] | 14:54 |
| ahasenack | or point us at the current maintainer? | 14:54 |
| ahasenack | doko: a landscape-client unit test started core dumping like that in xenial | 14:56 |
| * doko stares at mvo ... | 14:56 | |
| doko | ahasenack, could you check if a python-apt rebuild helps? we recently upgraded apt. juliank might want to comment too | 14:59 |
| doko | hmm,not rebuilt in Debian | 15:00 |
| ahasenack | doko: I'll try that | 15:02 |
| ahasenack | doko: also, do you know where I can find the core dump? | 15:02 |
| ahasenack | ubuntu@landscape-client-xenial:~$ ./foo.py | 15:02 |
| ahasenack | Segmentation fault (core dumped) | 15:02 |
| ahasenack | it's nowhere, not in /var/crash or $PWD | 15:02 |
| ahasenack | ulimit -c says unlimited | 15:02 |
| mvo | ahasenack: what doko said, a rebuild would be nice first, if that does not help I can have a look later | 15:03 |
| ahasenack | installing build deps... | 15:04 |
| mterry | 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:04 |
| mvo | mterry: uh, could you please comment in the bug so that I can sort it out? | 15:05 |
| tjaalton | doko: it's a mesa bug after all, was fine with 11.1 but 11.2rc breaks | 15:06 |
| ahasenack | mvo: it still core dumps after I rebuild and reinstall python-apt | 15:10 |
| ahasenack | mvo: it's inside a xenial lxd, if that matters | 15:10 |
| juliank | There's a bug somewhere in APT's cache generation | 15:11 |
| mvo | ahasenack: interessing, I get http://paste.ubuntu.com/15197818/ when I run your script | 15:11 |
| mvo | juliank: can you redproduce the segfault? | 15:11 |
| ahasenack | mvo: on a real xenial host, or vm? | 15:11 |
| mvo | ahasenack: real systemm | 15:12 |
| mvo | system | 15:12 |
| juliank | 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 |
| ahasenack | juliank: I can't find the core dump file | 15:12 |
| juliank | We probably missed a stringview that needs to be moved when the cache is moved | 15:12 |
| ahasenack | ulimit -c is unlimited, nothing in /var/crash or $PWD | 15:12 |
| juliank | Any service for core dumps installed? For example, I use systemd-coredump which stores them into /var/lib/systemd/coredump | 15:13 |
| juliank | there can be other handlers | 15:13 |
| ahasenack | let me check | 15:13 |
| ahasenack | that directory is empty here | 15:14 |
| ahasenack | I can remove apport | 15:14 |
| juliank | You could also run it in gdb if you have the debugging symbols available. | 15:14 |
| ahasenack | it's a python script | 15:15 |
| juliank | and how is that problematic? | 15:15 |
| ahasenack | still no core dump even with apport removed | 15:15 |
| juliank | Anyway, apt-cache gencaches should crash as well if you pass it a config file with -c that contains APT::Architecture ""; | 15:16 |
| juliank | For mvo, it works correctly. | 15:17 |
| juliank | FTR, this is likely http://bugs.debian.org/812251 | 15:18 |
| ubottu | Debian bug 812251 in apt "apt: suddenly segfaults after "apt update"" [Important,Fixed] | 15:18 |
| juliank | Try this reproducer: http://paste.ubuntu.com/15197886/ | 15:19 |
| juliank | Of course, setting Architecture to an empty string won't work, but it should at least build a cache | 15:19 |
| ahasenack | juliank: that crashed here | 15:20 |
| juliank | Great | 15:20 |
| ahasenack | juliank: I'm trying to find all the dbg packages I need | 15:20 |
| juliank | Only interested in libapt-pkg5.0 ddeb | 15:21 |
| ahasenack | the bt isn't that great yet | 15:21 |
| ahasenack | http://pastebin.ubuntu.com/15197906/ | 15:21 |
| juliank | 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:22 |
| juliank | But that seems like a bad place to crash in | 15:24 |
| tseliot | pitti: hi. Yes, I'd like that SRU. Where do I find the other changes? | 15:24 |
| ahasenack | juliank: ok, now I have something more | 15:25 |
| juliank | Do bt full | 15:25 |
| pitti | tseliot: it's bug 1473800 and bug 1535255 | 15:25 |
| ubottu | bug 1473800 in systemd (Ubuntu Trusty) "restarting logind during systemd update causes screen to lock" [Undecided,Triaged] https://launchpad.net/bugs/1473800 | 15:25 |
| ubottu | 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 |
| pitti | tseliot: but if you want I can upload the SRU for all three, your's is quite simple too | 15:25 |
| ahasenack | juliank: http://pastebin.ubuntu.com/15197953/ still a few "optimized out" bits | 15:26 |
| tseliot | pitti: yes, please | 15:26 |
| pitti | tseliot: ack, will do | 15:26 |
| tseliot | pitti: thanks | 15:26 |
| stgraber | pitti: lxc-copy | 15:28 |
| pitti | stgraber: ah, thanks; I didn't see an announcement yet on the homepage | 15:28 |
| juliank | ahasenack: I see. But it just crashes because you specified an invalid empty architecture there, AFAICT. | 15:28 |
| ahasenack | well, yes | 15:29 |
| juliank | But that's not really problematic. | 15:29 |
| pitti | 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 |
| juliank | Who specifies "" as an architecture in real life? | 15:29 |
| juliank | You told APT that your system has no architectures. | 15:29 |
| stgraber | 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 |
| ahasenack | juliank: it's something that < xenial was ok with we had it as a unit test, and it started failing | 15:30 |
| stgraber | pitti: we'll likely get rid of them immediately after y opens though | 15:30 |
| juliank | ahasenack: This has to fail. But it should not crash | 15:30 |
| pitti | stgraber: thanks for the heads-up | 15:30 |
| ahasenack | right | 15:30 |
| juliank | It also does not fail on multi-arch systems | 15:31 |
| ahasenack | juliank: it seems to crash only on a container, though | 15:32 |
| juliank | because they'll have the secondary architectures set from APT::Architectures | 15:32 |
| ahasenack | juliank: that tells me something else is going on | 15:32 |
| juliank | Read what I wrote | 15:32 |
| ahasenack | irc lag, I'm sure you are used to it | 15:32 |
| mterry | bdmurray, can you add ~snappy-dev to your package-subscribers list? | 15:33 |
| juliank | ahasenack: Should be fixed in a few mins | 15:34 |
| juliank | Writing a test case now | 15:41 |
| ahasenack | juliank: thx a lot | 15:42 |
| ahasenack | I attached your reproducer and the bt full to the bug | 15:42 |
| bdmurray | mterry: yep | 15:46 |
| seb128 | 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 |
| mterry | cheers | 15:47 |
| juliank | ahasenack: Fixed in https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=9de2fd4 | 15:48 |
| juliank | There will be a 1.2.4 release shortly | 15:49 |
| ahasenack | juliank: \o/ | 15:49 |
| ahasenack | thx a lot | 15:49 |
| davmor2 | seb128: nice, thanks | 15:50 |
| seb128 | davmor2, yw | 15:50 |
| juliank | 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 |
| juliank | Well, (2) might be fixed these days | 15:54 |
| juliank | (1) will be easy once there's a backtrace | 15:55 |
| cyphermox | seb128: ack | 16:00 |
| pitti | xnox: the cloud images are achingly fat, so it's quite a bit of a purge fest to minimize them | 16:13 |
| pitti | xnox: the images.linuxcontainers.org are much nicer, only 1/8th the size, faster, and minimal | 16:13 |
| pitti | xnox: right now I'm using the lxc "ubuntu" template which is similarly small | 16:13 |
| pitti | xnox: but anyway, I do have the purge list, I mostly just didn't get around to setting this up with lxd yet | 16:13 |
| xnox | pitti, horum. if they are "fat" we can trim them. I understood they have cloud-init + nested lxd, and that's it. | 16:15 |
| pitti | xnox: 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 at | 16:16 |
| pitti | 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:17 |
| nacc_ | Pharaoh_Atem: ping | 16:20 |
| rbasak | smoser: ^ | 16:21 |
| rbasak | Also kirkland ^ | 16:21 |
| rbasak | About "fat" cloud images. | 16:21 |
| rbasak | 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 |
| Odd_Bloke | Doesn't belong in a container, but does belong in an Ubuntu-server-that-works-on-a-cloud image. | 16:21 |
| Odd_Bloke | Well, not all of those things, perhaps. | 16:22 |
| rbasak | 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 |
| Odd_Bloke | (Looking at you, ppp) | 16:22 |
| rbasak | 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:22 |
| smoser | Odd_Bloke, ppp is gone i think | 16:23 |
| Odd_Bloke | Oh, cool. | 16:23 |
| smoser | yeah, i dropped hat a while ago. | 16:23 |
| smoser | cloud-image and server are now basically the same. | 16:25 |
| smoser | http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.xenial/revision/2413 | 16:25 |
| smoser | we also dropped wireless-tools wpasupplicant and memtest86+. | 16:25 |
| smoser | xenial cloud imags smaller than wily | 16:25 |
| smoser | thats the first reduction in quite some time. | 16:26 |
| pitti | rbasak: well, most container workloads shouldn't/don't have a "human experience" | 16:26 |
| smoser | 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 |
| pitti | they should be managed completely automatically, and be as dense/efficient as possible | 16:26 |
| pitti | indeed, the x86 ones got trimmed recently, thanks for that; some 380 MB to 290 MB | 16:27 |
| pitti | but, container images are 65 MB | 16:27 |
| rbasak | 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 |
| Odd_Bloke | pitti: Definitely; but that isn't what the cloud images are designed to be. :) | 16:27 |
| pitti | rbasak: sure, hence the need to have either two images, or a simple way to install the "comfy" bits | 16:27 |
| rbasak | pitti: ultimately kirkland has to balance whose things. | 16:27 |
| pitti | with a cloud-init option, or "apt-get install ubuntu-server-standard" or so | 16:28 |
| rbasak | those things | 16:28 |
| rbasak | 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 |
| pitti | 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:28 |
| pitti | rbasak: actually we do, I'm quite happy with teh images.linuxcontainers.org images | 16:29 |
| rbasak | Is it really a "penalize" though? | 16:29 |
| pitti | sure | 16:29 |
| Odd_Bloke | The argument for favouring the "comfy" use case is probably that anyone doing serious container stuff will be customising the images anyway. | 16:29 |
| pitti | it's 5x the download, HD size, unpack, upgrade size, plus the longer boot time etc. | 16:29 |
| rbasak | How expensive is it really? | 16:29 |
| rbasak | Right, but how expensive is _that_ really? :) | 16:30 |
| pitti | well, how expensive is "5x expensive" -- I'd say "5 times"? :-) | 16:30 |
| Odd_Bloke | rbasak: 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 |
| pitti | it's less well defined for dist-upgrade and boot time of course | 16:30 |
| smoser | wasted 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 |
| rbasak | It's mostly disk space. That isn't the bottleneck for container density, AIUI. | 16:30 |
| pitti | but 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 |
| pitti | than maintaining an ever-growing list of packages to purge, as that's really error prone | 16:31 |
| pitti | well, 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 |
| pitti | if 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 it | 16:32 |
| pitti | as that'll download the same things, but much less often | 16:32 |
| rbasak | The time is a penalty when doing interactive work. | 16:32 |
| rbasak | It doesn't matter so much for non-interactive work. | 16:32 |
| rbasak | Developer time is what is most expensive. | 16:32 |
| pitti | well, as I said, I'm quite happy with the images.linuxcontainers.org images | 16:33 |
| pitti | rbasak: developer time> exactly | 16:33 |
| pitti | cf. "maintaining an ever-growing purge list" | 16:33 |
| pitti | I know how brittle and maintenance-intense it is because I'm doing it | 16:34 |
| pitti | I 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 images | 16:34 |
| pitti | anyway, this just started out as an explanation to xnox why I prefer the lxc images | 16:35 |
| * hallyn points rbasak to the cost of bandwidth over satelite :) | 16:35 | |
| pitti | no doubt the classic "ubuntu server" experience shouldl have vim and stuff installed, as these are more geared towards humans | 16:35 |
| Odd_Bloke | hallyn: Ah, yes, the classic cloud use case. ;) | 16:35 |
| pitti | but "noninteractive container/VM" and "interactive server" are quite different use cases, and unifying them will always make people unhappy | 16:36 |
| Odd_Bloke | I guess it does potentially go through literal clouds... | 16:36 |
| hallyn | Odd_Bloke: i rest my case | 16:36 |
| rbasak | hallyn: if you're using satellite, you are presumably already caching the images. The one-off hit is still presumably insignificant. | 16:36 |
| rbasak | Anyway, I defer to kirkland. I understand there are use cases where "comfortable" is a pain. | 16:37 |
| rbasak | pitti: I don't think we're unifying them. We're just not doing the slim one right now. | 16:37 |
| pitti | the one package which is the most contentious one is probably cloud-init | 16:37 |
| xnox | Odd_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 |
| xnox | imho there is room for more minimalistic lxd image. | 16:38 |
| hallyn | rbasak: i think the cost is wroth it, i just object to your over-trivialization of the cost :) | 16:38 |
| pitti | xnox: lxd images are fairly minimal, mostly debootstrap really | 16:39 |
| xnox | pitti, when i say lxd images -> i mean the lxd image we publish at cloud-images.ubuntu.com. not the stgraber image =) | 16:39 |
| sergiusens | barry, hey, is a fix for this coming soon http://paste.ubuntu.com/15198707/ | 16:40 |
| pitti | xnox: ah, let's call them "cloud images" to avoid confusion | 16:40 |
| xnox | ack. | 16:41 |
| sergiusens | barry, there are many other conflicts that follow the same pattern | 16:42 |
| pitti | tseliot: I uploaded systemd to trusty-proposed with all three patches; can you still add an SRU test case to bug 1536438 please? | 17:01 |
| ubottu | bug 1536438 in systemd (Ubuntu Trusty) "Need add uaccess tag for /dev/dri/renderD*" [Undecided,In progress] https://launchpad.net/bugs/1536438 | 17:01 |
| pitti | tseliot: I meant, uploaded to the SRU review queue, of course (~ubuntu-sru still needs to review/process) | 17:02 |
| barry | pip 8.0.2-8 should fix those | 17:03 |
| rbasak | doko: thank you for the libecap fixes. | 17:05 |
| doko | rbasak, I'll forward these once they are visible in the release pocket | 17:06 |
| rbasak | doko: appreciated | 17:06 |
| tseliot | pitti: sure, I'll do it tomorrow. Thanks | 17:12 |
| seb128 | bdmurray, 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 now | 17:50 |
| bdmurray | seb128: I don't know but will have a look. | 18:00 |
| seb128 | bdmurray, thanks | 18:04 |
| bdmurray | seb128: it looks like wily had a security update recently :-( | 18:08 |
| marlinc | My GRUB broke since the latest updates, not sure why. Getting 'error: sparse file not allowed' while booting. It then jumps into the UEFI menu | 18:09 |
| marlinc | The only way get it to boot is to press esc so it goes into the actual GRUB screen instead of trying to boot immediately | 18:09 |
| bdmurray | seb128: also fonts-stix is in universe in wily but was added to main for xenial. would that need to change? | 18:11 |
| seb128 | bdmurray, 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 octobre | 18:11 |
| seb128 | I guess it would | 18:11 |
| jdstrand | bdmurray: 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 snappy | 18:13 |
| jdstrand | and seb128 scared me :) | 18:13 |
| bdmurray | jdstrand: are the two in the queue the same? | 18:15 |
| * jdstrand looks | 18:15 | |
| jdstrand | I uploaded one, then deleted it cause I wanted to tweak the changelog | 18:16 |
| jdstrand | and uploaded another | 18:16 |
| bdmurray | jdstrand: I still see 2 in the queue | 18:17 |
| jdstrand | bdmurray: ok, somehow the first didn't get deleted. | 18:17 |
| jdstrand | bdmurray: I did just now. if you refresh, you should see only one | 18:17 |
| bdmurray | jdstrand: okay | 18:18 |
| gpiccoli | cyphermox: ping | 18:28 |
| cyphermox | gpiccoli: hey | 18:28 |
| gpiccoli | hello! May I pm you? | 18:28 |
| cyphermox | sure | 18:28 |
| gpiccoli | thanks! | 18:29 |
| nacc_ | lol, fun to finally figure out that imagemagick in debian/ubuntu backported a fix that was then reverted upstream | 18:50 |
| nacc_ | slangasek: --^ that will resolve our php-imagick failures, i think | 18:50 |
| barry | pitti: 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 |
| doko | nacc_, both works | 19:32 |
| Son_Goku | nacc_: pong? | 19:41 |
| nacc_ | Son_Goku: hey, two things | 19:43 |
| Son_Goku | yes? | 19: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_Goku | nacc_: I don’t have access to any non x86 hw | 19:43 |
| nacc_ | Son_Goku: i'm pretty bogged down with just getting packages turned over | 19:43 |
| nacc_ | Son_Goku: sure, but can you look at the logs and see if it's something obvious? | 19:43 |
| Son_Goku | ah, sure | 19:43 |
| nacc_ | thanks | 19:43 |
| Son_Goku | I’m unusually bogged down today, though | 19:44 |
| Son_Goku | I’m closing on my house | 19: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 packages | 19:44 |
| Son_Goku | yeah, I’ll take a look at them | 19:45 |
| nacc_ | Son_Goku: thanks | 19:46 |
| nacc_ | Son_Goku: the non-x86 arch issue may not be a big deal, as it appears to have always failed there | 20:00 |
| Son_Goku | ah | 20:00 |
| Son_Goku | well, so it’s a “no change” situation | 20: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 |
| carldani | Can 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/1547144 | 23:29 |
| ubottu | Launchpad bug 1547144 in flashrom (Ubuntu) "[FFe] sync flashrom_0.9.9~rc1+r1942-1 from Debian unstable" [Low,New] | 23:29 |
| tumbleweed | carldani: looks reasonable. A full debdiff is always good to include | 23:38 |
| sarnold | perhaps a mention of testing of any dependant packages, if any -- if none, a mention of that too | 23:40 |
| tumbleweed | and if it's seeded on any release media | 23:40 |
| tumbleweed | this has neither, so it's it's a pretty easy FFe candidate | 23:40 |
| carldani | tumbleweed: how do I determine whether a package is on release media? | 23:43 |
| tumbleweed | carldani: seeded-in-ubuntu (in ubuntu-dev-tools) | 23:43 |
| carldani | oooh nice | 23:43 |
| tumbleweed | and reverse-depends for reverse-depnedencies :) | 23:43 |
| tumbleweed | I'm quite happy to dust off my release-team hat and approve that :) | 23:45 |
| carldani | thank you! | 23:45 |
| carldani | there's one catch, though | 23:46 |
| carldani | I'd rather mention it upfront | 23:46 |
| sarnold | it's not done yet? :) | 23:46 |
| carldani | flashrom doesn't build on s390, and AFAICS Ubuntu 16.04 will have s390 | 23:46 |
| tumbleweed | that's not a regression, though | 23:47 |
| tumbleweed | https://launchpad.net/ubuntu/+source/flashrom/0.9.7+r1852-1.1 | 23:47 |
| tumbleweed | if it builds on at least those architectures, you're fine | 23:47 |
| carldani | We (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 |
| tumbleweed | all the more reason to do it | 23:48 |
| tumbleweed | carldani: oh, if you're looking for things to talk about in FFes. Test coverage is useful, gives us an idea of risk levels | 23:49 |
| carldani | arm64 and ppc64el (broken in the old 0.9.7+r1852-1.1) are compiling just fine in the package mentioned in the ffe | 23:50 |
| carldani | tumbleweed: thank you! that was quick. wow. | 23:52 |
| tumbleweed | you happened to find a not-very-active release team member, with spare cycles, staring at IRC :) | 23:53 |
| stefanct | with a very descriptive nick too ;) | 23:54 |
| carldani | sarnold: 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 vga | 23:56 |
| sarnold | carldani: that's simultaneously cool and scary :) | 23:56 |
| carldani | sarnold: indeed. | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!