[00:12] <apetrescu> I'm trying to build the latest Anjuta that was released recently, but I'm running into a problem caused by the fact that ubuntu's copy of gnome-build is severely, severely outdated
[00:13] <apetrescu> The latest version is 2.24, Ubuntu stocks 0.2.4.
[00:13] <apetrescu> Does anyone know if any deb packages exist for a more recent gnome-build, or should I file a launchpad ticket about this?
[01:34] <acoc> hey guys, I am interested in getting a checkout of the ubuntu-seeds, but https://launchpad.net/ubuntu-seeds says it does not use launchpad for development, where are the seeds located?
[01:43] <TheMuso> acoc: The seeds for ubuntu intrepid for example can be checked ot with this URL: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.intrepid
[01:44] <acoc> TheMuso: thank you, why does that website say it is not developed through launchpad?
[01:45] <TheMuso> acoc: Because the ubuntu-seeds project is only used for bzr branch hosting. There are no tarballs/websites/docs etc associated with it,.
[01:45] <TheMuso> acoc: As far as I understand anyway.
[01:46] <TheMuso> acoc: You can view all bzr branches associated with that project by going to https://launchpad.net/ubuntu-seeds/+branches
[01:46] <acoc> TheMuso, ok thanks, very helpful
[01:46] <TheMuso> acoc: You're welcome.
[07:30]  * maswan looks around, hunting a USN-645-1. :)
[07:33] <asac> maswan: will be published quite soon i guess
[07:34] <asac> maswan: its basically what was announced here: http://www.mozilla.org/security/announce/
[07:35] <pitti> Good morning
[07:36] <pitti> kirkland: yes, I told you; you need to add the addon to the computer device, like in ./policy/10osvendor/10-cpufreq.fdi
[07:37] <pitti> kirkland: the computer device is always initialized, so you can use it as a kind of "startup hook" to trigger the calling of addons (scripts in /usr/lib/hal/)
[07:40] <maswan> asac: Ah, ok. I was just a bit confused when the changelog I got mailed to me just said "oh, see usn-645-1 for whatever critical stuff we're updating now" :)
[07:42] <asac> maswan: yes. we dont include the detailed advisory titles/CVEs in changelog anymore; otherwise we wont be able to deliver in-sync security updates with mozilla
[07:45] <torkel> asac: It is intentional that I have to select which certificate to use multiple times (again) in intrepid? The "remember" checkbox is missing.
[07:47] <asac> torkel: what kind of certificates are those? client or server side?
[07:47] <torkel> asac: client
[07:48] <asac> torkel: ok. but thats not a regression right?
[07:48] <asac> (regression in the last upload)
[07:49] <dholbach> good morning
[07:50] <asac> good morning dholbach
[07:50] <torkel> asac: well, before the last upload I was only asked once (for each site), now I am asked multiple times
[07:50] <dholbach> hiya asac
[07:50] <torkel> asac: I think it changed with the upload of xulrunner, not ff
[07:51] <asac> torkel: what update was that. build3 -> build6? or was it 1.9.0.1 -> 1.9.0.2
[07:51] <asac> ?
[07:52] <torkel> build3->build6
[07:52] <torkel> i.e the upload that was done yesterday
[07:53] <asac> interesting. anyway. the next nss upload should fix it for you
[07:53] <torkel> asac: great. thanks!
[07:53] <asac> i am currently trying to find out if we already have a test build somewhere
[07:53] <asac> torkel: but client certs still work at least right?
[07:54] <asac> torkel: ohj ... you said "again" above. does it mean that you had the same problem in 1.9.0.1?
[07:56] <torkel> asac: somewhere in the hardy timeframe I switched FF to automatically choose a cert, and I just turned it off again a week ago. So I really don't know when it was fixed.
[07:57] <tjaalton> asac: hey, is it a known bug that after a firefox update the current running instance can't be shutdown from File-Quit (or with ctrl-q)?
[07:57] <asac> tjaalton: well. there are plenty of bugs surrounding upgrades while still running
[07:58] <asac> tjaalton: do you have ubufox installed?
[07:58] <tjaalton> asac: yes, it's a normal ubuntu system
[07:58] <asac> i think the latest version should offer you a restart button ... which might help a bit
[07:59] <tjaalton> the notification bubble?
[07:59] <asac> tjaalton: are you currently in such a state?
[07:59] <tjaalton> erm, popup
[07:59] <tjaalton> yep
[07:59] <tjaalton> this is hardy
[07:59] <asac> tjaalton: within firefox ... there should be a yellow notification bar
[07:59] <asac> tjaalton: ah
[07:59] <tjaalton> I'll try it on intrepid
[08:00] <asac> tjaalton: on intrepid there should be a restart button in a notification area (like remember password) after upgrading firefox ... which might still have issues :)
[08:02] <tjaalton> asac: heh, ok. will see how it works
[08:03] <asac> tjaalton: http://people.ubuntu.com/~asac/screenshots/ubufox_restart_notification_intrepid.png
[08:04] <tjaalton> asac: oh, looks nice
[08:05] <alex_mayorga> hi, is there a chance of bluez-gnome-1.4 making it into intrepid?
[08:07] <tjaalton> asac: hum, nothing happened :) I got the light bulb on the notification area, but no restart button on the browser
[08:08] <alex_mayorga> tjaalton, you mean in FF .2 update?
[08:08] <tjaalton> alex_mayorga: right, the latest one
[08:09] <alex_mayorga> I got a reset button on FF, similar to the save password one, after the latest safe-upgrade on Intrepid
[08:10] <alex_mayorga> I also got a button to "my rights" or something similar after the restart, that contained bits of the Mozilla license
[08:11] <alex_mayorga> oddly, the light bulb notification didn't go away even after the FF restart
[08:11] <asac> alex_mayorga: light bulb notification == the thing in the system tray?
[08:11] <alex_mayorga> asac, exactly
[08:12] <asac> tjaalton: strange.
[08:12] <asac> tjaalton: sudo touch /var/lib/update-notifier/user.d/firefox-3.0-restart-required
[08:12] <asac> alex_mayorga: you also got the restart button in-browser?
[08:12] <asac> like /var/lib/update-notifier/user.d/firefox-3.0-restart-required ?
[08:12] <alex_mayorga> I clicked Close button and it went away now
[08:12] <asac> err
[08:12] <asac> http://people.ubuntu.com/~asac/screenshots/ubufox_restart_notification_intrepid.png
[08:13] <alex_mayorga> asac, yes I did, but looks like the notification didn't detected I've restarted already, not that it should IMHO
[08:13] <tjaalton> asac: the file was already there? touching it didn't help
[08:13] <alex_mayorga> asac, yes exactly like that screencap
[08:14] <asac> tjaalton: is there any error in tools -> error console?
[08:15] <asac> tjaalton: also, double check that you have no (old) ubufox instlaled in your profile (if tools -> addons offers you to "uninstall" then go for it)
[08:16] <asac> alex_mayorga: yeah notification area isnt the smartes thing in the world. the in-browser restart button is supposed to replace that at some point completely
[08:17] <alex_mayorga> anyone that might have decision power on the bluez-gnome thingie?
[08:17] <tjaalton> asac: lots. are the new ones in the bottom?
[08:17] <asac> tjaalton: you can filter for "errors" at the top of the error console
[08:18] <davmor2> asac: why won't FF run under valgrind?
[08:18] <asac> tjaalton: if there are still plenty of errors on the console its probably the reason ... would be cool if you could paste a few of those errors
[08:18] <asac> davmor2: it should work
[08:19] <asac> davmor2: i start like: valgrind /usr/lib/firefox-3.0.2/firefox
[08:19] <davmor2> asac: okay ta
[08:19] <tjaalton> asac: yeah, I keep getting more and more of the same error.. one sec
[08:20] <tjaalton> asac: http://pastebin.ubuntu.com/49976
[08:20] <asac> tjaalton: oh.
[08:20] <asac> tjaalton: you are not having latest ubufox version?
[08:21] <asac> tjaalton: that was an intermediate issue. thought i didnt upload that version :/
[08:21] <tjaalton> asac: well I just upgraded, so was the latest one the first with this feature?-)
[08:21] <asac> tjaalton: no. there were more before
[08:22] <asac> at least the one before had that
[08:22] <tjaalton> asac: ok, I'll restart and test the behaviour by hand
[08:22] <davmor2> asac: ta that worked :)
[08:22] <asac> tjaalton: ok 0.6~b1-0ubuntu1 had that issue
[08:23] <asac> tjaalton: i then uploaded 0.6~b1-0ubuntu2 with just that fix
[08:23] <asac> and ubuntu3 is the upgrade you should have received now
[08:23] <asac> tjaalton: thanks
[08:23] <asac> maybe you still had ubuntu1
[08:24] <asac> davmor2: welcome
[08:24] <tjaalton> asac: 0ubuntu1 installed on 16th, 0ubuntu2 on 18th and 0ubuntu3 today :)
[08:24] <asac> tjaalton: maybe you didnt restart firefox ;)
[08:24] <asac> (unlikely i know)
[08:24] <tjaalton> asac: I did, started it right before the latest upgrade :)
[08:25] <tjaalton> anyway, will try with the latest stuf
[08:25] <tjaalton> +f
[08:25] <asac> tjaalton: ok. lets see.
[08:26] <tjaalton> asac: duh, still the same errors
[08:27] <asac> *sigh*
[08:27] <asac> tjaalton: what do you have as LANG?
[08:27] <tjaalton> I wonder if I'm missing something
[08:27] <asac> running plain en_US install?
[08:27] <tjaalton> fi_FI
[08:27] <asac> tjaalton: try to start firefox as LANG=en_US firefox please
[08:28] <asac> tjaalton: btw, is firefox translated at all for you ?
[08:28] <tjaalton> no.. langpack got removed at some point
[08:28] <tjaalton> I'll try reinstalling that
[08:28] <asac> tjaalton: no better not ;)
[08:29] <asac> tjaalton: try LANG=en_US anyway
[08:29] <asac> and then touch the file ;)
[08:30] <alex_mayorga> Bug #273865 anyone?
[08:30] <tjaalton> asac: yeah, that works
[08:30] <asac> tjaalton: ok. thanks. i know what to do then :/
[08:31] <asac> tjaalton: btw, the langpacks are now usually shipped in language-pack-XX
[08:31] <asac> so no need to install the mozilla-firefox-locale-XX packages anymore
[08:31] <asac> its just that they are most likely disabled atm
[08:31] <asac> (in langpack-o-matic)
[08:32] <tjaalton> asac: ok, I reinstalled -fi and the same problem. seems that FF isn't that well translated anyway
[08:33] <asac> tjaalton: yeah. i think the ffox translations have been disabled :)
[08:33] <asac> ArneGoetje: btw, i never received any complain about that from you ^^ ;)
[08:33] <tjaalton> asac: heh, ok. I see some xulrunner-files there
[08:47] <StevenK> bryce: The point of my mail was xterm might then start to show up. :-)
[08:53] <tjaalton> pitti: do you think that shipping a simple fdi file to disable evdev from grabbing the thinkpad_acpi input device would be enough to fix bug 267682 for intrepid?
[08:54] <slangasek> huh, how does stopping evdev from grabbing the input device fix it?
[08:54] <slangasek> (in theory, or otherwise)
[08:55] <tjaalton> works just fine here
[08:55] <tjaalton> after that even battery and hibernate work
[08:55] <slangasek> my question is "how" :)
[08:55] <tjaalton> aha, well, to answer that I'd need to know a bit more about the underlying mess ;)
[08:56] <tjaalton> but I guess one reason why evdev can't handle the battery hotkey is because it's not specified in symbols/inet
[08:56] <tjaalton> commented out.. I don't think there is XF86Battery or equivalent..
[08:59] <slangasek> pitti, ArneGoetje: language-support-extra-de grew a dep on hunspell-de-med, which is in universe and has no MIR?
[08:59] <alex_mayorga> what package would the shutdown window belong to?
[09:01] <dholbach> alex_mayorga: gnome-session AFAIK
[09:02] <alex_mayorga> is it just me or the restart icon is smaller and the text miss aligned?
[09:05] <alex_mayorga> dholbach: thanks, wonder if that should be filed or has already spotted, launchpad won't tell me or I'm queryu
[09:05] <alex_mayorga> ing incorrectly
[09:05] <dholbach> alex_mayorga: try asking in #ubuntu-desktop - somebody might know
[09:24] <alex_mayorga> dholbach, thanks, turns out there a number of reports on that
[09:24] <dholbach> alex_mayorga: ah, great
[09:25] <alex_mayorga> you saved me of yet another dupe :)
[09:42] <tjaalton> what component opens the popup about battery statistics when you hit the hotkey?
[09:44] <sbeattie> pitti: did something happen to the kernel update in dapper-proposed? I can't seem to find it: http://paste.ubuntu.com/50006/
[09:59] <geser> kirkland: thanks for pointing me to your debdiff, it helped a lot to write a similar file for my smart card reader
[09:59] <geser> but now I'm stuck at assigning the device_file. http://paste.ubuntu.com/50012/ contans lshal output for my smart card reader, my current fdi file and the policy file
[10:00] <geser> it works when I use the hard-coded device file name
[10:01] <torkel> tjaalton: gnome-power-manager
[10:02] <tseliot> seb128: as regards my patches for gnome-desktop and gnome-control-panel, shall I add an "ubuntu_" prefix only to the functions which I put in the header file gnome_rr_config.h or shall I add it to any function I added in gnome_rr_config.c and xrandr-capplet.c (even though such functions cannot be accessed externally)? The former makes more sense to me but I'll do as you wish
[10:02] <seb128> tseliot: only for what is public api
[10:02] <tseliot> seb128: ok, agreed
[10:07] <slangasek> raphink: ping
[10:08] <raphink> slangasek: pong
[10:09] <slangasek> raphink: hi, ichthux seeds seem to need updates to not depend on khelpcenter and kghostview, which are both NBS packages; is that something you can take care of?
[10:13] <raphink> slangasek: I could try to find some time
[10:13] <tjaalton> torkel: ok, do you know about it's inner workings?-)
[10:13] <raphink> lately, it's been txwinkinger doing that
[10:13] <ara> hello, i have a question, which package provides system-config-printer-applet? system-config-printer-gnome? or another?
[10:14] <seb128> ara: dpkg -S system-config-printer-applet if it's installed on your box
[10:14] <ara> seb128: ta!
[10:14] <seb128> ara: otherwise you can use packages.ubuntu.com
[10:15] <seb128> you're welcome ;-)
[10:17] <slangasek> raphink: should I contact txwinkinger about it instead?  (if so, how?  no such nick on IRC)
[10:17] <TheMuso> ?C
[10:17] <slangasek> raphink: since kghostview and khelpcenter are NBS packages, they should be removed before the intrepid release, which would make ichthux uninstallable if the seeds aren't fixed
[10:17] <dholbach> slangasek: https://launchpad.net/~txwikinger
[10:18] <raphink> slangasek: he's just not online right now, but he often is
[10:18] <slangasek> dholbach: ah, those letter sare different :-)
[10:21] <cjwatson> pitti: http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt is healthy again
[10:22] <cjwatson> in the "oh my god, it's full of packages" sense
[11:39] <pitti> cjwatson: thanks
[11:40] <pitti> tjaalton: it's certainly a valid workaround
[11:50] <pitti> sbeattie: uh, that looks strange, it still appears on the SRU page
[11:54] <liw> cjwatson, you suggest promoting the schrodinger implementation of dirac, not the dirac-research one? I've heard the latter is of higher quality, do you have other information?
[11:54] <cjwatson> liw: is the latter in Ubuntu?
[11:54] <cjwatson> liw: oh, also, I believe that the schroedinger implementation is the only one that is implemented as a gstreamer plugin
[11:54] <cjwatson> so I was under the impression we only really had one choice
[11:55] <liw> cjwatson, you may be right about gstreamer, at least
[11:56] <liw> cjwatson, "dirac" and related packages should be dirac-research, as far as I can see
[11:56] <cjwatson> ah, I see that the other implementation is in Ubuntu
[11:56] <cjwatson> the BBC didn't object to schroedinger when I spoke to them, though
[11:56] <liw> actually, now that I think about it, the quality difference was probably in encoding
[11:57] <liw> yeah: http://www.schleef.org/blog/2008/09/20/dirac-in-the-news/ -- speaks specifically about encoding
[11:58] <pitti> sbeattie: oh, it's still in NEW, fixing
[11:59] <cjwatson> ah, right
[12:07] <pitti> slangasek: ugh, landscape updates package info *hourly* now? isn't that a bit exaggerated?
[12:10] <pitti> slangasek: I made a followup comment to bug 268765, FYI
[12:13] <tkamppeter> pitti, can you fix bug 269311 today? Then I can upload an s-c-p with updated API today and the driver download can be tested in the beta
[12:13] <pitti> tkamppeter: that's my intent, I just keep getting distracted
[12:18] <gAri-> hello there, where should I report that the kernel traced out while using apparmor?
[12:18] <gAri-> I have the log actually I would like to give to someone who knows what to do with :)
[12:19] <cjwatson> https://bugs.launchpad.net/ubuntu/+source/linux/+filebug
[12:22] <tkamppeter> pitti, can you tell me as soon as possible when you have uploaded the new version, so that I can download it and adapt s-c-p? Thanks.
[12:24] <ogra> so what the heck makes my laptop hardlock on boot at the wine sysctl stuff :/
[12:31] <gAri-> cjwatson: I submitted the bug, will I get information to my email address about the status of the bug?
[12:31] <cjwatson> yes
[12:32] <gAri-> okay I hope some intelligent guys will found out what is happening :)
[12:58] <munckfish> cjwatson: I'm looking at some of the issues that stop the PS3 installer cd working.
[12:59] <munckfish> cjwatson: re lp #251593. I'm working to find out why the spufs module isn't getting loaded auto
[12:59] <munckfish> but I'm just starting out with this.
[12:59] <munckfish> cjwatson: is it worth trying to patch sysvinit to add an extra clause which checks whether spufs module is loaded first?
[13:00] <tjaalton> what time does the beta freeze start?
[13:00] <munckfish> cjwatson: Or at least not fail configuration if mounting /spu fails
[13:00] <cjwatson> sheesh, have people not learned not to ask "what time" questions about freezes yet? :)
[13:00] <TheMuso> munckfish: You might also want to look at the initramfs-tools package.
[13:01] <cjwatson> munckfish: yes, I think so
[13:01] <TheMuso> munckfish: If I get a minute, I will have a look for you.
[13:02] <munckfish> TheMuso: I'm not too familiar with initramfs yet. I'll take a look
[13:03] <munckfish> cjwatson: also re LP #261490. Last cmt you mention probs with nvidia stuff - do you happen to know if those issues were addressed?
[13:04] <cjwatson> munckfish: yes, I believe that got fixed
[13:04] <cjwatson> (though I forget the details)
[13:05] <cjwatson> munckfish: ah yes, https://launchpad.net/ubuntu/+source/nvidia-common version 0.2.2
[13:06] <munckfish> cjwatson: thx
[13:07] <TheMuso> munckfish: Well I can tell you for a fact that the spufs module is not loaded by the initramfs.
[13:08] <munckfish> TheMuso: ok I see
[13:08] <munckfish> Would it have to be loaded explicitly?
[13:09] <munckfish> Apparently is should auto load I believe
[13:09] <munckfish> just like any other filesystem type
[13:09] <TheMuso> munckfish: I think so, since there is no modalias line that could cause it to be loaded by particular hardware being present.
[13:09] <TheMuso> Let me check the module source to be sure though.
[13:09] <munckfish> Hmmmm
[13:09] <munckfish> ok cool
[13:10] <pitti> tkamppeter: will do
[13:13] <TheMuso> munckfish: Yeah I don't think there is any aliases as I said earlier.
[13:13] <munckfish> TheMuso: thx I'll look into it further
[13:17] <pitti> james_w: hm, I patched hal and policykit, and they still not work with CK 0.3; this is becoming a real time sink
[13:19] <munckfish> Would  ...
[13:19] <munckfish> if grep -q '^spufs' /proc/modules 2>/dev/null; then echo "Mount /spu!"; fi
[13:19] <munckfish> ... be a decent way to check for this module?
[13:20] <cjwatson> should use lsmod rather than /proc/modules I feel
[13:20] <cjwatson> interfaces and all that
[13:20] <TheMuso> munckfish: Where does spufs get mounted? I personally think you should actually check for a file in the spufs filesystem.
[13:21] <cjwatson> I don't think it contains any files by default
[13:21] <TheMuso> cjwatson: Oh ok.
[13:21] <cjwatson> why not just mount the filesystem and ignore failures?
[13:21] <cjwatson> if it doesn't work, big deal
[13:22] <cjwatson> i.e. domount spufs "" /spu -ogid=spu || true
[13:22] <broonie> munckfish: There's also /proc/filesystems you could check.
[13:26] <pitti> kirkland: works great now, congrats! uploaded, I simplified the patch a bit and attached it to the bug FYI
[13:33] <geser> pitti: based on kirkland debdiff I've started to write a fdi and a policy file to handle access to smart card readers to finally close bug 57755
[13:35] <geser> pitti: I got it nearly working already but have problems with getting the acls set for the device, see http://paste.ubuntu.com/50012/ to see how far I got already
[13:35] <geser> have you time to help me finalise it?
[13:35] <pitti> not right now, sorry
[13:36] <pitti> I *finally* need to take some time of my own to fix some beta bugs, I kept getting distracted :(
[13:36] <geser> ok
[13:37] <pitti> geser: I'll help you Friday/Monday, is that ok?
[13:37] <geser> yes
[13:38] <geser> the bug is already over two years old so some more days don't matter
[13:40] <munckfish> cjwatson: yeah I prefer  just ignoring the mount if it fails, but still log it.
[13:51] <mvo> cjwatson: could you please check (and merge) https://code.edge.launchpad.net/~mvo/debian-cd/mvo - a small fix that makes apt-cdrom add happy again
[14:01] <james_w> pitti: sorry, was at lunch. That sucks, is there an error, or do they just not work?
[14:01] <pitti> james_w: haven't debugged it yet, I need to find some time to work on my beta bugs
[14:01] <pitti> james_w: I updated the bug, if you are interested
[14:01] <james_w> pitti: sure
[14:02] <cjwatson> mvo: surely that needs some kind of quoting :)
[14:02] <cjwatson> mvo: also I didn't think + worked in sed without special options to support extended regexes
[14:02] <cjwatson> -r I think
[14:03] <cjwatson> mvo: I'll fix it up and merge, thanks
[14:03] <cjwatson> mvo: err, actually, doesn't that break debootstrap? see the comment above
[14:04] <mvo> cjwatson: quoting> right, thanks for fixing that
[14:05] <mvo> cjwatson: debootstrap> not sure, if its needed there, then may we need to remove it later? is there a way for me to test this without building a full cd :) ?
[14:05] <asac> tjaalton: i opened bug 273948 for you :)
[14:07] <mvo> cjwatson: I thought the comment means that its ok to remove them at this point, but I may be wrong of course
[14:13] <kirkland> pitti: cool, thanks :-)
[14:14] <kirkland> pitti: I forgot to add the "Suggests: hal"
[14:14] <kirkland> pitti: did you add that, per chance?
[14:14] <pitti> kirkland: no, forgot about it as well; but *shrug*, no big deal IMHO
[14:14] <kirkland> pitti: it's okay, i'm fixing a bunch of kvm bugs
[14:15] <kirkland> pitti: i'll put it in the next one
[14:15] <kirkland> pitti: thanks for your help, btw ;-)
[14:15] <pitti> kirkland: you're welcome; thanks for teaching me about <spawn> :)
[14:15] <pitti> I already thougt yesterday "gee, why the heck can't FDI files create devices?" :)
[14:15]  * Hobbsee clones pitti, and spawns new copies of him.
[14:16] <pitti> Hobbsee: aww, I'll never finish argueing with those guys
[14:16] <Hobbsee> pitti: oh dear.  that might be a problem.
[14:16] <TheMuso> 5~/c
[14:16] <Hobbsee> pitti: but you could fix bugs quicker!
[14:17] <pitti> and keep up with my mail!
[14:17] <Hobbsee> that too!
[14:19]  * tseliot solves the problem with a simple "sudo /etc/init.d/pitti start"
[14:19]  * pitti clones tseliot as well, and suddenly sees all jockey bugs fixed and all drivers out there packaged for ubuntu
[14:20] <TheMuso> Ah... What I'd wish for a clone of myself. It would help me address accessibility related bugs/features quicker...
[14:20] <Hobbsee> maybe the next UDS needs to focus on people cloning.
[14:21]  * tseliot nods
[14:23] <tjaalton> asac: ooh, thanks
[14:28] <munckfish> cjwatson: I've attached a patch to that bug. I believe it's the postinst that's the problem as it runs with set -e. The normal mountkernfs init script does actually seem to fail.
[14:29] <munckfish> it just shows a message on boot
[14:29] <munckfish> http://launchpadlibrarian.net/17920729/0001-Prevent-postinst-configuration-failure-on-PS3-Cell-i.patch
[14:35] <kirkland> pitti: that was superm1's idea! (spawn)
[14:49] <james_w> I'm looking at bug 263888. SIGUSR1 used to re-open the log files, now it's not trapped. The logrotate file isn't installed by the current package though, as there are no longer any logs to rotate
[14:50] <lool> Hmm I'm looking at a set -e init script and the "status" action; it's implemented as status_of_proc "$ACPID" acpid && exit 0 || exit $?
[14:50] <lool> I wonder why not simply status_of_proc "$ACPID" acpid; exit $?
[14:50] <james_w> is the correct way to fix this to assemble a list of the logrotate md5sums from the old packages and remove the file on upgrade if it matches a known one?
[14:50] <lool> james_w: haha you're touching acpid as well :)
[14:50] <james_w> lool: heh :-)
[14:51] <cjwatson> munckfish: looks fine, thanks; uploaded
[14:51] <lool> james_w: If these were conffiles, I think you should try to remove them chekcing their md5 during upgrades, yes
[14:52] <cjwatson> lool: under set -e, the script will fall over before the exit $?
[14:52] <cjwatson> lool: so 'exit 0' would be clearer
[14:52] <ogra> grmbl, why does evtouch use quilt
[14:52] <cjwatson> lool: but yes, the code you quote is somewhat redundant. That sort of thing makes more sense when you need to do something non-trivial before exiting non-zero, like log_end_msg
[14:53] <ogra> applying the patch to the package takes longer than developing it :P
[14:53] <cjwatson> lool: my usual idiom is: CODE=0; action || CODE=$?; log_end_msg $?; exit 0
[14:53] <jcristau> ogra: because quilt is <3
[14:53] <TheMuso> ogra: We need quilt-edit-patch. :p
[14:53] <cjwatson> err log_end_msg $CODE
[14:53] <lool> cjwatson: Yeah, I wrote exit $? because I thought that it would work for set +e scripts as well
[14:53] <ion_> Why not just action; CODE=$?
[14:53] <cjwatson> ah
[14:53] <ogra> TheMuso, well, the packager could just use simple-patchsy.mk ...
[14:53] <cjwatson> ion_: set -e
[14:53] <ion_> Ah
[14:53] <TheMuso> ogra: oh yeah if it uses cdbs, I agree.
[14:54] <cjwatson> ion_: under set -e, if action returns non-zero, you don't get an opportunity to go further unless you guard it with a conditional
[14:54] <ogra> jcristau, quilt is in descriptor 3, yes :P
[14:54] <ion_> cjwatson: Yes, i was thinking slow. :-P
[14:54] <MacSlow_> tedg, the fusa uses dbus to communicate with gdm I assume.
[14:55] <lool> Thanks all for discussion
[14:55] <lool> In my particular I don't need anything in fact
[14:55] <lool> I can just status_of_proc "$ACPID" acpid  :)
[14:55]  * ogra has evtouch calibration work properly again ... and has it write to /etc/default/evtouch ... so now only fdi inclusion is needed ...
[14:57] <ogra> sillyness of the day, the binary had the fixed font hardcoded without encoding ... which makes the font default to japanese
[14:57] <tedg> MacSlow_: Not in the current incarnation -- the old GDM didn't support DBus.
[14:57]  * ogra shakes head
[14:57] <tedg> MacSlow_: Uses DBus for a bunch of other stuff, but sockets for GDM.
[14:59] <MacSlow> tedg, ah ok... I assumed you intrepid fusa was using dbus with the newer gdm ... but since we don't ship the new gdm yet ... well my bad :)
[15:07] <tedg> MacSlow: I'm hoping it'll use DBus in the Jackalope :)
[15:09] <kirkland> pitti: thanks for the patch clean, i just reviewed it
[15:09] <kirkland> pitti: i'm sorry about that, i'm glad you showed me that
[15:10] <pitti> kirkland: no need to be sorry, I'm just a "clean rules file" fetishist
[15:10] <kirkland> pitti: well, that's something I've been confused about, actually
[15:10] <kirkland> pitti: now it's clear
[15:10] <james_w> does this look ok for a prerm to remove the unneeded conffile? http://paste.ubuntu.com/50129/
[15:11] <kirkland> geser: how did yours come along?
[15:11] <kirkland> geser: this is the debdiff pitti eventually blessed with holy penguin pee: http://launchpadlibrarian.net/17919758/kvm.273764.simplified.debdiff
[15:11] <cjwatson> mvo: I'm pretty sure that debootstrap looks for the md5sum of Packages in the Release file in order to verify that it decompressed properly
[15:11] <cjwatson> mvo: and that therefore removing it will break
[15:12] <cjwatson> mvo: don't see how we could remove it later - the CD is read-only!
[15:12] <cjwatson> mvo: apt-cdrom never used to mind this
[15:12] <geser> kirkland: http://paste.ubuntu.com/50012/ is how far I got, it works when I hardcode the path to the device but I don't manage to get it from hal
[15:13] <kirkland> geser: oh, right, you might have a variable path, huh?
[15:13] <mvo> cjwatson: ok, I will investigate this further
[15:13] <cjwatson> thanks
[15:13] <geser> kirkland: yes, it's a usb device, so the device name depends on the used usb port
[15:14] <kirkland> geser: hrm, that does add a layer of complexity that I was immune to
[15:14] <geser> kirkland: lshal lists it, but I didn't figure out how to access this info in the fdi file
[15:14] <tseliot> seb128: ok, I have those patches. Shall I simply attach the patches in a FFE report or shall put the links to the new source code (i.e. the patched tarball, .changes, etc.)?
[15:15] <seb128> tseliot: can you attach debdiff to some bugs?
[15:15] <mvo> cjwatson: I added #273979 and milestoned it
[15:15] <tseliot> seb128: sure, I can do that
[15:16] <geser> kirkland: but your debdiff was really helpful to help me get to this point at all
[15:16]  * tseliot reboots
[15:17] <kirkland> geser: cool, thanks
[15:17] <kirkland> geser: as soon as I get a smart card, i'll look forward to trying it out ;-)
[15:20] <TheMuso> ?C
[15:43] <MacSlow> gee ... Xorg just blanked and doesn't come back
[15:48] <ion_> Meh, video playback is still broken with the radeon driver. /me downgrades to 1:6.9.0+git20080802.1f3eee36-1ubuntu1 again.
[16:06] <slangasek> pitti: "mirrors only update daily" - says who?
[16:07] <pitti> slangasek: ok, that might be a bit too general; at least that was true for the mirrors I used so far (de, us, es, uk, IIRC)
[16:07] <pitti> are there actually mirrors which update more often?
[16:08] <slangasek> I know the mirror that I pull from is updated more often than that
[16:08] <slangasek> I don't know how often, but - several times a day for sure
[16:09] <pitti> ah, that's news to me; sorry for being imprecise then
[16:10] <cjwatson> the push mirrors update hourly
[16:10] <TheMuso> My ISP's mirror often has new updates at best 3 hours after they get uploaded.
[16:17] <tseliot> seb128: can I use this bugreport for the FFE?
[16:18] <tkamppeter> pitti, it seems that the new pdftoraster filter in CUPS has a bug and causes blank pages to be produced in some cases, see bug 267903 and bug 269691
[16:19] <tseliot> seb128: this one: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/220563
[16:19] <seb128> tseliot: ok
[16:21] <tkamppeter> pitti, I asked the reporters for testing with a replacement filter for pdftoraster, a scriptonly containing '/usr/lib/cups/filter/cpdftocps "$@" | /usr/lib/cups/filter/pstoraster "$@"' and this one works. Should we replace pstoraster in CUPS for the beta?
[16:24] <pitti> tkamppeter: I'm afraid I don't know these filters well enough for a qualified answer; but I thought the idea was to not convert pdf to postscript?
[16:26] <tkamppeter> pitti, yes, we do not want to do too many conversions and Ghostscript can take PDF as input.
[16:27] <tkamppeter> pitti, this filter is an interim workaround for the time being until we get a fixed pdftoraster.
[16:30] <tkamppeter> pitti, Ghostscript needs very many parameters to generate CUPS raster. These parameters are set by PostScript commands in the PPD file. The new pdftoraster and also imagetoraster parse the parameters out of the PPD and create the raster data then. The pstoraster of CUPS takes these parameters embedded in the PostScript stream (by pstops).
[16:31] <pitti> tkamppeter: it's not possible to reproduce the crash?
[16:32] <tkamppeter> pitti, rewriting the parsing process would be awkward and very complicated if one wants to take into account all option types, including custom options.
[16:32] <pitti> tkamppeter: well, your call I think, but it would basically revert 90% of the pdf workflow, wouldn't it?
[16:34] <tkamppeter> pitti, the important core part of page management on PDF (pdftopdf) stays conserved.
[16:34] <tseliot> bryce, seb128: I have attached the 3 debdiffs and the diffstat for the FFE here: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/220563
[16:35] <pitti> tkamppeter: but it'd seem better to me to just fix the segfault instead?
[16:35] <tkamppeter> The best would perhaps be a C program derived from the current pdftoraster (or imagetoraster) which does the ugly parsing but instead of producing raster by itself it calls Ghostscript
[16:36] <tkamppeter> pitti, this is less for the segfault, but because of the black pages.
[16:36] <pitti> hm, I thought it said "crash"
[16:37] <tkamppeter> pitti, Both bugs also complain about black pages.
[16:37] <tkamppeter> pitti, the little script which I have written solved the black page problem.
[16:39] <tkamppeter> pitti, and the reporter of the bug with the crash has even the crash solved. Seems that the crash was caused by broken CUPS raster data fed into the driver (but then the driver should also not crash).
[16:39] <TheMuso> slangasek: I'm about to file a bug that I would like to be milestoned for beta, as I'm probably not going to get it fixed before beta freezre. I feel its important due to the fact that its currently not possible to install ubuntu onto a dmraid array, and successfully detect and make use of other operating systems, i.e no dual boot.
[16:39] <TheMuso> slangasek: Does this sound ok for a milestone?
[16:40] <slangasek> TheMuso: milestoning should be separate from requesting a freeze exception; in cases where the milestone state is relevant to the release team, it's used for tracking bugs that should be blockers for the milestone
[16:41] <slangasek> TheMuso: that doesn't sound to me like a bug that should be a blocker since we're already ahead of where we were before on dmraid support - but I would certainly consider an update for it depending on how intrusive the fix is
[16:42] <TheMuso> slangasek: RIght, I'll just file for a freeze exception once I have it sorted out, probably tomorrow or Friday at the latest.
[16:42] <TheMuso> thanks
[16:45] <calc> i am trying to do a bzr merge and it tells me there is nothing to do :(
[16:46] <calc> is it possible to get it to be more verbose about why? -v doesn't seem to help
[16:47] <slangasek> Riddell: what's the reason for adding openbabel in main, that it should be a blocker for beta? (bug #236051)
[16:47] <jdong> calc: bzr missing other_branch
[16:47] <jdong> calc: shows what you have that they don't, and vice versa. (i.e. commits)
[16:49] <Riddell> slangasek: it was supposed to have a security review, but that never seemed to happen
[16:49] <slangasek> Riddell: well, but I'm wondering if there's a strong reason that this should be a blocker
[16:50] <Riddell> slangasek: I don't know, you'd need to ask security people
[16:50] <slangasek> er
[16:50] <slangasek> I mean, if there's a strong reason that having openbabel in main should be a blocker for beta
[16:50] <slangasek> it should certainly be subject to security review before we let it in...
[16:51] <Riddell> I don't know
[16:51] <Riddell> I'm not a security person
[16:51] <slangasek> if it really needs to be included, then I would lean on the security team more to get the review done; but it doesn't look to me like this is critical to have for intrepid
[16:52] <jdstrand> if I recall, kees did the intial review, said 'fix this', it got fixed
[16:52] <slangasek> but the question I asked you wasn't about security, it was "why do you want openbabel in main?" :)
[16:52] <Riddell> slangasek: because it adds nice features which our user and edubuntu want
[16:52] <Riddell> it's in main
[16:53] <slangasek> oh, it's already promoted and only the security review is missing?
[16:53] <Riddell> only the security re-review
[16:54] <slangasek> kees: can you confirm that openbabel is ok for main now (bug #236051), given that it already is?
[16:54] <cjwatson> calc: which are the two branches involved?
[16:55] <jdstrand> slangasek, Riddell: to pre-emptively answer a perceived to be forthcoming question-- I plan to finish the libzip review today
[16:56] <slangasek> jdstrand: thanks :-)
[16:56] <slangasek> jdstrand: I wasn't going to pester you yet, I know you've had your hands full :)
[16:56]  * jdstrand nods
[16:56] <jdstrand> slangasek: btw, that issue should now be fixed
[16:56] <calc> cjwatson: bzr+ssh://ccheney@bzr.debian.org/srv/bzr.debian.org/bzr/pkg-openoffice/packages/openofficeorg/3.0/experimental/ and bzr+ssh://ccheney@bazaar.launchpad.net/%7Eopenoffice-pkgs/openoffice/3.0-intrepid/
[16:57] <slangasek> jdstrand: the issue of having your hands full? :)
[16:57] <jdstrand> ha!
[16:57] <jdstrand> slangasek: no-- the one we discussed that made my hands more full (a-c-c) ;)
[16:57] <slangasek> oh, if you mean the pam interaction one, I saw the bug closure :)
[16:57] <slangasek> thanks :)
[16:57] <jdstrand> np
[16:57] <kees> slangasek: yeah, I'm happy with babel.
[16:57]  * calc brb son threw up everywhere
[16:57] <slangasek> kees: please close the bug?
[16:58] <kees> slangasek: one sec
[16:58] <kees> slangasek: done
[17:00] <slangasek> kees: thanks :)
[17:01] <calc> back
[17:01] <calc> so yea it won't let me merge the debian into the ubuntu branch it says nothing to be done
[17:02] <calc> and bzr missing incorrectly claims only 1255 to current is missing from the debian tree which is why it won't let me merge an older set (1244) to it
[17:03] <calc> oh nevermind i am nutty
[17:03] <calc> or i think i screwed up something myself without realizing it
[17:03] <calc> the changelog entries threw me off
[17:03] <calc> cjwatson: never mind
[17:04] <calc> he deleted a changelog entry in his set so i was trying to merge something old that i didn't realize i had already merged
[17:04] <calc> doh
[17:05]  * calc notes deleting changelog entries is bad
[17:05] <cjwatson> 1255-current certainly looks right based on logs
[17:06] <calc> cjwatson: yes it is, after more thorough examination i found he deleted changelog entries which caused my basing off of looking at annotate to come up with a number i had already merged without realizing it :\
[17:06] <calc> so i merged head and it works fine :)
[17:10] <cjwatson> oh, yeah, a much better way to check is bzr log of both sides
[17:10] <cjwatson> bzr log --show-ids if you really want to be certain
[17:10] <calc> ok
[17:11] <cjwatson> note that bzr simply doesn't record non-contiguous merges - i.e. if you'd merged up to 1244 and then just revision 1255, it would only remember that you'd merged up to 1244
[17:12] <calc> yea, i try to always merge to a released debian version to base off of
[17:12] <calc> so don't pull individual changesets
[17:13] <calc> unfortunately OOo 3.0 is now pushed back to Oct 7, that seems to be the final date, but is very unlikely to be stable enough in the short window available
[17:14] <calc> they are still finding bugs now but are marking them for 3.0.1
[17:16] <doko> calc: please upload to the ppa. still better than the beta ;)
[17:17] <calc> doko: yes i will be
[17:17] <calc> just making note that it definitely doesn't look like a good idea to replace 2.4.1 anymore
[17:17] <calc> since its pushed back so far
[17:19] <calc> my neighbor just called, we have POWER :)
[17:19] <calc> yipee
[17:20] <calc> so now i will have access to my desktop in a few hours
[17:20] <liw> calc, congratulations
[17:20] <calc> only took them 2 weeks to restore my power, lol
[17:21] <calc> there wasn't even any real damage in the area, apparently the underground power in our neighborhood was feed by an above ground pole at some point
[17:22] <calc> ok i am going offline for a bit, packing up and then heading back to my house :)
[17:23] <cjwatson> good luck
[17:27] <Awsoonn> ping mvo
[17:33] <james_w> lool: updated patch in bug 263888, thanks
[17:43] <tkamppeter> pitti, I will do the following with CUPS: I will put in my script as an interim solution only for the beta, after the beta I will provide something written in C (to use CUPS libraries) which calls Ghostscript feeding in PDF directly.
[17:45] <tkamppeter> pitti, WDYT about that?
[17:48] <Keybuk> http://people.ubuntu.com/~scott/u6y-fail.png
[17:49] <cjwatson> yeah, there's a bug about the ... err ... interesting colour choice
[17:49] <cjwatson> bug 273271
[17:50] <Keybuk> evan's gay genes were clearly trying to co-ordinate colours ;)
[17:50]  * evand hides
[17:50] <davmor2> Keybuk: https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/271512
[17:50] <evand> Keybuk: You'd figure my inability to coordinate color would be evidence to the contrary.
[17:50] <cjwatson> davmor2: that's a different bug
[17:51] <davmor2> Ah yeah sorry :)
[18:04] <Riddell> slangasek: if you're looking for release critical bugs, here's one https://bugs.launchpad.net/rosetta/+bug/273489
[18:07] <pitti> tkamppeter: you are the expert :) but ok for me to rescue printing in the beta; you'll get less feedback, though
[18:13] <tkamppeter> pitti, feedback about known bugs which could mask other bugs is bad.
[18:21] <mathiaz> ahasenack: meh - landscape-client doesn't register when the package is installed from the installer.
[18:22] <mathiaz> ahasenack: that's because landscape-client is not started and dbus is not running
[18:22] <ahasenack> mathiaz: any idea why?
[18:22] <ahasenack> hmm
[18:23] <ahasenack> mathiaz: it may register later when the machine is booted, it tries in the background IIRC
[18:24] <ahasenack> mathiaz: but I suppose there is an ugly error message during the installation
[18:24] <mathiaz> ahasenack: well - in the syslog yes.
[18:24] <jkakar> Is DBUS ever expected to run in the installer?  Is this just an ordering issue?
[18:27] <mathiaz> ahasenack: this is the backtrace: http://paste.ubuntu.com/50203/
[18:27] <ahasenack> mathiaz: "fake start-stop-daemon"?
[18:28] <mathiaz> ahasenack: right - daemons are not started during the install by default
[18:28] <cjwatson> jkakar: dbus is intentionally not started in the installer
[18:28] <mathiaz> ahasenack: well - the registration is retried in the background
[18:28] <cjwatson> landscape-client should cope somehow, perhaps by registering at boot
[18:28] <cjwatson> should as in "needs to"
[18:28] <mathiaz> cjwatson: correct - that's the case
[18:28] <cjwatson> starting daemons in the installer is a real can of worms
[18:29] <niemeyer> Hmm
[18:29] <niemeyer> It can actually already do that, we just need the right flags in place
[18:30] <niemeyer> We just won't be able to tell immediately if there's something wrong (e.g. the registration password, or account name)
[18:30] <mathiaz> well - AFAICT the computer was registered after the first boot - it just doesn't show up right away
[18:30] <ahasenack> mathiaz: what account did you use?
[18:30] <niemeyer> Or it could, anyway..
[18:30]  * niemeyer checks
[18:30] <mathiaz> ahasenack: my own account -
[18:31] <mathiaz> ahasenack: I think it works
[18:31] <mathiaz> ahasenack: it's just that you have to wait for the first reboot and little bit afterwards until the registration process is retried by landscape-client
[18:31] <niemeyer> Oops.. no, apparently the ladnscape-config option was removed at some point
[18:32] <ahasenack> mathiaz: did you reject the registration request on the server?
[18:32] <mathiaz> ahasenack: I think I accepted it
[18:32] <mathiaz> ahasenack: but I've already deleted the computer from my account
[18:32] <ahasenack> ok
[18:33] <niemeyer> mathiaz: Yes, you're right.  Even with that failure, I think that should be the case indeed.
[18:34] <niemeyer> mathiaz: The computer should continue to try connecting.. nowadays the dbus connection in landscape-config is just to make the process faster and to provide live feedback to the user.
[18:34] <mathiaz> ahasenack: I'll redo a test install.
[18:34] <ahasenack> mathiaz: where can we get this iso?
[18:35] <mathiaz> ahasenack: http://cdimage.ubuntu.com/ubuntu-server/daily/
[18:36] <niemeyer> mathiaz: I wonder what would be the best way to handle this
[18:36] <niemeyer> mathiaz: We could support a --no-registration option somewhat easily
[18:36] <niemeyer> mathiaz: But the registration behavior is actually nice, when it does work
[18:36] <ahasenack> hmm, that will take some time to download
[18:36] <ahasenack> like, tomorrow
[18:37] <niemeyer> Maybe we should just prettify the error message
[18:37] <niemeyer> "Connection to the landscape broker failed." or something
[18:38] <cjwatson> it shouldn't cause a visible error in the installer at all
[18:38] <cjwatson> and it needs to not cause the package to fail to configure
[18:38] <cjwatson> that's very important - the installer by design doesn't recover easily from that
[18:38] <mathiaz> cjwatson: ok - as of now that's what happen (the pkg fails to configure)
[18:38] <cjwatson> I know
[18:38] <cjwatson> I read the log
[18:38] <niemeyer> cjwatson: Hopefully neither of these ideas conflict with the suggestion above
[18:39] <cjwatson> they don't, but simply changing the error message isn't enough :)
[18:39] <cjwatson> that's all I'm emphasising
[18:39] <niemeyer> cjwatson: Yeah, I was mostly thinking about landscape-config..
[18:40] <ahasenack> well, seems we can't register during installation
[18:40] <mathiaz> niemeyer: IIUC we could get rid of landscape-config in the postinst if we don't want register at all
[18:40] <ahasenack> but that wizard also prepares the client.conf file
[18:40] <niemeyer> mathiaz: Why does configure fail exactly?
[18:40] <ahasenack> so maybe have an option for it to not attempt the registration, just prepare the conf file
[18:40] <mathiaz> niemeyer: because of the registration with dbus
[18:40] <niemeyer> mathiaz: We want to set it up, and that's the way in which we setup the landscape-client
[18:41] <niemeyer> mathiaz: That's why landscape-client fails.. what exactly is causing the configuration of the package to fail?
[18:41] <niemeyer> Sorry.. s/landscape-client/landscape-config/
[18:41] <mathiaz> niemeyer: landscape-config returns a non 0 value
[18:42] <mathiaz> niemeyer: http://paste.ubuntu.com/50203/
[18:43] <mathiaz> niemeyer: how does landscape-client checks if it should register ?
[18:44] <mathiaz> niemeyer: if there is a retry in the background, landscape-client has a way to figure out that it has all the information to do the registration on its own
[18:45] <niemeyer> mathiaz: How is the script run?
[18:45] <niemeyer> mathiaz: I mean, normally a command in the middle of a script which return s non-zero value won't cause the whole script to return non-zero
[18:45] <niemeyer> mathiaz: I guess it's using some flag to enforce that?
[18:45] <mathiaz> niemeyer: maintainer scripts are run with set -e
[18:46] <niemeyer> mathiaz: Cool, thanks
[18:46] <niemeyer> mathiaz: As I explained above, this is already the case
[18:46] <niemeyer> mathiaz: The whole procedure will work fine, besides this error
[18:46] <niemeyer> mathiaz: The point is that the immediate registration is a good thing, when possible
[18:46] <niemeyer> mathiaz: It informs the user about errors in the information entered, and turns the process into something immediate, rather than on the next restart
[18:47] <niemeyer> mathiaz: So we should just ensure that landscape-config doesn't blow up, so that we don't screw the rest of the installation procedure
[18:47] <mathiaz> niemeyer: right - so I could a || true to the landscape-config command line
[18:47] <niemeyer> mathiaz: But trying to keep the current behavior
[18:47] <niemeyer> mathiaz: Yes, that would be a good immediate solution
[18:48] <niemeyer> mathiaz: We should prevent the traceback too ASAP
[18:48] <mathiaz> niemeyer: could landscape-config be modified to prevent to traceback ?
[18:48] <niemeyer> mathiaz: Definitely
[18:48] <mathiaz> niemeyer: I'd rather have that than adding || true to the maintainer script
[18:49] <mathiaz> niemeyer: there is a legitimate use case to not have the registration working.
[18:49] <niemeyer> mathiaz: Cool, let's do that then
[18:49] <mathiaz> niemeyer: adding a || true would just catch all the other potential errors
[18:50] <niemeyer> mathiaz: True
[18:51] <mathiaz> niemeyer: how fast could this be implemted ?
[18:51] <niemeyer> mathiaz: Quite quickly I believe
[18:52] <tkamppeter> pitti, CUPS package with interim pdftoraster is uploaded
[18:52] <niemeyer> mathiaz: It's just an option and a conditional.. the unittests are a bit boring on that area, though
[18:52] <niemeyer> Well, not an optional
[18:52] <pitti> tkamppeter: ah, ok; did you create an ubuntu bzr branch for cups?
[18:52] <niemeyer> Erm.. not an option.. we'll just catch the exception
[18:53] <mathiaz> niemeyer: could you get something ready today ?
[18:53] <tkamppeter> pitti, no. It is only an interim, the final solution I will put into the Debian BZR.
[18:54] <tkamppeter> pitti, it is only to get more chances to fix printer driver bugs with the beta.
[18:54] <pitti> tkamppeter: ok, noted; we just must be careful to not overwrite it accidentally
[18:54] <niemeyer> mathiaz: It depends on what else is going on.. I'm personally trying to address other important issues ATM.. I'll check if radix or someone else might have some time for it
[18:55] <radix> yo
[18:56] <radix> I can help
[18:56] <tkamppeter> pitti, in principle we should have Ubuntu and Debian CUPS synced. Deviations we do only if needed, for example if we have deadlines ahead or if you are on vacation.
[18:57] <mathiaz> radix: great - could you branch from lp:~ubuntu-core-dev/landscape-client/ubuntu ?
[18:57] <tkamppeter> pitti, I got another note from a bug reporter now, that the interim script did not only fix the black pages but also the crash. The original filter from OP Japan seems to produce really broken CUPS raster.
[18:58] <mathiaz> radix: this is the bzr branch that has the code that is uploaded to the archive.
[18:58] <radix> mathiaz: sure thing
[18:59] <radix> mathiaz: will you upload this as an ubuntu* bump, or should we release a new version number?
[19:01] <mathiaz> radix: what's easier for you
[19:02] <mathiaz> radix: if rolling a new tarball is too complicated we can bump the revision.
[19:02] <mathiaz> radix: The main factor here is time.
[19:02] <pitti> tkamppeter: just posted a followup question to bug 269454
[19:02] <pitti> tkamppeter: I fixed the search_driver() bug, and would like to get this one settled as well, then I'll do a 0.5beta1 release and upload to intrpeid (it's the last bug on https://edge.launchpad.net/jockey/+milestone/0.5)
[19:03] <radix> mathiaz: ok, well, I'll start on the change now :)
[19:03] <mathiaz> radix: thanks
[19:03] <radix> hopefully in the next release we'll be able to have much nicer installer integration
[19:07] <niemeyer> mathiaz: What's the deadline for getting important fixes in?
[19:08] <niemeyer> mathiaz: In general.. I know the sooner the better
[19:08] <mathiaz> niemeyer: well - we're entering BetaFreeze tomorrow
[19:09] <mathiaz> niemeyer: so starting from tomorrow until Beta is released (ie in one week) all the uploads have to be approved by the release team
[19:09] <doko> help, how do I revert the effect of the magnifying glass?
[19:09] <niemeyer> mathiaz: Cool, thanks
[19:10] <mathiaz> niemeyer: we should be able to get Freeze Exception has this issue has a direct impact on the installer.
[19:10] <mathiaz> niemeyer: we should be able to get a Freeze Exception *as* this issue has a direct impact on the installer.
[19:11] <niemeyer> mathiaz: That's cool.  Hopefully we'll be able to get the fix in before the freeze
[19:23] <Riddell> james_w: how come bzr-buildpackage doesn't run debsign?
[19:25] <Keybuk> ok
[19:25] <Keybuk> which smart-arse moved mountkernfs.sh to S02 from S01?
[19:27] <geser> doko: is it save to disable building libgcj-doc in gcj-4.2? libgcj-doc gets also build from gcj-4.3 and this prevents the upload of the i386 build of gcj-4.2 to get accepted
[19:31] <pitti> tseliot, superm1: wrt. bug 262819, do you think the fglrx driver is working well enough to lift it to restricted and add the fglrx-modaliases recommends to jockey-common?
[19:31] <superm1> pitti, i wouldn't do that until we have one that works with the x server in intrepid
[19:31] <Keybuk> pitti: it looks like it was you, so I retract the rudeness ;)
[19:31] <superm1> pitti, it works if you pin the x server to hardy only at this point
[19:32] <pitti> Keybuk: oh, fallout from the debian merge? I don't think I deliberately changed that?
[19:32] <Keybuk> but err, next time you merge sysvinit, please don't rearrange the boot ordering :p
[19:32] <tseliot> pitti: no, we shouldn't do it yet
[19:32] <pitti> superm1, tseliot: ack
[19:32] <Keybuk> pitti: possibly not, a 1 changing to a 2 is hard to spot in a postinst
[19:32] <pitti> Keybuk: there were only three differences in Ubuntu, which I kept (and asked you about)
[19:32] <Keybuk> the fact you didn't include any migration code for upgrades suggests it was simply an accident
[19:32] <superm1> pitti, there is still the problem regarding gcc-3.3 and fglrx too that would be needed to be sorted out before repromoting to restricted
[19:32] <pitti> Keybuk: ok, sorry if that screwed up something
[19:33] <Keybuk> pitti: was breaking readahead
[19:33] <pitti> Keybuk: 02hostname needs it?
[19:33] <Keybuk> no /var/run, /proc, etc. :)
[19:33] <pitti> ah, readahead
[19:33] <doko> geser: I'd say its safe to remove gcj-4.2 in intrepid
[19:33] <superm1> (bug 271794)
[19:39] <doko> pitti: wa this reaaly necessary? please could somebody talk with these guys?
[19:45] <bryce> doko: are you referring to bug 271794?  I talked with those guys about it
[19:45] <bryce> doko: or, I mentioned it to them; no response from them so far
[19:46] <doko> bryce: exactly
[19:46] <bryce> doko: don't bank on seeing a fix to that for intrepid though; they're scrambling just to get caught up to xserver 1.5, and I'm doubtful many other issues are going to get attention
[19:47] <bryce> doko: I have a phone call with them next week, and am planning on re-raising it then and try to get a response
[19:51] <doko> bryce: nice
[19:52] <geser> doko: pdftk still needs libgcj8-1 (from gcj-4.2) and it FTBFS with gcj-4.3
[19:55] <doko> geser: pdftk should better be fixrd
[20:02] <geser> doko: I tried, the problem is that gcj-4.3 doesn't like mixing c++ and java exceptions in one translation unit anymore
[20:03] <geser> it looks like all the code using c++ iostream and fstream needs to be moved into an own file
[20:08] <pitti> doko: erm, I didn't promote gcc-3.3 ... over my dead body... or did I?
[20:08] <pitti> doko: oh, I didn't *phew*
[20:10]  * calc is back in his own his with power finally after two weeks :)
[20:10] <calc> er house
[20:10] <calc> no television though for a while, directv is swamped with realigning the dishes
[20:11] <calc> they couldn't even make an appointment for me since it is too far out in the future for their systems
[20:13] <tedg> calc: You can probably realign it yourself, it isn't hard.
[20:13] <calc> tedg: it looked substantially harder for the hd dish than the old regular one
[20:13] <calc> plus i don't have a > 24' that can reach my roof :-\
[20:13] <tedg> calc: It is, but it's still not that difficult.
[20:13] <calc> grr dropping words, ladder
[20:14] <tedg> Okay, it would be hard if you were trying to throw baseballs at it to align it. ;)
[20:14] <calc> tedg: how do you do it? it completely bent it over, i can't see it up close but its knocked over in at least a 45 degree angle
[20:14] <_Zeus_> calc: is this all from ike?
[20:14] <calc> _Zeus_: yea
[20:14] <tedg> calc: Well, if it's broken, that's another story.
[20:15] <calc> tedg: i'm not sure if its broken or not, but its at least been bent over quite a bit
[20:15] <calc> it might have worked the bolts loose, not really sure though
[20:15] <tedg> calc: But, your STB has meters to show your signal.  Basically you can use those.  But, also, if you go through the full setup (reset everything) it'll tell you the angle to put it at.
[20:15] <calc> ok
[20:15] <calc> well i might see if my dad can help me with it this weekend if he isn't still working on ike stuff (works for a telco)
[20:16] <calc> he access to a better ladder as well
[20:16] <tedg> The latter is key.
[20:16] <tedg> ladder that is.
[20:16] <calc> _Zeus_: ike is why we don't have OOo 3.0 yet ;-)
[20:17] <calc> but now i have internet and access to my desktop pc so i can get it working
[20:17] <tedg> Note, you probably don't want to do "Reset All" to your HD DVR if you have one.  It'll remove all your recordings.  Do it to a non-DVR if you can.
[20:19] <calc> tedg: yea
[20:20] <radix> mathiaz: just to keep you updated, I have a potential fix that's unit tested, and I'm about to do some manual tests on my intrepid box
[20:20] <radix> mathiaz: (for the landscape-config thing)
[20:20] <mathiaz> radix: awesome ! thanks for your help !
[20:24] <acoc> hey guys, could you direct me to your documentation on the cd-build process (ie germinate to livecd)
[20:34] <ahasenack> when a package that was in universe is moved to main after a certain version, what happens to the previous versions? Are they also moved into main? Are they deleted? Do they stay in universe?
[20:36] <slangasek> Riddell: who is he waiting for approval from to run this SQL script?
[20:37] <slangasek> ahasenack: a change in the package's component is done on a per-distro basis; by default only the current development release is affected
[20:37] <jdstrand> slangasek, Riddell: I am comfortable with libzip in main. I hope it's ok I marked the bug 'Fix Released' (since you seemed to only be waiting on me)
[20:37] <slangasek> jdstrand: ok, thanks
[20:38] <ahasenack> slangasek: this package only existed in the development distro (update-motd is the package)
[20:38] <ahasenack> slangasek: I can't seem to find other versions other than the current one in the archive (1.7)
[20:38] <mathiaz> ahasenack: right - update-motd has been added to intrepid.
[20:39] <Riddell> slangasek: I've no idea
[20:39] <ahasenack> mathiaz: so the older versions are gone?
[20:39] <Riddell> jdstrand: great, thanks
[20:39] <ahasenack> I checked main and universe
[20:39] <ahasenack> inside pool
[20:39] <jdstrand> Riddell: sorry for the delay, but it's finally done :)
[20:40] <slangasek> ahasenack: older versions always go away from the archive; that's not related to whether it moves components
[20:40] <ahasenack> slangasek: ah, ok, so the older versions I see in the package directories are from other distros, that's why they are still there
[20:41] <mathiaz> ahasenack: you can find the publishing history in lp - https://launchpad.net/ubuntu/+source/update-motd
[20:41] <slangasek> ahasenack: yes, from previous Ubuntu releases
[20:41] <ahasenack> slangasek: right, thanks
[20:43] <Riddell> siretart: don't suppose you know what's up with this compile?  xine issue https://edge.launchpad.net/ubuntu/intrepid/+source/kdebase-runtime/4:4.1.1-0ubuntu5
[20:45] <jcastro> can someone with a minute please moderate my mail to ubuntu-devel please?
[20:59] <evand> sure
[21:01] <evand> dear lord, 1543 new messages to ubuntu-devel.
[21:01] <evand> jcastro: approved
[21:02] <nxvl> jcastro: around?
[21:03] <jcastro> evand: thanks!
[21:03] <jcastro> nxvl: yep!
[21:12] <calc> fridge take a long time to cool down when they haven't been used for a while
[21:15] <siretart> Riddell: it seems that this part of kdebase is redifining the keyword 'inline' to something funky.
[21:16] <siretart> Riddell: it doesn't look like an issue in xine to me, TBH
[21:19] <tkamppeter> pitti, can you upload a Jockey package ASAP with the fixed API (search_driver() to return result+list of installed packages) so that I can make an s-c-p package? Thanks.
[21:19] <pitti> tkamppeter: still waiting for your input in bug 269454, but I could do an upload without that if needed
[21:20] <tkamppeter> pitti, I have answered your questions now. bug mail notification is always delayed some time.
[21:21] <pitti> tkamppeter: ah, thanks
[21:21] <pitti> tkamppeter: anyway, I'm about to go to bed, so I'll do a quick upload now and a better one tomorrow
[21:22] <pitti> tkamppeter: I documented the search_driver() result structure in README.txt, FYI
[21:24] <tkamppeter> pitti, which hour tomorrow will the beta freeze be.
[21:24] <pitti> tkamppeter: depends on slangasek, I don't know
[21:26] <tkamppeter> pitti, thanks in advance for the quick upload.
[21:41] <pitti> tkamppeter: uploaded
[21:44] <NCommander> good $TIME all
[21:51] <cjwatson> evand: it hasn't even been that long since I processed the queue. I suspect it's getting joe-jobbed
[21:54] <evand> cjwatson: indeed, that's exactly what it was
[22:02] <slangasek> yes, u-d-a is also getting joe-jobbed
[22:09] <andrew_sayers> mdke: are you available to talk about IE6?
[22:13] <mdke> andrew_sayers: sure thing
[22:14] <andrew_sayers> mdke: ubuntu-doc better?
[22:14] <mdke> yeah
[22:30] <apachelogger> pitti: apport retracing marks a bug as duplicate of a private bug, but doesn't mention/explain the private state, which apparently confuses users (at least the one who just mentioned that) :/
[23:05] <kirkland> bryce: ping
[23:06] <kirkland> bryce: i'm nearly done fixing the kvm/keycode mapping bug
[23:06] <kirkland> bryce: i have an X11 question, though
[23:06] <kirkland> bryce: in the configure, I need a check to conditionally add the -lX11
[23:07] <kirkland> bryce: for now, i just stubbed -lX11 onto the beginning of the SDL_LIBS
[23:07] <kirkland> bryce: which "works", but it seems like that might be brittle
[23:07] <kirkland> bryce: i'm hoping you might point me at some source with a more appropriate check that I can clone
[23:09] <slangasek> eew, you're doing something that requires linking against libX11 directly? :)
[23:11] <kirkland> slangasek: as opposed to... ?
[23:11] <slangasek> I don't know - what are you doing that requires linking to libX11?
[23:12] <kirkland> slangasek: detecting evdev or not in kvm's internal qemu
[23:13] <kirkland> slangasek: http://pastebin.ubuntu.com/50278/
[23:13] <kirkland> slangasek: keycodes = XGetAtomName(info.info.x11.display, desc->names->keycodes);
[23:13] <slangasek> ah, yum
[23:13] <cjwatson> kvm/keycode> hooray!
[23:14] <kirkland> cjwatson: i'm 99% of the way there ;-)
[23:14] <cjwatson> you make me so happy
[23:14] <kirkland> cjwatson: it works, just trying to clean up one (possibly messy) aspect of the build
[23:14] <slangasek> kirkland: you're, uh... not really editing configure directly, are you? :)
[23:15] <kirkland> slangasek: this is debian/patches/evdev_keycode_map.patch
[23:15] <kirkland> slangasek: what do you suggest?
[23:16] <slangasek> kirkland: editing configure.{in,ac} and/or acinclude.m4, then regenerating configure
[23:16] <slangasek> editing configure directly tends to lead to confusing errors down the line
[23:16] <kirkland> slangasek: none of those exist
[23:16] <cjwatson> just be careful to look at the resulting diff to make sure there isn't a vast amount of junk due to configure last having been generated with a prehistoric autoconf
[23:17] <cjwatson> ... oh

[23:17] <kirkland> slangasek: apt-get source kvm
[23:17] <cjwatson> you do sometimes get configure with no configure.ac, due to an INSANE UPSTREAM
[23:17] <slangasek> looking :)
[23:18] <kirkland> cjwatson: slangasek: aliguori is upstream for qemu, been helping me with this in #ubuntu-virt
[23:18] <cjwatson> upstream isn't Fabrice any more?
[23:19] <kirkland> cjwatson: him too :-)
[23:19]  * slangasek scratches his head.  Tony is upstream for qemu?
[23:20] <slangasek> right, so qemu/configure is a hand-written script
[23:20] <slangasek> only 1572 lines long, though, so I guess that's ok ;P
[23:20] <kirkland> slangasek: my reasoning was that if you have SDL, then you have X11
[23:20] <kirkland> slangasek: so I just chunked it on the front of there
[23:20] <slangasek> kirkland: I don't object to the reasoning; it might not fly with upstream, but it works fine for us :)
[23:21] <kirkland> cjwatson: any objections from you?
[23:21] <kirkland> that was my only reservation ....
[23:21] <cjwatson> not at all, just that it's unconventional for "configure" not to be autoconf-generated, that's all
[23:21] <kirkland> i'm going to post a debdiff and look for a sponsor
[23:21] <cjwatson> but I can't see a libX11 dependency being a problem here
[23:21] <kirkland> cjwatson: right libsdl depends on libx11
[23:22] <kirkland> (fuzz up those names correctly ^)
[23:22] <cjwatson> libsdl1.2debian doesn't seem to unconditionally depend on libx11-6
[23:22] <kirkland> cjwatson: need an explicit build dep, then?
[23:23] <cjwatson> the primary alternative seems to depend on libdirectfb
[23:23] <cjwatson> kirkland: you should always use an explicit build-dependency when using something directly, rather than relying on transitive build-deps
[23:23] <bryce> kirkland: no that's probably the right approach.  All the examples I could point to have the X11 libs as prereqs
[23:23] <kirkland> bryce: thx
[23:23] <cjwatson> kirkland: dpkg-shlibdeps should find the runtime dependency for itself, though
[23:24] <cjwatson> the test for "do I need to build-depend on this even though one of my other build-deps depends on it" is "would I still need to build-depend on it if space aliens replaced that other build-dep with libhello?"
[23:24] <kirkland> cjwatson: shall I add libx11-dev to kvm's control file as a build-depends?
[23:24] <cjwatson> yes
[23:25] <kirkland> kewl
[23:25] <bryce> :-)
[23:26] <bryce> cjwatson: btw all the bugs mentioned at this morning's meeting have been reviewed and resolved
[23:26]  * NCommander flicks on the StevenK 
[23:26] <NCommander> ^light
[23:27] <bryce> cjwatson: also closed a couple others, all of which should be fine in current Intrepid.  there's just one intrepid targeted X bug - that we don't have -fglrx yet.
[23:27] <cjwatson> thanks; I've been noticing lots of bugs from the meeting in the dist-upgrade I'm doing at the moment
[23:27] <cjwatson> asac cleared out a bunch too
[23:28] <cjwatson> bryce: do you think the acpi-support upload closed the hotkey bug? (I haven't had a chance to look yet, sorry, browser closed in preparation for reboot)
[23:29] <bryce> I don't think so.  We didn't get mdz's test but several others tested it and did not find it fixed their issue
[23:29] <bryce> but all the changes included in it fixed specific bugs in debian so I think they're good.  At least, no signs of regressions
[23:30] <kirkland> cjwatson: patch attached to https://bugs.launchpad.net/ubuntu/+source/kvm/+bug/258389
[23:30] <kirkland> cjwatson: zul offered to sponsor later tonight
[23:30] <kirkland> cjwatson: but it's there if you want it ;-)
[23:31] <cjwatson> oh, I'm not in *that* much of a rush, have to go out in a few minutes to pick up a friend from the station anyway
[23:31] <kirkland> cjwatson: np ;-)  should be waiting for you in an update tomorrow
[23:32] <cjwatson> kirkland: beer[kirkland] += 1 if it works
[23:32] <james_w> Riddell: because I didn't and still don't have real upload rights anywhere, so I very rarely sign packages
[23:33] <kirkland> cjwatson: i just noticed your comments about virt*[s|z]*
[23:33] <james_w> Riddell: I don't think it should stay that way, but I haven't found a good way to suit both users that way
[23:33] <cjwatson> Riddell: oh yes, I meant to answer that; FWIW I have debuild configured not to sign anything either so I don't notice the difference :-) I prefer the model commit, build, test, sign
[23:33] <cjwatson> but it's easy to configure debuild either way, of course
[23:36] <aliguori> slangasek, fabrice doesn't really work on qemu anymore.  he still has commit access but he's doesn't want to be maintainer anymore
[23:37] <slangasek> ah, well then :)
[23:53]  * pochu waves good night