=== james_ is now known as Guest98563
[00:46]  * cjwatson apologies profusely for kubuntu.precise r1164 and xubuntu.precise r906
[00:46] <cjwatson> Grossly unpleasant hacks that they are - but we should be able to get rid of those for .3
[00:50] <cjwatson> OK, respinning Ubuntu alternate (for bug 1122525) and Kubuntu and Xubuntu alternates (for bug 1123379)
[00:50] <ubot2> Launchpad bug 1122525 in ltsp (Ubuntu Precise) " ltsp-build-client build ltsp chroot failed : Unable to locate package linux-image-generic" [Undecided,Fix released] https://launchpad.net/bugs/1122525
[00:50] <ubot2> Launchpad bug 1123379 in Ubuntu CD Images "Kubuntu alternate install 12.04.2 2013_02_11 AMD 64 bit cannot find/load kernel modules" [Critical,Triaged] https://launchpad.net/bugs/1123379
[00:51] <cjwatson> Hopefully those are the last respins
[00:55] <cjwatson> Should deal with Xubuntu alternate amd64's oversizedness too
[02:19] <cjwatson> I thought cdimage had run out of ways to surprise me
[02:19] <cjwatson> But now the Kubuntu images (at least) have nic-modules-* and others apparently without a Priority field
[02:41]  * cjwatson fixes, I think
[02:44] <cjwatson> Will need a couple of publication cycles, so I'll probably go for a nap before it's finished
[02:54] <cjwatson> (Hence, tangentially, the copy of refit to precise-updates that some may have noticed on -changes.)
[03:53] <cjwatson> Right, repeating all the earlier respins
[03:53] <cjwatson> (Ubuntu, Kubuntu, and Xubuntu alternate)
[04:30] <cjwatson> Those dailies are looking more plausible now.  Bed.
[05:06] <plars> cjwatson: took a quick look at the new alternate images and on a physical machine, they install and desktop comes up fine, though it's telling me I have incomplete language support.  I've never had a clear answer on whether this is expected to be the case or not, but considering it had full access to download whatever it needed during the install I would think it shouldn't need to get more english language packs after install
[05:06] <plars> let me know what you think on that...
[05:06] <plars> but under virtualbox it has the same problems I mentioned earlier in bug# 1122072
[05:06] <plars> bug #1122072
[05:06] <ubot2> Launchpad bug 1122072 in libpciaccess (Ubuntu Precise) "[Precise on VirtualBox] "Fatal server error: no screen found" in Xorg.0.log" [High,Fix committed] https://launchpad.net/bugs/1122072
[05:24] <skaet> slangasek,  have removed Edubuntu from Alpha 2 manifest per email from highvoltage.   Added Ubuntu Cloud images to the manifest per IRC from smoser.
[05:26] <slangasek> huh, ok
[05:26] <slangasek> switching the cron around
[05:27] <slangasek> ubuntu-server disabled in cron, edubuntu re-enabled
[05:36] <skaet> thanks
=== zequence_ is now known as zequence
[08:38] <cjwatson> plars: It's unexpected and rather weird, but not a blocker given the general EOL nature of alternates
[08:43] <cjwatson> plars: (I'll have a look if I have time, though.)
[10:11] <psivaa> cjwatson: xnox: Are raring server images delayed today? Generally they appear earlier than the desktop ones.
[10:12] <xnox> psivaa: "<slangasek> [05:27:37] ubuntu-server disabled in cron, edubuntu re-enabled"
[10:12] <xnox> psivaa: something to do with alpha2 'soft-freeze' / release
[10:13]  * xnox doesn't have access to that machine to actually check what's currently configured to build / is building.
[10:13] <Laney> server is indeed commented out
[10:14] <psivaa> xnox: Laney: ahh ok, thanks
=== henrix_ is now known as henrix
=== doko_ is now known as doko
[11:27] <skaet> Laney, psivaa, xnox - hmm...   it was cloud images that are going to be added,  not server.   raring server should be re-enabled for the daily.
[11:28] <cjwatson> I've re-enabled server and kicked off a daily build.
[11:29] <psivaa> cjwatson: skaet: thanks :)
[11:44] <Laney> What's the preferred way of SRUing when there's already a change in proposed? Upload the new change or try to get the old one to updates first?
[11:45] <cjwatson> The latter if possible - it avoids tangles.  We can accommodate the former though.
[11:46] <cjwatson> (If you stack SRUs, and the package in question doesn't already have a version in -updates, remember to use -v<version in release pocket> when upgrading.  Hopefully we'll get this LP bug fixed soonish.)
[11:46] <Laney> I'll give the guy a few days to respond
[11:46] <Laney> sure
[11:46] <cjwatson> s/upgrading/uploading/
[11:52] <seb128> Laney, you can usually upload, review time makes likely that the previous one will be in -updates before your upload gets accepted (if the previous one seems likely to be validated)
[11:52] <psivaa> stgraber: cjwatson: bug 1124029 is still occurring but on amd64+mac image. Still trying on amd64 and i386 though.
[11:52] <ubot2> Launchpad bug 1124029 in ltsp (Ubuntu) "'ltsp-client-builder' failed with error code 1 during LTSP server installation with 20120213.1 alternate images" [Undecided,New] https://launchpad.net/bugs/1124029
[11:52] <Laney> it's not that likely in this case as it's been outstanding since November
[11:53] <cjwatson> psivaa: sounds like it must be a different cause; the failure is a general one
[11:54] <cjwatson> from before, I mean
[11:55] <psivaa> cjwatson: ok, understand. but i was not sure if this will affect i386 and amd64 too
=== mmrazik is now known as mmrazik|lunch
[11:56] <cjwatson> psivaa: from the logs I just quoted in the bug, I suspect that it may be amd64-specific
[11:56] <cjwatson> But it's not entirely clear
[11:56] <cjwatson> Actually, maybe that apt warning is just noise for this purpose
[11:56] <psivaa> cjwatson: ok thanks, ill confirm in a little while
[11:57] <cjwatson> It's probably that touch failure that matters; maybe fallout from /run?
[11:57] <seb128> Laney, if it's sitting there since november either we need to get it reviewed/in or it's invalid and we need it kicked out, what upload is that?
[11:58] <Laney> seb128: gst-plugins-good0.10. I pinged the guy.
[11:59] <seb128> ok, otherwise we can probably do a "it might or might not fix the issue for good but there is no regression and it fixes it for some users so let's mark it verified"
[11:59] <cjwatson> Curious, though, since in-target has bind-mounted /run onto /target/run since oneiric
[12:02] <psivaa> cjwatson: just added a note saying that this is also a side-by-side installation in the bug.
[12:02] <cjwatson> *Probably* doesn't matter
[12:05] <cjwatson> psivaa: Is this the alternate image?
[12:07] <psivaa> cjwatson: yes
=== mmrazik|lunch is now known as mmrazik
[12:08] <cjwatson> I assume this means there are no automatic tests of LTSP
[12:09] <psivaa> no there are not
[12:09] <cjwatson> Since the dashboard is (effectively) clear
[12:29] <cjwatson> psivaa: trying to reproduce it now
[12:42] <rtg> why hasn't Raring linux-firmware been promoted from -proposed ? I thought that was automatic when all build dependencies were satisfied.
[12:42] <jdstrand> cjwatson: ping regarding precise security updates (openjdk-6 for me, mdeslaur has others)
[12:44] <psivaa> cjwatson: ack, sorry had to go out. the installation on i386 on an 8G hard drive dell mini has failed before going to Build LTSP chroot step because no space left on device.
[13:09] <smoser> utlemming, when you arive, we need to get ISO tracker populated http://cloud-images.ubuntu.com/raring/20130213/ i guess would be our candidate.
[13:17] <Riddell> anyone admit to rejecting cantata from New?
[13:27] <cjwatson> jdstrand: I want to finish diagnosing psivaa's LTSP bug first
[13:27] <cjwatson> rtg: It's blocked pending the community-flavour Alpha 2
[13:27] <cjwatson> rtg: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html lists that
[13:28] <rtg> cjack
[13:28] <cjwatson> (well, it shows it's a manual block, at least)
[13:28] <rtg> cjwatson, ok. thanks
[13:30] <jdstrand> cjwatson: ack
[14:03] <stgraber> cjwatson: want me to look at LTSP on amd64+mac? (that'd be in a non-mac VM though)
[14:16] <cjwatson> stgraber: Sure
[14:16] <cjwatson> My install is still running
[14:22] <plars> cjwatson: but it's also a problem on desktop, not just alternate
[14:23] <cjwatson> plars: What is?
[14:23] <cjwatson> Incomplete language support?
[14:24] <cjwatson> Well, OK - but even then I think that message is a minor flaw
[14:25] <Riddell> we want to get a SRU in of kde-workspace for bug 1123126 in 12.04.2 kubuntu
[14:25] <ubot2> Launchpad bug 1123126 in kde-workspace (Ubuntu Precise) "12.04 plasma init script order wrong" [Critical,In progress] https://launchpad.net/bugs/1123126
[14:25] <Riddell> who's good to look into that?  ScottK? infinity?
[14:25] <Riddell> bdmurray?
[14:25]  * ScottK can look.
[14:26] <ScottK> Are we going to respin for this?
[14:27] <ScottK> Riddell: ^^^
[14:27] <ScottK> Riddell: I don't see it in queue yet.
[14:27] <plars> cjohnston: the issue with X not starting under virtualbox - it's the same as I was seeing in the desktop image you built for me yesterday after we got past the libpciaccess bug
[14:28] <Riddell> ScottK: yes it'll need a respin
[14:28] <ScottK> OK.
[14:28] <Riddell> are we using an etherpad to keep track of things?
[14:28] <ScottK> Riddell: I don't suppose that while we're respinning there's anything we can do to shrink the live images?
[14:29] <cjohnston> I'm guessing ^^ was for cjwatson
[14:29] <Riddell> ScottK: I can't think of anything immediately
[14:29]  * Laney hugs cjohnston 
[14:30] <cjohnston> Laney: I feel so abused.. lol
[14:30] <plars> cjohnston: we really gotta do something about your name
[14:30] <plars> :)
[14:30]  * Laney starts a "one, two, three, tab" campaign
[14:31] <ScottK> At least the alternates fit.
[14:31] <plars> having to type 3 characters rather than 2 in order to ensure accurate tab completion is far too inconvenient!
[14:31] <cjohnston> Laney: +1
[14:32] <cjwatson> Riddell: etherpad> no
[14:32] <cjwatson> Riddell: kde-workspace> OK, get it in the queue and I'll have a look
[14:33] <cjwatson> ScottK: You could lose a language pack, but it'd take a live-build SRU :-/
[14:34] <cjohnston> Laney: much more convenient to tab complete someone else, and let everyone figure out what you really meant ;-)
[14:34] <cjwatson> plars: Curious that there are two success reports in the bug ... needs an X developer to unpick
[14:34] <ScottK> Ah.  A bit late for that now, I'd imagine.
[14:34]  * xnox points people again to the option of "tab completion based on last used order" in most irc clients that gets me cjwatson on cj<tab>
[14:35] <ogra_> xnox, ++
[14:35] <plars> cjwatson: it works fine on hardware, just not under virtualbox
[14:35]  * xnox ponders if I should upload it enabled by default in irssi & xchat
[14:35] <plars> cjwatson: so maybe they aren't going far enough? psivaa: can you try it too?
[14:35] <cjwatson> plars: So that indicates to me that it's a worthwhile improvement
[14:35] <ogra_> xnox, would make sense i think ...
[14:35] <cjwatson> plars: Perhaps we need the xorg-server change as well ...
[14:36] <plars> cjwatson: it could be that this is just a new bug and unrelated to the previous one
[14:36] <cjwatson> (Which isn't in -proposed because I didn't think we needed it yet)
[14:36] <cjwatson> Ah, no, xorg-server in the queue is something quite different AFAICS
[14:37] <cjwatson> plars: Could you file a separate bug so that we can split these?
[14:37] <plars> cjwatson: I will
[14:38] <cjwatson> So that means respinning ... uh, everything
[14:38] <Riddell> cjwatson, ScottK: kde-workspace 4:4.8.5-0ubuntu0.3 (Waiting for approval)   you can fight over it
[14:38] <cjwatson> Sigh
[14:38] <cjwatson> Riddell: Looking
[14:39]  * ScottK surrenders.
[14:39] <ScottK> (wasn't much of a fight)
[14:39] <cjwatson> Well, I don't mind, you probably know the package better
[14:40] <psivaa> cjwatson: plars i could try another alternate install on vbox once the ltsp installation is over
[14:41] <plars> psivaa: thanks
[14:42] <cjohnston> ScottK: since your here, do you have any thoughts on bug #1070772 probably specifically comment #4
[14:42] <ubot2> Launchpad bug 1070772 in shiboken (Ubuntu) "modelview_test.py segfaults python" [High,Confirmed] https://launchpad.net/bugs/1070772
[14:43] <ScottK> cjohnston: No opinion.  I don't use it either.
[14:44] <cjohnston> ScottK: ok. thanks
[14:44] <ScottK> cjohnston: OdYx is really the only one that knows that package AFAIK.
[14:45] <cjohnston> I spoke to him and he didn't have any idea, nor any time to look into it.
[14:48] <cjwatson> plars: Do you have a syslog (or just a bug ref with logs) for any of these incomplete-language-support cases?
[14:50] <plars> cjwatson: I can get that in just a bit
[14:55] <cjwatson> My LTSP test install worked ...
[14:55] <cjwatson> So I think I'm dependent on stgraber having a look
[14:56] <stgraber> cjwatson: mine is still running but it passed the chroot creation step and is compressing now, so it's very unlikely it'll fail
[14:57] <cjwatson> So current state: most things (except server) need respinning for libpciaccess; LTSP problem apparently unreproducible; kde-workspace building; incomplete language support needs investigation
[15:02] <ScottK> cjwatson: If most things need respin, is an SRU for live build to shrink the Kubuntu live images a possibility?
[15:05] <cjwatson> ScottK: powerpc would be easy enough to shrink, but I don't see any spare language packs in amd64, and I don't think that removing German from i386 will gain you enough space to be back under whatever the limit is
[15:05] <cjwatson> ScottK: So I'm not sure it's worth it?
[15:06] <cjwatson> (I've now looked at it in more detail ...)
[15:06] <stgraber> cjwatson: ok, so I identified what line failed for psivaa but it doesn't make any sense...
[15:06] <stgraber> in-target /bin/touch /etc/resolv.conf
[15:06] <cjwatson> Removing German would save about 6.5MB
[15:06] <cjwatson> stgraber: Yeah, I alluded to that above
[15:07] <cjwatson> 11:57 <cjwatson> It's probably that touch failure that matters; maybe fallout from /run?
[15:07] <cjwatson> 11:59 <cjwatson> Curious, though, since in-target has bind-mounted /run onto /target/run since oneiric
[15:07] <ScottK> cjwatson: OK.  Let's leave it then.  Thanks for checking.
[15:07] <cjohnston> /63/27
[15:08] <cjwatson> ScottK: I think the Kubuntu limit for precise was officially 1GB anyway ...?
[15:08] <cjwatson> Though it's true that earlier releases fit on a CD
[15:08] <ScottK> cjwatson: No.  We were still trying to fit on a CD.
[15:08] <cjwatson> Ah, well, the cdimage code lies then
[15:08] <ScottK> We didn't switch until quantal.
[15:08] <smartboyhw> I heard Xubuntu quit of having CD releases
[15:08] <cjwatson> I suspect somebody changed it without an appropriate release guard
[15:08] <cjwatson> (grr)
[15:10] <stgraber> cjwatson: hmm, right. I suppose the same would happen if /run/resolvconf didn't exist though, but in either case, the apt-get would then fail because DNS resolution would be horribly broken...
[15:10] <cjwatson> Right, you'd think
[15:10] <cjwatson> And netcfg doesn't *seem* to have fallen over in a heap earlier
[15:10] <stgraber> psivaa: can you easily reproduce this? if so, can you let me know when you have a machine that just got that problem (and is still in d-i)?
[15:10] <GridCube> smartboyhw, http://irclogs.ubuntu.com/2013/02/11/%23xubuntu-devel.html#t21:49
[15:10] <smartboyhw> GridCube, I knew.... I looked at the meeting logs
[15:11] <GridCube> :D
[15:11] <cjwatson> so ... why did nobody report this to ubuntu-cdimage?
[15:11] <cjwatson> ah, only two days ago
[15:11] <cjwatson> GridCube,smartboyhw: Shall I take this as a request to change the limit in our code?
[15:12] <smartboyhw> cjwatson, 1. Ask knome for official confirmation please
[15:12] <GridCube> cjwatson, please do ask kees
[15:12] <psivaa> stgraber: i am trying the amd64 image to confirm the issue, and will let you know if it hits the issue
[15:12] <stgraber> psivaa: ok, thanks
[15:12] <GridCube> s/ kees / knome
[15:12] <smartboyhw> I don't want to get killed for confirming things
[15:12] <cjwatson> knome: ^-
[15:12] <smartboyhw> While I am not even  a Xubuntu guy
[15:13] <GridCube> its going to happen anyway though, but i can't wear knome's hat
[15:18] <cjwatson> knome: I have the patch for the above once approved
[15:20] <plars> cjwatson: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1124214 is the latest bug for alternate not working under virtualbox, and I believe it to be similar to the situation I was seeing in the build you made yesterday but we are still at 20120211 for the desktop builds.  Is there going to be a respin for desktop at some point too?
[15:20] <ubot2> Ubuntu bug 1124214 in xorg (Ubuntu) "X does not start on alternate after installing in virtualbox" [Undecided,New]
[15:21] <cjwatson> plars: Yes, I will be respinning desktop
[15:21] <cjwatson> But I would like to understand the incomplete-language-support thing first
[15:21] <plars> cjwatson: that's next on my list
[15:22] <cjwatson> I'm trying to reproduce it locally now
[15:33] <plars> cjwatson: the bug with syslog attached is bug #1124230
[15:33] <ubot2> Launchpad bug 1124230 in language-selector (Ubuntu) "Language selector comes up after 12.04.2 rc candidate installation in english" [Undecided,New] https://launchpad.net/bugs/1124230
[15:41] <slangasek> skaet: the original comment from smoser said "opting in for cloud-images and for server ISOs"; doesn't that imply server image generation should also be paused?
[15:41]  * ScottK would think so.
[15:43] <smoser> server team is not opting-in for server ISO.
[15:43] <skaet> slangasek,  my understanding from him was AMI's not ISO's - but its best that smoser comment directly.
[15:43] <smoser> sorry for confusion there.
[15:44] <skaet> thanks smoser
[15:44] <smoser> we were considering ISO, but will instead simply have a call for testing of a daily.
[15:48] <cjwatson> plars: Did you say you saw this on desktop too?  I'm not seeing it
[15:49] <plars> cjwatson: not so far, but if its similar to bugs like this we've seen before, it may not happen every time
[15:49] <slangasek> skaet, smoser: ok, all clear now, thanks
[15:51] <cjwatson> plars: Well, the proximate cause here is in pkgsel, which isn't code that's directly in the desktop image
[16:28] <psivaa> stgraber: i did not see the ltsp issue on the next amd64+mac installation
[16:29] <psivaa> the amd64 installation did not complain but i can not restart the VM (using vbox) most probably due to the bug plars posted above
[16:43] <cjwatson> plars: aha, got it
[16:44] <cjwatson> Knew it looked vaguely familiar somehow :)
=== xnox is now known as foxtrot
[16:45] <plars> cjwatson: oh?
=== foxtrot is now known as xnox
[16:48] <cjwatson> Fix on its way
[16:51] <cjwatson> slangasek,stgraber: ^- could I have urgent review of that for 12.04.2?
[16:51] <cjwatson> Riddell,ScottK: How goes verification of kde-workspace?
[16:52]  * ScottK looks at Riddell
[16:52] <cjwatson> (I know it hasn't built on ARM/powerpc yet)
[16:52]  * ScottK is tied up with $WORK ATM.
[16:52] <Riddell> sorry got distracted by raring alpha 2
[16:52] <Riddell> I'll get back to 12.04.2 now
[16:53] <cjwatson> Let me know if you need a custom image build with -proposed
[16:53] <stgraber> cjwatson: I'm happy to review but can't accept myself (not SRU team)
[16:54] <Riddell> should be fine just installing on a live image and log in with a new user
[16:55] <stgraber> cjwatson: is the fact that the variable type will change from a list to set cause a problem later on?
[16:55] <stgraber> cjwatson: as in, should it be list(set( instead of just set( ?
[16:56] <cjwatson> Addressed in the regression potential section of the bug :)
[16:56] <cjwatson> And no - the only way that variable is used is by feeding it straight to sorted()
[16:56] <cjwatson> Which takes any iterable
[16:56] <stgraber> hehe, hadn't looked at the bug yet, sorry
[16:56] <cjwatson> Sorry, forgot (again) you weren't SRU team
[16:56] <stgraber> so yeah, perfectly safe if it's just sent through sorted()
[16:57] <cjwatson> It's a straight cherry-pick from quantal and I double-checked the context
[16:57] <ScottK> cjwatson: We should fix stgraber not being on the SRU team.
[16:57] <cjwatson> We should
[17:03] <cjwatson> bdmurray: Might you be around to review language-selector/precise for me?  (See above)
[17:05] <cjwatson> Once kde-workspace is verified and copied, and language-selector is reviewed, verified, and copied, we can start respins
[17:10] <Riddell> cjwatson: kde-workspace verified!
[17:10] <Riddell> bug 1123126
[17:10] <ubot2> Launchpad bug 1123126 in kde-workspace (Ubuntu Precise) "12.04 plasma init script order wrong" [Critical,Fix committed] https://launchpad.net/bugs/1123126
[17:18] <plars> cjwatson: on the X problem I'm getting after intsalling alternate, I didn't realize, but Sarvatt pointed out that the 20120213.1 respin of alternate didn't have the libpciaccess0 fix in it. So when that respins it *should* work, but I'm still a bit leery on desktop because of the image I tested for you yesterday which had other problems.
[17:19] <plars> as soon as we get the official respins of both, I'll take another look of course
[17:20] <bdmurray> cjwatson: looking at it now
[17:24] <bdmurray> cjwatson: accepted
[17:25] <psivaa> stgraber: i have a machine with ltsp install failure with amd64+mac image, if you'd like  me to try anything with it
[17:26] <stgraber> psivaa: ok, from a shell, can you do "ls -l /target/etc/resolv.conf" and "ls -l /run/resolvconf/"?
[17:27] <smoser> utlemming, can you please provide slangasek with list of amis to populate tracker with ?
[17:27] <smoser> and then have test done on those ? if you think we're ready for that.
[17:32] <psivaa> stgraber: "wxrwxrwx 1 root root  29 Feb13 16.41 /target/etc/resolv.conf -> ../run/resolvconf/resolv.conf" for the first one but "/run/resolvconf/: No such file or directory" for the second
[17:33] <stgraber> ok, the latter is the problem, though it's not an actual LTSP problem
[17:33] <stgraber> (and as mentioned earlier, may cause a lot more problems as it essentially means you don't have DNS resolution in there...)
[17:34] <stgraber> psivaa: can you pastebin: "ls -l /target/run" and "ls -l /run" (oh, and "ls -l /run/resolvconf" if it exists)?
[17:35] <utlemming> smoser: yes, I'll populate the tracker now
[17:35] <utlemming> slangasek, smoser: I have the ability to populate the tracker
[17:37] <utlemming> smoser, slangasek: populated
=== yofel_ is now known as yofel
[17:39] <psivaa> stgraber: ok, in a minute, have to find a way to get those information from the console
[17:39] <stgraber> psivaa: are you using libvirt?
[17:39] <psivaa> stgraber: no this is on a real hardware
[17:40] <stgraber> psivaa: ah, ok, you can go with something similar though.
[17:40] <stgraber> psivaa: on your machine, do: nc -l 1234
[17:40] <stgraber> psivaa: on the test machine do: <command> | nc <ip of your machine> 1234
[17:41] <stgraber> that'll simply redirect the command's output over the network, you can then copy/paste it or even pipe it straight to pastebinit
[17:48] <psivaa> stgraber: thanks for that, https://pastebin.canonical.com/84560/
[17:59] <knome> cjwatson, yes, xubuntu wishes to switch to a 1GB image starting from Raring.
[17:59] <knome> cjwatson, tell me if you need something else from me (please include nick so i'll notice). i thought infinity did something already, but not sure what exactly.
[18:00] <cjwatson> knome: Not that I can see.  I've made that size limit change for you.
[18:00] <cjwatson> Oh, BAH
[18:00] <cjwatson> infinity: Please don't make that kind of change only on the deployment branch
[18:00] <knome> cjwatson, ok, cheers! :)
[18:01] <skaet> slangasek,  https://wiki.ubuntu.com/RaringRingtail/Alpha2/CommonInfrastructure - can you please review and update as needed any changes for the foundations portion.   It will get pulled into Kubuntu and Ubuntu Cloud release notes for Alpha 2.
[18:02]  * cjwatson resolves the slightly different approaches infinity and he had taken
[18:04] <stgraber> cjwatson: ok, so it looks like the problem is that in some cases we get /target/etc/resolv.conf as the usual symlink, pointing to /run/resolvconf which apparently exists! in /target but doesn't in /run, so the bind-mount of /run essentially hides it
[18:04] <cjwatson> Perhaps the cheapest fix for now is a mkdir -p /run/resolvconf just before that in-target?
[18:05] <cjwatson> It's a bit of a hack, but ...
[18:06] <stgraber> cjwatson: yeah, I guess that'd work, assuming nothing tries to use the network from within the target after that
[18:06] <stgraber> (I don't think we do in LTSP, but something else might)
[18:07] <cjwatson> I don't think it can make the situation worse?
[18:07] <stgraber> nope, won't make it any worse :)
[18:07] <stgraber> I'll upload that hack now
[18:08] <cjwatson> Ta
[18:14] <stgraber> cjwatson: uploaded and paperwork done
[18:15] <stgraber> psivaa: oh, were all the failing installs happening when you had no network?
[18:15] <stgraber> psivaa: (just went through the initial syslog and noticed DHCP timing out)
[18:16] <slangasek> skaet: we agreed at UDS that we weren't going to do "common" release notes via includes anymore except for documenting bugs
[18:17] <slangasek> skaet: Secure Boot is certainly not relevant on cloud images, and is not a new feature in raring at all
[18:22] <cjwatson> stgraber: Ah, heh, I'd been envisioning just mkdir -p without in-target, but as it happens since there's a bind-mount this should work too ...
[18:23] <cjwatson> stgraber: please fix in raring too?
[18:23] <stgraber> cjwatson: yeah, I figured that doing it through in-target would guarantee that it always get created at the right place (whether the bind-mount works or not)
[18:24] <stgraber> cjwatson: I'd rather fix the actual bug in raring than upload the workaround and increase our delta with Debian
[18:24] <cjwatson> Fair enough
[18:24] <cjwatson> Accepted for precise, thanks
[18:25] <stgraber> cjwatson: (not to mention we don't actually use that code path as we don't have alternate, only some weird people using netboot can still use those bits)
[18:25] <cjwatson> True
[18:25]  * cjwatson gets https://launchpad.net/ubuntu/+milestone/ubuntu-12.04.2 into sync with reality
[18:27] <cjwatson> plars: Curious, I could have sworn I'd included the new libpciaccess, but you're right
[18:28]  * cjwatson → dinner
[18:29] <cjwatson> I'll verify language-selector after dinner
[18:34] <jdstrand> weird
[18:34] <jdstrand> https://launchpadlibrarian.net/131163934/upload_4291631_log.txt
[18:34] <jdstrand> INFO lxsession-edit_0.2.0-3ubuntu1_i386.deb: Version older than that in the archive. 0.2.0-3ubuntu1 <= 0.4.9.1~git20120828-0ubuntu1
[18:34] <jdstrand> but I can't find 0.4.9.1~git20120828-0ubuntu1 anywhere
[18:40] <skaet> slangasek,  common before was one page (Technical Overview) that had all the flavors on it ie;  https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Alpha3.   This is just a common section that can be embedded in each flavor announce page - so they get the common facts accurate, and all don't have to figure out the kernel version, etc.
[18:41] <slangasek> skaet: and the decision at UDS was to not do this include because the content is not actually common
[18:42] <slangasek> the commonality between edubuntu and ubuntu is completely different from the commonality between ubuntu and kubuntu, or ubuntu and ubuntu-server
[18:52] <jdstrand> ok, 0.4.9.1~git20120828-0ubuntu1 corresponds to lxsession afaict, and it ships an lxsession-edit
[18:52] <jdstrand> so I'll follow up with the uploader
[18:55] <skaet> slangasek, same kernel and foundation projects.   Agree secure boot is not relevant on cloud images.   Left it there, since it wasn't working for Kubuntu for 12.10,  so its new to them.  But agree it probably shouldn't be in common, since it isn't relevant to the cloud ones.
=== bjf is now known as bjf[afk]
=== henrix is now known as henrix_
=== henrix_ is now known as henrix
=== henrix is now known as henrix_
[20:26] <psivaa> stgraber: I am sure the failure on the second attempt was when there was no network ( comment #7) in the bug, but i am not really sure if that's the same case in the first attempt which i used to report the bug
[20:26] <stgraber> psivaa: you didn't have network in the first one (or so says the log)
[20:27] <psivaa> stgraber: ahh ok :)
[20:30] <plars> stgraber: so on ltsp, I'm able to get the server side fully installed now, but the client is only getting as far as plymouth.  I've not tried on hardware yet, only in kvm and virtualbox with networking setup as recommended in the test case.  That should work though right?
[20:30] <stgraber> plars: it worked in kvm here yesterday
[20:31] <stgraber> (with server and client being both in kvm, two interfaces on the server, one to the internet, one to an isolated network with the other vm)
[20:32] <plars> stgraber: that's what I'm doing, are you calling kvm directly or using something like virt-manager?
[20:32] <stgraber> plars: through libvirt
[20:32] <stgraber> plars: both VMs used cirrus graphic if that somehow matters
[20:33] <plars> stgraber: that was for an older bug that doesn't seem to be affecting me here
[20:35] <plars> stgraber: I'll try it again when we get the respins I suppose, I've not done much with libvirt and I'm not sure I trust vbox until the libpciaccess fix is included
[20:36]  * cjwatson is back (subject to filial whims) and attempting to verify language-selector
=== bjf[afk] is now known as bjf
[21:17] <antarus> cjwatson: so when is ubuntu switching to systemd?
=== Noskcaj is now known as Noskcaj_IsAtScho
=== Noskcaj_IsAtScho is now known as Noskcaj_Schooll
=== Noskcaj_Schooll is now known as Noskcaj_School
[21:19] <cjwatson> Are you trying to distract me from 12.04.2? :)
[21:19] <infinity> antarus: I'm going to assume that was trolling? :P
[21:20] <mdeslaur> antarus: right after RHEL switches to Unity :P
[21:20]  * mdeslaur can troll too
[21:21] <cjwatson> stgraber: So LTSP is the last thing outstanding - how are things looking?
[21:21] <stgraber> mdeslaur: well, they already use upstart ;)
[21:22] <stgraber> cjwatson: well, the only easy way to test it is to spin images, so I'm inclined on marking verification-done and doing real testing once we get medias that psivaa can test
[21:23] <stgraber> my standard way of patching those things during install relies on me having network and it looks like this bug happens only in networkless environment making things much trickier than usual
[21:25] <stgraber> cjwatson: I can run a sanity check of the standard install path though if that makes you feel better :)
[21:26] <antarus> mdeslaur: I'm not really trolling, is there a handy FAQ about it?
[21:26] <antarus> cjwatson: I dunno, are you looking for a distraction? ;p
[21:27] <slangasek> antarus: we have no plans to switch to systemd. Getting too much Lennart kool-aid? :)
[21:29] <antarus> slangasek: I think we had bad experiences with hardy / lucid upstart, and now that we know it better..we are looking for more bad experiences?
[21:29] <antarus> slangasek: its simply a common question that we get asked from our engineers ;)
[21:29] <slangasek> heh
[21:29] <psivaa> stgraber: will adding apt-setup/proposed=true help verify from proposed?
[21:29] <antarus> I am actually going to start an unofficial internal faq that might hold this answer (and other, google-specific answers)
[21:29] <mdeslaur> antarus: here: http://www.markshuttleworth.com/archives/1121
[21:30] <slangasek> antarus: shall I draft you an answer about plymouth for the faq? :)
[21:30] <slangasek> or has Marc Merlin stopped asking about that? ;)
[21:31] <stgraber> psivaa: hmm, I may be wrong but I think this flag will only change the system's sources, it won't tell d-i to use -proposed as the udeb source
[21:31] <antarus> slangasek: hahaaha hahahah haha haa....
[21:31] <cjwatson> stgraber: You're wrong :)
[21:31] <antarus> mdeslaur: helpful, thanks
[21:31] <cjwatson> I hacked it up to work for udebs too
[21:31] <antarus> slangasek: Marc still hates plymouth
[21:31] <antarus> slangasek: I think even Gentoo is switching to Plymouth though
[21:31] <stgraber> cjwatson: oh nice
[21:31] <antarus> we are using bootsplash right now, which is unmaintained, there is a thread on gentoo-dev about it
[21:32] <antarus> ;p
[21:32] <slangasek> ouch
[21:32] <stgraber> though in this case, there'd be little point setting this key as the bug appears only on internetless installs and so d-i wouldn't be able to pull the new udeb from the internet
[21:33] <stgraber> cjwatson: anyway, I'm running a standard LTSP install now, should have the result in a bit less than an hour (sorry, very slow core2duo instead as my nice i7 is a useless brick at the moment...)
[21:33] <stgraber> s/as/of/
[21:34] <stgraber> ah no, s/instead // :)
[21:38] <cjwatson> stgraber: OK.  I'll wander off for a while then and be back in a bit.
[21:38] <cjwatson> Actually.  I could probably start some images building
[22:06] <cjwatson> Right, respinning all precise images that contain X (for the libpciaccess fix) and that aren't Kubuntu (still waiting for kde-workspace to build everywhere) and that don't contain LTSP (so no alternates or DVDs, except Ubuntu Studio)
[22:06] <cjwatson> $ set -x; buildlive ubuntu daily-live precise && DIST=precise for-project ubuntu cron.daily-live; buildlive ubuntu-core daily precise && DIST=precise build-livecd-base ubuntu-core daily; DIST=precise SUBPROJECT=wubi buildlive ubuntu && DIST=precise for-project ubuntu cron.wubi; buildlive mythbuntu daily-live precise && DIST=precise for-project mythbuntu cron.daily-live; buildlive ubuntustudio-dvd dvd precise && ...
[22:06] <cjwatson> ... DIST=precise for-project ubuntustudio cron.dvd; buildlive xubuntu daily-live precise && DIST=precise for-project xubuntu cron.daily-live; UBUNTU_DEFAULTS_LOCALE=zh_CN buildlive ubuntu daily-live precise && DIST=precise build-chinese-edition; set +x
[22:21] <stgraber> cjwatson: LTSP is good to go, just had a working install here (so at least it's not regression the d-i code)
[22:22] <stgraber> I'll mark the bug verification-done in a sec
[22:22] <cjwatson> Ah, brilliant, thanks
[22:23] <cjwatson> No reproduction of the client problem plars reported?
[22:23] <stgraber> nope, client worked fine here, got a working unity session on it
[22:24] <stgraber> the server never started X though, but I'm blaming libpciaccess
[22:24] <cjwatson> stgraber: The libpciaccess fix I know about is in precise-updates ...
[22:24] <cjwatson> Well, I guess not if you were basing on the last alternate, though
[22:26] <cjwatson> And kde-workspace is very close to done
[22:26] <stgraber> cjwatson: right, I was installing from the latest alternate
[22:26] <cjwatson> Gotcha
[22:41] <cjwatson> stgraber: copied to -updates
[22:44] <Logan_> jdstrand: I think that the lxsession-edit migration issue makes sense, as it wouldn't want to copy it to raring from raring-proposed if it had a binary with a lower version than one provided by another source package.
[22:44] <Logan_> But I think a bug should be filed against lxsession to remove the lxsession-edit binary from that package, as it should be provided by the lxsession-edit source package, as it is in Debian.
=== james_ is now known as Guest49482
[23:35]  * cjwatson releases kde-workspace
[23:36] <cjwatson> I really hope that's the last one
[23:54] <plars> cjwatson: desktop on i386 still having some issues getting into live session that I'm not able to reproduce on amd64: bug #1124660
[23:54] <ubot2> Launchpad bug 1124660 in xorg (Ubuntu) "Precise 20120213 i386 live session fails in virtualbox" [Undecided,New] https://launchpad.net/bugs/1124660
[23:54] <plars> Sarvatt: ^
[23:55] <cjwatson> OK, I think we knew virtualbox was likely to still be broken
[23:55] <cjwatson> As long as it's virtualbox-specific I'm not going to consider it a blocker at this point; the last fix got in because it affected i915 too
[23:55] <cjwatson> Just not enough time ...
[23:56] <plars> cjwatson: yeah, I haven't had a chance to try it on hardware yet, but I'll be doing that this evening
[23:57] <cjwatson> Sarvatt: I'd appreciate a release note written by one of the X cabal about this
[23:57] <cjwatson> In /CommonInfrastructure I guess
[23:58]  * plars -> supper, then back for more iso testing