[00:14] <Riddell> claydoh: http://jasmine.19inch.net/~jr/tmp/adept/
[00:14] <Riddell> install adept_manager and run   kdesu "adept_manager --dist-upgrade-devel-lts"
[00:15] <claydoh> Riddell: thanks!
[00:15] <claydoh> wow kde3 feels
[00:15] <claydoh> 'wierd"
[00:16] <claydoh> wrong word,  rather
[00:17] <Riddell> claydoh: hmm, the upgrade doesn't work :(
[00:18] <Riddell> claydoh: but do let me know if the adept deb works though, and comment on bug 439706
[00:19] <claydoh> Riddell: will do
[00:50] <JontheEchidna> My dad is mad at his computer for suspending on him because the KNotification has such a tiny button and only gives him 10 seconds, which is a problem with a touchpad mouse
[00:51] <JontheEchidna> (He uses Fedora, so no patch)
[00:51] <Riddell> there's a thread on kde-core-devel that might be interested in that :)
[00:52] <JontheEchidna> all he did was unplug the power cord. Should powerdevil really be suspending?
[00:54] <neversfelde> Riddell: german is still broken on my desktop
[00:55] <neversfelde> I did not test french and should not do it, because I cannot understand it :)
[00:56] <spstarr> erm
[00:56] <spstarr> any reason we compile usb into kernel and not module?
[00:56] <spstarr> cannot mount usbfs?
[00:56] <spstarr> ??!
[00:56] <spstarr> you have to make usbcore a module to use usbfs I thought
[00:57] <Riddell> modules are slower to load?
[00:57] <Riddell> #ubuntu-kernel are more likely to know than us humble desktop types
[00:57] <yuriy> hmm no hanging apport-kde here. who still had that?
[00:57] <spstarr> negligible for usbcore i think
[00:57] <spstarr> im gonna ask
[00:57] <Riddell> neversfelde: ok I'll try german at some point (not tonight though)
[00:58] <neversfelde> Riddell: I am not at home till monday, so I cannot test it there. No problems on this machine so far, I'll keep an eye on other german speaking karmic users
[01:11] <neversfelde> where is the council vote?
[01:14] <nixternal> yuriy: wasn't it rgreening who had the apport-kde issue?
[01:14] <yuriy> nixternal: maybe. i'll ask when he's around
[01:15] <yuriy> blueeyed also had an issue with it not working if apport-kde is not installed, even if apport-gtk is, so gotta look at that
[01:16] <yuriy> nixternal: and then there's the problem with everything being labeled as kdelibs, did you get to look into that?
[01:19] <nixternal> I believe that might be due to the patch in kdelibs for khelpmenu
[01:19] <nixternal> but I am not 100% sure
[01:20] <nixternal> we could try to change it from doing PID to app name in the patch and see if that fixes it
[01:20] <yuriy> nixternal: this isn't related to that patch, it comes up when using ubuntu-bug with a pid
[01:21] <yuriy> my guess is it's an apport problem, it's probably parsing the process name as in ps and gets "kdeinit"
[01:22] <yuriy> nixternal: i'm looking at the apport_not_drkonqi patch and IIJM or is it forgetting to close the /etc/default/apport file?
[01:22]  * yuriy isn't very familiar with QFile
[01:24] <nixternal> hrmm
[01:30] <yuriy> nixternal: also I put up a patch for bug 415237 a few days ago. i guess that's for -backports now
[01:33] <nixternal> sweet, greasemonkey scripts + chromium == super love!
[01:36] <seele> didnt we change it to 30 seconds?
[01:44] <ScottK> JontheEchidna: The controversy over the patch wasn't over the amount of time (IIRC the change to extend it to 30 seconds is already in trunk).
[01:44] <ScottK> claydoh: Link me and I'll work on it in an hour or two.
[01:45] <ScottK> seele: We (and upstream) both did.
[01:45] <seele> ok that's what i thought
[01:48] <ScottK> seele: I played with the dialogue a bit today (ran the laptop out of power, charged for a few mniutes, then ran it down again) and I actually find the dialogue less "HEY PAY ATTENTION" than the notification was.
[01:49]  * ScottK guesses because he sees dialogs all the time and they are never very urgent or suprising.
[01:52] <seele> ScottK: expecting it and having it popup over and over sortof desensitizes you during the experiment ;P
[01:53] <seele> ScottK: actually i talked to sebas about it the other day, we're going to work out something else
[01:53] <seele> his and aarons issue had to do with the implementation
[02:01] <nixternal> holy smokes I am starving...who wants to take me to dinner?
[02:10] <seele> i made gnocchi with homemade sauce tonight
[02:11] <seele> but i ates it all
[02:13] <neversfelde> 3:13 am but I am hungry now
[02:13] <neversfelde> thanks seele and nixternal :)
[02:22] <yuriy> wow dr konqi is getting really nice
[02:23] <yuriy> we should borrow some of the UI for apport-kde
[02:24]  * seele coughs
[02:24] <seele> i helped with that ;)
[02:25] <yuriy> seele: nice :)
[02:27] <nixternal> mmm, pb&j ftw!
[02:29] <yuriy> ooh i think i found a way to reproduce the bookmarks toolbar getting enabled
[02:29] <yuriy> can someone try detaching a tab in konqueror and see if the bookmarks bar comes up?
[02:29]  * nixternal tries
[02:30] <nixternal> heh, it crashed konqi for me
[02:30] <yuriy> oh great
[02:31] <nixternal> am I supposed to have the bookmarks bar showing?
[02:31] <yuriy> it isn't showing for me, as default
[02:32] <yuriy> but when i detach a tab, it shows up in the new window
[02:32] <nixternal> hrmm, it might not have for me either, as I am pretty sure I didn't remove it
[02:32] <nixternal> i can't reproduce it, at least I don't think I can...though I could be doing something wrong
[02:33] <nixternal> heh, I just got an email from Facebook of all the people who have invited me since 2005
[02:33] <yuriy> it's not crashing anymore?
[02:34] <yuriy> nixternal: oh, doesn't happen in karmic. good i guess.
[02:38] <nixternal> anyone know off hand if solid can detect drive activity?
[02:51] <ScottK> seele: I'd like to have a resolution on the dialog/notification thing for low power really quickly that gets us off the "Oh, look what they did when we told them not to" list.  Politically, I don't think that can wait.
[02:51]  * nixternal waits for a google wave invitation
[02:51]  * ScottK hands nixternal an invitation to fix some stuff in Kubuntu.
[02:52] <claydoh> ScottK: https://wiki.kubuntu.org/KarmicKoala/Beta/Kubuntu
[02:52] <seele> ScottK: the resolution is whatever aurelian is told to do by his boss. if he isnt told anything then we shouldnt diverge
[02:52] <seele> because the upstream solution isnt going to be done by the time we need it
[02:52] <seele> what is google wave?
[02:52]  * seele feels old and out of syn with the world for not knowing
[02:53]  * nixternal files the invitation in his inbox hoping it gets processed within the next week - GTD!
[02:53] <ScottK> seele: I thought upstream already had a patch to jump out to 30 seconds.  That's the main issue, IMO.
[02:53] <seele> ScottK: right, but in the notification popup thingy not a dialog
[02:53] <ScottK> seele: I think that's fine for Karmic.
[02:53] <seele> the issue with upstream is that they dont like the dialog implementation. they already approved the 30 second thing
[02:54] <ScottK> Right now the world knows KDE said no dialogue and Kubuntu went and did it anyway.
[02:54] <ScottK> So I'd like to see us do a 30 second notification for Karmic and then do whatever is "right" for Lucid.
[02:54] <ScottK> seele: Is that reasonable?
[02:54] <seele> yes, but that's not up to me
[02:55] <seele> i'm not a developer, i dont work on the design team, and i dont have commit rights
[02:55] <ScottK> seele: It's up to KC in the end, so it's part of to you.
[02:55] <seele> i wish this stuff could get resolved without having to go to council all the time
[02:55] <ScottK> I can do the patch, but I don't want to unilateral revert someone else's work.
[02:55]  * ScottK too.
[02:55]  * ScottK thought we had agreed to something other than what happened.
[02:55] <seele> since kde is willing to work together and do it right, but just not right now, then imho we shouldnt diverge from upstream
[02:56] <seele> that means we have the countdown in a notification popup for 30 seconds instead of the dialog
[02:56] <ScottK> I don't think the notification can do the countdown.
[02:56] <seele> if i thought upstream wasnt willing to look into the matter more, my opinion would be different
[02:56] <seele> but i am quite confident they are interested in fixing it, but not in time for karmic
[02:56] <seele> really?
[02:56] <seele> that's lame
[02:57] <seele> can we make it persistent so it doenst dissapear right away?
[02:57] <ScottK> That I'm pretty sure we can do.
[02:58] <seele> the non updating countdown is a problem though
[02:58] <seele> if someone doesnt see it right away they dont know how long 30 seconds really is
[02:58] <seele> (a plus for the dialog unfortunately..)
[02:59] <ScottK> I doubt many people will think "Oh, I can type for another 5 seconds".
[02:59] <seele> is it just the ayatana notifications? people on the core list were talking about the countdown with regard to kde notifications as if it wasnt going to be a problem
[02:59] <ScottK> I agree the countdown is better, but I don't think it's critical.
[02:59] <ScottK> I may be wrong about that.
[02:59] <seele> it *is* critical. if people think 10 seconds isn't long enough, what value does saying "30 seconds to suspend" provide if you dont know how long that 30 seconds is?
[03:00] <seele> especially if you put it in a notification popup which people may not look at until they complete their subtask (such as typing a message or clicking through a menu)
[03:00] <seele> that could take 10 seconds in itself then all of a sudden 30 seconds is actually 20
[03:01] <seele> but whatever, the problem will get fixed, just not immediately
[03:01] <seele> as long as it gets fixed, i think minimizing the differences and going back and forth between designs is more important
[03:20] <yuriy> building kdelibs is always so much fun
[03:21] <ScottK> seele:   agateau already submitted an updated patch to have kmail use of MI default to off, so if we get this sorted, I think we are in line with what was agreed for at UDS for Kubuntu/KDE/Aytana interactions.
[05:22] <ScottK> claydoh: It could stand some editing, but there you go.  Something like that.
[06:25] <ScottK> So I asked my wife if she wanted me to upgrade here to the 4.2.4 backport.  I explained a bit about it and she asked my how I found out about such things.
[06:25] <ScottK> My answer was, "Because I put it there."
[06:25] <ScottK> ;-)
[06:42] <nixternal> ScottK: lol, nice
[06:51] <ScottK> nixternal: We've got a fair amount of Kubuntu Netbook testing that needs to get done yet.  I failed to do it due to getting sucked up in political drama today.  Anything you could do would be appreciated.
[06:51] <rgreening> hey nixternal
[06:52] <rgreening> everyones up late tonight
[06:52] <ScottK> Ohh, rgreening too.
[06:52] <nixternal> what needs to get done?
[06:52] <ScottK> Yes, I need to be up again in 3 1/2 hours
[06:52] <rgreening> yeah, Im just heading to deb after I verify K3B patch works
[06:52] <rgreening> deb=bed lol
[06:52] <nixternal> hehe
[06:52] <rgreening> lysdexic
[06:53] <nixternal> well, heading to deb worked as well, since I figured you would verify the patch, then upload, therefore creating the deb :)
[06:53] <rgreening> lol
[06:54] <rgreening> K3B is in my PPA. fixed the normalize detection :)
[06:56] <rgreening> yay it worked!
[06:57] <ScottK> Kewl.
[06:57] <rgreening> yeah, the patch was simple enough. It just needed some love to get it right...
[07:02]  * ScottK thinks about rgreening giving the patch some love and feel ill.
[07:02] <ScottK> Good night all.
[08:11] <jussi01> curious, I dont seem to be getting updates...
[08:11] <jussi01> have there really been no updates for about a day?
[08:25] <Tonio_> ScottK: kdebluetooth rc1 package ready to upload for post beta
[08:25] <Tonio_> fyi
[08:39] <nookie^> hi! what is the link to kubuntu daily where last kubuntu can be downloaded and tested?
[08:44] <jussi01> nookie^: Im guessing: http://cdimage.ubuntu.com/kubuntu/daily-live/
[08:50] <markey> morning
[08:50] <markey> hmm
[08:50] <markey> WARNING: The following packages cannot be authenticated! ia32-libs tasksel-data tasksel libnm-util1 libnm-glib2 network-manager
[08:50] <markey> is this normal?
[08:55] <nookie^> jussi01: thanx!
[08:59] <jussi01> markey: if you have a ppa, without adding the key, then yes
[08:59] <jussi01> !gpgerr | markey
[09:00] <markey> yes sure, but I haven't added anything recently
[09:00] <markey> that's why I wondered
[09:01] <jussi01> maybe one of your ppa's just updated some stuff?
[09:01] <markey> only ppa I use is chromium's
[09:01] <markey> on karmic, that is
[09:02] <jussi01> hrm, weird. Maybe someone else has an answer?
[09:11] <apachelogger> sweet
[09:11] <apachelogger> userconfig is not speaking german
[09:11] <apachelogger> I wonder why
[09:34] <apachelogger> Riddell: re karmicupgrades wiki page: 1) ... text sez update-notifier-kde -u, screenshot got update-notifier-kde -d
[09:34] <apachelogger> why is that necessary anyway :S
[10:14] <Riddell> I love the taste of Irn Bru in the mornings
[10:15] <Riddell> apachelogger: "update-notifier-kde -d" is necessary because it's always necessary for a beta
[10:21] <Nightrose> Riddell: Oo
[10:21] <Nightrose> irn bru in the morning?
[10:21] <Nightrose> do we have to have an intervention?
[10:22] <jussi01> hah
[10:28] <apachelogger> Riddell: well, yeah, but, that page targets audience of the final release, doesn't it?
[10:28] <apachelogger> so why exactly does update-notifier not notify about the distribution version update
[10:29]  * apachelogger finds it quite doubtable that one has to run a command to get ones distro upgraded
[10:32] <jimhu> Hi, anybody there?
[10:34] <Riddell> ahoy there
[10:35] <davmor2> Riddell: Morning Dude :)
[10:45] <jussi01> apachelogger: I may be wrong, but isnt it that when the new version comes out, they update the update notifier.desktop to run with the the distro upgrade flag? or am I completely off conversation here
[11:13] <jimhu> Hi, anybody there?
[11:17] <Riddell> there are 111 people on this channel
[11:56] <apachelogger> jussi01: do they?
[11:56] <apachelogger> dunno if that is much of a good implementatin if they do
[11:56] <apachelogger> quite in-your-face do-the-upgrade-NOW I would think
[11:57] <apachelogger> on a related matter, wasnt kpk supposed to provide update notifications in karmic?
[11:57] <Riddell> when the new version comes out the meta file on changelogs.u.c is updated and update-notifier-kde will pop up saying an upgrade is available
[11:58] <Riddell> kpackagekit does prompt for package updates in karmic
[11:58] <apachelogger> Riddell: I mean tray icon
[11:58] <Riddell> oh well, you know upstream and their notification plans
[11:59] <Riddell> tray icons shouldn't be there just for notification, that's what the "i" is for
[11:59] <apachelogger> hm
[11:59] <Riddell> the trouble is the "i" isn't at all graphically linked to the notifications so as a user I don't made that connection
[11:59] <apachelogger> oh
[11:59]  * apachelogger just noticed that there are indeed update noticifations :D
[12:00] <Riddell> but assuming you go with the plasma version of notifications then I don't see a need for kpackagekit to have  a systray icon at all
[12:00] <apachelogger> Riddell: you can hide about any progress dialog in kpk, where hide means go to tray
[12:01] <apachelogger> which makes sense for larger operations TBH, even though the hidding does not always work as expected
[12:03] <Riddell> currently it would just be nice if kpackagekit wasn't broken of course
[12:03] <apachelogger> very true
[12:08] <apachelogger> that said
[12:08] <apachelogger> glatzor: is it me or is pkgenpack broken??
[12:09] <glatzor> apachelogger, packagekit service packs are not supported
[12:09] <glatzor> apachelogger, hello
[12:09] <apachelogger> :(
[12:10] <apachelogger> glatzor: is that on some todo?
[12:10] <glatzor> apachelogger, no.
[12:10]  * apachelogger would think online service pack creation would be super useful considering kubuntu networking is broken each release :P
[12:11] <apachelogger> anyway
[12:11] <apachelogger> glatzor: I suppose the pkgenpack stuff should be stripped from the packages then?
[12:11] <Riddell> s/kubuntu/KDE/ while we're going to have tensions with upstream we may as well blame them for their lacking :)
[12:12] <apachelogger> they will blame us back for not using nm-applet
[12:12] <glatzor> apachelogger, makes sense. I will drop it.
[12:12] <apachelogger> kthx
[12:12] <apachelogger> :)
[12:16] <apachelogger> Riddell: bug 396255
[12:16] <apachelogger> since update-notifier only does recommendation of restricted packages these days, I suppose we should get a suitable icon for that
[12:18] <Riddell> apachelogger: commented
[12:19] <apachelogger> Riddell: too intrusive for karmic IMHO
[12:20] <Riddell> I agree
[12:23] <apachelogger> Riddell: how about download-later or download from the actions?
[12:25] <Riddell> apachelogger: I don't follow
[12:26] <apachelogger> Riddell: intermediate fix for karmic: exchange the system-run icon with something more sensible
[12:26] <apachelogger> so I'd like to know what you think about the download and download-later icons
[12:27] <Riddell> apachelogger: I'm currently stuck in a hardy install, got a URL?
[12:27] <apachelogger> sec
[12:27] <apachelogger> http://websvn.kde.org/*checkout*/trunk/kdesupport/oxygen-icons/22x22/actions/download.png
[12:28] <apachelogger> http://websvn.kde.org/*checkout*/trunk/kdesupport/oxygen-icons/22x22/actions/download-later.png
[12:29] <Riddell> I don't think the clock from download-later means anything much
[12:30] <Riddell> the download.png icon has two of the most overused icon elements (arror and earth globe) but is better than what's there currently
[12:31] <apachelogger> http://websvn.kde.org/*checkout*/trunk/kdesupport/oxygen-icons/22x22/apps/preferences-plugin.png
[12:31] <nookie^> in system settings in default view: there is an icon input actions.. i mean is that something that is regulary used or maybe u guys can move it to advanced?
[12:31] <apachelogger> Riddell: preferences-plugin is the only other one suitable
[12:32] <Riddell> apachelogger: I think I prefer download.png
[12:32] <apachelogger> k
[12:32]  * apachelogger tries
[12:32] <apachelogger> nookie^: KDE could
[12:34] <nookie^> apachelogger: will ask someone there
[12:35] <apachelogger> Riddell: http://aplg.kollide.net/images/snapshot041.png
[12:37] <Riddell> apachelogger: good with me.  as a UI change you should OK that with nixternal
[12:38] <apachelogger> nixternal: ok that :P
[12:43] <Sput> apachelogger: I will have to shutdown the quasselcore several times today, as I'm trying to debug our vservers... is this a bad time right now?
[12:43] <Sput> basically I need to reboot every now and then
[12:44]  * apachelogger can use irssi meanwhile :)
[12:44] <Sput> ok
[12:44] <Sput> should be short downtimes, but I do need to try out various kernel settings
[12:46] <Tonio_> Riddell: would you consider the issue is policykit of kpackagekit ?
[12:46] <Sput> brb
[12:46] <Tonio_> Riddell: I can investigate a bit if needed...
[12:46] <Riddell> Tonio_: I've no idea I'm afraid
[12:47] <Tonio_> do we know when it started to crash ?
[12:48] <Riddell> nope
[12:48] <Riddell> although I only heard complains about it this week
[12:48] <Riddell> try testing other frontends first
[13:17] <yuriy> Riddell: what I am seeing now is X starts with a black screen for a second or two, then ksplash starts for about half a second, then kdm. so there's time, but ksplash isn't doing it's job
[13:19] <Riddell> yuriy: yeah, I don't know how to get ksplash started sooner, that's the first KDM script isn't being run from
[13:24] <apachelo1ger_> bug 323459 is quite eww alright
[13:24] <apachelo1ger_> Riddell: I suppose that should be ported to ktoolinvocation for lucid?
[13:25] <apachelo1ger_> or maybe for karmic, dont see how to fix this properly otherwise
[13:27] <yuriy> Riddell: apport-notifier-kde won't use apport-gtk if that's the only one present?
[13:28]  * yuriy wonders if that's correct behavior
[13:28] <yuriy> *update-notifier-kde
[13:28] <apachelo1ger_> hm
[13:28] <apachelo1ger_> lovely
[13:29] <apachelo1ger_> invokeTerminal("/usr/sbin/su-to-root -c /usr/share/apt-file/do-apt-file-update") works but invokeTerminal(self.command) does not
[13:29] <apachelo1ger_> even though self.command is exactly that string
[13:29] <apachelo1ger_> oh
[13:29] <apachelo1ger_> actually it is not
[13:30] <apachelo1ger_> what a drag
[13:30] <Riddell> https://www-admin.kubuntu.org/news/9.10-beta for those who can access it
[13:31] <Riddell> apachelo1ger_: I don't know what apt-file is, I don't think it has anything to do with update-notifier-kde
[13:31] <ghostcube> apt-file is cool
[13:32] <ghostcube> it checks inside packages for files you searching or
[13:32] <Riddell> yuriy: yes that should be changed, shouldn't be hard if you feel in the mood to do it
[13:32] <ghostcube> *for
[13:33] <apachelo1ger_> Riddell: apt-file ships with an update hook that asks to run apt-file update, that hook is processed by update-notifier-kde, and that beast fails to do that properly
[13:33] <Riddell> oh, fooey
[13:34] <JontheEchidna> It'd make me happy if update-notifier-kde was ported to a C++ kded module that used KNotificationItem and KNotifications to notify users of things
[13:34] <apachelo1ger_> here is the good news, porting to ktoolinvocation would fix that
[13:34] <JontheEchidna> even without update notification functionality, update-notifier-kde is somewhat of a memory hog for what it does
[13:34] <apachelo1ger_> the bad news: since the hook command comes with \"'s invokeTerminal refuses to parse it properly
[13:35] <apachelo1ger_> JontheEchidna: +1
[13:35] <apachelo1ger_> super low priority
[13:36] <apachelo1ger_> JontheEchidna: also, I still think it leaks mem
[13:36] <apachelo1ger_> besides the fact that the python runtime env is way too big for that usecase
[13:37] <JontheEchidna> I wouldn't know since I always kill it on startup :P
[13:37] <JontheEchidna> Sysinfo for 'jonathan-desktop': Linux 2.6.31-11-generic running KDE 4.3.1 (KDE 4.3.1), CPU: Intel(R)Celeron(R)CPU2.50GHz at 2499 MHz (4999 bogomips), HD: 101/161GB, RAM: 584/615MB, 131 proc's, 2.0d up
[13:37] <JontheEchidna> ^I don't exactly have memory to spare
[13:38]  * apachelo1ger_ removed it :P
[13:38] <apachelo1ger_> along printer-applet
[13:39] <JontheEchidna> ha, I have about 7 apport-kde processes hanging around from the last crash eating up 41.2 MB ram in total
[13:39] <JontheEchidna> I just do "sudo killall python" every boot up
[13:39] <apachelo1ger_> yah well, that is what you get for using pyware :P
[13:39] <apachelo1ger_> rubyware is so much more shiny
[13:40] <JontheEchidna> speaking of such... I am confused at python
[13:40] <JontheEchidna> I did some work on kcm'ing software-properties yesterday
[13:41] <JontheEchidna> But I can't get the widget inside the kcm: http://imagebin.ca/view/gwEhqH.html
[13:42] <JontheEchidna> and I can't figure out how to make it a child of the KCM without it throwing a traceback
[13:42] <apachelo1ger_> what type is that form thingy?
[13:42] <JontheEchidna> QWidget
[13:42] <apachelo1ger_> weird
[13:43] <apachelo1ger_> parent of that widget is the KCM?
[13:43] <JontheEchidna> here's what I have so far: http://pastebin.ca/1587651
[13:44] <nookie^> Riddell: is this something u can use or should i throw it away? http://imagebin.ca/view/tW2hVN.html
[13:44] <apachelo1ger_> there is nothing like QA
[13:44] <apachelo1ger_> that konsole thingy is so horribly broken
[13:44] <apachelo1ger_> god darn it
[13:45] <JontheEchidna> nookie^: that's nice :)
[13:46] <Riddell> nookie^: it's very nice, but I don't have anything to do with the CD artwork myself
[13:46] <nookie^> JontheEchidna: thank you
[13:46] <Riddell> nookie^: but put it on kde-look and I suspect people will find uses
[13:46] <Riddell> nookie^: also s/in/the/
[13:46] <nookie^> Riddell: i was thinking about to put it on webpage when its time to announce 9.10
[13:46] <apachelo1ger_> JontheEchidna: could you push somehwere?
[13:46] <nookie^> i did something similar for 8.10 i think
[13:47] <apachelo1ger_> JontheEchidna: I should get going to get a new hair cut :D
[13:47] <JontheEchidna> apachelo1ger_: k, I'll have the thing in bzr by the time you get back
[13:47] <JontheEchidna> but you'll have to manually copy a few things, I haven't gotten it installing yet
[13:47] <seele> JontheEchidna: i think rgreening was working with KCMs at some point, he might be able to help
[13:47] <yuriy> JontheEchidna: agreed on u-n-k, maybe we should put that up as a Todo for Lucid in hopes someone will grab it :)
[13:47] <JontheEchidna> yuriy: if nobody does I'll probably at least give it a shot
[13:48]  * apachelo1ger_ hopes someone will fix stuff rather than redoing implementations
[13:48] <yuriy> Riddell: i'll add that to bug 439758. i have a patch for kdelibs, but need to fix update notifier to take advantage
[13:50] <yuriy> Riddell: is it ok to just fix u-n-k in bzr or do i need to work on the package?
[13:51] <Riddell> yuriy: bzr is fine
[13:51] <Riddell> so long as we remember to package it after
[13:51] <Riddell> nookie^: depends if there's anything better at release time :)
[13:52] <nookie^> Riddell: gr8 =))
[13:52] <Riddell> nookie^: do you know if anyone has made countdown images for karmic?
[13:52] <nookie^> Riddell: i really have no idea
[13:52] <nookie^> i havent seen anything yet
[13:53] <Riddell> nookie^: should you feel the artistic urge that would be useful :)
[13:59] <nookie^> Riddell: how big should they big in pixels
[13:59] <nookie^> and
[13:59] <nookie^> how many days?
[14:00] <nookie^> be big*
[14:01] <Riddell> nookie^: able to fit in the "latest update" banner at the top of  kubuntu.org
[14:01] <Riddell> nookie^: dunno, how many days are there to release? :)
[14:02] <Riddell> KarmicReleaseSchedule will know
[14:02] <nookie^> Riddell: thats quite huge banner
[14:03] <nookie^> and it should fit inside the homepage aswell
[14:03] <nookie^> i mean into the colors =)
[14:03] <Riddell> nookie^: well say 250 wide and as tall as that banner
[14:03] <Riddell> or tall enough to fit in it sensibly
[14:04] <nookie^> yeah
[14:04] <nookie^> october 29 th
[14:04] <nookie^> so 28 days
[14:09] <jimhu> Hi, anybody there?
[14:09] <Riddell> jimhu: we're still here
[14:10] <jimhu> Hi
[14:10] <jimhu> I want to report a bug here
[14:10] <jimhu> i've already reported on launchpad, but nothing happened then
[14:11] <jimhu> so the Loco team suggest me to report bugs directly here
[14:13] <jimhu> When i install ntfs-config,  the installer create a link in kickoff menu which runs the command "gksu ntfs-config".  Since default Kubuntu install doesn't include gksu, it was not able to run ntfs-config from kickoff menu.
[14:15] <Riddell> ooh that's not good
[14:15] <Riddell> jimhu: what's the bug number?
[14:16] <jimhu> https://bugs.launchpad.net/ubuntu/+source/ntfs-config/+bug/329095
[14:18] <Riddell> jimhu: do you have su-to-root installed?
[14:18] <jimhu> no
[14:19] <Riddell> jimhu: I'm in the middle of an upgrade so can't do much except irc currently.  could  you check if packages.ubuntu.com has su-to-root in a  package somewhere
[14:20] <JontheEchidna> !find su-to-root
[14:20] <JontheEchidna> Riddell, jimhu^
[14:20] <Riddell> genius
[14:21] <jimhu> sure. a moment please
[14:21] <Riddell> JontheEchidna: could you install menu and check if making the .desktop file use su-to-root works?
[14:21] <JontheEchidna> Oh man this is awesome. Within an hour of upstreaming complete backtraces, Dario Andres fixed KDE bug 193560 and KDE bug 203325
[14:22] <JontheEchidna> just in time for KDE 4.3.2 too
[14:22] <jimhu> Riddell: There is no su-to-root package
[14:22] <nookie^> Riddell: http://imagebin.ca/view/x1O9Ez.html
[14:22] <nookie^> is this too big?
[14:22] <JontheEchidna> jimhu: su-to-root lives in the "menu" package
[14:22] <nookie^> because its hard to fit anything in that lightblue color
[14:23] <nookie^> which is originaly in the banne
[14:23] <nookie^> r
[14:23] <JontheEchidna> Installing su-to-root doesn't work
[14:24] <JontheEchidna> gksu is indeed hardcoded: Exec=gksu ntfs-config
[14:25] <JontheEchidna> New Qt released: http://labs.trolltech.com/blogs/2009/10/01/qt-453-released/
[14:25] <Riddell> JontheEchidna: crivvens
[14:28] <JontheEchidna> Hmm, the changeset looks smaller than usual: http://qt.nokia.com/developer/changes/changes-4.5.3
[14:28] <JontheEchidna> less intrusive ftw
[14:31] <rgreening_> Riddell: can you review the meeting times in doodle... looks like we can do Friday if I get announce out now.. otherwise, we can push further into next week. Let me know
[14:31] <Riddell> rgreening_: URL?
[14:32] <rgreening_> http://doodle.com/3xh7d24q3skbpvwe
[14:32] <Riddell> rgreening_: it'll need to wait until this upgrade  is finished
[14:32] <rgreening_> haha
[14:32] <Riddell> shouldn't be long
[14:32] <rgreening_> np
[14:33] <rgreening_> we have some times with 6 participants Friday - Monday... So, we should pick something there...
[14:36]  * rgreening_ wants .. http://openpandora.org/
[14:48] <yuriy> rgreening: oh i thought that'd be like the internet radio
[14:48] <yuriy> that's not open is it?
[14:49] <yuriy> rgreening: but yeah that looks pretty sweet, though i don't really get what it is
[14:49] <yuriy> rgreening: were you the one still getting apport-kde hangs?
[14:49] <rgreening> haha
[14:49] <rgreening> ya
[14:49] <rgreening> yuriy: the pandora is a ARM devices. runs linux. Open design open OS
[14:50] <yuriy> rgreening: doing what? I tried ubuntu-bug with a PID and clicked send and everything worked, no leftover process
[14:51] <rgreening> I wasn't doing anything special... I just noticed at one point I had about 6 apport-kde processes hanging around my ps list
[14:52] <yuriy> rgreening: can you test that then?
[14:55] <JontheEchidna> [08:39:21] <JontheEchidna> ha, I have about 7 apport-kde processes hanging around from the last crash eating up 41.2 MB ram in total
[14:55] <JontheEchidna> rgreening: ^ same issue you think?
[14:57] <rgreening> yuriy: sure
[14:58] <rgreening> yuriy: works if I manually call apport-bug,..
[14:59] <yuriy> rgreening: how about for a crash report? (I think you can give apport-bug a .crash file if you have one)
[15:01] <rgreening> yuriy: if I call with crash and cancel the collection, I get a apport-kde hang
[15:01] <rgreening> hah
[15:01] <yuriy> rgreening: what if you don't cancel?
[15:02] <orestes> I've a question: I'd like to file a bug I've found testing a kubuntu karmic beta ISO, but I'm not sure which package I've to file it against. Someone can help?
[15:03] <rgreening> yuriy: If I let it complete and then close without sending, I get two ned apport-kde processes hung (I killed the previous one so these are new)
[15:03] <rgreening> s/ned/new
[15:03] <yuriy> oh fun. that's unexpected too, the close button is hacked to work
[15:04] <rgreening> yuriy: if I try a crash file belonging to root (and I have no permission to run) and hit ok, I get apport-bug and apport-kde hang
[15:05] <rgreening> it all seems very apport-buggy
[15:07] <rgreening> yuriy: same effect running /usr/share/apport/apport-kde direct rather than apport-bug.. so the issue is in apport-kde
[15:08] <rgreening> yuriy: I wonder if new qt 4.5.3 update would fix
[15:08] <rgreening> prob not..
[15:08] <yuriy> rgreening: not necessarily. all apport-bug does is choose the right frontend, each frontend still uses common code for all backend stuff.
[15:09] <yuriy> rgreening: maybe it'll fix the segfault that the hang works around
[15:09] <rgreening> 4.5.3 is released.. so guess we need to get it packaged asap..
[15:12] <yuriy> rgreening: but at least actually reports despite the leftover process?
[15:15] <rgreening> yuriy: it seems to
[15:19] <rgreening> yuriy: I think I fixed it
[15:20] <rgreening> hmm... nope
[15:22] <rgreening> yuriy: I'm almost there with the fixes... 2 so far I believe...
[15:32] <rgreening> yuriy, nixternal: what was the apport-kde hack for the crashing?
[15:36] <yuriy> rgreening: there is no main window, so nothing to do for the app.exec() call - most importantly, nothing to exit it. the dialogs exec themselves. so the way I understand it, the program as it is should never exit (but I don't think I understand it correctly, because it should be hanging on submit every time)
[15:36] <yuriy> so instead, there are sys.exit(0) calls for the cancel buttons
[15:36] <rgreening> hmm...
[15:36] <yuriy> rgreening: but if you don't app.exec() or sys.exit() and let the dialogs take care of themselves, you get a segfault
[15:36] <yuriy> rgreening: what were your fixes?
[15:37] <rgreening> for one... sys.exit(app.exec_()) at end of /usr/share/apport/apport-kde
[15:38] <yuriy> rgreening: but I don't see why app.exec_() would ever return, because you never quit() (I think i tried adding that somewhere but it didn't help, I don't remember what the issue was)
[15:38] <rgreening> hmm.
[15:39] <rgreening> yuriy: why can't we call the quit method on the close/cancel?
[15:41] <rgreening> oh.. nm
[15:41] <yuriy> don't remember. maybe you can. but the success condition is the bigger issue.
[15:42] <yuriy> rgreening: anyways, the way it's set up now is wrong, because all the code is run in the constructor of the MainInterface, then app.exec() is done so it's useless except to make the thing hang
[15:43] <rgreening> yuriy: instead of sys.exit, we could send a triggered signal and in the main, setup a slot that looks for the signal and it would call the app quit.
[15:43] <rgreening> maybe?
[15:44] <yuriy> rgreening: but the cancels and everything are in the separate dialogs which get created, execed, and done with before the app is ever execed
[15:45] <rgreening> hmm
[15:45] <rgreening> that's wrong
[15:45] <rgreening> lol
[15:46] <yuriy> umm yeah. and this is set up roughly the same as the apport-qt version it's based on, except that one segfaults instead of doing the extra exec() and exit()s
[15:50] <yuriy> rgreening: have you gotten the segfaults? i've been meaning to test with latest python-qt4 if that still happens
[15:50] <rgreening> no, just hang
[15:50] <yuriy> also with qt 4.5.3 would be good to test
[15:51] <yuriy> rgreening: ok, i mean if you change the code back to how apport-qt (see jaunty package) did it
[15:51] <rgreening> dunno
[15:51] <yuriy> unfortunately i accidentally overwrote my version where i was getting that
[15:52] <apachelogger> weeeh
[15:53] <apachelogger> that is so hacky
[15:53] <apachelogger> hrrr
[15:54] <yuriy> plan for Lucid: rewrite it to use a single window (more KDE style IMO) and base the UI on dr konqi
[15:55] <rgreening> yuriy: or add support into dr konqi to support plugin bug collection like apport
[15:55] <rgreening> and push upstream
[15:55] <rgreening> :)
[15:55] <yuriy> rgreening: harder, but would be nice
[15:58] <rgreening> yuriy: read this and nixternalshould too... http://aseigo.blogspot.com/2009/04/kapplication-tricks.html
[15:58] <rgreening> may help
[16:03] <rgreening> Riddell: don't forget K3B :)
[16:03] <Riddell> hmm?
[16:04] <apachelogger> Riddell: say I have a string in python that actually contains double quotes, how would I get rid of those quotes?
[16:04] <Riddell> apachelogger: I'd investigate the qstring API
[16:13] <apachelogger> interesting
[16:13] <apachelogger> QString(self.command).chop(1)
[16:13] <apachelogger> returns None
[16:13] <rgreening> Riddell: k3b can be taken from my ppa lp:~roderick-greening - fixes finding normalize-audio :) assuming we can upload now...
[16:13] <rgreening> tested fine here
[16:13] <apachelogger> A string enclosed in double quotes is not split. Within the string, the backslash quotes shell meta characters - if it is followed by a "meaningless" character, the backslash is output verbatim.
[16:13] <apachelogger> I fail to parse that
[16:13] <apachelogger> can someone explain me what that means :)
[16:26] <apachelogger> you know
[16:27] <apachelogger> it just hurts to use a programming language where you cant even do basic changes to a string object without wantint to shoot yourself
[16:27]  * Riddell takes the gun away from apachelogger
[16:27] <apachelogger> seriously about any language supports at least chop
[16:27] <apachelogger> no sign of that in python
[16:34] <apachelogger> kubotu: identica dent bug triage is more fun than python, like srsly!
[16:34] <kubotu> status updated
[16:43] <Riddell> ryanakca: nookie^ did some countdown images, would  you be able to inegrate them into the server?
[16:43] <Riddell> nixternal: survey broken again?
[16:44] <yuriy> apachelogger: what's chop? like split? or strip?
[16:44] <yuriy> i'm sure python can do it
[16:45] <apachelogger> yuriy: like strip
[16:46] <apachelogger> and no it cant
[16:57] <yuriy> apachelogger: what are you trying to do?
[16:57] <apachelogger> get rid of double quotes
[16:57] <yuriy> mystring.strip('"') ?
[16:58] <apachelogger> of the hook stuff from update-notifier
[16:58] <apachelogger> meaning string is command
[16:58] <apachelogger> and command might have sensible double quotes
[16:58] <apachelogger> meaning only if the string starts with a double quote => remove that and same for endswith
[17:02] <sebas> apachelogger: python has this [:1] and [:-1] syntax, which works pretty well
[17:02] <apachelogger> yeah, that is how I implemented it
[17:02] <rgreening> go sebas :P whee
[17:02] <apachelogger> though it seems strip works
[17:02] <sebas> If I understand well what chop does, at least
[17:02] <apachelogger> anyway
[17:02] <apachelogger> moved on to the next issue already :P
[17:03] <sebas> ah, boring. :P
[17:04]  * apachelogger thinks that sebas just wants to score a cookie, so apachelogger throws cookies at sebas and hopes he doesn't hit some essential body parts
[17:05] <sebas> I wouldn't admit if you did.
[17:05] <sebas> "Sorry, I can't produce children, apachelogger crushed my balls with cookies"
[17:05] <sebas> No way.
[17:05] <apachelogger> yeah, sounds weird
[17:05] <rgreening> haha
[17:05] <apachelogger> especially the produce part, makes it sound rather technical :P
[17:06] <sebas> yeah, I was about to write generate
[17:06] <yuriy> sebas, apachelogger: does kde/qt have some kind of onload event?
[17:07] <yuriy> rgreening: that's what i was looking for to fix apport-kde
[17:07] <sebas> What would onload do?
[17:07] <Riddell> objects have constructors
[17:08] <yuriy> rgreening: problem is the MainInterface isn't really used. if we could get it to actually exec() then "on load" it runs the apport code instead of in the constructor, and quits once it's done then it should work more correctly
[17:08] <rgreening> yuriy: I leave it in your capable hands :)
[17:08] <rgreening> haha
[17:09] <apachelogger> onload?
[17:10] <yuriy> sebas: well the problem we're having is with a pyqt app that doesn't have a main window. it's done rather.. wrongly.
[17:10]  * apachelogger notes that qt doesnt need a window these days :P
[17:10] <apachelogger> see quasselcore
[17:11] <yuriy> sebas: but I don't know how something like that works in general.  How do you use a K/Q/QCoreApplication without a main window (even, as a CLI app)? I haven't been able to find any examples or decent docs on that
[17:13] <apachelogger> JontheEchidna: btw, I was thinking about writing a script to spitout standard bug replies
[17:13] <apachelogger> adding alternating greeting and stuff
[17:13] <apachelogger> to give them the special personal touch
[17:13] <sebas> yuriy: hm, dunno. I do know that Qt doesn't mean the thing actually has a window
[17:14] <JontheEchidna> apachelogger: randomly generated personality! I like it
[17:14] <JontheEchidna> oh, and for software-properties
[17:14] <JontheEchidna> https://code.launchpad.net/~kubuntu-members/software-properties/software-properties-kcm
[17:15] <JontheEchidna> install instructions in the kde folder
[17:15] <apachelogger> rgreening: btw, please set the main branch for update-notifier-kde
[17:15] <apachelogger> JontheEchidna: thx
[17:15] <rgreening> apachelogger: ?
[17:16] <apachelogger> the u-n-k project on lp
[17:16] <apachelogger> IIRC you are the maintainer of that
[17:16] <apachelogger> currently it does not have a main branch
[17:16] <rgreening> oh, am I
[17:16] <rgreening> hmm...
[17:16] <apachelogger> preventing lp:ubuntu-notifier-kde from working
[17:17] <yuriy> is ~kubuntu-members/update-notifier-kde/trunk the right one for that btw?
[17:17] <apachelogger> aye
[17:18] <Riddell> rgreening: nothing  k3b related on https://code.edge.launchpad.net/~roderick-greening
[17:19] <rgreening> Riddell: ya, I only put the package in PPA. Let me upload the the kubuntu-members bzr branchso you can bzr debuild it...
[17:19] <rgreening> give me a few
[17:20] <Riddell> rgreening: oh that's fine
[17:20] <rgreening> fine as in you'll take it from my PPA and update bzr or fine, I can update bzr for you and then you take?
[17:21] <fale> hi
[17:21] <Riddell> hi fale
[17:21] <Riddell> rgreening: fine I'll take from the PPA
[17:21] <rgreening> cool.
[17:21] <rgreening> apachelogger: I'll look into it...
[17:21] <fale> hi Riddell
[17:22] <apachelogger> JontheEchidna: kcm actually crashes?
[17:22] <rgreening> Riddell: you'll update bzr then too correct
[17:22] <JontheEchidna> it does?
[17:23] <apachelogger> JontheEchidna: UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 6: ordinal not in range(128)
[17:23]  * apachelogger tries with lang c
[17:23] <JontheEchidna> huh
[17:23] <rgreening> apachelogger: Im looking but I see kubuntu-members is the owner...
[17:24] <Riddell> rgreening: yes if we have bzr
[17:24] <rgreening> Riddell: we do... may not be up to date in that case. hahah
[17:24] <apachelogger> rgreening: https://code.edge.launchpad.net/update-notifier-kde
[17:24] <apachelogger> there should somewhere be a message 'no default branch set'
[17:25] <Riddell> rgreening: debian/control doesn't think  so
[17:26] <rgreening> Riddell: I know. I think it was intended.. but never done. we probably should...
[17:26] <Riddell> rgreening: have you filed a bug with Debian?
[17:26] <rgreening> for the patch? not yet. It's on my list to do today
[17:26] <rgreening> I replaced their patch, as it does not work at all
[17:27] <Riddell> neversfelde synced k3b bzr with the archive
[17:29] <rgreening> apachelogger: how's that look now...
[17:29] <apachelogger> rgreening: perfect, thanks
[17:29] <rgreening> np
[17:30] <nixternal_> apachelogger: that's fine with me...the docs are out of whack anyways
[17:32] <apachelogger> kthx
[17:33] <apachelogger> JontheEchidna: the uic crap always makes stuff way too complex
[17:33] <JontheEchidna> agreed
[17:43] <apachelogger> JontheEchidna: I suppose it should look like this: http://aplg.kollide.net/images/snapshot042.png
[17:43] <apachelogger> :D
[17:43] <JontheEchidna> :o
[17:43] <JontheEchidna> now all we need to do is make it do all changes on apply rather than when you change things
[17:44] <JontheEchidna> the localization is in shambles :( I imagine this is an issue with normal software-properties too?
[17:44] <JontheEchidna> btw, what colorscheme/theme do you have?
[17:44] <apachelogger> yep
[17:45] <JontheEchidna> oh, and we need to policykit that bad boy up, but that might require changes inside SoftwareProperties
[17:45] <apachelogger> modified obsidian + nitro window deco
[17:46] <JontheEchidna> nitrogen... I think I didn't bother packaging that early on in karmic because it looked like an oxygen clone
[17:46] <JontheEchidna> but now it's all merged with oxygen for 4.4, so there's no need anymore for 10.04
[17:46] <JontheEchidna> one less package removal bug I suppose
[17:47] <apachelogger> aye
[17:47] <apachelogger> that is why I do not like clones :P
[17:47] <apachelogger> JontheEchidna:
[17:47] <apachelogger> -    self.ui = uic.loadUi("%s/designer/mainkcm.ui" % datadir, None)
[17:47] <apachelogger> +    self.ui = uic.loadUi("%s/designer/mainkcm.ui" % datadir, parent)
[17:47] <apachelogger> JontheEchidna: then just nuke the ui.show
[17:47] <apachelogger> that should take care of kcmification
[17:47] <JontheEchidna> ^why I am beginning to dislike python
[17:48] <JontheEchidna> too unstructured for my taste
[17:48] <apachelogger> not as beautiful as ruby for sure :P
[17:49] <JontheEchidna> putting this inside of kpackagekit should be fairly easy
[17:50] <apachelogger> yeah, should be something like $container.addPage(kcm-software) or something
[17:51] <JontheEchidna> I just have to set the parent in the .desktop file
[17:51] <apachelogger> that is if there is no internal roadblock that prevents pykcms from being part of capps
[17:51] <apachelogger> JontheEchidna: I would go right ahead and check if/how kpk integration works
[17:51] <apachelogger> to avoid wasted time if it goes wrong
[17:53] <rgreening> Riddell: I sent a bug to debian re the k3b patch. so we are good.
[17:53] <JontheEchidna> apachelogger: http://imagebin.ca/view/cJPqWz.html
[17:53] <JontheEchidna> huh, crashes systemsettings
[17:53] <rgreening> JontheEchidna: have a look at usb creator package for ideas on how to policykit in python for kde.
[17:54] <rgreening> and talk with evand on #ubuntu-installer if you need help. he did that work in that package.
[17:54] <JontheEchidna> will the SoftwareProperties ui-agnostic class need polkit support first?
[17:55] <JontheEchidna> that's what really does all the root-wanting stuffs
[17:55] <JontheEchidna> oh, I guess systemsettings didn't really crash, just a python error (most likely about permissions)
[17:55] <rgreening> Riddell: new arora is out today.
[17:56] <rgreening> Riddell: I'll package and test and let you know when ready.
[17:56] <JontheEchidna> \o/ http://imagebin.ca/view/z5xLPxlj.html
[17:57] <JontheEchidna> TODO:
[17:57] <JontheEchidna> -Packagekit so this can run as non root
[17:57] <JontheEchidna> *policykit
[17:57] <JontheEchidna> -KCM-ify so that settings changes aren't done instantly
[17:57] <JontheEchidna> come to think of it, IRC makes a horrible todo list
[18:05] <Quintasan> hmm
[18:05] <Quintasan> Why don't we change default input method to IBus? XIM is not installed by default and I need to switch to ibus maulally
[18:06] <Quintasan> manually*
[18:06] <apachelogger> harrrr
[18:07]  * apachelogger hugs JontheEchidna
[18:07] <apachelogger> one step closer to a happy apachelogger
[18:07] <JontheEchidna> :)
[18:08] <JontheEchidna> apachelogger: X-KDE-System-Settings-Parent-Category=add-and-remove-software
[18:12] <apachelogger> JontheEchidna: still crashes in the translate_widgets stuff on localized system though
[18:12] <JontheEchidna> historically that's been a problem with software-properties
[18:12] <apachelogger> mhh
[18:12] <apachelogger> pyware
[18:15] <Quintasan> stupid policykit-gnome
[18:20]  * Quintasan needs to make a list of proposed changes for meeting
[18:20] <apachelogger> Riddell: bug 367495 please have a look
[18:23] <yuriy> ok who put 175 character lines in update-notifier-kde :P some of us like to use our screen space
[18:26]  * apachelogger is wondering what he has to discuss for the meeting
[18:26] <apachelogger> JontheEchidna: any suggestions? :)
[18:26] <JontheEchidna> when I run the software kcm as root, it spits this out a few times and fails to be root: sh: getcwd() failed: No such file or directory
[18:27] <JontheEchidna> is it looking for a path to run from?
[18:27] <apachelogger> cwd = current working directory
[18:27] <apachelogger> there might be some way to wok around this, otherwise just cd to / in some init I suppose
[18:28] <JontheEchidna> see, software properties was meant to be a standalone application. Now we're having to work around all sorts of crap to make it a plugin :(
[18:28] <apachelogger> or was that meant as discussion material :D
[18:28] <JontheEchidna> lol
[18:28] <JontheEchidna> Open up project Timelord to more of the developer public?
[18:28] <apachelogger> python was just never meant to power apps :P
[18:29] <apachelogger> JontheEchidna: I'd like to keep it closed to avoid any more rants or public coverage of any kind
[18:29] <apachelogger> once we have it pretty ironed out it can go public
[18:29] <JontheEchidna> k
[18:30] <JontheEchidna> Back to software-properties, the thing is, I'm not to fond of the idea of making my own sources.list editor in C++
[18:30] <apachelogger>  Discuss top bugs to quash - bring a list so we can prioritize and delegate
[18:30] <apachelogger> that I find funny TBH
[18:31] <JontheEchidna> ^in theory that list should be launchpad
[18:31] <JontheEchidna> but it's too clogged up with upstream bugs
[18:31] <Quintasan> apachelogger: I wonder if Ruby could be used to create a Qt frontend to ibus-setup instead of creating starmonkeys
[18:32] <apachelogger> JontheEchidna: in theory someone first would need ot triage bugs :P
[18:32] <JontheEchidna> that too
[18:32] <apachelogger> Quintasan: KDE UI > Qt UI due to style integration, but yes, it could
[18:33]  * Quintasan puts it on his Future to-do list
[18:33] <Quintasan> god damn, too much to-do lists
[18:33] <apachelogger> make one and put everything on it :P
[18:33] <apachelogger> so
[18:34] <apachelogger> talking about bugs made me wanna rant
[18:34] <apachelogger> is it save to go ahead?
[18:34] <JontheEchidna> I'll listen
[18:34] <apachelogger> bug 409680
[18:34] <apachelogger> if you dare creating freaking patches
[18:34] <apachelogger> then at least QA them and watch out for bugs
[18:34] <apachelogger> 1 month of silence on a quite in your face bug is unacceptable
[18:34] <apachelogger> perfect example of why I think that patches are evil
[18:35] <JontheEchidna> I don't think that patch is worth having a hardly-used kubuntu feed on the twitter apple by default
[18:35] <apachelogger> question is if it caused by the patch though :)
[18:35] <apachelogger> just wanted to rant :)
[18:36] <JontheEchidna> easily discoverable, if anybody did QA :P
[18:36] <apachelogger> yeah
[18:36] <apachelogger> anyway, I find the feed patch doubtable
[18:36] <apachelogger> I think you cant even click links
[18:36] <davmor2> apachelogger: you forgot </rant>
[18:37] <apachelogger> davmor2: I am in constant rant mode :P
[18:37] <davmor2> :)
[18:37] <nixternal_> Riddell: fixed up the survey script...seems they changed the pages a bit on cdimages
[18:37] <Quintasan> lolwut
[18:37] <nixternal_> we need to find a much better way
[18:39] <apachelogger> better ways for all and everything I say
[18:55] <rgreening> Riddell: are you able to Doodle yet? :)
[18:55] <rgreening> oh, and is someone pacakaging new Qt 4.5.3? Im working on arora 0.10.0 now...
[18:56] <Quintasan> rgreening: I'm no good in packaging java modules and Dooble license requires packaging it along with modules :/
[19:00]  * rgreening has no idea Quintasan
[19:01] <Quintasan> omg, sorry rgreening, I read DooBle, not DooDle :P
[19:01] <rgreening> Riddell: I'd like ot propose a meeting time.... and it's getting late in the day to propose Friday.. unless you still want to....
[19:01] <rgreening> lol Quintasan
[19:05] <apachelogger> Quintasan: did you look at python code again?
[19:06] <apachelogger> I told you, dont do that, it will make your eyes blury!
[19:06] <Quintasan> no more python for me :<
[19:06] <apachelogger> there, I even lost a 'r' because I was looking at pycode all afternoon :S
[19:06] <Quintasan> anyone can help me with my noobish c++ code?
[19:07] <JontheEchidna> I now know why I need glasses...
[19:08] <JontheEchidna> my parents must have done pycoding before I was born
[19:08] <Quintasan> poor JontheEchidna
[19:08]  * Quintasan pats JontheEchidna
[19:08] <apachelogger> that is sad indeed :(
[19:09] <apachelogger> Quintasan: delete this; this = NULL;
[19:09] <apachelogger> hm, of all the wicked code I wrote, I never tried that TBH
[19:09] <Quintasan> grr, I managed to write this -> http://pastebin.com/f33c9adbf   how should I write it to make the app display the arguments in order I gave them (not backwards)?
[19:12]  * apachelogger blinks
[19:12] <apachelogger> Quintasan: out of interest, why not use a while and nuke stuff out of argv?
[19:13] <JontheEchidna> lol @ name
[19:13]  * apachelogger notes that argument parsing should only happen once in an apps live
[19:13] <Quintasan> JontheEchidna: :D
[19:13] <apachelogger> I dont find a for loop particularly suited for the use
[19:14] <Quintasan> apachelogger: I want this app to display the arguments given to, how else I can do this?
[19:14] <JontheEchidna> in porting jockey to pykde, I ended up copying the args, clearing the list, giving that to kde, and then giving the provided args to the jockey backend
[19:16] <apachelogger> Quintasan: markup: while not argv.empty?; output; argv.delete[0];
[19:16] <apachelogger> i.e. iterate over argv until argv becomes empty, in each iteration output the argument at hand and remove it from argv
[19:17] <apachelogger> at the end you have procssed all of argv and have the benefit of empty argv, which is a much more real-life use case :)
[19:18] <Quintasan> hurr, more complicated than I though
[19:19] <apachelogger> Quintasan: that is actually simpler than what you do :P
[19:19] <Quintasan> what?
[19:19] <JontheEchidna> I crashed skype
[19:19] <Quintasan> JontheEchidna: gratz
[19:19] <Quintasan> apachelogger: impossible!
[19:19] <apachelogger> JontheEchidna: lol, did you try to open entertainment videos with it to check the volume preset :P
[19:20] <JontheEchidna> all I did was try to login
[19:20] <apachelogger> hm, never crashed for me there
[19:21] <Quintasan> apachelogger: dunno how to write this, seems complicated >_<
[19:21] <apachelogger> Quintasan: ask the google :)
[19:22] <Quintasan> ＝＾＝
[19:22] <Quintasan> stackoverflow!
[19:23] <apachelogger> while(!argv.empty()) {}
[19:23] <apachelogger> I suppose
[19:24] <apachelogger> my cpp went down the hill ever since I become rather inactive :(
[19:24] <Quintasan> apachelogger: wut? .empty?
[19:27] <Quintasan> apachelogger: my skill are pretty meh
[19:27] <Quintasan> +s
[19:29] <apachelogger> Quintasan: !empty
[19:52] <rgreening> arora browser now uploaded to my ppa:~roderick-greening .. should start building soon
[19:52] <rgreening> Riddell: ^
[19:58] <nixternal> nielsslot: are we doing a call? if so, do I have time to run out for like 15 minutes?
[19:58] <nixternal> err, Nightrose ^^
[19:58] <nixternal> damn tab complete
[19:58] <Nightrose> jep i'm ready now
[19:58] <Nightrose> 15 mins is ok too
[19:58] <Nightrose> apachelogger: ^
[19:58] <nixternal> ok, we can do it right now
[19:58] <nixternal> how long is it going to take?
[19:58] <Nightrose> no idea
[19:58] <nixternal> what is it about?
[19:58] <Nightrose> apachelogger wanted to skype ;-)
[19:58] <nixternal> who all is involved?
[19:59] <Nightrose> no idea either ;-)
[19:59] <nixternal> can I ask more questions?
[19:59] <nixternal> why?
[19:59] <Nightrose> nooooooo!
[19:59] <nixternal> because!
[19:59] <nixternal> why?
[19:59] <Nightrose> :D
[19:59] <nixternal> because!
[19:59] <nixternal> :)
[19:59] <nixternal> my daughter used to drive me up a wall with that
[19:59] <Nightrose> haha
[19:59] <Nightrose> i poked harald on jabber
[19:59] <nixternal> k, I am going to run to the quick stop really quick...15 minutes
[19:59] <nixternal> brb
[20:00] <apachelogger> dont poke
[20:00] <apachelogger> need to go smoke
[20:00] <apachelogger> 15 mins
[20:00] <Nightrose> k
[20:00] <Nightrose> k
[20:01] <Nightrose> ping me when back
[20:07]  * ScottK waves
[20:08] <ScottK> Riddell: Looks like we need to upgrade xz-utils after beta<EMAIL_ADDRESS>[20:09] <apachelogger> ScottK: skype
[20:09] <ScottK> apachelogger: What about it?
[20:09] <apachelogger> going to have a timelord meeting :P
[20:09]  * ScottK is still reading backlog from 6 hours ago
[20:09] <ScottK> apachelogger: When?
[20:09] <apachelogger> though Id rather just chat a bit :D
[20:09] <apachelogger> ScottK: nowish
[20:10] <apachelogger> Nightrose: plz gimme a call
[20:10] <apachelogger> nixternal, JontheEchidna, ScottK: find me as apachelogger
[20:10] <ScottK> OK.  I need to be out the door in 20 minutes
[20:10]  * ScottK fishes for the netbook with skype
[20:10] <apachelogger> nixternal, JontheEchidna, ScottK: nightrose would be nightrose I suppose
[20:11] <Nightrose> restarting skype...
[20:11]  * ScottK is skitterman on skype
[20:11] <JontheEchidna> lotta nightroses
[20:11] <JontheEchidna> echidnaman on skype
[20:11] <Nightrose> btw i'm lydiapintscher
[20:13] <ScottK> I'm on now, BTW.
[20:13] <apachelogger> waiting for lydia to reboot :D
[20:13]  * ScottK continues reading backscroll until the phone rings.
[20:13]  * apachelogger should not be hosting the session due to somewhat unreliable intarwebs link
[20:15] <nixternal> back
[20:15] <JontheEchidna> nixternal = nixternal on skype?
[20:15] <nixternal> I am nixternal if you didn't know :p
[20:15] <JontheEchidna> hehe
[20:15] <rgreening> Riddell: I did the meeting post... booked #ubuntu-meeting via fridge... I think i got the timez correct. UTC/GMT blah...
[20:15] <nixternal> I am nixternal everywhere
[20:16] <nixternal> the one and only
[20:16] <apachelogger> so
[20:16] <ScottK> Riddell: Did seele discuss the results of her talking to upstream about the suspend dialog/notification issue?
[20:16] <apachelogger> someone start calling around :P
[20:16]  * ScottK waits for nixternal to do something.
[20:17] <ScottK> BTW, it should be someone not on wireless that initiates the call.
[20:17] <JontheEchidna> how fat do the interweb pipes have to be to be a good host?
[20:17] <apachelogger> not much
[20:17] <ScottK> I think it's more latency in wireless that is death on skype.
[20:18] <ScottK> (for the host)
[20:19] <nixternal> am I missing anyone?
[20:19]  * apachelogger waits for someone to call
[20:20] <ScottK> nixternal: Call.
[20:20] <nixternal> call who?
[20:20] <nixternal> I don't know how this stuff works :p
[20:20]  * JontheEchidna either
[20:20] <apachelogger> lol
[20:21] <apachelogger> quality sux
[20:21] <Nightrose> ok now i can hear absolutely nothing
[20:21] <apachelogger> we need another host :D
[20:22] <Nightrose> \o/
[20:22] <nixternal> i think I just head the cookie monster
[20:22] <JontheEchidna> lol
[20:22] <apachelogger> cookies
[20:22] <nixternal> i can't hear anybody
[20:22] <apachelogger> Nightrose just exploded
[20:22] <nixternal> lol
[20:22] <Nightrose> indeed
[20:22] <JontheEchidna> I can try
[20:23] <JontheEchidna> how do I do conference calls?
[20:23] <apachelogger> nixternal: right click a contact and say add to conference or something
[20:23] <apachelogger> that is if you have a connection
[20:23] <nixternal> roger that
[20:23] <nixternal> oh, I have the connection of all connections
[20:23] <ScottK> Riddell: Short version of my understanding of seele's findings is that upstream is not as opposed to a dialogue as the email discussion would appear, but there are some implementation details that they really don't like in the current patch.  Her recommendation was drop the dialog and go with a 30 second notification (agateau already has a patch upstream) and then work on a better solution together for 4.4/Lucid.
[20:23] <apachelogger> we should have used mumble :P
[20:25]  * Nightrose notes that apachelogger was the one who wanted to talk :D
[20:25] <rgreening> my brain hurts
[20:26] <apachelogger> kubotu: order brain
[20:26]  * kubotu shouts: OMG!!!!! RED ALERT! We lost a brain. Get me a medic, NOW!
[20:27] <rgreening> UTC/GMT is driving me nuts DST SDT.... lol
[20:28] <apachelogger> rofl
[20:28] <JontheEchidna> lmao
[20:30] <Riddell> are we nearly there yet
[20:30] <Riddell> ?
[20:30]  * Riddell spots  http://releases.ubuntu.com/kubuntu/karmic/
[20:33] <rgreening> Riddell: arora uploaded to my PPA. I built and tested locally. wallet support, adblock, mmmm..... goodness.
[20:34] <Riddell> rgreening: when is the meeting?
[20:34] <Riddell> ScottK: well yes, aseigo != upstream (sometimes)
[20:34] <rgreening> in yer email :) 19:00 UTC (I hope I got the TZ right .. )
[20:34] <rgreening> ^ true dat
[20:34] <rgreening> :)
[20:35] <ScottK> Riddell: I'd like to go with what seele suggested.
[20:35] <Riddell> ScottK: go for it (that patch is far more trouble than it's worth)
[20:36] <ScottK> Riddell: OK.  I'll deal with it tomorrow or over the weekend
[20:45] <rgreening> Riddell: arora 0.10.0 is awesome
[20:45] <rgreening> ie. it has adblock!
[20:45] <rgreening> so I am happy now
[20:46] <rgreening> Riddell: feel free to grab it from my PPA and push up. Works just fine.
[20:46]  * rgreening really needs rights to upload to main....
[20:48] <Tonio__> Riddell: about kpackagekit I think the guilty is policykit-kde...
[20:49] <Riddell> Tonio__: does it work with the old standalone policykit-kde package?
[20:50] <Tonio_> grmpf........... my internet connection sucks today...
[20:50] <Tonio_> so did anyone reaply to "kcmshell4 kcm_pkk_authorization" sefaulting test ? :)
[20:52] <Tonio_> rgreening: would you please confirm ?
[20:52] <Tonio_> I get this error : *** glibc detected *** kcmshell4: double free or corruption (fasttop): 0x0000000001501fe0 ***
[20:52] <Tonio_> pretty interesting:)
[20:56] <Tonio_> I suspect polkit-qt
[21:09] <Tonio_> PolkitQt::Context::hasError() const () from /usr/lib/libpolkit-qt-core.so.0
[21:10] <Tonio_> it is polkit-qt.... I'll test a fresh svn snapshot :)
[21:11] <Tonio_> hum it went from qt0 to qt1 on svn :)
[21:11] <Tonio_> same as gtk1 in fact.... interesting
[21:44] <Quintasan> ☭
[22:09] <ryanakca> nookie^: Hi, can you send me your countdown images please?
[22:11] <ryanakca> Riddell: "able to fit in the "latest update" banner at the top of kubuntu.org"... Should that integrate with the action items from the KubuntuKarmicWebsite spec (somehow), or will making the KubuntuKarmicWebsite changes live wait until after release?
[22:12] <Riddell> http://blusrcu.ba/kubuntu.zip
[22:14] <Riddell> ryanakca: ^^
[22:14] <ryanakca> Riddell: ... and should that go inside #kmasthead? Or in the page body somewhere?
[22:14] <Riddell> ryanakca: inside the masthead (if possible and if it looks decent)
[22:15]  * ryanakca asks matt for the JS to make it countdown
[22:25] <ryanakca> Riddell: Could you stick them up under /~jriddell/karmic-countdown-banner/ or something of the sort please?
[22:25] <Riddell> k
[22:28] <Riddell> ryanakca: done
[22:28] <ryanakca> Riddell: thanks
[22:30] <ryanakca> Also, was there a "Kubuntu 9.10 has arrived!" or an "Almost there!" one? or should I just display the "One day to go" until the end?
[22:31] <Riddell> ryanakca: just do the one day to go I guess
[22:38] <ryanakca> Riddell: Anyways, http://drupal.ryanak.ca
[22:38] <ryanakca> Riddell: I commented out the action items, I can make them go live a week or so after release I guess.
[22:39] <DaSkreecH> ryanakca: We need a Poster with Kubuntu needs you and Riddell doing the POinting Uncle Sam thing in a kilt :)
[22:39] <DaSkreecH> Who uses Kubuntu?
[22:39] <DaSkreecH> you!!
[22:40] <nixternal> there is a bit to much typefacing going on there
[22:40] <Riddell> ryanakca: that looks good
[22:41] <Riddell> DaSkreecH: I already have a vanity photo on kubuntu.org
[22:42] <DaSkreecH> :-)
[23:13] <DaSkreecH> Why can't you log out via KDM ?
[23:14] <Riddell> if we knew that, we'd fix it
[23:15] <DaSkreecH> ok I guess a less stupid question :) When did this start?
[23:15] <DaSkreecH> My latest test of karmic is about a month ago
[23:18] <Riddell> it started for me when we got the crash-on-logout bug fixed
[23:19] <ScottK> It's mentioned in the release notes for the Beta.
[23:22] <DaSkreecH> ScottK: I know that's how I know about it now
[23:22] <ScottK> Then I guess I'm glad I put it there.
[23:24] <DaSkreecH> :-)
[23:24] <DaSkreecH> Yeah we should kinda aim at Human open eyes release notes
[23:25] <ScottK> Talk to claydoh about format when he's around.
[23:25] <DaSkreecH> I don't mind the Format other than I don't like having the list of mirros first
[23:26] <Riddell> maybe that should go on a separate page
[23:27] <ScottK> It's at the end of the regular Ubuntu release announcement.
[23:27] <ScottK> I think at the end or a separate page would be an improvement.
[23:31] <DaSkreecH> Yes I almost didn't see the notes
[23:31] <DaSkreecH> I saw it because I was clicking every link to see if they had a mirror
[23:31] <DaSkreecH> almost none of them are valid currently btw but I guess they are still propogating
[23:32] <ScottK> For the final release we make sure the mirrors are in sync before pulling the trigger.
[23:34] <ScottK> Riddell: When you have a moment I'd like to chat about having the "warning" screen back in the installer for Netbook so we can use that for the "It's a tech preview, don't judge too harshly" disclaimer.
[23:34] <Riddell> we don't, but we do have a magically updating iframe with the list of mirrors
[23:35] <Riddell> ScottK: the thought had occured to me, it would need some code in ubiquity but I doubt it's too hard, I expect shtylman can be conjoled into action
[23:35] <ScottK> Riddell: Cool.  I think it'll be an important part of upstream being happy with the way we deliver the message for netbook.
[23:35] <Riddell> although it's late for a new string and it can't be updated with langpacks
[23:35] <ScottK> Ooops.
[23:36] <ScottK> Well I didn't think of it until yesterday.  Sorry.
[23:36] <Riddell> yeah it's upstream's fault for changing their plans :)
[23:36] <Riddell> shtylman: what say thee?
[23:36] <ScottK> Their suggestion was a watermark on the desktop.  I think this is way better.
[23:37] <Riddell> no need to rub users nose in it, they can make an informed choice
[23:38] <ScottK> Yep.
[23:38] <ScottK> I just want to have a solid response to "but users don't read release notes".
[23:39] <ScottK> I think  a click through on the installer is a solid answer.
[23:48] <Riddell> ScottK: looks like shtylman has been idle for a couple of days, we should e-mail him
[23:50]  * Riddell makes it sew
[23:53] <JontheEchidna> what if...
[23:54] <JontheEchidna> what if polkit-manager-kde crashing somehow caused bug 438279
[23:55] <JontheEchidna> if the root-having process that does all the priviledged stuff dies
[23:55] <JontheEchidna> kpackagekit can no longer write to root-needing places
[23:55] <Riddell> seems plausible
[23:55] <JontheEchidna> so then the dpkg suddenly halts, unable to write any more
[23:56] <JontheEchidna> causing the "cannot write to standard output error"
[23:56] <JontheEchidna> the packagekit traceback seems to indicate it cannot run a dpkg helper
[23:56] <Riddell> maybe Tonio_ has figured it all out :)
[23:57] <Tonio_> Riddell: I'm trying to fix, currently on my ppa :)
[23:57] <Tonio_> I have hudge internet connection problems today, so that'll take time :)
[23:57] <Tonio_> also I played with latest arora, it's real genius :)
[23:58] <Tonio_> Riddell: latest libpolkit-qt on my ppa, but as there is a API transition, I suspect we may expect problems with some apps :/
[23:58] <Riddell> umm, where's that from?
[23:59] <Tonio_> svn in branches/work
[23:59] <Tonio_> there is the libpolkit-qt-1
[23:59] <Tonio_> Riddell: was pretty hard for me to find it :)
[23:59] <Riddell> I believe that's not complete yet
[23:59] <Tonio_> Riddell: I know that, but it can lead to what need to be done


[06:12] <tcoread> date -u
[07:01] <dholbach> Good morning everybody!
[07:01] <dholbach> who' all here for the packaging training session? :-)
[07:01] <micahg> is this an open session?
[07:01] <dholbach> yes
[07:01] <micahg> ok
[07:01]  * micahg is here for packaging
[07:01]  * Rail is here too
[07:02] <dholbach> who else? come on, don't be shy! :)
[07:02] <juliend> o/
[07:02]  * Koterpillar *
[07:03] <dholbach> alright - I hope you all brought questions
[07:03] <dholbach> do we have any questions about something to do with packaging or ubuntu development in general?
[07:03]  * Koterpillar yes
[07:03] <dholbach> Koterpillar: cool - go ahead!
[07:04] <Koterpillar> How can I replace a package A with B so that ones dependent on A are satisfied?
[07:04] <dholbach> Koterpillar: can you illustrate that case a bit?
[07:06] <dholbach> just so we all know what we're talking about
[07:06] <Koterpillar> ubuntu-desktop depends on readahead, but there is sreadahead which i'd like to replace readahead with, but not remove ubuntu-desktop.
[07:07] <Koterpillar> Currently, sreadahead conflicts with readahead.
[07:08] <dholbach> there's two ways to achieve this, you could either change ubuntu-desktop (which is a special case) to depends on either  readahead | sreadahead  or you could change sreadahead to say   Provides: readahead   (if they indeed offer identical functionality)
[07:08] <dholbach> ubuntu-desktop is a special case because it is not modified by hand, but created from seed files
[07:09] <dholbach> https://wiki.ubuntu.com/SeedManagement has more detail about that
[07:09] <Koterpillar> Do I remove Conflicts: readahead?
[07:09] <dholbach> no
[07:10] <dholbach> "Conflicts:" says that both packages ship the same file which dpkg can't deal with
[07:10] <dholbach> http://www.debian.org/doc/debian-policy/ch-relationships.html has more detail about what conflicts / replaces / provides / etc are for
[07:10] <Rail> and http://www.debian.org/doc/debian-policy/ch-relationships.html#s7.6.2
[07:11] <dholbach> Koterpillar: I'm curious, what does sreadahead offer that readahead doesn't?
[07:11] <dholbach> (I haven't looked into either of them)
[07:11] <Koterpillar> I've seen a news about it doing better with SSD, wanted to try.
[07:11] <dholbach> ok
[07:12] <dholbach> do we have any other questions already?
[07:12] <FuturePilot> what do you do with the debian patches when a new version of the program is released? I know most of the time they won't patch anymore.
[07:12] <dholbach> FuturePilot: you need to check if you need to update them or if they can be dropped (because they were included upstream already)
[07:12] <TheMuso> Well, it depends on whether the patch has been commited upstrea in the new version
[07:13] <TheMuso> And any good maintainer will send patches upstream for inclusion.
[07:13] <ethana2> dholbach: doctormo and I are working on the wizardpen driver..
[07:13] <dholbach> TheMuso is absolutely right... the earlier you get stuff upstream, the less pain you have :)
[07:13] <ethana2> trying to get it to Just Works status and included in main
[07:13] <ethana2> by karmic
[07:14] <FuturePilot> ah, I see
[07:14] <dholbach> ethana2: just a sec
[07:14] <ethana2> ....there's one dependency that's giving us trouble, and he's going to make a 64 bit ubuntu install to help us pin it down
[07:14] <ethana2> dholbach: k
[07:14] <TheMuso> Mind you, there are sometimes patches for configuration settings that you want to keep, in which case you need to refresh the patch somehow.
[07:14] <dholbach> sometimes you will see that people use names for their patches like 50_from_cvs_............., so it's obvious that they can be dropped with the new release
[07:14] <dholbach> https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines is really really helpful in that regard too
[07:14] <TheMuso> That, and documenting that the patch was from upstream in the changelog is good.
[07:15] <dholbach> so if somebody else comes across your package they know where the patch comes from and where the discussion about it is happening
[07:15] <TheMuso> If the patch is from a git repo for example, its also useful to keep the git commit message in the header of the patch./
[07:15] <dholbach> sometimes "refreshing a patch for a new upstream version" is easy enough, because you just need to apply it again and you'll have some offsets and some fuzz, but sometimes it's really unpleasant work
[07:15] <TheMuso> And patch systems like dpatch alow a description of the patch to be added in the header of the patch.
[07:16] <dholbach> TheMuso: don't all patch systems allow that?
[07:16] <TheMuso> dholbach: Not in an official sense. Dpatch actually has commented lines where you add the author of the patch, and a description.
[07:16] <TheMuso> Sure you can add it to headers of other patches and it will be ignored, which is ok as well.
[07:16] <dholbach> "patch" itself can deal with    ## comment .....    above the    diff .....   line
[07:17] <dholbach> ah ok
[07:17] <dholbach> yes
[07:17] <dholbach> :-)
[07:17] <TheMuso> Yeah.
[07:17] <dholbach> FuturePilot: problem solved? :)
[07:17] <dholbach> https://wiki.ubuntu.com/Bugs/Upstream has more info for sending stuff upstream
[07:17] <FuturePilot> dholbach: yeah I think I get it now. thanks
[07:17] <dholbach> ROCK
[07:18] <dholbach> ethana2: so... what is giving you guys trouble? :)
[07:18] <ethana2> xautomation is a virtual package
[07:18] <ethana2> ...I don't think it's a problem on x32... not sure
[07:18] <ethana2> xautomation is evidently a dependency of wizardpen, which we're trying to package
[07:19] <ethana2> on 64 bit ubuntu, it won't build because it can't get that package
[07:19] <ethana2> I've checked my sources.list, it can get to source files
[07:19] <dholbach> daniel@bert:~$ apt-cache show xautomation | grep ^F
[07:19] <dholbach> Filename: pool/universe/x/xautomation/xautomation_1.03-1_amd64.deb
[07:19] <dholbach> daniel@bert:~$
[07:19] <dholbach> ?
[07:19] <ethana2> hmm
[07:19] <dholbach> it seems to exist on 64bit Ubuntu
[07:19] <ethana2> I'll get a pastebin link to my build errors
[07:19] <dholbach> sure
[07:19] <ethana2> http://paste.ubuntu.com/205915/
[07:20] <ethana2> and...  http://paste.ubuntu.com/205930/
[07:20] <ethana2> ok the second one is the important one at this point
[07:20] <dholbach> did you enable universe and multiverse for your pbuilder?
[07:20] <ethana2> not specifically
[07:21] <dholbach> do something like this
[07:21] <dholbach> daniel@miyazaki:~$ cat .pbuilderrc
[07:21] <dholbach> COMPONENTS="main universe multiverse restricted"
[07:21] <dholbach> daniel@miyazaki:~$
[07:21] <dholbach> and recreate the pbuilder
[07:21] <ethana2> k
[07:21] <dholbach> https://wiki.ubuntu.com/PbuilderHowto has more info
[07:21] <dholbach> might be the problem that xautomation is in universe
[07:21] <dholbach> looking at the first pastebin now
[07:21] <ethana2> don't bother I think
[07:22] <ethana2> ok, so I want a ~/.pbuilderrc file
[07:22] <ethana2> containing
[07:22] <TheMuso> The first one doesn't seem to be a problem, except for some lintian warnings.
[07:22] <ethana2> COMPONENTS="main universe multiverse restricted"
[07:22] <nellery> first one just looks like a keysigning error
[07:22] <dholbach> to avoid "Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address" you can run 'update-maintainer' from the ubuntu-dev-tools package
[07:22] <ethana2> TheMuso: maybe a gpg thing, but yeah
[07:22] <dholbach> https://wiki.ubuntu.com/DebianMaintainerField has the reason for it
[07:22]  * ethana2 saves .pbuilderrc file
[07:23] <ethana2> ok, I'm just going to try to build this again, carry on
[07:23] <dholbach> dh-clean-k-is-deprecated: just use dh_prep in debian/rules instead
[07:23] <ethana2> oh, ok, I should do that now
[07:23]  * ethana2 navigates to debian/rules
[07:23] <dholbach> configure-generated-file-in-source config.log config.status: just remove them in the clean target in debian/rules
[07:23] <dholbach> debian-files-list-in-source: this is weird :-)
[07:24] <dholbach> other than that there doesn't seem to be anything wrong from as far as I can tell
[07:24] <dholbach> do we have any other questions? :)
[07:24] <Rail> The upstream tarball doesn't contain LICENSE file, but the author declared LGPL on the Homepage. Should I repack the tarball and put a copy of license file?
[07:25] <dholbach> Rail: I'd ask the upstream developers to put a license file in there, then repacking for just this one release is fine
[07:25] <Rail> dholbach: already done, but no feedback from the author :(
[07:26] <dholbach> ok, that's fine then - just make sure you mention it in debian/changelog very prominently so reviewers and archive admins know why the md5sums of the original tarball and yours don't match
[07:27] <Rail> I have a very descriptive get-orig-source :)
[07:27] <dholbach> that sounds like a good idea :)
[07:28] <dholbach> any more questions? :)
[07:28] <ethana2> ope, it failed again :(
[07:28] <ethana2> ok, I made that file...
[07:28] <ethana2> but it gives me the same error
[07:28] <dholbach> I think you might need to recreate the pbuilder
[07:29] <ethana2> ohhh
[07:29] <dholbach> sudo pbuilder update --distribution karmic --override-config
[07:29] <dholbach> or something
[07:29] <ethana2> ok yeah I think I forgot that part
[07:29] <ethana2> karmic?
[07:29] <ethana2> I'm on Jaunty, does that matter?
[07:29] <dholbach> jaunty might be fine for now
[07:29] <ethana2> k
[07:29] <ethana2> should I still use 'karmic' in that command?
[07:30] <dholbach> but if you want to get it into karmic, it only makes sense if you test it on karmic first :)
[07:30] <ethana2> ahh
[07:30] <ethana2> hmm
[07:30] <dholbach> https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases explains how to do that in a sane way
[07:30] <ethana2> I was going to wait for alpha 3 and then install karmic over my intrepid
[07:30] <ethana2> I always dual boot two ubuntu's
[07:31] <dholbach> ethana2: you can use a vm too
[07:31] <ethana2> dholbach: yeah
[07:31] <dholbach> the page explains various options
[07:31] <dholbach> cool
[07:31] <ethana2> well, I don't think I'm nearly to the point where it becomes a matter of testing
[07:32] <ethana2> but I'll certainly test with karmic before I send it in to REVU
[07:32] <ethana2> or anything of that nature
[07:32] <dholbach> excellent
[07:32] <dholbach> do we have any more problems some of you ran into?
[07:34] <dholbach> what about the things we just discussed, did they raise any questions or eyebrows?
[07:34]  * ajmitch has a whole truckload of patches to check through & tag :)
[07:35] <Rail> Sometimes I want to override lintian warnings. Is there any policy or good practices on this subject?
[07:35] <ethana2> Rail: a warning shouldn't need to be overridden
[07:35] <ethana2> do you mean an error?
[07:35] <dholbach> Rail: I usually just leave them there to remind me (or others) to fix them at some stage :)
[07:36] <Rail> ethana2: no, just annoying warnings, like no-upstream-changelog
[07:36] <ethana2> Rail: yeah, the only proper thing to do is fix their cause
[07:36]  * ajmitch would only override where necessary
[07:37] <ethana2> ok, pbuilder updated and stuff, attempting to build the package again
[07:37] <dholbach> http://lintian.debian.org/manual/ch2.html#s2.4
[07:37] <dholbach> if you really want to
[07:37] <dholbach> I normally wouldn't bother :)
[07:38] <ethana2> well, it went to make it
[07:38] <ethana2> ..but failed
[07:38] <dholbach> Rail: but I agree... no-upstream-changelog is really annoying :)
[07:38] <ethana2> ..due to a bug in the code
[07:38] <dholbach> especially considering how much space on the CDs we waste because of changelogs :-)
[07:38] <ethana2> ohhhh, stricter gcc
[07:39] <ethana2> blast, I have to find a way to fix the code here
[07:39] <Rail> dholbach: thanks, going to read that manual :)
[07:39] <dholbach> any more questions? :)
[07:39] <maxpaguru> how to check in general if a patch that won't fix anymore need to be dropped or update? and then which steps?
[07:40] <dholbach> so let's assume there's version 6.5 of something and we have a bunch of patches and we update to 7.0 and applying some of the patches fails
[07:41] <dholbach> what you can do to easily test if a patch was applied upstream as-is, is run     patch -p1 --dry-run -R < some-patch-file
[07:41] <dholbach> it won't make changes to the code, and will try to "revert" the patch again
[07:42] <dholbach> if you have complicated patches were upstream used some parts and neglected others, it's a bit more tricky
[07:42] <dholbach> or if stuff was fixed in a different way
[07:42] <dholbach> another tool I find useful is diffstat - you can run it on a patch file and quickly get an overview over what's changed in the patch
[07:43] <ethana2> 'night, that was very helpful, rock on
[07:43] <dholbach> maxpaguru: was that answer helpful?
[07:43] <ajmitch> porting patches forward over multiple versions gets tedious, which is why it'd a great idea to pass stuff to debian & to upstream
[07:44] <maxpaguru> dholbach:thanks, i need to know better. what to reeD or tutorials ?
[07:45] <dholbach> maxpaguru: https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines https://wiki.ubuntu.com/Bugs/Upstream and generally https://wiki.ubuntu.com/MOTU/GettingStarted :-)
[07:45] <maxpaguru> dholbach: ok!
[07:45] <dholbach> :-)
[07:46] <dholbach> any more questions?
[07:47] <dholbach> ajmitch, TheMuso: it's weird that nobody says "review my package please", isn't it? :)
[07:47] <Rail> hehe :)
[07:47] <TheMuso> dholbach: Yeah.
[07:47] <FuturePilot> sometimes when I'm watching a package build I see warnings about uselessly linked libraries or something. What is that?
[07:48] <TheMuso> Sometimes, executables or libraries are linked against other libraries when they don't need to be.
[07:48] <Rail> dholbach: everybody pushes to Debian NEW :P
[07:48] <ajmitch> dholbach: I'll have to produce a few for you to review then :)
[07:48] <dholbach> FuturePilot: that's something the upstream maintainers should dive into - it's if you specify stuff in Makefiles just to be safe :)
[07:48] <TheMuso> FuturePilot: It won't break anything if they do, but may introduce unnecessary dependencies to a package, so if they can be fixed up, its worth doing so.
[07:49] <dholbach> TheMuso: does linking with -Wl,as-needed (or however you specify it) help with that?
[07:49] <FuturePilot> ah ok, so probably notify upstream?
[07:49] <dholbach> FuturePilot: yes
[07:49] <TheMuso> dholbach: I don't know.
[07:50] <TheMuso> I've just fixed up the autofoo and sent a patch upstream.
[07:50] <juliend> dholbach: hi, is there a tutorial somewhere about packaging perl projects from CPAN ?
[07:50] <dholbach>        --as-needed
[07:50] <dholbach>        --no-as-needed
[07:50] <dholbach>            This option affects ELF DT_NEEDED tags for dynamic  libraries  men‐
[07:50] <dholbach>            tioned on the command line after the --as-needed option.  Normally,
[07:50] <dholbach>            the linker will add a DT_NEEDED tag for each dynamic  library  men‐
[07:50] <dholbach>            tioned  on  the  command line, regardless of whether the library is
[07:50] <dholbach>            actually needed.  --as-needed causes  DT_NEEDED  tags  to  only  be
[07:50] <dholbach>            emitted for libraries that satisfy some symbol reference from regu‐
[07:50] <dholbach>            lar objects which is undefined at the point that  the  library  was
[07:50] <dholbach>            linked.  --no-as-needed restores the default behaviour.
[07:50] <dholbach> that's from the ld manpage... I've seen it in a couple of packages already, and I've seen it break a very few packages on some architectures
[07:51] <TheMuso> ah ok.
[07:51] <dholbach> so it might be a suitable workaround in some cases
[07:51] <dholbach> juliend: I'm delighted to tell you that we're going to have some perl wizards here in a few weeks that are going to talk about exactly that!
[07:51] <juliend> great :)
[07:51] <dholbach> 23rd July, 00:00 UTC, gwolf and jawnsy, Packaging Perl Modules
[07:52] <ajmitch> the problem is not seeing breakage until you hit specific areas of a program that need those missing functions
[07:52] <dholbach> ajmitch: that too
[07:52] <dholbach> juliend: for now I'd just tell you to review existing perl modules and how they are packaged
[07:52] <dholbach> http://www.debian-administration.org/articles/78 might be helpful too
[07:53] <juliend> perfect, thanks
[07:53] <dholbach> nice
[07:53] <dholbach> any more questions? :)
[07:54] <dholbach> I'm immensely proud of all the great work you guys are doing!
[07:54] <FuturePilot> :)
[07:55] <maxpaguru> can you give us an example of package updating where some of the patches fail and how to handle the problem?
[07:57] <dholbach> just a sec
[07:58] <dholbach> sudo apt-get install devscripts; dget -xu https://launchpad.net/ubuntu/karmic/+source/yelp/2.27.1-0ubuntu2/+files/yelp_2.27.1-0ubuntu2.dsc; dget -xu https://launchpad.net/ubuntu/karmic/+source/yelp/2.27.2-0ubuntu1/+files/yelp_2.27.2-0ubuntu1.dsc
[07:58] <dholbach> robert_ancell had to "refresh" the patches because they didn't apply any more in their current form
[07:58] <Rail> maxpaguru: maybe this log will help https://wiki.ubuntu.com/Packaging/Training/Logs/2009-04-16
[07:59] <dholbach> ok, let's wrap up
[07:59] <maxpaguru> dholbach:thank you very much!
[07:59] <dholbach> thanks a lot everybody for attending and your clever questions!
[08:00] <dholbach> logs will be up soon
[08:00] <FuturePilot> dholbach: thanks again
[08:00] <dholbach> see you in #ubuntu-motu and #ubuntu-devel :)
[08:00] <dholbach> have a great day :-)
[08:01] <maxpaguru> Rail: thanks a lot!
[21:50] <ryanprior> Hello there. Anybody helping with packaging questions yet?
[21:50] <ryanprior> (I'm currently working on a nearly-completed package that I hope to get into Ubuntu for Karmic if possible. =D )
[21:57] <james_w> ryanprior: #ubuntu-motu is the place to go
[21:57] <ryanprior> james_w: I thought that there was a packaging tutorial coming up soon?
[21:57] <james_w> there was one this morning
[21:57] <ryanprior> Ah, what time?
[21:57] <james_w> (last night for those on the West Coast US)
[21:58] <james_w> 6am UTC
[21:59] <ryanprior> That seems like a really silly time. >.>
[21:59] <nhandler> ryanprior: The times alternate each week


[07:26] <mbamford> word
[11:59]  * persia encourages someone to volunteer to chair the meeting
[12:00] <soren> o/ Hi, guys.
[12:00] <proppy> Hi
[12:00] <dholbach> heya
[12:00] <lionel> hi all
[12:00] <TheMuso> Greetings all.
[12:01] <dholbach> soren: does "o/" mean you volunteered? :)
[12:01]  * soren runs away, screaming.
[12:01] <dholbach> if not and nobody else wants to, I can do it
[12:01] <dholbach> hey sistpoty|work
[12:01] <sistpoty|work> hi dholbach
[12:02] <dholbach> ok, let's get started
[12:02] <dholbach> #startmeeting
[12:02] <MootBot> Meeting started at 12:02. The chair is dholbach.
[12:02] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[12:02] <dholbach> we have an agenda: https://wiki.ubuntu.com/MOTU/Meetings
[12:02] <dholbach> first up is persia
[12:02] <dholbach> [TOPIC] REVU Day scheduling: Should REVU Days be held on the 4th and 11th of February, or should we stop sooner so as to provide time for the archive admins to process NEW? Also, any suggestions for a last push? It would be unfortunate to have a package be all ready on REVU and not make the archive due to too few reviewers
[12:02] <MootBot> New Topic:  REVU Day scheduling: Should REVU Days be held on the 4th and 11th of February, or should we stop sooner so as to provide time for the archive admins to process NEW? Also, any suggestions for a last push? It would be unfortunate to have a package be all ready on REVU and not make the archive due to too few reviewers
[12:02] <persia> In the Gutsy cycle, there was some confusion about whether the deadline for new packages meant the last date on which a package could be uploaded to NEW without a freeze exception, or the last day the archive admins would process a package without a freeze exception.
[12:02] <persia> My memory of earlier discussions this cycle was that we had agreed that FeatureFreeze was the last day the archive admins would be expected to process source NEW without a freeze exception.
[12:02] <persia> Based on that understanding, I wonder if we oughtn't have 27 January be the last REVU day, perhaps with some specific packages for which a MOTU has explicit interest, or are needed for a Feature goal receiving attention thereafter, but no scheduled general REVU days.
[12:02] <persia> Also, there are a fair number of packages still in their final REVU cycles.  If anyone has any ideas about how to best grab those we want for hardy in time for FeatureFreeze, please share.
[12:03] <dholbach> persia: What do you suggest as deadline?
[12:03] <soren> FF is the 16th, if memory serve?
[12:03] <soren> serves?
[12:03] <dholbach> soren: 14th
[12:03] <dholbach> Happy Valentines Day :)
[12:03] <soren> Ok. I think 27th is too conservative.
[12:04] <persia> 14th I think.  I'm not sure we should impose a deadline, but from informal discussions I understood the archive admins wanted a couple weeks.
[12:04] <soren> Feb 4th should be plenty of time for NEW processing.
[12:05] <dholbach> I think 4th should be fine, especially given that exceptions can still be granted by motu-uvf (motu-ff? :))
[12:05] <TheMuso> 4th sounds good.
[12:05] <persia> 4th is fine with me.
[12:05] <dholbach> [AGREED] Feb 4th is deadline for uploading NEW packages.
[12:05] <MootBot> AGREED received:  Feb 4th is deadline for uploading NEW packages.
[12:05] <persia> Err.  No.
[12:06] <persia> February 4th is the last regularly scheduled REVU day.
[12:06] <lionel> 4th looks good. Maybe ask a confirmation to archive admin?
[12:06] <soren> 13:05:20 < soren> pitti: How does Feb 4th sounds as a (soft) deadline for submitting new packages? That leaves 10 days for NEW processing before FF.
[12:06] <soren> 13:05:59 < pitti> soren: sounds ok (although the current policy already accounts for processing the backlog)
[12:06] <lionel> soren :)
[12:07] <dholbach> ok... persia: what would you like to see as a deadline?
[12:07] <soren> 4th as a soft deadline is probably sensible. That still leaves time to work out the last few issues that might be raised, and if there's "urgent" stuff, it can still make it.
[12:07] <persia> dholbach: I don't think the deadline is ours to propose, but rather an archive-admin decision.
[12:07] <dholbach> Opinions?
[12:08]  * sistpoty|work agrees with persia
[12:08] <soren> Well, the deadline we propse it the deadline before which people should submit their stuff if they expect it to be reviewed before FF.
[12:09] <soren> It's not exactly the deadline for uploading the packages.
[12:09] <sistpoty|work> soren: so you want rather a "we won't review packages uploaded after <T>" deadline?
[12:09] <sistpoty|work> (newly uploaded packages even)
[12:09] <persia> soren: Ah.  I thought you were talking about deadline for upload to the archive.  For upload to REVU, I think 3rd Feb (for inclusion in 4th Feb REVU day) is perfectly sensible.
[12:09] <dholbach> I'm happy to have the last REVU day on Feb 4th and our "soft deadline" shortly afterwards
[12:10] <dholbach> to guarantee the archive admins have enough time
[12:10] <soren> sistpoty|work: Something like that, yes :)
[12:10] <persia> Also, I think any MOTU interested in a specific package should be free to ignore that deadline for further review, as long as it doesn't annoy the archive-admins.
[12:10] <sistpoty|work> soren: sounds good :)
[12:10] <dholbach> OK... what do we agree on now?
[12:11]  * persia thinks we agree that packages not submitted for the 4th February REVU day do not have a guarantee of review for inclusion in hardy.
[12:11] <sistpoty|work> how big is the revu backlog atm?
[12:11] <dholbach> persia: that's good enough
[12:11] <persia> sistpoty|work: Only two or three packages that didn't get hit in the last REVU day, and about 25-30 that will be part of the next.
[12:11] <dholbach> [AGREED] packages not submitted for the 4th February REVU day do not have a guarantee of review for inclusion in hardy
[12:11] <MootBot> AGREED received:  packages not submitted for the 4th February REVU day do not have a guarantee of review for inclusion in hardy
[12:12] <sistpoty|work> persia: ah, ok
[12:12] <dholbach> regarding "Also, there are a fair number of packages still in their final REVU cycles.  If anyone has any ideas about how to best grab those we want for hardy in time for FeatureFreeze, please share." - do you think it'd help to have blog entries with a list of those packages to raise interest?
[12:12] <persia> Anyone have any ideas about how to encourage more reviewers for the next three REVU days?  Lots of packages are close, but it needs more eyes.
[12:13] <TheMuso> Unfortunately, I won't be around for the january 27th day
[12:13] <TheMuso> But will do my best to attempt to help with the others
[12:13] <persia> dholbach: Depends on the goal.  If the goal is to advertise packages interesting to the blogger, sure.  If the goal is to list things, I think the blogger reviewing everything would be more useful.
[12:14] <dholbach> we can also post the list of packages that are 'nearly there' to ubuntu-motu@ and ubuntu-devel@
[12:15] <dholbach> there are a lot of people who don't scan REVU regularly
[12:15] <persia> That sounds sane.  I'll post a list of packages needing review at the start of the next REVU day.
[12:15] <persia> Any other ideas?
[12:16]  * pochu waves
[12:16] <dholbach> that's a great start
[12:17]  * persia cedes the topic, based on discussion having come to a close
[12:17] <dholbach> you're right... a blog might probably not adress the right people
[12:19] <dholbach> ok... sorry I was distracted by another question
[12:19] <dholbach> moving on
[12:19] <dholbach> [TOPIC] Other business
[12:19] <MootBot> New Topic:  Other business
[12:19] <dholbach> is there any other business?
[12:19] <dholbach> going once
[12:19] <dholbach> twice
[12:19] <dholbach> [TOPIC] agree on date and time of next meeting
[12:19] <MootBot> New Topic:  agree on date and time of next meeting
[12:20]  * persia proposes 2008 February 1st 20:00 UTC
[12:20] <dholbach> any opinions on date and time?
[12:20]  * dholbach will probably not make it
[12:21] <dholbach> DktrKranz: any opinion on date and time of the next MOTU meeting? (2008 February 1st 20:00 UTC :-))
[12:21] <DktrKranz> Sounds good for me
[12:22] <DktrKranz> (and proably will attend ...)
[12:22] <dholbach> ok... in absence of andbody complaining.... :-)
[12:22] <dholbach> [AGREED] Next MOTU Meeting is going to be 2008 February 1st 20:00 UTC
[12:22] <MootBot> AGREED received:  Next MOTU Meeting is going to be 2008 February 1st 20:00 UTC
[12:22] <dholbach> Meeting adjourned - thanks a lot everybody! :)
[12:23] <dholbach> #endmeeting
[12:23] <MootBot> Meeting finished at 12:23.
[12:23] <persia> Who is doing minutes?
[12:23] <persia> How about announcements for the next meeting?
[12:23] <dholbach> http://kryten.incognitus.net/mootbot/meetings/ubuntu-meeting.20080118_1202.html
[12:23] <dholbach> I'll do the announcement
[12:23]  * DktrKranz kicks at himself for being late.
[12:23]  * dholbach hugs DktrKranz
[12:23] <persia> DktrKranz: Since you have to read the logs anyway, maybe you want to do minutes?
[12:24] <DktrKranz> My next car will have wings, I swear!!!
[12:24] <dholbach> DktrKranz: be sure to post pictures! :)
[12:24] <DktrKranz> persia, sure.
[12:24] <dholbach> excellent - thanks a lot :)
[12:24]  * dholbach hugs persia and DktrKranz :)
[12:24] <DktrKranz> dholbach, can you remind me where mootbot shortlogs are?
[12:25] <mruiz> hi all
[12:25] <dholbach> DktrKranz: if you click on the meeting times it'll take you to the log (http://kryten.incognitus.net/mootbot/meetings/ubuntu-meeting.log.20080118_1202.html)
[12:25] <DktrKranz> thanks
[12:25] <ogra> DktrKranz, http://www.gyrotec.de/
[12:25] <ogra> they are pretty cheap :)
[12:25] <persia> DktrKranz: Also, ignore the first "AGREED".
[12:26] <persia> ogra: Those are too stubby to properly be called wings
[12:26] <DktrKranz> ogra, nice one. I need to check if Italy permits them, and no more traffic issues \o/
[12:26] <ogra> persia, it flies (with 200km/h)
[12:27] <persia> ogra: Yes.  I admit it's a flying car.  I'm just being pedantic and complaining that it's not a car with wings.
[12:27] <ogra> germany permits them (eastern german police uses them for traffic control)
[12:27] <persia> When I last lived in the united states, they were permitted for unlicensed use.
[12:27] <ogra> its not a helicopter .... it doesnt crash if you switch off the engine ;)
[12:28] <DktrKranz> Is it euro4? So I haven't to pay pollution taxes :)
[12:28] <ogra> heh
[12:29]  * sistpoty|work is off again, continue with working
[12:29] <sistpoty|work> cya


[15:13] <mhall119> maxolasersquad: congrats!
[16:08] <maxolasersquad> mhall119: Thanks.
[16:08] <maxolasersquad> And I'm glad you wrote that page because it was my next question for you.
[16:22] <mhall119> :)
[16:22] <mhall119> dholbach has been asking me to talk about going upstream since my first post


[00:07] <jsjgruber-x-q> JoseeAntonioR, I think I'm able to reproduce the problem in quantal--problem might be in a webkit or python-webkit component. Plugins are enabled. Please let me work on it a while and get back to you.
[05:54] <llstarks> was anything ultimately decided on rolling release or was the hangout just a briefing?
[06:27] <jsjgruber-x-q> [slidefile http://www.gnu.org/software/guile-gnome/docs/gtk/guile-gnome-gtk.pdf]
[06:28] <jsjgruber-x-q> [slidefile http://www.gnu.org/software/guile-gnome/docs/gtk/guile-gnome-gtk.pdf 3 ]
[06:33] <JoseeAntonioR> hey, jsjgruber-l85-q
[06:34] <jsjgruber-l85-q> Hi just trying a couple more things before I go to bed--you're up late too.
[06:34] <JoseeAntonioR> yep :)
[06:34] <JoseeAntonioR> I responded to your email btw
[06:35] <jsjgruber-l85-q> I saw it. Thanks a lot. Now I know what to work out. Before it was a total mystery. The SSE2 stuff is working fine, by the way.
[06:35] <JoseeAntonioR> great, then :)
[06:36] <jsjgruber-l85-q> In the morning I'll probably compare the midori and epiphany changelogs and see if epiphany did something to fix this.
[06:36] <JoseeAntonioR> great, thanks a bunch!
[06:36] <JoseeAntonioR> I really appreciate your efforts to get this working
[06:36] <jsjgruber-l85-q> Thank you.