[00:09] <Noskcaj> bdrung, There's a fair few big bugfixes in the new owncloud update, mind if i merge it?
[00:10] <bdrung> Noskcaj: not at all! i would appreciate it
[00:10] <bdrung> RL keeps me too busy
[00:10] <Noskcaj> let me know if there's any other merges/syncs you want me to look at, i'm out of stuff to do
[00:13] <Noskcaj> never mind, my internet is too broken to work on that package
[00:22] <bdrung> Noskcaj: vlc needs an upstream update + a fix for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736788 (and then it will be a sync ;) )
[00:22] <Noskcaj> That might just be a small enough download to work
[00:23] <bdrung> Noskcaj: i have other stuff i really want to do, but can't find time for it (beside responding to all the mail backlog)
[00:24] <Noskcaj> I'll look at the vlc thing then go through what parts of your merge list are FF safe
[00:24] <bdrung> there are fixes lying around for apt-mirror, mozilla-devscripts could get some love, nemo should be updated (but the new version has some issues)
[00:25] <bdrung> ubuntu-dev-tools could get some more love, too
[00:26] <Noskcaj> well vlc is too big as well. sigh
[00:26] <bdrung> time to go to bed (at least for me)
[00:27] <Noskcaj> g'night then. it's 11am here
[00:28] <bdrung> 1:30 (utc+2)
[01:12] <teward> so, question RE: MIR and https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1262710/comments/6
[01:12] <teward> the Checklist for it points out libssl-dev.  what do i need to "check" for that?
[01:22] <Logan_> teward: I'm not a fan of having nginx in main
[01:22] <Logan_> I feel like most people who use it in production environments get it from the PPA
[01:22] <Logan_> I do, at least
[01:24] <teward> Logan_: considering that jcastro messed up and jumped the gun on the announcement about nginx getting into main, we're under pressure
[01:24] <teward> so there.
[01:24] <teward> blame jcastro
[01:25] <teward> (the PPAs will continue to be maintained either way)
[01:25] <teward> (... starting tomorrow, because my brain hurts)
[01:26] <Logan_> oh dear
[01:27] <Logan_> teward: where was this announcement made?
[01:27] <teward> http://www.jorgecastro.org/2014/01/02/nginx-coming-to-main-in-14-dot-04/
[01:27] <teward> as i said, blame jcastro
[01:27] <Unit193> That's a blog, not an announcement.
[01:27] <ekarlso> coming to main what ? ^
[01:27] <teward> Unit193: that was read by arstechnica and many other blogs as an announcement
[01:28] <Logan_> > UPDATE: Note that the MIR has been filed, technically it is not in main yet, and it must go through that process, but we’re confident that there won’t be major issues in time for 14.04.
[01:28] <Unit193> teward: Right, I read it on Ars.
[01:28] <teward> then OMGUbuntu and many other things and twitter all treated it as an announcement
[01:28] <teward> then nginx upstream heard about it then boom
[01:28]  * teward grumbles
[01:28] <Logan_> OMGUbuntu fucks up a lot of things
[01:28] <Unit193> OMG!Ubuntu hardly counts for anything.
[01:28] <teward> THEY want it in main too
[01:28] <Unit193> Logan_++, quite so.
[01:28] <Logan_> I complained to them that they misled people about MATE getting in 14.04
[01:29] <Logan_> and they never wrote back
[01:29] <Logan_> > it's not happening
[01:29] <Logan_> http://www.omgubuntu.co.uk/2014/01/mate-desktop-ubuntu-1404
[01:29] <Logan_> and there were...263 comments/misled people? ffs
[01:32] <teward> Logan_: key thing is upstream is willing to help maintain it in main
[01:32] <Unit193> Logan_: How about a mailing list post that says in it that such and such is uploaded, which should be fine if it is kept as a low target and not many downloads landing on the front page?  That's the year/day I marked them as idiots and never looked back. :/
[01:32] <teward> but ultimately, I think i'm going to end up being the one who maintains things
[01:33] <Unit193> They will likely help with patches, though.
[01:33] <Logan_> :/ I feel you, Unit
[01:34] <teward> Unit193: but ultimately i have to incorporate it to the packaging (they do the source, and provide the patch, I SRU it)
[01:34] <Unit193> I'd say that's helpful...
[01:38] <Logan_> teward: okay so
[01:38] <Logan_> what's your question about libssl-dev? :P
[01:40] <teward> what do i need to look at regarding it?  it's in the MIR checklist of things to check for build-dep on
[01:40] <teward> and IDK the specifics
[01:48] <Logan_> okay, so, that's just a basic check to make sure the build-deps are in main
[01:48] <Logan_> because that's necessary for a package to be included in main
[09:14] <mapreri> Is there someone who can help me with this: https://jenkins.qa.ubuntu.com/job/trusty-adt-varnish/ARCH=i386,label=adt/31/console ? I can't reproduce it here... (note: it fails also on debian)
[16:24] <infinity> SpamapS: So, uhm.  Want to fix the braindead SONAME != packagename bit in mysql-5.6 in experimental?
[16:24] <infinity> SpamapS: And maybe just remove it from trusty while we're at it, since that would mean 5.6 takes over the client libs...
[16:27] <infinity> SpamapS: (Currently, if you install both, you end up using the 5.6 lib anyway, because ldconfig is smarter than you, so whoever thought there was value in trying to make them coinstallable was wrong, cause they're not both usable together anyway)
[21:38] <SpamapS> infinity: do I want to fix the braindead SONAME != package name bit? no. Should somebody? Probably. :)
[21:43] <infinity> SpamapS: Well, you
[21:43] <infinity> Err.
[21:43] <infinity> SpamapS: Well, you're one of the maintainers. :P
[21:44] <infinity> SpamapS: Anyhow, it should probably be removed from trusty and blacklisted before it's fixed in Debian, since the proper fix is for mysql-5.6 to produce libmysqlclient18, which would take over the one from 5.5
[21:44] <SpamapS> infinity: I am on the team, but have never touched 5.6 packaging
[21:45] <infinity> jamespage: ^
[21:45] <SpamapS> 'twas a surprise to me to see it in Ubuntu, hence my message to the TB
[21:47] <infinity> Not sure which archive admin reviewed it, but they didn't review very closely (in both the case of Debian and Ubuntu...)
[22:02] <jamespage> infinity, SpamapS: I'll look tomorrow
[22:02] <infinity> jamespage: I filed an RC bug on mysql-5.6 in Debian regarding the binary being misnamed and not shipping the .so.18 symlink.
[22:03] <infinity> jamespage: But given that it would be impossible to ship 5.6 in universe and 5.5 in main (since only one can produce the library, and that would have to be 5.6), I think we're best off just removing it.
[22:03] <jamespage> infinity, I think I'll probably just drop the libmysqlclient from the 5.6 packaging
[22:03] <infinity> jamespage: The only other option is a very well tested move wholesale to 5.6
[22:03] <jamespage> nothing will actually use it for this release
[22:03] <jamespage> oh - snap
[22:03] <jamespage> infinity, I was intending on having a mysql-* day tomorrow
[22:04] <jamespage> the breaks/replaces/conflicts etc... are all over the shop
[22:04] <infinity> jamespage: You can't breaks/replace/conflict, it's the SAME SONAME.  It needs to be the same package name.
[22:04] <jamespage> infinity, not on that package
[22:04] <jamespage> on the mysql-* package
[22:04] <infinity> Oh.
[22:05] <infinity> So, dropping the library, how would you view that working?
[22:05] <jamespage> they work but there is no intelligence in it
[22:05] <infinity> Surely, things in the mysql source link to the client lib.
[22:05] <infinity> And would want symbols in the newer version.
[22:05] <jamespage> infinity, nope - they static link
[22:05] <infinity> Err.  Lolwut?
[22:05] <jamespage> (well at least I think they do)
[22:05] <infinity> They friggin' shouldn't. :P
[22:06] <jamespage> I think there is a good reason but it pre-dates my involvement so not sure of the details
[22:06]  * jamespage takes a quick look
[22:07] <infinity> Anyhow, dropping the client lib until 5.6 is ready to be the default would fix my complaints.
[22:07] <infinity> Ish.
[22:07] <jamespage> infinity, ack
[22:07] <infinity> It doesn't at all fix the "we want to ship 5.6, and we know people will use it, but we won't support it, so nyah nyah" issue.
[22:07] <infinity> (You can read the above as "I really don't think we should ship a version we won't support, and if we plan to support it, we should be moving to it, not supporting two).
[22:11] <jamespage> infinity, there is certainly no dep from mysql-*-anything to libmysqlclient
[22:12] <infinity> jamespage: Indeed, I noticed that myself.
[22:12] <infinity> jamespage: I still would like to talk you out of having mysql-5.6 in universe at all, but if you honestly can come up with good counter-arguments to mine, removing the client libs is a passable compromise.
[22:13] <infinity> (I just seriously don't see any point in shipping something we don't want people to run.  And if we want them to run it, we're being duplicitous to the extreme by saying "here, a new version you can try[1]" [1] but it's not supported at all, whee)
[22:14] <jamespage> infinity, I don't agree with that statement
[22:14] <infinity> Which part?
[22:14] <jamespage> that we're shipping something we don't want people to run
[22:14] <jamespage> we're indicating a clear default in -5.5
[22:15] <infinity> Then why ship 5.6?
[22:16] <jamespage> as an option at this point in time
[22:16] <infinity> People see multiple versions, they'll pick the higher one.  Because version inflation is hip and cool.
[22:16] <jamespage> we've done the same with other packages
[22:16] <jamespage> infinity, people will install mysql-server
[22:16] <jamespage> which will give them 5.5
[22:16] <infinity> I like your optimism.
[22:17] <jamespage> infinity, I'm always one of those
[22:17] <infinity> apt-cache search mysql-server gives me mysql-server-5.5, mariadb-server-5.5, mysql-server-5.6, I'm likely to pick the shiniest of the bunch.
[22:17] <jamespage> infinity, in reality we'll be proposing the switch next cycle; the reason I asked re 5.6 on the TB MRE is that we do want to support it
[22:17] <infinity> (Well, I'm not, cause I know what I'm doing, but...)
[22:18] <infinity> jamespage: Define "support".  5 years of security and SRU?
[22:18] <infinity> jamespage: Bumping upstream versions isn't quite the same.
[22:19] <infinity> jamespage: So, seriously, if you want to switch, and you want to support it, why aren't we stress-testing an actual switch instead of faffing with shipping two?
[22:19]  * lifeless wants to make a fork of mysql called shiniest-$version now
[22:19] <jamespage> because I'm not happy introducing a complex package and switch the default in a single cycle
[22:20] <jamespage> esp a LTS cycle
[22:20] <infinity> jamespage: Anyhow, IME, people often want the latest and greatest, and if it's available, they'll install it.  I love your optimism that people won't do anything other than what the metapackage tells them to, but that's not really supported by history.
[22:20] <jamespage> infinity, fone
[22:20] <jamespage> man - its to late for me
[22:20] <jamespage> fine
[22:21] <jamespage> personally I would rather folk raise these objections at the start of cycle when we discuss plans
[22:21] <jamespage> rather than ~1 month before release
[22:22] <infinity> Not everyone can be in every planning session.
[22:22] <jamespage> infinity, this plan was been documented since the last vUDS so I find it frustrating
[22:23] <infinity> And if I'd known about it at the beginning of the cycle, I would have suggested you switch to 5.6 earlier and test it.
[22:23] <infinity> Like, honestly.  If you don't think it's going to be well-tested enough to support, that's true regardless of which component it ships in.
[22:24] <jamespage> I don't think that
 because I'm not happy introducing a complex package and switch the default in a single cycle
[22:24] <jamespage> I did not say I don't think its well tested enought to support
[22:25] <infinity> What would be the argument for not switching the default if it's "well-tested enough to support"?
[22:25] <infinity> "It's complex, therefor might be broken/buggy" returns to "not well-tested enough to support".
[22:25] <jamespage> because we categorically stated 4 months ago we would not be doing that
[22:25] <jamespage> I like to make a plan and stick to it persoanlly
[22:26] <infinity> And if the TB didn't grant your MRE, would you be able to stick to your plan? :P
[22:26] <jamespage> infinity, not effectively no
[22:26] <infinity> So, maybe making plans where input from others would be helpful should solicit input from others.
[22:26] <jamespage> if they didn't grant the exception I can push microreleases which makes it pretty much impossible to support
[22:27] <infinity> FTR, your upload to trusty should have been flat-our rejected for the broken library packages too.
[22:27] <infinity> s/flat-our/flat-out/
[22:27] <jamespage> infinity, indeed which is why we had representation from teams who are involved with supporting mysql at the session including the security team
[22:27] <jamespage> its not like I've not thought this through
[22:27] <jamespage> infinity, fine - but thats just a bug and is fixable
[22:28] <infinity> But the security team won't be on the hook for maintaining it.  Which means it won't get the level of support that 5.5 does.
[22:31] <infinity> jamespage: I don't think you're doing anyone any favours with the two version, but do what you will after you've fixed the library mess.  One AA/TB/SRU member's opinion certainly doesn't have the weight of those teams.
[22:31] <jamespage> infinity, ack
[22:31]  * jamespage goes to bed