[05:10] <Darkwing> Anyone know anyone that works on teh @ubuntu and @kubuntu forwards with Launchpad?
[05:17] <claydoh> ScottK: testing migration in kmail seems much  much better since your last upload: the migrator still fails, but after delting kmail-migratorrc and runnng it --interactive it all was migrated successfully, 1 imap(gmail), 2 d-imap and one pop account all went smoothly!,
[05:17] <claydoh> plus all my previous dimap cached messgaes were savded it theor own folders . 
[05:19] <claydoh> actually after running migrator manually, starting kmail prompted for the migrator again, which I rn just for fun, but it errored saying it had already been run. I closed it, then kmail opened to the well-migrated state.
[05:20] <claydoh> so you got us somewhere ! No errror messages downloading mail, either
[05:20] <claydoh> +1
[05:22] <claydoh> oops soory for draggin it on, but you do have  to reload any folders with previous mails to have then show, which will obviously not be obvious to users
[05:23] <Darkwing> So KMail is fixed?
[05:27] <claydoh> well mostly,  filters are not migrated (but that is known) , and a previously fixed bug has re emerged (gotta get hte number, it is the one where you can't filter based on mailing list id
[05:28] <claydoh> and I am awaiting spam to see if the spam filtering will move the junk mail  to the junk folder
[05:28] <claydoh> Darkwing: this is in a vm atm, for migration testing, I have a mostly working kmail setup from scratch for daily use
[05:29] <Darkwing> claydoh: Okay
[05:29] <claydoh> gotta remember to not delte the spam when using my droid
[05:29] <Darkwing> :D
[05:30] <Darkwing> I'm having massive issues with my email..
[05:30] <claydoh> phone=timesucker lol
[05:30] <Darkwing> I changed primary email in launchpad and they stopped sending to my old but failed to start sending it to my new one.
[05:30] <Darkwing> Yeah, it is. I love my galaxy s though.
[05:31] <claydoh> Darkwing: yeah, in mine, there are errors everywhere on one account, and often massive  dupes on another, 
[05:32] <claydoh> wish I could have one of those, have a droid charge, samsung and amoled  screen goodness so far, for this phone noob
[05:32] <Darkwing> VZW?
[05:32] <claydoh> yeah
[05:33] <Darkwing> :D I wanted a charge but all I could afford was a Fascinate. (Galaxy S)
[05:34] <claydoh> lol same here, but amazon had a penny sale on everything but the newest (bionic) plus a 50 buck gift card, so i get paid for the phone lol 
[05:35] <Darkwing> lol
[05:35] <claydoh> the wife has a fascinate, I am not allowed to touch it
[05:35] <Darkwing> :D I rooted mine and am running CyanogenMod7 on it.
[05:36] <claydoh> I rooted mine this past monday, just running a leaked vzw gingerbread 
[05:36] <claydoh> I lasted one week before rooting
[05:37] <claydoh> I actually like the touchwhiz, tho have not played enough with any other launchers
[05:38] <claydoh> gingerbread means front cam with skype/google
[05:38] <Darkwing> Yup.
[05:38] <Darkwing> I've been running gingerbrad for a while. Had the first Droid and have been running GB on it since Google opened the souce.
[05:41] <claydoh> I am getting decent battery life, though i can't really use it too much when I at work, so I get a full day before charging
[05:42] <Darkwing> I normally keep it plugged into my computer so, I think that UDS will be my first real test on batt life.
[05:43] <claydoh> I hope there is 4g there, that would be nice
[05:43] <claydoh> just to see
[05:44] <Darkwing> You don't have 4g where you are?
[05:44] <claydoh> nope
[05:45] <claydoh> I don't know if there is any 4g in Maine
[05:46] <Darkwing> Ahhh, fun.
[05:53] <claydoh> no, but in reality, the 3g is almost as fast as te dsl I had not too long ago :)
[10:00] <bambee> morning
[10:05] <bulldog98_> moin moin :)
[10:16] <yofel> o/
[10:29]  * yofel goes reinstalling oneiric on his thinkpad
[10:29] <yofel> might as well make an iso test while I'm at it
[10:52] <yofel> bulldog98_: btw. does gles work on your eeePC? Doesn't work on mine
[11:18] <bulldog98_> yofel: never tested that
[11:18] <yofel> for me kwin says "incomplete GLES support" and disables compositing
[11:23] <yofel> mgraesslin: do you know if kwin is supposed to work with MESA 7.11 GLES on intel? I'm getting http://paste.kde.org/131347
[11:24] <mgraesslin> yofel: no idea, have never seen that
[11:24] <mgraesslin> seems to be inside the mesa library
[11:24] <yofel> k, thanks
[12:36] <allee> yofel: is this the inofficial i915g. In this case opengl 2.0 was reached annouced yesterday: http://feedproxy.google.com/~r/Phoronix/~3/G9XiSH1DxiE/vr.php
[12:37] <yofel> *shrug* - it's whatever driver we have in the oneiric archive
[12:38] <allee> oh, I was guessing due to word gallium in your output: 'OpenGL renderer string:                 Gallium 0.4 on i915 (chipset: 945GME)'
[13:08] <sheytan> apachelogger: ping pin
[13:08] <sheytan> g
[13:10] <sheytan> hey guys
[13:11] <sheytan> i made the cd cover for oneirc
[13:11] <sheytan> where to upload it?
[13:32] <claydoh> ScottK: so, the append failed messages are back in kmail, assuming they never left
[13:32] <claydoh> on d-imap
[13:36] <sheytan> http://img593.imageshack.us/img593/5996/front2kf.jpg
[13:37] <GirlyGirl> Hi the pre rc iso for testing ... does it include KDE SC 4.7.2?
[13:41] <GirlyGirl> sheytan: Is the cd cover such a secret that it has to be kept private?
[13:42] <sheytan> GirlyGirl: why? Did  i hide it somehow?
[13:44] <GirlyGirl> sheytan: Clicking it gives me http://imageshack.us/img/blocked_login.jpg
[13:44] <sheytan> GirlyGirl: well, not for me and others :)
[13:45] <GirlyGirl> sheytan: Wow rekonq does that , opera shows it :d
[13:45] <GirlyGirl> sheytan: nice cover btw
[13:46] <sheytan> GirlyGirl: thank you :)
[13:47] <GirlyGirl> sheytan: What did you use for that ... Gimp , inkscape
[13:47] <sheytan> GirlyGirl: both :)
[14:59] <allee> sheytan: cool cover!    
[15:04] <allee> yofel: I'm curious what driver it is. On your eeepc    grep drivers/  /var/log/Xorg.0.log 
[15:07] <ximion> hi there! Could someone upload the Apper package to Ubuntu?
[15:28] <ximion> ScottK: ping
[15:31] <ScottK> claydoh: I don't think they did.
[15:31] <ScottK> ximion: pong
[15:32] <ScottK> claydoh: Great news on the migration.
[15:33] <shadeslayer> ScottK: Mac ISO still doesn't boot and i think its because the kernel doesn't properly pick up the HDD
[15:34] <shadeslayer> someone was working on that iirc
[15:34] <ximion> ScottK: I don't think we will have an Apper release in time, so is it okay if I package a Git snapshot of Apper?
[15:35] <ximion> The tools is very stable and I fixed some last issues upstream
[15:35] <shadeslayer> ScottK: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/782389/comments/21
[15:35] <ximion> the bug mentioned by dantti last time has also been fixed last night
[15:50] <claydoh> ScottK: just wish we could suppress the error messages, the imap seems to work despite the error, 
[15:51] <claydoh> I wonder why it is on one mail server (my webhost) and not gmail
[15:55] <ScottK> claydoh: I've tried to trace where they are coming from and didn't find it yet.
[15:55] <ScottK> ximion: Yes.
[15:55] <ScottK> shadeslayer: Make sure you mark the bug against the ISO testing results in the QA tracker.
[15:55] <shadeslayer> sure
[15:56] <ScottK> Quintasan: Could you take care of sponsoring ximion?
[15:56] <shadeslayer> Altho, i did manage to boot it off a normal PC with a BIOS
[15:56] <shadeslayer> works just fine there
[16:09] <yofel> allee: 
[16:09] <yofel> [    10.727] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
[16:09] <yofel> [    10.816] (II) intel(0): [DRI2]   DRI driver: i915
[16:09] <yofel> [    10.965] (II) AIGLX: Trying DRI driver /usr/lib/i386-linux-gnu/dri/i915_dri.so
[16:10] <yofel> and oneiric has
[16:10] <yofel> !info xserver-xorg-video-intel oneiric
[16:24] <allee> yofel: strange I'm using intel too.  but my output mesa output is completly different   http://paste.ubuntu.com/704514/
[16:25] <allee> seems to be that GL capabilities are strongly dependend some hw spec. support in kernelmod i915
[16:32] <ximion> ScottK, Quintasan: Package is now available here: http://revu.ubuntuwire.com/revu1-incoming/apper-1110081830/apper_0.7.0~20111008-0ubuntu1.dsc
[17:07] <ScottK> ximion: What about the packagekit update?
[17:07] <ximion> ScottK: The PackageKit update is not necessary if apper is uploaded
[17:07] <ScottK> Ah.  OK.
[17:08] <ximion> (then it would be stupid to ship a outdated lib)
[17:08] <ximion> the new PackageKit-Qt2 library is nearly twice as fast as the old one :)
[17:08] <ScottK> Nice.
[17:09] <ximion> Apper is noticeable faster than KPackageKit...
[17:09] <ScottK> That was definitely one of the points against it.
[17:10] <ximion> ScottK: theoretically, PK could be as fast as Synaptic, but the APT backend of PK is not in the best shape
[17:10] <ximion> and apt's api is just terrible...
[17:11] <ScottK> IIRC that was part of the motivation behind libqapt - to minimize the amount people had to deal with the apt API directly.
[17:11] <ximion> I talked with Richard Hughes about this issue at desktop summit and he showed me how the Zif backend works (Zif is a RPM package manager)
[17:11]  * yofel remembers JT saying something along those lines while writing libqtapt ^^
[17:12] <ximion> if it is possible for apt what he did with Zif, PK would be super-fast
[17:15] <ximion> I would like a API on top of APT which queries APT directly for apt-specifig operations (e.g. holding of packages) and PK for the rest
[17:15] <ximion> maybe write a small daemon for this
[17:16] <ximion> by doing it that way, we would only have to maintain one piece of terrible apt code
[17:17] <ximion> (the best option would be to replace aptdaemon with this api too)
[17:17] <ximion> I recently tested the PackageKit branch of the Ubuntu Software Center, and the native stuff is still faster, but APTcc becomes better with every release
[17:17] <ximion> :-)
[17:21] <yofel> I don't think slowness was the issue with kpackagekit, more that it simply didn't work right.
[17:21] <yofel> It doesn't really help if your update get's stuck somewhere in the middle
[17:21] <yofel> *gets
[17:29] <glatzor> ScottK, ximion: and that is why we use python-apt in aptdaemon
[17:30] <glatzor> ximion, aptdaemon will provide a more complete implementation of the packagekit api in P compared to the aptcc backend
[17:31] <glatzor> ximion, ScottK I am working on a compaitibility layer which provides the packagekit system dbus interface
[17:34] <ximion> glatzor: The only missing feature in aptcc is installation of local files at time, because apt doesn't support this...
[17:35] <ximion> juliank is working on this
[17:36] <ximion> aptdaemon can maybe cover more features of apt than PK can, but the implementation of PK's session bus is the same in GNOME-PackageKit/Apper and your implementation
[17:39] <glatzor> ximion, I am not talking about the session interface
[17:39] <glatzor> ximion, you can run apper/gpk-application with aptdaemon already
[17:40] <ximion> glatzor: oh, that's nice! :)
[17:40] <ximion> but what is missing in PK?
[17:40] <ximion> every feature is implemented
[17:40] <ximion> only the apt backend needs some love
[17:42] <ximion> is gpk-application faster with aptdaemon?
[17:46] <glatzor> ximion, I haven't made any profiling yet
[17:46] <ximion> ScottK: hmm, looks like Quintasan is missing...
[17:46] <ximion> glatzor: maybe I can do this later...
[17:47] <glatzor> ximion, It is not yet part of the main branch.
[17:47] <ximion> at time, aptcc is a little bit slower if you do many fast requests, e.g. fetching descriptions
[17:47] <ximion> this is because aptcc does not leave the cache open
[17:47] <ximion> PK has methods to handle opening/closing of caches
[17:48] <ximion> but aptcc does not use them (yet)
[17:48] <ximion> glatzor: okay
[17:48] <glatzor> ximion, how could pk help aptcc in handling its package cache?
[17:49] <ximion> at time I see aptdaemon as the Debian/Ubuntu-only variant of PackageKit, with less shared code and duplication of functionality, but as a good alternative to use until PK reaches APTd's functionality.
[17:49] <ximion> can you tell me something _only_ APTd can do?
[17:50] <ximion> glatzor: it just tells the backend when to open/close the cache
[17:50] <glatzor> ximion, in a first approach I even removed the need to queue query transaction (e.g. GetDetails). They could be processed before install/removal or even during an installation
[17:50] <ximion> via plugins the native tool like Synaptic can also interrupt PK and force it to unload the cache
[17:51] <ximion> sounds like PK's parallel-transactions... A feature I started which is now continued by richard
[17:52] <glatzor> ximion, metadata, plugins (was designed for automatically installing language packs), chaining of transactions, config file conflicts, terminal widget, hierachic policykit priviliges
[17:52] <glatzor> ans some more
[17:52] <ximion> glatzor: do you process all query transactions at once or do they just live in a queue which is executed in parallel to write transactions?
[17:53] <ximion> okay, I don't know what chaining pf transactions is... that one transaction can invoke another?
[17:53] <ximion> the terminal widget is impossible with hughsie
[17:53] <ximion> in his opinion showing a terminal is the UIs way of saying "I give up"
[17:53] <ximion> first I was against him, but now I think he's right
[17:57] <glatzor> ximion, it was in a separate  but now they just get queued as the rest - apt doesn't support threading. So you have to lock access to cache internally
[17:57] <glatzor> ximion, depends on the use case. Could be true for Ubuntu but not for Debian.
[17:57] <yofel> no terminal is ok as long everything goes right, but when something goes wrong I don't know a GUI that handles the situation in a good way.
[17:58] <glatzor> ximion, I have to leave for dinner now.
[17:58] <yofel> for example: how does apper inform you that a package failed to install with an I/O error?
[17:58] <glatzor> ximion, I will write an email to the pk list in the next days with the current state and the plans for the future
[17:59] <ximion> glatzor: That would be nice!
[18:00] <ximion> although I am a PK guy, I would like to hear something about aptd
[18:00] <ximion> aptd shows what Debian wants
[18:00] <ximion> yofel: it shows an error dialog with the error message
[18:00] <yofel> the full message from dpkg?
[18:01] <yofel> then ok
[18:02] <ximion> not the full log, but the APT error
[18:02] <ximion> e.g. if there's a file conflict it shows which files conflict
[18:02] <yofel> problem is that *that* usually is something like "post-installation script failed with exit status 1" - which is useless with the error from dpkg
[18:03] <yofel> *without
[18:04] <ximion> yofel: maybe we can attach the full log...
[18:04] <ximion> or write a PK plugin which forwads the output (bad idea, but possible)
[18:05] <yofel> add a details view/tab that shows the actual dpkg output for that package (not the full log). That way people can get help on the error without having to look up files in /var/log/apt/
[18:06] <yofel> bbl
[18:07] <ximion> bes way ist to never make it fail :D
[18:16] <Quintasan> ximion: I'm back
[18:24] <ximion> Quintasan: cool! Could you maybe take a look at the apper package and upload it if you find that the packaging is okay?
[18:24] <ximion> http://revu.ubuntuwire.com/revu1-incoming/apper-1110081830/apper_0.7.0~20111008-0ubuntu1.dsc
[18:28] <Quintasan> Uhh, ximion, what is that desktop.db in debian/ ?
[18:28]  * Quintasan has never seen this before
[18:28] <Riddell> weird e-mail du jour http://paste.kde.org/131479/
[18:29] <Quintasan> Ah
[18:29] <Quintasan> app metadata
[18:30] <Quintasan> ximion: Please file a bug with needs-packaging tag and give me the bug number, okay?
[18:30] <Quintasan> ScottK: ping
[18:30] <Quintasan> ximion: Or not. Wait a moment please
[18:31] <ximion> Quintasan: okay
[18:31] <ximion> I need to leave now, I'll be back late this evening
[18:31] <Quintasan> ximion: Apart from stuff like transitions, I believe a debug package would be appropriate
[18:31] <Quintasan> ximion: You have to add an entry in debian/control and then do override_dh_strip in debian/rules
[18:32] <ximion> Quintasan: Okay, I already did this for debconf-kde too
[18:32] <ximion> an I'll add an information that Apper breaks KPackageKit
[18:32] <Quintasan> I see
[18:32] <Quintasan> Well
[18:33] <Quintasan> ximion: We need Replaces, not breaks
[18:33] <Quintasan> and we needs transitional packages for smooth upgrade I believe
[18:33] <ximion> hmm... I really need to leave now... I will be back at 1:00 in the morning I guess...
[18:33] <Quintasan> but I am not sure about transitional packages
[18:34] <ximion> imo it's not necessary, but I'm not sure too
[18:35] <ximion> need to go... cu
[18:46] <ScottK> Quintasan: pong
[18:46] <ScottK> Quintasan: Needs packaging bug is totally optional.
[18:47] <ScottK> Quintasan: It should have transitional packages and Breaks/Replaces.
[19:02] <yofel> re
[19:21] <shadeslayer> Riddell: whoa, you're dealing with a price there
[19:21] <shadeslayer> "Prince Cassim Adepegba"
[21:08] <ximion> ScottK: Should I add a transitional package for kpackagekit to the new apper pkg or should I just "break" the kpk package in the apper package?
[21:08] <ScottK> Both.  The breaks needs to be versioned.
[21:13] <ximion> ScottK: okay - but if the pkg gets uploaded to Debian, I have to remove the transitional package again
[21:13] <ScottK> True.
[21:13] <ScottK> Most people would have it installed due to kubuntu-desktop anyway.
[21:14] <ScottK> So if it gets removed due to the upgrade and muon replaces it, that's not so bad.
[21:33] <ximion> Quintasan: new pkg ready.
[21:33] <ximion> do you have a bug number which this new package should close?
[21:33] <ximion> entering my Debian ITP there seems a bit weird :P
[21:33] <Quintasan> Nope, ScottK said it's not necessary
[21:34] <Quintasan> ximion: Did you upload to REVU
[21:34] <Quintasan> ?
[21:34] <ximion> yes, revu is processing it at time
[21:34] <ximion> http://revu.ubuntuwire.com/revu1-incoming/apper-1110081857/apper_0.7.0~20111008-0ubuntu1.dsc
[21:34] <ximion> Quintasan: ^
[21:35] <ximion> it's uploaded, but not yet shown in the UI
[21:36] <ximion> Quintasan: evu processed the package now, you can download it, I think :)
[21:37] <ximion> I did not run an explicit upgrade-test, but this should work. it always worked like this before when I renamed a package :P
[21:45] <Riddell> shadeslayer: fancy titles don't impress me
[22:02] <ximion> Quintasan: ping me, if you've any change/comment :)
[22:03] <Quintasan> Wait, waht
[22:03] <Quintasan> ximion: debian/control
[22:03] <Quintasan> no need for # Transitional dummy package
[22:03] <Quintasan> >Description: Safe and easy web browser from Mozilla - transitional package
[22:04] <Quintasan> How KPK is a web browser?
[22:04] <Quintasan> Replaces: oldname (<< 0.6.3.3-0ubuntu2~)
[22:04] <Quintasan> Breaks: oldname (<< 0.6.3.3-0ubuntu2~)
[22:04] <Quintasan> That would replace package "oldname"
[22:05] <Quintasan> !info kpackagekit
[22:05] <ximion> Quintasan: ? which version have you got?
[22:05] <ximion> one moment...
[22:06] <Quintasan> ximion: I was wondering what version of kpk do we have in natty
[22:06] <Quintasan> 0.6.3.3-0ubuntu2
[22:06] <Quintasan> You have 0.6.3.3-0ubuntu2~ there so I don't think it will work
[22:07] <Quintasan> Section of kpackagekit transitional package should be "kde"
[22:07] <Quintasan> ScottK: IMHO apper should Depend on debconf-kde-helper
[22:08] <ScottK> Quintasan: If you say so.
[22:08]  * ScottK doesn't have time to sort out the details.
[22:08] <ximion> Quintasan: Why should the section be kde?
[22:08] <Quintasan> ximion: Becasue it's a kde-related package?
[22:08] <ximion> if it is oldlibs, repo cleanup tools will suggest removing the transitional package
[22:10] <ximion> Quintasan: tools like deborphan (?) (don't know if this is the name of it) can delete transitional pkgs if they're marked as "oldlibs"
[22:11] <Quintasan> ximion: Hmm, that makes sense. Leave it in oldlibs then
[22:11] <ximion> also, shouldn't "0.6.3.3-0ubuntu2~" replace everything below 0.6.3.3-0ubuntu2 and all possible backports/fixes
[22:11] <Quintasan> Still the Description is wrong
[22:12] <Quintasan> and remove the comment please
[22:12] <ximion> please pull the package again from revu, looks like I uploaded crap last time :P
[22:12] <Quintasan> also move debconf-kde-helper to Depends
[22:12] <ximion> Quintasan: debconf-kde-helper is a tool which makes command-line applications of PackageKit, like "pkcon" show debconf kde dialogs
[22:12] <ximion> it is not required to run apper
[22:13] <ximion> (although it is useful)
[22:13] <ximion> apper embeds debconf dialogs directly and does not need to spawn an external application
[22:13] <Quintasan> ximion: Well, it is not but when you install some package using debconf and debconf-kde-helper is not installed then what happens?
[22:14] <ximion> Quintasan: If you install it via apper, a debconf-dialog is shown in Apper. If you install it via apt-get, a dialog is shown. If you install it via "pkcon", PackageKit will try the GNOME-dialogs and if this does not work set the debconf-frontend to passthrough
[22:15] <ximion> so the helper is only needed if a user uses PackageKit command line tools under KDE
[22:15] <Quintasan> Hmm.
[22:15] <Quintasan> Okay then, leave it as it is
[22:15] <ximion> Apper already depends on debconf-kde to embed debconf dialogs send by PackageKit
[22:15] <Quintasan> This looks sane to me
[22:16]  * ximion checks if revu pkg and local pkg are the same - just to be sure this time...
[22:17] <ximion> Qintasan: good :)
[22:17] <ximion> (and the revu package really is the pkg I have here locally :P)
[22:18] <Quintasan> Let me pbuild it and see what lintian has to say
[22:19] <debfx> ximion: shouldn't apper break kpackagekit (<= 0.6.3.3-0ubuntu2)?
[22:19] <ximion> I hope it is just the warning about a missing manpage  ^^
[22:20] <ximion> debfx: I followed the usual instructions: http://wiki.debian.org/Renaming_a_Package
[22:20] <ximion> but <= would make sense to me too.
[22:20] <ximion> but "<<" also works
[22:21] <debfx> those instructions suggest << 0.7.0~20111008-0ubuntu1~
[22:21] <ximion> (you can use dpkg --compare-versions to test it)
[22:21] <ximion> yep.
[22:21] <ximion> sh*
[22:22] <ximion> this happens if you go out of the pub and sit down on your computer right afterwards...
[22:24] <ximion> debfx: thank you for the attention!
[22:24] <Quintasan> yup, thanks debfx
[22:24] <ximion> I did this in a hurry before I left and simple forgot to be careful enough
[22:25] <Quintasan> ximion: Yeah, it complains about missing manpage and watch file
[22:25] <ximion> Quintasan: I fixed the version issue at revu now
[22:25] <ximion> okay, that's okay
[22:25] <ximion> :P
[22:25] <Quintasan> Well, it's not really okay but it's not an error
[22:25] <ximion> I will write a manpage later, if this is okay
[22:25] <Quintasan> Fair enough
[22:26] <ximion> most of the time packaging new software you write manpages :P
[22:26] <Quintasan> Not really, go ahead and package a library
[22:27] <ximion> I'll send one upstream soon, so this gets solved for everyone
[22:27] <ximion> Quintasan: like projectM? :D
[22:27] <ximion> this was my most complicated package.
[22:27] <ximion> now I am projectM upstream...
[22:27] <ximion> we apply over 15 patches to the source downstream to make the lib work somehow...
[22:28] <Quintasan> symbols etc.
[22:28] <Quintasan> maintaining that is a hell sometimes
[22:28] <ximion> or debconf-kde lib - the symbols file is evil :P
[22:28] <ximion> yes, exactly!
[22:28] <Quintasan> Uhh
[22:28] <Quintasan> ximion: Did you test apper?
[22:29] <Quintasan> http://wstaw.org/m/2011/10/09/plasma-desktopFd2079.jpg
[22:29] <ximion> Quintasan: yes, I'm using the git version here, but I also removed the git snapshot to test the package
[22:29] <ximion> works very well here
[22:29]  * debfx would think that being upstream helps pushing patches upstream ;)
[22:29] <Quintasan> ximion: Look at the screenshot
[22:29] <ximion> very meaningful message...
[22:30] <ximion> do you get a nice terminal output?
[22:30] <ximion> I guess it's a query to desktop.db
[22:30] <ximion> but then I wonder why I don't get this...
[22:30] <Quintasan> apper(24282)/kdecore (KLocale) KLocalizedStringPrivate::toString: Trying to convert empty KLocalizedString to QString.
[22:30] <Quintasan> apper(24282)/kdeui (KNotification) KNotificationManager::close: 3441
[22:30] <Quintasan> apper(24282)/kdeui (KNotification) KNotificationManager::close: 3452
[22:32] <ximion> Quintasan: works for me... => http://image-upload.de/image/WJVJD3/66e3595e77.png
[22:33] <Quintasan> Well, it doesn't work here
[22:33] <Quintasan> oneiric
[22:33] <ximion> what happens if you "sudo rm /usr/share/app-install/desktop.db" ?
[22:33] <ximion> oneiric too...
[22:33] <Quintasan> Let me rebuild it and reinstall
[22:34] <ximion> pleas etry to start it without desktop.db first :)
[22:34] <ximion> Quintasan: ^
[22:36] <Quintasan> QSqlDatabasePrivate::database: unable to open database: "unable to open database file Error opening database" 
[22:36] <Quintasan> QSqlQuery::prepare: database not open
[22:38] <ximion> Quintasan: as an error message?
[22:38] <ximion> because we can disable the desktop.db, if it causes problems...
[22:38]  * ximion has an idea
[22:38] <Quintasan> ximion: konsole output when I try to double click a category
[22:55] <utusan> does frozen means kubuntu 11.10  comes out not with 4.7.2?
[22:55] <ximion> Quintasan: if you remove the "-DAPPINSTALL=true" line in debian/rules, does this remove the issue too?
[22:56] <Quintasan> ximion: No idea, how about you try that?
[22:56] <ximion> Quintasan: try it! :)
[22:56] <Quintasan> utusan: I believe it comes out with 4.7.1 but we will provide upgrade to 4.7.2 as soon as possible
[22:56] <ximion> Apper works like a charm here...
[22:56] <ScottK> utusan: Yes.  We'll try to have it updated shortly after release.
[22:56] <utusan> Quintasan, thanks
[22:56] <ximion> if this flag is disabled, apper will loose it's application manager functionality.
[22:56] <ScottK> utusan: The kdepim related packages are updated though.
[22:56]  * ScottK slid those in.
[22:59] <Quintasan> ximion: LOL
[22:59] <Quintasan> http://wstaw.org/m/2011/10/09/plasma-desktopYc2079.jpg
[23:00] <Quintasan> More categories somehow
[23:00] <ximion> it just stopped loading categories before... .P
[23:00] <ximion> but why does this work for me?
[23:01] <ximion> we're using exactly the same database...
[23:01] <Quintasan> I have absolutely no idea
[23:01] <utusan> ScottK, thanks.
[23:01] <Quintasan> ximion: I'm not really content with uploading apper like this
[23:01] <ximion> but better have an Apper without AppInstall support in oneiric than having no apper :P
[23:02] <ximion> Quintasan: does everything else work?
[23:02] <ximion> (it should work)
[23:02] <Quintasan> shadeslayer: Can you testbuild and install apper with the -DAPPINSTALL=true flag and report back if clicking on categories does yield http://wstaw.org/m/2011/10/09/plasma-desktopFd2079.jpg ?
[23:02] <ximion> this issue was the result of myself using a new script to generate desktop.db, because the old one was broken.
[23:02] <Quintasan> yofel: Same as above but without the -DAPPINSTALL=true flag
[23:03]  * ximion investigates the database and Apper code regarding AppInstall support
[23:04] <Quintasan> ximion: Upgrading doesn't work here
[23:04] <ximion> :(
[23:04] <ximion> Quintasan: with which error?
[23:04]  * yofel dgets
[23:06] <Quintasan> ximion: http://i.imgur.com/vhUD2.png
[23:06] <Quintasan> Details say
[23:06] <Quintasan> "couldn't find package"
[23:06] <Quintasan> Probably multi-arch magic
[23:06] <yofel> very detailed...
[23:07] <ximion> Quintasan: sorry, what do you mean with upgrading? Upgrading from kpackagekit -> apper or doing an upgrade using Apper which works with Synaptic?
[23:07] <Quintasan> Doing any upgrade with Apper
[23:07] <Quintasan> I don't care if it's working in Synaptic
[23:08] <ximion> Quintasan: *any*!? Does this include *updates*, meaning if no package gets removed?
[23:08]  * ximion wants dantti here
[23:08] <yofel> lol, uploading screenshot
[23:08] <Quintasan> ximion: yes for Christ's sake, UPDATE did not work here
[23:09] <Quintasan> with this very detailed message
[23:09] <yofel> ximion: this is what apper looks like for me http://people.ubuntu.com/~yofel/pics/apper.png
[23:09] <ximion> wow
[23:09] <Quintasan> yofel: kbuildsycoca4
[23:09] <Quintasan> This shit is somehow a plague here too
[23:09] <yofel> ah, makes sense, trying again
[23:10] <ximion> Quintasan: is packagekit installed?
[23:10] <Quintasan> ximion: Are you seriously asking me this?
[23:10] <ximion> what happens if you run "pkmon" in a second terminal?
[23:10] <Quintasan> ximion: http://paste.kde.org/131533
[23:10] <ximion> Quintasan: this is an expression of "I don't know why this stuff does not work" ^^
[23:11] <yofel> next issue: http://people.ubuntu.com/~yofel/pics/apper1.png
[23:11] <yofel> I managed to open one category, now everyone fails
[23:11] <Quintasan> yofel: So you built it with -DAPPINSTALL=true, right?
[23:11] <Quintasan> This is broken then
[23:11] <yofel> Quintasan: ah no, I built the package
[23:11] <yofel> sry
[23:11] <Quintasan> yofel: No, no, it's good
[23:12] <Quintasan> the package from REVU has this flag
[23:12] <yofel> oh wait, I can open fonts
[23:12] <Quintasan> yofel: I could open them too, but nothing else
[23:12] <Quintasan> Building Apper without -DAPPINSTALL=true seems to be fixing the issue
[23:12] <yofel> and accessibility, those 2 work
[23:13] <yofel> wait... is packagekitd seriously taking like 2 _minutes_ to create the package DB o.O?
[23:14] <ximion> okay... => http://i.imgur.com/IAv5y.png
[23:14] <ximion> AppInstall is broken
[23:14] <yofel> on an intel i7 2.6GHz
[23:14] <ximion> at least with an updated desktop.db
[23:14] <ximion> using the db from natty would work...
[23:14] <Quintasan> ximion: That's not really a problem now, you know
[23:14] <Quintasan> How I am to upload a package manager that can't upgrade?
[23:15]  * yofel is still waiting for packagekitd to finish reading the package lists so he can try to update
[23:16] <yofel> I think I remember now why I started hating packagekit at some point
[23:16] <ximion> yofel: that's weird - I never got any of these issues reported with GNOME-PackageKit...
[23:16] <ximion> so it is apper
[23:16] <yofel> well, the process that's using 100% CPU now for a while is packagekitd
[23:16] <ximion> Quintasan: right, if this won't work today, I hope dantti will show up tomorrow
[23:16] <yofel>  4816 root      20   0  258m  93m  41m S   97  1.2   3:37.71 /usr/lib/packagekit/packagekitd                                                                                                   
[23:17] <ximion> yofel: kill it and try again :(
[23:17] <Quintasan> Well, either way ximion I'm heading to bed since I'm kinda tired
[23:17] <yofel> yay, it finished
[23:17] <Quintasan> Ahh governmental elections tomorrow
[23:17]  * Quintasan is getting to vote this year
[23:18] <ximion> Quintasan: okay. thanks for your patience, I'll contact you tomorrow with a solution, I hope :P
[23:18] <yofel> ok, updating seems to work WITHOUT multiarch (I'm not using it)
[23:18] <Quintasan> That's the main problem then.
[23:18] <Quintasan> Quintasan::gotoBed();
[23:18] <ximion> yofel, Quintasan: I use multiarch... and it works :P
[23:19] <ximion> PK itself supports multiarch
[23:19] <ximion> and apper should support it
[23:19] <yofel> ximion: even if you have package conflicts? because aptitude works with multiarch too - until you have a conflict
[23:19] <yofel> then it'll happily remove libc6 etc...
[23:19] <Quintasan> Well then, good night
[23:19] <yofel> gn
[23:19] <ximion> gn8
[23:20] <ximion> yofel: aptcc, the apt backend of PK, is based on Synaptics code. So I guess it will suggest the same things :P
[23:21] <ximion> yofel: I uploaded a new pkg to revu, this one hould work now
[23:21] <ximion> but it does not solve the update issue
[23:21] <ximion> hmm, dantti said something about it
[23:21] <ximion> but he told be this bug was fixed...
[23:22] <ximion> bow! Muon is running amok...
[23:22] <Darkwing> Still no emails.
[23:27] <claydoh> Darkwing: kmail?
[23:27] <yofel> ximion: the last upload was supposed to fix... what?
[23:36] <ximion> yofel: the "invalid query" issues
[23:36] <yofel> what I get from http://revu.ubuntuwire.com/details.py?upid=9295 doesn't fix it
[23:37] <ximion> okay, diabling the feature completely then
[23:58] <Darkwing> claydoh: No, my @ubuntu/@kubuntu forwards