[00:01] * phillw just what we need in a testing cycle.... sarcasm [00:13] micahg: Did your ubuntustudio-default-settings forget a Pre-Dep on a dpkg that supports maintscript-helper, or was it already there? [00:15] micahg: Ahh, nevermind, it was already there. [00:26] skaet, ETA on images dropping? [00:27] pgraner, they've started posting now. alternates and server are all up [00:27] * pgraner needs to plan his drinking accordingly [00:28] pgraner: That's some solid prioritizing. [00:28] :) [00:28] infinity, dude two nights of late drops... you're lucky I can type [00:28] pgraner: Timezone shift, man. Drink in the morning, work at night. [00:28] pgraner: As a former manager of mine used to remind me, "it's always happy hour somewhere." [00:29] ubuntu alternate, ubuntu dekstop, ubuntu server, ubuntu server arm should all be up. ubuntu preinstalled arm are building now. [00:29] ubuntu dvd will be a while. [00:29] infinity, I look at the whole day/night drinking times as limitations, I don't like being limited [00:29] LOL [00:30] skaet, yep they are rolling in, I'm doing ARM first, then alternate, and desktop last [00:30] pgraner, sounds good. flag here if any ugglies. [00:31] * skaet crossing fingers no ugglies. [00:34] slangasek: oho, aptitude 0.6.6-1 [00:34] hmm! [00:35] cjwatson: are you going to merge it? [00:35] can do though not tonight [00:35] ok, cool [00:35] * slangasek assigns you the bug then ;) [00:36] <- sucker [00:38] Oo. [00:38] It has the magical m-word. [00:42] stgraber, only selected images being published are being reported in the channel. Anything special needs to be done? [00:46] * infinity wonders idly where he can find 13MB to drop off the Ubuntu/PPC image. [00:50] skaet: the bot was disconnected after flooding freenode earlier [00:50] stgraber, gotcha. thanks. [01:25] added an hack to delay messages a bit to avoid being kicked out [01:27] that maas-enlist change is kind of important to avoid a rather obvious error [01:27] I've reviewed and accepted it [01:28] if pad.ubuntu.com will talk to me ... [01:30] hm, server was already built in this round [01:30] so I guess it's up to the server leads to ask for a respin if they want one [01:31] It was only *just* rebuilt, spinning it again wouldn't be world-ending, I bet. [01:31] And that bug seems annoying. [01:32] As well as the bug described, the particular manifestation of it will include the maas-enlist-udeb installer step failing with a red screen, I think. [01:32] cjwatson: does d-i output 'question will be asked' even if a response is in the preseed? [01:33] * hggdh sees an error on server raid, seemingly because of that [01:35] hggdh: Not normally. Point me to details? [01:36] cjwatson: we run, under Jenkins, the ISO tests for server. For the new ISO, I got a failure on the RAID test. Looking at the current (failed) syslog, I see a 'question will be asked'. Since I look for it, I cancelled the run automatically [01:36] Do you have a URL for me? [01:37] cjwatson: but looking at the *previous*, successful, run, I also see a 'question will be asked' [01:37] yes [01:37] cjwatson: https://jenkins.qa.ubuntu.com/view/Precise%20ISO%20Testing%20Dashboard/view/Daily/job/precise-server-amd64_raid1/126/console [01:38] the full syslog is in here: https://jenkins.qa.ubuntu.com/view/Precise%20ISO%20Testing%20Dashboard/view/Daily/job/precise-server-amd64_raid1/126/artifact/126/test-results/ [01:43] hggdh: Well, firstly, grub-pc/install_devices isn't preseeded (perhaps you're thinking of grub-installer/bootdev). But it shouldn't be preseeded anyway. [01:46] hggdh: Secondly, this question is INPUTted in a kind of weird environment, and (although I can't see precisely why right now) it's quite possible it might say "question will be asked" when it in fact won't be. If I were you I would disregard that one unless it's actually causing an automatic install to hang for itself. [01:47] cjwatson: thanks. I will correct the code so that it will only fail the test if we are stuck on a [01:47] It is a bit weird, but debconf debugging was designed for human consumption rather than machine :-) [01:47] 'question will be asked' right now. Later on I will look at the first point you made [01:47] Well, the first point doesn't contain any action for you [01:48] Your preseed looks fine from this point of view [01:48] even better :-) [01:48] this is a timing error on my code, then (and the first time since jaunty (when we added this test) that it happened [01:48] If it actually hangs, obviously, I'd like to know about it [01:49] ack [01:50] looking at the successful log, this is something to do with passthrough weirdness, indeed [01:50] https://jenkins.qa.ubuntu.com/view/Precise%20ISO%20Testing%20Dashboard/view/Daily/job/precise-server-amd64_raid1/125/artifact/125/test-results/d-i-syslog.log.gz [01:51] after the first "INPUT high grub-pc/install_devices", there's some fiddling around with DATA (which transfers template information from one debconf frontend to another) and SUBST, and then it reissues the INPUT [01:51] the second time, it gets "question skipped" [01:53] k [01:53] Oh, of course, this is a consequence of debconf-apt-progress [01:54] Sorry, for extremely limited values of "of course" probably confined to the person who wrote the code [01:54] :-) [01:54] I'll explain in case anyone cares [01:54] Just so as this little borg drone knows before he goes for regeneration cycle, how are the respins going? [01:54] debconf-apt-progress deals with bridging apt download and install progress bars into debconf progress bars so that they can be displayed nicely, particularly in the installer [01:55] This involves two instances of debconf, one for the progress bar and one passing through questions from the package(s) being installed [01:56] (Not to mention cdebconf, which runs in the installer environment and is what actually displays everything - they're all chained together in a way that took me weeks to get working to start with but now I just ignore it most of the time) [01:57] Now, it's painful to run two instances of debconf normally, because they both want to lock their config database when they start up [01:58] So what you do is you take the one that passes through questions from the package being installed, and give it a database which amounts to /dev/null; it just shunts everything over to the instance that's running the progress bar [01:58] This means that the debconf instance that *first* sees the INPUT command here has no idea that the question has been preseeded [01:59] It isn't until it forwards it to the second one, which actually has a database worth talking about, that it knows about the preseeding so you get "question skipped" [01:59] ah [02:00] This certainly makes machine parsing challenging, but that was never in the plan for that debug output :-) [02:00] So I don't feel too bad about it [02:01] heh. It will be easy to fix my code, anyway -- just compare previous 'question will be asked' line with the current -- if they are the same, then we are stuck [02:01] * cjwatson idly notes that debconf-apt-progress is one of the few debconf programs nobody has got round to reimplementing for cdebconf yet ... [02:01] cjwatson: I do not suppose that any time soon you could explain that for us mere mortals? But, if you have got the handle on it & we will have isos, I trust in you guys just as I trust in MOTU's. [02:01] phillw: I think that was the best I could do without a whiteboard [02:03] As for respins, the desktop/DVD sequence seems to be working on Lubuntu at the moment [02:03] now with tested anti-flood protection, hopefully it won't get kicked out any time soon [02:03] or rather the desktop sequence, looks like DVDs are being done in parallel with that [02:04] skaet: any particular reason bug 959224 is listed as a target of opportunity? I don't plan to look at that this week. [02:04] Launchpad bug 959224 in choose-mirror "Corrupt value for /etc/apt/apt.conf accepted during installation" [Medium,New] https://launchpad.net/bugs/959224 [02:05] It's only a validation bug; certainly a bug but there are more important things and it doesn't block installation [02:05] cjwatson: I am guilty, it just seems a really silly bug [02:05] Sure, but it shouldn't be tracked here [02:06] cjwatson: it does not, but it blocks updates [02:06] Only if you entered it wrongly during installation. It doesn't block otherwise. [02:06] What I mean is it isn't a blocker for everyone, or even most people. [02:06] cjwatson, noted it there from earlier discussion, wasn't sure. remove it if you're not looking at it, no worries. [02:07] cjwatson: it was only a suggestion, as it may have tied in with the wriong mirrors being suggested. [02:07] Wrong mirrors being suggested? [02:07] (Bug#?) [02:08] cjwatson: sorry, seems to be same bug [02:08] phillw: OK, well, that bug only affects the proxy setting [02:09] I'm happy to try to fix it for final if I have time [02:09] Though it's very unlikely to be new; I suspect it goes back a long way. [02:12] cjwatson: both lubuntu and another flavour reported it. [02:13] cjwatson: remove that, the bug 966450 [02:13] Launchpad bug 966450 in debian-installer "Kubuntu doesn't prompt for a password on encrypted LVM boot (dup-of: 966403)" [Undecided,New] https://launchpad.net/bugs/966450 [02:13] Launchpad bug 966403 in debian-installer "Lubuntu Install (entire disk with encryption) doesn't prompt for disk password." [Undecided,New] https://launchpad.net/bugs/966403 [02:14] which is an install bug [02:15] FWIW I did such an installation earlier today (or was it yesterday?) and it was fine [02:15] It's actually probably not an installer bug [02:16] That's first boot, so it's more likely to be cryptsetup or plymouth or something [02:16] * cjwatson sends it over to cryptsetup as a first pass [02:18] (which for the avoidance of doubt means somebody else will probably need to figure it out ...) [02:18] cjwatson: do you have the time to set the bugs as such and see if it comes back? I've seen reports of encryption bugs earlier & would like to clear the ground on them. Thanks. [02:18] "set the bugs as such"? don't understand, sorry [02:21] cjwatson: well, either fix released, or needs more information? The two bug reports have a lot of data, but if there has been a release that retrospectively makes them invalid, then a simple "please check with latest release" will suffice? [02:21] I don't think that would be appropriate; he only just reported it [02:22] and I don't know what information is needed, not being a cryptsetup expert and being fairly rusty on plymouth [02:22] so it's best if somebody else looks [02:23] "fix released" would certainly be wrong since (a) chances are it's just that it happens on his system and not mine for some reason or other (b) even if it had been fixed I can't point to the fix [02:24] * slangasek reassigns to plymouth [02:24] cjwatson: has there been any testing of encrytpted in ubuntu [02:24] slangasek: right :) [02:24] phillw: I test it every time I reboot [02:24] phillw: it's on the routine test cases so it's tested at every milestone [02:26] but it's important to be aware that this kind of thing can easily be hardware-specific [02:26] cjwatson: slangasek in which case, how do these bugs arrive? Please do understand that I am really new & trying to learn [02:27] even successful testing doesn't immunise you from hardware-specific problems [02:27] or the category of problem described by http://en.wikipedia.org/wiki/Race_condition [02:28] which sadly makes for the majority of these annoying bugs... [02:29] plymouth (the software that handles input/output multiplexing at boot, and also displays a splash screen) takes some quite different code paths dependent on the graphics card, for instance, and is also more prone than most to delicate race conditions that take ages to track down [02:29] cjwatson: I saw that as bug earlier, I'm gradually getting used to this weird and wonderful language you speak in :) [02:32] I'm pretty much barred from speaking about the installing of 'strict' GTK3 rules. But I am getting better to understand that #shit happens# [02:33] how you guys do this? WOW [02:35] http://people.canonical.com/~ubuntu-archive/pending-sru.html <- "The following packages have an equal or higher version in the release pocket and should be removed from -proposed:" [02:35] whee [02:35] (hand-checked and processed) [02:36] I do wish lp-remove-package.py would tell you about the pocket it's removing from in its output. Always gives me heartattacks. [02:38] * skaet just goes to look at the link. :) [02:39] looking good cjwatson. :) [02:40] * skaet --> evening dog walk, biab [02:50] Is anyone with cocoplum access still using any of the old crap in ~lp_archive/python/? [02:51] I'm not seeing anything likely elsewhere in ~lp_archive/, and I strongly suspect it's all been superseded by launchpadlib-based stuff in ubuntu-archive-tools. [02:51] not me [02:52] I'll nuke it tomorrow morning unless somebody shouts that they care. Speak now or forever hold your peace. [03:04] cjwatson: Not I. [03:06] cjwatson: Also, regarding lp-remove-package.py heart attacks, I could have sworn someone filed a bug about better verbosity, like, 6 years ago. But I can't find it. [03:57] pitti, infinity, only images left to come off the builder are wubi, and ubuntu mx5/ac100 kubuntu omap4. pad has been updated. [03:57] good night. [03:57] * skaet --> zzz [04:17] stgraber: queubot's seeing double. [04:17] infinity: please tell me that is a joke..... [04:17] stgraber: (See all the double entries for mosh) [04:18] stgraber: Or, triple... [05:10] Good morning [05:30] morning pitti [06:04] * pitti accepts the -proposed uploads [06:10] ogra_, is the TI icon supposed to be in the launcher on omap4 desk top? [06:11] everything else in unapproved is seeded somewhere [06:43] pitti: if I use mass-sync.py to sponsor some bug fixes sync from debian (and for universe), that won't bypass the freeze, isn't it? [06:43] didrocks: I don't know about mass-sync; why not just use syncpackage? [06:43] didrocks: in the past, syncs from cocoplum went straight through, without being held in unapproved [06:44] pitti: can use syncpackages with -n -e options [06:44] pitti: I guess it's not very important for 2 packages in universe, right? [06:44] didrocks: -s for sponsoring, please [06:45] ah ok, yeah, seeing -s :) [06:45] -n/-e are for --no-lp syncs [06:45] ok ;) [06:50] so, it's in unapproved :) [08:02] pgraner, theoretically yes, practically i dont think anyone but tobin has teswted desktop in a while and technically we planned to switch to jockey for the driver and just add a wiki page for the codecs from the PPA [08:02] (in which case we dont need the icon anymore) [08:04] the latest pvr drivers are sitting in NEW so they wont make beta2, the old ones in the PPA are broken, so the icon is moot anyway atm [08:04] (broken for precise) [08:42] infinity,stgraber: not so much seeing double, as misrepresenting binary as source. [08:42] didrocks: mass-sync.py is decommissioned for everything except backports. (I forget whether I actually made it not work for syncs.) [08:45] cjwatson: ah, thanks for the hint, I'll have a look at the wiki page later and probably make a note if not there already [08:48] aha, I actually made mass-sync.py call syncpackage if you try. [08:49] But mass-sync's interface is kind of awkward so you might as well call syncpackage directly (preferably without --no-lp). [08:49] ah, it was a trap then! :) [08:49] (btw, I still have syncpakcage running and not closing the sync bug until the universe sync is approved) [08:50] * cjwatson will be starting work properly in a few minutes and will look then [08:54] pgraner, what is the bug you tracked as bug 966858 on the tracker, LP gets me to an error page for it [08:58] (and given it seems to block the panda images it would actually be good to know what it is) [08:59] didrocks: ^- [08:59] cjwatson: thanks :) [09:24] * ogra_ wonders why oem-config always takes so long to come up ... the ac100 usually gets you to lightdm in less than 15sec from powering on ... the installer takes about 2min to start ubiquity-dm [09:26] mvo: doesn't skype-bin need to be Multi-Arch: foreign? [09:37] cjwatson: ups, yes you are right, let me fix this [10:33] cjwatson: Ahh, were those binary NEW with translations, by any chance? stgraber was having issues making those DTRT. [10:33] infinity: Not sure at this point. [10:34] cjwatson: Hrm, no they're not. [10:34] cjwatson: So, a regression while he was trying to fix the other case, I guess. :P === wgrant_ is now known as wgrant [11:08] cjwatson: I will upload a new skype in a bit with the missing multi-arch: foreign and also with a conflicts/replaces for skype-bin on older skype versions. anything else you can think of that I may have missed? is the general direction sensible for the lucid->precise skype upgrade or do you have a alternative idea that might work, the -bin package is a little bit ugly [11:11] mvo: that was all I noticed. Also Breaks/Replaces rather than C/R I think [11:12] thanks! [11:42] ogra_, https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/966858 [11:42] Launchpad bug 966858 in gnome-settings-daemon "[power]: gnome-settings-daemon crashed with SIGSEGV in gnome_rr_screen_get_dpms_mode()" [Undecided,New] [11:43] pgraner, oh, i filed the same yesterday, funny that apport didnt point you to it [11:43] but given it respawns fine, why did you mark the image failed ? [11:44] its surely a wart (like the missing icon) and should be noted in the release notes ... but the image generally works [11:46] i.e. "good ehough for a beta" [11:46] *enough [12:39] no images listed for testing http://iso.qa.ubuntu.com/qatracker/milestones/210/builds/14369/downloads [12:40] Riddell: for which milestone should that be? [12:40] err, image [12:40] http://iso.qa.ubuntu.com/qatracker/milestones/210/builds has quite a lot [12:41] pitti: for ubuntu desktop beta 2 armhf+omap4 [12:42] Mm, I think it just doesn't know the URLs. [12:42] I think so too [12:43] should be http://cdimage.ubuntu.com/daily-preinstalled/20120328/precise-preinstalled-desktop-armhf+omap4.img.gz [12:43] * Riddell eyes up pitti as a member of the ubuntu desktop team who has powers to add them [12:44] He does? It needs DB access. [12:44] I think. [12:44] no it's all improved [12:44] just needs admin access to that site === bladernr_afk is now known as bladernr_ [12:44] oh maybe so, I was logged out [12:45] I can do it then [12:45] looking [12:46] pitti: I'm on it, unless you want to [12:46] cjwatson: ah, thanks [12:46] I just found where to set that [12:46] so, please go ahead [12:51] OK, it's pretty cumbersome and manual, but done for armhf+{omap4,omap} [13:01] is a release sprint happening this release? how do I get invited along? [13:03] https://wiki.canonical.com/UbuntuEngineering/Sprints/PreciseReleaseSprint [13:08] cjwatson: lovely, and I get invited along by just putting my name on there and magically a hotel room will be allocated to me? [13:10] ogra_, yea I agree [13:11] Riddell: I don't know, you should probably ask Kate [13:12] skaet: hello [13:27] * phillw sulks ... not allowed to even view https://wiki.canonical.com/UbuntuEngineering/Sprints/PreciseReleaseSprint [13:28] btw, was last night / this morning the final respin for beta 2 RC? [13:28] that's because it contains next week's lottery numbers [13:30] Laney: I recall a 0 day horror that had the devs attending the release party all locked up and respinning whilst the forum went into melt down with people screaming "Why is not released yet!".... I'll give it a miss :P [13:53] cjwatson: What was the upload from a few days ago for inclusion ? [13:54] from roaksox ? [13:59] Riddell, release sprint participation in london is being limited explicitly, we're looking into setting up a G+ hangout for those not able to be there in person. [14:00] Daviey: powernapd [14:02] ah [14:02] I didn't think it was critical for beta-2 TBH.. but ok. [14:03] That's fine, then just bump the bug milestone [14:03] phillw: it held next door to MI5 and opposite MI6 so it's pretty tightly controlled [14:04] phillw: there have been respins, we won't know if they're final or not until they are all tested to work correctly [14:17] skaet, we have a further (single) report of issues with aspm on the latest kernel. after long discussions we think it is better to leave things as they are and make sure its documented in the notes. this is based on the belief this may well be a bios issue, and that there should be work arounds we can document. therefore we would much prefer to leave the code in to find out if there any other [14:17] affected machines with a note in the release notes; all this for B2, using the results of that to make an informed decision for release [14:19] apw, please add the release note to the TechnicalOverview, along with bug number. if there are workarounds available, release note should be ok. We're getting to late to do another respin unless its a kitten killer. [14:20] skaet, yeah that was my feeling [14:22] apw, if things change as the testing emerges, flag me please. [14:22] skaet, ack [14:26] Riddell: thanks, we're just waiting on powerppc for lubuntu to be tested and we are good to go :) [14:28] jibel, any concerns on your list from the testing so far, other than the kernel bug ^ referenced? [14:30] pitti, cjwatson - pad is looking quiet, any concern areas showing up on your radars? [14:30] not from here [14:31] * skaet hopes the trend continues.... :) [14:31] thanks [14:32] all quiet on the western front so far [14:32] phillw, lubuntu test team rocks! just saw that almost all the images have been tested now. sweet. :) [14:32] skaet, nothing from me. [14:32] testing mac now [14:33] thanks jibel. :) [14:36] hi, shouldn't https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/913731 be a release critical bug? [14:36] Launchpad bug 913731 in plymouth "non-X installs still have vt.handoff=7" [High,Confirmed] [14:36] I just had a colleague tell me that ubuntu server installations have been broken for the last few weeks because he doesn't get a login prompt, and it's reasonable to expect that many, many ubuntu users will think the same when installing it [14:51] Daviey, ^ thoughts? [14:55] Riddell, did you get to test the panda image ? [14:55] looking [14:57] skaet: It's something i'm happy to release note for b2.. I don't think it's a blocker. I'd surprised I hadn't seen it myself TBH. :) [14:57] ogra_: yep [14:57] Riddell, aaaaand ? [14:57] Daviey, thanks. Release note it is. [14:57] cjwatson: I see bug 913731 is assigned to foundations, is it on your hit list for release? [14:57] Launchpad bug 913731 in plymouth "non-X installs still have vt.handoff=7" [High,Confirmed] https://launchpad.net/bugs/913731 === doko_ is now known as doko [14:57] ogra_: same bug in the graphics driver bug 961133 [14:57] Launchpad bug 961133 in linux "No video output from Ubuntu Desktop ARM Images on my Pandaboard to my DVI monitor" [Medium,Confirmed] https://launchpad.net/bugs/961133 [14:58] found a new monitor where it works using the other port at 640x480 [14:58] infinity, test rebuild started [14:58] Riddell, ohh, intresting, can you note that on the bug and also talk to robclark in #ubuntu-arm ot #pandaboard ? [14:59] ogra_: bug is updated, I can try pinging rob [15:00] highvoltage, could you take a pass at updating the https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview for Edubuntu? [15:01] Daviey: hmm, not right now, slangasek, what do you think? [15:01] slangasek: (913731) [15:02] skaet: will do [15:02] It's not critical but a nicety IMO. [15:02] thanks! :) [15:03] highvoltage: I'm currently in a meeting but I can have a look at the TechnicalOverview in an hour or so if you don't have time to look at it now [15:04] stgraber: thanks, I'll try to take a stab at it in the meantime. is it confirmed that we should include all the changes since the beginning of the cycle? [15:05] highvoltage: for Edubuntu, I'd prefer we do that yes, maybe hilight changes from beta1 but IIRC the only change is translation update and bugfix releases of epoptes and ltsp [15:07] Morning, I just created a FFe (bug 967195) to help resolve bug 965484. If a bug manager would be kind enough to help triage it, thanks [15:07] Launchpad bug 967195 in ruby-rack "FFe: Sync ruby-rack 1.4.0-1 (universe) from Debian wheezy (main)" [Undecided,New] https://launchpad.net/bugs/967195 [15:07] Launchpad bug 965484 in redmine "redmine : Depends: ruby-rack (>= 1.4.0) but 1.3.5-1 is to be installed " [High,Triaged] https://launchpad.net/bugs/965484 [15:12] pabelanger: bug triagers I think are in #ubuntu-qt and universe packages are maintained by MOTU who I think are in #ubuntu-motu [15:13] Riddell, yeah, that would help for sure, rob maintains the graphics drivers for the panda (sorry in meetings atm) [15:13] Riddell: right, but I though I needed somebody from ubuntu-release to first triage the FFe, before having somebody in MOTU sponsor the sync process [15:15] pabelanger: ah for the FFe yes that needs approval from ubuntu-release, but it'll be much easier if a MOTU has already commented on the bug "yes this is good we want it" [15:16] Riddell: okay, let me get that for you [15:50] stgraber: Did you look into queubot's confusion about binary NEW from last night? [15:51] stgraber: The queue entries that confused it (mosh, on a few arches) are still in oneiric-backports/new. [15:51] infinity: nope, I saw it in the backlog but haven't tried fixing it yet. I'm currently looking into an LTSP bug, then have the edubuntu techoverview to look at and the perf review stuff to get done (now that HR fixed my account). So I'll look at the bot this afternoon/evening [15:52] stgraber: Oh, yeah, not a priority by any means, was just curious if you caught the backscroll. [15:59] skaet: Would like to do a server rebuild in ~2 hours. If you are happy, I'll make sure all testcases are satisfied on the new build. [16:01] skaet: I'm off for TKD/dinner, etc.; will check back in after it to check for any new fires, but it seems rather quiet ATM [16:02] Daviey: We, the sufferers, will also test it ;-) [16:05] hggdh: What would we do without you? [16:05] suffer yourself indeed :) [16:05] thanks pitti. [16:06] Daviey, ok for the respin if it helps. [16:31] guys, a bit of bad news :( bug 967257 [16:31] Launchpad bug 967257 in lubuntu-meta "PPC Install CD from 28 Mar does not boot" [Undecided,New] https://launchpad.net/bugs/967257 [16:32] Lars is a good tester for mac stuff. If he says it's broken, it's broken. [16:32] Has he tested any other powerpc images successfully? [16:33] I'd like to know whether this is Lubuntu-specific for some reason. [16:33] Or any images from earlier? [16:33] I can have a look in qemu, but the download will take the best part of an hour and I suspect I'll have finished for the day by then. [16:34] So any narrowing down of where/when things broke would be helpful. [16:36] I've asked him. We did have working isos from ppc before. [16:36] I've asked for a bit more verbosity on "doesn't boot". [16:37] http://iso.qa.ubuntu.com/qatracker/milestones/210/builds/14310/testcases [16:37] cjwatson: bug #913731> so I actually sat down at the global jam and worked through this question; we have a tentative fix for plymouth, but I'm concerned that it could be racy [16:37] cjwatson: Possible that the default yaboot config might be aiming at powerpc instead of powerpc-smp? Though, I'm pretty sure I got every such case I saw. [16:37] Launchpad bug 913731 in plymouth "non-X installs still have vt.handoff=7" [High,Confirmed] https://launchpad.net/bugs/913731 [16:37] my guess would be that the iso does not get recognised as a boot CD [16:37] infinity: It's a good possibility [16:38] cjwatson: i.e., that having plymouth chvt carries a non-zero risk that installs *with* a GUI will get dropped to vt1 [16:39] I couldn't think of any other sensible approach, unfortunately :-/ [16:39] cjwatson: what about probing for a DM when deciding whether to put vt.handoff on the commandline? [16:40] (though this could go pear-shaped in a number of ways and I'm not keen to make this change late in cycle either) [16:41] Possible, but I have similar reservations; in particular it's quite possible for a DM to be installed after the last call to update-grub [16:41] yep [16:41] or removed [16:41] I'll grant you that that approach is better than hardcoding it at install time, though [16:42] dpkg triggers to the rescue? [16:42] possibly [16:42] Starts getting hairy [16:42] Combined with DMs shipping the vt.handoff bit as a config snippet, rather than grub doing it heuristically. [16:42] I don't want to introduce new triggers at this point [16:42] so the race I'm seeing is as follows: [16:43] - rc is nearly empty, so finishes first [16:43] Well, no triggers, then, just ship vt.handoff as a config snippet, and update-grub in DM postinsts. [16:43] - plymouth-stop is called with JOB=rc [16:43] - 'plymouth quit' runs and shuts down the splash screen [16:43] - DM starts up, sees no splash running, chvt and starts X [16:43] - plymouth-stop calls chvt [16:44] *maybe* 'plymouth stop' could do the vt switch itself, but that also makes me nervous [16:45] 'plymouth quit' I mean [16:46] Can we atomically say "chvt but only if we're on our own VT"? [16:46] I don't know [16:47] And also, yes, I thought 'plymouth quit' already chvted [16:47] probably not [16:47] and --retain-splash stayed on the same vt [16:47] yeah, let me dig into the code then and see [16:48] Doing the chvt outside of plymouth itself does seem doomed to raciness [17:08] if (terminal->initial_vt_number == terminal->vt_number) [17:08] { [17:08] ply_trace ("can't deactivate initial VT"); [17:08] return false; [17:08] } [17:08] that'll be it [17:10] so plymouth only handles a chvt on quit if it started on a different vt than the one it used for splash [17:11] seems fixable, but definitely needs some double-checking to make sure there are no races w/ the DM [17:16] phillw: Grabbing the lubuntu/ppc ISOs, I'll see if I can reproduce and/or debug after an early lunch. [17:17] infinity: thanks, Mars is grabbing the ubuntuppc - again about an hour. [17:20] can I get someone from -release to review bug 967320 before I forward to the MIR team? thanks! [17:20] Launchpad bug 967320 in xcompmgr "[MIR] Please promote xcompmgr to main for LTSP" [Undecided,New] https://launchpad.net/bugs/967320 [17:20] ^ is actually a FFe + MIR [17:20] (just updated the title now) [17:24] Huh, the Lubuntu powerpc image claims to be "3.2.0-18-powerpc" [17:24] Oh, sorry, false alarm, that's an out of date Ubuntu one [17:25] Current Lubuntu claims to be "3.2.0-20-powerpc-smp", which is correct [17:29] It's sitting at a black screen in qemu. Hard to tell if that's just slow or hung. [17:29] * cjwatson tries with --verbose [17:30] But at any rate, from the bug, this isn't the same thing. [17:41] cjwatson: Julien did say it takes a while with qemu. [18:06] * skaet --> lunch, biab [18:29] skaet: I'm also out for lunch, be back in 30min, will take a look at Edubuntu's tech overview then (sorry, trying to get LTSP's bandwidth usage down and performance up took a bit longer than anticipated) [19:06] bug 967257 --- YAY!!!!! [19:06] Launchpad bug 967257 in lubuntu-meta "PPC Install CD from 28 Mar does not boot" [Undecided,Invalid] https://launchpad.net/bugs/967257 [19:07] As to why he had issues? ... pass. He's a darn good mac tester. [19:14] can i get someone on the release team to give us the go/no-go on these two freeze requests: #956077 and #851810 [19:14] bug #851810 and bug #956077 [19:14] Launchpad bug 851810 in ubuntuone-client "[FFe] Notify clients when volumes info from server is ready" [Medium,In progress] https://launchpad.net/bugs/851810 [19:14] Launchpad bug 956077 in ubuntuone-control-panel/stable-3-0 "[UIFe] Colour changes for the QT control panel" [High,Fix committed] https://launchpad.net/bugs/956077 [19:18] highvoltage: I think I'm done drafting the Edubuntu techoverview, can you have a look and maybe improve a bit? [19:19] :) [19:20] skaet: can you help with getting someone to give us the go/no-go decision on those two freeze exceptions i listed? :) [19:22] joshuahoover, they won't make it for Beta2 at this point. [19:22] * skaet going to look at them now, and see who else needs to review. [19:24] skaet: right, but we'd like to have them for final if possible, especially the color change [19:27] joshuahoover, problem is that the UIFe didn't land last week, and screen shots have started being taken. [19:27] skaet: if you're into FFe reviews, can you look at bug 967320? ideally I'd like xcompmgr to be pulled by the next LTSP upload (scheduled for Friday) [19:27] Launchpad bug 967320 in xcompmgr "[FFe][MIR] Please promote xcompmgr to main for LTSP" [Undecided,New] https://launchpad.net/bugs/967320 [19:28] jbicha, ^ how far along are we with the screenshots for the docs? [19:28] skaet: i'll personally update screenshots if that would help :) [19:28] joshuahoover, jbicha may take you up on it ;) [19:28] (and yes it might well help) [19:29] documentation freeze is tomorrow. [19:36] joshuahoover, 851810 is approved as long as we can get it landed early next week. [19:39] joshuahoover, could you take a review pass at https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview, and make sure its got all the key changes that have happened in Ubuntu One captured? [19:40] skaet: yep, was doing that just a bit ago...then got distracted ;) [19:52] stgraber, challenge will be getting MIR resources to look at it in time. details in bug. [19:54] * micahg wonders if changing the i386 default to PAE is worth release noting (or has this been hashed already) [19:54] *default kernel [19:54] I would think so [19:54] changes in the hardware we support installing on are generally a big question; better to document that up front [19:55] * skaet nods [19:57] do you want a release notes task on a bug? [20:03] joshuahoover: we don't have any screenshots of ubuntuone in the system docs [20:04] jbicha: perfect :) [20:04] skaet: so, bug 956077 should be ok to do since we don't do screenshots of u1 in the sys docs - sound good? [20:04] Launchpad bug 956077 in ubuntuone-control-panel/stable-3-0 "[UIFe] Colour changes for the QT control panel" [High,Fix committed] https://launchpad.net/bugs/956077 [20:05] joshuahoover, sounds good, thanks jbicha [20:06] micahg, just go into TechnicalOverview wiki page and add in some text for now. Most of that will be transfered to formal Release Notes, next week. [20:07] skaet: sorry, I don't think I'm the right person to do this [20:07] * skaet still needs to scrub out old release notes from that project, so we have something we can work with next month. [20:08] skaet: joshuahoover: yes, updating ubuntu-one isn't a problem for Precise docs [20:12] micahg, ack, I'll add a sentence after its free to edit, and we'll get apw or ogasawara to review. [20:12] skaet: thanks [20:14] Riddell: are you editing the tech overview? [20:15] Daviey: it's the other Jonathan ;) (highvoltage) [20:15] Daviey: and yeah, he's still editing (we're discussing discussing some changes now in #edubuntu) [20:15] ok, groovy [20:19] joshuahoover, yes. have updated bug. [20:19] thanks [20:28] stgraber: oops, yes, 10s... [20:28] (I mean Daviey) [20:29] Daviey: ok I'm out of it [20:36]