[00:00] txwikinger: ready in a minute? [00:00] I am ready [00:00] well friends, a real treat for you now [00:00] txwikinger is our ace beastie squisher [00:00] here to tell you how to help out with the millions of bugs we have, it's txwikinger! [00:01] ok..let's look a little into our bug treatment [00:01] I am not so famous like some others here.. so just a little bio [00:02] === About Me === [00:02] Riddell: seeing as nobody else has volunteered, I guess that means I'll be doing it :) [00:02] * Free software enthusiast and advocate [00:02] * Computer Science and law degrees [00:02] * Started computing on unix [00:02] * Worked as developer, system and network admin, and consultant in Telecom, Finances and Education industries. [00:02] * Computer Science Lecturer at University [00:02] txwikinger: law degree...... so I won't get sued by PETA for squashing bugs? [00:03] yep.. that's the idea :) [00:03] * Involved in Ubuntu/Kubuntu for nearly 1.5 years now and lately also a little bit for Debian. [00:03] well.. I use Kubuntu since hoary, I believe [00:03] * Doing advocacy, community stuff, bug triage and some packaging [00:04] * Email me at txwikinger@ubuntu.com if you like [00:04] or talk to me where I hang around in irc [00:04] ok.. but now to the topic [00:04] === What is bug triage? === [00:04] The word triage comes from the French word trier which means sorting, sifting (see http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=triage) [00:04] Commonly it is used in the field of medicine, especially in the context of emergency rooms, disaster situations, basically when limited resources must be allocated to a high number of patients. [00:05] This in an analogy that also describes what we do with bug-reports. When they are submitted, they must be checked if the adhere to a certain standard, contain all the necessary information that they can be fixed and be sorted and classified in order to get the right "resource" to work on it. [00:05] In some way someone who triages bugs is something like a facilitator or arbitrator. You work with the reported in order to retrieve as much information as possible. [00:06] reporter that is [00:06] You also work with the developers for kubuntu and ubuntu as well as upstream distributions like KDE and debian and others in providing the information or finding out what information is needed. [00:06] Due to the fact that all of this concerns people it is very important that bug triage is done with a lot of patience and humility. [00:07] There are sometimes different interests that need to be mitigated when decisions are made, and it is always the best to be as polite as possible to everybody around (see also Ubuntu CoC https://launchpad.net/codeofconduct/1.0.1) [00:07] The bug triage happens on launchpad https://bugs.launchpad.net/ In order to be able to triage bugs effectively, you must have an account on launchpad. [00:07] Ok.. so far the theory... [00:08] Let's see what is really done [00:08] === There are different elements to triaging bugs === [00:08] ==== 1) Cleaning up bug reports: ==== [00:08] Bugs are often submitted by reporters that do not understand fully the process. [00:08] On the other hand, the people working with the bugs need efficient access to the information. [00:09] Therefore it can be very important to clean up the bugs summary to soemthing that is meaningful that in a list of reports someone already understand the main issue of every report in the list. [00:09] It can also be helpful if certain important information is added to the description of the report, since this is the first thing after the summary one would read. [00:11] Lets look at bug #240242 [00:11] Launchpad bug 240242 in firefox-3.0 "address bar suddently not responding to " [Undecided,New] https://launchpad.net/bugs/240242 [00:11] Is this report well described? [00:12] What would be helpful to know? [00:12] well, for a one liner, I would say .... .... ... I would say launchpad is taking forever to come up :( [00:13] i'd ask if typing in other parts of firefox works [00:13] yes.. good idea [00:13] hmmmm, opera says "launchpad is using an outdated encryption algorithm that is no longer considered secure", interesting [00:14] A developer probably would like to know exactly the build of firefox [00:14] So it would be good to ask the reporter for the package version [00:15] It would be interesting if firefox is the only app for which this happen [00:15] So as you can see... lots of additional information is interesting and should be added [00:16] This can also be done by the triager if it can be reproduced [00:16] We also like to add workarounds if we know them into the description [00:16] This way others who has this problem can easily work around them until they are fixed [00:17] ==== 2) Colleting more information in order to be able to triage and/or reproduce and fix a bug ==== [00:17] This is in my opinion the most important step of bug triage. In an ideal world, a bug report has a description that allows anybody following it to immediately reproduce the bug. [00:17] It is good practice to see if the description given is sufficient to reproduce or see the problem and if necessary add additional information if the problem is found. [00:18] Here is an example, I have worked on: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/102979 [00:18] Launchpad bug 102979 in ubiquity "[kde-ui] next button does not respond to keyboard" [Low,Confirmed] [00:19] This was the original description: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/102979/comments/0 [00:19] I have made it a little more readable and have added the workaround I found [00:20] I also added a question to the submitter and explained some more how to reproduce the problem [00:21] Another important task: [00:21] ==== 3) Sorting tasks. ==== [00:21] ===== 3a) Assigning the report to the right package ===== [00:21] Often reports are submitted without a package assigned to it [00:21] An important part of the sorting of the reports is to assign them to the right package. The allows the right people to look at the bugs. [00:22] Here are good instructions on how to find the right package to assigne a bug to: [00:22] https://wiki.ubuntu.com/Bugs/FindRightPackage [00:22] Sometimes it is not easy to understand from the beginning which the right packages is [00:23] However, reports can easily be assigned to multiple packages, or packages can later be changed [00:23] This is done by clicking on the Status value [00:23] The opens up the fields that can be edited [00:24] The first field is for the package [00:24] there is also a search function if the complete name of the package is not known [00:24] (Choose) [00:25] In the same part the next task can be performed: [00:25] ===== 3b) Entering the correct status: ===== [00:25] https://wiki.ubuntu.com/Bugs/CommonTasks#head-6e435bd3f0413458778d4688ea2f4983e90e6ab4 gives an overwiew of the different states a report can have. [00:25] For the triage, the essential states are New, Incomplete, Confirmed and Invalid. [00:26] very report start with the state New. When somebody starts to triage it and more information is necessary it will be set in the state incomplete until all the information is in the report. [00:26] When all the information is in the report and the bug can be reproduced it will be set to the state Confirmed. [00:26] A lot of reports will turn out either not to be bugs, or it is impossible to collect the necessary information that the report has a positive effect, i.e really helps to solve a problem. [00:27] Sometimes reporters will not respond for request for the information needed, and it is not feasible or possible to recreate it yourself. [00:27] In these cases the state will be changed to invalid. [00:27] With all those state changes always keep in mind the consequences. We do not want to unnecessarily mark reports invalid because of laziness. [00:28] A report might contain crucial information to solve a problem, sometimes not understood to the person that triages it. [00:28] the tutorials day isn't over yet/ [00:28] ? [00:28] I am talking about bug triage at the moment, so yes :) [00:29] Therefore, we do not close report lightly in this way. We always want to make sure the report has all the necessary information to be set for the next state. [00:29] sorry [00:29] No problem :) [00:29] Reports with missing information are set to Incomplete [00:29] However, there should also always be instruction put in a comment how the reporter can collect the necessary information that is missing [00:30] Another important task is to find: [00:30] ==== 4) Duplicates ==== [00:30] While reporters are encouraged to first look for similar or identical problems in the bug tracker, it is inevidable that we get a lot of duplicate reports. [00:30] Therefore a very important step during the information collection is to see if there is already another report. [00:31] If this is the case, the report is linked to the original report (more here: https://wiki.ubuntu.com/Bugs/CommonTasks#head-170e00a7154fcfc87f0fc50f65bba9cff7ab27fe) [00:32] ==== 5) Upstream reports: ==== [00:32] Often we will deal with issues that are problems in upstream packages. [00:32] We are working very close with the upstream distros and it is a mutual benefit for everybody to get bug fixes introduced as high upstream as possible. [00:33] For Kubuntu, KDE is in particular of interest. Here is an example of this https://bugs.launchpad.net/kdebase/+bug/96151 [00:33] Launchpad bug 96151 in kdebase "kcmclock does not change to correct location" [Low,Confirmed] [00:34] In such cases you either find an already existing report in the upstream bugtracker and add it to the report, or you create a new report in the upstream bug tracker and add that one. [00:34] Here are the instructions how to do this https://wiki.ubuntu.com/Bugs/HowToTriage#head-ab0eb9d7731fa877b5fc866eedc4c312dab50ee7 [00:34] Basically you choose the upstream project (KDE in this case) an add the url to the particular bug in their tracker. [00:35] launchpad will then update periodically the state of the report in the upstream tracker. [00:35] Actually this part takes a lot of my time when I am triage [00:36] As faster we get reports to the proper places, as faster we get fixes back through our upstream packages [00:36] Ok... I am breezing here a little fast through some of the steps [00:37] The urls are supposed to give you references to look at when you get stuck while triaging [00:37] that's probably because you aren't being bogged down by dozens of questions ... for better or for worse [00:37] hehe [00:37] Well.. if you have a question, ask [00:38] Looks pretty straightforward to me ... but .... where did everybody else go ... [00:38] nice, i can only emphasize how much you can help the community with triaging (to all) :p [00:38] Or feel free to ask someone while you triage [00:38] One of the really helpful things are: [00:38] ==== 6) Standard Responses ==== [00:39] One thing that helps a lot, especially to maintain a polite and collaborative atmosphere are standard responses that can be adjusted to the particular situation. [00:39] Here are lots of such responses for various situations: https://wiki.ubuntu.com/Bugs/Responses [00:39] In particular I would like to raise the attention for this one: [00:39] https://wiki.ubuntu.com/Bugs/Responses#head-6ee6466fdaac8c81274185f0316afd794d2ee0b6 [00:40] This can be used when the reporter does not responds (usually within a month) to the requests for more information and the existing information does not help to reproduce the problem. [00:40] Another issue we often see is the following [00:40] Look ast bug #240261 [00:40] Launchpad bug 240261 in ubuntu "Synapse Monitor - no drivers??" [Undecided,New] https://launchpad.net/bugs/240261 [00:41] Is this really a bug? [00:41] hehe, not really [00:42] Okay, gotta go. Thank you all, thank you txwikinger and thank you Riddell. :) [00:42] katastrophe: Yes.. I think this is rather a [00:42] ==== 7) Support Requests ==== [00:42] Sometimes bug reports turn out to be really support requests. [00:42] Reporters should be gently nudged to the support tracker in launchpad. [00:42] It is certainly beneficial if inexperienced users are guided by the people that help to support them to filter out all the issues that are not really bugs. [00:43] It is very easy to create a bug report linked to an existing question if it turns out to be such. [00:44] In order to convert the report to a question, there is a link in the left margin of the report page [00:44] "Convert to question" === Jucato_ is now known as Jucato [00:44] The Standard reposes above have a text that can be put into the field [00:44] responses [00:45] The questions can all be found at https://answers.launchpad.net/ubuntu/ [00:46] Ok.. this is all the issues I want to go through about how to deal with the reports during the triage process [00:46] Now some fun things: [00:46] ==== 8) Bug Days ==== [00:46] We have currently, I believe, weekly bug days where there is special focus on a particular class of bugs. Information can be found here: https://wiki.ubuntu.com/UbuntuBugDay [00:47] I believe on Tuesday there will be OpenOffice reports that are particularily looked at [00:48] We often have also in parallel specific KDE/Kubuntu packages that we focus on [00:48] It is always lots of fun to work together on those lists and see them getting finished [00:49] Questions can always be asks on ==== 9) The IRC channel: #ubuntu-bugs ==== [00:49] hug days! [00:50] Dholbach has also started a nice motivational tool to do a little bit every day [00:50] ==== 10) Five-a-day Teams ==== [00:51] oh do you have a link? [00:51] https://wiki.ubuntu.com/5-A-Day [00:51] k :) [00:51] Here are the stats for it http://daniel.holba.ch/5-a-day-stats/ [00:52] The idea is, to try to do a couple of bugs every day which over time gets a lot done [00:52] ok.. coming to the end: [00:52] ==== 11) Wrap up ==== [00:52] lways remember that we are working here in a team. [00:52] Always remember that we are working here in a team. [00:52] nice, we only have the the stats of the kde bugtracker [00:52] Therefore, we help each other. It is always good to ask questions if you are not sure how to proceed. [00:53] Even for the most seasoned people it can be in tricky cases very helpful to have a second opinion. [00:53] So if your are not sure about something ask somebody. [00:53] I am often around on the IRC channels as txwikinger or txwikinger2 [00:53] Feel free to see me if I can help you. [00:54] Here some more links with lots of helpful information: [00:54] https://wiki.ubuntu.com/HelpingWithBugs [00:54] https://wiki.ubuntu.com/BugSquad/KnowledgeBase [00:54] https://wiki.ubuntu.com/DebuggingProcedures [00:54] In particular for Kubuntu and KDE: [00:55] https://wiki.kubuntu.org/Kubuntu/Bugs/Reporting [00:55] https://wiki.kubuntu.org/DebuggingKDE [00:56] https://wiki.kubuntu.org/Kubuntu/Bugs [00:57] * nosrednaekim clpas for txwikinger [00:57] and claps as well [00:57] all done? [00:58] I hope you will all enjoy bug triage in the future [00:58] It is a lot of fun !!!!! [00:58] lots of beasties to squish! [00:58] one thing to add: if you have some kde specific stuff, there is also #kde-bugs and youre welcome :) [00:58] Riddell: yes.. if there aren't any questions [00:59] thanks for coming all [00:59] sorry about the netsplits [00:59] we'll get logs up soon [00:59] Q&A now? [01:00] if there are any questions we're happy to take them [01:00] dwidmann: if you want to do that techbase tutorial, grab a page on the wiki under http://techbase.kde.org/Development/Tutorials#Python [01:00] and let me know when there's something to review [01:00] Riddell: will do [01:00] should be later tonight [01:01] Please give feedback at the bottom of https://wiki.kubuntu.org/KubuntuTutorialsDay [01:01] if the contents was ok, or how well the timing worked [01:01] I'm going to go take a shower and get some mountain dew, then come back and start wittling away at it :) [01:01] Intrepid is an exciting cycle since it's the start of the two year LTS cycle we get to do interesting things... like move to KDE 4 [01:01] seele: can you say something about the progress of the kde4 hig? [01:02] katastrophe: sure [01:02] Ellen Reitmayr and myself are working on the HIG htis summer [01:02] Riddell: about the packaging, debuild fails because it can't sign the packages, I need to create my own gpg key? [01:02] we also have 2 interns for the Season of Usabiity working on it [01:02] ah this is cool :) [01:02] currently we have a long list of questions and requests we've gathered from developers that we are working on documenting [01:03] m4v: that's a good sign, it means it has completed all the important bits! [01:03] and we hope to have a collection of examples (patterns) to go along with the list of guidelines for widgets [01:03] m4v: when you become a motu you'll need a gpg key to sign packages for upload, and you'll need one to upload to revu [01:03] right now it is in between a wiki on openusability and transitioning to kde techbase [01:04] katastrophe: so hopefully by the end of the summer we will have lots of materials for developers to use [01:04] cool, i would love to see that, hopefully the developers will stick to the guide :) [01:04] katastrophe: i think they will once it is done, we get questions and requests all the time [01:04] .. [01:04] the problem is we have two very busy people doing a very long and painful job. writing guidelines is not very fun no matter how important [01:05] we hope the interns help with that [01:05] m4v: I can't find the wiki page that describes how to create one, but it'll be somewhere under MOTU on the wiki [01:05] really nice, perhaps kde could be the "most consistent platform" in some far future :p [01:05] yeah i can understand [01:05] katastrophe: i think that will happen more as kde3 apps get transitioned out of kde4 [01:06] I'm creating one, sorry, the last ".." comment was cause I thought I was on my terminal :p [01:06] even though they look the same, there may be UI rules that have changes which will make them different [01:06] yes [01:06] ah hah https://help.ubuntu.com/community/GnuPrivacyGuardHowto [01:06] Riddell: kind of an ot question, but do you know if/when/how soon/etc dual head might be playing nice with kde 4(.1)? [01:07] (vague is fine too) [01:07] dwidmann: I don't know I'm afraid, you'd need to ask the plasma developers [01:07] m4v: for getting a revu account see https://wiki.kubuntu.org/MOTU/Packages/REVU [01:08] Riddell: okay, was just asking ... it's hindering my ability to run it/ report bugs :( [01:08] seele: hm and another one :p what do you think about options? how much should be available in a program? can it be too much? [01:08] or does it depend on the targeted users [01:08] katastrophe: it always depends on the application, the tasks, and the target users [01:09] ok [01:09] like i said earlier, expert systems need to cater to experts.. which means they will probably have tons of options [01:09] but if something simple also needs or supports high configuration, then you might have tons of options for that too [01:09] like Eric :P [01:09] take instant messaging for example [01:09] you could stay simple and provide only one look and feel for your chat window [01:10] but even non-expert users like to configure fun stuff like colors and themes [01:10] and only one sze for the input box *ahem* [01:10] yeah its because i always liked miranda, if you know the client because its so configurable [01:10] and if it is done right, you might be able to provide tons of themeing options that arent too hard to use [01:10] ah ok [01:10] having a ton of options does not mean there is unneeded complexity [01:10] Just make the options non-intrusive? [01:10] yeah, i thought about that, good to hear :) [01:11] well.. again, non-intrusive for certain kinds of options [01:11] understanding work flows and what experience your target users have will help shape a lot of the UI [01:12] if your users are used to web applications that use a specific pattern for choosing a color.. you might be able to support tons of color options if you go with a design they already know [01:12] or if users only want to choose from a palette of 30 colors.. dont give them the gradient selector or ask them to enter hex colors [01:12] if you can configure every single widget, previews help them keep track of their work [01:12] stuff like that [01:12] ok [01:12] any time you have a ton of widgets on the screen youre at risk for complexity [01:12] there is just so much to take in and understand [01:13] your job as a designer or developer is to create a presentation they can make sense of [01:13] so they can focus on small parts of the problem to solve instead of taking in the problem all at once [01:13] we do this by creating tabs with specific option categories or hiding advanced options behind advanced buttons and new dialogs [01:13] and so on [01:14] ah ok [01:14] btw i had a look at kgrubeditor, its really nice :) [01:14] i'm not saying that you can never have too many options, it is all a balance between the users you focus on [01:15] ok :) [01:15] if 5% of your users want 10 options but 95% of your users wont use it, it probably wont be worth screwing with the 95% of users to add those options in [01:15] (this is why we didnt get through as much as i wanted today.. i talk and talk and talk..) [01:15] yeah, kgrubeditor is shaping up nicely [01:15] but we have a huge problem with automagic [01:15] i'm not sure how to solve it yet [01:15] no problem, perhaps you could give an advanced talk later :p [01:15] we dont want to break it, but that means that you cant reorder half the menu [01:16] hm will kgrubeditor be available as system settings module? would be awesome [01:16] if you can't reorder half the menu, how do you present the non-reorderable options from the orderable options? [01:16] very complicated, it makes my head hurt [01:16] yes, one of the requirements was that it could be turned in to a module [01:16] nice [01:16] so standalone and integrated [01:16] oh yay .... T_T ....... Fair Access Policy Threshold Exceeded: YES [01:18] ah i think i heard a podcast with ellen [01:20] chaosradio express, number 64 [01:21] yeah [01:22] was really cool [01:22] she's in berlin and involved in the berlin UPA and gives talks a few times a year [01:25] hm and what do you think about tooltips and help systems such as the kde helpcenter? [01:27] * dwidmann votes for "good, when they're there" [01:30] night all [01:30] night Riddell [01:30] good job fillin in for me :P [01:30] thanks seele, Nightrose, txwikinger [01:30] :) thanks to you too [01:30] sleep well [01:31] thanks Riddell === pascutti is now known as pascutti|coding [01:37] Q&A over? [01:38] starting to look that way yuriy [01:38] * dwidmann heads off for a shower [01:38] ah, how did tutorials day go? [01:39] very well I'd say [01:40] * Nightrose is off to bed [01:40] good night folks :) [01:40] how did the tutorials day go? [01:40] goodnight night rose [01:40] er.. [01:40] good night night rose [01:40] hm.. nvm [01:40] ;-) [01:48] Jucato: went OK I think [01:50] nosrednaekim: btw what happened to your reply in the kubuntu-devel ML? it was like it was limited to 10-15 characters per line (in KMail) [02:00] Jucato: my signature? [02:01] you're whole post. maybe it's just KMail... [02:01] I thought I turned that off... [02:05] nosrednaekim: ah it was indeed only kmail... but you still have that sig that tries to spell your nick... maybe that caused it to bork in kmail? [02:13] well... I send it as HTML [02:13] * nosrednaekim ducks [02:15] :P [02:21] awww man [02:21] missed it === nixternal_ is now known as nixternal [02:56] nixternal: boo! [02:56] nixternal: Something for you :P http://jucato.org/stuff/Pater.jpg [02:59] Ah [02:59] pater [02:59] Latin [02:59] Duh :) [02:59] I read peter :) [03:00] Faith of a mustard seed (ha ha) [03:00] that's pretty cool Jucato :) thanks! [03:17] nixternal: what's the latest KDE 4 version in the PPA? and does it install on Intrepid? [03:19] 4.1 beta is in the ppa [03:21] ok :) [03:21] jjesse: btw, what's our doc project (other than adept please :P) for Intrepid? [03:22] Adept. Thank you [03:22] :-) [03:23] * daskreEEch votes Plasma [03:29] Jucato: don't know i think kde docs [03:29] not quite sure need to start working again :P [03:30] ah so no idea on the Kubuntu end of things yet? [03:30] correct [03:30] ok :) [03:31] watching a discovery channel thing on nasa and flying in space.... if they could do that in 1960 technology why aren't we further in space these days? [03:31] $$$ [03:34] No one cares about space anymore [03:36] ak bed time talk to you all later [03:37] bye jjesse [03:39] apachelogger: i am now. what's up? [03:39] Hobbsee: ^_^ [03:39] daskreEEch! [03:40] * daskreEEch adorns Hobbsee with flowers [03:40] Hobbseedobbsee!!!!!!!!!!!!!!! [03:40] :D [03:42] how'd the sessions go? [03:43] * Jucato was sleeping soundlyh [03:46] hehe [03:46] so was i [03:55] no fair! you were supposed to be awake by that time [03:56] Is it up somewhere? [03:56] on !logs, yes [03:58] ok I never recall if they log dev chans [03:59] I suppose they must cause I had this one person in #kubuntu who kept pulilng up things I had said and pasting them in the chan [03:59] ...yya [04:03] Does it make sense to have a plugin structure for a plugin ? === supert0nes is now known as supert0nes[A] [05:31] Do new KDE4 applications still go to /usr/lib/kde4? [05:32] LucidFox: define new? [05:32] Added after the new kdelibs were uploaded to intrepid [05:36] I'm currently fixing a build failure in kplayer, which was added in intrepid, and I was wondering whether it should go to /usr or /usr/lib/kde4 [05:38] LucidFox: hmm, not sure, it looks like kde4 is replacing kde3 in intrepid, so I would assume you'd want it to go to /usr ..... look for an example?? === man[afk] is now known as Aides === Jucato_ is now known as Jucato === Aides is now known as man[afk] === man[afk] is now known as Aides [07:21] Nightrose: morning === hunger_t is now known as hunger === prateek_ is now known as prateek [07:33] Nightrose: morning [07:34] Riddell: how did the pkging seminar go yesterday [07:34] morning Hobbsee [07:34] hi [08:04] morning [08:04] morning [08:05] Nightrose: hows u [08:05] *you [08:05] sleepy [08:05] <\sh> apachelogger: did you fixed pykde4 in ppa? [08:05] morning [08:13] it is my understanding that in order to implement plasmoids in python you need 2 things; [08:13] 1) Kross python which is a library that allows embedding the python interpreter in the plasma application [08:14] 2) wrappers for the plasma api (should be provided by pykde4) [08:14] the first part looks like it is there but the second doesn't [08:16] exist yet ? [09:06] <\sh> whoever uploaded python-kde4 to ppa..broke it [09:06] <\sh> pykdeuic4 doesn't exist anymore in python-kde4-dev [09:09] <\sh> fixing it now === Aides is now known as man[afk] === man[afk] is now known as Aides [09:48] <\sh> bah [09:55] <\sh> apachelogger: pingeling === Aides is now known as man[afk] === StuartMarsden_ is now known as StuartMarsden === man[afk] is now known as Aides [11:29] \sh: plong [11:30] <\sh> apachelogger: can you do the following for pykde4 in kdebindings? [11:31] <\sh> apachelogger: install symlink from /usr/share/kde4/apps/pykde4/pykdeuic4.py /usr/bin/pykdeuic4 <- make the first one 755 too [11:31] \sh: sure [11:31] according to stdin there is some more stuff broken [11:31] * apachelogger dives in [11:31] <\sh> apachelogger: and install symlink from /usr/share/kde4/apps/pykde4/kde4.py /usr/lib/python{2.4,2.5}/site-packages/PyQt4/uic/widget-plugins/ make it 755 too [11:31] Hobbsee: the problem self-resolved :) [11:32] <\sh> apachelogger: push it into python-kde4-dev ...:) [11:32] Nightrose: hey [11:32] <\sh> apachelogger: they are the ui compiler for pykde4 [11:32] apachelogger: oh good! [11:32] eagles0513875: sorry - dealing with massive traffic on my website right now [11:32] \sh: as if one needs that stuff :P [11:32] need to redirect some things to other servers [11:32] <\sh> apachelogger: dang [11:32] Nightrose: do you offer any free hosting [11:33] no [11:33] <\sh> apachelogger: or you move them into python-kde4-tools package or something like that...and recommend them in python-kde4 ;) [11:33] \sh: I think the stuff is just missing from the package [11:33] I didn't have time to run list-missing [11:34] off to an interview ill be back later [11:34] <\sh> apachelogger: no it's installed already :) [11:34] <\sh> apachelogger: but not in the correct places [11:35] \sh: well, having the uic not in bin seems rather stupid to me [11:35] <\sh> apachelogger: yes...but sime installed them in the $DATA dir whysoever..reading the CMakeLists.txt [11:36] Oo [11:36] oh well [11:36] <\sh> apachelogger: therefore they are in the shared/kde4/apps dir...(which is wrong by default ;)) [11:36] <\sh> apachelogger: actually you symlink them to the right position, or just remove them and install them from $SOURCETREE/tools/ to the correct locations :) [11:37] * apachelogger runs the >1h build for bindings [11:37] we will see [11:39] <\sh> apachelogger: thx...I would have done it myself..but I'm busy at work and with leonov... [11:40] * apachelogger likes the new animations in the trunk splashscreen [11:41] oh [11:41] there are now java kross bindings === Czessi__ is now known as Czessi === Riddell changed the topic of #kubuntu-devel to: Welcome to the Kubuntu developers channel | https://wiki.kubuntu.org/Kubuntu/Todo | Back to merging! | https://wiki.kubuntu.org/Kubuntu/Teams [11:52] good mornin' [11:52] nixternal: did you win at golf? [11:53] oh no, I got badly whooped [11:59] eh-heh! :P [12:00] heya nixternal ;-) [12:03] * apachelogger made Nightrose steal nixternal's talk *giggles* [12:06] :P [12:06] * Nightrose writes angry mail to website hoster *grummel* [12:08] hehe, thanks Nightrose [12:08] you're welcome - was not to difficult to adept your last talk [12:10]