[12:11] packager wanted http://www.kde-look.org/content/show.php?content=29207 [12:11] ascii KDE screensaver thing [12:13] Riddell: can I, will use it to teach viviersf a few things [12:14] chmj: viviersf? [12:15] chmj: wold be cool if you got it packaged, the developer said he's had people want it for kubuntu [12:15] viviersf = Cain_SA = francis [12:16] ok, will do [12:16] chmj: ah yes. great [12:17] viviersf: say HI to your new toy :-) [12:18] huh [12:18] the screensaver ? [12:18] yes, for packaging [12:19] haha [12:19] :) [12:19] Riddell, changed my nick, should be easier for people to know who i am [12:19] becoz CaiN is registered to some1 else [12:20] chmj, will be kewl [12:20] thx === claydoh [n=claydoh@65.99.186.168] has joined #kubuntu-devel === cain_ [n=cain@209.104.102.193] has joined #kubuntu-devel [12:41] now cain_ and viviersf ? [12:41] hello claydoh === JRe [n=jre@pai34-2-82-226-199-36.fbx.proxad.net] has joined #kubuntu-devel [12:41] lol [12:41] rofl wait [12:41] hello Riddell [12:42] better ? [12:44] Riddell: need a package for this ? [12:44] Tonio_: not for the screensaver, viviersf is doing that [12:44] k [12:45] ya [12:45] so that i can become a motu [12:45] I missed yesterday's meeting..... [12:45] i also want to look smart [12:45] hehe [12:45] Tonio_: are you a member? [12:46] Riddell: not yet.... [12:46] I missed the last to meetings, lacking informations on the date [12:46] Tonio_: isn't there a CC meeting today? you could go for membership there [12:46] really ? [12:46] well, isn't a wiki page needed first ? [12:46] I didn't do it :) [12:47] Tonio_: make one make one! [12:47] Riddell: is there any page that explains the different requirements to become a member ? [12:47] 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] last time I could introduce because there was a problem, I think with agenda [12:48] Tonio_: any sustained and useful contribution [12:48] can I had what I did with adept's icons and the kubuntu usplash too ? [12:48] I think only packages have some interesst [12:49] http://www.ubuntu.com/community/community/processes/newmember [12:49] Tonio_: certainly can [12:49] I'll do it right now, and calmy wait for the next CC [12:49] Tonio_: and kubuntu-girl :) [12:49] there is no emergency ;) [12:49] Riddell: haha ;) [12:50] ho Riddell I saw your slideshow [12:50] what a troll !!!!!!!!! in front of 90% gnome gurus !!! I'm really impressed !! === jubei [n=jubei@ppp133-248.lns2.adl2.internode.on.net] has joined #kubuntu-devel [12:50] how did I troll? [12:50] hello jubei [12:50] not a troll to my view, but : [12:51] http://kubuntu.org/~jr/kubuntu-below-zero/html/slide_3.html [12:51] this, in front of so many gnome fans, waw !!! [12:52] that's a reasoned argument, all very well behaved [12:53] lol [12:53] 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] Riddell: sorry for the confusion [12:53] atleast Riddell has some fans of kde here supporting him [12:53] viviersf: I am [12:54] my personnal ethiq is to NEVER package a gnome application ^^ [12:54] haha [12:54] and I never did at least for the moment [12:54] well Tonio_ [12:54] kde isnt superior to gnome [12:54] and gnome isnt superior to kde [12:55] its just a matter of which you prefer [12:55] to my view his architecture is superior [12:55] and does what you want it to do [12:55] but about the rendering and the fealing, that's of course personnam [12:55] personal [12:56] damn, my english is awfull today..... [12:57] Riddell: personal question, are you living in quebec actually ? cause I can see you're making efforts on your french actually ;) [12:57] rofl [01:01] Tonio_: non, j'habite a edibourg [01:02] 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] hehe === Tonio_ is making his member page ! [01:04] ho Riddell interested in the list of package I will soon upload (when kdelibs4-dev will install) ?? [01:04] Tonio_: yes, put it on wiki page along with packages uploaded and in rev [01:05] okay, I will add them as "in progress" so [01:06] Tonio_: do you have a launchpad account? [01:07] yep === Tonio_ is waiting for kde to be added to rosetta... [01:08] Riddell: I think it is in your plans right ? [01:09] Tonio_: https://wiki.ubuntu.com/KubuntuTranslations [01:09] spec in progress [01:10] nice [01:10] I may contribute a lot to that when available === LeeJunFan [n=junfan@adsl-69-210-207-6.dsl.klmzmi.ameritech.net] has joined #kubuntu-devel === LeeJunFan [n=junfan@adsl-69-210-207-6.dsl.klmzmi.ameritech.net] has joined #kubuntu-devel === hunger [n=hunger@p54A60171.dip0.t-ipconnect.de] has joined #kubuntu-devel [02:10] Tonio_: no membership requests at he meeting today [02:11] Riddell: that's fine. no fire arround, I can wait ;) [02:39] sebas, Sime: is there any way we can make this more explicit? https://wiki.ubuntu.com/KubuntuSystemTools [02:40] can we create goals of things to acheve for dapper? [02:40] hmm, late in europe I suppose === seth_k|lappy [n=seth@d-ip-129-15-214-26.wireless.ou.edu] has joined #kubuntu-devel === jubei [n=jubei@ppp133-248.lns2.adl2.internode.on.net] has joined #kubuntu-devel [03:15] seth_k|lappy: that amarok beastie should be PENDINGUPLOAD unil it's in the archives [03:15] Riddell, ah, my bad. I didn't know it was going to go into the archives. I'll twiddle the bits [03:16] of course it'll go in the archives, we won't hvae dapper with an old amarok :) [03:16] oh, I thought you meant Breezy archives [03:16] bah, school has fried my brain :) [03:16] no, but the development relase is the one that matters for beastie fixes [03:17] bug fixed, sorry about that === apokryphos [n=apokryph@70.85.216.98] has joined #kubuntu-devel [03:19] https://launchpad.net/distros/ubuntu/+spec/kubuntu-roadmap-dapper Approved! [03:20] seth_k|lappy: don't worry, and thanks for tending to bestise, always very welcome [03:23] 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] switched a month or two after Hoary [03:25] also Riddell, kmobiletools will be done Friday and barring any more comments, ready to go [03:25] I've been using it for months so the remaining things are just polish; the package itself works fine [03:26] seth_k|lappy: excellent :) [03:38] 'night everyone === LeeJunFan [n=junfan@adsl-69-210-207-6.dsl.klmzmi.ameritech.net] has joined #kubuntu-devel === seth_k [n=seth@asmallorange.com] has joined #kubuntu-devel [04:57] Hi Riddell, dholbach suggested that I did not need such explicit libqt3 build-deps. What should I use instead of: [04:57] libqt3-headers (>= 3:3.3.3-7), libqt3-mt-dev (>= 3:3.3.3-8), libqt3-mt (>= 3:3.3.3-8) [04:58] just libqt3-mt-dev [04:58] right, thank you === jubei [n=jubei@ppp133-248.lns2.adl2.internode.on.net] has joined #kubuntu-devel [05:21] hlloju [05:22] hello jubei [05:24] Hi Riddell === jubei [n=jubei@ppp133-248.lns2.adl2.internode.on.net] has joined #kubuntu-devel === hunger [n=hunger@p54A61903.dip0.t-ipconnect.de] has joined #kubuntu-devel === seth_k [n=seth@asmallorange.com] has joined #kubuntu-devel === claydoh [n=claydoh@65.99.187.147] has joined #kubuntu-devel === seaLne [n=sealne@obelisk.wasters.com] has joined #kubuntu-devel === olwin [n=olwin@dyn-83-157-244-188.ppp.tiscali.fr] has joined #kubuntu-devel === Mez [n=Mez@66.103.220.200] has joined #kubuntu-devel === LeeJunFan [n=junfan@adsl-69-210-207-6.dsl.klmzmi.ameritech.net] has joined #kubuntu-devel === jubei [n=jubei@ppp133-248.lns2.adl2.internode.on.net] has joined #kubuntu-devel === LeeJunFan [n=junfan@adsl-69-210-207-6.dsl.klmzmi.ameritech.net] has joined #kubuntu-devel === tvo [n=tobi@5354EA9B.cable.casema.nl] has joined #kubuntu-devel === Tonio_ [n=tonio@cac94-5-82-229-219-55.fbx.proxad.net] has joined #kubuntu-devel [09:49] mornin' === freeflying [n=freeflyi@61.190.65.35] has joined #kubuntu-devel === JRe [n=jre@pai34-2-82-226-199-36.fbx.proxad.net] has joined #kubuntu-devel === freeflying [n=freeflyi@61.190.65.35] has joined #kubuntu-devel === freeflying [n=freeflyi@61.190.65.35] has joined #kubuntu-devel === hunger [n=hunger@p54A63988.dip0.t-ipconnect.de] has joined #kubuntu-devel === freeflying_ [n=freeflyi@61.190.65.35] has joined #kubuntu-devel === freeflying [n=freeflyi@61.190.65.35] has joined #kubuntu-devel === freeflying [n=freeflyi@61.190.65.35] has joined #kubuntu-devel === apokryphos [n=apokryph@70.85.216.98] has joined #kubuntu-devel === JRe [n=jre@pai34-2-82-226-199-36.fbx.proxad.net] has joined #kubuntu-devel === pef_aw is now known as pef === tvo [n=tobi@5354EA9B.cable.casema.nl] has joined #kubuntu-devel === freeflying [n=freeflyi@61.190.65.35] has joined #kubuntu-devel [02:19] <\sh> who packaged libvisual for the new amarok? [02:25] not me [02:30] <\sh> Mez: new k3b version [02:36] I know :D === jjesse [n=jjesse@mail.ftpb.com] has joined #kubuntu-devel [02:56] \sh: there are debian packages [02:57] \sh: unfortunately i think libvisual-plugins is broken [02:58] \sh: I know how to fix it if you're interrested === claydoh [n=claydoh@65.99.187.147] has joined #kubuntu-devel [03:47] JRe: I'm sure he would love that [03:48] \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] \sh: libvisual_plugins [03:49] \sh: that's why he can't build [03:49] s/he/it/ [03:49] <\sh> JRe: u made the package, right? can u give me the url to the source packages? [03:50] \sh: I made the package but removed it because it has now an official debian maintainer [03:50] \sh: tough, the package libvisual_plugin does not build (see lamont buildlogs) === Czessi [n=czessi@dslb-084-059-016-109.pools.arcor-ip.net] has joined #kubuntu-devel [03:51] \sh: for having libvisual integrated into amarok, take also the latest amarok debian's package it have the fix i made [03:51] \sh: plus very good polish of dato ;) [03:52] \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] \sh: poke me if you have trouble with building libvisual_plugins === viviersf [n=cain@66.103.220.242] has joined #kubuntu-devel === seth_k|lappy [n=seth@d-ip-129-15-215-209.wireless.ou.edu] has joined #kubuntu-devel === seth_k|lappy [n=seth@d-ip-129-15-215-209.wireless.ou.edu] has joined #kubuntu-devel [04:09] <\sh> JRe: why the hell libvisual_plugins is using gcc/g++-3.4? [04:10] \sh: because of incompatibility with gcc4 IIRC [04:10] <\sh> gcc/g++-3.4 will go away [04:13] 3.4 is compatible with 4.0 [04:13] it's 3.3 that's not compatible [04:16] <\sh> Riddell: yeah...but 3.4 will be demoted to universe [04:16] 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] pef: great thanks, I'll try and take a look [04:17] busy day in KDE land today [04:17] ok :) [04:28] Riddell: did you ever apply the stylesheet i asked for :) [04:30] jjesse: no, keep poking me please [04:32] anyone know a package made with scons [04:33] Riddell: will do :) [04:33] btw nice motd on #kubuntu [04:34] hi, i build this package yesterday with scons: http://ubuntu.czessi.net/pool/breezy/testing/kleansweep_0.2.0-0czessi2_i386.deb === seth_k|lappy [n=seth@d-ip-129-15-215-209.wireless.ou.edu] has joined #kubuntu-devel === seth_k|lappy [n=seth@d-ip-129-15-215-209.wireless.ou.edu] has joined #kubuntu-devel [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] \sh: buildep on x11-proto-gl [04:49] \sh: wait a sec I search the real name of the package [04:49] \sh: x11proto-gl-dev [04:50] <\sh> i think i had it inside... [04:50] nah nah [04:50] you want libgl1-mesa-dev | libgl1-dev, libglu1-mesa-dev | libglu1-dev [04:50] might not need glu [04:51] 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] Lathiat: those packages seem to not exists [04:52] JRe: they dont [04:52] their so something else can provide the build depend [04:52] debian compat etc [04:52] Lathiat: k [04:53] <\sh> no ways to get this [04:54] \sh: when I tried it, putting x11proto-gl-dev in the builddeps was fine [04:54] JRe: and broken [04:54] JRe: x11proto-gl-dev will be pulled in by libgl1-mesa-dev [04:55] 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] \sh: :) [05:03] <\sh> JRe: how did u build it then on dapper? [05:07] \sh: never tried on dapper only with breezly [05:07] \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? === Czessi [n=czessi@dslb-084-059-016-109.pools.arcor-ip.net] has left #kubuntu-devel ["Kopete] === KaiL [n=KaiL@p548F49EB.dip.t-dialin.net] has joined #kubuntu-devel [06:18] Sime: about? [06:19] fucking annoying! === Riddell spots his bad language hilight going off [06:20] can't rip audioCD, drive keeps flashing led... [06:20] DRM? [06:20] can't be [06:20] or scratched CD [06:20] can't be [06:21] buyed today, looks like this is ~18years old cd [06:22] and why it keep spinning cd ? [06:22] there's not a sincle app tha should read the disc [06:23] at very first time I'm forced to say this: I hate KDE 3.5 [06:23] maybe disabling "HAL backend" would help, maybe not [06:24] if the disk can't be read that's nothing to do with KDE [06:24] err, I can play it [06:24] can't rip [06:25] playing and reading are different, more error checking on reading [06:25] yu [06:25] have to try other cd's too === OculusAquilae [n=bastian@p548D1610.dip0.t-ipconnect.de] has joined #kubuntu-devel [06:26] ok, how I find out what app keep reading cd [06:26] annoying [06:31] ok, ripping problems with beatles, ac/dc ... [06:32] hmm, maybe my cd/dvd drive is broken [06:34] anyway, annoying [06:37] hmh, can't rip who either, I did rip this albums just a month ago [06:38] oh and I can eject it only as root [06:41] there really is something wrong [06:45] I give up, have to find old cardiscman -> [06:57] ok, rebooted and checked bios ... [06:58] well, now it again auto-opens kscd and konqueror -> trying mount [06:58] funny in a way === Oculus [n=bastian@p548D1610.dip0.t-ipconnect.de] has joined #kubuntu-devel === seth_k|lappy [n=seth@ip-129-15-39-171.bio.ou.edu] has joined #kubuntu-devel [07:42] anyone know if there is a package for mod_ntlm w/ apache2? [07:43] i couldn't find one by searching (either adept or using google) [07:45] jjesse: I'm looking at KubuntuDocs and thinking that release notes should be split into the announcement and a quick guide [07:45] http://help.ubuntu.com/quicktour/C/quicktour.html this sort of thing is really cool [07:46] pictures and soundbytes [07:46] 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] yeah it is, you want one for kubuntu then? [07:47] quick guide is so much more readable and grabs your attention [07:48] you mean quicktour? [07:48] yes === mornfall kicks whoever bears the name StephanHermann [07:49] i'll change KubuntuDocs [07:49] adept *is* the frontend/backend split [07:49] mornfall: \sh_away [07:49] mornfall: where is this? [07:49] Riddell: KubuntuPackageManager2 [07:49] mornfall: can we talk with mvo now quickly? [07:49] Riddell: yeah, why not [07:49] quickly though :) [07:49] i have exam to study for [07:49] he needs lunch [07:50] hmm, i could use a dinner :) [07:50] can he give a rough time? [07:50] i can appear for a talk at any reasonable time tonight [07:50] hang on [07:50] (reasonable is something before 2am :-)) [07:51] 16:50 our time [07:51] zone? (gmt offset?) === mornfall has +1 [07:51] 5 hours time [07:52] in 5 hours? that's 1am, well... okey then [07:53] --> dinner now [07:53] no, 3 hours time [07:53] mvo says sorry for the miscalculation [07:53] okey np [07:53] cool [07:53] 11pm for me [07:55] Riddell: is there a package i can install that will give me mod_ntlm for apache2? [07:59] hey === Tonio_ [n=tonio@tonio.planetemu.net] has joined #kubuntu-devel [08:16] re [08:19] is Ridell busy eating??? [08:21] <\sh> zepp [08:21] <\sh> yepp [08:22] Riddell, new kmobiletools upped, fixes dholbach's comments :) [08:27] will dapper ship with kernel 2.6.14 and FUSE? === Tm_T [i=tm_travo@xob.kapsi.fi] has joined #kubuntu-devel [08:35] Sime: hi [08:35] Riddell: Hi, I'm writing up a sort of Guidance plan for the next few months. [08:36] Sime: excellent [08:37] Sime: you and/or sebas should definatly come to the next ubuntu conference [08:38] 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] Riddell: is there a general ubuntu mailing list that I should be on? [08:38] Sime: there's kubuntu-devel and kubuntu-users (which sebas is quite good at answering stuff on) [08:39] the synaptic, aptitude, dpkg and apt maintainers are all here too, need to get mornfall here for the next one [08:39] where? [08:40] ubuntu conference, montreal [08:40] oh well [08:40] the Smart developer too [08:40] i'll be in a minority [08:40] everyone's so python these days [08:41] yeah, the Smart code is written in C but commented in Python [08:42] i don't dig smart though [08:43] I havn't seen it at all but those who have rave about it [08:45] i don't see what it's got above apt, really... something significant i mean :) [08:45] downgrades are not supported anyway (at least not within debian) [08:45] and aptitude can solve those situations that smart claims noone else does :) [08:45] well, at least it looks like it to me [08:45] i haven't researched it in detail [08:46] lets get mvo to explain it to us later, he seems to like it [08:49] okey, why not :) === olwin [n=olwin@dyn-83-157-217-159.ppp.tiscali.fr] has joined #kubuntu-devel [09:09] Riddell: ok, you should have mail now. [09:10] excellent, thanks, very useful [09:20] need to get me for docs at the next one as well :) [09:20] Riddell: what would also be handy is a list of which configuration utils are still needed. [09:21] Riddell: and which config utils need improvement. [09:22] Riddell: i've got some ideas, but I'm curious as to what everyone else thinks. [09:22] jjesse: am working on docs spec now [09:22] how's it going? [09:23] 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] good [09:24] Sime: there is a bunch of suggestions on the current KubuntuSystemTools spec [09:25] Riddell: ...but not on the wiki yet. [09:25] Riddell: well according to InclusionofDocumentation Daniel Holbach will be building the packages and uploading them [09:28] \sh: hi === viviersf [n=cain@66.103.220.242] has joined #kubuntu-devel === viviersf [n=cain@66.103.220.242] has joined #kubuntu-devel [09:35] cool, so i'm now stuck with twm+xterm [09:35] and fscking xorg died with sigsegv [09:38] jjesse: https://wiki.ubuntu.com/DocteamPlansDapper FAQGuide and UserGuide going [09:40] Sime: https://wiki.ubuntu.com/KubuntuSystemTools under "Guidance" heading, second paragraph [09:41] Riddell: errr..... nothing appears to have changed here. [09:42] Sime: no, I'm just pointing out the suggestions of config utils [09:43] Riddell: ok :-) [09:49] Riddell: yes it looks like the FAQ Guide for Ubuntu-docs is going === spstarr_work [n=spstarr@192.219.104.10] has joined #kubuntu-devel === chmj [n=chmj@66.103.220.182] has joined #kubuntu-devel [09:57] Riddell: but it wasn't decided if Kubuntu-docs wants to keep a FAQ Guide or going to the Desktop Starter Guid [09:58] any word on when beta 3 is coming? [09:58] ive sorta got beta 2 with beta 1 mixed (artsd being broke, and kmail) === allee [n=ach@dialin-212-144-131-168.pools.arcor-ip.net] has joined #kubuntu-devel === seth_k|lappy [n=seth@d-ip-129-15-215-153.wireless.ou.edu] has joined #kubuntu-devel [10:24] jjesse: I think we should keep as close to ubuntu docs as possible [10:24] Riddell: so move to the desktop guide and ditch the FAQGuide [10:24] 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] jjesse: yes, seems the sensible thing, then we can borrow server guide too [10:24] ok, i'll grab those as soon as they're out [10:25] Riddell: what is the difference between ubuntu-server and typing server at the Kubuntu install splash screen? [10:26] 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] Riddell: ok [10:41] 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 :) === mvo [n=egon@209.104.102.193] has joined #kubuntu-devel [10:44] mornfall: say that again === seth_k|lappy [n=seth@d-ip-129-15-215-153.wireless.ou.edu] has joined #kubuntu-devel === seth_k|lappy [n=seth@d-ip-129-15-215-153.wireless.ou.edu] has joined #kubuntu-devel [10:45] 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] (thanks go to Torsten Marek) [10:46] mornfall: great news [10:46] https://wiki.ubuntu.com/KubuntuPackageManager2 [10:46] the API will expand with adept 2 of course (the C++ one, and i believe torsten will follow) [10:47] I would like to make some comments about the feature goals for adept2 [10:47] yes, go ahead [10:47] > automatic dependency tracking of some kind [10:48] 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] I would love if you would have a look and use that if that suits your needs [10:48] it's in a baz branch, not yet mirrored [10:48] > make it possible to hide the konsole somehow, unless it's needed for user interaction [10:49] for that, yes, i have seen the apt code [10:49] there is a status_fd thing in libapt now that can be used for that, it should be fairly easy to integrate [10:49] it broke my old code silently, i couldn't not notice :p [10:50] mornfall: it was improved a lot in the last couple of days, daniel and I worked on it [10:50] mornfall: did you use the apt--auto-mark branch? or how did it broke your code? [10:50] mvo: the status fd [10:50] > advanced problem resolution algorithm [10:50] the breakage was due to fact that a virtual function changed signature, so my override didn't get called anymore [10:51] daniel burrows did some great work in this area for aptitude and wrote a paper about it [10:51] we will very likely integrate it into libapt and make it availabe for the frontends [10:51] the paper is really great [10:51] i have seen the code in action (haven't seen the paper) [10:52] > individual .deb installation [10:52] 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] well, two alternatives [10:53] either make a local repo or install with dpkg and run fixing pass on the result [10:53] 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] i guess i prefer first (it also gives you archival of the installed stuff) [10:54] yes, no problem... i'd like to see more things adopt the libapt-front api of course :) [10:54] 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] as soon as I switched from svn to bzr/baz I will make a libapt-front branch [10:57] for analyzing dependencies [10:57] the right thing IMO would be to have the package graph in apt more flexible [10:57] so you could drop in packages [10:58] in the long run [10:58] I think daniel burrows new resolver can do that [10:58] we will (hopefully) be able to have both in apt soon [10:58] so that you can activate it in apt with "--new-resolver" and use it in the frontends easily [10:59] do you think the status_fd stuff is usefull for you? [10:59] 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] status fd, yes, i think so... [11:00] great. [11:00] that's what i planned to use from the start [11:00] I hope to get translated package descriptions in as well [11:00] great again :) [11:00] 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] it should be really easy (if it gets in and I get matts ok etc) for you to hook into it [11:01] btw, is there some plan to work on the fetcher api? [11:02] it's a bit... klunky [11:02] i was thinking about just redoing it around libcurl, but haven't gotten any further than contemplating [11:02] we have at least some documentation for it now (in the --doxygen branch that will be mreged when I come back) [11:03] yeah, libcurl would be nice (and shuldn't be too hard) [11:03] I don't think I'll have a chance to have a look though [11:03] what do you think about some abstraction for "update" and "fetching packages"? [11:03] that should be doable in a reasonable amount of time [11:04] i have those in libapt-front [11:04] http://people.debian.org/~dburrows/model.pdf [11:04] they need some work [11:04] right, maybe they can be used as a starting point? [11:06] the url is daniels paper [11:06] 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? === seth_k|lappy [n=seth@d-ip-129-15-215-153.wireless.ou.edu] has joined #kubuntu-devel [11:08] Riddell: start with ept [11:09] Riddell: i also suspect it could be done a lot more efficiently than what gnome-app-install does [11:09] mornfall: efficient in which way? [11:10] Riddell: not needing to make all those .desktop files [11:10] 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] 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] Riddell: for the first, apt database should do (with i18n support), for latter, i'd prefer debtags [11:11] mornfall: the other problem is that a major feature is that it represents the menu strucutre [11:11] so the menu information must be availabe [11:11] it not needed to put it in desktop files of course [11:11] mvo: hmm, okey, that may be a problem... but last time i have seen gnome-app-install, the list was *huge* [11:11] yes, that is definitely a problem [11:12] it's a design goal to have most useful applications availabe even if the "universe,multiverse" stuff is not enabled [11:12] and reflecting a menu structure, you need the icon and categories (and that's about it) [11:12] and those can be done easily with debtags, i'd say [11:12] just make special-icon and special-category facets [11:13] debtags supports multiple data sources well [11:13] so you can ship this separately [11:14] hmm [11:14] right, so if it can be done in that way I don't really mind [11:14] okey, there's still a problem with packages having multiple binaries [11:14] I just want to tell why we did it that way :) [11:14] (knowing that it's not really the most elegant way) [11:15] if you stick to the .desktop files, i can still easily parse them [11:16] 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] i will just see, i guess :) [11:16] but it's fine of course if you just use this desktop files and convert them to something else :) [11:17] mornfall: any thoughts about making the sources.list editor more friendly [11:17] 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] mvo: if something, i'll probably convert it to a tagfile and add support for it to libapt-front [11:17] 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] ok, it would be nice if you would keep me in the loop if you do it [11:17] Riddell: which is probably the most common use case ever [11:18] mvo: sure [11:18] Riddell: the other would be enabling/disabling/removing lines and adding/removing components [11:18] there is a "custom" button to paste sources.list entries [11:18] we hopefully have sources.list.d support soon [11:19] mvo: oh, why that? sources.list.d sounds evil [11:19] mvo: i definitely hate it in apt-rpm [11:19] mornfall: why don't you like it? [11:19] looks very useful to me? [11:19] mvo: it complicates nearly everything related to managing sources [11:20] 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] but that's really not too hard. it makes adding stuff to sources.list in a automatic way incredible easy [11:21] 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] mvo: and adding to a flat file is hard? [11:21] 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] 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] 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] 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] 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] but I agree that it's not perfect and has some semantic problems. but that can be easily hidden from the user [11:25] mvo: unless he tries to use a text editor on it (and many will) [11:25] I tend to think that it really should be fine [11:25] i'm pretty sure we will get it, but we won't force anyone to use it [11:25] it's all optinonal [11:26] and there is a open whishlist bug about it on the debian page that is really old [11:26] * mvo runs to the toilet [11:26] as long as you keep the sources.list file and it takes precedence, i'm all fine with it [11:27] (you actually make life harder for libapt-front too, since i will have to add code to merge those files) [11:28] 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] Riddell: if you think bounty is possible, why not [11:28] Riddell: i did it once, guess i can do it again :) [11:29] if no, well, no catastrophe happens [11:29] mornfall: sources.list will still be available, yes [11:29] and i always need cash, i'm a poor guy [11:30] mvo: btw, i'm wondering how to approach with the libapt vs libapt-front split... === mvo makes his own life harder as well as the synaptic edito will need to cope with it as well [11:30] mvo: the overlap is growing... [11:30] in what way? [11:31] let's say sources.list parser [11:31] i have my own, that can also write out the file [11:31] and do changes to it [11:31] right. would that we something that can be ported to libapt? [11:31] or do you rather want to have it seperated? [11:32] mvo: the problem is, it's written using apt-front/utils... so direct port to libapt is not feasible [11:32] I think the overlap should be as small as possible [11:32] surely libapt already has a sources.list parser? [11:33] what bits of utils are needed and can they be put into libapt? [11:34] now, the problems are: libapt is managed with baz/bzr, libapt-front with svn/svk [11:34] libapt-front api is radically different from libapt [11:34] is that the case for stuff like "sources.list" class as well? [11:35] have you tried bzr yet? you may like it, it's really well done (also very new) [11:35] well, libapt-front's aptFront::Sources uses c++ stream operators [11:35] we will be able to merge from svn in the future as well [11:35] bzr will support that [11:35] and it's using aptFront::utils::Range [11:36] range in turn needs multitype and shared pointer implementation [11:36] 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] *and* i need to be flexible in changing all of this [11:37] right, but that is a problem [11:37] i am used to xp/agile style development [11:37] aggressive unit testing, refactoring on the go [11:37] I mean, if you need to be flexible, you need to maitain it in your own branch [11:38] well, i have libapt-front because of that [11:38] yes, I know that [11:39] question is, if we can converge this somehow [11:39] 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] i of course could branch of libapt and merge it into libapt-front... but that's not very useful [11:40] why would you want to merge from libapt? [11:40] 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] I mean, it's fine to branch from it [11:40] Riddell: both better api and ability to modify the file [11:40] but it would be rather unfortunate if you would need your own libapt to support libapt-front ... [11:42] mvo: well, i will eventually reimplement many parts of libapt, so i won't need -much- of it [11:42] mvo: the graph/database access api is first [11:42] mvo: also sources.list [11:42] mvo: i am contemplating the fetcher rewrite [11:43] mornfall: is your hope to eventually obsolete libapt by libapt-front? [11:43] 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] Riddell: i don't know... i'd prefer a merge of some sort [11:43] mvo: yes i know [11:44] mvo: i don't say rip libapt [11:44] mvo: i can't replace it in the short-term, anyway [11:44] mvo: what i can do is reimplementing the commandline tools with it and making them comparable to apt's own [11:44] 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] 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] 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] since i have very little influence over apt development, depending on some branch of it would kind of kill me off [11:47] it was enough of a problem with konsolepart, which is much less central to the system [11:47] mornfall: my point is that you can have a *lot* influence in it's development [11:48] mornfall: there aren't that many people working on it (matt,me,dburrows) [11:48] so it's really easy to influce it's development [11:49] 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] so I tend to think that certain things have their place in libapt and others in libapt-front [11:49] i'm not sure what has (inherent) place in libapt-front [11:50] you want to have (eventually) everything in libapt-front :) [11:50] that's because i want it to eventually become libapt :) [11:51] the point is, what belongs to a library separate from libapt [11:52] ok, I have a appointment in a couple of minutes so I won't be able to be around for much longer [11:52] okey, i will just try to make some sense out of all this [11:52] the most pressing problem i feel between libapt and libapt-front [11:53] 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] is that we use different paradigms for nearly everything [11:53] from version control through development methodology to api [11:53] and coding paradigm and style [11:55] 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] if that is what you want to do anyway, then that's fine [11:55] i do it right now, i am not sure it's the ultimate goal though :) [11:55] but, we'll see how things evolve [11:55] don't miss your appointment :) [11:56] 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] (and not in libapt-front) [11:56] yes of course [11:56] (among other things) [11:56] and that's fine [11:56] i don't oppose that at all [11:56] I really really want to have close cooperation between the two projects [11:57] 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] great, so let's have productive 6 months :) [11:58] if there is anything I can do for you (and libapt-front) let me know [11:58] 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] i am trying to keep things as standalone as possible [11:59] right :) [11:59] if you are reimplementing those bits, what about rewriting methods/http.cc with libcurl? [11:59] or was that not the thing you had in mind? [12:00] sorry, didn't wanted to come up with another discussion topic [12:01] need to leave, I'll try to follow the stuff as close as I can [12:02] 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] and the bounty stuff would have to be done soon so we aren't rushing again [12:02] end of meeting [12:02] thanks mornfall, mvo that was useful