[00:00] <Riddell> cjwatson: any idea what went wrong with my ubiquity upload?
[00:00] <Riddell> http://starsky.19inch.net/~jr/tmp/ubiquity_2.13.14.dsc
[00:00] <Riddell> "Rejected:
[00:01] <Riddell> ubiquity 2.13.14 in raring (source has no binaries to be copied)"
[00:03] <xnox> Riddell: those ubiquity files need chmod +r  =) Forbidden at the moment.
[00:03] <xnox> Riddell: do you want me to try an upload?
[00:05] <Riddell> xnox: permissions changed
[00:05] <Riddell> xnox: yes that would be good
[00:05] <cjwatson> xnox: Eh, hang on
[00:06] <cjwatson> Let me investigate Riddell's failure first
[00:07] <cjwatson> That is a truly strange error
[00:07] <xnox> ok.
[00:10] <cjwatson> The question is why proposed-migration thought it was suitable to copy
[00:10] <cjwatson> Because it wasn't built yet
[00:11] <Riddell> I had a force on it
[00:11] <Riddell> could that have caused it to go early?
[00:12] <cjwatson> Yes, you broke it, please don't do that
[00:13] <cjwatson> Please in general don't force things unless there is no alternative
[00:13] <cjwatson> "I'm in a hurry" isn't a good enough reason
[00:13]  * cjwatson tries to work out if it is possible to clean up this mess
[00:14] <Riddell> how about "I want it in the beta"?
[00:14] <cjwatson> Not good enough
[00:14] <cjwatson> The only excuse for a force is that proposed-migration won't accept it due to some problem you've checked with other members of the release team first
[00:14] <cjwatson> They really need peer review
[00:15] <cjwatson> As it is, you *delayed* having this in the beta
[00:15] <xnox> Riddell: well "i want it in the beta" sure, but you didn't get it in beta, and instead powerpc & armhf have not build.
[00:15] <cjwatson> If you want to bypass the general freeze migration, use "unblock", never "force"
[00:16] <cjwatson> xnox: the latter *may* be fixable
[00:16] <xnox> interesting =) how?
[00:17] <cjwatson> I'll tell you if it works :)
[00:17] <Riddell> ah, sorry
[00:18]  * xnox is pondering if it's trigger a rebuild, or sneakily copy-binaries back into the archive.
[00:23] <cjwatson> No, unfortunately that didn't work.  I changed Riddell's hint to be unblock rather than force, then undeleted the packages from -proposed in the hope that I could then trigger a rebuild of armhf/powerpc and proposed-migration would copy it to release again when those were done.
[00:24] <cjwatson> However, that isn't enough to resurrect a SUPERSEDED build record.
[00:25] <cjwatson> It might be possible to recover this with DB surgery, but I'm not willing to attempt that when it isn't strictly necessary.  I suggest reuploading. :-(
[00:30] <slangasek> stgraber: libreoffice is currently blocked in -proposed; we ought to take the update, since it fixes coinstallability of language support
[00:30] <stgraber> slangasek: agreed
[00:30] <slangasek> stgraber: can you handle the unblock? (since you already have a hint file handy :)
[00:30] <stgraber> slangasek: yep, will do
[00:30] <slangasek> ta!
[00:33] <Riddell> cjwatson: I'll upload a new version then
[00:35] <cjwatson> Thanks
[00:36] <cjwatson> You'll need to bump the unblock version in your hint of course
[01:00] <phillw> cjwatson: I was under the mis-understanding that AMD64+Mac was bug 1153992, with that working for alternate (lubuntu) there is still no build for the AMD64+Mac. I'm sorry if I 'nag', but do you have any update on it?
[01:00] <ubot2> Launchpad bug 1153992 in Ubuntu CD Images "Raring server and precise d-i installations fail at the clock configuring step" [Critical,Fix released] https://launchpad.net/bugs/1153992
[01:17] <cjwatson> phillw: It's on the Raring Daily milestone.  As to why it's not on the Raring Beta 1 milestone on iso.qa, that would be something for you to discuss with stgraber.
[01:17] <cjwatson> phillw: The cdimage side of things appears to be working fine.
[01:18] <stgraber> phillw: that'd be because the product lead didn't ask for +mac to be on the manifest
[01:18] <phillw> cjwatson: thanks, I'll catch up with stgraber and ask him to mirror it over (I'm guessing it is due to this 'freeze' thingie :P )
[01:18] <cjwatson> phillw: 1153992 was indeed entirely unrelated to this matter.
[01:18] <stgraber> the manifest was generated from what was released in 12.10 and apparently you didn't have +mac back then
[01:18] <phillw> stgraber: he did not?
[01:19] <stgraber> or it wasn't addded to the manifest for 12.10 anyway
[01:19] <xnox> stgraber: yes, due to no lack/absence of +mac testers.
[01:19] <phillw> stgraber: https://help.ubuntu.com/community/Lubuntu/GetLubuntu
[01:19] <phillw> We did, as far as I can see?
[01:20] <phillw> xnox: we have a very dedicated +Mac tester, it was he who alerted me to the missing ISO.
[01:20] <stgraber> phillw: https://wiki.ubuntu.com/QuantalQuetzal/ReleaseManifest disagrees
[01:20] <stgraber> phillw: anyway, if you get gilir to ask for +mac, I'm happy to add it
[01:21] <phillw> stgraber: without wanting to start a row, http://cdimages.ubuntu.com/lubuntu/releases/quantal/release/ says we have.
[01:22] <cjwatson> That's a different matter.
[01:23] <cjwatson> Builds != releases
[01:23] <phillw> stgraber: I'm actually in the rare position of being able to ask for it :) I knew what he did to me would be handy one day...https://launchpad.net/~lubuntu-product-managers
[01:23] <cjwatson> Wait, that is a release, wtf
[01:24] <cjwatson> well, I suppose this is just one more way the old manifest scheme didn't work
[01:24] <phillw> cjwatson: you've lost me there. We had builds, we have had releases, what is the need to ask for it to be resurrected 3/4 the way through 13.04?
[01:24] <cjwatson> I'm on my phone, accuracy is optional
[01:25] <cjwatson> we should kill off the old manifest scheme ... oh wait, we did :)
[01:25] <stgraber> ;)
[01:26] <phillw> asides of that, can we please have the +Mac on the beta 1 testing area? Pretty please :D
[01:26] <cjwatson> I suspect that the tracker and the manifest got out of sync near the tail end of the 12.10 release and nobody noticed.
[01:27] <phillw> cjwatson: as I recall, we were still testing PPC stuff when you were moving them to 'final release'. It was some what of a crazy day :)
[01:27] <cjwatson> Or possibly I got confused while doing the publishing.
[01:28] <cjwatson> shrug
[01:28] <cjwatson> Not likely to be debuggable from this distance in time
[01:28] <phillw> cjwatson: heck, they all got out there and bug reports were what was in the release notes....
[01:28] <cjwatson> No release is perfect
[01:29] <phillw> if it were, you'd all be out of a job :)
[01:29] <stgraber> oh no, I'm sure we'd still have enough work even if the releasing process was perfect
[01:30] <phillw> stgraber: I was not referring to the release process, I was referring to what is released :P
[01:31] <phillw> But, I will leave you good people in peace. thank you, as always, for tolerating me on here :)
[01:36] <phillw> or maybe not... Have I used up my allotted time to ask about things?
[01:37] <phillw> I'll email it, as it something I cannot see an answer to as a bug.
[01:53] <phillw> stgraber: / cjwatson can you remove the notice "Respins upcoming for bug 1153992; will affect at least most server/alternate images." from http://iso.qa.ubuntu.com/ Thanks :)
[01:53] <ubot2> Launchpad bug 1153992 in Ubuntu CD Images "Raring server and precise d-i installations fail at the clock configuring step" [Critical,Fix released] https://launchpad.net/bugs/1153992
[02:53] <stgraber> I'm waving through the grub binary in Unapproved so I can then have this migrate to raring
[03:58] <stgraber> respinning Edubuntu for new grub2, that will hopefully fix amd64
[04:20] <stgraber> cjwatson: edubuntu-dvd-amd64 on kapok.buildd finished at 2013-03-13 04:16:05 (success)
[04:35] <RAOF> You know what would be awesome? If people could say “verifed on precise” or “verified on quantal” rather than just ‘verified’ on bugs SRUd to both Precise and Quantal.
[04:45] <RAOF> Hm. We don't _really_ support Oneiric now, do we.
[04:45]  * RAOF eyes off the SRUs awaiting verification for 200+ days
[04:46] <micahg> technically for about another month
[04:57] <RAOF>  !!! There are 3 packages in the oneiric-unapproved queue‽
[04:57] <ubot2> RAOF: I am only a bot, please don't think I'm intelligent :)
[04:59] <RAOF> infinity: Were you the one who didn't want be rejecting gcc-4.6 from the precise-unapproved queue because you wanted it there as a reminder to fix it?
[05:00] <infinity> RAOF: Yeah, but go ahead and reject it, and doko and I can discuss it later.
[05:04] <RAOF> Oh, god. Webservices.
[05:14] <RAOF> Oh dear lord, unity-2d's mega sru.
[07:34] <cjwatson> stgraber: woo
[08:33] <didrocks> infinity: hey. grrr, it seems that the killing all process fix didn't work. Do you mind killing https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4365076 please?
[08:53] <JackYu> Hi, I am Jack from UbuntuKylin team. We are wondering how could we customize the first show when installing? we created a branch lp:syslinux-themes-ubuntukylin, but don't know how to use it...
[08:55] <seb128> JackYu, hey, what do you call "first show"? the installer slideshow?
[08:56] <seb128> or the screen at the very beginning of the boot?
[08:57] <JackYu> seb128: the screen at the very beginning of the boot.
[08:57] <ShineHuang> is the first screen of install process
[08:59] <JackYu> seb128: how could we customize it? thanks.
[09:00] <seb128> JackYu, I'm not sure, but cjwatson can probably help you (not sure if he's around yet)
[09:01] <JackYu> seb128: thanks. I will ping him:)
[09:01] <seb128> JackYu, you can considered him pinged
[09:01] <seb128> he reads this channel and his nickname got mentioned
[09:01] <seb128> I'm sure he will read it when he's around ;-)
[09:02] <JackYu> oh, i see. so I will wait for his response.
[09:07] <cjwatson> JackYu: I would rather not have a separate package - all other flavours share a single implementation
[09:07] <cjwatson> JackYu: do you just need to replace the graphic?
[09:08] <maclin> Hi watson, we also want to replace the dialog for F1
[09:09] <JackYu> cjwatson: yes, we need replace the graphic and the F1
[09:11] <JackYu> cjwatson: so we submit the graphic and the content to you? is it ok?
[09:13] <cjwatson> I'm not sure you can replace F1 straightforwardly
[09:14] <cjwatson> It would depend what you wanted to do with it
[09:14] <cjwatson> maclin: FYI Watson is my family name - my personal name is Colin
[09:14] <cjwatson> or just "cjwatson" is fine
[09:15] <maclin> I'm sorry
[09:15] <cjwatson> For the graphic, yes, send that to me
[09:15] <JackYu> cjwatson: we only replace the 'Ubuntu' to 'UbuntuKylin' in F1
[09:16] <cjwatson> I'll have to check how feasible that is right now.  I don't think we replace it in other flavours
[09:16] <cjwatson> In some places it's talking about the Ubuntu project as a whole
[09:17] <JackYu> sure, thanks. if not easy, just keep the F1.
[09:18] <JackYu> I will send the graphic to your email asap.
[09:18] <cjwatson> If we change anything there, it should be some kind of general change for all flavours, rather than a specific hack for UbuntuKylin
[09:18] <cjwatson> IMO
[09:19] <cjwatson> Are you still seeing that problem with ubuntukylin-default-settings not being installed on the target system?  That was pretty surprising ...
[09:20] <cjwatson> maclin: That's OK, I know ordering conventions differ
[09:20] <cjwatson> But better to say early :)
[09:21] <JackYu> yes, it works ok when we build locally
[09:22] <penghuan> we tried ubuntukylin-default-settings locally, it works well.
[09:22] <cjwatson> I mean the cdimage.u.c builds, not something local
[09:23] <JackYu> en, we are also wondering why it not work on cdimage...
[09:24] <cjwatson> OK, so I'll try to reproduce that this morning
[09:25] <JackYu> Thanks. do you have any logs on the iso build process?
[09:28] <JackYu> BTW, we are working to update some packages. I will file bugs to these exceptions:)
[09:31] <cjwatson> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/raring/ubuntukylin/
[09:31] <cjwatson> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntukylin/raring/
[09:31] <cjwatson> former for the squashfs part, latter for the main ISO
[09:32] <JackYu> well, thanks
[09:32] <cjwatson> hmm, weird black bar on the boot menu
[09:33] <cjwatson> JackYu: do you want to have the same behaviour as Ubuntu where you have to press a key if you want the boot menu, but otherwise it boots straight into a graphical "try" or "install" screen?
[09:36] <cjwatson> maclin: regarding bug 1153917, it's always a good idea to report separate problems as separate bugs; version updates need to be tracked separately
[09:36] <ubot2> Launchpad bug 1153917 in UbuntuKylin "UbuntuKylin Default Settings do not worked as expected" [Undecided,Confirmed] https://launchpad.net/bugs/1153917
[09:38] <JackYu> cjwatson: We prefer the same behavior as Ubuntu...
[09:40] <cjwatson> OK, I can arrange that
[09:40] <cjwatson> Drat, why doesn't this laptop have KVM support turned on
[09:45] <maclin> I find the following log:
[09:45] <maclin> The following packages will be REMOVED:
[09:45] <maclin>   libreoffice-help-zh-cn ubuntukylin-default-settings
[09:46] <cjwatson> Are you sure that's current?
[09:46] <cjwatson> I thought I'd fixed that
[09:46] <cjwatson> Ah, yes, it is
[09:47] <cjwatson> In that case this'll be fixed by the new libreoffice
[09:47] <cjwatson> So I think a plain rebuild will fix this - I'll sort out your boot menu and then do that
[09:47] <maclin> cjwatson: I think it maybe about 'apt-get autoremove' libreoffice-l10n-zh-cn
[09:49] <cjwatson> No
[09:49] <cjwatson> It was a Conflicts in libreoffice which we analysed and fixed the other day
[09:49] <cjwatson> But it took a while to build everywhere
[09:49] <cjwatson> Because libreoffice
[09:50] <cjwatson> I'm building new images now
[09:50] <JackYu> it's great:)
[09:50] <maclin> OK. Another question: this is found in the log of 20130311.2 while the image we test is 20130311.3. Is that OK?
[09:53] <cjwatson> Yes, the livefs build IDs and the CD build IDs are not necessarily in sync
[09:53] <cjwatson> Because it's possible to build a new image without building a new livefs
[09:56] <maclin> Good, we will  expect new image to test, thanks cjwatson!
[10:08] <tumbleweed> what rationale did stgraber use for his beta-1 block? there are packages seeded in flavours participating in the beta that he hasn't blocked, and people are requesting FFes for
[10:09] <xnox> tumbleweed: whatever the product owners asked to block.
[10:09] <xnox> no more / no less.
[10:10] <cjwatson> I think stgraber said it was incomplete ...
[10:10] <Laney> right, and based on what ScottK had before
[10:10] <tumbleweed> what am I getting at, is should we be deferring FFes for a couple of days, or adding to the block list
[10:10] <xnox> but there are first-time flavours this time around, and hence the block possibly needs to be expanded.
[10:11] <tumbleweed> also, some of these things are insane. did people forget about FF again?
[10:11] <xnox> (first-time with blocks that is)
[10:12] <cjwatson> Laney: do you think the verification in bug 1041432 is sufficient for both precise and quantal?  you just applied the general v-done tag
[10:12] <ubot2> Launchpad bug 1041432 in gst-plugins-good0.10 (Ubuntu Quantal) "Any application which uses v4l2src element can be froze when recording video (e.x. cheese)" [High,Fix committed] https://launchpad.net/bugs/1041432
[10:12] <Laney> reviewing "New Unity stack" are we? :-)
[10:12] <tumbleweed> Laney: well, it came past :P
[10:13] <Laney> cjwatson: I couldn't rememeber what the format was (v-d-precise?) and figured that the promoter would just do precise and then flip it back
[10:13] <cjwatson> Don't rely on that :)
[10:13] <cjwatson> tweaked the tags now
[10:13] <Laney> merci
[10:14] <cjwatson> And yes, v-done-precise
[10:26] <cjwatson> Package: gnome-shell
[10:26] <cjwatson> Task: ubuntu-gnome-desktop
[10:26] <cjwatson> oh good, that's in place
[10:27] <Laney> tumbleweed: I think I'm going to approve stuff and block it
[10:28] <tumbleweed> Laney: thanks. I've got intermittent access to my e-mail atm
[10:28] <Laney> e.g. shotwell
[10:28] <tumbleweed> yeah, I'm ok with the yorba stuff
[10:28] <tumbleweed> nautilus sounds sane too
[10:29] <Laney> will leave unity to you :-)
[10:29] <tumbleweed> pffff
[10:32] <Laney> seb128: ^ so you don't need to hold off uploading that stuff as I've blocked it until after the beta
[10:32] <seb128> Laney, thanks
[10:33] <Laney> or I would have... diverged branches
[10:34]  * Laney just found some worcestershire sauce which expired in 2008
[10:34] <Laney> probably fine, right?
[10:34] <Daviey> for sure.
[10:43] <Riddell> stgraber: could you spin up new kubuntu images?
[10:47] <cjwatson> Riddell: What are the changes, so I can mention them on the tracker?
[10:48] <cjwatson> (I expect stgraber isn't up yet)
[10:49] <Riddell> cjwatson: ubiquity fixes, kubuntu-settings and kde-workspace
[10:51] <cjwatson> Riddell: Kubuntu Active too, or just desktop?
[10:52] <Riddell> cjwatson: yes active too please
[10:53] <cjwatson> OK, marked for rebuild
[10:54] <cjwatson> And rebuilding now
[11:01] <highvoltage> have anyone come across this bug testing today's images yet? https://bugs.launchpad.net/ubuntu/+bug/1154539
[11:01] <ubot2> Launchpad bug 1154539 in ubuntu "[raring-beta1] Live system does not boot to LightDM when a disk is attached with swap" [Undecided,New]
[11:15] <JackYu> cjwatson: I have filed two separate bugs for  Chinese-calendar and indicator-china-weather to Upgrade to latest version , i.e., bug #1154542 and bug # 1154523. Would you please help us to check them?
[11:15] <ubot2> Launchpad bug 1154542 in chinese-calendar (Ubuntu) "Upgrade to chinese-calendar 0.7.6 in Raring" [Undecided,New] https://launchpad.net/bugs/1154542
[11:15] <cjwatson> JackYu: I'm afraid I have no experience with either package - you probably want somebody a bit more desktopy?
[11:16] <cjwatson> Or maybe whoever uploaded them last
[11:17] <cjwatson> I mean, the bugs themselves are fine
[11:17] <JackYu> cjwatson: it said that 'Once the Feature Freeze Exception has been ACK'd by a member of the Release Team, the status will be changed to TRIAGED. '
[11:17] <cjwatson> Do you have a conventional tag for bugs that UbuntuKylin is interested in?
[11:17] <cjwatson> Ah, yes
[11:17] <cjwatson> You might want to put '[FFE]' or something at the front of the bug subject to indicate that that's what you're looking for
[11:17] <JackYu> so we need somebody to TRIAGED them:)
[11:17] <cjwatson> I'll amend these ones now
[11:18] <JackYu> Ah, thanks:)
[11:23] <JackYu> cjwatson: the other one is bug # 1154523 :)
[11:28] <JackYu>  bug #1154523
[11:28] <ubot2> Launchpad bug 1154523 in indicator-china-weather (Ubuntu) "Upgrade to indicator-china-weather 1.0.4 in Raring" [Undecided,New] https://launchpad.net/bugs/1154523
[11:29] <cjwatson> Yeah, I know, I was just interrupted by the computer recycling man turning up
[11:29] <JackYu> :)
[11:31] <cjwatson> study[cjwatson] -= 4 * monitor
[11:32] <cjwatson> JackYu: Don't worry about it for this time, but for future reference, excluding the .bzr directory from your diffs would be very helpful
[11:32] <cjwatson> If it's in bzr anyway, you could just use 'bzr diff' with appropriate arguments, rather than creating a -new directory and diffing the old-fashioned way
[11:32] <cjwatson> But, failing that, --exclude=.bzr
[11:39] <cjwatson> Triaged now but I have some comments on 1154523 that really ought to be addressed
[11:43] <xnox> JackYu: http://doc.bazaar.canonical.com/latest/en/mini-tutorial/ is good intro into what bzr is, what it can do, and how does it help.
[12:01] <JackYu> cjwatson: nice. I got it. will follow your suggestion next time:)
[12:51] <JackYu> cjwaton: we have downloaded the newest image and found that 1) the default-setting package still dose not take effect, e.g., the wallpaper is still the same as ubuntu;  and 2) the screen at the very beginning of the boot when installing doesn't show as we expected.
[12:52] <ScottK> tumbleweed: The goal of the block (and it's coverage is not as complete as it should be) is to block transitions of packages on the participating product ISOs.  I gave stgraber an initial hint for Kubuntu + base.  He's added other packages for other flavors, AIUI.  No, you don't need to defer FFes.  In theory stuff should just sit in proposed until the block is listed with no harm.
[12:54] <JackYu> cjwatson: but this time, we did not find any error in the log.
[12:56] <cjwatson> JackYu: I noticed the boot screen problem myself and have just committed a fix
[12:56] <cjwatson> (gfxboot has fairly limited PCX parsing; I ran 'mogrify -colors 256' over it to fix it)
[12:57] <JackYu> thanks for that.
[12:57] <tumbleweed> ScottK: ok, I didn't have a hints file at the time, but I created one now (assuming that doesn't still need a bzr up on teh other side). so I'll block things I approve, as needed
[12:57] <cjwatson> JackYu: As for the wallpaper, please can you describe the exact sequence of steps you took all the way from the boot screen?  There are a few possibilities and I need to make sure I'm checking the right one.
[12:58] <cjwatson> It seems odd to me that the calendar pops up in the middle of the desktop when you start.  Is that intentional?
[12:58] <ScottK> tumbleweed: You do have one.  When I bzr pull the hints directory, I got your file.
[12:58] <cjwatson> tumbleweed: bzr up is automatic; you're fine
[12:58] <tumbleweed> cjwatson: ta
[12:58] <JackYu> yes:). But we have changed in the latest version of calendar.
[12:59] <tumbleweed> ScottK: there's the config side to tell britney about it (in the early, days, I believe that was manual)
[12:59] <ScottK> Oh.
[12:59] <ScottK> Didn't know.
[13:00] <cjwatson> JackYu: I seem to get the proper wallpaper in my simple test (i.e. boot live CD in "Try UbuntuKylin without installing" mode)
[13:01] <JackYu> cjwatson: the wallpaper is in the default-settings package, and default-setting will install ubuntukylin-theme. but they did not show...
[13:01] <cjwatson> JackYu: But it does show for me, so if you want me to investigate it then I need a precise sequence of steps to reproduce the problem.
[13:01] <JackYu> really?
[13:01] <cjwatson> We're obviously not doing the same thing.  I've told you what I did; now you tell me what you did
[13:02] <JackYu> we run the iso using virtual box and try ubuntukylin without installing, but the wallpaper doesn't show
[13:03] <cjwatson> Can I have a screenshot?
[13:03] <JackYu> a moment
[13:03] <cjwatson> Also, i386 or amd64?
[13:04] <JackYu> i386
[13:04] <cjwatson> Likewise
[13:15] <cjwatson> JackYu: So, after I move the calendar out of the way, it looks like this for me in virtualbox: http://people.canonical.com/~cjwatson/tmp/ubuntukylin.png
[13:15] <cjwatson> That's your wallpaper, isn't it?
[13:15] <JackYu> cjwatson: email you
[13:16] <JackYu> Yes!
[13:16] <cjwatson> I'll just respin to fix the boot screen
[13:16] <JackYu> you are using which image?
[13:17] <cjwatson> JackYu: http://cdimage.ubuntu.com/ubuntukylin/daily-live/20130313/raring-desktop-i386.iso
[13:17] <JackYu> ok, we will try this one again.
[13:17] <cjwatson> The link on iso.qa looks correct too
[13:18] <JackYu> sure. thanks.
[13:19] <cjwatson> (I typically use rsync though)
[13:23]  * stgraber waves
[13:23] <cjwatson> yo
[13:24] <cjwatson> JackYu: there we go, that fixes the boot screen
[13:24] <cjwatson> (20130313.1)
[13:24] <cjwatson> no changes to the live filesystem
[13:25] <JackYu> ok, we will try the latest one:)
[13:38] <cjwatson> JackYu: So this is why I wanted you to give me exact steps - you didn't tell me that you'd let the boot menu proceed without pressing a key, and then selected "Try UbuntuKylin" from the graphical menu; as opposed to pressing a key at the boot menu and selecting "Try UbuntuKylin without installing"
[13:41] <JackYu> cjwatson: without pressing a key, it goes to the selection screen.
[13:42] <cjwatson> Indeed.  But you didn't tell me that that was what you were doing :)
[13:43] <cjwatson> And that was what I needed to know.  I worked it out from the screenshot ..
[13:43] <cjwatson> Do you see what I mean now?
[13:44]  * ogra_ hands cjwatson hos spare crystal ball 
[13:44] <ogra_> *his
[13:45] <JackYu> oh, i see. sorry for your time:0
[13:45] <cjwatson> Well, no, I'm not trying to be sarcastic, just trying to make bug reporting more effective :)
[13:48] <JackYu> thank you. I will do it better next time:)
[13:54] <cjwatson> JackYu: OK, ubiquity bug, fix committed for the next upload (2.13.16)
[13:54] <cjwatson> should only have affected the wallpaper during installation / live session, not the rest of it
[13:56] <JackYu> cjwatson: yes.
[14:02] <stgraber> can I get someone to review bug 1154601 fairly quickly?
[14:02] <ubot2> Launchpad bug 1154601 in edubuntu-live (Ubuntu) "[FFe] Disable the edubuntu-server bits on the Edubuntu media" [Undecided,New] https://launchpad.net/bugs/1154601
[14:03] <stgraber> edubuntu as it currently is isn't in a state we'd feel like releasing for beta1 so I'm preparing a bunch of changes that I hope will address that. If I make it any worse, we'll simply skip beta1, if I somehow get it all right, we'll have something worth shipping.
[14:03] <stgraber> Sorry for the last minute notice but I only just found a few minutes to look at it now after highvoltage did an initial test of the images generated yesterday...
[14:04] <cjwatson> stgraber: acked in the bug
[14:04] <stgraber> cjwatson: thanks
[14:04] <cjwatson> Damn, too slow, ScottK beat me
[14:04] <ScottK> ;-)
[14:05] <ScottK> Seemed like an easy decision to make.
[14:05] <ScottK> Anyone on u-release have an opinion on this new Unity stack FFe?
[14:06] <ScottK> It seems to me exactly the kind of thing we said we'd say no to when we moved feature freeze later in the cycle.
[14:07] <stgraber> I'm really annoyed that they haven't learned from the past cycles... and I don't think they can get away with the "vUDS and release discussions" argument because they're essentially telling us they'll only be ready in a month...
[14:09] <tumbleweed> ScottK: I think we should push back hard, yes. We said we would
[14:09] <highvoltage> stgraber: I think for Edubuntu, it might make sense to skip beta1 for tomorrow, and then aim to have a beta quality image early next week
[14:10] <highvoltage> (probably not even worth while to make a big deal about it either)
[14:11] <stgraber> highvoltage: well, I'll still do the cdimage, artwork and installer fixes now and respin. We should have another image early this afternoon and can decide then. I know that if I don't do those changes now they'll get moved to the bottom of my TODO and we'll be in the exact same state for beta2
[14:11] <highvoltage> stgraber: imho the swap partition problem is a blocker
[14:11] <highvoltage> https://bugs.launchpad.net/ubuntu/+bug/1154539
[14:11] <ubot2> Launchpad bug 1154539 in ubuntu "[raring-beta1] Live system does not boot to LightDM when a disk is attached with swap" [Undecided,New]
[14:14] <stgraber> highvoltage: I'm trying to reproduce that one now. I find it hard to believe we would have missed this if it was as simple as "any swap partition"
[14:15] <highvoltage> stgraber: yeah, hopefully that's not the case
[14:28] <stgraber> highvoltage: appears to be pretty consistently reproducable... I'll have to test with Ubuntu next
[14:28] <stgraber> highvoltage: the reason why I never noticed is that I usually use virtio devices and casper doesn't know about those, so simply skips them
[14:33] <stgraber> highvoltage: Ubuntu isn't affected... odd...
[14:35] <stgraber> highvoltage: I'm going to ignore that problem and fix everything else first, then respin and hope the problem will just vanish ;)
[14:35] <stgraber> highvoltage: the only thing I can think of that may cause casper to do weird things on Edubuntu is the multiple squashfs and I just fixed that by removing the server one from the cdimage scripts
[14:50] <highvoltage> stgraber: ok. could you confirm it on edubuntu?
[14:53] <stgraber> highvoltage: yeah, I definitely have it on edubuntu
[14:58] <jokerdino> infinity: hey, around? :)
[15:02] <stgraber> highvoltage: I'm reverting edubuntu-live to the 12.10 version, that should fix all our current issues
[15:03] <stgraber> highvoltage: that should fix the lightdm config bug in the process
[15:18] <stgraber> highvoltage: revert of edubuntu-live uploaded. I'll trigger a new build once it lands.
[15:19] <stgraber> highvoltage: unless we broke anything else, this should bring us back to where we were with 12.10
[16:36] <stgraber> highvoltage: edubuntu rebuilding now
[16:37]  * Laney stabs affects-metoo for process bugs
[17:05] <jbicha> cjwatson: I noticed that http://cdimage.ubuntu.com/ubuntu-gnome/daily-live/current/ is live, thank you!
[17:06] <cjwatson> Oh, yes, I set that up earlier today - didn't notice you coming online
[17:06] <jbicha> I don't think we plan to support powerpc at this time, I'm not sure if we have people to test the amd64+mac images or not
[17:06] <cjwatson> jbicha: Do you want the boot menu to behave like Ubuntu's (the "press a key" screen)?
[17:07] <cjwatson> and then into ubiquity with a try/install choice if you don't press anything?
[17:07] <cjwatson> Yeah, I was going to check on architectures
[17:08] <cjwatson> jbicha: So http://paste.ubuntu.com/5611239/ ?
[17:08] <didrocks> joshuahoover: hey, please do not update the FFe bug without asking
[17:08] <didrocks> joshuahoover: adding lenses we are not waiting to install by default this release
[17:08] <jbicha> cjwatson: yes to those archs
[17:09] <joshuahoover> didrocks: my understanding was we want those in by default
[17:09] <didrocks> joshuahoover: it's not the list communicated by PS to me
[17:09] <didrocks> joshuahoover: did you check with them? are they ready? is the packaging fixed as we did for the others?
[17:10] <cjwatson> you know it's OK to have multiple FFE bugs if there's some disagreement about whether things are connected ...
[17:10] <joshuahoover> didrocks: i will double check, but i was talking to thostr_ earlier and he wanted me to double check the list for client scopes that are said to be ready to go
[17:11] <didrocks> joshuahoover: ok, tell him to send me an email, I spent a day updating 40 components, so if you want those in, please update with the same fixes I had to do on the others
[17:11] <didrocks> joshuahoover: I'm removing them meanwhile, feel free to update if the double checking is positive :)
[17:11] <joshuahoover> didrocks: will do, sorry for the confusion :)
[17:11] <didrocks> joshuahoover: no worry, as the bug is polemic already, I prefer we avoid noise ;-)
[17:12] <joshuahoover> heh
[17:21] <cjwatson> jbicha: OK, I've applied that and removed the amd64+mac and powerpc images
[18:11] <infinity> jokerdino: Am now.
[18:15] <xnox> infinity: what do you want me to do to get openssl accepted into quantal|precise-proposed? write autopkgtests to abuse webservers over https? anything else?
[18:16] <infinity> xnox: Talk to Rob Herring to see what testing he's done?
[18:17] <infinity> xnox: I'm not sure how autopkgtests factor into it, unless you happen to have an autopkgtest environment on ARM (I thought it all relied on KVM or something).
[18:18] <xnox> infinity: does this mean I get to go and see motocorss races with him?
[18:18]  * xnox ponders if I got wrong Rob Herring......
[18:21] <infinity> xnox: :P
[19:39] <stgraber> hallyn: hey, just so you know, we found a very very odd bug on Edubuntu :)
[19:40] <stgraber> hallyn: mountall will fail at boot time if cgroup-lite is installed and you have a swap in /etc/fstab
[19:40] <stgraber> hallyn: preventing the media from booting completely
[19:40] <stgraber> hallyn: removing the swap from /etc/fstab OR removing cgroup-lite fixes the issue
[19:40]  * slangasek squints
[19:40] <slangasek> is this related to the new change to add cgroups to /lib/init/fstab?
[19:41] <hallyn> a SWAP in fstab?
[19:42] <hallyn> that seems random
[19:42] <stgraber> slangasek: not impossible. We may be getting some kind of race between mountall and cgroup-lite to mount /sys/fs/cgroup.
[19:42] <slangasek> yes, since cgroup-lite is 'start on mounted MOUNTPOINT=/sys'
[19:42] <stgraber> hallyn: actually, looking at it, we probably want to change the start condition for cgroup-lite. that maybe the problem
[19:42] <infinity> And mounting (or not) your swap partition is altering the timing of the race? :)
[19:42] <slangasek> there's certainly a race there
[19:43] <stgraber> hallyn: we'd want MOUNTPOINT=/sys/fs/cgroup
[19:43] <slangasek> right, cgroup-lite's upstart job should be changed, and cgroup-lite should add a versioned depends on mountall
[19:43] <stgraber> slangasek: good, we seem to agree then ;) Changing that in my test VM to see if that fixes it
[19:44] <hallyn> stgraber: good point, now that that is always a mountpoint, we can do that, cool.
[19:44] <hallyn> stgraber: if it fixes it for you do you mind pushign the fix?
[19:44] <slangasek> (or we can add a versioned Breaks: on old cgroup-lite, if people think cgroup-lite Depends: mountall is wrong)
[19:44] <stgraber> infinity: it's a very very reliable race though. I reproduced it 10-15 times here and highvoltage reproduced it using a different VM solution on a different machine, apparently just as reliably :)
[19:44] <infinity> stgraber: Cute.
[19:44] <stgraber> hallyn: if that works, I'll push the fix immediately, then respin Edubuntu so we have a working image for beta1
[19:44] <infinity> slangasek: The Breaks is definitely more correct.
[19:45] <slangasek> infinity: is it?  The new version of cgroup-lite will have a no-op upstart job in the absence of the new mountall
[19:45] <hallyn> still it might be worth figuring out what is the actual cause of the hang...  cause that feels like a workaround for a bad bug
[19:45] <slangasek> so it might be that both are equally correct
[19:45] <infinity> slangasek: Oh, if the job ends up actually depending on mountall, then the dep is fine.
[19:46] <slangasek> infinity: well, cgroup-lite being "start on mounted $anything" implies a dependency on mountall
[19:46] <stgraber> eventually cgroup-lite should make its way to Debian and be used with something else than upstart, but for now, versioned Depends works for me
[19:46] <infinity> slangasek: I was thinking of this more from the Debian multiple swappable init systems perspective, where forcing mountall on people is wrong, but if our cgroup-lite is actually useless without mountall, the dep is correct.
[19:46] <infinity> slangasek: Moreover, it's all academic, since mountall is Essential in Ubuntu anyway.
[19:46] <slangasek> stgraber: nah, eventually cgroup-lite should make its way to Debian and Debian should be using upstart for everything
[19:47] <slangasek> infinity: no it isn't :)
[19:47] <slangasek> upstart is not Essential, and neither is mountall
[19:47] <infinity> slangasek: Transitively, isn't it?  Oh, sorry, required, not Essential.
[19:47] <slangasek> ah, required, yes
[19:48] <stgraber> ok, MOUNTPOINT=/sys/fs/cgroup works fine. I'll push that along with a versioned Depends on mountall
[19:48] <infinity> Hrm, have we actually removed anything that depends on upstart out of the Essential set?  I was sure it used to be.
[19:48] <infinity> That's shiny news for people who want to fiddle with init swapping at some point.
[19:48] <stgraber> highvoltage: ETA ~2h for working Edubuntu images
[19:48] <infinity> (Though I'd rather do that in Debian anyway)
[19:51] <xnox> infinity: i think i added upstart-job dependency to shadow, which i should remove probably.
[19:52] <infinity> xnox: Not to login, which is the only Essential part of shadow.
[19:52] <slangasek> xnox: you added it manually?
[19:53] <slangasek> anyway, the fix for that is to make upstart-job go away
[19:53] <xnox> slangasek: we've been through this.... dh_installinit did that for me.
[19:53] <infinity> slangasek: No, he added it by giving passwd an upstart job. :P
[19:53] <slangasek> by 1) fixing remaining init scripts to work with insserv, 2) un-neutering insserv, 3) merging sysvinit
[19:53] <xnox> remember the locked shadow dbs bug.....
[19:53] <slangasek> xnox: right, thought so, but maybe my memory was playing tricks on me :)
[19:53] <slangasek> xnox: yeah, I remember the job in question - was just wondering about "added upstart-job dependency" and making sure you didn't do it manually
[19:54] <stgraber> hallyn: cgroup-lite uploaded
[20:12] <hallyn> stgraber: saw it - thanks
[20:12] <hallyn> but i think i'll set up a vm to test the old in.  it's weird
[20:15] <hallyn> i can't reproduce it...
[20:16] <stgraber> hallyn: the easiest reproducer is current edubuntu amd64
[20:17] <stgraber> hallyn: boot it on a system that has a disk containing a swap partition (connected over SATA, not VIRTIO as a casper bug makes VIRTIO work just fine ;))
[20:17] <hallyn> aw look at that, google gives me a nice pic of you :)
[20:18] <stgraber> (casper doesn't try to setup swap partitions for vda devices. I have a fix staged in ubuntu:casper to fix that post-beta1.)
[20:18] <stgraber> hallyn: yeah, google does that sometimes...
[20:26] <highvoltage> hallyn: the scary thing is when I google myself and get pics of stgraber
[20:27] <hallyn> :)
[20:27] <hallyn> identity theft can strike anyone
[23:50] <cjohnston> Laney: ping