Riddellpackager wanted http://www.kde-look.org/content/show.php?content=2920712:11
Riddellascii KDE screensaver thing12:11
chmjRiddell: can I, will use it to teach viviersf a few things 12:13
Riddellchmj: viviersf?12:14
Riddellchmj: wold be cool if you got it packaged, the developer said he's had people want it for kubuntu12:15
chmjviviersf = Cain_SA = francis12:15
chmjok, will do12:16
Riddellchmj: ah yes.  great12:16
chmjviviersf: say HI to your new toy :-) 12:17
viviersfthe screensaver ?12:18
chmjyes, for packaging 12:18
viviersfRiddell, changed my nick, should be easier for people to know who i am12:19
viviersfbecoz CaiN is registered to some1 else12:19
viviersfchmj, will be kewl12:20
=== claydoh [n=claydoh@] has joined #kubuntu-devel
=== cain_ [n=cain@] has joined #kubuntu-devel
Riddellnow cain_ and viviersf ?12:41
Riddellhello claydoh 12:41
=== JRe [n=jre@pai34-2-82-226-199-36.fbx.proxad.net] has joined #kubuntu-devel
cain_rofl wait12:41
claydohhello Riddell 12:41
viviersfbetter ?12:42
Tonio_Riddell: need a package for this ?12:44
RiddellTonio_: not for the screensaver, viviersf is doing that12:44
viviersfso that i can become a motu 12:45
Tonio_I missed yesterday's meeting.....12:45
viviersfi also want to look smart 12:45
RiddellTonio_: are you a member?12:45
Tonio_Riddell: not yet....12:46
Tonio_I missed the last to meetings, lacking informations on the date12:46
RiddellTonio_: isn't there a CC meeting today?  you could go for membership there12:46
Tonio_really ?12:46
Tonio_well, isn't a wiki page needed first ?12:46
Tonio_I didn't do it :)12:46
RiddellTonio_: make one make one!12:47
Tonio_Riddell: is there any page that explains the different requirements to become a member ?12:47
RiddellI 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:47
Tonio_last time I could introduce because there was a problem, I  think with agenda12:48
RiddellTonio_: any sustained and useful contribution12: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 interesst12:48
RiddellTonio_: certainly can12:49
Tonio_I'll do it right now, and calmy wait for the next CC12:49
RiddellTonio_: and kubuntu-girl :)12:49
Tonio_there is no emergency ;)12:49
Tonio_Riddell: haha ;)12:49
Tonio_ho Riddell  I saw your slideshow12:50
Tonio_what a troll !!!!!!!!! in front of 90% gnome gurus !!! I'm really impressed !!12:50
=== jubei [n=jubei@ppp133-248.lns2.adl2.internode.on.net] has joined #kubuntu-devel
Riddellhow did I troll?12:50
Riddellhello jubei 12:50
Tonio_not a troll to my view, but :12:50
Tonio_this, in front of so many gnome fans, waw !!!12:51
Riddellthat's a reasoned argument, all very well behaved12:52
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 confusion12:53
viviersfatleast Riddell has some fans of kde here supporting him12:53
Tonio_viviersf: I am12:53
Tonio_my personnal ethiq is to NEVER package a gnome application ^^12:54
Tonio_and I never did at least for the moment12:54
viviersfwell Tonio_ 12:54
viviersfkde isnt superior to gnome12:54
viviersfand gnome isnt superior to kde12:54
viviersfits just a matter of which you prefer12:55
Tonio_to my view his architecture is superior12:55
viviersfand does what you want it to do12:55
Tonio_but about the rendering and the fealing, that's of course personnam12:55
Tonio_damn, my english is awfull today.....12:56
Tonio_Riddell: personal question, are you living in quebec actually ? cause I can see you're making efforts on your french actually ;)12:57
RiddellTonio_: non, j'habite a edibourg01:01
Riddelland 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 french01:02
=== Tonio_ is making his member page !
Tonio_ho Riddell interested in the list of package I will soon upload (when kdelibs4-dev will install) ??01:04
RiddellTonio_: yes, put it on wiki page along with packages uploaded and in rev01:04
Tonio_okay, I will add them as "in progress" so01:05
RiddellTonio_: do you have a launchpad account?01:06
=== Tonio_ is waiting for kde to be added to rosetta...
Tonio_Riddell: I think it is in your plans right ?01:08
RiddellTonio_: https://wiki.ubuntu.com/KubuntuTranslations01:09
Riddellspec in progress01:09
Tonio_I may contribute a lot to that when available01:10
=== 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
RiddellTonio_: no membership requests at he meeting today02:10
Tonio_Riddell: that's fine. no fire arround, I can wait ;)02:11
Riddellsebas, Sime: is there any way we can make this more explicit? https://wiki.ubuntu.com/KubuntuSystemTools02:39
Riddellcan we create goals of things to acheve for dapper?02:40
Riddellhmm, late in europe I suppose02:40
=== 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
Riddellseth_k|lappy: that amarok beastie should be PENDINGUPLOAD unil it's in the archives03:15
seth_k|lappyRiddell, ah, my bad. I didn't know it was going to go into the archives. I'll twiddle the bits03:15
Riddellof course it'll go in the archives, we won't hvae dapper with an old amarok :)03:16
seth_k|lappyoh, I thought you meant Breezy archives03:16
seth_k|lappybah, school has fried my brain :)03:16
Riddellno, but the development relase is the one that matters for beastie fixes03:16
seth_k|lappybug fixed, sorry about that03:17
=== apokryphos [n=apokryph@] has joined #kubuntu-devel
Riddellhttps://launchpad.net/distros/ubuntu/+spec/kubuntu-roadmap-dapper  Approved!03:19
Riddellseth_k|lappy: don't worry, and thanks for tending to bestise, always very welcome03:20
seth_k|lappyYeah, 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 Gnome03:23
seth_k|lappyswitched a month or two after Hoary03:23
seth_k|lappyalso Riddell, kmobiletools will be done Friday and barring any more comments, ready to go03:25
seth_k|lappyI've been using it for months so the remaining things are just polish; the package itself works fine03:25
Riddellseth_k|lappy: excellent :)03:26
Tonio_'night everyone03:38
=== 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
seth_kHi Riddell, dholbach suggested that I did not need such explicit libqt3 build-deps. What should I use instead of:04:57
seth_klibqt3-headers (>=  3:3.3.3-7), libqt3-mt-dev (>= 3:3.3.3-8),  libqt3-mt (>= 3:3.3.3-8)04:57
Riddelljust libqt3-mt-dev04:58
seth_kright, thank you04:58
=== jubei [n=jubei@ppp133-248.lns2.adl2.internode.on.net] has joined #kubuntu-devel
Riddellhello jubei 05:22
jubeiHi Riddell 05:24
=== 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@] 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@] 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
=== freeflying [n=freeflyi@] has joined #kubuntu-devel
=== JRe [n=jre@pai34-2-82-226-199-36.fbx.proxad.net] has joined #kubuntu-devel
=== freeflying [n=freeflyi@] has joined #kubuntu-devel
=== freeflying [n=freeflyi@] has joined #kubuntu-devel
=== hunger [n=hunger@p54A63988.dip0.t-ipconnect.de] has joined #kubuntu-devel
=== freeflying_ [n=freeflyi@] has joined #kubuntu-devel
=== freeflying [n=freeflyi@] has joined #kubuntu-devel
=== freeflying [n=freeflyi@] has joined #kubuntu-devel
=== apokryphos [n=apokryph@] 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@] has joined #kubuntu-devel
\shwho packaged libvisual for the new amarok?02:19
Tm_Tnot me02:25
\shMez: new k3b version02:30
MezI know :D02:36
=== jjesse [n=jjesse@mail.ftpb.com] has joined #kubuntu-devel
JRe\sh: there are debian packages02:56
JRe\sh: unfortunately i think libvisual-plugins is broken02:57
JRe\sh: I know how to fix it if you're interrested02:58
=== claydoh [n=claydoh@] has joined #kubuntu-devel
RiddellJRe: I'm sure he would love that 03:47
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
\shJRe: context now? 03:48
\shJRe: amarok, libvisual_03:48
JRe\sh: libvisual_plugins03:49
JRe\sh: that's why he can't build03:49
\shJRe: u made the package, right? can u give me the url to the source packages?03:49
JRe\sh: I made the package but removed it because it has now an official debian maintainer03:50
JRe\sh: tough, the package libvisual_plugin does not build (see lamont buildlogs)03:50
=== Czessi [n=czessi@dslb-084-059-016-109.pools.arcor-ip.net] has joined #kubuntu-devel
JRe\sh: for having libvisual integrated into amarok, take also the latest amarok debian's package it have the fix i made03:51
JRe\sh: plus very good polish of dato ;)03:51
JRe\sh: http://packages.debian.org/changelogs/pool/main/a/amarok/amarok_1.3.5-1/changelog it's from 1.3.4-103:52
\shJRe: k03:53
JRe\sh: poke me if you have trouble with building libvisual_plugins03:54
=== viviersf [n=cain@] 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
\shJRe: why the hell libvisual_plugins is using gcc/g++-3.4?04:09
JRe\sh: because of incompatibility with gcc4 IIRC04:10
\shgcc/g++-3.4 will go away04:10
Riddell3.4 is compatible with 4.004:13
Riddellit's 3.3 that's not compatible04:13
\shRiddell: yeah...but 3.4 will be demoted to universe04:16
pefRiddell: hello, I've synced gwenview, what's your opinion ? http://revu.tauware.de/details.py?upid=86204:16
\shRiddell: so if u want libvisual_plugins in main ,) we need to fix it....04:17
Riddellpef: great thanks, I'll try and take a look04:17
Riddellbusy day in KDE land today04:17
pefok :)04:17
jjesseRiddell: did you ever apply the stylesheet i asked for :)04:28
Riddelljjesse: no, keep poking me please04:30
Riddellanyone know a package made with scons04:32
jjesseRiddell: will do :)04:33
jjessebtw nice motd on #kubuntu04:33
Czessihi, i build this package yesterday with scons: http://ubuntu.czessi.net/pool/breezy/testing/kleansweep_0.2.0-0czessi2_i386.deb04:34
=== 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
\shwhy should we need libvisual-plugins...we have screensaver..04:39
\shmeans...libvisual-plugins are evil04:39
\shJRe: checking where to install plugins... /usr/lib/libvisual04:47
\shconfigure: error: conditional "HAVE_LIB_GL" was never defined.04:47
\shbuild-dep on libgl1-mesa-dev and libglu1-mesa-dev that is04:48
JRe\sh: buildep on x11-proto-gl04:49
JRe\sh: wait a sec I search the real name of the package04:49
JRe\sh: x11proto-gl-dev04:49
\shi think i had it inside...04:50
Lathiatnah nah04:50
Lathiatyou want libgl1-mesa-dev | libgl1-dev, libglu1-mesa-dev | libglu1-dev04:50
Lathiatmight not need glu04:50
Lathiatmm i lied its | libgl-dev and | libglu-dev04:51
\shLathiat: 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 left04:51
JReLathiat: those packages seem to not exists04:51
LathiatJRe: they dont04:52
Lathiattheir so something else can provide the build depend04:52
Lathiatdebian compat etc04:52
JReLathiat: k04:52
\shno ways to get this04:53
JRe\sh: when I tried it, putting x11proto-gl-dev in the builddeps was fine04:54
LathiatJRe: and broken04:54
LathiatJRe: x11proto-gl-dev will be pulled in by libgl1-mesa-dev04:54
JReLathiat: tes it replaces04:55
\shJRe: i have now at least all *GL* build deps in debian/control ...04:55
\shlibvisual-plugins is b0rked04:55
JRe\sh: :)04:55
\shJRe: how did u build it then on dapper?05:03
JRe\sh: never tried on dapper only with breezly05:07
JRe\sh: i can't make the dapper debootstrap05:07
\shJRe: create a breezy pbuilder and after that, replace the breezy archives with dapper05:10
\shRiddell: should we bring amarok-1.3.5 in, and fix this crappy visual stuff later...thinking about leaving libvisual-plugins in universe?05:16
=== 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
RiddellSime: about?06:18
Tm_Tfucking annoying!06:19
=== Riddell spots his bad language hilight going off
Tm_Tcan't rip audioCD, drive keeps flashing led...06:20
Tm_Tcan't be06:20
Riddellor scratched CD06:20
Tm_Tcan't be06:20
Tm_Tbuyed today, looks like this is ~18years old cd06:21
Tm_Tand why it keep spinning cd ?06:22
Tm_Tthere's not a sincle app tha should read the disc06:22
Tm_Tat very first time I'm forced to say this: I hate KDE 3.506:23
Tm_Tmaybe disabling "HAL backend" would help, maybe not06:23
Riddellif the disk can't be read that's nothing to do with KDE06:24
Tm_Terr, I can play it06:24
Tm_Tcan't rip06:24
Riddellplaying and reading are different, more error checking on reading06:25
Tm_Thave to try other cd's too06:25
=== OculusAquilae [n=bastian@p548D1610.dip0.t-ipconnect.de] has joined #kubuntu-devel
Tm_Tok, how I find out what app keep reading cd06:26
Tm_Tok, ripping problems with beatles, ac/dc ...06:31
Tm_Thmm, maybe my cd/dvd drive is broken06:32
Tm_Tanyway, annoying06:34
Tm_Thmh, can't rip who either, I did rip this albums just a month ago06:37
Tm_Toh and I can eject it only as root06:38
Tm_Tthere really is something wrong06:41
Tm_TI give up, have to find old cardiscman ->06:45
Tm_Tok, rebooted and checked bios ...06:57
Tm_Twell, now it again auto-opens kscd and konqueror -> trying mount06:58
Tm_Tfunny in a way06:58
=== 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
jjesseanyone know if there is a package for mod_ntlm w/ apache2?07:42
jjessei couldn't find one by searching (either adept or using google)07:43
Riddelljjesse: I'm looking at KubuntuDocs and thinking that release notes should be split into the announcement and a quick guide07:45
Riddellhttp://help.ubuntu.com/quicktour/C/quicktour.html  this sort of thing is really cool07:45
Riddellpictures and soundbytes07:46
Riddelland then there's this http://kubuntu.org/announcements/breezy-release.php  which was based off the release notes but isn't quite the same07:46
jjesseyeah it is, you want one for kubuntu then?07:46
Riddellquick guide is so much more readable and grabs your attention07:47
jjesseyou mean quicktour?07:48
=== mornfall kicks whoever bears the name StephanHermann
jjessei'll change KubuntuDocs07:49
mornfalladept *is* the frontend/backend split07:49
Riddellmornfall: \sh_away 07:49
Riddellmornfall: where is this?07:49
mornfallRiddell: KubuntuPackageManager207:49
Riddellmornfall: can we talk with mvo now quickly?07:49
mornfallRiddell: yeah, why not07:49
mornfallquickly though :)07:49
mornfalli have exam to study for07:49
Riddellhe needs lunch07:49
mornfallhmm, i could use a dinner :)07:50
mornfallcan he give a rough time?07:50
mornfalli can appear for a talk at any reasonable time tonight07:50
Riddellhang on07:50
mornfall(reasonable is something before 2am :-))07:50
Riddell16:50 our time07:51
mornfallzone? (gmt offset?)07:51
=== mornfall has +1
Riddell5 hours time07:51
mornfallin 5 hours? that's 1am, well... okey then07:52
mornfall--> dinner now07:53
Riddellno, 3 hours time07:53
Riddellmvo says sorry for the miscalculation07:53
mornfallokey np07:53
mornfall11pm for me07:53
jjesseRiddell: is there a package i can install that will give me mod_ntlm for apache2?07:55
=== Tonio_ [n=tonio@tonio.planetemu.net] has joined #kubuntu-devel
Simeis Ridell busy eating???08:19
seth_kRiddell, new kmobiletools upped, fixes dholbach's comments :)08:22
Simewill dapper ship with kernel 2.6.14 and FUSE?08:27
=== Tm_T [i=tm_travo@xob.kapsi.fi] has joined #kubuntu-devel
RiddellSime: hi08:35
SimeRiddell: Hi, I'm writing up a sort of Guidance plan for the next few months.08:35
RiddellSime: excellent08:36
RiddellSime: you and/or sebas should definatly come to the next ubuntu conference08:37
RiddellI 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 done08:38
SimeRiddell: is there a general ubuntu mailing list that I should be on?08:38
RiddellSime: there's kubuntu-devel and kubuntu-users (which sebas is quite good at answering stuff on) 08:38
Riddellthe synaptic, aptitude, dpkg and apt maintainers are all here too, need to get mornfall here for the next one08:39
Riddellubuntu conference, montreal08:40
mornfalloh well08:40
Riddellthe Smart developer too08:40
mornfalli'll be in a minority08:40
mornfalleveryone's so python these days08:40
Riddellyeah, the Smart code is written in C but commented in Python08:41
mornfalli don't dig smart though08:42
RiddellI havn't seen it at all but those who have rave about it08:43
mornfalli don't see what it's got above apt, really... something significant i mean :)08:45
mornfalldowngrades are not supported anyway (at least not within debian)08:45
mornfalland aptitude can solve those situations that smart claims noone else does :)08:45
mornfallwell, at least it looks like it to me08:45
mornfalli haven't researched it in detail08:45
Riddelllets get mvo to explain it to us later, he seems to like it08:46
mornfallokey, why not :)08:49
=== olwin [n=olwin@dyn-83-157-217-159.ppp.tiscali.fr] has joined #kubuntu-devel
SimeRiddell: ok, you should have mail now.09:09
Riddellexcellent, thanks, very useful09:10
jjesseneed to get me for docs at the next one as well :)09:20
SimeRiddell: what would also be handy is a list of which configuration utils are still needed.09:20
SimeRiddell: and which config utils need improvement.09:21
SimeRiddell: i've got some ideas, but I'm curious as to what everyone else thinks.09:22
Riddelljjesse: am working on docs spec now09:22
jjessehow's it going?09:22
Riddelljjesse: 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 wanted09:23
RiddellSime: there is a bunch of suggestions on the current KubuntuSystemTools spec09:24
SimeRiddell: ...but not on the wiki yet.09:25
jjesseRiddell: well according to InclusionofDocumentation Daniel Holbach will be building the packages and uploading them09:25
mornfall\sh: hi09:28
=== viviersf [n=cain@] has joined #kubuntu-devel
=== viviersf [n=cain@] has joined #kubuntu-devel
mornfallcool, so i'm now stuck with twm+xterm09:35
mornfalland fscking xorg died with sigsegv09:35
Riddelljjesse: https://wiki.ubuntu.com/DocteamPlansDapper  FAQGuide and UserGuide going09:38
RiddellSime: https://wiki.ubuntu.com/KubuntuSystemTools under "Guidance" heading, second paragraph09:40
SimeRiddell: errr..... nothing appears to have changed here.09:41
RiddellSime: no, I'm just pointing out the suggestions of config utils09:42
SimeRiddell: ok :-)09:43
jjesseRiddell: yes it looks like the FAQ Guide for Ubuntu-docs is going09:49
=== spstarr_work [n=spstarr@] has joined #kubuntu-devel
=== chmj [n=chmj@] has joined #kubuntu-devel
jjesseRiddell: but it wasn't decided if Kubuntu-docs wants to keep a FAQ Guide or going to the Desktop Starter Guid09:57
spstarr_workany word on when beta 3 is coming?09:58
spstarr_workive sorta got beta 2 with beta 1 mixed (artsd being broke, and kmail)09:58
=== 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
Riddelljjesse: I think we should keep as close to ubuntu docs as possible10:24
jjesseRiddell: so move to the desktop guide and ditch the FAQGuide10:24
Riddellspstarr_work: see developer.kde.org for the schedule.  I'll be remaking the 3.5 packages next week and putting them into dapper10:24
Riddelljjesse: yes, seems the sensible thing, then we can borrow server guide too10:24
spstarr_workok, i'll grab those as soon as they're out10:24
jjesseRiddell: what is the difference between ubuntu-server and typing server at the Kubuntu install splash screen?10:25
Riddelljjesse: see the seeds (SeedManagement) ubuntu-server includes a squillion more packages not on the ubuntu or kubuntu CDs, stuff like mail server or apache modules10:26
jjesseRiddell: ok10:26
mornfallRiddell: 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:41
=== mvo [n=egon@] has joined #kubuntu-devel
Riddellmornfall: say that again10:44
=== 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
mornfallmvo: 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:45
mornfall(thanks go to Torsten Marek)10:46
mvomornfall: great news10:46
mornfallthe API will expand with adept 2 of course (the C++ one, and i believe torsten will follow)10:46
mvoI would like to make some comments about the feature goals for adept2 10:47
mornfallyes, go ahead10:47
mvo>  automatic dependency tracking of some kind10:47
mvothis is going to be in libapt, daniel burrows (aptitude) and I where working on this and we ported the aptitude code into libapt10:48
mvoI would love if you would have a look and use that if that suits your needs10:48
mvoit'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:48
mornfallfor that, yes, i have seen the apt code10:49
mvothere is a status_fd thing in libapt now that can be used for that, it should be fairly easy to integrate10:49
mornfallit broke my old code silently, i couldn't not notice :p10:49
mvomornfall: it was improved a lot in the last couple of days, daniel and I worked on it10:50
mvomornfall: did you use the apt--auto-mark branch? or how did it broke your code?10:50
mornfallmvo: the status fd10:50
mvo> advanced problem resolution algorithm10:50
mornfallthe breakage was due to fact that a virtual function changed signature, so my override didn't get called anymore10:50
mvodaniel burrows did some great work in this area for aptitude and wrote a paper about it10:51
mvowe will very likely integrate it into libapt and make it availabe for the frontends10:51
mvothe paper is really great10:51
mornfalli have seen the code in action (haven't seen the paper)10:51
mvo>  individual .deb installation10:52
mvohow 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 dependencies10:52
mornfallwell, two alternatives10:52
mornfalleither make a local repo or install with dpkg and run fixing pass on the result10:53
mvoI 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
mornfalli guess i prefer first (it also gives you archival of the installed stuff)10:53
mornfallyes, no problem... i'd like to see more things adopt the libapt-front api of course :)10:54
mvomornfall: 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 do10:54
mvoas soon as I switched from svn to bzr/baz I will make a libapt-front branch10:55
mornfallfor analyzing dependencies10:57
mornfallthe right thing IMO would be to have the package graph in apt more flexible10:57
mornfallso you could drop in packages10:57
mornfallin the long run10:58
mvoI think daniel burrows new resolver can do that10:58
mvowe will (hopefully) be able to have both in apt soon10:58
mvoso that you can activate it in apt with "--new-resolver" and use it in the frontends easily10:58
mvodo you think the status_fd stuff is usefull for you?10:59
mornfalli would like to see a complete interface supporting that, not only the resolver though :) (like getting an entity::Package for it, etc)10:59
mornfallstatus fd, yes, i think so...10:59
mvogreat. 11:00
mornfallthat's what i planned to use from the start11:00
mvoI hope to get translated package descriptions in as well11:00
mvogreat again :)11:00
mornfallfor i18n, well, yeah, libapt-front is a bit behind, i didn't really get around that... shouldn't be -that- bad though11:00
mvoit should be really easy (if it gets in and I get matts ok etc) for you to hook into it11:01
mornfallbtw, is there some plan to work on the fetcher api?11:01
mornfallit's a bit... klunky11:02
mornfalli was thinking about just redoing it around libcurl, but haven't gotten any further than contemplating11:02
mvowe have at least some documentation for it now (in the --doxygen branch that will be mreged when I come back)11:02
mvoyeah, libcurl would be nice (and shuldn't be too hard)11:03
mvoI don't think I'll have a chance to have a look though11:03
mvowhat do you think about some abstraction for "update" and "fetching packages"?11:03
mvothat should be doable in a reasonable amount of time11:03
mornfalli have those in libapt-front11:04
mornfallthey need some work11:04
mvoright, maybe they can be used as a starting point?11:04
mvothe url is daniels paper11:06
Riddellmornfall, 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:06
=== seth_k|lappy [n=seth@d-ip-129-15-215-153.wireless.ou.edu] has joined #kubuntu-devel
mornfallRiddell: start with ept11:08
mornfallRiddell: i also suspect it could be done a lot more efficiently than what gnome-app-install does11:09
Riddellmornfall: efficient in which way?11:09
mornfallRiddell: not needing to make all those .desktop files11:10
mornfallRiddell: it could make use of some sort of icon mapping, but short descriptions (and their translations) and package selection can be done in other ways11:10
mvomornfall: 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
mornfallRiddell: for the first, apt database should do (with i18n support), for latter, i'd prefer debtags11:10
mvomornfall: the other problem is that a major feature is that it represents the menu strucutre11:11
mvoso the menu information must be availabe11:11
mvoit not needed to put it in desktop files of course11:11
mornfallmvo: hmm, okey, that may be a problem... but last time i have seen gnome-app-install, the list was *huge*11:11
mvoyes, that is definitely a problem11:11
mvoit's a design goal to have most useful applications availabe even if the "universe,multiverse" stuff is not enabled11:12
mornfalland reflecting a menu structure, you need the icon and categories (and that's about it)11:12
mornfalland those can be done easily with debtags, i'd say11:12
mornfalljust make special-icon and special-category facets11:12
mornfalldebtags supports multiple data sources well11:13
mornfallso you can ship this separately11:13
mvoright, so if it can be done in that way I don't really mind11:14
mornfallokey, there's still a problem with packages having multiple binaries11:14
mvoI just want to tell why we did it that way :)11:14
mvo(knowing that it's not really the most elegant way)11:14
mornfallif you stick to the .desktop files, i can still easily parse them11:15
mvofor 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
mornfalli will just see, i guess :)11:16
mvobut it's fine of course if you just use this desktop files and convert them to something else :)11:16
Riddellmornfall: any thoughts about making the sources.list editor more friendly11:17
Riddelli.e. at the moment it's just a grid of sources.list, but synaptic does nice things to make it more human readable11:17
mornfallmvo: if something, i'll probably convert it to a tagfile and add support for it to libapt-front11:17
mornfallRiddell: well, there's a definitive problem with synaptic's one -- you can't just paste a sources.list line you get there11:17
mvook, it would be nice if you would keep me in the loop if you do it11:17
mornfallRiddell: which is probably the most common use case ever11:17
mornfallmvo: sure11:18
mornfallRiddell: the other would be enabling/disabling/removing lines and adding/removing components11:18
mvothere is a "custom" button to paste sources.list entries11:18
mvowe hopefully have sources.list.d support soon 11:18
mornfallmvo: oh, why that? sources.list.d sounds evil11:19
mornfallmvo: i definitely hate it in apt-rpm11:19
mvomornfall: why don't you like it?11:19
mvolooks very useful to me?11:19
mornfallmvo: it complicates nearly everything related to managing sources11:19
mornfallmvo: want to disable one? need to find which file it is in... want to add one? need to figure where it belongs11:20
mvobut that's really not too hard. it makes adding stuff to sources.list in a automatic way incredible easy11:20
mornfallmvo: 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 overkill11:21
mornfallmvo: and adding to a flat file is hard?11:21
mornfallmvo: 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 latter11:21
mvomornfall: 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 nervous11:22
mvosources.list files tend to get pretty big for users quickly. especially if we get more sources.list entries (something that is planed)11:23
mornfallmvo: 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
mvoobviously there will be some sanity checks, but I tend to think of the sources.list.d think as something that should really be auto-managed11:23
mvobut I agree that it's not perfect and has some semantic problems. but that can be easily hidden from the user11:24
mornfallmvo: unless he tries to use a text editor on it (and many will)11:25
mvoI tend to think that it really should be fine11:25
mvoi'm pretty sure we will get it, but we won't force anyone to use it11:25
mvoit's all optinonal11:25
mvoand there is a open whishlist bug about it on the debian page that is really old11:26
Riddell* mvo runs to the toilet11:26
mornfallas long as you keep the sources.list file and it takes precedence, i'm all fine with it11:26
mornfall(you actually make life harder for libapt-front too, since i will have to add code to merge those files)11:27
Riddellmornfall: 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 things11:28
mornfallRiddell: if you think bounty is possible, why not11:28
mornfallRiddell: i did it once, guess i can do it again :)11:28
mornfallif no, well, no catastrophe happens11:29
mvomornfall: sources.list will still be available, yes11:29
mornfalland i always need cash, i'm a poor guy11:29
mornfallmvo: btw, i'm wondering how to approach with the libapt vs libapt-front split...11:30
=== mvo makes his own life harder as well as the synaptic edito will need to cope with it as well
mornfallmvo: the overlap is growing...11:30
mvoin what way?11:30
mornfalllet's say sources.list parser11:31
mornfalli have my own, that can also write out the file11:31
mornfalland do changes to it11:31
mvoright. would that we something that can be ported to libapt?11:31
mvoor do you rather want to have it seperated?11:31
mornfallmvo: the problem is, it's written using apt-front/utils... so direct port to libapt is not feasible11:32
mvoI think the overlap should be as small as possible11:32
Riddellsurely libapt already has a sources.list parser?11:32
mvowhat bits of utils are needed and can they be put into libapt?11:33
mornfallnow, the problems are: libapt is managed with baz/bzr, libapt-front with svn/svk11:34
mornfalllibapt-front api is radically different from libapt11:34
mvois that the case for stuff like "sources.list" class as well?11:34
mvohave you tried bzr yet? you may like it, it's really well done (also very new)11:35
mornfallwell, libapt-front's aptFront::Sources uses c++ stream operators11:35
mvowe will be able to merge from svn in the future as well11:35
mvobzr will support that11:35
mornfalland it's using aptFront::utils::Range11:35
mornfallrange in turn needs multitype and shared pointer implementation11:36
mvoIMHO apt can't be switched to libapt-front easily, so we will have to see what can be merged in the best possible way11:36
mornfall*and* i need to be flexible in changing all of this11:37
mvoright, but that is a problem11:37
mornfalli am used to xp/agile style development11:37
mornfallaggressive unit testing, refactoring on the go11:37
mvoI mean, if you need to be flexible, you need to maitain it in your own branch11:37
mornfallwell, i have libapt-front because of that11:38
mvoyes, I know that11:38
mornfallquestion is, if we can converge this somehow11:39
mvoI 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
mornfalli of course could branch of libapt and merge it into libapt-front... but that's not very useful11:39
mvowhy would you want to merge from libapt?11:40
Riddellmornfall: what's the reason for libapt-front to have its own sources.list classes if libapt already does (better API?  more functionality?)11:40
mvoI mean, it's fine to branch from it11:40
mornfallRiddell: both better api and ability to modify the file11:40
mvobut it would be rather unfortunate if you would need your own libapt to support libapt-front ...11:40
mornfallmvo: well, i will eventually reimplement many parts of libapt, so i won't need -much- of it11:42
mornfallmvo: the graph/database access api is first11:42
mornfallmvo: also sources.list11:42
mornfallmvo: i am contemplating the fetcher rewrite11:42
Riddellmornfall: is your hope to eventually obsolete libapt by libapt-front?11:43
mvoyou 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 time11:43
mornfallRiddell: i don't know... i'd prefer a merge of some sort11:43
mornfallmvo: yes i know11:43
mornfallmvo: i don't say rip libapt11:44
mornfallmvo: i can't replace it in the short-term, anyway11:44
mornfallmvo: what i can do is reimplementing the commandline tools with it and making them comparable to apt's own11:44
mvoI 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 well11:44
Riddellmornfall: I think you should start to throw stuff back at mvo where it would be good for libapt to use what's in libapt-front11:45
mornfallRiddell: that probably won't work, as i need my hands free for development... putting to libapt is sort of like casting it into stone11:46
mornfallsince i have very little influence over apt development, depending on some branch of it would kind of kill me off11:47
mornfallit was enough of a problem with konsolepart, which is much less central to the system11:47
mvomornfall: my point is that you can have a *lot* influence in it's development11:47
mvomornfall: there aren't that many people working on it (matt,me,dburrows)11:48
mvoso it's really easy to influce it's development11:48
mvomy problem is that I can't really put stuff like translated package descriptons into libapt-front because apt won't be able to use it11:49
mvoso I tend to think that certain things have their place in libapt and others in libapt-front11:49
mornfalli'm not sure what has (inherent) place in libapt-front11:49
mvoyou want to have (eventually) everything in libapt-front :)11:50
mornfallthat's because i want it to eventually become libapt :)11:50
mornfallthe point is, what belongs to a library separate from libapt11:51
mvook, I have a appointment in a couple of minutes so I won't be able to be around for much longer11:52
mornfallokey, i will just try to make some sense out of all this11:52
mornfallthe most pressing problem i feel between libapt and libapt-front11:52
mvoI 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
mornfallis that we use different paradigms for nearly everything11:53
mornfallfrom version control through development methodology to api11:53
mornfalland coding paradigm and style11:53
mvoyes, 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 it11:55
mvoif that is what you want to do anyway, then that's fine11:55
mornfalli do it right now, i am not sure it's the ultimate goal though :)11:55
mornfallbut, we'll see how things evolve11:55
mornfalldon't miss your appointment :)11:55
mvoas 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
mornfallyes of course11:56
mvo(among other things)11:56
mornfalland that's fine11:56
mornfalli don't oppose that at all11:56
mvoI really really want to have close cooperation between the two projects11:56
mornfalli 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 overlap11:57
mvogreat, so let's have productive 6 months :)11:58
mvoif there is anything I can do for you (and libapt-front) let me know11:58
mornfallwhen 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
mornfalli am trying to keep things as standalone as possible11:58
mornfallright :)11:59
mvoif you are reimplementing those bits, what about rewriting methods/http.cc with libcurl?11:59
mvoor was that not the thing you had in mind?11:59
mvosorry, didn't wanted to come up with another discussion topic12:00
mvoneed to leave, I'll try to follow the stuff as close as I can12:01
Riddellmornfall: 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 bounty12:02
Riddelland the bounty stuff would have to be done soon so we aren't rushing again12:02
Riddellend of meeting12:02
Riddellthanks mornfall, mvo that was useful12:02

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!