[00:43] <slangasek> do not meddle in the affairs of dpkg-maintscript-helper; for its bugs are subtle, and life's too short.
[00:51] <mwhudson> infinity: oops, i forgot to update Maintainer when i added ubuntu delta to dh-golang
[00:52] <infinity> mwhudson: Naughty.
[00:52] <infinity> mwhudson: You can go sit on the bench of shame with doko -- he never updates the maintainer. :/
[00:52] <mwhudson> heh
[00:52] <slangasek> mwhudson: set DEBEMAIL to something appropriately Ubuntuish and dpkg-buildpackage will remind you of this
[00:53] <slangasek> and yeah, I hate doing an ubuntu2 upload behind doko ;)
[00:53] <mwhudson> oh right i guess i should use ubuntu.com for packaging now
[00:58] <stgraber> can someone review lxc and lxd in the queue? lxd is trivial, lxc is a bit bigger what with being an upstream rc release and all
[00:58] <stgraber> I have some hope of tagging final lxc 2.0 tomorrow but that kind of depends on users being exposed to that last rc first :)
[01:04] <infinity> stgraber: Looking.
[01:05] <infinity> stgraber: Oh look, ports support!
[01:06] <stgraber> it was there already as a cherry-picked fix in the previous upload :)
[01:07] <stgraber> but yeah, the Debian maintainer didn't know that archive and ports are separate in Ubuntu so when fixing the ubuntu template on Debian he kinda broke it for everything but amd64 and i386 :)
[01:08] <stgraber> yay, now to tag another lxd rc, hoping that's the last one but as can be seen by the absurd number of rcs we've gone through already, I'm not gonna bet on it :)
[01:09] <stgraber> at least we're done with lxcfs, that's one less thing to worry about
[01:09] <infinity> stgraber: Meh, keep on RCing until release week, as long as the bugfixes are tiny and auditable.
[01:10] <infinity> stgraber: Just gimme a shiny round number before we close the archive. :P
[01:10]  * infinity isn't sure if he'd have more confidence in 2.0rc1 or 2.0rc30, but 2.0 is always prettier)
[01:10] <stgraber> well, our plan was to land the first upstream bugfix release of all 3 before 16.04 releases but for that to work we need to release the actual thing first and for that to happen people should stop reporting rc bugs :)
[01:11] <infinity> rc30 is either a sign of an anal-retentive perfectionist upstream release manager, or people who Really Can't Get It Right, Ever.
[01:13] <infinity> stgraber: Knowing you, I'm sure it's the former, but if it was just some random, I might start thinking it was the latter. :P
[01:13] <infinity> Tag, "crap, it's broken", tag, "crap, it's broken", ad infinitum.
[01:14] <stgraber> :)
[01:14] <stgraber> I thing we had one lxc tag where I had to tag again 10min later because someone landed a change which introduced a new file but which wasn't included in the dist tarball... turns out things don't build when files are missing.
[01:15] <infinity> Picky, picky.
[01:15] <infinity> Also, never push a tag until you've tested.
[01:15] <stgraber> but that was at at the time where the kernel was busted so jenkins was lying to us, otherwise we'd have caught it way earlier (as our jenkins job does a make dist + build + package on all arches we care about and even on Android)
[01:15] <infinity> They're super easy to delete locally.  Super hard to delete from everyone else's computer. :P
[01:16] <slangasek> infinity: you're going to love reviewing this one.  A taste of things to come: http://paste.ubuntu.com/15572738/
[01:16] <stgraber> "./configure && make && make install" worked great locally :)
[01:16] <infinity> slangasek: Dude.
[01:17] <infinity> slangasek: How's the ganja over there?
[01:17] <slangasek> infinity: 100% legal
[01:17] <stgraber> slangasek: you forgot to throw some messing with IFS in there
[01:18] <slangasek> stgraber: haha
[01:18] <stgraber> assuming your goal was to give a headache to whoever reviews it
[01:19] <infinity> I'm already a bit headachey trying to figure out *which* maintscript he feels needs that abuse.
[01:19] <slangasek> stgraber: this is a very parsimonious implementation ;)
[01:19] <infinity> But I'll wait for the glorious finished product before I string the rope.
[01:20] <slangasek> infinity: the preinst and postinst of squid.  The existing Debian package calls dpkg-maintscript-helper in both the squid and squid3 packages, for conffiles previously owned by squid3.  The 'squid' copy of these DTRT *if* you previously had the squid dummy package installed, otherwise it's a complete no-op.  The squid3 copy does the right thing *only if you haven't modified any of the conffiles*;
[01:20] <slangasek>  otherwise it overwrites the squid package's ...
[01:20] <slangasek> ... conffiles with your modified squid3 version with no conffile prompt
[01:21] <slangasek> because dpkg-maintscript-helper looks at the args and says "oh, you have no previous version? jollygood, I'll just noop all this code"
[01:21] <slangasek> so the only way to dtrt is to trick it, in the squid maintscripts, to not no-op
[01:21] <infinity> Gross.
[01:25] <infinity> slangasek: Oh well, to be fair, I pointed someone to the pkgbinarymangler preinst as a "useful example" today, so we all have blood on our hands.
[01:27] <infinity> Speak of the devil.
[01:27] <cyphermox> haha, yeah
[01:27] <cyphermox> now I have bloody hands too, good job
[01:28] <cyphermox> oh wait, there once was usb-modeswitch too.
[01:31] <infinity> cyphermox: Oh, hrm.  I might make you reupload that, even after I pre-reviewed it. :/
[01:32] <infinity> cyphermox: The postinst bit could concievably break if an upgrade breaks for other reasons and then someone does "dpkg -i dbus.deb" over the half-installed dbus.
[01:32] <infinity> cyphermox: ie: instead of the version check in postinst, it should be a check for the diversion, probably.
[01:52] <slangasek> infinity: wow. ok, no, when all is said and done, mv_conffile does entirely the wrong thing for a modified conffile, no matter what... it just moves the new conffile aside and drops the old one in its place, in the postinst, when it's too late to get any conffile prompts.
[01:52] <slangasek> why did we ever stop using Keybuk's cargo culted code snippets again?
[01:54] <infinity> slangasek: Because a single, central copy is better.  If anyone bothers to improve it. :P
[01:54] <slangasek> it wasn't supposed to need improving :P
[01:54] <slangasek> it was supposed to have gotten all this stuff right on the first go!
[02:05] <slangasek> infinity: alright, so it's possible some of the work I did here didn't make a darn bit of difference anyway.  Except that it does simplify the maintscript code quite a bit overall, so probably still worth doing; and it's as good as it's going to get.  So I'll upload and if you balk at the diff I can trim things down
[02:06] <infinity> slangasek: Heh.  Does it upgrade from old versions?  That's sort of the bit that matters.
[02:06] <slangasek> infinity: it does, and it does as well a job of handling modified conffiles as dpkg-maintscript-helper allows it to
[02:07]  * infinity is filing github pull requests in anger over his upstream not understand what an ABI is.
[02:07] <infinity> Or, rather, what an SOVER is for.
[02:07] <infinity> I suppose both.
[02:08] <infinity> (No, not *that* upstream, we don't have libc7 on the horizon)
[02:08] <infinity> Though, man, if we were collectively prepared to go through the pain of another libc transition, we could clean up SO MUCH CRUFT.
[02:08] <infinity> There's a metric whackton of stuff we've removed from the API, but not the ABI.
[02:10] <slangasek> infinity: 2038 man, just drop all entry points that predate 64-bit time_t
[02:10] <rharper> slangasek: \o/
[02:11] <infinity> slangasek: That date is way less scary-far-off-futuristic than it used to be...
[02:12] <slangasek> infinity: we could avoid the transition pain by moving all the computers to within 10 feet of sealevel?
[02:13] <infinity> slangasek: To be fair, that's where an awful lot of them are already.
[02:13] <slangasek> rharper: yeah, squid3 uploaded, it should upgrade everywhere, I'm looking for whiskey now
[02:14] <infinity> slangasek: And it occurs to me that the reason Republicans outwardly appear to be climate change deniers is simply because if they continue to do nothing about it, a large portion of the Democrat voting base will be floating.
[02:14] <infinity> (Along with their fancy datacenters)
[02:21] <slangasek> infinity: PJ O'Rourke: "well sure, we *say* it's not happening, meanwhile we're buying a lot of inland real estate"
[02:26] <infinity> Man, when did 8 o'clock happen?
[02:26]  * infinity goes to find a pizza and take a TV break.
[02:28] <infinity> slangasek: If you had an upstream that bundles multiple libs in the same source, versions them based on source version, and one of them broke ABI, would you be more inclined to recommend decoupling the versioning, or just bump them both in lockstep, even though it's a lie for the unchanged one?
[02:29] <infinity> Guessing the latter is easier to explain.  And it's definitely a simpler patch.
[02:29] <slangasek> infinity: generally, decoupling
[02:29] <slangasek> but yeah
[02:31] <infinity> slangasek: Ain't no autotools or other magic in play, they literally parse the RPM specfile (lolz) for the version, and slap that on the library.  Which works well enough, but isn't amazingly flexible.
[02:32] <slangasek> infinity: software is horrible, where's that bottle of whiskey
[02:32]  * infinity will see if he can catch up with Nate and converse realtime.
[02:49] <bluesabre> Please accept the above mugshot package. Resolves several issues and has been tested by Xubuntu QA
[03:00] <bluesabre> yay!
[03:43] <bluesabre> Please accept the above catfish package. Fixes an issue with displayed timestamps and brings more complete translations.
[03:44] <bluesabre> (sorry for the redundant looking messages, but the first few seem to have worked well, and somebody seems to be seeing them :))
=== NCommander is now known as mcasadevall
[13:38] <knome> hello release team! the xubuntu team will be doing an upload to our community wallpapers package; this upload doesn't change the default wallpaper, only the some of the wallpapers available by default. would you like some kind of freeze exception paperwork done whatsoever, or can we just upload that once we have picked our winners?
[13:41] <infinity> knome: No exception needed, if the defaults are all the same, IMO.
[13:42] <knome> infinity, ok, cheerio
[13:42] <knome> we'll make sure it lands before the final freeze then :)
[13:43] <infinity> Ta.
[14:31] <teward> can I get the nginx 1.9.13 upload at bug 1563393 reviewed for an FFe?  I'd like to get this reviewed now, and included, and then the next version (to also need review, it'll be before FinalFreeze) will have additional changes - but for that next upload to go in, I'd like 1.9.13 to land first.
[14:31] <ubot5`> bug 1563393 in nginx (Ubuntu) "[FreezeException Needed] Update nginx to 1.9.13." [Wishlist,Confirmed] https://launchpad.net/bugs/1563393
[14:31] <teward> it's not in the upload queue yet, i was waiting for the review before i pushed it up
[15:00] <ogra_> can someone let livecd-rootfs in (i'd like to build a test image before EOD)
=== flocculant_ is now known as flocculant
[17:30] <infinity> superm1: Unless those symbols really were added with an Ubuntu patch (man, I hope not), you should s/0.7.0-0ubuntu1/0.7.0/ in the symbols file to get sane deps against the upstream version rather than the package version.
[17:32] <infinity> superm1: Also, is there an FFe for this?  It's pretty clearly not just bugfixes.
[17:39] <infinity> xnox: What's the point of differing from upstream on the location of cpuplugd's config file?
[17:40] <infinity> xnox: Seems like a pretty large delta for no good reason.
[17:42] <infinity> xnox: Oh, I see, it's IBM that fed you that patch.  Weird.  Does that mean they intend to move it in the upstream packaging too?
[17:43] <infinity> xnox: Also, shipping a service disabled by default is both un-Ubuntu and un-Debian.
[17:46] <teward> infinity: given the final stretch before Final Freeze, any chance you can look at the nginx FFe for 1.9.13?  I haven't uploaded yet, was waiting on the 'all clear' - bug 1563393.  Tuesday's my deadline on getting 1.9.13 uploaded...
[17:46] <ubot5`> bug 1563393 in nginx (Ubuntu) "[FreezeException Needed] Update nginx to 1.9.13." [Wishlist,Confirmed] https://launchpad.net/bugs/1563393
[17:47] <infinity> teward: Looking.
[17:47] <teward> infinity: thank you kindly, sorry to be a nag :)
[17:49] <infinity> teward: Make it happen.
[17:49] <teward> infinity: thank you kindly!
[17:50] <xnox> infinity, i will not ship a brand new config file in /etc/sysconfig/cpuplugd that it too much redhadish
[17:50] <xnox> infinity, the daemon is weird, i believe default config will make one not use 100% of available resources and scale one back.
[17:50] <xnox> which imho is wrong to be enabled by default, and hence needs user to provide/update config before enabling.
[17:51] <superm1> infinity: ack, reject it and I'll make sure the features are documented in ffe
[17:51] <xnox> infinity, and hence whilst that is undebian and unubuntu, it's least surprise.
[17:51] <xnox> and hence does not warrant to be in a standalone package
[17:51] <superm1> They're used only with new software not in archive but yes technically new features included
[17:51] <teward> infinity: it's waiting approval, can you ACK it?
[17:51] <infinity> xnox: I was with you right up until the last sentence. :P
[17:51] <xnox> infinity, however the osnmp thing adds dependency on three more shared libraries, maybe that should be split into stand alone package
[17:51] <infinity> teward: I did.
[17:51] <teward> ah, email is slow :)
[17:52] <xnox> infinity, so would you rather see cpuplug thing into standalone package, and enabled service by default instead?
[17:52] <xnox> i'm happy to upload that.
[17:52] <xnox> infinity, also what's your opinion on growing three more shared libraries deps for osnmp thing?
[17:52] <infinity> xnox: It's generally more the Debian Way to have services start when installed.  It's the element of least surprise.
[17:53] <xnox> ok.
[17:53] <infinity> xnox: As for the conffile, I'm not fundamentally opposed to it moving, I'd just like to see the movement mirrored upstream.  It's a silly delta to carry forever.
[17:53] <xnox> i think i would want to split the osnmpd into separate package too
[17:53] <xnox> because of the deps, and not eveyone carrying about snmp
[17:54] <xnox> (and for snmp to be worthwhile one needs an extra furtune, to have more than one mainframe....)
[17:54] <infinity> xnox: Yeah, no huge opinion there from me, but not dragging more deps into the base install is nice.
[17:54] <infinity> xnox: Can you name the extra packages "s390-tools-$binary", so they're obviously parts of s390-tools split out (and not pulluting namespace with the super generic names)?
[17:55] <infinity> xnox: And probably add both to s390-tools' Suggests, so they're vaguely discoverable.
[17:56] <xnox> yes and yes
[17:57] <infinity> xnox: Oh, and if that current conffile move is a copy or symlink (sadly, debdiff presents both the same), a debian/rules hack to mv tmp/etc/sysconfig/foo to tmp/etc/foo.conf would be a much less ugly delta until upstream moves it for realz.
=== nhandler is now known as StaffUnicorn
[17:57] <xnox> infinity, i did mv in debian/rules
[17:57] <xnox> then went with a patch
[17:57] <xnox> it is identical / rename
[17:57] <infinity> Yeah, I'd go for the rules mv then.
[17:57] <xnox> i might go fancy and use dh-exec to rename it in debian/*.install file =)
[17:57] <infinity> 1 line instead of hundreds. :P
[17:58] <infinity> Or dh-exec, sure.
[17:58] <xnox> ok.
[17:58] <xnox> so i take it you have rejected this upload by now, right?
[17:58] <xnox> =)
[17:58] <infinity> Yeah, I did.
[17:59] <infinity> You didn't respond on IRC in time, so I rejected it to prevent someone else accepting before we talked. :P
[18:01] <infinity> superm1: And fix your symbols too, if you missed that nag. ;)
[18:09] <infinity> teward: OOI, where do your nginx orig tarballs come from?  Are they guaranteed to be the same ones Debian will pick/use?
[18:10] <teward> infinity: upstream directly
[18:10] <infinity> teward: (Having weird deltas due to mismatched tarballs makes future maintenance suck)
[18:10] <teward> Debian grabs the pristine tarballs and uses them as their base
[18:10] <teward> most of their changes are done internal to debian/*
[18:10] <teward> including third party modules
[18:10] <infinity> teward: So, same tarballs as Debian is what I'm hearing?
[18:10] <teward> correct
[18:10] <infinity> Kay, good.
[18:10] <infinity> Thanks.
[18:10] <teward> I personally pull them right from nginx's site
[18:10] <teward> I think Debian grabs them then adds them to alioth/git
[18:11] <infinity> But with pristine-tar, I'd assume, so they reconstruct same as uptream.
[18:11] <teward> right
[18:11] <teward> the biggest hurdle going into Y-series is that Debian is, IIRC, planning on releasing their experimental module support "soon"
[18:11] <teward> as in before FinalFreeze
[18:12] <teward> Xenial FinalFreeze*
[18:12] <teward> rbasak and I discussed, so from here until Xenial release there's not going to be a merge
[18:12]  * infinity nods.
[18:12] <teward> then comes Y-series, which will be the hellish time - many more things to determine - what goes in what pocket, Security review, etc.
[18:12]  * teward shivers
[18:12] <infinity> teward: No merge with Debian (cherrypicks for bugfixes, though, please) is fine, but having the same tarball still makes it much simpler to check what the delta is.
[18:12] <teward> infinity: indeed.
[18:13] <teward> though, consider Debian's, what, at least 3 revisions behind now
[18:13] <teward> so a merge will need some finesse to make sure it works right
[18:13] <teward> last I saw, Debian's on 1.9.10
[18:13] <teward> and 'cause they never moved i've been doing direct-upload
[18:13] <teward> (Debian's aware we're gunning for 1.10.0)
[18:14] <teward> s/gunning/going/
[18:14] <teward> i hate IRC over phone >.>
[18:14] <infinity> gunning works in that context too....
[18:14] <teward> true, though i didn't type it
[18:15] <infinity> I would never have known it was a typo if you hadn't mentioned it.
[18:15] <teward> infinity: so far, though, there's not been any real bugfixes in Debian, just some feature changes to what gets HTTP/2, some third party modules that got updated to work around 1.9.11 FTBFS (we nitpicked the fix, the update to an RC version was a "yeah, no" moment)...
[18:15] <teward> i think maybe some core config changes given dynamic modules, but they're not landing in Xenial
[18:15] <teward> (Not Released, yet, in Debian, for the feature changes parts)
[18:16] <teward> infinity: I also track upstream, so when an issue happens here, and upstream has fixes, I nitpick there :)
[18:17] <infinity> superm1: Remind me to un-reject gnome-software after your new fwupd is a thing.
[18:18] <infinity> slangasek: Running out of things in the queue to use as a delay tactic.  Looks like squid3's up.  Can I trade you appstream-glib as penance?
[18:19] <teward> infinity: also, for the record, perfect example of this happened in 1.9.10 - https://launchpad.net/ubuntu/+source/nginx/1.9.10-0ubuntu1 was direct-uploaded ahead of a Debian merge for the CVE, to make sure it lands in Xenial; https://launchpad.net/ubuntu/+source/nginx/1.9.10-1ubuntu1 uploaded the next day with the Debian merge
[18:19] <teward> with no merge/tarball oddities, that almost reinforces the tarballs are both pristine
[18:19] <infinity> ogra_: [ -d /etc/cloud/cloud.cfg.d ] || mkdir -p /etc/cloud/cloud.cfg.d
[18:20] <infinity> ogra_: That test is pointless, mkdir -p is idempotent.
[18:20] <infinity> ogra_: (Not worth a reject, just pointing it out so you can make a mental note for future shell abuse)
[18:28] <infinity> slangasek: Sweet mother of holy changelogs.  I guess I can't fault you for your documentation.
[18:30] <infinity> slangasek: Why the choice to mv squid3 squid instead of moving the contents?  Concern that if it's a mountpoint you'll ENOSPC their root partition?
[18:30] <slangasek> infinity: that, plus not having to deal with dotfiles
[18:31] <mgz> slangasek: can I bug you about the suggestion to not do update-alternatives and just make a juju-1.25 binary
[18:31] <slangasek> infinity: and yeah, I'll look at appstream-glib
[18:31] <slangasek> mgz: sure
[18:32] <mgz> slangasek: the reason that I didn't do that is the way juju plugins work is they select sibiling or path binaries named juju-$PLUGIN
[18:33] <mgz> so, if we just have a juju-1.25, that breaks all juju 1.X plugins, because it will find and try to use the juju 2 plugins
[18:33] <slangasek> mgz: where do these plugins come from?
[18:33] <infinity> slangasek: The dotfile argument could surely be sorted with "for i in `ls -A1`", but the mountpoint argument is probably still valid.
[18:33] <mgz> whereas when you run `/usr/lib/juju-1.25/juju` it works, and is also unambiguous
[18:33] <mgz> slangasek: they're built from the same source
[18:34] <slangasek> mgz: /usr/bin/juju-1.25 doesn't have to be a binary, just an executable; it could be a wrapper that just calls 'exec /usr/lib/juju-1.25/juju "$@"'?
[18:34] <mgz> but the logic for doing that stuff is in go, not in the packaging
[18:34] <mgz> let me see
[18:38] <infinity> slangasek: We don't install anything by default that shows NEWS.Debian, I'm wondering if a debconf note at migration failure (before the daemon is restarted) prompting the admin to shell out, fix the situation, and continue, might not be the worst idea.
[18:38] <mgz> slangasek: plugins only work when they're on the path, and named 'juju-$NAME'
[18:39] <slangasek> infinity: I've already burned way more time on this package than it deserves; that seems like a further enhancement above and beyond, rather than a bug I've introduced with my changes?
[18:40] <superm1> infinity: ^ with the symbols fix and FFe documentation
[18:40] <infinity> slangasek: Oh, sure, it's not a bug in your bits, which are clearly an improvement over not attempting the migration at all. :P
[18:40] <infinity> superm1: Ta.
[18:40] <slangasek> mgz: isn't that a problem with the update-alternatives approach too?
[18:40] <slangasek> mgz: or, should your /usr/bin/juju-1.25 wrapper just prepend /usr/lib/juju-1.25 to the path (also trivial)?
[18:42] <mgz> slangasek: that's an idea. it's not a problem with update-alternatives when we do switching, because the plugins get symlinked into /usr/bin
[18:43] <slangasek> mgz: ok. but then that means the update-alternatives approach really doesn't support the user running the non-default alternative at all, despite it being installed
[18:43] <slangasek> I think a wrapper script makes more sense there
[18:43] <infinity> Indeed, the wrapper with a PATH modification seems much cleaner.
[18:43] <mgz> slangasek: `PATH=/usr/lib/juju-1.25/bin:$PATH juju "$@"` works
[18:44]  * slangasek nods
[18:44] <infinity> export PATH=...\nexec juju "$@" gets a prettier ps output (and lack of useless long-running shell)
[18:45] <slangasek> +#define AS_TEST_WILDCARD_MD5   "\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?"
[18:45] <slangasek> hahahahaha
[18:45] <infinity> Wat.
[18:46] <infinity> slangasek: "It's an MD5 if it's a string of the right length" is the test here?
[18:46] <slangasek> infinity: this complements AS_TEST_WILDCARD_SHA1 on the preceding line
[18:46] <slangasek> infinity: yes!
[18:46] <infinity> Oh dear.  Same thing for SHA1?
[18:46] <infinity> But, well, longer?
[18:46] <slangasek> yes! :)
[18:46] <infinity> Brilliant.
[18:47] <mgz> slangasek, infinity: so, I propose leaving the update-alternatives machinery in place (I want it for a safe way of putting alphas in the next dev release), and adding a /usr/bin/juju1 that's a script wrapper
[18:48] <infinity> mgz: Given the plugins argument, I don't see much use for the update-alteratives at all.  The safe way to do alphas would be to have a similar /usr/bin/juju3 wrapper, and then drop it when the default flips.
[18:48] <infinity> Or /usr/bin/juju-alpha, so it's not ever-changing.
[18:49] <slangasek> mgz: I am unconvinced that update-alternatives is the right tool for any of this.  The only legitimate way to change which alternative is the "default" on a system is by juggling priorities; I don't think you want to have to upload old versions of juju multiple times in a release cycle for this
[18:49] <slangasek> I also don't see that alphas warrant co-installability
[18:50] <mgz> I have had conflicting feedback on putting alphas into the distro
[18:50] <slangasek> in a dev release, standard procedure is that you upload to the archive the package that's on track to be released, and it just owns that name, and you deal with bugs
[18:50] <infinity> YOu could make all versions co-installable if they *all* used a /usr/bin/juju-$ver path wrapper and introduced a juju-defaults that ships the /usr/bin/juju symlink to the right default (Cause, hey, if it's good enough for compilers, why not replicate it everywhere!)
[18:50] <mgz> distro says go do that... everyone else doesn't want it
[18:50] <mgz> I can do the path wrapper thing in replacement
[18:50] <slangasek> who is this "everyone else" that has opinions on what should be in the dev release that AFAIK they aren't using?
[18:51] <slangasek> anyway, from a ux pov, you don't want to have to 'sudo update-alternatives fwibble' every time you switch between coinstalled versions
[18:52] <slangasek> you want to be able to run any of the installed versions of juju as a user without doing that; in which case the alternative is of marginal value but high overhead
[18:52] <mgz> it seemed like a nice way of having people who need to remain on 1.X have all their scripts still work
[18:53] <mgz> but I'm fine with doing what's suggested now
[18:53] <slangasek> sure; but the fact that juju-1.25 /won't/ be the default means the user has to do $something to keep their script working, and that something might as well be editing the script (or adding /usr/lib/juju-1.25 to their system path?) rather than managing an alternative
[18:54] <infinity> slangasek: The plan was for juju-1 to be the default, actually, to avoid breaking upgrades.
[18:54] <infinity> (But maybe that plan changed again)
[18:54] <slangasek> infinity: that plan was nacked by sabdfl
[18:54] <infinity> Ah.
[18:54] <slangasek> and I signed off on this
[18:54] <infinity> Yeah, then alternatives are pointless in this context.
[18:54] <slangasek> things don't always work without interruption on LTS upgrade
[18:54]  * slangasek nods
[18:55] <mgz> okay, so I'll switch to wrapping scripts named juju-$VERSION that add /usr/lib/juju-$VERSION/bin to the path
[18:55] <slangasek> by which I mean: the distro should work without interruption on LTS upgrade, but things external to our packages that make assumptions are not guaranteed to work without modification
[18:55] <slangasek> mgz: +1, thanks
[18:55] <infinity> There's no real difference between saying "you must run update-alternatives" or "you must sed s/juju/juju-1.25/ in all your scripts", except that the latter is a much saner explicit choice that works everywhere and isn't dependent on some obscure system config.
[18:55] <mgz> thanks for the explanations guys
[18:56] <infinity> And, indeed, if the version wrappers persist forever, people can keep that explicit choice motif going forward and be less surprised on the next upgrade.
[18:57] <infinity> (ie: they can move to 2, and then when 3 happens, their 2 scripts won't be broken and they can test and move)
[19:02] <mgz> I have some fiddly bits with man pages and bash completion to work out, but am just removing scripts for now
[19:18] <mgz> slangasek: can the FFE bug be accepted as it stands? I'm doing the changes for name-version linking, were there other concerns to address?
[19:27] <infinity> doko: Why does --with-milestone differ between EFAULT_CONFIGURE_ARGS and COMMON_CONFIGURE_ARGS?
[19:27] <infinity> s/EFAULT/DEFAULT/
[19:27] <slangasek> mgz: the packages to be accepted will need to meet the outlined conditions; are you asking for the bug to be marked 'Confirmed'?
[19:28] <infinity> doko: re: openjdk-8, if that wasn't clear.
[19:32] <slangasek> infinity: ok so I've reviewed appstream-glib and this looks to me like a featureful upload with no FFe bug, no upstream changelog, and no assurance of upstream QA (git snapshot); unless you had some other context, this looks like a nack to me
[19:32] <mgz> slangasek: do you/release team need to review the debian/rules once I've uploaded to unblock this process? or are we good to propose with these changes?
[19:32] <infinity> slangasek: I had zero context outside the diff being something I didn't want to read.  All you.
[19:33] <slangasek> mgz: there will be a post-upload review
[19:33] <mgz> slangasek: so, do I have the sign-off to upload? that's not reflected in the bug at present.
[19:33] <slangasek> mgz: you unblock the process by getting something uploaded
[19:34] <infinity> slangasek: "rm -f || true"?  You don't trust the effiness of -f?
[19:34] <slangasek> infinity: hum.  Did I write that? or did I copy it from somewhere
[19:35] <slangasek> (what did I rm -f and why?)
[19:35] <infinity> slangasek: I dunno.  If you copied it, it's not from anywhere in context. :P
[19:35] <slangasek> infinity: ah, I copied it from dh_apparmor's maintscript snippet :-)
[19:40] <infinity> slangasek: Oh, also, that squid3->Pre-Dep: squid, squid->Conflicts: squid3 combo kinda buggers the world a tiny bit.  That Conflict should surely be a Breaks.
[19:41] <slangasek> infinity: it was like that when I got there.  I at one point iterated and dropped it to Breaks, then reverted because of the horror of dpkg-maintscript-helper being called in both packages. Let me think
[19:41] <infinity> The conflict forces a total removal before we even start, which messes up any attempts to stop the old daemon, and also busts your mv_conffile attempts, if we're doing the upgrade with --purge.
[19:42] <slangasek> the old daemon is stopped by the old package's prerm
[19:42] <slangasek> ... who does an upgrade with --purge?
[19:42] <infinity> I do. :P
[19:42] <infinity> Pretty much always.
[19:43] <slangasek> right, well
[19:43] <slangasek> yes, I think the Conflicts can and should be dropped to Breaks now that the maintscripts are confined to a single package
[19:43] <slangasek> but I'll need to re-test that
[19:45] <infinity> slangasek: The rest looks vaguely reasonable in that "I'd really have to build it and test to be sure" sort of way.
[19:47] <infinity> tjaalton: Where's the FFe for this major version bump to wayland?
[19:47]  * infinity said, while clicking reject.
[19:49]  * mdeslaur chuckles at commentary
[19:55] <slangasek> infinity: ok, so I'll downgrade Conflicts to Breaks, retest the upgrades, and reupload.  Do you want the current one accepted or rejected in the meantime?  Note that while I versioned the Conflicts in this upload, it's there in the one currently in -proposed already
[19:56] <infinity> slangasek: Yeah, I'd rather we just leave this in the queue while we test.  Then we can accept whichever turns out to be more correct.
[19:57] <slangasek> infinity: but block the server team from doing any more Real Testing in the meantime.  My turnaround on this is probably going to be about 2 hours
[19:57] <infinity> slangasek: And +1 from me on this, other than that one sticking point, so if you either come to the conclusion that the Conflict is necessary or reupload with Breaks and that's the only diff, feel free to self-accept.
[19:57] <infinity> slangasek: To be fair, it's EOD for most people by now anyway.
[19:57] <infinity> (or close to it)
[19:57] <infinity> EOW, even.
[19:58] <infinity> slangasek: But I suppose you're right that it does no harm to upload twice.  I can accept this one, and you can self-accept the 1-liner if it's gooder.
[19:59]  * infinity won't be testing upgrades on his production kit until the second upload happens. :P
[20:14] <infinity> superm1: You appear to have an endian bug in fwupd which, based on the build logs, might actually be a singed-comparison bug that is exacerbated by your ints being backwards. :P
[20:15] <tjaalton> infinity: gnome folks asked for it, i don't care
[20:15] <infinity> tjaalton: Well, you uploaded, you get to be the one who cares.
[20:15] <tjaalton> heh
[20:15] <infinity> tjaalton: Alternately, get the "GNOME folks" to file an FFe and sync in their name. :P
[20:15] <superm1> infinity: sigh, and it looks like it's only encountered from actually running the test suite on all the other archs now :)
[20:16] <infinity> superm1: Well, good.  That's what testsuites are for.
[20:16] <tjaalton> it's a build dep for mesa & xserver, only reaaon why it's in main
[20:16] <tjaalton> iirc
[20:16] <infinity> tjaalton: And gtk, and a few others.  But it still has the ability to destabilise the world.
[20:16] <infinity> (it's a runtime dep too, obviously)
[20:17] <superm1> infinity: can you let it through proposed for now and this can be investigated more closely at a lower priority?  the more interesting part today really is x86
[20:17] <infinity> superm1: No.
[20:18] <infinity> superm1: It's regressed on two arches.
[20:18] <superm1> okay.
[20:18] <infinity> superm1: If what you're saying is "this was always broken on BE, apparently", you can reupload with the tests disabled on BE, so it can build everywhere, and thus things can link to it.
[20:19] <infinity> superm1: But I'd want a pretty firm commitment to actually fix the bug.  Since endian and singed-compare bugs are often lurking evil on other arches too that your testsuite just happens not to notice (or that other code could perturb into a bug)
[20:21] <superm1> infinity: yeah i'll need to get some BE emulation set up to investigate further, but yes likely this was broken everywhere BE most likely all along
[20:21] <infinity> superm1: Without looking at the code, I'm betting it's a signed-char versus unsigned-int comparison, where you just happen to not be comparing the top bit, so it works by accident on some arches, but explodes on big-endian because the ints also happen to be flippity whee.
[20:23] <infinity> superm1: Based on that, and a build log, you might be able to fix it blind (happy to test).  But I can hook you up with BE hardware if blind is a no-go.
[20:28] <infinity> superm1: Oh, or actually, it's the length mismatch that's probably the endian bug.  I missed that one.
[20:28] <infinity> superm1: (You'd end up comparing the wrong half of your long)
[20:28] <infinity> superm1: But you should fix the singed-compare bug too. :P
[20:28] <infinity> superm1: Anyhow, both are staring at you angrily in the build log.
[20:34] <infinity> superm1: FWIW, both those compiler warnings were there in the previous version, so I'd be okay with an upload to disable the testsuite on big-endian and a commitment to fix and reenable "soon".
[20:37] <superm1> infinity: OK well i'll take a stab at a fix and make the test suite failing non-critical on those archs in case it's not adequate
[20:37] <infinity> superm1: ifeq($(shell dpkg-architecture -qDEB_HOST_ARCH_ENDIAN),big) for the workaround
[20:39] <superm1> infinity: can i have my PPA turned on for one of those archs?
[20:39] <infinity> Sadly not yet. :(
[20:39] <superm1> that way i don't need to waste more of your time trying to fix it
[20:39] <superm1> oh
[20:39] <superm1> okay
[20:39] <infinity> We're almost there for powerpc.
[20:41]  * infinity notes that he failed to lunch again, and goes to find a snack.
[21:39] <slangasek> infinity: yeah, I'm good with the Breaks/Replaces behavior; uploaded
[21:43] <infinity> slangasek: Ta.
[21:47] <infinity> Okay, now lunch for realz.  I mean it.
[21:47] <infinity> Back later.
[21:48] <superm1> infinity: it looked like an easy rabbit hole, but alas it's deeper than it appears , test suite off for now on those archs but i'll work with upstream to get this fixed
[21:49] <slangasek> infinity: "failure to lunch", a common problem for the younger generation
[22:01] <superm1> blah, s390x is failing harder than powerpc was
[22:04] <superm1> xnox: although the s390x failure was with launching valgrind, is that itself working on s390x?
[22:05] <superm1> i see the build used 1:3.11.0-1ubuntu2, but 1:3.11.0-1ubuntu3 was just uploaded to proposed.  probably should retry with that
[22:08] <slangasek> superm1: "illegal instruction"?
[22:09] <slangasek> (cf https://launchpadlibrarian.net/249873837/buildlog_ubuntu-xenial-s390x.colorhug-client_0.2.8-1_BUILDING.txt.gz which I knew was another package using valgrind at build-time)
[22:10] <superm1> looks pretty similar  failure
[22:12] <superm1> looks like trying with new valgrind did resolve it
[22:12] <slangasek> and it looks like -1ubuntu3 is a fix specifically for s390x issues, so \o/
[22:13] <slangasek> superm1: ah, you did a rebuild and already picked up -1ubuntu3? I was waiting for it to show up in rmadison before retriggering things
[22:13] <superm1> yeah
[22:13] <slangasek> spiff
[22:13] <superm1> talk about convenient timing
[22:14] <slangasek> clearly dannf was sent back in time from the future to fix all our s390x bugs
[22:16] <dannf> but not in a nude terminatory way, i promise
[22:20] <slangasek> "come with me if you want to virtualize"
[23:06] <flocculant> cyphermox: you might like to know that I have now got an upgraded xubuntu 16.04 from 14.04.4
[23:06] <flocculant> I know I did ;)
[23:12] <flocculant> restart appeared to not - but in the context I still think it's a win :)
[23:20] <infinity> flocculant: Restart should work, so still some bugs to squish, but yay progress.
[23:21] <flocculant> yea - I realise it *should* but given I was wiki warning last week - definitely progress :)
[23:22] <flocculant> infinity: also, your throw away comment last week re flavours and release notes - made me stop and think a bit - so if I save time next cycle- thanks :D
[23:39] <superm1> infinity: I recall you told me to remind you to unreject gnome software earlier
[23:40] <infinity> superm1: Yup, already have the tab open.  Was just waiting for those binaries to publish in the release pocket, for reasons unexplained.
[23:40] <superm1> Kk