[00:00] <xnox> slangasek, ok. attached a gdb backtrace gnutls module trips up... which juju-local uses...
[00:03]  * xnox doesn't like the "Backtrace stopped: previous frame inner to this frame (corrupt stack?)"
[00:06] <slangasek> xnox: is valgrind more informative?
[00:08] <xnox> slangasek, http://paste.ubuntu.com/14683950/ ?
[00:18] <slangasek> xnox: invalid read in the valgrind preload? ok shure
[00:19] <slangasek> xnox: was the "user process fault" == SIGILL?
[00:19] <xnox> rsyslog.service: Main process exited, code=killed, status=11/SEGV
[00:21] <slangasek> hmm
[00:21] <slangasek> so it's possible valgrind doesn't understand z12 code
[00:22] <xnox> slangasek, true. however it seems like i'm not the only one
[00:22] <xnox> bug 1534106
[00:22] <ubot5> bug 1534106 in rsyslog (Ubuntu) "rsyslogd crashed with SIGSEGV with juju-local configuration" [High,Triaged] https://launchpad.net/bugs/1534106
[00:22] <xnox> bug 1538454
[00:22] <ubot5> Error: Launchpad bug 1538454 could not be found
[00:22] <xnox> http://pad.lv/1538454
[00:23] <slangasek> xnox: sure; I don't doubt that it's a real bug, but the fact that valgrind is throwing SIGILL for you makes it difficult to debug :)
[00:23] <slangasek> unless that bug is reproducible cross-architecture?
[00:24] <xnox> yeap.
[00:24] <xnox> pitti has it with juju-local on amd64 it seems
[00:24] <xnox> (unless it's a different bug in the same config, and same rsyslog module)
[00:24] <slangasek> aha, ok
[00:30] <flexiondotorg> infinity, slangasek, Ubuntu MATE i386 and PPC still showing as rebuild in the QA tracker. Can you correct that?
[00:46] <infinity> flexiondotorg: Thwacked again.  How does this keep happening?
[00:46] <infinity> Oh.
[00:46] <infinity> Maybe if I didn't cancel in --dry-run mode...
[00:47] <infinity> flexiondotorg: Fixed for real this time. *blush*
[00:49] <infinity> flexiondotorg: Sorry about that.  It's not so much that I'm stupid, just that I'm the opposite of smart.
[00:50] <knome> trams?
[00:51] <infinity> Ding, ding.
[01:09] <wxl> slangasek: infinity: you gents have any idea what we're going to do with the trusty point release?
[01:10] <wxl> i see it moved a week dowen in the schedule
[01:10] <wxl> https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule has it a week later
[01:19] <slangasek> wxl: hi - "do with it" in what sense?  yes, the date has been pushed back, which I believe infinity mentioned on ubuntu-release (though buried in a thread, not as an announcement)
[01:21] <wxl> slangasek: it was mentioned, but the note was that it would be taken care of later
[05:54] <slangasek> xnox: you've disabled test suite in htslib to make it build; in turn this makes the build-dependencies for samtools installable, but samtools' tests fail at build time.  Should samtools tests also be disabled, or is it rather the case that the test failures indicate real problems with htslib?
[05:59] <slangasek> xnox: (asking because jquery blocked by python-pbcore, python-pbh5tools autopkgtests failing due to broken python-pysam, dep-wait in xenial-proposed on samtools)
=== darkxst_ is now known as darkxst
=== stokachu_ is now known as stokachu
=== sil2100_ is now known as sil2100
[09:02] <flexiondotorg> infinity, Thank you :-)
[10:56] <Odd_Bloke> flexiondotorg: wxl: Cloud images are ready for alpha-2 whenever; given this isn't GA, shall I pull the trigger(s) now?
[12:48] <Odd_Bloke> I'm gonna go ahead and pull the trigger on cloud images; I'd like to see any problems that crop up before my day ends. :)
[12:50] <flexiondotorg> Odd_Bloke, OK, I'll add CLoud to the Release Notes.
[12:53] <flexiondotorg> Odd_Bloke, Can I confirm that you are says the Cloud images for alpha-2 are Ready?
[12:53] <Odd_Bloke> flexiondotorg: They are being published out to clouds now.
[12:53] <flexiondotorg> Thanks.
=== smb` is now known as smb
=== smb is now known as Guest52432
[14:09] <LocutusOfBorg> hi release team, I'm actually doing a lot of work to have ubuntu packages ready for libpng1.6 transition, can you please tell me if it is feasible for xenial?
[14:09] <LocutusOfBorg> the transition is ready in debian
[14:09] <LocutusOfBorg> and I syncd/merged almost all the packages in Ubuntu
[14:09] <Laney> LocutusOfBorg: do you have a transition tracker?
=== xnox is now known as s390x
=== s390x is now known as xnox
[16:15] <mapreri> Laney: he does not /cc LocutusOfBorg
[16:15] <mapreri> (in ubuntu)
[16:17] <LocutusOfBorg> Laney, nope, I'm not sure how ubuntu handles transitions
[16:17] <xnox> LocutusOfBorg, same as debian does =)
[16:17] <LocutusOfBorg> metapackage?
[16:17] <mapreri> (except there is not the auto-transitioner)
[16:18] <LocutusOfBorg> I remember they were setup
[16:18] <xnox> mapreri, true.
[16:18] <LocutusOfBorg> but you seem to not use them anymore, bad for me :(
[16:18] <Laney> not true
[16:18] <mapreri> LocutusOfBorg: http://people.canonical.com/~ubuntu-archive/transitions/
[16:18] <xnox> LocutusOfBorg, ben transition tracker, eg.. http://people.canonical.com/~ubuntu-archive/transitions/
[16:18] <LocutusOfBorg> yes, I know that page, but it looks always the same
[16:18] <cyphermox> yeah, for instance there was the perl transition not that long ago
[16:19] <xnox> LocutusOfBorg, metapackages may or may not help with transitions. Most libraries don't use metapackages.
[16:19] <LocutusOfBorg> I think many transitions just don't appear there
[16:19] <mapreri> Laney: what's not true?
[16:19] <LocutusOfBorg> e.g. auto transitions
[16:19] <Laney> that we don't use the transition tracker
[16:19] <cjwatson> lots of small transitions aren't worth tracking
[16:19] <LocutusOfBorg> xnox, I mean, opening a bug against release.ubuntu.com metapackage
[16:19] <cjwatson> if there's like four packages you JFDI
[16:19] <LocutusOfBorg> sure
[16:19] <mapreri> Laney: I said, you don't use the auto-transitioner, https://anonscm.debian.org/cgit/collab-maint/auto-transition.git/
[16:20] <Laney> mapreri: I wasn't answering to you
[16:20] <cjwatson> but if you look at the history of lp:~ubuntu-transition-trackers/ubuntu-transition-tracker/configs there's plenty of turnover there
[16:20] <LocutusOfBorg> anyway, I would appreciate to know where to open a bug and discuss libpng16 (if you think there is enough time)
[16:21] <LocutusOfBorg> debian is ready, only 22 packages are FTBFS, but for unrelated reasons, so we can't patch them
[16:21] <LocutusOfBorg> and I pretty much syncd/merged every package on ubuntu
[16:21] <LocutusOfBorg> so it should be a matter of rebuilds
[16:21] <LocutusOfBorg> but I miss the paperwork for release team  :)
[16:22] <cjwatson> the nearest equiv to opening a bug against a metapackage would be to open a bug against the package that's the root of the transition and subscribe ~ubuntu-release
[16:22] <LocutusOfBorg> that package is not in ubuntu (libpng1.6)
[16:22] <LocutusOfBorg> I can open a bug against the old one
[16:23] <cjwatson> doesn't stop you opening a bug against the new one
[16:23] <cjwatson> https://launchpad.net/ubuntu/+source/libpng1.6 exists
[16:23] <LocutusOfBorg> oh yes, just not published, but existing
[16:23] <LocutusOfBorg> wonderful
[16:23] <cjwatson> probably because the source package name exists following the auto-import of https://launchpad.net/debian/+source/libpng1.6 from experimental
[16:23] <cjwatson> creating SPNs is not too hard
[16:26] <LocutusOfBorg> I can't create a bug against that package
[16:27] <LocutusOfBorg> "libpng1.6" does not exist in Ubuntu. Please choose a different package. If you're unsure, please select "I don't know"
[16:27] <cjwatson> oh, well, just use libpng then *shrug*
[16:28] <LocutusOfBorg>  (Error ID: OOPS-3f79f2d24ee2b339622a0ef266d7a62c)
[16:28] <LocutusOfBorg> I tried :)
[16:28] <apw> good old launchpad
[16:29] <cjwatson> do file a bug about that oops, it should be refused but not oops.  anyway, libpng should work
[16:29] <LocutusOfBorg> I stole an already open bug
[16:30] <LocutusOfBorg> #1524328
[17:14] <bdmurray> slangasek / infinity: I'd like to release the SRU for bug 1507151 early so the people who can't upgrade to Vivid could try upgrading to Wily (if the use a custom meta-release file)
[17:14] <ubot5> bug 1507151 in sysvinit (Ubuntu Wily) "sysv-rc.postinst calls insserv by name, but insserv package does not provide the command in a bin directory" [High,Fix committed] https://launchpad.net/bugs/1507151
[17:28] <slangasek> bdmurray: +1 from me
[18:24] <slangasek> xnox: and after twiddling the htslib/samtools/python-pysam stack a bit with binary removals, it seems python-pysam's tests fail on all architectures (but only at test time, not at package build time) - in case you have any interest there
[18:24] <xnox> slangasek, i've copied your earlier message into a google keep postit note for later.
[18:25] <xnox> slangasek, but i do take the point that unwinding things that dep-wait in autopkgtests is a good thing forward.
[18:25] <slangasek> xnox: not saying this bit is your personal responsibility, you just happened to have touched one of the packages so I thought I'd mention :)
[18:30] <xnox> =)
[18:30] <xnox> slangasek, thank you.
[19:37] <bdmurray> xenial is showing "Supported: 9m" for packages
[19:40] <bdmurray> slangasek / infinity: ^^
[19:40] <slangasek> well that seems like something we should fix
[19:40] <slangasek> I don't remember how to do that though :)
[19:44] <cjwatson> it's in lp:ubuntu-archive-publishing
[19:44] <cjwatson> you need to bring your own tears of rage and frustration
[19:50]  * slangasek checks the cupboard
[19:53] <slangasek> oh that's interesting, ppc64el is listed as "supported but not LTS"
[19:53] <slangasek> guess nobody bothered to look at that bit
[19:59] <infinity> slangasek: Unconvinced that SUPPORTED_ARCHES should even be a thing anymore, do we not support everything (except PPC) for the same time?
[20:00] <infinity> Also needs s390x added to the mess.
[20:00] <infinity> slangasek: If you're fixing, I'll be happy to review.
[20:01] <slangasek> infinity: conceptually, I know that ppc64el, s390x, i386, and amd64 are all fully LTS supported.  arm64 was not for trusty, and I don't know that it is for xenial either.  armhf is also an open question to me
[20:03] <infinity> slangasek: We certainly treat arm64 and armhf as LTS-supported, I'm not sure what the official stance from manglement is.
[20:04] <slangasek> infinity: who treats them as LTS supported and why?
[20:04] <infinity> slangasek: We continue to pull ARM-specific kernel and userspace fixes at the request of hyperscale and such.
[20:05] <slangasek> infinity: ok; I should clarify that I mean I don't know that arm64 is a full 5y LTS, but it of course is the target for a bunch of ongoing contractual work
[20:05] <slangasek> if you're getting stuff from hyperscale that kind of speaks for itself :)
[20:05] <slangasek> infinity: anyway, https://code.launchpad.net/~vorlon/ubuntu-archive-publishing/xenial-support/+merge/284341 pls
[20:06] <infinity> slangasek: Right, well, if you want to make the conservative edit and just move the IBM arches up to PRIMARY for now, that's cool, but we probably should get an answer from someone.  We advertsise ARM trusty on the website, etc, and hyperscale pushes it to customers, so it's confusing to see the shorter support listed.
[20:07] <infinity> slangasek: And Xenial=Trusty probably won't cut it once all the flavours weigh in, but maybe they'll all pick the same cycles.  +1 for now.
[20:08] <cjwatson> can has tests?
[20:08] <infinity> You kids and your tests.
[20:08] <cjwatson> hm, never mind, not much in the way of existing tests for that
[20:09] <cjwatson> I was looking at tests/test_get_supported_series.py but that's for something else
[20:09] <infinity> When I was your age, we tested by putting it in production and staying up all night fixing it when it broke.
[20:10] <infinity> (This implies that you're about a week younger than I am)
[20:35] <jderose> has anyone investigated backporting dmidecode 3.0 to 14.04.4 or adding a hack in Ubiquity to work around the "SMBIOS-implementations-newer-than-version-2-8-are-not-fully-supported-by-this-version-of-dmidecode-" junk from dmidecode 2.12 on newer hardware?
[20:35] <jderose> cjwatson: would you be open to such a hack in Ubiquity?
[20:37] <cjwatson> jderose: up to cyphermox these days
[20:38] <cyphermox> jderose: what hack?
[20:38] <jderose> cjwatson: gotcha, thanks. cyphermox: would you be open to this, or have any thoughts on a better approach? we could also get the model from /sys/class/dmi/id/product_name
[20:39] <jderose> cyphermox: so the problem is that on newer systems (especially UEFI systems), dmidecode will return something like "SMBIOS-implementations-newer-than-version-2-8-are-not-fully-supported-by-this-version-of-dmidecode-MODEL-NAME"
[20:39] <jderose> which isn't actually valid for the host name (too long)
[20:40] <cyphermox> alright
[20:40] <jderose> i should have been on this sooner, now i'm trying to come up with a not too hacky or risky solution for 14.04.4 :)
[20:43] <cyphermox> since it's already a string that gets hyphenated, maybe the easiest is to just rip that piece out if it's there.
[20:43] <jderose> cyphermox: yeah, that was kinda my thought too. is it to late to try and get this changed in Ubiquity for 14.04.4?
[20:44] <cyphermox> it's close, but no. do you want to file a bug / merge proposal to fix this?
[20:52] <jderose> cyphermox: yup, on it. thanks!
[21:09] <jderose> cyphermox: filed a bug, will get a merge proposal together shortly - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1539266
[21:09] <ubot5> Launchpad bug 1539266 in ubiquity (Ubuntu) "14.04.4: work-around "SMBIOS-implementations-newer-than-version-2-8..." junk from dmidecode" [Undecided,New]
[21:37] <jderose> cyphermox: what Ubiquity branch should I be working from? lp:~ubuntu-installer/ubiquity/trusty-proposed or lp:ubiquity or something else?
[21:42] <cyphermox>  lp:~ubuntu-installer/ubiquity/trusty-proposed is the correct one
[21:49] <jderose> cyphermox: okay, thanks!
[22:26] <flexiondotorg> wxl I heard from the Ubuntu CLoud team earlier.
[22:26] <flexiondotorg> They have release the Alpha 2 cloud images.
[22:26] <flexiondotorg> I've added details to the draft release notes.
[23:11] <jderose> cyphermox: merge proposal - https://code.launchpad.net/~jderose/ubiquity/fix-1539266/+merge/284364
[23:11] <jderose> i didn't actually build ubiquity yet, just copy the changed file over the installed one, tested that way