[12:06] <TheMuso> Ah fair enough.
[12:19] <sladen> UVF is next week?!
[12:19] <Keybuk> yes
[12:19] <Keybuk> week tomorrow
[12:19] <Keybuk> effectively a week from now, in fact
[12:20] <sladen> do we even have a building build system yet
[12:20] <sladen> ...nevermind
[12:20] <Keybuk> at the moment, yes
[12:20] <Keybuk> don't stare at it too hard though
[12:27] <HiddenWolf> sladen, dapper ran long, edgy is a 4 month cycle only
[12:28] <Keybuk> ergo 6.06 "Late To Ship"
[12:28] <LaserJock> lol
[12:28] <LaserJock> now I know why that LTS was there ;-)
[12:28] <HiddenWolf> Keybuk, you wish. :)
[12:28] <jdub> Keybuk: what's the name of that user style firefox extension you suggested? "stylish"?
[12:28] <Keybuk> stylish = greasemonkey for css
[12:28] <HiddenWolf> Keybuk, that'd save you from fixing weird dapper bugs for paying customers. ;)
[12:28] <Keybuk> yes
[12:28] <Keybuk> https://addons.mozilla.org/firefox/2108/
[12:29] <jdub> thanks
[12:29] <LaserJock> Keybuk: where's that LP thing you did for stylish?
[12:29] <Keybuk> http://people.ubuntu.com/~scott/launchpad.user.css
[12:30] <Keybuk> though you also need greasemonkey and
[12:30] <LaserJock> ah, sweet thanks
[12:30] <Keybuk> http://people.ubuntu.com/~scott/launchpad.user.js
[12:31] <LaserJock> way cool
[01:17] <givre> great day today, svn works and france is in final ;)
[01:17] <givre> sorry wrong channel
[01:51] <Keybuk> 2006/07/06 00:46 BST [-]  Scheduling queue_builder for   1.18 seconds time
[01:51] <Keybuk> 2006/07/06 00:46 BST [-]  Running queue_builder
[01:51] <Keybuk> 2006/07/06 00:49 BST [-]  Job queue_builder completed with exit code 0
[01:51] <Keybuk> AHA!
[01:51] <Keybuk> the queue builder took three minutes
[01:51] <Keybuk> that's more like it!
[03:09] <robertj> btw, does anyone know an easy way to reply back to a specific digest message without screwing up the threading?
[03:58] <Hobbsee> hi all
[04:08] <Hobbsee> hi jdub 
[04:16] <jdub> hey Hobbsee 
[04:17] <Hobbsee> jdub: i didnt *quite* get killed :P
[04:19] <jdub> haha
[04:25] <bddebian> Hello
[04:25] <bluefoxicy> Can I change #51881 to critical
[04:25] <Keybuk> bddebian: I was just thinking about you
[04:25] <bddebian> Keybuk: Uh oh, what did I do now?
[04:25] <bluefoxicy> I mean seriously, I just got another font package that went nuts on me
[04:25] <whiprush> jdub: what's your preferred email address for requests for speaking at shows/cons? 
[04:27] <Keybuk> bddebian: sync requests :p
[04:27] <bddebian> Keybuk: Did I screw one up again?
[04:27] <Keybuk> nope
[04:29] <jdub> whiprush: depends on the context ;)
[04:29] <jdub> whiprush: i've applied for ohio btw
[04:30] <whiprush> oh, one of the planners just mailed me, I just wanted to make sure I linked you guys up.
[04:31] <HrdwrBoB> is there any special reasons why uniq has actually had features removed from version 5.2 to 5.93? (breezy- dapper)
[04:45] <bddebian> WAY OT: But have any of you heard of any EDI Translators for GNU/Linux?
[04:51] <bddebian> Thanks Keybuk :-)
[05:07] <bluefoxicy> Setting up xfonts-intl-european (1.2.1-6ubuntu1) ...  <-- this is main, right?
[05:17] <Keybuk> jdub: hang on, phone died :p
[05:17] <jdub> heh
[05:17] <jdub> 1:17 in one call ;)
[05:18] <dieman> oh jeez, people are digging ubuntu specs now
[05:18] <Keybuk> k, calling again
[05:18] <dieman> you know its crazy when...
[05:18] <Keybuk> uh, call again even
[05:18] <Keybuk> (I don't have your sip address in my book yet)
[05:20] <jsgotangco> good morning
[05:22] <Hobbsee> hi jsgotangco 
[05:24] <ajmitch> hi jsgotangco 
[06:04] <Keybuk> http://www.nowcast.co.uk/lightning/index.htm
[06:04] <Keybuk> jdub: ^
[06:07] <Keybuk> btw, thanks for the quick headset test <g>
[06:20] <jdub> Keybuk: ;)
[06:21] <Keybuk> woo, so the thunderstorm we've been promised for 24 hours looks to be finally on its way!
[06:43] <Keybuk> jdub: so, f-spot is cute then
[07:04] <shaya> how does one file a bug against malone?
[07:05] <Lathiat> shaya: http://launchpad.net/products/malone/+filebug
[07:05] <Lathiat> at a guess
[07:07] <shaya> yea
[07:07] <shaya> figrued it out
[07:07] <shaya> painful to search for bugs on malone :(
[07:07] <shaya> unsure how to word the bug
[07:07] <shaya> oh well
[07:08] <shaya> I'll sleep on it
[08:15] <crimsun> hmm, I'm attempting to dput alsa-utils_1.0.11-5ubuntu1_source.changes, and I'm receiving "Connection failed, aborting. Check your network (111, 'Connection refused')". Known issue?
[08:16] <crimsun> (tried from two different hosts on different ISPs)
[08:17] <Hobbsee> crimsun: i got that once, tried again, it went away.  not much help, i know
[08:17] <crimsun> yeah, I'll try again in ~10 mins. 
[08:25] <fabbione> morning
[08:26] <crimsun> 'morning fabbione 
[08:28] <Hobbsee> hi fabbione 
[08:28] <Keybuk> http://www.boardsmag.com/screeningroom/commercials/2206/
[08:29] <Keybuk> ^ I do like that advert ... pretty much every F1 race has it in one break
[08:30] <Keybuk> morning
[08:30] <Hobbsee> afternoon :P
[08:30] <jsgotangco> hello
[08:30] <crimsun> Keybuk: hi, hate to bother you this early, but is the ftpd running on upload.u.c?
[08:30] <Keybuk> crimsun: probably
[08:30] <Keybuk> why?
[08:31] <Keybuk> are you getting connection refused?
[08:31] <crimsun> "Connection failed, aborting. Check your network (111, 'Connection refused')
[08:31] <Keybuk> me too
[08:31] <Keybuk> so that would be "no" then
[08:31] <Keybuk> that requires admin intervention :-/
[08:32] <crimsun> Keybuk: ok, thanks
[08:34] <Keybuk> hmm
[08:34] <Keybuk> maybe it doesn't
[08:34] <Keybuk> this will be ugly, but
[08:35] <Keybuk> ok, we should have an FTP daemon again
[08:36] <crimsun> indeed, thanks again
[08:42] <dholbach> good morning
[08:43] <Hobbsee> hey dholbach!
[08:43] <fabbione> morning dholbach 
[08:43] <dholbach> heya Hobbsee, fabbione!
[08:45] <jsgotangco> hi dholbach!
[09:13] <pitti> Good morning
[09:13] <Hobbsee> hi pitti!
[09:15] <pitti> hi Hobbsee 
[09:18] <\sh> moins
[09:19] <Hobbsee> hi \sh 
[09:19] <pitti> \sh: Guten Morgen!
[09:20] <\sh> pitti: how's the weather at your place? still raining or still hot like hell? ;)
[09:23] <sivan> morning all
[09:23] <pitti> \sh: the latter
[09:23] <pitti> hi sivan
[09:23] <sivan> hey pitti 
[09:23] <\sh> moins sivan
[09:23] <sivan> MoinMoin \sh :)
[09:23] <\sh> sivan: I heard some rumours from raphink that he had lunch with your roomate? :)
[09:24] <sivan> \sh: hahah, amazing, isn't it? :-)
[09:24] <sivan> speaking of the devil :p
[09:24] <Hobbsee> hehe
[09:25] <sivan> morning raphink
[09:25] <\sh> sivan: yeah...ubuntu is everywhere :)
[09:25] <raphink> hi sivan :)
[09:25] <raphink> :)
[09:26] <raphink> sivan : just saw shahar 5 mins ago, he just arrived ;)
[09:26] <sivan> raphink: hehe
[09:26] <sivan> Riddell, sladen : ^^
[09:30] <Keybuk> pitti: so, is Debian undergoing a C++ transition?
[09:30] <Keybuk> or has it recently completed one?
[09:30] <dholbach> Keybuk: I think they fixed most of the c++ packages to build with g++ 4.1
[09:31] <Keybuk> they've dropped the "c2a" from most of the package names
[09:31] <dholbach> afaik you can only do that, if the soname changes in the meantime
[09:31] <dholbach> i don't know if g++ 4.1 changes the abi
[09:32] <Keybuk> they haven't changed the soname
[09:33] <Mithrandir> Keybuk: uh, example package?
[09:34] <Keybuk> libalps-light1c2a -> libalps-light1
[09:34] <dholbach> doko will know for sure
[09:34] <dholbach> i thought gcc 4.1 was only "pickier"
[09:35] <pitti> Keybuk: I don't know, but 4.1 doesn't change the ABI
[09:36] <Mithrandir> Keybuk: it might never have had a non c2a package in the archive in which it's fine to drop the c2a.
[09:37] <Keybuk> just wondered
[09:37] <Keybuk> after UVF, we'll probably have to do a cruft shakedown and rebuild
[09:43] <fabbione> i assume it is known that .17-4 kernel postinstall is broken...
[09:45] <Keybuk> nope?
[09:46] <fabbione> hmmm
[09:46] <\sh> Keybuk: oh fck....
[09:46] <fabbione> it didn't do a bunch of things... like the initrd, update grub menu and depmod
[09:46] <Keybuk> \sh: what did you break?
[09:46] <\sh> Keybuk: alps-light1 and c2a missing...I have to set conflicts/replaces I think
[09:47] <Keybuk> \sh: hmm?
[09:47] <\sh> Keybuk: if we had c2a in the name, and debian not...then I have to, no?
[09:47] <\sh> Keybuk: and in dapper we had c2a in the name
[09:48] <seb128> The following packages have unmet dependencies:
[09:48] <seb128>   libpango1.0-dev: Depends: libxft-dev but it is not going to be installed
[09:48] <seb128> hum
[09:48] <Keybuk> \sh: yes.
[09:48] <\sh> fixing
[09:50] <seb128> hum
[09:50] <seb128> "x11-common: Conflicts: libxft-dev (<= 2.1.8.2-5) but 2.1.8.2-0ubuntu2 is to be installed."
[09:50] <seb128> is somebody working on fixing x11-common? :)
[09:54] <\sh> alps-light1 fixed
[09:56] <Keybuk> you seem much happier today *pats it*
[09:57] <\sh> Keybuk: btw...thx for the syncs :)
[09:57] <Keybuk>   libgtk2.0-dev: Depends: libpango1.0-dev (>= 1.10.0-2) but it is not going to be installed
[09:57] <Keybuk> seb128: ^ ?
[09:57] <fabbione> seb128: it's going to take a few days to get all of X in shape
[09:57] <seb128> Keybuk: 
 "x11-common: Conflicts: libxft-dev (<= 2.1.8.2-5) but 2.1.8.2-0ubuntu2 is to be installed."
 is somebody working on fixing x11-common? :)
[09:58] <Keybuk> same thing?
[09:58] <seb128> yeah
[09:58] <seb128> libpango1.0-dev wants libxft-dev
 seb128: it's going to take a few days to get all of X in shape <-
[09:58] <seb128> which refuses to be installed
[09:58] <seb128> fabbione: welcome to edgy :)
[09:59] <fabbione> seb128: i didn't complain it was not working.. you are welcome to edgy :)
[09:59] <seb128> which means we will have nothing remotly GNOMish building for a days then?
[09:59] <seb128> :p
[09:59] <fabbione> seb128: it depends from you too.. 
[09:59] <fabbione> rodrigo is doing his best, but there are still 100 or more pkgs...
[10:00] <seb128> sure, I don't blame anybody
[10:00] <fabbione> so perhaps getting some help to do the libs will unleash gnome too
[10:00] <Keybuk> seb128: no, no TV ... MERGES
[10:00] <seb128> Keybuk: I can't build packages atm :p
[10:00] <fabbione> seb128: and libs are like any other libs around :)
[10:00] <fabbione> seb128: yes you can.. X libs
[10:00] <sivan> heh
[10:00] <Keybuk> seb128: build them on dapper?
[10:00] <Keybuk> seb128: or help out with the X merge?
[10:00] <fabbione> Keybuk: the latter
[10:00] <crimsun> fabbione: is there a roadmap or sequence? I'm happy to help out
[10:00] <seb128> Keybuk: I was joking for the TV; don't worry I've enough to do on my list too :)
[10:01] <fabbione> crimsun: yes.
[10:01] <fabbione> crimsun: #ubuntu-x for X merges
[10:01] <seb128> Keybuk: I'll keep doing GNOME merges and stack them for now
[10:01] <\sh> seb128: you could help out with KDE 
[10:01] <seb128> sure
[10:01] <seb128> let's break KDE
[10:02] <dholbach> \sh: he was angry at me for weeks, when i touched kde packages
[10:02] <seb128> dholbach: I'm still :p
[10:02] <dholbach> \sh: see
[10:02] <Keybuk> oh, wow, &batch=3000 does bad things to both LP and Firefox
[10:03] <\sh> dholbach: I'm sorry for that...but I think you had a good reason for touching evil KDE packages...:)
[10:03] <dholbach> \sh: seb128 didn't think so
[10:03] <seb128> I just think you have enough to do without trying to fix KDE yourself too :p
[10:03] <\sh> seb128: be happy, france will be world soccer champion
[10:04] <\sh> seb128: and let dholbach fix KDE ;)
[10:04] <Keybuk> so
[10:05] <Keybuk> how upset do you think LP will be if I do a mass give-back? :p
[10:15] <fabbione> Keybuk: i was able to reproduce the kernel issue on ppc too. i will have to talk to Ben and zul
[10:15] <Keybuk> "the kernel issue" ?
[10:16] <pitti> hi ivoks
[10:16] <ivoks> hi
[10:16] <Hobbsee> fabbione: ajmitch reproduced it on his amd64 (i think) laptop earlier too
[10:17] <ivoks> pitti: hplip for edgy and dapper shouldn't just get backported :)
[10:17] <ivoks> pitti: that source should provide different binarys for them
[10:18] <pitti> ivoks: I mean a manual backport, not the 'press the button and generate dapper-backports version'
[10:18] <ivoks> :)
[10:25] <sivan> hunger: is it on a laptop with SATA->PATA bridge ?
[10:35] <Kamion> grr @ merges which revert stuff needed for new X
[10:36] <Kamion> if your merge looks like it needs new X, just leave it alone and do something else, don't revert the bits and then have to put them back again later
[10:38] <Mithrandir> Kamion: which one this time?
[10:39] <Kamion> Mithrandir: jnethack - I'm catching up on edgy-changes
[10:39] <Kamion> -*-Mutt: =ubuntu/edgy-changes [Msgs:1244 New:288 Post:11 Inc:49 6.0M] ---(threads/date)--------------------------------------------------------------------------------------------------------------------(81%)---
[10:43] <sivan> Hobbsee: you have any idea if Riddell should come online soon?
[10:43] <pitti> seb128: what's the issue with this never-ending 'symbol for evolution-2.6 could not be found'?
[10:43] <seb128> pitti: what distro do you speak about, dapper?
[10:43] <pitti> seb128: edgy
[10:43] <seb128> edgy has evolution-2.8 afaik
[10:43] <Hobbsee> sivan: none at all, i dont remember speaking to him last night either
[10:44] <seb128> not 2.6
[10:44] <seb128> pitti: ELACKOFCONTEXT
[10:44] <pitti> seb128: well, I just did a daily dist-upgrade, and now my evo icon is broken
[10:44] <pitti> seb128: (since a few days ago)
[10:44] <pitti> and I repeatedly get this error message
[10:44] <seb128> ah, panel icon?
[10:44] <pitti> yes
[10:44] <seb128> you must point to 2.6 where the icon is name 2.8 now
[10:45] <dholbach> hum, why doesnt it point to /usr/bin/evolution?
[10:45] <pitti> dholbach: the icon is the issue, not the link target
[10:45] <pitti> oh, wait
[10:45] <dholbach> (as upstream is so fond of changing the name every now and then, even if they're not installalble in parallel)
[10:45] <pitti> if I click on it, it cannot execute 'evolution-2.6'
[10:46] <pitti> seb128: since I didn't do anything special with that, this might become a general dapper->edgy upgrade problem
[10:46] <seb128> pitti: is that a launchpad you created or the top panel stock one?
[10:47] <pitti> seb128: hm, if it doesn't happen for other people, maybe I removed it in the past and dragged it again to the panel from the menu
[10:48] <pitti> seb128: yes, now it points to evolution-2.8 and has the 2.8 icon
[10:48] <seb128> pitti: might me, we still have time before edgy, I'm sure somebody else will hit the issue if that's an upgrade issue :)
[10:48] <pitti> yep, we'll do upgrade tests anyway
[10:49] <seb128> pitti: BTW is there any language-pack update planned? due to the translation domain change evolution is 0% translated again...
[10:49] <pitti> seb128: I'd like to, but carlos needs to enable edgy tarballs
[10:49] <pitti> seb128: so, next Monday he should be back from vac, then I hope we can do that
[10:49] <pitti> he promised me to look into it soon
[10:49] <seb128> is there a trick to tell to the buildd to not stip translations for that package? :)
[10:50] <seb128> strip
[10:50] <pitti> well, yes
[10:50] <seb128> like some variable to set or something?
[10:50] <pitti> seb128: NO_PKG_MANGLE=1
[10:50] <pitti> seb128: it doesn't have time until next week?
[10:51] <seb128> it has, but if I do another upload I'll set that
[10:52] <seb128> it might weeks to carlos to get edgy on road
[10:57] <seb128> pitti: what do you mean?
[10:58] <pitti> seb128: appending the -version suffix everywhere instead of just /usr/bin/evolution, evolution.png for the icon, and evolution.mo
[10:58] <seb128> there is no translation breakage out of Ubuntu
[10:58] <seb128> we are the only one to strip translations out like that
[10:59] <sivan> did I ever mention http://fridge.ubuntu.com/files/no-pony-for-you.jpg is SO cruel? I just accidently clicked it while checking the time of the DevTeam meeting today, and it just made me hurt :)
[10:59] <seb128> and they have a non-versionned binary and icon since previous cycle
[10:59] <Keybuk> sivan: NOT YOURS
[11:00] <sivan> Keybuk: mehhhhhhh ! But it's so cute!
[11:00] <Kamion> \sh: merging X fonts before X is merged isn't the best idea in the world :P
[11:00] <ogra> seb128, is it intentional that evo asks for a keyring password now on every start ? thats pretty annoying
[11:01] <seb128> ogra: if it does that's probably because somebody hacked the feature
[11:01] <ogra> hmm... thne he/she should make it work right :)
[11:02] <seb128> ogra: feel free to bug upstream ;)
[11:02] <seb128> ogra: (or to use dapper)
[11:02] <\sh> Kamion: well, am I too fast again? ;)
[11:02] <ogra> at lest is seems i can search my mailboxes without crashers again :)
[11:05] <Zdra> ogra: I guess they uses gnome-keyring to manage password of your email account... I've the same thing here
[11:06] <Zdra> so it asks your password to unlock the keyring and get your emails
[11:06] <Kamion> \sh: yes
[11:06] <Kamion> top tip, if it won't work yet, don't merge it
[11:08] <\sh> Kamion: the xfonts worked yesterday evening ;)
[11:08] <ogra> Zdra, which is very annoying ... 
[11:09] <Kamion> \sh: at least some of the packages affected by 51881 were ones you merged
[11:10] <ogra> whats even more annoying is that its not upgrade safe at all ... you loose all your passwords for all your accounts 
[11:11] <\sh> Kamion: argl..ok
[11:12] <fabbione> sh: if you are doing X please join #ubuntu-x and coordinate otherwise nothing is going to work
[11:12] <Zdra> ogra: yes that's a problem... seb128: don't know if it's possible to import passwords from evo's config to gnome keyring in the upgrade ?
[11:13] <Zdra> that's much a evo bug which should import him self
[11:13] <seb128> no idea
[11:15] <TheMuso> c
[11:16] <doko> hmm, looks like dist-upgrading via dselect is broken ...
[11:16] <seb128> doko: only by dselect?
[11:16] <doko> Reading package lists... Done
[11:16] <doko> Building dependency tree
[11:16] <doko> Reading state information... Done
[11:16] <doko> and hangs with 100% CPU time
[11:16] <doko> seb128: apt-get dist-upgrade works
[11:17] <seb128> weird
[11:17] <doko> seb128: can you reproduce it?
[11:22] <seb128> doko: right, does the same on my box
[11:23] <doko> ok, submitting a report ...
[11:29] <doko> mvo: bug 52074
[11:29] <Ubugtu> Malone bug 52074 in apt "apt-get -f dselect-upgrade hangs with 100% CPU time" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52074
[11:29] <dholbach> doko: mvo is on holidays
[11:30] <doko> dholbach: I'll use apt-get dist-upgrade in the mean time
[11:30] <tseng> you want apt-get upgrade atm :)
[11:30] <tseng> dist-upgrade will remove half your system
[11:30] <tseng> ez gtk boog
[11:31] <dholbach> tseng: not really
[11:31] <tseng> :D
[11:31] <dholbach> . o O { he loves it }
[11:32] <ogra> haha
[12:06] <tseng> Mithrandir: ping
[12:07] <Mithrandir> tseng: hello
[12:07] <tseng> Mithrandir: hey
[12:07] <tseng> can I do a drop-ubuntu sync on openbox?
[12:07] <tseng> build-deps are in line in Debian now, i dont see any other glaring changes we need
[12:08] <Mithrandir> tseng: yeah, should work fine, apart from it might very well end up ftbfs-ing due to X being all over the place atm, but I guess we'll solve that by a mass-give-back of doom.
[12:08] <tseng> right, will file the bug
[12:08] <tseng> thanks.
[12:11] <heno> Keybuk: can you use your ubuntu-driver super powers to set a priority on https://launchpad.net/distros/ubuntu/+spec/sok ?
[12:12] <heno> Keybuk: Medium will do nicely :)
[12:15] <Keybuk> heno: done
[12:15] <heno> Keybuk: thanks!
[12:19] <heno> Keybuk, Mithrandir, fabbione: would any of you care to review sok and xubuntu-accessibility ?
[12:19] <heno> these should really be on the edgy track
[12:19] <fabbione> heno: if it can wait 30 minutes i can take one of them
[12:20] <fabbione> i am in the need of food
[12:20] <Keybuk> heno: I don't really have the time right now I'm afraid
[12:20] <heno> fabbione: great, thanks
[12:20] <Keybuk> I have a small stack of specs already, and I need to sleep at some point before the meeting
[12:20] <heno> Keybuk: np, sleep well :)
[12:22] <heno> iwj, Kinnison: either of you have time for a spec review today?
[12:27] <pygi> sivang, poke? :)
[12:27] <sivan> pygi: hi
[12:27] <pygi> sivan, what's the review status ? :)
[12:28] <sivan> pygi: there's more stuff to fix, take a loot at both of the specs mdz and Keybuk have comments inline
[12:28] <pygi> ok, looking 
[12:29] <pygi> system backup is out of edgy scope
[12:29] <pygi> we agreed on edgy+1 for that
[12:29] <sivan> pygi: Well, mvo noted it is something very easy to do, and what's proposed there is a very simple system backup, read on :)
[12:30] <jsgotangco> yeah
[12:30] <sivan> pygi: it's far from being something complete or comprehensive. Just another step to make it easier to return a bit more closer to a previous system state.
[12:30] <pygi> sivan, ah :P
[12:30] <Kamion> fabbione: do you have time to review https://launchpad.net/distros/ubuntu/+spec/ubuntu-server-tasks ?
[12:30] <sivan> hmm, I wish mvo was here..
[12:31] <pygi> the UI for the clean tool is libnotify baloon :P
[12:33] <Keybuk> pygi: you can't click anything inside one of those, or offer choices
[12:33] <sivan> pygi: not only, the kernel clean up (the highest priority use case for it) will need some sort of a treeview/list so users can choose to keep more then only the currently running and the previous kenrel.
[12:33] <pygi> Keybuk, indeed ^_^ When you click the baloon, the UI will appear :P
[12:34] <Keybuk> pygi: right... that's the UI that isn't specified
[12:34] <pygi> Kamion, isn't that something like Ubuntu Instant Server?
[12:34] <pygi> Keybuk, agreed ^-^
[12:34] <Kamion> pygi: never heard of it
[12:34] <pygi> Kamion, hm, sec,if it still exists
[12:34] <iwj> heno: Should be able to, yes.
[12:34] <sivan> Keybuk: I think there's some tests in the libnotify package that offer more then just one callback, as in choices
[12:35] <Kamion> pygi: apparently does; Adam never mentioned it so I assume he hadn't heard of it either
[12:35] <heno> iwj: great, thanks :)
[12:35] <iwj> Which one ?
[12:35] <Kamion> pygi: this should obsolete the first half of ubuntu-instant-server-manager I guess; we already have all the mechanism mapped out
[12:35] <heno> iwj: you can choose :)  sok is much longer
[12:35] <Kamion> so I'm not too interested in going back to the start again
[12:36] <pygi> Kamion, no worries, seems like u-i-s is mostly removed anyway :-
[12:36] <heno> xubuntu-accessibility is almost informational in nature
[12:36] <Kamion> pygi: shame about the duplication, but there you go
[12:37] <fabbione> Kamion: yer
[12:37] <fabbione> Kamion: yeps looking..
[12:37] <pygi> Kamion, partly my fault probably
[12:37] <iwj> heno: I'll take sok for now.
[12:37] <fabbione> heno: which one do you need first?
[12:38] <sivan> pygi: are you going to work on the specs? I intend to work on them in about 15 minutes, if you have any additoins or suggestion add inline like keybuk did and I'll merge stuff
[12:38] <heno> fabbione: well, iwj is doing sok now, so if you could do xubuntu-a sometime today, that would be great
[12:38] <Kamion> pygi: it didn't help that the spec was off on a random product rather than on /distros/ubuntu
[12:38] <pygi> Kamion,yes, I am aware of that
[12:38] <fabbione> heno: sure.. i will do it in few mintues
[12:39] <pygi> sivan, will do, just not right now
[12:39] <sivan> Riddelll: around? are you able to log into muse ?
[12:39] <sivan> pygi: okay, then please let me know before as I may be editing it.
[12:39] <pygi> sivan, no worries :)
[12:40] <Riddelll> sivan: no, ssh has died
[12:41] <sivang> Riddelll: I see, well, I guess you're onto it already or should we wait for sladen ? :)
[12:42] <Riddelll> sivang: he's awake now at least
[12:44] <fabbione> Kamion: -> Pending Approval.
[12:44] <fabbione> heno: checking xubuntu-a right now
[12:45] <Seveas> Kamion, is the CC meeting scheduled yet?
[12:46] <iwj> heno: Looks pretty good.  Just a couple of comments, see Review Comments in the wiki page.
[12:46] <heno> iwj: great, thanks
[12:47] <fabbione> heno: i think we need to work a bit in xubuntu-a and add a few more details
[12:47] <Kamion> fabbione: thanks
[12:48] <heno> fabbione: should it be made an informational spec you think?
[12:48] <fabbione> heno: basically you need to think in a position like mine. I know absolutely nothing about accessibility and xubuntu. reading the spec i should be able to implement it.
[12:48] <heno> ok
[12:49] <heno> I'll look again from that perspective
[12:49] <fabbione> heno: for example: package foo, move foo from universe to main, link xubuntu-terminal to library bar provided by foo to enable Sticky Keys (or whatever)
[12:49] <Kamion> Seveas: is now, although mako never replied to my mail
[12:49] <fabbione> heno: just as general guide line..
[12:49] <heno> I see
[12:49] <Seveas> Kamion, gracias!
[12:49] <heno> sounds good
[12:49] <fabbione> heno: same goes for the LiveCD. I don't know what i should do if i was assigned this spec..
[12:49] <Kamion> Seveas: do you remember who does the meeting logs?
[12:50] <fabbione> heno: perfect.. just ping me when you are ready for the next review
[12:50] <Seveas> I *think* robitaille
[12:50] <Kamion> apparently they're out of date
[12:50] <Seveas> ah
[12:50] <heno> fabbione: you mean https://launchpad.net/distros/ubuntu/+spec/livecd-access ?
[12:50] <iwj> heno: ping me again here when you've updated it and I'll re-review.
[12:50] <Seveas> maybe I should rig up ubugtu to do the logs (automation++)
[12:51] <fabbione> heno: no i mean xubuntu-a.
[12:51] <fabbione> heno: "Scope: Create a Live CD configuration based on the Ubuntu one."
[12:51] <heno> fabbione: right. I'll explain it better there
[12:51] <fabbione> perfect :)
[12:51] <heno> https://launchpad.net/distros/ubuntu/+spec/livecd-access has the explanation, so I can link to that
[12:52] <heno> iwj: thanks. I'll need some help finding the right terms for the keystroke-sending bit
[12:52] <heno> Mithrandir: ping ^
[12:52] <heno> The keystrokes are sent 'directly to X'
[12:53] <heno> is probably too vague
[12:53] <Mithrandir> heno: hmm?
[12:54] <heno> Mithrandir: in SOK we feed keystrokes directly in through the X infrastructure
[12:54] <heno> what is a good way to express that?
[12:54] <heno> we don't use AT-SPI or anything
[12:54] <Mithrandir> heno: you're probably synthesizing input events using the Record X server extension.
[12:55] <heno> Mithrandir: very likely. What should I look for in the source to be sure? (python)
[12:56] <Mithrandir> heno: no idea, I've never used the extension myself.
[12:56] <heno> Mithrandir: ok, thanks I'll look at the code and old emails, thanks
[01:03] <TheMuso> heno: The xtst extension is used AFAIK.
[01:04] <heno> TheMuso: thanks :)
[01:12] <iwj> heno: You might be using XSendEvent, which is an even older thing.
[01:13] <heno> iwj: could be. I'll ask my student for details when he turns up. It's coded and working nicely already though :)
[01:14] <fabbione> who knows quilt enough to tell me what's the canonical way to add a patch to it?
[01:16] <lifeless> refresh I think
[01:16] <lifeless> or something like that 
[01:17] <Kamion> 'quilt new' surely
[01:17] <Kamion> ?
[01:18] <heno> iwj: ok, I've saved my changes
[01:25] <iwj> Urr.  OK.  Well, I'll send it up for approval.
[01:25] <iwj> But first I'll edit your answers into the body of the text.
[01:26] <ogra> would someone mind looking at the student-control-panel-completion spec ? fabbione already looked and had some critics on the remote desktop section which i rewrote
[01:27] <iwj> heno: Is that 90 developer days really right ?
[01:28] <iwj> ogra: From a review PoV ?  Sure.
[01:28] <ogra> iwj, thanks :)
[01:28] <heno> iwj: it's a SoC project, with a student working on it full time. Those are his days, not ours
[01:28] <iwj> Ah.
[01:28] <heno> If I were to list my days, I might make it 15
[01:29] <iwj> Still, 90 working days is 18 weeks (at least).
[01:29] <heno> iwj: right he started on it before dapper was out though
[01:30] <iwj> Aha.
[01:30] <heno> We have made good progress, so I'm happy to set it to 50 now
[01:30] <iwj> ogra: I take it you don't mind if I edit it for grammar ?
[01:31] <ogra> totally not, go ahead :)
[01:31] <heno> you can grab a working version of SOK here: https://wiki.ubuntu.com/Accessibility/Projects/SOK
[01:33] <iwj> ogra: Is comma-splice allowed in German ?
[01:33] <iwj> Because it's not in formal English.
[01:33] <ogra> well, its mostly german comma rules with english words there ... might all be wrong :P
[01:34] <ogra> sorry for that
[01:34] <Kamion> Toadstool:  -> http://librarian.launchpad.net/3282392/y1QkQEkEU4T7Yb3BgaUnAvCvATC.txt (GPG verification of mini-dinstall_0.6.21ubuntu1_source.changes failed: No public key)
[01:35] <Toadstool> uh?
[01:36] <Kamion> Toadstool: oh, you aren't in ubuntu-dev, you can't upload to universe
[01:37] <Kamion> ... but mini-dinstall 0.6.21ubuntu1 is already in dapper/universe. what's going on?
[01:37] <Toadstool> Kamion: never tried to upload mini-dinstall as far as i remember
[01:37] <Kamion> is somebody automatically reuploading crap from revu? I see a number of failures like that
[01:37] <Toadstool> or anything else in universe
[01:37] <Kamion> yeah, sorry, I saw your name but forgot to check the date
[01:37] <Toadstool> ah ok, no problem :)
[01:38] <Toadstool> I thought I did something wrong :)
[01:49] <iwj> This wiki is so slow atm ...
[01:50] <ogra> iwj, urgh, all other sections were already approved ...
[01:51] <ogra> oh, you only edited the remote desktop stuff ... sorry ... it became so big :)
[01:52] <ogra> iwj, recommends can install stuff inside a unspecified chroot if i install soemthing in the host system ?
[01:52] <ogra> (thats really news to me)
[01:56] <iwj> ogra: Oh, I see, like that.
[01:56] <iwj> Err, you could do that in the postinst.
[01:56] <iwj> Although it's a bit scary.
[01:57] <iwj> `all other sections were already approved'> I see.  Well, no, I don't see.
[01:58] <ogra> iwj, running: chroot /opt/ltsp/$(dpkg --print-architecture) apt-get install x11vnc from postinst would be allowed ?
[01:58] <ogra> wow, i wouldnt have guessed ...
[01:58] <iwj> I don't see why it wouldn't work.
[01:58] <iwj> How do you normally set up this chroot ?
[01:59] <iwj> You are going to get hideously confused if installing x11vnc does anything unexpected (worst case: asks debconf questions).
[01:59] <iwj> You might have to untangle some of the debconf env vars to stop it from trying to talk to the outside debconf db.
[01:59] <ogra> well, the chroot might not exist if you run it on debian systems ... but a simple if clause could check that
[02:00] <iwj> No, I mean, how does the chroot normally get there ?
[02:00] <iwj> Whether or not it's reasonable to mess with it like that depends on how much you own it.
[02:00] <Kamion> if you actually want to pass through debconf questions it asks then that's massive fiddliness
[02:00] <ogra> and setting depconf to noninteractive at the top of the postinst for the chroot and setting it back at the end should work as well
[02:00] <Kamion> ogra: you also need to unset DEBIAN_HAS_FRONTEND at least to make it start up a new debconf frontend
[02:01] <Kamion> if you think it's straightforward then you've never done it before
[02:01] <ogra> iwj, the chroot exists either because you installed edubuntu or because you ran ltsp-build-client in ubuntu
[02:01] <iwj> Right, so if you do that, it makes the chroot for you with debootstrap or some such ?
[02:01] <ogra> Kamion, i didnt plan to do that at all from the postinst ... i was wondering why iwj suggested that 
[02:02] <iwj> Eg, as part of the edubuntu install setup ?
[02:02] <ogra> yep
[02:02] <ogra> in edubuntu the installer runs the chroot setup script
[02:02] <Kamion> ogra: it doesn't sound like a terribly good idea to do it from the postinst, I agree
[02:02] <iwj> Well, then your edubuntu/ltsp stuff definitely owns it and I think you're probably entitled to mess with it.
[02:02] <ogra> in ubuntu you have to do it after you installed ltsp-server manually
[02:03] <iwj> Hmm.  I'd still be cautious.
[02:03] <Mithrandir> iwj: thanks for the new meeting times, they look much better.
[02:03] <ogra> thats why i want a gui option that just installs it 
[02:03] <ogra> Mithrandir++
[02:03] <iwj> Mithrandir: Oh, good.  No-one has said anything at all about them on email which I suppose means everyone agrees :-).
[02:03] <ogra> iwj, they are great :)
[02:03] <Kamion> meeting times> I agree. Will be interested to see how it works out in winter time (I suppose we'll have a new schedule).
[02:04] <Mithrandir> iwj: mdz seemed happy enough, but I didn't see the point of mailing everybody to say I'm happy.
[02:04] <iwj> ogra: GUI option> Fine, that's a good answer.  Just write it into the wiki page.
[02:04] <ogra> its in there :)
[02:04] <iwj> new schedule> Indeed, we will.
[02:04] <iwj> Mithrandir: :-).
[02:04] <ogra> A "first start popup window" will be added to the GUI, with a checkbox "Dont show this window again" and a button "Install remote desktop access".
[02:04] <ogra> :)
[02:04] <ogra> i'll rewtite it a bit :)
[02:04] <iwj> Right.  But point out the thing about a chroot.
[02:04] <iwj> I missed that when I was reading it.
[02:04] <ogra> yep
[02:05] <iwj> I'm sure it's clear if you already understand all of this stuff.
[02:05] <ogra> well: Choosing the latter option will execute a script /usr/share/student-control-panel/install-client-vnc.sh which will run  apt-get install x11vnc  in the client chroot with the above described option preseeded.
[02:05] <iwj> I thought the alternative you were dismissing was to run apt-get install something _not_ in a chroot from a postinst which would an "unusual" approach.
[02:05] <ogra> i thought "client chroot" would suffice there ... i'll re-formulate it
[02:06] <iwj> Sorry, maybe I just didn't read it carefully enough.
[02:06] <iwj> I haven't had any lunch yet :-).
[02:06] <ogra> yeah, that'd be silly, i'd just add a dependency :)
[02:06] <doko> pitti, BenC: http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00206.html
[02:06] <ogra> iwj, no its fine, even hungry people should understand my specs ;)
[02:08] <Hobbsee> ogra: just make sure you talk about lots of food in the spec :P
[02:08] <ogra> haha
[02:09] <iwj> So, yes, lunch.
[02:09] <Hobbsee> :P
[02:09] <Seveas> The have-lunch-before-reading-specs-spec
[02:09] <mdke> Znarl: around?
[02:14] <zul> hey
[02:24] <doko> Keybuk, Kamion: anyone of you wants to review edgyplusone-toolchain-roadmap or python2.5?
[02:25] <azeem> whoa, I thought that was a package name for a second
[02:26] <Kamion> doko: I'll do python2.5
[02:27] <Kamion> doko: either fill out the Scope section or delete it
[02:27] <Kamion> don't leave empty sections
[02:39] <enrico> Is there some free LPI ubuntu training material available?
[02:41] <ogra> iwj, "Which actual protocol will you be using ?" there is only *one* protocol dbus speaks ... if oyu add a listener for student control panel that one will be used ... what exactly do you mean with the comment ? 
[02:41] <enrico> sorry, wrong channel
[02:44] <enrico> was there a decision to migrate to smart for edgy?  I just heard people mentioning it but I didn't remembering hearing official decisions
[02:44] <enrico> (but maybe it's in one of the new specs I haven't looked at)
[02:44] <neuralis> enrico: no.
[02:46] <seb128> enrico: there is plan to play with smart but not to use it by default (yet?)
[02:49] <enrico> ok, thanks.  Maybe I can correct that statement
[02:49] <heno> Mithrandir: with live-cd-stacked-filesystems will be be able to have different packages installed for different boot options on the same Live CD? So a xubuntu-access package could be installed only if F5-... were selected?
[02:50] <iwj> ogra: You give a reference to the dbus spec.  The dbus spec says any SASL authentication mechanism is supported and also offers one of its own.
[02:50] <Mithrandir> heno: conceivably, yes, but it's a stack, not a heap so you need to choose carefully.
[02:50] <ajmitch> any reviewers available to re-check network-authentication?
[02:51] <iwj> And you just say `dbus does it for us' but which authentication mechanism with which credentials ?
[02:51] <heno> Mithrandir: ok, thanks
[02:51] <ogra> iwj, the default one we use everyawhere indeed (no sasl, i'll add a note)
[02:52] <iwj> You mean DBUS_COOKIE_SHA_1 ?
[02:52] <ogra> iwj, i expect someone who wants to implement that dbus part to know about dbus, i dont think that needs further specification
[02:52] <iwj> So using which private key ?
[02:52] <ogra> no keys
[02:53] <ogra> you have a listener in the users session (like all other apps have) if thats connected, it blocks
[02:53] <ogra> s/other apps/other dbus based apps/
[02:53] <iwj> Listen to me: you're proposing to allow the LTSP admin tool to run commands as users.  Ie, to give them full control of the user accounts.  Well, fair enough, you may say.
[02:54] <iwj> But you haven't explained how you will prevent other people from (ab)using this mechanism.
[02:54] <iwj> That is absolutely critical for this feature, surely ?
[02:54] <ogra> by a dbus connection thats established
[02:54] <ogra> if its established it blocks ...
[02:54] <iwj> Maybe we're having a language barrier here.
[02:55] <iwj> Because I can't understand how whether it blocks or not is at all relevant.
[02:56] <iwj> Did you read the dbus spec authentication section, that you link to from the spec ?
[02:56] <ogra> i read the dbus-specification, yes ... 
[02:56] <ogra> the auth section is only a subpart
[02:56] <seb128> I'm away for some hours, I've spoke with mdz about it yesterday and will catch up later today, bbl
[02:57] <iwj> The auth section is obviously what we're talking about in this context.
[02:57] <iwj> So far your spec just says `DBUS has the security built in to not accept any messages except from SCP (see [WWW]  http://dbus.freedesktop.org/doc/dbus-specification.html#auth-protocol for tech details)' which is not enough detail I'm afraid.
[02:58] <ogra> (/me is near to just enable xdmcp in edubuntu and just use xhost as everyone else does)
[02:58] <iwj> If you propose not to have any security at all then write that in the spec and we'll see whether it gets approved, eh ?
[02:58] <ogra> i'll take out the auth part if that bothers you and just say we'll do it via dbus
[02:59] <iwj> Taking stuff out is not the answer.
[02:59] <ogra> with the same security constarints every other dbus aware app has
[02:59] <pitti> doko: oh, that sounds nice; thanks for the link
[03:00] <iwj> We're going round in circles here.  Bottom line: I'm not happy with it as it stands; I've tried to explain to you what I think needs to be in the spec, and apparently failed.  I'm going to go and calm down a bit and then I'm going to send an email about it.
[03:01] <ogra> ok
[03:07] <Zdra>  sudo apt-get build-dep nautilus
[03:07] <Zdra> Reading package lists... Done
[03:07] <Zdra> Building dependency tree
[03:07] <Zdra> Reading state information... Done
[03:07] <Zdra> E: Build-dependencies for nautilus could not be satisfied.
[03:07] <Zdra> does it mean something is broken ? or mirror not up-to-date ?
[03:08] <ogra> dapper ? breezy ? hoary ?
[03:08] <Zdra> edgy :)
[03:08] <tseng> alot of things in edgy are broken atm
[03:08] <ogra> pfft
[03:08] <tseng> but please do not paste big blocks here
[03:08] <ogra> what do you expect ? we dont even have a complete X 
[03:08] <ogra> ;)
[03:09] <jsgotangco> heh
[03:09] <Zdra> ok so it is normal... (sorry I should use pastbin)
[03:09] <jsgotangco> i can't even boot my box!
[03:10] <ogra> Zdra, i'm not even sure gtk is there yet ... 
[03:10] <Hobbsee> jsgotangco: however did you manage that?
[03:10] <Zdra> ogra: yes 2.10 is running just fine here :)
[03:10] <jsgotangco> Hobbsee: i'll do it later
[03:10] <Kamion> Zdra: we're in the middle of merging Debian's X into edgy. Breakage is expected.
[03:11] <Hobbsee> Kamion: any ETA on the end of the merging?
[03:11] <ogra> Hobbsee, nah ... only if you merge X stuff or things with direct X deps
[03:12] <fabbione> Hobbsee: not really.. we are dealing with LP being a bit slow today
[03:12] <fabbione> Hobbsee: because most of X is ok .. and it should be able to install
[03:12] <Hobbsee> ogra: kdelibs4-dev depends on libxft-dev.  and that's screwed.  and most kde based things have a b-d on kdelibs4-dev.
[03:12] <Kamion> not so much LP being slow as an archive inconsistency problem
[03:12] <Mithrandir> Hobbsee: apparently the publisher part of launchpad decided to blow up so until that's fixed, there's not much we can do.
[03:12] <sivang> does anybody have good ideas for HomeUserBackup's files file extension for a mime type registring? Please consider that in the future it might be use for more then just home user folder's backups..
[03:12] <Zdra> why merging X from debian if we'll upgrade to 7.1 after that ? :)
[03:13] <Hobbsee> Mithrandir: oh what fun, hehe.  blowing things up is great!
[03:13] <Kamion> Zdra: (a) syncing the packaging first makes our lives much easier
[03:13] <Mithrandir> Hobbsee: not so much when it leads to not being able to do ones work.
[03:13] <Hobbsee> Mithrandir: that's true
[03:13] <ogra> Hobbsee, libxft-dev was uploaded already so if the LP prob is solved it should be available
[03:13] <Kamion> Zdra: (b) Debian have at least part of 7.1 in experimental so we may well be able to sync that
[03:13] <fabbione> Zdra: "we"? are you helping with the merge?
[03:13] <Hobbsee> ogra: any idea on what version?
[03:14] <ogra> Hobbsee, no, but surely the most recennt debian one 
[03:15] <Hobbsee> ogra: right, good, i'll just wait for that then.
[03:15] <Zdra> fabbione: no, no... I just don't know how to translate impersonal "on" from french :p
[03:15] <ogra> Hobbsee, X :)
[03:15] <Hobbsee> ogra: you *really* want me to run away screaming?  :P
[03:15] <ogra> Hobbsee, join #ubuntu-x so you can at least lurk :)
[03:16] <Hobbsee> ogra: hehe at the topic!
[03:17] <Kamion> the topic is serious; we have a serious time shortage and would appreciate minimal distractions in -x
[03:17] <Hobbsee> ogra: if it's simplish, i can probably help you out.  but if it's complicated, then there's probably no point in trying to explain it, and taking time to do it as a result, instead of just getting on to the job at hand.
[03:17] <Hobbsee> Kamion: sure
[03:18] <sivang> pitti: do you know how complex would it be to have support for detecting HomeUserBackup CDs and fire up a program when such "Backup CD" is detected?
[03:18] <pitti> sivang: it would require a hook in update-notifier or gnome-volume-manager
[03:19] <sivang> pitti: what's invloved to actually recognize a CD or another device to contain CD of type 'X' ? do we have special checks in g-v-m's hooks to positively recognize it's an ubuntu install cd? like certain files or so?
[03:20] <pitti> sivang: Ubuntu CDs are recognized by update-notifier
[03:20] <pitti> it checks for a special file and its contents
[03:20] <tseng> it would make more sense to me to have an autorun file on the cd
[03:20] <pitti> tseng: we disable autorun by default
[03:22] <sivang> pitti: so update notifier checks that file each time it receives an insert CD event from hal?
[03:22] <pitti> yep
[03:23] <sivang> ah, so I'd probably use g-v-m to not have to depend on another daemon I will have to create for that.
[03:23] <sivang> althought if a daemon is created to count days since user's last backup operation I can add this there..
[03:26] <sivang> pitti: do we have any other stuff that's using  g-v-m hook to do something when something happens?
[03:26] <sivang> (I'd like to try look at an example to get an idea for it)
[03:26] <pitti> sivang: gvm doesn't provide any hooks
[03:26] <pitti> you have to hardcode it into the code
[03:27] <sivang> bah 
[03:27] <sivang> so I need a daemon... or attempt to use hermes if it's planned to have it in for edgy..
[03:34] <ajmitch> Kamion: if you have time for a quick review of network-authentication, it'd be much appreciated 
[03:35] <Kamion> ajmitch: have to go out for a bit now, but if nobody's picked it up when I'm back (an hour or so), I will
[03:35] <ajmitch> iirc it was unapproved just before paris 
[03:35] <ajmitch> thanks
[03:46] <sivang> yay, my muse is back :)
[03:48] <bddebian> Hello
[04:00] <heno> fabbione: when you get a chance, I've made changes to https://wiki.ubuntu.com/Accessibility/Specs/XubuntuAccessibility based on your feedback
[04:42] <fabbione> heno: looking now
[04:43] <bddebian> Heya fabbione
[04:44] <fabbione> hi bddebian 
[04:47] <bddebian> fabbione: Done holding rodarvus's hand yet? ;-P
[05:08] <Riddell> mdz: kubuntu-system-settings-usability is ready for another review
[05:08] <Riddell> as is kubuntu-edgy-package-manager
[05:10] <Kamion> slomo: mono FTBFS on powerpc again; did you drop that workaround patch?
[05:10] <slomo> Kamion: no this is a new problem unfortunately
[05:10] <Riddell> and if any reviewer wants to take over from keybuk on kde-kiosk-profiles that would be great
[05:10] <slomo> Kamion: we have a better patch now that worked some time
[05:11] <slomo> Kamion: and then mono failed completely on ppc so i guess it's a change outside of mono that caused this breakage now
[05:11] <Kamion> d00m
[05:11] <slomo> Kamion: it's not ssp at least, pitti tested this already. and the new patch for the old problem is not broken because we get the same segfault with the old patch as with the new patch
[05:13] <slomo> no idea what we can do about it... i asked the guy who fixed the old problem to reproduce it on his machine (on debian)... if he can't i'm lost ;)
[05:16] <pitti> zul, BenC: ping
[05:17] <slomo> Kamion: FYI, last time the problem was that new memory for code was allocated via malloc() on another cpu and the memory was not marked executable
[05:17] <zul> pitti: ping
[05:17] <zul> er...pong
[05:20] <doko> Mithrandir: could you review edgyplusone-toolchain-roadmap?
[05:26] <BenC> pitti: pong
[05:32] <jbailey> Is there a reviewer handy for https://launchpad.net/distros/ubuntu/+spec/edgyplusone-toolchain-roadmap ?  I did a bunch of the editting on it, so I'm not longer comfortable passing it past review stage myself.
[05:37] <Kamion> Riddell: re bug 52104, you have a koffice-l10n in dapper too (as well as koffice-i18n). Are you still sure you want to sync?
[05:37] <Ubugtu> Malone bug 52104 in koffice-i18n "Please sync koffice-l10n from unstable" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52104
[05:47] <Kamion> mdz: can you look over ubuntu-server-tasks?
[05:51] <Riddell> Kamion: yes please sync
[05:51] <Kamion> Riddell: for kubuntu-file-transfer-dialogue, how does the user configure whether to show/hide finished downloads if they've already chosen to hide them and they have no downloads in progress?
[05:51] <Kamion> "The option to show and hide finished downloads is accessible via the system tray icon's right context menu."
[05:51] <Riddell> Kamion: and can you remove koffice-i18n?
[05:52] <Riddell> Kamion: right click on systray menu
[05:53] <Kamion> Riddell: but you said the icon would disappear if there were no downloads in progress and you'd configured it to hide, so how do you get to that?
[05:54] <Kamion> koffice-i18n-srlatn | 1.4.1-0ubuntu1 | edgy/universe | all
[05:54] <Kamion> koffice-i18n-zhcngb2312 | 1.4.1-0ubuntu1 | edgy/universe | all
[05:54] <Kamion> koffice-i18n-zu | 1.4.1-0ubuntu1 | edgy/universe | all
[05:54] <Kamion> ^-- binaries still shipped by koffice-i18n, for the record
[05:54] <Kamion> ok to remove those too?
[05:55] <pygi> sivang, poke?
[05:55] <Riddell> Kamion: yes, remove them
[05:57] <Kamion> done
[05:57] <Riddell> Kamion: once you've chosen to hide finished downloads you don't get to show them again
[05:58] <Kamion> that seems like a design bug
[05:59] <Riddell> you don't get to see copied files curently once they've finished downloaded
[05:59] <Riddell> s/ed/ing/
[05:59] <doko> reviewers: could you still do two reviews, one informational: edgy-openoffice.org and ooo-langpacks?
[06:01] <Kamion> Riddell: right but you also don't get to turn it back to "show all downloads from here on"
[06:01] <Kamion> without starting a download long enough for you to find the icon and right-click on it
[06:02] <mdz> Kamion: ok
[06:03] <Riddell> Kamion: you can configure this in Konqueror's Settings, leave a note on the wiki and I'll clarify that
[06:03] <Kamion> Riddell: ok, that's what I wanted to hear :)
[06:03] <mdz> Kamion: "Each task will be implemented as a seed, from which the server seed will inherit"
[06:03] <mdz> Kamion: do I misunderstand or is that backwards?
[06:04] <mdz> I'd assume the task seeds should inherit from the server seed, not vice versa
[06:04] <mdz> oh, right, server is actually server-ship
[06:04] <mdz> Kamion: can we rename that regardless of whether we create a true server seed?
[06:05] <Kamion> sure, I was talking about the current server seed
[06:05] <Kamion> (renaming's out of scope for that spec)
[06:05] <Kamion> I can add a note to say that the server seed should inherit from them if they're to go on the CD
[06:06] <Kamion> (done)
[06:08] <slomo> Kamion: nice, i can reproduce this one on my ibook... so it's not only ppc64 related this time
[06:10] <mdz> Kamion: no metapackages?
[06:11] <Kamion> mdz: I'm not hugely keen on creating another n metapackages
[06:11] <Kamion> at some point, apt is just going to have to understand tasks
[06:11] <Kamion> or smart
[06:12] <Kamion> I think the upgrade concern here is much less than for ubuntu-desktop - the tasks won't change often, and once somebody's set a server up they're unlikely to want to radically change the set of packages implementing their services anyway
[06:18] <Kamion> mdz: thanks
[06:23] <iwj> doko: Do you have reviewers for those yet ?
[06:26] <iwj> doko: Err, EdgyOpenOffice still looks like a braindump to me.
[06:26] <iwj> doko: Am I looking at the wrong page ?
[06:28] <iwj> doko: OpenOfficeLangPacks still seems a bit sketchy.  There are empty sections which you should put some stuff in, or rename, or delete, or something.
[06:28] <Kamion> heno: could you note the DVD content requirement from EdgyContent somewhere in LargerLivefs, please?
[06:29] <iwj> doko: re OpenOfficeLangPacks> It would be nice if you could perhaps explain the build flow process before-and-after.
[06:29] <Kamion> heno: EdgyContent seems to have quite a few outstanding issues; which of those need to be addressed before approval?
[06:30] <iwj> doko: Do you want me to put these comments somewhere in the page and set it back to Drafting, or are you going to pick it up right now ?
[06:30] <Kamion> heno: (for the record I don't think a separate content repository is a good idea; it requires too much support in the installer, packaging infrastructure, etc. before random users actually stand a chance of finding it)
[06:32] <bddebian> is #!/bin/sh -e  valid for pre-post-etc inst files?  Or should it be #!/bin/bash?
[06:37] <pitti> bddebian: sh -e is the prefered shell
[06:38] <pitti> bddebian: as long as the script is POSIX clean and works with dash, you should use sh
[06:38] <bddebian> pitti: OK, so what if they use bashisms in the script then?
[06:38] <pitti> bddebian: then use /bin/bash, of course
[06:38] <pitti> (-e)
[06:38] <bddebian> Hmm.
[06:39] <bddebian> Is there a POSIX let?
[06:39] <bddebian> pitti: Thx btw :-)
[06:40] <pitti> bddebian: let> no idea
[06:40] <pitti> bddebian: use dash -n and a test run with dash
[06:40] <bddebian> pitti: I already know it fails :-)  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367939
[06:40] <Ubugtu> Debian bug 367939 in libapache-mod-mp3 "Subject: libapache-mod-mp3: bashizm in postinst" [Important,Open]  
[06:41] <pitti> bddebian: oh, then just use bash and let it RIP
[06:41] <iwj> doko: I have put my comments (as wittered above) into the wiki page and adjusted the spec status.
[06:42] <iwj> doko: NB that I'm going to be going swimming at about 1800ish (in 19mins from now) and will probably not return until the meeting so you should get someone else to do the next iteration review.
[06:47] <jdub> mako: ping
[06:50] <heno> Kamion: yes, it's a shame we didn't get a chance to have a session on EdgyContent in Paris. I think I need to email or phone a few more people to get their views. I'll take your word for the problems with Outstanding Issue #2 though, and skip that notion
[06:51] <heno> Kamion: By DVD requirement to you mean in disk space?
[06:51] <heno> that depends on how much useful content we find by then
[06:51] <heno> setting an upper limit is an idea though
[06:52] <rodarvus> mdz, (asking you since you were the last reviewer for them) ltsp-login-and-session-handling and edubuntu-xfce-desktop are back on the review queue - do you think you'll be able to review them, or should I bug someone else?
[06:54] <bddebian> rodarvus: Don't you have X work to do? ;-)
[06:55] <rodarvus> bddebian, as everyone else, I have various tasks ongoing. (including X)
[06:55] <pitti> rodarvus: lart him, lart him! :)
[06:55] <bddebian> Gah, I was joking
[06:55] <dholbach> bddebian: you do some X merges!
[06:55] <pitti> bddebian: me too, saw the smiley? :)
[06:55] <doko> iwj: thanks
[06:55] <bddebian> dholbach: I'd love to
[06:56] <rodarvus> bddebian, don't worry :)
[07:07] <doko> iwj: added a background section, left in your review comment. please remove it if you think it's understandable
[07:08] <doko> iwj: I'm away for today, dholbach has my phone number if needed
[07:13] <Kamion> heno: DVD requirement> at present larger-livefs only envisages adding language packs to the DVD filesystem; if extra content is to be added as well then that just needs to be noted as well, that's all
[07:14] <wasabi_> There a good reason why linux-image-2.6.17-4 isn't builidng an initramfs?
[07:14] <heno> Kamion: ok, did that. I added a speech synthesis language file use case as well ;)
[07:28] <pitti> mdz: I have prepared and tested the new cupsys package for dapper-updates now; it also includes some fixes from upstream svn that are in the forthcoming 1.2.2; they are already in edgy, but I didn't send you the changelog for them; are these okay for you? http://paste.ubuntu-nl.org/17361 
[07:32] <mdz> rodarvus: I'm pretty swamped right now and trying to focus on approvals + email
[07:33] <mdz> rodarvus: better to have someone else review them and I'll verify when they get to approval
[07:33] <rodarvus> mdz, ok, I'll do that - thanks!
[07:39] <heno> Kamion: I've resolved the outstanding issues in EdgyContent
[07:39] <rodarvus> Kamion, ping
[07:50] <Riddell> Kamion: commend addressed on kubuntu-file-transfer-dialogue
[07:51] <wasabi_> Nice. 2.6.17 panic on boot. Hmm.
[07:54] <mdz> doko: is https://wiki.ubuntu.com/OpenOfficeL10n still relevant?
[07:56] <jdub> (yay, in edgy i can remove tcl/tk!)
[07:56] <tseng> jdub: blasphemy
[07:57] <bddebian> heh
[08:10] <mako> jdub: hola
[08:12] <jdub> mako: hey - where is your voting software kept?
[08:21] <mako> jdub: http://rubyvote.rubyforge.org/
[08:21] <mako> jdub: i guess i never put that on my homepage
[08:22] <jdub> mako: thanks!
[08:22] <mako> jdub: not sure what you're looking for but it ships with a test script that should make it clear how to use it to compute a vote
[08:23] <jdub> mako: do you know of (fully baked with ui) anonymous election systems that do preferential voting for named positions?
[08:23] <jdub> forgot that yours was a lib :)
[08:24] <pygi> sivang, poke? :)
[08:25] <mako> jdub: when do you need it?
[08:26] <mako> jdub: i have a prior date with someone to write a rails frontend to this in two days :)
[08:26] <jdub> mako: novemberish ;)
[08:26] <jdub> ha ha
[08:27] <mako> what do you mean by anonymous?
[08:28] <jdub> anonymous voting
[08:28] <mako> our plan was to have it do either authentication over XML-RPC or against database built with a simple sort of username:password list
[08:29] <mako> jdub: yeah, this would probably work for you
[08:29] <jdub> (voters should be verified, but disassociated from their votes)
[08:29] <mako> even to the administrator?
[08:30] <mako> it's possible
[08:30] <jdub> ideally
[08:31] <mako> jdub: i'll blog it when it's done
[08:31] <jdub> rad, thanks :)
[08:32] <mako> jdub: i know spi has used a php based system but it pure condorcet and doesn't have a lot flexibility
[08:42] <pitti> seb128: are you fine with me doing the xsane merge? (it has your name on it right now)
[08:43] <pitti> seb128: I'd also take intltool from you
[08:45] <pitti> seb128: ... and gamin, if you want
[08:57] <pitti> seb128: since you seem to be offline, I guess it's safe for me to proceed until you return :)
[08:59] <sivang> re
[08:59] <Riddell> mdz: what do you mean by updated status for specifications?
[09:01] <sivang> pygi: I'm also here :)
[09:01] <pitti> hi ivoks 
[09:01] <ivoks> hi
[09:02] <pygi> sivang, specs status report?
[09:02] <pitti> ivoks: cups 1.2.1 + some upstream svn fixes from 1.2.2. is prepared for dapper
[09:02] <ivoks> pitti: nice
[09:02] <pitti> ivoks: I'm just waiting for mdz's ack to the 1.2.2 fixes, then I'm ready to go
[09:02] <mdz> Riddell: the implementation status
[09:02] <ivoks> pitti: ok, i'll prepare gutenprint
[09:02] <sivang> pygi: no yet, need to work on the other one to make sure it's approved, will talk to you later okay ?
[09:02] <mdz> Riddell: i.e., which are started and which are not
[09:02] <pitti> ivoks: that would rock
[09:02] <pygi> sivang, sure :)
[09:02] <ivoks> pitti: i allready have is somewhere, but i have to find it :)
[09:03] <ivoks> s/is/it
[09:03] <Riddell> mdz: right
[09:03] <mdz> Riddell: I've asked for a "Not Started" status, but use Unknown meanwhile
[09:04] <sivang> mdz: home-user-backup could be go to go now, I've merged all your comments, and it can go another round of review now, setting it up to review in LP.
[09:04] <ivoks> pitti: is there something specialy new in 1.2.2 fixes?
[09:05] <mdz> Burgwork: ubuntu-art-wacom-documentation (art?) is up for review, but it only links to an email which doesn't contain enough information to provide any feedback
[09:05] <ivoks> pitti: something that i should watch out for?
[09:05] <mdz> Burgwork: a proper spec should describe the work to be done (e.g., what tasks the documentation should allow the user to complete, links to the old documentation, etc.)
[09:08] <Burgwork> mdz, just got that, will do\
[09:08] <seb128> pitti: I was having diner, feel free to do them :)
[09:09] <pitti> ivoks: no, just bug fixes (but by reading them I was reminded of some bugs we have)
[09:09] <pitti> ivoks: http://paste.ubuntu-nl.org/17361 
[09:09] <ivoks> pitti: thanks
[09:09] <pitti> seb128: already at it :) (merged gamin, requested intltool sync, merging xsane now)
[09:10] <pitti> seb128: I can take inkscape and libgnomeprint, too, but the rest of your's is too gnomeish for me
[09:16] <jdub> hrm
[09:16] <jdub> on edgy
[09:16] <jdub> Failed to fetch http://people.ubuntu.com/~jdub/edgy/./Packages.gz  404 Not Found
[09:16] <jdub> Packages.bz2 exists there though
[09:16] <bddebian> Damn, all my merges are turning into syncs.. Sheesh :-)
[09:17] <sladen> bddebian: that's good
[09:18] <bddebian> Well and now I am getting reply's back from DD's that they are adding in my changes too so they can be synced next go round... :-)
[09:19] <sladen> bddebian: this sounds like the grand scheme is starting to work
[09:19] <sivang> does anybody know what would be the fastest call to get the modification time of a file? 
[09:22] <seb128> pitti: I can do libgnomeprint*
[09:22] <seb128> pitti: if you didn't start on it, other way feel free to do them
[09:22] <bddebian> sladen: Well in Dapper I got a lot of "huh, what" responses from DDs :)
[09:24] <mdz> jdub: works for me
[09:24] <mdz> jdub: -rw-r--r-- 1 root root 2994 2006-07-06 12:13 /var/lib/apt/lists/people.ubuntu.com_%7ejdub_edgy_Packages
[09:25] <mdz> jdub: deb http://people.ubuntu.com/~jdub/edgy /
[09:25] <jdub> mdz: 0.6.44.2ubuntu?
[09:25] <mdz> jdub: no, not yet
[09:25] <mdz> that was uninstalling the world last I checked
[09:25] <jdub> ahr :)
[09:26] <jdub> btw, what's a sane way of using an ssh key with ssh:// ?
[09:26] <elmo> how do I tell where a gnome app is hiding it's data?
[09:26] <elmo> short of strace
[09:26] <Zdra> seb128: If you have time I reported a crash for evolution: http://bugzilla.gnome.org/show_bug.cgi?id=346740
[09:26] <mdz> jdub: ~root/.ssh/config I suppose
[09:26] <elmo> specifically, ekiga and it's addressbook
[09:26] <jdub> mdz: *boh* not entirely sane,but... ;)
[09:26] <Ubugtu> Gnome bug 346740 in Mailer "crash when sending gpg signed email" [Critical,Unconfirmed]  
[09:26] <jdub> elmo: .gnome2/ekiga maybe?
[09:26] <sivang> hmm , Keybuk is not here ?
[09:27] <mdz> jdub: works fine for me after upgrading as well
[09:27] <elmo> jdub: nope
[09:27] <mdz> jdub: there's nothing insane about .ssh/config
[09:27] <dholbach> Zdra: upstream is aware of the problem and i suppose they're working on it
[09:27] <seb128> Zdra: I've some hundreds bugs waiting, any reason I should give a priority to that one? :)
[09:27] <jdub> mdz: yeah - thought you meant putting the keys there for a moment
[09:27] <dholbach> elmo: isn't it using evolution's adress book?
[09:28] <elmo> dholbach: I've no idea
[09:28] <Zdra> seb128: no :p
[09:28] <mdz> elmo: I rm -rf'd it once but can't remember where it was
[09:28] <mdz> jdub: maybe your sources.list line is wrong
[09:28] <dholbach> elmo: looking at its depends: libebook1.2-5 (>= 1.6.1), libedataserver1.2-7 - seems like it's evolution's
[09:28] <jdub> mdz: apart from the / -> ./, no - and it was fine earlier today
[09:29] <seb128> dholbach: what?
[09:29] <mdz> elmo: ah, looks like it's all in gconf
[09:29] <dholbach> elmo: which would be in .evolution/addressbook
[09:29] <elmo> aiee!
[09:29] <elmo> evolution is importing all my mail
[09:29] <dholbach> seb128: ekiga's addressbook
[09:29] <mdz> jdub: the . is unnecessary
[09:29] <mdz> and confusing
[09:29] <seb128> ah, it uses e-d-s afaik
[09:29] <elmo> no no no no no, BAD evolution.  that 2GB is not yours
[09:29] <elmo> and the cancel button only cancels each individual folder it's oimporting.  wah.
[09:30] <bddebian> Heya Keybuk
[09:30] <bddebian> Keybuk: Stop closing my sync requests and stealing my karma.. ;-P
[09:30] <jdub> mdz: yeah, i removed it after seeing the difference, but still no love.
[09:30] <mdz> jdub: proxy?
[09:30] <jdub> mdz: nup
[09:31] <mdz> jdub: (that you know of)
[09:31] <elmo> seb128: is there anyway to check that doesn't involve running evolution?
[09:31] <elmo> oh, well rm -fr .evolution should work
[09:31] <jdub> mdz: see the output - 404 on the gz (which indeed is not there)
[09:31] <Keybuk> bddebian: huh?
[09:31] <Keybuk> bddebian: I can ignore all of your sync requests if you like ... :p
[09:31] <bddebian> Keybuk: Doh...
[09:32] <seb128> elmo: install contacts ?
[09:32] <mdz> jdub: opinion on menu placement for https://wiki.ubuntu.com/HomeUserBackup ?
[09:32] <dredg> why discriminate? ignore all sync requests!
[09:32] <bddebian> w00t
[09:33] <elmo> seb128: ah, thanks, that looks useful
[09:33] <seb128> np
[09:33] <elmo> so - next question, if I want to provide people data in a form they can pump into e-d-s, how do I do that?
[09:34] <bddebian> Keybuk: Well I'm stacking you up some more so I guess I'll shut up :-)
[09:34] <seb128> send some csv or vcf?
[09:34] <jdub> mdz: seems sane to me (i think we moved too many "apps" into system > administration)
[09:34] <elmo> seb128: there's a csv import option?
[09:35] <jdub> elmo: in evo, yeah.
[09:35] <seb128> elmo: from evolution yep
[09:35] <dholbach> elmo: don't hit me, but ldap seems to be still the best solution, not sure, if there's "subscribe to a url of a vcf" (if you want to be able to change it every now and then)
[09:35] <elmo> whine
[09:36] <jdub> elmo: thanks for mentioning this
[09:36] <sivang> Keybuk: Hey, I am trying to address your comments on system-clean-up-tool, however, I have partial answers to some of the issues, there are more complete answers from mvo on this, specifically, about being able to differentiate an upgrade installed kernel vs. dpkg -i one.
[09:36] <dholbach> elmo: (one time vcf import should work fine though)
[09:36] <sivang> Keybuk: also, I did understand what you were having issues with another question regarding that feature 
[09:37] <sivang> Keybuk:     1. The new kernel that was just installed.
[09:37] <sivang>      ''ScottJamesRemnant: this seems a bad time to mark the currently running kernel?  Why?''
[09:38] <Keybuk> sivang: perhaps you need to explain why what you're using the current kernel for
[09:39] <mdz> seb128: evolution upgrade seems to break the panel icon (evolution-2.6.png is gone)
[09:40] <sivang> Keybuk: ah, k, I'll try clarifiying this some more.
[09:40] <seb128> mdz: was that the stock icon or one you added?
[09:40] <mdz> seb128: it was the stock icon afaik
[09:40] <seb128> mdz: pitti already told that today, but it's supposed to use the non-versioned icon
[09:40] <seb128> since when do you have your profile?
[09:40] <seb128> dapper or before?
[09:41] <mdz> seb128: since warty
[09:41] <mdz> though I may not have had the evo icon the whole time
[09:41] <mdz> I probably dragged it from the menu at some point
[09:41] <seb128> ok, so that's probably the issue
[09:41] <seb128> you dragged a version variant
[09:41] <bddebian> Grr I hate trails of broken depends..
[09:41] <seb128> it's non-versionned since dapper
[09:42] <seb128> we will probably have to add a compatibility 2.6 symlink for it 
[09:42] <mdz> seb128: the current icon is versioned also
[09:42] <seb128> the menu one is, the panel one should be evolution-mail.desktop
[09:42] <kbyrd> I guess I'll come out of lurk mode. I've got an inetd and etc/services question.
[09:43] <mdz> Keybuk: when you approve a spec, don't forget to target it for edgy (unless there's some reason not to)
[09:44] <Keybuk> mdz: did I forget one?
[09:44] <Keybuk> I usually do
[09:45] <mdz> Keybuk: edgyplusone-toolchain-roadmap
[09:45] <Keybuk> hmm, I just did that one
[09:45] <Keybuk> oh, right, yeah, I deliberately didn't target that one
[09:45] <mdz> it's not on https://launchpad.net/distros/ubuntu/edgy/+specs
[09:45] <Keybuk> because it says "edgy plus one" :p
[09:45] <kbyrd> Would it be horrible if my package depended on inetd and conflicted with xinetd?
[09:45] <mdz> Keybuk: the idea is that the work gets done duringso that it can land immediately in edgy+1
[09:45] <mdz> s/duringso/during edgy so/
[09:46] <mdz> it won't be due by feature freeze, but should be on the edgy radar
[09:46] <mdz> (I've targeted it)
[09:46] <Keybuk> ah, fair enough
[09:46] <Keybuk> I vaguely misinterpreted "Release Goal" then :p
[09:48] <rodarvus> Keybuk, (asking to you since you were the person who reviewed it) ogra, sbalneav and I updated the spec fully-automatic-swap-server earlier today - do you think you'll have time to review it again before the meeting?
[09:48] <pygi> sivang, uh, forgot to tell you about libburn stuff :(
[09:48] <Keybuk> rodarvus: given the meeting is in 10 minutes time, no :p
[09:49] <Keybuk> I'll have a quick skim
[09:49] <rodarvus> wow, its *late* :)
[09:49] <ogra> pygi, gah, that was for sivang ? i could have told him if i had known 
[09:49] <rodarvus> I didn't noticed the current time :)
[09:49] <pygi> ogra, yea, we need that for HUB :P
[09:51] <pygi> mdz, poke?
[09:51] <mdz> pygi: yes?
[09:51] <pygi> your comment on HUB is adressed
[09:52] <sladen> kbyrd: what is your package doing?
[09:52] <mdz> pygi: oh, there is a python API for libburn? I didn't realize
[09:53] <mdz> we should package it
[09:53] <mdz> and that should go in the spec, since it's a prerequisite for using it
[09:53] <pygi> mdz, pyburn
[09:53] <pygi> mdz, ok, will address that as well
[09:53] <mdz> pygi: set to pending approval when you're finished
[09:54] <sivang> pygi: yay, thank
[09:54] <pygi> sivang, :)
[09:55] <pygi> sivang, do we have KDE UI in spec for edgy or is it edgy+1?
[09:56] <pygi_> sivang, sorry, ISP
[09:56] <pygi_> do we have a KDE UI in scope for edgy?
[09:57] <pitti> seb128: ok, then I just take inkscape (I didn't start libgnomeprint yet)
[09:57] <pitti> seb128: and since it'll interact with gtk 2.10 anyway, I leave it in your capable hands then
[09:57] <seb128> k
[09:59] <pygi> sivang, you still alive? :)
[10:00] <sivang> pygi: yeah, #u-m
[10:01] <pygi> sivang, just please set spec to pending approval
[10:01] <pygi> all mdz's comments are addressed now
[10:02] <kbyrd> sladen. It's VMware VirtualServer, it's a soon to be release free version of what used to be called VMware GSX.
[10:03] <kbyrd> Yea, that was a copy pasto. Official product name is VMwareServer, not VirutalServer.
[10:04] <rodarvus> Keybuk, thanks a lot for reviewing the spec!
[10:04] <sladen> kbyrd: does  update-inetd --add/remove  do what you need?
[10:05] <sladen> kbyrd: you should be able to call them from postinst and prerm to add and remove your entries
[10:05] <pygi> iwj, poke? :)
[10:05] <iwj> Hello.  I'm in the distro meeting atm.  Can it wait an hour ?
[10:05] <pygi> oki
[10:06] <kbyrd> sladen: update-inetd adds the line to inetd.conf and restarts it. That's all fine. But, if the user has xinetd installed instead, they get some instruction that they need to convert inetd.conf to xinet.d format manually. 
[10:06] <kbyrd> sladen: my inetd.conf line doesn't use a service name, it uses 902 explicitly. inetd is ok with this, xinetd is not (by default). I'm wondering if it's ok to just depend on inetd.
[10:06] <kbyrd> sladen: and not "inetd | xinetd"
[10:09] <sladen> kbyrd: xinetd wants an entry in /etc/services?
[10:11] <kbyrd> sladen: it seems so. Looking at debug output it looks up the service by name. There's an option I can use in the config file that looks like it'll not do that. But I would be relying on users to know that and do it themselves based on the warning about xinetd update-inetd generates.
[10:11] <kbyrd> sladen: I'm wondering if I can just depend on inetd and be done with it.
[10:11] <kbyrd> s/just depend on/depend just on/
[10:13] <sladen> kbyrd: might be the easiest way of getting away with it, the other is to get /etc/services updated with your port-number.  However, since that's below 1024 I don't know whether that'll wash
[10:14] <kbyrd> sladen: Right, I wouldn't be here asking if I thought I had a chance of getting a <1024 port added.
[10:16] <kbyrd> sladen: it loos like I should do depends on inetd and conflicts with xinetd. xinetd does this "/etc/init.d/inetd" redirection thing
[10:17] <sladen> kbyrd: go for it, if anyone has a better solution, I'm sure they'll complain and let you know :)
[10:18] <kbyrd> sladen: thanks. I was kind of hoping someone would pipe up with something like: "no theres this "foo-baz-update script that will do both xinetd and inetd updating. 
[10:41] <pitti> seb128: control-center merge will fall under the general gnome 2.15 upgrade wave, I assume? c-c merge is currently infinity's
[10:42] <seb128> pitti: yeah, anything GNOMEish will be merge during 2.15.3 or 2.15.4 updates this week or next week
[10:42] <pitti> ogra: nessus-plugins was already synced
[10:44] <pitti> ogra: oh, good to know that you claim kino, it was already on my list of things to grab from Adam
[10:46] <pitti> Mithrandir: ah, let's coordinate merge-wise then; today I noticed that we two merged bcel and cup at the same time
[10:48] <Mithrandir> pitti: given that I merged bcel and cup two days ago, that'd be special.
[10:48] <pitti> Mithrandir: oh, hm, then main.html lagged behind that amount of time
[10:48] <pitti> Mithrandir: anyway, I'll ping you when I do stuff from Adam or Charles, ok?
[10:49] <Mithrandir> pitti: excellent.
[10:49] <pitti> (unless you want to do them all on your own, that is :) )
[10:49] <pitti> it's not that I'm bored, but we need to get it behind us soon
[10:50] <Mithrandir> pitti: I've mostly moved on to X crack now, but we should coordinate better, agreed.  Ideally, we should have a way of grabbing merges.
[10:51] <bddebian> Is something hosing up libxft-dev?
[10:51] <pitti> Mithrandir: I'm fine with doing all of Charles' -java stuff; it's boring, but it's trivial, just takes time
[10:51] <pitti> Mithrandir: if you want to turn your attention to X instead (which seems more important to me)
[10:51] <Mithrandir> pitti: ok, please.
[10:51] <crimsun> bddebian: yes, libxrender. Btw, it's src:xft now.
[10:52] <crimsun> bddebian: I interpret "hosing up" to mean "holding up".
[10:53] <bddebian> crimsun: Aye.  So it's been replaced or it's just held up?
[10:53] <crimsun> bddebian: libxrender hasn't completed the transition yet.
[10:55] <gnomefreak> crimsun: while we are on libxrender something i was asked earlier gimmie looks for libxrender.la but its no where in ubuntu and not in libxrender-dev where i thought it would be
[10:56] <bddebian> Well get on it damnit ;-)
[10:56] <gnomefreak> libxrender.a was the only thing close in the -dev package
[10:56] <bddebian> gnomefreak: Probably the same issue I had last week.  Something else is bringing that in
[10:57] <gnomefreak> is this a left out lib or just something that was never added?
[10:58] <bddebian> gnomefreak: In my case it was libwnck-1.la that was brought in from devhelp.
[10:58] <crimsun> gnomefreak: that's correct, it's not supposed to ship .la anymore.
[10:58] <gnomefreak> oh ok ill count that as gimmie hasnt been updated than ty
[10:59] <dholbach> gnomefreak: gimmie?
[10:59] <bddebian> gnomefreak: You can try to figure it out by grepping the source tree to see what is looking for libxrender.la
[10:59] <gnomefreak> dholbach: gimmie is some crap like panels (not sure never used it)
[10:59] <tseng> hah
[10:59] <dholbach> i looked into packaging it and it's nearly ready
[11:00] <dholbach> but i'm waiting for upstream to fix their install target
[11:00] <gnomefreak> dholbach: that would be nice since ive had alot of people asking for it
[11:00] <dholbach> gnomefreak: i know
[11:00] <dholbach> install:
[11:00] <dholbach>         @echo
[11:00] <dholbach>         @echo "Gimmie isn't ready to be installed yet!"
[11:00] <dholbach>         @echo "Just run ./gimmie.py for now."
[11:00] <dholbach>         @echo
[11:00] <dholbach> in ./gimmie/Makefile.am
[11:00] <Amaranth> lmao
[11:00] <dholbach> that's problem
[11:01] <gnomefreak> ah
[11:01] <bddebian> heh
[11:01] <dholbach> if that doesn't get fixed we don't get a package :)
[11:01] <tseng> you could call cp and then dh_install
[11:01] <gnomefreak> im assuming its nto gonna be in edgy maybe edgy+1
[11:02] <dholbach> tseng: assuming that everthing does *not* depend on static paths and stuff (same for import xyz (python modules)) :)
[11:02] <tseng> dholbach: hah :)
[11:07] <Mithrandir> mdz: could you look at https://launchpad.net/distros/ubuntu/+spec/cd-packet-writing now?
[11:08] <jdub> tseng: hrm, no libbeagle-dev?
[11:09] <jdub> libbeagle0 is described as "development files"
[11:09] <jdub> but it is not :)
[11:09] <LaserJock> mdz: in Paris somebody had talked about getting doc team reports at the distro meetings, is that correct?
[11:13] <Mithrandir> mdz: also, https://launchpad.net/distros/ubuntu/+spec/live-cd-share-live-cd should be review- and approvable now, I think.
[11:16] <mdz> Mithrandir: I'm having a couple of other conversations at the moment, but I will, yes
[11:17] <mdz> LaserJock: I remember discussing artwork updates, and probably doc as well, yes
[11:17] <mdz> LaserJock: are you volunteering to liase?
[11:18] <Mithrandir> ogra: live-cd-share-this-live-cd was demoted to priority low now so I think you'll have to get some volunteers to help out if it's going to really happen.
[11:18] <mdz> Mithrandir: I'm pretty sure it needs to be copied; tftpd shouldn't follow symlinks (in fact it should chroot itself)
[11:19] <ogra> Mithrandir, i think i can find some 
[11:19] <jdub> mdz: your opinion on fuse in general - good or bad?
[11:19] <Mithrandir> mdz: tftpd-hpa can be told to do either, IIRC.
[11:19] <ogra> Mithrandir, but i think your second usecase is rather utopic
[11:20] <ogra> you wont be able to run *a bunch* of thin clients that way ... access times of the drive are to slow
[11:20] <LaserJock> mdz: I can't for all meetings, but I could write up a note for the ones I can't make I suppose
[11:20] <ogra> (unless the server is fat enough to cache everything)
[11:20] <LaserJock> mdz: more or less a quick note on the doc teams progress?
[11:21] <mdz> LaserJock: what's happened in the past week, what's planned for the next week, with a particular focus on edgy targets
[11:21] <Mithrandir> ogra: 1G of memory isn't very expensive those days.
[11:21] <Mithrandir> ogra: but maybe it is; *shrug*
[11:21] <pygi> Mithrandir, 115$ I would say
[11:22] <pygi> or less
[11:22] <ogra> Mithrandir, we have a default of 256MB for an edubuntu server with additional 128MB per client ...
[11:22] <sivang> pygi: libburn doesn't have a debian package yet?
[11:22] <ogra> so with 1G you can run 6 clients *without* space for caching ...
[11:23] <pygi> sivang, I think it doesnt
[11:23] <pygi> lemme check
[11:23] <LaserJock> mdz: ok
[11:23] <pygi> sivang, libburn does, pyburn (python bindings) don't
[11:23] <ogra> if that thing caches 512MB you are left with 2 clients ...
[11:24] <mdz> Mithrandir: cd-packet-writing is fairly open-ended; could you do some investigation and see which of the open questions under Scope are necessary?
[11:24] <ogra> its a good thing to demo ltsp, but i dont think it can be a full time solution
[11:24] <pygi> sivang, have you changed to pending approval and notified mdz?
[11:25] <mdz> pygi: yes
[11:25] <mdz> pygi: you can see that in LP
[11:25] <pygi> oki :)
[11:26] <ogra> Mithrandir, i'll do some tests with sshed sessions to a livecd next week so i can get some real impression ...
[11:27] <Mithrandir> mdz: willdo
[11:27] <mdz> ogra: s-c-p-p whiteboard says comments inline, but there are no comments and it's still in drafting
[11:28] <ogra> mdz, oh, sorry i'll change status ...
[11:28] <ogra> fixed
[11:31] <mdz> sivang: you set make-free-space-wizard to pending approval instead of back to review. why?
[11:37] <sivang> mdz: by mistake sorry, I am supposed to set to pending approval only after reciving informal approval from the approver or only he's supposed to do that?
[11:37] <mdz> sivang: a reviewer sets it to pending approval after it has been reviewed
[11:37] <Kamion> sivang: you set it to review
[11:39] <sivang> Kamion, mdz : noted, I'll set both of my specs to review then. (I also set h-u-b for pending approval)
[11:39] <mdz> sivang: I already reviewed and approved h-u-b
[11:40] <pygi> thanks mdz :)
[11:41] <sivang> mdz: I just saw that, thank you mucho
[11:42] <tseng> jdub: hm?
[11:42] <tseng> jdub: its called beagle-dev
[11:42] <tseng> jdub: and yes, I know
[11:43] <Mithrandir> mdz: fixed the scope bit after testing a little bit with packet writing here.
[11:47] <mdz> Mithrandir: better, thanks
[11:48] <mdz> Mithrandir: presumably the existing hook for erasing cd-rw media could be used for the formatting
[11:48] <Mithrandir> mdz: good point.
[11:50] <mdz> ogra: doesn't ltsp have an existing info daemon?
[11:50] <ogra> mdz, ltsp-org has
[11:50] <mdz> ogra: right, wouldn't it be better to use that?
[11:50] <mdz> oh, wait, that one runs on the client, doesn't it
[11:50] <mdz> even so
[11:51] <ogra> well, it would also still need the extensions for ldm (assuming youre on that atm)
[11:51] <mdz> I'm on login and session handling
[11:51] <ogra> i dont think it provides either of the info we need there
[11:51] <mdz> yes, but it already exists, is tested, works and provides a network service for retrieving information
[11:51] <ogra> (neither languses nor installed X session)
[11:51] <mdz> no need to reinvent the wheel
[11:51] <ogra> *languages
[11:52] <ogra> ok, i'll change the spec so it uses ltspinfod
[11:53] <ogra> (i'm pretty sure it can run either on the server or on the client, its just an inetd started daemon)
[11:55] <mdz> Mithrandir: hmm, just saw the Opera announcement in LWN...I suppose we should get that into dapper-updates
[11:56] <Mithrandir> mdz: can you investigate where the upload went?
[11:57] <Mithrandir> or, you could grab the source from http://people.ubuntu.com/~tfheen/opera/ and upload that to dapper-updates then do the third-party-packages dance.
[11:57] <mdz> Mithrandir: looking
[11:58] <mdz> Mithrandir: version '3'?
[11:58] <Mithrandir> mdz: ? opera_9.00-20060616.7 is the version.
[11:58] <mdz> oh, I was looking for app-install-data-commercial
[11:59] <Mithrandir> oh, sorry, I haven't touched that since there'd be no way for me to test it until the package was in an archive.
[11:59] <mdz> I have no idea how the commercial repository works
[12:00] <mdz> Mithrandir: to what queue did you upload it?