| jonfore_ | I want to get involved with MOTU...is there anywhere I should look at beside the topic link? | 00:15 |
|---|---|---|
| Jazzva | jonfore_, you might want to check out https://wiki.ubuntu.com/MOTU/GettingStarted , in case you haven't already | 00:20 |
| jonfore_ | Jazzva: yep I've been checking it out. So I should learn how to package? | 00:24 |
| Jazzva | jonfore_, you don't have to learn all of that right now. You will learn the stuff by doing it. But at least reading the packaging manual will be helpful. | 00:25 |
| Jazzva | jonfore_, you can take a look at the bugs that're easy to fix (bitesize) | 00:25 |
| Jazzva | And find something you can work on. | 00:26 |
| jonfore_ | ok cool | 00:26 |
| jonfore_ | thanks | 00:26 |
| Jazzva | No problem | 00:26 |
| jonfore_ | Is there mentoring through MOTU? | 00:27 |
| crimsun | yes | 00:27 |
| Jazzva | jonfore_, http://tinyurl.com/5vp5g8 is the list of all bugs that are tagged with "bitesize" | 00:28 |
| Jazzva | jonfore_, for mentoring check https://wiki.ubuntu.com/MOTU/Mentoring | 00:29 |
| persia | cody-somerville: -1 for top posting. -1 for one-line with big quote. :p | 04:00 |
| cody-somerville | I knew I'd get that. | 04:00 |
| ScottK | I kind of over shot on doing my 5 today. I filed 8 bugs. | 04:02 |
| ScottK | Oh, wait. That was supposed to be about fixing, not filing, right? | 04:02 |
| persia | ScottK: Is 5-a-day really about filing :) | 04:02 |
| ScottK | ;-) | 04:02 |
| cody-somerville | I | 04:03 |
| persia | Well, it's about doing something with bugs: perhaps you're supposed to touch 13 now. Did you at least triage the ones you filed? | 04:03 |
| ScottK | I'm not even counting the Launchpad bugs. | 04:03 |
| persia | LP bugs don't count for 5-a-day anyway. | 04:03 |
| cody-somerville | I'm pretty sure filing 5 new bugs a day is a 5-a-day anti-pattern :P | 04:03 |
| ScottK | They were mostly syncs, so they'll be gone soon enough. | 04:03 |
| ScottK | Launchpad bugs are like catching fish in a barrell anyway. | 04:04 |
| persia | LP: feed's on | 04:04 |
| cody-somerville | Such negativity is not conducive to positivity :P | 04:04 |
| persia | cody-somerville: Well, there are lots of LP bugs, and historically some people haven't been good about filing them. Personally, I think having the bugs on record is better. | 04:05 |
| cody-somerville | persia, I agree | 04:05 |
| persia | From what I've heard from the LP devs, they have a lot easier time fixing things when the bugs are filed, so if finding LP bugs is like catching fish in a barrel, it's nice to prep them for the cooks. | 04:06 |
| * cody-somerville nods. | 04:06 | |
| cody-somerville | Nothing wrong with filing bugs :) | 04:06 |
| wgrant | I tend to find that LP bugs get triaged faster when you file a dozen in 20 minutes. | 04:06 |
| nxvl | ScottK: 5-a-day is about bugs, being filing, fixing, commenting, triaging, etc... | 04:07 |
| nxvl | hi all! | 04:07 |
| cody-somerville | nxvl, well thank you for that informative clarification ;] | 04:07 |
| * ajmitch starts up his automated bug filer | 04:08 | |
| persia | ajmitch: Which one? | 04:08 |
| ajmitch | persia: oh /dev/random should do | 04:08 |
| * persia thought ajmitch had a selection of useful automatd bug filers | 04:09 | |
| * ajmitch doesn't have useful stuff | 04:09 | |
| persia | Bah. RCbugs is direct counter-evidence. More could be found. | 04:10 |
| * ajmitch is having too much fun doing silly things in python | 04:11 | |
| wgrant | ajmitch: What kind of silly things? | 04:12 |
| ion_ | Bug filer based on MegaHAL, perhaps | 04:12 |
| ajmitch | wgrant: just playing around with creating types at runtime, some introspection, etc | 04:14 |
| ajmitch | nothing particularly useful yet | 04:14 |
| wgrant | ion_: I like that idea. I wonder what triagers would think when it responded to them. | 04:14 |
| wgrant | ajmitch: That's always fun. | 04:14 |
| ubuntu_ | anyone working on any cool projects? | 04:30 |
| cody-somerville | No, sorry | 04:30 |
| ion_ | Nope | 04:31 |
| ubuntu_ | so ion, you don't think anyone is working on anything cool? | 04:31 |
| ion_ | Indeed. | 04:31 |
| ubuntu_ | indubidably | 04:31 |
| ubuntu_ | I am going to go play a game then | 04:32 |
| === ubuntu_ is now known as foxjazz | ||
| nxvl | see you all! | 04:33 |
| persia | foxjazz: Can you define cool? | 04:33 |
| foxjazz | sure, anything that has to do with communication (net working) | 04:33 |
| foxjazz | or vr gaming | 04:34 |
| LucidFox | Gah! The fuzzy fonts in OpenJDK Swing! It burns! | 04:36 |
| persia | foxjazz: Well, there's a bit of gaming work that could be done. | 04:37 |
| persia | foxjazz: You might look in Section;games in your package manager, and see if anything there interests you. | 04:38 |
| persia | LucidFox: I believe there is a new swt-gtk that ought fix that: see bug #249158: needs testing and history investigation. | 04:39 |
| ubottu | Launchpad bug 249158 in ubuntu "Please sync swt-gtk 3.4-1 (universe) from Debian unstable (main)." [Wishlist,Incomplete] https://launchpad.net/bugs/249158 | 04:39 |
| persia | (Mind you, if someone wanted to write up some swt-qt bindings, that would be nifty) | 04:40 |
| LucidFox | persia> Swing, not SWT | 04:40 |
| LucidFox | Fonts in SWT are OK, because SWT is just a wrapper around system widget toolkits | 04:40 |
| persia | Oh. I (mistakenly) conflated the two. Re-education in progress... | 04:41 |
| persia | Ah. SWT is IBM's reimplementation of Swing for Eclipse, but completely different. Sometimes I love Java. | 04:44 |
| foxjazz | too many memory leaks in java | 04:45 |
| LucidFox | SWT uses a different philosophy from Swing | 04:45 |
| LucidFox | so they're not really comparable | 04:45 |
| LucidFox | Swing only uses the platform's window system and draws the widgets itself | 04:45 |
| LucidFox | whereas SWT uses platform widgets, such as Win32 standard controls, or GTK under Linux | 04:46 |
| LucidFox | This is why, for example, Eclipse looks native on every platform while the Java Control Panel does not | 04:47 |
| lifeless | foxjazz: less memory leaks in java than most C programs :) | 04:48 |
| foxjazz | heh no argument there | 04:48 |
| foxjazz | I prefer c# | 04:49 |
| persia | LucidFox: I thought that Swing had a native peer implementation for widgets. That said, yes, SWT and Swing are entirely different (they just seem to solve the same class of problem) | 04:49 |
| LucidFox | Yes, both are widget toolkits | 04:49 |
| persia | At least according to the IBM article I read, they also have feature parity, just completely different ways of being used. | 04:50 |
| LucidFox | I personally prefer Qt Jambi to both :) | 04:50 |
| persia | heh | 04:50 |
| LucidFox | Stupid upstream... their versioning scheme confuses uscan | 04:54 |
| LucidFox | BrowserLauncher2-all-11.jar | 04:54 |
| LucidFox | BrowserLauncher2-all-12.jar | 04:54 |
| LucidFox | BrowserLauncher2-all-1_3.jar | 04:54 |
| LucidFox | these are supposed to be 1.1, 1.2 and 1.3 : | 04:54 |
| ion_ | uversionmangle=s/^([0-9])_?([0-9])$/$1.$2/ | 04:56 |
| persia | ion_: The trick is knowing that they might introduce an underscore in advance of the release :p | 05:04 |
| ion_ | persia: :-) | 05:05 |
| foxjazz | how do you find the code for gaim? | 05:24 |
| lifeless | debcheckout gaim | 05:25 |
| wgrant | Except that Gaim ceased to exist some time ago. | 05:26 |
| foxjazz | lifeless is that a bash command | 05:26 |
| foxjazz | what about Kopete | 05:26 |
| persia | lifeless: Note that pidgin also doesn't have Vcs-* fields ... | 05:29 |
| persia | (Except when I run the right package analysis command) | 05:29 |
| foxjazz | persia how do you use debcheckout? | 05:29 |
| persia | foxjazz: I don't. | 05:29 |
| foxjazz | oh | 05:30 |
| foxjazz | I want to look at source for Kopete | 05:30 |
| foxjazz | how do I do that | 05:30 |
| wgrant | apt-get source kopete | 05:30 |
| foxjazz | says it failed | 05:31 |
| wgrant | I'd then advise you to fix the issue mentioned in the failure message. | 05:32 |
| foxjazz | dpkg-source: not found | 05:33 |
| wgrant | Install dpkg-dev | 05:33 |
| foxjazz | install command not found | 05:35 |
| StevenK | foxjazz: sudo apt-get install dpkg-dev | 05:38 |
| foxjazz | I finally got the source for kopete now what | 05:48 |
| persia | foxjazz: What do want to do with kopete? | 05:49 |
| foxjazz | well I want to look at the sorce | 06:03 |
| foxjazz | source code persia | 06:03 |
| ScottK | Then look at it. | 06:05 |
| persia | foxjazz: OK. You've run apt-get source kopete. This should create a directory called kopete-4.1.0. The source code is therein. Use your favorite text editor to view it. | 06:06 |
| foxjazz | well it created a folder called dkenetwork-3.5.8 | 06:09 |
| foxjazz | and the only source code viewer I have now is geany | 06:09 |
| foxjazz | persia there is no project file to open | 06:10 |
| persia | foxjazz: Ah. RIght. Kopete doesn't have it's own package. What do you see in the kdenetwork-3.5.8 folder? | 06:11 |
| foxjazz | kopote is in there | 06:11 |
| persia | s/it's/its/ | 06:11 |
| foxjazz | huh | 06:11 |
| foxjazz | what's a "good" dev environment? | 06:12 |
| persia | foxjazz: I tend to use terminals and vi. | 06:12 |
| foxjazz | well I am spoiled with vistual studio | 06:13 |
| foxjazz | visual* | 06:13 |
| persia | It depends on what upstream uses. Some packages have project files for various IDEs included in the source. Others do not. | 06:14 |
| === Igorot is now known as Knightlust | ||
| foxjazz | what's .svgz | 06:14 |
| persia | In those cases where upstream uses an IDE, and it is an IDE with which you are familiar, using the IDE can be good. For other cases, text editors win. | 06:14 |
| foxjazz | looking at it through geany now, geany is really nice I think | 06:15 |
| superm1 | foxjazz, geany works very well for some languages indeed | 07:39 |
| superm1 | it's my favorite to use for python | 07:39 |
| Wubbbi | Can a Motu take a look at http://revu.ubuntuwire.com/details.py?package=plasmoid-teacooker please? | 09:16 |
| persia | Wubbbi: For a new upstream release, please attach the new diff.gz to a bug, rather than uploading to REVU. Subscribe ubuntu-universe-sponsors to request upload. | 09:21 |
| Wubbbi | persia: so I have to creat a bug-report for new Upstream Release? oO | 09:23 |
| persia | Wubbbi: That is how they are usually processed. | 09:28 |
| Wubbbi | ok | 09:28 |
| persia | Wubbbi: Don't forget to review any open bug reports against the package to see if the new upstream release closes them. | 09:28 |
| sistpoty|work | hi folks | 09:32 |
| huats | morning everyone | 09:37 |
| huats | hey sistpoty|work | 09:37 |
| sistpoty|work | hi huats | 09:37 |
| Wubbbi | persia: ok I have created a new Bug-report, and I have uploaded the diff.gz to the bugreport. what to do now? upload to revu? | 09:38 |
| Iulian | Hey sistpoty, huats. | 09:38 |
| sistpoty|work | hi Iulian | 09:38 |
| persia | Wubbbi: Subscribe the sponsors queue, and wait for a sponsor | 09:40 |
| huats | hi Iulian | 09:40 |
| Wubbbi | persia: https://bugs.launchpad.net/ubuntu/+bug/253563 good like this? | 09:53 |
| ubottu | Launchpad bug 253563 in ubuntu "[ New Upstream Release ] Plasmoid Teacooker 0.3.0" [Undecided,New] | 09:53 |
| persia | Wubbbi: Precisely like that. Now it goes into the queue, and someone ought upload it. | 09:56 |
| Wubbbi | persia: and the Revu upload is not is necessary? | 10:11 |
| persia | Wubbbi: RIght. The diff.gz ought have everything needed. The watch file does work, doesn't it? | 10:14 |
| Wubbbi | persia: what watch file? oO | 10:15 |
| Wubbbi | I dont have a watch file | 10:16 |
| persia | Wubbbi: Ah. You'll want one of those. man uscan for details | 10:16 |
| Wubbbi | persia: lol the download link is "http://kde-look.org/CONTENT/content-files/85564-TeaCooker.tar.gz" how sould this call in debian/watch? | 10:20 |
| Wubbbi | I cant set the (.*) because no version is given xD | 10:21 |
| Iulian | Anybody knows why 'http://sf.net/salasaga/salasaga-([0-9]+\.[0-9]*[02468])\.tar\.bz2' doesn't work? I'd like to avoid dev versions which are odd numbered (0.7.x, 0.9.x, 1.1.x) and stable versions are 0.8.x, 1.0.x, 1.2.x | 10:21 |
| persia | Wubbbi: Well, complain to upstream about that: they should provide a version. | 10:21 |
| persia | Wubbbi: In this case, you'll want to implement a get-orig-source rule. | 10:22 |
| sistpoty|work | Iulian: seems like you're missing the second "." in the version number | 10:22 |
| Wubbbi | persia: omg ... why cant I upload the hole program? Like I have done it on the Initial Release? oO | 10:22 |
| persia | Iulian: You've missed the 'x'? | 10:22 |
| sebner | huhu sistpoty|work | 10:22 |
| sistpoty|work | hi sebner | 10:23 |
| persia | Wubbbi: Well, I don't think the initial release should have been accepted with neither a watch file or a get-orig-source rule. I have doubts that anyone verified the upstream tarball. | 10:23 |
| Burgundavia | Hobbsee: ping | 10:24 |
| Iulian | Oh, is this correct - http://sf.net/salasaga/salasaga-([0-9]+\.[0-9]+\.[02468])\.tar\.bz2 ? | 10:24 |
| sistpoty|work | Iulian: that however would match 0.7.2 for example, but I thought you'd want the 02468 as second digit, right? | 10:25 |
| Hobbsee | You sent me a contentless ping. This is a contentless pong. Please provide a bit of information about what you want and I will respond when I am around. | 10:25 |
| persia | Iulian: Try ([0-9]+\.[02468]+\,[0-9]+) | 10:26 |
| Iulian | sistpoty|work: Well, all I want to do is to avoid development versions. | 10:26 |
| Iulian | persia: Will try | 10:26 |
| sistpoty|work | Iulian: persia's version looks right at least if you s/,/./ :P | 10:27 |
| Iulian | Yea, sure :) | 10:27 |
| * persia is still learning to use a new keyboard, and doesn't have all the positions encoded in the forearms yet | 10:28 | |
| Iulian | no matching hrefs for watch line | 10:28 |
| Iulian | http://sf.net/salasaga/salasaga-([0-9]+\.[02468]+\.[0-9]+)\.tar\.bz2 | 10:28 |
| Iulian | Hmm, be right back - lunch. | 10:28 |
| Wubbbi | persia: how to make a .deb to the source again? | 10:30 |
| persia | Wubbbi: .deb -> source is not usually possible. Note that some languages (e.g. python, perl, PHP) can allow this, but it's a fair bit of manual work. | 10:33 |
| Wubbbi | persia: ufff ok | 10:33 |
| persia | Iulian: What is the specific URL you want to match? | 10:33 |
| Wubbbi | thx 4 info | 10:33 |
| Iulian | persia: This is the url from where you can download the source - http://sourceforge.net/project/platformdownload.php?group_id=58083 | 10:41 |
| Iulian | persia: Maybe we forgot the .alpha part? | 10:44 |
| Iulian | persia: Upstream will release in a few weeks alpha4. | 10:45 |
| persia | Iulian: Yep. Looks like you want ([0-9]+\.[02468]+\.[a-z-9\.]+).tar.bz2 | 10:49 |
| Iulian | persia: Bleah, still doesn't work... | 10:51 |
| persia | Iulian: Because I forgot to type the character '0' or because of something else? | 10:53 |
| Iulian | Right, it's working. | 10:54 |
| Iulian | persia: Well, Vincent from debian suggested to use mangle option to exactly match upstream version. I've read that part from the man page but still don't get it. | 10:54 |
| Iulian | persia: I'll use this watch file for now. | 10:55 |
| persia | Iulian: I'm never a fan of exact matching. On the other hand, you probably do want uversionmangle as you don't want to preserve the .alpha. | 10:57 |
| persia | And you'll want dversion mangle to drop the associated ~alpha :) | 10:57 |
| persia | Of course, this may well break when they release beta or final... | 10:58 |
| Iulian | persia: Yes, indeed, it will download the .alpha version, although I have renamed it to ~alpha. | 11:01 |
| Iulian | persia: So, I want that dversion mangle thingie. | 11:01 |
| Iulian | persia: Let me have a look at the man page again. | 11:01 |
| persia | Iulian: It's for precisely this sort of thing that uversionmangle and dversionmangle exist. | 11:01 |
| Iulian | persia: In the man page of uscan says 'opts=dversionmangle=s/\.dfsg\.\d+$// \'. I'm not sure how to use that. | 11:04 |
| Iulian | persia: I think I will have to change .dfsg with .alpha but I've not idea what d+ is for. | 11:04 |
| Iulian | Uhh, I have never understood the watch file. | 11:05 |
| persia | Iulian: \d is a short way to type [0-9] | 11:05 |
| Iulian | persia: And the dollar sign? | 11:06 |
| persia | So you could write the other example as (\d+\.[02468]+... | 11:06 |
| persia | $ is end of string | 11:06 |
| persia | So that matches e.g. ".dfsg4" | 11:07 |
| Iulian | Ah-ha | 11:08 |
| persia | (Anybody watching: please always try to avoid needing anything as complicated as dfsg4: it's almost always better to get more people to lok at dfsg1) | 11:08 |
| Iulian | So, how do I rename the dot from alpha to a tilde? | 11:09 |
| Iulian | In the end, that's what I want, to match ~ instead of . | 11:10 |
| Iulian | Btw, I will mail upstream to use tilde instead of dot in the versioning scheme. | 11:11 |
| persia | Iulian: Upstream should be fine using '.'. It's fairly normal for upstreams to do that. | 11:12 |
| Iulian | It's pretty odd. | 11:13 |
| persia | Why? | 11:13 |
| * persia sees it not infrequently, similar to e.g. 0.6rc4 | 11:13 | |
| persia | On the other hand, we typically don't want to ship such code, unless we're pressed tight against a deadline: it's generally better to wait a bit, let upstream release, and pull that. | 11:14 |
| Iulian | IMHO, it's pretty confusing to use that versioning scheme. | 11:14 |
| persia | Just because it doesn't ASCII-sort? Most people don't think in ASCII. | 11:14 |
| Iulian | Ah, right. | 11:15 |
| Iulian | When packaging something it's not indicated to use e.g. 0.1.0.alpha1, right? | 11:17 |
| Iulian | So, I changed the dot to a tilde and now the watch file will not work. I'm not sure what is the best way for doing this. | 11:18 |
| Iulian | persia: Is it ok to leave it as it is? | 11:22 |
| Iulian | persia: I mean, to use the dot instead of tilde in the changelog. | 11:22 |
| BUGabundo | is fuse.gvfs mount in / or in /home? | 11:23 |
| persia | Iulian: No, because then you can't get back to the bare version when it gets released. This is an issue with how versions work in Debian-format packages. | 11:23 |
| BUGabundo | please see http://fileland.bugabundo.net/temp/Screenshot-SystemMonitor.png | 11:27 |
| Iulian | persia: Hmm ok. Do you think I should leave the watch file as it is? | 11:28 |
| Iulian | persia: Because as far as I can see, there is no way. | 11:28 |
| persia | Iulian: I think it may make sense to step back a bit: why do we want alpha4 in the repos? | 11:28 |
| persia | (The way is to uversionmangle and dversionmangle to a common base: perhaps something like /\.[a-z]+(\d+)/.\1/ for uversionmangle. | 11:30 |
| Iulian | persia: It's alpha 3 actually, alpha 4 will be released in a few weeks. | 11:34 |
| persia | Iulian: Still why this version? | 11:34 |
| persia | Is it not better to work with upstream to hasten the release, and package that? | 11:35 |
| Iulian | persia: Upstream would like to fix some issues before releasing a new version. | 11:35 |
| persia | Right. Presumably we'd like those issues to be fixed before pushing it to all the users, as well, no? | 11:36 |
| Iulian | persia: That will be 0.8.0 but alpha4. That's not a big issue for users to stop using it. | 11:39 |
| Iulian | persia: And like I said it will be released in a few weeks so that won't be a problem. | 11:40 |
| persia | Iulian: To ask differently, what is so important about 0.8.0 that it is worth preparing an upload for alpha3? | 11:40 |
| persia | Especially as one would need to do it again for alpha4 in a couple weeks, and possibly follow this as continous integration until the proper 0.8.0 release. | 11:40 |
| persia | Do we have a sufficient number of testers who are also upstream testers to be worth it? Is someone tracking the bugs that closely? | 11:41 |
| persia | Are there lots of rdependencies that need porting, and starting now makes that easier? | 11:41 |
| persia | (Almost any reason would be acceptable, but there ought be some reason to take on the maintenance hassle that is an alpha release) | 11:41 |
| Iulian | persia: There is nothing important about 0.8.0 (see salasaga.org + lp). Upstream told me that he will still release alpha versions until he thinks that it's ok. The program is stable, it doesn't crash or something. When releasing a new alpha version the difference between the last one is not so big. The difference between alpha 3 and 4 is support for localisation. | 11:46 |
| Iulian | persia: + some bug fixes. | 11:46 |
| slytherin | Iulian: tell upstream that they have got the definition of alpha wrong | 11:46 |
| slytherin | Iulian: Instead of packaging alpha, why not backport bug fixes to current version in intrepid? | 11:47 |
| persia | Iulian: Do you expect a 0.8.0 final by end of August? | 11:47 |
| Iulian | persia: I don't know, will have to mail upstream. | 11:48 |
| Iulian | Btw, I'm packaging it for Debian, there is not version in Intrepid. | 11:49 |
| Iulian | I like to get it in Debian first and then request a sync. | 11:49 |
| persia | Iulian: You've heard about the freeze for lenny, right? Just right now, it may be better to put it in intrepid, and then push for lenny+1 in October or so. | 11:50 |
| Iulian | persia: It will get in unstable, right? | 11:51 |
| Iulian | persia: Lenny is still testing. | 11:51 |
| persia | Iulian: Maybe. Depends on the sponsor. Some people won't be uploading to unstable when the know it may not make lenny. | 11:51 |
| slytherin | when is teh freeze for lenny? | 11:52 |
| Iulian | slytherin: It's already frozen, if I'm not wrong. | 11:52 |
| persia | Iulian: http://lists.debian.org/debian-devel-announce/2008/07/msg00007.html makes my think it's frozen. | 11:52 |
| Iulian | persia: Since Vincent already replied to my RFS I think he will upload it. | 11:52 |
| slytherin | :-( | 11:53 |
| persia | Anyway, I think both of you should be subscribed to debian-devel-announce@lists.debian.org. It gets about 5-6 mails a month, and is a good way to keep track of our main upstraem. | 11:53 |
| persia | Iulian: OK. I still think it's worth waiting for 0.8.0 proper if it's soon. If not, you can use the mangling example I gave earlier to get the number and drop the words. | 11:54 |
| persia | Alternately just dversionmangle s/~/./ | 11:54 |
| Iulian | I'm only subscribed to debian-devel but I will subscribe to d-d-a, thanks for telling. | 11:54 |
| Iulian | persia: Ok, will try to use that. | 11:54 |
| === Ekushey_ is now known as Ekushey | ||
| Iulian | persia: http://iulian.devzero.co.uk/tmp/watch | 12:06 |
| Iulian | persia: It's ok now, thanks a lot. | 12:06 |
| Iulian | Huh, I just learnt more about these watch files ;-) | 12:08 |
| persia | Iulian: Excellent :) Nice job. | 12:08 |
| persia | Iulian: Would you like to use your newfound knowledge to do some more watch files? | 12:08 |
| Iulian | persia: Later - I still have some minor issues to fix on this package (http://www.mail-archive.com/debian-mentors@lists.debian.org/msg57295.html). Fixed everything, except the part with BitstreamVera. | 12:10 |
| Iulian | Brb - phone | 12:10 |
| * Iulian is back. | 12:12 | |
| Quintasan | Hi, I'm going to make a package with pastebin-like service script, any chances that it will be included in repository? | 12:20 |
| Iulian | I fixed that lintian info but now I get two warnings: desktop-command-not-in-package /usr/share/applications/salasaga.desktop /usr/bin/salasaga and menu-command-not-in-package /usr/share/menu/salasaga:3 /usr/bin/salasaga. I've renamed the menu file to salasaga.menu and modified the desktop file from Exec=salasaga to Exec=/usr/bin/salasaga. | 12:20 |
| Iulian | These are my dpkg contents: http://iulian.devzero.co.uk/tmp/contents. No idea why I get those warnings... | 12:21 |
| === ember_ is now known as ember | ||
| Iulian | Quintasan: I think there is already a package in the repo like that one. | 12:21 |
| sistpoty|work | yep, pastebinit | 12:23 |
| Iulian | Quintasan: https://edge.launchpad.net/ubuntu/+source/pastebinit | 12:23 |
| Iulian | sistpoty :P | 12:23 |
| Quintasan | Iulian: ok, thanks :) | 12:24 |
| persia | I thought pastebinit was a pastebin client. Do we also have a pastebin server? | 12:27 |
| sistpoty|work | no idea... I interpreted pastebin-like service script as client *shrug* | 12:29 |
| persia | Ah. I think we ought have a server, if there is a free one. Saves people cobbling them together full of the same issues. | 12:30 |
| Quintasan | I meant script as a client :P | 12:30 |
| sistpoty|work | persia: not if it's written in php :P | 12:30 |
| persia | sistpoty|work: I meant a good one :p | 12:32 |
| sistpoty|work | *g* | 12:32 |
| persia | Quintasan: There are actually several clients available. aptitude search paste ought get you a base list | 12:32 |
| persia | Well, I thought it would. Seems like people aren't always well behaved about short descriptions. In addition to pastebinit, there ought be at least GTK and QT front-ends. | 12:33 |
| persia | I seem to remember a plugin for some editor as well | 12:34 |
| huats | norsetto: hello my friend ! | 12:41 |
| norsetto | huats: hey! | 12:41 |
| huats | hey persia too ! | 12:41 |
| * norsetto <-- food | 12:53 | |
| Iulian | Is it ok to move the manual pages to the -common package? | 12:53 |
| sistpoty|work | Iulian: assuming you depend on it: yes | 12:53 |
| stefanlsd | i have trouble finding newbie tasks to take care of | 13:11 |
| Pici | !bitesize | perhaps? | 13:12 |
| persia | stefanlsd: What soft of tasks do you like? | 13:12 |
| ubottu | perhaps?: A list of bugs that are considered easy to fix and good for beginners to attempt can be found at: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize | 13:12 |
| persia | Some stuff that doesn't usually get bugs, but needs doing include: missing manpages, watch files, dependency analysis, .desktop file review, etc. | 13:13 |
| stefanlsd | i havent done anything yet, as I dont want to try anything advanced. i've checked the bitesize stuff in harvest and they all seem to be attended with debdiff's attached. I looked at the merge stuff from MoM and also couldnt find anything there... | 13:13 |
| stefanlsd | Like i saw eggdrop was listed - its kinda fun. used to play with them a lot. But i see its already been done after checking launchpad | 13:14 |
| persia | stefanlsd: Well then, how about watch files. Small changes, easy to test, and lots to choose from. | 13:14 |
| persia | http://qa.ubuntuwire.com/uehs/no_watch.html has a list of 760 packages that need watch files. For many of these, the watch wizard has already prepared a candidate that might work. | 13:15 |
| stefanlsd | persia: sounds good. I dont know anything about watch files. Find something on the wiki... https://wiki.ubuntu.com/PackagingGuide/Recipes/DebianWatch - so will give it a go | 13:15 |
| persia | stefanlsd: You may also find the uscan manual page helpful. | 13:16 |
| stefanlsd | thanks :) | 13:16 |
| persia | stefanlsd: Just for variety, I recommend taking a look at the bugs open against any package for which you plan an update: it may be that something there is also fairly easy to fix. | 13:17 |
| stefanlsd | persia: thanks. good idea. will do | 13:18 |
| persia | stefanlsd: Good luck, and when you get bored with watch files, ask for something else :) | 13:18 |
| stefanlsd | persia: kk. thanks. will do. How often is the html for qa.ubuntuwire.com/no_watch updated? | 13:20 |
| persia | I think it's every six hours or so, but maybe wgrant could answer with more precision. | 13:20 |
| stefanlsd | persia: would I follow the process of choosing a package and then logging a LP bug against my work? | 13:20 |
| persia | stefanlsd: Yep. Pick a package. Make sure nobody else is already working on it (by checking the open bugs). Open a bug for your work (and assign yourself). Ask here with questions. Attach a debdiff (or diff.gz if you update with a new upstream) to the bug. Subscribe the sponsors. | 13:22 |
| stefanlsd | persia: thanks. makes sense. I presume if a package has no watch file (the website will not list a watch file or an error) - the package needs a watch file. My job will be to add a watchfile. Would the correct thing be to check for a newer version, create a new version, and add a watch file? And if the package versions are same as upstream, just the debdiff to add the watch file? | 13:24 |
| stefanlsd | heh. never new about watch files. they are pretty clever... | 13:26 |
| Iulian | Could someone please archive gtkmm-utils package on revu? | 13:30 |
| ScottK | stefanlsd: Any non-Debian distro I've asked how they find out about new versions, the answer is, "Someone files a bug". This is definitely better. | 13:31 |
| huats | norsetto: if I am not attending the meeting, please ping me :) | 13:32 |
| huats | I am a bit busy some I might forget the time... | 13:32 |
| norsetto | huats: will do | 13:32 |
| huats | norsetto: thanks :) | 13:32 |
| huats | was the pasteque good ? | 13:32 |
| stefanlsd | ScottK: yeah. seems a little bit of a lazy way to do something. Although there must be something to be said with, if its not broken, dont fix it | 13:32 |
| norsetto | huats: excelletn ;-) | 13:32 |
| ScottK | It seems rather scattershot to me. This is more comprehensive. | 13:33 |
| huats | :) | 13:34 |
| ScottK | stefanlsd: Note that if the packages that don't have a watch file are in Debian, it's useful to send a patch to their BTS. We can help you learn how to do that too. | 13:34 |
| huats | o/ ScottK | 13:34 |
| stefanlsd | ScottK: ooh. ok. Thanks. I'm gonna try grab a package without a watch file and see how i manage. | 13:34 |
| joaopinto | is anyone familiar with the gambas2 package ? Are the examples supposed to run ? | 13:45 |
| kdubois | so now that I know how to use pbuilder, i figure i may as well help package things. are new packages being accepted on review? i dont know what point in the roadmap we're at for intrepid | 14:10 |
| kdubois | s/review/revu | 14:10 |
| Adri2000 | kdubois: see https://wiki.ubuntu.com/IntrepidReleaseSchedule, the deadline for new packages is FeatureFreeze | 14:12 |
| kdubois | hmm, so if i understand this correctly, up to august 28th, its possible to get new packages in the universe? | 14:14 |
| Adri2000 | yeah | 14:14 |
| persia | kdubois: Just to be safe, while 28th August is the absolute deadline, 14th August is a safer guideline for general use | 14:17 |
| persia | That gives a couple weeks for review cycles, fixing things, etc. | 14:18 |
| kdubois | and how can i know what still needs repackaging for intrepid? | 14:19 |
| persia | kdubois: For new packages, you can look at bugs with the needs-packaging tag. For new upstreams, you can use the watch files. | 14:22 |
| persia | http://qa.ubuntuwire.com/uehs/no_updated.html and https://launchpad.net/ubuntu/+bugs?field.tag=needs-packaging | 14:24 |
| Jazzva | Hi. Could someone review sphinxbase at REVU <http://revu.ubuntuwire.org/details.py?package=sphinxbase>? Thanks :) | 14:48 |
| kdubois | hmm, ok. question, in my revu package for tv-grab-dvb, it says i can put my name in control under XSBC-Original-Maintainer. however, i see warnings that this is a 'user defined field' | 14:49 |
| Jazzva | kdubois, as far as I know, you can safely ignore the warning. | 14:50 |
| tuxmaniac | kdubois: you can ignore that warning. Also the make sure the standards is 3.8.0 | 14:50 |
| stefanlsd | tuxmaniac: Do we say 3.8.0 or 3.8.0.1 as the actual lastest standards? | 14:51 |
| ScottK | 3.8.0 is preferred. | 14:51 |
| stefanlsd | ScottK: kk. Thanks. | 14:53 |
| persia | Note that it's not generally worth updating the standards version of any package with a Debian Maintainer, as those tend to be things that get fixed anyway, and only rarely break things. | 14:53 |
| stefanlsd | ScottK: Im looking at the package mp3wrap that has no watch file. There is also an open bug regarding some ID3v2 tags. Upstream states that the program is not under development anymore since 2006. What should be our thinking on this? (the LP bug logged is an upstream issue) | 14:54 |
| kdubois | so i uploaded to revu, but it doesnt show up yet. is there some latency between upload, and seeing it on the site? | 14:55 |
| persia | kdubois: I think the index refreshes every ten minutes. Also, I hear the documentation is out of date: you may need to log in before uploading. | 14:56 |
| persia | stefanlsd: If upstream is inactive, fixing it locally is greatly appreciated. It's considered polite to send patches upstream, just in case they become active again, or so another distro can easily apply it. | 14:57 |
| nhandler | persia: When you log into REVU, it syncs the keyring. So you do need to log in at least once prior to uploading a package | 14:58 |
| stefanlsd | persia: ok. When does the decision (if ever) to drop the package from universe happen? | 14:58 |
| ScottK | stefanlsd: I was going to suggest if upstream is dead and there are alternatives available consider asking for removal. | 14:58 |
| kdubois | persia: ok, i logged in and tried it again. it looked like it worked, i guess we'll see in 10 minutes | 14:58 |
| persia | nhandler: Right. Thi is different than the wiki :) | 14:58 |
| ScottK | stefanlsd: If it's removed from Debian, we remove it semi-automatically. Otherwise it's when someone notices and suggests it. | 14:59 |
| stefanlsd | Do we have anyway to track userstats - like how many people have apt-get (ed) it? | 14:59 |
| nhandler | persia: The entire wiki page probably needs updating now that REVU has been updated. For instance, it no longer uses the revu-uploaders team on Launchpad. | 14:59 |
| persia | stefanlsd: I consider a package suitable for removal if there are irreconcilable bugs and no prospect of fixing it. If the package is otherwise in shape, no need to remove. | 15:00 |
| persia | nhandler: Good idea. Maybe you're up for that? | 15:00 |
| nhandler | persia: I haven't done much wiki work in the past, but I could probably give it a try later today. | 15:00 |
| stefanlsd | persia, ScottK: Thanks - makes sense. I will see if the fix is easy enough to close the LP bug and see if I can make the watch file. | 15:01 |
| norsetto | ping huats | 15:01 |
| huats | norsetto: pog | 15:02 |
| huats | pong | 15:02 |
| norsetto | huats: meeting | 15:02 |
| stefanlsd | thanks for all the help so far. bbl | 15:07 |
| nhandler | persia: It looks like RainCT took care of updating the REVU wiki page after the update. | 15:07 |
| * persia looks again, confused | 15:07 | |
| Xand3r | hey ho | 15:23 |
| Xand3r | i am Alexander | 15:23 |
| Xand3r | i had package something, could some one review it? that would be realy great | 15:24 |
| Xand3r | here the links http://revu.ubuntuwire.com/details.py?package=digikam-kde4 http://revu.ubuntuwire.com/details.py?package=rubberband | 15:24 |
| Xand3r | thx | 15:24 |
| emgent | moin | 15:27 |
| Xand3r | moin emgent | 15:34 |
| [GuS] | hi Guys... how can i avoid dpkg-shlibdeps? I am compiling/packaging Qt4.4 with phonon support.. and it fails checking that at the end... | 15:46 |
| [GuS] | and i need that lib... | 15:46 |
| ScottK | [GuS]: I think fix the lib is the answer (as I already mentioned on #kubuntu-devel). | 15:52 |
| sistpoty|work | [GuS]: also you don't really want to disable dkpg-shlibdeps... can you pastebin the error messages? | 15:59 |
| [GuS] | sistpoty|work: sure | 16:00 |
| [GuS] | sistpoty|work: http://pastebin.com/m30619d0f | 16:01 |
| sistpoty|work | [GuS]: that's a bug in the phonon package, which doesn't ship an shlibs file. | 16:04 |
| [GuS] | is why i've asked how to skip that in that part... | 16:05 |
| [GuS] | since the only phonon in the system comes from kde | 16:05 |
| [GuS] | which i need the qt version one.. | 16:05 |
| [GuS] | theres is no Qt phonon in repositories to install | 16:06 |
| sistpoty|work | [GuS]: well, you could skip that part by omitting the call to dh_shlibdeps... however the real bug is in the phonon package and should be fixed there | 16:06 |
| [GuS] | i know i know sistpoty|work but i am not going to upload the built anywhere.. is just for me | 16:07 |
| [GuS] | so just skipping that check for now will do for me... | 16:07 |
| [GuS] | since i need that lib in many computers.. | 16:07 |
| sistpoty|work | [GuS]: even if it's just for you, that doesn't make the phonon package less buggy ;)... can you file a bug at https://launchpad.net/ubuntu/+source/phonon/+bugs please? | 16:08 |
| [GuS] | hehe.. i know that sistpoty|work but i am developer... and to do what i need... is only with that lib.. :S | 16:08 |
| [GuS] | sistpoty|work: but that phonon comes from kde if i am not wrong... | 16:09 |
| [GuS] | (of that bug report) | 16:09 |
| [GuS] | mm... | 16:10 |
| sistpoty|work | [GuS]: so you don't have the libphonon-dev package installed but use your own version? | 16:10 |
| [GuS] | sistpoty|work: lets see... that libphonon-dev is not from Qt so far i know and so what devs told me | 16:11 |
| [GuS] | you see, i must build PyQt with the libphonon support that comes from Qt4 | 16:11 |
| [GuS] | and not from kde | 16:11 |
| [GuS] | and i saw that in qt4.4 source package, on debian rules has phonon disabled | 16:11 |
| sistpoty|work | [GuS]: so you have built your own qt4 debs with phonon enabled and then get this error? | 16:12 |
| [GuS] | exactly | 16:13 |
| [GuS] | i've changed the rule -no-phonon by -phonon to build it | 16:13 |
| [GuS] | the packages finished to compile... it fails when is ending to build the package itselft | 16:13 |
| [GuS] | i have no make errors, that is what i mean | 16:14 |
| sistpoty|work | [GuS]: and are you putting the resulting files in the correct packages? (libphonon[SONAME], libphonon-dev?) | 16:14 |
| sistpoty|work | [GuS]: otherwise debhelper won't find the info for the shared libraries resulting from the build itself | 16:15 |
| [GuS] | mmmm | 16:15 |
| [GuS] | seems i need more skills bulding a package... (indeed never had this problem..) | 16:16 |
| sistpoty|work | [GuS]: maybe this might be an interesting read in regards to your problem: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html | 16:18 |
| [GuS] | ok, lets see.. thanks.. | 16:18 |
| [GuS] | just i do this cause i want to avoid compile Qt4.4 with phonon support in every workstation that i need | 16:18 |
| [GuS] | is why i am trying to build the package | 16:19 |
| * sistpoty|work heads home... cya | 16:27 | |
| [GuS] | damn... this is to much for just build the package of a lib... i dont want to become pro MOTU :S | 16:29 |
| kdubois | ok, its been quite some time, and my package hasn't moved up from needs work on revu. how can i tell what i'm doing wrong? | 16:39 |
| slytherin | kdubois: did you check comments? | 16:41 |
| kdubois | comments on revu? yes, i corrected the issues the reviewer found, and am trying to resubmit | 16:42 |
| slytherin | kdubois: so what is the problem? Did you not reupload the package? | 16:42 |
| kdubois | i tried to with dput, and it looks like it did it, but nothing happened | 16:43 |
| kdubois | i.e. my command looks like it worked on my machine, but the site isn't updating | 16:43 |
| slytherin | kdubois: what command did you fire? | 16:43 |
| kdubois | dput revu tv-grab-dvb_0.9-1_i386.changes | 16:44 |
| slytherin | kdubois: you need to use dput -f when uploading second time. | 16:44 |
| Hobbsee | you need to upload a source, too | 16:44 |
| Hobbsee | launchpad doesn't accept binaries. | 16:44 |
| slytherin | kdubois: which means force the upload even if same version is alreayd available on revu | 16:44 |
| Hobbsee | neither does revu | 16:45 |
| slytherin | kdubois: yes, you need to upload source.changes file | 16:45 |
| kdubois | pdebuild -S doesnt work like debuild -S | 16:46 |
| slytherin | kdubois: I have never used pdebuild but with debuild I use -S -sa when uploading to revu | 16:46 |
| kdubois | my issue here is i'm on hardy, so i think i have to use pdebuild, right? | 16:47 |
| slytherin | kdubois: I use pbuilder. I am not aware of other build tools. | 16:48 |
| Hobbsee | if you're on hardy, you don't want to use pdebuild. | 16:49 |
| Hobbsee | you want to use pbuilder. | 16:49 |
| Hobbsee | slytherin: it uses the same tool, more or less. | 16:49 |
| slytherin | hmm | 16:49 |
| norsetto | huats: hmmm, can we talk for few secs? | 16:49 |
| huats | norsetto: sure | 16:50 |
| kdubois | sigh, just when i thought i had this figured out... | 16:52 |
| kdubois | so pbuilder validates installs, and debuild makes the .changes and .dsc files? | 16:54 |
| persia | kdubois: pbuilder generates binary packages from source packages | 16:55 |
| bddebian | Heya gang | 16:58 |
| kdubois | so standard work flow is:1) make debian dir with dh_make. modify what needs to be modified | 16:59 |
| kdubois | 2) run debuild to make the .changes and .dsc files | 16:59 |
| kdubois | and 3) check what was made with pbuilder? | 16:59 |
| persia | kdubois: Essentially, although not everyone uses dh_make to create debian/ and some people use sbuild instead of pbuilder. | 17:00 |
| kdubois | one thing i still don't get is why do i need a tar.gz file in the parent directory? | 17:02 |
| norsetto | kdubois: oh, thats just the content of the package | 17:03 |
| norsetto | kdubois: you can normally don't bother, its not worth most of the time :-) | 17:03 |
| * sebner winks norsetto (without a clear reason) | 17:06 | |
| norsetto | kdubois: mainly, you take the .tar.gz from upstream, change it to an .orig.tar.gz, untar it, add the packaging stuff in debian/, debuild -S (notice that this will make a .diff.gz, which is your packaging stuff) and then build the binaries with, for instance, pbuilder | 17:06 |
| norsetto | sebner: ahah! you are back! | 17:07 |
| sebner | norsetto: uhhh yes, I am :D | 17:07 |
| norsetto | sebner: was it good? | 17:07 |
| sebner | norsetto: something between good and ok ^^ | 17:07 |
| norsetto | sebner: thats better than plainly awful, rainy and wet :-) | 17:08 |
| sebner | norsetto: true. it wasn't that rainy and if it was then just short and not heavy | 17:08 |
| sebner | ember: \o/ | 17:11 |
| kdubois | norsetto: i guess it makes sense in that context, i've only ever done 'packaging from scratch" so far though | 17:14 |
| norsetto | kdubois: sure | 17:14 |
| norsetto | kdubois: there is also anothery category pf packages (so called native ones) that do not use a .diff.gz to store the packaging info. In these cases debian/ is an integral part of the upstream tarball. | 17:19 |
| huats | norsetto: enjoy your we | 17:21 |
| huats | cause I'll enjoy mine :) | 17:21 |
| huats | bye | 17:21 |
| persia | Native packages are in some ways anti-social, as their construction implies they will not be used in any other distribution. | 17:21 |
| norsetto | ah, that would be week-end | 17:21 |
| norsetto | persia: I stumbled in a debian mailing list once about a discussion about what can be considered or not native, the policy is ambiguous in that respect | 17:23 |
| persia | norsetto: Deliberately so, from what I understand. | 17:24 |
| norsetto | persia: possible | 17:24 |
| thibs | hi | 17:44 |
| thibs | I have a little question about packaging | 17:44 |
| thibs | could someone tell me what's the "right" to launch an app right after it has been installed ? | 17:44 |
| thibs | s/right/right way/ | 17:45 |
| persia | thibs: GUI or CLI? | 17:45 |
| superm1 | thibs, is this a daemon, or an app a regular user will be running? | 17:45 |
| thibs | gui | 17:45 |
| thibs | it gets in the systray | 17:45 |
| thibs | s/gets/goes/ | 17:46 |
| persia | thibs: Most of those I've seen seem to have well-crafted .desktop files. | 17:46 |
| thibs | you mean you can have the app launch automatically thanks to the .desktop file ? | 17:47 |
| thibs | I thought I would have to put something in postint or something like that... | 17:47 |
| persia | thibs: postinst runs as root, so you can't adjust the user session. | 17:49 |
| persia | The user needs to launch it manually once, after which it can live in the session. ekiga and liferea might be good examples for GNOME. | 17:49 |
| thibs | right... I did not see that | 17:49 |
| thibs | hmm... so you think there's no way to have it launch automatically after install ? | 17:50 |
| thibs | just for my culture, what if it had been a daemon ? | 17:52 |
| persia | thibs: Generally one installs either an init script or an upstart event to start the daemon on boot. | 17:52 |
| thibs | ok | 17:53 |
| thibs | thanks! | 17:53 |
| siretart | thibs: you could emit a signal on the system dbus and make gnome-session to react on that | 17:53 |
| siretart | which in turn could fire up 'missing' user services | 17:54 |
| siretart | no idea if gnome-session does support such a concept, though. | 17:54 |
| [GuS] | Guys... can someone help me to build Qt4.4 package with phonon support? i've downloaded the source package from repository and i've changed the rules of the configure, -no-phonon by -phonon, but i know is not enought and something i am missing since i have this at the end: http://pastebin.com/m30619d0f . I just need this since as developer fro my application... i dont really want to know perfect to build a package (i am suing dpkg-buildpackge | 17:54 |
| [GuS] | btw) | 17:54 |
| [GuS] | using* | 17:54 |
| james_w | thibs: you can install a .desktop file to add it to the default session, so the user will get it when they next restart their session | 17:55 |
| === slayton-ZzZz is now known as slayton | ||
| ScottK | [GuS]: did you install the phonon dev package? | 17:56 |
| thibs | siretart, thanks for the hint. Pb is I've never touched these techno (dbus and gnome-session) so far.. so it might take me too much time experimenting and getting it to work | 17:56 |
| [GuS] | ScottK: again... the dev package of phonon if the phonon of kde........ | 17:56 |
| [GuS] | there is not package for the phonon of Qt... | 17:57 |
| siretart | thibs: it is a rather complicated thing. I wouldn't invest to much efford in thus unless it is a really critical requirement | 17:57 |
| ScottK | [GuS]: Then my suggestion is make a package for that first. | 17:57 |
| thibs | james_w: good idea.. it's better than nothing | 17:57 |
| [GuS] | from where? ScottK¿ and what do you think i am doing? | 17:57 |
| [GuS] | that package does not come alone... | 17:57 |
| [GuS] | is inside Qt4. | 17:57 |
| [GuS] | and if you could tip me... i coudl do it... | 17:58 |
| ScottK | OK. | 17:58 |
| [GuS] | i dont want to be a MOTU expert or so | 17:58 |
| james_w | thibs: /etc/xdg/autostart/ if you haven't found it yet, unless you are specific to a single desktop environment | 17:58 |
| [GuS] | i just need libphonon from Qt4... | 17:58 |
| ScottK | Understand. Unfortunately I'm headed out the door. | 17:58 |
| thibs | siretart, I guess a good enduser documentation on how to launch the app once it is installed will make it... | 17:58 |
| [GuS] | i am using now it, but cause i did make install after qt4 compilation | 17:58 |
| [GuS] | but i need to create the package | 17:58 |
| [GuS] | to install in all other workstations i need | 17:58 |
| siretart | thibs: just install the .desktop file and make it appear in the menu. this causes least surprise, I'd say | 17:59 |
| [GuS] | and i just now a base of how to build packages for debian/ubuntu | 17:59 |
| [GuS] | know* | 17:59 |
| james_w | thibs: if you do what siretart suggests then gnome-app-install will allow the user to install it, and then give them the chance to run it straight after installing | 17:59 |
| thibs | siretart, that's how it is now but still the user has to go find it in the menu | 18:00 |
| james_w | thibs: if you wanted it to run for that user on login from that point you can install a file to their local autostart directory. | 18:00 |
| siretart | thibs: is this really a concern for you? | 18:00 |
| thibs | james_w, my concern is more having it to run just after it gets installed | 18:01 |
| persia | Unless there's a need to run by default for every user on every system on which it is installed, it's probably nicer to have it not be in autostart, and just be added to a user session through a menu item. | 18:01 |
| ogra | thibs, you can add a notification | 18:02 |
| james_w | thibs: I don't think there's a way to do that currently for user level programs | 18:02 |
| siretart | thibs: it seems to me that this problem is better solved in the application/frontend that installs the package. there you are already in the right security context | 18:02 |
| thibs | james_w, this way the user doesn't have to bother about searching for the app in the menu | 18:02 |
| ogra | like the reboot notification or firefox restart notification | 18:02 |
| [GuS] | i thini i sould contact the maintainer... | 18:02 |
| ogra | that then can tell the user that she has gotten new software that will be autostarted after relogin | 18:04 |
| ogra | or where to find it in the menu | 18:04 |
| ogra | or whatever yo want | 18:04 |
| === Syntux_ is now known as Syntu | ||
| === Syntu is now known as Syntux | ||
| === x-spec-t is now known as Spec | ||
| poningru | quick question | 18:05 |
| poningru | I have a theme deb package | 18:05 |
| poningru | how can I convert it into a normal theme package? | 18:05 |
| persia | poningru: How do you mean? You want to convert a binary package to a source package? | 18:06 |
| thibs | ogra, any hint on how I could add a notification? | 18:06 |
| ogra | thibs, grab the firefox source and look at the postinst script | 18:06 |
| thibs | siretart, you're right but gdebi doesn't offer the possibility to run the package after installation | 18:06 |
| ogra | thibs, or alsa-utils or fuse i think | 18:06 |
| ogra | they all do that | 18:06 |
| poningru | persia, http://launchpadlibrarian.net/16248217/human-netbook-theme_0.3_all.deb | 18:07 |
| ogra | fuse might be the lightest to download | 18:07 |
| thibs | ogra, I'll look into that right now! | 18:07 |
| thibs | thank you all for your help | 18:07 |
| thibs | If I find something cool to solve my pb, I'll come back to tell you | 18:08 |
| persia | poningru: That doesn't answer my question :p | 18:08 |
| siretart | thibs: perhaps you should fix gdebi then instead of adding weird workarounds in your package, then. | 18:08 |
| persia | poningru: But I suspect that http://ppa.launchpad.net/netbook-remix-team/ubuntu/pool/main/h/human-netbook-theme/ contains the answer to the question you haven't asked. | 18:09 |
| poningru | persia, sorry I need that to convert it to a normal theme package | 18:10 |
| poningru | as in a .tar.gz | 18:10 |
| poningru | no but thats a deb package | 18:10 |
| poningru | doesnt work for me | 18:10 |
| poningru | as in if I try to do a theme install from the normal interface system->pref->appearences | 18:11 |
| poningru | it errors out saying package is not a theme | 18:11 |
| thibs | siretart, I find the firefox notification cool don't you? and I don't think it's in the weird workaround... if it is, I'll not implement it | 18:12 |
| siretart | thibs: no idea. I don't really like firefox | 18:13 |
| siretart | and use epiphany instead | 18:13 |
| poningru | thibs, what are you trying to do? | 18:16 |
| thibs | poningru, trying to have an app run just after it got installed | 18:17 |
| ogra | he needs an app runing in the sytray ... for what you usually have a .desktop file in /etc/xdg/autostart ... | 18:17 |
| ogra | but since the user should know about having ot log out to make that take effect it needs also a notification from postinst | 18:18 |
| norsetto | poningru: you have downloaded something with a .deb extension? | 18:18 |
| poningru | norsetto, yeah http://launchpadlibrarian.net/16248217/human-netbook-theme_0.3_all.deb | 18:18 |
| poningru | and its source file http://launchpadlibrarian.net/16248178/human-netbook-theme_0.3.tar.gz | 18:18 |
| poningru | I want it to be a normal theme file | 18:18 |
| poningru | never worked with themes before | 18:18 |
| ogra | poningru, i dont think thats really compatible to a gnome tehem file | 18:18 |
| ogra | *theme | 18:18 |
| norsetto | poningru: ok, then you need to install it, wiith dpkg or gdebi (but then, why don't you install it with your package manager?) | 18:18 |
| poningru | norsetto, its for cd iso repackaging purposes | 18:19 |
| poningru | I guess that will work as well... | 18:19 |
| persia | If a notification is being used anyway, why should it call for the user to log out and log in again, when really the user only needs to start the application? Wouldn't putting something as a menu entry be preferable to autostart (so other users of the same system would also be able to choose whether or not to run the application)? | 18:19 |
| ogra | you would have to unpack it and roll a tarball according to the gnome theme policies f you wanted it to be a standard gnome theme | 18:19 |
| ogra | persia, but the menu entry would persist for something thats running all the time anyway | 18:20 |
| persia | Might be easier to start with the source package, rather than the binary package. | 18:20 |
| poningru | persia, yeah frack it I think I am just going to have to script it to install the package on first run or something | 18:20 |
| persia | ogra: Well, running for those users who want it. I have a menu entry for liferea. I use it once per user definition. | 18:20 |
| ogra | if you have it autostarting, why add a menu entry and waste menu space ? | 18:20 |
| persia | ogra: Well, in the case of liferea, it allows me to restart it when it crashes without restarting my whole session. | 18:21 |
| ogra | right, if you want to provide choice a menu entry helps :) | 18:21 |
| thibs | ogra, it looks like ubuntu have a standard way to notify users about random events | 18:22 |
| ogra | in case of i.e. my classmate screen switcher that switches the panning mode i wouldnt want a menu entry ... since that tool has to be available on every desktop at every time | 18:22 |
| thibs | ogra, by putting specific files in /var/lib/update-notifier/user.d/ | 18:22 |
| ogra | it really depends what the app is | 18:22 |
| ogra | thibs, i know i wrote the notification bit for fuse | 18:22 |
| thibs | ok sorry :) | 18:22 |
| ogra | ;) | 18:22 |
| sebner | persia: ok if I start to work on RC bugs list in the near future (mainly syncs and merges though)? | 18:23 |
| ogra | in case of something like liferea a menu entry makes indeed sense ... in case of a status measurement tool etc which should run all the time for all users not having a menu entry makes more sense imho | 18:24 |
| * ogra rushes for the doorbell | 18:24 | |
| persia | sebner: I heard that RCbugs got retargeted to intrepid just this week, so you're right on schedule :) | 18:24 |
| persia | ogra: Good point. | 18:25 |
| persia | thibs: What does the app do? | 18:25 |
| sebner | persia: hrhr, well was 2 weeks away so I don't know anything ^^. Better to wait for FF? | 18:26 |
| persia | sebner: No need to wait. It gets more important after FF, but if you perhaps first focus on the ones that would otherwise need FF exceptions, it may be advantageous to start early. | 18:27 |
| persia | This is all the more true as lenny recently froze, so there's a good chance we'll have almost no FF exceptions from Debian if we can pull any new upstreams required in advance. | 18:28 |
| sebner | persia: kk, /me is just making a todo list for the next few weeks so I'm collecting ideas | 18:28 |
| thibs | persia, it's a small client that need to connect to a website... as long as the client doesn't connect to the website, the user is stuck with the registration process | 18:30 |
| thibs | this is why i'd love it to execute right after install :) | 18:31 |
| thibs | to ease the user experience | 18:31 |
| persia | thibs: Hmmm. execute-on-install would need some new hook for the package managers (and such a hook would need to work with all of them). | 18:33 |
| persia | re-login at install seems odd, as users are presumably downloading this from the website where they need to register. | 18:34 |
| thibs | persia, exactly | 18:34 |
| === thekorn_ is now known as thekorn | ||
| persia | Install, launch, register is awkward. Sending some notice through dbus might be the least awkwarsd way, but t'it's fairly hackish. | 18:34 |
| thibs | persia, siretart proposed a solution like this one... might probably work but I think 'hackish' is the good word to describe it indeed :) | 18:36 |
| DRebellion | Any MOTUs with a bit of free time ---> monkeystudio is a Qt4 IDE that needs reviewing in REVU: http://revu.ubuntuwire.com/details.py?package=monkeystudio ;) | 18:49 |
| LucidFox | Error '425 Security: Bad IP connecting.' during ftp transfer of libbrowserlauncher2-java_1.3.dfsg-0ubuntu1.dsc | 19:03 |
| LucidFox | Why can't I upload to REVU anymore? | 19:03 |
| === dpm_ is now known as dpm | ||
| Falken | hi motu, I'm looking for advocates for my simple package, flabber --> http://revu.ubuntuwire.com/details.py?package=flabber | 19:25 |
| Falken | It's been reviewed several times already, this one should be the last :) can anyone take a look ? | 19:25 |
| awmcclain | I'm a little confused about the debian upstream version number. If I'm part of a project that maintains a /debian directory in the source control, would that mean that the upstream-version shouldn't be used ( eg mogilefs-1.70-ubuntu1 vs mogilefs-1.70-1ubuntu1?) | 19:33 |
| Laney | awmcclain: It's generally discouraged for upstream to maintain their own debian/ directory | 19:48 |
| awmcclain | Laney: Because they don't know what they're doing? =) | 19:48 |
| Laney | No, because the files in there are for the use of packagers who need to know what's going on in there. And merging upstream's changes with local ones is bound to cause headaches | 19:50 |
| Laney | if you want to release your own debs then a separate branch for them would probably be most convenient | 19:51 |
| awmcclain | Mmm. Understood. What if the maintainer is part of the project? (The only reason I push is that politically, I can't change the fact that /debian is checked into VCS) | 19:52 |
| awmcclain | "Local ones" being, what? Changes to the package that haven't been checked in? | 19:53 |
| Laney | Plus it ties the release process to debian - the files in there are useless to all other distros | 19:53 |
| Laney | No, changes to the package made by someone not part of the upstream team | 19:53 |
| Laney | awmcclain: You might not always be the maintainer. And also, debian changes should be (able to be) independent of upstream. | 19:55 |
| ScottK | awmcclain: I have a project that I'm upstream for and I maintain the debian/dir in the upstream VCS. I just don't include it in the tarball when I roll a new release. | 19:56 |
| awmcclain | ScottK: Ok, that makes sense. Sorry I'm slow to this, I'm still wrapping my head around all the packaging concepts. Do you manually roll the tarball, then? Or is there an excludes? Or do you remove it from the manifest? | 19:58 |
| ScottK | My project is very small, so I do it manually. There are tools that support excluding directories from the build. | 19:58 |
| ScottK | tar -cvvzf project-name-version.tar.gz project-name-version --exclude=debian | 20:00 |
| Laney | That's fine too. I think (and this is nice and easy with something like bzr) that I'd keep another debian branch which merges with trunk as and when. Just like to keep a separation of project and packaging. | 20:01 |
| awmcclain | Laney: I agree. That's what I've done with the ubuntu packaging. | 20:02 |
| Laney | awmcclain: Cool. I think this is the way that Ubuntu development in general is planned to go anyway (DVCS as opposed to source packages) | 20:03 |
| awmcclain | Laney: And that branch would be public, so i the maintainer goes MIA, someone else can take over. | 20:04 |
| awmcclain | s/i/if | 20:04 |
| awmcclain | But. Since the main branch is on SVN, and since the debian dir is checked in there, what's the appropriate way to deal with versions? Think of the checked-in version control as a "template" for people to roll their own packages, and leave off the upstream version? | 20:06 |
| ScottK | Laney: The whole no source packages thing is still very controversial. | 20:09 |
| Laney | ScottK: Oh? I thought it was The Way Things Are Going To Be. | 20:09 |
| ScottK | There are a number of version 3.0 source package formats out there. The most popular approach in Debian is one oriented around Git. | 20:11 |
| ScottK | Obviously Canonical has a different view. | 20:11 |
| ion_ | git ftw. ;-) | 20:11 |
| awmcclain | Here's the context: http://groups.google.com/group/perlbal/browse_thread/thread/379f468a73dbafe | 20:12 |
| ScottK | My view until I don't feel like I'm waiting for the heat death of the universe trying to check out some bzr thing from Launchpad, I"m really not interested. | 20:12 |
| awmcclain | Poor little bzr. :( | 20:13 |
| ScottK | awmcclain: What version number will the next upstream release of your package have? | 20:14 |
| ivoks | vista-sp2 | 20:15 |
| ivoks | :D | 20:15 |
| ivoks | sorry... | 20:15 |
| porthose | in debian/control do you use the source package name or the binary package name ie prototpe.js (source package name) libjs-prototype (binary package name) http://packages.debian.org/search?keywords=prototypejs&searchon=sourcenames&suite=testing§ion=all | 20:15 |
| awmcclain | ScottK: Ha. Well. That's the other thing. There aren't really upstream releases at this point. For ubuntu, at least, I've been marking things as perlbal-0.70-1ubuntu1, but the real question is what to check into the "master" debian dir in VCS... perlbal-0.70-1 or perlbal-0.70 | 20:16 |
| awmcclain | eep | 20:16 |
| awmcclain | should read | 20:17 |
| awmcclain | "things as perlbal-0.70+svnXXX-1ubuntu1..." | 20:17 |
| awmcclain | Since upstream has gotten lazy doing point releases | 20:17 |
| ScottK | awmcclain: 0.70. The +svn is a problem though | 20:17 |
| ScottK | If 0.70 is the next release, please do 0.70~svnxxx | 20:18 |
| ScottK | 0.70+svn is a higher version number than 0.70 and that's not what you want. | 20:18 |
| ion_ | Anyone feel like reviewing http://revu.tauware.de/details.py?package=compcache-setup? Thanks. | 20:19 |
| awmcclain | Hrm. That was the intention, since the svn release is more stable than the point release. | 20:19 |
| ion_ | If it’s an older snapshot than 0.70, it should be called 0.70~svnfoo. If it’s a newer snapshot than 0.70, 0.70+svnfoo is ok. | 20:20 |
| awmcclain | ion_: That's correct. Ah.. the NEXT version would be .71 or 0.80 | 20:24 |
| ScottK | awmcclain: Ah. Yes. That's fine then. | 20:27 |
| awmcclain | Ok. Phew. | 20:27 |
| porthose | in debian/control in the depends field do you use the source package name or the binary package name ie prototype.js (source package name) libjs-prototype (binary package name) | 20:30 |
| ScottK | porthose: For depends use binary. | 20:30 |
| porthose | ScottK: thx | 20:30 |
| === emgent_ is now known as emgent | ||
| apachelogger | RainCT: *poke* apparently uploads with "-" can't be viewed on revu | 20:59 |
| apachelogger | e.g. http://revu.ubuntuwire.com/details.py?package=plasmoid-flickr | 21:00 |
| RainCT | apachelogger: oh. is this new or did it already fail before? | 21:02 |
| apachelogger | RainCT: considerable new I reviewed plasmoid-qalculate just a couple of minutes ago | 21:02 |
| ion_ | An hour ago, it worked. | 21:03 |
| * RainCT is looking into it | 21:06 | |
| RainCT | apachelogger, ion_: it'll be working agian in 2 minutes | 21:12 |
| apachelogger | hooray | 21:12 |
| ion_ | Thanks | 21:12 |
| RainCT | works now | 21:13 |
| === fta_ is now known as fta | ||
| apachelogger | RainCT: thank you | 21:15 |
| ion_ | http://revu.ubuntuwire.com/merge.py: NameError: global name 'User' is not defined | 21:16 |
| ion_ | File "/srv/revu-production/merge.py", line 130, in index | 21:16 |
| ion_ | u = User.User(s['nickname'], s['openid'], c) | 21:16 |
| ion_ | Someone forgot to run the unit tests before pushing new code to production? :-) | 21:17 |
| NCommander | ion_, looks like it | 21:25 |
| NCommander | ion_, I can mark your account MOTU if needed | 21:26 |
| tacone | ScottK: may I private message you for 5 seconds ? | 21:27 |
| ion_ | ncommander: I’m not a MOTU. ;-) | 21:29 |
| RainCT | I *knew* that I had forgotten to test something :) | 21:30 |
| ion_ | You could automate the verification of the test suite before the pushing happens. :-) | 21:30 |
| RainCT | ion_: there's no test suit :) | 21:31 |
| ion_ | ouch | 21:31 |
| NCommander | ion_, I've never seen a test suite for a web based application ;-) | 21:31 |
| ion_ | Funny | 21:31 |
| tacone | NCommander: they do exist :) | 21:32 |
| NCommander | tacone, recommend one to RainCT then ;-) | 21:32 |
| ion_ | “Recommend one”? You write one. :-) | 21:33 |
| RainCT | ion_++ | 21:33 |
| RainCT | ;) | 21:33 |
| tacone | While selenium is what seems the right choice to test a web interface, I'd just recommend to at least implement unittesting on the underlined libraries. That would help a lot, even if total coverage is not achieved. | 21:34 |
| tacone | If you find your webapplication is difficult to be unit tested, maybe you need some refactoring. Unit testing is hard, even if testers say it's not. | 21:34 |
| RainCT | tacone: patches are welcome | 21:35 |
| NCommander | ;-) | 21:35 |
| tacone | RainCT: I have plenty of things to be patched. You patch mine, I'll patch yours :) | 21:36 |
| NCommander | RainCT, at some point I'm going to need your help testing the PPA uploader scripts | 21:36 |
| NCommander | RainCT, we don't want a repeat of breaking REVU like we did with OpenID :-) | 21:36 |
| tacone | RainCT: I am not saying it's a mistake not to unit test, but I disagree with NCommander, unit testing is possibile on a web application :-) | 21:37 |
| NCommander | tacone, I didn't say it wasn't a bad thing, I've just never seen one for a web based application | 21:37 |
| RainCT | possibility is one thing, priority another :) | 21:37 |
| tacone | NCommander: just ask RainCT to write one to show you :) | 21:37 |
| * NCommander thinks RainCT would love PyUnit ;-) | 21:38 | |
| NCommander | argh *attempts to remember joins* | 21:39 |
| RainCT | NCommander: ''.join(list) | 21:39 |
| RainCT | if that's what you mean | 21:39 |
| NCommander | RainCT, SQL joins | 21:39 |
| RainCT | ah ok | 21:40 |
| NCommander | RainCT, at least it won't be the EVIL query from index.py | 21:40 |
| NCommander | (that's got to be one of the biggest SQL queries I've ever seen) | 21:40 |
| NCommander | ^in a web app | 21:40 |
| RainCT | yeah that one is really evil | 21:40 |
| RainCT | NCommander: you're pessimistic... s/Forgot Password/Recover Password ;) | 21:41 |
| RainCT | :P | 21:41 |
| NCommander | Four subselects | 21:41 |
| NCommander | There has got to be a better way to write that query | 21:41 |
| NCommander | RainCT, you know, I'm so happy psql has readline support; I remember when I didn't ... | 21:45 |
| NCommander | *It | 21:46 |
| RainCT | NCommander: for programs that haven't, rlwrap is your friend :) | 21:46 |
| NCommander | Oooh, handy | 21:47 |
| * RainCT has lots of aliases with it in his bashrc | 21:47 | |
| NCommander | BTW, I think I wrote one of the best comments ever in this script | 21:47 |
| NCommander | # Ok, first create a lock file so we don't crash into | 21:47 |
| NCommander | # ourselves. | 21:47 |
| NCommander | # FIXME: Implement lockfile ;-) | 21:47 |
| === _neversfelde is now known as neversfelde | ||
| RainCT | bbl | 21:50 |
| NCommander | rofl, https://bugzilla.mozilla.org/show_bug.cgi?id=448604 | 21:59 |
| ubottu | Mozilla bug 448604 in Facilities Management "Can't get out of Whistler" [Blocker,New] | 21:59 |
| === chuck_ is now known as zul | ||
| RainCT | re | 22:07 |
| RainCT | ion_: it *may* work now | 22:31 |
| RainCT | and it's more beautiful than before :P | 22:32 |
| tacone | if they ran ubuntu they could have just apt-get removed any obstacle | 22:33 |
| ion_ | rainct: Thanks, it did. | 22:33 |
| RainCT | :) | 22:33 |
| Laney | With a package not in Debian, the XSBC-Original-Maintainer should be the initial debianiser, right? | 22:42 |
| Laney | or can it be left out? | 22:42 |
| emgent | oh Laney. | 22:44 |
| Laney | emgent: Huh? | 22:44 |
| emgent | First to work in all packages, please ask to last uploader. | 22:44 |
| Laney | I didn't think that was a requirement | 22:44 |
| emgent | YES it`s! | 22:45 |
| Laney | (except for merges/sync before DIF) | 22:45 |
| Laney | hmm | 22:45 |
| wgrant | emgent: It's not a requirement unless you're merging/syncing. | 22:45 |
| emgent | Laney: you worked in xdigger, and totopalma was the last uploader.. him like work in this package, and you dont asked. | 22:45 |
| SolarWar | if you're package is in the revu queue at the moment, is it likely it will make it into Intrepid? Providing that your package has fairly few faults? | 22:45 |
| wgrant | It is a good idea if they are a regular uploader, though. | 22:45 |
| wgrant | SolarWar: Depends if you can get it uploaded within 2 weeks. | 22:46 |
| emgent | Laney: anyway _please_ ask first. ok? | 22:46 |
| emgent | heya wgrant :) | 22:47 |
| SolarWar | wgrant, I was under the impression that once you've put the package into revu you had uploaded- could you elaborate on the process? | 22:47 |
| emgent | Laney: ? | 22:48 |
| wgrant | SolarWar: You have to ask MOTU to review it. Once you have convinced two people that your package is good enough, it will be uploaded to Ubuntu. | 22:48 |
| Laney | emgent: I saw some mail on one of the MLs saying that as we were approaching DIF, we should drop that requirement | 22:48 |
| Laney | ...and he didn't complain until about a month after I'd done the merge anyway, so I might argue that the merge would have been very late | 22:48 |
| Laney | But if you really want me to ask before I make any change I will...... | 22:49 |
| Laney | even though this isn't something I see people doing. | 22:49 |
| wgrant | Laney: You don't have to. I tend to only do it if they are obviously a regular maintainer. | 22:49 |
| Laney | wgrant: Yes, I do too. | 22:49 |
| Laney | I certainly don't expect people to ask it of me | 22:49 |
| wgrant | Hi emgent. | 22:49 |
| Laney | emgent: If you want this as a policy, perhaps you should raise it on u-d-d | 22:50 |
| SolarWar | wgrant, and the cut off date is two weeks from today? | 22:51 |
| RainCT | SolarWar: yep | 22:51 |
| SolarWar | oh man | 22:52 |
| RainCT | SolarWar: https://wiki.ubuntu.com/IntrepidReleaseSchedule - Feature Freeze is on 28th August | 22:52 |
| emgent | Laney: the human road is: "if you like work in this package, you are wellcome.. but first ask to last uploader." | 22:52 |
| SolarWar | isn't that four weeks? | 22:52 |
| RainCT | so it's one month rather | 22:52 |
| emgent | s/wellcome/welcome/ | 22:52 |
| SolarWar | oh okay | 22:52 |
| SolarWar | i got a little stressed out :) | 22:52 |
| RainCT | (after that date you'd need a Feature Freeze Exception, which needs a good reason :)) | 22:53 |
| emgent | anyway no problem. but in the future first to work in other packages, please ask to last upload. Thanks. | 22:53 |
| emgent | s/upload/uploader/ | 22:53 |
| * RainCT doesn't think that's a requirement, neither | 22:54 | |
| Laney | Well I guess it depends on whether you see making a change in a package as claiming some sort of ownership over it | 22:54 |
| Laney | I personally don't | 22:54 |
| wgrant | RainCT, SolarWar: The 28th is the freeze for it being accepted. It has to be somewhat before that to get through NEW, and it's always nice to have some buffer to resolve issues that could get it rejected. | 22:55 |
| emgent | anyway we should decide one policy aout that. i will write on u-d-d ml. | 22:56 |
| wgrant | You want to upload at least a week before that, probably two. | 22:56 |
| wgrant | emgent: We're Ubuntu. TIL isn't strong. One doesn't have to ask the last uploader. | 22:56 |
| * RainCT is looking for someone to review http://revu.ubuntuwire.com/details.py?package=julius, btw | 22:57 | |
| SolarWar | ohh | 23:00 |
| * RainCT glances at SolarWar :P | 23:01 | |
| * SolarWar won't be asking people to review his package for a while | 23:02 | |
| SolarWar | :P | 23:02 |
| RainCT | SolarWar: uhm.. why not? | 23:02 |
| SolarWar | i was a little to insistent earlier this week :) | 23:03 |
| directhex | urgh, sound-juicer segfaults :/ | 23:07 |
| SolarWar | i've been telling people for years- theres /no/ way you can extract sound juice. | 23:08 |
| Jazzva | Hmm, getting an error on REVU when trying to open a package http://revu.ubuntuwire.org/details.py?package=sphinxbase ... Any REVU devs around :)? | 23:12 |
| RainCT | Jazzva: lol.. I'm looking at that right now | 23:12 |
| Jazzva | heh :)... good that someone noticed:) | 23:13 |
| Jazzva | Thanks, RainCT | 23:13 |
| ion_ | Btw, please make a redirect from revu.tauware.de to revu.ubuntuwire.com or vice-versa. :-) | 23:13 |
| Jazzva | RainCT, yay. Thanks for making it work :) | 23:14 |
| Jazzva | BTW, if anyone is feeling like doing a review, both pocketsphinx and sphinxbase packages are corrected and on REVU :) | 23:15 |
| RainCT | np. someone had send a comment with evil encoding :P | 23:15 |
| Jazzva | heh | 23:15 |
| Jazzva | I'm innocent :) | 23:15 |
| RainCT | uhm.. I think I'll catch the exception to replace evil stuff with a placeholder message, so that a single comment can't break a complete page | 23:16 |
| RainCT | Jazzva: it was an UnicodeError, right? | 23:17 |
| Jazzva | I don't remember | 23:18 |
| ion_ | rainct: How about validating the input in the first place? :-P | 23:19 |
| RainCT | Laney: you're bug report is a dupe! ;P | 23:23 |
| Laney | RainCT: :O | 23:24 |
| RainCT | uhm.. Or at least it has been in our TODO for a while | 23:24 |
| Laney | I just looked at the titles of currently open bugs | 23:24 |
| Laney | Ah, then confirm it ;) | 23:24 |
| Laney | (LP: #x, #y) works for multiple bugs, right? | 23:25 |
| RainCT | I may implement it one of those days, btw. It should be quite easy to do now because of the changes we've done those last days. | 23:25 |
| RainCT | Laney: yep | 23:25 |
| Laney | RainCT: Cool. I might have a look at the source and see if I can do it if it won't be that bad | 23:26 |
| wgrant | ion_: It redirects now. | 23:28 |
| RainCT | Laney: it's basically a two lines fix | 23:29 |
| Laney | :D | 23:29 |
| RainCT | Laney: replacing the redirect to index.py in launchpad_login.py with a redirect to the referring address | 23:29 |
| ion_ | wgrant: Cool | 23:29 |
| Laney | RainCT: Is lp_login.py where the user lands after finishing on LP? | 23:30 |
| Laney | Won't the referrer be lp.net then? | 23:30 |
| RainCT | Laney: yes, launchpad_login.py redirect the user to LP and LP redirect him back to launchpad_login.py | 23:31 |
| Laney | Unless you mean to store the referring url in the session - I guess that could work | 23:34 |
| Laney | anyway, must be off. Night all | 23:34 |
| RainCT | right | 23:35 |
| RainCT | Laney: good night | 23:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
