[00:02] uploads rejected: ffmpegthumbs, kfloppy, kiten and pairs. Someone else will have to upload those [00:02] (not in packageset for quantal) [04:51] yofel_: Yes. Also need meta-kde. [04:52] yofel_: I'm rejecting packaging that don't have any upstream diff. Don't be alarmed. [05:01] yofel_: kdenetwork needs a reupload to not overwrite the debian/changelog entry for the SRU that's already in updates. [05:03] yofel_: The rest is fine. === valorie_ is now known as valorie [09:42] mmm [09:43] people here asking for PA3 for quantal :) [09:43] we should get cracking on that ASAP [09:43] yeah plenty of requests [09:44] * shadeslayer is at the KDE Miniconf @ FOSS.in \\o/ [09:57] whoops, sebas can't load the RSS widget in touch mode [10:15] !find plasmate [10:15] Package/file plasmate does not exist in quantal === Tonio_aw is now known as Tonio_ === Tonio__ is now known as Tonio_aw [10:30] afiestas: ping === Tonio_aw is now known as Tonio__ === Tonio__ is now known as Tonio_aw === Tonio_aw is now known as Tonio__ [13:28] Howdy all [13:35] hmm, kubuntu-devel hasn't been moderated in a while [13:37] * ScottK didn't know it had a moderation queue. [13:37] it usually doesn't since any address not subscribed of ubuntuy gets rejected [13:37] but some merge requests don't get through and laney's post there was over the size limit [13:38] so remember to look at the date on those e-mails :) [14:19] yofel_: How goes finishing up 4.9.3? [14:20] bad, I'm at work, so not really much time for it right now [14:21] won't get anything done for at least another 3h [14:21] OK. I'd like to wait for powerpc to catch up some more before accepting, so no rush. I'd just like to get it sorted today. [14:22] Riddell: Could you upload ffmpegthumbs, kfloppy, kiten and pairs for yofel (4.9.3 for quantal-proposed) so I can accept them later. [14:22] sure [14:27] agateau: pong [14:28] ScottK: oh yes I forgot to note that down last night on my todo [14:28] Thanks. [14:28] afiestas: hey, I have been thinking more about our yesterday discussion regarding packages for beta versions [14:28] afiestas: the more I think of it, the more I think beta tarballs are a practice of the past [14:29] During beta period, master should be as stable or more stable than beta release [14:29] Means people can use packages built from master to test instead of packages build from beta tarball [14:30] So something like project-neon would be good enough for testers, maybe even better since it does not mess with "stable settings". [14:30] it also means it is easier for a tester to test a fix after a bug report [14:30] no need to wait for beta+1 [14:31] freeze schedules still makes sense, but I am not sure creating tarballs and even tagging beta is useful nowadays [14:31] that is: if we get other distros to provide nightly packages as well [14:31] afiestas: what do you think? [14:31] agateau: I think that if you rewatch the KDE tea time we did a few days back you'll see that I hold that opinion as well [14:32] afiestas: yes, that's why I was a bit surprised you wanted packages for beta releases [14:32] agateau: for the future I want a lot of things, but for tyhe present I want different stuff [14:33] :) [14:33] afiestas: project-neon is not the future, though [14:33] in the future, yes we need a more modern release cycle for multiple reasons, but until then Kubuntu should package things before anyother distro [14:33] *any other [14:34] I was a little bit "shocked" when jussi said neon is not good enough to have real packages [14:34] we need real packages for master, always asap [14:34] they are not good enough to get into the main archive, but they are good enough for testers [14:34] maybe we have to make upstream modify his behaviour by announcing new dependencies and stuff like that [14:35] packages should not differ technically, they may legally (copyright and stuff like that) [14:35] but technically (dependencies, features) they should be the same [14:35] if not #fail [14:35] (because users won't be testing the real thing) [14:35] they also differ by the amount of splitting [14:35] for example: calligra in neon is one single package, whereas it is splitted in the archive [14:36] I can see an user using neon oh look everything works ! I got everything! [14:36] then he isntalls the final packages, forgets to install a split package and "meh mtp is not working on stable while it was working in unstable"! [14:36] project-neon differs quite a bit technically due to the idea to install it side-by-side with a stable KDE setup [14:37] the 'put everything into one package' thing is mostly a thing of maintainability [14:37] yofel_: that should be a PREFIX and maybe a few dependencies that can't be added to the archive/bacjkports/thingy [14:37] right now on my system I have distro KDE, KDE 4.10, KDE 4.9 and Frameworks5 [14:37] yofel_: note that I am not against putting everything in one package for neon [14:37] yofel_: it makes sense for nightly builds to follow upstream split imo [14:38] agateau: I didn't assume you did ;) [14:38] now kdelibs lock screen appears different, with a kubuntu background and the dialog to enter the password also different, is this something done with a patch in kdelibs? [14:38] any more splitting means tracking what files are installed where. That gets tricky if upstream changes things all the time [14:38] afiestas: set up is a bit more involved for things like akonadi [14:39] agateau: why's that? [14:39] simplew: raring? KDE 4.10 has a new screenlocker [14:39] afiestas: you need to define quite a few env vars if you don't want to mix akonadi versions [14:39] yofel_: raring kde 4.9.80 [14:39] afiestas: akonadi does not use $KDEHOME for example [14:39] agateau: XDG vars, so? [14:39] simplew: that's just the new KDE screenlocker then [14:39] afiestas: yes [14:40] I'm afraid of feedback not being 100% reliable because users have literally different things isntalled [14:40] yofel_: but that was a patch submited where, in kdelibs? [14:40] we need to not only test KDE but also Kubuntu setup [14:40] simplew: I don't know - I think it's part of workspace [14:40] agateau: btw, if master were stable, why do we need project neon? [14:40] afiestas: I did not say master is stable [14:41] (unfortunately) [14:41] afiestas: I say it is as stable as beta when we start freezing [14:41] During beta period, master should be as stable or more stable than beta release [14:41] oks, well there we differ then [14:41] yofel_: when i move the mouse to get the dialog to enter the passowrd, the dialog does NOT get focus, to be able to enter the password i need to first go with the mouse and click in the password field [14:41] afiestas: I am not saying I like it that way [14:41] in my ideal world of the future, master should be prepared for release anytime [14:41] afiestas: I agree with this [14:42] afiestas: but right now (ie, for 4.10) I think we can consider master stable enough to be used by testers [14:42] for Akademy2013 I want to hold a round table or something to talk about this [14:42] we must act [14:42] afiestas: I'd rather have testers use nightly builds of master than builds of beta1 [14:42] I always use master, and only very very very few times I'm annoyed by it [14:42] again, for 4.10 [14:43] afiestas: this is a different topic [14:43] (and I agree with you we need an always-releasable master) [14:43] for 4.10 I'd stick with normal releases, we have developers that give value to that [14:43] yofel_: i just prefer to use kde default unloack screen/dialog, that one gets focus when you move the mouse, and i prefer the black background, the kubuntu background image isnt that pretty... [14:43] and since ti is the stablished way we should respect that [14:43] simplew: that's the default KDE background, we didn't patch anything there [14:44] simplew: It's an upstream change in KDE. [14:44] afiestas: What I am saying is: for 4.10 should we encourage testers to use project-neon to test, instead of beta1 packages (which do not exist) [14:44] simplew: and the screenlocker you get now is the new KDE default [14:44] simplew: if it has bugs report them on bugs.kde.org, but someone else will have to tell you against which component [14:44] ScottK, yofel_: but i dont see anywhere a way to configure unlock background image [14:45] agateau: and about that I'm saying that I disagree, we should provide real packages for the releases upstream does [14:45] simplew: I'd ask on #kde. It's not Kubuntu specific. [14:45] for various reasons, 1-Upstream developers expect bugs to have a release [14:45] 2-Project neon packages re different from normal packages [14:45] that's it, 2 [14:45] xd [14:45] ScottK: but seams that was submited by a kubuntu developer, since it uses kubuntu default background image... [14:45] I was expecting more reasons :p [14:45] :) [14:46] afiestas: I think 2) is not an upstream concern [14:46] simplew: I don't think so. I think it uses system default, which for Kubuntu would be the Kubuntu image. [14:46] agateau: well, it should be ours [14:46] afiestas: we have a problem with versions indeed [14:46] ScottK: hum [14:46] it is conceptualy broken ask people to test something that won't be used in 13.04 [14:46] afiestas: if we were to use nightlies we would need a way to publish their commit-id when bugs are reported [14:47] afiestas: I am not talking about Kubuntu here [14:47] so let's wait for 4.12 and do this together with upstream [14:47] afiestas: I am talking about testing KDE [14:47] I'm ok on doing nighties as long as packages as real ones, not neon's [14:47] yofel_, ScottK: uploaded [14:47] thanks [14:47] Riddell: Thanks. [14:47] afiestas: I want people who are willing to test KDE and happens to be running Kubuntu, to have an easy way to test master [14:48] agateau: and you have neon for that, what's the matter? [14:48] maybe we are talking about different things [14:48] agateau: I am talking about getting more people to test KDE master, whatever distro they run [14:48] damn, pinging myself [14:48] neon is a wonderful thing for users that want to be in the cutting-edge without risking too much, but that's about it [14:49] beta testing and master testing right now should not be messed imho [14:49] afiestas: why? [14:49] right now master == beta + some fixes [14:49] well because that's not how upstream works, that's not wht some upstream expect [14:50] we should not decide those things, (we as in Kubuntu) upstream should [14:50] mmm [14:50] and it will be a waste of time make users test neon instead of the real packages that we will ship 13.04 with [14:50] maybe I should have pinged you on #kde-release then [14:50] (is there such a channel) [14:51] imho there is nothing to do for 4.10, we are in beta already [14:51] IMO people should test the beta + check with neon if a bug still exists. Everyone will agree that we need to get faster at building the packages, which is work in progress. But I'm not too much a fan of yet another master build [14:51] this is a discussion either for 4.11 or 4.12 [14:51] again, I am not concerned about kubuntu there, I just want to take advantage of one kubuntu community product (neon) to get more tests of the upcoming kde sc release [14:52] so they will have real apckages soon (Riddell said today) [14:52] adn they will be able to test all releases upstream does [14:53] I (as a KDE upstream developer) would rather see people test my latest code than code from 3 days ago [14:53] but you are only one, maybe others don't, so the right thing to do imho is discuss this for 4.11 [14:53] and not mess with 4.10 since it is already going on [14:54] well, this doesn't follow the topic , but I'm concerned about the HW recognition of the 3.7 kernel . It's freezing at my wirelessKB and mouse , with absolutely no response . 13.04 here , but had to regress to the 3.5.0.17 kernel to make things work [14:54] or you can move gwenview to extragear adn do your own releases :P that's what I do with my stuff since I dont' want to follow SC [14:54] afiestas: I think the 4.10 release schedule does not suggest master is supposed to break between beta1 and beta2 [14:55] afiestas: but maybe you are confused about what I want to do for 4.10 [14:55] BluesKaj: We can't do anything about kernel stuff here. [14:55] afiestas: I am not saying we should review our release schedule or strategy [14:56] afiestas: at least not for 4.10 [14:56] you are saying that we should encourage users to test KDE 4.10 with neon [14:56] afiestas: I think we should suggest testers to run nightly builds, because those give us the most valuable output [14:56] afiestas: yes [14:56] which I'm against because users won't know how the hell report bugs [14:57] and how is it different with muon than with beta packages? [14:57] they wuill say "Beta1" while in reality it won' tbe Beta1 [14:57] but Beta1+patches [14:57] that makes the user feedback less valuable and less trustworthy because we won't know (we as in upstream) in which commit exactly the user is [14:57] ScottK, I'm not asking for a fix , let me rephrase , I guess this is a warning and have you guys seen or heard anything about this kernel module problem , because #ubuntu+1 is strangely silent on this issue. [14:58] besides, giving test to neon packages haas a serious downside for Kubuntu, which I'm also concerned about [14:58] It sounds very hardware specific. [14:58] if you read for example Martin G blog you will see many references to beta releases [14:58] asking specially for testing iun "Beta2 packages" and things like that [14:58] if you make Beta2 not be Beta2 anymore but instead beta2+patches it may get messy [14:58] afiestas: well, you can replace those references with "YYYYMMDD" [14:59] which is the info you get from neon packages [14:59] YYYYMMMDD of when neon packaged, not corresponding exactly to git [14:59] since neon is slow according to shadeslayer [14:59] the packaging of neon I mean [14:59] there can be quite a bit of delay [14:59] version says git20121022, is it the date of the git import? [14:59] and btw, why would an upstream developer have to care about something kubuntu (only) does? [14:59] this is adding overhead to upstream [14:59] leave things as they are for now and fix upstream, that's what I say [15:00] that is why I say: [15:00] first the bzr importers run periodically, which means up to (IIRC) 4h delay, then the recipes need to build and packages need to build (add at least twice the i386 builder queue time + build time) [15:00] 1. testers should provide correct version numbers (if not possible we are screwed) [15:00] 2. we should encourage other distro to have similar nightly packages [15:01] doesn't opensusue have nighlies? [15:01] I don't know [15:01] I'd like to gather such information on community.kde.org [15:01] in the Get involved page [15:01] could someone expalin the references to KDE 4.10? I think it's confusing some people including me [15:01] agateau: I can agree with what you propose, but not for 4.10, again because it is not the STABLISHED things [15:01] I'm all up for modifying things, you know that better than anyone xD [15:02] I want to do releases each 3 months damn it... [15:02] yofel_: a build delay is ok, as long as the reported dates match those of the git import [15:02] but things should be done right, not just taking things into our own [15:02] BluesKaj: we're talking about the beta testing and neon, with would both currently be 4.10 [15:02] yofel_: iirc recipes even have the ability to include the git commit-id in the version number, right? [15:02] agateau: well, the package version has the bzr revision in it, you can then compare bzr log and git log to find the hash out [15:03] but that's not really trivial [15:03] yofel_: yes, too complicated :/ [15:03] yofel_, ahh neon ... ok , didn't work for me last yr [15:04] afiestas: ok, then I am going to do it in my little corner [15:05] afiestas: asking kubuntu users willing to test gwenview from kde sc 4.10 to use neon [15:05] afiestas: and we can revisit this discussion for 4.11 [15:05] agateau: you can do as you please, but since you are in SC because you want to, you shouldn't do that imho [15:06] if you are in SC you should follow whatever SC says, and try to change SC ways if you want to [15:06] afiestas: actually that could provide some valuable feedback for 4.11 [15:06] if not, you should come to extragear with me, where is sunny etc [15:06] and where it's a mess to deal with translations [15:06] :/ [15:07] I don't see how it can, but well do as you want xD [15:07] feedback on benefits/drawbacks of using nightly builds [15:07] some extragear packages depend on some SC packages which change API and ABI meaning we can't do backports easily [15:08] *cough* libkdcraw *cough*? [15:09] agateau: well, then you should at least send an email somewhere to say "I'm going to do this with this objective" [15:09] we all should go at once in all this, that's why it is a SC [15:10] afiestas: define "somewhere". kde-testing@ kde-release-team@? [15:11] we are a SC, that's why we all use the same VCS [15:12] agateau: release team and kde core devel? or only release team [15:14] the thing about sending it to release team is that only a few people are there [15:14] but anyway, do as you please dude [15:14] all this is a bloody mess already [15:14] nobody will notice a little bit more mess, really [15:15] :/ [15:16] I assume people on kde-core-devel build kde by hand, so they don't really care about nightly builds [15:16] they do care [15:16] because they are the ones that are going to fix the bugs reported with "BEta1" though they won't be beta1 code but beta1+patches [15:17] nobody is going to tell you "Nitghtly are bad" they are not [15:17] they wil (or I will) tell you, say to the user "Test BEta1 but instead test a nightly" is bad [15:17] if someone else but me and Benjamin committed code to Gwenview I would agree [15:17] but they don't [15:17] then I go to the point before, you are part of SC [15:18] you are not releasing software by your own [15:18] no, I am just writing it [15:18] which btw I would prefer if you did that (I'd like to have gwenview features when ready, nto every 6 months) [15:18] but right now you are part of SC, and SC should have an unified way of doing things, including asking user feedback [15:18] Yes. Please. [15:18] but as I said, this is a bloody mess already everybody deos whatever they please [15:19] so you are in your rights to do whatever you please as well [15:19] The betas are still important though for distros. Don't forget that. [15:19] We can't redo the whole KDE SC in the archive every day or two. [15:20] ScottK: sure, but would you be able to do it, say every week, or every two weeks? [15:20] Two weeks we could probably do. [15:20] I guess it depends. [15:20] We're working on automating a lot of it. There are just too many packages now. [15:21] Once that's working better, the bigger issue will be build capacity. [15:21] I'm sure if we tried weekly, we'd get yelled at. [15:21] Bi-weekly we could probably get away with. [15:22] mmm, actually every two weeks is roughly the time between sc unstable releases so that would not change much I guess [15:22] If there was an easy way to know the subset of packages to update, we could do it more often. [15:23] Some kind of an API to query where the KDE maintainer would flip a "worth updating" flag or something. [15:23] we could re-use the diff-check for SRU's for the normal packages [15:23] I wouldn't trust KDE maintainers to do this reliably [15:23] Yes, but I'm trying to get away from us having to read the diff. [15:24] the scripts have a diff check [15:24] It could be a git tag. [15:24] automated [15:24] Oh. [15:24] Then how come you uploaded stuff with no diff? [15:24] (for 4.9.3) [15:24] anything that starts wth lib is not included there becaues some packages might build-dep on >= 4.9.3 of them [15:25] how can i downgrade to a previous kernel version? [15:25] agateau: Maybe a transitional approach would be to keep the beta/RC schedule, but define a git tag format maintainers could use, if they choose, to signal it's worth taking a snapshot. [15:26] wrong channel, sorry [15:26] we should re-check that for those packages that should have a stable ABI [15:26] Then a commit hook could monitor for the tag and maybe mail the pacakger list. [15:27] afiestas: 15:27 < seb128> Riddell, ScottK: does https://code.launchpad.net/~stijnbrouwers/ubuntu/quantal/kamoso/fix-missing-icons/+merge/134772 seems fine to you? it's basically making an icon change "webcamreceive" -> "digikam" [15:28] ScottK: interesting, so your point is that you'd rather avoid rebuilding everything [15:29] afiestas: I told seb128 it needed to go upstream. [15:29] agateau: It takes a LOT of build time to rebuild the whole SC. [15:30] ScottK: sure, and it is the same problem for other distributions, so that's something to take into account [15:31] I think it'd be cool to do more updates and keep things closer to upstream if there's a good way to find the interesting times to do it. [15:38] * yofel_ perpares kde-l10n and wonders what happened to the 4.9.4 tagging [15:39] I accepted kde4libs for quantal so it'll have time to build everywhere. [15:39] yofel_: don't forget meta too. [15:40] do we really need meta? [15:40] I think there's still something we use from it. [15:40] yofel_: I guess the same thing happened to 4.9.4 as 4.10 beta 2 tagging [15:41] * yofel_ is worried that, as some of the meta packages use >=, our no-diff rejects might not really work [15:41] yofel_: Good point. [15:41] Maybe we don't need it. [15:41] I'll take a look at it and check if we need it after all [15:42] Thanks. [15:42] kubuntu peeps, last chance to decide do we want an alpha next week? we do but it'll get in the way of 4.10 beta 2 [15:42] hm, 4.9.85 had the same tagging date, right [15:42] geez, time flies... [15:42] You're point about the >= is a good one. [15:42] Riddell: Yes. We want it. [15:43] ScottK: that seems like a workaround for a workaround [15:43] meaning, depending on digikam icon instad of webcamreceive [15:43] new kde sc and an alpha, a busy week :) [15:43] anyway, tell him to make a reviewboard and we w'll check it asap [15:43] We need it to work out the machinery of a milestone without the Canonical flavors participating. [15:44] any other flavours planning to have an a1 ? [15:44] afiestas: I didn't look at the content of the change just enough to see it wasn't something I'd distro patch. [15:44] yofel_: No. [15:44] yofel_: I think we'll be all alone [15:44] that'll be fun [15:44] i386/amd64 desktop images? [15:44] Yes. [15:44] stgraber will be driver [15:45] is there a reason why we still have alternate dailies? [15:45] or did someone just forget to kill them? [15:45] No. Those should go away. [15:46] k === yofel_ is now known as yofel [15:48] Riddell: for owncloud, maybe you want to add a NEWS entry as that's a major change? [15:48] yofel: killed. [15:48] Riddell: for the SRUs I mean [15:49] micahg: owncloud has no NEWS file and I'd think all users will read the index.php [15:49] Adding a NEWS file is easy. [15:50] Riddell: index.php is too late :) [15:51] Riddell: you want to warn users that you're pulling the rug out from under them [15:51] at least I would think you'd want to :) [15:51] micahg: how will a NEWS file do that? [15:51] it's in the changelog which is what muon etc shows [15:52] Riddell: well, in cases of cli tools, it's displayed on install, it's e-mailed to admins on servers [15:52] idk how muon handles it TBH [15:52] Riddell: server installs don't have muon. NEWS is the right tool. [15:52] I've never seen that [15:52] and I've been running a debian server for a decade :) [15:52] does apt-get do this or something else? [15:53] Apt will show it. [15:53] It's only used in cases where there's a significant incompatibility. I've only ever done it once. [15:54] interesting [15:54] so I want a file in /usr/share/doc/owncloud/NEWS detailing the change? [15:55] dch --news? [15:56] where the hell is that documented? I couldn't find it in the debian policy [15:57] not in policy, but developers reference: http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-news-debian [15:58] thanks [15:59] I'm shocked it's not in policy [16:07] Policy would be use a NEWS file when ...., not here's how you do a NEWS file. [16:08] ScottK: right, but I couldn't seem to find that either [16:09] As with many things in Debian, I think it's left to the maintainer to decide. [16:09] ownclouds reuploaded with NEWS [16:24] \o === Quintasan_ is now known as Quintasan [16:24] evening queuebot [16:24] ... [16:24] good evening to you too Quintasan [16:25] T_T [16:25] * Quintasan throws bricks at queuebot [16:26] oy, no violence in this channel! [16:28] * Quintasan thorws more bricks at queuebot [16:28] It's just a bot [16:31] s/bricks/lego bricks/ [16:31] let's nerf it [16:32] * Riddell stands infront of queuebot in an act of nonviolent resistance [16:33] * yofel sends a creeper in queuebot's direction [16:34] I don't like the sound of that! [16:43] Riddell: Got some time to review maliit? [16:44] Quintasan: throw it at me and see how far I get :) [16:44] mikhas: Could you get someone to write more extensive descriptions for packages in maliit? I only want descriptions since the current ones are not really good and I don't feel like figuring out which module does what [16:45] duh [16:45] Riddell: Wait, I accidentaly overwrote the damn changelog [16:46] sebas is going to test Kubuntu active, he says to expect a long email about broken things if he finds any issues :) [16:47] shadeslayer: how did the newpackage for our bot work? [16:48] ubottu: help [16:48] Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience [16:48] duh [16:49] newpackage foo ver [16:49] I think [16:49] !newpackage [16:49] The packaging guide is at http://developer.ubuntu.com/packaging/html/ - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports and !sponsoring [16:49] ~newpackage [16:50] XDD [16:50] yofel: help us! [16:50] no kubotu [16:50] so ... [16:50] talk to agateau [16:50] er, apachelogger_ [16:50] today's my tab-complete failure day... [16:50] tab fail day for yofel [16:50] \o/ [16:50] :P [16:51] yofel: but what was the commad format again [16:52] kubotu: newpackage foo ver [add. descr] [16:52] the bot only runs 'newpackage' from kubuntu-dev-tools, so just use that [16:52] apachelogger_: Where be me bots [16:53] shadeslayer: Can we get PA3 done first and he tries that? [16:53] We know there's breakage in the earlier stuff. [16:53] Quintasan, you need a package description for each individual package? [16:54] huh ? I got most requests for PA3 today [16:54] so we should prioritize that [16:54] mikhas: Where applicable, let me send you what I have so there is something to expand [16:54] there's a packaging tutorial tomorrow, will try and recruit people for doing kde games [16:55] [tools]% newpackage (quintasan@demonbane:~/Sauce/tools) [16:55] Traceback (most recent call last): [16:55] File "/usr/bin/newpackage", line 26, in [16:55] from KubuntuDevTools.launchpad import KDTLaunchpad [16:55] wat [16:55] ScottK: kde-l10n coming, you said kdenetwork needs to be redone? [16:55] set pythonpath to the pylib folder or just install the package from the PPA [16:55] Quintasan: ^ [16:56] what PPA now [16:56] T_T [16:56] yofel: yes. there was already a kdenetwork SRU in quantal and you dropped the changelog entry for it. [16:56] Quintasan: https://code.launchpad.net/~bulldog98/+archive/kubuntu-dev-tools [16:56] bulldog98: could you please enable raring for the recipe? thanks [16:57] ScottK: we should probably add a check for that to the scripts [16:57] Yes. [16:57] I just took the 4.9.3 packages as we did them [16:58] That's why I get to read ALL the diffs. [16:58] you have kubotu now [16:58]