[00:00] <soren> cjwatson: around?
[00:01] <kees> mneptok: hah, yeah, but then you have to fix the stuff he ships you.  ;)
[00:01] <cjwatson> soren: sort of
[00:01] <soren> cjwatson: You forgot to commit or push to the eucalyptus packaging branch when you uploaded it.
[00:01]  * cjwatson blinks
[00:02] <cjwatson> turnabout is fair play, I suppose :)
[00:02]  * soren blushes at cjwatson's blinking
[00:02] <soren> :)
[00:02] <cjwatson> fixed
[00:02] <soren> ta
[00:02] <cjwatson> odd, normally I use a wrapper script which causes me to remember to do that, in this case I must have forgotten ...
[00:04] <soren> I'm still trying to get used to this setup.
[00:05] <soren> I still haven't quite worked out when to use dch (and which heuristic to use) and when to use debcommit.
[00:09] <cjwatson> I use DEBCHANGE_RELEASE_HEURISTIC=changelog, DEBCHANGE_MULTIMAINT_MERGE=yes, dch to add changelog entries (which I do any time I make a non-trivial change), debcommit to commit anything other than trivial changes
[00:09] <soren> DEBCHANGE_RELEASE_HEURISTIC=changelog makes dch put the "UNRELEASED" as the release, right?
[00:10] <soren> So when you're releasing, you just "dch --release", save, "debcommit --release"?
[00:10] <soren> Or is there a shortcut I'm not aware of?
[00:11] <slangasek> soren: that's the way
[00:11] <slangasek> (and DEBCHANGE_FORCE_SAVE_ON_RELEASE=no is nice, but that hasn't been merged to Ubuntu yet :()
[00:13] <soren> Cool, thanks.
[00:13]  * soren adds to his .bashrc
[00:14] <slangasek> soren: or .devscripts
[00:18] <soren> slangasek: Ah. Thanks.
[00:33] <cjwatson> yes, you want it in .devscripts, I don't think it works right in .bashrc
[00:34] <cjwatson> I have http://paste.ubuntu.com/260110/ as ~/bin/ubuntu-release
[00:34] <cjwatson> watch out for dch -r's slightly coarse time granularity - you have to wait a second :-/
[00:39]  * soren hasn't heard of debrelease before
[00:39] <cjwatson> it is for very, very lazy people like me
[00:41] <soren> cjwatson: Ah, I see what it does. That's convenient.
[00:43]  * soren wonders if there's more he can reasonably manage to do before FF kicks in.
[00:45] <cjwatson> I have a new grub2 building here, I do hope it works ...
[00:47]  * soren throws in the towel and wanders off to bed
[00:48] <soren> 11 months old babies don't care much when their parents go to bed. They'll happily wake up at 6 AM even though their father didn't stagger to bed until 2 AM. :)
[00:55] <cjwatson> I noticed that
[00:55] <cjwatson> GOOD MORNING DADDY ISN'T IT A LOVELY DAY
[00:55] <cjwatson> *grunt*
[02:40] <TheMuso> StevenK: That is a close one.
[02:44] <StevenK> TheMuso: Which? window-picker-applet? It's all bug fixes.
[02:44] <TheMuso> StevenK: ah ok
[02:48] <maco> https://bugs.launchpad.net/ubuntu/+source/jhbuild/+bug/419363 would require packaging and getting up on REVU and getting 2 advocates by tomorrow, huh?
[03:01] <chrisccoulson> maco - if you're talking about uploading to REVU and getting 2 advocates by tomorrow in order to meet the FF deadline, then it's too late ;)
[03:01] <maco> chrisccoulson: ok
[03:01] <maco> and FF covers everything or just main?
[03:02] <chrisccoulson> maco - it's everything. I haven't looked at whats changed in jhbuild though
[03:02] <maco> major version releases, it seems
[03:05] <chrisccoulson> maco - that would need to follow the process at https://wiki.ubuntu.com/FreezeExceptionProcess
[03:05] <maco> so i guess that means it freezes at the *start* of thursday, not the end of it
[03:06] <chrisccoulson> yeah, it gets all confusing due to timezones ;)
[03:06] <chrisccoulson> but the e-mail went out about 1hour ago
[03:09] <superm1> kees, what's up?
[03:37] <kees> superm1: I'd like to test some changes to fglrx-installer and nvidia, but I don't have ATI hardware that fglrx works on
[03:38] <kees> superm1: it's as simple as:  sudo apt-get install execstack; sudo execstack -c /usr/lib/dri/fglrx_dri.so /usr/lib/libGL.so.* /usr/bin/amdcccle  and then making sure X still loads, and ccc still works, etc
[03:40] <superm1> kees, has to be on karmic?
[03:42] <kees> superm1: better if it is -- jaunty i386 -desktop kernel won't break if the executable stack is executed.
[03:42] <superm1> kees, well i've got a jaunty box right here actually thats i386.  how do i undo this if this breaks?
[03:42] <kees> sudo execstack -s /usr/lib/dri/fglrx_dri.so /usr/lib/libGL.so.* /usr/bin/amdcccle
[03:43] <kees> if you're running jaunty i386 -desktop it won't break if it's broken.  i386 -server will break if it's broken, though.
[03:44] <kees> for jaunty it'd be better to test on amd64
[03:44] <superm1> i've only got i386 -desktop
[03:44] <superm1> so still a good test case?
[03:45] <kees> unfortunately not, the markings will have not affect there (since -desktop in jaunty lacks PAE and nx-emulation)
[03:45] <kees> I can test nvidia amd64, and nvidia i386, but I've got no ATI anywhere.
[03:45] <kees> (well, no fglrx-supported-ATI)
[03:46] <superm1> kees, i'd say throw something out on ubuntu-devel ML then and see if you can grab someone to help out
[03:46] <kees> yeah, it's probably more a bug-fix than a feature, so I probably don't need to rush it in tonight.
[03:56] <Amaranth> kees: nvidia actually works with that turned on now?
[03:57] <kees> Amaranth: dunno, haven't tested it yet.
[03:58] <kees> Amaranth: nvidia is actually worse than fglrx; they're compiling with such an old gcc that it doesn't include ELF header with the stack flags.  :P
[03:58] <Amaranth> kees: yay RHEL 2 support
[03:58] <kees> heh
[04:15] <kees> Amaranth: yup, seems to work fine with nvidia (at least on jaunty 180)
[04:18] <Amaranth> kees: One of their customers must have made it a requirement :)
[04:18] <Amaranth> yay
[04:19] <kees> Amaranth: now I wonder if it was just fixed in newer drivers, I don't have -173 -96 or -71 hardware...
[04:19] <Amaranth> kees: Pretty sure it didn't work a couple years ago
[04:20] <kees> well, I'll try to find some people with older nvidia hardware to test those.  /me prepares a ppa
[04:46] <StevenK> And now gnome-orca is broken
[04:51] <StevenK> TheMuso: Right, python-speechd is in universe, and gnome-orca is in main.
[04:53] <StevenK> TheMuso: This makes ubuntu-netbook-remix and ubuntu-desktop livefses unbuildable
[04:56] <TheMuso> StevenK: right I think pitti promoted speech-dispatcher but didn't promote python-speechd.
[04:57] <StevenK> Not according to LP, he didn't. The source for speech-dispatcher is still in universe.
[04:58] <StevenK> TheMuso: Is there an MIR bug for this?
[04:58] <TheMuso> StevenK: yes just a sec.
[04:59] <TheMuso> bug 419036
[04:59] <TheMuso> hrm maybe I misread the bug...
[05:00] <TheMuso> although it is marked fix committed
[05:00] <StevenK> Fix Commited means "MIR approved", Fix Released means "It's been promoted"
[05:01] <TheMuso> right
[05:01] <StevenK> Anyway, I'll promote it now
[05:01] <TheMuso> ok
[05:02] <TheMuso> StevenK: thanks I owe you one.
[05:02] <StevenK> TheMuso: Actually, there are a whole bunch of binary packages - do they all need promotion?
[05:02] <TheMuso> StevenK: No, you should only need to promote speech-dispatcher, python-speechd, libspeechd2, and libspeechd-ev.
[05:02] <TheMuso> libspeechd-dev even
[05:03] <StevenK> Bah. Just missed the publisher.
[05:03] <StevenK> Heh, no, I haven't.
[05:03] <TheMuso> haha
[05:05] <StevenK> TheMuso: Done.
[05:05] <TheMuso> StevenK: thanks again
[05:06] <StevenK> TheMuso: Should I demote gnome-speech while I'm at it?
[05:06] <ScottK> StevenK: If you have a few moments, there are a couple of backports sitting in Jaunty New that it'd be nice to get pushed through.
[05:07]  * StevenK grumbles at ScottK 
[05:07] <TheMuso> StevenK: may as well
[05:07] <ScottK> I can do kontrolpack, but quassel's my upload, so if you could take that one, I'd appreciate it.
[05:08] <StevenK> ScottK: If I'm going to do one, I may as well do them both
[05:08] <ScottK> StevenK: Thanks.
[05:14]  * StevenK fiddles the overrides of quassel-dbg
[05:17] <StevenK> ScottK: Accepted.
[05:17] <ScottK> StevenK: Thank you.
[05:18] <StevenK> ScottK: I should rescue protobuf from hardy-backports, too?
[05:18] <ScottK> Please.
[05:19]  * StevenK blinks
[05:20] <StevenK> libprotobuf3 is in main in jaunty, karmic and jaunty-backports, but universe in intrepid-backports?
[05:21] <ScottK> Doesn't really matter for backports.
[05:21] <wgrant> StevenK: It was in universe pre-Jaunty...
[05:21] <ScottK> They are all equally unsupported and Main can build on Universe in backports.
[05:28] <StevenK> ScottK: Crackports ignores the OGRE model? Ugh
[05:29] <ScottK> StevenK: It pretty much has to or you'd end up having to do backports only promotions to backports stuff with new depends and we don't have a mechanism for that.
[06:38] <dholbach> good morning
[06:46] <highvoltage> guten morgen dholbach!
[06:46] <dholbach> hey highvoltage!
[06:49] <highvoltage> dholbach: how are things?
[06:49] <dholbach> good good - I'm just waking up slowly :-)
[06:57] <highvoltage> dholbach: heh, same.
[07:06] <TheMuso> Does anyone plan on filing an MIR for liblqr, as it seems imagemagick has not been built for ages due to requiring liblqr-1-0-dev
[07:06] <TheMuso> which puts it in dep wait.
[07:07]  * TheMuso checks to see if imagemagick can be built without it.
[07:09] <pitti> Good morning
[07:09] <pitti> TheMuso, StevenK: no, I just approved speech-dispatcher; I still had some questions for it, and seeds need changing
[07:09] <TheMuso> Morning pitti.
[07:09] <TheMuso> pitti: right. The issues pointed out were addressed, and questions answered.
[07:09] <pitti> ah, read the further backlog
[07:10] <pitti> StevenK promoted, was the MIR bug closed then?
[07:10] <TheMuso> yes
[07:10] <pitti> and was gnome-speech demoted along?
[07:10] <TheMuso> yes
[07:10] <pitti> great
[07:10] <StevenK> I didn't demote gnome-speech, acutally
[07:11] <StevenK> Should I drop the lot to universe?
[07:11] <TheMuso> oh ok
[07:11] <TheMuso> Yes nothing should be depending on it.
[07:11] <TheMuso> in main at least
[07:12] <ttx> pitti: good morning
[07:12] <StevenK> Right, confirmed with checkrdepends.
[07:13] <pitti> hey ttx
[07:13] <StevenK> pitti, TheMuso: gnome-speech dumped to universe.
[07:13] <TheMuso> ok great.
[07:13] <pitti> \o/
[07:14] <TheMuso> ok seems imagemagick is doing fine without liblqr. Will upload assuming the build is successful, unless someone does plan to file an MIR for liblqr.
[07:14] <TheMuso> s/assuming/if/
[07:15] <ttx> pitti: do you know what was the outcome yesterday night for axis2c and rampart ? Would you consider preemptively promoting them as well to let Eucalyptus reach the CD ?
[07:16] <pitti> ttx: oh, sure; sorry that this got dropped, yesterday was too crazy
[07:17] <ttx> pitti: I can only imagine, it was already crazy for me :)
[07:19] <pitti> ttx: promoted
[07:19] <ttx> pitti: thanks !
[07:20] <pitti> kirkland: did you see this in component-mismatches:
[07:20] <pitti>  o kvm: kvm
[07:20] <pitti>    [Reverse-Depends: Ubuntu.Karmic virt-host seed]
[07:20]  * TheMuso is a little surprised at hearing his CPU fan spin up with the imagemagick build.
[07:21] <pitti> kirkland: seems this needs some seed fix?
[07:35]  * soren hugs pitti
[07:35] <soren> pitti: Thanks for the axis2c and rampart promotions.
[07:36] <pitti> yw :)
[07:38]  * soren is puzzled why apport decided to bombard him with crash reports just now
[07:39] <ttx> soren: you're past-FF, now you can concentrate on crash reports.
[07:40] <soren> ttx: heh :)
[07:40] <highvoltage> how consderate of apport
[07:40] <ttx> highvoltage: that's part of its AI adaptive features.
[07:41] <pitti> I pushed the crash nagging lever up two notches yesterday
[07:48] <soren> pitti: I just tried the Eucalyptus build again, and it ended up in depwait?
[07:48] <soren> pitti: Oh,I need to wait for a publisher run, don't I?
[08:02] <tkamppeter> superm1: hi
[08:14] <pitti> soren: yes
[08:23] <lool> Does someone know why we pull things like ubiquity, casper, or even lupin-casper in livecd-rootfs instead of the live seeds?
[08:23] <lool> I mean why LIVELIST="ubuntu-live^ laptop-detect casper lupin-casper" instead of LIVELIST="ubuntu-live^" + seeding?
[08:26] <slangasek> I guess cjwatson or lamont might have an answer
[08:27] <StevenK> lool: hysterical raisins, I suspect
[09:03] <maxb> If there are any main-sponsors or ubuntu-release members who would like to weigh in on LP 406245 it would be appreciated - it's missed FeatureFreeze whilst waiting for sponsorship, but I think it's important for Karmic
[09:13] <ogra> cjwatson, u bumped the dove ABI in d-i (just in case you are rolling a package right now, there is a pending change)
[09:13] <ogra> s/u/i/
[09:24]  * pitti blinks
[09:24] <pitti> ValueError: Invalid value '"Medium"' for parameter 'importance': valid values are: "Unknown", "Critical", "High", "Medium", "Low", "Wishlist", "Undecided"
[09:24] <pitti> go launchpadlib
[09:25] <pitti> james_w: did you ever happen to see this by chance? happens since recently, probably with new wadllib or so
[09:25]  * pitti files bug
[09:25] <dholbach> '"Medium"' != "Medium"
[09:25] <dholbach> or am I wrong?
[09:25] <pitti> right, seems wadllib quotes it once too often or so
[09:25] <pitti> dholbach: right, it's probably that
[09:25] <pitti> my code didn't change in ages, though, and I don't see what's wrong
[09:25] <pitti> task.transitionToImportance(importance='Medium')
[09:27] <geser> pitti: I've seen this yesterday, bug #418802
[09:28] <pitti> geser: ah, thanks
[09:29] <james_w> yeah, I need to update the bug
[09:29] <james_w> I forgot that it was blocked by the ugly python-oauth MIR
[09:30] <james_w> and I'm not sure what to do about it
[09:54] <ttx> cjwatson: eucalyptus should reach the CD now that all of it was promoted... when should the cloud installer part hit the daily CD ?
[09:59] <cjwatson> ttx: it's in the archive, you know the rules I'm sure :)
[10:00] <ttx> cjwatson: cool, thanks :)
[10:00] <cjwatson> the node installation isn't really right yet though
[10:00] <cjwatson> and need a small change to CD bits to get a boot option in place
[10:01]  * cjwatson promotes eucalyptus-udeb
[10:06] <apachelogger> mvo: salut, apturl-kde additions pushed to trunk branch (not yet uploaded), please have a quick look (especially at the translation stuff, I am not quite sure how to test pot creation) and upload if you are good with it
[10:07] <mvo> apachelogger: thanks, will do
[10:07] <evand> pitti: I'm slightly confused by bug 400179.  It says you promoted pywebkitgtk, but it lists udev as the package and I don't see it in the overrrides file.
[10:09] <pitti> package is still pywebkitgtk; I'll re-promote it
[10:09] <pitti> it's not the first time that a change-override.py command was just silently not working :/
[10:10]  * cjwatson sighs at people projecting single bugs in grub2 that affect them into "it shouldn't be the default"
[10:10] <pitti> evand: done
[10:11] <cjwatson> BTW is anyone here successfully running GRUB2 with Windows ME?
[10:11] <cjwatson> there's a really really weird bug report about WinME thinking it's a virus
[10:11] <evand> pitti: thanks!
[10:12] <evand> Anyone have a Karmic machine and a USB disk (that they don't care about) handy and want to test for me whether DeviceKit-disks' PartitionTableCreate dbus method is broken?
[10:15] <pitti> evand: o/
[10:15] <pitti> what do you want me to do?
[10:16] <pitti> I have an 1 GB USB stick which I can trash at will, thath should suffice?
[10:16] <evand> pitti: cool.  I'm seeing "Error creating partition table: timeout (10s) waiting for change" when calling PartitionTableCreate with 'none', [] in d-feet.
[10:16] <evand> pitti: can you reproduce that?
[10:16] <pitti> 'none' literally?
[10:16] <evand> yes
[10:17] <evand> it will clear the partition table
[10:18] <pitti> evand: is 'none' even legal? shouldn't that be "mbr" or so?
[10:18] <pitti> evand: right, I get the same error
[10:18] <pitti> evand: it does work fine with 'mbr', []
[10:18] <evand> if you say mbr when a partition table exists, you get an error, I believe
[10:19] <evand> indeed, "device already has a partition table of given scheme"
[10:19]  * pitti tries
[10:19] <pitti> oh nice, palimpsest can also partition now
[10:20] <pitti> ok, I have an existing partition table now
[10:20] <evand> (I'm implementing a "format the device" method here, so it needs to wipe everything (including the boot sector), and then create a msdos style partition table and a single fat32 partition spanning the disk)
[10:20] <evand> okay
[10:21] <evand> thanks!
[10:21] <pitti> 'org.freedesktop.DeviceKit.Disks.Error.Failed: device already has a partition table of given scheme'
[10:21] <pitti> confirmed
[10:21] <pitti> that's "mbr", [] with an already existing mbr
[10:22] <tkamppeter> superm1: hi
[10:22] <pitti> evand: so it seems the bug is that 'none', [] works, but doesn't give a proper return code?
[10:22] <evand> pitti: indeed, it's timing out, but otherwise works
[10:22] <pitti> ok, that should be fixed then
[10:23] <evand> indeed, I'll file a bug report
[10:29] <tkamppeter> pitti, have you ever submitted a patch to a vger.kernel.org mailing list?
[10:29] <pitti> tkamppeter: no, I didn't
[10:29] <pitti> the #ubuntu-kernel folks certainly did, though
[10:34] <evand> pitti: filed as bug 419796
[10:36] <ddeath> Hi
[10:37] <ddeath> The console application won't display user information when running under X Session
[10:37] <ddeath> It is correct behavior?
[10:52] <IntuitiveNipple> Which would be the correct mailing-list to ask a very technical question about python-support, CDBS, and adding a "python-mlt" binary package to "mlt" - the main issue being how to run python-support only for python-mlt (not all the mlt binary packages), or how to recreate python-support's binary-arch output manually?
[10:52] <ddeath> Hi.
[10:52] <directhex> hm. it's not clear to me from xorg.0.log which input device is used in the event that xinput thinks there are "multiple" mice
[10:52] <ddeath> Could anybody look on my library and ask god to include it into Ubuntu?
[10:54] <ddeath> https://sourceforge.net/projects/cli2gui/
[10:55] <slangasek> directhex: all of them?
[10:56] <directhex> slangasek, hm, then i need to debug it. assuming xev isn't lying to me, it's not seeing any events at all from the side buttons or side-wheel
[10:58] <directhex> (II) Microsoft Microsoft Wireless Optical Mouse? 1.00: Found 5 mouse buttons
[10:58] <directhex> lies
[11:02] <sebner> directhex: no wonders it doesn't work with ubuntu
[11:02] <sebner> slangasek: now in NEW (again) :)
[11:05] <slangasek> sebner: yep, accepted
[11:05]  * sebner hugs slangasek and showers with with cookies :)
[11:10]  * hyperair wishes mdadm and lvm2 are installed on the livecd by default
[11:23] <Keybuk> hyperair: you can use the alternate CD to install with them
[11:23] <Keybuk> or you can just apt-get install them if you need to mount an LV or MD device
[11:23] <hyperair> Keybuk: yes, yes i know. but i'd like to avoid having to apt-get install them all the time =\
[11:23] <Keybuk> "all the time" ?
[11:24] <Keybuk> you break your MD arrays *that often*? :p
[11:24] <hyperair> for recovery purposes
[11:24] <hyperair> more like i'm trouble shooting grub, and it's refusing to read anything
[11:24] <hyperair> Loading Stage1.5Read Error
[11:24] <Keybuk> remember that if they were on the Live CD, they'd be on the default install for everyone
[11:24] <hyperair> so i tried grub2, and i got Loading kernel.. Read error
[11:24]  * hyperair whacks grub
[11:25] <hyperair> eh? really?
[11:25] <cjwatson> Keybuk: not actually quite true ...
[11:25] <sebner> Keybuk: is it possible that e2fsprogs broke anything? Since the updates fsck fails on boot. Telling me root partition needs a manual fsck. I do and reboot, works. On the next day I start the laptop again, same issue
[11:25] <cjwatson> the installer would have to remove them for everyone
[11:25] <Keybuk> cjwatson: well, you could uninstall them, but that's just wasting effort ;-)
[11:25] <cjwatson> Keybuk: consider that ubiquity is not on the default install for everyone :)
[11:25] <Keybuk> sebner: fsck will give you detailed output, what is it?
[11:25] <cjwatson> the real reason we don't have them on the live CD yet is that it would cause quite a bit of confusion since ubiquity doesn't support LVM or RAID yet
[11:26] <Keybuk> cjwatson: actually we *removed* them from the set a while back
[11:26] <sebner> Keybuk: on bootup it just tells me, fsck died on /dev/sda and needs a manual fsck
[11:26] <Keybuk> we didn't want LVM or RAID on desktop installs because they're expensive
[11:26] <sebner> *dev/sda3
[11:26] <cjwatson> Keybuk: right, I know
[11:26] <cjwatson> Keybuk: but nevertheless that's the reason they aren't in the live seed
[11:26] <cjwatson> what's in the desktop install is a red herring I think
[11:26] <Keybuk> sebner: and what does the output of fsck -y /dev/sda3 say?
[11:26] <Keybuk> cjwatson: I'd say that u6y shouldn't support them
[11:27] <cjwatson> I want it to (at least LVM, maybe not RAID), just haven't had time
[11:27] <Keybuk> the experience would be much better if we waited to support btrfs instead
[11:27] <sebner> Keybuk: Checking inodes etc, result is always 0.4% non-contiguous
[11:28] <Keybuk> sebner: see, what you're not doing here is pasting me the exact output
[11:28] <sebner> Keybuk: well, next time I boot up I'll make notes ;)
[11:30] <Keybuk> sebner: there's a particular e2fsck change that outputs a particular piece of information
[11:30] <Keybuk> if you don't have that, then no, I don't think the update will have "broken" it
[11:30] <Keybuk> you could simply be failing to unmount the filesystem properly on shutdown, etc.
[11:31] <slangasek> ArneGoetje: was ttf-vlgothic meant to directly replace tt-sazanamic-gothic?  because the bzr log says they're meant to be smaller, but vlgothic is 2MB larger than sazanami-gothic
[11:31] <sebner> Keybuk: Uhhh, that may be a point. since some days it hangs on shutdown
[11:31] <Keybuk> sebner: there you go then, unclean/dirty filesystem -> fsck required
[11:31] <sebner> Keybuk: not sure if it's because of the -7 kernel. I'll try
[11:33] <ArneGoetje> slangasek: ttf-vlgothic is preferred over ttf-sazanami-gothic by Japanese users.
[11:34] <slangasek> ArneGoetje: but it cost us 2MB on the CDs that we already didn't have... :/
[11:34] <ArneGoetje> slangasek: together with the other changes I made, we actually gained space according to the Size: numbers
[11:35] <slangasek> ArneGoetje: which changes?
[11:35] <slangasek> the arabic / chinese changes?
[11:35] <slangasek> it's a slight net gain, yes
[11:36] <ArneGoetje> slangasek: http://pastebin.ubuntu.com/259752/
[11:39] <ArneGoetje> slangasek: I might reshuffle and repackage fonts further to gain extra space while supporting as many scripts as possible on the LiveCD.
[11:39] <torkel_> sebner: there are a couple bug reports blaming -7 kernel to hang on shutdown
[11:39] <slangasek> ArneGoetje: hmm, yep, those numbers look good
[11:39] <slangasek> and in fact, alternates /are/ down in size vs. alpha-4
[11:39] <slangasek> so why are the liveCDs up
[11:40] <slangasek> possibly livefs build failures
[11:40]  * ArneGoetje doesn't know how size calculation for the LiveCD works
[11:40] <slangasek> much less precisely :-P
[11:41] <torkel> sebner: for instance #418509
[11:41] <directhex> f-spot 0.6.1.1 should give you a couple of meg
[11:43] <slangasek> ArneGoetje: right, this libgd2 conflict is breaking the livefs builds.  Why does libm17n-0 care about xpm support?
[11:43] <ArneGoetje> slangasek: no idea
[11:43] <slangasek> hmm, I'll have a closer look
[11:43] <ArneGoetje> slangasek: thanks
[11:47] <pitti> StevenK: would you have a minute to source NEW media-player-id? It's a small data-only package, but needed by new rhythmbox
[11:47] <agutierr> hello all: I am using preseeds to make unattended ubuntu install. Well, someone knows how to tell installer NOT to install a package (Network-manager :-). Thanks!
[11:47] <pitti> StevenK: it's more or less converted data to hal, and I'll maintain it, so it's fine for main
[11:47] <pitti> StevenK: s/to/from/, of course
[11:51] <sebner> torkel: cool, thx for the hint
[11:53] <pitti> james_w: retracers just failed with
[11:53] <pitti>   File "/usr/lib/python2.6/dist-packages/launchpadlib/errors.py", line 20, in <module>
[11:53] <pitti>     from lazr.restfulclient.errors import *
[11:53] <pitti>   File "/usr/lib/python2.6/dist-packages/lazr/restfulclient/__init__.py", line 19, in <module>
[11:53] <pitti>     import pkg_resources
[11:53] <pitti> ImportError: No module named pkg_resources
[11:53] <pitti> james_w: that's just a missing dep from -launchpadlib to python-pkg-resources, do you agree? I'll do the change now
[11:54] <james_w> restfulclient
[11:54] <james_w> I'll upload, sorrt
[11:54] <pitti> ah, ok
[11:55] <pitti> james_w: don't worry, I can do it, just checking with you
[11:55] <james_w> already half way through
[11:55] <pitti> heh, ok :) (so was I)
[11:55]  * pitti drops and fixes retracers instead
[11:55] <pitti> james_w: thansk!
[11:56] <james_w> thank you
[11:56] <james_w> I guess pkg_resources isn't something that people are required to put in setup.py?
[11:56] <pitti> as requires?
[11:56] <pitti> they shold, it's not a built in module
[11:59] <james_w> lazr.restfulclient_0.9.3-0ubuntu2 uploaded
[11:59] <pitti> yay you
[12:00] <james_w> and bug filed upstream
[12:00] <james_w> I'm concerned about python-oauth though
[12:01] <pitti> I thought using the other API version was okay?
[12:01] <directhex> i really should work out how to make my mouse not suck
[12:01] <Laney> stop using a dyson
[12:01] <directhex> it worked before the new hrad disk, so that implies it worked with manual xorg.conf manglement
[12:03] <james_w> pitti: I thought so, dobey has objections to using it though
[12:03] <james_w> pitti: the issue isn't entirely fixed for server implementations, but we have none of those in Ubuntu
[12:03] <pitti> james_w: is it strictly required in p-launchpadlib? it wasn't necessary so far
[12:04] <james_w> the old version had an embedded copy
[12:04] <james_w> u1 still does
[12:04] <pitti> ugh
[12:04] <james_w> and dobey has objections to us using the system copy instead of the embedded one, for reasons that aren't entirely clear to me
[12:04] <pitti> but then we can just as well promote it, if it already has been in main covertly
[12:05] <pitti> an explicit package is so much easier to support than trying to find hidden copies
[12:05] <james_w> he has valid concerns about the code, but I don't see why that stops us using the exact same code from a single package
[12:05] <james_w> exactly
[12:05] <james_w> he is proposing a fork to fix the issues as he finds upstream to be too slow responding to his concerns and patches
[12:06] <cjwatson> agutierr: err, it's tricky to exclude a package from a task, easiest way is to use preseed/late_command to remove the package after it's installed
[12:06] <agutierr> cjwatson, the problem, on the installer I only have apt-install, not apt-remove command
[12:06] <james_w> it's your call as to what goes in, I have made it clear to him that we are not shipping karmic with an embedded copy of oauth.py when it is packaged separately
[12:07] <james_w> I'm not sure what the situation will look like when we release though, potentially both projects will use the fork and we drop the python-oauth package
[12:07] <slangasek> ArneGoetje: ok, no reason m17n-lib needs libgd2-xpm specifically - fix uploaded
[12:08] <slangasek> ArneGoetje: thanks for your work on getting the CDs smaller :)
[12:10] <cjwatson> agutierr: apt-install is just a wrapper
[12:10] <cjwatson> agutierr: 'in-target apt-get purge network-manager' or similar ought to do it
[12:12] <agutierr> ahh
[12:12] <agutierr> ok!!!
[12:12] <agutierr> so much thanks
[12:14] <slangasek> TheMuso: why does speech-dispatcher use libaudio-dev?  Surely nothing should be using that today?
[12:14] <slangasek> TheMuso: (pulls it into the CDs now by default)
[12:26] <ogra> oh my, pulse as it is hacked up for arm support upstream now will never work if you dont compile it on the machine you want to use it on :/
[12:26] <ogra> (reads /proc/cpuinfo inline from the code at buildtime)
[12:42] <pitti> doko: does dh_pycentral change a #!/usr/bin/python2.6 shebang line into #!/usr/bin/python ?
[12:42] <pitti> doko: can I tell it not to? (it really only works with 2.6, and I would like to upload it to debian experimental)
[12:43] <doko> pitti: no, not automatically. do you call python2.6 setup.py explicitely?
[12:43] <doko> some build systems replace it automatically
[12:43] <pitti> doko: I don't, should I?
[12:43]  * pitti tries, thanks
[12:45] <Keybuk> *blink*
[12:45] <Keybuk> /dev/sda1: Superblock last mount time (Thu Aug 27 14:34:07 2009,
[12:45] <Keybuk>         now = Thu Aug 27 12:44:59 2009) is in the future
[12:47] <pitti> doko: it's correct in debian/tmp, though, just changed in debian/calibre
[12:47] <pitti> so it's not the upstream build system
[12:48] <doko> pitti: which package
[12:48] <pitti> doko: calibre
[12:48] <pitti> doko: that's why I thought it was dh_pycentral
[12:48] <doko> pitti: unstable, karmic?
[12:49] <pitti> doko: right
[12:49] <doko> right what?
[12:49] <pitti> oops, karmic
[12:49] <doko> :)
[12:49] <pitti> can't upload to sid (ENOPYTHON2.6)
[12:54] <doko> pitti: well, you call python, not python2.6. that's like setuptools doing this
[12:55] <pitti> doko: ah, thanks
[12:55] <doko> likely even
[12:57] <pitti> doko: ah, no, the install command installs into debian/tmp/, and that is correct
[12:58] <pitti> the shebangs get changed in the debian//tmp -> debian/calibre mangling (and it's not dh_install, I'm sure)
[12:58] <pitti> but anyway, python2.6 setup.py install still does the trick
[12:58] <pitti> doko: thanks!
[13:04] <doko> pitti: is bug 320743 filed with the help of apport? IMO apport should not file this kind of report, and point the user to remove the corrupt archive
[13:05] <pitti> doko: ah, can't build it for 2.6 anyway, since all the dependencies are only available for 2.5
[13:05] <pitti> doko: looking
[13:07] <pitti> doko: indeed; apt shouldn't create those in the first place, but I'll filter them out in the hooks for now; thanks for pointing out
[13:07] <doko> \o/
[13:09] <doko> is arky an automated tester?
[13:25] <tkamppeter> pitti, a question about bug 419834
[14:10] <liw> hm, in my karmic desktop, I seem to have a sound volume control in the gnome panel that I can't get rid of
[14:10] <liw> in the notification area widget
[14:10] <ion> liw: System → Preferences → Startup Applications, uncheck Volume Control, i think.
[14:11] <liw> what a sucky way to control that
[14:14] <ion> Meh
[14:14] <pitti> hi tkamppeter
[14:14] <directhex> hm
[14:17] <directhex> why is mouseemu installed by jaunty's ubiquity install?
[14:20] <tkamppeter> pitti, hi
[14:21] <directhex> found it. stupid ubiquity
[14:24] <Keybuk> is it wrong that I have a post-it note on a netbook with "DO NOT REBOOT!" in large letters?
[14:24] <pitti> tkamppeter: you had a question about hplip PK-1 porting?
[14:24] <ion> keybuk: Any progress with the mount daemon, btw?
[14:24] <Keybuk> ion: yes
[14:25] <Keybuk> it's not really a daemon
[14:25] <Keybuk> ion: you can actually do fully native upstart-based filesystem mounting ;)
[14:25]  * Keybuk figured out how
[14:25] <soren> Keybuk: Depends.. Is it turned off?
[14:25] <ion> keybuk: Awesome
[14:25] <Keybuk> soren: no ;)
[14:25] <Keybuk> ion: but the fully native upstart one is bloody inefficient ;-)
[14:25] <soren> Keybuk: Then I'd say yes, it is wrong :)
[14:25] <ion> Heh
[14:26] <highvolt1ge> mount daemon? that's called an incubus right?
[14:27] <ion> keybuk: That will handle local mountpoints depending on network mountpoins, fsck et al?
[14:27] <Keybuk> highvolt1ge: or a succubus, depending on your inclination
[14:27] <Keybuk> ion: yup
[14:28] <ion> keybuk: How about the parallelizing of fsck instances that work on physically separate devices?
[14:28] <Keybuk> ion: yes
[14:29] <ion> (or blocking fsck instances that work on the same physical device, depending on how you look at it)
[14:30] <soren> Keybuk: I don't think you traditionally get to make a choice between incubi and succubi.
[14:30] <soren> Perhaps that's why they're so dreaded.
[14:30] <highvolt1ge> Keybuk: indeed
[14:31] <LordMetroid> Is there a netinstall for the alpha4 or how would I go about installing alpha4 in order to help
[14:32] <LordMetroid> Ahh, #ubuntuone already answered, sorry
[14:34] <tkamppeter> pitti, yes.
[14:35] <tkamppeter> pitti, you say in the bug that it is enough to remove the PK support from HPLIP, simply use a ==disable option?
[14:35] <pitti> tkamppeter: no, I didn't
[14:35] <pitti> tkamppeter: the PK client code can be entirely removed, but the PK server code needs to be ported
[14:35] <cjwatson> Keybuk: wild speculation from me in bug 412972, wonder if you could look
[14:36] <pitti> tkamppeter: previously, the callers of PK-protected methods had to do PK stuff themselves to get authorization after a denied call, etc.; that was changed, PK does it all by itself now
[14:36] <cjwatson> hmm, actually, the most recent SigBlk mask doesn't match
[14:36] <pitti> tkamppeter: entirely disabling PK is legitimate, of course, but that would lead to reduced functionality?
[14:36] <directhex> ooh, sigblk mask issues? i remember those from f-spot
[14:37] <pitti> tkamppeter: do you know what part of hplip uses that, I guess user tools to check ink level and such stuff?
[14:37] <tkamppeter> pitti, HPLIP uses it to gain privileges for setting up queues and installing the proprietary plug-in.
[14:38] <al-maisan> Hello there, I am doing archive administration today and have a question:
[14:38] <al-maisan>  given a package P listed for demotion to universe: If I don't find P mentioned in any of the seeds and "checkrdepends P" shows no packages in main depending on P then it's safe to demote the latter.
[14:38] <al-maisan> Is that right?
[14:38] <tkamppeter> For normal users seeing ink levels ACLs are used.
[14:38] <pitti> tkamppeter: hm, I thought queues were handled by cups
[14:38] <pitti> al-maisan: in fact, component-mismatches does that very check
[14:38] <james_w> al-maisan: listed by component-mismatches?
[14:38] <cjwatson> al-maisan: yes, that's generally sane, though if I can I usually also try to look through history to find out why it used to be in main, just as a double-check
[14:39] <tkamppeter> pitti, HPLIP serves for all distros, also the ones where there are no privileged users in the lpadmin group.
[14:39] <pitti> al-maisan: if a package appears there, it's _technically_ safe to promote; however, sometimes that's a bug, and it's missing seeding or a dependency
[14:39] <cjwatson> sigblk> I noted that su blocks a bunch of signals, and then (later) calls pam_close_session
[14:39] <cjwatson> without restoring the signal mask
[14:39] <pitti> al-maisan: for example, a common case is transitional packags which don't have rdepends any more; but we need to keep them in main (and seed them) so that upgrades work
[14:39] <cjwatson> so that suggests to me that possibly a PAM session module might end up restarting a daemon on session close, or something
[14:40] <cjwatson> (which is obviously crazy but I'd imagine it'd be fairly indirect)
[14:40] <al-maisan> pitti: ah, how interesting!
[14:40] <tkamppeter> pitti: For us it means that an unprivileged user can start hp-setup and then a login/password dialog appears when finishing queue setup. If a privileged user logs in there, the queue should get set up (not tested by me).
[14:40] <ScottK> al-maisan: Or something that got promoted because it's needed as a build-depend, but the new upload hasn't happened yet.
[14:41] <pitti> tkamppeter: hm, given that we actually use lpadmin instead of admin for printers, the former actually sounds sane as well?
[14:41] <al-maisan> ScottK: gotcha, thanks!
[14:41] <pitti> tkamppeter: anyway, if the existing PK functionality is disposable, disabling it is certainly fine
[14:41] <pitti> but I have no clue about hplip, and what that would break, so I rather don't do that
[14:42] <tkamppeter> pitti: I have build HPLIP simply with PK support all the time. I do not really know whether it is PK client or PK server, or perhaps  both.
[14:46] <pitti> tkamppeter: both, I presume
[14:46] <al-maisan> so, the nvclock/smartdimmer packages are listed for demotion to universe. Can somebody please explain how this came about..?
[14:47] <pitti> tkamppeter: cups doesn't have PKified calls, so it can only provide these services itself
[14:48]  * directhex bugs ~ubuntu-installer with a buggy bug
[14:50] <pitti> al-maisan: you can use "checkrdepends nvclock jaunty" to see what it was used by in jaunty
[14:50] <Keybuk> cjwatson: yeah
[14:50] <Keybuk> clearly it's a signal mask issue
[14:50] <lool> kirkland: Hey I see qemu-kvm pulls bridge-utils as a Depends; neither kvm nor qemu did this in the past, could it be removed or at least relaxed?  I never used it on my laptop and would prefer continuing to avoid setting up a bridge there
[14:50] <Keybuk> but from what
[14:50] <al-maisan> cjwatson: so, when you "look through history", where do you look?
[14:50] <al-maisan> pitti: thanks!
[14:50] <pitti> -- jaunty/main amd64 deps on smartdimmer:
[14:50] <Keybuk> cjwatson: there's a sneaky quick fix, of course ;)  make ssh an upstart job
[14:50] <pitti> hal
[14:50] <tkamppeter> pitti, can you add some references/additional info to the bug report, so that the HP guys can migrate HPLIP easily?
[14:51] <pitti> al-maisan: so, apparently it was dropped from hal; I'll check the changelog
[14:51] <cjwatson> al-maisan: seeds, .debs, etc.
[14:51] <cjwatson> directhex: there are already bugs about mouseemu, don't bother
[14:51] <pitti> tkamppeter: I gave a link to the porting guide
[14:51] <cjwatson> directhex: there's no way to detect "do you have a one-button mouse", unfortunately
[14:51] <tkamppeter> pitti, OK
[14:51] <directhex> cjwatson, sure there is.
[14:51] <cjwatson> directhex: so we just check "is it an Intel Mac"
[14:51] <cjwatson> directhex: oh?
[14:51] <directhex> cjwatson, no intel desktop mac has ever had a single button mouse
[14:51] <directhex> cjwatson, only laptops do
[14:51] <cjwatson> directhex: bluff
[14:52] <cjwatson> directhex: I have one just to my left
[14:52] <pitti> al-maisan: ah, I see the confusion
[14:52] <pitti> al-maisan: I need to add back the dependency, please leave it in main for now
[14:52] <al-maisan> pitti: also: "jaunty/main i386 deps on smartdimmer: acpi-support"
[14:52] <pitti> al-maisan: right, but that's truly obsolete
[14:52] <liw> cjwatson, is it the mighty mouse? (the mighty mouse in my apartment has at least two buttons: right side is a hidden button, can be clicked separately though)
[14:52] <al-maisan> pitti: right, will do.
[14:53] <cjwatson> liw: I forget, I don't use it much
[14:53] <directhex> cjwatson, mighty mouse has shipped by default since october 2005. intel macs appeared in 2006
[14:53] <cjwatson> patch welcome to turn it off for desktops
[14:53] <cjwatson> the relevant source package is hw-detect
[14:54] <liw> (the mighty mouse right button is so well hidden it might as well not exist, though)
[14:55] <directhex> cjwatson, isn't it as simple as inserting "laptop-detect &&" or am i missing something?
[14:55] <pitti> al-maisan: hal uploaded, thanks
[14:55] <al-maisan> pitti: thank you :)
[14:55] <directhex> liw, the mighty mouse looks physically single-button. if it has a scrollball, it has 4 clickables & is a mighty muse
[14:55] <directhex> cjwatson, does the mouse to your left have a scrollball?
[14:55] <cjwatson> directhex: and depending on laptop-detect-udeb, I suppose
[14:55] <cjwatson> yeah, it does
[14:55] <liw> directhex, that's the one I mean, yes
[14:56] <cjwatson> ok, my apologies
[14:56] <directhex> cjwatson, then it's 4-button, and mouseemu would likely prevent one from working
[14:56] <directhex> probably the "squeeze it like you mean it" button
[14:57] <cjwatson> here's another question
[14:57] <cjwatson> WHY does mouseemu prevent it from working? it should just pass through those events
[14:57] <cjwatson> there's an argument that that would be a more complete fix
[14:58] <directhex> i agree. still working on that bug
[15:00] <directhex> looks 100% by design to me
[15:01] <ogra> directhex, yo
[15:01] <directhex> ogra, yup?
[15:02] <ogra> directhex, is there any chance i can get some mono people look at Bug 391124 ?
[15:02] <ogra> i'm a bit lost with it
[15:03] <cjwatson> directhex: by design> how so? it's definitely meant to pass through mouse events
[15:03] <ogra> but we need to include tomboy in the arm images ... its apparently only tomboy having issues, f-spot works fine as expected so no general mono prob imgo
[15:03] <ogra> *imho
[15:04] <directhex> cjwatson, define "pass through". mouseemu for me appears to swallow all real mouse events (event6), and regurgitates them itself under its virtual device (event5) - but the virtual device lacks buttons
[15:04] <directhex> ogra, have you spoken to sandy?
[15:04] <cjwatson> directhex: defining it by mouse_event and passthrough in the source code
[15:04] <ogra> directhex, only on the bug yet
[15:04] <ogra> (see the last two comments)
[15:05] <cjwatson> directhex: I'm not saying your symptoms are untrue; but when you say "bad design" that suggests that you think it's deliberate in the code, rather than a bug
[15:06] <cjwatson> the virtual mouse device does this to set up buttons:
[15:06] <cjwatson>         ioctl(ui_mouse_fd, UI_SET_KEYBIT, BTN_LEFT);
[15:06] <cjwatson>         ioctl(ui_mouse_fd, UI_SET_KEYBIT, BTN_RIGHT);
[15:06] <cjwatson>         ioctl(ui_mouse_fd, UI_SET_KEYBIT, BTN_MIDDLE);
[15:06] <cjwatson> what else should it be doing?
[15:07] <directhex> cjwatson, passing BTN_SIDE, BTN_EXTRA et al?
[15:08] <cjwatson> directhex: that sounds sensible. Is it only the buttons after the third that it breaks for you?
[15:08] <directhex> cjwatson, yes. well, scrolling works, where scrollwheels are seen in x as buttons 4 and 5
[15:09] <cjwatson> and are there any drawbacks to passing extra buttons? presumably, ideally, we should only pass through those buttons which the real mouse has
[15:09] <jpds> MacSlow: Please prod bug #419928 when you have time.
[15:09] <cjwatson> otherwise I guess there might be some software that acts differently on the assumption that there's a scrollwheel present when there isn't
[15:09] <directhex> cjwatson, yes - or, if X is happy with it, not swallowing button presses for all buttons. i'm not sure about the best approach
[15:10] <MacSlow> jpds, "prod"?
[15:10] <MacSlow> jpds, what do you mean by this?
[15:10] <jpds> MacSlow: Take a look.
[15:11] <ogra> MacSlow, prod = stochern/stupsen :)
[15:12] <directhex> cjwatson, Bug #419947 if you want to write some notes on it
[15:13] <MacSlow> jpds, done
[15:14] <directhex> ogra, my instinct is that it's a gtk# bug
[15:14] <directhex> ogra, let me find mkestner
[15:15] <ogra> directhex, thanks a lot
[15:16] <cjwatson> directhex: thanks
[15:17] <directhex> ogra, he seems offline. try pinging mkestner@novell.com - he's the gtk# maintainer, and it seems to be dying in the binding in the binding layer - something about menu positioning, perhaps? this isn't on a normal gnome desktop is it?
[15:17] <jpds> MacSlow: So notify-osd bubbles should be coming up half-way down the screen?
[15:17] <ogra> directhex, thats a normal gnome desktop under armel if i either click the tray icon or the "notebook" button
[15:18] <directhex> cjwatson, if X uses a composite of all mice plugged in, then could mouseemu simply not swallow events outside the range it emulates, so those few buttons go through "real" event6 rather than emulated event5?
[15:18] <ogra> directhex, and as i said above it must be something tomboy uses that f-spot doesnt, f-spot works fine on the same desktop
[15:19] <MacSlow> jpds, see my comment on https://bugs.edge.launchpad.net/ubuntu/+source/notify-osd/+bug/419894 (which #419894 is a duplicate of)
[15:19] <directhex> ogra, well, i know tomboy uses non-standard decorations in tis context menu, perhaps that's related
[15:19] <ogra> yeah, might be
[15:19] <directhex> ogra, certainly sandy is the first port of call, but i have a hunch it's gtk# - sandy can confirm though
[15:19] <ogra> i wouldnt call it a general gtk# bug though
[15:20] <jpds> MacSlow: Aha, OK.
[15:20] <directhex> time to catch a bus!
[15:20] <ogra> since f-spot uses gtk# too and doesnt have any issues, probably that makes it easier to intersect
[15:28] <blackxored> hello all
[15:36] <cjwatson> directhex: I'm not sure you can do that - AFAICS you either grab all events or none
[15:37] <cjwatson> argh. I HATE PATCH SYSTEMS. (just ate my code)
[15:40] <mvo> quilt?
[15:40] <mvo> dholbach had this idea of having a "edit-patch" script that would provide a common editing interface on top of all the different ones
[15:41] <mvo> (that would at least make working with them a bit easier)
[15:41] <cjwatson> dpatch. I hate them all almost equally though
[15:41] <dholbach> and prompt you to fill out the PatchTaggingGuidelines stuff afterwards
[15:41] <mvo> :)
[15:41] <mvo> dholbach++
[15:41] <sistpoty|work> edit-patch --eat-my-code :P
[15:42] <chrisccoulson> liw - i'm not sure i agree with bug 419912
[15:43] <chrisccoulson> nm-applet (the other persistent notification icon) doesn't have an option to exit either
[15:43] <liw> chrisccoulson, the fact that it is a persistent notification is irrelevant to me, I just want an easy way to get rid of it
[15:43] <chrisccoulson> and if you give users an easy way to quit it, there is no obvious way to relaunch it again (because it is a session agent rather than an application that you launch from the menu's)
[15:44] <liw> so make it easy to put it back, too, no worries
[15:45] <chrisccoulson> hmmm, i'm not sure. perhaps you could report it to the Gnome bugzilla though and discuss it with upstream?
[15:47] <liw> the ubuntu default session is under ubuntu's control, right?
[15:47] <chrisccoulson> yes, but adding an option in the applet to exit would be better off coming from upstream
[15:48] <liw> then please forward the bug
[15:49] <pochu> pitti: hi, do you plan to upload media-player-id to Debian too?
[15:51] <pitti> pochu: can do eventually, but I'm a little tight on time right now
[15:51] <pitti> pochu: it needs an ITP first, and all that
[15:51] <pitti> pochu: do you want to upload the the rb to debian?
[15:52] <pitti> (or RFP)
[15:57] <pochu> pitti: I looked yesterday at switching rb to gudev
[15:57] <pochu> pitti: but libgudev is in experimental only right now anyway, so no hurry :)
[15:58] <pitti> uh, still?
[15:58] <pitti> it becomes ubiquituous, debian should get the latest udev..
[15:59] <pochu>       udev |    0.141-2 |      unstable | source, alpha, amd64, armel, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc
[15:59] <pochu>       udev |      146-1 |  experimental | source, alpha, amd64, armel, hppa, i386, powerpc, s390, sparc
[15:59] <pochu> so yeah
[16:05] <sebner> pitti: the comments aren't that useful (SATA -USB -71), hmm? :(
[16:06] <pitti> didn't have time to look at the replies yet, sorry; crazy FF rush with 16-hour days, etc.; will get to it soon, promised
[16:06] <sebner> heh, np
[16:07] <al-maisan> quick sanity check: ibus-qt/ibus-qt4 are listed for demotion to universe and were only added in karmic. Is it OK to go ahead and demote them?
[16:08] <pitti> ArneGoetje: ^ isn't it supposed to replace skim in Kubuntu, too?
[16:08] <pitti> al-maisan: probably just not seeded yet
[16:08] <Riddell> pitti: hmm, I think we want those ibus-qt packages
[16:08] <al-maisan> pitti: aha, so I should hold off then.
[16:12] <ArneGoetje> we do want ibus-qt in the kubuntu seeds
[16:14] <Riddell> ArneGoetje: I'll add that then
[16:15] <al-maisan> Thanks for the info
[16:16] <ArneGoetje> Riddell: I'm not sure of the kubuntu seeds in the moment, I did some reshuffeling for the ubuntu seeds. http://pastebin.ubuntu.com/259752/ I guess, replace ibus-gtk with ibus-qt and the rest can be the same, or what do you think?
[16:17] <cjwatson> directhex: I'd appreciate it if you could give http://paste.ubuntu.com/260391/ a try
[16:18] <Riddell> ArneGoetje: and add kimpanel too?
[16:19] <directhex> cjwatson, i have an abominable memory. if you email that to me, i'll try it out at home tonight (i'm not at the mac anymore)
[16:19] <Riddell> pitti: re bug 418688 can I move it to main for the sake of FF and look into a wrapper script shortly?
[16:19] <cjwatson> directhex: shall I just put it in the bug?
[16:19] <directhex> yeah, that works
[16:21] <ArneGoetje> Riddell: yep
[16:26] <directhex> maybe i could expense a many-button gaming mouse for the office, that's work
[16:26] <directhex> any benefit it would give to my Quake Live scores would be a side-effect
[16:31] <cjwatson> directhex: indeed, ignore that pastebin URL, since I missed a bit. Updated version in the bug
[16:35] <al-maisan> hmm .. what happened to gnome-terminal in karmic so it does not honour cmd line args like "--geometry 110x20+0+5" any more?
[16:42] <al-maisan> bug #418555
[16:43] <al-maisan> .. and http://bugzilla.gnome.org/show_bug.cgi?id=592435
[16:44] <pitti> Riddell: kimpanel> sure, please go ahead; it seems to be by and large fine
[16:44] <pitti> Riddell: I'll add some official blessing to it
[16:46] <pitti> Riddell: [done]
[16:50] <lool> bryce: I'm giving back xorg-server on i386 to see if it builds now; it seels it was just a transient libdrm installability issue which caused it to FTBFS
[16:59] <LordMetroid> Dang, everything just crashed on my alpha4
[17:02] <cjwatson> bryce,jdstrand: is bug 407428 still happening for you, right now?
[17:13] <Keybuk> it's amazing how much slower the PPA system is once the US is awake...
[17:16] <ScottK> Needs higher build scores for developers ....
[17:16]  * lool gives three cheers to paulliu, StevenK and others who helped shape http://people.canonical.com/~lool/moblin-virtualbox.png
[17:16] <lool> And OEM team and every who participated in the moblin beta work
[17:17] <dholbach> lool: that looks sweet!
[17:17] <lool> Still built from a PPA but on cdimage; hopefully we'll merge as much as possible into Ubuntu proper
[17:27] <dholbach> pitti: did you get in touch with Don Scorgie about it? I'm sure he could help
[17:27] <dholbach> (gnome-help->langpack)
[17:28] <cjwatson> for the replaces fields? how?
[17:29] <dholbach> I though we were pondering a different installation path or something
[17:35] <pitti> dholbach: no, I didn't; the problem really just occurred to me yesterday; he's the GNOME help guru?
[17:40] <dholbach> pitti: rarian guru and knows a lot about the gnome help stuff
[17:40] <pitti> ah
[17:41] <pitti> dholbach: thanks, I'll talk to him; failing that, lool just had a good idea as well
[17:41] <kees> pitti: woohoo!  bug 419658
[17:42] <kees> well, it's an assert bug.  :)
[17:42] <pitti> nice! just saw it
[17:43] <pitti> kees: I think automatic duplication should work as well, let's see..
[17:43] <kees> pitti: so, I just noticed that when upstream rewrote my patch, they also renamed the variable (from __assert_msg to __abort_msg), so I'm going to update our eglibc to match upstream's patch, and then swap it in apport.
[17:43] <kees> pitti: cool!
[17:43] <pitti> eww, a glibc was detected..
[17:43] <pitti> kees: eek, I actually did check the upstream patch, but that failed to catch my eye
[17:43] <kees> heh, yeah, mdz was complaining a while back that the malloc error string is confusing.
[17:43] <pitti> kees: yes, we should do that to avoid divergence, thanks
[17:44] <pitti> kees: oh, it has an address in the assert message, so it might not match after all (for duplicates)
[17:44] <kees> pitti: I'll get that up today; I built the "fixed" eglibc overnight, and confirmed that it works correctly just now.
[17:44] <kees> could the dup-checker learn to ignore 0x[0-9a-f]* ?
[17:45] <pitti> kees: it should be filtered in def crash_signature()
[17:46] <pitti> kees: perhaps not *, but [6-]
[17:46] <pitti> to filter out small numbers like 0x02
[17:46] <kees> pitti: ah, good idea.
[17:47] <kees> pitti: should I try to fix the malloc error message to be more clear?
[17:47] <pitti> kees: is that an ubuntu patch?
[17:47] <pitti> kees: if so, sure
[17:48] <kees> pitti: no, the malloc errors are upstream.  I actually meant "should I send a patch to upstream to improve..."
[17:48] <kees> I'll see what they say, it's always entertaining...
[17:48] <pitti> kees: not really important at least to me, but if you wish
[17:48] <pitti> but it's so much fun
[17:49] <kees> hehe
[17:49] <pitti> reminds me of the discussion about strings like "OMG computer burning" in the kernel
[17:49] <kees> we need more of those kinds of easter eggs.  :)  /me is sad that the new gdm doesn't include the "insert a quarter" easter egg now.
[17:50] <pitti> yeah, that was cute
[17:51] <kees> pitti: oh, btw, should the retracer learn to unwind to the first non-libc stack location for the source retrace?
[17:51] <kees> pitti: otherwise, everything will look like:  StacktraceTop:__kernel_vsyscall (), *__GI_raise (sig=6), *__GI_abort () at abort.c:88, etc...
[17:52] <pitti> that would certainly be good
[17:52] <pitti> we don't use stacktracetop for dup matching for assertions, so it's not immediately urgent
[17:52] <pitti> but stacktracetop is still convenient for developers to look at
[17:52] <kees> true, though it's sometimes really hard to isolate where a fortify crash happens, so I'll likely try to work on that as it would hugely improve the speed of debugging.
[17:53] <kees> actually, nevermind, the full stack trace is sufficient.
[17:53] <kees> you're right, stacktraceTop is a cosmetic issue.
[18:12] <directhex> halfway there, cjwatson!
[18:34] <bryce> cjwatson, I've not seen it the last few days
[18:42] <martinald> hi guys, i am looking to create a GUI frontend to dmg2img for ubuntu. i am wondering if anyone in the ubuntu community would be willing to spend 10 minutes going through what the best programming language and GUI toolkit I should use
[18:43] <martinald> i am very experienced in web programming but I have very little experience of linux GUI programming
[18:43] <martinald> or if someone could point me to a correct channel that would be much appreciated
[18:55] <directhex> martinald, c# and gtk!
[18:55] <directhex> martinald, mor generally, i don't know of any generalist channels for development *on* ubuntu, this is for development *of* ubuntu
[18:57] <jdstrand> cjwatson: re sshd> it hasn't for a little while, but I've rebooted a lot lately. I'll keep an eye out for it though
[19:13] <ebroder> Anyone from ubuntu-sru that could look at bug #330766? It's causing problems for our site deployment, and we were hoping it would be fixed by the time term starts here (in a week)
[20:16] <billybigrigger> anyone aware of the errors in ubuntuone?
[20:16] <billybigrigger> causing %100 cpu usage?
[20:18] <pitti> [ubuntu/karmic] fteqcc 3343+svn3223-1build1 (Accepted)
[20:18]  * pitti tries to pronounce that
[20:18] <pitti> looks like git revision numbers are actually used as package names now? :-)
[20:18] <vorian> keep your teeth together when trying
[20:18] <vorian> it makes it much easier
[20:19]  * sistpoty is innocent :P
[21:15] <ScottK> Speaking of which: Sput shouldn't netsplits be added to the list of events one can hide?
[21:15] <ScottK> Whoops.  Wrong channel.
[21:27] <rtg_> kirkland, you around?
[21:37] <kees> james_w: did anything ever happen with gnome-system-tools and getting it to launch the "self" password changer?
[21:37] <james_w> ah
[21:37] <james_w> no
[21:37] <james_w> I completely forgot about that proposal I'm afraid
[21:39] <kees> james_w: I'd like to try to get a FFe for it; do you have a guess at how long it might take to implement.  it's the only thing that is blocking the ecryptfs feature for the installer.
[21:40] <james_w> ah, because it currently bypasses pam and so changing your password means you can't log in?
[21:40] <kees> correct
[21:40] <james_w> and you would be happy with changing anyone elses password using that causing them to be unable to log in?
[21:41] <james_w> well, not happy I guess :-)
[21:41] <kees> the idea was that if you went to users&groups and selected yourself, it would change the password tab to match the "about yourself" screen that has a proper password-via-PAM thing
[21:41] <kees> not happy, but we felt at UDS it was a reasonable compromise.
[21:41] <james_w> ugh
[21:42] <james_w> users-admin seems to be bust anyway
[21:43] <kees> james_w: can I assign 307019 to you, then, as a catalyst for the g-s-t work?
[21:44] <james_w> I'm just trying to look at this problem, a first glance suggests it could be serious
[21:44] <james_w> but go ahead, even though having a g-s-t bug assigned to me will make me cry
[21:44] <kees> james_w: is it hard to have it just launch the "about me" dialog?
[21:45] <kees> heh, okay
[21:45] <james_w> no, I think that would be quite easy
[21:45] <james_w> you can't do groups from there
[21:45] <kees> okay, right, that's the work-around that would unblock ecryptfs for karmic.
[21:46] <kees> right, I mean, within g-s-t, if you select yourself and go to the password tab, it would just have a single button to launch "About Me", rather than the regular password tab.
[21:46] <james_w> ah
[21:46] <james_w> it's not a tab, but an area on the first tab
[21:46] <james_w> still possible to have a button of course
[21:47] <james_w> plus gnome-about --change-password to get it to show it's password changer only
[21:47] <james_w> that's probably not too much work
[21:47] <james_w> it's just the danger of pulling at that hanging thread
[21:48] <kees> james_w: well, the "contact" tab should have the launcher, and the password area should have the launcher.
[21:49] <kees> I think it's okay to just launch the entire about-me dialog?  maybe drop the "Contact Information" tab in Account Properties, and just replace the Password section of the "Account" tab with a buttonr eading "Change password or contact informatin" ?
[21:50] <james_w> oh, the "contact" tab because that's also present in the other one?
[21:50] <james_w> I think the gnome-about-me one doesn't use gecos for that info
[21:50] <james_w> I think that would be a good suggestion though
[21:51] <kees> oh, heh, yeah, if the about-me doesn't actually change gecos, nevermind on that.  :P
[21:53] <james_w> it seems GNOME ignores gecos though, so whatever about-me changes might be more useful to change for the average desktop user
[22:12] <eurythmia_> if I wished to start contributing as a dev, should I run a dist-upgrade to karmic, or should I perform a clean isntall?
[22:12] <highvoltage> eurythmia_: jaunty will be fine
[22:13] <highvoltage> eurythmia_: you could use karmic as well, but there are risks associated with it
[22:14] <eurythmia_> highvoltage: so, there shouldn't be any *major* differences between the libraries I would be building against if I were using jaunty?
[22:14] <highvoltage> eurythmia_: look up pbuilder on the ubuntu wiki, pbuilder will sort that out for you, it creates a chroot for the package you want to build and also makes sure that you have the correct build dependencies installed in the chroot
[22:15] <highvoltage> eurythmia_: so you can build packages for pretty much any version regardless of the release you're running
[22:15] <eurythmia_> highvoltage: ahh. I hadn't gotten around to reading much about pbuilder yet, but that's pretty neat.
[22:15] <eurythmia_> thanks.
[22:16] <highvoltage> you're welcome
[22:17] <eurythmia_> there's a lot to read when starting to develop (for any project), but I'm making *some* headway.
[22:17] <highvoltage> eurythmia_: if you're interested in packaging, you might want to check out the #ubuntu-motu channel. MOTU is the right place for getting started with packaging, this channel isn't really appropriate for that
[22:17] <highvoltage> eurythmia_: yes indeed, there's lots of reading work
[22:18] <eurythmia_> highvoltage: actually, I'm interested in the kernel, but it's been suggested that everyone starts with MOTU.
[22:21] <highvoltage> eurythmia_: it's a good suggestion, whatever you contribute to in ubuntu, it's pretty much necessary to know how to contribute those changes, and to do that you have to understand some core processes and be familiar with debian packaging
[22:22] <highvoltage> eurythmia_: there's also am #ubuntu-kernel channel where the kernel guys hang out. they could probably sponsor your initial patches and contributions
[22:23] <eurythmia_> highvoltage: yep, I'm already there :)  ... I suppose I'll also try my hand out at the MOTU thing to get started.
[22:24] <sistpoty> erm, highvoltage, eurythmia_: right now, you *should* be using karmic, especially for kernel stuff. otherwise it'd be pretty hard to test changed, wouldn't it?
[22:24] <sistpoty> s/changed/changes/
[22:25] <highvoltage> sistpoty: you can test some things in a virtual machine as well, or on the hardware that you're testing the bugs with
[22:25] <eurythmia_> is there a testing machine?
[22:25] <eurythmia_> or are you referring to a personal test machine?
[22:25] <sistpoty> highvoltage: no, not really in a sufficient matter (for a kernel()
[22:26] <eurythmia_> sistpoty: actually, depending on which part of the kernel is being worked on, VMs are ideal for kernel testing.
[22:26] <highvoltage> sistpoty: I just can't afford instability on my laptop, and I think it's like that for many other people, I have a bunch of other machines that I run karmic on though
[22:26] <eurythmia_> I don't do hardware or drivers ... so it would be okay for me to not run the kernel on a physical machine
[22:27] <sistpoty> eurythmia_: that really depends if it's in anyway related to timing/hardware. if it is, no chance for a vm
[22:28] <eurythmia_> sistpoty: heh, timing issues are their own special brand of bad ... even with the right hardware, there's no guarantee that they'll be reproducible ;)
[22:28] <sistpoty> highvoltage: you're right, that I wouldn't recommend karmic for the average user ;)
[22:28] <sistpoty> heh
[22:29] <directhex> cjwatson++
[22:32] <highvoltage> anyway, sistpoty has much more experience than me so I trust his judgement. I'm just not that convinced that you always *have* to be on the development version on your actual production system in order to contribute
[22:33] <sistpoty> highvoltage: sorry for not being clear enough, what you just stated is certainly right... just this occurance is certainly a special case ;)
[22:34] <highvoltage> sistpoty: ok :)
[22:37] <eurythmia_> highvoltage,sistpoty: thanks, both of you, for your input. :)
[22:37] <highvoltage> eurythmia_: pleasure and good luck.
[22:39] <james_w> kees: bug updated with some suggestions that you may want to stomp out before we get carried away
[22:50] <kees> james_w: checking, one sec
[22:50] <james_w> sorry, shouldn't have pinged you, I'm sure you are subscribed and could respond when ready
[22:53] <kees> james_w: well, it's in recent memory, so my latency is lower.  :)  no problem.  :)
[22:53] <jtimberman> I want to use sbuild for package build testing for hardy through karmic, should the build host node be karmic?
[22:53] <kees> james_w: I'm fine with any of those, but prefer ones that use pipes or fd over dbus.
[22:53] <james_w> kees: any concrete reason?
[22:53] <kees> jtimberman: yeah, it's easier to set up the debootstrap bits (i.e. no work).
[22:54] <kees> james_w: simply that they are ancient methods that are very well understood.  dbus is still "new", and negotiating ssl over a message-passer just makes me want to cry.
[22:55] <james_w> oh, I wouldn't have gone for that one, I just like the idea :-)
[22:55] <james_w> but I would characterise that as natural security professional wariness, I wondered if there were reasons why DBus may present a larger surface or similar
[22:56] <james_w> thanks for your time
[23:00] <kees> james_w: heh, yeah, my programming conservatism really comes out on these kinds of things.  ;)
[23:00] <kees> james_w: np, I've commented on the bug too.
[23:00] <james_w> thanks
[23:01] <james_w> I'll see how Milan feels about the suggestions
[23:01] <james_w> coding suid helpers would be more work, but fits my tendencies better than GUI coding :-)
[23:03] <kees> I think that's why I like the named pipe best: no extra helpers.  backend is already running as root, iirc
[23:06] <james_w> yeah, probably the easiest to implement as well
[23:24] <directhex> cjwatson, poke poke
[23:34] <mathiaz> jtimberman: my main build server is running hardy - and I build packages from dapper to karmic with it
[23:35] <ebroder> Anyone from ubuntu-sru around who could look at either bug #330766 or bug #328575? They're causing problems for our site deployment, and we were hoping to get them fixed as soon as possible
[23:35] <mathiaz> jtimberman: however I had to fix sbuild in hardy as it broke with karmic
[23:35] <jtimberman> mathiaz: already installing karmic ><
[23:35] <jtimberman> which is fine, because i'm going to manage the node with chef, so i can use the chef packages from karmic directly :)
[23:35] <mathiaz> jtimberman: oh well. in that case - if you find a bug don't forget to report it!
[23:35] <jtimberman> mathiaz: definitely.
[23:36] <mathiaz> jtimberman: sounds like a good plan
[23:40] <lifeless> jcastro: you should hang in #bzr somedays ;)
[23:40] <lifeless> jcastro: also  -- bzr-builder < jamesw at u.c>   - is the changelog author for quicklies build
[23:40] <lifeless> jcastro: you may want to tweak/fix that
[23:44] <jcastro> lifeless: That's a limitation of how he's set it up iirc, he mentioned it at the sprint
[23:47] <lifeless> jcastro: sadly I wasn't there
[23:47] <lifeless> its just _odd_ to have you uploading his changelog :)
[23:48] <jcastro> lifeless: yeah I was just mentioning that it's a known thing.
[23:48] <jcastro> lifeless: really james_w is just hijacking everyone's karma