[01:08] Amaranth: is compiz required for proper notify-osd now? [01:40] micahg: A compositor of some kind is needed for the fade part, yes [01:40] Always has been [01:41] Amaranth: ok, but that shouldn't make duplicates happen, right? [01:41] duplicates? [01:41] not duplicates, multiples on either side [01:41] Oh, I don't know [01:41] bug 559109 [01:41] Launchpad bug 559109 in notify-osd "Two notification bubbles at the same time" [Undecided,New] https://launchpad.net/bugs/559109 [01:41] compiz doesn't have any effect on notify-osd [01:41] and macslow is the author of notify-osd, not me :) [01:42] k, someone mentioned compiz fixed it, so I figured I'd ask you Amaranth, thanks [01:42] Well, he probably only tests with compiz so it's possible notify-osd is taking advantage of something we handle differently compared to metacity [03:18] slangasek: the final LanguagePackTranslationDeadline is set to 22nd. (Thu). I will ask the Launchpad Translation team for the final export on 23rd. (Fri), which will then be available for langpack-o-matic on 24th (Sat.)building all the langpacks will take around 2 days, depending on how busy the buildds are... So, by Monday, 26th we should have everything ready. Is that too late for you? BTW: since last week, every language-pack update is a full updat [03:22] So, why is libglib2.0 failing to build on sparc, with the buildd log ending with “no really, you do not get to build glib2.0 here.”? [03:23] http://launchpadlibrarian.net/43173338/buildlog_ubuntu-lucid-sparc.glib2.0_2.24.0-0ubuntu1_FAILEDTOBUILD.txt.gz [03:24] ArneGoetje: hi, you got cut off at "full update" [03:24] ArneGoetje: 23rd your time, or UTC? :) [03:31] RAOF: Because that build was taking down the buildds. [03:31] RAOF: manual policy override :> aka lamontd [03:31] RAOF: glib2.0 and sparc are not on speaking terms at the moment. [03:32] rpc.lamontd, I think [03:33] Ok. That archive skew causes anything which b-ds on mono-devel to fail to build :( [03:34] Yep. [03:35] on all arches ? [03:35] No, just on sparc. [03:36] We could probably work around it by explicitly giving mono-devel an option dependency on an older libglib on sparc; then it'd be installable and should work. [03:36] Sparc: Now that hppa can't be complete crap anymore, someone has to do it. [03:37] RAOF: given that this cropped up early last week, I'd do it. [03:38] that or fix the glib issue on sparc [03:39] We have a sparc porter box, don't we? [03:45] Where we == Canonical, yes. [03:45] There's probably one in the DC: I know that at least one Sparc user has been reporting that the lucid kernel still can't boot. [03:46] slangasek: So, we won't have any delta updates until final release. [03:46] NCommander: Any chance you got your sparc booting to help RAOF look at libglib? [03:46] slangasek: 23rd UTC [03:47] slangasek: so that the UTC-n timezoners have a chance to get updates in until 22nd their time. [03:49] Does anyone happen to know the name of the script that checks packageset permissions in LP, or what access level is required to set permissions? [04:05] persia: edit_acl.py from ubuntu-archive-tools? [04:05] That's likely it. Thanks. [04:13] RIght. I seem to be good at crashing that :) Time to find another class of solution :) [05:38] ArneGoetje: well, final ISO mastering should start on Monday so that we have the full three days for validation; I think having the deadline prior to end-of-day 22nd would benefit us [05:38] ArneGoetje: and of course since this is an LTS, there will be future point releases that can incorporate any translations that miss .0 [05:41] slangasek: sure... so, pull the deadline in front? Like 20th (Tue) and export the translations on 21st, like it would do by cron job? [05:41] dpm: ^^ [05:48] good morning and thanks for the heads up, ArneGoetje. I think by "having the deadline prior to end-of-day 22nd" slangasek meant having the deadline a bit earlier during the day (didn't you?). I believe otherwise translators would not be happy with the idea of moving it to the 20th at this point and loosing 2 full days of time for translation [05:49] dpm: should we just say we export the translations at 22:00 UTC on 22nd? [05:51] ArneGoetje, dpm: yes, I just mean having it a little earlier in the day on the 22nd [05:51] ArneGoetje, that sounds good to me, if 22:00 UTC is early enough for the release team. slangasek, what do you think the best time would be? [05:53] ArneGoetje: is 22:00 early enough that it's available to langpack-o-matic before Saturday? [05:56] slangasek: well, the export takes 10 hours to finish, lp-o-matic build takes about 2 hours, the buildds chew on them for about 2 days (700+ packages) [05:56] * slangasek nods [05:57] and there's a manual upload step that you have to do between lp-o-matic building the source, and the buildds starting to chew? [05:58] slangasek: yes, including review the logs if anything failed... [05:59] slangasek: so, if you want to have them before Saturday (UTC, I assume), then exporting them on Wednesday would be necessary, I guess. [06:00] 22nd @22:00UTC export, + 12h, +1h padding for log review, takes us to 18:00 your time on Friday, right? [06:01] slangasek: 19:00 [06:01] ok [06:02] so a few hours earlier is better? [06:02] I don't want to move the deadline back any further than we have to, but I'd like us to have the langpack build start before the weekend (UTC) [06:03] especially since I'll be in the air that weekend [06:03] slangasek: the time for uploading them at 19:00 is OK for me, I can arrange that. [06:04] ok === thekorn_ is now known as thekorn [07:26] good morning [07:28] Good morning! [07:38] RAOF: HAPPY BIRTHDAY! :-) [07:38] dholbach: Thanks! [07:39] RAOF: dholbach +1 :) [08:01] Good morning [08:02] apw: WI tracker> no, you still have to do that manually; that's bug 509806 [08:02] Launchpad bug 509806 in launchpad-work-items-tracker "Alllow postponing to a different milestone" [Wishlist,Triaged] https://launchpad.net/bugs/509806 [08:08] pitti, hi [08:08] hi tkamppeter; how's the LF summit? [08:08] pitti, starts on Wednesday, flight tomorrow at noon time [08:11] pitti, there are people still complaining that CUPS does not start on boot, on bug 554172 [08:11] Launchpad bug 554172 in cups "cups not starting at boot" [Undecided,New] https://launchpad.net/bugs/554172 [08:12] pitti, was this not an ifupdown problem (do not know bug number) which is already fixed? [08:13] tkamppeter: no idea; this bug does not have any data, such as whether the rc2.d/S50cups link exists, etc. [08:13] tkamppeter: /var/log/boot.log might be useful as well [08:16] pitti, thanks, I asked the user. [08:24] A laptop of mine (running lucid) gets stuck after a post-boot file system check, I don't see any hard disk activity (the hard disk LED is not lighting up) and typing 'C' will not abort the fsck; I have to hold the power button to turn off the machine. [08:25] A part of the drive is encrypted FWIW [08:25] Is this a known issue? [08:29] how does one get the ability to accept bug nominations for particular releases? [08:30] pitti, found the bug, it was 497299. [08:30] the ubuntu-docs team would quite like the ability to do this so that we can target bugs for SRUs, but at the moment I seem to be the only person able to do it [08:30] bug 497299 [08:30] Launchpad bug 497299 in ifupdown "upstart not starting init-scripts (event net-device-up IFACE=lo missing)" [High,Fix committed] https://launchpad.net/bugs/497299 [08:33] pitti, by the way, a user has confirmed on April 1 that the Karmic SRU in this bug works for him, so you can push it to -updates on your next SRU run. [08:34] al-maisan: have seen bug reports describing this, but they're as-yet-untriaged - can you try a few things for me? [08:35] slangasek: yes, of course. [08:35] tkamppeter: can he please say so in that bug? [08:35] al-maisan: 1) are the dots under the logo still scrolling, or have they stopped? [08:35] (tells us whether plymouth is still running) [08:35] tkamppeter: oh, there is a confirmation already [08:36] slangasek: I believe they have stopped. [08:36] al-maisan: ok - Alt+F1 doesn't switch VTs? [08:36] slangasek: nope, I tried that. [08:36] al-maisan: Alt+SysRq+K? [08:37] didn't try that [08:37] how can I mark a partition to be fsck'ed? [08:37] I'd like to do that and reboot in order to try Alt+SysRq+K [08:38] pitti, I changed the tag to verification-done now, so that this bug should get into your SRU queue. [08:38] tkamppeter: yes, so did I [08:38] * al-maisan looks for a 'SysRq' key on his keyboard [08:39] al-maisan: you can set the mount count manually on the filesystem with tune2fs -C ; or to force a rootfs check, touch /forcefsck [08:39] SysRq is the printscreen key [08:39] slangasek: right [08:42] al-maisan: probably not helpful for your use-case, but the recovery mode has a filesystemcheck option too [08:42] mvo: just did a "sudo tune2fs -l /dev/mapper/ul-h" [08:42] rebooting.. [08:44] pitti, do you know what goes wrong at bug 559676? [08:44] Launchpad bug 559676 in hplip "package hplip-data 3.10.2-1ubuntu5 failed to install/upgrade: subprocess installed post-installation script returned error exit status 2" [Undecided,New] https://launchpad.net/bugs/559676 [08:45] pitti, it gives the error: update-python-modules: error: hplip-data.private is not a recognized python-support module. [08:45] pitti, issued by update-python-modules [08:45] tkamppeter: perhaps it's trying to install that into a public module dir? [08:49] pitti, hplip-date contains a file /usr/share/python-support/hplip-data.private [08:50] alternatively, is it possible to do a query that shows bugs in a particular package that have been nominated for a release? [08:51] pitti, /usr/share/python-support/hplip-data.private contains a list of all.py files in /usr/share/hplip/ and subdirectories, but I am not Python expert enough to know whether this is really needed and for what. [08:52] this isn't really python itself; it's python-support, which is a Debian-ish way of packaging them; I'm afraid I can only refer you to http://www.debian.org/doc/packaging-manuals/python-policy/ at this point, to check whether there's something wrong with the packging [08:52] mdke: https://bugs.launchpad.net/ubuntu/lucid/+nominations?field.searchtext=foo? may have false-positives since it's not keyed on the package field, but is close [08:53] mdke: in theory, accepting nominations is tied to upload privs; anywhere you find this to not be true is a bug AIUI [08:53] mdke: oh, you want it for other people that aren't uploaders, though - hmm [08:54] slangasek: right [08:55] slangasek: that url is helpful though, thanks [08:58] didrocks, got a minute about bug 542091? [08:58] Launchpad bug 542091 in cheese "Add apport hook for cheese" [Wishlist,Triaged] https://launchpad.net/bugs/542091 [08:59] nigelb: sure, did you post the latest version of the patch? [08:59] didrocks, I wanted to run by you the latest version of the hook before I made a debdiff [08:59] nigelb: ok :) [08:59] http://pastebin.com/DMpQ0KDA [08:59] is the prompt too confusing? [09:00] "If Cheese is running, please close Cheese. Cheese will run again in debug mode. Please wait till you see a video or an error message before closing cheese" [09:01] nigelb: how can the user tell if cheese is running ? [09:01] lifeless, well, I suppose user could see it in the taskbar? [09:01] nigelb: right, if it crashes, not sure it's still displayed [09:02] didrocks, if cheese crashes, doesn't apport deal with it differently? [09:02] i.e., not via the hook [09:02] slangasek: so, here's the data you asked for: 1 - the dots under the logo are not scrolling, 2 - Alt-F1 does not switch VTs, 3 - Alt+SysRq+K gets me out of there and the boot process continues successfully. [09:03] nigelb: it launches the hook when it crashes… but that's still better than "killall" which was present in the previous version. I guess we can go on with it for the moment. I'll just change "please close Cheese" by "please close it" [09:03] slangasek: after pressing Alt+SysRq+K I see a black screen for a second, there was an error message related to getpwuid or something similar bit I do not know whether it's pertinent to the fsck problem [09:03] didrocks, ok. will get you a debdiff in a few :) [09:04] al-maisan: do you have an external monitor plugged in? [09:04] nigelb: sweet :) [09:04] slangasek: sorry, I don't. [09:05] al-maisan: darn, was hoping this was bug #533135 again - that would've made things simpler [09:05] Launchpad bug 533135 in plymouth "System fails to boot with plymouth installed (nouveau driver with >1 display)" [Medium,Triaged] https://launchpad.net/bugs/533135 [09:05] al-maisan: ok, next question is whether it's reproducible when booting without 'splash' [09:06] slangasek: I will try that. === radoe_ is now known as radoe [09:20] Hi, [09:20] I am having a grub problem with Lucid: [09:20] On boot I get this message: http://pastey.net/135171 [09:20] Pressing a key just prints the message again :/ [09:20] Any idea? [09:22] agateau: wow, I've never seen that before. could you mail that to bug-grub@gnu.org? [09:22] cjwatson: will do [09:23] slangasek: booting w/o splash makes no difference i.e. the file system is checked and the boot-strapping is stuck [09:23] agateau: what system is this? [09:23] cjwatson: googling for the message I found people having a similar issue with memtest86 on asus bios (the machine is an asus), do you think it could be related? [09:23] al-maisan: excellent, that makes it much easier to debug ;-) Try booting without quiet, without splash, and with --verbose [09:23] yes, I just found the same thing [09:24] it probably is indeed related [09:24] it's a brand new asus laptop p81ij [09:24] slangasek: will do. [09:25] cjwatson: I assume you found http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549429 [09:25] Debian bug 549429 in memtest86+ "error: too small lower memory (0x99100 > 0x96000)" [Important,Open] [09:26] yes [09:26] cjwatson: I am not familiar with memtest86, do you think I can try the binaries they suggest in this report? [09:26] you aren't trying to boot memtest86+, are you? [09:26] cjwatson: no [09:26] then those binaries won't help [09:26] ok [09:26] I tried to reach grub interactive mode, but could not [09:27] wait, just got it [09:27] mmm [09:27] There are only Memory test entries [09:27] I miss a kernel here! [09:28] hah [09:29] * agateau boots on a usb key [09:29] so you *are* booting memtest86+ [09:29] what language are you using? [09:29] bryceh: there's something very strange with the xserver-xorg-video-displaylink package in the NEW queue; it seems to contain two copies of the upstream source, one in a subdir [09:29] french [09:29] some kind of locale issue with the boot loader? [09:30] slangasek: hmm .. ok .. I have a console full of log statements, is there anything in particular you'd like to know? [09:30] don't know if it's important, but I actually translated the last line of the message I pasted from french to english, the rest was in english [09:31] So, um, will all the bugs in the archive queue be processed before release? Any way I can expedite a bug in that queue? [09:31] slangasek: btw, the last line reads: "plymouth-log state changed from pre-start to spawned" [09:31] al-maisan: the last four or five lines are probably the place to start; maybe easier to take a photo? [09:31] agateau: there was a particular bug I was thinking of, but doesn't seem to be that. nevertheless, I'd like to see your /boot/grub/grub.cfg [09:31] slangasek: let me do that .. just a minute [09:31] al-maisan: ah, that job only runs once the 'filesystem' event is emitted [09:31] so that tells us something [09:32] cjwatson: sure [09:32] just a minute [09:32] aha [09:32] tsk, plymouth-log.conf calls a plymouth command not documented in plymouth --help [09:33] cjwatson: http://pastey.net/135172 [09:34] mmm the BEGIN END 10_linux does not sound very good [09:36] mmm, I have no linux-image-generic installed :/ [09:37] cjwatson: ^ no wonder it does not boot [09:37] cjwatson: I think that's my mystake [09:37] agateau: that would do it, yes ... [09:37] cjwatson: I moved the package selection from old laptop to new laptop with a combination of dpkg --get-selections, dpkg --clear-selections, dpkg --set-selections [09:38] cjwatson: and I guess I somehow uninstalled the kernel :/ [09:39] pitti, the HPLIP problem I mentioned earlier I cannot reproduce, probably the user has a broken file somewhere, but I have a more important problem, bug 530327. [09:40] Launchpad bug 530327 in hplip "hplip has dependency on libcups2-dev (for cups-config cmd)" [High,New] https://launchpad.net/bugs/530327 [09:41] pitti, should we move cups-config to a non-dev package or what should we do? [09:45] bryceh: it pains me to see a package that was successfully using dh 7 switch to xsfbs :( [09:47] cjwatson: hi, I have a odd issue with ssh, I have a running ssh connection on the client but the command that was run has exited and on the server I see no sshd running anymore for the connection. the client still does not timeout (I use --batch-mode, this is the auto-ugprade tester). any idea? do I miss another config option for this ? [09:49] slangasek: here's the screen shot: https://devpad.canonical.com/~muharem/IMG_4284.JPG [09:49] mvo: is there still a port-forward open or something? running the client with -vvv might help [09:50] ssh should automatically exit when all its channels are closed, without the need for any options [09:52] al-maisan: very odd; I don't see anything here that tells me why it stopped where it did [09:53] hmm.. [09:53] cjwatson: thanks! I run with -vvv now (will take a bit, it only hangs at the end of the lts-mythbuntu upgrade test. [09:53] al-maisan: I guess it's most likely to be a bug in plymouth, then [09:53] al-maisan: since plymouth is responsible for console redirection at boot time [09:53] aha [09:54] slangasek: yeah .. I was scrolling up a bit and did not see any error message that would stand out either [09:56] tkamppeter: we could theoretically move it to the cups binary package, but why does hplip even need that? we do not need any runtime detection in hplip, we know where cups lives.. [10:00] slangasek: so, after pressing Alt+SysRq+K I see one more error message, it reads: "General error mounting filesystems." [10:01] "A maintenance shell will now be started." [10:02] "Control-D will terminate this shell and reboot the system" [10:02] pitti, only the debug tool hp-check needs it, for normal printing with HPLIP cups-config is not needed. [10:03] slangasek: the boot continues and gdm comes up, after "sudo /etc/init.d/gdm stop" I can do Ctrl+Alt+F7 and the maintenance shell still seems to be there [10:03] tkamppeter: ah, do we ship this in hplip itself? [10:05] pitti, yes [10:06] pitti, should it go into hplip-dbg? [10:06] tkamppeter: not sure how useful it is; but if you don't normally need it, you might move it to there, and have -dbg depend on libcups-dev perhaps? [10:08] Since beta2 I had * the netbook progra chooser thing break, then gdm started to freeze the system und now the whole thing stopped booting:-( [10:12] al-maisan: ok, so mountall was still running when you hit Alt+SysRq+K, probably waiting for the processing of the 'filesystem' signal to finish; that gives us a small clue, but I still don't know where the bug lies. Can you file a bug on the plymouth package with this information? It's best if Keybuk can take a look at it [10:12] slangasek: will do. [10:16] mvo: any ideas about what's going on in bug #559587 ? xorg-driver-fglrx is now a transitional package and we do this in the preinst of fglrx: pastebin.ubuntu.com/413010/ [10:16] Launchpad bug 559587 in fglrx-installer "package fglrx (not installed) failed to install/upgrade: trying to overwrite '/etc/ati/signature', which is also in package xorg-driver-fglrx 2:8.721-0ubuntu8" [High,Triaged] https://launchpad.net/bugs/559587 [10:17] tseliot: yes, you have files in /etc/ that aren't marked as conffiles... [10:18] tseliot: you should ship these files under /usr/share instead since they aren't really conffiles, declare Conflicts: on the old version of xorg-driver-fglrx that contained them, and in the fglrx preinst, make either the directory, or the individual files, symlinks to the real files in /usr/share [10:21] slangasek - for bug 469752 - that's being backported upstream btw [10:21] Launchpad bug 469752 in firefox "firefox,3.5/3.6 startup-notification bug" [Unknown,Fix released] https://launchpad.net/bugs/469752 [10:21] so i will defer that to lucid-updates [10:21] chrisccoulson: ok [10:22] slangasek: bug #561312 [10:22] Launchpad bug 561312 in plymouth "fcsk hangs up the boot-strapping process" [Undecided,New] https://launchpad.net/bugs/561312 [10:23] slangasek: ah, so this is why they're not removed. Wouldn't a "Conflicts" defeat the purpose of transitional packages? [10:24] tseliot: Conflicts on the *old version*; you don't want to conflict with the transitional package, only with the previous versions of the package that weren't transitional [10:25] so Conflicts: xorg-driver-fglrx (<< 2:8.721-0ubuntu1), I guess? [10:26] slangasek: ok, it makes sense now. Another thing: I think /etc/ati/amdpcsdb.default is supposed to be modified by amd's control panel [10:26] which is why we make a backup of configuration files [10:27] can everybody please have a look at http://qa.ubuntu.com/reports/sponsoring/ and see what should go in as last minute fixes? [10:28] tseliot: but despite making a backup, you always put the new one from the package in place, with the comment in the script that it's required to be updated when the driver is updated? [10:29] slangasek: yes that is correct. I think superm1 implemented this [10:30] tseliot: well, I do think that if we're always going to ignore changes from the control panel, then we shouldn't put them in /etc/ at all since that gives people the wrong impression [10:31] tseliot: (and makes the package itself confusing and complicated in ways it doesn't need to be) [10:31] slangasek: in the light of what I know about this, I agree [10:32] as long as it causes fewer drops into "Low graphics mode", which tend to make a grumpy directhex [10:33] slangasek: I'll send an email to superm1 and to upstream just to be sure that what we do is correct [10:33] directhex: oh, but that's a feature :-P [10:34] tseliot, a driver which supports my new radeon is a feature. x not starting due to missing amdpcsdb.default is a bug [10:35] directhex: a driver which makes you grumpy is a feature :-P [10:35] jokes aside, I'll fix this soon [10:52] zul: your latest seed change to server-ship wants to drop these five packages out of main. If they're supposed to be in main (as implied by server-lucid-canonical-application-support), they need to be seeded *somewhere*; currently they aren't [11:09] lool, I would be happy to test your bogofilter package [11:12] sigh, why do we only get big packages on the armel buildds today ... [11:13] mdz: it's in my PPA [11:13] mdz: thanks for your help [11:13] ogra: someone tries to make you cry [11:13] mdz: the main code change is to fix parsing of the first line of the body [11:14] Tm_T, definately ... gcc, kdeedu, kdebase and tons of haskell [11:14] ogra: muhahahaha === MacSlow is now known as MacSlow|lunch === dholbach_ is now known as dholbach [12:30] can a member of ubuntu-release review bug #516249? [12:30] Launchpad bug 516249 in hdparm "FFe: Please merge hdparm 9.27-2 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/516249 === dyfet` is now known as dyfet [12:56] Hi, what's the most helpful thing to do for Lucid this late in the cycle? Fix FTBFS? [12:57] it's at least useful [12:58] doko__: any better idea? [12:58] tackle unassigned bugs on https://bugs.launchpad.net/ubuntu/lucid/+bugs [13:02] cjwatson: thanks, I'll have a look === ogra_ is now known as ogra === MacSlow|lunch is now known as MacSlow === rgreening_ is now known as rgreening [13:43] simon-o: are [13:43] usp [13:43] ignore that [14:04] james_w: you are doing the archive-admin work today? [14:04] yes [14:07] james_w: can you release pwdhash from the NEW queue? [14:07] (let it in) [14:07] in a bit [14:09] thanks [14:12] superm1: http://people.canonical.com/~mvo/automatic-upgrade-testing/current/ has mythbuntu profiles now and the first bug is discovered (#560691) (just fyi) [14:19] mvo: that is great, thanks [14:23] yw [14:26] mvo: Did you see the bug I filed on update-manager about the package removal list being incorrect? Now that I look for that, it seems quite common. Am I misunderstanding what that list is supposed to cover? [14:27] didrocks: can you merge vala from debian? [14:27] any archive admins around? [14:28] bdrung: sure, I only uploaded today after having it handy for a week (but I wasn't fancy to upload that before the week-end). Didn't noticed that debian had it uploaded. I add this on my TODO, thanks! [14:28] mdz: If it's something doable from the web U/I, yes. [14:29] ScottK, I need an API operation [14:29] or rather, I may [14:30] didrocks: btw, you broke abraca ;) [14:30] ScottK, does that count or not? or should I bug someone else? [14:30] mdz: I'm not sure. [14:31] cjwatson, I may need somebody with privileges to run lp-remove-package.py per DWC [14:31] james_w, pitti, Keybuk ^^ [14:32] mdz: here [14:32] bdrung: I don't see it as a rdep of vala or valac? (in any case, upstream should ship .c file during build) [14:32] mdz: what's the crisis? [14:32] can some archive admin bump casper to something very high ? [14:32] * ogra wants to chatch the one free armel buildd [14:32] ogra: no, you need buildds admin for build scores [14:32] mdz: DWC? [14:32] *catch [14:32] cjwatson, kernel 2.6.32-20.29 contains a serious-looking regression, #-kernel is responding, IS has made a chmod quick fix [14:32] ogra: it's already building [14:32] seb128, err, indeed [14:32] cjohnston, oh [14:32] mdz: I can help out with archive bits if necessary [14:33] DWC calls for the package to be removed next, though I'm open to discussion as to whether that's appropriate in this case [14:33] grmbl, cjwatson indeed [14:33] didrocks: it FTBFS. upstream will release a vala 0.8 compatible version soon. [14:33] What's the bug number? I've been running that kernel for a while now. [14:33] cjwatson, it's only lucid [14:33] ("only") [14:33] cjwatson, it refreshed on the webpage the second you said that :) [14:33] -20 runs fine here.. [14:33] thanks anyway [14:33] persia, I'm in mitigation mode right now [14:33] mdz: do you have a bug reference? [14:33] oh [14:33] persia asked that [14:33] bdrung: sweet. But can you convince them to ship .c generated files in their release too? (it's just an additional line in autotools if they need help) [14:34] didrocks: why? [14:34] mdz: I can't do that one. [14:34] the issue is believed to affect ThinkPads [14:34] (a few, some, all - I don't know) [14:34] mdz: so, is it more serious to render lucid entirely uninstallable for everyone, or to permit ThinkPad users to continue installing this kernel? [14:35] pitti: DealingWithCrisis [14:35] bdrung: it avoids building thing needed to build (like the fact we don't run autoreconf during build). It makes life for package maintainers easier and more and more upstream are adopting this for vala [14:35] cjwatson, already made the call (based on input from apw) that we should block further distribution of the packages [14:35] #ubuntu-kernel is still isolating the root cause from the looks of it [14:35] the one awkward bit about removing it is that it will mean the kernel-overrides script won't work next time, and we'll have to reapply kernel overrides by hand, which is actually non-trivial [14:36] didrocks: abraca uses scons [14:36] 561151 [14:36] or at least potentially non-trivial - I haven't validated recently that the kernel packages precisely match the overrides in the archive [14:36] persia: ^ [14:36] cjwatson: shouldn't be that bad, though; these days, binaries are all in main, so it's easy with the +queue page [14:36] pitti: section/priority mismatches can cause problems [14:37] I don't recommend that people use +queue for the kernel at the moment [14:37] bdrung: ah ok, doesn't know very well scons, maybe no vala integration for autogenerating .c file during release so :( [14:37] unless you've personally validated that all the section/priority fields match [14:38] cjwatson, is it a lesser evil to leave the packages 403? [14:39] mind you, kernel-overrides doesn't actually seem to do anything with priority, which is the significant one for d-i, so if this is a problem then it's already been broken [14:41] mdz: I think pitti's right and they can be removed with minimal knock-on effects [14:41] -19 is already gone, so -20 is our only kernel right now [14:42] though I'm not wild about the precedent here; kernel regressions are far from unheard of and if we removed them all the time it would be very hard to get anything done [14:42] cjwatson: the main difference that I see is that with removing the next version would need to be NEWed again, while with 403 it should just work [14:42] still, as you say, you've already agreed to 403 [14:42] but 403 seems good enough to me, TBH [14:42] pitti,mdz: I'm available by SMS all today for NEW processing [14:42] let's not flood mvo with a new batch of update-manager bugs due to the 403 at this point [14:43] Just as a note, the kernels have been published for three days according to LP: do we expect most active lucid testers have not yet upgraded? [14:43] bad enough that I'm going to be flooded with installer bugs [14:44] cjwatson, thanks [14:44] mdz: is this certain to be fixed today? [14:44] because once I lp-remove-package this, I can't easily undo it [14:44] cjwatson, we have a known good state to roll back to, so I'm optimistic, yes [14:45] specifically which binary package(s) have been 403ed? [14:45] if we don't find a good fix, we should be able to back out the change at least [14:45] cjwatson, [14:45] linux-image-2.6.32-20-generic_2.6.32-20.29_amd64.deb (29.5 MiB) [14:45] linux-image-2.6.32-20-preempt_2.6.32-20.29_amd64.deb (29.9 MiB) [14:45] linux-image-2.6.32-20-server_2.6.32-20.29_amd64.deb (29.5 MiB) [14:45] linux-image-2.6.32-20-386_2.6.32-20.29_i386.deb (29.5 MiB) [14:45] linux-image-2.6.32-20-generic_2.6.32-20.29_i386.deb (29.5 MiB) [14:45] linux-image-2.6.32-20-generic-pae_2.6.32-20.29_i386.deb (29.6 MiB) [14:45] cjwatson: well, upgrades will be broken either way :) [14:46] (wrt. update-manager bug reports) [14:46] so the packages are actually 404 right [14:46] + now [14:47] as in, we chmod-ed on cocoplum and rm-ed everywhere else [14:47] I don't know if 404 is any better or worse than 403 from an update-manager POV [14:48] mdz: this is bug 561151? [14:48] Launchpad bug 561151 in linux "reproducible oops at startup on thinkpad x61s in acpi_ex_read_data_from_field" [High,In progress] https://launchpad.net/bugs/561151 [14:48] oh yes, dholbach said [14:49] cjwatson, yes, that's the master bug now [14:51] damnit, I can't remove just single binaries [14:51] wait, what's going on, I should be able to [14:51] -b ? [14:52] never mind, I was saying -a amd64 -a i386 when I didn't need to [14:52] mdz: http://paste.ubuntu.com/413135/ [15:02] ScottK: I saw it, I check it out today, I'm working on u-m currently anyway [15:02] ScottK: (and thanks :) [15:02] mvo: OK. Let me know if you need anything. === barry` is now known as barry_ [15:07] cjwatson, I've notified NG that you've removed the packages, in case he needs to do any further cleanup [15:07] s/NG/Ng/ === barry_ is now known as barry [15:13] mdz: at some point we should post-mortem whether this was really necessary - it's a trade-off between users affected by a bug, and developers unable to do certain types of work just before final freeze [15:14] cjwatson, feel free to make a note on the incident report for the retrospective [15:20] cjwatson, robbiew is relieving me wrt the kernel incident in progress [15:21] mdz: note> done [15:24] sistpoty|work: can you have a look at bug #516249, too? [15:24] Launchpad bug 516249 in hdparm "FFe: Please merge hdparm 9.27-2 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/516249 [15:25] bdrung: I must admit that I'd prefer someone else handling hdparm than me [15:26] sistpoty|work: can you ping someone? [15:26] i would like to have a yes or no soon. [15:26] pitti: ^^ [15:27] sistpoty|work: another thing: audacious 2.3 [15:27] sistpoty|work: by default, "no" [15:27]