[03:23] <austin987> hi there, I'm the upstream for winetricks, and I've noticed that Ubuntu's version is ridiculously out of date. I keep getting bugs filed by Ubuntu users that think they have the latest, while ubuntu is shipping a 2 year old version. The maintainer (Scott Ritchie) is no longer active, so the package and its bugs is getting no attention. I'd like to know what sort of bug I should file to request that the package be marked
[03:23] <austin987> abandoned / needs new maintainer
[03:23] <austin987> I'm concerned that if I file one against winetricks in LP that it too will be ignored...
[03:23] <austin987> example issue: https://bugs.winehq.org/show_bug.cgi?id=40514#c8
[05:14] <cpaelzer> good morning
[06:23] <dholbach> @pilot in
[06:36] <pitti> Good morning
[06:38] <pitti> mapreri: ah, well spotted (this is a fairly new icon from last week's debci merge); will fix
[06:40] <austin987> hi there, I'm the upstream for winetricks, and I've noticed that Ubuntu's version is ridiculously out of date. I keep getting bugs filed by Ubuntu users that think they have the latest, while ubuntu is shipping a 2 year old version. The maintainer (Scott Ritchie) is no longer active, so the package and its bugs is getting no attention. I'd like to know what sort of bug I should file to request that the package be marked
[06:40] <austin987> abandoned / needs new maintainer. I'm concerned that if I file one against winetricks in LP that it too will be ignored...
[06:42] <dholbach> you could bring it up on the ubuntu-devel-discuss@lists.u.c mailing list
[06:52] <austin987> dholbach, okay. Is a subscription required?
[06:53] <dholbach> austin987, if it ends up in the moderation queue, somebody will let it through
[06:53] <austin987> dholbach, cool, thanks
[06:54] <dholbach> anytime
[07:12] <austin987> sent
[07:24] <sam_yan> can not connect to X server:0  Is there someone who knows the reason?
[07:26] <mgedmin> W: Can't drop privileges for downloading as file '/var/lib/update-notifier/package-data-downloads/partial/adobe-flashplugin_20160407.1.orig.tar.gz'
[07:26] <mgedmin> couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
[07:30] <mgedmin> ah, https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/1570141
[07:31] <ice9> I want to submit bug but I'm not sure from which package is the cause, can someone help?
[07:51] <seb128> hey there
[07:52] <seb128> bug #1574285 ... is anybody in foundation wanting to SRU that fix to xenial? seems to create upgrade issues
[07:52] <seb128> infinity, pitti, ^?
[08:01] <pitti> seb128: http://anonscm.debian.org/cgit/dpkg/dpkg.git/diff/?id=ca5c108 looks easy enough, yes; do we have some way to reproduce it, for testing?
[08:01] <seb128> pitti, I'm unsure, Bjoern flagged it as an issue, but I think he picked up from the reports
[08:04] <seb128> pitti, asked on desktop (unsure why he's not on -devel)
[09:05] <Mirv> pitti: is s390x stuck? http://autopkgtest.ubuntu.com/running.shtml just things in queue, nothing running
[09:06] <pitti> Mirv: yes, they segfault ATM, this is high on my list
[09:06] <pitti> Mirv: I disabled s390x for ubuntu testing for now
[09:06] <pitti> xnox: and aupkg01 is AWOL again, if you could reboot/prod it please?
[09:06] <Mirv> pitti: ok thanks for confirming
[09:07] <pitti> xnox: no idea why this suddenly starts acting up like that :/
[09:13] <Mirv> Saviq: ^ you'll be interested in that since silo 19 is not in QA queue because of that
[09:18] <Saviq> Mirv, ack, thanks
[09:34] <xnox> pitti, some test must be killing it. We have posix something killing zvm hosts
[09:34] <xnox> pitti, any idea from logs what was the last thing started on it to run tests?
[09:34] <pitti> xnox: I can tell you when I can get back to the machine
[09:35] <pitti> xnox: I guess I should enable persistent journal on these things, but rsyslog ought to have it too
[09:36] <xnox> it detected cpu task stalls
[09:36] <xnox> with kthreads starved for ever
[09:36]  * xnox is killing it
[09:37] <pitti> xnox: curious, I notice them on arm64 scalingstack instances (bug 1531768), but I never saw them on s390x (until it started hanging last week)
[09:37] <pitti> they ran for months without that, so maybe some change in the xenial kernel or a new test indeed
[09:38] <pitti> but then, .13 took over all the work and it didn't crash so far
[09:38] <pitti> anyway, right now they just segfault right away, so this needs to be investigated first
[09:38] <xnox> pitti, i think it should be booted now.
[09:39] <xnox> but i don't see login prompt
[09:39] <pitti> ssh still hangs
[09:39]  * xnox ponders if it kexeced
[09:40] <xnox> pitti, try again?
[09:40] <pitti> xnox: thanks
[09:42] <pitti> xnox: fun, and .12 does not segfault
[09:43] <pitti> so I now have an unstable one which works and a stable one which always fails, great :)
[09:43] <pitti> and both are up to date xenial
[09:43] <xnox> enable logging, such that we catch the trigger =/
[09:44] <xnox> or do you want me to script reboot every 6h? =)
[09:44] <pitti> Apr 23 01:10:52 aupkg01 kernel: [41802.586805] Unable to handle kernel pointer dereference in virtual kernel address space
[09:44] <pitti> Apr 23 01:10:52 aupkg01 kernel: [41802.586809] failing address: 0404c00180000000 TEID: 0404c00180000803
[09:44] <pitti> Apr 23 01:10:52 aupkg01 kernel: [41802.586811] Fault in home space mode while using kernel ASCE.
[09:44] <pitti> and from then on there's more kernel spew
[09:44] <pitti> xnox: I do have logs
[09:45] <pitti> before that it did a dozen DCHP requests on lxcbr0
[09:45] <pitti> xnox: and I can reconstruct the list of running tests from syslog
[09:46]  * pitti saves syslog
[09:47] <pitti> xnox: actually, these "Unable to handle kernel pointer dereference" already started on Apr 22, one day before it finally hung
[09:48] <pitti> xnox: aupkg02 has them too
[10:06] <seb128> is launchpad timeouting for others as well?
[10:06] <seb128> when trying to edit bugs
[10:25] <dholbach> @pilot out
[10:26] <LocutusOfBorg> dholbach, I replied to LP: #535686 thanks
[10:26] <LocutusOfBorg> LP: #1535686
[10:31] <FredTheNoob> Good Morning, I'd installed Ubuntu on my USB Flash Drive, it was because my hard drive is dead... I'm wondering if there some way to move that usb OS to my new hd?
[10:31] <cpaelzer> I hae a packet that now gets an example in a /etc/defaults/... file that will depend on a certain version of another packet. Other than for that example the two packets work fine without the version restriction. I wonder if I should add a version specific info in the Depends on debian/control.
[10:31] <cpaelzer> The debian policy was not specific enough about that - so it would be great if anybody would have an advice.
[10:32] <cpaelzer> I could - as an alternative - put that version dependency in a comment along the example it that would be more appropriate
[10:33] <cjwatson> (The English word is "package", not "packet".)  Is the addition of the versioned dependency likely to be inconvenient for anyone?
[10:33] <cjwatson> Policy doesn't talk about this because it's a situation-dependent judgement call.
[10:34] <cpaelzer> cjwatson: I don't think that it is very inconvenient, I can't think of a reason to really pin it
[10:34] <cjwatson> And doesn't have to be prescribed for interoperability.
[10:34] <cjwatson> I would add the versioned dependency if it seems unlikely to be a bother to anyone, and otherwise document it somewhere.
[10:34] <cpaelzer> cjwatson: thanks - that it comes down to a "situation-dependent judgement call" is all I needed - I can discuss witrh the package owner then
[10:35] <cpaelzer> yeah, adding the dependency in my initial suggestion is the way I'll go
[10:35] <cpaelzer> cjwatson: thanks
[10:35] <cjwatson> np
[10:35] <cpaelzer> and sorry for the packet/package
[10:41] <cjwatson> cpaelzer: It's a common false friend for German speakers, I think possibly some other languages too ...
[10:41] <maswan> swedish has the same
[11:17] <pitti> doko: is http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gcc-6 the default compiler in yakkety already? the linux regression is not a build but a runtime test regression
[11:17] <pitti> apw: ^ timed out in a test, is that known?
[11:17] <pitti> doko: if gcc-5 is still the default, then i'm happy to let gcc-6 in; if gcc-6 is already the default, then this might be a mis-build of the kernel?
[11:19] <doko> pitti, gcc-5 stays the default til around June/July
[11:19] <aniruddhab> Hello, when I run sudo apt-get install crossbuild-essential-armhf
[11:19] <pitti> doko: ack, ignoring that linux failure then, thanks
[11:19] <aniruddhab> It replaces my libc6-dev with libc6-dev:armhf
[11:19] <aniruddhab> Is there a way to keep both?
[11:42] <doko> sil2100, could you forward https://launchpad.net/ubuntu/+source/dee/1.2.7+15.04.20150304-0ubuntu3 ?
[12:17] <doko> Mirv, any progress with https://launchpad.net/ubuntu/+source/qtbase-opensource-src/5.5.1+dfsg-16ubuntu8 ?
[12:18] <Odd_Bloke> I have a changelog line that fixes multiple bugs; does it matter how I format it?  "blah blah (LP: #123, LP: #456)" or "blah blah (LP: #123) (LP: #456)" or ...?
[12:19] <rbasak> Odd_Bloke: I@
[12:20] <rbasak> Odd_Bloke: I'm not sure, but you can verify the result by examining the changes file that building a source package generates.
[12:20] <Odd_Bloke> rbasak: Aha, thanks!
[12:22] <cjwatson> Odd_Bloke: As well as what rbasak said, the regex is in /usr/share/perl5/Dpkg/Vendor/Ubuntu.pm:find_launchpad_closes
[12:24] <doko> jamespage, https://launchpad.net/ubuntu/+source/ceph/10.1.2-0ubuntu2
[12:27] <Mirv> doko: no time yet to look at it.
[12:27] <Mirv> that rebuild should be useful to see if any of the four failing tests were flaky or consistent
[12:30] <apw> pitti, not know no
[12:31] <apw> pitti, that doesn't reboot onto the built kernel, right?  so it can't be a gcc related issue
[12:31] <apw> (onto the one gcc-6 built)
[12:32] <pitti> apw: it isn't even built with gcc-6, the default is still gcc-5
[12:32] <pitti> apw: gcc-6 triggering linux is more like an accident
[12:32] <apw> ahh point
[12:32] <apw> pitti, so whatever it is it shouldn't block gcc-6
[12:33] <pitti> apw: right, I already unblocked it, but that linux regression won't just go away I figure
[12:36] <apw> pitti, so the x86s are both an RTC issue we've been seeing intermittantly
[12:59] <underyx> I tried to upgrade my SO's machine yesterday with `do-release-upgrade -d` from 14.04 to 16.04 and it failed horribly because udev's dpkg configure step said 'input group already exists and is not a system group' and just gave up after that
[13:00] <underyx> setting the input group's ID to <1000 and then dpkg reconfing everything fixed the issue
[13:01] <underyx> just thought I'd give you a heads up that this can break an upgrade, I use mac/windows myself and have no idea how bug reporting in the ubuntu world works but hopefully someone can take it from here
[13:14] <dobey> underyx: just run "ubuntu-bug udev" on the ubuntu computer, and it will basically walk you through reporting a bug against that package; but since you had an input group > 1000, it sounds like probably it was manually added/changed somehow; maybe the postinst should handle that by forcing it back to the right gid though
[13:15] <underyx> dobey: that solution is what I was kinda going to suggest
[13:16] <underyx> she's no power user and I'm sure she didn't manually tinker with the gid
[13:16] <underyx> so if it was changed, it must have been changed by some fairly popular package
[13:17] <juliank> pitti: You're funny. You merged the pre-depends commit for apt into xenial, and I precisely hold out doing a new APT bug fix release because I did not want to endanger xenial with that commit (but wanted the others :/)
[13:20] <juliank> I think we do a 1.2.11 bug fix release now and could then SRU this in a week or so?
[13:27] <doko> ginggs, https://launchpad.net/ubuntu/+source/yade/1.20.0-8ubuntu1 not really fixing the ftbfs ;)
[13:37] <pitti> juliank: well, given how much this breaks upgrades, we don't have much choice :) we even fast-tracked this into trusty and wily, but still get dozens of new dupes
[13:39] <juliank> pitti: I just released 1.2.11, we should sync that tomorrow, and then check if it's SRU-able
[13:39] <pitti> juliank: cool, thanks
[13:40] <juliank> pitti: This fixes issues with zero size files and "E: Unpatched file  doesn't exist (anymore)!" during update runs
[13:46] <ginggs> doko: hey! sorry, that really fixes the glibc issue, but now there's a new boost issue
[14:10] <doko> Mirv, failed again
[14:15] <sil2100> doko: sure
[15:09] <barnes> anyone going to rebuild the nagios-nrpe packages to enable setting dont_blame_nrpe=1 in nrpe.conf
[15:09] <barnes> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756479
[15:09] <barnes> https://bugs.launchpad.net/ubuntu/+source/nagios-nrpe/+bug/1555258
[15:10] <barnes> i assume that this is going to be a problem for some of those who are going to upgrade to 16.04
[15:29] <infinity> seb128: By "SRU to xenial", did you mean "SRU to trusty"?
[15:31] <seb128> infinity, both is useful I guess?
[15:31] <infinity> seb128: Or just trusty.
[15:31] <infinity> seb128: Because it was fixed in utopic.
[15:31] <seb128> oh ok
[15:31] <seb128> better then!
[15:36] <infinity> A bit shocked that we get that far before having upgraded dpkg too. :/
[15:37] <infinity> I wonder if u-r-u can be mangled to force dpkg to upgrade early.
[15:59] <cyphermox> infinity: I think we already have some stuff to tweak the order of upgrades a bit
[16:01] <cyphermox> despite the name, I think that's what the PostUpgrade{Install, etc.} option does :)
[16:01] <infinity> I wouldn't think so.
[16:02] <infinity> Oh, maybe.
[16:02] <infinity> Should be PostUpdate
[16:03] <infinity> I feel like dpkg and apt should almost always be in that list.
[16:04] <cyphermox> don't they already have logic to put themselves first when you run dist-upgrade?
[16:05] <infinity> They do, but this is python-apt, which is special.
[16:05] <cyphermox> ahh
[16:05] <infinity> And never quite the same as apt itself.
[16:05] <cyphermox> yeah
[16:05] <infinity> Irritatingly.
[16:06] <cyphermox> well, it's worth testing just putting them in the list and rolling a hacked up u-r-u in a PPA or something
[16:10] <infinity> cyphermox: Actually, apt too will probably perturb the upgrade order a bit too much, but just dpkg should be fine.
[16:11] <infinity> cyphermox: That said, uru also forces a dist-upgrade to latest trusty before upgrading, right?  So an SRU is also a good belt-and-bracers approach.
[16:11] <infinity> mdeslaur: Any qualms about me SRUing https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1574285 through the security PPA (and putting it in both pockets) for the benefit of people upgrading from security-only setups?
[16:12] <infinity> mdeslaur: There's currently no dpkg delta between updates and security, and the fix is trivial and obvious: http://anonscm.debian.org/cgit/dpkg/dpkg.git/diff/?id=ca5c108
[16:26] <mdeslaur> infinity: no qualms at all, go ahead
[16:26] <infinity> mdeslaur: Roger.
[16:26] <bdmurray> pitti: with bug 1560797 we could make the release upgrader depend on the fixed version of apt, does that seem like a good idea?
[16:27] <infinity> bdmurray: Doesn't the release upgrader force a dist-upgrade of $current_series before running the upgrade?
[16:27] <infinity> bdmurray: Or am I imagining a behaviour that was never there?
[16:29] <bdmurray> infinity: It does in most situations
[16:30] <bdmurray> infinity: check-new-release-gtk doesn't and I think that's what notifies most people
[16:30] <infinity> bdmurray: Oh.  That seems like an odd gap.
[16:31] <infinity> bdmurray: Well, if the workaround is to make it depend on things, then we'll also want it to depend on dpkg (>= 1.17.5ubuntu5.6), once I SRU that.
[16:31] <infinity> Which is incoming shortly, after I coffe myself awake.
[16:32] <bdmurray> infinity: yeah, the update notifier release notification calls check-new-release-gtk
[16:58] <doko> infinity, do you have a glibc update in the queue? else I would just to a no-change upload to pick up pie
[17:00] <infinity> doko: A no-change upload might not work.  I'll do a test build and upload in a bit.
[17:01] <doko> ta
[17:01] <infinity> doko: Though, said upload might be forcing pie off everywhere, so it would effectively be a no-op.
[17:01] <infinity> (I already force it off on s390)
[17:02] <doko> hmm, ok. sbeattie just mentioned that we should upload that one
[17:02] <infinity> I'll get it sorted.  Enabling it might require me to do some upstream work to sort out a few things.
[17:18] <doko> sbeattie, check ftbfs at least on i386: https://launchpad.net/ubuntu/+source/check/0.10.0-3build1
[17:20] <sbeattie> doko: that's strange, looking.
[18:54] <rlaager> Which package (in Launchpad) should text-mode installer bugs be assigned to?
[18:55] <Unit193> rlaager: Perhaps you are talking about the 'alternate installer' or server installer?  If so, debian-installer.
[18:56] <rlaager> Unit193: I am. debian-installer is what I expected. I couldn't find that package. I'll try again.
[18:56] <Unit193> https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bugs/
[19:01] <rbasak> !dmb-ping
[19:01] <rbasak> Oooh, it works.
[19:01] <rbasak> Maybe out of date though?
[19:02] <stgraber> clearly out of date :)
[19:02] <Unit193> https://launchpad.net/~developer-membership-board/+members
[19:02] <rbasak> sil2100: ping
[19:04] <Unit193> rbasak: Fixed.
[19:04] <rbasak> Unit193: thanks :)
[19:07] <sil2100> rbasak: pong :)
[19:19] <showaz> Hi guys, why is everything so horrible https://people.canonical.com/~ubuntu-security/cve/universe.html?
[19:19] <pitti> bdmurray: if that doesn't need an SRU by itself, sure; I take it you don't just mean adding a plain Depends:, as then users would first have to install *that*, but instead doing that in the downloaded tarball?
[19:19] <pitti> bdmurray: it could also be that a lot of these duplicates are from plain apt-get dist-upgrades, or not?
[19:21] <sarnold> hey showaz; a few reasons: (a) once a package is vulnerable to something, it's hard for it to get off the list -- we never revisit open universe cves to determine which ones might have been closed with newer releases
[19:21] <sarnold> showaz: (b) there's just not that many people tending to universe packages; there's a handful of people who tend to their handful of favorites, but by and large universe is often overlooked
[19:22] <showaz> sarnold: fuzzing packages?
[19:22] <sarnold> showaz: I meant more, providing debdiffs for sponsoring
[19:24] <showaz> Yes actually it is good that popular packages not affected vulnerable
[19:25] <showaz> hmm.. libjpeg9 instead of turbo-jpeg
[19:27] <sarnold> flexiondotorg: congratulations :)
[19:28] <flexiondotorg> sarnold, Thanks :-)
[19:34] <doko> pitti, please have a look at the apport, crash and fpc autopkg test failures triggered by the no-change upload of binutils
[19:41] <ginggs> doko, pitti: iirc the armhf and i386 issues with fpc were fixed in fpc 3.0.0+dfsg-4 which never migrated because of the ftbfs on powerpc due to glibc  (LP: #1562480_
[19:48] <bdmurray> pitti: It's a special ubuntu-release-upgrader depends http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/view/head:/DistUpgrade/README#L37 the upgrade won't proceed if it is not met.
[19:59] <AlbertA> pitti: the s390x tests here: https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-019/excuses.html
[19:59] <AlbertA> don't seem to complete
[19:59] <AlbertA> any ideas?
[20:07] <Umeaboy> Hi!
[20:07] <Umeaboy> I don't mean to be rude in any way, but I think I found a sentance that's written in the wrong way in a po file. I'd like to check if I'm correct in my judgement.
[20:08] <Umeaboy> Could not create SSL connection through proxy server: %s
[20:08] <Umeaboy> Shouldn't that instead be written like this: Could not establish a SSL connection through the proxy server: %s
[20:08] <Umeaboy> ?
[20:08] <slangasek> Umeaboy: why do you think it's wrong? it looks reasonable to me
[20:09] <Umeaboy> You don't create a connection to SSL. You use SSL to encrypt the connection.
[20:09] <Umeaboy> Right?
[20:09] <Umeaboy> I could be wrong thou.
[20:09] <Umeaboy> In that case I'm sorry.
[20:09] <slangasek> it would not be "a SSL connection", fwiw, it would be "an SSL connection"; the rules for a/an follow pronunciation not spelling
[20:10] <Umeaboy> I wasn't talking about spelling error either.
[20:10] <Umeaboy> I'm talking about HOW the sentance is formed.
[20:11] <slangasek> Umeaboy: as a native speaker, I don't have a problem with what's written there.  "create SSL connection" doesn't mean "create a connection to SSL", SSL is an adjective that modifies "connection"
[20:11] <Umeaboy> I agree, I'm not an English native speaker so I don't keep track of all the rules, but......
[20:11] <Umeaboy> I was just saying.
[20:11] <Umeaboy> OK, in that case I'm sorry.
[20:12] <doko> crap, pitti invalidated icu, giving back s390x autopkg tests :-/
[20:12] <slangasek> Umeaboy: no problem, thanks for asking
[20:13] <slangasek> doko: invalidated because tests that were ignored as always-failed have been reset to 'in progress'?  We can override that
[20:15] <doko> slangasek, well, let's see if these succeed. but I'm fine to override these
[20:16] <tyhicks> infinity: hi - I need to sponsor a small grub2 upload to yakkety which causes it to build with --no-pie
[20:17] <slangasek> doko: ideally an in-progress run of an always-failed test would also not block us.  OTOH, some of these are tests that have passed before on s390x (evolution-data-server), so how would this have been a candidate before pitti gave them back?
[20:18] <tyhicks> infinity: does a corresponding grub2-signed update need to happen at the same time?
[20:19] <Umeaboy> How long time til 16.04 is released as a NON LTS version?
[20:19] <slangasek> tyhicks: yes
[20:19] <tyhicks> slangasek: thanks - I couldn't remember if that was required for the dev release or not
[20:19] <tyhicks> slangasek: do you know if we have that process documented anywhere?
[20:19] <slangasek> tyhicks: so to be clear, a grub2 upload to devel will stick in -proposed until grub2-signed upload also happens.  So it doesn't /have/ to happen "at the same time", but
[20:20] <doko> slangasek, enouclue. maybe he ignored these while s390x autopkg test were broken or builds not available?
[20:21] <slangasek> tyhicks: process> probably not, except if the security team themselves have documentation for it; it's one of those packages that if you don't know already, you probably shouldn't be touching without talking to somebody (which you've now done ;)
[20:21] <tyhicks> agreed :)
[20:21] <infinity> tyhicks: The process is "update the build-deps and upload the source".  There's prior art in pretty much every previous upload.
[20:22] <infinity> tyhicks: But if you copy grub2 over, I can do -signed.
[20:23] <infinity> tyhicks: I believe the security team process says "ask someone like Adam for help with this". :P
[20:23] <tyhicks> infinity: I think I can handle both of them - the previous grub2-signed uploads look very straight forward but I didn't want to miss any behind the scenes steps
[20:23] <infinity> tyhicks: Which should probably be "ask an AA who knows how the package works".
[20:23] <tyhicks> (sounds like there aren't any)
[20:23] <infinity> tyhicks: There are AA steps when you copy out of a PPA.
[20:24] <tyhicks> "IMPORTANT: also needs grub2-signed updates, and special publishing procedure - talk to infinity" :)
[20:24] <infinity> tyhicks: But the big thing to know is that even if your PPA can build UEFI signed bits (not sure if yours does), you should *never* copy -signed *binaries* from a PPA to the archive.
[20:24] <infinity> tyhicks: grub2 binaries are fine, but -signed should be a sourceful upload/copy to the archive.
[20:25] <slangasek> it should? whyzzat?
[20:25] <infinity> slangasek: Because if you have a PPA with a UEFI signing key and upload grub2-singed to your PPA, the grub2-signed binaries are now signed by your PPA key, not the archive ket.
[20:25] <infinity> s/ket/key/
[20:25] <tyhicks> infinity: ack - I'm not copying out of a ppa so I should be fine
[20:26] <tyhicks> (we only use the security PPA for security updates to stable releases)
[20:26] <slangasek> infinity: oh. does launchpad generate new uefi-signed artifacts on copy to the different archive?
[20:26] <infinity> slangasek: Yeah.  It signs the bits as it publishes the tarball.
[20:27] <slangasek> ok
[20:27] <tyhicks> good stuff to know - thanks
[20:33] <TJ-> whilst your on it, does the -signed build now include the crypto modules so SecureBoot can boot with a LUKS/dm-encrypt protected /boot/ file system?
[20:35] <cyphermox> TJ-: IIRC not necessarily all of them
[20:35] <cyphermox> there was a bug about this, it needs a change in grub
[20:38] <slangasek> doko: yeah, so I think s390x was being ignored architecture-wide due to some problems with the infrastructure before, and pitti probably turned it back on now that the tests are running again
[20:39] <cyphermox> TJ-: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1565950
[20:43] <rlaager> So if GRUB updates are being pushed to yakkety, https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1527727/comments/31 should be ready to go. I'd love to see that in yakkety so I can do the formal test and propose it an SRU for xenial.
[20:50] <TJ-> cyphermox: thanks; I couldn't find that earlier, but I've been hacking on grub for quite a time now and wondered if that were fixed... now using a UEFI SecureBoot PC as my prime dev PC and was hit by it last week
[20:51] <TJ-> cyphermox: currently I'm working on adding key-file and u2f/yubikey support to cryptodisk
[20:52] <AlbertA> doko: not sure who else I can ask, but would have an idea of why the s390x tests still say they are in progress here: https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-019/excuses.html
[20:52] <AlbertA> the queue seems empty
[20:52] <cyphermox> TJ-: as long as you know that I'm not going to include patches in grub that haven't been blessed by upstream developers; I wouldn't mind u2f/yubikey for my crypto though
[20:54] <cyphermox> for now I'll concentrate of pushing the changes that haven't already been, to Debian
[20:54] <cyphermox> wow, I can't proper english today
[20:58] <TJ-> cyphermox: yeah, it's work for upstream
[20:58] <cyphermox> ok
[21:21] <xnox> pitti, do autopkgtest builders think they can access non-split mirrors?
[21:21] <xnox> Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty/main/binary-armhf/Packages  404  Not Found
[21:21] <xnox> in e.g. binutils armhf test, or is this a test failure/bug?
[21:22] <ogra_> xnox, looks like a wrong mirror url to me
[21:22] <ogra_> (ports ... )
[21:28] <dax> What's the plan with fglrx and xenial? Last we heard it wasn't gonna be a thing, but I'm hearing rumors about adding it to 16.04.1?
[21:31] <xnox> dax, currently AMD does not provide binaries that are compatible with xenial's X.
[21:31] <xnox> so there is nothing we can ship.
[21:32] <gQuigs> dax: I think the rumor was about the 14.04 + 16.04HWE that we'd have to figure something out
[21:34] <infinity> xnox: Where are you seeing that?
[21:35] <xnox> infinity, in the snippet of the autopkg test log that was just on http://autopkgtest.ubuntu.com/running.shtml for binutils armhf
[21:36] <xnox> the test is for yakkety, and the error is totally for failing to fetch trusty armhf from archive.ubuntu.com
[21:36] <infinity> xnox: Might need to see more context than that to see what it's really doing.
[21:36] <infinity> xnox: But binutils looks green across the board to me, so...
[21:38] <ogra_> why would anything try to fetch armhf from archive.u.c ?
[21:40] <infinity> ogra_: Because someone asked it to. :P
[21:40] <ogra_> heh
[21:40] <infinity> "Why do 404s happen, Daddy?"
[21:43] <xnox> infinity, because people change urls =)
[21:58] <dax> xnox: yep, which is why the last paragraph update of http://news.softpedia.com/news/canonical-recommends-open-source-amdgpu-and-radeon-drivers-for-ubuntu-16-04-lts-501556.shtml confused me
[21:59] <dax> Did AMD decide they are in fact going to update fglrx again, or is the reporting there missing a good deal of "maybe"
[22:00] <xnox> dax, news agencies also reported that we released a day early, when we didn't....
[22:00] <dax> "Update: We've been informed by Oliver Grawert from Canonical that the proprietary AMD Catalyst (fglrx) driver has been temporarily removed the Ubuntu 16.04 LTS repositories, as it is not yet ported to X.Org Server 1.8. It will be added again as part of the first point release, Ubuntu 16.04.1 LTS."
[22:00] <dax> heh
[22:01] <ogra_> heh
[22:01] <dax> so they misinterpreted maybe?
[22:01] <xnox> dax, quotes taken out of context, from somebody who doesn't do anything at all with X or amd
[22:01] <ogra_> yes, definitely
[22:01] <xnox> =)
[22:01] <ogra_> <- Oliver Grawert
[22:01] <dax> oh, right, lol
[22:01] <dax> I knew that, I just forgot :)
[22:01] <dax> xnox: thank you
[22:02] <ogra_> what i heard is that amd said they would likely offer some hybrid thing based on amdgpu but with binary bits added
[22:02] <ogra_> no idea if thats real or just rumours though ... and if it exists, when it would be ready
[22:05] <TJ-> any udev experts that can confirm that using PROGRAM="..." to set $result in the same rule-statement as RUN="... $result" will fail if other rules execute in parallel processes that also set $result? I've a rule that appears to be getting result set to the output of another statement in a different rules file
[22:53] <TJ-> it seems it does, you have to capture the value with PROGRAM="...", ENV{MY_VAR}="$result" and in the later RUN="... %E{MY_VAR}" to avoid the potential race with multiple rules setting $result
[23:10] <mwhudson> when will yakkety open for uploads (ish)?
[23:10] <mwhudson> not been a developer for this part of the cycle yet :-)
[23:11] <teward> mwhudson: it will open when it opens lol
[23:11] <teward> (have patience)
[23:11] <mwhudson> teward: heh, just like the release then
[23:11] <teward> :P
[23:21] <slangasek> mwhudson: I think the current plan is to open once icu lands in xenial, so that the libpng16 library transition doesn't get entangled with further uploads
[23:22] <slangasek> and icu is currently waiting for s390x autopkgtest runners to drain their queue
[23:22] <slangasek> there's also an ocaml question I don't have the full context on
[23:23] <slangasek> anyway, #ubuntu-release scrollback addresses most of this ;)
[23:24] <Unit193> Ah cool, waiting to upload something too.
[23:24] <slangasek> no need to wait before uploading
[23:24] <slangasek> there's an unapproved queue for that
[23:32] <Unit193> Oh, OK.  Thought closed meant don't upload. :D
[23:34] <mwhudson> ah right
[23:35] <sarnold> bdmurray: https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1574458
[23:37]  * bdmurray sighs
[23:38] <sarnold> bdmurray: fwiw he also filed 1574450 which I can no longer access; he probably set it to private once he saw the logs
[23:38] <bdmurray> sarnold: I could automate making them all private fwiw
[23:39] <sarnold> bdmurray: \o/ until the apport hooks are fixed that sounds ideal
[23:39] <sarnold> bdmurray: are the apport hooks something you'd fiddle with or is that something a mysql packager needs to tackle?
[23:40] <bdmurray> sarnold: It should be easy fix the hooks although I haven't looked.
[23:46] <bdmurray> sarnold: it looks like it tries to replace the password at least
[23:49] <sarnold> bdmurray: from the config file, perhaps; granted, if the password winds up in the logs, that's probably one for oracle..
[23:50] <bdmurray> sarnold: have you verified that this happens at all?
[23:50] <sarnold> bdmurray: no
[23:52] <sarnold> bdmurray: hey, here's a log from ~last week https://launchpadlibrarian.net/254421818/Logs.var.log.mysql.error.log.txt
[23:54] <bdmurray> sarnold: and I don't see anything but I just briefly scanned it
[23:59] <sarnold> bdmurray: https://launchpadlibrarian.net/255183707/Logs.var.log.mysql.error.log.txt  has "Starting mysqld daemon with databases from /media/datadrive/data/mysql" -- that may come close..