[04:41] <Sarvatt> was madwifi bundled up in anything in jaunty (like restricted extras?) i've noticed alot of people having problems with wifi after upgrading to karmic because they had things like madwifi installed which were blacklisting the kernel modules but theres no transitionary package to remove the blacklists
[04:42] <Sarvatt> same deal with the old broadcom packages not removing the blacklists right
[04:56] <Hobbsee> wasn't in restricted extras, but may have been in the restricted kernel packages
[05:23] <spotter> it appears latest poppler has broken pdftex/pdflatex
[05:23] <spotter> trying to test w/ older version
[05:24] <spotter> yea
[05:24] <spotter> downgraded
[05:24] <spotter> works
[05:28] <spotter> bug filed
[08:43] <pitti> Good morning
[08:44] <mdke> morning pitti
[08:44] <Hobbsee> hey pitti!
[08:45]  * pitti hugs Hobbsee and mdke, how are you?
[08:45] <Hobbsee> :D
[08:45] <Hobbsee> pretty good - first week of uni again here
[08:46]  * Hobbsee heads off to find some food before the next lecture
[08:50] <mdke> pitti: well thanks, hope you are too
[10:15] <mdz> cjwatson, should we unseed acpid? it's still depended upon by acpi-support, but once that's gone, I think we want it to pass out of main
[10:26] <directhex> when's the next alpha due?
[10:26] <cjwatson> slangasek: ^- acpid is your call I think; I'm happy to remove the explicit seed
[10:27] <liw> directhex, https://wiki.ubuntu.com/KarmicReleaseSchedule
[10:27] <cjwatson> the installer explicitly installs acpi, acpid, acpi-support-base if it can - I assume I should remove that?
[10:27] <cjwatson> (that's from Debian)
[10:27] <directhex> liw, alpha 4 soon, then.
[10:28] <mdz> cjwatson, I think so, yes
[10:29] <cjwatson> removed in my working tree
[10:32] <mdz> pitti, what would you think about making the apport fields in the bug description into a table, lining up the columns so they were easier to scan visually?
[10:34] <slangasek> cjwatson: acpid shouldn't be seeded explicitly, right
[10:35] <slangasek> it's only wanted as an acpi-support dep
[10:38] <StevenK> But acpi-support is only a Recommend
[10:40] <slangasek> StevenK: you're reading it upside-down
[10:43] <doko> seb128: looks like some gtk/gnome -dev package did drop the dependency on libgtk2.0-dev?
[10:43] <seb128> doko, where?
[10:44] <doko> seb128: I just see openjdk-6 failing to build because gtk isn't available anymore. did work for the last upload
[10:44] <seb128> is openjdk using gtk directly?
[10:44] <seb128> in which case it should depends on it
[10:45] <seb128> or rather build-depends
[10:49] <seb128> doko, the configure check for gtk you should list it in the build-depends and not rely on other packages to pull it there
[10:49] <cjwatson> mdz: unseeded
[10:50] <mdz> cjwatson, thanks
[10:53] <ogra> seb128, any idea why my gconfd is eating about 25% CPU constantly ?
[10:53] <ogra> since yesterday already
[10:54] <seb128> ogra, try running compiz --replace and ctrl-C directly
[10:54] <seb128> there is some weird wm things going on sometime that workaround it
[10:55] <ogra> well, nw my compiz is gone and doesnt come back
[10:55] <ogra> *now
[10:55] <ogra> but gconfd is silent again
[10:55] <seb128> hum
[10:55] <seb128> ok so that was it
[10:55] <seb128> restart compiz ;-)
[10:55] <ogra> it doesnt want to :)
[10:56] <seb128> what does it say?
[10:56] <ogra> at least not through the UI
[10:56] <ogra> works in terminal, but the fan starts spinning again
[10:56] <ogra> yup, and gconfd is bak at the top of my processlist
[10:56] <ogra> *back
[10:57] <ogra> nothing special in the terminal output
[11:32] <liw> hmm... it's as if launchpad has some javascript now that affects pageup/pagedown keys in the browser
[11:42] <ogra> liw, i think its related to the "subscribers" list
[11:43] <ogra> but its massively annoying
[11:43] <liw> yes, it is
[12:21] <mdz> jdstrand: I experienced the same symptoms described in bug 399446 and noticed you marked it invalid
[12:21] <mdz> jdstrand: maybe an error on the part of an automated tool?  the bug report looks good to me, complete with debug symbols
[12:23] <jdstrand> mdz: hmm.. looking
[12:24] <jdstrand> mdz: yeah, best I can tell it was a mistake
[12:25] <jdstrand> mdz: I updated the bug to Confirmed
[12:26] <mdz> jdstrand: thanks
[12:26] <mdz> jdstrand: was that a script?
[12:27] <jdstrand> mdz: a script generated the text, but it was a human that call the script on that bug. I'll need to find him and thrash him :)
[12:28] <mdz> jdstrand: :-)
[12:32] <zul> james_w: ping can you add samba to your distributed development thing?
[12:35] <james_w> zul: done
[12:35] <zul> thanks
[12:35] <james_w> may take a little while to import that one
[12:36] <zul> k
[12:50] <mdz> pitti, I noticed that apport bugpatterns don't seem to use re.MULTILINE. don't you think they should?
[13:07] <pitti> mdz: I guess we just didn't need it so far, but I don't mind enabling it
[13:08] <ogasawara> mdz: bug 390256
[13:13] <Riddell> lool: https://wiki.kubuntu.org/MainInclusionReportGpsd
[13:15] <sebner> pitti: about this usb bug, Should I just upgrade gvfs and devicekit again and run the 2 commands or do I have to go through the whole list of commands posted the last days?
[13:52] <pitti> sebner: just the two last ones should be enough
[13:52] <pitti> sebner: also, you can keep the current versions, you just need to move 95-devkit-disks.rules to the side
[13:54] <sebner> pitti: can't find 95-devkit-disks.rules. In what package is that? At least upgrade devicekit?!
[13:54] <pitti> sebner: /lib/udev/rules.d/95-devkit-disks.rules
[13:54] <pitti> sebner: it's in devicekit-disks
[13:54] <pitti> sebner: if you uninstalled that, you won't have it of course
[13:55] <sebner> pitti: it's 98 and not 95 though
[13:55] <pitti> sebner: no, 95
[13:55] <pitti> sebner: what file are you looking at?
[13:56] <evand> Does anyone know what sets XDG_CONFIG_HOME, or how to get the xdg-user-dirs information for a different user?
[13:56] <sebner> pitti: http://paste.ubuntu.com/248637/
[14:12] <pitti> sebner: 98-devkit is totally obsolete, devicekit isn't needed/installed any more
[14:12] <sebner> pitti: ah you are right, sry
[14:18] <sebner> pitti: hmm I would run the commands but my harddrive isn't recognised *cough*
[14:19] <pitti> sebner: just talked to upstream, he'll do a newer version today
[14:19] <pitti> it's worth testing that
[14:20] <sebner> pitti: sounds nice, btw .. when I plug my USB harddrive in -> http://img199.imageshack.us/i/90367185.png/
[14:21] <pitti> sebner: mmm, haven't seen that' is that with current gvfs/devkit, or with the downgrade?
[14:22] <sebner> pitti: gvfs is downgraded, devkit is current. dmesg still shows me the -71 errors though
[14:22] <sebner> I gues after installing libatasmart*
[14:24] <pitti> sebner: right, as I said you need to move aside 95-devkit-disks.rules
[14:24] <sebner> pitti: I did
[14:25] <sebner> pitti: I hope naming it 95-devkit-disks.rules.backup is enough?
[14:25] <pitti> should be
[14:26] <sebner> well, then this is the result ^^. anyways, waiting for new upstream version is always good :)
[14:27] <Laney> damn
[14:27] <Laney> CDBS now FTBFS due to a test failur
[14:27] <Laney> e
[14:27] <Laney> and I need the new release for some syncs
[14:37] <mdz> pitti, I've pushed to ubuntu/apport some patches to redirect bugs from the kernel to grub and initramfs-tools when the failure was in those tools
[14:37] <mdz> pitti, could you have a look and review it?
[14:52] <Laney> whatever it is broke between 2009-07-23 (last successful build) and now
[14:56] <seb128> Laney, what error do you get?
[14:56] <Laney> seb128: one of the tests failed
[14:57] <Laney> bug 409863
[14:57] <seb128> --verbose?
[15:00] <lool> \
[15:00] <lool> \
[15:01] <lool> \
[15:01] <lool> \\
[15:01] <lool> \
[15:01] <lool> 
[15:01] <lool> \
[15:01] <lool> \
[15:01] <lool> \
[15:01] <lool> \
[15:01] <lool> \
[15:01] <lool> \
[15:01] <lool> \\[6~\\\
[15:01] <lool> [6~\
[15:01] <lool> \
[15:01] <lool> \
[15:01] <lool> Crap sorry folks
[15:01] <Laney> modern art?
[15:01] <lool> This is what happens when you carry your laptop with a single hand with the keyboard hitting your belly
[15:02] <jussi01> heh
[15:03] <lool> Riddell: Ah I see it the gpsd MIR was assigned to asac just before lunch  :-)
[15:23] <highvoltage> lool: nice belly art.
[15:31] <mdz> ogasawara, I added an apport patch for the update-initramfs failures as well
[15:31] <mdz> ogasawara, are you using bughelper? clue files might help to clear out the old ones
[15:31] <Gh0sty> anyone here knows if gnome-keyring in the new version will have pam support?
[15:32] <Gh0sty> just reading up on some stuff that bothers me for quite a while: if you use fingerprint reader on your laptop you still need to login with a password to gnome-keyring :/
[15:34]  * mdz wonders if anyone has looked at unifying bughelper clue files with apport bugpatterns
[15:34] <liw> fingerprints are good for identification, but not authentication; using them for authentication encourages people to cut off your fingers
[15:36] <pitti> Gh0sty: right, because your fingerprint usually doesn't have your password engraved, and the keyring is encrypted with your password as a key
[15:37] <ogasawara> mdz: yup, I've used bughelper in the past so I'll use it to help clean up the existing bugs.
[15:37] <mdz> ogasawara, it must take a long time for bughelper to download all the kernel bug data!
[15:37] <cjwatson> Gh0sty: somebody demonstrated quite convincingly recently why using fingerprints as passwords would be a spectacularly bad plan
[15:38] <cjwatson> Gh0sty: they lifted the fingerprints of the German Interior Minister off a glass he'd handled
[15:38] <cjwatson> Gh0sty: so we regard a fingerprint as more analogous to entering a username
[15:39] <Gh0sty> pff
[15:39] <mdz> unique-ish, but not secret
[15:40] <Gh0sty> still its not like i work for the secret service but it still would be fun to auth with fingerprint :p
[15:40] <pitti> no, every computer and keyboard has them spread all over the place
[15:40] <pitti> Gh0sty: it works, libpam-thinkfinger does that
[15:40] <Gh0sty> yes but how can it interact with gnome-keyring?
[15:40] <pitti> it can't
[15:41] <pitti> for decryption you need a secret key
[15:41] <Gh0sty> as far as i saw there is talks about libpam_keyring.so in the past
[15:41] <pitti> so you'd need to keep your keyring unencrypted
[15:41] <Gh0sty> but even though the lib is installed i don't find the file
[15:41] <Gh0sty> lol thats security wise good? nope ... :p
[15:42] <Gh0sty> why can't it just store the session like "you're logged in ... ok you have also access to your keyring"
[15:42] <mdz> james_w, have you talked with mvo about turning the ubuntu apt branch into a source package branch?
[15:42] <Gh0sty> i see it's similar with people who do auto login, they just save their keyring unencrypted :/
[15:43] <james_w> mdz: I have not
[15:43] <mdz> james_w, see any reason not to just do it?
[15:43] <james_w> I don't think so
[15:44] <james_w> I would just want to ensure that an appropriate revision is tagged with the latest version
[15:44] <Gh0sty> and anyway as a guy also said: if it's not for fingerprints ... gnome-keyring should still use pam, you can have auth through usb stick or cardreaders or otp
[15:45] <Gh0sty> so this would mean that those auth methods do not work for gnome-keyring either :)
[15:46] <cjwatson> james_w: likewise ubiquity, BTW
[15:46] <cjwatson> james_w: is that just a matter of setting the official branch, or do we need to also re-push the current branch to lp:~ubuntu-installer/ubuntu/karmic/ubiquity/trunk ?
[15:47] <james_w> we need a couple of code changes to support that
[15:47] <james_w> I'll bump that task up in my list
[15:49] <cjwatson> so presumably those same changes would apply to apt too
[15:50] <mdz> james_w, it looks like he has not-yet-uploaded changes in the branch at the moment
[15:52] <cjwatson> mdz: (from a meatspace conversation with james_w) so either apt gets pushed to ~ubuntu-branches and that's set as the official branch, in which case mvo loses the ability to commit to it until jml lands a codehosting change; or else the official branch link is set to mvo's current ~ubuntu-core-dev branch, which requires an importer tweak to avoid continuing to update the spurious ~ubuntu-branches branch
[15:53] <cjwatson> the importer tweak is pending resolution of an RT ticket to cherry-pick a launchpadlib fix onto jubany
[15:53]  * jml is working on said change atm.
[15:53] <mdz> cjwatson, so in short, we should leave it alone for the moment?
[15:54] <james_w> yeah, but should be a short while until we can change things around
[15:54] <cjwatson> I've been waiting for one of those two things to get fixed before doing anything with my many bzr package branches, put it that way :-)
[15:54] <cjwatson> setting the official branch link to something else is apparently mostly harmless, it just leaves some junk lying around which might be confusing
[15:55] <cjwatson> so perhaps we should start doing that for selected branches, to get a jump on any issues that might arise?
[15:55] <cjwatson> since the junk can be cleaned up later
[15:55] <cjwatson> of course eventually we want all source package branches to be owned by ~ubuntu-branches
[15:55] <cjwatson> because that means that magic permissions resolution can apply, once it works
[15:56] <jml> umm
[15:56]  * mdz reboots to check out linux-crashdump
[15:56] <jml> it's only for official branches
[15:57] <jml> wgrant mentioned in a bug report that it'd be nice to turn it on somehow for your own branches
[15:57] <jml> maybe it should be the celebrity -- seems kind of hacky though
[16:07] <cody-somerville> pitti, Does postgresql8.4 not bind to the same port as postgresql8.3?
[16:08] <ogra> cjwatson, i have another merge for debian-cd on https://code.launchpad.net/~ogra/debian-cd/ubuntu ... lp:~ogra/debian-cd/ubuntu could you pull that in ?
[16:08] <pitti> cody-somerville: it does (5432)
[16:09] <pitti> cody-somerville: if you have several versions installed in parallel, you can just have one cluster on 5432, of course
[16:10] <cody-somerville> pitti, update-manager installed 8.4 and removed 8.3
[16:10] <directhex> kees, would you object to me requestsyncing a new mono version from sid which does not include your patch, then?
[16:11] <directhex> if i sync now, we should be able to shrink the next alpha a little
[16:11] <cody-somerville> pitti, my connection just dropped. Did you get that update-manager installed 8.4 and removed 8.3?
[16:12] <pitti> cody-somerville: I got it (sorry, in discussion here)
[16:12] <pitti> cody-somerville: it really should keep 8.3, though
[16:12] <pitti> I thought that was already fixed in update-manager
[16:12] <pitti> cody-somerville: can you please report this as a major bug against update-manager? should be easy to fix
[16:13] <cody-somerville> pitti, even if update-manager doesn't remove it, sudo apt-get autoremove will
[16:14] <cody-somerville> pitti, and theres still the fact that I have just postgresql8.4 installed and it starts but I can't connect to it via the standard port nor the unix domain socket.
[16:14] <kees> directhex: yeah, please do, I was about to upload a revsion, but a merge would be better.
[16:16] <StevenK> cody-somerville: -p 5433 ?
[16:16] <directhex> kees, well, excluding your patch, we're in sync town. 2.4.2-5ubuntu1 was rendered obsolete by -6, so...
[16:16]  * directhex fires up a console
[16:16] <mdz> cjwatson, I didn't spot any code where depmod would exit nonzero without an error message
[16:16] <pitti> cody-somerville: what does pg_lsclusters say?
[16:17] <mdz> my best guess is that it didn't manage to exec depmod at all
[16:17] <kees> directhex: was ogra's reversion a reversion of an ubuntu change?
[16:17] <pitti> cody-somerville: if you just have one cluster, it should pick the port of that one, even if it's not the default port
[16:17]  * ogra looks up 
[16:17] <mdz> the kernel postinst doesn't attempt to catch that error
[16:17] <ogra> what did i reverse ?
[16:17] <cody-somerville> pitti, It appears I have a cluster for 8.3 and one for 8.4 and that 8.4 is indeed running on 5433 like StevenK suggested.
[16:18] <kees> ogra: "revert dropping of --with-tls=pthread on armel to fix FTBFS
[16:18] <kees> " in mono
[16:18] <directhex> kees, ogra's revision was adding back some hacks. -5 assumed upstream's build system was sane, -6 did the same thing as ogra's patch (although possibly not in the same way, i'd need to check)
[16:18] <ogra> oh, directhex said he would push that to debian or get it fixed upstream
[16:18] <kees> directhex: ah-ha!  perfect then.  rock on.  :)
[16:18] <mdz> IIRC dpkg enforces a sane PATH, so that wouldn't be it
[16:18] <directhex> kees, it's built on arm in debian, if that counts!
[16:18] <kees> sounds good to me.  :)
[16:18] <ogra> not really
[16:18] <ogra> we use gcc 4.4 they dont ...
[16:19] <ogra> and a different toolchain, but just push it up, i need to test it anyway, if there are arm issues i'll care
[16:20] <directhex> mono (2.4+dfsg-6) unstable; urgency=low
[16:20] <directhex>   * debian/rules:
[16:20] <directhex>     + Force pthread for armel as __thread FTBFS.
[16:21] <directhex> i think 2.4.2.3 may well be what we release with. unless upstream push out another important bugfix in the 2.4 branch
[16:22] <directhex> there we go, #409920 filed. i'm feeling pretty good about karmic
[16:22] <cody-somerville> pitti, here is a pastebin out the output: http://pastebin.ubuntu.com/248703/
[16:24] <cody-somerville> pitti, I assume I have to upgrade the cluster but that doesn't seem possible since the original cluster isn't running anymore with 8.3 removed.
[16:24] <pitti> cody-somerville: right, you need to reinstall postgresql-8.3
[16:25] <cody-somerville> pitti, Should I file a bug against postgresql-8.4? - this doesn't seem like a very good transition experience
[16:25] <mdz> pitti, do you see any issue with one apport package hook invoking another one's add_info function?
[16:26] <pitti> mdz: should work fine, but I think it's cleaner for the hook to call add_hooks_info(otherpackage)
[16:26] <mdz> pitti, oh, I didn't know about that
[16:26] <pitti> mdz: now, you can't specify "otherpackage" yet, I've been meaning to add that
[16:26] <pitti> mdz: in the meantime you can temporarily change report['Package']
[16:28] <cody-somerville> pitti, thanks. worked like a charm.
[16:28] <pitti> seb128 asked me about this as well, I'll add it right now
[16:28] <pitti> cody-somerville: still an awkward upgrade, needs fixing in u-m
[16:30] <pitti> seb128, mdz: committed that to trunk now, FYI
[16:30] <seb128> pitti, thanks!
[16:30] <mdz> pitti, ok, I'll stop working on it now ;-)
[16:30] <pitti> mdz: you can still change report['Package'], that'll work
[16:31] <mdz> pitti, in this case I can just use hookutils.attach_alsa(), but I had been wondering if this was possible
[16:32] <MacSlow> anybody with an idea how to pass any of the multimedia-key into the system runnung under VirtualBox?
[16:37] <mdz> seb128,
[16:37] <mdz>   [ Matt Zimmerman ]
[16:37] <mdz>   * apt-pkg/deb/dpkgpm.cc:
[16:37] <mdz>     - Suppress apport reports on dpkg short reads (these I/O errors are not
[16:37] <mdz>       generally indicative of a bug in the packaging)
[16:37] <seb128> mdz, excellent, thanks!
[16:39] <liw> MacSlow, I'm not convinced it's possible, at all; multimedia keys tend to be different on each kind of hardware
[16:40] <soren> james_w: Have you thought about adding a few lines of code to apt-cache to fake a vcs-bzr header if it's not explicitly set?
[16:40] <sladen> (since the Microsoft extended keyboard, the mediamedia keys have had defacto standard keycodes, and the kernel now also uses these internall)
[16:40] <MacSlow> liw, I'll guess pykey/crikey (using xtst & co) is what I'm looking for... thanks to soeren for the hint
[16:41] <soren> liw: They (at least used to) get mapped to a specific keysym, so they're easily catchable.
[16:41] <liw> I seem to be wrong, then; good
[16:42] <sladen> however, as to how to ensure they get passed through to virtualbox, no idea
[16:43] <sladen> probably kill -9 whatever bit of magic (gnome-settings-daemon?) is catching them
[16:46] <ogra> kees, "mmap: No such device or address" .... i still see mmap issues with qemu even with setting cap_sys_rawio
[16:50] <kees> ogra: oh, hrm.  let me check something...
[16:52] <pitti> mdz: hm, no new revisions in lp:~ubuntu-core-dev/ubuntu/karmic/apport/ubuntu/, did you push?
[16:52] <kees> ogra: well, to get that working asap, use the method that wine and dosemu currently use (but set it to 32k instead of 0).  I need to test the fscaps stuff more, it seems.
[16:54] <ogra> kees, hmm k
[16:54] <mdz> pitti, Using saved push location: bzr+ssh://bazaar.launchpad.net/~ubuntu-branches/ubuntu/karmic/apport/karmic/
[16:54] <mdz> pitti, is that the wrong place?
[16:55] <mdz> I did bzr branch lp:ubuntu/apport
[16:55] <mdz> jml, ^^
[16:55] <pitti> mdz: Vcs-Bzr: should point to ~ubuntu-core-dev
[16:55] <pitti> it seems that we got a package import into bzr although an official branch already exists?
[16:55] <pitti> so it seems we should abandon ~ubuntu-core-dev/ubuntu/karmic/apport/ubuntu/ then
[16:56] <mdz> james_w, help?
[16:56]  * pitti checks out lp:ubuntu/apport
[16:57] <pitti> mdz: ah, I wouldn't like to use that one; it's just a dsc import, and lost all the individual history, and you can't merge from trunk
[16:58] <pitti> I don't think we should use the auto-imported package branches for anything that has a Vcs-Bzr: right now
[16:59] <pitti> (this question keeps coming up..)
[17:05] <cjwatson> mdz: I couldn't figure it out either, that's why I punted to the submitter
[17:05] <cjwatson> mdz: yes, dpkg enforces a sane PATH
[17:05] <cjwatson> mdz: well, although it doesn't exclude *extra* weird shit from being on PATH
[17:06] <cjwatson> ogra: merged, thanks
[17:07] <james_w> mdz: I have no idea why your revisions aren't showing up in that branch
[17:08] <ogra> cjwatson, thanks
[17:08] <linuxdude> ubuntu alpha 3
[17:08] <linuxdude> sweet
[17:08] <linuxdude> is it any good?
[17:08] <mdz> james_w, it looks like I pushed to the wrong branch (the ~ubuntu-branches one)
[17:08] <james_w> ah
[17:08] <linuxdude> gotta go
[17:08] <mdz> james_w, I assumed that pitti's ubuntu branch had been imported as the source package branch
[17:09] <cjwatson> mdz: you could probably only push there because you're a Launchpad admin
[17:10] <mdz> james_w, can you help me rip the patches out of there and put them into the right branch?
[17:10] <james_w> yeah, I think so
[17:10] <spotter> seb128, I think you misunderstand my latex bug
[17:10] <spotter> the usage.pdf works fine (generated by gnuplot as eps converted to pdf)
[17:10] <spotter> it's pdflatex can't include it in the document I provided
[17:10] <spotter> wont build
[17:11] <pitti> james_w: is it possible to somehow make lp:ubuntu/foo point to Vcs-Bzr: if it exists?
[17:11] <seb128> spotter, oh, that's a pdflatex bug then
[17:12] <spotter> seb128, except it works w/ old poppler
[17:12] <james_w> pitti: technically, yes.
[17:12] <spotter> I've downgraded poppler and I can build
[17:12] <spotter> it would appear that new poppler lib isn't the same abi
[17:12] <pitti> james_w: but it wouldn't be a good idea?
[17:12] <james_w> pitti: (if it's on LP and exists etc.)
[17:12] <seb128> spotter, right, which doesn't mean that poppler changed and pdflatex need to be updated to use poppler correctly
[17:12] <seb128> though soname should have changed if they broke abi
[17:12] <seb128> will check
[17:12] <james_w> not currently (c.f. discussion a couple of hours ago), but perhaps in a couple of weeks
[17:13] <spotter> right.
[17:13] <spotter> that's my only point
[17:13] <pitti> james_w: ok, thanks
[17:13] <seb128> spotter, sorry the bug was not really clear, it makes easier to give the command you run and an example is such cases
[17:13] <spotter> I thought I did
[17:13] <spotter> included the 2 files and said run "pdflatex test.tex"
[17:14] <spotter> sorry if i wasnt' clear
[17:14] <james_w> pitti: we could create a list of eligible packages then and review it when it is possible
[17:14] <spotter> a bit rushed due to paper deadline
[17:14] <seb128> spotter, you did in the update but I misunderstood the bug from the initial description
[17:14] <seb128> spotter, and I just read the update quickly
[17:14] <seb128> spotter, will look at that now thanks
[17:14] <james_w> jcastro: gnonlin synced
[17:15] <jcastro> \o/
[17:15] <seb128> jcastro, so you run from people to people asking to sync different things? ;-)
[17:15] <james_w> jcastro: it's just a .3 update, is that what we need?
[17:15] <seb128> jcastro, new pitivi synced
[17:15] <jcastro> no I told him I would talk to you
[17:16] <jcastro> but he's james_w and he's awesome
[17:16] <jcastro> james_w, I believe so yes
[17:16] <seb128> jcastro, and I'm seb128 and I suck right? ;-)
[17:16] <jcastro> seb128, I'm sure next time you will win.
[17:17] <seb128> right ;-)
[17:19] <mdz> robbiew, kernel crash dumps work great, nice work on mvo's part
[17:20] <robbiew> mdz: I wouldn't expect anything less from him ;)....I'll pass it along
[17:21]  * jml back, catching up
[17:29] <lool> kees: Hey I'm happy to promote python-oauth unless you'd like to do a security review; it's relatively small and trivial python lib but it's parsing data from the net https://bugs.launchpad.net/bugs/408878
[17:42] <james_w> lool, kees: python-oauth implement OAuth 1.0, not 1.0a, so is vulnerable to what can be a very serious session fixation attack
[17:42] <james_w> it's not really a "full of buffer overflows" problem, but something to consider
[17:43] <kees> james_w: sounds like a reason to reject it to me.
[17:44] <kees> lool: what needs it?
[17:44] <james_w> kees: Ubuntu One, the new python-launchpadlib
[17:44] <james_w> (the old one embeds a copy :-/)
[17:45] <bdrung> bryce: did the kms for karmic work also on r6xx/7xx?
[17:45] <bryce> bdrung, haven't tested it
[17:45] <kees> james_w: so, ubuntu one is vulnerable to a serious session fixation attack currently?
[17:45] <james_w> kees: depends how they use it
[17:45] <bryce> kees, what was your graphics card?  lspci | grep VGA
[17:46] <kees> bryce: 01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]
[17:46] <james_w> I haven't looked in to their use of it
[17:46] <bdrung> bryce: ok, then i will try it today (if i have time for it)
[17:46] <james_w> I believe Launchpad is
[17:46] <james_w> it's more of a server-side fix, but clients need to roll out the change
[17:47] <james_w> in addition, LP doesn't really do "full" OAuth, so the impact is mitigated I think
[17:54] <hoban> I'm having trouble finding an existing bug report about this and maybe it's because it's by design. Maybe someone can shed some light? With any other Linux distro I've used, when you enter the GRUB command-line interface at boot, setting the root device (e.g. root=(hd0,0)), kernel (e.g. kernel /vmlinuz-2.6.22), or initrd (e.g. initrd /initrd-2.6.22) will cause the command line to indicate whether or not the action was successful. Ubuntu's
[17:54] <hoban>  grub does not. It just prints a blank line. This can make it hard to manually boot the system using GRUB if the menu.lst is incorrect or missing.
[17:55] <lool> james_w, kees: Wow ok thanks for feedback; I'm happy I pinged on that security review!
[17:56] <lool> kees: Do you want a bug or something for the python-oauth issue?
[17:57] <lool> kees: I just Incompleted the MIR for now
[17:57] <TheMuso> lool: Thanks for making those fixes, I would have been happy to chase them up myself. I'll keep an ee on the Debian package to get them into Ubuntu.
[17:58] <kees> lool: feel free to subscribe me to it
[18:00] <cjwatson> hoban: I think that's accidental, perhaps a consequence of having 'quiet' in the menu?
[18:00] <cjwatson> hoban: unless you mean in karmic in which case it could be a difference between grub and grub2 ...
[18:01] <hoban> cjwatson, I'm actually referring to 8.04 LTS
[18:01] <cjwatson> ok, so grub 1
[18:01] <hoban> cjwatson, I'll take a look to see if it's related to the quiet option and return shortly
[18:02] <hoban> cjwatson, I removed the quiet option and there is no difference in behaviour
[18:03] <hoban> recall also that I'm referring to the grub command-line, so configuration in /boot/grub/menu.lst isn't being used at that time anyway. Perhaps there is a difference in the way grub is being compiled?
[18:08] <cjwatson> hoban: ok, every distro has massive patches to grub legacy so that's entirely possible; afraid I can't hunt through it right now
[18:09] <hoban> cjwatson, not a problem. Is this something I should create a bug report for or just ignore until grub2 is in use? (I'm fine with either)
[18:10] <cjwatson> could be a consequence of the patch to quieten boot in general
[18:11] <cjwatson> go ahead and file a bug of course, although I should warn that we aren't putting a whole lot of effort into grub any more
[18:11] <cjwatson> but no harm in having it recorded
[18:13] <hoban> will do. Thank you cjwatson!
[18:14] <lool> hoban: If I recall correctly the default value for the quiet option might be one
[18:15] <cjwatson> I don't think there's actually any way to set it to zero
[18:15] <hoban> lool: which quiet option (grub's quiet option or the kernel quiet option) and where is that configurable?
[18:16] <lool> hoban: The grub quiet command is supposed to set a quiet flag in grub
[18:17] <lool> hoban: This is all added by a patch in the packaging
[18:17] <lool> But the deafult value of the flag is 1 anyway (IIRC)
[18:17] <hoban> lool: I see. thanks
[18:18] <lool> hoban: See debian/patches/quiet.diff in http://archive.ubuntu.com/ubuntu/pool/main/g/grub/grub_0.97-29ubuntu56.dsc
[18:18] <lool> +/* Whether to quiet boot messages or not. */
[18:18] <lool> +int quiet_boot = 1;
[18:19] <hoban> lool: I'll take a look at that, and if removing that diff changes the behaviour in the way I'm wanting, I'll include that information in the bug report
[20:43] <MisterN> i discovered sysfsutils today, and i think maybe ubuntu could itself use it for initialising sysfs variables in a standardised place. just a suggestion :)
[21:28] <stefanlsd> pitti: i made a new diff.gz for 0.6.5 of calibre. are you ok if i upload or do you have other plans for it?  bug #410046
[21:55] <goldins> Hello, where do I voice my opposition to multisearch being enabled by default on firefox 3.5?
[21:58] <dtchen> here (or) #ubuntu-mozillateam (or) preferrably, ubuntu-devel-discuss@lists
[21:58] <dtchen> i can't speel today, apparently
[22:00] <goldins> I hate it. I think it's really annoying and limits the awesomebar's coolest features. If there was a vote on default addons for firefox, I would vote for absolutely anything else
[22:01] <dtchen> i think that while your enthusiasm may be appreciated, documenting impartially (or as close to that as one may be) the use case regressions with detailed screenshots is likely a far more productive method of "protest"
[22:03] <goldins> I mean, I think if you're going to ship firefox with addons, the burden of proof is on you to prove those addons are great for everybody
[22:04] <goldins> it behaves a particular way, it behaves that way on all of my computers and every computer I use. My users are going to be confused when it behaves differently on their linux machines than their windows machines than the CentOS machines etc
[22:23] <eimann_> morning
[22:23] <eimann_> anyone here who knows why dvb/webcam modules are missing in 2.6.31-rc5 mainline kernels from ppa repository?
[22:24] <dtchen> which, specifically?
[22:25] <eimann_> the "official" one ;-) -- http://kernel.ubuntu.com/~kernel-ppa/mainline/
[22:25] <dtchen> no, which .ko?
[22:26] <eimann_> dvb-usb-umt-010.ko and uvcvideo.ko
[22:29] <dtchen> config skew. you could ask apw nicely if there's a more specific reason.
[22:32] <eimann_> ok, thx :)
[22:32] <eimann_> apw: Could you please explain if there is a reason for not including video/dvb modules in the 2.6.31-rcX Packages? ;-)