[03:02] <slangasek> bdmurray, infinity: ok, bzip2 debhelperized; that's one missing ddeb sorted
=== NCommand` is now known as NCommander
=== NCommander is now known as Guest2749
=== Guest2749 is now known as NCommander
=== Mirv_ is now known as Mirv
[07:53] <cjwatson> ogasawara,jibel: update-{notifier,manager}/precise released now
[08:10] <jibel> cjwatson, thanks
=== Eisbrecher_xnox is now known as xnox
=== doko_ is now known as doko
=== psivaa-off is now known as psivaa
[10:51]  * cjwatson pulls lp:germinate on nusakan to fix the latest Xubuntu image build failure
[10:51] <cjwatson> (hopefully)
[10:52] <cjwatson> was previously on r533, germinate 2.12
=== ara is now known as Guest56630
=== pete-woods is now known as pete-woods_lunch
=== pete-woods_lunch is now known as ptet-woods
[13:35] <mvo_> could someone please reject my gui-ufw sponsored upload? its incomplete
[13:37] <stgraber> always happy to reject stuff, sure
[13:37] <stgraber> done
[13:40] <mvo_> thanks!
[13:47] <cjwatson> zequence: Can you explain the desktop-minimal seed to me a bit?  Are you intending to build a metapackage out of it?  There are also some oddities - for example desktop-minimal includes a dependency on network-manager-gnome, whereas desktop only recommends it
[13:52] <zequence> cjwatson: I'm going to base the desktop seeds more or less entirely on Xubuntu seeds. They recently introduced -core. Yes, I think we should make that into a meta
[13:53] <zequence> Those seeds may now be somewhat out of sync with Xubuntu seeds, as I haven't checked them for a while
[13:54] <cjwatson> zequence: The tricky bit is what to do about existing systems on upgrade
[13:54] <zequence> I would rather -desktop depended on -minimal, but I'm going to leave that up to Xubuntu devs
[13:54] <cjwatson> Well, no, it's not up to them
[13:54] <cjwatson> It's your metapackage
[13:55] <cjwatson> Normally, metapackages don't depend on each other, because that makes it hard to vary from one of them down the stack, but we may have to think about that a bit in this case
[13:55] <cjwatson> The normal way to do this would be to have the desktop seed inherit from desktop-minimal, and just make sure to install both of those when building images
[13:55] <stgraber> cjwatson: there's precedent for meta-packages depending on each other though :)
[13:55] <cjwatson> But that won't get the ubuntustudio-desktop-minimal installed on upgrade
[13:55] <stgraber> (not saying it's the right option for this case though)
[13:55] <cjwatson> *metapackage
[13:56] <cjwatson> So I think the two sane choices are (a) to strip the duplicate stuff out of the desktop seed and make it inherit from desktop-minimal (which it doesn't right now) and make ubuntustudio-desktop Depends: ubuntustudio-desktop-minimal; or (b) to leave them as entirely separate things
[13:56] <cjwatson> But you have to decide that, you can't delegate it to Xubuntu developers
[13:57] <zequence> cjwatson: -desktop-minimal only servers one purpose atm. And, that is so we can minimize the size of the CD size ISO
[13:58] <zequence> cjwatson: I'm copying Xubuntu seeds, and have proposed to them they would make -desktop inherit from -core, as they both are identical up to a point
[13:58] <cjwatson> They'll have the same decision to make, I'm sure
[13:58] <zequence> (they might have done so already, I haven't checked)
[13:59] <zequence> I will work on the desktop seeds more later on, and make sure they are reasonable
[14:00] <zequence> I will still need to solve how to install our metas over the internet when using the CD size ISO
[14:01] <zequence> The idea with the CD size is so that you can get the ISO down quickly, but still be able to install the full Ubuntu Studio system, if you want. The CD size will not be a showcase. Just a practical tool for certain things
[14:01] <cjwatson> Well, a live image doesn't offer any customisation
[14:01] <cjwatson> Unless you write a ubiquity plugin
[14:01] <zequence> Right
[14:03] <zequence> So, -desktop-minimal is only for the CD size. And, we don't want to ship the packages that are included in our multimedia metas.
[14:04] <cjwatson> Right, you've said that, but I'm not sure I understand whether that implies choice (a) or (b) above
[14:05] <zequence> cjwatson: I won't do that unless Xubuntu devs do it, as I'm copying their seeds. Not as long as their seeds are usable for us.
[14:06] <cjwatson> You won't do which one?
[14:06] <cjwatson> You have to do one or the other.
[14:06] <cjwatson> Sorry to press but I can't do anything on the images or updating ubuntustudio-meta for you without this.
[14:06] <cjwatson> And updating ubuntustudio-meta is blocking *lots* of other stuff outside Ubuntu Studio
[14:07] <zequence> cjwatson: Ah, yes. I won'd do a) until Xubuntu does so
[14:07] <cjwatson> (Although I could do a manual update of ubuntustudio-meta that just changes the libav* stuff, perhaps ...
[14:07] <cjwatson> )
[14:09] <zequence> cjwatson: By b), do you mean making -desktop-minimal a meta? Is it a problem if it is not a meta?
[14:10] <cjwatson> Whether it's a metapackage is slightly independent
[14:10] <cjwatson> It would be much more usual for the desktop-ish component of a live CD image to be a metapackage
[14:10] <cjwatson> I'm not sure that it's strictly required
[14:32] <rbasak> Any chance an SRU team member can take a look at juju-core and juju-quickstart in the Trusty queue, please?
[14:57] <zequence> cjwatson: What else would you need to start building an ISO?
[15:00] <cjwatson> zequence: I'm not sure yet :-)  Hopefully that's basically it though.  I guess I could do it without a desktop-minimal metapackage for the time being
[15:07] <zequence> cjwatson: Great. What I was mostly concerned about was "STRUCTURE", "ship" and "live" files. Seemed like it was hard to boil it down to as few files as possible, without having to duplicate entries.
[15:07] <zequence> Don't remember what I was thinking around that, but I had some ideas on how to optimize it.
[15:07] <cjwatson> I'll fix up the seeds if I run into anything horrible
[15:07] <cjwatson> Some duplication is required
[15:07] <cjwatson> Usually because even if the seed contents are the same, the way they expand differs depending on content
[15:07] <cjwatson> *context
[15:08] <cjwatson> Though some day I might add a #include mechanism or something which might help
[15:09] <zequence> cjwatson: Ok. Thanks for the help.
=== mhall119_ is now known as mhall119
[15:53] <bregma> I have an SRU that's been languishing in the pending queue for trusty for a while now, probably because the autogenerated report incorrectly  shows it has an unverified task for a bug that is not included in the SRU
[15:53] <bregma> can I get someone from the SRU team to take a look and promote the compiz SRU in trusty, please?
[15:55] <cjwatson> bregma: looking
[15:55] <cjwatson> may have to let the bug be closed and reopen it
[15:56] <bregma> #1087090 was actually removed from the SRU because it had a regression and a new build uploaded
[15:56] <cjwatson> Yeah, just following through the history, I see that
[15:56] <cjwatson> It might not auto-close in that case
[15:57] <cjwatson> OMG bug 1063617 thankyouthankyouthankyou
[15:57] <ubot93> bug 1063617 in compiz/0.9.11 "1:0.9.8+bzr3319-0ubuntu1 regression: keeps setting gsettings keys to wrong values" [High,In progress] https://launchpad.net/bugs/1063617
[15:58] <bregma> ☺
[15:58] <bregma> if I just remove the verification-needed tag from the bug would that fix it?
[15:58] <cjwatson> no, leave it alone now
[15:58] <bregma> that I know how to do
[16:01] <cjwatson> bregma: should be on its way now, thanks for the prod
[16:01] <bregma> no, thank you
[16:01] <cjwatson> And yeah, there's no verification-* tag on that bug anyway
[17:00] <ogasawara> mdeslaur: mind moderating my post to ubuntu-security-announce for the HWE stack email
[17:00] <ogasawara> infinity: I tried to send the same to ubuntu-announce but I got an email that it was flat out rejected, any ideas there?
[17:00] <infinity> ogasawara: See /msg
[17:01] <slangasek> ogra_: is there any reason not to nuke the ubuntu-touch-preview directory on nusakan, containing only quantal/raring-era images? (and thus disambiguating my tab completion ;)
[17:04] <mdeslaur> ogasawara: done, thanks!
[17:08] <infinity> liburcu sure does have a comprehensive testsuite...
[17:46] <slangasek> infinity: yes; it's mostly benchmarking actually, but the upstream has a goofy setup - 'make check' tests almost nothing, and 'make regtest' (as in, "regression test") runs the benchmarks too :P
[17:47] <infinity> slangasek: Brilliant.
[17:47] <infinity> Ugh.  Two glibc build failures in a row on ppc64el, why do I feel like I'm going to end up bisecting binutils and/or gcc today?
[18:03] <infinity> slangasek: Speaking of that "testsuite", I'm incredibly suspicious of anything that runs in nearly identical wall-time on 6 completely different (and wildly different, in some cases) machines.
[18:03] <slangasek> infinity: well, perhaps the benchmarks are of the form "how much work can we get done in $unit_time"
[18:03] <infinity> slangasek: Unless the "benchmark" tests all consist of "execute 20 instructions, sleep 2s, repeat".
[18:04] <infinity> Or, that.
[18:04] <slangasek> I haven't looked closely; I don't really care and don't plan to have to touch this package again ever, with the exception of a sync when the Debian maintainer decides what to do about the test suite :)
[18:05] <infinity> slangasek: yeah, would be nice to talk upstream into properly separating make check and make bench.
[18:05] <infinity> slangasek: Otherwise, meh.
[18:07] <infinity> I'm going to find some lunch while this glibc/ppc64el build runs on another machine and pray it was the host that was broken and not the toolchain.
[18:07] <infinity> Cause I look forward to hunting binutils bugs like I look forward to massaging my scalp with an anvil.
[18:20] <slangasek> infinity: the key is to use the narrow end