[10:12] <flexiondotorg> How do I go about having an obsolete package removed from the Yakkety archive?
[10:13] <Laney> file a bug and subscribe ~ubuntu-archive
[10:13] <flexiondotorg> Thanks.
[14:13] <attente> bdmurray: hi. looking at the gnome-software error logs, i'm not sure that those errors are regressions. they just seem to be binned separately from https://errors.ubuntu.com/problem/77807d3502a3e74469d5b5dca0a34e9197c647d6
[14:25] <bdmurray> attente: I'm sorry which crash is binned separately from 77807d35...
[14:26] <attente> bdmurray: this one https://errors.ubuntu.com/problem/dc83afe90b31d0984940db9de2ff06b2c6ee8b78
[14:26] <attente> which seems to be the reason why it looks like a new regression with increased rate of occurrence
[14:29] <bdmurray> attente: okay, thanks for digging. I'll take care of it now.
[14:30] <attente> bdmurray: thanks again
[14:31] <bdmurray> attente: what about https://errors.ubuntu.com/problem/111ba23deb7463e9f1203f30099e0c2ca6c2af80?
[14:33] <attente> bdmurray: hadn't seen that one. does look like a regression though
[14:37] <seb128> attente, do you say that from code changes making it likely? or just because it was not reported before?
[14:39] <attente> just because it wasn't reported before
[14:44] <seb128> attente, there is a similar 3.18 report on the redhat bugzilla, I think it's not a regression, just not a common issue
[14:44] <attente> ok, i guess you are right. that upstream bug report doesn't seem to have any resolution
[14:51] <seb128> no, I tried to play with nm status changes during install and co, but can't trigger it
[14:51] <seb128> anyway I don't see any sign of an obvious regressions in those reports
[14:53] <seb128> but e.u.c retracings are unreliables atm so difficult to say, if 2/3 of the weekly view was not missing symbols we would have more datas on what has already been reported
[14:53] <seb128> bdmurray, can you unblock the SRU? we believe there are no reason to block it due to e.u.c reports
[15:01] <bdmurray> seb128: will do
[15:01] <seb128> bdmurray, thanks
[15:01] <seb128> attente, ^
[15:01] <seb128> attente, thanks for following up on the issues btw!
[15:03] <attente> seb128: i was just the messenger here, thanks for finding that upstream report :)
[15:03] <seb128> attente, yw, good team work!
[16:50] <infinity> kirkland: Do you care that your changelog format is ugly (extra newline)?
[16:50] <infinity> kirkland: http://launchpadlibrarian.net/258203000/pollinate_4.15-0ubuntu1_4.15-0ubuntu1.2.diff.gz
[16:50] <infinity> kirkland: Also, never upload to series-updates. :P
[16:51] <xnox> uploads to xenial -> are redirected by launchpad into the right place already.
[16:51] <infinity> I'm well aware.
[16:51] <infinity> uploads to updates are not, however, rewritten.
[16:52] <xnox> infinity, that's not for you =) but kirkland.
[16:52] <infinity> kirkland: But yes, you're living 5 years in the past.  If you always just upload to "$series", LP does the right thing.
[16:58] <infinity> sgclark: Talk to me about kde-l10n-*
[16:58] <infinity> sgclark: In the past, Scott/Riddell did the SRU admin side (I'm happy to take that over), but are you still following whatever previous practise was for building and testing them?
[16:59] <sgclark> infinity: hi, when they were sponsered for me they missed a chunk, which randomly break installs across the world, no pun intended
[16:59] <infinity> sgclark: Sure, I'm not questioning the necessity of the uploads.  We do them for point releases anyway, historically.
[16:59] <sgclark> they were heavily tested, it was the upload to archive at the end that just missed a chunk
[17:00] <infinity> sgclark: More questioning how people plan to test and promote, etc.
[17:01] <sgclark> We have several bugs with willing testers? Sorry I am not sure what the question is
[17:02] <infinity> sgclark: Well, updating *all* the lang stuff tends to imply that either you're only spot-checking one or two, or you have an automated test plan to make sure they don't suck.
[17:02] <infinity> sgclark: I don't know how that was handled before, but scott/riddell did it without me intervening, so I didn't need to know.
[17:03] <sgclark> Yeah and Jonathan took all his knowledge with him. Scott still helps me out when he can (very busy) and yofel has much of the knowledge.
[17:03] <sgclark> yofel uploaded the last languages correctly afaik, he is also very busy
[17:04] <infinity> Indeed, I'm not questioning the uploads, I'm questioning how we get them all tested so they can move from proposed to updates.
[17:05] <sgclark> right. so if I conjure up testers, what do I need to have them do? I do not use language pack to be perfectly honest
[17:07] <infinity> sgclark: I'm not sure manual testing is the right answer, unless you can find 60+ testers who all speak the right languages.
[17:07] <sgclark> I see yoour point
[17:07] <infinity> sgclark: And maybe the answer is "in the past, we never actually tested, but just spot-checked a few languages".
[17:07] <infinity> sgclark: But I'd like to know what Scott was doing in the past, so we can either emulate or improve, but not regress. :P
[17:08] <sgclark> infinity: ok I will ping him and ask.
[17:08] <infinity> Ta.
[19:27] <kirkland> infinity: xnox: :-)  thanks dudes.
[19:28]  * xnox did nothing =)
[19:36] <infinity> Who accepted what-utils?
[19:37] <infinity> kirkland: You didn't address my reject message on that upload (s,ports.ubuntu.com,ports.ubuntu.com/ubuntu-ports,)
[19:38] <kirkland> infinity: hmm
[19:38] <kirkland> infinity: it seems to work okay, without
[19:38] <infinity> kirkland: Both work, technically, but the symlink from ubuntu-ports -> isn't necessary for mirrors, so it has the potential to be wrong.
[19:38] <kirkland> ⟫ how-many-binary -a s390x
[19:38] <kirkland> 50855
[19:38] <kirkland> interesting
[19:38] <infinity> "ubuntu-ports -> ." that is.
[19:38] <kirkland> fixing now.
[19:39] <infinity> (IMO, it should just be /ubuntu/ to be consistent, but yay history)
[19:39] <infinity> Maybe we should fix that some day.
[19:40] <infinity> kirkland: That said, why does it use the archive at all?  That seems amazingly slow.
[19:41] <kirkland> infinity: yes, requires network access
[19:41] <infinity> https://launchpad.net/ubuntu/xenial/s390x/ -> 67302 binary packages
[19:41] <infinity> kirkland: No, I mean, using the archive implies downloading Packages and parsing..
[19:42] <infinity> Not that I've read the source.
[19:42] <kirkland> infinity: download package list, and count
[19:42] <infinity> Yeah, could be a single API call.
[19:43] <kirkland> infinity: hrmm, well...
[19:43] <kirkland> infinity: i'm curious about the discrepancy
[19:44] <kirkland> https://launchpad.net/ubuntu/xenial/s390x/ says 67302
[19:44] <infinity> kirkland: Also, to avoid lpapi clients: wget -O- https://api.launchpad.net/devel/ubuntu/xenial/s390x/package_count 2>/dev/null
[19:44] <infinity> kirkland: The count would be the difference between all binaries in all pockets and whatever you're parsing in your script, I imagine.
[19:44] <kirkland> This page contains the following errors:
[19:44] <kirkland> error on line 1 at column 1: Document is empty
[19:44] <kirkland> Below is a rendering of the page up to the first error.
[19:45] <infinity> kirkland: Yeah, hence wget. ;)
[19:45] <infinity> wget -O- https://api.launchpad.net/devel/ubuntu/xenial/s390x/package_count 2>/dev/null && echo -en "\n"
[19:45] <infinity> 67302
[19:45] <infinity> (base)adconrad@nosferatu:~$
[19:45] <kirkland> yeah
[19:45] <kirkland> so, now, I'd like to see that list of 67K packages
[19:46] <kirkland> ie, how-many-binary --verbose
[19:48] <infinity> for i in main universe restricted multiverse; do
[19:50] <infinity> You're at least missing a "for release in $release{,-updates,-proposed,-backports}; do" after that.
[19:50] <infinity> Which will get your list higher.