[12:17] <manchicken> toma: I think that method just tells it which column to care about with tooltips.
[12:18] <manchicken> toma: But that would still help
[12:18] <toma> manchicken: you want a pixmap and show a tooltip on mouse over or on mouse click?
[12:19] <manchicken> mouse over
[12:19] <toma> ah
[12:19] <Riddell> robertknight: what brings you here?
[12:20] <robertknight> Riddell: I'm just keeping tabs on my distribution
[12:21] <toma> manchicken: you could connect to slotOnItem() and then find out on which column the user hovers
[12:21] <robertknight> Riddell: Actually, I have a quick question about getting a small piece of software into Kubuntu
[12:21] <Riddell> robertknight: what's that?
[12:22] <manchicken> toma: At that point you're assuming that it gives me a signalt at the level I need it.
[12:22] <robertknight> Riddell: Currently there is no easy way for KDE developers to provide users with access to new versions of software to test. (For testing bug fixes, HCI changes, features etc.)
[12:23] <toma> manchicken: it gives you the item so you should be able to determine that
[12:23] <robertknight> Riddell: Something such as Klik or ZeroInstall would be very useful to provide a sandbox for users to run out-of-repo software in a safe way
[12:23] <manchicken> Each cell of a listview should be its own QWidget.
[12:23] <manchicken> This blows.
[12:23] <robertknight> Riddell: Both have very small client programs. I was hoping that it would be possible to get one of those shipped in the default install.
[12:24] <robertknight> Klik in particular is designed to work well with KDE.  After installing the client you can point it at klik:/software-package-name and it downloads and runs the software in MacOS-fashion
[12:26] <robertknight> It isn't a complete solution, but as a way of letting users run an "experimental" version of some softare alongside their stable one provided by the repo.
[12:31] <robertknight> Riddell: This would be for Feisty +1
[12:31] <manchicken> That'd be Gorey Gecko, right?
[12:32] <Riddell> robertknight: people have looked at klik for ubuntu and it's had problems
[12:32] <robertknight> Riddell: What problems?
[12:32] <Riddell> packages being unsigned is one I paticuarly dislike
[12:32] <Riddell> but there were larger problems with getting it working, the linux build needed FUSE or something which it didn't hvae
[12:32] <Riddell> raphink was looking into it
[12:32] <robertknight> Riddell: Klik does work on the current Kubuntu though
[12:33] <yuriy> ryanacka: interesting cover, but i don't like that it has beryl on it
[12:33] <raphink> robertknight: are you willing to help with klik integration?
[12:34] <robertknight> raphink: Yes
[12:34] <raphink> great
[12:34] <raphink> robertknight: do you have contacts with klik devs - probono for ex?
[12:34] <raphink> I began a spec some time ago : https://wiki.ubuntu.com/KlikIntegration
[12:34] <raphink> and we have more infos on the klik wiki
[12:34] <raphink> the idea was to make a systemwide install
[12:34] <raphink> packaging is not the hard part at all
[12:35] <raphink> but making klik work systemwide with fuse support
[12:35] <robertknight> raphink: No, I don't have any connections to the Klik developers at the moment. What I do have is a need to be able to publish updates of KDE software for people to test.
[12:35] <raphink> it's not acceptable to get fuse installed in ~ obviously
[12:35] <robertknight> raphink: Is a system-wide install necessary to begin with?
[12:36] <raphink> robertknight: all programs should be installed in /usr/bin, /bin/, /usr/sbin or /sbin
[12:36] <raphink> there's no reason to install a program in ~
[12:36] <raphink> even if it was doable cleanly
[12:36] <raphink> I don't see a reason for an except with klik
[12:36] <raphink> the klik client should be installed in ~
[12:36] <raphink> it should use fuse
[12:37] <raphink> with special authorization for users in the fuse unix group
[12:37] <raphink> to mount cmg images running the klik client from /usr/bin
[12:37] <raphink> if it's not this way, it's not proper to distribute it
[12:37] <robertknight> raphink: Just to clarify, this is just the client that needs to be in /usr/bin
[12:37] <raphink> what else?
[12:38] <raphink> cmg images can be in ~ without a problem
[12:38] <robertknight> raphink: The .cmg files can still go wherever?
[12:38] <raphink> or ~/Desktop for that matter
[12:38] <raphink> since it's the default behaviour so far iirc
[12:38] <raphink> just as it's firefox default's behaviour to download files in ~/Desktop
[12:39] <raphink> http://klik.atekon.de/wiki/index.php/Dapper
[12:39] <yuriy> manchicken: is it possible to get the rectangle of that cell in the list? and then use maybeTip() to display a tooltip attached to the list only for that rectangle?
[12:40] <raphink> if you need help, you can always ping me robertknight
[12:40] <raphink> and we can work on a proper solution if you're wanting to work on it
[12:40] <manchicken> yuriy: I'm trying to, but I can't get it to call maybeTip()...
[12:40] <robertknight> raphink: I am happy to work on it, scratching an itch and all.
[12:40] <robertknight> raphink: But I want to know whether it will be accepted
[12:41] <raphink> it might be accepted if it's properly done
[12:41] <raphink> and I think i've listed the conditions in my spec
[12:42] <raphink> did you ever make deb packages?
[12:42] <robertknight> raphink: I have only ever modified a few deb packages to incorporate fixes.
[12:42] <robertknight> raphink: I am interested in a solution which is at least potentially cross-distro
[12:42] <raphink> hmmm
[12:43] <raphink> robertknight: then you should primarily work with the klik team to provide a clean tarball
[12:43] <raphink> that installs klik systemwide with fuse support
[12:43] <raphink> with proper conf in /etc, proper binaries in /usr/bin
[12:43] <raphink> and a Makefile to install all this
[12:43] <raphink> then the packaging work will be fairly easy for all distros
[12:44] <robertknight> So the basic task is to make the klik client much more packager-friendly?
[12:44] <raphink> for me
[12:45] <raphink> the main task is to make the klik client installable from a tarball
[12:45] <raphink> by untarring the tarball
[12:45] <raphink> and running "make && make install"
[12:45] <robertknight> Have you discussed this with the klik developers?
[12:45] <raphink> sure
[12:45] <raphink> and we came to the pages I've posted the URIs of
[12:46] <raphink> did you read https://wiki.ubuntu.com/KlikIntegration ?
[12:46] <robertknight> Yes, there is just quite a lot there to get my head around
[12:47] <raphink> sure
[12:47] <raphink> :)
[12:47] <Riddell> robertknight: have you seen the patches we made to konsole recently?
[12:47] <robertknight> Riddell: No, not yet.
[12:47] <yuriy> manchicken: looks like http://www.klaralvdalens-datakonsult.se/docfiles/Chapter_3.6.pdf talks about exactly this, though i'm sure it's all stuff you already know
[12:47] <robertknight> Riddell: Are they changes that should go upstream?
[12:48] <robertknight> raphink: There is a link to a "potential deb package for klik" (dated Feb last year)
[12:48] <robertknight> http://svn.berlios.de/viewcvs/fullstory/klik/trunk/
[12:48] <raphink> I didn't test them
[12:49] <raphink> I'll have a quick look at them before going to bed ;)
[12:49] <robertknight> Perhaps that is a good starting point
[12:49] <raphink> not sure
[12:49] <raphink> depends whether upstream worked on the suitable pionts
[12:49] <raphink> points
[12:50] <raphink> from reading debian/rules
[12:50] <raphink> I'm not happy with this package
[12:50] <raphink> install/klik::
[12:50] <raphink>         dh_installmime
[12:50] <raphink>         cp applnk/directory debian/klik/usr/share/applnk/klik/.directory
[12:50] <raphink>         cp applications/cmgrun.desktop debian/klik/usr/share/applications/.cmgrun.desktop
[12:50] <raphink> this won't be accepted
[12:50] <raphink> 1) applnk is obsolete
[12:51] <raphink> 2) installing invisible desktop files in /usr/share/applications is something I've never seen and I don't understand why it would be done
[12:51] <Riddell> robertknight: http://kubuntu.org/~jriddell/tmp/konsole/kdebase_3.5.5a.dfsg.1-1ubuntu19.debdiff http://kubuntu.org/~jriddell/tmp/konsole/kdelibs_3.5.5a.dfsg.1-3ubuntu10.debdiff
[12:51] <raphink> 3) it doesn't install anything else so I guess running this stuff would copy the klik client into ~, which is not acceptable
[12:51] <Riddell> robertknight: it lets you attach another program's pty to an embedded konsole
[12:51] <Riddell> robertknight: we need it for the dist-upgrade tool for dpkg processes
[12:51] <robertknight> Riddell: I get a 403 error
[12:52] <Riddell> permissions fixed
[12:52] <robertknight> Riddell: There is at least one open bug report asking for the ability to attach to an arbitrary PTY in Konsole
[12:53] <raphink> robertknight: it seems to be on the way to be acceptable
[12:53] <raphink> but I don't think it's the role of the klik team to provide a deb
[12:54] <raphink> they shoudl provide a tarball with a working Makefile to isntall klik systemwide
[12:54] <raphink> then I would be happy to make the package
[12:55] <raphink> I might try to find the time to have a look at it
[12:55] <raphink> but I can't promise
[12:55] <raphink> I think from where it stands now, something good could be done in a short time
[12:55] <raphink> but for now, it's bed time for me :)
[12:55] <robertknight> raphink: Thanks, I will get in touch soon. Have a good night :)
[12:55] <raphink> robertknight: don't hesitate to contact me though :)
[12:55] <raphink> bye
[12:57] <ash211> did anyone here see bug 81768 ?
[12:57] <Ubugtu> Malone bug 81768 in amarok "Don't compile amarok packages with Stack Smashing Protection" [Medium,Confirmed]  https://launchpad.net/bugs/81768
[12:58] <robertknight> Riddell: Thanks for the patch. I will review it for inclusion upstream.
[12:58] <robertknight> Riddell: Is it okay for me to get in touch with Michael Vogt to discuss the finer points?
[12:59] <ash211> apparently SSP on Amarok messes up collection scanning of UTF-8 files
[01:00] <Riddell> robertknight: certainly
[01:01] <Riddell> ash211: any idea how to actually do that?  is it a gcc flag?
[01:02] <ash211> dsas mentioned how to do it yesterday
[01:02] <ash211> let me look through the logs, I forget
 ash211: I think ssp is enabled by default for every package, so as such it's probably amarok that would need changing, but gcc, that said it probably needs a decision from the amarok maintainers.
 ash211: [snip]  if I recall correctly ssp is not something specified in a debian/rules packaging file but further down the toolchain.
[01:03] <ash211> that's pretty much all I know
[01:05] <ash211> might have found relative info:
[01:05] <ash211> "When building a patched gcc, the ./configure --enable-stack-protector  option can be used to build a gcc which uses -fstack-protector by default. In this scenario, the -fno-stack-protector switch must be used to build a source file without SSP"
[01:05] <ash211> http://d-sbd.alioth.debian.org/www/?page=ssp
[01:06] <ash211> so using -fno-stack-protector looks like it would work
[01:07] <Riddell> ash211: fancy having a go at making .debs with that flag?
[01:07] <manchicken> SWEET!
[01:07] <ash211> I've never done any MOTU work, so I'd be quite inefficient in a first shot
[01:07] <manchicken> It's calling maybeTip() now.
[01:08] <ash211> no packaging, I mean
[01:08] <yuriy> : )
[01:09] <Riddell> ash211: I nee#d to go to bed now, but give it a shot if you want, apt-get source amarok, edit debian/rules with adding CXXFLAGS := -fno-stack-protector  and see if that works, debuild to build
[01:09] <ash211> I'll see what I can do
[01:10] <ash211> thanks
[01:12] <Riddell> ask here or #ubuntu-motu for help
[01:13] <ash211> i've been compiling svn amarok for a while, so it's just the packaging I'm unfamiliar with
[01:13] <ash211> it's download the .tar now :)
[01:19] <ash211> do I run debuild in the amarok-1.4.4 directory?
[01:28] <manchicken> yuriy and toma are both my heroes.
[01:28] <toma> manchicken: did i help?
[01:28] <manchicken> Yup.
[01:31] <manchicken> Could someone me with the copy for this tooltip?
[01:31] <manchicken> I came up with: This logo indicates that this package is officially supported by the Kubuntu development and support teams.
[01:31] <manchicken> I'm guessing we'll need internationalization as well...
[01:33] <manchicken> Weaksauce
[02:02] <manchicken> Patch submitted.
[05:53] <Hobbsee> anyone feel like upgrading kipi plugins
[05:53] <Hobbsee> ?
[06:14] <Mez> Hobbsee, no idea what they are
[06:14] <Hobbsee> Mez: used in digikam. it's in main.
[06:14] <Hobbsee> dunno who usually does it / if they plan to
[06:14] <Mez> Hobbsee, changelog?
[06:15] <Hobbsee> ie, havent looked
[07:02] <manchicken> Hobbsee: https://wiki.ubuntu.com/MikeStemleJr ^_^
[07:04] <Hobbsee> manchicken: nice :D
[07:04] <manchicken> I like it ^_^
[07:04] <Mez> hmm
[07:05] <Mez> why does qtparted not have an option to create an ext3 partition
[07:07] <Hobbsee> manchicken: :)  going for membership, or what?
[07:07] <Hobbsee> Mez: because it doesnt like you...
[07:08] <manchicken> I'd be lying if I said no, but it's not at the top of my priorities.
[07:08] <manchicken> I'm just having fun hacking.
[07:09] <Hobbsee> manchicken: ahh :)
[07:09] <Hobbsee> manchicken: usually people only update them when someone's explictly going to look at them, ie membership :P
[07:10] <manchicken> Ah.
[07:11] <manchicken> I didn't have one.
[07:12] <manchicken> But no, I wouldn't have a problem being considered for membership ;)
[07:13] <Hobbsee> hehe
[07:15] <nixternal> Hobbsee: -1 on him and membership :)
[07:15] <Hobbsee> nixternal: *grin*
[07:15] <nixternal> hehe
[07:15] <nixternal> I was supposed to do a lot of work today, and did absolutely nothing
[07:16] <nixternal> and now it is time to goto bed
[07:16] <nixternal> hopefully I can work on some stuff tomorrow
[07:16] <manchicken> Wow.
[07:16] <nixternal> or today
[07:16] <nixternal> hehe
[07:17] <manchicken> Totally burned.
[07:18] <nixternal> g'nite!
[07:19] <Hobbsee> night nixternal!
[07:21] <yuriy> manchicken: i didn't realize i actually said anything helpful but thanks for mentioning me :)
[07:22] <manchicken> yuriy: That PDF was the breakthrough I needed.
[07:22] <yuriy> ah
[07:22] <yuriy> google is your friend ;)
[07:24] <manchicken> I'd been googling all week off and on.
[07:24] <manchicken> I guess I just didn't go deep enough.
[07:26] <yuriy> heh looks like i was looking for this a day early: http://dot.kde.org/1169902218/
[07:27] <Hobbsee> hehe, yeah
[07:35] <manchicken> Hobbsee: Would I be premature in going for membership?
[07:38] <Hobbsee> manchicken: dunno
[07:39] <manchicken> Nor am I.
[07:39] <manchicken> either way.
[07:39] <Hobbsee> i'm sure i should know though
[07:39] <manchicken> heh
[07:41] <ajmitch> yes, you should
[07:55] <yuriy> wow they even made it so you don't have to put in the .h when including qt4 libraries. neat.
[07:58] <manchicken> That's a C++ thing.  I never understood what the big deal was.
[08:00] <yuriy> hmm really? because there is a little "qt include syntax" section in the project options for qt3 style or qt4 style so i thought it was a qmake thing
[08:01] <manchicken> I would think includes are C/C++ preprocessor...
[08:02] <yuriy> well it is in the c++ support section
[08:03] <manchicken> Either way, I never understood what the point was.
[08:03] <manchicken> Either way.
[09:02] <wgw> hey kwwii, are you active at the moment?
[09:59] <Lure> python-dbus 0.80.1 breaks quidance-power-manager ;-(
[09:59] <Lure> mainloop is now explicitly required by dbus.SystemBus()
[10:00] <Lure> sebas: ^^^
[12:50] <hunger> Wow, you are fast, guys! I just wanted to ask about kdevelop 3.4 and it is already available in feisty.
[12:55] <mhb> hunger: edgy too
[12:55] <hunger> mhb: Wow!
[12:55] <hunger> I am impressed!
[12:56] <Lure> hunger: thank Riddell!
[12:56] <hunger> Riddell: Thank you! You rock!
[12:58] <Hobbsee> Riddell blushing?
[12:58] <hunger> Hobbsee: I sometimes have that effect on men;-)
[12:58] <Hobbsee> hunger: uh....
[12:59] <hunger> Hobbsee: Unfortunately never on women;-)
[12:59] <Hobbsee> poor you :P
[01:02] <mhb> who's responsible for guidance-power-manager?
[01:03] <mhb> == who works on it :o)
[01:03] <Riddell> mhb: we all do!
[01:03] <mhb> hmm
[01:03] <hunger> will that stay the pm of the day in feisty?
[01:04] <Riddell> yes
[01:04] <mhb> is it normal that it takes 128MB RAM after a while ?
[01:04] <hunger> kpowersave was much nicer... too bad.
[01:13] <marseillai_> mhb: hunger wait for 0.7.1 version .... there's no more powersaved dependency
[01:22] <Riddell> freeflying: your dapper CDs arrived back at my flat the other day
[01:22] <freeflying> Riddell: dapper's?
[01:23] <Riddell> freeflying: yes, big box I sent you for dapper release
[01:23] <Riddell> it must have gone half way around the world and back
[01:23] <freeflying> :)
[01:24] <freeflying> but I javen't heard of anything about it here  :)
[01:32] <jeroenvrp> KDevelop 3.4 Released with Kubuntu Packages: the 'read more' link links since yesterday to http://kubuntu.org/announcements/kde-356.php
[01:32] <Riddell> jeroenvrp: that's the correct page
[01:33] <jeroenvrp> mm
[01:33] <jeroenvrp> oh yes
[01:33] <jeroenvrp> I see it
[01:33] <jeroenvrp> confusing
[01:33] <Riddell> I'll change the headline
[01:33] <jeroenvrp> good
[01:35] <Riddell> voila
[02:49] <imbrandon_> err
[02:57] <Hobbsee> hey imbrandon
[02:58] <Hobbsee> imbrandon: did you want to package up 1.4.5 when it's released, or did you want me to?  (amarok)
[04:01] <MetaBookfoziS> hi all
[04:01] <MetaBookfoziS> i'm a beginner in this case, but i want to help the community
[04:02] <MetaBookfoziS> so i have seen on kde-apps somebodys publicates packages related to other kde projects
[04:02] <MetaBookfoziS> so i wanna ask, if i create a pkg with checkinstall, can i just publicate that?
[04:02] <MetaBookfoziS> or has it a secret that i don'T know
[04:03] <Jucato> btw, checkinstall isn't recommended for creating correct and proper Kubuntu packages, afaik
[04:03] <MetaBookfoziS> but i'm only have know that, and i have succesfully maked a package for krusader 1.80-beta1 and polyester 1.0
[04:04] <MetaBookfoziS> the latest in kubuntu erpos is 1.70 and 0.99
[04:04] <MetaBookfoziS> so i think this is usefull for who can't compile thats or don'T want to install gigs of devel packages:)
[04:05] <MetaBookfoziS> and, krusader won't ./configure-s because it finds at the wrong path the italian documentations, so that need to modify.
[04:05] <MetaBookfoziS> so i just want upload these packages, if no other judgement
[04:11] <fdoving> MetaBookfoziS: join #ubuntu-motu and ask about making proper packages. we don't recommend using checkinstalled packages. :)
[04:12] <MetaBookfoziS> but that is aproblem?
[04:12] <Jucato> (he won't listen to me... so better let a MOTU say it...)
[04:12] <MetaBookfoziS> i think i'm don't udnerstand something:)
[04:13] <fdoving> making checkinstall packages and distributing? - well the problem is that checkinstall install packages to whereever the upstream project wants to place the files, in ubuntu and other distros specific files must be placed at their proper locations, for everything to work out properly.
[04:13] <Jucato> MetaBookfoziS: if you want your package to 1) be accepted into Kubuntu (if you want to contribute it) or 2) be acknowledge as a properly built package for Kubuntu, then you'd have to follow that guide and *not* use checkinstall
[04:14] <fdoving> MetaBookfoziS: also, we have rules for including the correct copyright information, and licenses with the packages we make, that way we ensure to distribute the software legally.
[04:14] <MetaBookfoziS> oh yes, but i'M only wanted first to only publicate that on kde-apps, not to the official packages, i haven't got enough time for that, and maintain and etc
[04:14] <MetaBookfoziS> just i saw, checkinstal creteed a package and i thought about it:)
[04:14] <MetaBookfoziS> a+e-
[04:15] <MetaBookfoziS> but okay, if i'm at home, i read that doc you linked
[04:15] <Jucato> MetaBookfoziS: well, even if just for kde-apps. if you want to ensure that your package will not give problems on Kubuntu systems, wouldn't you want to build it properly from the very beginning? :)
[04:16] <MetaBookfoziS> ehm
[04:16] <MetaBookfoziS> ok:)
[04:21] <MetaBookfoziS> brb, good bye
[09:24] <hunger> Is it possible thta guidance-power-manager is leaking memory?
[09:24] <crimsun> anything's possible.
[09:24] <crimsun> does valgrind affirm it?
[09:25] <hunger> Virt size 985MB, RES 648MB...
[09:26] <hunger> crimsun: Haven't tried, but top says it is the app using 90% of my memory... next up with regard to memory consumption is konqueror using 6%.
[09:31] <crimsun> suspicious, certainly. Hopefully you're not using compiz/beryl, too.
[09:32] <hunger> crimsun: nope. just plain x.org.
[09:34] <crimsun> I would follow with a valgrind trace, then.
[09:55] <hunger> does valgrind work with python apps?
[10:07] <manchicken> Damn, why didn't anybody tell me how deep launchpad and bzr worked together?
[10:07] <manchicken> This is sweet.
[10:07] <manchicken> Though konq still seems to have trouble rendering launchpad.  Hopefully that'll be better in kde4.
[10:11] <Tm_T> manchicken: ?
[10:11] <manchicken> Tm_T: Wuddup?
[10:11] <Tm_T> What rendering trouble?
[10:17] <Lure> hunger: edgy or feisty?
[10:17] <hunger> Lure: feisty.
[10:17] <ajmitch> manchicken: it's barely scratching the surface of bzr integration so far
[10:18] <manchicken> Good.
[10:18] <Lure> hunger: interesting... it does not grow here... Can you start it from Konsole to see if it prints any messages out?
[10:18] <manchicken> Tm_T: Just slow to render.  that's all.
[10:18] <manchicken> ajmitch: Is it a good idea to link branches to specs?
[10:18] <ajmitch> manchicken: why not?
[10:18] <manchicken> Dunno.
[10:18] <manchicken> Not sure if it's being too forward or not.
[10:18] <ajmitch> depends
[10:19] <ajmitch> branches should also link to bugs soon
[10:19] <hunger> Lure: power-manager: ERROR: Communication problem with power-manager, it probably crashed.
[10:19] <manchicken> I'm not a big-time contributor by any means, but I would like to make sure that folks looking at the specs know which use cases have been implemented.
[10:19] <Lure> hunger: ignore that one ;-)
[10:19] <Riddell> Lure: I've had other complaints about guidance using lots of memory in feisty
[10:19] <hunger> Lure: "Warning: policy from config file not supported", but nothing else.
[10:19] <manchicken> Riddell: How's it going?
[10:20] <Riddell> manchicken: how's what going?
[10:20] <manchicken> Riddell: Life, liberty, and the persuit of happiness.
[10:20] <manchicken> Or whatever.
[10:20] <manchicken> ^_6
[10:20] <Lure> Riddell: it may be that sebas and me do not see this as we are restarting it too often ;-)
[10:21] <Riddell> life is good, liberty was good but then I read that Bill Gates is coming to the Scottish Parliament on Tuesday, and I'm always ecstatically happy
[10:21] <Lure> Riddell: btw, python-dbus 0.80 upload broke powermanager
[10:21] <Riddell> erk
[10:21] <manchicken> Riddell: Persuit of happiness?
[10:21] <Lure> Riddell: say hello to Bill in my name ;-)
[10:22] <manchicken> Riddell: Should I be linking branches to these adept specs as I complete features?
[10:22] <Riddell> manchicken: linking branches?
[10:22] <manchicken> I figured folks may want to know... but I'm not sure if that's how we do things.
[10:22] <manchicken> Yeah, in launchpad you can link branches to specs.
[10:22] <Riddell> didn't know that, but sounds like a useful idea
[10:22] <manchicken> Okie dokie.  I'll carry on then.
[10:23] <manchicken> I got my tooltips in there.
[10:23] <manchicken> Now I'm trying to decide whether I want to experiment with the sources editor thing, or stick changelog support into the updater.
[10:24] <manchicken> I'm thinking changelogs.
[10:24] <manchicken> right now there's zero changelog support there.
[10:25] <manchicken> Whereas there is some sources.list support.
[10:26] <manchicken> Okay, I have my branches linked to that spec.
[10:26] <manchicken> I've been kinda playing with launchpad last night and again this afternoon.
[10:30] <Riddell> I'm looking at the sources editor, I've already started it
[10:30] <Riddell> changelogs would be cool
[10:31] <manchicken> Okie dokie.
[10:31] <manchicken> Are you doing the python conversion?
[10:32] <manchicken> I still think that with the massive undertaking that port would be, it might be easier to just implement the UI change by updating the existing adept interface.
[10:32] <manchicken> That's just going to be a long, tedious port.
[10:32] <Riddell> it's not too massive, I've done the UI
[10:33] <Riddell> just need to do the functionality
[10:33] <Riddell> and bits can be missed out if time runs out
[10:34] <manchicken> That's cool.  You know the proggy better than I.
[10:34] <manchicken> I've never even used that program before.  Only adept.
[10:39] <manchicken> Riddell: You got some time to /msg for a bit?
[10:45] <Riddell> manchicken: ok
[11:06] <Zerlinna> ping Riddell
[11:13] <Riddell> hi Zerlinna
[11:14] <Zerlinna> hi Riddell :-) ... is it true that as a member one can have an something@kubuntu.org alias?
[11:15] <Riddell> yes, it is indeed
[11:15] <Riddell> it works with your launchpad username
[11:15] <Zerlinna> great
[11:16] <Zerlinna> how can I get it?
[11:16] <Riddell> it should work automatically
[11:16] <Zerlinna> oh... wow.. then I'll just try it out :D
[11:16] <Zerlinna> thank you
[11:25] <Riddell> working?
[11:26] <manchicken> Are kubuntu members also ubuntu members?
[11:26] <Riddell> yes
[11:26] <manchicken> Launchpad has all of those "this group is related to this group" thing at the bottom, but it's not worded very clearly.
[11:26] <Riddell> but ubuntu members aren't kubuntu members, so you get two for one with us :)
[11:27] <crimsun> clever.
[11:27] <manchicken> heh
[11:27] <ajmitch> the rest of us mere ubuntu members are disenfranchised
[11:28] <Zerlinna> Riddell: not by now.. where is it forwarded, to the "preferred contact adress"?
[11:29] <Riddell> Zerlinna: yes
[11:38] <raphink> if anyone is willing to have a look at http://revu.tauware.de/details.py?upid=4221
[11:38] <raphink> it would be nice
[11:38] <raphink> this is a very promising app :)
[11:38] <raphink> s/very/_VERY_/