[01:08] <micahg> Amaranth: is compiz required for proper notify-osd now?
[01:40] <Amaranth> micahg: A compositor of some kind is needed for the fade part, yes
[01:40] <Amaranth> Always has been
[01:41] <micahg> Amaranth: ok, but that shouldn't make duplicates happen, right?
[01:41] <Amaranth> duplicates?
[01:41] <micahg> not duplicates, multiples on either side
[01:41] <Amaranth> Oh, I don't know
[01:41] <micahg> bug 559109
[01:41] <Amaranth> compiz doesn't have any effect on notify-osd
[01:41] <Amaranth> and macslow is the author of notify-osd, not me :)
[01:42] <micahg> k, someone mentioned compiz fixed it, so I figured I'd ask you Amaranth, thanks
[01:42] <Amaranth> 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] <ArneGoetje> 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] <RAOF> 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] <RAOF> http://launchpadlibrarian.net/43173338/buildlog_ubuntu-lucid-sparc.glib2.0_2.24.0-0ubuntu1_FAILEDTOBUILD.txt.gz
[03:24] <slangasek> ArneGoetje: hi, you got cut off at "full update"
[03:24] <slangasek> ArneGoetje: 23rd your time, or UTC? :)
[03:31] <ScottK> RAOF: Because that build was taking down the buildds.
[03:31] <lifeless> RAOF: manual policy override :> aka lamontd
[03:31] <ScottK> RAOF: glib2.0 and sparc are not on speaking terms at the moment.
[03:32] <slangasek> rpc.lamontd, I think
[03:33] <RAOF> Ok.  That archive skew causes anything which b-ds on mono-devel to fail to build :(
[03:34] <ScottK> Yep.
[03:35] <lifeless> on all arches ?
[03:35] <RAOF> No, just on sparc.
[03:36] <RAOF> 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] <ScottK> Sparc: Now that hppa can't be complete crap anymore, someone has to do it.
[03:37] <lifeless> RAOF: given that this cropped up early last week, I'd do it.
[03:38] <lifeless> that or fix the glib issue on sparc
[03:39] <RAOF> We have a sparc porter box, don't we?
[03:45] <ScottK> Where we == Canonical, yes.
[03:45] <persia> 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] <ArneGoetje> slangasek: So, we won't have any delta  updates until final release.
[03:46] <persia> NCommander: Any chance you got your sparc booting to help RAOF look at libglib?
[03:46] <ArneGoetje> slangasek: 23rd UTC
[03:47] <ArneGoetje> slangasek: so that the UTC-n timezoners have a chance to get updates in until 22nd their time.
[03:49] <persia> 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] <JontheEchidna> persia: edit_acl.py from ubuntu-archive-tools?
[04:05] <persia> That's likely it.  Thanks.
[04:13] <persia> RIght.  I seem to be good at crashing that :)  Time to find another class of solution :)
[05:38] <slangasek> 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] <slangasek> 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] <ArneGoetje> 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] <ArneGoetje> dpm: ^^
[05:48] <dpm> 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] <ArneGoetje> dpm: should we just say we export the translations at 22:00 UTC on 22nd?
[05:51] <slangasek> ArneGoetje, dpm: yes, I just mean having it a little earlier in the day on the 22nd
[05:51] <dpm> 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] <slangasek> ArneGoetje: is 22:00 early enough that it's available to langpack-o-matic before Saturday?
[05:56] <ArneGoetje> 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] <slangasek> 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] <ArneGoetje> slangasek: yes, including review the logs if anything failed...
[05:59] <ArneGoetje> 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] <slangasek> 22nd @22:00UTC export, + 12h, +1h padding for log review, takes us to 18:00 your time on Friday, right?
[06:01] <ArneGoetje> slangasek: 19:00
[06:01] <slangasek> ok
[06:02] <slangasek> so a few hours earlier is better?
[06:02] <slangasek> 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] <slangasek> especially since I'll be in the air that weekend
[06:03] <ArneGoetje> slangasek: the time for uploading them at 19:00 is OK for me, I can arrange that.
[06:04] <slangasek> ok
[07:26] <dholbach> good morning
[07:28] <RAOF> Good morning!
[07:38] <dholbach> RAOF: HAPPY BIRTHDAY! :-)
[07:38] <RAOF> dholbach: Thanks!
[07:39] <micahg> RAOF: dholbach +1 :)
[08:01] <pitti> Good morning
[08:02] <pitti> apw: WI tracker> no, you still have to do that manually; that's bug 509806
[08:08] <tkamppeter> pitti, hi
[08:08] <pitti> hi tkamppeter; how's the LF summit?
[08:08] <tkamppeter> pitti, starts on Wednesday, flight tomorrow at noon time
[08:11] <tkamppeter> pitti, there are people still complaining that CUPS does not start on boot, on bug 554172
[08:12] <tkamppeter> pitti, was this not an ifupdown problem (do not know bug number) which is already fixed?
[08:13] <pitti> tkamppeter: no idea; this bug does not have any data, such as whether the rc2.d/S50cups link exists, etc.
[08:13] <pitti> tkamppeter: /var/log/boot.log might be useful as well
[08:16] <tkamppeter> pitti, thanks, I asked the user.
[08:24] <al-maisan> 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] <al-maisan> A part of the drive is encrypted FWIW
[08:25] <al-maisan> Is this a known issue?
[08:29] <mdke> how does one get the ability to accept bug nominations for particular releases?
[08:30] <tkamppeter> pitti, found the bug, it was 497299.
[08:30] <mdke> 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] <tkamppeter> bug 497299
[08:33] <tkamppeter> 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] <slangasek> al-maisan: have seen bug reports describing this, but they're as-yet-untriaged - can you try a few things for me?
[08:35] <al-maisan> slangasek: yes, of course.
[08:35] <pitti> tkamppeter: can he please say so in that bug?
[08:35] <slangasek> al-maisan: 1) are the dots under the logo still scrolling, or have they stopped?
[08:35] <slangasek> (tells us whether plymouth is still running)
[08:35] <pitti> tkamppeter: oh, there is a confirmation already
[08:36] <al-maisan> slangasek: I believe they have stopped.
[08:36] <slangasek> al-maisan: ok - Alt+F1 doesn't switch VTs?
[08:36] <al-maisan> slangasek: nope, I tried that.
[08:36] <slangasek> al-maisan: Alt+SysRq+K?
[08:37] <al-maisan> didn't try that
[08:37] <al-maisan> how can I mark a partition to be fsck'ed?
[08:37] <al-maisan> I'd like to do that and reboot in order to try Alt+SysRq+K
[08:38] <tkamppeter> pitti, I changed the tag to verification-done now, so that this bug should get into your SRU queue.
[08:38] <pitti> tkamppeter: yes, so did I
[08:38]  * al-maisan looks for a 'SysRq' key on his keyboard
[08:39] <slangasek> al-maisan: you can set the mount count manually on the filesystem with tune2fs -C <device>; or to force a rootfs check, touch /forcefsck
[08:39] <slangasek> SysRq is the printscreen key
[08:39] <al-maisan> slangasek: right
[08:42] <mvo> al-maisan: probably not helpful for your use-case, but the recovery mode has a filesystemcheck option too
[08:42] <al-maisan> mvo: just did a "sudo tune2fs -l /dev/mapper/ul-h"
[08:42] <al-maisan> rebooting..
[08:44] <tkamppeter> pitti, do you know what goes wrong at bug 559676?
[08:45] <tkamppeter> pitti, it gives the error: update-python-modules: error: hplip-data.private is not a recognized python-support module.
[08:45] <tkamppeter> pitti, issued by update-python-modules
[08:45] <pitti> tkamppeter: perhaps it's trying to install that into a public module dir?
[08:49] <tkamppeter> pitti, hplip-date contains a file /usr/share/python-support/hplip-data.private
[08:50] <mdke> alternatively, is it possible to do a query that shows bugs in a particular package that have been nominated for a release?
[08:51] <tkamppeter> 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] <pitti> 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] <slangasek> 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] <slangasek> mdke: in theory, accepting nominations is tied to upload privs; anywhere you find this to not be true is a bug AIUI
[08:53] <slangasek> mdke: oh, you want it for other people that aren't uploaders, though - hmm
[08:54] <mdke> slangasek: right
[08:55] <mdke> slangasek: that url is helpful though, thanks
[08:58] <nigelb> didrocks, got a minute about bug 542091?
[08:59] <didrocks> nigelb: sure, did you post the latest version of the patch?
[08:59] <nigelb> didrocks, I wanted to run by you the latest version of the hook before I made a debdiff
[08:59] <didrocks> nigelb: ok :)
[08:59] <nigelb> http://pastebin.com/DMpQ0KDA
[08:59] <nigelb> is the prompt too confusing?
[09:00] <nigelb> "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] <lifeless> nigelb: how can the user tell if cheese is running ?
[09:01] <nigelb> lifeless, well, I suppose user could see it in the taskbar?
[09:01] <didrocks> nigelb: right, if it crashes, not sure it's still displayed
[09:02] <nigelb> didrocks, if cheese crashes, doesn't apport deal with it differently?
[09:02] <nigelb> i.e., not via the hook
[09:02] <al-maisan> 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] <didrocks> 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] <al-maisan> 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] <nigelb> didrocks, ok.  will get you a debdiff in a few :)
[09:04] <slangasek> al-maisan: do you have an external monitor plugged in?
[09:04] <didrocks> nigelb: sweet :)
[09:04] <al-maisan> slangasek: sorry, I don't.
[09:05] <slangasek> al-maisan: darn, was hoping this was bug #533135 again - that would've made things simpler
[09:05] <slangasek> al-maisan: ok, next question is whether it's reproducible when booting without 'splash'
[09:06] <al-maisan> slangasek: I will try that.
[09:20] <agateau> Hi,
[09:20] <agateau> I am having a grub problem with Lucid:
[09:20] <agateau> On boot I get this message: http://pastey.net/135171
[09:20] <agateau> Pressing a key just prints the message again :/
[09:20] <agateau> Any idea?
[09:22] <cjwatson> agateau: wow, I've never seen that before.  could you mail that to bug-grub@gnu.org?
[09:22] <agateau> cjwatson: will do
[09:23] <al-maisan> slangasek: booting w/o splash makes no difference i.e. the file system is checked and the boot-strapping is stuck
[09:23] <cjwatson> agateau: what system is this?
[09:23] <agateau> 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] <slangasek> al-maisan: excellent, that makes it much easier to debug ;-)  Try booting without quiet, without splash, and with --verbose
[09:23] <cjwatson> yes, I just found the same thing
[09:24] <cjwatson> it probably is indeed related
[09:24] <agateau> it's a brand new asus laptop p81ij
[09:24] <al-maisan> slangasek: will do.
[09:25] <agateau> cjwatson: I assume you found http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549429
[09:26] <cjwatson> yes
[09:26] <agateau> cjwatson: I am not familiar with memtest86, do you think I can try the binaries they suggest in this report?
[09:26] <cjwatson> you aren't trying to boot memtest86+, are you?
[09:26] <agateau> cjwatson: no
[09:26] <cjwatson> then those binaries won't help
[09:26] <agateau> ok
[09:26] <agateau> I tried to reach grub interactive mode, but could not
[09:27] <agateau> wait, just got it
[09:27] <agateau> mmm
[09:27] <agateau> There are only Memory test entries
[09:27] <agateau> I miss a kernel here!
[09:28] <cjwatson> hah
[09:29]  * agateau boots on a usb key
[09:29] <cjwatson> so you *are* booting memtest86+
[09:29] <cjwatson> what language are you using?
[09:29] <slangasek> 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] <agateau> french
[09:29] <agateau> some kind of locale issue with the boot loader?
[09:30] <al-maisan> slangasek: hmm .. ok .. I have a console full of log statements, is there anything in particular you'd like to know?
[09:30] <agateau> 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] <nigelb> 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] <al-maisan> slangasek: btw, the last line reads: "plymouth-log state changed from pre-start to spawned"
[09:31] <slangasek> al-maisan: the last four or five lines are probably the place to start; maybe easier to take a photo?
[09:31] <cjwatson> 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] <al-maisan> slangasek: let me do that .. just a minute
[09:31] <slangasek> al-maisan: ah, that job only runs once the 'filesystem' event is emitted
[09:31] <slangasek> so that tells us something
[09:32] <agateau> cjwatson: sure
[09:32] <agateau> just a minute
[09:32] <al-maisan> aha
[09:32] <slangasek> tsk, plymouth-log.conf calls a plymouth command not documented in plymouth --help
[09:33] <agateau> cjwatson: http://pastey.net/135172
[09:34] <agateau> mmm the BEGIN END 10_linux does not sound very good
[09:36] <agateau> mmm, I have no linux-image-generic installed :/
[09:37] <agateau> cjwatson: ^ no wonder it does not boot
[09:37] <agateau> cjwatson: I think that's my mystake
[09:37] <cjwatson> agateau: that would do it, yes ...
[09:37] <agateau> 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] <agateau> cjwatson: and I guess I somehow uninstalled the kernel :/
[09:39] <tkamppeter> 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:41] <tkamppeter> pitti, should we move cups-config to a non-dev package or what should we do?
[09:45] <slangasek> bryceh: it pains me to see a package that was successfully using dh 7 switch to xsfbs :(
[09:47] <mvo> 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] <al-maisan> slangasek: here's the screen shot: https://devpad.canonical.com/~muharem/IMG_4284.JPG
[09:49] <cjwatson> mvo: is there still a port-forward open or something?  running the client with -vvv might help
[09:50] <cjwatson> ssh should automatically exit when all its channels are closed, without the need for any options
[09:52] <slangasek> al-maisan: very odd; I don't see anything here that tells me why it stopped where it did
[09:53] <al-maisan> hmm..
[09:53] <mvo> 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] <slangasek> al-maisan: I guess it's most likely to be a bug in plymouth, then
[09:53] <slangasek> al-maisan: since plymouth is responsible for console redirection at boot time
[09:53] <al-maisan> aha
[09:54] <al-maisan> slangasek: yeah .. I was scrolling up a bit and did not see any error message that would stand out either
[09:56] <pitti> 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] <al-maisan> slangasek: so, after pressing Alt+SysRq+K I see one more error message, it reads: "General error mounting filesystems."
[10:01] <al-maisan> "A maintenance shell will now be started."
[10:02] <al-maisan> "Control-D will terminate this shell and reboot the system"
[10:02] <tkamppeter> pitti, only the debug tool hp-check needs it, for normal printing with HPLIP cups-config is not needed.
[10:03] <al-maisan> 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] <pitti> tkamppeter: ah, do we ship this in hplip itself?
[10:05] <tkamppeter> pitti, yes
[10:06] <tkamppeter> pitti, should it go into hplip-dbg?
[10:06] <pitti> 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] <hunger> 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] <slangasek> 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] <al-maisan> slangasek: will do.
[10:16] <tseliot> 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:17] <slangasek> tseliot: yes, you have files in /etc/ that aren't marked as conffiles...
[10:18] <slangasek> 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] <chrisccoulson> slangasek - for bug 469752 - that's being backported upstream btw
[10:21] <chrisccoulson> so i will defer that to lucid-updates
[10:21] <slangasek> chrisccoulson: ok
[10:22] <al-maisan> slangasek: bug #561312
[10:23] <tseliot> slangasek: ah, so this is why they're not removed. Wouldn't a "Conflicts" defeat the purpose of transitional packages?
[10:24] <slangasek> 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] <slangasek> so Conflicts: xorg-driver-fglrx (<< 2:8.721-0ubuntu1), I guess?
[10:26] <tseliot> 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] <tseliot> which is why we make a backup of configuration files
[10:27] <dholbach> 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] <slangasek> 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] <tseliot> slangasek: yes that is correct. I think superm1 implemented this
[10:30] <slangasek> 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] <slangasek> tseliot: (and makes the package itself confusing and complicated in ways it doesn't need to be)
[10:31] <tseliot> slangasek: in the light of what I know about this, I agree
[10:32] <directhex> as long as it causes fewer drops into "Low graphics mode", which tend to make a grumpy directhex
[10:33] <tseliot> slangasek: I'll send an email to superm1 and to upstream just to be sure that what we do is correct
[10:33] <tseliot> directhex: oh, but that's a feature :-P
[10:34] <directhex> tseliot, a driver which supports my new radeon is a feature. x not starting due to missing amdpcsdb.default is a bug
[10:35] <tseliot> directhex: a driver which makes you grumpy is a feature :-P
[10:35] <tseliot> jokes aside, I'll fix this soon
[10:52] <slangasek> 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] <mdz> lool, I would be happy to test your bogofilter package
[11:12] <ogra> sigh, why do we only get big packages on the armel buildds today ...
[11:13] <lool> mdz: it's in my PPA
[11:13] <lool> mdz: thanks for your help
[11:13] <Tm_T> ogra: someone tries to make you cry
[11:13] <lool> mdz: the main code change is to fix parsing of the first line of the body
[11:14] <ogra> Tm_T, definately ... gcc, kdeedu, kdebase and tons of haskell
[11:14] <Tm_T> ogra: muhahahaha
[12:30] <bdrung> can a member of ubuntu-release review bug #516249?
[12:56] <simon-o> Hi, what's the most helpful thing to do for Lucid this late in the cycle? Fix FTBFS?
[12:57] <doko__> it's at least useful
[12:58] <simon-o> doko__: any better idea?
[12:58] <cjwatson> tackle unassigned bugs on https://bugs.launchpad.net/ubuntu/lucid/+bugs
[13:02] <simon-o> cjwatson: thanks, I'll have a look
[13:43] <bdrung> simon-o: are
[13:43] <bdrung> usp
[13:43] <bdrung> ignore that
[14:04] <bdrung> james_w: you are doing the archive-admin work today?
[14:04] <james_w> yes
[14:07] <bdrung> james_w: can you release pwdhash from the NEW queue?
[14:07] <bdrung> (let it in)
[14:07] <james_w> in a bit
[14:09] <bdrung> thanks
[14:12] <mvo> 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] <Daviey> mvo: that is great, thanks
[14:23] <mvo> yw
[14:26] <ScottK> 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] <bdrung> didrocks: can you merge vala from debian?
[14:27] <mdz> any archive admins around?
[14:28] <didrocks> 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] <ScottK> mdz: If it's something doable from the web U/I, yes.
[14:29] <mdz> ScottK, I need an API operation
[14:29] <mdz> or rather, I may
[14:30] <bdrung> didrocks: btw, you broke abraca ;)
[14:30] <mdz> ScottK, does that count or not? or should I bug someone else?
[14:30] <ScottK> mdz: I'm not sure.
[14:31] <mdz> cjwatson, I may need somebody with privileges to run lp-remove-package.py per DWC
[14:31] <mdz> james_w, pitti, Keybuk ^^
[14:32] <cjwatson> mdz: here
[14:32] <didrocks> 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] <cjwatson> mdz: what's the crisis?
[14:32] <ogra> can some archive admin bump casper to something very high ?
[14:32]  * ogra wants to chatch the one free armel buildd
[14:32] <seb128> ogra: no, you need buildds admin for build scores
[14:32] <pitti> mdz: DWC?
[14:32] <ogra> *catch
[14:32] <mdz> cjwatson, kernel 2.6.32-20.29 contains a serious-looking regression, #-kernel is responding, IS has made a chmod quick fix
[14:32] <cjwatson> ogra: it's already building
[14:32] <ogra> seb128, err, indeed
[14:32] <ogra> cjohnston, oh
[14:32] <pitti> mdz: I can help out with archive bits if necessary
[14:33] <mdz> 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] <ogra> grmbl, cjwatson indeed
[14:33] <bdrung> didrocks: it FTBFS. upstream will release a vala 0.8 compatible version soon.
[14:33] <persia> What's the bug number?  I've been running that kernel for a while now.
[14:33] <mdz> cjwatson, it's only lucid
[14:33] <mdz> ("only")
[14:33] <ogra> cjwatson, it refreshed on the webpage the second you said that :)
[14:33] <pitti> -20 runs fine here..
[14:33] <ogra> thanks anyway
[14:33] <mdz> persia, I'm in mitigation mode right now
[14:33] <cjwatson> mdz: do you have a bug reference?
[14:33] <cjwatson> oh
[14:33] <cjwatson> persia asked that
[14:33] <didrocks> 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] <bdrung> didrocks: why?
[14:34] <ScottK> mdz: I can't do that one.
[14:34] <mdz> the issue is believed to affect ThinkPads
[14:34] <mdz> (a few, some, all - I don't know)
[14:34] <cjwatson> 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] <cjwatson> pitti: DealingWithCrisis
[14:35] <didrocks> 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] <mdz> cjwatson, already made the call (based on input from apw) that we should block further distribution of the packages
[14:35] <mdz> #ubuntu-kernel is still isolating the root cause from the looks of it
[14:35] <cjwatson> 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] <bdrung> didrocks: abraca uses scons
[14:36] <dholbach> 561151
[14:36] <cjwatson> or at least potentially non-trivial - I haven't validated recently that the kernel packages precisely match the overrides in the archive
[14:36] <dholbach> persia: ^
[14:36] <pitti> cjwatson: shouldn't be that bad, though; these days, binaries are all in main, so it's easy with the +queue page
[14:36] <cjwatson> pitti: section/priority mismatches can cause problems
[14:37] <cjwatson> I don't recommend that people use +queue for the kernel at the moment
[14:37] <didrocks> bdrung: ah ok, doesn't know very well scons, maybe no vala integration for autogenerating .c file during release so :(
[14:37] <cjwatson> unless you've personally validated that all the section/priority fields match
[14:38] <mdz> cjwatson, is it a lesser evil to leave the packages 403?
[14:39] <cjwatson> 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] <cjwatson> mdz: I think pitti's right and they can be removed with minimal knock-on effects
[14:41] <pitti> -19 is already gone, so -20 is our only kernel right now
[14:42] <cjwatson> 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] <pitti> 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] <cjwatson> still, as you say, you've already agreed to 403
[14:42] <pitti> but 403 seems good enough to me, TBH
[14:42] <cjwatson> pitti,mdz: I'm available by SMS all today for NEW processing
[14:42] <cjwatson> let's not flood mvo with a new batch of update-manager bugs due to the 403 at this point
[14:43] <persia> 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] <cjwatson> bad enough that I'm going to be flooded with installer bugs
[14:44] <mdz> cjwatson, thanks
[14:44] <cjwatson> mdz: is this certain to be fixed today?
[14:44] <cjwatson> because once I lp-remove-package this, I can't easily undo it
[14:44] <mdz> cjwatson, we have a known good state to roll back to, so I'm optimistic, yes
[14:45] <cjwatson> specifically which binary package(s) have been 403ed?
[14:45] <mdz> if we don't find a good fix, we should be able to back out the change at least
[14:45] <mdz> cjwatson,
[14:45] <mdz> linux-image-2.6.32-20-generic_2.6.32-20.29_amd64.deb (29.5 MiB)
[14:45] <mdz>   linux-image-2.6.32-20-preempt_2.6.32-20.29_amd64.deb (29.9 MiB)
[14:45] <mdz>   linux-image-2.6.32-20-server_2.6.32-20.29_amd64.deb (29.5 MiB)
[14:45] <mdz>   linux-image-2.6.32-20-386_2.6.32-20.29_i386.deb (29.5 MiB)
[14:45] <mdz>   linux-image-2.6.32-20-generic_2.6.32-20.29_i386.deb (29.5 MiB)
[14:45] <mdz>   linux-image-2.6.32-20-generic-pae_2.6.32-20.29_i386.deb (29.6 MiB)
[14:45] <pitti> cjwatson: well, upgrades will be broken either way :)
[14:46] <pitti> (wrt. update-manager bug reports)
[14:46] <elmo> so the packages are actually 404 right
[14:46] <elmo> + now
[14:47] <elmo> as in, we chmod-ed on cocoplum and rm-ed everywhere else
[14:47] <elmo> I don't know if 404 is any better or worse than 403 from an update-manager POV
[14:48] <cjwatson> mdz: this is bug 561151?
[14:48] <cjwatson> oh yes, dholbach said
[14:49] <mdz> cjwatson, yes, that's the master bug now
[14:51] <cjwatson> damnit, I can't remove just single binaries
[14:51] <cjwatson> wait, what's going on, I should be able to
[14:51] <pitti> -b ?
[14:52] <cjwatson> never mind, I was saying -a amd64 -a i386 when I didn't need to
[14:52] <cjwatson> mdz: http://paste.ubuntu.com/413135/
[15:02] <mvo> ScottK: I saw it, I check it out today, I'm working on u-m currently anyway
[15:02] <mvo> ScottK: (and thanks :)
[15:02] <ScottK> mvo: OK.  Let me know if you need anything.
[15:07] <mdz> cjwatson, I've notified NG that you've removed the packages, in case he needs to do any further cleanup
[15:07] <mdz> s/NG/Ng/
[15:13] <cjwatson> 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] <mdz> cjwatson, feel free to make a note on the incident report for the retrospective
[15:20] <mdz> cjwatson, robbiew is relieving me wrt the kernel incident in progress
[15:21] <cjwatson> mdz: note> done
[15:24] <bdrung> sistpoty|work: can you have a look at bug #516249, too?
[15:25] <sistpoty|work> bdrung: I must admit that I'd prefer someone else handling hdparm than me
[15:26] <bdrung> sistpoty|work: can you ping someone?
[15:26] <bdrung> i would like to have a yes or no soon.
[15:26] <sistpoty|work> pitti: ^^
[15:27] <bdrung> sistpoty|work: another thing: audacious 2.3
[15:27] <pitti> sistpoty|work: by default, "no"
[15:27] <pitti> given how much trouble it sometimes causes, I wouldn't change critical pieces like this at this point
[15:28] <sistpoty|work> bdrung: got a FFe for audacious filed already? (the list is just too long :/)
[15:30] <bdrung> sistpoty|work: no. i have prapared a package based on debian's git repo and uploaded into my ppa. it's tested by some people. i have to convert the package to debian merges and then it's ready for the FFe.
[15:31] <sistpoty|work> bdrung: straight from what I recall about audacious: shouldn't be really a problem imho, as long as you make sure it's well tested
[15:32] <sistpoty|work> bdrung: just read your comment about autotools-dev, I'll mark that won't fix then, ok?
[15:32] <bdrung> sistpoty|work: k
[15:33] <bdrung> pitti: the newer hdparm version is required by SSD owners (-> TRIM)
[15:34] <pitti> in which way?
[15:34] <pitti> bdrung: does hdparm issue those commands by itself?
[15:35] <bdrung> pitti: the wiper script that cleans the SSD required the new hdparm version
[15:35] <mdz> cjwatson, <apw> robbiew, mdz, i have three reliable confirmations that a single patch revert will resolve the thinkpad issues
[15:35] <pitti> but we have tested lucid for 5 months on SSDs without it
[15:36] <pitti> bdrung: I really want to avoid yet another issue like bug 515023
[15:36] <bdrung> pitti: the wiper script uses  --trim-sector-ranges-stdin
[15:37] <pitti> bdrung: how is the wiper script called?
[15:37] <bdrung> wiper /dev/sdXY
[15:38] <bdrung> and wiper /dev/sdXY --commit for actual doing the clean
[15:38] <pitti> bdrung: I mean, is it cron'ed, or otherwise integrated?
[15:38] <bdrung> pitti: manually run by the user
[15:38] <superm1> tseliot, slangasek I think we'll have to defer to what AMD says is the best POR for that file to prevent these upgrade problems
[15:38] <pitti> bdrung: but who will actually do that?
[15:38] <bdrung> the best solution would be that the kernel supports TRIM
[15:38] <pitti> bdrung: we might provide a newer version in lucid-backports for the adventurous folks perhaps?
[15:39] <pitti> but few, if any users will even know about stuff like that
[15:39] <pitti> (not that I do..)
[15:39]  * pitti reads http://en.wikipedia.org/wiki/TRIM
[15:40] <tseliot> superm1: yes, let's see what they say
[15:40] <bdrung> pitti: http://ubuntuforums.org/showthread.php?t=1272893 http://www.ocztechnologyforum.com/forum/showthread.php?60882-wiper.sh-discussion-thread-%28Linux-TRIM-tool%29
[15:41] <pitti> bdrung: to me this sounds utterly scary, nothign like we should rush into lucid without ever having tested it on a large scale
[15:41] <pitti> other opinions appreciated, though
[15:42] <pitti> but a bug in this could potentially wipe your entire disk
[15:42] <bdrung> pitti: in the prepared package, the wiper script will not be installed
[15:42] <m_anish> Hi I am facing a peculiar problem.. I have just installed ubuntu-lucid-beta2 and installed the sugar-emulator-0.88 package (there is some bug in karmic that doesn't allow sugar-emulator/xephyr to work)... anyways sugar-emulator is now working in lucid but it seems to have screwed up my touchpad settings. When I left-click instead of performing the normal left-click operation it turns the normal pointer to a hand... I have to use CTRL+Left click t
[15:42] <m_anish> o make left click work. Any ideas how to fix this?
[15:48] <ScottK> m_anish: Help for Lucid is in #ubuntu+1
[15:48] <m_anish> ScottK, Ok thanks!
[15:52] <apw> cjwatson, robbiew, unless anyone objects I will upload this kernel fix now
[15:54] <robbiew> apw: fine by me...you should probably update bug 526354...so those affected by that issue know
[15:55] <apw> robbiew, done
[15:56] <robbiew> thnx
[15:56] <apw> cjwatson, if i upload a non-ABI bumper will things be ok following the deletion?
[15:57] <cjwatson> please do it
[15:57] <cjwatson> it'll probably require binary NEW but that's OK
[15:57] <cjwatson> (SMS me if necessary)
[15:57] <apw> cjwatson, ack
[16:03]  * mdz wonders why the git-core package contains multiple copies of some fairly chunky (1M) binaries
[16:04] <cjwatson> mdz: aren't those hardlinks?
[16:04] <mdz> cjwatson, not on my system
[16:04] <cjwatson> 1283400 -rwxr-xr-x 103 root root 984888 2010-02-18 07:36 git
[16:04] <cjwatson> 1283400 -rwxr-xr-x 103 root root 984888 2010-02-18 07:36 git-add
[16:04] <cjwatson> for example
[16:04] <mdz> -rwxr-xr-x 1 root root 984888 2010-02-18 07:36 /usr/bin/git
[16:04] <mdz> -rwxr-xr-x 1 root root 984888 2010-02-18 07:36 /usr/bin/git-receive-pack
[16:04] <mdz> -rwxr-xr-x 1 root root 984888 2010-02-18 07:36 /usr/bin/git-upload-archive
[16:05] <cjwatson> those are hardlinks here, according to ls -li
[16:05] <Chipzz> mdz: have you stat'ed them?
[16:05] <cjwatson> 1283400 -rwxr-xr-x 103 root root 984888 2010-02-18 07:36 git-receive-pack
[16:05] <mdz> Chipzz, they have different inode numbers
[16:05] <cjwatson> 1283400 -rwxr-xr-x 103 root root 984888 2010-02-18 07:36 git-upload-archive
[16:05] <cjwatson> same inode number
[16:05] <mdz> they were put there by dpkg on an ext3 filesystem
[16:06] <mdz> I looked because I was curious why the .deb was so big
[16:06] <cjwatson> the .deb is only 5.5MB
[16:06] <mdz> cjwatson, which seemed like a lot to me for what it is
[16:07] <cjwatson> oh, you mean the ones in /usr/bin, sorry
[16:07] <cjwatson> those aren't hardlinks, indeed, I was looking in /usr/lib/git-core/
[16:08] <cjwatson> seems like a straightforward bug
[16:09] <seb128> does anybody know how is the default dictionnary language set?
[16:09] <seb128> empathy and evolution default to english on a lucid beta2 french install there with french listed as available too
[17:11] <nigelb> asac, you were looking for problems with ssl on firefox?
[17:14] <nigelb> asac, someone in #launchpad has trouble with logging in.  could be part of the problem
[17:32] <persia> hyperair: So I'm thinking about a compcache spec for UDS: is there a writeup of the requirements LTSP has related to compcache?
[17:33] <hyperair> persia: er.. my experiences with compcache have been bad. did you highlight the wrong person?
[17:35] <persia> Yes, actually.  Sorry :)
[17:35] <hyperair> =)
[17:35] <hyperair> persia: are you sure compcache is stable enough, though? my experiences with compcache forced me to reboot to reclaim the lost memory compcache took
[17:36] <persia> It's being used currently.  It was also merged upstream.  I think we'd benefit from a review of it for maverick.
[17:43] <asac> nigelb: all updates should be fine
[17:43] <asac> e.g. run dist-upgarde
[17:43] <nigelb> asac, oh ok.  I've asked him to try with another browser for now.
[17:45] <asac> nigelb: tell him to upgrade everything
[17:45] <asac> thats really important
[17:45] <nigelb> asac, will do
[18:16] <souffledev> hi guys. i am having segfaults - ff 3.5.9 on 9.10.
[18:16] <souffledev> updated, re-installed multiple times with no success
[18:16] <souffledev> deleted ~/.mozilla
[18:17] <souffledev> i can't find anything about this on LP
[18:25] <souffledev> wait. i think the /usr/lib/firefox-3.5.9/firefox.sh is going into an infinite loop
[18:26] <souffledev> hahaha
[18:26] <souffledev> lmfao
[18:26] <ari-tczew> please move package to jaunty-updates bug 249104
[19:49] <cody-somerville> How interesting. I have a random GTK text input field hovering in the lower right of my screen.
[19:49] <persia> And which process owns it?
[19:49] <persia> (you ought be able to determine this with the X utilities, but it's long enough since I played screen wars that I don't remember which)
[20:03] <cody-somerville> persia, I tried xwininfo but the trouble is that I click right through it.
[20:09] <persia> That's annoying
[20:16] <zul> slangasek: when you get a chance can you have a look at #392759 its a ffe exception for apache2
[20:16] <zul> slangasek: also 533029, thanks
[21:35] <hunger_> Could somebody please fix opensync-plugin-syncml, please? It is not installable in lucid:-/
[21:49] <geser> hunger_: see bug 524938
[21:50] <ramvi> /boot/vmlinuz* doesn't exist on my system. Can I regenerate it some how?
[22:08] <kklimonda> install kernel package
[22:10] <hyperair> linux-image-`uname -r`
[22:10] <cjwatson> he left
[22:10] <hyperair> oh whoops
[22:10] <cjwatson> speaking of which, amd64 kernel NEW-processed, i386 still building
[22:11] <cjwatson> though nearly done, I notice
[22:11]  * hyperair compiles his own kernels
[22:11] <cjwatson> that's nice
[22:11] <hyperair> mmhmm
[22:11] <hyperair> it has things that upstream does not like
[22:11] <hyperair> stuff like BFS, linux-phc
[22:12] <cjwatson> (my comment was relevant because the kernel had to be temporarily removed from the archive today, and this constitutes putting it back; it wasn't an invitation for general "I don't need the archive kernel" :-) )
[22:12] <hyperair> aah i see.
[22:12] <hyperair> why was the kernel removed from the archive?
[22:13] <cjwatson> bug 561151
[22:13] <persia> Apparently it didn't boot for some thinkpads.
[22:13] <hyperair> i see.
[22:13] <hyperair> that sucks.
[22:13] <hyperair> well at least it's fixed.
[22:21] <JamieBennett> Any core-dev around to upload me a patch, https://bugs.edge.launchpad.net/ubuntu/+source/webservice-office-zoho/+bug/561836 ?
[22:32] <ajmitch> JamieBennett: looks like you modified Depends rather than Build-Depends in that debdiff
[22:34] <JamieBennett> ajmitch: ah, sorry, silly mistake
[22:34]  * JamieBennett goes to fix
[22:42] <jpds> Can an archive admin please pass https://launchpad.net/ubuntu/+source/linux/2.6.32-20.30/+build/1687719 through NEW?
[22:43] <jpds> cjwatson / slangasek ^
[22:44] <slangasek> looking
[22:46] <ccheney> NCommander: how far do you think we are away from having a new arm patch?
[22:46] <ajmitch> JamieBennett: fwiw, from looking at setup.py I think you need the python-distutils-extra package, best to do a test build in pbuilder or similar to check it
[22:47] <JamieBennett> ajmitch: just building it in pbuilder now, thanks for the heads-up
[22:48] <slangasek> jpds: accepted
[23:02] <mathiaz> slangasek: about bug 552786
[23:02] <mathiaz> slangasek: what would be the next step?
[23:02] <mathiaz> slangasek: it seems that Scott doesn't plan to fix it in time for lucid
[23:10] <jdong> *criiiinge* I just saw http://www.exploit-db.com/exploits/12130
[23:11] <jdong> looks like user_xattrs is all tht's needed for this to work
[23:17] <JamieBennett> ajmitch: moved the depend to Build-Depends and tested in pbuilder if you have time to have a look again
[23:18] <ajmitch> ok
[23:22] <slangasek> zul: done
[23:23] <slangasek> zul: did you see my earlier comment about your unseeding of packages that AIUI are supposed to be in main?
[23:23] <ajmitch> JamieBennett: I've unsubscribed -sponsors & will upload in a minute once I've testbuilt it myself
[23:24] <JamieBennett> ajmitch: Thanks !
[23:24] <slangasek> mathiaz: well, I've followed up in the bug; since we're all agreed that the real bug is in upstart, I'd like to still get it fixed there
[23:24] <slangasek> mathiaz: barring that, workarounds in puppet will be considered
[23:25] <mathiaz> slangasek: ok - thanks for the follow up
[23:25] <mathiaz> slangasek: so I'll wait for Scott's reply