[00:06] http://paste.debian.net/214431/ [00:07] stgraber: ^^^ [00:08] Riddell: I was thinking that we ought to freeze transitions for everything on the images tomorrow AM (when stgraber is awake) do one final respin to get current and then test that until we're ~ready on Thursday). [00:08] How does that sound? [00:09] I think it's up to Edubuntu separately if they want to put a block in place or not. [00:09] I don't think Edubuntu is planning to respin, but I haven't explicitly asked highvoltage about it [00:10] The test results didn't look good on the ISO tracker. [00:10] Not sure if you care for an Alpha 1. [00:11] "block" works on source packages as well as binaries, right? [00:12] ScottK: It only works on source packages. [00:13] OK. Then my list should be right. [00:13] I've obviously not checked the details but I'm OK with such a block going in for a couple of days [00:13] OK. [00:14] I got the list by looking at the seed structure and cat'ing the relevant .sources files together and then de-duplicating. [00:14] It wasn't pretty, but I think it's ~right. [00:14] You might want to compare against actual images, just in case. [00:15] Assuming you can come up with a reasonably efficient binary-to-source function [00:15] (I usually can but it's a bit late for me) [00:15] Well, it seems I manage to have no KDE at all in there, so clearly I missed something. [00:18] ScottK, stgraber: I wasn't planning on requesting a re-spin. We could potentially fix some issues, but it's an alpha so I don't particularly care about the issues as long as they're listed as known issues [00:18] OK [01:58] ScottK: yes that sounds like a good plan [01:58] OK. [01:59] stgraber: As the U-R dude for this milestone, would you please write a mail to u-d-a letting people know? [02:15] stgraber: I've built a new precise daily that actually has the signed kernel on (though I haven't tested the installer with this yet) === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === doko_ is now known as doko [06:32] cjwatson, gcc-4.7-armhf-cross doesn't migrate from proposed, because it thinks that armhf and powerpc builds are needed [06:57] doko: That's not why at all. [06:57] doko: It's not migrating because hrw broke some dependencies, we've already discussed it. [06:59] ahh, ok [07:06] or not ok, bad hrw [07:08] doko: Basically, he stopped building biarch packages because he ran into a build failure he couldn't figure out, and that broke the gcc-4.6-cross stuff that depended on those packages. So, our options are either fix his biarch builds or un-bi-arch the 4.6 stuff (or drop the 4.6 stuff entirely). [07:08] doko: He promised he'd look into the first option, before we look at the other two. [07:09] I might look into it in the next week or two if he doesn't get to it. === mmrazik is now known as mmrazik|afk [07:58] cjwatson, infinity: the gettext b-d issue was s/gettext:any/gettext/, yes? [08:36] doko: Yes. It not a critical issue to revert it (nothing's broken, per se), but the gettext:any stuff is unnecessary now, that's all. === henrix_ is now known as henrix [09:33] cjwatson: Precise desktop images seem to have some problem, i386 is not available, amd64 images do not have casper/vmlinuz [09:39] psivaa: Look again. [09:41] infinity: thanks, they appear now [09:42] doko: yes [09:42] infinity: disagree, :any breaks [09:43] it's not allowed with M-A: foreign and some tools (inc. apt IIRC) enforce that [09:43] psivaa: precise amd64 images have /casper/vmlinuz.efi [09:44] (which is bootable as non-UEFI too, but the rename was necessary for installer reasons) [09:44] cjwatson: Ahh, fair enough. doko uploaded the revert/fix anyway. [09:44] Also, WTF: [09:44] if test "$cross_compiling" = yes; then : [09:44] ap_cv_void_ptr_lt_long=yes [09:45] if test "$ap_cv_void_ptr_lt_long" = "yes"; then [09:45] as_fn_error "Size of \"void *\" is less than size of \"long\"" "$LINENO" 5 [09:45] fi [09:45] Brilliant. [09:45] infinity: I discovered the glory that is AC_CHECK_SIZEOF last night [09:45] "If cross-compiling, just fail hard for no good reason" is how I read that. [09:45] Look at its implementation - it's worth it [09:49] Hahaha. Googling for this brings up an upstream commit fixing it (yay), but also the following mailing list post detailing someone's "workaround" to crossing apache: [09:49] ./configure --host=arm-linux-uclibc LIBS=-lpthread apr_cv_process_shared_works=set ap_cv_void_ptr_lt_long=no ac_cv_sizeof_struct_iovec=8 apr_cv_tcp_nodelay_with_cork=yes ac_cv_func_setpgrp_void=no ac_cv_file__dev_zero=yes --prefix=/usb/sda1/apache [09:49] "Let's just preseed every potentially broken test and carry on." [09:51] The principle of dpkg-cross ... [09:55] Yeah, but we live in a brave new post-dpkg-cross world. [09:55] (Where I'm honestly impressed that most of this "just works" at this point) [10:23] hi release team, someone on call? [10:24] I'd like to know status (in the queue) of bug 1085961 and bug 1060327 [10:25] Launchpad bug 1085961 in ubiquity (Ubuntu) "Unable to install two raring desktops side-by-side" [High,Confirmed] https://launchpad.net/bugs/1085961 [10:25] Launchpad bug 1060327 in compiz (Ubuntu) "compiz crashed with SIGSEGV in compiz::opengl::bindTexImageGLX() from TfpTexture::bindTexImage() from ... from GLTexture::bindPixmapToTexture() from DecorTexture::DecorTexture()" [High,Confirmed] https://launchpad.net/bugs/1060327 [10:25] .. which are impacting a lot our testing [10:25] and the ability to install Raring [10:25] EOM [10:26] I'll have a look at the first one [10:26] cjwatson: thanks [10:26] Might be best to ask the desktop/unity teams directly about the second [10:27] cjwatson: ack, will do [10:28] gema_: is this crash on top of errors.ubuntu.com [10:28] ? [10:29] didrocks: I don't its ranking, but I know this crash is making people unable to test on vbox [10:29] didrocks: which is really bad [10:30] gema_: can we have the question asked just on one channel? it's currently split up on 2 :p [10:30] so just pick one please ;) [10:30] didrocks: it's blocking the installation (since ubiquity now uses compiz). One "workaround" is to seed metacity back on to the ubuntu desktop cds, such that users can complete installation while this bug is being fixed. [10:30] & respin. [10:30] ok, it's the first time I'm pinged with that one, so status is "unknown" and not on the priority list right now [10:30] didrocks: sorry, I was trying to make people aware of the issue [10:30] :) [10:30] didrocks: ack. [10:31] I'll put that on the priority list when I have the meeting with the 13.04 maintenance team [10:31] (next week) [10:31] sounds good to you? [10:31] gema_: i maybe over-reacting here. [10:31] didrocks: not really, since it is blocking testing [10:31] is that happening on every virtualbox run, starting the raring iso? [10:31] didrocks: manual testing [10:31] gema_: does this bug only happens post-install in try-ubuntu session, or can this be triggered during install-ubuntu? [10:32] xnox: let me find you some (I believe) duplicates [10:32] xnox: bug 1085171 [10:32] Launchpad bug 1085171 in ubiquity (Ubuntu) "installer doesn't appear Ubuntu AMD 64 in Vbox" [Undecided,Confirmed] https://launchpad.net/bugs/1085171 [10:32] 11:31:46 didrocks | is that happening on every virtualbox run, starting the raring iso? [10:32] * didrocks would like an answer [10:33] didrocks: I will get you one, need to talk to nick about it, he has been following the progress of it [10:33] is it on "try ubuntu" or the ubiquity session? [10:33] * xnox does not like virtualbox at all, there are many problems with virtualbox which we can or might not be able to fix. [10:33] would be good to have data about how critical this is so that I can weigh in before pinging about it with OMG it's urgent :p [10:34] * xnox wishes we can just not support virtualbox. [10:34] didrocks: understood, there's also bug 1080437 [10:34] Launchpad bug 1080437 in ubiquity (Ubuntu) "no background during the 13.04 daily install" [Undecided,New] https://launchpad.net/bugs/1080437 [10:35] gema_: so no live session it seems, but reliably on the install one? [10:35] gema_: no background is known & unrelated as it is present regardless of virtualisation / bare metal. [10:35] didrocks: judging from the iso tracker, I'd say it is quite widespread, but I will get balloons input and get some input from my team as well [10:35] * didrocks stop bother about this until we get data and what is impacted first :) [10:35] didrocks, xnox thanks for the pointers [10:35] so waiting for ballons :) [10:36] yep [10:36] thanks gema_, xnox! [10:36] keep me posted [10:36] will do [10:36] gema_: if people report VirtualBox issue, they should also report virtual box version numbers (proprietary vs opensource edition) (from ubuntu archive vs from oracle) [10:36] and also if it is reproducible in KVM or not. [10:36] xnox: ok, we'll need to train them to do that [10:37] didrocks: i tried with virt manager and it happens in every live session, bug 1086036 [10:37] Launchpad bug 1060327 in compiz (Ubuntu) "duplicate for #1086036 compiz crashed with SIGSEGV in compiz::opengl::bindTexImageGLX() from TfpTexture::bindTexImage() from ... from GLTexture::bindPixmapToTexture() from DecorTexture::DecorTexture()" [High,Confirmed] https://launchpad.net/bugs/1060327 [10:37] gema_: it is better for them to stop using VirtualBox and instead use virt-manager - a graphical interface for kvm which is similar if not better than virtualbox. [10:37] xnox: Virtualbox is not going to go away [10:37] psivaa: ok, that's more interesting, and it's raring only? not quantal? [10:37] xnox: until we decide to stop supporting it [10:38] didrocks: only raring [10:38] interesting, as unity raring is (until today) the exact same than unity quantal [10:38] so maybe a rdepends is triggering this [10:40] psivaa: do you have the setup ready? [10:40] psivaa: like, can you update from a ppa and start again the vm? [10:41] didrocks: this is during the live session, so i could try that [10:41] psivaa: excellent, please install ~ubuntu-unity/daily-build ppa, which is going to land in raring later on (first real unity version in raring) [10:42] psivaa: at least, we'll know if the issue still exists, as compiz changed quite a lot [10:43] popey: Mirv: the ppa is updated with what should land soon, if you want to test it… :) [10:43] roger roger [10:57] xnox: regressions are regressions, virtualbox or not [10:57] I'd be very wary of saying "oh, it's virtualbox, screw it" without very careful evidence to demonstrate that it isn't something that affects real hardware too [11:01] cjwatson: ok. === yofel_ is now known as yofel [11:19] xnox, also worth noting virtualbox supports hardware 3d passthrough, so users can actually use Unity without going via LLVM. I don't believe kvm does this? [11:20] popey: ok. I shall try to set that up on my machine. Will it work with intel graphics? I guess I will find out =) [11:21] yes [11:21] I am using ubuntu 12.04, 12.10 and raring in virtualbox [11:21] (on i7, HD2000 GPU) [11:23] FWIW last I checked 3D passthrough was only in the proprietary edition [11:24] Certainly a good reason somebody might use it though === mmrazik is now known as mmrazik|lunch [11:29] infinity, bad boy [11:38] doko: ? [11:46] infinity, no, it's hrw [11:47] Oh. Yeah. [11:50] infinity, so it looks like the armhf-armel packages are always empty. did something change how stubs-hard and stubs-soft are generated? currently I can only see stubs-hard.h [11:52] doko: stubs-hard is in libc6-dev:armhf and stubs-soft is in libc6-dev-armel:armhf [11:52] doko: They didn't used to be split out at all, pre-2.16 === mmrazik|lunch is now known as mmrazik [11:53] (As in, there used to just be one stubs.h that had code for both) [11:53] bah, http://packages.ubuntu.com/ can't search armhf [11:53] Nope, I've complained to Rhonda recently about that. [11:53] It may change. [11:55] * infinity wonders idly if this cross-built apache2 of his will actually run. [12:08] didrocks: i could not verify the ppa in the live session, tried with persistence but rebooting the VM in KVM does not go back to the live session, even though the boot order is correct and the dvd with the iso is the first one on the list. tried to 'sudo restart lightdm' after the ppa installation but that command just hangs and i do not see anything happening [12:20] nothing weirds noticed with the new PPA versions either === henrix is now known as henrix_ === henrix_ is now known as henrix [12:46] infinity, tsk, tsk. linux-meta-nexus7 has a git repo [12:47] rtg: Tsk, tsk, I can't commit to it. :P [12:47] infinity, you're not supposed to. How about sending me a patch ? [12:47] rtg: Thanks in advance for merging without complaining about my not committing somewhere that I can't commit. [12:48] rtg: http://launchpadlibrarian.net/124931118/linux-meta-nexus7_3.1.10.8.12_3.1.10.8.13.diff.gz [12:48] rtg: Enjoy. :) [12:48] rtg, i have a config patch for the image package [12:52] Hi, I could use some advice on how to get a SRU through. The SRU fixes bugs that currently block hardware certification for some devices. [12:52] psivaa: usually: stop lightdm; stop ubiquity; pkill -9 X; start lightdm; all as root should be able to "restart" the graphical session for you after installing / changing packages. [12:52] I uploaded Pulseaudio almost a month ago and nothing happened; however, during this month more bugs have shown up so I should do another upload before it's accepted [12:54] However, if I do that, I'm afraid I'll get last in queue again and have to wait another month. [12:55] slangasek, infinity, ScottK, bdmurray, SpamapS, RAOF: ^ [12:55] diwic, if you have a new upload to replace the currently waiting just get it in, it will not "reset the counter" [12:56] diwic: Upload a new one, use -vold_old_version to generate a sane changelog that included both, and ping me. [12:56] but what infinity said, merge both entries or use -v [12:56] infinity, should the new upload have the same version as the old one? [12:58] diwic: Oh, either option is fine. Re-use, or -v to catch both. Don't care. [12:59] ok [12:59] I'll go and prepare another upload [12:59] thanks [13:18] xnox: thanks, pkill -9 X alone brings up the live session properly even without installing the unity daily ppa [13:20] psivaa: ;-) [14:01] gema_: phew, that was an obscure bug [14:02] cjwatson: did you fix it already!? [14:02] cjwatson: thanks a lot! [14:02] Just preparing an upload now [14:02] It may take a little while to reach images as ubiquity is one of the packages frozen for the community image milestone [14:03] Speaking of which ... [14:03] cjwatson: ack, no problems, thanks a lot for this :D [14:04] cjwatson: Now that it's not incredibly late, did you have in mind a way to get a list of packages to freeze? [14:04] ScottK: Oh, huh. I thought you'd frozen already. Isn't it a bit late now? [14:04] I mean, not for me, but for it to be useful [14:04] No, we were going to block transitions today and respin. [14:05] Since it's just Kubuntu images it's not that big of a deal to retest. [14:05] Ideally we'd have done it earlier, but this is the first time and all ... [14:06] I was playing with germinate last night, but didn't get anywhere since I couldn't figure out how to use -c to get it to use both main and universe at the same time. [14:07] -c main,universe - but I think it'd be better to use the .manifest and .list files from the images [14:07] Ah. That's one option I didn't try. [14:07] * xnox thought edubuntu & kubuntu are releasing and hence the set of frozen packages is larger. [14:08] well "to be frozen" [14:08] It's up to Edubuntu if they want a freeze or not. [14:08] IIRC, stgraber said they weren't going to respin, so there was no need for a freeze for their stuff. [14:09] join -j1 -o2.2 <(sort -u list-of-binary-packages) <(grep-aptavail -nsPackage,Source:Package '' | perl -ple '$_ .= " " . <>; chomp; <>' | sort -u) [14:09] Should be close enough [14:09] .oO( SQL in shell ) [14:10] Might miss packages that don't exist on the architecture you're running on [14:11] * xnox is impressed. But questions perl's ability to do sort -u? [14:11] It could but then you can't use -p which is handy [14:11] ah [14:12] xnox, ScottK: yep, edubuntu has some release-critical bugs for alpha-1 but it doesn't seem necessary to block an alpha release because of them. people who want something more feature complete and without sever bugs can wait for the beta :) [14:24] infinity, okay, a new upload is now in the queue [14:24] highvoltage: I think you just summed up everything I dislike about actually releasing alphas there. [14:25] ScottK: so I caught up on the highlights but not on the rest of the log. Did you push your britney hints to the branch already? [14:25] stgraber: No. [14:25] I'm sorting out the list now. [14:25] ok [14:26] ScottK: I guess this would be a bad time for me to push a new d-i and kernels? ;) [14:35] stgraber: Pushed. [14:35] I'd appreciate it if someone would check it please. [14:36] infinity: It's probably OK. I think my block hits faster than the buildds get that ready to transition. [14:36] Hints are updated at the start of every britney run [14:36] stgraber: Once we've confirmed that works, would you please respin the Kubuntu images. [14:37] It looks plausible at a very cursory glance [14:38] cjwatson: hey, you maybe have seen we just had our first automated daily process (but with manual testing, autopilot not being ready yet) unity stack release. [14:38] cjwatson: we had some new (renaming) source packge which went through NEW [14:38] like unity-scope-gdrive [14:38] but nux bumped its soname and is now nux4 [14:38] the binary package didn't seem to go in the NEW queue [14:39] (fortunately, I asked a beforehand review from the ppa itself to seb128) [14:39] any idea if I either use a wrong copy argument or if there is indeed a bug? [14:39] cjwatson: For Alpha 1, I'll settle for plausible. [14:41] stgraber: Since my block is in place, would you please respin Kubuntu. [14:41] didrocks: copies don't hit binary NEW, this is true. And mildly problematic in this case, perhaps. [14:42] infinity: ah, well, when we have packaging changes, the publisher is stopped for a manual review [14:42] I think I remember vacillating about that when implementing --auto-approve [14:42] infinity: so at least, we won't copy without noticying [14:42] but then, you can just count on people having the credential following the process [14:42] ScottK: sure [14:43] ScottK: running [14:43] I believe I settled for auto-approve bypassing NEW because that way it was convenient for Debian auto-syncs [14:43] (which I think, I did proove more than once ;) but I would prefer it to be enforced) [14:43] Thanks. [14:43] yeah, I understand [14:44] should I just note that on the doc and we rely on people pushing the manual trigger when there is a packaging change? [14:44] in* [14:44] cjwatson: Yeah, the problem isn't necessarily bypassing NEW (although, if this sort of automated copying happens more, I'm a bit irked by it bypassing ftpmaster checks), but that the overrides will be wrong by default. [14:45] And I think that's an independent bug [14:45] stgraber: Do you think the block is worth a mail to u-d-a? [14:45] I think it is. [14:46] If only because it's new information that we can do this without affecting people's ability to upload. [14:46] OK. [14:46] * ScottK writes [14:46] ScottK: I'm actually 90% done writing an e-mail to u-d-a :) [14:47] * ScottK stops writing. [14:47] Thanks. [14:50] ScottK: did I miss something? http://paste.ubuntu.com/1412595/ [14:51] I think it's fine. [14:51] stgraber: ^^^ [14:51] alright, sent [14:52] cjwatson: can you accept it in u-d-a's moderation queue? [14:54] stgraber: done [14:56] cjwatson: about those auto-accepted binaries, they are landing in main or universe? [14:56] cjwatson: thanks [14:56] didrocks: As infinity says, there's a bug in default overrides, so we'll probably need to fix that [14:56] Yeah, it's filed. [14:57] ok, I'll do a manual promote then [14:57] I'm doing it [14:57] I thought about override as "bypassing" [14:57] ok, thanks cjwatson :) [14:57] done [14:58] hopefully it won't go wrong again on copy to release [14:58] https://bugs.launchpad.net/launchpad/+bug/1079577 [14:58] Launchpad bug 1079577 in Launchpad itself "Copies with binaries don't correctly override NEW binaries" [High,Triaged] [14:58] Which may or may not be more than one bug. [14:58] thanks [14:58] cjwatson: you'll be happy to hear that today's precise image boots on SB :) [14:58] stgraber: \o/ [14:59] I'm now testing that it installs and boots, hoping to be done before the team meeting :) [15:00] stgraber: HOORAY [15:00] "happy" doesn't really cover it, that's a huge relief [15:05] * stgraber really needs to fix queuebot to better deal with disabled products :) [15:22] cjwatson: so, I can boot the media, install but not quite boot post-install... sorry :( [15:23] checking what's wrong now [15:23] ok, so the reason why I can boot is because the efibootmgr entry doesn't point to the shim... [15:23] Boot0018* ubuntu HD(1,800,2f000,fe060401-4d67-4ea8-8f0d-0f5910471a15)File(\EFI\ubuntu\grubx64.efi) [15:25] cjwatson: installer syslog: http://paste.ubuntu.com/1412670/ [15:27] stgraber: is shim in \EFI\ubuntu\ at all? [15:27] cjwatson: yep [15:29] Hm, curious [15:30] looking at the log, the signed grub and shim are clearly installed but for some reason the wrong efibootmgr entry is written, then ubiquity removes linux-signed-generic-lts-quantal [15:31] one thing that may have confused the scripts is that it's on my laptop where I already have a working secureboot raring installation on the internal disk. The precise installation was done from a USB stick to another USB stick but sharing the efi partition on my internal disk with the raring install [15:54] cjwatson: did you handle also the unity-scope-gdrive migration to main? (it's the unity-scope-gdocs code, just a source package rename) [16:00] didrocks: No, I didn't touch it [16:00] should I? just don't want to conflict when it will migrate to main :) [16:00] Be my guest [16:00] ok, doing :) [16:24] cjwatson: last question before I stop bothering you, I'm looking at the proposed migration and it seems it's failing in some way for the unity stack, but I'm quite unsure about how to read the log :) [16:25] didrocks: looking (modulo meeting) [16:25] didrocks, left to right, top to bottom :P [16:26] ogra_: ah, that explains why… oh wait! :-) [16:26] didrocks: Why does bamf-dbg depend on both libbamf0 and libbamf3-0? [16:26] :) [16:27] didrocks: Also, ginn needs to be rebuilt against (or ported to) libbamf3-0 [16:27] Also, should I expect the block to show up on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt ? [16:27] ScottK: excuses [16:27] Thanks [16:27] And I do see it there [16:27] cjwatson: waow, indeed, not sure as those libbamf0 renaming came from debian, maybe a wrong merge, I can fix it directly [16:28] didrocks: those are the two problems blocking migration AFAICS [16:28] ok, let me see for ginn [16:28] thanks for the hint cjwatson :) [16:28] OK. I can see the block is working. [16:41] cjwatson: do you have enough information to debug that efi weirdness or do I need to extract something else before I fix my laptop to work again with SB? [16:43] It turns out the block is incomplete, but I'm not going to worry about it for Alpha 1. [16:43] stgraber: I'm currently baffled but I can probably make some progress given that plus more coffee, so go ahead and restore [16:45] hmm, what's the efi weirdness now? [16:45] slangasek: even though I install under secureboot, the grub scripts somehow decide to use grubx64.efi instead of the shim [16:46] so I end up with a system where shim-signed and grub2-signed are installed but the efibootmgr entry points to grub directly [16:47] mmk [16:48] grub-install bug - ${source_dir} isn't set [16:48] i.e. misbackport [16:48] doesn't explain why linux-signed-generic-lts-quantal gets removed [16:58] stgraber: I remember you were requesting "static efi secure boot image validation". Currently that is run in jenkins and fails because of s/vmlinuz/vmlinuz.efi/ [16:58] stgraber: was there a irc log of all the things you were asking to be checked for? cause we can feed it to the smoke testing jenkins job. [17:01] 16:12 < stgraber> cjwatson: well, at least we have a pretty comprehensive list of things that can go wrong with SB images ;) I'm almost tempted to write a testing script checking that the partition table is correct, that the fs structure is fine for EFI, that shim and grub exist and are signed, that grub.cfg looks right and that vmlinuz is signed. If all of those match, it's pretty sure it'll at least boot (install is a whole other proble [17:01] xnox: ^ [17:01] If somebody wants to review that grub2, that should be half of stgraber's problem [17:02] Only touches grub-install so shouldn't need a new grub2-signed [17:05] The removal of linux-signed-generic-lts-quantal is perplexing, and we need to fix it, but I don't think it should break booting because it's just the metapackage [17:05] (It'll break future upgrades instead) [17:06] stgraber: thanks, I'll try to work on those bits. [17:10] cjwatson: At which point is the metapackage being removed? [17:10] By the "I guess you don't need a signed kernel" logic? [17:16] infinity: It's actually more that it isn't being specifically kept (because it's in the live part of the squashfs manifest) [17:17] infinity: I think check-kernels is getting confused by the -lts-quantal suffix. Tedious rather than complex as such. [17:17] Ahh. [17:17] infinity: Go work with pinky on sulfur, sounds like he's making progress :) [17:17] He is? [17:17] #is [17:18] I've apparently forgotten most of what I know about rescuing powerpc boot failures, but at least it gets somewhere interesting now [17:19] Dangit, if he'd just waited longer on the udev spam, it would have eventually let him in. [17:39] Hi, a bit of a n00b Q, I know! When I cannot get a crash report to send the details, which files do I manually upload to the manually opened bug report on lp? (A link to wiki with list is fine). [17:44] phillw: You could just file it with apport-bug /path/to/.crash [17:45] phillw: Or if you've already filed a bug, "apport-collect 12345" (for the bug number) [17:45] infinity: it's a KVM instance. and is dying with ubiquity. I can use guestfs to pull files from it, but not much more. [17:46] syslog is a good start. [17:47] shall i pull /var onto my local machine? [17:48] phillw: /var/log [17:49] xnox: thanks, I'm just installing guestfs onto my machine [18:05] Is there a reason php5 hasn't moved out of raring-proposed ? [18:05] Its compiled on all arches.. and I don't see any installability issues. [18:07] SpamapS: trying: php5 [18:07] skipped: php5 (57 <- 25) [18:07] got: 107+0: i-107 [18:07] * i386: php5-suhosin [18:07] SpamapS: so php5-suhosin becomes uninstallable if php5 is upgraded. [18:08] SpamapS: http://people.canonical.com/~ubuntu-archive/proposed-migration/ [18:08] Self service at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt [18:08] ahh .. http://people.canonical.com/~ubuntu-archive/testing/raring_probs.html .. is that not up to date? [18:08] SpamapS: that looks at raring-release, not raring-proposed nor the mix of the two yet. [18:08] http://people.canonical.com/~ubuntu-archive/testing/raring-proposed_probs.html [18:09] AHH [18:09] SpamapS: so britney telss you when/why it's not migrating a package and that's more canonical way to check why something is not migrating. [18:09] * ScottK wonders if xnox was punning. [18:09] micahg: Ooohhh we have that now =) [18:09] ok, looks like php5-suhosin will need another rebuild [18:10] Right, but it doesn't actually answer SpamapS' question. [18:10] excuses page said it's a valid candidate... [18:11] micahg: excuses saying "valid candidate" means "and thus, I shall try and see if it fits!" [18:12] micahg: Basically, it means is passed the "is it build" and "are there any blocks" tests, etc. [18:12] Then it actually tries the complex upgrade bits. [18:12] And that's _output. [18:12] xnox: We've had it since roughly when raring opened [18:12] infinity: right, I'm one step behind since I haven't dug into this yet :) [18:12] micahg: excuses and output aren't actually two views of the same thing, rather, excuses is the first stage, and output the second. [18:12] (this being britney mimgrations) [18:13] Yes [18:13] Excuses is package-local, output is global. [18:14] cjwatson: Right, but if something isn't a valid candidate, according to excuses, it'll never hit the global try/pass/fail in output. [18:14] (Which was what I was trying to get across with the "two stages" bit) [18:14] Indeed. [18:14] Right and the stages are: 1 local 2 global [18:15] Heh. [18:15] Ed Zachary. [18:15] So, is breakfast still breakfast when you've been up since 6pm the previous evening? [18:16] * infinity decides to go cook some and find out. [18:18] infinity: if you've not been eating since then, certainly :) [18:20] xnox: I'm looking at https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1086036 and would like to improve the title so that it's clear that we're not talking about the 2 month old compiz bug that it was duped to earlier. do you happen to know what the thing is called that comes up to ask if you want to go into live session or the installer? is that part of ubiquity? [18:20] Launchpad bug 1086036 in compiz (Ubuntu) "Compiz crashes when booting to raring live session" [Undecided,New] [18:20] I'm currently thinking that the compiz crash may or may not even be related to the real problem described here [18:21] plars: so ubuntu desktop CD's boot into "ubiquity-dm" session which presents ubiquity in the greeter mode aka "Try or Install Ubuntu" screen. [18:22] plars: so something like "compiz driven ubiquity-dm crashes in raring daily" is a reasonable title or something else you can think off. [18:23] ... but did not under metacity. [18:23] xnox: because one of the other things we've noticed is that if you hit a key at the boot screen and choose boot to live session, it goes into the live session fine, but if you choose install ubuntu, it seems to give us something similar to what we see here (top bar only, no installer) [18:23] xnox: ah, so there was a change from metacity to compiz here recently? [18:23] plars: correct. So "install only" mode is also running under a "ubuntu-dm" session. [18:24] plars: yes, there was. See the email to ubuntu-devel announcing this. [18:24] [6~[6~[6~[6~[6~/win 99 [18:24] curse you lag [18:24] plars: I have tested it across all hardware I had available and the idea is that live-cd should gracefully use 3D accelaration or fallback to LLVM Pipe rendering. [18:25] xnox: ok, that's about the same timeframe for that change and when I'm seeing it that it quit working [18:25] plars: if this experiment doesn't work out well, we can seed metacity back on to the desktop CDs, but keep using compiz on nexus7 images (e.g. controlled environment / hard ware where we know it works correctly) [18:26] xnox: that's sheds some light on this for me, thanks [18:26] plars: So it can be easily tested: stop lightdm; stop ubiquity; pkill -9 X; apt-get install metacity; start ubiquity [18:26] if that works you know it's compiz fault. [18:26] Ideally I want compiz to work out of the box for the installer on all hardware, because this is requirement to run the installed system after all. [18:28] xnox: well, it *does* seem to run once we get it installed, just not for the ubuntu-dm session [18:29] so, I think php-suhosin probably needs to be removed [18:30] plars: interesting. Somebody with compiz skills should debug this then. Does it work on the installed system, due to installing & activating extra graphics drivers? [18:30] plars: didrocks was pinged about it earlier. [18:31] xnox: also, I think psivaa already did some of this testing this morning, but even just killing X and restarting lightdm worked on it's own [18:31] without installing metacity [18:31] 8) sounds racy. [18:31] indeed [18:32] plars: coincidently ogra_ was reporting race condition between compiz & onboard with subsequent boot working out better for onboard. [18:32] (that's on nexus7) [18:32]