[00:59] inane error du jour: http://tinyurl.com/7u62bak v.v [01:00] turns out, function pointers are always nonzero :P [01:06] always :P [01:25] I'll blame tab completion :P [02:57] yofel_: Should be in main. === ronnoc_ is now known as ronnoc [03:07] yofel_: Being promoted. [03:35] * genii-around sips === rdieter_laptop is now known as rdieter === amichair__ is now known as amichair [09:25] [lp:~kubuntu-packagers/kubuntu-packaging/kde-workspace] Philip Muškovac * 640 * debian/ (changelog control) Switch boost build-dep to 1.49 [09:46] can anybody help me with this log? https://launchpadlibrarian.net/105030999/buildlog_ubuntu-precise-amd64.qapt_1.3.50-0~940~precise1_FAILEDTOBUILD.txt.gz [10:17] [lp:~kubuntu-packagers/kubuntu-packaging/kdepim-runtime] Philip Muškovac * 108 * debian/ (changelog control) Switch boost build-dep to 1.49 [10:19] apol: in libqapt1.install change usr/lib/libqapt.so.1.3.0 to 1.3.65 === yofel_ is now known as yofel === amichair__ is now known as amichair [10:20] hm [10:20] thanks [10:29] apol: a question: translations are imported to Muon Discover? [10:31] ulysses: imported? [10:32] apol: I installed Muon Discover from the PPA, and it is in English :( But I translated it to Hungarian [10:33] ulysses: well, upload the .po files to the hungarian svn repository [10:34] ulysses: in future versions the kde-l10n-hu package should provide it, I guess [10:34] uploaded [10:36] technically speaking, since muon is extragear I suppose the translations would be in the muon tar ;) [10:47] afiestas: http://paste.kde.org/477938/ when unpluggin bluetooth adapter while scanning [10:47] apachelogger: report a bug plz [10:49] no idea where, your application fails to give me a bug report button :P [10:50] I don't see debug symbols installed [10:50] not one bd .cpp file in that bt [10:50] my application fails to find them :D [10:50] there is BlueDevil::Adapter::unregisterAgent though :P [10:51] not useful [10:51] what version are you using? [10:51] your application also fails to tell me that :P [10:51] you need a khelpmenu somewhere, srsly [10:51] dude [10:51] !info bluedevil precise [10:51] check out the package you have installed [10:51] bluedevil (source: bluedevil): KDE Bluetooth stack. In component main, is optional. Version 1.2.2-0ubuntu1 (precise), package size 262 kB, installed size 1552 kB (Only available for linux-any) [10:51] afiestas: what is this? 1990? :P [10:52] checking installed packages [10:52] patches are welcomed [10:52] * apachelogger mumbles and scuttles off to *manually* search for dbg symbols [10:52] you should update yoru version [10:52] to a supported one [10:52] 1.2.3 [10:53] fixed a few fixed in there, one related to unregisterAgent [10:53] BUG: 298633 // Crash in kded daemon (ObexFtp module) [10:53] u telling me we have an unsupported version in a long term support release :O [10:53] nd another one in libbluedevil 1.9.1 [10:53] well not my fault [10:53] I do maintain the 1.2 branch [10:54] but kubuntu has not upgrade to 1.2.3 [10:54] I blame ScottK [10:54] blue* is imported from debian [10:54] * afiestas start packing, still in sfo [10:55] Hey all [10:56] uhm [10:56] http://packages.debian.org/changelogs/pool/main/b/bluedevil/bluedevil_1.2.3-1/changelog [10:56] afiestas: so now I need to revise, not ScottK is to blame but Debian [10:57] ftp://ftp.kde.org/pub/kde/stable/bluedevil/1.2.3/src/ [10:57] afiestas: and now not Debian is to blame but you :P [10:57] \o/ [10:57] ? [10:57] you releasing after us :P [10:57] * apachelogger runs a diff [11:01] afiestas: http://paste.kde.org/477956/ [11:01] aren't you using releaseme? cause I don't think you need that with releaseme [11:02] the find_package stuff anyway [11:16] afiestas: debian decided to change the packaging ecessivley, so we probably need to manual update the package and sru it -.- === amichair__ is now known as amichair [11:50] bulldog98_: i18n( "Install Mysqldump") that is terrible realy [11:55] bulldog98_: also I think mysqldump should be package separately [11:55] it appears to only link against low level libraries === echidnaman is now known as jtechidna === Quintasan_ is now known as Quintasan [12:29] Sup [12:34] Din [13:08] Darkwing: ping [13:15] JonTheEchidna: muon 1.4 alpha looks awesome great job [13:22] jovin: thank apol too :) [13:23] but thanks :) [13:26] hellos all [13:29] jtechidna: ah of course both of you, i didnt know :) [13:31] jtechidna, jovin \o/ :) [13:34] yofel, heya [13:34] lol: http://imgur.com/rJ6z0 [13:36] * koolhead17 is still in hangover [13:37] jtechidna: will Muon 1.3 alpha available on Oneiric? [13:37] 1.4* [13:38] ulysses: I think the cyberspace ppa has daily snapshots for oneiric, but I don't plan to support anything past the current release + the development release for the QApt Experimental PPA [13:38] https://launchpad.net/~cyberspace/+archive/cyber-stuff?field.series_filter=oneiric [13:39] Package: /var/cache/apt/archives/libmuonprivate1_1.3.65-0ubuntu1~precise1_amd64.deb [13:39] Error: trying to overwrite '/usr/share/kde4/apps/muon-installer/categories.xml', which is also in package muon-installer 1.3.1-0ubuntu2 [13:39] oops [13:39] dammit, I'll have to wait until I get home to fix that :( [13:39] jtechidna and apol: Yeah, good job on Muon, makes me use terminal a little bit less :P [13:40] :P [13:40] Now just somebody has to fix KMail once and for all [13:40] SHUT UP ALREADY WITH CANNOT APPEND FLAGS [13:40] Quintasan: #kontact :D [13:40] * Quintasan purges kmail back to hell [13:40] jtechidna: that doesn't contains my translation yet :( your packages in the QApt Experimental does [13:41] unfortunately I don't have the time necessary for maintaining packages for 3 releases :( [13:42] I understand [13:42] What's the name for Q release? [13:43] Quantal Quetzal or something [13:43] Urgh [13:43] this thing: http://images.nationalgeographic.com/wpf/media-live/photos/000/006/cache/quetzal_675_600x450.jpg [13:43] They really want me to break my tongue [13:43] lol [13:44] haha [13:45] Muon 1.4's codename is Energetic Elemental, after the creatures from this Dr. Who episode: http://tardis.wikia.com/wiki/Love_%26_Monsters :D [13:45] in keeping w/ the Doctor Who codename tradition ;-) [13:45] If QQ is supposed to be quantal, how do we do it? [13:45] Release and don't release at the same time? [13:45] lol [13:46] we could start another rumor about a rolling release :P [13:46] NO [13:46] haha [13:46] EVERYTHING BUT NOT ROLLING RELEASE [13:46] I'm getting out of here if we switch to rolling [13:46] what's wrong with rolling? [13:46] (just asking) [13:47] What's wrong with stable and current devel release separation? [13:48] jtechidna: Maybe we announce that we switch to emerge? [13:48] :P [13:48] doesn't benefit from projects that release-soon-release often [13:49] apol: no qa on rolling [13:49] who can guarantee that release-soon, release-often is better? [13:49] I prefer to have some testing done instead of PACKAGE ALL THE VERSIONS [13:50] well that works for the OS if you want [13:50] but there's little advantage in packaging only the last version of, let's say, digikam before the last release xD [13:51] jtechidna: Who is going to make some todos from uds discussion? [13:51] * Quintasan pokes apachelogger [13:52] or Darkwing [13:52] Muahahahaha [13:52] * Quintasan digs trough his basement looking for Might Stick of TODO Creation [13:53] s/Might/Mighty [13:57] JontheEchidna: ping [13:58] ximion: pong [13:58] (JontheEchidna is my laptop which is at home right nwo) [14:01] jtechidna: ah, makes sense! :) I wanted to ask you a few questions about QApt/Muon and the relation to PackageKit... [14:02] first of all, I'm doing a GSoC on AppStream, the underlying distro-agnostic technology for the Ubuntu Software-Center, which is also used on other distributions. [14:03] I'm driving the implementation at Debian and a (possible) update of some background stuff on Ubuntu too, but apt and the repository format will first need some changes for that. (will probably be finished with the end of this year) [14:03] the GSoC project is for OpenSUSE, btw. [14:03] * jtechidna nods [14:04] now, Muon has a very nice software-center-like feature, which uses the same AppStream infrastructure available on other distros too (only few changes necessary, which Ubuntu will do too, later) [14:05] it also ships an own Apt transaction daemon, the qapt-worker. [14:05] it would be awesome to make at least the MSC cross-distro using PackageKit. [14:06] right now, PK has some API missing, we're currently planning the changes so e.g. fetching package lists will be faster in future. [14:06] so, would you allow porting parts of Muon to PK, where it makes sense, so other distributions can use the software too? [14:07] (please remember that this is a long-term goal, won't happen now since I first have to fix the USC fork to use PK) [14:07] jtechidna: ^ [14:07] ximion: where are AppStream servers? [14:07] as in, for reviews and all [14:08] apol: distributions provide the necessary data by themselve [14:08] So let me start off by saying that I would like to see Muon integrate in with AppStream to some degree [14:08] in terms of the flowchart here: http://gitorious.org/appstream/resources/blobs/raw/master/architecture.png [14:08] for the review stuff, a cross-distro solution is planned, but nobody has taken the task yet [14:08] I could see Muon/QApt implementing the "client" section [14:08] adding support for additional reviews/ratings backends shouldn't be too hard given the current setup [14:09] and getting the app data from an external server as opposed to the current app-install-data package shouldn't be too hard [14:09] just for information: http://distributions.freedesktop.org/wiki/AppStream/Implementation (how AppStream works) [14:09] But I'm not too convinced that swapping out QApt for PK is in the best technical interest of the project. [14:09] http://wiki.debian.org/AppStreamDebianProposal (what is planned to make it work easily on any Debian repository) [14:10] ximion: what's supposed to be in app-data.xml? [14:10] apol: it's analagous to the flat files that we use from app-install-data [14:10] jtechidna: I thought so [14:10] * apol thinks that AppStream is reinventing the wheel [14:11] apol: see http://gitorious.org/appstream/resources/blobs/master/appdata.xml (but at Debian, we will use a different format than XML, where ftpmasters are happier with - what matters in the end is the Xapian database) [14:12] apol: AppStream is essentially a cross-distro version of what Ubuntu has today, with some extras. Ubuntu people were at the meeting, so AppStream is heavily influenced by them, of course ^^ [14:12] With some work, I could see the qaptworker providing at least a limited PK-like API [14:12] sort of like aptdaemon is currently doing [14:12] jtechidna: please, please don't do that! It's already causeing much pain for me with PK :) [14:12] ximion: I think that from the muon PoV we could start collaborating by being compatible with AppStream reviewing services [14:12] jtechidna: What are your concerns about PK? [14:13] ximion: well, for one thing, it will never be too terribly fast due to everything going through DBus [14:13] ximion: the concern is that what we have works great [14:13] +1 [14:13] :P [14:13] apol: In fact, it should already be ^^ [14:14] ximion: if you give me a reference server, I probably can adapt Muon myself to target it in my work time [14:14] jtechidna: You could for example replace the QApt-worker with PK without loosing any functionality, but sharing more code with PK. The PK daemon would take modify-tasks over DBus and do exacly the same as the current QApt-daemon does [14:14] ah, hmm. hadn't thought about that [14:15] regarding the other speed-limits, you're right, that's why future PK versions will be able to access backends without DBus, but that's not yet implemented [14:15] ximion: does the aptcc backend currently support specifying package versions? [14:15] e.g. for downgrading [14:16] ximion: what do we win by having half libqapt relying on apt for some features and pk on other? [14:17] Muon would still have to rely on APT and wouldn't be cross platform [14:17] apol: Removing code-duplication by using PK, avoiding running another package-management daemon in background (I got bug reports from users running three (!) at the same time), implementation of PackageKit API for free. [14:17] *cross distro [14:19] btw, the qaptworker doesn't run all the time [14:19] it times out after 30 seconds of inactivity [14:19] jtechidna: yes, but we'd have the benefits mentioned above, and it would be easier to make it cross-distro. Muon itself can't be cross-distro and shouldn't be, e.g. because it can target specific Apt features (like pinning) then. - But the MSC could be cros-distro, as it does not rely on advanced functionality, like Muon does. [14:20] jtechidna: so does PK, so does Aptd - the user I'm talking about used Muon, a PK-relying application (PK is used be many apps now, at least on Debian) and the USC at the same time :P [14:20] currently MSC does use libqapt functions for getting information about the underlying packages. (Version, file size, etc) [14:21] so it's not that simple to just not use libqapt for that [14:22] jtechidna: We'd need the new, planned PK functions for that to replace libqapt there. [14:22] this is @work, I just want to check the general possibility of doing this :P [14:23] because right now, having aptd, PK, and Qaptd around is not optimal... [14:23] and even PackageKit has two backends for Apt [14:24] (where aptcc is the better (and faster) one right now) [14:24] well, to be fair nobody uses the python apt one :P [14:24] that one is broken as heck [14:25] it was even removed, because it was abandoned - all Ubuntu developers did aptd then. [14:25] I think we could definitely commit to using the OCS Reviews and Ratings API as an alternate (perhaps even default?) backend, as well as the metadata sourcing system. [14:25] but suddenly, they were back, made a huge set of commits and then vanished again (for months now) [14:25] But sharing worker implementation will require more discussion [14:26] jtechidna: I think PK can cover 98% of current qapt worker already, for the other stuff, we can discuss :) [14:27] PK will now get a sqlite cache, to make accessing the package-information faster and to benachmark backends, then we'll go for "PK2", when Richard has some more time again.# [14:29] for other parts of Muon, you don't need much changes. AppStream is nearly the same as current Ubuntu implementation is, and mvo will make it more AppStream-like during the next releases. [14:29] I should note that Muon currently does not have a strong Xapian backend for retreiving pkg information [14:29] it only uses Xapian for package search [14:30] jtechidna: How does it fetch the application data then? [14:30] ximion: via libapt-pkg [14:31] ah, okay :) [14:31] https://projects.kde.org/projects/extragear/sysadmin/libqapt/repository/revisions/master/entry/src/package.cpp [14:32] basically libapt-pkg mmap's a large (15 or 30 MB, depending on whether you're 32 or 64 bit) file in to memory that contains the info for all the packages [14:32] and uses pointers and iterators to access information [14:32] hmm... I'll suggest another AppStream meeting (maybe not in person but in IRC) to discuss the current state - there are many things which are unclear and the goal "ship something with the end of December" hasn't been reached too :P [14:32] very fast, once you've actually mmap'ed the file :P [14:33] hehe ^^ [14:33] ximion: i'd be intrested in attending such meeting [14:33] that takes around 1 or 2 seconds at application startup ^.^ [14:33] I like QApts code very much, btw. - given the horrow Apt's API is, it lokks very clean and is super-easy to read :) [14:33] ;-) [14:33] I'm very proud of it [14:34] +1 [14:34] kudos for jtechidna :) [14:34] though there are definitely things I'd like to change <.< [14:34] like this abomination: https://projects.kde.org/projects/extragear/sysadmin/libqapt/repository/revisions/master/entry/src/package.cpp#L1088 [14:34] lol [14:34] :P [14:34] Apt has the worst API I've ever seen, so this QApt is indeed a great thing to have. [14:35] I wrote that after I discovered QHash, and went "Use QHash for EVERYTHING!" [14:36] http://www.quickmeme.com/meme/3pa44v/ [14:36] ^^ [14:36] :) [14:37] apol: I can tell you when we discuss the matter :) [14:37] would be cool to get the team back together and some new people too - especially from QApt/Muon [14:38] and as soon as PK-with-less-DBus is ready, implementaing Software-Centers with PK should be a trivial thing. [14:39] for my GSoC on SC, I use a not very nice workaround. [14:39] * apol doesn't really like such "when it's ready it will be awesome" [14:39] because it doesn't always happen [14:40] let's focus on what we have working at the present at any moment and keep iterating forward [14:42] apol: that's the plan [14:42] and since I want a working SC with the end of my project, I will now implement an ugly solution to be able to switch to the better one when it's ready [14:44] So on a slightly-related note, I was thinking that the Qt4 -> Qt5 transition might be the perfect excuse to break ABI/ABI and do a QApt2. [14:44] If you've looked in the code, you can probably see that I've written some notes about API that I'd like to change for a QApt2. [14:44] But I think that it would be beneficial to get an API review with a few more heads than my own [14:47] A 'grep -iR QApt2 src/' should show all of my notes :) [14:49] oh, and this isn't mentioned in the source code, but the QApt Worker API needs a bit of rework. [14:50] all of the functions that start processes where the worker and frontend communicate should return dbus objects which can be monitored for dbus signals. (Kind of like aptdaemon does now) [14:50] currently all signals are outputted on the main qaptworker dbus bus [14:50] which means that all open applications that can communicate with the qaptworker will recieve them. :( [14:51] that's probably the biggest design problem with the library at the moment, which has to be worked around with considerable effort in the frontends [14:52] I should set up a wiki page or something for an API review [14:55] jtechidna: yep, Qt4->Qt5 will break ABI anyway, so yes it makes sense [15:00] We'll definitely want to not go too wild with changing API. While Muon is the biggest consumer of the LibQApt API, there are some other things using it. [15:01] IIRC there's some small Ubuntu derivative using it to develop a Qt package manager [15:02] and some other users include the GRUB2 KCM and the Kubuntu debug installer plugin for Dr. Konqi [15:07] :) [15:09] but the good thing is that I don't think we'll have to change too much [15:14] oh btw, I was also able to find out how the Ubuntu Software Center populates its "For Purchase" origin: http://software-center.ubuntu.com/api/2.0/applications/en/ubuntu/precise/i386/ [15:15] since they're ever so good at making their API publicly visible :P [15:16] While I feel there's definitely less impetus to implement support for their AppStore API now that we aren't an official Canonical Ubuntu flavor, I think that having support there would still be nice. [15:17] I don't know if Blue Systems would take an interest in implementing the API, but it's quite similar to the reviews API and it uses the Ubuntu SSO which we can now do in Muon, so I'd be willing to give a shot at implementing it [15:28] jtechidna: Congrats on the new Muon Suite release! When updating 12.04, I get this error, first by standard upgrade (within Muon) and also in terminal with -f flag. Ideas? http://paste.kde.org/478226/ [15:28] ronnoc: unfortunately a result of me not testing the packages [15:29] run sudo dpkg -i --force-overwrite /var/cache/apt/archives/libmuonprivate1_1.3.65-0ubuntu1~precise1_amd64.deb [15:29] you'll also need to do /var/cache/apt/archives/muon-installer_1.3.65-0ubuntu1~precise1_amd64.deb if my memory serves [15:30] anways, I'm off to lunch, and afterwards I do have some $WORK stuff to do so I'll get off of IRC (well, idle, but yeah) [15:31] jtechidna: ok thanks :) [15:31] jtechidna: btw. could you integrate adding the dbgsym sources to the kubuntu debug installer? Or would that be too invasive? (maybe add, install, remove again?) [15:32] yofel: it'd require some code for adding the dbgsym repo, running an update, searching for the package, removing the repo afterwards [15:32] so it's doable [15:32] it just hasn't been don eyhet [15:32] *done yet [15:33] ok, was just curious if it's doable or total nonsense [15:33] it's not exactly trivial, but it's not insane either [15:46] [lp:~kubuntu-packagers/kubuntu-packaging/kdemultimedia] Philip Muškovac * 153 * debian/ (changelog libkcddb4.symbols) * Update symbol files for gcc 4.7 [16:46] [lp:~kubuntu-packagers/kubuntu-packaging/kdepim] Philip Muškovac * 203 * debian/ (changelog control) * Switch boost depends to 1.49 [17:08] [lp:~kubuntu-packagers/kubuntu-packaging/smokekde] Philip Muškovac * 23 * debian/changelog releasing version 4:4.8.3-0ubuntu1 [17:14] hey yofel :) [17:14] o/ [17:14] razor is in the repos ? [17:14] i guess no [17:15] btw yofel my bug Darkwing is going to help me fix it :) maybe ill learn a few things :) [17:16] Peace-: it is [17:16] yofel: razor-qt sorry [17:16] :D [17:16] i mean http://nowardev.wordpress.com/2011/12/16/light-qt-destkop-ex-antico-razor-qt/ [17:18] yofel: btw on unity there is a shortcut to open unity menu with super key [17:18] on kubuntu shoudl be the same [17:19] i managed to get it but it seems with some problme [17:20] well, problem is that you can't use Meta by itself as a shortcut, it's a modifier [17:20] and I haven't managed to set a single key shortcut for kickoff so far [17:21] yofel: i did it [17:22] yofel: http://nowardev.wordpress.com/2012/05/06/kde-laucher-set-superkey-lke-shortcut/ [17:22] but i have a problem anyway [17:49] [lp:~kubuntu-packagers/kubuntu-packaging/kdeadmin] Philip Muškovac * 150 * debian/changelog releasing version 4:4.8.3-0ubuntu1 [18:17] [lp:~kubuntu-packagers/kubuntu-packaging/kdeartwork] Philip Muškovac * 139 * debian/changelog releasing version 4:4.8.3-0ubuntu1 === rbelem_ is now known as rbelem [18:48] ^^ why isn't a hook used that when you commit, or better yet, tag, add 'release:precise' to change debian/changelog automagically instead of manually doing it each time? [18:50] I've a script that does that :P [18:50] locally? [18:51] yeah (that's a local hook anyway, launchpad has no CIA support) [18:52] you can't add a hook to the bzr server that takes care of it server side? with your script, after it triggers the release:precise, you sill have to do another commit right? [18:53] well, as I need to testbuild before uploading, I need to edit the changelog anyway to create the source package. If it builds fine I let my script commit, tag and upload [18:54] and there's a bug about CIA support, that's about as cooperative the launchpad folks will get [18:55] ahh, that sucks, though i could care less about cia [18:55] shadeslayer: you were looking for fun build failures, enjoy: http://paste.kde.org/478406 [19:39] * highvoltage adds #kubuntu-devel to autojoin to keep up to date with tablet stuff :) [19:46] yofel: I don't see the error, needs more backlog :P [19:47] unless that's the only error message you get [19:47] then it's just plain weird [19:47] shadeslayer: that *is* the error, but here the full log http://paste.ubuntu.com/987758/ [19:49] ... [19:50] firefox just froze up when I tried to use Find on that page [19:50] [lp:~kubuntu-packagers/kubuntu-packaging/kdeplasma-addons] Philip Muškovac * 202 * debian/ (changelog control) * Switch boost build-dep to 1.49 === ronnoc_ is now known as ronnoc [20:33] [lp:~kubuntu-packagers/kubuntu-packaging/kdesdk] Philip Muškovac * 166 * debian/ (changelog control) * Switch boost build-dep to 1.49 [20:34] * JontheEchidna is now home [20:53] blog post without screenshots on April 26th vs. blog post with screenshots today: http://i.imgur.com/1v5T0.png [20:53] :P [20:54] people love teh screenies [20:56] next time you'll have to create some gif images for even more hits [21:00] all is fine as long as you don't use flash :D