[12:11] <Riddell> packager wanted http://www.kde-look.org/content/show.php?content=29207
[12:11] <Riddell> ascii KDE screensaver thing
[12:13] <chmj> Riddell: can I, will use it to teach viviersf a few things 
[12:14] <Riddell> chmj: viviersf?
[12:15] <Riddell> chmj: wold be cool if you got it packaged, the developer said he's had people want it for kubuntu
[12:15] <chmj> viviersf = Cain_SA = francis
[12:16] <chmj> ok, will do
[12:16] <Riddell> chmj: ah yes.  great
[12:17] <chmj> viviersf: say HI to your new toy :-) 
[12:18] <viviersf> huh
[12:18] <viviersf> the screensaver ?
[12:18] <chmj> yes, for packaging 
[12:19] <viviersf> haha
[12:19] <viviersf> :)
[12:19] <viviersf> Riddell, changed my nick, should be easier for people to know who i am
[12:19] <viviersf> becoz CaiN is registered to some1 else
[12:20] <viviersf> chmj, will be kewl
[12:20] <viviersf> thx
[12:41] <Riddell> now cain_ and viviersf ?
[12:41] <Riddell> hello claydoh 
[12:41] <cain_> lol
[12:41] <cain_> rofl wait
[12:41] <claydoh> hello Riddell 
[12:42] <viviersf> better ?
[12:44] <Tonio_> Riddell: need a package for this ?
[12:44] <Riddell> Tonio_: not for the screensaver, viviersf is doing that
[12:44] <Tonio_> k
[12:45] <viviersf> ya
[12:45] <viviersf> so that i can become a motu 
[12:45] <Tonio_> I missed yesterday's meeting.....
[12:45] <viviersf> i also want to look smart 
[12:45] <viviersf> hehe
[12:45] <Riddell> Tonio_: are you a member?
[12:46] <Tonio_> Riddell: not yet....
[12:46] <Tonio_> I missed the last to meetings, lacking informations on the date
[12:46] <Riddell> Tonio_: isn't there a CC meeting today?  you could go for membership there
[12:46] <Tonio_> really ?
[12:46] <Tonio_> well, isn't a wiki page needed first ?
[12:46] <Tonio_> I didn't do it :)
[12:47] <Riddell> Tonio_: make one make one!
[12:47] <Tonio_> Riddell: is there any page that explains the different requirements to become a member ?
[12:47] <Riddell> I don't know if there is a meeting but someone on #ubuntu-meeting said there was one in an hou (and that was 45 minutes ago)
[12:48] <Tonio_> last time I could introduce because there was a problem, I  think with agenda
[12:48] <Riddell> Tonio_: any sustained and useful contribution
[12:48] <Tonio_> can I had what I did with adept's icons and the kubuntu usplash too ?
[12:48] <Tonio_> I think only packages have some interesst
[12:49] <Riddell> http://www.ubuntu.com/community/community/processes/newmember
[12:49] <Riddell> Tonio_: certainly can
[12:49] <Tonio_> I'll do it right now, and calmy wait for the next CC
[12:49] <Riddell> Tonio_: and kubuntu-girl :)
[12:49] <Tonio_> there is no emergency ;)
[12:49] <Tonio_> Riddell: haha ;)
[12:50] <Tonio_> ho Riddell  I saw your slideshow
[12:50] <Tonio_> what a troll !!!!!!!!! in front of 90% gnome gurus !!! I'm really impressed !!
[12:50] <Riddell> how did I troll?
[12:50] <Riddell> hello jubei 
[12:50] <Tonio_> not a troll to my view, but :
[12:51] <Tonio_> http://kubuntu.org/~jr/kubuntu-below-zero/html/slide_3.html
[12:51] <Tonio_> this, in front of so many gnome fans, waw !!!
[12:52] <Riddell> that's a reasoned argument, all very well behaved
[12:53] <viviersf> lol
[12:53] <Tonio_> note that I agree with you, I defenitly love kde better than anything else, but I thought that in front of gnome fans that could be seen like a kind of joke, or gentle provocation ;)
[12:53] <Tonio_> Riddell: sorry for the confusion
[12:53] <viviersf> atleast Riddell has some fans of kde here supporting him
[12:53] <Tonio_> viviersf: I am
[12:54] <Tonio_> my personnal ethiq is to NEVER package a gnome application ^^
[12:54] <viviersf> haha
[12:54] <Tonio_> and I never did at least for the moment
[12:54] <viviersf> well Tonio_ 
[12:54] <viviersf> kde isnt superior to gnome
[12:54] <viviersf> and gnome isnt superior to kde
[12:55] <viviersf> its just a matter of which you prefer
[12:55] <Tonio_> to my view his architecture is superior
[12:55] <viviersf> and does what you want it to do
[12:55] <Tonio_> but about the rendering and the fealing, that's of course personnam
[12:55] <Tonio_> personal
[12:56] <Tonio_> damn, my english is awfull today.....
[12:57] <Tonio_> Riddell: personal question, are you living in quebec actually ? cause I can see you're making efforts on your french actually ;)
[12:57] <viviersf> rofl
[01:01] <Riddell> Tonio_: non, j'habite a edibourg
[01:02] <Riddell> and these quebequois are so good at knowing if you are francophone or anglophone before speaking that I don't usually get much chance to speak french
[01:03] <Tonio_> hehe
[01:04] <Tonio_> ho Riddell interested in the list of package I will soon upload (when kdelibs4-dev will install) ??
[01:04] <Riddell> Tonio_: yes, put it on wiki page along with packages uploaded and in rev
[01:05] <Tonio_> okay, I will add them as "in progress" so
[01:06] <Riddell> Tonio_: do you have a launchpad account?
[01:07] <Tonio_> yep
[01:08] <Tonio_> Riddell: I think it is in your plans right ?
[01:09] <Riddell> Tonio_: https://wiki.ubuntu.com/KubuntuTranslations
[01:09] <Riddell> spec in progress
[01:10] <Tonio_> nice
[01:10] <Tonio_> I may contribute a lot to that when available
[02:10] <Riddell> Tonio_: no membership requests at he meeting today
[02:11] <Tonio_> Riddell: that's fine. no fire arround, I can wait ;)
[02:39] <Riddell> sebas, Sime: is there any way we can make this more explicit? https://wiki.ubuntu.com/KubuntuSystemTools
[02:40] <Riddell> can we create goals of things to acheve for dapper?
[02:40] <Riddell> hmm, late in europe I suppose
[03:15] <Riddell> seth_k|lappy: that amarok beastie should be PENDINGUPLOAD unil it's in the archives
[03:15] <seth_k|lappy> Riddell, ah, my bad. I didn't know it was going to go into the archives. I'll twiddle the bits
[03:16] <Riddell> of course it'll go in the archives, we won't hvae dapper with an old amarok :)
[03:16] <seth_k|lappy> oh, I thought you meant Breezy archives
[03:16] <seth_k|lappy> bah, school has fried my brain :)
[03:16] <Riddell> no, but the development relase is the one that matters for beastie fixes
[03:17] <seth_k|lappy> bug fixed, sorry about that
[03:19] <Riddell> https://launchpad.net/distros/ubuntu/+spec/kubuntu-roadmap-dapper  Approved!
[03:20] <Riddell> seth_k|lappy: don't worry, and thanks for tending to bestise, always very welcome
[03:23] <seth_k|lappy> Yeah, I hope to really focus on Kubuntu stuff for this dev cycle, it'll be the first full cycle I've been using KDE instead of Gnome
[03:23] <seth_k|lappy> switched a month or two after Hoary
[03:25] <seth_k|lappy> also Riddell, kmobiletools will be done Friday and barring any more comments, ready to go
[03:25] <seth_k|lappy> I've been using it for months so the remaining things are just polish; the package itself works fine
[03:26] <Riddell> seth_k|lappy: excellent :)
[03:38] <Tonio_> 'night everyone
[04:57] <seth_k> Hi Riddell, dholbach suggested that I did not need such explicit libqt3 build-deps. What should I use instead of:
[04:57] <seth_k> libqt3-headers (>=  3:3.3.3-7), libqt3-mt-dev (>= 3:3.3.3-8),  libqt3-mt (>= 3:3.3.3-8)
[04:58] <Riddell> just libqt3-mt-dev
[04:58] <seth_k> right, thank you
[05:21] <Riddell> hlloju
[05:22] <Riddell> hello jubei 
[05:24] <jubei> Hi Riddell 
[09:49] <Tonio_> mornin'
[02:19] <\sh> who packaged libvisual for the new amarok?
[02:25] <Tm_T> not me
[02:30] <\sh> Mez: new k3b version
[02:36] <Mez> I know :D
[02:56] <JRe> \sh: there are debian packages
[02:57] <JRe> \sh: unfortunately i think libvisual-plugins is broken
[02:58] <JRe> \sh: I know how to fix it if you're interrested
[03:47] <Riddell> JRe: I'm sure he would love that 
[03:48] <JRe> \sh: appart of from changing the version of libjack, you have to pass a flag to configure: specify the x include dir to /usr/includes/
[03:48] <\sh> JRe: context now? 
[03:48] <\sh> JRe: amarok, libvisual_
[03:48] <\sh> ?
[03:49] <JRe> \sh: libvisual_plugins
[03:49] <JRe> \sh: that's why he can't build
[03:49] <JRe> s/he/it/
[03:49] <\sh> JRe: u made the package, right? can u give me the url to the source packages?
[03:50] <JRe> \sh: I made the package but removed it because it has now an official debian maintainer
[03:50] <JRe> \sh: tough, the package libvisual_plugin does not build (see lamont buildlogs)
[03:51] <JRe> \sh: for having libvisual integrated into amarok, take also the latest amarok debian's package it have the fix i made
[03:51] <JRe> \sh: plus very good polish of dato ;)
[03:52] <JRe> \sh: http://packages.debian.org/changelogs/pool/main/a/amarok/amarok_1.3.5-1/changelog it's from 1.3.4-1
[03:53] <\sh> JRe: k
[03:54] <JRe> \sh: poke me if you have trouble with building libvisual_plugins
[04:09] <\sh> JRe: why the hell libvisual_plugins is using gcc/g++-3.4?
[04:10] <JRe> \sh: because of incompatibility with gcc4 IIRC
[04:10] <\sh> gcc/g++-3.4 will go away
[04:13] <Riddell> 3.4 is compatible with 4.0
[04:13] <Riddell> it's 3.3 that's not compatible
[04:16] <\sh> Riddell: yeah...but 3.4 will be demoted to universe
[04:16] <pef> Riddell: hello, I've synced gwenview, what's your opinion ? http://revu.tauware.de/details.py?upid=862
[04:17] <\sh> Riddell: so if u want libvisual_plugins in main ,) we need to fix it....
[04:17] <Riddell> pef: great thanks, I'll try and take a look
[04:17] <Riddell> busy day in KDE land today
[04:17] <pef> ok :)
[04:28] <jjesse> Riddell: did you ever apply the stylesheet i asked for :)
[04:30] <Riddell> jjesse: no, keep poking me please
[04:32] <Riddell> anyone know a package made with scons
[04:33] <jjesse> Riddell: will do :)
[04:33] <jjesse> btw nice motd on #kubuntu
[04:34] <Czessi> hi, i build this package yesterday with scons: http://ubuntu.czessi.net/pool/breezy/testing/kleansweep_0.2.0-0czessi2_i386.deb
[04:39] <\sh> why should we need libvisual-plugins...we have screensaver..
[04:39] <\sh> means...libvisual-plugins are evil
[04:47] <\sh> JRe: checking where to install plugins... /usr/lib/libvisual
[04:47] <\sh> configure: error: conditional "HAVE_LIB_GL" was never defined.
[04:48] <\sh> build-dep on libgl1-mesa-dev and libglu1-mesa-dev that is
[04:49] <JRe> \sh: buildep on x11-proto-gl
[04:49] <JRe> \sh: wait a sec I search the real name of the package
[04:49] <JRe> \sh: x11proto-gl-dev
[04:50] <\sh> i think i had it inside...
[04:50] <Lathiat> nah nah
[04:50] <Lathiat> you want libgl1-mesa-dev | libgl1-dev, libglu1-mesa-dev | libglu1-dev
[04:50] <Lathiat> might not need glu
[04:51] <Lathiat> mm i lied its | libgl-dev and | libglu-dev
[04:51] <\sh> Lathiat: we will pull in libgl1-mesa-dev and libglu1-mesa-dev .. debian the ORed ones...or the buildds will read the OR statement from right to left
[04:51] <JRe> Lathiat: those packages seem to not exists
[04:52] <Lathiat> JRe: they dont
[04:52] <Lathiat> their so something else can provide the build depend
[04:52] <Lathiat> debian compat etc
[04:52] <JRe> Lathiat: k
[04:53] <\sh> no ways to get this
[04:54] <JRe> \sh: when I tried it, putting x11proto-gl-dev in the builddeps was fine
[04:54] <Lathiat> JRe: and broken
[04:54] <Lathiat> JRe: x11proto-gl-dev will be pulled in by libgl1-mesa-dev
[04:55] <JRe> Lathiat: tes it replaces
[04:55] <\sh> JRe: i have now at least all *GL* build deps in debian/control ...
[04:55] <\sh> libvisual-plugins is b0rked
[04:55] <JRe> \sh: :)
[05:03] <\sh> JRe: how did u build it then on dapper?
[05:07] <JRe> \sh: never tried on dapper only with breezly
[05:07] <JRe> \sh: i can't make the dapper debootstrap
[05:10] <\sh> JRe: create a breezy pbuilder and after that, replace the breezy archives with dapper
[05:16] <\sh> Riddell: should we bring amarok-1.3.5 in, and fix this crappy visual stuff later...thinking about leaving libvisual-plugins in universe?
[06:18] <Riddell> Sime: about?
[06:19] <Tm_T> fucking annoying!
[06:20] <Tm_T> can't rip audioCD, drive keeps flashing led...
[06:20] <Riddell> DRM?
[06:20] <Tm_T> can't be
[06:20] <Riddell> or scratched CD
[06:20] <Tm_T> can't be
[06:21] <Tm_T> buyed today, looks like this is ~18years old cd
[06:22] <Tm_T> and why it keep spinning cd ?
[06:22] <Tm_T> there's not a sincle app tha should read the disc
[06:23] <Tm_T> at very first time I'm forced to say this: I hate KDE 3.5
[06:23] <Tm_T> maybe disabling "HAL backend" would help, maybe not
[06:24] <Riddell> if the disk can't be read that's nothing to do with KDE
[06:24] <Tm_T> err, I can play it
[06:24] <Tm_T> can't rip
[06:25] <Riddell> playing and reading are different, more error checking on reading
[06:25] <Tm_T> yu
[06:25] <Tm_T> have to try other cd's too
[06:26] <Tm_T> ok, how I find out what app keep reading cd
[06:26] <Tm_T> annoying
[06:31] <Tm_T> ok, ripping problems with beatles, ac/dc ...
[06:32] <Tm_T> hmm, maybe my cd/dvd drive is broken
[06:34] <Tm_T> anyway, annoying
[06:37] <Tm_T> hmh, can't rip who either, I did rip this albums just a month ago
[06:38] <Tm_T> oh and I can eject it only as root
[06:41] <Tm_T> there really is something wrong
[06:45] <Tm_T> I give up, have to find old cardiscman ->
[06:57] <Tm_T> ok, rebooted and checked bios ...
[06:58] <Tm_T> well, now it again auto-opens kscd and konqueror -> trying mount
[06:58] <Tm_T> funny in a way
[07:42] <jjesse> anyone know if there is a package for mod_ntlm w/ apache2?
[07:43] <jjesse> i couldn't find one by searching (either adept or using google)
[07:45] <Riddell> jjesse: I'm looking at KubuntuDocs and thinking that release notes should be split into the announcement and a quick guide
[07:45] <Riddell> http://help.ubuntu.com/quicktour/C/quicktour.html  this sort of thing is really cool
[07:46] <Riddell> pictures and soundbytes
[07:46] <Riddell> and then there's this http://kubuntu.org/announcements/breezy-release.php  which was based off the release notes but isn't quite the same
[07:46] <jjesse> yeah it is, you want one for kubuntu then?
[07:47] <Riddell> quick guide is so much more readable and grabs your attention
[07:48] <jjesse> you mean quicktour?
[07:48] <Riddell> yes
[07:49] <jjesse> i'll change KubuntuDocs
[07:49] <mornfall> adept *is* the frontend/backend split
[07:49] <Riddell> mornfall: \sh_away 
[07:49] <Riddell> mornfall: where is this?
[07:49] <mornfall> Riddell: KubuntuPackageManager2
[07:49] <Riddell> mornfall: can we talk with mvo now quickly?
[07:49] <mornfall> Riddell: yeah, why not
[07:49] <mornfall> quickly though :)
[07:49] <mornfall> i have exam to study for
[07:49] <Riddell> he needs lunch
[07:50] <mornfall> hmm, i could use a dinner :)
[07:50] <mornfall> can he give a rough time?
[07:50] <mornfall> i can appear for a talk at any reasonable time tonight
[07:50] <Riddell> hang on
[07:50] <mornfall> (reasonable is something before 2am :-))
[07:51] <Riddell> 16:50 our time
[07:51] <mornfall> zone? (gmt offset?)
[07:51] <Riddell> 5 hours time
[07:52] <mornfall> in 5 hours? that's 1am, well... okey then
[07:53] <mornfall> --> dinner now
[07:53] <Riddell> no, 3 hours time
[07:53] <Riddell> mvo says sorry for the miscalculation
[07:53] <mornfall> okey np
[07:53] <Riddell> cool
[07:53] <mornfall> 11pm for me
[07:55] <jjesse> Riddell: is there a package i can install that will give me mod_ntlm for apache2?
[07:59] <Sime> hey
[08:16] <Tonio_> re
[08:19] <Sime> is Ridell busy eating???
[08:21] <\sh> zepp
[08:21] <\sh> yepp
[08:22] <seth_k> Riddell, new kmobiletools upped, fixes dholbach's comments :)
[08:27] <Sime> will dapper ship with kernel 2.6.14 and FUSE?
[08:35] <Riddell> Sime: hi
[08:35] <Sime> Riddell: Hi, I'm writing up a sort of Guidance plan for the next few months.
[08:36] <Riddell> Sime: excellent
[08:37] <Riddell> Sime: you and/or sebas should definatly come to the next ubuntu conference
[08:38] <Riddell> I suspect this spec process seems quite harsh to those who havn't come to a conference, but it's a great process for getting the distro done
[08:38] <Sime> Riddell: is there a general ubuntu mailing list that I should be on?
[08:38] <Riddell> Sime: there's kubuntu-devel and kubuntu-users (which sebas is quite good at answering stuff on) 
[08:39] <Riddell> the synaptic, aptitude, dpkg and apt maintainers are all here too, need to get mornfall here for the next one
[08:39] <mornfall> where?
[08:40] <Riddell> ubuntu conference, montreal
[08:40] <mornfall> oh well
[08:40] <Riddell> the Smart developer too
[08:40] <mornfall> i'll be in a minority
[08:40] <mornfall> everyone's so python these days
[08:41] <Riddell> yeah, the Smart code is written in C but commented in Python
[08:42] <mornfall> i don't dig smart though
[08:43] <Riddell> I havn't seen it at all but those who have rave about it
[08:45] <mornfall> i don't see what it's got above apt, really... something significant i mean :)
[08:45] <mornfall> downgrades are not supported anyway (at least not within debian)
[08:45] <mornfall> and aptitude can solve those situations that smart claims noone else does :)
[08:45] <mornfall> well, at least it looks like it to me
[08:45] <mornfall> i haven't researched it in detail
[08:46] <Riddell> lets get mvo to explain it to us later, he seems to like it
[08:49] <mornfall> okey, why not :)
[09:09] <Sime> Riddell: ok, you should have mail now.
[09:10] <Riddell> excellent, thanks, very useful
[09:20] <jjesse> need to get me for docs at the next one as well :)
[09:20] <Sime> Riddell: what would also be handy is a list of which configuration utils are still needed.
[09:21] <Sime> Riddell: and which config utils need improvement.
[09:22] <Sime> Riddell: i've got some ideas, but I'm curious as to what everyone else thinks.
[09:22] <Riddell> jjesse: am working on docs spec now
[09:22] <jjesse> how's it going?
[09:23] <Riddell> jjesse: fine, I need to ask corey about packaging.  I also put in a note about We will use the Ubuntu Docs repository so it's clear we arn't forking like froud wanted
[09:24] <jjesse> good
[09:24] <Riddell> Sime: there is a bunch of suggestions on the current KubuntuSystemTools spec
[09:25] <Sime> Riddell: ...but not on the wiki yet.
[09:25] <jjesse> Riddell: well according to InclusionofDocumentation Daniel Holbach will be building the packages and uploading them
[09:28] <mornfall> \sh: hi
[09:35] <mornfall> cool, so i'm now stuck with twm+xterm
[09:35] <mornfall> and fscking xorg died with sigsegv
[09:38] <Riddell> jjesse: https://wiki.ubuntu.com/DocteamPlansDapper  FAQGuide and UserGuide going
[09:40] <Riddell> Sime: https://wiki.ubuntu.com/KubuntuSystemTools under "Guidance" heading, second paragraph
[09:41] <Sime> Riddell: errr..... nothing appears to have changed here.
[09:42] <Riddell> Sime: no, I'm just pointing out the suggestions of config utils
[09:43] <Sime> Riddell: ok :-)
[09:49] <jjesse> Riddell: yes it looks like the FAQ Guide for Ubuntu-docs is going
[09:57] <jjesse> Riddell: but it wasn't decided if Kubuntu-docs wants to keep a FAQ Guide or going to the Desktop Starter Guid
[09:58] <spstarr_work> any word on when beta 3 is coming?
[09:58] <spstarr_work> ive sorta got beta 2 with beta 1 mixed (artsd being broke, and kmail)
[10:24] <Riddell> jjesse: I think we should keep as close to ubuntu docs as possible
[10:24] <jjesse> Riddell: so move to the desktop guide and ditch the FAQGuide
[10:24] <Riddell> spstarr_work: see developer.kde.org for the schedule.  I'll be remaking the 3.5 packages next week and putting them into dapper
[10:24] <Riddell> jjesse: yes, seems the sensible thing, then we can borrow server guide too
[10:24] <spstarr_work> ok, i'll grab those as soon as they're out
[10:25] <jjesse> Riddell: what is the difference between ubuntu-server and typing server at the Kubuntu install splash screen?
[10:26] <Riddell> jjesse: see the seeds (SeedManagement) ubuntu-server includes a squillion more packages not on the ubuntu or kubuntu CDs, stuff like mail server or apache modules
[10:26] <jjesse> Riddell: ok
[10:41] <mornfall> Riddell: oh, btw, python bindings for libapt-front are progressing steadily... (we require swig cvs for now though): http://svn.debian.org/wsvn/libapt-front/libapt-front/trunk/swig/python/apt-cat.py?op=file&rev=0&sc=0 -- mvo may like that :)
[10:44] <Riddell> mornfall: say that again
[10:45] <mornfall> mvo: python bindings for libapt-front are progressing steadily... (we require swig cvs for now though): http://svn.debian.org/wsvn/libapt-front/libapt-front/trunk/swig/python/apt-cat.py?op=file&rev=0&sc=0 -- you may like that :)
[10:46] <mornfall> (thanks go to Torsten Marek)
[10:46] <mvo> mornfall: great news
[10:46] <Riddell> https://wiki.ubuntu.com/KubuntuPackageManager2
[10:46] <mornfall> the API will expand with adept 2 of course (the C++ one, and i believe torsten will follow)
[10:47] <mvo> I would like to make some comments about the feature goals for adept2 
[10:47] <mornfall> yes, go ahead
[10:47] <mvo> >  automatic dependency tracking of some kind
[10:48] <mvo> this is going to be in libapt, daniel burrows (aptitude) and I where working on this and we ported the aptitude code into libapt
[10:48] <mvo> I would love if you would have a look and use that if that suits your needs
[10:48] <mvo> it's in a baz branch, not yet mirrored 
[10:48] <mvo> >  make it possible to hide the konsole somehow, unless it's needed for user interaction 
[10:49] <mornfall> for that, yes, i have seen the apt code
[10:49] <mvo> there is a status_fd thing in libapt now that can be used for that, it should be fairly easy to integrate
[10:49] <mornfall> it broke my old code silently, i couldn't not notice :p
[10:50] <mvo> mornfall: it was improved a lot in the last couple of days, daniel and I worked on it
[10:50] <mvo> mornfall: did you use the apt--auto-mark branch? or how did it broke your code?
[10:50] <mornfall> mvo: the status fd
[10:50] <mvo> > advanced problem resolution algorithm
[10:50] <mornfall> the breakage was due to fact that a virtual function changed signature, so my override didn't get called anymore
[10:51] <mvo> daniel burrows did some great work in this area for aptitude and wrote a paper about it
[10:51] <mvo> we will very likely integrate it into libapt and make it availabe for the frontends
[10:51] <mvo> the paper is really great
[10:51] <mornfall> i have seen the code in action (haven't seen the paper)
[10:52] <mvo> >  individual .deb installation
[10:52] <mvo> how do you plan to do this? I'm curious because I hacked it into apt a while ago but wasn't happy with the result. I tried a different approach that just analyzes the deb and sees if it can satisfy the dependencies
[10:52] <mornfall> well, two alternatives
[10:53] <mornfall> either make a local repo or install with dpkg and run fixing pass on the result
[10:53] <mvo> I hope my comments are helpful, I'm happy to help if I can (and feel guilty that I don't work on libapt-front)
[10:53] <mornfall> i guess i prefer first (it also gives you archival of the installed stuff)
[10:54] <mornfall> yes, no problem... i'd like to see more things adopt the libapt-front api of course :)
[10:54] <mvo> mornfall: a third alternative would be to analyze the debs dependencies before the install (with libapt-inst and see if the dependencies make sense). that's what I'm currently trying to do
[10:55] <mvo> as soon as I switched from svn to bzr/baz I will make a libapt-front branch
[10:57] <mornfall> for analyzing dependencies
[10:57] <mornfall> the right thing IMO would be to have the package graph in apt more flexible
[10:57] <mornfall> so you could drop in packages
[10:58] <mornfall> in the long run
[10:58] <mvo> I think daniel burrows new resolver can do that
[10:58] <mvo> we will (hopefully) be able to have both in apt soon
[10:58] <mvo> so that you can activate it in apt with "--new-resolver" and use it in the frontends easily
[10:59] <mvo> do you think the status_fd stuff is usefull for you?
[10:59] <mornfall> i would like to see a complete interface supporting that, not only the resolver though :) (like getting an entity::Package for it, etc)
[10:59] <mornfall> status fd, yes, i think so...
[11:00] <mvo> great. 
[11:00] <mornfall> that's what i planned to use from the start
[11:00] <mvo> I hope to get translated package descriptions in as well
[11:00] <mvo> great again :)
[11:00] <mornfall> for i18n, well, yeah, libapt-front is a bit behind, i didn't really get around that... shouldn't be -that- bad though
[11:01] <mvo> it should be really easy (if it gets in and I get matts ok etc) for you to hook into it
[11:01] <mornfall> btw, is there some plan to work on the fetcher api?
[11:02] <mornfall> it's a bit... klunky
[11:02] <mornfall> i was thinking about just redoing it around libcurl, but haven't gotten any further than contemplating
[11:02] <mvo> we have at least some documentation for it now (in the --doxygen branch that will be mreged when I come back)
[11:03] <mvo> yeah, libcurl would be nice (and shuldn't be too hard)
[11:03] <mvo> I don't think I'll have a chance to have a look though
[11:03] <mvo> what do you think about some abstraction for "update" and "fetching packages"?
[11:03] <mvo> that should be doable in a reasonable amount of time
[11:04] <mornfall> i have those in libapt-front
[11:04] <mvo> http://people.debian.org/~dburrows/model.pdf
[11:04] <mornfall> they need some work
[11:04] <mvo> right, maybe they can be used as a starting point?
[11:06] <mvo> the url is daniels paper
[11:06] <Riddell> mornfall, mvo: for the kde equivalent gnome-app-install is it best to start with gnome-app-install and port to KDE or start with ept and make a simple user interface?
[11:08] <mornfall> Riddell: start with ept
[11:09] <mornfall> Riddell: i also suspect it could be done a lot more efficiently than what gnome-app-install does
[11:09] <Riddell> mornfall: efficient in which way?
[11:10] <mornfall> Riddell: not needing to make all those .desktop files
[11:10] <mornfall> Riddell: it could make use of some sort of icon mapping, but short descriptions (and their translations) and package selection can be done in other ways
[11:10] <mvo> mornfall: we can't really avoid this I think. one problem is that we want to pressed with stuff that we haven't fetched yet (universe may not be enable in ubuntu)
[11:10] <mornfall> Riddell: for the first, apt database should do (with i18n support), for latter, i'd prefer debtags
[11:11] <mvo> mornfall: the other problem is that a major feature is that it represents the menu strucutre
[11:11] <mvo> so the menu information must be availabe
[11:11] <mvo> it not needed to put it in desktop files of course
[11:11] <mornfall> mvo: hmm, okey, that may be a problem... but last time i have seen gnome-app-install, the list was *huge*
[11:11] <mvo> yes, that is definitely a problem
[11:12] <mvo> it's a design goal to have most useful applications availabe even if the "universe,multiverse" stuff is not enabled
[11:12] <mornfall> and reflecting a menu structure, you need the icon and categories (and that's about it)
[11:12] <mornfall> and those can be done easily with debtags, i'd say
[11:12] <mornfall> just make special-icon and special-category facets
[11:13] <mornfall> debtags supports multiple data sources well
[11:13] <mornfall> so you can ship this separately
[11:14] <mornfall> hmm
[11:14] <mvo> right, so if it can be done in that way I don't really mind
[11:14] <mornfall> okey, there's still a problem with packages having multiple binaries
[11:14] <mvo> I just want to tell why we did it that way :)
[11:14] <mvo> (knowing that it's not really the most elegant way)
[11:15] <mornfall> if you stick to the .desktop files, i can still easily parse them
[11:16] <mvo> for g-a-i we will stick to desktop files because I will not be able to change the code to use something new for dapper (there are way too many open tasks)
[11:16] <mornfall> i will just see, i guess :)
[11:16] <mvo> but it's fine of course if you just use this desktop files and convert them to something else :)
[11:17] <Riddell> mornfall: any thoughts about making the sources.list editor more friendly
[11:17] <Riddell> i.e. at the moment it's just a grid of sources.list, but synaptic does nice things to make it more human readable
[11:17] <mornfall> mvo: if something, i'll probably convert it to a tagfile and add support for it to libapt-front
[11:17] <mornfall> Riddell: well, there's a definitive problem with synaptic's one -- you can't just paste a sources.list line you get there
[11:17] <mvo> ok, it would be nice if you would keep me in the loop if you do it
[11:17] <mornfall> Riddell: which is probably the most common use case ever
[11:18] <mornfall> mvo: sure
[11:18] <mornfall> Riddell: the other would be enabling/disabling/removing lines and adding/removing components
[11:18] <mvo> there is a "custom" button to paste sources.list entries
[11:18] <mvo> we hopefully have sources.list.d support soon 
[11:19] <mornfall> mvo: oh, why that? sources.list.d sounds evil
[11:19] <mornfall> mvo: i definitely hate it in apt-rpm
[11:19] <mvo> mornfall: why don't you like it?
[11:19] <mvo> looks very useful to me?
[11:19] <mornfall> mvo: it complicates nearly everything related to managing sources
[11:20] <mornfall> mvo: want to disable one? need to find which file it is in... want to add one? need to figure where it belongs
[11:20] <mvo> but that's really not too hard. it makes adding stuff to sources.list in a automatic way incredible easy
[11:21] <mornfall> mvo: if it had hundreds of well-groupable items, i wouldn't say anything... but with the couple of lines it has, i'd say .d is overkill
[11:21] <mornfall> mvo: and adding to a flat file is hard?
[11:21] <mornfall> mvo: i'd say that if there's choice between "make a bit harder for user" and "make a bit harder for programs", i'd pick the latter
[11:22] <mvo> mornfall: it makes me very nervous to mess with the sources.list file. if I'm able to just add a file if the user clicks on "add something" and just remove that again if the clicks on "remove something" that makes me me less nervous
[11:23] <mvo> sources.list files tend to get pretty big for users quickly. especially if we get more sources.list entries (something that is planed)
[11:23] <mornfall> mvo: hmm, i haven't thought about it that way... and what happens if the user puts something in that "something" file and then clicks remove on that original "something" he added with a program?
[11:23] <mvo> obviously there will be some sanity checks, but I tend to think of the sources.list.d think as something that should really be auto-managed
[11:24] <mvo> but I agree that it's not perfect and has some semantic problems. but that can be easily hidden from the user
[11:25] <mornfall> mvo: unless he tries to use a text editor on it (and many will)
[11:25] <mvo> I tend to think that it really should be fine
[11:25] <mvo> i'm pretty sure we will get it, but we won't force anyone to use it
[11:25] <mvo> it's all optinonal
[11:26] <mvo> and there is a open whishlist bug about it on the debian page that is really old
[11:26] <Riddell> * mvo runs to the toilet
[11:26] <mornfall> as long as you keep the sources.list file and it takes precedence, i'm all fine with it
[11:27] <mornfall> (you actually make life harder for libapt-front too, since i will have to add code to merge those files)
[11:28] <Riddell> mornfall: any more thoughts on whether you want to try for a bounty again with this or if that's too much stress and you want to move on to new things
[11:28] <mornfall> Riddell: if you think bounty is possible, why not
[11:28] <mornfall> Riddell: i did it once, guess i can do it again :)
[11:29] <mornfall> if no, well, no catastrophe happens
[11:29] <mvo> mornfall: sources.list will still be available, yes
[11:29] <mornfall> and i always need cash, i'm a poor guy
[11:30] <mornfall> mvo: btw, i'm wondering how to approach with the libapt vs libapt-front split...
[11:30] <mornfall> mvo: the overlap is growing...
[11:30] <mvo> in what way?
[11:31] <mornfall> let's say sources.list parser
[11:31] <mornfall> i have my own, that can also write out the file
[11:31] <mornfall> and do changes to it
[11:31] <mvo> right. would that we something that can be ported to libapt?
[11:31] <mvo> or do you rather want to have it seperated?
[11:32] <mornfall> mvo: the problem is, it's written using apt-front/utils... so direct port to libapt is not feasible
[11:32] <mvo> I think the overlap should be as small as possible
[11:32] <Riddell> surely libapt already has a sources.list parser?
[11:33] <mvo> what bits of utils are needed and can they be put into libapt?
[11:34] <mornfall> now, the problems are: libapt is managed with baz/bzr, libapt-front with svn/svk
[11:34] <mornfall> libapt-front api is radically different from libapt
[11:34] <mvo> is that the case for stuff like "sources.list" class as well?
[11:35] <mvo> have you tried bzr yet? you may like it, it's really well done (also very new)
[11:35] <mornfall> well, libapt-front's aptFront::Sources uses c++ stream operators
[11:35] <mvo> we will be able to merge from svn in the future as well
[11:35] <mvo> bzr will support that
[11:35] <mornfall> and it's using aptFront::utils::Range
[11:36] <mornfall> range in turn needs multitype and shared pointer implementation
[11:36] <mvo> IMHO apt can't be switched to libapt-front easily, so we will have to see what can be merged in the best possible way
[11:37] <mornfall> *and* i need to be flexible in changing all of this
[11:37] <mvo> right, but that is a problem
[11:37] <mornfall> i am used to xp/agile style development
[11:37] <mornfall> aggressive unit testing, refactoring on the go
[11:37] <mvo> I mean, if you need to be flexible, you need to maitain it in your own branch
[11:38] <mornfall> well, i have libapt-front because of that
[11:38] <mvo> yes, I know that
[11:39] <mornfall> question is, if we can converge this somehow
[11:39] <mvo> I don't really know what the way forward is here. I can offer you to merge stuff that you feel ready. obviously you will lose flexibility then :/
[11:39] <mornfall> i of course could branch of libapt and merge it into libapt-front... but that's not very useful
[11:40] <mvo> why would you want to merge from libapt?
[11:40] <Riddell> mornfall: what's the reason for libapt-front to have its own sources.list classes if libapt already does (better API?  more functionality?)
[11:40] <mvo> I mean, it's fine to branch from it
[11:40] <mornfall> Riddell: both better api and ability to modify the file
[11:40] <mvo> but it would be rather unfortunate if you would need your own libapt to support libapt-front ...
[11:42] <mornfall> mvo: well, i will eventually reimplement many parts of libapt, so i won't need -much- of it
[11:42] <mornfall> mvo: the graph/database access api is first
[11:42] <mornfall> mvo: also sources.list
[11:42] <mornfall> mvo: i am contemplating the fetcher rewrite
[11:43] <Riddell> mornfall: is your hope to eventually obsolete libapt by libapt-front?
[11:43] <mvo> you are free to do whatever you want, but I don't think that apt-get can be depend in the neat future on libapt-front, so apt/libapt needs to be maintained for a certain amount of time
[11:43] <mornfall> Riddell: i don't know... i'd prefer a merge of some sort
[11:43] <mornfall> mvo: yes i know
[11:44] <mornfall> mvo: i don't say rip libapt
[11:44] <mornfall> mvo: i can't replace it in the short-term, anyway
[11:44] <mornfall> mvo: what i can do is reimplementing the commandline tools with it and making them comparable to apt's own
[11:44] <mvo> I can only offer to take stuff for libapt that you feel should be there and I don't mind to put additional util code it as well
[11:45] <Riddell> mornfall: I think you should start to throw stuff back at mvo where it would be good for libapt to use what's in libapt-front
[11:46] <mornfall> Riddell: that probably won't work, as i need my hands free for development... putting to libapt is sort of like casting it into stone
[11:47] <mornfall> since i have very little influence over apt development, depending on some branch of it would kind of kill me off
[11:47] <mornfall> it was enough of a problem with konsolepart, which is much less central to the system
[11:47] <mvo> mornfall: my point is that you can have a *lot* influence in it's development
[11:48] <mvo> mornfall: there aren't that many people working on it (matt,me,dburrows)
[11:48] <mvo> so it's really easy to influce it's development
[11:49] <mvo> my problem is that I can't really put stuff like translated package descriptons into libapt-front because apt won't be able to use it
[11:49] <mvo> so I tend to think that certain things have their place in libapt and others in libapt-front
[11:49] <mornfall> i'm not sure what has (inherent) place in libapt-front
[11:50] <mvo> you want to have (eventually) everything in libapt-front :)
[11:50] <mornfall> that's because i want it to eventually become libapt :)
[11:51] <mornfall> the point is, what belongs to a library separate from libapt
[11:52] <mvo> ok, I have a appointment in a couple of minutes so I won't be able to be around for much longer
[11:52] <mornfall> okey, i will just try to make some sense out of all this
[11:52] <mornfall> the most pressing problem i feel between libapt and libapt-front
[11:53] <mvo> I hope I made clear that certain bits are better of in libapt at this point in time. and that benefits both libapt and libapt-front 
[11:53] <mornfall> is that we use different paradigms for nearly everything
[11:53] <mornfall> from version control through development methodology to api
[11:53] <mornfall> and coding paradigm and style
[11:55] <mvo> yes, I noticed that as well. I don't think this is a bit problem though. because you can easily use (and wrap) stuff from libapt and reimplemnt them when you feel like it
[11:55] <mvo> if that is what you want to do anyway, then that's fine
[11:55] <mornfall> i do it right now, i am not sure it's the ultimate goal though :)
[11:55] <mornfall> but, we'll see how things evolve
[11:55] <mornfall> don't miss your appointment :)
[11:56] <mvo> as I said, I hope we can share as much as possible and I hope you see why I (for example) implemented the translated package descroptions in libapt 
[11:56] <mvo> (and not in libapt-front)
[11:56] <mornfall> yes of course
[11:56] <mvo> (among other things)
[11:56] <mornfall> and that's fine
[11:56] <mornfall> i don't oppose that at all
[11:56] <mvo> I really really want to have close cooperation between the two projects
[11:57] <mornfall> i am only worried about the mid-to-long term... for short-term (like dapper), everything will be still fine enough and not much code will overlap
[11:58] <mvo> great, so let's have productive 6 months :)
[11:58] <mvo> if there is anything I can do for you (and libapt-front) let me know
[11:58] <mornfall> when i get the fetcher done, we can maybe see if the libapt-front utils+fetcher+sources.list classes could be shoved into libapt :)
[11:58] <mornfall> i am trying to keep things as standalone as possible
[11:59] <mornfall> right :)
[11:59] <mvo> if you are reimplementing those bits, what about rewriting methods/http.cc with libcurl?
[11:59] <mvo> or was that not the thing you had in mind?
[12:00] <mvo> sorry, didn't wanted to come up with another discussion topic
[12:01] <mvo> need to leave, I'll try to follow the stuff as close as I can
[12:02] <Riddell> mornfall: I'll write a spec for this stuff, I'll probably pass it by you, I don't know if it'll get approved at the conference but then we can refine it more if/when we apply for a bounty
[12:02] <Riddell> and the bounty stuff would have to be done soon so we aren't rushing again
[12:02] <Riddell> end of meeting
[12:02] <Riddell> thanks mornfall, mvo that was useful