[00:06] <ScottK> http://paste.debian.net/214431/
[00:07] <ScottK> stgraber: ^^^
[00:08] <ScottK> Riddell: I was thinking that we ought to freeze transitions for everything on the images tomorrow AM (when stgraber is awake) do one final respin to get current and then test that until we're ~ready on Thursday).
[00:08] <ScottK> How does that sound?
[00:09] <ScottK> I think it's up to Edubuntu separately if they want to put a block in place or not.
[00:09] <stgraber> I don't think Edubuntu is planning to respin, but I haven't explicitly asked highvoltage about it
[00:10] <ScottK> The test results didn't look good on the ISO tracker.
[00:10] <ScottK> Not sure if you care for an Alpha 1.
[00:11] <ScottK> "block" works on source packages as well as binaries, right?
[00:12] <cjwatson> ScottK: It only works on source packages.
[00:13] <ScottK> OK.  Then my list should be right.
[00:13] <cjwatson> I've obviously not checked the details but I'm OK with such a block going in for a couple of days
[00:13] <ScottK> OK.
[00:14] <ScottK> I got the list by looking at the seed structure and cat'ing the relevant .sources files together and then de-duplicating.
[00:14] <ScottK> It wasn't pretty, but I think it's ~right.
[00:14] <cjwatson> You might want to compare against actual images, just in case.
[00:15] <cjwatson> Assuming you can come up with a reasonably efficient binary-to-source function
[00:15] <cjwatson> (I usually can but it's a bit late for me)
[00:15] <ScottK> Well, it seems I manage to have no KDE at all in there, so clearly I missed something.
[00:18] <highvoltage> ScottK, stgraber: I wasn't planning on requesting a re-spin. We could potentially fix some issues, but it's an alpha so I don't particularly care about the issues as long as they're listed as known issues
[00:18] <ScottK> OK
[01:58] <Riddell> ScottK: yes that sounds like a good plan
[01:58] <ScottK> OK.
[01:59] <ScottK> stgraber: As the U-R dude for this milestone, would you please write a mail to u-d-a letting people know?
[02:15] <cjwatson> stgraber: I've built a new precise daily that actually has the signed kernel on (though I haven't tested the installer with this yet)
[06:32] <doko> cjwatson, gcc-4.7-armhf-cross doesn't migrate from proposed, because it thinks that armhf and powerpc builds are needed
[06:57] <infinity> doko: That's not why at all.
[06:57] <infinity> doko: It's not migrating because hrw broke some dependencies, we've already discussed it.
[06:59] <doko> ahh, ok
[07:06] <doko> or not ok, bad hrw
[07:08] <infinity> doko: Basically, he stopped building biarch packages because he ran into a build failure he couldn't figure out, and that broke the gcc-4.6-cross stuff that depended on those packages.  So, our options are either fix his biarch builds or un-bi-arch the 4.6 stuff (or drop the 4.6 stuff entirely).
[07:08] <infinity> doko: He promised he'd look into the first option, before we look at the other two.
[07:09] <infinity> I might look into it in the next week or two if he doesn't get to it.
[07:58] <doko> cjwatson, infinity: the gettext b-d issue was s/gettext:any/gettext/, yes?
[08:36] <infinity> doko: Yes.  It not a critical issue to revert it (nothing's broken, per se), but the gettext:any stuff is unnecessary now, that's all.
[09:33] <psivaa> cjwatson: Precise desktop images seem to have some problem, i386 is not available, amd64 images do not have casper/vmlinuz
[09:39] <infinity> psivaa: Look again.
[09:41] <psivaa> infinity: thanks, they appear now
[09:42] <cjwatson> doko: yes
[09:42] <cjwatson> infinity: disagree, :any breaks
[09:43] <cjwatson> it's not allowed with M-A: foreign and some tools (inc. apt IIRC) enforce that
[09:43] <cjwatson> psivaa: precise amd64 images have /casper/vmlinuz.efi
[09:44] <cjwatson> (which is bootable as non-UEFI too, but the rename was necessary for installer reasons)
[09:44] <infinity> cjwatson: Ahh, fair enough.  doko uploaded the revert/fix anyway.
[09:44] <infinity> Also, WTF:
[09:44] <infinity>   if test "$cross_compiling" = yes; then :
[09:44] <infinity>   ap_cv_void_ptr_lt_long=yes
[09:45] <infinity> if test "$ap_cv_void_ptr_lt_long" = "yes"; then
[09:45] <infinity>     as_fn_error "Size of \"void *\" is less than size of \"long\"" "$LINENO" 5
[09:45] <infinity> fi
[09:45] <infinity> Brilliant.
[09:45] <cjwatson> infinity: I discovered the glory that is AC_CHECK_SIZEOF last night
[09:45] <infinity> "If cross-compiling, just fail hard for no good reason" is how I read that.
[09:45] <cjwatson> Look at its implementation - it's worth it
[09:49] <infinity> Hahaha.  Googling for this brings up an upstream commit fixing it (yay), but also the following mailing list post detailing someone's "workaround" to crossing apache:
[09:49] <infinity> ./configure  --host=arm-linux-uclibc  LIBS=-lpthread apr_cv_process_shared_works=set ap_cv_void_ptr_lt_long=no ac_cv_sizeof_struct_iovec=8 apr_cv_tcp_nodelay_with_cork=yes ac_cv_func_setpgrp_void=no  ac_cv_file__dev_zero=yes --prefix=/usb/sda1/apache
[09:49] <infinity> "Let's just preseed every potentially broken test and carry on."
[09:51] <cjwatson> The principle of dpkg-cross ...
[09:55] <infinity> Yeah, but we live in a brave new post-dpkg-cross world.
[09:55] <infinity> (Where I'm honestly impressed that most of this "just works" at this point)
[10:23] <gema_> hi release team, someone on call?
[10:24] <gema_> I'd like to know status (in the queue) of bug 1085961 and bug 1060327
[10:25] <ubot2> Launchpad bug 1085961 in ubiquity (Ubuntu) "Unable to install two raring desktops side-by-side" [High,Confirmed] https://launchpad.net/bugs/1085961
[10:25] <ubot2> Launchpad bug 1060327 in compiz (Ubuntu) "compiz crashed with SIGSEGV in compiz::opengl::bindTexImageGLX() from TfpTexture::bindTexImage() from ... from GLTexture::bindPixmapToTexture() from DecorTexture::DecorTexture()" [High,Confirmed] https://launchpad.net/bugs/1060327
[10:25] <gema_> .. which are impacting a lot our testing
[10:25] <gema_> and the ability to install Raring
[10:25] <gema_> EOM
[10:26] <cjwatson> I'll have a look at the first one
[10:26] <gema_> cjwatson: thanks
[10:26] <cjwatson> Might be best to ask the desktop/unity teams directly about the second
[10:27] <gema_> cjwatson: ack, will do
[10:28] <didrocks> gema_: is this crash on top of errors.ubuntu.com
[10:28] <didrocks> ?
[10:29] <gema_> didrocks: I don't its ranking, but I know this crash is making people unable to test on vbox
[10:29] <gema_> didrocks: which is really bad
[10:30] <didrocks> gema_: can we have the question asked just on one channel? it's currently split up on 2 :p
[10:30] <didrocks> so just pick one please ;)
[10:30] <xnox> didrocks: it's blocking the installation (since ubiquity now uses compiz). One "workaround" is to seed metacity back on to the ubuntu desktop cds, such that users can complete installation while this bug is being fixed.
[10:30] <xnox> & respin.
[10:30] <didrocks> ok, it's the first time I'm pinged with that one, so status is "unknown" and not on the priority list right now
[10:30] <gema_> didrocks: sorry, I was trying to make people aware of the issue
[10:30] <gema_> :)
[10:30] <xnox> didrocks: ack.
[10:31] <didrocks> I'll put that on the priority list when I have the meeting with the 13.04 maintenance team
[10:31] <didrocks> (next week)
[10:31] <didrocks> sounds good to you?
[10:31] <xnox> gema_: i maybe over-reacting here.
[10:31] <gema_> didrocks: not really, since it is blocking testing
[10:31] <didrocks> is that happening on every virtualbox run, starting the raring iso?
[10:31] <gema_> didrocks: manual testing
[10:31] <xnox> gema_: does this bug only happens post-install in try-ubuntu session, or can this be triggered during install-ubuntu?
[10:32] <gema_> xnox: let me find you some (I believe) duplicates
[10:32] <gema_> xnox: bug 1085171
[10:32] <ubot2> Launchpad bug 1085171 in ubiquity (Ubuntu) "installer doesn't appear Ubuntu AMD 64 in Vbox" [Undecided,Confirmed] https://launchpad.net/bugs/1085171
[10:32] <didrocks> 11:31:46 didrocks | is that happening on every virtualbox run, starting the raring iso?
[10:32]  * didrocks would like an answer
[10:33] <gema_> didrocks: I will get you one, need to talk to nick about it, he has been following the progress of it
[10:33] <didrocks> is it on "try ubuntu" or the ubiquity session?
[10:33]  * xnox does not like virtualbox at all, there are many problems with virtualbox which we can or might not be able to fix.
[10:33] <didrocks> would be good to have data about how critical this is so that I can weigh in before pinging about it with OMG it's urgent :p
[10:34]  * xnox wishes we can just not support virtualbox.
[10:34] <gema_> didrocks: understood, there's also bug 1080437
[10:34] <ubot2> Launchpad bug 1080437 in ubiquity (Ubuntu) "no background during the 13.04 daily install" [Undecided,New] https://launchpad.net/bugs/1080437
[10:35] <didrocks> gema_: so no live session it seems, but reliably on the install one?
[10:35] <xnox> gema_: no background is known & unrelated as it is present regardless of virtualisation / bare metal.
[10:35] <gema_> didrocks: judging from the iso tracker, I'd say it is quite widespread, but I will get balloons input and get some input from my team as well
[10:35]  * didrocks stop bother about this until we get data and what is impacted first :)
[10:35] <gema_> didrocks, xnox thanks for the pointers
[10:35] <didrocks> so waiting for ballons :)
[10:36] <gema_> yep
[10:36] <didrocks> thanks gema_, xnox!
[10:36] <didrocks> keep me posted
[10:36] <gema_> will do
[10:36] <xnox> gema_: if people report VirtualBox issue, they should also report virtual box version numbers (proprietary vs opensource edition) (from ubuntu archive vs from oracle)
[10:36] <xnox> and also if it is reproducible in KVM or not.
[10:36] <gema_> xnox: ok, we'll need to train them to do that
[10:37] <psivaa> didrocks: i tried with virt manager and it happens in every live session, bug 1086036
[10:37] <ubot2> Launchpad bug 1060327 in compiz (Ubuntu) "duplicate for #1086036 compiz crashed with SIGSEGV in compiz::opengl::bindTexImageGLX() from TfpTexture::bindTexImage() from ... from GLTexture::bindPixmapToTexture() from DecorTexture::DecorTexture()" [High,Confirmed] https://launchpad.net/bugs/1060327
[10:37] <xnox> gema_: it is better for them to stop using VirtualBox and instead use virt-manager - a graphical interface for kvm which is similar if not better than virtualbox.
[10:37] <gema_> xnox: Virtualbox is not going to go away
[10:37] <didrocks> psivaa: ok, that's more interesting, and it's raring only? not quantal?
[10:37] <gema_> xnox: until we decide to stop supporting it
[10:38] <psivaa> didrocks: only raring
[10:38] <didrocks> interesting, as unity raring is (until today) the exact same than unity quantal
[10:38] <didrocks> so maybe a rdepends is triggering this
[10:40] <didrocks> psivaa: do you have the setup ready?
[10:40] <didrocks> psivaa: like, can you update from a ppa and start again the vm?
[10:41] <psivaa> didrocks: this is during the live session, so i could try that
[10:41] <didrocks> psivaa: excellent, please install ~ubuntu-unity/daily-build ppa, which is going to land in raring later on (first real unity version in raring)
[10:42] <didrocks> psivaa: at least, we'll know if the issue still exists, as compiz changed quite a lot
[10:43] <didrocks> popey: Mirv: the ppa is updated with what should land soon, if you want to test it… :)
[10:43] <popey> roger roger
[10:57] <cjwatson> xnox: regressions are regressions, virtualbox or not
[10:57] <cjwatson> I'd be very wary of saying "oh, it's virtualbox, screw it" without very careful evidence to demonstrate that it isn't something that affects real hardware too
[11:01] <xnox> cjwatson: ok.
[11:19] <popey> xnox, also worth noting virtualbox supports hardware 3d passthrough, so users can actually use Unity without going via LLVM. I don't believe kvm does this?
[11:20] <xnox> popey: ok. I shall try to set that up on my machine. Will it work with intel graphics? I guess I will find out =)
[11:21] <popey> yes
[11:21] <popey> I am using ubuntu 12.04, 12.10 and raring in virtualbox
[11:21] <popey> (on i7, HD2000 GPU)
[11:23] <cjwatson> FWIW last I checked 3D passthrough was only in the proprietary edition
[11:24] <cjwatson> Certainly a good reason somebody might use it though
[11:29] <doko> infinity, bad boy
[11:38] <infinity> doko: ?
[11:46] <doko> infinity, no, it's hrw
[11:47] <infinity> Oh.  Yeah.
[11:50] <doko> infinity, so it looks like the armhf-armel packages are always empty. did something change how stubs-hard and stubs-soft are generated? currently I can only see stubs-hard.h
[11:52] <infinity> doko: stubs-hard is in libc6-dev:armhf and stubs-soft is in libc6-dev-armel:armhf
[11:52] <infinity> doko: They didn't used to be split out at all, pre-2.16
[11:53] <infinity> (As in, there used to just be one stubs.h that had code for both)
[11:53] <doko> bah, http://packages.ubuntu.com/ can't search armhf
[11:53] <infinity> Nope, I've complained to Rhonda recently about that.
[11:53] <infinity> It may change.
[11:55]  * infinity wonders idly if this cross-built apache2 of his will actually run.
[12:08] <psivaa> didrocks: i could not verify the ppa in the live session, tried with persistence but rebooting the VM in KVM does not go back to the live session, even though the boot order is correct and the dvd with the iso is the first one on the list. tried to 'sudo restart lightdm' after the ppa installation but that command just hangs and i do not see anything happening
[12:20] <Mirv> nothing weirds noticed with the new PPA versions either
[12:46] <rtg> infinity, tsk, tsk. linux-meta-nexus7 has a git repo
[12:47] <infinity> rtg: Tsk, tsk, I can't commit to it. :P
[12:47] <rtg> infinity, you're not supposed to. How about sending me a patch ?
[12:47] <infinity> rtg: Thanks in advance for merging without complaining about my not committing somewhere that I can't commit.
[12:48] <infinity> rtg: http://launchpadlibrarian.net/124931118/linux-meta-nexus7_3.1.10.8.12_3.1.10.8.13.diff.gz
[12:48] <infinity> rtg: Enjoy. :)
[12:48] <ogra-cb> rtg, i have a config patch for the image package
[12:52] <diwic> Hi, I could use some advice on how to get a SRU through. The SRU fixes bugs that currently block hardware certification for some devices.
[12:52] <xnox> psivaa: usually: stop lightdm; stop ubiquity; pkill -9 X; start lightdm; all as root should be able to "restart" the graphical session for you after installing / changing packages.
[12:52] <diwic> I uploaded Pulseaudio almost a month ago and nothing happened; however, during this month more bugs have shown up so I should do another upload before it's accepted
[12:54] <diwic> However, if I do that, I'm afraid I'll get last in queue again and have to wait another month.
[12:55] <seb128> slangasek, infinity, ScottK, bdmurray, SpamapS, RAOF: ^
[12:55] <seb128> diwic, if you have a new upload to replace the currently waiting just get it in, it will not "reset the counter"
[12:56] <infinity> diwic: Upload a new one, use -vold_old_version to generate a sane changelog that included both, and ping me.
[12:56] <seb128> but what infinity said, merge both entries or use -v
[12:56] <diwic> infinity, should the new upload have the same version as the old one?
[12:58] <infinity> diwic: Oh, either option is fine.  Re-use, or -v to catch both.  Don't care.
[12:59] <diwic> ok
[12:59] <diwic> I'll go and prepare another upload
[12:59] <diwic> thanks
[13:18] <psivaa> xnox: thanks, pkill -9 X alone brings up the live session properly even without installing the unity daily ppa
[13:20] <xnox> psivaa: ;-)
[14:01] <cjwatson> gema_: phew, that was an obscure bug
[14:02] <gema_> cjwatson: did you fix it already!?
[14:02] <gema_> cjwatson: thanks a lot!
[14:02] <cjwatson> Just preparing an upload now
[14:02] <cjwatson> It may take a little while to reach images as ubiquity is one of the packages frozen for the community image milestone
[14:03] <ScottK> Speaking of which ...
[14:03] <gema_> cjwatson: ack, no problems, thanks a lot for this :D
[14:04] <ScottK> cjwatson: Now that it's not incredibly late, did you have in mind a way to get a list of packages to freeze?
[14:04] <cjwatson> ScottK: Oh, huh.  I thought you'd frozen already.  Isn't it a bit late now?
[14:04] <cjwatson> I mean, not for me, but for it to be useful
[14:04] <ScottK> No, we were going to block transitions today and respin.
[14:05] <ScottK> Since it's just Kubuntu images it's not that big of a deal to retest.
[14:05] <ScottK> Ideally we'd have done it earlier, but this is the first time and all ...
[14:06] <ScottK> I was playing with germinate last night, but didn't get anywhere since I couldn't figure out how to use -c to get it to use both main and universe at the same time.
[14:07] <cjwatson> -c main,universe - but I think it'd be better to use the .manifest and .list files from the images
[14:07] <ScottK> Ah.  That's one option I didn't try.
[14:07]  * xnox thought edubuntu & kubuntu are releasing and hence the set of frozen packages is larger.
[14:08] <xnox> well "to be frozen"
[14:08] <ScottK> It's up to Edubuntu if they want a freeze or not.
[14:08] <ScottK> IIRC, stgraber said they weren't going to respin, so there was no need for a freeze for their stuff.
[14:09] <cjwatson> join -j1 -o2.2 <(sort -u list-of-binary-packages) <(grep-aptavail -nsPackage,Source:Package '' | perl -ple '$_ .= " " . <>; chomp; <>' | sort -u)
[14:09] <cjwatson> Should be close enough
[14:09] <cjwatson> .oO( SQL in shell )
[14:10] <cjwatson> Might miss packages that don't exist on the architecture you're running on
[14:11]  * xnox is impressed. But questions perl's ability to do sort -u?
[14:11] <cjwatson> It could but then you can't use -p which is handy
[14:11] <xnox> ah
[14:12] <highvoltage> xnox, ScottK: yep, edubuntu has some release-critical bugs for alpha-1 but it doesn't seem necessary to block an alpha release because of them. people who want something more feature complete and without sever bugs can wait for the beta :)
[14:24] <diwic> infinity, okay, a new upload is now in the queue
[14:24] <infinity> highvoltage: I think you just summed up everything I dislike about actually releasing alphas there.
[14:25] <stgraber> ScottK: so I caught up on the highlights but not on the rest of the log. Did you push your britney hints to the branch already?
[14:25] <ScottK> stgraber: No.
[14:25] <ScottK> I'm sorting out the list now.
[14:25] <stgraber> ok
[14:26] <infinity> ScottK: I guess this would be a bad time for me to push a new d-i and kernels? ;)
[14:35] <ScottK> stgraber: Pushed.
[14:35] <ScottK> I'd appreciate it if someone would check it please.
[14:36] <ScottK> infinity: It's probably OK.  I think my block hits faster than the buildds get that ready to transition.
[14:36] <cjwatson> Hints are updated at the start of every britney run
[14:36] <ScottK> stgraber: Once we've confirmed that works, would you please respin the Kubuntu images.
[14:37] <cjwatson> It looks plausible at a very cursory glance
[14:38] <didrocks> cjwatson: hey, you maybe have seen we just had our first automated daily process (but with manual testing, autopilot not being ready yet) unity stack release.
[14:38] <didrocks> cjwatson: we had some new (renaming) source packge which went through NEW
[14:38] <didrocks> like unity-scope-gdrive
[14:38] <didrocks> but nux bumped its soname and is now nux4
[14:38] <didrocks> the binary package didn't seem to go in the NEW queue
[14:39] <didrocks> (fortunately, I asked a beforehand review from the ppa itself to seb128)
[14:39] <didrocks> any idea if I either use a wrong copy argument or if there is indeed a bug?
[14:39] <ScottK> cjwatson: For Alpha 1, I'll settle for plausible.
[14:41] <ScottK> stgraber: Since my block is in place, would you please respin Kubuntu.
[14:41] <infinity> didrocks: copies don't hit binary NEW, this is true.  And mildly problematic in this case, perhaps.
[14:42] <didrocks> infinity: ah, well, when we have packaging changes, the publisher is stopped for a manual review
[14:42] <cjwatson> I think I remember vacillating about that when implementing --auto-approve
[14:42] <didrocks> infinity: so at least, we won't copy without noticying
[14:42] <didrocks> but then, you can just count on people having the credential following the process
[14:42] <stgraber> ScottK: sure
[14:43] <stgraber> ScottK: running
[14:43] <cjwatson> I believe I settled for auto-approve bypassing NEW because that way it was convenient for Debian auto-syncs
[14:43] <didrocks> (which I think, I did proove more than once ;) but I would prefer it to be enforced)
[14:43] <ScottK> Thanks.
[14:43] <didrocks> yeah, I understand
[14:44] <didrocks> should I just note that on the doc and we rely on people pushing the manual trigger when there is a packaging change?
[14:44] <didrocks> in*
[14:44] <infinity> cjwatson: Yeah, the problem isn't necessarily bypassing NEW (although, if this sort of automated copying happens more, I'm a bit irked by it bypassing ftpmaster checks), but that the overrides will be wrong by default.
[14:45] <cjwatson> And I think that's an independent bug
[14:45] <ScottK> stgraber: Do you think the block is worth a mail to u-d-a?
[14:45] <cjwatson> I think it is.
[14:46] <cjwatson> If only because it's new information that we can do this without affecting people's ability to upload.
[14:46] <ScottK> OK.
[14:46]  * ScottK writes
[14:46] <stgraber> ScottK: I'm actually 90% done writing an e-mail to u-d-a :)
[14:47]  * ScottK stops writing.
[14:47] <ScottK> Thanks.
[14:50] <stgraber> ScottK: did I miss something? http://paste.ubuntu.com/1412595/
[14:51] <ScottK> I think it's fine.
[14:51] <ScottK> stgraber: ^^^
[14:51] <stgraber> alright, sent
[14:52] <stgraber> cjwatson: can you accept it in u-d-a's moderation queue?
[14:54] <cjwatson> stgraber: done
[14:56] <didrocks> cjwatson: about those auto-accepted binaries, they are landing in main or universe?
[14:56] <stgraber> cjwatson: thanks
[14:56] <cjwatson> didrocks: As infinity says, there's a bug in default overrides, so we'll probably need to fix that
[14:56] <infinity> Yeah, it's filed.
[14:57] <didrocks> ok, I'll do a manual promote then
[14:57] <cjwatson> I'm doing it
[14:57] <didrocks> I thought about override as "bypassing"
[14:57] <didrocks> ok, thanks cjwatson :)
[14:57] <cjwatson> done
[14:58] <cjwatson> hopefully it won't go wrong again on copy to release
[14:58] <infinity> https://bugs.launchpad.net/launchpad/+bug/1079577
[14:58] <ubot2> Launchpad bug 1079577 in Launchpad itself "Copies with binaries don't correctly override NEW binaries" [High,Triaged]
[14:58] <infinity> Which may or may not be more than one bug.
[14:58] <didrocks> thanks
[14:58] <stgraber> cjwatson: you'll be happy to hear that today's precise image boots on SB :)
[14:58] <infinity> stgraber: \o/
[14:59] <stgraber> I'm now testing that it installs and boots, hoping to be done before the team meeting :)
[15:00] <cjwatson> stgraber: HOORAY
[15:00] <cjwatson> "happy" doesn't really cover it, that's a huge relief
[15:05]  * stgraber really needs to fix queuebot to better deal with disabled products :)
[15:22] <stgraber> cjwatson: so, I can boot the media, install but not quite boot post-install... sorry :(
[15:23] <stgraber> checking what's wrong now
[15:23] <stgraber> ok, so the reason why I can boot is because the efibootmgr entry doesn't point to the shim...
[15:23] <stgraber> Boot0018* ubuntu	HD(1,800,2f000,fe060401-4d67-4ea8-8f0d-0f5910471a15)File(\EFI\ubuntu\grubx64.efi)
[15:25] <stgraber> cjwatson: installer syslog: http://paste.ubuntu.com/1412670/
[15:27] <cjwatson> stgraber: is shim in \EFI\ubuntu\ at all?
[15:27] <stgraber> cjwatson: yep
[15:29] <cjwatson> Hm, curious
[15:30] <stgraber> looking at the log, the signed grub and shim are clearly installed but for some reason the wrong efibootmgr entry is written, then ubiquity removes linux-signed-generic-lts-quantal
[15:31] <stgraber> one thing that may have confused the scripts is that it's on my laptop where I already have a working secureboot raring installation on the internal disk. The precise installation was done from a USB stick to another USB stick but sharing the efi partition on my internal disk with the raring install
[15:54] <didrocks> cjwatson: did you handle also the unity-scope-gdrive migration to main? (it's the unity-scope-gdocs code, just a source package rename)
[16:00] <cjwatson> didrocks: No, I didn't touch it
[16:00] <didrocks> should I? just don't want to conflict when it will migrate to main :)
[16:00] <cjwatson> Be my guest
[16:00] <didrocks> ok, doing :)
[16:24] <didrocks> cjwatson: last question before I stop bothering you, I'm looking at the proposed migration and it seems it's failing in some way for the unity stack, but I'm quite unsure about how to read the log :)
[16:25] <cjwatson> didrocks: looking (modulo meeting)
[16:25] <ogra_> didrocks, left to right, top to bottom :P
[16:26] <didrocks> ogra_: ah, that explains why… oh wait! :-)
[16:26] <cjwatson> didrocks: Why does bamf-dbg depend on both libbamf0 and libbamf3-0?
[16:26] <ogra_> :)
[16:27] <cjwatson> didrocks: Also, ginn needs to be rebuilt against (or ported to) libbamf3-0
[16:27] <ScottK> Also, should I expect the block to show up on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt ?
[16:27] <cjwatson> ScottK: excuses
[16:27] <ScottK> Thanks
[16:27] <cjwatson> And I do see it there
[16:27] <didrocks> cjwatson: waow, indeed, not sure as those libbamf0 renaming came from debian, maybe a wrong merge, I can fix it directly
[16:28] <cjwatson> didrocks: those are the two problems blocking migration AFAICS
[16:28] <didrocks> ok, let me see for ginn
[16:28] <didrocks> thanks for the hint cjwatson :)
[16:28] <ScottK> OK.  I can see the block is working.
[16:41] <stgraber> cjwatson: do you have enough information to debug that efi weirdness or do I need to extract something else before I fix my laptop to work again with SB?
[16:43] <ScottK> It turns out the block is incomplete, but I'm not going to worry about it for Alpha 1.
[16:43] <cjwatson> stgraber: I'm currently baffled but I can probably make some progress given that plus more coffee, so go ahead and restore
[16:45] <slangasek> hmm, what's the efi weirdness now?
[16:45] <stgraber> slangasek: even though I install under secureboot, the grub scripts somehow decide to use grubx64.efi instead of the shim
[16:46] <stgraber> so I end up with a system where shim-signed and grub2-signed are installed but the efibootmgr entry points to grub directly
[16:47] <slangasek> mmk
[16:48] <cjwatson> grub-install bug - ${source_dir} isn't set
[16:48] <cjwatson> i.e. misbackport
[16:48] <cjwatson> doesn't explain why linux-signed-generic-lts-quantal gets removed
[16:58] <xnox> stgraber: I remember you were requesting "static efi secure boot image validation". Currently that is run in jenkins and fails because of s/vmlinuz/vmlinuz.efi/
[16:58] <xnox> stgraber: was there a irc log of all the things you were asking to be checked for? cause we can feed it to the smoke testing jenkins job.
[17:01] <stgraber> 16:12 < stgraber> cjwatson: well, at least we have a pretty comprehensive list of things that can go wrong with SB images ;) I'm almost tempted to write a testing script checking that the partition table is correct, that the fs structure is fine for EFI, that shim and grub exist and are signed, that grub.cfg looks right and that vmlinuz is signed. If all of those match, it's pretty sure it'll at least boot (install is a whole other proble
[17:01] <stgraber> xnox: ^
[17:01] <cjwatson> If somebody wants to review that grub2, that should be half of stgraber's problem
[17:02] <cjwatson> Only touches grub-install so shouldn't need a new grub2-signed
[17:05] <cjwatson> The removal of linux-signed-generic-lts-quantal is perplexing, and we need to fix it, but I don't think it should break booting because it's just the metapackage
[17:05] <cjwatson> (It'll break future upgrades instead)
[17:06] <xnox> stgraber: thanks, I'll try to work on those bits.
[17:10] <infinity> cjwatson: At which point is the metapackage being removed?
[17:10] <infinity> By the "I guess you don't need a signed kernel" logic?
[17:16] <cjwatson> infinity: It's actually more that it isn't being specifically kept (because it's in the live part of the squashfs manifest)
[17:17] <cjwatson> infinity: I think check-kernels is getting confused by the -lts-quantal suffix.  Tedious rather than complex as such.
[17:17] <infinity> Ahh.
[17:17] <cjwatson> infinity: Go work with pinky on sulfur, sounds like he's making progress :)
[17:17] <infinity> He is?
[17:17] <cjwatson> #is
[17:18] <cjwatson> I've apparently forgotten most of what I know about rescuing powerpc boot failures, but at least it gets somewhere interesting now
[17:19] <infinity> Dangit, if he'd just waited longer on the udev spam, it would have eventually let him in.
[17:39] <phillw> Hi, a bit of a n00b Q, I know! When  I cannot get a crash report to send the details, which files do I manually upload to the manually opened bug report on lp? (A link to wiki with list is fine).
[17:44] <infinity> phillw: You could just file it with apport-bug /path/to/.crash
[17:45] <infinity> phillw: Or if you've already filed a bug, "apport-collect 12345" (for the bug number)
[17:45] <phillw> infinity: it's a KVM instance. and is dying with ubiquity. I can use guestfs to pull files from it, but not much more.
[17:46] <infinity> syslog is a good start.
[17:47] <phillw> shall i pull /var onto my local machine?
[17:48] <xnox> phillw: /var/log
[17:49] <phillw> xnox: thanks, I'm just installing guestfs onto my machine
[18:05] <SpamapS> Is there a reason php5 hasn't moved out of raring-proposed ?
[18:05] <SpamapS> Its compiled on all arches.. and I don't see any installability issues.
[18:07] <xnox> SpamapS: trying: php5
[18:07] <xnox> skipped: php5 (57 <- 25)
[18:07] <xnox>     got: 107+0: i-107
[18:07] <xnox>     * i386: php5-suhosin
[18:07] <xnox> SpamapS: so php5-suhosin becomes uninstallable if php5 is upgraded.
[18:08] <xnox> SpamapS: http://people.canonical.com/~ubuntu-archive/proposed-migration/
[18:08] <ScottK> Self service at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
[18:08] <SpamapS> ahh .. http://people.canonical.com/~ubuntu-archive/testing/raring_probs.html .. is that not up to date?
[18:08] <xnox> SpamapS: that looks at raring-release, not raring-proposed nor the mix of the two yet.
[18:08] <micahg> http://people.canonical.com/~ubuntu-archive/testing/raring-proposed_probs.html
[18:09] <SpamapS> AHH
[18:09] <xnox> SpamapS: so britney telss you when/why it's not migrating a package and that's more canonical way to check why something is not migrating.
[18:09]  * ScottK wonders if xnox was punning.
[18:09] <xnox> micahg: Ooohhh we have that now =)
[18:09] <SpamapS> ok, looks like php5-suhosin will need another rebuild
[18:10] <ScottK> Right, but it doesn't actually answer SpamapS' question.
[18:10] <micahg> excuses page said it's a valid candidate...
[18:11] <infinity> micahg: excuses saying "valid candidate" means "and thus, I shall try and see if it fits!"
[18:12] <infinity> micahg: Basically, it means is passed the "is it build" and "are there any blocks" tests, etc.
[18:12] <infinity> Then it actually tries the complex upgrade bits.
[18:12] <infinity> And that's _output.
[18:12] <cjwatson> xnox: We've had it since roughly when raring opened
[18:12] <micahg> infinity: right, I'm one step behind since I haven't dug into this yet :)
[18:12] <infinity> micahg: excuses and output aren't actually two views of the same thing, rather, excuses is the first stage, and output the second.
[18:12] <micahg> (this being britney mimgrations)
[18:13] <ScottK> Yes
[18:13] <cjwatson> Excuses is package-local, output is global.
[18:14] <infinity> cjwatson: Right, but if something isn't a valid candidate, according to excuses, it'll never hit the global try/pass/fail in output.
[18:14] <infinity> (Which was what I was trying to get across with the "two stages" bit)
[18:14] <cjwatson> Indeed.
[18:14] <ScottK> Right and the stages are: 1 local 2 global
[18:15] <infinity> Heh.
[18:15] <infinity> Ed Zachary.
[18:15] <infinity> So, is breakfast still breakfast when you've been up since 6pm the previous evening?
[18:16]  * infinity decides to go cook some and find out.
[18:18] <micahg> infinity: if you've not been eating since then, certainly :)
[18:20] <plars> xnox: I'm looking at https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1086036 and would like to improve the title so that it's clear that we're not talking about the 2 month old compiz bug that it was duped to earlier. do you happen to know what the thing is called that comes up to ask if you want to go into live session or the installer? is that part of ubiquity?
[18:20] <ubot2> Launchpad bug 1086036 in compiz (Ubuntu) "Compiz crashes when booting to raring live session" [Undecided,New]
[18:20] <plars> I'm currently thinking that the compiz crash may or may not even be related to the real problem described here
[18:21] <xnox> plars: so ubuntu desktop CD's boot into "ubiquity-dm" session which presents ubiquity in the greeter mode aka "Try or Install Ubuntu" screen.
[18:22] <xnox> plars: so something like "compiz driven ubiquity-dm crashes in raring daily" is a reasonable title or something else you can think off.
[18:23] <xnox> ... but did not under metacity.
[18:23] <plars> xnox: because one of the other things we've noticed is that if you hit a key at the boot screen and choose boot to live session, it goes into the live session fine, but if you choose install ubuntu, it seems to give us something similar to what we see here (top bar only, no installer)
[18:23] <plars> xnox: ah, so there was a change from metacity to compiz here recently?
[18:23] <xnox> plars: correct. So "install only" mode is also running under a "ubuntu-dm" session.
[18:24] <xnox> plars: yes, there was. See the email to ubuntu-devel announcing this.
[18:24] <SpamapS> [6~[6~[6~[6~[6~/win 99
[18:24] <SpamapS> curse you lag
[18:24] <xnox> plars: I have tested it across all hardware I had available and the idea is that live-cd should gracefully use 3D accelaration or fallback to LLVM Pipe rendering.
[18:25] <plars> xnox: ok, that's about the same timeframe for that change and when I'm seeing it that it quit working
[18:25] <xnox> plars: if this experiment doesn't work out well, we can seed metacity back on to the desktop CDs, but keep using compiz on nexus7 images (e.g. controlled environment / hard ware where we know it works correctly)
[18:26] <plars> xnox: that's sheds some light on this for me, thanks
[18:26] <xnox> plars: So it can be easily tested: stop lightdm; stop ubiquity; pkill -9 X; apt-get install metacity; start ubiquity
[18:26] <xnox> if that works you know it's compiz fault.
[18:26] <xnox> Ideally I want compiz to work out of the box for the installer on all hardware, because this is requirement to run the installed system after all.
[18:28] <plars> xnox: well, it *does* seem to run once we get it installed, just not for the ubuntu-dm session
[18:29] <SpamapS> so, I think php-suhosin probably needs to be removed
[18:30] <xnox> plars: interesting. Somebody with compiz skills should debug this then. Does it work on the installed system, due to installing & activating extra graphics drivers?
[18:30] <xnox> plars: didrocks was pinged about it earlier.
[18:31] <plars> xnox: also, I think psivaa already did some of this testing this morning, but even just killing X and restarting lightdm worked on it's own
[18:31] <plars> without installing metacity
[18:31] <xnox> 8) sounds racy.
[18:31] <plars> indeed
[18:32] <xnox> plars: coincidently ogra_ was reporting race condition between compiz & onboard with subsequent boot working out better for onboard.
[18:32] <xnox> (that's on nexus7)
[18:32] <xnox> interesting.
[19:17] <stgraber> pgraner, slangasek, ScottK, highvoltage: Initial draft of the announcement: http://pad.ubuntu.com/raring-alpha1-announcement
[19:18] <ScottK> Riddell: ^^^
[19:19] <highvoltage> stgraber: I'm going to make some slight yet liberal changes to that
[19:20] <ScottK> stgraber: It's a bit difficult to get this just right since Ubuntu is a: a free software project, b: a Linux distribution, c: a desktop OS that you get when install "Ubuntu", d: all of the above.
[19:20] <highvoltage> ah I see you changed the URL so long, thanks
[19:21] <highvoltage> ScottK: yeah hence my small change there too :)
[19:23] <highvoltage> stgraber: I just realised that we don't actually link to any iso image from the release announcement, should I just link to the daily build we used or is there special logic somehow that preserves that iso somewhere?
[19:26] <ScottK> That's one thing he has to do as it still requires Canonical powerz.
[19:26] <ScottK> infinity: http://pad.ubuntu.com/raring-alpha1-announcement <-- I added a paragraph about not reporting old bugs for you.
[19:27] <ScottK> stgraber: What do you think about the pargraph I added?
[19:30] <stgraber> highvoltage: use the same link I put on the pad (the /alpha-1/ thing)
[19:31] <stgraber> ScottK: looking
[19:31] <ScottK> Thanks.
[19:32] <infinity> ScottK: You seem to be having problems Englishing. :)
[19:32] <ScottK> Did I?
[19:33] <infinity> should identified in the Alpha 1 installer should be
[19:33] <ScottK> Ah.
[19:33] <infinity> But thanks for that.
[19:33] <ScottK> Anyway, trying to address your golden image concerns at least a bit.
[19:33] <infinity> Sadly, we'll see people keep using Alpha1 images to install from for a long while.
[19:33] <ScottK> Sure.
[19:34] <infinity> Hopefully they're not full of annoying installer bugs that keep dominating errors.u.c. :P
[19:34] <ScottK> Not so far, althought I may have just found one.
[19:34] <infinity> (Which is what we saw last cycle... Tons of ancient ubiquity bugs drowning the signal in noise)
[19:35] <stgraber> infinity: well, people like using obsolete stuff, I'm still regularly getting e-mails from people who want to install Feisty (not sure why but Feisty seems rather popular for Edubuntu...) and wonder where to find packages for it...
[19:35] <infinity> Which is one of the reasons why I've argued that, even if people want to do the alpha-style freeze/test week, maybe publishing the final images isn't actually a net positive.
[19:36] <infinity> stgraber: Feisty?  Wow.  Impressive.
[19:36] <highvoltage> infinity: sounds like something that needs to be fixed with the error reporting mechanism
[19:36] <infinity> highvoltage: It does reasonable version tracking.  But we *want* the stats on old versions that are in use, it's just annoying when they're the top crashers because no one uses the newer versions.
[19:37] <stgraber> infinity: I think someone made some kind of Edubuntu based appliance using Feisty, then never updated their stuff and the company disappeared a few years back, so apparently entire school districts now run Feisty + a ton of custom packages and have no upgrade path :)
[19:37] <ScottK> Feisty was a good release.
[19:37] <infinity> stgraber: Oh fun. :/
[19:37] <stgraber> ScottK: looks good. I spotted the same problem as infinity and dropped a couple of words from your paragraph to make it more parsable
[19:38] <ScottK> Thanks.
[19:38] <infinity> stgraber: If we could actually identify this particular appliance and userbase, there may be some money in this for a consulting company (or Canonical) to help provide them a solid and safe upgrade path.
[19:38] <highvoltage> My mother ran Feisty for around 4.5 years and it just kept going
[19:39] <infinity> highvoltage: Heh.  I ran woody for around 8 years before I decided that was a really stupid idea.
[19:39] <tumbleweed> it was the stable release for aronud that long, though :P
[19:39] <slangasek> lies :P
[19:39] <highvoltage>   sheesh, and woody was already kind of old when it was released
[19:40] <infinity> Give or take five years.
[19:40] <stgraber> I've been running woody for a long time too as for some reason I never quite liked sarge so didn't want to update anything to it, probably not 8 years though
[19:40] <highvoltage> it was the first debian release I tried on my laptop and gnome 1.2 just hurt my eyes too much
[19:41] <highvoltage> (now gnome 3.6 hurts my eyes, I guess I've gone full circle)
[19:53] <pgraner> stgraber, I made a few small edits but it looks great.
[19:58] <seb128> hey
[19:58] <seb128> I'm looking at https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule ... is DesktopInfrastructureFreeze the point where things need to be uploaded or be approved?
[19:58] <seb128> wondering if the SRU team backlog is going to be an issue there...
[19:59] <infinity> seb128: We'll clear it out by then, but if not, ping about specific things that need to make the freeze.  Not every SRU does.  Some clearly do (enablement stack stuff).
[20:00] <infinity> seb128: I'm hoping the curious combination of "most people will be on holidays for a few weeks and not uploading" and "lots of the SRU team members are silly workaholics who work on their holidays anyway" will help catch us right up. :P
[20:00] <seb128> infinity, so you are saying that the SRU team commit in having everything which is currently in the team approved (or at least not reject because the SRU team didn't get to do reviews on time)?
[20:01] <seb128> doh
[20:01] <seb128> which is currently in the *queue*
[20:01] <seb128> infinity, I'm starting to worry that the month backlog is going to create issues
[20:01] <infinity> seb128: That sentence didn't English very well, but I'm not saying we're committing to clearing the queue entirely, but that we'll clear what's deemed necessary.  And if we miss something on that list, let us know. :P
[20:02] <infinity> seb128: While, ideally, we'll clear the queue (and I'd like to), not all SRUs *need* to be on the .2 disc.  Some of them obviously HAVE to be.
[20:02] <seb128> infinity, sorry about my french, it's 9pm and it has been a long day :p
[20:02] <seb128> infinity, should I start lobbying today for things I want to get reviewed?
[20:02] <infinity> seb128: I'm going to throw my shoulder at the queue a few times over the next week to see how far down I can get it, FWIW.
[20:02] <seb128> infinity, or should I give you guys some slack and start complaining about things still not reviewed after holidays?
[20:03] <infinity> seb128: Complain early January, if things still suck.  And pick your battles carefully, cause if you just complain about "everything in the queue", we'll have to have some cultural misunderstandings. ;)
[20:04] <infinity> seb128: In the week before that freeze, we should be able to push through anything that's urgent and got missed.
[20:05] <seb128> infinity, thanks
[20:45] <SpamapS> FYI, https://bugs.launchpad.net/ubuntu/+source/php-suhosin/+bug/1086984 ... probably time to drop php-suhosin
[20:45] <ubot2> Launchpad bug 1086984 in php-suhosin (Ubuntu) "Should Drop php-suhosin from Ubuntu" [Critical,New]
[20:49] <ScottK> Yeah.
[20:52] <ScottK> SpamapS: Gone
[20:55] <slangasek> cjwatson: do you have any idea why this command would only be copying the i386 binary, not the amd64 binary?: copy-package -j -b -s precise --to-suite quantal gstreamer0.10-fluendo-plugins-partner
[20:55] <slangasek> oh, n/m
[20:55] <slangasek> cjwatson: it's because there are separate source packages for the upstream binary drops, ignore me :)
[20:58] <phillw> If there is a potential fix to an issue in debian/unstable for a bug (i.e. a newer release), is there a way for me to pull it in & test it? https://bugs.launchpad.net/ubuntu/+source/libguestfs/+bug/1086974/comments/2
[20:58] <ubot2> Launchpad bug 1086974 in libguestfs (Ubuntu) "libguestfs: error: cannot find any suitable libguestfs supermin" [Undecided,New]
[20:59] <slangasek> speaking of gstreamer, is it planned to drop gst0.10 from the images for raring in favor of gst1.0?
[21:00] <slangasek> phillw: you can grab the source with pull-debian-source and build it yourself; or you can copy it to a ppa; but this is off topic for #ubuntu-release, perhaps #ubuntu-devel is better
[21:01] <seb128> slangasek, yes it is, we should be close from that
[21:01] <slangasek> seb128: ok, cool
[21:02] <seb128> slangasek, I just respinned discussion about partner/fluendo codecs as well since we are on the topic
[21:02] <seb128> just as a piece of information
[21:02] <slangasek> ugh, python-support on component-mismatches /again/?
[21:02] <slangasek> seb128: respinned discussion?
[21:03] <seb128> slangasek, there has been discussion between Canonical/fluendo before quantal since we were not sure if we going to follow GNOME (which went with gst1 in 3.6) or not
[21:03] <slangasek> seb128: ok
[21:03] <seb128> slangasek, those discussions sort of stopped when we decided to hold on the update for quantal
[21:04] <infinity> slangasek: Yeah, looks like someone's idea of "all deps are in main" didn't take build-deps into account.
[21:04] <seb128> so it's time to get that resolved ;-)
[21:04] <slangasek> infinity: hmph.  Is that because we're not providing people the right tools?
[21:04] <infinity> slangasek: I've already commented on the MIR bug.
[21:04] <slangasek> (to give them the correct answers)
[21:04] <slangasek> ok
[21:04] <infinity> slangasek: No, our tools are fine.  That doesn't mean people use them.
[21:04] <slangasek> seb128: right, that's why the question comes up :)
[21:04] <slangasek> infinity: which tool?
[21:05] <slangasek> I can't tell you what tool I'd even use for this
[21:05] <slangasek> so I'm not surprised if $random_mir_submitter doesn't use it
[21:05] <infinity> Oh, actually, hrm.  There may not be a simple tool to check maininess of rdeps.
[21:05] <infinity> slangasek: I'm not surprised when mir_submitters miss this, I'm a bit more miffed when mir_reviewer does. :P
[21:06] <slangasek> also, promoting before uploading the thing that depends on it
[21:07] <infinity> Oh, is it not actually being used in main yet?  In that case, demote away.
[21:07] <SpamapS> ScottK: thanks!
[21:07] <infinity> Indeed, its only reverse-dep is rlvm.
[21:08] <infinity> slangasek: I'm going to demote it and reopen the MIR bug, unless you've beat me to it.
[21:08] <slangasek> infinity: beating you now
[21:08] <infinity> Alright.
[21:08] <infinity> And ow.
[21:29] <micahg> infinity: there's check-mir in ubuntu-dev-tools
[21:30] <infinity> So there is.
[21:30] <infinity> And it even works for google-mock.
[21:34] <slangasek> perhaps someone should point this tool out to the MIR team? :)
[21:50] <slangasek> "unar" - wtfbbq
[21:51] <infinity> ?
[21:51] <slangasek> c-m again
[21:51] <slangasek> file-roller has a new recommends on some tool that needs gnustep
[21:51] <infinity> There's... Something called unar?
[21:51] <cjwatson> it's like thunar but when you've been to the dentist
[21:51] <slangasek> that's what it's *called*
[21:51] <infinity> Oh, I see, a one-size-fits-all.
[21:53] <seb128> bdrung, ^
[21:54]  * cjwatson sees nux binaries fell into universe again - fixed
[21:57] <cjwatson> anyone know why farstream-0.2 was moved to main without its dependencies?  looks like it was deliberate but I can't find an MIR
[21:58] <infinity> Might have just started out in main because it was a new upstream of an already-main package.
[21:58] <infinity> (As in, I may have NEWed it that way, assuming it would be a build-dep ASAP, or fall out if not)
[21:59] <cjwatson> +publishinghistory said it was NEWed into universe and then moved to main.
[21:59] <infinity> Oh.  In that case, no idea.  It sounded like the sort of thing I'd do. :P
[22:00] <cjwatson> I think.  Unless it was a copy bug.
[22:00] <cjwatson> I'll move it back.
[22:01] <seb128> cjwatson, what infinity said
[22:01] <seb128> it's a new version of a package in main
[22:01] <seb128> it's part of the gst1
[22:01] <cjwatson> It's uninstallable in main.
[22:01] <seb128> transition
[22:01] <seb128> kubuntu is mixed in the farstream transition afaik
[22:01] <cjwatson> You can put it back if you fix that; after this publishing cycle though (to avoid triggering that long-standing LP bug).
[22:02] <seb128> Laney sent an email Ccing the kubuntu team about that
[22:02] <seb128> but he's on holidays this week
[22:02] <seb128> cjwatson, I think it has been kept off the transition because of kubuntu so it's fine to demote
[22:02] <seb128> but it will come back soon
[22:02] <cjwatson> I don't mind if it's promoted again as long as it's not showing up on uninstallability reports :-)
[22:02] <infinity> Sure, it's not kubuntu that was making it uninstallable, mind you, it was gst1.0
[22:02] <cjwatson> gstreamer1.0-nice, indeed
[22:02] <seb128> cjwatson, ok, fair enough ;-)
[22:03] <seb128> cjwatson, infinity: Laney wrote
[22:03] <seb128> "  * Kubuntu-ers again: There's a mini telepathy-farstream transition
[22:03] <seb128>     required (syncing the new version from experimental which has a new
[22:03] <seb128>     SONAME) for the gst 1.0 port. This is needed for Ubuntu for empathy,
[22:03] <seb128>     but you have kde-telepathy-call-ui libtelepathy-qt4-farstream2
[22:03] <seb128>     depending on it. ktp-call-ui explicitly depends on gstreamer0.10
[22:03] <cjwatson> I'd have promoted gstreamer1.0-nice if farstream-0.2 had been seeded anywhere
[22:03] <seb128>     stuff and FTBFS with the new telepathy-farstream (see attachment)."
[22:04] <cjwatson> As it is, I'd rather not cause component-mismatches to get any bigger with stuff we don't know why it's there or whether it can be moved to univere
[22:04] <cjwatson> +s
[22:04] <cjwatson> Investigating those is time-consuming
[22:04] <seb128> cjwatson, thanks, I will investigate that tomorrow but there is no hurry (as long as we are fine still having gst0.10 in mainà)
[22:05] <cjwatson> I don't care either way :-)  What I want is continuous consistency
[22:05] <seb128> right, all good then ;-)
[22:05] <infinity> cjwatson: Speaking of c-m.  Do you happen to remember the cause of the misfeature that wants to drag all the universe kernels in for their udebs?  I swore we had this in previous cycles and cleared it up somehow...
[22:06] <cjwatson> infinity: It might be a missing Provides in the primary kernel's kernel-image udeb on that arch
[22:07] <cjwatson> Our esteemed kernel team is sometimes lazy about those (probably because they don't realise they're actually useful)
[22:07] <infinity> Ahh, so probably a bug on all the primary kernels, but since ARM is the only arch with other kernels...
[22:07] <cjwatson> Well, it depends on config too
[22:08] <cjwatson> The general notion is that if a feature that's sometimes provided by *-modules udebs is instead built into the kernel, kernel-image ought to have "Provides: ext2-modules" or similar
[22:08] <bdrung> infinity: it's for extract RARv3 archives
[22:08] <cjwatson> It'll be either ext2-modules or fat-modules, I expect
[22:09] <bdrung> extracting RARv3 archives is a common use case
[22:10] <seb128> bdrung, file-roller is doint install-on-demand so that's not an issue
[22:10] <seb128> doing
[22:11] <seb128> bdrung, e.g it will prompt you to install utilities if those are needed
[22:11] <bdrung> seb128: it does not prompt you to install unar (it suggests unrar or rar instead)
[22:11] <seb128> oh, ok
[22:12] <infinity> unrar would work too, mind you.
[22:12] <infinity> (Except for the part where it's nonfree)
[22:12] <bdrung> infinity: unrar is non-free, but unar is free
[22:14] <ScottK> seb128: I think if you start an uncoordinated transition, that's not our fault that we didn't work it out at the same time.
[22:15] <seb128> ScottK, I don't think it's fair to say the transition was uncoordinated, it was discussed at UDS, prepared in a ppa and Laney sent emails Ccing the kubuntu list
[22:15] <seb128> ScottK, and there is no blaming, the transition is still ongoing, nobody is late or blocking anyone
[22:16] <seb128> ScottK, we just got some bits demoted because we didn't get to them yet which is fine
[22:18] <slangasek> bdrung: free but requires a crazy ObjC stack that we don't want in main
[22:19] <bdrung> hm
[22:22] <bdrung> i think it makes sense to have a rar extracter installed by default, but preferable without pulling ObjC in
[22:22] <seb128> bdrung, there is unrar-free...
[22:23] <bdrung> seb128: it does not support v3 files (which is what nearly all rar files use)
[22:23] <bdrung> v3 is 11 years old
[22:24] <seb128> hum, k
[22:24] <seb128> that's not something we got lot of complain about so far afaik
[22:24] <ScottK> seb128: Even better.  Ask questions.  Don't get responses and then upload anyway.
[22:24] <seb128> so I'm not sure how many people out there are using rar v3 and if install-on-demand is working for that usecase or not
[22:25] <ScottK> Kamoso is currently unbuildable, so there's no way this can go forward right now.
[22:25] <ScottK> (at least not without removals)
[22:25] <seb128> ScottK, even better, ask question, don't quest responses, get stucked for ever to not be able to move forward
[22:25] <infinity> Because the largest consumers of RAR are people splitting and distributing copyrighted material and they (a) don't like to file bugs about not being able to do that, and (b) have switched to torrents that don't need splitting.
[22:25] <seb128> quest->get
[22:26] <ScottK> The message is less than a week old.
[22:26] <seb128> right and as said there is no issue, the transition is ongoing
[22:26] <ScottK> We've been kind of busy getting KDE 4.10 beta 1/2 packaged and doing an Alpha
[22:26] <seb128> so the uploads didn't hurt
[22:26] <seb128> both versions are co-installable
[22:26] <seb128> it just means we have both on our iso
[22:26] <ScottK> OK, then don't complain about Kubuntu'ers and it's not done yet then.
[22:26] <seb128> which is fine
[22:27] <seb128> ScottK, sorry, I was more pointing at where we are than complaining
[22:27] <seb128> the current situation is not an issue
[22:27] <seb128> but reality is that we need kubuntu to move forward to finish the transition
[22:27] <ScottK> Sure.
[22:27] <seb128> no hurry though
[22:28] <ScottK> OK.  No worries then.
[22:29] <bdrung> infinity: RAR files are used for legal stuff, too (some friends use it and need to extract these files from time to time), but you probably describe the normal use case
[22:29] <seb128> cool, sorry for the confusion if there was any
[22:29] <infinity> bdrung: I did say the "largest consumers", not all of them.  I also realise in looking at my wording there that I may have implies that warez kiddies are overweight.
[22:29] <infinity> s/implies/implied/
[22:31]  * ScottK wonders if clamav can use unar.
[22:31] <bdrung> i would love to see someone port the algorithm from unar to libarchive
[22:31] <infinity> I've generally been happy with the assumption than an .rar attached to an email was a virus without opening it to look.
[22:31] <infinity> That assumption's not been wrong yet. :P
[22:36] <bdrung> infinity: a .rar attachment from an unknown person. a .rar attachment from an known person could be no spam.
[22:37] <infinity> bdrung: Sure, could be.  But no one I know has ever emailed me a rar, hence the assumption works for me, that's all.
[22:37]  * bdrung nods.
[22:53] <Riddell> stgraber: the announcement has no ringtail themed quote!
[22:53] <Riddell> that's essential for alpha 1
[22:54] <stgraber> Riddell: add one :)
[22:56] <Riddell> how about this one? PG Woodhouse: "Sir, that stolen lemur bit one of your prostitutes right in the face and she says she can't go to hospital because she's, quote, "tripping balls.""
[22:57] <Riddell> oh it's not pg woodhouse, that's no good then
[22:58] <Riddell> The Philosopher's Apprentice "I know the God hypothesis has its partisans, but, oh, what a boring idea. Where did the universe come from? He did it. How do we account for rivers and rocks and ring-tailed lemurs? He made them. Ho-hum. "  I like that one
[22:58] <slangasek> infinity: statistically speaking, warez kiddies don't exercise much
[22:59] <Riddell> "Krusty The Clown: Book that animal that always chomps on my groin. Secratary: Susan Anton? Krusty The Clown: No, the lemur."
[23:01] <phillw> Riddell: "The lifespan of the ring-tailed lemur is 20 years", slightly less than 13.04 :P
[23:03] <Riddell> I'm going with  "I am a ring-tailed roarer. I can draw faster, shoot straighter, ride  harder, and drink longer than any
[23:03] <Riddell> man alive. I'm the rip-snortinest cowboy that ever rode North, South, East or West of the Rio Grande."
[23:03] <Riddell>  - Pecos Bill, Tall Tale 1995
[23:07] <phillw> Riddell: I like that one... and look forward to the further quotations as we progress :)
[23:15]  * ScottK removes some passive voice from the draft announcement.