[07:05] <zequence> Let's look at the possibility of supporting ardour4 in the same fashion as firefox is being supported. This will work fine as long as we don't need to SRU required libraries also
[07:06] <zequence> We just sync the latest tested version from Debian testing
[12:50] <zequence> Ny email might not be working for a little while
[13:04] <astraljava> zequence: That ardour thingie sounds good. I might get a nice external sound card from a friend for this laptop, so I could in fact be able to record my guitars ran through a Behringer preamp/effects with that setup. Ardour should be the key to that, I believe.
[13:14] <OvenWerks> zequence: I am able to run ardour 4.0.0 and the nightlies with no problem on 14.04. So it should be doable.
[13:18] <zequence> At the most we would be able to backport to trusty, but perhaps we can change the update model for that particular application for release X
[13:20] <OvenWerks> The download from the ardour site is about 10 times the size of the ubuntu package  :)
[14:15] <astraljava> How can that be?
[15:01] <OvenWerks> astraljava: the DL from ardour includes any libs a distro might not have. It will work anywhere. They install their own local directory tree in /opt
[15:02] <OvenWerks> astraljava: That is why most distros want to roll their own version of ardour.
[15:04] <OvenWerks> astraljava: one would think this would use a lot of extra memory too, but the whole Ardour tree is only 150M which is actually pretty small is even a 4Gram system
[15:07] <OvenWerks> A lot of the package size concerns are not so much the installed size, but the DL/ISO size.
[15:10] <OvenWerks> Our ISO is 2.4G (vivid release) so our limit becomes 4G (next up USB thumb drive size) which will also fit a DVD.
[15:11] <OvenWerks> I don't know if it is wise, but it is probably possible to incluse the packages needed to select any DE without extra downloads and still be within that.
[15:19] <OvenWerks> It may even be possible to choose which DE to use as the live session DE... but again I don't think it is a good idea. The testing alone is beyond our manpower  :)
[15:23] <micahg> zequence: OvenWerks: you can certainly use the backports pocket to keep updating ardour for trusty, Firefox has it's special exception mainly for security reasons
[15:25] <OvenWerks> micahg: I would certainly prefer that to pointing people to the kxstudio PPAs
[17:17] <zequence> micahg: Most or all of the updates have security fixes. I'd rather update the whole thing than cherry pick single commits
[17:17] <zequence> Might get really hard to do fixes after a while too, if ardour has changed a lot in the mean time
[17:18] <micahg> only 1 CVE in the past 5 years: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=ardour
[17:19] <zequence> micahg: Well, that is truly a security issue, but I was thinking of things like losing data, etc
[17:20] <zequence> TBH, I haven't followed ardour updates very cosely. And it doesn't move as quickly as Firefox, or say the kernel
[17:20] <micahg> well, data loss is certainly critical, but not security, if there's constant data loss issues, it might be better to look to another software package
[17:21] <micahg> MREs aren't so easy to get either, upstream needs a good track record: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions/
[17:22] <zequence> micahg: Thanks for looking at the bug btw. I wasn't sure how to go forward
[17:22] <zequence> I'm sure I could do something better there
[17:22] <micahg> major issues like bug 1450992 almost certainly warrant updates of some type, whether or not that's a full update I would think would be a case by case basis (jessie will have similar issues after this update, so we can follow their lead)
[17:23] <micahg> zequence: BTW, I'd suggest trying a full backport SRU since the packaging changes are very minimal for consistency sake, I can upload that a bit later
[17:23] <micahg> (I didn't look at the changelog for your merge request, so you might have proposed that as well..)
[17:24] <micahg> that'll also have the benefit of having trusty and jessie in sync
[17:24] <zequence> No, I didn't, but I thought that might be the best
[17:26] <zequence> JUst didn't know how to request that, actually
[17:26] <micahg> Probably a comment in the bug is easiest, since we have requestbackport, it's not really worth a debdiff or merge request IMHO
[17:27] <micahg> errr...backportpackage
[17:27] <micahg> I'm test building trusty now
[17:27] <zequence> ok. I made a comment just now
[17:30] <micahg> I closed out the merge requests as well, if the SRU team rejects it, I can revert the one packaging change and reupload
[17:30] <zequence> ok, thanks
[17:30] <micahg> can you fill out the SRU paperwork in the bug description?
[17:30] <zequence> micahg: Will do
[17:31] <micahg> thanks
[17:39] <zequence> micahg: I hope that is ok. Let me know if there's anything more I can do.
[17:40] <micahg> ok, I added a note about the backport SRU
[17:41] <micahg> looks good
[17:42] <zequence> alright
[17:47] <micahg> oops, I forgot there were 2 more patches in the packaging changes, but they should both be ok as well
[17:47] <micahg> I updated the description
[17:49] <zequence> Ah, right
[18:12] <astraljava> OvenWerks: Ok nice, didn't think of that. :)
[19:25] <micahg> zequence: do you care about your name in the changelog, current tools don't make that easy for a backport
[19:43] <zequence> micahg: Not at all. I assume it will look like in vivid
[19:46] <micahg> pretty much, ok, I'll upload shortly