[12:07] <Seveas> guadalicious, I presume
[12:07] <jono> Keybuk, awesome :)
[12:08] <jono> Keybuk, had a great time, met some old and new pals and spoke about Jokosher :)
[12:08] <jono> Seveas, it was :)
[12:08] <Keybuk> jono: I was sad to miss it, but timing was not good
[12:08] <Keybuk> btw, is it lug this week?
[12:08] <jono> Keybuk, damn you and your ways
[12:08] <jono> Keybuk, it is, but I won't be there - I am away
[12:08] <Keybuk> heh, where are you this week?
[12:08] <jono> Keybuk, we need to hook up for a pint sometime soon
[12:08] <Keybuk> aye, we should
[12:08] <jono> Keybuk, visiting friends
[12:08] <jono> Keybuk, its their anniversary
[12:09] <jono> so wha you guys up to ?
[12:09] <Keybuk> merges :-(
[12:10] <jono> heh
[12:10] <Seveas> Keybuks mom is giving everybody work
[12:10] <jono> oof
[12:10] <Keybuk> "new mom"
[12:11] <Seveas> yeah, the old mom was even worse :
[12:11] <Keybuk> Kamion: just reviewing seed-cleanup ... got a few secs?
[12:14] <Kamion> Keybuk: sure
[12:14] <Keybuk> Kamion: the scope mentions the review of the actual seeds; it would have been nice for the rationales of the changes to be included in the spec
[12:14] <Kamion> Keybuk: (I've nearly finished the implementation, so I guess now is a good time ;-))
[12:14] <Keybuk> but I guess that's all long forgotten now
[12:15] <Keybuk> so maybe just drop mention of that review from the spec and make it a germinate spec
[12:15] <Keybuk> also (and in particular for the implementation)
[12:15] <Kamion> Keybuk: I'll note explicitly that it was carried out at the conference
[12:15] <Keybuk> germinate already supports regexes for the language packs and friends
[12:15] <Keybuk> so having both regexes and globs for different functionality seems ... bogus
[12:15] <Kamion> good point
[12:15] <Keybuk> could this use regexes, OR the existing stuff use globs?
[12:15] <Kamion> I'll make that regexes
[12:16] <Kamion> don't really want to break the existing stuff
[12:16] <Kamion> in retrospect globs would probably have been sufficient for the language pack stuff, but it's too late now
[12:16] <Keybuk> aye
[12:16] <Keybuk> if both called out to a common function that could be changed to globs later, that would be nice
[12:17] <Keybuk> otherwise no other comments there, so if you could fix those bits, it's fine for approval
[12:17] <jdub> oh man, i'm getting that perl locale spew again
[12:18] <sivang> I'd like to sign off for the night, will it be okay to sort left over spec approval fixes tomorrow UTC time ?
[12:19] <Kamion> Keybuk: my current implementation needs 10 exclude patterns to produce IMO sane results following including *-{dbg,dev,doc}
[12:19] <Kamion> which is pretty much as good as I'd hoped for
[12:20] <Keybuk> can you mention those in the spec? :p
[12:20] <Kamion> sure, why not
[12:20] <Keybuk> sivang: I don't understand the question
[12:21] <sivang> Keybuk: Well, if on the next review round there will be more stuff to fix, I wouldn't be able to do them until tomorrow morning UTC time, and since the 4th is the spec approval dead line, I'd like to kow if it's okay that I sort these past the dead line and get my specs approved.
[12:22] <Keybuk> there's a spec approval deadline?
[12:23] <Kamion> yes, but it's the 6th, not the 4th
[12:23] <Kamion> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-June/000153.html
[12:23] <Keybuk> 6th sounds more sane
[12:23] <sivang> hrm 
[12:23] <Keybuk> 4th is not a Thursday :)
[12:23] <sivang> Doh!
[12:24] <sivang> For some reason I made it in my head to be the 4th of July , which incidently, is US independence day ...interesting mis-association.
[12:24] <sivang> Kamion: thanks for the reminder
[12:25] <Kamion> Keybuk: actually, how about I cheat, kind of
[12:25] <Kamion> Keybuk: regexes in seeds are always surrounded by //
[12:25] <Kamion> Keybuk: so I just extend that to say you can provide globs if you don't surround by //, and you can use either globs or regexes in either context
[12:25] <Keybuk> sounds fine to me :)
[12:25] <Kamion> then I get the prettier syntax *and* consistency *and* don't break backward-compat
[12:25] <sivang> night Kamion , Keybuk , laters
[12:25] <Keybuk> WIN!
[12:26] <Kamion> night sivang
[12:26] <Keybuk> sivang: g'night
[12:26] <LaserJock> sivang: I thought the same thing, don't feel bad ;-)
[12:29] <Kamion> Keybuk: spec adjusted
[12:30] <Kamion> oh I'll just dump the current exclusions in
[12:30] <jdub> weird:
[12:30] <jdub> $ locale
[12:30] <jdub> locale: Cannot set LC_ALL to default locale: No such file or directory
[12:30] <jdub> LANG=en_AU.UTF-8
[12:30] <jdub> LANGUAGE=en_AU:en
[12:30] <jdub> 
[12:31] <Keybuk> strace
[12:32] <Keybuk> Kamion: ok, approved
[12:32] <Kamion> thanks!
[12:32] <Keybuk> given I suspect strongly it'll move straight to Implemented <g>
[12:32] <jono> hey jdub 
[12:33] <Keybuk> am about 1/3 though u6y partioner
[12:33] <Kamion> I'm not going to do the germinate regex changes tonight, but I'll attack that tomorrow
[12:34] <jdub> Keybuk: http://people.ubuntu.com/~jdub/2006/locale-strace.txt
[12:39] <Keybuk> jdub: odd
[12:39] <Keybuk> jdub: dpkg-reconfigure locales
[12:41] <jdub> Keybuk: hrm, it's "... done" for all of them (not skipping)
[12:41] <jdub> $ locale
[12:41] <jdub> LANG=en_AU.UTF-8
[12:41] <jdub> LANGUAGE=en_AU:en
[12:41] <jdub> 
[12:42] <Keybuk> what's your LC_COLLATE ?
[12:43] <jdub> LC_COLLATE="en_AU.UTF-8"
[12:43] <Keybuk> weird *shrug*
[12:43] <jdub> everything's en_AU.UTF-8 apart from LANGUAGE
[12:43] <jdub> but it's all ok now
[12:43] <Keybuk> wrong ABI I guess
[12:43] <Keybuk> dpkg --configure -a
[12:45] <lifeless> 'lo
[12:53] <jono> hmm
[12:57] <lifeless> gnight
[01:14] <mdz> sivang: if you've revised it, then you need to set it back to 'review' state to get further review
[01:30] <zul> hey
[02:31] <Keybuk> fabbione: ping?
[03:13] <Lathiat> wow the zeroconf thread fired off into a mess yestrday
[03:15] <Keybuk> it reached four levels
[03:15] <Keybuk> after that, all threads are inherently useless
[03:15] <Lathiat> heh
[03:16] <zul> heh...i dont have the energy to read that tonight
[03:16] <Lathiat> i skimmed over the second useless half of it
[03:24] <robertj> neuralis: you home?
[03:25] <neuralis> robertj: sorry, have we met?
[03:26] <robertj> neuralis: nope, just stalking based off a poste to -devel. Was going to ask you about the whole zeroconf flameware and whether an amended policy for zero-conf was 100% off the table
[03:26] <robertj> because the one thing I haven't read is "Let's do another code-audit and amend our policy"
[03:27] <neuralis> it's actually been relatively non-flamewarish. no one has called anyone an idiot yet ;)
[03:28] <neuralis> robertj: i don't think an amended policy is absolutely, completely off the table, but it's not too far from. going down the exceptions road is a slippery slope.
[03:29] <neuralis> robertj: i'm very strongly against it, to be sure. my mind could be changed, but it would require a good spec.
[03:30] <robertj> neuralis: I will say that I think a firewall is a non-solution
[03:31] <robertj> neuralis: would you accept a trite saying if it was true :)
[03:32] <neuralis> robertj: it might well be the case that the right thing to do is to open up zeroconf. but i want a spec convincing me, not a bunch of people shouting at each other on -devel.
[03:33] <robertj> the little saying that grinds my mind is this: things should be a simple as possible but no simpler
[03:33] <robertj> but it argues both sides of the coin, one in terms of UI and the other in terms of policy :)
[03:35] <neuralis> robertj: basically, i'm fully open to discussing this, but NOT without a spec. i want a spec that looks at the implications, zeroconf's privilege needs, possible solutions, et cetera.
[03:35] <robertj> neuralis: is there really not a spec yet?
[03:35] <neuralis> robertj: not that i've seen, but i haven't been looking at zeroconf too closely.
[03:36] <neuralis> robertj: there's kubuntu-easy-zeroconf targetting edgy, and zeroconf targetting dapper (deferred).
[03:37] <robertj> digging now
[03:37] <neuralis> robertj: both are looking at a way to enable zeroconf easily, but keep it turned off by default, so no spec exists that details what you're proposing.
[03:37] <neuralis> robertj: https://wiki.ubuntu.com/ZeroConfSpec and https://wiki.kubuntu.org/KubuntuEasyZeroconf
[03:38] <robertj> ahh I was looking in launchpad
[03:38] <neuralis> these are launchpad specs, yes.
[03:38] <robertj> I wans't finding em there, I should have used the Wiki
[03:38] <neuralis> robertj: they're there as zeroconf and kubuntu-easy-zeroconf, respectively. 
[03:39] <robertj> ahh now i'm on the ubuntu spec page
[03:42] <robertj> neuralis: your certainly right, no deluge of information in these "specs"
[03:44] <neuralis> robertj: it would be very helpful if you decided to remedy that.
[03:44] <robertj> should I start a new wiki page & spec?
[03:45] <robertj> ZeroConfSpec seems fine but the launchpad description does not
[03:45] <robertj> (fine as a name that is)
[03:45] <neuralis> yes, i'd start a new spec. you have until the 6th to get the spec approved, so you'd ideally want to have it done in a day or so.
[03:47] <robertj> you going to be on for the next little bit?
[03:48] <bddebian> Howdy
[03:51] <neuralis> robertj: 10pm here, i'm about to leave the office, but i'll be back on later tonight. feel free to mail me and request feedback.
[03:51] <robertj> will do, thanks
[04:00] <Keybuk> hmm
[04:01] <Keybuk> I have absolutely no idea what I've done to my knee :-/
[04:01] <zul> banged it?
[04:01] <bddebian> Blown ACL? :)
[04:01] <Keybuk> it's a dull pain _under_ the knee cap
[04:01] <bddebian> Ugh
[04:02] <bddebian> Water on the knee?
[04:02] <zul> i think i have that
[04:03] <Keybuk> yeah, that's vaguely what it feels like
[04:03] <Keybuk> probably a result of insufficent exercise at the conference
[04:03] <Hobbsee> morning Keybuk 
[04:04] <bddebian> Bah, I'm old, fat, and out of shape and my knee doesn't hurt :-)
[04:04] <tseng> bddebian++
[04:04] <bddebian> Heya tseng
[04:06] <Keybuk> I've got an edgy knee ... painful at the moment, but I'm sure it'll be fine given time
[04:06] <bddebian> hehe
[04:06] <neuralis> Keybuk: it'll be edgy+1, given time.
[04:08] <Hobbsee> Keybuk: i believe when foo = breezy
[04:08] <Hobbsee> when #ubuntu+1 started
[04:08] <Keybuk> Hobbsee: nah, it was a lot earlier than that
[04:08] <Hobbsee> although, maybe earlier
[04:08] <bddebian> Keybuk: I dunno but it's irritating
[04:08] <Hobbsee> bleh
[04:08] <Keybuk> I think foo was originally "woody"
[04:08] <Keybuk> bddebian: why?
[04:09] <Keybuk> Hobbsee: it's definitely something we inherited from Debian, and just started using when we ran out of pre-decided names
[04:09] <bddebian> Well not the term itself, just the usage.  Edgy barely opens and people start spouting Edgy+1.. :-)
[04:09] <Hobbsee> Keybuk: ah right
[04:09] <Keybuk> http://groups.google.co.uk/group/linux.debian.devel/browse_thread/thread/d0bf5b3ae3e75625/433891e87d7f0ab4?lnk=st&q=woody%2B1&rnum=8&hl=en#433891e87d7f0ab4
[04:11] <tseng> bddebian: because ubuntu is transparent enough for the noisy kids to make a fuss about the next release
[04:11] <Keybuk> bddebian: that's the best thing possible!
[04:11] <tseng> or maybe because the next release isnt 5 years in the future?
[04:11] <Keybuk> it's a sign of a mature time based release process when you can talk about "not for this release"
[04:12] <Keybuk> hmm, yeah, woody+1 is the earliest I can see ... don't find a potato+1 or slink+1 in my mail archive
[04:13] <Keybuk> woody+1 was probably the first time Debian sat down and thought about "the next release" while still doing a release (it was the first time Debian had testing/)
[04:17] <bddebian> OK,OK, I give up
[04:19] <zul> its like that nine inch nails song
[04:20] <zul> i tired...i gave up
[04:20] <Keybuk> zul: "Closer" ?
[04:20] <zul> yeppers
[04:21] <Keybuk> or a _different_ Nine Inch Nails song? :p
[04:21] <Keybuk> there's many to choose from
[04:21] <tseng> I think there is one called "Gave Up" actually
[04:21] <Keybuk> yeah, I was just thinking, I don't think I got the right one there <g>
[04:24] <bddebian> NiN..pfft.. Metallica...
[04:25] <zul> whatever
[04:26] <zul> Keybuk:  http://www.azlyrics.com/lyrics/nineinchnails/gaveup.html
[04:46] <robertj> Keybuk: can you look over https://wiki.ubuntu.com/ZeroConfPolicySpec please?
[04:58] <siriusnova> i feel really bad asking this in here but no one in #ubuntu can help me
[04:59] <siriusnova> :(
[04:59] <bddebian> You haven't asked anything
[05:00] <siriusnova> i need to recompile wpa supplicant because i am using patched madwifi drivers (no WPA menus show up in network manager) 
[05:00] <siriusnova> :/
[05:01] <siriusnova> how do i recompile wpa supplicant so that i can use Network manager and my new drivers, wep works fine
[05:01] <siriusnova> basically is my question 
[05:01] <siriusnova> i know ths is the wrong place to ask but no one in #ubuntu could help me
[05:01] <siriusnova> sry :(
[05:04] <bddebian> siriusnova: Sorry, I don't know
[05:04] <siriusnova> its ok
[05:04] <siriusnova> no one else does either haha
[05:07] <bluefoxicy> siriusnova:  file bugs with the patches and the issue and maybe somedev will look at it and fix it :P
[05:07] <siriusnova> hrmm ok
[05:07] <siriusnova> but do i need to recompile wpa after using patched drivers or not?
[05:07] <siriusnova> im confused about the issue
[05:07] <bluefoxicy> I have no idea
[05:07] <siriusnova> me either heh 
[05:07] <bluefoxicy> I am more thinking, why did you patch the drivers
[05:08] <siriusnova> for security testing, packet injection
[05:08] <bluefoxicy> file a bug on whatever problem required it for a start-- ah, that sounds like a useful feature :)
[05:08] <siriusnova> aircrack-ng etc..
[05:09] <bluefoxicy> (oh yes, "Ubuntu now supports cracking wifi encryption" in the list of new features for Edgy XD)
[05:09] <siriusnova> the default madwifi drivers dont support it so they have to be patched, i used madwifi-old and patched them. Network Manager with wep works fine but there is no WPA menu so i am assuming i had to recompile wpa too but i cant find any detailed information regarding what exactly i have to do
[05:09] <bluefoxicy> tseng: ssp looks to be on by default in edgy now, did pitti/doko fix the propolice issue on sparc?
[05:14] <bluefoxicy> .... o.O
[05:20] <bluefoxicy> I am STILL trying to figure out why certain things are in ubuntu-desktop (libgnome2-perl for now) ...
[05:34] <siriusnova> ok another stupid question, the madwifi in Dapper is madwifi-old right?
[05:37] <wasabi> All this ZeroConf talk is interesting.
[05:38] <jsgotangco> :)
[05:42] <bluefoxicy> what does Ubuntu use cpio for...?
[05:46] <msw> bluefoxicy: initramfs?
[05:46] <bluefoxicy> msw:  figured it probably did... you could use tar/gzip for that or cpio, either or.
[05:47] <msw> bluefoxicy: note that you have to have the archive unpacker in kernel code -- you don't want to have to support every formt under the sun
[05:47] <msw> format
[05:47] <bluefoxicy> oh
[05:47] <bluefoxicy> cpio works on its own archive format, not on tarballs?
[05:48] <msw> right
[05:48] <bluefoxicy> wait.. I thought initrds were EXT2 file system images that were gzip'd?
[05:48] <msw> that'
[05:48] <msw> that's old initrd -- not initramfs
[05:48] <bluefoxicy> what's initramfs?
[05:48] <msw> bluefoxicy: http://marc.theaimsgroup.com/?l=linux-kernel&m=101095500820185&w=2
[05:49] <msw> alas, I must retire - gnight
[05:49] <msw> see also http://lwn.net/Articles/14776/
[05:50] <bluefoxicy> msw:  interesting
[05:50] <bluefoxicy> msw:  I had considered busybox + tarball on the initrd; mount a tmpfs; unpack the tarball to it; copy busybox into it; pivot_root; exec a fresh /linuxrc; umount the ramdisk
[05:50] <bluefoxicy> which would appear to generate the same results
[05:51] <bluefoxicy> I guess kernel code to do this shorter is simpler though ;)
[05:51] <msw> somewhat -- initramfs's size is dynamic
[05:51] <bluefoxicy> so is a tmpfs
[05:51] <bluefoxicy> you specify a max size but really it uses about 0 until it stores files
[05:51] <msw> whereas initrd has to have a RAMDISK_SIZE set large enough to decompress the image
[05:51] <bluefoxicy> yeah
[05:51] <bluefoxicy> (it doesn't calculate that on the fly?)
[05:52] <msw> no
[05:52] <msw> you can set it on the kernel command line
[05:52] <bluefoxicy> ok point made :)
[05:52] <msw> but it's not dynamic
[05:52] <bluefoxicy> night msw
[05:53] <msw> g'night
[06:40] <renewip> hi, can I write on ntfs partition if I rebuild ubuntu kernel ???
[06:51] <wasabi> grrr. udev.
[07:00] <anibal> fabbione, ping
[07:05] <fabbione> morning
[07:05] <fabbione> anibal: pong
[07:11] <siriusnova> im going to shoot my laptop
[07:11] <siriusnova> :X
[07:17] <stub> Launchpad will be going down in 15 minutes for its regular code update. Estimated downtime is 20 mins.
[07:56] <anibal> fabbione, when you have a chance, please have a look at my package nfs-utils_1.0.8-10ubuntu1
[07:58] <fabbione> anibal: where is that supposed to be?
[07:58] <crimsun> 14:40 < crimsun> fabbione: anibal has prepared merged nfs-utils at  http://users.monash.edu.au/~anibal/ubuntu/nfs-utils/ . They look sane to me.
[07:58] <fabbione> oh
[07:58] <fabbione> meh.. ok
[07:58] <fabbione> yeah
[07:58] <fabbione> it's kind of overkill to check a merge
[07:59] <fabbione> it's faster to do it 
[07:59] <fabbione> but ok
[07:59] <crimsun> fabbione: just following protocol ;)
[07:59] <anibal> fabbione, I would like to keep my debian packages in sync with the ubuntu packages
[07:59] <fabbione> anibal: yes i could guess that
[08:00] <fabbione> i don't disagree at all in the reason why
[08:00] <fabbione> anyway fetching
[08:00] <fabbione> anibal: did you consider to join the MOTU and later core-dev?
[08:01] <anibal> fabbione, I'm very interested to join the MOTU and later core-dev :)
[08:01] <fabbione> anibal: ok
[08:03] <anibal> it would be nice to upload same versions of packages to debian and ubuntu at the same time :)
[08:03] <anibal> mdz, hello
[08:04] <fabbione> anibal: what's the diff between the deb and ubuntu package by now?
[08:04] <fabbione> i mean what's leftover?
[08:05] <sivang> morning
[08:05] <anibal> the lbs in the init.d scripts
[08:05] <fabbione> and that's it?
[08:05] <anibal> yep
[08:06] <anibal> soon the debian and ubuntu packages will be the same
[08:06] <fabbione> anibal: didn't debian adopt the lsb stuff already?
[08:07] <anibal> yep
[08:07] <anibal> it's one of our release goals
[08:07] <fabbione> right
[08:07] <fabbione> so why can't we just merge the lsb changes in -11 and we sync from you?
[08:07] <fabbione> what's holding that up?
[08:08] <anibal> testing
[08:08] <anibal> I need to test it
[08:08] <fabbione> anibal: what kind of testing would you like to see?
[08:08] <fabbione> we have been using this changes for the last 2 years + or -
[08:08] <fabbione> and i do personally use nfs here
[08:09] <anibal> and also, I want to have the current package moved to etch, before I introduce the lsb changes
[08:09] <fabbione> fair enough
[08:09] <fabbione> all good reasons
[08:09] <fabbione> ok
[08:09] <fabbione> i will upload these changes to edgy
[08:10] <anibal> fabbione, ta
[08:10] <fabbione> but can you be so kind to remind me when -11 with lsb changes will hit sid?
[08:10] <fabbione> at that point we can enable the autosync
[08:10] <anibal> ok
[08:10] <fabbione> and you just upload to sid
[08:10] <fabbione> does it sound like a plan for you?
[08:10] <anibal> yep, sound good to me :)
[08:11] <anibal> s/sound/it sounds
[08:11] <fabbione> perfect
[08:12] <anibal> thanks again
[08:12] <fabbione> no problem
[08:13] <fabbione> anibal: uploaded
[08:13] <fabbione> thanks for the merge
[08:13] <anibal> good :)
[08:45] <fabbione> anibal: did you get all the bits and pieces for NFSv4 too, right?
[08:46] <fabbione> (catching up on -devel)
[09:03] <fabbione> E: Could not open file /var/lib/apt/extended_states - open (2 No such file or directory)
[09:03] <fabbione> E: Failed to open StateFile /var/lib/apt/extended_states
[09:03] <fabbione> mvo: ^^
[09:03] <fabbione> mvo: what the hell is that?
[09:03] <mvo> fabbione: ah, thanks
[09:04] <fabbione> mvo: freshly updated EDGY :P
[09:04] <sivang> probably the code that was moved from aptitude to apt? :)
[09:05] <mvo> fabbione: I'm fixing this with the next upload
[09:05] <mvo> sivang: yes
[09:06] <fabbione> mvo: ok thanks :)
[09:06] <sivang> mvo: cool :) Will I be able to call the package left over removal stuff from another program? 
[09:06] <mvo> sivang: yes, I will send a mail about this soonish
[09:07] <sivang> mvo: yay
[09:08] <mvo> fabbione: what operation did give you this message?
[09:08] <fabbione> apt-get install libx11-dev
[09:09] <fabbione> mvo: everything did install fine
[09:09] <fabbione> the error was the very end
[09:09] <mvo> fabbione: thanks, I have it here now too
[09:09] <fabbione> Setting up libxt-dev (1.0.0-0ubuntu3) ...
[09:09] <fabbione> E: Could not open file /var/lib/apt/extended_states - open (2 No such file or directory)
[09:09] <fabbione> E: Failed to open StateFile /var/lib/apt/extended_states
[09:09] <fabbione> mvo: no problem at all
[09:22] <pitti> hi ivoks 
[09:22] <ivoks> pitti: hi
[09:22] <ivoks> i have great news
[09:23] <pitti> hi sivang 
[09:23] <ivoks> pitti: i found python ipp library
[09:23] <pitti> ivoks: oh, I thought you knew about it?
[09:23] <ivoks> pitti: it's even better than redhat's pycups
[09:23] <pitti> ivoks: jamesh wrote a python module for it once
[09:23] <pitti> but I thought you would know it
[09:24] <ivoks> pitti: jamesh?
[09:24] <ivoks> i found ipplib
[09:24] <ivoks> (c) 2003, 2004, 2005, 2006 Jerome Alet
[09:24] <jamesh> ivoks: mine is at http://www.gnome.org/~jamesh/code/ipplib.py
[09:25] <jamesh> haven't touched it for a few years
[09:25] <ivoks> heh
[09:25] <ivoks> this one is fresh (may 2006)
[09:25] <ivoks> but i'll take a look at yours
[09:25] <pitti> jamesh: your's was very nice for a few debugging tasks so far :)
[09:25] <ivoks> maybe combine it with this one
[09:25] <jamesh> mine worked okay with cups and HP jetdirect cards
[09:25] <jamesh> but I had some problems talking to a Canon ImageRunner
[09:26] <ivoks> i needed to talk with cups only, atm
[09:26] <ivoks> svn://svn.librelogiciel.com/ipplib/trunk iplib
[09:26] <jamesh> ivoks: actually http://www.jamesh.id.au/files/ipplib.py is a little newer
[09:26] <ivoks> ipplib
[09:32] <ivoks> same name, but somewhat different :)
[09:33] <ivoks> i'll tak a look at your ipplib later today, when i'm back from work
[09:34] <ivoks> bye for now
[09:49] <dholbach> good morning
[10:24] <carlos> doko: ping
[11:04] <sivang> morning dholbach 
[11:04] <raphink> hi sivang, dholbach
[11:04] <dholbach> hi sivang, raphink
[11:04] <raphink> :)
[11:04] <raphink> hi cousin :)
[11:05] <raphink> lol
[11:05] <sivang> hehe
[11:06] <sivang> raphink: hey Mr. Grunberg :)
[11:06] <raphink> ;)
 doko: ping
 carlos: pong
[11:25] <carlos> doko: I'm on a phone call, give me some minutes...
[11:26] <anibal> fabbione: that was the last package waiting for NFSv4, everything looks good now :)
[11:26] <carlos> doko: I'm back
[11:26] <fabbione> anibal: ok thanks
[11:26] <carlos> doko: what's the status of OO.org language packs?
[11:26] <fabbione> who is Glite that just edited UbuntuCluster ?
[11:27] <carlos> doko: other than the warning we saw? did you manage to workaround the long path problem?
[11:27] <carlos> s/saw?/saw,/
[11:37] <doko> carlos: yes, removing two languages :)
[11:38] <carlos> doko: so, are we able to upload an update?
[11:45] <\sh> mvo: ping 
[11:46] <mvo> \sh: pong
[11:47] <\sh> mvo: aptitude: Depends: libapt-pkg-libc6.3-6-3.11 but it is not installable
[11:47] <\sh> mvo: freshly created edgy chroot :)
[11:49] <mvo> \sh: its edgy ;)
[11:49] <mvo> \sh: there is a new version of aptitude uploaded, its just not build yet
[11:49] <mvo> \sh: we got a new apt (PHEAR!)
[11:49] <Kamion> seb128: libcairo binaries newed
[11:49] <seb128> Kamion: thank you!
[11:49] <\sh> mvo: yes ;) ah ok...I thought it was the latest aptitude
[11:49] <doko> carlos: carlos didn't check yet, trying to get 2.0.3 built before seb128 starts to upload the new gnome
[11:49] <mvo> \sh: 0.4.1-1.1ubuntu2 is currently waiting to be build
[11:53] <\sh> mvo: k
[12:07] <carlos> doko: ok
[12:23] <dholbach> Gloubiboulga: i'm just merging goffice and gnumeric - it'd be nice if you'd look over them (later) and see if I retained your *-gtk* changes correctly
[12:46] <ogra> Riddell, do you have any idea what happened to the plans of the kdeedu guys to split the source in single packages ? it seems to get bigger and bigger with every release
[12:50] <Riddell> ogra: I've not heard of any such plans, packagers keep asking for it but KDE quite like their large modules
[12:50] <Riddell> ogra: are you merging kdeedu?
[12:50] <ogra> i'm about to ... seems trivial
[12:50] <ogra> unless you claim it
[12:50] <Riddell> nope, go ahead
[12:51] <Riddell> although adding the ocaml stuff to it would be cool
[12:51] <ogra> its just the 60Mb upload thats a *bit* annoying everytime :)
[12:51] <Riddell> unfortunetely the ocaml build stuff is broken
[12:51] <ogra> oh, so i should probably wait and jump on something else for now
[12:52] <Riddell> why?
[12:52] <ogra> well, if it ftbfs ...
[12:53] <ogra> (i like to see my results asap after doing package work, else i tend to forget about it :) )
[12:54] <Riddell> it'll get stuck in NEW, I think there's a kdeedu-dbg package added
[12:54] <Riddell> but the ocaml stuff is broken upstream, it doesn't do builddir!=sourcedir
[12:54] <Riddell> so to add it to the kdeedu package you'd need to do funky tricks to get it to build
[12:55] <ogra> any ETA when that'll be fixed ?
[12:56] <Kamion> ok, since you two (Riddell/ogra) are here, I think I should have seed-cleanup pretty much implemented, so shortly I'll change the Ubuntu seeds to say "Extra-Include: *-dbg *-dev *-doc" and a few excludes to eliminate the packages matching those patterns that we don't want
[12:56] <\sh> when is the cronjob running which is pushing newly build packages to a.u.c?
[12:56] <Kamion> you will have a somewhat interesting merge as a result
[12:56] <pitti> \sh: at :03 hourly AFAIK
[12:57] <\sh> pitti: thx
[12:57] <Kamion> feel free to talk to me if you're confused, but the upshot is that we shouldn't need to seed -dbg/-dev/-doc packages by hand any more
[12:57] <ogra> Kamion, fun :)
[12:57] <Kamion> \sh: it *starts* at :03 hourly but takes quite a while to run; in practice the mirrors don't get triggered until :40 or so
[12:58] <Riddell> Kamion: cool
[12:58] <\sh> hmm...complete ubuntu server with apache, nfs, tftp, dhcp3, fai + configuration in 150secs...too long
[12:59] <\sh> time to beat: <=120secs
[01:00] <pygi> jdub, you have a sec?
[01:00] <Hobbsee> pygi: i believe he's severely jetlagged and asleep
[01:00] <pygi> Hobbsee, oki, thanks :)
[01:00] <ogra> Riddell, libfacile-ocaml-dev is already in kdeedus build deps
[01:00] <ogra> seems thats a no op for us
[01:01] <Riddell> ogra: oh, interesting
[01:01] <Riddell> ogra: want to do the main inclusion report for libfacile-ocaml-dev? :)
[01:01] <ogra> meh, but they also added a dep for a ttf we dont have ...
[01:02] <pitti> Riddell: ouch, do you want to reintroduce ocaml to main?
[01:02] <ogra> well, i have to do one for ttf-sjfonts, so i can do the one for libfacile-ocaml-dev as well
[01:02] <pitti> Riddell: we were about this -><- close to throw it out
[01:02] <Riddell> pitti: it's mostly up to ogra, whether he wants/needs the functionality it adds
[01:02] <ogra> pitti, write me some educational gnome apps and we can drop kdeedu and ocaml from main :P
[01:03] <ogra> (i'd *so* love to drop it)
[01:04] <pitti> ogra: find -type f | xargs sed -i s/G/K/g in the sources is not eough to port it :-P
[01:04] <ogra> :P
[01:05] <Riddell> ogra: you can still remove the ocaml stuff if you want to keep pitti happy
[01:05] <ogra> i guess i'll do that then ... we lived fine without it in dapper
[01:06] <ogra> at least i have heard no complaints yet
[01:06] <\sh> what kdeedu app needs ocaml?
[01:06] <ogra> all ?
[01:06] <Riddell> \sh: kalzium I think
[01:06] <ogra> at least kalzium
[01:06] <Riddell> and it doesn't need it, it just adds some extra features if you have it
[01:06] <ogra> which is the main reason for kdeedu in edubuntu
[01:06] <\sh> and kalzium needs it to run properly or is it just some scientist gimmick?
[01:06] <pygi> ogra, sorry for interupting, but arent we removing kdeedu from edgy?
[01:07] <ogra> its an optional add on
[01:07] <ogra> pygi, if you have a replacement 
[01:07] <\sh> ogra: then throw ocaml somewhere but not in kdeedu ;)
[01:07] <Riddell> it can probably be split out into a separate source package without too much difficulty
[01:08] <ogra> you mean kalzium ? 
[01:08] <Riddell> I mean the ocaml bits of it
[01:08] <ogra> hmm
[01:09] <pygi> ogra, I don't really have a replacement, but ... 
[01:10] <Riddell> ogra: so I'd say remove the ocaml dep to keep pitti happy and I'll find an elite MOTU to build the ocaml stuff in a separate universe package
[01:10] <\sh> pygi: without kdeedu edubuntu has nothing...I think it helds the majority of edu apps...but I can be wrong
[01:10] <ogra> pygi, well, Kamion donated 20MB free space to the CD so if we now could switch yelp to xulrunner and have epiphany as default browser that should gain us a lot in the end ...
[01:11] <ogra> Riddell, fine with me :)
[01:11] <spacey> epiphany++ =)
[01:13] <pitti> Riddell, ogra: don't worry too much, ocaml isn't a real burden
[01:13] <pitti> if you need it, we keep it
[01:14] <ogra> pitti, no we dont *need* it (apparently)
[01:14] <tseng> ogra: so, is there a real plan to move anything to xulrunner?
[01:14] <tseng> ogra: i am merging gecko-sharp2 which uses libxul in debian
[01:14] <ogra> tseng, well, edubuntu needs to switch to epiphany in any case
[01:14] <tseng> ogra: i was going to build on firefox-dev per our last talk
[01:14] <tseng> and epiphany will use libxul?
[01:15] <ogra> tseng, ask the epiphany maintainer :)++
[01:15] <ogra> seb128, do you plan to go with debian here ? 
[01:15] <ogra> i know there is an informal spec
[01:16] <tseng> I am assuming it is pretty safe to mix firefox-dev and libxul-dev packages at runtime?
[01:16] <dholbach> ogra: epiphany and everything else will build with firefox
[01:16] <ogra> no idea, i'd drop all ff-dev deps if possible
[01:16] <dholbach> ogra: it makes no sense to have firefox AND xulrunner source in main
[01:16] <ogra> dholbach, why ? thats a huge delta to debian we produce here
[01:17] <dholbach> it's not, it's some characters in debian/control and debian/rules
[01:17] <ogra> so i still have to waste tens of megabytes in the edubuntu CD, sigh
[01:18] <dholbach> ogra: it's not my decision, but try to ask pitti and iwj if they want to support xulrunner and firefox in main
[01:18] <ogra> OLPC wont work either withhout xul btw
[01:18] <dholbach> ogra: firefox supports xul too - xulrunner is just the name of the 'engine'
[01:19] <ogra> yes
[01:19] <ogra> but firefox pulls in language packs
[01:19] <Kamion> indeed, if firefox can be built against xulrunner then that would solve the problem
[01:19] <ogra> its not ff itself
[01:19] <ogra> its the deps that make probs 
[01:19] <Kamion> we may not want to push that ourselves, but the xulrunner maintainer in Debian is also one of the firefox maintainers
[01:20] <pitti> dholbach, ogra: If firefox can use xulrunner, then I'm fine with it; otherwise, having two copies of ffox code on the CD seems bad to me (not even considering the overhead of providing security updates for two copies)
[01:20] <ogra> s/make probs/eat space/
[01:20] <dholbach> for that we need a supported and maintained "firefox-without-xulrunner-parts" tarball from upstream
[01:20] <ogra> pitti, my biggest prob are the deps of yelp and epiphany
[01:20] <ogra> if these two could swwitch i'd already be fine ... 
[01:21] <ogra> i'm not after commiting to be xulrunner maintainer, but if thats the only way i'd even take the bllame here
[01:21] <ogra> (indeed that still duplicates the source)
[01:24] <dholbach> iwj: do you know something about the state of things concerning "firefox-without-xulrunner-parts"?
[01:24] <heno> mvo: ping
[01:25] <heno> dholbach: will you guys be taking this https://wiki.ubuntu.com/FutureOfGst forward for Edgy?
[01:25] <dholbach> heno: yes, carlos garnacho will work on some select fixes and problems
[01:26] <heno> dholbach: ok, there is some related work being done by these people: http://www.ubuntuforums.org/showthread.php?t=207894 FYI
[01:26] <tseng> dholbach: carlos rocks!
[01:27] <dholbach> heno: that's more about control-center, isn't it?
[01:27] <heno> dholbach: yes (heno is still not quite clear on where those overlap ...)
[01:28] <heno> dholbach: any work on control-center being planned I could look at?
[01:28] <dholbach> heno: to me it seems they are only referring to control-center
[01:28] <dholbach> heno: just upstream control-center CVS, sorry
[01:28] <heno> ok
[01:30] <sladen> ogra: we ported xpdf to poppler, which is a fairly similar setup
[01:30] <ogra> sladen, yes, but poppler is in main already and doesnt duplicate source
[01:31] <Riddell> pitti: any opinion on adding back gpgsm to kdepim in edgy?  I've talked to the upstream and he insists its stable despite having a .9 version number
[01:32] <pitti> Riddell: that's gnupg2, right?
[01:33] <Riddell> pitti: yes
[01:33] <pitti> Riddell: is there any ETA for 2.0 release?
[01:33] <pitti> Riddell: I wouldn't mind too much having it in main
[01:34] <Riddell> pitti: "sometime in summer", but I wouldn't hold my breath for it
[01:34] <tseng> any build admins who can try kicking mono-tools?
[01:35] <fabbione> tseng: you need to ask Keybuk when he is around
[01:35] <tseng> fabbione: k.
[01:40] <ogra> hrm, why the heck did they add cdbs as build dep to kdeedu ... there are no cdbs bits in it at all ...
[01:45] <Gloubiboulga> dholbach, ok (about goffice/gnumeric), I'll have a look
[01:48] <dholbach> Gloubiboulga: i wait on a sync and upload another merge before - i'll notify you
[01:49] <iwj> dholbach: No, I know nothing about that.
[01:49] <iwj> Sorry.
[01:50] <Kamion> I'm about to do a sync run now
[01:50] <dholbach> iwj: it would have been the perfect opportunity to introduce it in a "edgy" release cycle. :-)
[01:50] <dholbach> Kamion: thanks a lot - you rock! :-)
[01:51] <tseng> https://launchpad.net/people/brandon/+packages
[01:51] <tseng> if anyone missed this page like I did
[01:51] <tseng> most useful thing of all time
[01:55] <fabbione> oh cow
[01:55] <fabbione> they fixed it
[01:56] <pitti> fabbione: moo?
[01:56] <fabbione> my page is endless.. i don't even want to think about Colin or Seb :)
[01:58] <zul> hey
[01:58] <pitti> hi zul
[01:59] <zul> hey pitti how is it going?
[01:59] <Hobbsee> hi zul 
[01:59] <zul> hey Hobbsee 
[02:01] <heno> what's the right procedure for suggesting removals from edgy main? 
[02:01] <ogra> grmbl ... you cnat build that silly kdeedu sourcepackage in dapper, sigh
[02:01] <\sh> a segmentation fault during building is not a good sign
[02:01] <Kamion> heno: file a bug on the package concerned and subscribe ubuntu-archive
[02:01] <heno> Kamion: ok, thanks
[02:01] <Kamion> heno: see https://wiki.ubuntu.com/DeveloperResources for documentation of this and caveats
[02:02] <\sh> removals from main?
[02:02] <heno> cool, thx
[02:02] <ogra> \sh, demotions to universe
[02:02] <Kamion> heno: oh, you meant demotions, not removals?
[02:02] <heno> Kamion: yes, demotions 
[02:02] <Kamion> heno: ok, see "Seed management" in DeveloperResources
[02:03] <heno> thx
[02:03] <\sh> anyone familiar with dietlibc?
[02:03] <Riddell> ogra: why not?
[02:04] <ogra> Riddell, it needs cdbs 0.4.37
[02:04] <Riddell> ogra: which kde.mk is it using?
[02:04] <ogra> debian/cdbs/debian-qt-kde.mk: No such file or directory
[02:04] <Hobbsee> ogra: what? why?
[02:04] <Hobbsee> bleh
[02:05] <Hobbsee> guess you can call it anything if you're shipping it with the package
[02:05] <ogra> it has a build dep on cdbs >= 0.4.37 which apparently ships that file 
[02:05] <Riddell> debian-qt-kde.mk is part of the package
[02:05] <ogra> its just annoying that i have to build an edgy chroot just to build the source package
[02:05] <Hobbsee> oh good
[02:05] <Riddell> hopefully it'll use the stock kde.mk
[02:06] <Riddell> ogra: if you're developing for edgy it's kindae a good idea to have an edgy chroot
[02:06] <ogra> Riddell, well, for most sourcepackages a edgy pbuilder is sufficient ... 
[02:06] <\sh> bin-i386/diet gcc -pipe -nostdinc -Os -fomit-frame-pointer -falign-functions=1 -falign-jumps=1 -falign-loops=1 -mpreferred-stack-boundary=2 -Wall -W -Wchar-subscripts -Wmissing-prototypes -Wmissing-declarations -Wno-switch -Wno-unused -Wredundant-decls -o bin-i386/elftrunc contrib/elftrunc.c
[02:06] <\sh> make[1] : *** [bin-i386/elftrunc]  Segmentation fault
[02:06] <\sh> not for this 
[02:07] <Kamion> doko: re 51818, did you check out the wxwidgets2.6 changes?
[02:07] <Kamion> ogra: and a pbuilder is what exactly if not a chroot? ;-)
[02:07] <ogra> having to have a chroot to just create a sourcepackage is just bad ... you'll not be able to backport for example ...
[02:07] <fabbione> ogra: you should be running edgy no matter what :)
[02:07] <ogra> Kamion, well, an additional one just to have a source package i can throw into pbuilder 
[02:08] <Kamion> 'pbuilder login' HTH
[02:08] <fabbione> ogra: you have pbuilder login to enter the chroot
[02:08] <ogra> fabbione, and suffer from all the breakage you guys introduce ? :)
[02:08] <fabbione> ogra: and the chroots are in /var/ somewhere
[02:08] <ogra> Kamion, i know
[02:08] <fabbione> edgy is BUG FREE
[02:08] <ogra> i find it still wrong for a source package to do that
[02:08] <zul> hey fabbione 
[02:08] <fabbione> hey zul
[02:08] <Hobbsee> fabbione: famous lasts words :P
[02:09] <Yagisan> of course there are no moths in edgy ;)
[02:09] <ogra> fabbione, really 
[02:09] <ogra> 7me quickly starts the upgrade
[02:09] <fabbione> Hobbsee: it works (for me) so it must work for everybody
[02:09] <fabbione> Hobbsee: if it doesn't work, your setup is wrong
[02:09] <Mithrandir> fabbione: yeah, must be hardware bugs.
[02:10] <fabbione> Mithrandir: they are indeed
[02:10] <zul> ogra: evolution is so much fun though
[02:10] <ogra> Mithrandir, sorry for the makedev merge yesterday, Kamion told me about your plans but it was urgent to fix a fuse bug 
[02:10] <ogra> zul, especially on powerpc :)
[02:12] <ogra> i.e. if you forget that searching in mailboxes gets evo in an infinite crash loop and you have to delete your mailboxes completely to make it work again, these are the moments where i think about reinstalling breezy :P
[02:14] <zul> yeah thats why i dont use it
[02:14] <ogra> well up to breezy it worked fine ...
[02:14] <Mithrandir> evo is quite debuggable so it should be easy enough to track down and get a fixed version into -updates and edgy, though
[02:14] <tseng> so
[02:15] <tseng> so far evo 2.7 has worked better for me
[02:15] <ogra> in dapper i get at least one "evo recieved an X window system error" a day if i just move the mouse over the window and that upstream search bug they dont find a fix for
[02:15] <ogra> Mithrandir, its an upstream bug they didnt find the cause for in time ...
[02:16] <ogra> but well, i'll go to edgy, things can only get better :)
[02:17] <tseng> edgy so far is our smoothest devel cycle yet
[02:17] <tseng> ironically
[02:17] <ogra> tseng, wait until rodarvus starts his work :P
[02:18] <rodarvus> tseng, things will change on this regard ;)
[02:18] <tseng> rodarvus: oh no!
[02:18] <tseng> daniels-lite
[02:18] <tseng> (I *hope* -lite)
[02:22] <doko> Kamion: yes
[02:22] <Kamion> doko: thanks
[02:25] <sivang> ogra: I switched to thunderbird. Gives me much better workflow with imaps
[02:25] <ogra> sivang, i'm fine with evo... as long as it works ;)
[02:26] <sivang> ogra: it mostly worked for me actually, but it took too much time to fetch emails, and to shutdown when I wanted to close my machines. Also I find it easier to read emails with it and do all srots fo sorting and grouping
[02:28] <ogra> sivang, but it would be boring if i had nothing to rant about on days you can only survive with 2kg of icecram to your left and right and with your feet in a bucket of iced water ;)
[02:29] <sivang> ogra: ha ha ha, I'm actually trying to use my room's AC, currenly it failes to really cool the room :)
[02:34] <doko> Kamion: please sync #51777 as well, so that the other python packages can build
[02:35] <sivang> malone #51777
[02:35] <Ubugtu> Malone bug 51777 in Ubuntu "sync requests" [Untriaged,Fix released]  http://launchpad.net/bugs/51777
[02:37] <sivang> doko: I saw there was already one sync of python-support, no? (as in the "updated mergers" in m.u.c)
[02:37] <mvo> \sh: I will request a ssync for cpunit (you touched it last, that is why I tell you :)
[02:37] <mvo> cppunit
[02:38] <Kamion> doko: ...
[02:39] <Kamion> doko: I did that first
[02:39] <Kamion> can a member of ubuntu-dev confirm bug 51824, please?
[02:39] <Ubugtu> Malone bug 51824 in fonttools "sync fonttools 1.99+2.0b1+cvs20060225-1 from unstable" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/51824
[02:41] <doko> Kamion 51824 looks ok, just python changes
[02:41] <Kamion> doko: thanks, could you put a note in the bug?
[02:42] <Kamion> doko: oh, don't bother, it was one of your python syncs already
[02:42] <Kamion> thanks
[02:43] <doko> Kamion: hmm, didn't get an email for the 51777 syncs
[02:43] <doko> I should subscribe to edgy-changes ...
[02:44] <pitti> Keybuk: did you plan to process NEW today?
[02:44] <Keybuk> pitti: I process NEW *everyday*
[02:44] <pitti> ok, cool :)
[02:44] <Kamion> doko: they're definitely in accepted
[02:44] <Kamion> with the exception of the one that landed in new
[02:44] <pitti> Keybuk: I uploaded the first version of pkg-create-dbgsym today; it should remain in universe for now
[02:45] <pitti> Keybuk: (it's not urgent, just telling you for the overrides)
[02:47] <\sh> slomo: ping
[02:48] <\sh> grmpf
[02:49] <sivang> \sh: He'll be online this evening
[02:49] <sivang> \sh: he has project in uni he needs to attend to, etc
[02:49] <\sh> libquicktime sync depends on libavcodec-dev which is in universe, because ffmpeg is universe, too
[02:49] <pitti> Keybuk: if you could accept gnutls13 from NEW soon, that would rock
[02:49] <\sh> or are there plans to promote ffmpeg to main?
[02:50] <Kamion> $ q info gnutls
[02:50] <Kamion> Listing ubuntu/edgy (NEW) 0/17
[02:50] <zul> BenC: ping
[02:50] <tseng> \sh: are you kidding?
[02:50] <\sh> tseng: no...looks like I have to deal with libquicktime first
[02:50] <Keybuk> Kamion: u6y-advanced-partitioner approved
[02:50] <tseng> Keybuk: hi, can you please kick mono-tools, evolution-sharp
[02:50] <Kamion> \sh: I believe that one will need a merge but I'm not sure
[02:50] <Kamion> Keybuk: thanks
[02:51] <Keybuk> tseng: define "kick"
[02:51] <pitti> Kamion: oh, hm; it's in unstable, I thought we'd automatically get it
[02:51] <\sh> Kamion: it was a sync on 2006-06-28 
[02:51] <tseng> Keybuk: "rebuild the same source package on the buildd because it theoretically works fine now"
[02:51] <\sh> Kamion: https://launchpad.net/distros/ubuntu/edgy/+source/libquicktime/
[02:51] <tseng> evo-sharp had a broken evo-dev at the time, bad luck
[02:51] <tseng> similar for mono-tools
[02:51] <Kamion> pitti: it's on the new-packages list
[02:52] <Keybuk> tseng: ah, you want a give-back
[02:52] <Kamion> Keybuk: do you wanna sync gnutls13? I'm bored of archive admin for a bit
[02:52] <tseng> Keybuk: hm right sorry
[02:52] <Keybuk> Kamion: sure
[02:52] <Keybuk> tseng: ok, all needs-build again
[02:52] <tseng> Keybuk: thanks!
[02:53] <Keybuk> pitti: any ubuntu changes?
[02:53] <pitti> Keybuk: for what?
[02:54] <Keybuk> gnutls13 ?
[02:54] <pitti> Keybuk: oh, that's not in ubuntu yet
[02:54] <Kamion> it's new
[02:54] <Keybuk> oh, I see, it's literally NEW in Debian
[02:54] <Keybuk> E: libgnutls-dev is in main but it's source (gnutls13) is not.
[02:54] <pitti> Keybuk: right now, the gnutls12/13 libtasn1-2/3 situation is quite confused
[02:54] <Keybuk> grr
[02:54] <pitti> we need to clean it up
[02:54] <Keybuk> Kamion: can we get a cruft-check for that one?  (binary in main, but source in universe)
[02:55] <pitti> Keybuk: Keybuk libgnutls-dev is currently built from gnutls12 for us
[02:55] <Kamion> Keybuk: anastacia reports it
[02:55] <Kamion> you'll get "source only promotions to main" or some such
[02:55] <pitti> Keybuk: (it's not new in Debian, BTW)
[02:55] <Kamion> (I just promoted python-central for the same thing)
[02:55] <Keybuk> Kamion: it doesn't ?
[02:55] <Keybuk> Kamion: e.g. gnutls12 above
[02:55] <Kamion> Keybuk: when you're syncing a new source, use -f -F to override the component check
[02:55] <Keybuk> Kamion: yeah, I know the override wibble :p
[02:55] <Kamion> Keybuk: gnutls13 is not in Ubuntu and sync-source assumes universe therefore
[02:56] <Kamion> if it's being newed into main then it's not a problem
[02:56] <Kamion> Keybuk: anastacia obviously doesn't report it when the package isn't in the archive yet
[02:56] <Keybuk> ah, duh
[02:56] <Keybuk> right, it's just sync-source being silly, that one
[02:56] <Kamion> Keybuk: sync-source is saying "libgnutls-dev is in main but you're asking me to sync new source for it which [I think]  won't be in main"
[02:57] <Keybuk> yeah
[02:57] <Keybuk> I've seen it the other way too, where syncing a non-new package had the same problem
[02:57] <Keybuk> but I haven't looked at anastacia in edgy through fear
[02:57] <Kamion> yeah, that's possible in the event that it starts generating packages it didn't previously generate
[02:57] <Keybuk> yup
[02:57] <Kamion> I'm not touching demotions from main in edgy until hppa catches up or I'm told not to care
[02:58] <Keybuk> heh
[02:58] <Keybuk> I figure caring about promotions is sufficient for not
[02:58] <Kamion> yeah
[02:58] <Keybuk> btw, who put type-handling in the supported seed? :p
[02:58] <Kamion> Keybuk: that's a weird-shit germinate thing
[02:59] <Kamion> it's not actually in supported, it's because type-handling provides: linux
[02:59] <Keybuk> linux is in the supported seed?
[02:59] <Kamion> but for some reason germinate isn't picking the real package
[02:59] <Kamion> %linux-meta is in supported
[03:00] <Kamion> it's not a massive deal, I'll figure it out at some later point and in the meantime we can just ignore it
[03:00] <Kamion> Keybuk: I implemented seed-cleanup this morning - just deployment stuff to go before we can delete loads of stuff from supported
[03:01] <pitti> Keybuk: basically we have two options: first get rid of libtasn1-2 to migrate to 1-3, and then do the gnutls12->13 migration as a second step (which will mean to rebuild a lot of packages twice), or do it all in one shot (tasn+gnutls) which will be messier, but faster
[03:01] <Kamion> actually didn't pull in toooo many new binaries, but enough to reassure me that it was actually doing something :)
[03:01] <Kamion> Keybuk: I also halved germinate's runtime ;-)
[03:01] <Keybuk> \o/
[03:01] <\sh> if someone cares, on http://archive.linux-server.org/ is the new libquicktime source package which resolves the dep-wait and can be pushed by keybuk...
[03:02] <Keybuk> pitti: we have the new libtasn and gnutls now, yes?
[03:02] <\sh> Kamion: manual dep-wait...or is keybuk not processing the manual dep-waits?
[03:02] <Kamion> new uploads automatically clear dep-waits
[03:02] <tseng> manual dep-waits arent that manual anymore
[03:02] <pitti> Keybuk: libtasn1-3 is already in main, but not yet used; gnutls13 will appear soon then, I assume?
[03:03] <pitti> Keybuk: I'd really like to get this transition behind us soon (I'll care for it), since right now it's a mess
[03:03] <\sh> ok, then the text of buildlog_ubuntu-edgy-i386.libquicktime_1:0.9.7-0.6_MANUALDEPWAIT.txt.gz is wrong ;)
[03:03] <pitti> Keybuk: so if you are fine with the 'let's do it all at once' approach, that'll be my afternoon
[03:03] <Keybuk> pitti: yup, it's processed
[03:03] <pitti> cool, thanks
[03:03] <pitti> Keybuk: in main already?
[03:04] <Keybuk> pitti: I think it just made this publisher run, yes
[03:05] <Keybuk> \sh: what does your upload fix?
[03:05] <\sh> Keybuk: it removes libavcodec-dev from build-deps and let this package build
[03:06] <Keybuk> \sh: ok, so just uploading is fine
[03:06] <\sh> Keybuk: yes, i would, but can't so someone with main powers has to do it :)
[03:07] <Keybuk> \sh: BTW never upload signed dsc or changes files
[03:08] <Keybuk> hmm
[03:08] <\sh> Keybuk: oh yes
[03:08] <Keybuk> why should this not link to libavcodec?  what's the loss of functionality?
[03:08] <Mithrandir> seb128,dholbach: are any of you taking the control-center merge?
[03:08] <\sh> Keybuk: libavcodec-dev is build from ffmpeg which is universe
[03:09] <ogra> Keybuk, kino depends on libqicktime
[03:09] <azeem> is kino using gstreamer these days?
[03:09] <ogra> azeem, not in debian, no
[03:09] <ogra> (i havent looked upstream though)
[03:09] <Keybuk> right ... but what happens to libquicktime if you strip it of a build-dep?
[03:10] <azeem> ok
[03:10] <ogra> seems to still do the job
[03:10] <ogra> pitti, i get a conffile prompt for /etc/dhcp3/dhclient.conf ?
[03:11] <\sh> Keybuk: so I think it removes 
[03:11] <\sh> MPEG,
[03:11] <\sh>  DivX, MPEG4, AC3, DV,
[03:11] <ogra> (i havent touched that file)
[03:11] <\sh> Keybuk: nothing it just builds, because it's just a codec for libquicktime
[03:11] <\sh> Keybuk: so some fileformats are not handled by libquicktime.
[03:11] <Keybuk> \sh: aren't a bunch of those required for quicktime itself/
[03:12] <\sh> Keybuk: not that I know of, in dapper it works as well without ffmpeg
[03:12] <ogra> Keybuk, it worked for two releases (at least i havent seen a bug about it)
[03:13] <Keybuk> right, so it's a new build-dep?
[03:13] <\sh> hmm...I merged it for dapper, too...how strange ;)
[03:13] <\sh> Keybuk: yes
[03:13] <ogra> Keybuk, it always was a build dep in debian, i had to drop it in breezy to get kino to main
[03:13] <pitti> ogra: hm; can you file a bug? (EBUSY)
[03:14] <ogra> pitti, k
[03:15] <Keybuk> ogra: ok, so whoever requested the sync instead of doing the merge properly needs to be spanked
[03:15] <ogra> wasnt me :)
[03:16] <ogra> WOW
[03:17] <ogra> my panel just exploded to 48pt sized icons
[03:17] <\sh> phew, I thought you are playing this evil game ;)
[03:18] <ogra> no, i opened my menu in the middle of a dist-upgrade to edgy
[03:21] <dholbach> Mithrandir: we'll do it, once the new gtk is in the archive and we can do the update with it
[03:21] <Hobbsee> Keybuk: and who was it?
[03:22] <ogra> tseng, 
[03:22] <\sh> Keybuk: thx
[03:22] <ogra> Got a SIGSEGV while executing native code. This usually indicates
[03:22] <ogra> a fatal error in the mono runtime or one of the native libraries
[03:22] <ogra> used by your application.
[03:22] <Mithrandir> dholbach: ok.  I'm playing Adam this week while he's on vacation and doing some of his merges, but I'll leave that to you.
[03:23] <dholbach> Mithrandir: thanks
[03:23] <ogra> tseng, sh: line 1: 31278 Segmentation fault      /usr/bin/mono /usr/lib/mono/1.0/gacutil.exe /i .//usr/lib/cli/dbus-sharp-0.60/dbus-sharp.dll >/dev/null
[03:23] <ogra> tseng, thast on ppc
[03:24] <Keybuk> Mithrandir: I think we all are :)
[03:28] <ogra> Use of uninitialized value in print at /var/lib/defoma/scripts/gs.defoma line 108.
[03:28] <ogra> didnt we get rid of that around release time ? 
[03:28] <hunger> ogra: I always had those...
[03:32] <dholbach> ... and was never seen again
[03:34] <Hobbsee> hehe yeah, i suspect so
[03:34] <Hobbsee> or was hiding in a corner, whimpering
[03:38] <Keybuk> edgy is fine
[03:40] <ogra> urgh
[03:40] <dholbach> Kamion, Keybuk: can one of you get libvte9 (of the vte package) out of NEW and promote it to main, once you have a bit of time?
[03:41] <ogra> BenC, !
[03:41] <Hobbsee> ogra: welcome back!  you did survive?
[03:41] <ogra> not really
[03:41] <Hobbsee> heh
[03:42] <ogra> i have to attach a usb keyboard to my ibook
[03:42] <pitti> Kinnison: ping
[03:42] <ogra> no keyboard support at all anymore
[03:42] <Keybuk> dholbach: are you going to take care of rebuilding everything that depends on it?
[03:42] <dholbach> Keybuk: yeppa
[03:42] <Kinnison> pitti: I'm about to go into a pre-implementation call, anything I can do for you in the short-term?
[03:42] <ogra> gnome is also weird but that was expected ...
[03:43] <pitti> Kinnison: you mean for ddeb support?
[03:43] <pitti> Kinnison: actually I wanted to ask you if I can grab the exim4 merge from you
[03:43] <ogra> that my suspend light on the ibook turned into a disk indicator lamp somehow wasnt
[03:43] <Keybuk> dholbach: accepted
[03:43] <dholbach> Keybuk: rocknroll - thanks a lot
[03:43] <Kinnison> pitti: No, not for ddeb, for ppa
[03:44] <Kinnison> pitti: and I don't have a merge, what do you mean?
[03:44] <pitti> Kinnison: http://merges.ubuntu.com/main.html -> exim4 belongs to you right now
[03:44] <sivang> pitti: what's ddeb ? :)
[03:44] <pitti> Kinnison: but I need to touch exim4 anyway for the gnutls13 transition
[03:44] <pitti> sivang: https://wiki.ubuntu.com/AptElfDebugSymbols
[03:44] <pitti> Kinnison: I don't have a special urgency for ppa
[03:45] <sivang> pitti: ah, righ, cool
[03:46] <Kinnison> pitti: amazing since I don't work on ubuntu
[03:46] <Kinnison> pitti: Noone in distro cares about ppa, but it's mark's highest priority for the soyuz team
[03:46] <ogra> mumble mumble
[03:46] <sivang> Kinnison: it just indicates you're the last person to have touched it :)
[03:46] <Kinnison> sivang: oh righty
[03:47] <pitti> Kinnison: oh, I'd welcome PPA, it's nice for providing testing packages to users and such
[03:47] <pitti> Kinnison: just from my perspective it's less important than security or ddeb support
[03:48] <Kinnison> pitti: If you can find a single distro team member that rates ppa above build-unpublished-source, security-in-soyuz or similar then I'd love to know about them
[03:48] <sivang> Kinnison: right, and it would make it quicker for folks to publish their packages and to use them as basis to get approved for uploading to different section of the archive :)
[03:52] <ogra> dholbach, do you have a reciepe to work around the panel taking 100% CPU in edgy ?
[03:52] <dholbach> ogra: it's the first time i hear of that
[03:53] <dholbach> ogra: any other processes taking a lot of cpu?
[03:53] <ogra> well, now it dropped to 65%
[03:53] <ogra> but stays there
[03:53] <ogra> the app menu doesnt work either
[03:53] <ogra> its a flickering something ...
[03:54] <Mithrandir> doko: do you happen to know if there is a consensus in the debian java community to move towards java-gcj or if that's just us?
[03:54] <ems> hello
[03:54] <ogra> looks like its collapsing/expanding in half second cycles
[03:54] <dholbach> ogra: hum... never heard of anything like it
[03:54] <ems> did anyone notice http://www.ubuntu.com/include/ubuntu-cof-606.png might be offensive to Jews and the like
[03:55] <ogra> well, it also expands to 48px if i use the gartoon icons i blame version inconsistency for now
[03:55] <ogra> i was just hoping you had a reciepe or something
[03:55] <dholbach> ogra: no, heard of it for the first time
[03:55] <ems> it looks much like the Nazi swastika
[03:56] <doko> Mithrandir: there is (we said we did want to use java-gcj-compat), although it's not done very active.
[03:57] <jsgotangco> ems: surely the art director did not think of it
[03:57] <Kamion> ems: it's just as much like the Isle of Man symbol
[03:58] <Kamion> (in neither case does it have the same number of legs)
[03:58] <sivang> ems: I suspect you would be able to say this about every group of people photoed from above holding hands :)
[03:58] <sivang> ems: (like this, and close in number)
[03:58] <jsgotangco> sivang: did you find it offensive?
[03:58] <jsgotangco> surely not :)
[03:58] <ems> but the hand bends...
[03:58] <sivang> jsgotangco: ofcourse not :)
[03:59] <ems> can we make sure it does not happen again?
[03:59] <ems> can it be noted to the director?
[03:59] <Kamion> it is not possible to ensure that nothing will offend anyone
[03:59] <ems> Kamion: obviously.
[03:59] <Kamion> it is not a swastika; the swastika has four legs
[04:00] <sivang> Kamion: they hands are also tilted in angle, no association AFAICS
[04:00] <ems> could it be noted to the director so it doesn't happen next time?
[04:00] <Kamion> so that what doesn't happen next time? an accidental association with some random other symbol?
[04:00] <ems> look lets keep this simple
[04:01] <jsgotangco> right there's hardly anything to argue about it
[04:01] <ogra> surely not :)
[04:01] <Keybuk> ems: the swastika is a holy symbol to some religions
[04:01] <Keybuk> rather than a symbol of evil
[04:01] <zul> like hinduism
[04:01] <zul> its just reverse
[04:02] <ems> Keybuk: I understand that
[04:03] <Keybuk> ems: pretty much any symbol or shape offends some people, and delights others
[04:03] <Kamion> in any case, I'm reasonably sure it's come up in the hearing of art folks
[04:03] <ems> Keybuk: so lets keep this simple. The current photo has got criticism. Just point out the criticism to the director and it should be over.
[04:03] <Kamion> but I doubt it's possible to give any guarantee
[04:03] <Keybuk> there are groups of people who'd be equally offended that the women in that picture aren't covered
[04:04] <Keybuk> not to mention that people are holding hands
[04:04] <Keybuk> etc.
[04:04] <ems> Keybuk: sure. 
[04:04] <ems> Keybuk: and the director I guess knows about that criticism
[04:04] <Keybuk> which director?
[04:04] <ems> as I have no idea who the director is
[04:04] <ogra> we neither :)
[04:04] <ems> could this criticism be passed on to him
[04:04] <Kamion> the ubuntu-art mailing list would be more appropriate
[04:05] <ogra> yeah
[04:05] <Keybuk> ems: we don't have "a director"
 ems: surely the art director did not think of it
[04:05] <jsgotangco> ems: its contracted outside
[04:05] <Kamion> in any case as I say I'm pretty sure it has already been brought up
[04:05] <Kamion> but of course everyone who thinks of it wants their objection individually logged
[04:05] <ems> Kamion: if it has then okay...
[04:05] <ems> Kamion: I actually never notice it.
[04:06] <Kamion> you just did, vocally :-)
[04:06] <ems> Kamion: a German pointed it to a friend who pointed ... who told me about it
[04:06] <Kamion> was that somebody who was offended by it themselves?
[04:07] <ems> Kamion: I clearly above said it has the possiblity of offended Jews. I have no idea if it will actually ever offend a Jew.
[04:07] <Kamion> given that the Hebrew speaker I know of on this channel doesn't seem bothered, I don't think we should be overly worried
[04:07] <ems> Kamion: and that is why I said lets keep this simple. 
[04:07] <Kamion> it's sometimes much easier to get righteously angry on behalf of imaginary people
[04:08] <ogra> ems, as you heard before it doesnt at least offend the jews in this channel
[04:08] <ems> ogra: of couse but that doesn't mean it couldn't offend...
[04:08] <fabbione> Keybuk: pong
[04:08] <jsgotangco> were going in circles
[04:08] <ems> anyway we have talked enough over this issue
[04:09] <Keybuk> fabbione: kernel FTBS on sparc, I assume you're aware?
[04:09] <Kamion> come back when somebody's actually offended, and then it will be possible to discuss it with them
[04:09] <sivang> I'll repeat - I don't find it offensive neither I could see any association talked about.
[04:09] <fabbione> Keybuk: 17-4 ?
[04:09] <ems> just pass it on to someone who might care if (s)he exists...
[04:09] <Keybuk> Hobbsee: oddly enough, someone did complain about that
[04:09] <Keybuk> fabbione: yeah
[04:09] <jsgotangco> Hobbsee: im not offended at all though
[04:09] <Hobbsee> that could cause offence, thinking that ubuntu isnt designed for people who live in the area, etc
[04:09] <fabbione> Keybuk: no i didn't know, but i think BenC will notice.
[04:09] <ems> see you later
[04:09] <Hobbsee> jsgotangco: so i thought
[04:09] <Hobbsee> Keybuk: darn!  :P
[04:10] <Hobbsee> Keybuk: i was hoping for something that had never been, and never would be, thought up :P
[04:10] <fabbione> Keybuk: i am not watching the kernel as close as i used to
[04:10] <fabbione> Keybuk: but thanks for the info
[04:11] <robertj> Keybuk: I appreciate your response to my avahi policy-change spec
[04:12] <Keybuk> robertj: was chatting to Lathiat a lot about it yesterday
[04:12] <robertj> Keybuk: I feel like it's a good but not perfect solution
[04:13] <Keybuk> which?
[04:13] <robertj> Security audit + policy change
[04:13] <Keybuk> It'd have to be a hell of a security audit, I'm afraid
[04:13] <Keybuk> every single line carefully considered, and the implications of every branch taken and expanded
[04:13] <robertj> Which is a step above firewall which I consider "workable but long-term security problem"
[04:14] <Keybuk> I still think that just having avahi-daemon switchable on/off at user request is adequate
[04:16] <robertj> Keybuk: It couldn't hurt, System->Administration->Services seems like the best place for it although its a but unfriendly these days to new users
[04:17] <robertj> err it's a bit unfriendly
[04:17] <Keybuk> robertj: I think the notification area is the right place for it
[04:17] <Keybuk> as a clickable icon
[04:17] <dholbach> robertj: i hope gnome-system-tools >= 2.15 will be a bit nicer
[04:17] <robertj> Keybuk: In it's present form I believe almost nothing should go on the notification tray
[04:18] <seb128> robertj: what is unfriendly about it ?
[04:18] <Keybuk> robertj: why?
[04:19] <robertj> Keybuk: almost no user would every want to turn it off
[04:19] <lifeless> Keybuk: you have mail I hope
[04:20] <Keybuk> robertj: it'd be off by default
[04:20] <elmo> robertj: you know how bluetooth in mobiles defaults to off?  ever wonder why?
[04:20] <Keybuk> robertj: I would expect most people to turn it on
[04:20] <Keybuk> but then that's their funeral
[04:20] <Keybuk> I like the idea of the notification area being like the little icons on a mobile phone
[04:20] <Keybuk> it's an interface most people will be familar with
[04:20] <Keybuk> it's already like that really -- battery power, network signal, "you have (voice)mail", etc.
[04:21] <Keybuk> don't see why "laptop is discoverable via avahi/bluetooth/etc." shouldn't be in that list
[04:21] <robertj> seb128: overly-large icons, "real" service names, names & descriptions that are too mcuh alike, etc...
[04:22] <robertj> seb128: even so, I'd prefer it be there. I'll also assume that default installs don't have 2 mail agents, 3 action schedulers, and 2 loggers
[04:22] <robertj> seb128: but not horrible by any means, and it sure beats nothing
[04:22] <seb128> robertj: what is wrong about using the service name?
[04:23] <seb128> robertj: upstream is not planning any change afaik because he's not aware of any issue, if you have some real complain suggestions are welcome
[04:23] <robertj> seb128: bug about it?
[04:23] <seb128> robertj: saying that it's unfriendly is not of real use
[04:23] <seb128> robertj: by example
[04:24] <robertj> seb128: can I get back with you in a few minutes after I get out of avahi-mode?
[04:24] <robertj> I _promise_ I won't drop the ball & will file a bug report
[04:25] <seb128> sure, no hurry
[04:26] <jdub> ahr
[04:26] <seb128> hey jdub
[04:26] <robertj> Keybuk: I think there are some battery concerns that bump bluetooth up the list, wifi has a level of security exposure that is more severe than avahi advertising so I think there are reasons it should be more prominant
[04:27] <Keybuk> robertj: bluetooth certainly has security concerns!
[04:27] <robertj> Keybuk: I know it does
[04:27] <seb128> jdub: GTK 2.10 is the suck, static build is b0rked and nobody has an idea (or people who could have an idea seems to not bother about it enough to track it)
[04:27] <Keybuk> how do you figure hiding an option in a dialog is more prominent than an icon on the desktop?
[04:27] <jdub> seb128: static matters for us?
[04:28] <mvo> seb128: wasn't static building b0rked with earlier versions too anyway?
[04:28] <robertj> It's not, it's less. I think Wifi is a-ok for an always-on-screen element, as well as bluetooth
[04:28] <seb128> jdub: it matters for Debian apparently and I didn't want to divert from them, but I'm that near || of dropping it
[04:28] <seb128> mvo: no, at least it has already been b0rked but fixed too
[04:28] <Keybuk> robertj: make it a single element
[04:29] <jdub> seb128: weird - the gtk+ dudes are not being responsive?
[04:29] <robertj> Keybuk: no matter what you have to decide either on or off by default
[04:29] <jdub> seb128: got some build log output?
[04:29] <mvo> seb128: hm, last time I tried that (1-2y ago) it claimed to be doable, but in reality it wasn't (because of dynamically loaded stuff like pango-modules and all this stuff)
[04:29] <seb128> jdub: mclasen and owen have no idea "offhand" and neither of them showed interest to look at it
[04:30] <seb128> jdub: http://bugzilla.gnome.org/show_bug.cgi?id=346531
[04:30] <Ubugtu> Gnome bug 346531 in gtk "GTK 2.10 static build is broken (required to package it for Debian and Ubuntu)" [Major,Unconfirmed]  
[04:30] <robertj> Keybuk: I guess you could ask when a network connection was created
[04:30] <seb128> mvo: GTK has a static build target since before I started working on GNOME for Debian
[04:31] <robertj> Keybuk: Most users will want guidance on what to select and not remember the dialog 2 days for then and be confused when their auto-detect doesn't work.
[04:31] <seb128> mvo: 
[04:31] <seb128> gtk+2.0 (2.2.0-1) unstable; urgency=low
[04:31] <seb128>   * debian/rules:
[04:31] <seb128>     modified to build the static libraries. (closes: Bug#161938)
[04:31] <seb128>  -- Akira TAGOH <tagoh@debian.org>  Mon,  6 Jan 2003 18:34:31 +0900
[04:31] <robertj> Keybuk: but if we say This is a good idea for 99.9% of users then we will just be bothering people.
[04:32] <mvo> seb128: right, what I say is that also it is available I was not able to build a static linked gtk app that had no external dependencies (e.g. on pango-modules). this may be me of course
[04:32] <seb128> mvo: ah right
[04:32] <robertj> If you are the kind of person who disables access to your USB ports then you can disable it, and if your not _and_ a vulnerability is discovered _and_ someone is on your subnet to exploit it _and_ your not doing your updates then you are screwed
[04:33] <seb128> mvo: <Np237> I've already raised the question on -devel, and people do use static libraries *especially* for gtk
[04:33] <seb128> mvo: I've not really tried myself
[04:35] <robertj> Keybuk: but right now we are holding back major functionality because of a purely theoretical problem which we have lots of evidence to suggest is a non-issue and no verifiable way to ever know for sure the software is safe. 
[04:36] <Keybuk> robertj: *choke*
[04:36] <Keybuk> security is not a "non-issue"
[04:36] <Keybuk> the No Open Ports policy is there for a reason
[04:37] <robertj> Keybuk: I didn't say it was a non-inssue
[04:37] <Kamion> robertj: thing is, the burden of proof is on the proposer of opening up ports, not the other way round
[04:37] <robertj> Kamion: we shouldn't open up dhcp because there is no way to prove there isn't an exploit left
[04:38] <Kamion> robertj: there are ways to demonstrate that vulnerabilities are contained
[04:38] <Kamion> if that cannot be demonstrated for a piece of software, then it shouldn't be allowed to listen by default
[04:38] <robertj> Kamion: what proof has been done on dhcp client then?
[04:38] <Kamion> also, dhcp is a very long-established piece of software; we have a security history for it
[04:38] <Keybuk> dhclient has been around for a very long time, and has had a large number of security audits done on it
[04:39] <Keybuk> likewise the libc resolver
[04:39] <Keybuk> avahi has been around for a very short time, and to my (and Google's) knowledge, never had a formal security audit
[04:39] <Kamion> we've also taken steps to ensure that the client runs as non-root
[04:39] <robertj> Mandrake had DHCP exploits in 2002
[04:40] <robertj> So vintage is no gauruntee unfortunately
[04:40] <Keybuk> robertj: a history of exploits is not necessarily negative
[04:40] <Kamion> it's a rare piece of network software that never has an exploit, but if 2002 is the best you can do, then that's not so bad
[04:40] <Keybuk> I actually feel more comfortable about code that's had bugs and exploits shaken out of it
[04:40] <Keybuk> (and yes, I know avahi has had very recent exploits :p)
[04:40] <robertj> Kamion: I do to but technically I don't know they are "out" though
[04:41] <Keybuk> anyway, this talk about DHCP is not much relevant; that has been granted a policy exception
[04:41] <robertj> In the end the only way to know is to put it out there and let it sit a decade
[04:42] <Kamion> well, no, having people who care turn it on is a good way to start finding out
[04:42] <Keybuk> avahi is an interesting case, because while it is non-root and chroot'd, it still communicates with things outside of that jail -- dhclient doesn't
[04:42] <Kamion> it's not mass deployment that tells you about exploits, it's *just enough* deployment that people start auiting it
[04:42] <Keybuk> so it's a little more concerning
[04:42] <Kamion> auditing
[04:42] <Keybuk> we should certainly ship avahi in an "off by default" state
[04:43] <Kamion> deploying avahi on my mum's computer won't tell you a thing about exploits :)
[04:43] <Keybuk> then, later, we can decide whether enough users have turned it on and shaken the bugs out
[04:43] <robertj> Keybuk: what makes you think people turning it on will spur an audit
[04:43] <Keybuk> robertj: such things often do
[04:44] <Keybuk> the right people using it makes other people look at it, etc.
[04:44] <robertj> Keybuk: I don't think that's a very realistic expectation
[04:44] <robertj> You have a 1:1000 chance that someone will get a group together & do a full code audit & do a good job
[04:45] <robertj> You have the black-hats who won't look at it until there is an install base large enough for pandemic spreading to occur because it's in their best interest not to
[04:46] <pitti> how come that all our buildds are idle when there are a thousand packages waiting to be built?
[04:46] <Zdra> the problem I see is if we don't activate it by default users won't know about that feature ! What is great is tu turn on an ubuntu computer and say "oh my god I can see shared folders from my other ubuntu machine !"... I don't understand how we can tell it "zeroconf" if the user has tu enable it...
[04:46] <robertj> And you have the white-hats who for the most part have more fun things to do than do a code audit & a whole slew of ways around the issue including turning a blind eye, firewalling traffic, disabling multicast & setting up machines by hand, etc
[04:47] <neuralis> robertj: there are multiple ways to approach the problem. very carefully looking at avahi's security implications, and documenting how each can be best addressed in the code first (e.g. sshd's privilege separation, etc) would be an excellent start.
[04:47] <neuralis> robertj: i haven't read your spec yet, it's in my queue for later today.
[04:47] <robertj> There is no use case in which a code audit takes less effort/money than disabling multicast or securing your network in general
[04:49] <robertj> Keybuk: do you see these as factors that make it unlikely for anyone to do the kind of needed audit themselves?
[04:49] <Keybuk> robertj: tbh, I don't care :P
[04:49] <Keybuk> until such an audit has happened, I don't see that avahi has proved itself worthy of an open port
[04:49] <Keybuk> I really don't see a problem shipping it off by default forever
[04:49] <neuralis> keybuk: +1.
[04:50] <Keybuk> my phone came with bluetooth and irda off by default
[04:50] <robertj> neuralis: next question, do you think its important enough that it's worth begging Mark for $$$ to pay someone to do?
[04:50] <Keybuk> this, to me, is not a problem
[04:50] <robertj> err Keybuk, sorry
[04:50] <Keybuk> nope, I don't
[04:50] <mjg59> Keybuk: Bluetooth comes switched off by default because of battery life concerns more than security
[04:50] <Keybuk> I don't think it's important at all
[04:51] <Keybuk> I seriously don't think anybody will care that it's off by default
[04:51] <robertj> I think a lot of the least-vocal users will
[04:51] <Keybuk> mjg59: right, the reason they're off doesn't matter
[04:51] <Keybuk> if those users are missing the obvious "turn this on forever" button, then those users are idiots
[04:52] <pitti> G0SUB: ping
[04:52] <Keybuk> and not worth caring about
[04:52] <neuralis> robertj: quite honestly, an easy, approachable way to turn it on from the networkmanager menu would more or less completely satisfy me, at least to begin with.
[04:52] <Zdra> Keybuk: I think nobody will care because nobody will know that ubuntu can discover services automatically...
[04:53] <neuralis> robertj: almost certainly you won't get more into edgy; edgy+1 is debatable again, contingent on audits, etc being done.
[04:53] <Keybuk> I'd like a generic "service discovery" gubbins to turn on/off things like avahi, cups browsing, bluetooth, irda, etc.
[04:53] <Keybuk> if it's easy to find and use, people will discover very quickly
[04:53] <mjg59> Bluetooth has a strong distinction between discovery and listening
[04:53] <tseng> the service manager is pretty easy to use in gnome-system-tools
[04:53] <neuralis> Keybuk: what's the latest story with networkmanager? i didn't pay too much attention in paris. are we planning to actually install it by default?
[04:53] <Keybuk> mjg59: aye, I think the pattern works well for avahi too
[04:54] <Keybuk> neuralis: we are not
[04:54] <mjg59> Keybuk: Not really
[04:54] <mjg59> Bluetooth discovery is a per-connection thing - you don't opportunistically look for Bluetooth devices
[04:54] <Keybuk> mjg59: sorry, I mean the pattern works well for dns-sd
[04:54] <mjg59> No
[04:54] <Keybuk> avahi allegedly doesn't implement them separately
[04:54] <robertj> With bluetooth the likelyhood that an attacker is in a 30" proximity is somewhat less than someone being on your dorm-floor with an infected computator
[04:54] <mjg59> The protocol doesn't really allow them to be implemented separately
[04:55] <Keybuk> why not?  doing dns service discovery is distinct from announcing your own services
[04:55] <mjg59> No, because you don't do dns-sd just when you're specifically looking for something - you opportunistically pick up announcements as well
[04:55] <mjg59> Bluetooth has a protocol-level timeout for service discovery
[04:55] <mjg59> Which dns-sd doesn't seem to
[04:56] <neuralis> robertj: i'll take a 15-minute look at the avahi source today, to get a super-general feel for the security.
[04:56] <mjg59> If it did, there'd be much less of a problem
[04:56] <pitti> neuralis: I did that a while ago, btw, and also talked with upstream
[04:56] <jdub> Keybuk: multicast dns-sd != unicast dns-sd
[04:56] <pitti> I pointed him to an integer overflow or two, which he promptly fixed
[04:56] <neuralis> pitti: what did you think about the rest?
[04:56] <pitti> in general, the code look quite well
[04:57] <robertj> neuralis: thanks, please grafitti the spec page when done ;)
[04:57] <pitti> it's carefully written to not cause overflows etc., but I do not vouch for the higher-level threats
[04:57] <pitti> like, stealing files from other people, that sort
[04:57] <pitti> I didn't audit the protocol at all
[04:57] <neuralis> pitti: were you satisfied with the privilege separation that they do, and such?
[04:58] <pitti> I just checked for the usual suspects (malloc, arrays, etc.)
[04:58] <mjg59> pitti: That's presumably more a function of the applications using it rather than avahi itself?
[04:58] <neuralis> pitti: well, the protocol isn't avahi's, it's standardized, right? so it's a layer7 matter.
[04:58] <pitti> mjg59: well, the daemon opens a port, thus potentially you can abuse it to read anything avahid can
[04:58] <pitti> as I said, I just looked at the code to get a feeling for the cautiousness
[04:59] <pitti> I have never used avahi nor checked the network application layer
[04:59] <pitti> neuralis: privsep> that looked quite well, running as non-root in a chroot, IIRC
[05:00] <robertj> pitti: http://avahi.org/wiki/SecurityConsiderations <- that was written for Ubuntu & then posted up genearlly
[05:00] <pitti> https://wiki.ubuntu.com/MainInclusionReportAvahi has that list, too
[05:00] <neuralis> pitti: okay, i'll take a brief look at some of the higher-level things that you didn't look at originally
[05:01] <neuralis> pitti: if it's a non-root process in a chroot, and the outside helper is sufficiently paranoid, that's a rather secure combination; i could be convinced not to oppose the policy amendment on security grounds
[05:04] <pitti> neuralis: agreed
[05:04] <neuralis> pitti: cool. i'll report findings to -devel later today.
[05:04] <neuralis> robertj: --^
[05:07] <pitti> neuralis: the thing that frightens me most about enabling it by default is that it might allow outsiders to see data and files which the user never intended to share
[05:07] <pitti> neuralis: maybe that's just my wrong understanding of how avahi works, I didn't yet find the time to deal with it
[05:08] <epx> dns-sd can't share files, AFAIK
[05:09] <Amaranth> pitti: you have to explicitly turn on sharing in the individual applications
[05:09] <Amaranth> pitti: like music sharing in rhythmbox, you have to go into the preferences and turn it on
[05:10] <epx> dns-sd just 'shares' smal TXT records about services, it is way less powerful than upnp to expose things
[05:10] <Amaranth> all they should get by default from your computer is the fact that there is a computer there and the name of the computer
[05:10] <shackan> dns-sd is just a protocol to publish services, sharing files could be a concern IFF the user installs a service to share files which advises its existence on the network via avahi
[05:11] <neuralis> pitti: yeah, that's what i plan to look at.
[05:12] <neuralis> pitti: i think we should be in the clear about it, based on what i remember reading of the apple docs on this a long time ago, but i'll look at it again.
[05:12] <shackan> avahi by default doesn't do much more than listen what services other people made available on the network
[05:13] <robertj> pitti: as an applied use case - if you have Avahi instalelled by default you will see other Music Shares in Rhythmbox but must enable Music Sharing in Rhythmbox
[05:14] <robertj> pitti: it's purely an advertising endeavour. The idea is that it tells the world that you are sharing as a side-effect of the actual sharing itself which is handled elsewhere
[05:15] <pitti> robertj: I see; thanks for the heads-up
[05:17] <robertj> pitti: this does lead to issues that end-users consider "security problems." For instance graduate students are able to locate the IP printer in the faculty closet & print to it. 
[05:17] <neuralis> robertj: that's not a security problem, that's tuition reimbursement :)
[05:18] <robertj> think of it as a scholarship for people with an emphasis in computers
[05:18] <Amaranth> robertj: how could avahi let them find that printer?
[05:18] <Amaranth> robertj: unless that printer advertises itself
[05:18] <robertj> Amaranth: it does
[05:18] <robertj> New HPs advertise that way
[05:19] <Amaranth> robertj: that's a SEP :P
[05:19] <robertj> SEP?
[05:19] <Amaranth> Somebody Else's Problem
[05:19] <robertj> Oh, of course. Just be on the look-out for that.
[05:20] <neuralis> ok, i'm about to go grab some food.
[05:21] <neuralis> robertj: you're getting your audit, now take it easy and let -devel and #-devel think about other things than avahi for a bit.
[05:24] <robertj> planned on it :)
[05:25] <robertj> i'm already looking at seb128's request for a bug at services applet
[05:31] <pitti> Keybuk: do you know what's wrong with our buildds?
[05:31] <pitti> (why they went on strike)
[05:32] <Keybuk> pitti: I don't
[05:32] <Keybuk> are they still on strike?
[05:33] <Keybuk> hmm
[05:33] <Keybuk> the only things Pending Build are security and backports
[05:34] <dholbach> Gloubiboulga: you will need to rebuild xfce4-terminal against the new libvte-dev
[05:35] <pitti> Keybuk: there should be a thousand things waiting to be built
[05:35] <Keybuk> pitti: there aren't
[05:35] <Keybuk> there's 1,350 things in dep-wait
[05:36] <pitti> Keybuk: ah, ok :)
[05:36] <Keybuk> Missing Dependencies python-setuptools
[05:36] <pitti> Keybuk: many of them waiting for python-support or so?
[05:36] <Kamion> bet they just need new processing
[05:36] <pitti> yep, gnutls13 binaries are missing as well, but probably for the same reason
[05:37] <Kamion> hmm
[05:37] <Kamion> oh, python-setuptools needs to be promoted to main I suppose?
[05:37] <Kamion> pitti: your call
[05:38] <Kamion> WBNI python-support built
[05:39] <Kamion> Keybuk: python-support is in "no builds recorded" and all the buildds are idle - that can't be right
[05:39] <pitti> same for gnutls
[05:39] <pitti> or pkg-create-dbgsym
[05:40] <ompaul> http://www.dvocha.org/index.php/Main_Page
[05:40] <ompaul> woops
[05:40] <ompaul> wrong place
[05:40] <Keybuk> Kamion: yeah, that one's odd
[05:41] <pitti> Kamion: the only reverse dependency of python-setuptools is celementtree, so that is hardly the reason for The Big Lock
[05:41] <Keybuk> pitti: no builds have even been attempted yet
[05:41] <Keybuk> so it won't yet know it's in dep-wait
[05:41] <pitti> Kamion: nevertheless, p-setuptools is fine for main for me
[05:49] <robertj> seb128: Shares admin does come from gst right?
[05:49] <robertj> err not Shares, Services setting
[05:49] <seb128> yep
[05:49] <robertj> It's not listed as a component on bugzilla
[05:50] <robertj> after thinking about it more, I recommending that there be a list of "essential system services" (basically everything installed by default) that are hidden unless users check a "View system services" checkbox
[05:53] <robertj> seb128: sound reasonable? The idea would be to get it very bare-looking so that at some point we could say "lets add more informatin about the selected service, links to logs, a configure button, etc."
[05:54] <seb128> robertj: gnome-system-tools, runlevel-admin
[05:54] <seb128> robertj: on bugzilla.gnome
[05:54] <robertj> ahh
[05:55] <robertj> gnome bug 346560
[05:55] <Ubugtu> Gnome bug 346560 in runlevel-admin "visual cleanup for Services dialog" [Enhancement,Unconfirmed]  http://bugzilla.gnome.org/show_bug.cgi?id=346560
[05:55] <seb128> robertj: we discussed that, upstream opinion is that it should only list services that are installed and you might be likely to change (ie: not dbus by example)
[05:55] <robertj> yeah, even though system logging _could_ be disabled...for most people it's not a use-case
[05:56] <seb128> robertj: thank you, I've subscribed to the bug, let's see what he says about it
[05:56] <robertj> oh yeah, and the dialog needs to be wider if we can swing it;)
[05:56] <robertj> (pork-barrel bug-filing)
[05:58] <mdz> doko: will you take care of the bash and zlib merges?
[05:58] <robertj> seb128: I will volunteer that OS X has a Services admin utility that succeeds in being profoundly useless
[05:58] <pitti> mdz: good morning
[05:59] <mdz> pitti: I am not here
[05:59] <pitti> oh, I hate it when I talk to illusions :)
[06:01] <ogra> pitti, stop licking on frogs then :)
[06:01] <ogra> that helps a lot :)
[06:01] <pitti> *wuerg*
[06:01] <ogra> heh
[06:02] <robertj> seb128: and OS X server has a seperate one for Net-facing services where you can actually do some managing that is ugly (although it doesn't need to be) but functional
[06:02] <pitti> Keybuk: did you recently get reports about wrong device permissions? /dev/usblp0 is now always in group root in edgy
[06:03] <Keybuk> pitti: yeah, known bug (typo in rules file)
[06:03] <pitti> ok, great; thanks
[06:03] <Keybuk> KERNEL="lp" needs to be KERNEL=="lp"
[06:03] <doko> mdz: after the half final :-)
[06:03] <mdz> doko: half final?
[06:03] <pitti> mdz: soccer today :) Germany - Italy
[06:03] <doko> semi final? anyway, Italy <->Germany
[06:03] <pitti> semifinal, or so
[06:03] <mdz> oh
[06:04] <Keybuk> woo!  now the only things in new-source output are things that look like they've been in Ubuntu in the past
[06:04] <Keybuk> elmo: don't suppose we have the historic katie removals.txt around anywhere?
[06:04] <elmo> Keybuk: sure it's on jackass?
[06:04] <Keybuk> elmo: I have no account on jackass
[06:05] <pitti> Keybuk: I have
[06:05] <elmo> it's in drescher:~james/ now too
[06:05] <Keybuk> elmo: should I have one?
[06:07] <elmo> Keybuk: no
[06:07] <elmo> jackass is only used for security
[06:08] <elmo> which AFAIK is just pitti and infinity
[06:08] <Keybuk> *nods*
[06:08] <Keybuk> what does "ROM" mean in removals.txt, btw?
[06:09] <elmo> Request Of Maintainer
[06:09] <elmo> there should be a legend at the top
[06:09] <Keybuk> ah
[06:09] <elmo> or if not, there will be at the top of http://ftp-master.debian.org/removals.txt
[06:09] <Keybuk> we seem to just use NBS now :)
[06:12] <msw> Keybuk: the == thing has bitten me more than once...
[07:15] <hunger> Any kernel people around? I get oopses with the 2.6.17 series in edgy.
[07:16] <hunger> The OOps is attached to #51384.
[07:38] <jsgotangco> goodnight
[07:43] <highvoltage> goodnight jsgotangco 
[08:11] <pygi> jdub, around this time ? :)
[08:23] <slomo> Keybuk: hi, please move libvisual to main. the main inclusion report was approved by pitti yesterday
[09:25] <bddebian> Heya
[09:26] <simosx> hi there
[09:26] <bddebian> Hi simosx
[09:37] <iriefrank> I'm trying to create a patch that changes a default gconf setting for epiphany-extensions, where can I find a schema file or equivalent?
[09:37] <iriefrank> how are gconf settings set when installing a .deb?  I'm sorry, this is my first patch
[09:39] <sladen> iriefrank: calls in  postinst  to  gconftool-2
[09:41] <iriefrank> so is there somewhere in CVS where there is a file with default gconf values?
[09:41] <iriefrank> thanks sladen
[09:43] <sladen> iriefrank: have a lookin   /var/lib/dpkg/info/epiphany.postinst
[09:46] <iriefrank> i see calls to schemas in the epiphany-browser.postinst but there is no postinst file for epiphany-exensions
[09:50] <iriefrank> sladen: what about  /epiphany-extensions/include/ephy-prefs.h
[09:50] <iriefrank> that seems to contain gconf settings
[09:52] <sladen> iriefrank: you can neither add a postinst file, or workout what it's actually doing in ephy-prefs.h and see if it makes sense to add your extensions there
[09:53] <sladen> iriefrank: iwj may know how to add your gconf-overrides WRT to firefox
[09:53] <Kamion> s/neither/either/ surely
[09:55] <iriefrank> sladen: thanks
[09:59] <sladen> Kamion: affirmative
[10:01] <BenM> are any of you who might know stuff  about glibc packaging here?
[10:02] <simira> BenM: Mithrandir might know a thing or two
[10:03] <BenM> ok,so i'm looking at /usr/lib/gconv/gconv-modules.cache
[10:03] <BenM> it seems this is a cache for /usr/lib/gconv/gconv-modules
[10:03] <BenM> there are 60kb some of allocations caused by reading the gconv-modules
[10:03] <BenM> which seems to be potentially avoided by the .cache file, which ubuntu doesn't have
[10:04] <BenM> somebody on fc5 reports having that file
[10:07] <Kamion> running iconvconfig should create it I think
[10:08] <BenM> yea
[10:09] <BenM> so, that saves 70kb of mallocs
[10:09] <BenM> for most gnome programs
[10:10] <Kamion> should be possible to run it in the postinst
[10:10] <BenM> want me to file a bug
[10:10] <Kamion> and make sure it gets removed in the prerm or so
[10:11] <Kamion> I'm not a glibc maintainer, but it sounds like a good idea to me FWIW; yes, filing a bug would be sensible
[10:11] <Kamion> jbailey wrote the iconvconfig man page so he should know about it
[10:14] <Kamion> BenM: yeah, I can see the difference in an strace
[10:14] <BenM> in valgrind it's even more obvious :-)
[10:14] <Kamion> http://people.ubuntu.com/~cjwatson/tmp/man-iconvconfig.diff
[10:15] <Kamion> any idea of the memory saving across the whole desktop?
[10:15] <BenM> well, every program that uses gnome_program_init seems to make use of it
[10:16] <BenM> a really easy test would be to reboot and see how many procs mmapd that file
[10:17] <BenM> one issue, the stack trace is:
[10:17] <BenM> ==14654==    by 0x429146A: gnome_program_parse_args (in /usr/lib/libgnome-2.so.0.1401.0)
[10:17] <BenM> ==14654==    by 0x4291BC7: (within /usr/lib/libgnome-2.so.0.1401.0)
[10:17] <BenM> ==14654==    by 0x4291ED8: gnome_program_init (in /usr/lib/libgnome-2.so.0.1401.0)
[10:17] <BenM> it's possible that popt using programs avoid this
[10:18] <BenM>               1272 kb private dirty
[10:18] <BenM>               1188 kb private dirty
[10:18] <BenM> that's a before/after for me
[10:18] <Kamion> one process?
[10:18] <BenM> ya
[10:19] <BenM> multiply that by 10? 20?
[10:20] <Kamion> $ sudo grep -l gconv /proc/*/maps | wc -l
[10:20] <Kamion> 21
[10:20] <Kamion> might be a reasonable approximation
[10:20] <Kamion> (pre-reboot)
[10:22] <bddebian> Hmm, are we going to have xutils-dev in Edgy?
[10:22] <BenM> i could just kill X
[10:22] <BenM> that'd get most of the data
[10:22] <BenM> hold on
[10:23] <Kamion> bddebian: xutils-dev |  1:1.0.2-3 |      unstable | source, alpha, amd64, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
[10:23] <Kamion> bddebian: so I'd guess so
[10:24] <bddebian> Hmm.  Should I wait on cernlib merge then?  It was build-depping xutils-dev which apparently wasn't in dapper?
[10:25] <BenM> [bmaurer@omega ~] $ grep gconv-modules.cache /proc/*/maps -l | wc -l
[10:25] <BenM> 23
[10:25] <crimsun> you can either merge it by hand by adding the necessary b-ds, which should be imake
[10:25] <crimsun> or you can wait
[10:25] <bddebian> What is preferred?
[10:26] <crimsun> I take the "clear the merge list ASAP" approach
[10:26] <bddebian> And why wasn't xutils-dev synced/merged already?
[10:26] <Kamion> bddebian: I'd wait
[10:26] <Kamion> because otherwise we just introduce diffs unnecessarily
[10:27] <Kamion> bddebian: because our new X maintainer is just getting up to speed
[10:27] <bddebian> Kamion: So should I file a sync request bug on LP and put "After xutils-dev makes it in"?  Or just do nothing?
[10:27] <Keybuk> Kamion: btw, I've put the sync-blacklist file into bzr
[10:27] <Keybuk> and tidied it up rather a lot
[10:28] <Keybuk> bddebian: do nothing
[10:28] <Kamion> bddebian: if it can be synced now, it can just dep-wait
[10:28] <Kamion> so a sync request would be fine IM
[10:28] <Kamion> O
[10:28] <Kamion> Keybuk: thanks
[10:29] <Kamion> bddebian: syncs are harmless if they won't build yet :-) but if you want to test it before requesting the sync, then wait
[10:29] <BenM> man, this looks nice, about 1.5 MB on startup
[10:29] <BenM> probably a bit more once apps are launched
[10:29] <Kamion> assuming that's the only necessary diff from Debian
[10:29] <Kamion> BenM: nice!
[10:29] <bddebian> Kamion: Well I usually like to make sure something "works" before I request a sync.  I get in enough trouble as it is :-)
[10:29] <Kamion> might be worth trying in a non-English locale, just to make sure it still works ...
[10:30] <Keybuk> Kamion: sync won't work :)  xutils is blacklisted
[10:31] <Kamion> Keybuk: sync of cernlib not xutils
[10:31] <Keybuk> Kamion: oh, sorry, duh :p
[10:31] <bddebian> Keybuk: Why is X blacklisted?
[10:31] <bddebian> Err xutils
[10:31] <Keybuk> bddebian: because it's going to come in together
[10:31] <bddebian> Ah
[10:31] <Kamion> bddebian: because we know it all needs manual love and attention
[10:31] <Kamion> and careful ordering
[10:32] <bddebian> Goddamn I hate being useless
[10:33] <rodarvus> bddebian, debian xutils is quite different from ours (for now)
[10:34] <bddebian> rodarvus: Aye, I know
[10:34] <Keybuk> that's why it's blacklisted, to prevent us picking it by accident via a sync
[10:34] <bddebian> OK
[10:39] <bddebian> Hello pygi
[10:39] <pygi> hey bddebian :)
[10:43] <BenM> open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
[10:43] <BenM> open("/usr/share/locale/locale.alias", O_RDONLY) = 3
[10:43] <BenM> that looks fishy
[10:52] <jdub> BenC: ping
[11:08] <Mithrandir> lifeless: you played a bunch around with opensync, didn't you?
[11:08] <lifeless> yes, I package libopensync
[11:09] <Mithrandir> lifeless: doesn't seem to be in dapper?  Will be in edgy?
[11:09] <lifeless> no, not in dapper, no way was it suitable
[11:09] <lifeless> upstream are being slow doing next release
[11:10] <Mithrandir> ok, do you have the packages somewhere?  I'd love to play with it now that I got a phone which should be able to sync over *
[11:10] <lifeless> Mithrandir: its in edgy
[11:10] <lifeless> just pull the package ;)
[11:10] <Mithrandir> oh, cool.
[11:10] <Mithrandir> I'll take a look at that, then.
[11:13] <jdub> known b0rkage with atheros in edgy's 2.6.17?
[11:14] <sivang> Keybuk: Will you take a look at +spec/make-free-space-wizard and let me know what it's missing to be approved? (I just read the TB meeting backlog)
[11:15] <sivang> iwj: thanks for your fixes and approval for home-user-backup
[11:17] <bluefoxicy> Keybuk:  you got a little time?
[11:18] <bddebian> Is CLK_TCK from time.h deprecated?
[11:20] <jdub> hrm, ok, there's some funny module ordering problems with atheros
[11:20] <Keybuk> bluefoxicy: not right now
[11:20] <Keybuk> sivang: not right now
[11:20] <pygi> jdub, you here finally? :P
[11:20] <jdub> pygi: hi
[11:20] <bluefoxicy> Keybuk:  hrm, I'll try later then.
[11:20] <pygi> jdub, hi hi, you have a sec?
[11:20] <jdub> pygi: very early morning here, been jetlagged after guadec - expect the unexpected.
[11:20] <jdub> sure
[11:22] <pygi> jdub, oki, pm/ed you
[11:22] <jdub> pygi: quick - gotta have breakfast
[11:23] <pygi> jdub, just you go eat, its not urgent
[11:23] <jdub> pygi: if it's private, mail it, if it's not, here is fine
[11:23] <pygi> not private...
[11:23] <pygi> was just wondering where is that conference in asutralia, to see if I could try to attend
[11:23] <jdub> sydney
[11:23] <pygi> eh, not where*
[11:23] <pygi> sorry, when*
[11:24] <jdub> jan 15-20, 2007 - as stated on the website...
[11:24] <pygi> uh, havent seen that :) Thanks :)
[11:24] <pygi> uh, havent read the dates :P
[11:24] <pygi> thanks :)
[11:26] <sivang> Keybuk: okay, let me know when you can or I should bug someone else :)
[11:28] <sivang> Keybuk: I'm singing off for today, if you do get to review it, email me with any fixes I need to do and/or put remakrs inline the wiki page.
[11:29] <sivang> night all
[11:30] <bddebian> Gnight sivang
[11:38] <shaya> is it just me, or is aptitude seriously broken in edgy?
[11:38] <shaya> pegging my cpu on startup with "Initializing package states"
[11:39] <pygi> shaya, everything is seriously broken in edgy :P
[11:39] <shaya> :-p
[11:39] <shaya> not quite true
[11:40] <crimsun> 0.4.1-1.1ubuntu2?
[11:40] <shaya> yes
[11:40] <shaya> filing a bug
[11:41] <shaya> and filed
[11:43] <zul> Keybuk: can you check up on kernel-package, it got accepted into edgy but i dont think its in the archive yet
[11:44] <Keybuk> zul: not right now
[11:44] <zul> ok
[11:44] <Kamion> kernel-package | 9.001ubuntu15 |          edgy | all
[11:44] <Kamion> kernel-package | 9.001ubuntu16 |          edgy | source
[11:45] <Kamion> probably just blocked on the buildd queue being fixed
[11:45] <Kamion> (which Keybuk is sorting out)
[11:45] <zul> ah ok...thanks
[11:58] <Keybuk> right
[11:58] <Keybuk> so 500 in needsbuild, 1258 in depwait
[12:06] <elmo> does gnome-cups-icon randomly leak memory like it was going out of fashion for anyone else?