[00:15] <mathiaz> slangasek: do you have an idea what went wrong in bug 328525?
[00:43] <TheMuso> calc: what functionality in OpenOffice needs java, so I have something I can test?
[00:45] <calc> TheMuso: help - search for item
[00:46] <calc> er 'Find'
[00:46] <calc> it doesn't install it by default but i believe if you have either 'openoffice.org' installed or at minimum openoffice.org-java-common it should work
[00:48] <TheMuso> calc: ok
[00:49] <TheMuso> calc: there is no search option in the help menu, do I have to go into OpenOffice help?
[00:50] <TheMuso> I am in writer
[00:51] <TheMuso> calc: nvm found it
[00:56] <TheMuso> calc: ok once I made sure I had openoffice.org-java-common installed, the find function in the help worked without issue. WIll add my comment to the bug.
[01:07] <calc> TheMuso: cool thanks :)
[01:08] <calc> TheMuso: that uses java so it seems it does work now :)
[01:08] <TheMuso> Great!
[01:08] <calc> TheMuso: so i can close the bug after you follow up to it, and if anyone else has troubles they can always reopen it :)
[01:09] <TheMuso> calc: I've followed up to it.
[01:09] <calc> TheMuso: ok thanks
[01:09] <calc> yea in the past ppc wouldn't even compile with java enabled at all so i think it should be fine now that you have verified it
[01:10] <TheMuso> Sweeet!
[01:18] <stgraber> TheMuso: is there a known bug in Jaunty's pulseaudio that'd make it using way more CPU than it should (10-15% with a single sound input) and making the sound to cut sometimes (especially during movies) ?
[01:18] <stgraber> TheMuso: I see a few bugs that could cause that on LP but couldn't find THE bug
[01:18] <TheMuso> stgraber: what ver are you using currently? A new version was uploaded several hours ago, please make sure you have that before filing bugs etc.
[01:18] <TheMuso> ubuntu11
[01:19] <stgraber> still running 10, will update and retry.
[01:19] <TheMuso> ok thanks
[01:20] <TheMuso> a lot of work went into 11, as you might see from the changelog.
[01:20] <stgraber> yeah, just saw the changelog on LP :) lot of changes.
[01:20] <TheMuso> Yep.
[01:21] <TheMuso> Thanks to Daniel for all that hard work to get Pulse running stable. :)
[01:22] <stgraber> good to know siretart is back at work :)
[01:28] <stgraber> TheMuso: no glitch so far, seems to have fixed it. thanks
[01:29] <TheMuso> stgraber: thanks dtchen. :)
[01:29] <TheMuso> s/thanks/thank/
[01:30] <johanbr> stgraber: did the cpu usage go down at all?
[01:30] <stgraber> johanbr: nope but sound is perfect now
[01:30] <johanbr> alright. always something. :)
[01:31] <stgraber> still some 10% of CPU usage from pulse .. though that's on an Atom cpu so ...
[01:32] <dtchen> johanbr: "high cpu usage" was due to two major culprits: spinning on snd_pcm_avail_update() and cpu-intensive resampler. both have been addressed for the most common hardware.
[01:35] <johanbr> dtchen: That's good to hear. I should give pulse a try again. Thanks.
[01:52] <stgraber> dtchen: thx for fixing pulse
[01:52] <ScottK> I have a novice archive-admin question for one of you who's more experienced if someone is around?
[01:53] <StevenK> ScottK: Shoot
[01:55] <ScottK> StevenK: I'm looking at a package that is one BSD file, one file that's explicitly GPL v2 and later, and the rest say GPL v2.  Debian/copyright lumps the V2 files and the V2 and later file together and describes them as V2 and later.
[01:55] <StevenK> Ahh, that's licensing
[01:55] <ScottK> Is incorrectly describing files as V2 and later that are just V2 a reject or an accept and file a bug?
[01:56] <StevenK> ScottK: It doesn't mention the BSD file, and isn't clear, since V2 is different from V2 and later
[01:56] <ScottK> It does mention the BSD file.  That part is fine.
[01:56] <ScottK> The problem as I see it is listing V2 files as V2 and later.
[01:57] <ScottK> No advertising clause on the BSD file, so that's OK to mix with GPL.
[01:57] <ScottK> It's mythnettv if you'd rather just look.
[01:58] <StevenK> ScottK: Right, but the BSD file isn't shown in the copyright file?
[01:59] <ScottK> It is.
[01:59] <ScottK> It's fine.
[01:59] <StevenK> Ah
[01:59] <ScottK> It's not separating the GPL v2 only and the GPL v2 and later.  Sorry I'm not being clear.
[01:59] <StevenK> ScottK: Not sure, to be honest
[02:00] <cjwatson> I would be inclined to reject it for that; it should be simple to fix
[02:00] <ScottK> It's got some interesting packaging issues like build-dep on python-central and build-dep-indep on python-support.
[02:01] <StevenK> ScottK: Eeek
[02:01] <ScottK> cjwatson: Thanks.  I'll do that along with some commentary on the packaging.
[02:02] <JanC> ScottK: that sounds just plain wrong ?
[02:03] <ScottK> It is.
[02:03] <ScottK> And it's a cdbs rules file, so I have no idea what would actually happen if one built it.
[02:03] <ScottK> The guy that uploaded it is new, so ....
[02:24] <slangasek> mathiaz: smells to me like a dpkg/trigger bug
[02:25] <slangasek> mathiaz: in fact, the 'Processing triggers' line 7 lines earlier is fairly conclusive IMHO :)
[02:25] <calc> i tried adding a local repo to sources.list but apt just claims 'Ign file: ./ Packages'
[02:25] <calc> in intrepid
[02:25] <calc> the same setup works in jaunty
[02:26] <calc> the sources.list contains deb file:/root/debs ./
[02:26] <cjwatson> check which files it's actually accessing
[02:26] <calc> and in /root/debs/ i ran apt-ftparchive packages . > Packages
[02:26] <cjwatson> you need to give it a Packages.gz, IIRC
[02:26] <calc> does the same thing for Packages.gz
[02:27] <cjwatson> or maybe even Packages.bz2
[02:27] <cjwatson> cf. Debian #440973
[02:27] <cjwatson> anyway, my advice stands, strace it or something to see what it's actually trying to fetch
[02:28] <StevenK> --print-uris works, too
[02:29] <calc> cjwatson: hmm that seems to work with bzip2, but doesn't seem to be needed on jaunty for some reason
[02:30] <calc> hmm actually that didn't seem to work but it made the Hit/Ign line go away, i'll strace and see what is going on
[02:30] <cjwatson> apt (0.7.17~exp2) experimental; urgency=low
[02:30] <cjwatson>   [ Eugene V. Lyubimkin ]
[02:30] <cjwatson>   * apt-pkg/acquire-item.cc:
[02:30] <cjwatson>     - Added fallback to uncompressed 'Packages' if neither 'bz2' nor 'gz'
[02:30] <cjwatson>       available. (Closes: #409284)
[02:30] <cjwatson>        apt | 0.7.14ubuntu6 |      intrepid | source, amd64, i386
[02:33] <calc> ok so it did download it, hmm
[02:34] <calc> but it still doesn't show up in apt-cache policy
[02:34] <calc> i see it in /var/lib/apt/lists/_root_debs_._Packages
[03:06]  * calc kicks himself
[03:06] <calc> i am trying to install amd64 debs on... i386, argh!!!
[03:06] <calc> no wonder it didn't work
[03:06] <calc> cjwatson: sorry for bugging you earlier :\
[03:20] <Hobbsee> way cool.  kernel panic on hibernation now.  I'm sure this was working a week ago!
[03:20] <TheMuso> Hobbsee: what wireless driver are you using?
[03:21] <Hobbsee> TheMuso: iwl3945
[03:22] <lifeless> Hobbsee: we're moving the panics closer to the start of the uptime
[03:22] <Hobbsee> lifeless: ahhh.  is that the problem... right ;)
[03:22] <lifeless> TheMuso: abentley was reporting hangs on iwl3945, on intrepid, but didn't that get a kernel update recent?
[03:23] <Hobbsee> not sure if it got a kernel headers update, though?
[03:24] <TheMuso> lifeless: don't know.
[03:24] <Hobbsee> oh, hmm.  they're all together
[03:40]  * calc deletes his remaining i386 vm's since he doesn't need them anymore
[03:47]  * Amaranth reports an i386 OOo bug for calc 
[03:59] <wgrant> .win 4
[03:59] <wgrant> Grmph.
[04:05] <calc> Amaranth: you can keep it ;-)
[04:07] <calc> Amaranth: i wasn't able to run amd64 vm's until i upgraded my laptop this past month since the cpu didn't have the right support
[04:07] <calc> Amaranth: and so whenever i build test packages i had to remember to build them for i386, but i don't need to anymore :)
[04:51] <LaserJock> slangasek: it's Tuesday already? :-)
[04:51] <slangasek> yep
[04:52] <TheMuso> By almost 5 hours
[04:52] <TheMuso> UTC time
[04:56] <LaserJock> TheMuso: should be end of Tuesday UTC :-)
[04:56] <TheMuso> LaserJock: What, and push the alpha out bya day? :p
[04:56] <persia> LaserJock, Why?  We've been midnight-starting for a while now.
[04:56] <persia> Often enough the alpha doesn't get out until well into Friday on this side of the world anyway.
[05:00] <LaserJock> persia: I don't have a particular reason. I need to do a couple Edubuntu uploads to make edubuntu-desktop properly installable but I think that shouldn't be a problem.
[05:00] <persia> LaserJock, The do them.  It's a "soft freeze".  You should feel guilty that they are late.
[05:00] <persia> s/The/Then/
[05:00] <persia> Just make sure to inform the release managers if the Edubuntu alpha CDs need rerolling once candidates are ready.
[05:01] <persia> (and don't do it too often or the release managers may not reroll)
[05:02] <StevenK> Or the release managers might sharpen weapons while re-rolling
[05:02] <persia> That too :)
[05:02]  * Hobbsee sharpens her Long Pointy Stick of DOOM!!!!!!!!!!!!!!!™
[05:03] <Kamping_Kaiser> ah oh
[05:03] <Kamping_Kaiser> :)
[05:23] <TheMuso> How often does ddebs.ubuntu.com get updated with dbgsym packages?
[05:26] <TheMuso> nvm my local screw up here
[06:42] <slangasek> Tonio_: hrm; why does "libk3b4" contain libk3b.so.6?
[06:43] <l3ftm1n0r> how do packages get included into the synaptic package manager? like how is it decided that a particular package needs to be there in the online repositories
[06:50] <dholbach> good morning
[06:52] <LaserJock> slangasek: I just uploaded edubuntu-artwork. Due to a miscommunication pitti removed the entire source package instead of just the edubuntu-artwork-usplash .deb so it's going to land in NEW :(
[06:54] <persia> l3ftm1n0r, Essentially, a developer uploads it.  See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for more information.
[06:59] <l3ftm1n0r> persia, thanks
[07:00] <l3ftm1n0r> persia, the reason i asked was that some packages for ubuntu arent on the synaptic but are available on the developers site ( case in point frostwire and limewire deb packages)
[07:14] <LaserJock> l3ftm1n0r: often times those sorts of packages are not in Ubuntu for license/patent reasons
[07:16] <l3ftm1n0r> LaserJock, ok. but i guess frostwire is os?
[07:19] <LaserJock> l3ftm1n0r: I think there were still some problems with it, I can't remember for sure though
[07:20] <l3ftm1n0r> LaserJock, maybe the whole jacking off the Ui of limewire :P
[07:33] <directhex> slangasek, to avoid going through binary NEW?
[07:50] <KaiL> damn, we need a fresh pidgin once again :/
[07:51] <KaiL> 2.5.5 works ;)
[07:51] <pitti> Good morning
[07:51] <pitti> calc: pong
[07:52] <KaiL> also good morning from here ;)
[07:52] <pitti> LaserJock: oh, sorry; I thought you entirely wanted to drop it
[07:52] <LaserJock> pitti: no, we have other artwork (gdm, FF homepage, etc.) that we still keep
[07:52] <LaserJock> it's all in the same source
[07:53] <LaserJock> unlike ubuntu I think which has separate source packages
[07:53] <LaserJock> pitti: no harm done though, we got it back :-)
[08:27] <mvo> thanks slangasek
[08:35] <tkamppeter> pitti, hi
[08:36] <pitti> hey tkamppeter, good morning
[08:48] <doko> james_w: could you upload the patch for python-crypto? I'm still in Hamburg
[08:49] <dholbach> doko: james_w is in .au :)
[08:49] <doko> ahh
[08:49] <doko> he was awake 1h ago :)
[08:50] <james_w> doko: I would have if it wasn't in main :-)
[08:50] <dholbach> doko: and james_w is not in core-dev :)
[08:50] <doko> aha ...
[08:50] <doko> ok, will do tomorrow
[08:50] <james_w> thanks
[08:51] <dholbach> totally unjustified in my opinion, but looks like James is working on it: https://wiki.ubuntu.com/JamesWestby/CoreDevApplication :-)
[08:51]  * pitti puts up the "James for core-dev!" sign
[08:52] <dholbach> pitti: you can speed up the process by adding your endorsement to the wiki page :)
[08:52]  * dholbach hugs pitti, james_w and doko
[08:52]  * pitti hugs dholback
[08:52]  * james_w hugs dholbach 
[08:57] <ara> doko, don't you hug anybody?
[09:00]  * seb128 hugs dholbach
[09:01]  * dholbach hugs seb128 back
[09:01]  * dholbach hugs ara too
[09:01]  * ara hugs dholbach :D
[09:05]  * juanje likes hugs as well and hugs dholbach :-P
[09:05]  * dholbach hugs juanje
[09:06] <dholbach> juanje: (-: ¡hola! ¿como estas? :-)
[09:07] <juanje> dholbach: fine, trying to do so many things at the same time... but I like to come to this channel because is so full of love :-D hehe
[09:09] <dholbach> juanje: so how's guadalinex coming together?
[09:09] <juanje> dholbach: I post it some things we've done in Guadalinex (btw, you are there :-P) and I'm working now in some i18n stuff, some documentation in Spanish for our collaborators and a bit on Ubiquity and casper
[09:10] <dholbach> juanje: are you in touch with the ubuntu installer folks for ubiquity and casper?
[09:10] <juanje> dholbach: I'm still have some things I don't know well how to work with in Launchpad, but I'll try step by step...
[09:11] <juanje> dholbach: no much for now, just about some missing strings for translations, but I planning to do for some stuff.
[09:11] <dholbach> juanje: just ask :)
[09:12] <juanje> dholbach: but actually we did a kind of wrapper for the frontend so we don't need to touch so much by now the Installer
[09:13] <juanje> dholbach: anyway, I was wondering if is still possible to touch things there (ie. in casper)
[09:13] <dholbach> juanje: evand and cjwatson might be good people to judge if it can go into Jaunty or if it should wait
[09:14] <juanje> dholbach: yeah, I guessed so, I was thinking to ask them today or tomorrow (before it be too late) about it
[09:16] <juanje> dholbach: but I like to create branches with solutions (when I know about it) before put a bug a bug or bother someone
[09:17] <juanje> dholbach: maybe I should ask first, i don't know....
[09:17] <dholbach> juanje: best to just ask quickly :)
[09:17] <juanje> dholbach:  yeah, you right ;-)
[09:33] <Tonio_> slangasek: concerning k3b that's for historical reasons... previous version was libk3b3 and contained libk3b.so.5, same for the one before etc...
[09:34] <directhex> yay for historical raisins
[09:34] <Tonio_> slangasek: I prefered not to change the naming schema, still debian will use that one to (they started to package it) in order to remain sync
[09:35] <Tonio_> slangasek: also, that upload was targetted to my ppa, shouldn't have reached the archives... we're currently testing it and I'll it reviewed before upload
[09:35] <Mirv> mvo: great news, the new libcompizconfig does, like I suspected, take ca. 4-5 seconds away from GNOME login. Keybuk will be happy probably as well, if he was the one doing boot time improvements.
[09:35] <Tonio_> slangasek: I've reuploaded back the kde3 version for the moment...
[09:35] <tkamppeter> pitti, hi
[09:35] <pitti> hey tkamppeter
[09:36] <mvo> Mirv: excellent! thanks for confirming this :)
[09:37] <Tonio_> directhex: to say it differently, I prefer to stay sync with debian naming convention on that package, and I don't have the all history behind it, it's just the way it is for long now...
[09:43] <Tonio_> slangasek: hum, just looked again, k3b-kde3 had libk3bdevice.so.5 and libk3b.so.3 in fact...
[09:44] <Tonio_> slangasek: now it's been sync to be all .so.6.... so maybe I should fix to libk3b6, you're right
[09:46] <Tonio_> slangasek: but I have to see with debian since afaik, the maintainer is using 4 too...
[09:52] <gaspa> dholbach, james_w: nbs and edos up again (and sorry for the long delay...)
[09:52] <gaspa> dholbach: i'm updating harvest-data to point to the right urls.
[09:54]  * dholbach hugs gaspa
[09:54] <dholbach> awesome
[09:55] <gaspa> dholbach: :)
[09:55]  * dholbach hugs gaspa
[09:55] <dholbach> awesome :-)
[10:07] <Mirv> Keybuk: hi. the new libcompizconfig should do something visible to your grub -> desktop bootcharts :) in the case of warm login the difference is huge, since compiz was the only thing that prevented warm login (no disk access needed) from being ca. 3s
[10:08] <Keybuk> Mirv: yes, I know, mvo and I have been discussing it for a while
[10:08] <Mirv> Keybuk: ok.
[10:15] <cjwatson> slangasek: I uploaded base-installer to fix bug 340308
[10:16] <cjwatson> ubiquity ought to see an upload too
[10:22] <pitti> doko: with pycentral, how can I tell XS-Python-Version: to only use python >= 2.5?
[10:22] <pitti> doko: or do I need to use pysupport for that?
[10:23] <Keybuk> pitti: 2.5-
[10:23] <pitti> doko: debian/pyversions is already 2.5-, but it still tries to compile for 2.4, which fails
[10:24] <pitti> Keybuk: ah, indeed; that's not documented on http://wiki.debian.org/DebianPython/NewPolicy
[10:24] <pitti> Keybuk: thanks
[10:25] <Keybuk> though I had endless problems with pycentral last night, and switched to pysupport
[10:25] <Keybuk> I had lots of problems with that too, but at least they weren't endless ;)
[10:25] <pitti> pyversions: error parsing Python-Version attribute
[10:25] <pitti> it doesn't seem to like this very much
[10:31] <pitti> Keybuk: I give up, and switch to pysupport, too, I think
[10:33] <geser> pitti: try ">= 2.5" for XS-Python-Version (it's mentioned on the wiki page and pyversions seems to like it too)
[10:33] <pitti> aah
[10:41] <cjwatson> slangasek: ok, ubiquity and casper (for a slight security problem) uploaded now too
[10:50] <cjwatson> Keybuk: could you look at bug 340188? it has a udev debug log now, although the problem went away upon cranking up the log level
[10:51] <Keybuk> cjwatson: I have too much else to do right now, sorry
[10:51] <cjwatson> Keybuk: this is critical for alpha-6 - can I have some advice at least?
[10:51] <Keybuk> what's the problem?
[10:52] <cjwatson> Keybuk: recurrence of the partitioning races we saw in alpha-5
[10:52] <cjwatson> BLKPG_DEL_PARTITION* then BLKPG_ADD_PARTITION says busy
[10:52] <Keybuk> meh
[10:52] <cjwatson> I've had multiple reports
[10:52] <Keybuk> are there change events i nvolved?
[10:52] <cjwatson> yes
[10:52] <Keybuk> then vol_id or something is probably running on the partition
[10:53] <Keybuk> I had a random thought
[10:53] <cjwatson> I asked the reporter to add a udevadm settle before we tell parted_server to commit, and that didn't help
[10:53] <Keybuk> why do we even have those rules in udev in the installer?
[10:53] <cjwatson> libparted *does* open devices read-write
[10:53] <Keybuk> do you use /dev/disk/by-uuid at all?
[10:53] <Keybuk> or udevinfo ?
[10:53] <Keybuk> why does libparted open devices at all?
[10:53] <cjwatson> err, it kind of has to write to them sometimes
[10:54] <cjwatson> I don't think we use /dev/disk/by-uuid/
[10:55] <cjwatson> I was wondering if adding system("udevadm settle") after the BLKPG_DEL_PARTITION calls might be a good idea
[10:55] <Keybuk> though I guess postinst's and stuff might
[10:55] <Keybuk> settle won't help here
[10:55] <Keybuk> since it won't want for the inotify event
[10:55] <Keybuk> if libparted closes a device, at some point later udev will check the device for changes
[10:56] <cjwatson> oof. we really need a way to make that synchronous
[10:57] <cjwatson> Keybuk: I've had scattered previous reports suggesting that this may happen in ubiquity too, where it isn't so easy to just strip stuff out of the udeb
[10:57] <KaiL> ...is there a bug about misspositioned window decoration known, or is my local config screwn up?
[11:01] <cjwatson> basically, this sounds as though the problem is that if you open a device read-write and close it, then at some random point later udev will open it and fiddle with it, and you have absolutely no way to control when
[11:01] <Keybuk> right
[11:01] <Keybuk> because udev is checking to see what you changed
[11:01] <cjwatson> I have a really hard time seeing how this could possibly be fixed anywhere other than udev
[11:02] <Keybuk> sure, don't open block devices for writing unless you intend to write to them?
[11:02] <Keybuk> I don't see why libparted is doing that if it's about to remove the partition
[11:03] <cjwatson> it's doing it at some previous point for something else, I imagine, and it's just outracing udev
[11:03] <cjwatson> why can't udev also check that the inotify queue is empty when you say udevadm settle?
[11:03] <Keybuk> because there's no such thing
[11:04] <Keybuk> where are you adding the settle call?
[11:04] <cjwatson> it could at least check for pending inotify evenets!
[11:04] <cjwatson> events
[11:04] <Keybuk> if it's also affecting ubiquity, it would need to be in parted itself, surely?
[11:04] <Keybuk> cjwatson: it doesn't work that way
[11:04] <cjwatson> I added it in partman-base right before it tells parted_server to COMMIT
[11:05] <cjwatson> that code is common to d-i and ubiquity
[11:05] <cjwatson> Keybuk: why doesn't it work that way?
[11:05] <cjwatson> when you close the fd, the kernel writes to inotify watchers, does it not?
[11:06] <Keybuk> when you run udevadm settle, you don't have access to udevd's inotify file descriptor
[11:06] <Keybuk> obviously
[11:07] <cjwatson> Keybuk: can udevadm not communicate with udevd?
[11:07] <Keybuk> that would be a hell of a lot of overhead
[11:08] <cjwatson> better than the sleep 5 I'm going to have to insert otherwise
[11:08] <Keybuk> since you're not even giving me a chance to think about this, go with the sleep 5 for now
[11:09] <cjwatson> I've no problem at all with you thinking about this :-) It's just that you're rejecting everything I come up with out of hand and this is making me (I think understandably) rather frustrated.
[11:09] <Keybuk> I told you, I'm in the middle of other things right now
[11:10] <Keybuk> hassling me about a bug when I've already said I'm busy is not exactly going to elicit the most helpful responses from me
[11:10] <cjwatson> well, I'm sorry that things are urgent
[11:10] <Keybuk> everything's urgent
[11:10] <Keybuk> we're at that point of the release cycle
[11:10] <cjwatson> I've lost several days fighting with this
[11:12] <Keybuk> I assume that this also affects non-LVM cases?
[11:13] <cjwatson> yes
[11:13] <Keybuk> what syscall actually returns an error?
[11:13] <cjwatson> BTW, if the answer is "go away for several hours and I'll look later today" or something, that would be fine - you just didn't give me any idea of timescale
[11:15] <cjwatson> ioctl(fd, BLKPG, {BLKPG_ADD_PARTITION, 0, datalen, data})
[11:15] <Keybuk> I'm trying to understand where you're thinking of sticking the settle call
[11:15] <Keybuk> I assume you're looking through the libparted code
[11:15] <Keybuk> is there an obvious point to do so?
[11:15] <Keybuk> ie. you can see it opening block devices, closing them again, etc.
[11:17] <Keybuk> it doesn't make any sense to me that it's the BLKPG_ADD_PARTITION that fails with "in use"
[11:17] <cjwatson> note that errors from BLKPG_DEL_PARTITION are not checked
[11:17] <cjwatson> I expect that it's failing too
[11:17] <Keybuk> I could understand if it were the BLKPG_DEL_PARTITION :)
[11:17] <sladen> KaiL: file it, I had somebody show me that yesterday (and also asked them to file it)
[11:17] <Keybuk> isn't that a bit error-prone?
[11:18] <cjwatson> well, you'll always get an error from BLKPG_ADD_PARTITION if BLKPG_DEL_PARTITION failed, so it doesn't matter except in that you get slightly more confusing error messages
[11:18] <Keybuk> where were you thinking of putting the settle?
[11:18] <cjwatson> the point where I asked a user affected by this to add udevadm settle is outside libparted, but effectively immediately before the first BLKPG_DEL_PARTITION
[11:19] <cjwatson> thinking about it, there's of course no point in calling settle after BLKPG_DEL_PARTITION
[11:19] <Keybuk> indeed
[11:19] <Keybuk> I'm assuming it's the partition deletion that's actually failing
[11:19] <Keybuk> ie. you're doing
[11:19] <cjwatson> yes, I think so
[11:19] <Keybuk>  <change block device>
[11:19] <Keybuk>  <delete partition>
[11:19] <Keybuk>  <add new partition>
[11:19] <Keybuk> and the delete is failing, because changing the block device causes it to be opened
[11:19] <cjwatson> right
[11:20] <cjwatson> so I can probably fudge things such that the change goes away
[11:20] <cjwatson> but I'm concerned that there will be cases where I can't, simply because it's a race
[11:20] <Keybuk> sure, so there's a few obvious solutions
[11:20] <Keybuk> firstly is to try and eliminate the change
[11:20] <Keybuk> the second is to fix settle so that you can call it between the change and delete and have it actually wait
[11:21] <cjwatson> or perhaps something based around udevadm control (I see stuff like --stop-exec-queue?)
[11:21] <Keybuk> right, that's another option
[11:21] <Keybuk> also you can just do evil things
[11:21] <Keybuk> before the change, do
[11:21] <Keybuk>   echo -n remove > /sys/block/*/*/uevent ;)
[11:21] <Keybuk> (filling in the *s)
[11:21] <cjwatson> heh
[11:22] <Keybuk> you'll lose the device node though
[11:22] <cjwatson> I suspect the change is actually fairly unrelated (i.e. at that point I don't yet know I'm going to remove the device)
[11:22] <Keybuk> right
[11:22] <Keybuk> fixing settle seems the right approach
[11:22] <cjwatson> but ok, that gives me enough to work with
[11:22] <cjwatson> thanks a lot
[11:22] <Keybuk> the problem there is that udevd receives the inotify watch
[11:22] <Keybuk> but doesn't immediately process it
[11:22] <Keybuk> instead it asks the kernel to send a change event for that device
[11:22] <Keybuk> so there's a gap between the two
[11:23] <Keybuk> I'm thinking that the right solution there is to add a second line to /dev/.udev/uevent_seqnum when inotify events are received
[11:23] <Keybuk> and clear that second line when uevents are received
[11:23] <Keybuk> and have udevsettle wait unconditionally if that second line exists
[11:24] <Keybuk> that's still not perfect though
[11:24] <Keybuk> since you don't know that there aren't pending inotify events that udevd hasn't picked up yet
[11:24] <cjwatson> you'd have to make sure that udevd picks up inotify events before you do the rest of the settle
[11:24] <cjwatson> that wouldn't be atomic though :-/
[11:25] <Keybuk> I have a thought
[11:26] <Keybuk> udevadm control obviously sends messages to udev
[11:26] <cjwatson> at the moment, it looks like udevd might actually synthesise the change event after it has received a remove event for the same device, in some cases
[11:26] <Keybuk> cjwatson: that shouldn't happen
[11:27] <Keybuk> no idea whether there's a sanity check on it though <g>
[11:31] <Keybuk> this is actually a fun problem <g>
[11:31] <Keybuk> a test case should be easy to do
[11:31] <Keybuk> have a udev rule that sleeps for a minute on change
[11:31] <Keybuk> and try removing a partition during that minute
[11:32] <cjwatson> oh, good idea
[11:32] <cjwatson> ok, will do that
[11:34] <Keybuk> right, need to download a couple of dailies now for these HPs
[11:34] <Keybuk> I'm all yours for a bit ;)
[11:34] <Keybuk> this USB key has moblin on it ... *screams a war cry and deletes it* :p
[11:35] <StevenK> Hah
[11:36] <KaiL> sladen, bug 340423; I hope that information helps ;)
[11:38] <Keybuk> cjwatson: obv. you need to "open" the block device for that minute
[11:38] <cjwatson> I was just about to say the exact same thing :-)
[11:38] <Keybuk> ie. RUN+="/bin/sh -c 'sleep 60 < %k'"
[11:38] <cjwatson> just setting that up now
[11:38] <Keybuk> sorry, you know how it is
[11:39] <Keybuk> certain debugging patterns are so deep-rooted in your brain you forget that other people might now know them enough to know which one you mean
[11:39] <ogra> cjwatson, do you plan a d-i upload before A6 (i see no changes in bzr)
[11:39]  * ogra is wondering if the seed changes will end up in the slug firmware image without rebuild 
[11:40] <cjwatson> ogra: seed changes shouldn't need a d-i upload
[11:40] <cjwatson> d-i uploads are just for the initrd bit
[11:40] <ogra> right, but the firmware is a bit special
[11:40] <Keybuk> err $root/$name not %k ;p
[11:41] <ogra> i wasnt sure it pulls in flash-kernel automatically
[11:41] <Keybuk> well, you certainly can't delete a partition if anything has it open
[11:41] <ogra> but i trust you if you say it is so :)
[11:41] <Keybuk> BLKPG ioctl returns -EBUSY
[11:42] <cjwatson> ogra: it should just require it to be priority standard; let me check
[11:43] <ogra> prio should be fine, i just wasnt sure the info ends up in the initrd without rebiuld, since its so oddly merged into a firmware image
[11:44] <cjwatson> yes, it's priority standrd
[11:44] <cjwatson> a
[11:44] <cjwatson> ogra: well, the point is that this isn't information that goes in the initrd at all
[11:44] <cjwatson> ogra: remind me which d-i image this is?
[11:45] <cjwatson> ixp4xx/netboot?
[11:45] <ogra> yep
[11:45] <ogra> di-nslu2.bin
[11:45] <cjwatson> ogra: the way the initrd image is packed is essentially not relevant here
[11:45] <ogra> ok
[11:46] <cjwatson> ogra: what happens is that the initrd contains code to bring up the network and retrieve package lists from it (net-retriever)
[11:46] <ogra> just wanted to be sure it pulls the info late enough and doesnt need it inside
[11:46] <ogra> right
[11:46] <cjwatson> ogra: and anna then figures out from the information delivered by net-retriever which packages it needs to install
[11:46] <cjwatson> ogra: so as long as it can bring up the network, it'll be fine
[11:47] <cjwatson> it'll syslog what it installs, though, so you can check without having to wait for the end of the install
[11:47] <cjwatson> or you can look in /var/lib/dpkg/status in the running installer after it installs additional components
[11:47] <ogra> right, but it takes over 8h to do one install so i want to exclude all surprises as early as possible :)
[11:48] <ogra> its about 3h to get to net-retriever
[11:51] <cjwatson> fair enough :-)
[11:51] <cjwatson> Keybuk: what I'm seeing here is that settle waits for the change events; presumably it was lucky enough to happen to run after udevd processed the inotifies
[11:51] <cjwatson> so the race is actually between inotify and udevadm settle
[11:52] <Keybuk> cjwatson: right
[11:52] <Keybuk> well
[11:52] <Keybuk> the race is between the close() and the settle
[11:52] <Keybuk> if you do them quick enough, udev may not have received the inotify event or sent the change event
[11:54] <cjwatson> yeah, I think I might nobble udevd to be slower about processing the inotify or something
[11:54] <cjwatson> for the purposes of reproducing this
[12:00]  * cjwatson hacks up 'udevadm control --slow-inotify'
[12:13] <sivang> hi all
[12:13]  * lamont looks around for a blkid-clueful person
[12:13] <lamont> sivang: howdy
[12:13] <sivang> how is everybody?
[12:13] <Keybuk> lamont: blkid or volid?
[12:13] <sivang> lamont: hey there, how are you ?
[12:13]  * sivang dicts the words in urban-dict
[12:14] <Keybuk> lamont: or blkid"-ng"
[12:14] <lamont> Keybuk: specifically, why fsck -A decides to try to fsck /dev/sda2 instead of /dev/md1, which appears to be the direct result of blkid_get_devname()
[12:14] <lamont> hardy
[12:14] <Keybuk> lamont: bad information in /etc/blkid.tab usually
[12:14] <Keybuk> though why is your fsck calling blkid_get_devname() ?  we patch that in Ubuntu to use vol_id instead
[12:16] <lamont> Keybuk: really?
[12:16] <lamont> 1.40.8-2ubuntu2 seems to, um, not
[12:16] <Keybuk> oh, e2fsprogs fsck or util-linux-ng fsck? :p
[12:16] <sivang> hey Keybuk
[12:16] <tkamppeter> pitti, did you write the apport hook for printing? It has a problem. See bug 340298. It says "CupsErrorLog: Error: [Errno 13] Permission denied: '/var/log/cups/error_log'". You, or whoever has written the apport hook seem to have forgotten that the access to this file is restricted.
[12:17] <lamont> Keybuk: e2fsprogs fsck is the one that lands in sb
[12:17] <lamont> sbin
[12:17] <lamont> and hence the one that the system uses
[12:17] <pitti> tkamppeter: yes, that can't work for reporting bugs
[12:17] <Keybuk> lamont: oh, right, that one might still use blkid ;)
[12:17] <Keybuk> it's all a bit of a mess really
[12:17] <Keybuk> but yes, likely wrong information in /etc/blkid.tab then
[12:17] <pitti> tkamppeter: but we should eventually fix the log file to be readable by adm group, then it'll work
[12:18] <Keybuk> probably blkid utterly failing to realise that /dev/sda2 is part of a RAID-1 and it should use /dev/md1 instead
[12:18] <cjwatson> tkamppeter: is bug 83957 something you can look at? I'm not sure who deals with scanners ...
[12:18] <Keybuk> :> /etc/blkid.tab
[12:18] <lamont> yeah - especially when one has a non-root RAID1 array, and mdadm grabs it before init.d/checkfs.sh runs, and then you get a ZOMG IZ INUSE HALP
[12:18] <lamont> does it auto-regen later just to hurt me?
[12:18] <tkamppeter> pitt, can you do that?
[12:18] <Keybuk> lamont: it writes to it every time it thinks it can
[12:18] <Keybuk> this is all fixed in util-linux-ng's new blkid
[12:19] <tkamppeter> cjwatson, I do not deal with scanners. Only the scannner driver of HPLIP is under the packages which I maintain. See debian/changelog of the SANE package to find the right person.
[12:20] <cjwatson> yeah, sane is a bit of a village bike in Ubuntu by the looks of things
[12:20] <cjwatson> pitti: ^- (83957)/
[12:20] <cjwatson> ?
[12:21] <Keybuk> cjwatson: so, thinking about this
[12:21] <Keybuk> will a super-settle really be the right way to fix this?
[12:21] <lamont> Keybuk: so which package gets the bug that the hardy system FAILS TO BOOT if there is a non-root RAID1 array with a filesystem on it?
[12:21] <Keybuk> ie. make it mean "udev is not about to do anything else unless somebody else tells it to"
[12:21] <Keybuk> lamont: mdadm
[12:22] <Keybuk> lamont: though if it's caused by bad data in blkid.tab, it's pretty likely you caused the bug by accident somehow
[12:22] <Keybuk> ie. even by just running a test suite or something
[12:22] <lamont> it's possibly more than that :-)
[12:22] <pitti> cjwatson: will have a look
[12:22] <cjwatson> ta
[12:23] <lamont> palo-installer kinda makes assumptions about where /boot lives, and um, /dev/mdN isn't one of the options.  And then you get out a hammer
[12:24] <lamont> and deleting the ext* entries for /dev/sd* from blkid.tab fix0rs things.  go figure
[12:24] <Keybuk> lamont: bug on palo-installer? :p
[12:26] <lamont> Keybuk: yeah
[12:26] <cjwatson> Keybuk: that's basically what I had expected it to do, although I now realise that my expectation was a bit simplistic based on current code
[12:26] <lamont> Keybuk: $beverage+=1
[12:27] <Keybuk> cjwatson: basically we need something that says "if inotify is pending, process it" and, most importantly, replies after the processing is done
[12:27] <Keybuk> you can guarantee that the kernel seqnum has increased once the inotify write has been finished
[12:27] <Keybuk> any control message will wake up udev's main loop
[12:27] <cjwatson> I was wondering whether the performance of udevadm settle was especially important
[12:28] <Keybuk> well, reasonably
[12:28] <cjwatson> would it matter if it just always talked to udevd?
[12:28] <Keybuk> ie. it's not a place for sleep 1s
[12:28] <Keybuk> cjwatson: the problem there is complexity
[12:28] <cjwatson> oh, sure, I meant within reasonable bounds
[12:28] <Keybuk> ie. there really isn't a useful local 2-way message socket in UNIX :p
[12:28] <cjwatson> hmm, granted
[12:29] <Keybuk> I have an idea though
[12:30] <bigon> any buildd admin around? could it be possible to remove python2.5-minimal from the buildd as it is not needed by any other pkgs?
[12:30] <pitti> bigon: how do you mean, from the buildd?
[12:30] <pitti> bigon: from the archive?
[12:31] <persia> Or from the base buildd chroot?
[12:31] <pitti> bigon: that needs to be done in the python2.5 source first
[12:31] <bigon> yeah from the buildd chroot
[12:33] <bigon> The following packages were automatically installed and are no longer required:  python2.5-minimal << http://launchpadlibrarian.net/23697414/buildlog_ubuntu-jaunty-i386.telepathy-gabble_0.7.22-1_FAILEDTOBUILD.txt.gz
[12:33] <persia> That needs more than just a buildd admin.
[12:34] <persia> In all honesty, it's unlikely to be dropped until the buildd chroots are recreated for karmic.
[12:34] <cjwatson> buildd chroots get refreshed every now and then for performance reasons anyway
[12:34] <cjwatson> infinity: ^-
[12:41] <persia> Is there any schedule for that, or just on an as-one-gets-to-it basis?
[12:48] <Keybuk> cjwatson: http://people.ubuntu.com/~scott/udevd-settle.patch
[12:55] <Keybuk> how I've missed random X server crashes
[12:56] <directhex> they're fun! i get them on my laptop if i play a game then quit it
[12:57] <directhex> i think it's the x server telling nme to keep playing
[12:57] <pitti> directhex: s/keep/stop/?
[12:57] <directhex> pitti, nah, X only dies when i quit the game
[12:58] <pitti> lol
[12:59] <mvo> directhex: nvidia?
[12:59] <directhex> mvo, intel
[13:00] <cjwatson> Keybuk: udevd-settle> coo, thanks, will give that a try
[13:00] <mvo> directhex: interessting, I see something similar with nvidia
[13:00] <cjwatson> Keybuk: can I upload that if I get people to test that it works?
[13:00] <Keybuk> cjwatson: I'd rather do the upload since it's a patch in git
[13:01] <Keybuk> and thus needs git -> bzr -> ubuntu repo massaging
[13:01]  * cjwatson nodes
[13:01] <Keybuk> otherwise I'll go nuts when Kay merges it
[13:01] <cjwatson> nods, even
[13:10] <Keybuk> cjwatson: uploaded to my PPA if people want to test it
[13:11] <cjwatson> I'll kill the local build I had in progress then
[13:11] <cjwatson> ... no I won't, it's done
[13:11] <mnabil> guys, how can i download (only) package and their dependency in a certain directory using apt ?
[13:14] <directhex> mnabil, using apt-get install --download-only?
[13:15] <directhex> and -o Dir::Cache::Archives=/tmp/foobor/
[13:15] <mnabil> directhex, actually this didn't work when i had the packages already installed
[13:15] <Keybuk> mnabil: did you read "man apt-get" ?
[13:28] <Canaman> hello people. I'm trying to develop a gtk interface with glade. When i created a new window, add a frame then add a label, the label uses all frame area, i can't set it to be small than the frame.
[13:32] <cr3> should /usr/lib/python2.6/site-packages be a symlink to /usr/lib/python2.6/dist-packages?
[13:34] <slytherin> Canaman: wrong channel.
[13:34] <ScottK> cr3: No.  /usr/lib/python2.6/site-packages should not exist in a Debianized package.
[13:35] <ScottK> /usr/lib/python2.6/site-packages is for things not installed via the packaging system.
[13:36] <cr3> ScottK: was that the same in previous releases of ubuntu?
[13:36] <Kamping_Kaiser> Is there a page that documents what repositories have to be enabled for a package to build? currently linux-image-{386,generic} in -security require -updates to be enabled. This seems a bit wrong to me, hence i'm asking
[13:36] <ScottK> cr3: No.  It's new with Python 2.6.
[13:36] <cr3> ScottK: is there a way to keep a single package compatible across releases then?
[13:36] <Kamping_Kaiser> (IIRC an ubuntu-mozilla person rebuilt firefox for us so it no longer depended on -updates in this exact situation)
[13:37] <ScottK> cr3: If it has a distutils setup.py using install-layout=deb should put things in the right place for 2.5 (site-packages) and 2.6 (dist-packages).
[13:39] <cr3> ScottK: so the upstream setup.py will be compatible, but the resulting package needs to be built separately for each release
[13:39] <cr3> ScottK: by the way, if I have some source files which go in one package and other source files in another package, all under the same project, how can I prevent my debian/*.install files from referring explicitly to site-packages or dist-packages?
[13:39] <ScottK> cr3: I'm not sure you'll have to.  i haven't tested it, but I think older releases will just ignore the unknown option.
[13:41] <cr3> ScottK: aha! I know, I simply use /usr/lib/python*/*-packages/...
[13:41] <ScottK> cr3: Yes.
[13:41] <ScottK> You type faster than I do.
[13:42] <cr3> ScottK: what I meant before that *-packages is that the resulting package I build on jaunty could only be installed on jaunty, not on previous releases. however, the same source code could be used to build packages for all releases probably because the unknown option will be ignored as you said
[13:44] <ScottK> cr3: Yes.  That's generally true anyway as there will be binary version dependencies generated that would prevent something built on Jaunty installing in an earlier release.
[13:46] <cr3> ScottK: that actually solves another unrelated dilemna I had yesterday, thanks man!
[13:46] <ScottK> yw
[13:56] <mnabil> directhex, i got this ! E: Archive directory /home/mnabil/home2/testing/partial is missing  and no package in there !
[13:57] <directhex> mnabil, so create it
[14:02] <mnabil> directhex, k, thanks
[14:11] <cr3> ScottK: fyi, --install-layout is not being ignored gracefully: error: option --install-layout not recognized
[14:11] <ScottK> cr3: OK.  Thanks for letting me know.  That's unfortunate.
[14:12] <cr3> ScottK: your assumption was good though :)
[14:40] <pitti> cjwatson, evand: is ubiquity meant to work for installing on an USB hard disk?
[14:43] <evand> pitti: there's no reason it shouldn't work, provided ubiquity is running from the live CD
[14:43] <pitti> evand: okay; I filed a bug about it, but wondered whether it's even meant to work
[14:43] <pitti> evand: grub-install completely falls over :(
[14:44] <cr3> ScottK: I've had to derive the distutils.install.install class in order to properly ignore the --install-layout option, this is really sad :(
[14:44] <pitti> I admit I have never fully understand how to make grub-install work what I want, but I wasn't able at all to install grub on the non-primary hard disk
[14:47] <evand> pitti: yikes, ok
[14:47] <pitti> evand: bug 340498 FYI
[14:47] <mathiaz> dendrobates: are you still working on bug 121337?
[14:48] <evand> indeed, already there :)
[14:48] <dendrobates> mathiaz: no
[14:54] <kirkland> lool: hi there, are you still seeing https://bugs.edge.launchpad.net/ubuntu/+source/kvm/+bug/290680 in Jaunty?
[15:11] <lool> kirkland: I'm not at home (oxford sprint), so not in front of my kvms; I'll check when I'm back home
[15:11] <lool> kirkland: thanks a lot for working on it
[15:12] <kirkland> lool: cool, no problem, i'll leave it 'incomplete' for now
[15:39] <cjwatson> Keybuk: I think you need 'if (settle_pid > 0)' in your patch, rather than just 'if (settle_pid)' (which matches -1 ...)
[15:39] <Keybuk> oh yeah
[15:39] <cjwatson> Keybuk: sending SIGUSR1 to init breaks rather terminally :)
[15:39] <Keybuk> really?
[15:39] <Keybuk> it shouldn't do anything
[15:39] <cjwatson> busybox init
[15:39] <Keybuk> busybox init handles USR1 ?
[15:40] <cjwatson> (actually, maybe >= 0 to match handle_ctrl_msg)
[15:40] <Keybuk> and since kill (-1, ...) doesn't send to init ... :p
[15:40] <Keybuk> but yes, it's wrong
[15:41] <cjwatson> Keybuk: yeah, it maps it to halt
[15:41] <cjwatson> observed behaviour is:
[15:41] <cjwatson> User defined signal 1
[15:42] <cjwatson> Kernel panic - not syncing: Attempting to kill init!
[15:42] <cjwatson> anyway, the fix is obvious
[15:42] <Keybuk> sure
[15:42] <Keybuk> but since kill (-1, ...) doesn't send to init ... :p
[15:43] <pitti> Keybuk: out of curiosity, how's current jaunty booting on your mini9 right now?
[15:43] <Keybuk> pitti: FAST
[15:43] <Keybuk> http://people.ubuntu.com/~scott/black-jaunty-20090310-4_cropped.png
[15:44] <pitti> wow
[15:44] <ion_> Nice
[15:44] <pitti> Keybuk: the red line is the limit, or when the desktop is "usable"?
[15:45] <primes2h> apw: Keybuk: Thanks for fixing floppy bug, you made happy a lot of people. :-)
[15:45] <Keybuk> pitti: when I consider it complete
[15:45] <Keybuk> pitti: I don't count nm-applet, that's the only bit to the right
[15:45] <Keybuk> the desktop is fully usable a few seconds before the line
[15:45] <pitti> that's awesome
[15:45] <apw> primes2h, i am amazed so may oeioke eve
[15:45] <apw>  
[15:45] <apw> even have one
[15:45] <apw> primes2h, i am amazed so many people even have one (even)
[15:46] <ion_> keybuk: Do you think we’ll get a HDD-enabled sreadahead for jaunty, btw?
[15:46] <pitti> Keybuk: ah, you are using sreadahead now; what kind of impact does it have for you?
[15:46] <Keybuk> pitti: on the mini9, it's totally worth it
[15:46] <Keybuk> ion_: dunno, got a patch ? :p
[15:46] <primes2h> apw: I know, there are country that still have it, and a lot of old pc have it as well...
[15:47] <Keybuk> cjwatson: gnargh, bzr fast-import and git reset are not friends :p
[15:47] <ion_> keybuk: Heh
[15:47] <apw> Keybuk, sounds like a world of pain
[15:48] <primes2h> apw: I don't have it on my laptop now as well, but I have some old pc (5-7 yo) in which it's present.
[15:48] <primes2h> s/now/new
[15:48] <primes2h> new laptop
[15:48] <Keybuk> apw: today I'm learning about git fetch
[15:48] <Keybuk> the hard way
[15:48] <apw> git fetch == bzr pull mostly
[15:49] <Keybuk> except without the changes to your branch, or the working tree
[15:49] <apw> git pull does the merge after which i guess is what you are expecting
[15:50] <slangasek> LaserJock: hmm, you know the NBS list generally gets taken care of semi-automatically by the archive admins?  No opportunity for miscommunication there :)
[15:50] <slangasek> mvo: sure... :)
[15:52] <slangasek> Tonio_: well, libk3b4 hasn't been approved into the Debian archive yet, so I wouldn't presume that it's going to get into Debian that way just because the maintainer is packaging it that way currently ;)
[15:53] <slangasek> cjwatson: ack, thanks for the fixes
[15:53] <Tonio_> slangasek: sure :) just that I wanted to stay sync with the debian upstream and sync the fix...
[15:54] <Tonio_> slangasek: but you're right, now that all libs have the same soname, there's no reason not to version the package according to this...
[15:54] <Tonio_> slangasek: anyway, that upload should have stay in my ppa, the packaging is currently in the work, unpolished...
[15:55] <slangasek> right :)
[15:56] <slangasek> I've rejected the binaries now, thanks
[15:56] <Tonio_> slangasek: sorry for the ppa in archives... dput can be dangerous sometimes...
[16:01] <cjwatson> Keybuk: ok, this at least boots now
[16:06] <Keybuk> cjwatson: "at least boots" ?:)
[16:07] <cjwatson> seems to complete partitioning successfully; I'll need to get the people who reported problems to test though
[16:08] <Keybuk> I uploaded a new one to the PPA that fixes the pid issue
[16:08] <cjwatson> Keybuk: any tests you want me to do here that would conclusively demonstrate that it fixes the race?
[16:10] <Keybuk> can't think of anything
[16:10] <Keybuk> did you try with the sleep rule for change?
[16:11] <pitti> seb128: hm, seems that python2.6-doc is no longer in devhelp any more :(
[16:11] <pitti> OMGkittensdie need documentation
[16:11] <cjwatson> Keybuk: I did, but that doesn't guarantee encountering the race; if udevd has already noticed the inotify and fired off the change event, then the old udevadm settle works fine
[16:11] <Keybuk> ah
[16:11] <cjwatson> it only breaks if you manage to get udevadm settle in before udevd notices the inotify
[16:11] <Keybuk> just trying it a few times I guess
[16:11] <Keybuk> short of adding a sleep into udevd itself
[16:11] <pitti> seb128: right, it lacks /usr/share/devhelp/
[16:11] <Keybuk> (which I've tested here)
[16:12] <cjwatson> if you've tested explicitly adding in a sleep, then I don't think I need to do anything more rigorous
[16:12] <cjwatson> beyond making sure that it's this race we're hitting and not a different one :)
[16:12] <Keybuk> right
[16:12] <cjwatson> I'm pushing a CD image with this up at the moment
[16:12] <Keybuk> we still could be fixing the wrong thing ;)
[16:29] <seb128> slangasek: would a gnome-session upload to not flood logs with debugging informations be ok to upload now?
[16:29] <slangasek> seb128: yes
[16:29] <seb128> slangasek: ok thanks
[17:05] <Keybuk> pitti: ya know
[17:05] <Keybuk> I really want to kill usplash
[17:05] <Keybuk> on the mini 9, usplash is visible for 6 seconds
[17:06] <Keybuk> and then a black screen with a mouse cursor, thanks to X's long startup time and compiz's even longer startup time, is visible for 12 seconds :p
[17:06] <jdong> sounds about right :)
[17:07] <jdong> why does compiz take several seconds to start up?
[17:07] <ogra> so kill X and compiz ... it takes longer than usplash :P
[17:19] <pitti> Keybuk: heh
[17:19] <pitti> Keybuk: see, I can enjoy it for about 50 seconds :)
[17:19] <kirkland> slangasek: server cd's are looking much smaller ;-)
[17:20] <slangasek> \o/
[17:20] <Nafallo> kirkland: removed screen-profiles? ;-)
[17:20]  * Nafallo ducks
[17:20] <jdong> haha
[17:20] <jdong> Nafallo: that only takes up SCREEN space :)
[17:21] <Keybuk> pitti: that's because we have the I/O problem of doom
[17:21] <Keybuk> tell apw all about it ;)
[17:21] <pitti> apw: I can has fast IO?
[17:21]  * pitti hugs apw
[17:22]  * apw sends a couple of red-cross io-parcels your way
[17:22]  * pitti bounces
[17:22] <Keybuk> apw: I do have a sad bug to report
[17:23] <apw> heh ?
[17:23] <Keybuk> apw: you know how I said that setting the kernel default scaling governor to ondemand was ok, and shouldn't affect boot performance
[17:23] <apw> yep ...
[17:23]  * Keybuk was wrnog
[17:23] <apw> ooops.  have we changed it yet?
[17:23] <kirkland> Nafallo: no way dude ;-)
[17:23] <Keybuk> no, I'm going to do some digging first
[17:24] <apw> ok.  that was my memory of the UDS conversation
[17:24] <Keybuk> I'm sure slangasek will not be my friend anymore if I ask you to upload a new kernel before alpha 6 :p
[17:26] <rtg> Keybuk: rumor has it you want to change the default CPU governor?
[17:28] <Keybuk> rtg: ;)
[17:29] <Keybuk> rtg: not sure of the best way to do deal with it yet
[17:29] <Keybuk> the default should be "ondemand"
[17:29] <Keybuk> but during boot, we want it to be "performance" after all
[17:29] <rtg> Keybuk: its just a config change
[17:30] <Keybuk> sure, but I'm wondering whether we shouldn't leave it at ondemand in the kernel
[17:30] <Keybuk> and temporarily set it to performance during the boot
[17:30] <Keybuk> before setting it back again
[17:30] <Keybuk> OR
[17:30] <Keybuk> whether that's just mad
[17:30] <Keybuk> and we should have it as performance in the kernel
[17:30] <Keybuk> and set it to ondemand at the end of the boot
[17:30] <Keybuk> what do you think?
[17:31] <Keybuk> one of those ideas was so bad it crashed x-chat
[17:31] <jdong> Keybuk: is there a huge power difference between performance and ondemand? Strangely I have been playing with that on Intel Core 2 laptop hardware and couldn't tell a big difference between the two...
[17:32] <Keybuk> jdong: booting on the mini 9 with ondemand = 35s
[17:32] <Keybuk> booting with performance = 25s
[17:32] <Keybuk> I consider this a big difference ;)
[17:32] <jdong> I meant power consumption difference
[17:32] <jdong> i.e. idle power draw with lowest clockrate vs highest
[17:32] <Keybuk> I'm not mjg59 ;)
[17:32] <Keybuk> he cares about power consumption
[17:33] <rtg> Keybuk: set it to performance on boot, then ondemand later.
[17:33] <slangasek> Keybuk: your isdnutils upload FTBFS with a libtool version error? :)
[17:33] <jdong> my anecdotal experience is that as long as the CPU is idle there's not a huge difference between the two settings, assuming your combined system draws more than like 8W on idle.
[17:33] <jdong> maybe it's a 200mW difference at best that I could measure with acpitool
[17:34] <EagleScreen> Hi all
[17:34] <slangasek> Keybuk: surely changing it twice is inferior to changing it once? :)
[17:34] <Keybuk> rtg: ok, well make that kernel change at your convenience ;)
[17:34] <Keybuk> slangasek: ?
[17:35] <Keybuk> pitti: hal has a cpufreq addon, right?
[17:35] <slangasek> Keybuk: leaving the default to ondemand and changing it back and forth from userspace, vs. having the kernel default come up with what we want it to be at boot, then changing it after
[17:35] <jdong> why can't we quirk it in initramfs or something to what we want?
[17:35] <pitti> Keybuk: yes
[17:35] <jdong> does it really hurt pre-initrd boot time that badly?
[17:35] <slangasek> Keybuk: sorry, I'm interleaving
[17:35] <pitti> Keybuk: I never looked what it does, though
[17:36] <Keybuk> pitti: what does that do?
[17:36] <Keybuk> pitti: it appears to be enabled here
[17:36]  * pitti RTFS
[17:36] <Keybuk> jdong: as slangasek almost said, why work around the kernel when you can change it? :p
[17:36] <EagleScreen> linux 2.6.28 in jaunty turns on Bluetooth adapter in my laptop during system boot and keep it on consuming battery power when it is not in use, in linux 2.6.27 in intrepid, Bluetooth was off until I pressed the Bluetooth key
[17:36] <jdong> Keybuk: well this is such a subtle point I think it'd be gracious to help those with custom-compiled kernels
[17:37] <jdong> Keybuk: I don't think an extra line in initramfs hurts anything; could be a complementary solution
[17:37] <Keybuk> jdong: ?!
[17:37] <Keybuk> those compiling custom kernels are free to use our config
[17:37] <Keybuk> or make up their own ;)
[17:37] <Keybuk> if they make up their own - we shouldn't override their selected default governor
[17:38] <jdong> Keybuk: well what I'm saying is, if I were looking at that option in make config, it wouldn't occur to me that a 30% difference in bootspeed can be incurred by choosing ondemand....
[17:38] <jdong> but I see what you mean too wrt. overriding the kernel
[17:39] <pitti> Keybuk: hm, puzzling; the entire addon just implements d-bus requests, but nothing in hal uses them
[17:39] <pitti> Keybuk: apparently it's meant for tools like GNOME's cpu freq applet to provide the implementing backend
[17:40] <pitti> Keybuk: or *should* it do something?
[17:40] <Keybuk> pitti: no, that's what it should do
[17:40] <Keybuk> was just making sure it didn't do anything else :p
[17:41] <pitti> Keybuk: well, it's a 35kB source file, but from a cursory inspection it's entirely passive
[17:41] <Keybuk> *nods*
[17:42] <Keybuk> I thought gnome-power-manager used to use it, but apparently not anymore
[17:42] <pitti> Keybuk: I didn't check that (used by g-p-m)
[17:42] <pitti> door bell, dinner
[17:42] <Keybuk>         Remove all the cpufreq code, as I keep being told I'm insane by Matthew.
[17:42] <pitti> lol
[17:43] <Keybuk>         See http://www.advogato.org/person/mjg59/diary.html?start=123 for rationale.
[17:44] <jdong> Keybuk: so reading that, again, is there any real point to using ondemand?
[17:44] <jdong> honestly here it even makes Firefox scrolling within Compiz noticeably more choppy for whatever reason
[17:45] <Keybuk> jdong: it allegedly saves power
[17:45] <Keybuk> of course, if your processor sucks at scaling, it won't help :p
[17:45] <jdong> well my poor man's testing using battery draw feedback doesn't really show much of a difference between 800 and 1600MHz on a core duo
[17:46] <Keybuk> which scaling driver?
[17:46] <pitti> yes; reducing 1200 MHz to 800 MHz makes a lot of difference here, battery-wise
[17:46] <jdong> I believe it's acpi_cpufreq?
[17:46] <Keybuk> jdong: then to bugzilla.kernel.org with you!
[17:46] <jdong> whatever is loaded by default for the core duo
[17:46] <slangasek> Riddell: kubuntu livefs builds failing because packagekit wants dbus to be active during its postinst
[17:46] <Keybuk> jdong: that's why I'm asking you ;)
[17:47] <jdong> so it's supposed to help idle power draw?
[17:52] <slangasek> cjwatson, Keybuk: should I be expecting a udev upload soon wrt that bug?  or an upload of something else?
[17:53] <cjwatson> slangasek: still waiting for testing; charlie-tca gave it a try but there was a false start because I forgot to tell him about the extra magic wand he needed to wave
[17:54] <slangasek> ok
[17:55] <Keybuk> there's a magic wand?
[17:55] <Keybuk> why don't I have a magic wand?
[17:55] <Keybuk> I WANT A MAGIC WAND!
[17:55] <ScottK> Keybuk: The Ponies have it.
[17:56] <cjwatson> Keybuk: http://paste.ubuntu.com/129436/ <- magic wand
[17:56] <Keybuk> scottK: is that because Ng didn't pay for the pony again, and Woody got turned to glue?
[17:56] <ScottK> That or gelatin.
[17:56]  * Nafallo has the magical forest :-P
[17:57] <cjwatson> Keybuk: looks like no luck :-/
[17:59] <Keybuk> cjwatson: then I really don't see how it can be udev with the device open ;)
[18:00] <Keybuk> you could always just stick "pkill udevd" in there and start it again afterwards
[18:00] <Keybuk> just to prove me wrong
[18:03] <Riddell> glatzor: know anything about the problem slangasek is talking about?
[18:05] <slangasek> Riddell: lp:~vorlon/packagekit/ubuntu-packagekit, if you want to pull
[18:05] <slangasek> mm, but wait a few minutes so it finishes pushing first :)
[18:06] <slangasek> Riddell, glatzor: anyway, why does this service run managed by dbus instead of having its own init script?  I thought we'd cured that problem when NetworkManager added its own init script
[18:09] <glatzor> Hello slangasek, Riddell
[18:09] <glatzor> slangasek, does it fail because of the dbus-send call?
[18:10] <slangasek> yes
[18:11] <glatzor> slangasek, the problem of package managers is the package cache. so this is why the daemon is only started on request.
[18:11] <slangasek> ah
[18:12] <glatzor> slangasek, actually this dbus-send call is not obligatory.
[18:12] <slangasek> yes, I've just sent up a patch to not fail when dbus-send fails
[18:13] <glatzor> slangasek, great. thanks a lot. I just have forgotten this use case.
[18:13] <glatzor> slangasek, sorry.
[18:13] <glatzor> for the extra work
[18:14] <slangasek> glatzor: 'sok :)  uploading now - please merge lp:~vorlon/packagekit/ubuntu-packagekit
[18:16] <glatzor> slangasek, I merged it. Thanks
[18:21] <gnomefreak> did Jaunty get support for fingerprint scan?
[18:21] <Tm_T> gnomefreak: by default you mean?
[18:22] <gnomefreak> Tm_T: or drivers
[18:22] <Tm_T> hmmm, I thought there were some support already
[18:22] <gnomefreak> Tm_T: im running another search but i have yet found it
[18:23] <gnomefreak> Tm_T: yep libpam-thinkfinger
[18:23] <Tm_T> gnomefreak: I believe there has been something like that for ages already
[18:23] <Tm_T> gnomefreak: as I remember installing stuff year ago
[18:24] <Tm_T> never had time to make it work too, though
[18:24] <gnomefreak> Tm_T: oh ok thanks
[18:24] <Tm_T> but, what do I know anyway (;
[18:25] <gnomefreak> Tm_T: when i get my laptop ill let you know how it goes
[18:25] <Tm_T> danke
[18:26] <Tm_T> I will need that feature some day soon
[18:26] <Tm_T> with encrypted disk ofcourse
[18:27]  * gnomefreak still hasnt tried the encryptFS yet
[18:27] <Tm_T> me neither
[18:27] <Tm_T> gnomefreak: my next Ubuntu hobby project will be https://www.alwaysinnovating.com/touchbook/
[18:28] <Tm_T> with possible hardware modifications
[18:28] <gnomefreak> Tm_T: good luck with that. I would have looked for an easier project
[18:30] <gnomefreak> ill be back sunbird hates me today
[18:30] <Mirv> seems to be a great day for I18N fixes, five new items fix released on JauntyTranslationIssues
[18:33]  * Tm_T goes back digging memleaks somewhere ->
[18:34] <cjwatson> gnomefreak: are you sure that bug 340652 is a ubiquity bug? it's not entirely clear to me that the installer has actually started, and that this isn't in fact an X bug or desktop bug instead
[18:34] <cjwatson> gnomefreak: BTW, you don't generally need to leave a comment when reassigning a bug to a different package unless there's something specific you want to say about it - the activity log is enough
[18:44] <KaiL> oh, bug 317781 just got a news message on heise.de ;)
[18:56] <mdke> Mirv: around?
[18:58] <Mirv> mdke: yes
[18:59] <mdke> Mirv: I noticed on the page TranslatingUbuntu/JauntyTranslationIssues you've written "about ubuntu completely untranslated" - can you explain more about that? It shouldn't be the case
[19:00] <mdke> Mirv: e.g. what languages have you tested? is /usr/share/gnome/help/about-ubuntu populated, etc?
[19:02] <mdke> Mirv: ah, I can reproduce it actually on my jaunty system. That's definitely a bug I wasn't aware of, we need to look into it
[19:02] <Mirv> mdke: System -> About Ubuntu gives all-English..
[19:02] <Mirv> mdke: dpkg -L ubuntu-docs | grep about <- basically those are not included at all, only C
[19:03] <mdke> hmm.
[19:07] <mdke> Mirv: ok, looking at the build log, it seems to be working properly, the problem is probably that we need to do an import from Rosetta, because the translations used in the package from Intrepid don't get over the 75% barrier for inclusion in the package. Don't know why, but let's recheck after the first export from rosetta a bit later
[19:09] <Mirv> mdke: ok, sounds fine, since it's not documentation string freeze yet anyway. good that there is no deeper problem.
[19:10] <calc> does anyone else see a /root/1 file keep appearing?
[19:10] <calc> something is creating it on my system but i'm not sure what
[19:10] <calc> its a 0 byte file
[19:11] <calc> happens on multiple systems so i think it is a packaging bug somewhere
[19:11] <Mirv> calc: hah, interesting, I have /root/1 as well
[19:11] <calc> Mirv: ok then it definitely is a packaging bug
[19:12] <calc> i even have the 1 in my OOo build chroot
[19:12] <jono> is something up with X - I just did an upgrade and got some Xsession errors
[19:12] <jono> looked to be a gdm issue
[19:13] <LaserJock> calc: because root is #1? ;-)
[19:13] <calc> LaserJock: lol
[19:13] <LaserJock> and he's ticked that we use sudo
[19:13] <LaserJock> so he reminds us
[19:13] <calc> LaserJock: i thought it was a foo > /dev/null 2>1 but couldn't find any scripts like that
[19:15] <LaserJock> calc: funny you mention it I found an empty 1 in the edubuntu-artwork source package last night
[19:15] <LaserJock> I suspect something like that happened there
[19:15] <calc> LaserJock: heh
[19:15] <calc> LaserJock: i keep removing the 1 and it keeps coming back
[19:16] <calc> heh
[19:17] <LaserJock> calc: so you looked at init scripts and cron jobs?
[19:17] <JanC> hm, I had a /root/1 and a ~/1 file like that
[19:19] <calc> LaserJock: yea but i might have glossed over the one that had the problem
[19:19] <calc> LaserJock: eyes glaze over after seeing the same line repetivitely :)
[19:19] <LaserJock> yeah
[19:20] <calc> a simple grep to find >1 turned up nothing though
[19:20] <calc> so it must be a bit more complicated than that
[19:22] <cjwatson> so I have a theory about the udev/partitioning problem
[19:22] <soren> calc: Are you a vi user?
[19:22] <cjwatson> libparted does partitioning commit in two phases: the first is commit to the device and the second is commit to the OS
[19:22] <cjwatson> in the first phase, it opens the device and writes out the new partition table to it
[19:23] <cjwatson> (and closes it again). As a device write, this causes udev to fire off some change events.
[19:23] <cjwatson> In the second phase, it does BLKPG_{DEL,ADD}_PARTITIONS calls.
[19:23] <soren> calc: If you are, I'm going to guess something like <ESC>wq1  happened to you..
[19:23] <soren> calc: Oh, it comes back on reboot?
[19:23] <cjwatson> I speculate that adding udevadm settle between those two phases will help
[19:24] <cjwatson> furthermore, the second phase is bracketed with ped_device_open and ped_device_close of the disk device, which will probably cause another set of change events at the end, so I bet we need to settle before that
[19:24] <calc> soren: yea i use vi but it is always coming back as a 0 byte file, so i think it isn't that, might be though
[19:24] <cjwatson> Keybuk: ^- would appreciate plausibility check
[19:24] <calc> soren: not sure when the last time i rebooted was
[19:24] <cjwatson> Keybuk: I think your udevadm settle change is sound and we'll need that - it just seems that we need a bit more too
[19:26] <gnomefreak> cjwatson: looking bug back up but as i recall he stated in #ubuntu+1 that after setup his mouse cuased freeze and keyboard wasnt detected, looking at the bug it looks like he didnt state the same. i think i still have logs
[19:26] <cjwatson> gnomefreak: freezes aren't usually installer bugs ...
[19:27] <cjwatson> gnomefreak: the installer's a relatively ordinary application from this point of view; if the system freezes, it's usually a lower-level problem
[19:27] <gnomefreak> it was afte3r install i was figuring more of livecd over d-i
[19:28] <cjwatson> gnomefreak: I'm afraid I couldn't understand that sentence
[19:28] <gnomefreak> freeze yes but keybourd detection is my concern but yes freezing would be X more so than anything
[19:28] <cjwatson> Could you please use some punctuation? It would really help me to understand what you're saying.
[19:28] <gnomefreak> cjwatson: since he stated that after install his keyboard wasnt detected "didnt work" i think he out it
[19:29] <gnomefreak> cjwatson: sorry i dont have brace on. puttin git on now
[19:29] <cjwatson> gnomefreak: If it has the wrong keyboard map, that could be an installer problem. If it just doesn't respond, it's something lower-level.
[19:31] <gnomefreak> cjwatson: agreed I'm going by his 2nd paragraph more so than last. The mouse most likely is an X or graphics issue. the keyboard is either d-i or Ubiquity and thinking abou tit now d-i runs in background right? so maybe it is d-i?
[19:32] <gnomefreak> cjwatson: i am however concerned about the 64bit install. The new intels for macs are 32bit i thought
[19:32] <cjwatson> gnomefreak: ubiquity is a frontend over d-i, but that doesn't mean that d-i runs in the background in any reasonable sense
[19:32] <cjwatson> gnomefreak: the only thing that d-i does in this case is set the keyboard map; it isn't responsible for interpreting keyboard events as they come in
[19:32] <gnomefreak> cjwatson: i thought d-i did the work, where as ubiquity was just for looks/ewasy install, ect.
[19:33] <cjwatson> gnomefreak: if the system was 32-bit only, it would have entirely failed to boot a 64-bit system at all; it wouldn't have got halfway up and then frozen
[19:33] <cjwatson> gnomefreak: it does a lot of the work, but it doesn't replace things like the kernel and X which are responsible for handling keyboard events
[19:34] <cjwatson> again, d-i only sets the keyboard map (via its console-setup component)
[19:34] <gnomefreak> cjwatson: right 64bit can install either, that makes sense becuase to boot livecd kernel and X have to run
[19:34] <cjwatson> but if you can't select the language, that's likely to be some lower-level issue
[19:34] <gnomefreak> isnt lang still first setup?
[19:35] <gnomefreak> right before keyboard layout
[19:36] <cjwatson> gnomefreak: yes, but I think he's talking about the language selector in gfxboot which isn't part of d-i
[19:36] <gnomefreak> cjwatson: in the 3rd paragraph he isnt as clear as i thought he was
[19:36] <cjwatson> gnomefreak: in any case, driving the language chooser only requires cursor keys (in d-i) or the mouse (in ubiquity); it is more or less impossible for the problem as described to be an installer bug
[19:36] <cjwatson> cursor keys are invariant across keymaps
[19:37] <gnomefreak> cjwatson: ok that makes sense now.
[19:37] <cjwatson> https://wiki.ubuntu.com/Installer/FAQ may help to untangle the different bits and pieces involved in the installer, although it doesn't talk about this problem specifically
[19:39] <gnomefreak> cjwatson: thanks ill read it. I am unable to test this on an imac since the one i have is old very old
[19:39] <cjwatson> it'll probably vary between models, particularly the speculated problem with the keyboard at gfxboot
[19:39] <cjwatson> we have some other reports of the latter
[19:45] <cjwatson> Keybuk: further data point: libparted/arch/linux.c has an obscure _flush_cache function that claims to have something to do with cache coherency, and that opens all the child partition devices for writing in order to fsync them; this is called upon opening a device, and upon closing a device if it's dirty
[19:45] <cjwatson> Keybuk: hence lots of change events ...
[19:46] <Keybuk> nice
[19:46] <cjwatson> (it only does this for unmounted partition devices obviously)
[19:46] <cjwatson> so I think this explains why the race is so tight
[19:47] <cjwatson> bracketing linux_disk_commit with settles ought to do it I think
[19:48] <cjwatson> Keybuk: could you upload the udev stuff you have so far?
[19:49] <Keybuk> done
[19:49] <cjwatson> thanks
[20:37] <LiraNuna> "not app development on Ubuntu" what is, then?
[20:38] <pbn> well that's not English LiraNuna
[20:38] <LiraNuna> text was taken from the topic.
[20:39] <LiraNuna> I came here thinking it's a channel for developers using ubuntu. Topic said I'm wrong. What is the correct channel then?
[20:39] <Amaranth> LiraNuna: it's for developing ubuntu
[20:39] <Amaranth> LiraNuna: generally for app development you want to go to the place for the tool you're using
[20:39] <Amaranth> #gtk+ on GIMPNet, #qt on freenode, etc
[20:39] <LiraNuna> I need help with packages and cross compiling
[20:40] <LiraNuna> I don't know where to turn, since it's not API specific
[20:40] <Amaranth> ah, perhaps #ubuntu-motu then, that's the place for packaging help
[20:40] <LiraNuna> thank you
[20:40] <cjwatson> pbn: we only have a limited number of characters in the topic, and at the time that was written, the only way we could fit all the required information in was to abbreviate "application"
[20:42] <pbn> cjwatson: ah ok, sorry :)
[20:51] <slangasek> cjwatson, Keybuk: where do we stand?  If the udev fix isn't imminent, I should probably go ahead with a d-i build anyway to get candidate CDs up
[20:51] <cjwatson> the udev fix is uploaded and mostly built
[20:52] <slangasek> ok
[20:52] <cjwatson> I'm working on testing a parted fix to go with it
[20:52] <cjwatson> which is based on a bit of an assumption - but I don't want to go round again with time-consuming hand-built images if possible
[20:54] <mdke> quick question about the SRU process. After I do step 3 (subscribe ubuntu-sru), do I wait for intervention before step 4 (uploading to intrepid-proposed), or do I just go ahead and upload then wait for approval
[20:55] <ScottK> Main or Universe?
[20:56] <mdke> ScottK: main, but the question applies generally
[20:56] <ScottK> Main you upload.  Universe I think you wait.
[20:57] <mdke> ok, thanks
[20:57] <cjwatson> you know what I hate? forgetting to edit debian/patches/00list
[21:03] <directhex> i hate forgetting to run update-maintainer
[21:22] <cjwatson> Keybuk: random note, it would make the logs marginally easier to understand if udevd logged a debug message when it sent the SIGUSR1
[21:23] <cjwatson> Keybuk: then we could see not only when the SETTLE control message arrived, but when it finished
[21:23] <cjwatson> (IYSWIM)
[21:28] <Amaranth> calc: why do all OOo apps run under the same process?
[21:30] <calc> Amaranth: its only one app
[21:30] <Amaranth> calc: looks like 5 or so to me :P
[21:30] <calc> Amaranth: different views in the same program
[21:31] <Amaranth> calc: if I open presentation and it's waiting for me to finish the wizard I can't open writer
[21:31] <calc> Amaranth: long time ago star office looked like a whole computer enivornment (iirc)
[21:31] <calc> Amaranth: yep its just one app you have to finish the other one
[21:31] <calc> Amaranth: look at how it is executed, you just run ooffice -math
[21:31] <calc> to get a default math view
[21:32] <Amaranth> makes it impossible for gnome-do to keep them separate :/
[21:32] <calc> Amaranth: well nothing that can be done except work around it somehow in gnome-do
[21:32] <calc> OOo is just OOo the 'apps' are just easy ways to start a view in the particular document format
[21:34] <calc> it may be less confusing to just get rid of the extra menu options and only call it OpenOffice.org but I think its done in the present way to be clearer to users what is available from the menu
[21:34] <calc> er less confusing in that it would be obvious then that it is only really one program
[21:36] <calc> Amaranth: there currently isn't a menu option but if you run 'ooffice' it will become more clear what I am talking about
[21:36] <Amaranth> wow that's...
[21:37] <Amaranth> I don't even know how to describe the fail
[21:37] <Amaranth> This is not how you write software :P
[21:38] <calc> Amaranth: OOo is 20+ years old, heh
[21:38] <Amaranth> So is Xorg
[21:38] <Amaranth> Wait, forget I said that
[21:38] <Amaranth> Yeah, I understand :)
[21:39] <calc> it appears it was 'integrated' in 1994
[21:39] <ajmitch> no wonder people accuse OOo of being bloated & slow
[21:39] <calc> ajmitch: uh because it is? :)
[21:39] <calc> ajmitch: i'm pretty sure no one could argue it isn't bloated and/or slow
[21:40] <Amaranth> well it wasn't until very recently that Xorg wasn't an OS so I guess we can give OOo some time to stop being one
[21:40] <Amaranth> I thought one of the goals for OOo 3.0 was to split them out
[21:40] <calc> it takes 638MB VIRT and 97MB RES (afaict)
[21:40] <calc> just to start up with nothing loaded
[21:40] <calc> Amaranth: nope
[21:41] <calc> Amaranth: i don't think anyone has ever proposed that it would be too huge a goal to do
[21:41] <Amaranth> So the only solution is to nuke it from orbit and start over
[21:41]  * Amaranth installs koffice
[21:41] <calc> what they are considering doing is splitting some of the code into separate buildable bits, but you would still need pretty much all of it to use it
[21:41] <calc> Amaranth: good luck with koffice :)
[21:42] <calc> isn't it in a perpetual state of not quite ready? :)
[21:42] <walters> virt is pretty much irrelevant
[21:43] <calc> walters: doesn't that include what is mapped from libraries?
[21:43]  * calc may be confused
[21:43] <calc> or does RSS include that
[21:43] <maix> hi, what does "fix commited" exactly mean?
[21:43] <calc> maix: depends on who used it
[21:43] <maix> hehe
[21:43] <Amaranth> maix: it'll be in the next upload, usually
[21:44] <maix> means how long?
[21:44] <calc> maix: usually it means the fix is committed somewhere and usuall for the next upload
[21:44] <maix> calc: https://bugs.launchpad.net/ubuntu/hardy/+source/pidgin/+bug/340151/+viewstatus
[21:44] <Amaranth> whenever they do the next upload
[21:44] <walters> calc: well, shared libraries can have both shared and non-shared parts
[21:44] <Amaranth> is that for a backport?
[21:45] <calc> walters: i think i may be mistaken in thinking RSS was the private memory part for the application?
[21:45] <Amaranth> jdong: what does Fix Committed mean for a backport request?
[21:45] <maix> Amaranth: how often do they usually?
[21:45] <jpds> Amaranth: Probably package uploaded to -backports pocket for release.
[21:45] <calc> grr gtk_file_chooser_set_local_only does exactly what it says
[21:45] <Amaranth> maix: depends on...everything
[21:45] <Amaranth> maix: somewhere between 1 minute and the heat death of the universe
[21:45] <cjwatson> maix: "fix committed" has absolutely no implication of timescale
[21:45] <calc> it doesn't cause the file chooser to see the gvfs fuse paths, it just hides the gvfs file shares entirely
[21:45] <maix> just roughly. less than one day?
[21:46] <Amaranth> maix: Probably not
[21:46] <maix> hm
[21:46] <cjwatson> days, weeks, maybe months
[21:46] <calc> walters: any ideas on how to get a gvfs fuse path out of gtk_file_chooser ?
[21:46] <cjwatson> or maybe ten seconds
[21:46] <maix> hm ok *g*
[21:46] <cjwatson> "fix committed" just doesn't mean anything about time
[21:46] <calc> walters: i want to disable gvfs in OOo but want the gtk file chooser still and want to be able to get to the gvfs fuse files
[21:46] <walters> calc: there's information scattered on the web; http://virtualthreads.blogspot.com/2006/02/understanding-memory-usage-on-linux.html is one
[21:46] <walters> calc: i don't have any gvfs-fu, sorry =/
[21:46] <calc> walters: ok
[21:47] <Amaranth> calc: I think we need that patch to make it always use FUSE paths for that to work
[21:47] <Amaranth> although if it can figure out the FUSE path surely there must be an API to do so...
[21:47] <maix> it's just some from ubuntu-de have just written an article describing what to do and i discovered that it's already "fix released" and thought maybe we wouldn't have to publish it then
[21:47] <Amaranth> maix: wait a day or two
[21:47] <maix> ok then we'll publish it
[21:48] <Amaranth> although I still don't know if that is for backports or updates
[21:48] <maix> well, it's an essential feature, must be updates :)
[21:48] <calc> Amaranth: there is a path for that?
[21:48] <Amaranth> calc: fedora has a patch to always use FUSE paths, iirc
[21:48] <calc> Amaranth: er patch?
[21:48] <maix> ok thanks then
[21:48] <calc> Amaranth: hmm i thought their patch was to never use FUSE paths?
[21:49] <Amaranth> calc: nah, that wouldn't make sense
[21:49] <calc> Amaranth: they added support to desktop files to do: X-GIO-NoFuse=true
[21:49] <Amaranth> ah, they've changed the patch then
[21:49] <Amaranth> I know when gio/gvfs was first being used someone who works on fedora had a patch to always use FUSE paths
[21:50] <Amaranth> seb128 may know more about it?
[21:50] <calc> seb128_: ping
[21:50] <calc> seb128_: any ideas about a fedora patch to always use fuse paths that Amaranth mentioned?
[21:50] <seb128_> calc: pong, dunno of hand about how to change the fileselector to run gvfs fuse paths no
[21:50] <calc> seb128_: ok
[21:51] <seb128_> calc: what he was speaking about is the .desktop changes
[21:51] <calc> seb128_: ok
[21:51] <seb128_> to give fuse uris to apps when calling those
[21:51] <calc> yea
[21:51] <seb128_> but that's not gtkfileselector code
[21:51] <calc> seb128_: yea that is what i need to find out how to get fuse paths out of :-\
[21:52] <calc> its probably not terribly common to have a file dialog but no gio/gvfs support, heh
[21:53] <seb128_> well, use the local mode
[21:53] <Amaranth> hrm, I guess I misunderstood what they were doing
[21:53] <seb128_> you can still browse .gvfs ;-)
[21:57] <Amaranth> ah, davidz was trying to get it to always pass the FUSE path but must have gotten too much pushback
[22:01] <Amaranth> calc: looks like g_file_get_path ()
[22:01] <Amaranth> ha, a google search for that gives a bunch of ubuntu crash reports crashing on that function
[22:02] <calc> Amaranth: hmm ok
[22:02] <Amaranth> calc: so OOo would still have to use gio at least for that part
[22:02] <calc> Amaranth: i'll have to add some debugging into OOo see what it spits out for various functions and then patch it properly :)
[22:02] <tormod> slangasek and others: thanks for the new ports build, but why is .manifest not updated?
[22:02] <calc> Amaranth: that should be fine since gio is in glib now
[22:03] <Amaranth> calc: why disable gio/gvfs usage in OOo anyway?
[22:03] <calc> Amaranth: the actual gio/gvfs saving support seems horribly broken which is why i am disabling that part as I don't know enough about it to fix it in the short time we have left
[22:03] <calc> Amaranth: i got gvfs fuse support working for OOo properly as of 1.1.8 (filed a few bugs upstream) so that much will work if i can get the fuse paths
[22:05] <slangasek> tormod: that would be a livefs build failure of some kind
[22:05] <slangasek> tormod: i.e., http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/
[22:06]  * calc bbl, dinner
[22:22] <tormod> slangasek: thanks, yes compiz breakage as you predicted yesterday
[22:23] <slangasek> tormod: if that's the failure, it might be fixed by now - I'll do a test spin
[22:24] <tormod> slangasek: thanks
[22:27] <lool> Keybuk: modprobe dropped the -Q option it seems
[22:27] <lool> Hmm weird, I don't see it every working
[22:28] <lool>        -Q --silent
[22:28] <lool>                  As -q with the addition that all warnings and errors are also
[22:28] <lool>                  silenced.
[22:30] <lool> Hmpf and /sbin -> /bin/lsmod hits more than just powernowd
[22:31] <cjwatson> slangasek: I just reassigned a d-i bug to compiz about that, and I guess there's probably a small stack
[22:31] <slangasek> cjwatson: about compiz installability?  should already be resolved as of last night
[22:32] <cjwatson> yeah, I tend to get bugs whenever dailies are uninstallable, I don't always have time to look up the status
[22:32] <cjwatson> usually just punt it to the right package and let them sort it out ...
[22:34] <slangasek> ack, I'll chase it up
[22:34] <slangasek> thanks :)
[23:54]  * TheMuso notices that jaunty-changes is lagging somewhat...
[23:54] <cjwatson> the list server has been loaded of late, I believe
[23:54] <TheMuso> makes sense
[23:57] <cjwatson> (several people have been asking on #is)