[12:04] <mdz> Kamion: nice!
[12:04] <thom> Kamion: very cool
[12:42] <mdz> https://bugzilla.ubuntu.com/show_bug.cgi?id=2817
[12:42] <thom> assign it to elmo
[12:43] <jdub> haha
[12:43] <jdub> awesome
[12:58] <thom> actually, no
[12:58] <thom> find someone to make that as a mask
[12:58] <thom> and then we can give it to elmo at decConf
[01:02] <mdz> 482 >= normal bugs to review
[01:28] <mdz> lamont: ping?
[01:31] <lamont> yo
[01:35] <mdz> lamont: how is amd64 coming along?
[01:36] <lamont> hoary.all.amd64:Total 616 package(s) in state Needs-Build.
[01:36] <lamont> hoary.all.powerpc:Total 52 package(s) in state Needs-Build.
[01:36] <lamont> starting to look at bugs, pondering gnutls1[01] 
[01:41] <__daniel> hmmmmm, why does noflushd depend on ed?! :-)
[01:50] <lamont> __daniel: because some things are sick, that's why
[01:50] <lamont> depend, or build-depend?
[01:50] <__daniel> depend
[01:54] <lamont> ew!
[01:54] <azeem>         printf "%%s?^ *$1=.*?$1=\"$new\"?\nw\nq\n" | ed -s "$CONFFILE"
[01:55] <azeem> it's used in the postinst
[01:55] <lamont> azeem: warn me before you do that, so I can puke other than on the keyboard...
[01:56] <azeem> lamont: heh, you might want to read the comment before that line one day...
[01:56] <lamont> azeem: please tell me it's an apology?
[01:56] <azeem>         # Careful here! Both DISKS and PARAMS may contain '/' (or just about
[01:56] <azeem>         # any other character. In order not to confuse ed, we use a delimiter
[01:56] <azeem>         # for the regexp that very rarely occurs in path names.
[01:57] <lamont> AAAAAAAAAAAAAIIIIIIIIIIIIIIIIIIIIIEEEEEEEEEEEEEEEEEEEE!
[01:57] <lamont> " very rarely occurs"
[01:57] <azeem> oops, lamont just did another edwards
[01:57] <azeem> "it's perfectly safe"
[01:57] <__daniel> WOW
[01:57] <lamont> "hundreds and hundreds of times, ain't nothing happened"
[01:57] <__daniel> this is something even <b>I</b> wouldnt have thought of
[02:04] <__daniel> good night everyone, hopefully ed won't blow up my box tonight ;-)
[02:19] <mjg59> Is / an accepable character in disklabels?
[02:31] <jdub> heh
[02:31] <jdub> rock
[02:32] <lamont> packages with at least one failed arch: dh-kpatches, linux86, rrdtool
[02:32] <lamont> jdub: so what's uninstallable, I wonder?
[02:32] <jdub> well, gdm no longer wants to be removed or upgraded
[02:32] <jdub> so i'm chancing it
[02:42] <lamont> oh, and planner
[02:42] <lamont> jdub: lol
[02:43] <jdub> only thing that wanted to be removed on this run was python2.3-generic (replaced without 2.3)
[02:43] <jdub> so i'm upgrading without losing anything
[02:44] <jdub> which is a good start ;)
[02:53] <mdz> jdub: I fixed the removing-alsa-utils bug earlier today
[02:53] <mdz> then upgraded my laptop
[02:53] <mdz> the only issue I ran into was a segfaulting gnome-settings-daemon, which seb fixed
[02:56] <lamont> do we have a list of the needs-review packages?
[02:56] <lamont>   libgnomevfs2-dev,libgnutls10-dev
[02:56] <lamont>   libcupsys2-dev,libgnutls10-dev
[02:56] <lamont> grumble
[03:56] <jdub> hrm, so
[03:57] <jdub> i have two binary packages in the same source package
[03:57] <jdub> one of which incorrectly had files that should've been in anoother
[03:57] <jdub> so now when i go to upgrade, i borks on replacing those files
[03:58] <jdub> the one which should have those files depends on the Source-Version of the one which shouldn't
[03:58] <jdub> shouldn't that be upgraded first?
[03:58] <jdub> or do i have to do something with Replaces?
[04:13] <mdz> jdub: you need to add a Conflicts:
[04:13] <jdub> versioned?
[04:14] <mdz> lamont: the list of needs-review packages is pending the latest reduction through Keybuk magic
[04:20] <lamont> mdz: ah, ok
[04:53] <fabbione> morning guys
[05:07] <tseng> hi
[05:12] <hornbeck> tseng: that libdbus-cil did not work
[05:12] <hornbeck> sorry I did not get to it sooner
[05:30] <lamont> hoary.all.amd64:Total 256 package(s) in state Needs-Build.
[06:05] <mdz> morning, fabbione
[06:05] <fabbione> i was wondering...
[06:06] <fabbione> in a changelog
[06:06] <fabbione> * blabla:
[06:06] <fabbione>   + foobar:
[06:06] <fabbione>     - dkdkdk:
[06:06] <fabbione> and then?
[06:06] <fabbione> what is the next symbol to use?
[06:06] <mdz> =?
[06:06] <fabbione>  / ?
[06:06] <fabbione> ~ ?
[06:07] <mdz> I would go with = or .
[06:07] <fabbione> sqrt() 
[06:07] <mdz> 
[06:07] <mdz> 
[06:09] <lamont> night all
[06:10] <lamont> ?
[06:10] <mdz> night
[06:12] <lamont> hoary.all.amd64:Total 204 package(s) in state Needs-Build.
[06:12] <lamont> hoary.all.i386:Total 4 package(s) in state Needs-Build.
[06:13] <lamont> and really off to bed
[06:13] <mdz> 52 packages in the past 40 minutes, not bad
[06:15] <fabbione> night lamont 
[06:21] <fabbione> uhuh
[06:21] <fabbione> 97 lines of changelog already
[06:21] <fabbione> and it is not even that detailed
[06:29] <fabbione> ahhh there is a new server
[06:29] <fabbione> #if defined(XdmxServer) && XdmxServer
[06:29] <fabbione> XCOMM
[06:29] <fabbione> XCOMM distribued multihead Server
[06:29] <fabbione> XCOMM
[07:31] <fabbione> daniels: ping
[07:39] <mdz> fabbione: this hardware cursor thing is becoming a FAQ
[07:39] <mdz> is there anything we can do?
[07:39] <mdz> can we just disable it by default?
[07:42] <geppy> How does one go about becoming a ubuntu packager?
[07:46] <pitti> Morning, guys!
[07:48] <mdz> pitti: morning
[07:48] <AndyFitz> afternoon
[07:48] <pitti> Hi mdz!
[07:49] <pitti> mdz: AFAICS you did not yet send out the announcements?
[07:49] <mdz> geppy: http://www.ubuntulinux.org/community/maintainers
[07:49] <mdz> pitti: that is correct
[07:49] <mdz> pitti: I can run amber if you have tested the packages
[07:50] <pitti> mdz: so far I'm prepared for glibc and tetex-bin
[07:54] <mdz> pitti: which USN number is each?
[07:54] <pitti> mdz: glibc: 4-1, tetex-bin: 9-1
[07:58] <fabbione> mdz: no we can't.. on quite a bunch of hardware it works fine
[07:58] <geppy> mdz:  Thank you.
[07:58] <fabbione> mdz: if we disable it by default, someone will complain of the opposite
[07:58] <fabbione> mdz: as usual.. no win2win situation here
[07:58] <mdz> fabbione: what will they complain about?
[07:58] <fabbione> mdz: welcome to X :-)
[07:59] <fabbione> that the cursor is not accelerated in hardware
[07:59] <mdz> pitti: both installed, templates are on their way
[07:59] <mdz> will they even notice?
[08:00] <pitti> mdz: got them
[08:01] <fabbione> mdz: people will complain just because there is the option in the config. i don't know at visual level
[08:01] <fabbione> + each driver has it's own option
[08:01] <fabbione> one has SwCursor another HwCursor
[08:01] <fabbione> so you get the picture...
[08:02] <mdz> what is the cause of the bug, where there are two cursors on the screen?
[08:02] <fabbione> AND THE FONTS BUILD FLAGS in X.org are borked!
[08:02] <fabbione> mdz: apparently there is the default black X cursor printed on the screen, but the real mouse works
[08:03] <mdz> fabbione: right, it is as if there are two cursors
[08:03] <mdz> one hardware and one software? two hardware?
[08:03] <mdz> or is it even something else?
[08:03] <mdz> perhaps there is a bug that can be fixed
[08:03] <pitti> mdz: odd, the libc6 thingy contains two package versions
[08:03] <mdz> pitti: yes
[08:03] <mdz> pitti: it had to be fixed so that it would build
[08:04] <pitti> mdz: right, but can't we just drop the ubuntu2.1?
[08:04] <mdz> pitti: yes, you can drop it from the advisory
[08:04] <mdz> amber needs to process it, though
[08:04] <mdz> it probably should be omitted from the template
[08:04] <mdz> pitti: send mail to elmo about it
[08:05] <elmo> or just tell me now
[08:07] <fabbione> mdz: i think one is the hardware and one is the software
[08:07] <fabbione> mdz: yes.. it might be a bug.. and i don't know 1) how to reproduce it 2) if it can be fixed
[08:07] <mdz> elmo: wtf are you doing awake?
[08:08] <jdub> mdz: ... 5.04 or 5.4?
[08:08] <elmo> mdz: fell asleep at my desk, got woken by cron.daily
[08:08] <mdz> jdub: 5.4 would be more accurate
[08:08] <pitti> mdz: out
[08:08] <mdz> elmo: tell me you're joking
[08:09] <elmo> mdz: ...
[08:13] <fabbione> this is going to be so cooooool
[08:13] <fabbione> mdz: do you feel lucky today?
[08:18] <mdz> fabbione: why, do you want to upload X? :-)
[08:19] <elmo> pitti: oh, I thought you guys were talking about nothing-to-merge syncs.. and you weren't.. do mail me about/explain whatever you were talking about ;-)
[08:19] <pitti> elmo: the only problem was that the glibc amber output contained two versions (2.1 and 2.2); I deleted all 2.1 package lines
[08:20] <mdz> elmo: glibc had two versions in accepted/
[08:20] <mdz> elmo: I passed them both through amber at the same time, as I understand I'm supposed to
[08:20] <elmo> yeah, definitely
[08:20] <mdz> elmo: and amber included md5sums for both versions in the template
[08:20] <mdz> which I think it has always done, but it occurred to me that it doesn't make much sense
[08:21] <elmo> well, easy workaround is to run amber twice, that works too
[08:21] <elmo> as long as you do it in the right order ;-)
[08:21] <elmo> but yeah, I'll TODO hiding anything-but-latest version from template
[08:21] <mdz> thanks
[08:21] <mdz> and lamont will TODO having everything in warty actually buildable :-)
[08:21] <mdz> s/warty/hoary/
[08:22] <mdz> wartylog: TOO LATE FOR YOU
[08:22] <fabbione> mdz: no... i need someone to help me debugging a 22K lines Makefile
[08:23] <pitti> mdz: did you already approve the two messages? I did not get them yet
[08:23] <mdz> fabbione: I am feeling so tired suddenly
[08:23] <elmo> hehe
[08:23] <fabbione> mdz: but still lucky, eh?
[08:24] <fabbione> elmo just woke up... so he should be fresh :P
[08:24] <mdz> pitti: done
[08:24] <pitti> mdz: thx. I also added them to the website (works now)
[08:24] <mdz> great
[08:24] <pitti> mdz: BTW, any idea how to delete this test item?
[08:24] <mdz> pitti: test item?
[08:25] <pitti> mdz: the USN page contains a "testing manager permissions" item
[08:25] <pitti> mdz: maybe lulu created it to check something
[08:25] <mdz> pitti: oh, who did that? :-)
[08:25] <pitti> mdz: its state is "obsolete", but it still appears
[08:26] <mdz> pitti: I changed it to in-progress
[08:26] <mdz> so it should not appear
[08:26] <mdz> but I do not know if it is possible to delete anything
[08:26] <pitti> mdz: ah, right, as soon as I log out, it does not appear any more
[08:26] <mdz> elmo: I don't suppose you have a handy list of all the little gotchas for ambering, to give to pitti?
[08:27] <pitti> mdz: but neither do my newly added items. Gosh - I changed them to "published"...
[08:27] <pitti> mdz: oh, now they do. Please forget that
[08:27] <mdz> our website is SO SLOW
[08:27] <elmo> the lack of caching probably isn't helping
[08:28] <elmo> but yes, it is painful
[08:28] <mdz> elmo: does the load spike on gentoo every time someone clicks a link?
[08:29] <elmo> heh, well it has jumped a lot since we broke the caching
[08:33] <sid77> 'morning
[08:34] <mdz> elmo: was that intentional in order to un-break the authentication?
[08:35] <mdz> gah, falling asleep. night, all
[08:35] <fabbione> night mdz
[08:35] <elmo> mdz: they're trying to get it caching with auth, yeah, but broke it entirely in the process. woo
[08:35] <elmo> night
[08:37] <pasc> elmo: sounds like you need to run anacron later ;-)
[08:39] <elmo> pasc: I was more thinking I should sleep in a bed instead
[08:39] <elmo> radical idea, I know, but..
[08:47] <fabbione> pitti: are you sending out the USN, BEFORE or AFTER the packages are available on the main mirror?
[08:47] <pitti> fabbione: after
[08:47] <jdub> hoary is back to the glory days of warty
[08:47] <pitti> fabbione: mdz ambers them (which should mean to push them to the mirror), then I send out the announcement
[08:47] <fabbione> pitti: imho you should wait a coule of hours to give time to the mirrors to sync
[08:47] <jdub> every time you update, even if it's only 15 minutes apart or less, there'll be new packages ;)
[08:48] <pitti> fabbione: hmm, mdz wanted me to send out the announcements immediately. mdz, what do you think?
[08:48] <fabbione> pitti: mdz is asleep
[08:48] <pitti> fabbione: oh
[08:48] <fabbione> i am afraid that in this way mirror maintainer will be bombed of requests to sync more often
[08:49] <pitti> fabbione: hmm, mirroring is a good point; OTOH, further delay of updates is not the best thing either
[08:49] <fabbione> pitti: i completed my mirror 10 minutes before the USN
[08:49] <pitti> fabbione: maybe there could be some sort of a mirror pulse whenever a new security upload is available? It's not that much to sync
[08:50] <fabbione> and the packages were not there
[08:50] <pitti> fabbione: maybe this should be discussed on the ML?
[08:50] <fabbione> on Debian they usually wait that it is available
[08:50] <elmo> no they don't fabbione
[08:50] <elmo> they tell people not to mirror security.debian.org
[08:50] <pitti> nevertheless folks do it
[08:51] <fabbione> elmo: i still see the DSA and i have the packages on the local mirror
[08:51] <elmo> yes, but the point is they don't delay DSAs for the sake of mirrors
[08:51] <fabbione> and i mirror debian much less often than ubuntu
[08:51] <elmo> because there are no official ones
[08:51] <elmo> and I don't think we should delay our USNs either
[08:51] <fabbione> elmo: it's not like delaying them 24Hours
[08:51] <pitti> me neither, I rather think the mirroring strategy should be fixed then
[08:52] <fabbione> pitti: i agree
[08:52] <elmo> what mirroring strategy?
[08:52] <pitti> fabbione: would this be technically possible to send out a mirror pulse?
[08:52] <fabbione> elmo: the point is that we don't have a fully separate archive for security
[08:52] <fabbione> pitti: yes. that can be done
[08:52] <fabbione> pitti: but it's up to elmo to implement it
[08:52] <elmo> not to fabbione's personal mirror it won't
[08:52] <fabbione> i use ssh triggers for that
[08:53] <fabbione> elmo: nahh... i am not that selfish you know :-)
[08:54] <fabbione> i can handle stuff for myself.. i am more concerned about normal users that do not understand all the details behind stuff and that usually tends to panic when they read "security"
[08:54] <fabbione> elmo: allow me that at least :P
[08:55] <elmo> normal users are going to be pointed at security.ubuntu.com
[08:55] <fabbione> not in big company environments
[08:55] <fabbione> anyway
[08:55] <elmo> we wouldn't be triggering big company environments, so what's your point?
[08:55] <elmo> dude, we can not "fix" this
[08:55] <fabbione> it's pitti and mdz call for that
[08:56] <fabbione> elmo: companies like Ericsson (just to make an example) have their own internal mirrors
[08:56] <fabbione> and you might end up triggering them
[08:56] <elmo> err, no I wouldn't?
[08:56] <pitti> fabbione: it certainly makes sense to have a local mirror; maybe we can introduce a kind of "sync subscription" process?
[08:57] <pitti> elmo: why do you think it's bad to send out sync triggers?
[08:57] <elmo> pitti: I didn't say it was
[08:57] <fabbione> elmo: if company $FOO comes here and say: we pay XXXXX USD/month to be triggered....
[08:57] <fabbione> elmo: aren't we going to trigger it?
[08:57] <elmo> pitti: but you have a hiearchahal structure
[08:57] <elmo> not a flat one where you trigger every mirror and his dog
[08:57] <pitti> elmo: so we do trigger some main mirrors?
[08:58] <elmo> pitti: no not right now, but what's your point?  even if we do, we should NOT delay USNs for that
[08:58] <elmo> and triggers are triggers - you have no idea when the mirror is up2date
[08:59] <pitti> elmo: no, we shouldn't delay USNs, that was not my question
[08:59] <elmo> or often, even if the trigger's worked, they're not some magic solution
[08:59] <pitti> elmo: I just thought about shortening the mirroring delay
[09:07] <fabbione> ok... and another bug in X.org is fixed
[09:07] <fabbione> now let's wait these... few hours to complete the compilation
[09:08] <sid77> c'mon fabbione you are doing it for "the cause" ;)
[09:14] <fabbione> elmo: all our amd64 and ppc buildd are in single cpu mode, right?
[09:15] <fabbione> but the i386 is SMP
[09:15] <thom> fabbione: correct
[09:24] <thom> uh oh
[09:24] <thom> these are never good
[09:24] <sid77> lol
[09:26] <pitti> elmo: do package syncs need to be approved my mdz?
[09:26] <pitti> elmo: imagemagick can be synced from sid
[09:26] <fabbione> thom: not that bad... but the i386 buildd will save a bunch of time
[09:26] <fabbione> thom: they started implementing the target DONE inside X.org, to mark a subdir as such
[09:26] <fabbione> thom: i can easily detect if the target is there or not
[09:26] <fabbione> and parallelize building of docs and fonts
[09:27] <fabbione> according to /proc/cpuinfo
[09:33] <__daniel> good morning
[09:34] <AndyFitz> morning __daniel
[09:35] <__daniel> hai AndyFitz
[09:49] <daniels> fabbione: pong
[09:50] <fabbione> daniels: libXaw.a disappeared from X.org
[09:50] <fabbione> how are we supposed to ship libXaw*-dev ?
[09:51] <fabbione> daniels: http://people.ubuntulinux.org/~fabbione/006_update_fonts_Imakefiles.diff
[09:52] <fabbione> please apply upstream if it is not there alredy in 6.8.1+CVS
[09:52] <fabbione> it fixes fonts build
[09:54] <daniels> fabbione: what the hell? disppeared?
[09:54] <daniels> probably because no-one cares
[09:54] <daniels> fabbione: ok, I'll check it out
[09:54] <daniels> brb
[09:54] <bob2> xaw = athena?
[09:58] <fabbione> daniels: no it's not upstream
[10:00] <fabbione> argh
[10:00] <fabbione> daniels: wait.. there is a missing bit in the patch
[10:04] <fabbione> daniels: it should be ok now
[10:15] <thom> pitti: you need to fix the desktop seed - libhal-storage is in universe
[10:15] <pitti> thom: argh, thanks for that hint
[10:15] <pitti> thom: can I do that myself?
[10:16] <thom> i don't know
[10:16] <thom> sorry
[10:16] <pitti> thom: I'll mail matt
[10:16] <jdub> hrm
[10:16] <jdub> so
[10:17] <jdub> does germinate pull from the new wiki or the old wiki? :)
[10:17] <jdub> pitti: approved
[10:17] <thom> jdub: i was wondering that
[10:17] <jdub> pitti: but i imagine it will make most sense on the old wiki atm
[10:17] <pitti> jdub: okay, then I'll add it there
[10:17] <thom> old wiki is read only
[10:17] <jdub> oh
[10:17] <jdub> already
[10:17] <pitti> then new wiki... :-)
[10:18] <pitti> jdub: if it does not work with the new wiki, I can still bother mdz; it's not that urgent, nothing uses this library yet (I think)
[10:18] <pitti> jdub: no, sorry, hal itself uses it
[10:18] <thom> well, hal depends on it
[10:18] <thom> so trying to use just hoary will break
[10:21] <jdub> yeah
[10:23] <sivang> thom : around?
[10:23] <seb128> morning
[10:23] <danielshower> hai seb128
[10:23] <danielshower> /nickt __daniel
[10:24] <thom> sivang: yo?
[10:24] <thom> sivang: in general, please just talk. if i'm not around, i'll have an away log set
[10:24] <sivang> thom : just remembered something from my past, you ever heared of TANDEM / HIMALAYA ?
[10:24] <thom> nope
[10:25] <sivang> thom : or should I say Compaq TANDEM :)
[10:25] <thom> nope, no bells are being rung here
[10:26] <sivang> thom : ok
[10:33] <pitti> jdub: currently I think germinate uses the Warty seeds; but I can't possibly change them, right?
[10:33] <jamesh> hi seb128
[10:33] <pitti> jdub: that is, I shouldn't
[10:34] <seb128> hey jamesh 
[10:34] <jdub> pitti: oh, true, germinate is totally unrelated to hoary so far
[10:34] <daniels> bob2: X Athena Widgets
[10:34] <jdub> pitti: perhaps just put it on SupportedSeed proposals for hoary if it needs to go there (isn't it a depends?)
[10:34] <bob2> daniels: ah
[10:35] <pitti> jdub: it is a depends, that's why I'm wondering why it got to universe
[10:35] <pitti> jdub: seems like germinate did not run recently
[10:35] <pitti> jdub: I shouldn't need to modify the seeds
[10:36] <jamesh> seb128: w.r.t. the new drive mount applet and Hoary, would it be easier if I backported it to 2.8, or just leave it for a 2.9 release.
[10:36] <jamesh> ?
[10:36] <seb128> just leave it, I'll package the 2.9 branch
[10:37] <seb128> 2.9.1 is due next week, right ?
[10:37] <jdub> pitti: i don't think we're germinating hoary at all yet
[10:37] <pitti> jdub: so maybe we should? New upstream versions are flooding Hoary
[10:37] <pitti> jdub: they could introduce more of these problems
[10:38] <|trey|> Is Xorg in Hoary yet?  Breakages are welcome, filing bugs makes me feel needed  8)
[10:39] <daniels> |trey|: we will tell you when xorg is in hoary.
[10:39] <daniels> nothing about hoary (it being ready for use, xorg entering, everything) will creep up on you
[10:40] <pitti> Hi Keybuk!
[10:40] <|trey|> daniels, just thought I would ask here due to "Happy Hoary Trail"... I usually use Sid anyways, so know what to expect  :)
[10:40] <jdub> morning Keybuk 
[10:41] <jdub> Keybuk: dude, you still doing germinate stuff?
[10:41] <Keybuk> nope, Colin's been looking after that for a while now
[10:41] <bob2> |trey|: hoary contains nothing exciting atm
[10:41] <jdub> ok
[10:41] <|trey|> bob2, anything new = exciting... new features are fun  :)
[10:42] <jdub> tjere
[10:42] <jdub> there's nothing particularly featureish
[10:43] <daniels> bob2: http://www.livejournal.com/users/ajaxxx/33986.html
[10:44] <Keybuk> we're still very much resynchronising with Debian
[10:44] <bob2> daniels: hah, saw that
[10:44] <bob2> daniels: and liw* removed sex
[10:46] <robtaylor|away> amu: ping?
[10:50] <amu> robtaylor: pong
[10:50] <daniels> bob2: mmm
[10:50] <robtaylor> amu: hey :) have you seen the bug i logged about hotplug not working on the live cd?
[10:51] <robtaylor> amu: well, hal not working, but i'm pretty sure hal doesnt work cause hotplug isnt being run from the pivot_rooted root..
[10:55] <amu> robtaylor: strange, looks like matt thinks the same, i tried with a ext fs, looks working, but it wasnt automountet.  
[10:56] <robtaylor> amu: yeah  i cant quite figure whats wroing - i've but debug code in /sbin/hotplug on a running livecd system, and it never gets called
[10:56] <amu> hmm, i've still no idea, what's different if you compare a chroot or a "normal" sys 
[10:57] <robtaylor> amu: well doenst morphic pivot_root twice?
[10:57] <robtaylor> or is it chroot?
[10:57] <amu> pivot_root
[10:57] <robtaylor> right, so that uses a new namespace
[10:57] <robtaylor> its possible the kernel is trying to run hotplug in one of the other namespaces..
[10:58] <robtaylor> but the only problem with this hypothesis is that i find it hard to belive noones ever noticed hotplug not working...
[11:01] <amu> robtaylor: i think, thats should be problem for hotplug, doent matter at which time you insert you hardware, hotplugs job is loading the module, if you chroot to somewhat else, it should work also. Sounds funny if you chroot into a chroot and you have no disk left.         
[11:02] <amu> or a missing ethernet interface, cause of the chroot 
[11:02] <robtaylor> amu: yep, it'd definitly a bug if its not working they way we expect it to work..  it could be some 2.6 kernel bug and maybe only occus after two pivot_root, or some such obscureness
[11:02] <amu> probably hotplug is the (main) problem. 
[11:03] <robtaylor> amu: or are you saying you'd expect hotplug to run from the main system, not the pivot_rooted system?
[11:03] <robtaylor> amu: chroot is very different to pivot_root
[11:03] <amu> mdz: we should discuss a redesign :) i've some ideas    
[11:04] <amu> robtaylor: just a minute ...
[11:05] <robtaylor> amu: np :)
[11:09] <amu> robtaylor: your localtime 10:08 is correct ?
[11:09] <amu> ....i've to wait for mdz 
[11:10] <robtaylor> amu: yep :)
[11:11] <robtaylor> amu: ok. what's his TZ?
[11:12] <robtaylor> amu: so i dont get what you're saying.. are you saying that this is how hotplug works by design?
[11:12] <amu> probably : TIME reply from mdz: Thu Oct 28 02:10:11
[11:12] <sivang> hey sparkes
[11:13] <robtaylor> amu: ah , we'll be waiting a long time..
[11:14] <robtaylor> amu: i'm not convinced, as i see it a pivot_root call *should* change current->fs->root
[11:14] <amu> robtaylor: i tried with RC2, a ext3 on it, device is detected but not automounted. if i mount it by hand it works    
[11:15] <enrico> Hello, good morning.  I posted the question about Wiki contents licensing in the warthogs list some days ago, but I haven't got any answer.  However, it'd be important for the doc team to know about that
[11:16] <robtaylor> amu: if you run syslog, do you get any hotplug messages?
[11:17] <robtaylor> amu: bear in mind that morphix adds a fstab entry for sda1 by default
[11:17] <robtaylor> and that if the device is plugged in at boot, it gets detected by the coldplugging
[11:18] <amu> robtaylor: yap, without any error 
[11:19] <amu> robtaylor: impossible, if you run a scsi-sys, extern scsiCDrom, sata disks  
[11:19] <robtaylor> amu: well it should work. the coldplugging is just script running in whereever you did your /etc/rc.0/Sxxhotplug
[11:19] <robtaylor> amu: eh?
[11:20] <amu> ... sda1 by default   
[11:25] <robtaylor> amu: boto up the livecd with no scsi devices added, and /etc/fstab will have an entry for sda1. yes its broken.
[11:25] <robtaylor> amu: try it of you dont beleive me =)
[11:25] <amu> robtaylor: first thing i've to do, i must reach mdz. If he say ok, you spend much time as you need on this bug, thats fine for me. 
[11:26] <robtaylor> amu: if he says ok to what?
[11:27] <robtaylor> amu: right now the livecd is very broken... i dont see how you can release a warty livecd with no working hal..
[11:29] <amu> robtaylor: right, cause of this, i need mdz, the liveCd isnt designed for hal.  
[11:30] <robtaylor> ah
[11:30] <robtaylor> thats very broken then
[11:31] <amu> so there are some feature plans, but first we have to discuss them, fixing a bug is no problem, we should find a solution for feature development.   
[11:32] <jdub> enrico: it's being discussed
[11:33] <pitti> Can somebody please proofread an USN? TIA! https://chinstrap.warthogs.hbd.com/~pitti/usn-libxml.txt
[11:33] <enrico> jdub: where?
[11:34] <jdub> enrico: it was brought up off-list
[11:34] <robtaylor> amu: what's your plan?
[11:34] <amu> robtaylor: just hold on a little. btw. the FAT16 is orginal one with done with mkfs 
[11:34] <__daniel> pitti: i can't read it :-)
[11:34] <Keybuk> Kamion: do you want to double-check things like anna which have translation skew?
[11:34] <jdub> i don't think it'll last long there
[11:34] <pitti> __daniel: well, it's not yet public, so this is on purpose :-)
[11:34] <amu> s/one/one, or 
[11:34] <enrico> jdub: ah, I see.  Could you please keep me updated?   I took care of sorting this out
[11:35] <jdub> enrico: i don't think it'll be off-list for long
[11:35] <enrico> jdub: ok, I'll wait then.  At least now I know that my message didn't go ignored like I was thinking
[11:35] <robtaylor> amu: umm, i belive the 1st key key was created with syslinux.  the 2nd key used for testing is as-new
[11:35] <sivang> pitti : need password for that
[11:36] <pitti> sivang: it's only readable for canonical folks. Sorry, I posted in the wrong channel
[11:36] <sivang> pitti : ah nevermind :)
[11:36] <amu> robtaylor: with the existing packages, building the liveCD
[11:38] <amu> bbiab
[11:41] <sabdfl> jdub: saw your lsb-release upload
[11:41] <sabdfl> can we make that explicitly "development" please?
[11:42] <sabdfl> same for any other version indicators
[11:42] <sabdfl> i've added lsb-release to the ReleaseChecklist so we don't forget to set it correctly for release
[11:48] <sabdfl> jdub: ^^ ack?
[11:59] <fabbione> Keybuk: ping
[12:02] <jdub> sabdfl: ahr, yeah
[12:02] <sabdfl> jdub: cool
[12:03] <jdub> sabdfl: btw, was going to ask mdz, should we make it like this:
[12:03] <sabdfl> anywhere else we should do that?
[12:03] <jdub> DISTRIB_DESCRIPTION="Ubuntu (Hoary Hedgehog)" ?
[12:03] <jdub> or perhaps, given development
[12:03] <jdub> DISTRIB_DESCRIPTION="Ubuntu Development Branch (Hoary Hedgehog)" ?
[12:03] <sabdfl> The Hoary Hedgehog Release
[12:04] <jdub> DISTRIB_DESCRIPTION="Ubuntu, The Hoary Hedgehog Development Branch" ?
[12:04] <jdub> and then s/Development Branch/Release/ later on?
[12:04] <sabdfl> prefer the ()'s
[12:04] <jdub> ok
[12:04] <sabdfl> Ubuntu (The Hoary Hedgehog Release) Unfer Development
[12:05] <sabdfl> d
[12:05] <sabdfl> any is good
[12:05] <jdub> ok
[12:07] <Keybuk> fabbione: ello
[12:07] <seb128> jdub: gst-python has been upload (it's in NEW)
[12:07] <seb128> uploaded even
[12:08] <jdub> aha
[12:08] <jdub> rad
[12:08] <jdub> thanks
[12:08] <sabdfl> gst-python?
[12:09] <jdub> gstreamer
[12:09] <jdub> python bindings
[12:09] <robtaylor> ooh :)
[12:09] <jdub> which are used by FLUMOTION
[12:10] <sabdfl> nice
[12:10] <sabdfl> seems rather perfect for ubuntu
[12:10] <jdub> indeedy
[12:11] <jdub> hopefully i'll have flumotion in such a state that we can use it in december :)
[12:12] <jdub> ah, crap
[12:12] <jdub> lamont, elmo: ping?
[12:20] <fabbione> Keybuk: can you put back online the xfree86 diff from ubuntu1 up to ubuntu25 ?
[12:21] <Keybuk> as a single diff?
[12:23] <fabbione> if possible as separate diff it would be nice
[12:24] <Keybuk> http://people.ubuntu.com/~scott/xfree86-patches
[12:25] <fabbione> thanks
[12:25] <fabbione> 23 24 and 25?
[12:25] <jdub> NOOOOOOOO
[12:25] <jdub> argh
[12:25] <jdub> i thought we locked warty-updates
[12:26] <Keybuk> jdub: who uploaded what?
[12:26] <Kamion> Keybuk: yes please, where?
[12:27] <jdub> i uploaded hoary's lsb-release to warty
[12:27] <seb128>  lsb-release (1.4-7.1ubuntu5) warty; urgency=low
[12:27] <Kamion> jdub: hm, I thought we agreed 5.04 rather than 5.4 ages ago ...
[12:27] <Keybuk> Kamion: in about 10-15 minutes
[12:27] <jdub> Kamion: mdz seemed to think 5.4 yesterday
[12:27] <Kamion> jdub: yeah, I saw that
[12:27] <Keybuk> ugh, 5.4 is harder to compare than 5.04
[12:27] <Keybuk> we should try and be clear
[12:27] <Kamion> mkay
[12:28] <jdub> to be fair, 5.4 -> 5.10 is okay by dotversion comparison generally
[12:28] <Kamion> not that bothered, just surprised
[12:28] <Keybuk> descent scott% touch 5.10
[12:28] <Keybuk> descent scott% touch 5.4
[12:28] <Keybuk> descent scott% ls -1 5.*
[12:28] <Keybuk> 5.10
[12:28] <Keybuk> 5.4
[12:29] <jdub> Keybuk: that's numeric, not version :)
[12:29] <jdub> apache will sort it the right way :)
[12:29] <Keybuk> jdub: FTP won't though
[12:29] <sabdfl> 5.04 ould be more accurate
[12:29] <Keybuk> so anyone using a mirror, or grabbing via FTP, will pick the wrong one
[12:29] <seb128> 5.04 is better imho
[12:29] <fabbione> Keybuk: can you put online also 23, 24 and 25?
[12:29] <Keybuk> fabbione: cooking atm
[12:29] <fabbione> Keybuk: great!
[12:29] <jdub> non-date version numbers would be ideal! :)
[12:29] <sabdfl> jdub: nice
[12:30] <sabdfl> lucky it wasn't x.org :-)
[12:30] <jdub> yeah
[12:30] <jdub> has it hit the archive?
[12:30] <fabbione> eheheh
[12:30] <sabdfl> jdub: reactionary
[12:30] <jdub> dude
[12:30] <jdub> so far you have called me a terrorist and a reactionary
[12:30] <jdub> and that's just today
[12:31] <jdub> 'freedom fighter' is preferable ;)
[12:31] <fabbione> sabdfl: did you hear the news about x.org?
[12:31] <sabdfl> it's the hair
[12:31] <sabdfl> and the reactionary, terrorist attitude
[12:31] <sabdfl> "desktop icons" indeed
[12:31] <sabdfl> walk freely into the future dude!
[12:32] <sabdfl> let go!
[12:32] <sabdfl> fabbione: no?
[12:32] <fabbione> sabdfl: that it takes approx 60% more build resources that Xfree86?
[12:32] <Keybuk> fabbione: ok, up now
[12:32] <fabbione> Keybuk: cool!
[12:32] <jdub> sabdfl: i should point out that you didn't manage to express the whole scheme until a couple of weeks before the preview - had you done so, the changes would have been simple :)
[12:33] <sabdfl> which scheme?
[12:33] <fabbione> oh and that's with ccache :-)
[12:34] <sabdfl> fabbione: why?
[12:34] <jdub> sabdfl: no desktop icons at all, handle the problem elsewhere (ie. the panel changes were the result, not the goal)
[12:34] <fabbione> sabdfl: it's bigger.. it has more stuff inside.
[12:34] <fabbione> sabdfl: more extensions, mode libraries
[12:34] <fabbione> sabdfl: one server more
[12:34] <fabbione> (that i still need to figure what it does)
[12:35] <fabbione> Keybuk: i downloaded them. if you want you can remove the dir on people
[12:35] <fabbione> Keybuk: thanks a lot :-)
[12:35] <sivang> jdub:  che guevara ?
[12:35] <sabdfl> jdub: speaking of which, any candidate for the slicker "places" menu in both nautilus and panel?
[12:36] <sabdfl> jdub: find a win-xp box, and check out how they handle it
[12:36] <sabdfl> they have two icons sizes
[12:36] <sabdfl> and for their places menu they use the more compact one
[12:36] <jdub> sabdfl: yeah
[12:36] <sabdfl> which allows you to fit a lot in there
[12:36] <jdub> sabdfl: had some ideas, will run them by you
[12:36] <sabdfl> ok
[12:36] <jdub> sabdfl: oh, btw, you got time for a quick call?
[12:36] <sabdfl> we need to spec and bounty this 
[12:37] <sabdfl> jdub: sure
[12:37] <jdub> related stuff
[12:37] <pitti> any C guru around here?
[12:37] <pitti> can I always expect "long long int" to be (at least) 64 bit?
[12:38] <Keybuk> sabdfl: nautilus, panel *and* GtkFileChooser please <g>
[12:39] <jdub> yeah, those will all be integrated
[12:39] <sabdfl> Keybuk: absoloodle
[12:40] <jamesh> pitti: on interesting platforms yes, but in general you can't rely on "long long" existing (it was only standardised in C99, iirc)
[12:40] <jdub> Subject: Porposing libgnomesu for 2.10
[12:40] <jdub> ^ dolphins in gnome 2.10, good for ubuntu :)
[12:40] <Keybuk> plus I don't think C99 actually specifies a size anyway
[12:40] <pitti> jamesh: I need a reliable way to detect overflow of multiplication of two 32-bit-ints
[12:40] <Keybuk> "longer than a long int" is about as far as it goes
[12:41] <seb128> jdub: I've uploaded libgnomesu in debian yesterday
[12:41] <jdub> cool
[12:41] <Mithrandir> pitti: use int_64 or whatever it's called?
[12:41] <robtaylor> jdub: libgnomesu?
[12:41] <pitti> Keybuk: any better method to check for integer multiplication overflow?
[12:41] <Keybuk> pitti: asm
[12:41] <pitti> Mithrandir: oh, if that exists and is portable?
[12:41] <jdub> robtaylor: see the post, it's kinda what the library name implies ;)
[12:41] <jamesh> pitti: there is some code in Python's int class to do that portably
[12:42] <Keybuk> pitti: there's also imaxdiv in C99
[12:43] <Mithrandir> pitti: uint64_t
[12:43] <Mithrandir> afaik, it's portable.
[12:43] <pitti> Mithrandir: thanks, this is great
[12:43] <pitti> Keybuk: thanks as well, now I have some ideas
[12:43] <jamesh> pitti: the Python code uses floating point multiplication and compares the result with an integer multiplication.
[12:44] <robtaylor> jdub: ah, nothing too exciting then..
[12:44] <pitti> jamesh: hmm, that's a bit ugly but could be a last resort
[12:45] <robtaylor> though if gnome apps standardise on using libgnomesu, that'll make integration nice an easy :)
[12:45] <pitti> Keybuk: sivang is right, http://gcc.gnu.org/onlinedocs/gcc/Long-Long.html says it's 64 bit minimum
[12:45] <pitti> Keybuk: but I think uint64_t is nicer
[12:46] <Mithrandir> pitti: I could see if it exists on irix, if we have the SGI compiler there.. if it exists there, it exists everywhere ;P
[12:46] <pitti> Mithrandir: well, above link is just for gcc...
[12:46] <jamesh> pitti: how portable does it really need to be?
[12:46] <pitti> Mithrandir: which would be okay for a security fix, however, I'm interested in a generic solution
[12:46] <pitti> jamesh: it's just a security fix for Ubuntu
[12:46] <jamesh> I mean, long long is available on pretty much all modern systems.
[12:46] <jamesh> ah.
[12:46] <pitti> jamesh: so gcc is enough
[12:47] <sivang> tseng : gemme the apt source for tomboy :)
[12:48] <Keybuk> pitti: sizes are *officially* implementation defined, but I suspect all unixes define long long as at least 64-bits :)
[12:48] <pitti> Keybuk: I think I will rely on uint64_t. The advantage is, if it does not exist on a platform, you get a compiler error
[12:49] <Keybuk> indeed
[12:49] <pitti> Keybuk: instead of making it silently work
[12:49] <sivang> pitti : or loose bits off at a functino call :)
[12:49] <pitti> sivang: this is indeed the critical part
[12:49] <jamesh> Keybuk: I thought they had some set minimums for certain sizes though.
[12:49] <Keybuk> pitti: long long is defined as being "at least as wide as long"
[12:49] <pitti> I currently need to fix libgd2, and it uses malloc(width*height) style
[12:49] <jamesh> certain types, even.
[12:49] <Keybuk> jamesh: god no, that'd limit C to 8-bit architectures
[12:49] <pitti> both width and height are 32 bit
[12:50] <Mithrandir> seems to exist on IRIX 6.5 just fine.
[12:50] <pitti> so I want to multiply into a 64 bit int, then compare against UINT_MAX or so
[12:50] <Kamion> Title             Comp.compilers: Re: ANSI portable overflow detection
[12:50] <Kamion> Current URL       http://compilers.iecc.com/comparch/article/94-05-045
[12:50] <sivang> Mithrandir : you have access to an IRIX ? cool
[12:50] <Keybuk> 32-bit machines "long int" and "int" are the same width, 16-bit "long int" is twice as wide as "int" for example (generally speaking)
[12:50] <Mithrandir> sivang: for some value of cool, sure. ;)
[12:50] <Mithrandir> just an old indigo 2, though
[12:51] <sivang> Mithrandir : what's hardware is it running on?
[12:52] <sivang> Mithrandir : desktopish like? 
[12:52] <jamesh> on ILP32 systems, int and long int are the same :)
[12:52] <jamesh> good thing there aren't many LP32 ones.
[12:52] <Mithrandir> a 250MHz R4400, the box itself is a bit biggish desktop case.
[12:52] <pitti> jamesh: why, int and long int are the same also on i386
[12:53] <jamesh> pitti: i386 is ILP32 (== ints, longs and pointers are 32-bit)
[12:53] <Keybuk> pitti: in fact, obviously now I think about it, LP64 and ILP64 architectures have "long int" as 64-bit
[12:53] <pitti> jamesh: ah
[12:53] <pitti> Keybuk: right, but my numbers are explicitly declared as 32-bit ones
[12:53] <Mithrandir> Keybuk: what arches are ILP64?
[12:53] <jamesh> Keybuk: and Windows 64 is neither LP64 or ILP64 ..
[12:54] <Keybuk> LLP64?
[12:54] <jamesh> yeah
[12:54] <jamesh> longs are smaller than pointers on win64.
[01:08] <rburton> jdub: plop
[01:08] <thom> fabbione: theme song for the X Sprint: "happiness is free when you lose your mind"
[01:13] <seb128> hey rburton 
[01:13] <rburton> hi seb128 
[01:15] <jdub> rburton: grr, on phone, and have to go away for a couple of hours
[01:15] <jdub> rburton: will ping when i get back
[01:15] <rburton> jdub: k :)
[01:24] <sabdfl> seb128: how does the trash applet use the keyring?
[01:25] <sabdfl> hmm... does it make sense to but 5.04 in for hoary now?
[01:25] <sabdfl> what if gnome slips?
[01:25] <seb128> ? I don't understand the question ? It uses it in the same way as the other GNOME apps do ...
[01:25] <sabdfl> seb128: how is that?
[01:27] <seb128> there is a gnome_authentication_manager_init () to call and the GNOME libs do all the work
[01:32] <jamesh> sabdfl: before adding the gnome_authentication_manager_init(), I'd need to check all the sync. gnome-vfs calls
[01:33] <jamesh> since you can get a deadlock if you do a synchronous vfs call while holding the GDK lock and gnome-vfs wants to pop up an auth dialog.
[01:34] <seb128> jamesh: ? I've already uploaded a trashapplet using it, is there a problem ?
[01:34] <jamesh> seb128: possibly.
[01:34] <seb128> hum, ok
[01:35] <jamesh> seb128: basically, an app using gnome-authentication_manager_init() needs to be a threaded GTK program
[01:35] <seb128> let me know if you get a problem, seems to work fine here
[01:35] <jamesh> (normally, no GTK calls are made in gnome-vfs's worker threads so you don't need to turn on GTK threading(
[01:35] <jamesh> but the auth dialogs change that.
[01:36] <seb128> ok. How do you check there is no problem so ?
[01:37] <jamesh> well, all idles and timeouts that make GTK calls need to call gdk_threads_enter() and gdk_threads_leave()
[01:37] <Kamion> sabdfl: if we have to remove the Under Development thing anyway, we've got time to change it
[01:38] <jamesh> and all sync gnome-vfs calls need to be surrounded by gdk_threads_leave() and gdk_threads_enter().
[01:39] <Keybuk> sabdfl: then we slip and change to 5.05 :)
[01:39] <sabdfl> Kamion: ok, i was just thinking we should maybe put no version number in there while it's under development
[01:39] <fabbione> thom: lol
[01:40] <seb128> jamesh: ok
[01:46] <jamesh> seb128: I'll look at it tomorrow.  I also noticed that the trash applet wasn't resizing quite right too, which should be pretty easy to fix.
[01:50] <seb128> yes, there is a bug open about this
[01:51] <seb128> the resizing is not correct with some panel width
[01:52] <fabbione> UUHAA
[01:52] <fabbione> and another bit is fixed
[01:52] <pitti> Can somebody please review the patch for #2810?
[01:53] <pitti> Mithrandir: since you are a security crack, mind to have a look? ^
[01:58] <jono> is there a guide to writing FDI files for HAL anywhere?
[01:58] <pitti> jono: hal-doc contains a decent specification
[01:58] <thom> look at an existing one, change what you need? they're very simple
[01:59] <jono> cool :)
[02:01] <sivang> what are FDI files?
[02:01] <sivang> FreeDesktop something?
[02:04] <sivang> oh, these are probably the XML dockies for hardware specs or hal behavior..
[02:07] <lamont> any french speakers here?
[02:07] <tseng> sivang: gimme? no thanks
[02:07] <tseng> sivang: and its up there
[02:07] <lamont> "Il faut combien pour une mini-tour PC pour ubuntu et/ou serveur debian?"
[02:07] <tseng> sivang: minor bug in it, missing a ) in debian/control i havent gotten to yet
[02:08] <lamont> I think I understand it, but not sure.
[02:08] <sivang> tseng : I installed it on my other machine yesterday, hornbeck provided me with the sources URLs ..It worked very nicely IMHO
[02:09] <tseng> ok
[02:09] <sivang> tseng : you would like me to use proper english ? :)
[02:09] <tseng> please works.
[02:10] <sivang> tseng : oh sorry :( didn't notice I forgot that in the hurry of typing.
[02:10] <tseng> nps
[02:11] <fabbione> lamont: ask seb128 :-)
[02:11] <fabbione> lamont: or msg bubulle 
[02:11] <seb128> hum
[02:11] <lamont> fabbione: yeah - was hoping he'd show up..
[02:12] <fabbione> see
 "Il faut combien pour une mini-tour PC pour ubuntu et/ou serveur debian?"
[02:12] <seb128> lack of contexte
[02:12] <fabbione> he works only on my summon :-9
[02:12] <lamont> seb128: or I could forward you the email and you could reply in french....
[02:12] <lamont> talking about liveCD
[02:12] <seb128> he's probably asking which kind of configuration he needs to run ubuntu (mini-tower or server)
[02:13] <seb128> or it could be "how much does it cost to get a working config for ubuntu" .. but probably that's probably the first option
[02:13] <seb128> lamont: feel free to forward any french mail if you want
[02:14] <seb128> ok
[02:14] <lamont> seb128@c.c?
[02:14] <seb128> yes
[02:14] <lamont> sent
[02:20] <pasc> that's a weird way of phrasing it though. It literally means "You need how much for a mini-tower PC for ubuntu and/or a debian server"
[02:20] <sivang> up
[02:22] <lamont> could be asking for system specs?
[02:22] <lamont> kids->school.  bbl
[02:24] <fabbione>   * Remove xprt, libxp6-* and libxp-dev packages.
[02:24] <fabbione> AHHH
[02:25] <thom> it *really* doesn't like ESSIDs with spaces
[02:28] <pitti> thom: please fix it! My ESSID at home has a space :-/
[02:30] <seb128> lamont: that's what I was saying, he's probably asking for the minimal hardware requirements ... do we have "official" requirements ?
[02:32] <sjoerd> pitti: the plugdev group, does that have read/write permissions or only read ?
[02:32] <pitti> sjoerd: r/w
[02:32] <pitti> sjoerd: it's similar to 'disk'
[02:32] <thom> pitti: so does mine, so I will
[02:33] <sjoerd> pitti: why is write permission usefull?
[02:33] <pitti> sjoerd: users are able to partition, format and label devices
[02:34] <sjoerd> hmmm
[02:34] <pitti> sjoerd: you can start with having the device nodes 640, if you like
[02:34] <T-Bone> hi
[02:34] <pitti> sjoerd: but I think Marco should device that, as udev maintainer :-)
[02:34] <pitti> Hi T-Bone
[02:35] <sjoerd> pitti: oh i'm just wondering how it all works out.. i wouldn't really want all users who can mount, to also be able to have direct write perms
[02:36] <pitti> sjoerd: well, they can do pretty much anything with USB devices anyway
[02:37] <jono> where are the fdi files in ubuntu located?
[02:38] <sjoerd> pitti: the user can, not the programs running as user
[02:39] <pitti> sjoerd: we wanted to keep it compatible to 'disk', but if Debian wants to have the permissons as 640, Ubuntu can adopt this, too
[02:40] <pitti> sjoerd: personally, I don't have a very strong preference, but I like to be able to partition my devices without becoming root
[02:40] <rburton> jono: i imagine /usr/share/hal/fdi
[02:40] <pitti> sjoerd: also, hal will not be able to change device labels without write permission as plugdev
[02:40] <pitti> sjoerd: according to the reply to my question on the hal list, hal will support that 
[02:41] <sjoerd> i know
[02:41] <sjoerd> i'm not really happy with it though
[02:42] <pitti> sjoerd: I would have preferred a database maintained by g-v-m
[02:42] <sjoerd> pitti: explain
[02:42] <pitti> sjoerd: but it would only apply to one host and not to other OS
[02:43] <pitti> sjoerd: instead of writing the device label to the device, g-v-m could maintain a persistent mapping UUID -> label
[02:43] <pitti> sjoerd: s/writing/using/
[02:43] <sjoerd> one could do that mapping in hal, user specific fdi's would be nice for that
[02:43] <sjoerd> for the labelling, why not have an external program that signals hal to reread the label
[02:44] <pitti> sjoerd: in fact storing the labels in hal (persistently in /var/lib/hal or so) was my idea
[02:44] <rburton> (speaking of which, any idea how to change the label on vfat without booting windows)
[02:44] <pitti> sjoerd: and the reason why I asked on the ML whether hal supports persistent keys
[02:44] <jono> are these fdi files probed each time you plug a device in?
[02:44] <sjoerd> pitti: sorry forgot the exact reasoning :)
[02:44] <sjoerd> jono: yes
[02:45] <pitti> sjoerd: both approaches have pros and cons
[02:45] <jono> sjoerd, does it load each file one by one and check the pci/usb id?
[02:45] <pitti> sjoerd: device labels are very limited, but aren't restricted to one host
[02:46] <sjoerd> pitti: long time ago there was a discussion about the exact goal of hal.. and one of the outcomes was that hal wasn't ment as system configurator
[02:46] <pitti> sjoerd: I always understood it as hardware database
[02:46] <pitti> sjoerd: so I think persistent keys fit into the idea
[02:47] <sjoerd> pitti: so why they want to put labelling inside...
[02:47] <jono> how can I probe the vendor id and device of a usb device?
[02:48] <sjoerd> jono: at which level ? hal can tell you those 
[02:48] <pitti> sjoerd: don't ask me...
[02:48] <pitti> sjoerd: I would prefer hal to stay read-only
[02:48] <pitti> sjoerd: this would fit with the host-based database of device labels
[02:48] <jono> ahhh it says them in the device manager - I am writing an fdi file for my mouse
[02:48] <sjoerd> pitti: i'm not asking you, i'm explainig why i find it weird :)
[02:48] <pitti> sjoerd: sorry
[02:48] <sjoerd> pitti: i'm probably not completely clear, my fault 
[02:50] <sjoerd> pitti: we don't have to follow hal in the labelling part though.. 
[02:51] <sjoerd> hal upstream thatis
[02:51] <pitti> sjoerd: right
[02:51] <pitti> sjoerd: but if we use the physical device labels, the user still needs to have write access to the device
[02:51] <pitti> sjoerd: (the label writing could be done by another process)
[02:52] <sjoerd> true
[02:52] <sid77> hi
[02:52] <sjoerd> pitti: but to give the user full write access, just for labelling..
[02:52] <pitti> sjoerd: and partitioning, and formatting
[02:54] <sjoerd> still.. well need to think about it, i guess
[02:55] <pitti> sjoerd: yes
[02:55] <pitti> sjoerd: I'm currently drowning in work, not really the best time to make design decisions... :-(
[02:55] <pitti> sooo many security bugs...
[02:56] <sjoerd> pitti: no need to rush into things, better to wait some time and do it right :)
[02:56] <pitti> agreed :-)
[03:00] <pitti> fabbione: still no luck with the damn beast^W^WX.org?
[03:00] <fabbione> pitti: i have done 70% of the boring job
[03:00] <pitti> congrats
[03:00] <fabbione> now i am working on trying to figure out all the changes
[03:00] <fabbione> pitti: "boring"
[03:01] <pitti> fabbione: you mean reviewing the 300K+ lines changes?
[03:01] <fabbione> once we take that away it comes all the messy part
[03:01] <fabbione> pitti: i finished that 2 days ago :-)
[03:01] <fabbione> that was easy
[03:01] <pitti> oh
[03:01] <fabbione> the boring part is to reallign the MANIFEST checks
[03:01] <fabbione> and to see what is changed across the entire tree
[03:01] <pitti> I did nothing else that reading patches and doing security uploads in the last days, I did not listen to any news :-(
[03:01] <fabbione> like for example check why fonts were not build properly
[03:02] <fabbione> or why all of a sudden libXaw.a is not shipped anymore
[03:02] <fabbione> and it takes forever to do a test build
[03:02] <fabbione> to see if the flags you change will put the stuff back
[03:03] <fabbione> robtaylor: xfree86 is a nice walk compared to x.org
[03:03] <fabbione> x.org takes 60% more time to build
[03:03] <fabbione> time and space actually
[03:03] <robtaylor> fabbione: oh no! i thought it was supposed to be getting better!!
[03:04] <pitti> robtaylor: ever saw a new upstream version that was leaner and faster than it's predecessor? :-/
[03:04] <robtaylor> fabbione: any ideas why? is x.org still using imake or have they transitioned to autotools now?
[03:04] <fabbione> robtaylor: not when tons of people have cvs commit to it
[03:04] <robtaylor> pitti: heheh good point ;)
[03:04] <fabbione> robtaylor: the problem is not Imake or autocrap
[03:04] <pitti> robtaylor: about the only thing that would possibly help was to rewrite it from scratch
[03:04] <fabbione> robtaylor: the problem is the amount of (useless) code that has been committed
[03:04] <pitti> robtaylor: but not for Hoary then... :-)
[03:04] <fabbione> and i am pretty sure there is something badly wrong with the build system
[03:05] <robtaylor> pitti: i thought that was the plan.. ;) 
[03:05] <pitti> sjoerd: oh, providing a wrapper around pmount is really a good idea
[03:05] <fabbione> because i noticed that timestamps are not in order as they should
[03:05] <fabbione> and the build dir is full of .bak files
[03:05] <robtaylor> fabbione: quit epossible, thats why i asked if they'd transitioned yet
[03:05] <pitti> sjoerd: it should be in a package pmount-hal or so
[03:05] <fabbione> robtaylor: but i don't have this problem with Xfree86
[03:05] <fabbione> so it must be something they introduces recently
[03:05] <robtaylor> probably :(
[03:05] <robtaylor> check the changelog for anything suspicious..
[03:06] <fabbione> robtaylor: one thing at a time :-)
[03:06] <robtaylor> heh
[03:06] <fabbione> point is that they didn't check what they checked out of xfree86
[03:06] <fabbione> and their cvs is kinda borked
[03:06] <fabbione> so it's not even easy to do so
[03:06] <robtaylor> uurgh
[03:07] <fabbione> for example...
[03:07] <fabbione> the Imakefiles.inc in xc/fonts/bdf/75dpi
[03:07] <fabbione> that one is 4 and half years old
[03:07] <fabbione> and buggy
[03:07] <fabbione> but the one in xfree86 (still the real free version)
[03:07] <fabbione> is 1 year old
[03:07] <fabbione> and it works fine
[03:08] <fabbione> so i suspect that their fork hasn't been done properly
[03:08] <fabbione> at all
[03:09] <robtaylor> oh god. thats just horrific
[03:10] <Keybuk> http://people.ubuntu.com/~scott/merge/review/
[03:10] <Keybuk> (and read http://people.ubuntu.com/~scott/merge/README)
[03:11] <robtaylor> daniels: explain yourself, man!
[03:13] <robtaylor> Keybuk: out of interest, on avarage, how well have warty patches made it back upstream?
[03:13] <fabbione> Keybuk: SEXY!
[03:14] <fabbione> Keybuk: drop xfree86
[03:14] <fabbione> don't even spend time on it
[03:15] <Keybuk> robtaylor: reasonably, maybe half of them
[03:15] <Keybuk> fabbione: sure, those are for everyone else to spend time on :)  I've done 150 :p
[03:15] <Keybuk> just ignore it
[03:16] <fabbione> Keybuk: sure.. i was helping :-)
[03:17] <Keybuk> robtaylor: one nice thing about this is we end up with a fresh set of patches to ping people with
[03:17] <Keybuk> (after we've filtered out branding and so-on)
[03:19] <Kamion> Keybuk: might want to deal with things like the removal of vi.po throughout d-i
[03:19] <Keybuk> heh, yeah I noticed that one <g>
[03:19] <Kamion> Keybuk: (it was removed in Debian because it wasn't well-enough maintained, but your hoary patch adds it back in)
[03:19] <Keybuk> I deliberately ignored debian-deletion of translations
[03:19] <Keybuk> just incase you screamed at me
[03:19] <Kamion> also, uh, debian/templates seems to be added back in for anna?
[03:20] <Kamion> I bet it's called anna.templates now
[03:20] <Keybuk> there's a reason those are all in "review" :o)  they need a human to check them because the automatic stuff went "uhh..." at them
[03:20] <Kamion> which will probably require .po changes
[03:20] <Kamion> ok, fair enough
[03:20] <Keybuk> it'd be good if people could note what they had to fix as well, because then we can fix that kind of stuff automatically next time
[03:21] <robtaylor> Keybuk: good going :)
[03:21] <Kamion> Keybuk: ready/kbd-chooser/ has the same problem with ga.po and vi.po though
[03:22] <Kamion> might want to add an "uhh..." when Debian deletes a translation
[03:22] <Keybuk> ah, ok, I'll fix that one manually
[03:22] <fabbione> cache hit                         129731
[03:23] <fabbione> (btw ccachetop rocks)
[03:24] <Keybuk> Kamion: ok, does kbd-chooser look right now?
[03:26] <Kamion> Keybuk: I think that UML-addition hunk is a duplicate
[03:26] <Kamion> Keybuk: that code got merged in Debian
[03:26] <Kamion> Keybuk: note the diff -p header
[03:27] <Keybuk> yeah was just noticing that
[03:27] <Kamion> the only change should be the high->critical bit, I think
[03:32] <Kamion> nice work, though :)
[03:33] <robtaylor> amu: well, i've been grokking kernel sources all day, and as far as i can tell the rootfs of the kernel helper thread that start the process that execve's to /asbin/hotplug should have had its root changed by pivot_root...
[03:34] <Kamion> robtaylor: I'm missing context; but you don't have /sbin/hotplug in the initrd do you?
[03:34] <robtaylor> amu: so either a) the hypothesis is wrong or b) its a subtle kernel bug
[03:35] <robtaylor> Kamion: context is http://bugzilla.ubuntu.com/show_bug.cgi?id=2758
[03:35] <robtaylor> bascially on the livecd, /sbin/hotplug doesnt seem to ever get called
[03:36] <robtaylor> (except when coldplugging)
[03:36] <Kamion> might be worth making sure /sbin/hotplug only exists in the final pivot_rooted filesystem
[03:37] <robtaylor> Kamion:  might be, but even then, if the kernel helper thread has the wrong fs->root, then its'll fail to execve it..
[03:39] <Kamion> true
[03:39] <Kamion> was thinking more of the problem I had last night where udevd was running in the wrong root
[03:39] <Kamion> thereby making it hard to umount it
[03:39] <robtaylor> Kamion: it does appear that minimod has /sbin/hotplug
[03:39] <robtaylor> Kamion: intersting.. how did you reach that state?
[03:40] <robtaylor> Kamion: wow. late lunch!
[03:40] <thom> hrm, lunch sounds like a stunning plan
[03:44] <Micksa> oh my
[03:44] <Micksa> I just came home to the cow screensaver on the live cd :)
[03:44] <Micksa> welp, apart from a few glitches, it's looking good guys
[03:49] <pitti_> pitti_: can I read this?
[04:02] <Kamion> robtaylor: I only started at about 11
[04:03] <Kamion> robtaylor: I had all the hotplug and udev infrastructure in the initrd; you pretty much have to, because of the way d-i's early putting-itself-together process works
[04:03] <Kamion> robtaylor: so a hotplug event fired just after init started, and triggered udevsend, which started udevd before /sbin/init got around to doing pivot_root
[04:07] <Keybuk> Kamion: btw, is there any consideration for binaries in d-i?
[04:08] <Keybuk> I suspect there won't be an issue, because it's written to be tiny and not depend on anything in /usr anyway
[04:08] <Kamion> Keybuk: what do you mean?
[04:08] <Kamion> oh, you mean something written in C? go ahead, shouldn't be a problem
[04:09] <Keybuk> yeah, something small and fast
[04:11] <fabbione> robtaylor: got it! the install targets relinks all the binaries around!
[04:11] <fabbione> creating all .bak files
[04:11] <fabbione> that's so SAD
[04:14] <Kamion> somebody make hotplug's init script less insanely verbose, too
[04:14] <Kamion> it's really ugly as d-i starts now
[04:15] <Kamion> hmm. it's safe to run /etc/hotplug/*.rc start multiple times, isn't it?
[04:15] <sladen> daniels: to you have a handied separated copy of the -noswitchvt patch ?
[04:16] <robtaylor> Kamion: should be
[04:17] <Kamion> good, I'll need that
[04:18] <robtaylor> Kamion: hmm, but for you, after the pivot_root, its running the /sbin/hotplug in the pivoted root?
[04:19] <Micksa> is it just me or is the teams' development process maginificently streamlined?
[04:20] <robtaylor> fabbione: thats pretty grim
[04:25] <Kamion> robtaylor: yep, definitely
[04:25] <Micksa> anyway, how can I find out about the team's development methods? is there much info on the wiki or whatever?
[04:29] <Kamion> apart from {WartyWarthog,HoaryHedgehog}/ReleaseSchedule and the various plans and meeting agendas and stuff, we mostly just do stuff and try not to get in each others' way :-)
[04:29] <Micksa> well
[04:29] <Micksa> okay
[04:29] <Micksa> that was anti-climactic :)
[04:30] <Micksa> has some sort of structure/procedures/etc arisen out of that?
[04:30] <lifeless> yeah, cutting code :)
[04:30] <Micksa> heh, okay
[04:31] <Micksa> so basically it comes down to you people generally knowing how to Get Shit Done
[04:31] <Micksa> guess it helps that you can all cut code in your sleep huh :)
[04:39] <Micksa> uhm, is the wiki on ubuntulinux.org public?
[04:39] <lifeless> I hope so :)
[04:40] <Kamion> yes, but you need to log in
[04:40] <lifeless> what sort of tree?
[04:40] <Micksa> to log in you need an account right? :)
[04:41] <Micksa> ahem. I can't find the "create new account" thingy, if there's meant to be one
[04:42] <lifeless> dude.
[04:42] <lifeless> oh, has it gone to zwiki yet ?
[04:42] <lifeless> is it a moin moin or a zwiki you are seeing ?
[04:43] <Micksa> zwiki
[04:43] <lifeless> ah, no idea.
[04:44] <Micksa> :) okay
[04:44] <Micksa> phew, I thought I was about to be LARTed into next week
[04:45] <jdub> rburton: around?
[04:45] <rburton> jdub: yes
[04:45] <jdub> jabber keeps kicking me off
[04:45] <jdub> gar
[04:45] <jdub> excellent
[04:45] <jdub> home?
[04:45] <rburton> aye
[04:57] <lamont> jdub: why does clicking on the terminal icon on the panel give me _2_ terminal windows?
[04:59] <robtaylor> Kamion: boh.. well this livecd issue is looking weirder by the minute.. i'm tempted to blame mini_fo =)
[05:03] <pitti> sjoerd: I'm currently at fixing pmount
[05:03] <pitti> sjoerd: if pmount shall get a "-t" option for specifying the fs type
[05:03] <pitti> sjoerd: what shall pmount then do with the mount options?
[05:04] <pitti> sjoerd: currently it uses appropriate mount options for each file system type (i. e. whether it supports rw, uid=, etc.)
[05:04] <sjoerd> pitti: with the other mount options you mean ?
[05:04] <pitti> sjoerd: yes, like -o uid=1000 or so
[05:04] <pitti> sjoerd: some file systems don't support them and will fail to mount
[05:04] <Micksa> ah, I see. the doc team are establishing a structure in the new wiki.
[05:04] <pitti> sjoerd: so either I keep a mapping of valid file systems and only allow keys of this mapping as -t
[05:05] <pitti> sjoerd: s/so either/A solution would be that/
[05:05] <pitti> sjoerd: any better idea?
[05:05] <sjoerd> pitti: i guess that's the best 
[05:06] <sjoerd> pitti: letting the calling process indicate the options is insecure, so the only way is internal
[05:06] <pitti> sjoerd: ?
[05:07] <pitti> sjoerd: please try to reexplain that, my brain is already very boiled today :-(
[05:07] <sjoerd> pitti: your solutions is doing it internal, map the given filesystem to sane options right..
[05:07] <pitti> sjoerd: yes, that was my intention
[05:07] <pitti> sjoerd: if no -t is specified, I try every entry in succession
[05:07] <sjoerd> pitti: doing it !internal -> external, would be to have for example the calling process specify the options
[05:07] <pitti> sjoerd: if -t is specified, I look it up (and fail if it is not found)
[05:08] <sjoerd> but that's insecure
[05:08] <pitti> sjoerd: I still don't understand
[05:08] <pitti> sjoerd: you mean that I put the mapping into a conffile?
[05:09] <Micksa> hrmyes.
[05:09] <Micksa> oops
[05:09] <pitti> sjoerd: what do you mean with "external mapping"?
[05:10] <sjoerd> pitti: external == something else then pmount :)
[05:10] <pitti> sjoerd: but then pmount had to check the options for validity
[05:10] <sjoerd> yep, so that sucks 
[05:10] <pitti> sjoerd: there really isn't much you can change
[05:11] <pitti> sjoerd: apart from sync/async
[05:11] <sjoerd> hence your option is the best :)
[05:11] <pitti> sjoerd: also, it does not require to parse something :-?
[05:12] <hornbeck> what happened to the new wiki?
[05:12] <hornbeck> nevermind I guess my settings got changed
[05:14] <sjoerd> pitti: btw do you want to package a hal-pmount wrapper seperate from pmount? 
[05:14] <pitti> sjoerd: I don't want the core pmount package depend on hal
[05:14] <pitti> sjoerd: because it is also useful without hal at all
[05:15] <sjoerd> s/hal/libhal{,-storage}0
[05:15] <pitti> sjoerd: so the source package could produce another .deb (arch-all) which depends on pmount and hal
[05:17] <pitti> :w
[05:17] <sjoerd> my first choice would be to implement it in C.. there are no language bindings for the hal libs
[05:17] <pitti> argh, wrong window
[05:17] <sjoerd> hehe
[05:17] <pitti> sjoerd: not? there is hal-get-property, not?
[05:17] <pitti> sjoerd: you mean there is no shell binding for hal-storage?
[05:18] <sjoerd> ok, you could call that a binding.. 
[05:18] <pitti> sjoerd: I actually thought of a simple shell wrapper
[05:18] <pitti> sjoerd: well, python would be okay, too :-)
[05:19] <sjoerd> then you have the language bindings problem.. you can talk to hal directly like h-d-m, but still
[05:19] <pitti> sjoerd: hmm, we should start with a shell wrapper
[05:19] <sjoerd> maybe it's simple enough to be plain shell, haven't thought about it enough
[05:19] <pitti> sjoerd: if it gets too clumsy, we can change the language at any time
[05:20] <sjoerd> pitti: agreed
[05:20] <pitti> sjoerd: so it shouldn't actually do more than specify (or not) --async and the device label, right?
[05:20] <pitti> sjoerd: sounds like a four-line script by now
[05:22] <sjoerd> hmmm.. the default policy defines more options, probably not usefull for us
[05:22] <pitti> sjoerd: which options?
[05:22] <sjoerd> nosuid, noexec, noauto, ro
[05:22] <sjoerd> first three are obvious
[05:23] <pitti> sjoerd: hmm, pmount policy fixes this
[05:23] <sjoerd> yeah, so their useless for us
[05:23] <pitti> sjoerd: not only for us - allowing suid mounts is kind of insane...
[05:24] <mdz> morning
[05:24] <sjoerd> pitti: fstab-sync isn't very sane :p
[05:24] <sjoerd> pitti: to be serious, it's indeed just sync and suggested label for now.. so a shell script should do the trick
[05:24] <pitti> sjoerd: don't tell me that fstab-sync currently respects the nosuid value from hal!
[05:25] <sjoerd> pitti: i won't say a word about that then :)
[05:25] <pitti> :-)
[05:25] <pitti> whoever... nevermind
[05:26] <mdz> pitti: no, no approval is needed for syncs at this stage, just verify against the changelog
[05:26] <pitti> mdz: oh, good morning!
[05:26] <pitti> mdz: okay, good to know
[05:26] <daniels> robtaylor: i'm not responsible for imake; right now, I'm leading the charge to kill the monolithic tree.
[05:27] <pitti> mdz: BTW, do you know how to get a CAN number?
[05:27] <robtaylor> daniels: i know, i was just teasing you ;)
[05:27] <mdz> pitti: in most cases I can assign one
[05:27] <pitti> mdz: I already mailed cve@mitre.org to get one for #2808
[05:27] <pitti> mdz: but I did not get an answer so far
[05:27] <mdz> however, if a vulnerability is publicly known, it must be assigned by MITRE in order to avoid duplicate assignments
[05:27] <daniels> robtaylor: heh
[05:28] <mdz> pitti: I usually mail  "Steven M. Christey" <coley@mitre.org>
[05:28] <pitti> mdz: hmm, it's on bugtraq, I guess that counts as public
[05:28] <robtaylor> mdz: that livecd bug's just looking worse by the day :/
[05:28] <pitti> mdz: hmm, I followed the FAQ and mailed cve@
[05:28] <mdz> robtaylor: which one?
[05:28] <mdz> pitti: they probably go to the same place
[05:28] <pitti> mdz: what do you think, shall I upload the package without a CAN or wait?
[05:28] <robtaylor> mdz: http://bugzilla.ubuntu.com/show_bug.cgi?id=2758
[05:29] <mdz> robtaylor: I didn't realize until that bug that the live CD wasn't running in the real root
[05:29] <mdz> it was impossible to fix in time
[05:29] <robtaylor> mdz: yeah, whats the plan going forward?
[05:29] <mdz> pitti: wait, the bug is not serious
[05:29] <mdz> robtaylor: fix it :-)
[05:30] <pitti> mdz: well, if you trust your ISP, it is not really serious
[05:30] <pitti> mdz: but ppp is very common also with p2p connections
[05:30] <robtaylor> mdz: its a bit weird, tho, i cant see why the kernel isnt running the current /sbin/hotplug
[05:30] <pitti> mdz: so I would still like to fix that in warty; you don't?
[05:31] <robtaylor> mdz: it just executes it in the context of the kernel helper thread, which should have had its root changed by pivot_root
[05:31] <mdz> robtaylor: it is running the only one it could possibly choose, the real one
[05:31] <mdz> the CD doesn't use pivot_root, no? that's the whole problem
[05:31] <mdz> pitti: what kind of p2p connections?
[05:31] <robtaylor> mdz: ah, it doesnt? that would explain it.. what is it doing?
[05:32] <pitti> mdz: not the warez ones :-)
[05:32] <mdz> robtaylor: chroot
[05:32] <mdz> robtaylor: as I discussed in the bug
[05:32] <robtaylor> mdz: ahhhh....
[05:32] <mdz> either that one, or another one
[05:32] <pitti> mdz: I just meant I can talk to the modem of my friend directly over ppp
[05:32] <robtaylor> mdz: hmm, are you familiar enought with the morphix stuff to point me in the right direction for fixing this?
[05:33] <mdz> robtaylor: no, I am not
[05:33] <robtaylor> boh
[05:33] <mdz> pitti: yes, your friend :-)
[05:33] <pitti> mdz: or believed friend :-)
[05:33] <mdz> pitti: if you truly want to release without a CAN, you may
[05:33] <mdz> pitti: it creates more work for _you_ though, to track it
[05:33] <pitti> mdz: since it's not that critical, I can wait for another day or two
[05:34] <pitti> mdz: I also created a patch for #2810 (this one is truly serious)
[05:34] <mdz> pitti: when did you send the mail?
[05:34] <pitti> mdz: I asked for review, but did not get one so far
[05:35] <mdz> mitre is UTC-4
[05:35] <pitti> mdz: Thu, 28 Oct 2004 15:00:04 +0200
[05:35] <pitti> mdz: so, 9:00 am of their time
[05:35] <mdz> yes
[05:35] <mdz> pitti: where did you ask?  I will review it if needed
[05:36] <robtaylor> lamont: ping?
[05:36] <pitti> mdz: on the Debian bug and on the Warty one (and on IRC)
[05:36] <lamont> robtaylor: yo
[05:37] <Kamion> the lack of MODULE_DEVICE_TABLE killed my first d-i pure hotplug test
[05:37] <robtaylor> lamont: so does the livecd actually chroot rather than pivot_root?
[05:37] <lamont> robtaylor: 2 minutes
[05:37] <robtaylor> lamont: np :)
[05:37] <lamont> and I'll be back...
[05:37] <lamont> robtaylor: I think it does chroot.  dunno actually
[05:37] <mdz> pitti: mail to ubuntu-devel would probably be good practice
[05:37] <lamont> but pretty sure.
[05:37] <lamont> brb
[05:37] <mdz> it is timezone-skew-friendly
[05:37] <pitti> mdz: right, I'll do that
[05:43] <pitti> mdz: BTW, I uploaded a libxml2 security patch, USN is prepared
[05:44] <pitti> mdz: https://chinstrap/~pitti/usn-libxml.txt
[05:44] <jdub> mdz, pitti: can you guys read the following thread, tell me what you think?
[05:44] <jdub> http://mail.gnome.org/archives/desktop-devel-list/2004-October/msg00419.html
[05:51] <Kamion> Keybuk: your .po merge seems to have thrown away lots of non-ISO-8859-1 characters ...
[05:52] <mdz> pitti: hmm
[05:52] <Kamion> look at anna_hoary.patch debian/po/cs.po, for instance
[05:52] <Kamion> msgid "Loading components of the Ubuntu installer"
[05:52] <Kamion> msgstr "Nahrvaj se komponenty instalanho programu"
[05:52] <Kamion> #~ msgid "Loading components of the Debian installer"
[05:52] <Kamion> #~ msgstr "Nahrvaj se komponenty instalanho programu"
[05:52] <mdz> pitti: what type are rowbytes and height?
[05:52] <pitti> jdub: I don't really see the reason why it shouldn't use sudo, though
[05:53] <pitti> mdz: png_int_32 or so
[05:53] <pitti> mdz: 32 bit in all cases
[05:53] <mdz> pitti: signed or unsigned?
[05:53] <pitti> mdz: unsigned
[05:53] <pitti> mdz: nevertheless, I compare it to INT_MAX, not to UINT_MAX
[05:53] <jdub> pitti: i gather the only reason he's not doing sudo so far is because he hasn't figured out how to do it nicely, within his framework
[05:53] <pitti> mdz: since size_t (the actual type of malloc) is signed
[05:53] <pitti> jdub: right, but gksudo calls sudo asynchronously
[05:54] <mdz> pitti: 2^32-1 * 2^32-1 > 2^64-1
[05:54] <pitti> jdub: I don't know why this shouldn't work for him
[05:54] <mdz> oh, no it isn't
[05:54] <Kamion> Keybuk: hm, mind you, the old translation was broken in a different way
[05:54] <pitti> mdz: ?
[05:54] <pitti> mdz: okay
[05:54] <mdz> pitti: I think this is probably safe, but the usual way to do the check is somewhat different
[05:54] <pitti> mdz: I don't know the "official" way. I asked the guys on IRC, thoug
[05:54] <pitti> mdz: and we agreed that this one is feasible
[05:54] <mdz> pitti: the way it is done later in the patch
[05:54] <pitti> mdz: what's the official?
[05:54] <mdz> +      if (height >= INT_MAX/sizeof(png_bytep)) {
[05:55] <pitti> mdz: but that does not work too well for bigger numbers, since it's integer
[05:55] <mdz> for a possible overflow X*Y, you test X >= INT_MAX/Y
[05:55] <pitti> mdz: I only did that for numbers which are fixed and 1,2,4 or so
[05:55] <sivang> howdy again all
[05:56] <mdz> pitti: it works fine, since integer division is rounded down
[05:56] <sivang> hi hornbeck
[05:56] <pitti> mdz: ah, right, I mixed the rounding up
[05:56] <sivang> mdz : I think I have an idea for that performance bug on my dekk
[05:56] <sivang> mdz : dell
[05:56] <thom> so what's the go with ~ ?
[05:56] <pitti> mdz: okay, then I change the patch 
[05:56] <sivang> mdz : do you have a minute for me?
[05:57] <mdz> sivang: I cannot give you my undivided attention, but please don't wait, just describe your idea
[05:58] <robtaylor> lamont: back yet?
[05:58] <lamont> robtaylor: sorry, yes.
[05:58] <mdz> pitti: there is no patch available upstream for libgd?
[05:59] <robtaylor> lamont: i've been trying to figure where the pivot_roots/chroots happen, do you knwo enough morphix to point me in the right direction?
[05:59] <lamont> not really.
[06:00] <sivang> mdz : I've tried to play several media file on the dell, using the debian kernel (on the bugtrail), when I'm constantly at the machine - It seems like its responsivness goes bit higher.
[06:00] <lamont> I'd expect to find them in the people.ubuntulinux.org/~lamont/LiveCD/morphix tree though
[06:00] <robtaylor> lamont: thanks :)
[06:00] <sivang> mdz : My assumption is, that this which menifests lightly on the debian kernel, probably takes much nastier form on the ubuntu ones
[06:00] <sivang> mdz : which results in the system barely usabe.
[06:01] <seb128> jdub: here ?
[06:01] <jdub> yeah
[06:01] <jdub> sivang: the machine is running awfully slow?
[06:01] <mdz> sivang: what is the bug #?
[06:01] <sivang> mdz : If only I could disable altogether ubunut's support for fan control, thermal and cpu freq
[06:01] <sivang> mdz : I think it might be solved.
[06:01] <seb128> jdub: I'm packaging gnome-vfs2 2.8.3 for hoary, good time to add the build-dep on libhowl-dev, right ?
[06:02] <sivang> jdub,mdz : sec
[06:02] <mdz> sivang: why?
[06:02] <jdub> seb128: yes, rock and roll :-)
[06:02] <seb128> ok, cool :)
[06:02] <sivang> jdub,mdz : #2315
[06:02] <sivang> mdz : the fact that the system goes into a much more usable and responsivness when using it constantly, cliking windows, playing media files , accessing the hd etc
[06:03] <sivang> mdz : suggest to me that when I leave it to idle,
[06:03] <sivang> mdz : it enters power/cycle saving mode that it has trouble getting out of
[06:03] <mdz> sivang: I agree, it sounds like it is overheating
[06:04] <mdz> sivang: is the CPU fan coming on at all?
[06:04] <sivang> mdz : now I could nicely invesitage it using the media files playing thing, I first tried to play it off  after just firing up the mahicne - no go
[06:04] <sivang> mdz : I tinkered with it a bit,
[06:04] <sivang> mdz : casued to do disk access and some massive gnome works, and it suddenly worked
[06:05] <lamont> robtaylor: yeah - I pruned the knoppix tree down to just wjat'
[06:05] <lamont> s used, but the morphix one is still full.
[06:05] <sivang> mdz : the cpu comes relatively long after the system starts.
[06:05] <sivang> mdz : the fan
[06:06] <sivang> mdz : could you supply me with a kernel that doesn't do powersaving/cycle down/ fan control at all? I want to machine to be working at it's full speed all time to test
[06:06] <mdz> sivang: is there anything in /proc/acpi/thermal_zone ?
[06:07] <sivang> mdz : btw, even when it starts the fan never goes to it's fullest rpm like on XP
[06:07] <mdz> sivang: try booting with acpi=off
[06:07] <jdub> sivang: have you booted that machine with acpi=force or acpi=off?
[06:07] <elmo> GAR
[06:07] <sivang> jdub : never tried acpi=force
[06:07] <mdz> sivang: don't, use acpi=off
[06:07] <sivang> jdub : all the others, I did
[06:07] <elmo> jdub: you know you uploaded the "Hoary Hedgehog" lsb-release to warty, right? 
[06:07] <thom> elmo: did you just wake up?
[06:07] <jdub> pipka's toshiba runs horribly slowly on the ubuntu kernel
[06:07] <mdz> sivang: check /proc/acpi/thermal_zone please
[06:07] <jdub> elmo: one, yes, it was a mistkae - did it hit the archive?
[06:08] <elmo> yes
[06:08] <jdub> if she runs it with acpi=force, then it's fine
[06:08] <jdub> elmo: cock
[06:08] <jdub> elmo: i thought uploads were restricted anyway?
[06:08] <elmo> they go to warty-updates
[06:08] <elmo> but it's still in warty-updates now
[06:08] <jdub> they don't require manual auth?
[06:08] <mjg59> sivang: acpi=off disables the kernel's control of all power saving except CPU frequency scaling
[06:08] <mdz> jdub: acpi=force can help sometimes if ACPI is being disabled by default; in sivang's case it is enabled properly
[06:09] <elmo> jdub: no, I was told manual auth wouldn't be necessary :P
[06:09] <mjg59> Stopping the powernowd service will disable the latter
[06:09] <mdz> elmo: can we make it so that things uploaded to 'warty' are rejected, and warty-updates must be uploaded explicitly to warty-updates?
[06:09] <sivang> mdz : I have THM under /proc/acpi/thermal_zone
[06:09] <elmo> yeah, probably, I'll look at doing that
[06:10] <elmo> thom: pretty much, I woke up (again) a couple of hours ago
[06:12] <thom> elmo: ouch
[06:12] <pitti> mdz: sorry, phone. There's no new upstream version and I did not find a public CVS for libgd
[06:13] <sivang> mjg59 : I want to disable cpu freq scaling also
[06:14] <sivang> mdz : polling_freq = disabled
[06:14] <sivang> mdz : state = ok
[06:14] <sivang> mdz : temp = 52C
[06:14] <sivang> mdz : critical(S5) = 94C
[06:14] <mjg59> sivang: Stop powernowd
[06:14] <sivang> mjg59 : it's doing cpu freq scaling?
[06:15] <sivang> mjg59 : what about cpu scaling accoridng to battery charge?
[06:15] <mjg59> There isn't any
[06:16] <sivang> mjg59 : ok, I hope this is not the case of buggy hardware..
[06:16] <sivang> mdz,jdub : I will try acpi=force
[06:16] <mjg59> sivang: No, acpi=force will do nothing
[06:16] <mjg59> All that does is force acpi to be enabled. It already is enabled for you.
[06:17] <mdz> pitti: I will see what I can find
[06:17] <mdz> sivang: I already explained the same thing that mjg59 said
[06:17] <pitti> mdz: BTW, I'm at updating it to use the division method
[06:17] <mdz> pitti: I will see fi I can find a semi-official patch
[06:17] <sivang> mdz : k :)
[06:18] <mjg59> sivang: acpi=off will disable the kernel's management of power saving and leave it up to the hardware. Stopping powernowd will stop frequency scaling.
[06:18] <elmo> GAR god damn it keybuk
[06:19] <bluefoxicy> so, naked men, and a whorey branch?
[06:19] <bluefoxicy> :)
[06:20] <sivang> mjg59 : can I disable entirely the scaling modules that probably interacts with the userlan powernowd ?
[06:20] <Keybuk> elmo: ?
[06:21] <lamont> mjg59: is there a FM I can go read to tell me how to have acpi/whoever not do anything when i close the lid?
[06:22] <mjg59> lamont: It's managed by /etc/acpi/events.d
[06:22] <mjg59> s/.d//
[06:22] <lamont> thanks
[06:25] <mdz> Kamion: any fun new stuff in anna?
[06:26] <robtaylor> lamont: so is a knoppix-based one something your looking at?
[06:26] <lamont> robtaylor: no. morphix uses 3 knoppix packages
[06:27] <robtaylor> lamont: ah, ok, good :)
[06:27] <lamont> specificaly, the hw detection/setup...  which goes away/merges for hoary
[06:28] <mjg59> Is powernowd actually doing the right thing on startup?
[06:28] <mjg59> Does an Ubuntu system have anything in /lib/modules/`uname -r`/kernel/drivers/cpufreq ?
[06:29] <pitti> mdz: I updated the patch and put it in bz
[06:29] <robtaylor> lamont: that'd be cool
[06:29] <mdz> pitti: bug#?
[06:29] <pitti> mdz: 2810
[06:29] <lamont> robtaylor: it's kinda like a hoary-requirement
[06:30] <robtaylor> lamont: it dioes seem to chroot, according to http://am.xs4all.nl/morphix/diagrams/base-module-complex.png, i just need to figure out why..
[06:31] <pitti> mdz: I added rowbytes >= INT_MAX before division checking to avoid problems with signed/unsigned autoconversion with the division
[06:34] <Kamion> mdz: some more lowmem support, bit of extra error checking, preseeding support
[06:34] <jdub> PREEEEEESEEEEEEED!
[06:35] <Kamion> I *so* need to get sarge out so that we can merge some of that stuff back to Debian
[06:35] <pitti> the Release Manager has spoken :-)
[06:36] <sivang> Kamion : you work with Joey Hess right? :)
[06:37] <Kamion> in some projects, yes
[06:38] <sivang> mdz,jdub : acpi=off halts the boot process on detecting IDE drives.
[06:40] <elmo> mdz: done ('warty' uploads being rejected)
[06:42] <sivang> Kamion : he also working on D-I right?
[06:42] <sivang> mdz : acpi=force yeilds the same prformance resluts, I recall something with epic=somethign you told me
[06:43] <sivang> mjg59 : I apt-get removed powernod, however on startup I still get a message that thermal and fact control modules are loaded.
[06:43] <mjg59> sivang: Yes. Pass acpi=off
[06:44] <sivang> mjg59 : acpi=off just hangs the machine when it detects IDE drives, thuse render it unbootable.
[06:44] <mjg59> sivang: For the last time, acpi=force will do precisely nothing on your computer. Ever.
[06:44] <mjg59> sivang: Right. That's an entirely separate problem
[06:44] <sivang> mjg59 : ok. 
[06:44] <sivang> mjg59 : maybe disable acpi on bios?
[06:44] <mjg59> If the BIOS lets you disable acpi, then yes
[06:45] <mjg59> It's unlikely that it will
[06:45] <mjg59> If you're using acpi, you must load the thermal and fan modules
[06:45] <mjg59> Otherwise your computer will potentially be damaged
[06:45] <sivang> mjg59 : what happens if I dont? Can't I not use if my system hangs the kernel due to it?
[06:46] <mjg59> If your machine hangs when you try to boot without acpi, you must use acpi
[06:46] <mjg59> If you use acpi, you must load the thermal and fan modules or your computer will be physically damaged
[06:46] <sivang> mjg59 : ok then. 
[06:47] <mdz> elmo: great, thanks
[06:48] <robtaylor> mjg59: ah, that explains why my laptop burnt itself out at debconf...
[06:48] <robtaylor> ah no, that was apm ..
[06:49] <Kamion> sivang: joeyh started the d-i project and has written a vast amount of its code, yes
[07:13] <Keybuk> elmo: what are you doing?
[07:14] <elmo> preparing the latest mail about hoary seed syncage - there's a dep chain of despair that's going to pull in a bunch of packages we've been trying to avoid in main since forever
[07:15] <mdz> gah
[07:19] <hornbeck> sivang: hello
[07:21] <bluefoxicy> is the devel list slow?
[07:21] <lamont> fabbione: should I expect toresetXbeforethespacekeymapping is correctwhenIchangekyeboards?
[07:21] <elmo> btw, the testing page is actually looking sane now, compared to yesterday (err, or whenever it was I was last up)
[07:22] <elmo> aiee, keybuk
[07:23] <elmo> guys, don't upload stuff that has no changes from Debian, with the same version
[07:23] <elmo> it'll be synced automatically
[07:23] <elmo> and if and old 'ubuntu' version needs overridden, just let me know
[07:25] <Keybuk> elmo: agh
[07:25] <Keybuk> that's a "stupid keybuk", I uploaded the wrong thing anyway
[07:25] <Keybuk> bleh
[07:35] <Kamion> $ debdiff base-installer_1.12.dsc base-installer_1.12ubuntu1.dsc | wc -l
[07:35] <Kamion> 15219
[07:35] <Kamion> $ debdiff base-installer_0.087ubuntu13.dsc base-installer_1.12ubuntu1.dsc | wc -l
[07:35] <Kamion> yay for base-installer
[07:35] <Kamion> 29610
[07:36] <Kosai> lamont: This is why we have a priority variable for the startup programs in g-s-m.
[07:36] <mdz> |diffstat is a better metric than |wc -l
[07:36] <lamont> Kosai: nope.
[07:36] <lamont> that _starts_ gnome-ask-pass, but doesn't block for it to finish.
[07:36] <tseng> lamont: there is a gtk2 ssh askpass i used to use
[07:36] <lamont> see "_reliable_"
[07:36] <tseng> that goes full screen
[07:37] <tseng> seemed to prevent other stuff from working until it returned
[07:37] <lamont> tseng: but still doesn't stop everything else from starting and asking for the passphrase before you can enter it into ssh-agent
[07:37] <Kamion>  1 files changed, 5339 insertions(+), 1840 deletions(-)
[07:37] <Kamion>  1 files changed, 8454 insertions(+), 6226 deletions(-)
[07:37] <Kamion> (respectively)
[07:37] <lamont> prevents keyboard focus, iirc
[07:37] <tseng> well i was runing it from xinitrc also
[07:37] <Kosai> lamont: I see.
[07:37] <Kamion> (although the "1 files changed" is bogus)
[07:37] <tseng> if you had a .xsession that read
[07:38] <tseng> ssh-askpass &
[07:38] <tseng> exec gnome-session
[07:38] <Kosai> I use x11-ssh-askpass; even if other windows are opened, x11-ssh-askpass refuses to give up focus to them.
[07:38] <tseng> i imagine that would be it
[07:38] <tseng> ?
[07:38] <Kamion> do ssh-add, not ssh-askpass &
[07:38] <Kosai> So, gnome loads, ssh-askpass comes up, I start typing my passphrase, if some xterms appear on top of it I just keep typing and hit return.
[07:38] <lamont> Kosai: but if you're not there to type the passphrase quickly enough, then all the ssh windows block _WANTING_THE_PASSPHRASE_
[07:38] <Kamion> simply don't put ssh-add in the background in .xsession. easy.
[07:39] <lamont> in short, it's not integrated.
[07:39] <Kamion> $ cat .xsession
[07:39] <Kamion> #! /bin/sh
[07:39] <Kamion> ssh-add
[07:39] <Kamion> exec fluxbox
[07:39] <mdz> Kamion: I don't know what it is, but that seems to confuse everyone (ssh-add vs. ssh-askpass)
[07:39] <lamont> Kamion: that'll block everyting?
[07:39] <Kamion> ssh-askpass asks for a passphrase, it doesn't *do* anything with it :-)
[07:39] <Kamion> lamont: yes
[07:39] <mdz> Kamion: I know that, you know that
[07:39] <lamont> what's fluxbox?
[07:39] <mdz> Kamion: but I've seen dozens of people go down the wrong road :-)
[07:40] <Kamion> lamont: lightweight window manager
[07:40] <mdz> maybe ssh-askpass should be renamed to tnhoenushoeuo
[07:40] <mdz> youdontwanttorunthisprogram
[07:40] <Kosai> I know it too, since if I wasn't running ssh-add my passphrase would never get anywhere, just forgot it for this conversation.  :)
[07:40] <mdz> Kamion: in fact, maybe it should go in /usr/lib
[07:40] <mdz> probably too late for that
[07:40] <Kosai> mdz: Yeah, like people pay attention to what filesystem hierarchy means.  :)
[07:40] <Kamion> mdz: compatibility implications, ssh-add calls it and there are several filesystems involved ...
[07:40] <Kosai> (See:  "Dude, where the hell is traceroute?  This sucks.")
[07:40] <Kamion> er, not filesystems, packages
[07:41] <mdz> Kosai: (see: "sbin directories are in the default PATH in Ubuntu") :-)
[07:41] <Kosai> mdz: Coo.  Okay, then.
[07:41] <mdz> when The World straightens itself out wrt FHS, we can revisit that
[07:42] <lamont> does .xsession need to be +x?
[07:42] <Kamion> -rw-r--r--  1 cjwatson cjwatson 33 2003-12-24 12:04 /home/cjwatson/.xsession
[07:44] <elmo> Out-of-date BUT modified: 175 (17.01%)
[07:44] <elmo> Updated:                    0 (0.00%)
[07:44] <elmo> Ubuntu Specific:           19 (1.85%)
[07:44] <elmo> Up-to-date [Modified] :    157 (15.26%)
[07:44] <elmo> Up-to-date:               678 (65.89%)
[07:44] <mdz> it really _ought_ to be +x, and executed
[07:45] <mdz> what if I want to write my .xsession in python? :-P
[07:45] <elmo> (main only)
[07:46] <mdz> elmo: that's after this batch of uploads from Keybuk?
[07:46] <mdz> or before?
[07:47] <elmo> after
[07:49] <lamont> ~lamont/.xsession is never executed in the normal login path that I can see.
[07:49] <elmo> updated http://people.ubuntu.com/~james/packages_to_merge.txt
[07:49] <Kamion> lamont: yes, I do
[07:49] <Kamion> lamont: you may have to change the session option from the gdm login screen
[07:49] <lamont> from, to?
[07:49] <Kamion> there are only a few options, try them ... :)
[07:49] <Kamion> I think I use "Xsession"
[07:49] <lamont> heh.
[07:50] <mdz> yow
[07:50] <mdz> popularity-contest merged?
[07:50] <mdz> didn't thom basically rewrite it?
[07:51] <mdz> oh, probably as a separate program for the submission
[07:51] <seb128> lamont: system session is ~/.xsession
[07:51] <Keybuk> yeah, two separate programs
[07:54] <mdz> Kamion: how hairy is the d-i merge so far?
[07:55] <Kamion> tolerable; about me-hairy rather than elmo-hairy
[07:55] <Kamion> (the other extreme, obviously, being mdz-hairy)
[07:55] <thom> mdz: seperate program, just the cron job changed
[07:56] <lamont> the other cute one is the way gnome-session fires up a new firefox for each window that was open when you logged out, and n-1 ask for which profile you want...
[07:56] <lamont> so the session manager is launched in the background...  GRUMBLE!
[07:57] <mdz> elmo: we talked a while back about having notifications sent to -changes for syncs from sid, is that still on your list?
[07:59] <Kamion> Keybuk: do you know what causes Report-Msgid-Bugs-To: to be shifted around in all your .po merges?
[08:00] <Keybuk> Kamion: msgcat, I think
[08:00] <Kamion> hm, ok
[08:02] <Keybuk> I can't work out whether Linux's support for printers sucks, or my ability to use printers sucks
[08:03] <mdz> Keybuk: neither. printers suck
[08:03] <lamont> I win.
[08:03] <Keybuk> lamont: ?
[08:03] <pitti> mdz: any news regarding libgd?
[08:03] <lamont> local diversion of /usr/bin/gnome-session to /usr/bin/gnome-session.real
[08:04] <lamont> more /usr/bin/gnome-session
[08:04] <lamont> #!/bin/sh
[08:04] <lamont> ssh-add
[08:04] <lamont> exec /usr/bin/gnome-session.real "$@"
[08:04] <lamont> _THAT_ does what I want
[08:04] <Keybuk> heh
[08:04] <Keybuk> I put ssh-add into "Startup Programs"
[08:04] <lamont> doesn't block
[08:04] <mdz> pitti: I found nothing so far
[08:04] <Keybuk> aye
[08:04] <lamont> my solution blocks. :-)
[08:04] <Keybuk> why not just use .xsession for that? :p
[08:05] <mdz> Kamion: what would be a good unique string to search for to detect debbugs bug closures by searching bugzilla comments?
[08:05] <lamont> gnome-session also fails miserably in tracking applications that open multiple windows, it appears...  Each window gets a new invocation of the program upon logging out (save changes) and back in.
[08:05] <lamont> Keybuk: because .xsession also doesn't block
[08:06] <lamont> hrm... /me verifies.
[08:06] <Kamion> mdz: do you get the Received: headers?
[08:06] <Keybuk> at some point, we should teach lamont about Xnest
[08:07] <mdz> http://pacsec.jp/advisories.html
[08:07] <Keybuk> mdz: should I not write grepmap --ieee1394map then? :p
[08:07] <jdub> mdz: *boggle*
[08:07] <mdz> Kamion:     want_headers = ('message-id', 'date', 'from', 'to', 'cc', 'subject')
[08:08] <Kamion> mdz: if you can get the Received: headers again, you could take the very first one and search for /\(at [^)] *-(?:done|close)\)/ in it
[08:08] <pitti> mdz: well, if you have physical access to a computer, all security bets are off anyway, not?
[08:08] <mdz> Keybuk: that, or explain to the ipod users that they could get r00ted by their ipod
[08:08] <pitti> mdz: still, this is scary. Thanks for that link!
[08:09] <mdz> Kamion: the received headers are gone...it doesn't need to be perfect, though, I  just want to make a report that I can quickly skim over and close bugs which have been fixed in the merge
[08:10] <Kamion> mdz: I guess you could look for -done or -close in To:/Cc: then
[08:10] <Kamion> mdz: in future I suggest you take X-Debian-PR-* ...
[08:11] <jdub> gcc-3.4 depends on kdebindings? crack!
[08:11] <Javi> hi, people, do you know how is Ubuntu sound system configured ? I'd like my debian sound system like my ubuntu sound system, but I can't find diff on configuration, but ubuntu is better than debian on this feature
[08:11] <mdz> Kamion: the reason I trim them is that they appear at the beginning of every comment
[08:11] <mdz> Kamion: but, point taken
[08:12] <mdz> Javi: please /join #ubuntu for support questions
[08:12] <jdub> (build-depends)
[08:12] <Kamion> mdz: you can also use the standard dpkg regex for closes:, which may help
[08:12] <Kamion> mdz: maybe they could be stashed somewhere else eventually ...
[08:12] <mdz> Kamion: searching for 'source-version' seems to do well enough
[08:12] <Kamion> mdz: not guaranteed not to get that on bug openings too
[08:13] <Kamion> but yeah, that'll appear in all recentish katie closing mails
[08:13] <lamont> than warty
[08:13] <Kamion> mdz: that often won't appear when the maintainer closed the bug by hand
[08:13] <Kamion> which is why I suggested looking in To:/Cc: ...
[08:14] <mdz> Kamion: good point
[08:14] <mdz> of course, that won't find stuff closed with control@, right?
[08:14] <Kamion> indeed not
[08:15] <Kamion> /^\s+close\s+\d+/
[08:15] <Kamion>  /^\s+close\s+\d+/
[08:15] <Kamion> (ish)
[08:16] <Javi> mdz: ok, thanks you, i'll go there
[08:16] <mdz> Keybuk: I'm sending you some bugs which would be closed by merges; if they end up falling into the manual pile, send them back
[08:17] <Keybuk> ah right
[08:17] <Keybuk> was just muttering "why's he assigned these to me?" :)
[08:17] <Keybuk> http://people.ubuntu.com/~scott/merge/README
[08:17] <Keybuk> http://people.ubuntu.com/~scott/merge/review/
[08:17] <Keybuk> ^ is the to-review stuff
[08:17] <Kamion> I was gonna say, the grub-installer thing's probably mine, since I'll be reviewing that ...
[08:18] <Keybuk> Kamion: yeah, just reassigned that one to you :p
[08:19] <Keybuk> alsa-base hasn't got warty changes, has it?
[08:19] <Keybuk> ah, alsa-base = alsa-driver
[08:21] <hornbeck> can one of you dev's write up a chroot doc for me, so I can start working with it?
[08:21] <hornbeck> please :-)
[08:22] <Kamion> what kind of document?
[08:23] <Kamion> like http://www.debian.org/doc/manuals/reference/ch-tips.en.html#s-chroot ?
[08:23] <Kamion> or like http://archive.ubuntulinux.org/ubuntu/dists/warty/main/installer-i386/release/doc/manual/en/apcs03.html (note, you can use the Ubuntu system built thereby without considering it an "installation" if you want)?
[08:25] <lamont> Keybuk: so those are all ready for people to start working on?
[08:26] <mdz> Kamion: regex searching doesn't seem to work properly anyway, and is horrifically slow
[08:26] <hornbeck> Kamion: thanks
[08:28] <jdub> mdz: happy for me to make the gamin/polypaudio seed changes for hoary now?
[08:29] <mdz> jdub: yes
[08:29] <mdz> jdub: should we upload a new ubuntu-desktop to propagate them?
[08:29] <jdub> not jsut yet ;)
[08:29] <mdz> hmm, that shouldn't be a question.  the seeds and ubuntu-desktop should match
[08:29] <mdz> if they're not ready to be pushed out to hoary users, they shouldn't go in the seed yet
[08:29] <jdub> can u-d be updated automagically?
[08:29] <mdz> yes
[08:30] <mdz> there's a script in the source package which pulls the stuff from the wiki
[08:30] <jdub> cool
[08:30] <mdz> it's totally trivial
[08:30] <Kamion> presumably the new wiki now, though?
[08:30] <jdub> i'm, um, waiting for the new wiki to load...
[08:30] <Kamion> www.u.o isn't giving me any love either
[08:30] <lamont> mdz: re 2756 - we still have -2ubuntu1
[08:30] <Kamion> can somebody give me the new URLs so I can update germinate?
[08:30] <jdub> mmm, seems to be a distinct lack of all love
[08:31] <Kamion> elmo: do you need to run germinate for warty any more?
[08:31] <Keybuk> lamont: yup, start taking them, fixing them and uploading
[08:31] <Kamion> maybe I should tag the last warty revision or something
[08:31] <mdz> lamont: yes, but I saw nothing in the bug report which stated whether it affected that version or not, which is why I gave it to you
[08:31] <lamont> Keybuk: are there bugs filed, or how are we synchronizing things?
[08:31] <Keybuk> lamont: ask mdz
[08:31] <mdz> Keybuk: how many source packages?L
[08:31] <Keybuk> 250-odd
[08:32] <elmo> Kamion: not particularly - I'm only running it on hoary atm
[08:32] <lamont> mdz: yeah.  -2ubuntu1 is installed in hoary on all 3.  Probably need to see if it's on keybuk's sync list.
[08:32] <Keybuk> most of them are fairly trivial and just have one or two drops that should be obvious to fix
[08:32] <lamont> mdz: I'll take care of either requesting the sync back to debian, or what not.
[08:32] <mdz> Keybuk: http://people.ubuntu.com/~scott/merge/review/ ?
[08:33] <Keybuk> yeah
[08:33] <Keybuk> there's a README one level up saying what the files mean
[08:33] <mdz> I'll file bugs about them
[08:33] <Kamion> elmo: ok ... well, colin.watson@canonical.com--2004/germinate--tags--4.10 is the warty version if you need it
[08:36] <Kamion> Keybuk: wouldn't ddetect have been better merged starting from 1.03?
[08:36] <Kamion> rather than 1.00?
[08:39] <Keybuk> Kamion: we probably never had 1.03 in our archive
[08:40] <Kamion> ah, I see
[08:40] <Keybuk> it doesn't actually seem to make much difference ;o)
[08:40] <Kamion> snapshot.debian.net maybe
[08:40] <Kamion> well, it means .po files have to be merged
[08:40] <Keybuk> evolution it did both sides from 1.4 to 2.0
[08:40] <Keybuk> Kamion: it merges po files from latest debian, so that generally works
[08:40] <Kamion> it produced lots of unnecessary .po patches
[08:40] <Kamion> look at them :)
[08:40] <Keybuk> shouldn't make a difference ?
[08:40] <Kamion> no, but it's more merge work for later
[08:40] <Keybuk> was the warty side 1.00 or 1.03 ?
[08:41] <Kamion> 1.03ubuntu14 I think
[08:41] <Kamion> I'm merging it now anyway, just a suggestion for the next merge run :)
[08:41] <Keybuk> ok, then it would've applied the debian changes to that, ignoring any that already were there
[08:41] <Keybuk> ah, but yeah
[08:42] <Keybuk> if there were .po changes from 1.00 to 1.03, then it would do merging of those
[08:42] <Keybuk> but that's because it can't understand "already there" like it does with ordinary changes
[08:42] <Keybuk> ho-hum
[08:43] <Keybuk> (btw, feel free to steal stuff out of rookery:~scott/sources if you want the unpacked debian or warty versions)
[08:49] <Kamion> Keybuk: the other difference it makes is that it duplicates changelog entries :)
[08:50] <Keybuk> heh
[08:51] <Keybuk> LOOK OVER THERE!  A THREE-HEADED MONKEY!
[08:59] <mdz> justdave: here?
[09:00] <mdz> justdave: emailed you a list of components which need to be present in order for me to mass-file these merge bugs
[09:01] <bluefoxicy> bah my post to the ML got ignored
[09:02] <justdave> ok.
[09:02] <elmo> mdz: err, will your script error out if I give it a non-existent component?
[09:03] <mdz> elmo: yes
[09:03] <mdz> er
[09:03] <mdz> elmo: which script?
[09:03] <justdave> mdz: I have a script that takes a text file with one component per line and checks the entire thing against the component list and creates any component from the list that's missing.
[09:03] <mdz> justdave: ok, that's what I sent you
[09:03] <elmo> mdz: the bugzilla.py thing from debzilla
[09:03] <mdz> elmo: yes
[09:03] <elmo> duh, that sucks
[09:03] <justdave> If we can come up with a standard place to get that text file from we could cron the script
[09:03] <mdz> elmo: doing anything else requires uber privilege
[09:04] <lamont> germinate output comes to mind...
[09:04] <mdz> elmo: well, I suppose it could fall back to UNKNOWN, but that's pretty crap too
[09:04] <mdz> the right thing is to just have the components exist
[09:04] <justdave> yeah, I've used germinate for that in the past.
[09:04] <mdz> justdave: the way to generate that text file is to grab Sources.gz from the archive and, do: zcat Sources.gz | grep-dctrl -nsPackage ''
[09:05] <mdz> elmo: you should be happy it detects that bugzilla blew up in that case; that was SO non-trivial
[09:05] <mdz> justdave: grep-dctrl is in the package of the same name
[09:06] <elmo> mdz: yeah, I wasn't saying your script was crap, just that it was a PITA, but if you guys are going to cron the component generation, that's fine
[09:06] <mdz> cron is probably fairly reasonable
[09:06] <mdz> it should do binaries as well
[09:06] <mdz> but that's somewhat more of a pain due to having to iterate over known architectures
[09:07] <elmo> and fricking bugzilla needs to stop overloading the word 'component'.  debian was here first damn it :-P
[09:07] <mdz> justdave: let me know when you've run that list through the script
[09:26] <justdave> mdz will do.  should be up in a couple minutes
[09:30] <pitti> mdz: without wanting to bother you, shall I upload the libgd package into the queue to have it built?
[09:31] <justdave> mdz: done
[09:31] <justdave> 54 new components created
[09:41] <seb128> elmo: gthumb good to overwrite with a sync from debian
[09:41] <elmo> seb128: done
[09:41] <seb128> thanks
[09:43] <mdz> justdave: thanks
[09:43] <mdz> hmm
[09:43] <mdz>     You must choose a component to file this bug in. If necessary,
[09:43] <mdz>     just guess.
[09:43] <mdz> KEYBUUUUUUK
[09:43] <mdz> there are universe packages in that list
[09:44] <elmo> use mine, if you want?
[09:46] <mdz> elmo: I'm just letting it fail for stuff which is missing from bugzilla, which is ~= universe
[09:46] <mdz> didn't see what you said in time
[09:46] <mdz> that means <<250 bugs to file, though
[09:46] <mdz> which is nice
[09:47] <elmo> should be 169, by my count
[09:47] <elmo> Rejected: cdrtools_2.0+a38-1ubuntu1.dsc refers to cdrtools_2.0+a38.orig.tar.gz, but I can't find it in the queue or in the pool.
[09:47] <elmo> ^-- someone
[09:48] <pitti> elmo: sorry, that's me
[09:48] <pitti> elmo: forgot -sa
[09:48] <Kosai> Hm.  Can OS X HFS partitions be resized non-destructively?  Gf just bought a powerbook, wondering whether installing Ubuntu on it can wait a while.
[09:48] <Kamion> I wouldn't trust warty's parted to deal with HFS+ correctly.
[09:48] <Kosai> Maybe the resizing could be done in OS X?
[09:48] <Kamion> Not sure about HFS; but it's probably best to use OS X's tools to do it.
[09:49] <Kamion> When I got mine, I "resized" by reinstalling OS X from the provided media ...
[09:49] <Kamion> (but with a smaller partition for OS X)
[09:49] <Kosai> Yeah.  Don't think Mad'll want to do that, I'm not gonna see her again until Christmas, she'll have built up a lot of stuff on the OS X partition.
[09:49] <Kamion> yeah, can imagine
[09:49] <Kamion> there may be pointy-clicky tools if you boot from the OS X CD
[09:50] <Kamion> "Disk Utility" is the name, I think
[09:50] <Kamion> but best check google
[09:50] <Kosai> Okie.  Thanks.
[09:50] <Kosai> gl :) I just decided I'm not going to make it in time, will eat at home first.
[09:53] <cenerentola> Any Italian around HERE?
[09:55] <seb128> elmo: python-gtk2 sync too please
[09:56] <elmo> http://www.redhat.com/archives/fedora-devel-list/2004-October/msg01484.html 
[09:57] <elmo> ^-- that's not terribly encouraging for polpyaudio and hoary
[09:57] <elmo> seb128: done
[09:59] <seb128> thanks
[10:00] <seb128> elmo: http://lists.gnome.org/archives/desktop-devel-list/2004-October/msg00436.html
[10:00] <seb128> too
[10:01] <seb128> no problem described in this thread for the moment ...
[10:01] <seb128> (too=on the same subject, not a "not terribly encouraging")
[10:04] <elmo> hmm?
[10:04] <elmo> http://lists.gnome.org/archives/desktop-devel-list/2004-October/msg00449.html
[10:04] <elmo> seems just as negative to me :)
[10:05] <seb128> uh, I've not read this one yet
[10:06] <seb128> I've just get this mail
[10:10] <mdz> 166
[10:11] <mdz> ok, it is seriously annoying that bugzilla doesn't show the component in search results
[10:11] <mdz> justdave: is that possible?
[10:11] <justdave> mdz: click the "change columns" link at the bottom
[10:11] <justdave> you can show whatever columns you want
[10:11] <mdz> justdave: dthanks
[10:12] <mdz> justdave: is it possible to set it as default for our instance?
[10:12] <justdave> sure
[10:14] <justdave> done
[10:15] <justdave> (note it sets your column list in a cookie if you've ever set the columns via the change-columns page)
[10:15] <cenerentola> all: just an hint: how do i sign mail in evolution after ive set the sign?
[10:16] <elmo> oh, kick ass, benh has done sleep for modern powerbooks
[10:17] <cenerentola> sorry i mistook chan
[10:17] <chrisa> elmo: Oh? Is that a recent patch?
[10:18] <sjoerd> elmo: yeah, it works very nice :)
[10:18] <sjoerd> chrisa: yesterday 
[10:19] <chrisa> I wonder if that covers the ibooks as well (some of which use the same ATI chipset)
[10:19] <elmo> he says it doesn't - check out the debian-powerpc@l.d.o archives
[10:19] <sjoerd> chrisa: not yet, but he asked for testers 
[10:19] <amu> on the new pb4 it works 
[10:19] <chrisa> ah, haven't read ppc in a day or two
[10:20] <mdz> justdave: it seems to truncate the component at 8 characters, which is too short for most packages. can we increase that?
[10:23] <justdave> mdz: done
[10:23] <justdave> removed length restriction, renamed column header to "Package" :)
[10:24] <elmo> justdave: rock
[10:24] <mdz> justdave: thanks
[10:25] <elmo> argh.  this component thing just became critical - libhowl0 is same version in warty/hoary and needs promoted to main
[10:25] <elmo> 'cos the enitre gnome world now depends on it
[10:33] <mdz> elmo: please clobber kernel-source-2.6.7
[10:40] <mdz> elmo: would it make your life exceedingly difficult to purge a bunch of the Debian kernel stuff?
[10:40] <mdz> (to clarify, for kernel-source-2.6.7 I meant to overwrite with the Debian version for now)
[10:49] <seb128> elmo: sound-juicer sync please
[10:55] <seb128> hum
[10:56] <seb128> gnome-gv is 2.8.0-0ubuntu1 in warty and 2.6.2-3 in debian ... why do we get a bug report for a sync if the warty version > debian version ?
[10:56] <mdz> seb128: my list came from Keybuk
[10:57] <mdz> if there were some errors, I apologize on his behalf, and please close any erroneous bugs :-)
[10:57] <seb128> ok, and he left :)
[10:57] <seb128> no problem
[10:57] <seb128> I was just wondering
[11:10] <seb128> elmo: gossip sync too please
[11:10] <justdave> anyone had any thoughts yet on how we should handle warty vs hoary identification on Bugzilla?
[11:13] <justdave> warty might be good as a flag...  so if someone things something should be fixed in warty, they can request it, and mdz can give it a + or a - if he agrees or doesn't
[11:22] <tseng> milestone?
[11:23] <tseng> ive seen what you are talking about on other bugzillas
[11:24] <doko> thom, elmo: would it be possible to have a hoary amd64 chroot on yellow?
[11:25] <elmo> seb128: done
[11:25] <seb128> elmo: thanks
[11:25] <elmo> doko: yeah, give me a bit
[11:26] <elmo> mdz: purge how?
[11:26] <mdz> elmo: remove from the archive
[11:26] <elmo> even universe?
[11:26] <doko> elmo: thanks!
[11:26] <elmo> kernel-source-2.6.7 clobbered
[11:26] <mdz> elmo: yeah
[11:26] <mdz> thanks
[11:27] <elmo> mdz: hmm, no not particularly, I'll just have to maintain a blacklist of stuff we don't want to sync from sid to universe, no big
[11:27] <mdz> elmo: we've talked about it before, I think, but I assume it makes your life a lot more interesting with regard to processing new stuff added to sid
[11:27] <mdz> hmm, ok then
[11:27] <mdz> email?
[11:28] <elmo> sure, or here, whichever
[11:29] <mdz> kernel-source-2.4.24
[11:29] <mdz> kernen-source-2.4.25
[11:29] <mdz> kernel-source-2.4.26
[11:29] <mdz> kernel-source-2.6.5
[11:29] <mdz> kernel-source-2.6.6
[11:29] <mdz> kernel-source-2.6.7
[11:29] <mdz> kernel-image-2.4.26-i386
[11:29] <mdz> kernel-image-2.6.7-i386
[11:29] <mdz> can all go
[11:30] <mdz> s/kernen/kernel/
[11:31] <jdub> mdz: http://www.redhat.com/archives/fedora-devel-list/2004-October/msg01484.html
[11:31] <jdub> heh
[11:31] <jdub> I downloaded the code and took a look. I think its actually worse than
[11:31] <jdub> esd as an implementation. As a protocol well that may be a different
[11:31] <jdub> matter.
[11:33] <mdz> "No rate adaption"??//
[11:33] <mdz> wtf is the point of this thing, then?
[11:34] <jdub> conversation continues on d-d-l
[11:34] <elmo> mdz: done
[11:34] <mdz> thanks
[11:36] <doko> what is the procedure for packages to be merged, if they should be synced from unstable again?
[11:37] <doko> just email the usual suspects? ;)
[11:37] <elmo> doko: ask me
[11:37] <elmo> no, just me, no approval needed - and you can do it via IRC, if I'm around
[11:37] <doko> ok
[11:38] <elmo> hmm, why does a warty chroot come without shadow by default..
[11:41] <jdub> mdz: i don't get the rate adaption thing; polypaudio uses libsamplerate
[11:48] <elmo> doko: okay, hoary chroot exists on yellow now
[11:49] <jdub> dudes
[11:49] <jdub> floppies
[11:49] <jdub> is the only sane way of doing on-demand mounting of floppies... automount?
[11:52] <doko> elmo: thanks!
[11:54] <mdz> seb128: g-v-m quit unexpectedly during an upgrade just now; is that normal?
[11:54] <mdz> jdub: there is no sane way of doing on-demand mounting of floppies
[11:54] <mdz> floppies are so 1980
[11:55] <seb128> mdz: hal has been updated ?
[11:57] <jdub> mdz: would you be 100% opposed to automount running for floppies only?
[11:58] <seb128> elmo: screem and libxklavier synchros please
[11:58] <mdz> seb128: hal seems to be ahead of Debiain
[11:58] <mdz> Debian
[11:59] <sjoerd> mdz: check experimental :)
[12:00] <seb128> mdz: yeah, but did hal get upgraded when g-v-m crashed ?
[12:00] <doko> hmm, can we have latex2html and graphviz in restricted? the former to build the python docs, the latter to build the libstdc++ docs