[00:15] I want to get involved with MOTU...is there anywhere I should look at beside the topic link? [00:20] jonfore_, you might want to check out https://wiki.ubuntu.com/MOTU/GettingStarted , in case you haven't already [00:24] Jazzva: yep I've been checking it out. So I should learn how to package? [00:25] 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] jonfore_, you can take a look at the bugs that're easy to fix (bitesize) [00:26] And find something you can work on. [00:26] ok cool [00:26] thanks [00:26] No problem [00:27] Is there mentoring through MOTU? [00:27] yes [00:28] jonfore_, http://tinyurl.com/5vp5g8 is the list of all bugs that are tagged with "bitesize" [00:29] jonfore_, for mentoring check https://wiki.ubuntu.com/MOTU/Mentoring [04:00] cody-somerville: -1 for top posting. -1 for one-line with big quote. :p [04:00] I knew I'd get that. [04:02] I kind of over shot on doing my 5 today. I filed 8 bugs. [04:02] Oh, wait. That was supposed to be about fixing, not filing, right? [04:02] ScottK: Is 5-a-day really about filing :) [04:02] ;-) [04:03] I [04:03] 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] I'm not even counting the Launchpad bugs. [04:03] LP bugs don't count for 5-a-day anyway. [04:03] I'm pretty sure filing 5 new bugs a day is a 5-a-day anti-pattern :P [04:03] They were mostly syncs, so they'll be gone soon enough. [04:04] Launchpad bugs are like catching fish in a barrell anyway. [04:04] LP: feed's on [04:04] Such negativity is not conducive to positivity :P [04:05] 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] persia, I agree [04:06] 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] Nothing wrong with filing bugs :) [04:06] I tend to find that LP bugs get triaged faster when you file a dozen in 20 minutes. [04:07] ScottK: 5-a-day is about bugs, being filing, fixing, commenting, triaging, etc... [04:07] hi all! [04:07] nxvl, well thank you for that informative clarification ;] [04:08] * ajmitch starts up his automated bug filer [04:08] ajmitch: Which one? [04:08] persia: oh /dev/random should do [04:09] * persia thought ajmitch had a selection of useful automatd bug filers [04:09] * ajmitch doesn't have useful stuff [04:10] Bah. RCbugs is direct counter-evidence. More could be found. [04:11] * ajmitch is having too much fun doing silly things in python [04:12] ajmitch: What kind of silly things? [04:12] Bug filer based on MegaHAL, perhaps [04:14] wgrant: just playing around with creating types at runtime, some introspection, etc [04:14] nothing particularly useful yet [04:14] ion_: I like that idea. I wonder what triagers would think when it responded to them. [04:14] ajmitch: That's always fun. [04:30] anyone working on any cool projects? [04:30] No, sorry [04:31] Nope [04:31] so ion, you don't think anyone is working on anything cool? [04:31] Indeed. [04:31] indubidably [04:32] I am going to go play a game then === ubuntu_ is now known as foxjazz [04:33] see you all! [04:33] foxjazz: Can you define cool? [04:33] sure, anything that has to do with communication (net working) [04:34] or vr gaming [04:36] Gah! The fuzzy fonts in OpenJDK Swing! It burns! [04:37] foxjazz: Well, there's a bit of gaming work that could be done. [04:38] foxjazz: You might look in Section;games in your package manager, and see if anything there interests you. [04:39] LucidFox: I believe there is a new swt-gtk that ought fix that: see bug #249158: needs testing and history investigation. [04:39] 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:40] (Mind you, if someone wanted to write up some swt-qt bindings, that would be nifty) [04:40] persia> Swing, not SWT [04:40] Fonts in SWT are OK, because SWT is just a wrapper around system widget toolkits [04:41] Oh. I (mistakenly) conflated the two. Re-education in progress... [04:44] Ah. SWT is IBM's reimplementation of Swing for Eclipse, but completely different. Sometimes I love Java. [04:45] too many memory leaks in java [04:45] SWT uses a different philosophy from Swing [04:45] so they're not really comparable [04:45] Swing only uses the platform's window system and draws the widgets itself [04:46] whereas SWT uses platform widgets, such as Win32 standard controls, or GTK under Linux [04:47] This is why, for example, Eclipse looks native on every platform while the Java Control Panel does not [04:48] foxjazz: less memory leaks in java than most C programs :) [04:48] heh no argument there [04:49] I prefer c# [04:49] 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] Yes, both are widget toolkits [04:50] At least according to the IBM article I read, they also have feature parity, just completely different ways of being used. [04:50] I personally prefer Qt Jambi to both :) [04:50] heh [04:54] Stupid upstream... their versioning scheme confuses uscan [04:54] BrowserLauncher2-all-11.jar [04:54] BrowserLauncher2-all-12.jar [04:54] BrowserLauncher2-all-1_3.jar [04:54] these are supposed to be 1.1, 1.2 and 1.3 : [04:56] uversionmangle=s/^([0-9])_?([0-9])$/$1.$2/ [05:04] ion_: The trick is knowing that they might introduce an underscore in advance of the release :p [05:05] persia: :-) [05:24] how do you find the code for gaim? [05:25] debcheckout gaim [05:26] Except that Gaim ceased to exist some time ago. [05:26] lifeless is that a bash command [05:26] what about Kopete [05:29] lifeless: Note that pidgin also doesn't have Vcs-* fields ... [05:29] (Except when I run the right package analysis command) [05:29] persia how do you use debcheckout? [05:29] foxjazz: I don't. [05:30] oh [05:30] I want to look at source for Kopete [05:30] how do I do that [05:30] apt-get source kopete [05:31] says it failed [05:32] I'd then advise you to fix the issue mentioned in the failure message. [05:33] dpkg-source: not found [05:33] Install dpkg-dev [05:35] install command not found [05:38] foxjazz: sudo apt-get install dpkg-dev [05:48] I finally got the source for kopete now what [05:49] foxjazz: What do want to do with kopete? [06:03] well I want to look at the sorce [06:03] source code persia [06:05] Then look at it. [06:06] 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:09] well it created a folder called dkenetwork-3.5.8 [06:09] and the only source code viewer I have now is geany [06:10] persia there is no project file to open [06:11] foxjazz: Ah. RIght. Kopete doesn't have it's own package. What do you see in the kdenetwork-3.5.8 folder? [06:11] kopote is in there [06:11] s/it's/its/ [06:11] huh [06:12] what's a "good" dev environment? [06:12] foxjazz: I tend to use terminals and vi. [06:13] well I am spoiled with vistual studio [06:13] visual* [06:14] It depends on what upstream uses. Some packages have project files for various IDEs included in the source. Others do not. === Igorot is now known as Knightlust [06:14] what's .svgz [06:14] 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:15] looking at it through geany now, geany is really nice I think [07:39] foxjazz, geany works very well for some languages indeed [07:39] it's my favorite to use for python [09:16] Can a Motu take a look at http://revu.ubuntuwire.com/details.py?package=plasmoid-teacooker please? [09:21] 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:23] persia: so I have to creat a bug-report for new Upstream Release? oO [09:28] Wubbbi: That is how they are usually processed. [09:28] ok [09:28] Wubbbi: Don't forget to review any open bug reports against the package to see if the new upstream release closes them. [09:32] hi folks [09:37] morning everyone [09:37] hey sistpoty|work [09:37] hi huats [09:38] 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] Hey sistpoty, huats. [09:38] hi Iulian [09:40] Wubbbi: Subscribe the sponsors queue, and wait for a sponsor [09:40] hi Iulian [09:53] persia: https://bugs.launchpad.net/ubuntu/+bug/253563 good like this? [09:53] Launchpad bug 253563 in ubuntu "[ New Upstream Release ] Plasmoid Teacooker 0.3.0" [Undecided,New] [09:56] Wubbbi: Precisely like that. Now it goes into the queue, and someone ought upload it. [10:11] persia: and the Revu upload is not is necessary? [10:14] Wubbbi: RIght. The diff.gz ought have everything needed. The watch file does work, doesn't it? [10:15] persia: what watch file? oO [10:16] I dont have a watch file [10:16] Wubbbi: Ah. You'll want one of those. man uscan for details [10:20] 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:21] I cant set the (.*) because no version is given xD [10:21] 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] Wubbbi: Well, complain to upstream about that: they should provide a version. [10:22] Wubbbi: In this case, you'll want to implement a get-orig-source rule. [10:22] Iulian: seems like you're missing the second "." in the version number [10:22] persia: omg ... why cant I upload the hole program? Like I have done it on the Initial Release? oO [10:22] Iulian: You've missed the 'x'? [10:22] huhu sistpoty|work [10:23] hi sebner [10:23] 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:24] Hobbsee: ping [10:24] Oh, is this correct - http://sf.net/salasaga/salasaga-([0-9]+\.[0-9]+\.[02468])\.tar\.bz2 ? [10:25] Iulian: that however would match 0.7.2 for example, but I thought you'd want the 02468 as second digit, right? [10:25] 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:26] Iulian: Try ([0-9]+\.[02468]+\,[0-9]+) [10:26] sistpoty|work: Well, all I want to do is to avoid development versions. [10:26] persia: Will try [10:27] Iulian: persia's version looks right at least if you s/,/./ :P [10:27] Yea, sure :) [10:28] * persia is still learning to use a new keyboard, and doesn't have all the positions encoded in the forearms yet [10:28] no matching hrefs for watch line [10:28] http://sf.net/salasaga/salasaga-([0-9]+\.[02468]+\.[0-9]+)\.tar\.bz2 [10:28] Hmm, be right back - lunch. [10:30] persia: how to make a .deb to the source again? [10:33] 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] persia: ufff ok [10:33] Iulian: What is the specific URL you want to match? [10:33] thx 4 info [10:41] persia: This is the url from where you can download the source - http://sourceforge.net/project/platformdownload.php?group_id=58083 [10:44] persia: Maybe we forgot the .alpha part? [10:45] persia: Upstream will release in a few weeks alpha4. [10:49] Iulian: Yep. Looks like you want ([0-9]+\.[02468]+\.[a-z-9\.]+).tar.bz2 [10:51] persia: Bleah, still doesn't work... [10:53] Iulian: Because I forgot to type the character '0' or because of something else? [10:54] Right, it's working. [10:54] 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:55] persia: I'll use this watch file for now. [10:57] 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] And you'll want dversion mangle to drop the associated ~alpha :) [10:58] Of course, this may well break when they release beta or final... [11:01] persia: Yes, indeed, it will download the .alpha version, although I have renamed it to ~alpha. [11:01] persia: So, I want that dversion mangle thingie. [11:01] persia: Let me have a look at the man page again. [11:01] Iulian: It's for precisely this sort of thing that uversionmangle and dversionmangle exist. [11:04] persia: In the man page of uscan says 'opts=dversionmangle=s/\.dfsg\.\d+$// \'. I'm not sure how to use that. [11:04] persia: I think I will have to change .dfsg with .alpha but I've not idea what d+ is for. [11:05] Uhh, I have never understood the watch file. [11:05] Iulian: \d is a short way to type [0-9] [11:06] persia: And the dollar sign? [11:06] So you could write the other example as (\d+\.[02468]+... [11:06] $ is end of string [11:07] So that matches e.g. ".dfsg4" [11:08] Ah-ha [11:08] (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:09] So, how do I rename the dot from alpha to a tilde? [11:10] In the end, that's what I want, to match ~ instead of . [11:11] Btw, I will mail upstream to use tilde instead of dot in the versioning scheme. [11:12] Iulian: Upstream should be fine using '.'. It's fairly normal for upstreams to do that. [11:13] It's pretty odd. [11:13] Why? [11:13] * persia sees it not infrequently, similar to e.g. 0.6rc4 [11:14] 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] IMHO, it's pretty confusing to use that versioning scheme. [11:14] Just because it doesn't ASCII-sort? Most people don't think in ASCII. [11:15] Ah, right. [11:17] When packaging something it's not indicated to use e.g. 0.1.0.alpha1, right? [11:18] 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:22] persia: Is it ok to leave it as it is? [11:22] persia: I mean, to use the dot instead of tilde in the changelog. [11:23] is fuse.gvfs mount in / or in /home? [11:23] 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:27] please see http://fileland.bugabundo.net/temp/Screenshot-SystemMonitor.png [11:28] persia: Hmm ok. Do you think I should leave the watch file as it is? [11:28] persia: Because as far as I can see, there is no way. [11:28] Iulian: I think it may make sense to step back a bit: why do we want alpha4 in the repos? [11:30] (The way is to uversionmangle and dversionmangle to a common base: perhaps something like /\.[a-z]+(\d+)/.\1/ for uversionmangle. [11:34] persia: It's alpha 3 actually, alpha 4 will be released in a few weeks. [11:34] Iulian: Still why this version? [11:35] Is it not better to work with upstream to hasten the release, and package that? [11:35] persia: Upstream would like to fix some issues before releasing a new version. [11:36] Right. Presumably we'd like those issues to be fixed before pushing it to all the users, as well, no? [11:39] persia: That will be 0.8.0 but alpha4. That's not a big issue for users to stop using it. [11:40] persia: And like I said it will be released in a few weeks so that won't be a problem. [11:40] Iulian: To ask differently, what is so important about 0.8.0 that it is worth preparing an upload for alpha3? [11:40] 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:41] 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] Are there lots of rdependencies that need porting, and starting now makes that easier? [11:41] (Almost any reason would be acceptable, but there ought be some reason to take on the maintenance hassle that is an alpha release) [11:46] 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] persia: + some bug fixes. [11:46] Iulian: tell upstream that they have got the definition of alpha wrong [11:47] Iulian: Instead of packaging alpha, why not backport bug fixes to current version in intrepid? [11:47] Iulian: Do you expect a 0.8.0 final by end of August? [11:48] persia: I don't know, will have to mail upstream. [11:49] Btw, I'm packaging it for Debian, there is not version in Intrepid. [11:49] I like to get it in Debian first and then request a sync. [11:50] 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:51] persia: It will get in unstable, right? [11:51] persia: Lenny is still testing. [11:51] Iulian: Maybe. Depends on the sponsor. Some people won't be uploading to unstable when the know it may not make lenny. [11:52] when is teh freeze for lenny? [11:52] slytherin: It's already frozen, if I'm not wrong. [11:52] Iulian: http://lists.debian.org/debian-devel-announce/2008/07/msg00007.html makes my think it's frozen. [11:52] persia: Since Vincent already replied to my RFS I think he will upload it. [11:53] :-( [11:53] 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:54] 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] Alternately just dversionmangle s/~/./ [11:54] I'm only subscribed to debian-devel but I will subscribe to d-d-a, thanks for telling. [11:54] persia: Ok, will try to use that. === Ekushey_ is now known as Ekushey [12:06] persia: http://iulian.devzero.co.uk/tmp/watch [12:06] persia: It's ok now, thanks a lot. [12:08] Huh, I just learnt more about these watch files ;-) [12:08] Iulian: Excellent :) Nice job. [12:08] Iulian: Would you like to use your newfound knowledge to do some more watch files? [12:10] 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] Brb - phone [12:12] * Iulian is back. [12:20] Hi, I'm going to make a package with pastebin-like service script, any chances that it will be included in repository? [12:20] 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:21] These are my dpkg contents: http://iulian.devzero.co.uk/tmp/contents. No idea why I get those warnings... === ember_ is now known as ember [12:21] Quintasan: I think there is already a package in the repo like that one. [12:23] yep, pastebinit [12:23] Quintasan: https://edge.launchpad.net/ubuntu/+source/pastebinit [12:23] sistpoty :P [12:24] Iulian: ok, thanks :) [12:27] I thought pastebinit was a pastebin client. Do we also have a pastebin server? [12:29] no idea... I interpreted pastebin-like service script as client *shrug* [12:30] 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] I meant script as a client :P [12:30] persia: not if it's written in php :P [12:32] sistpoty|work: I meant a good one :p [12:32] *g* [12:32] Quintasan: There are actually several clients available. aptitude search paste ought get you a base list [12:33] 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:34] I seem to remember a plugin for some editor as well [12:41] norsetto: hello my friend ! [12:41] huats: hey! [12:41] hey persia too ! [12:53] * norsetto <-- food [12:53] Is it ok to move the manual pages to the -common package? [12:53] Iulian: assuming you depend on it: yes [13:11] i have trouble finding newbie tasks to take care of [13:12] !bitesize | perhaps? [13:12] stefanlsd: What soft of tasks do you like? [13:12] 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:13] Some stuff that doesn't usually get bugs, but needs doing include: missing manpages, watch files, dependency analysis, .desktop file review, etc. [13:13] 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:14] 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] stefanlsd: Well then, how about watch files. Small changes, easy to test, and lots to choose from. [13:15] 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] 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:16] stefanlsd: You may also find the uscan manual page helpful. [13:16] thanks :) [13:17] 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:18] persia: thanks. good idea. will do [13:18] stefanlsd: Good luck, and when you get bored with watch files, ask for something else :) [13:20] persia: kk. thanks. will do. How often is the html for qa.ubuntuwire.com/no_watch updated? [13:20] I think it's every six hours or so, but maybe wgrant could answer with more precision. [13:20] persia: would I follow the process of choosing a package and then logging a LP bug against my work? [13:22] 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:24] 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:26] heh. never new about watch files. they are pretty clever... [13:30] Could someone please archive gtkmm-utils package on revu? [13:31] 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:32] norsetto: if I am not attending the meeting, please ping me :) [13:32] I am a bit busy some I might forget the time... [13:32] huats: will do [13:32] norsetto: thanks :) [13:32] was the pasteque good ? [13:32] 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] huats: excelletn ;-) [13:33] It seems rather scattershot to me. This is more comprehensive. [13:34] :) [13:34] 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] o/ ScottK [13:34] ScottK: ooh. ok. Thanks. I'm gonna try grab a package without a watch file and see how i manage. [13:45] is anyone familiar with the gambas2 package ? Are the examples supposed to run ? [14:10] 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] s/review/revu [14:12] kdubois: see https://wiki.ubuntu.com/IntrepidReleaseSchedule, the deadline for new packages is FeatureFreeze [14:14] hmm, so if i understand this correctly, up to august 28th, its possible to get new packages in the universe? [14:14] yeah [14:17] kdubois: Just to be safe, while 28th August is the absolute deadline, 14th August is a safer guideline for general use [14:18] That gives a couple weeks for review cycles, fixing things, etc. [14:19] and how can i know what still needs repackaging for intrepid? [14:22] kdubois: For new packages, you can look at bugs with the needs-packaging tag. For new upstreams, you can use the watch files. [14:24] http://qa.ubuntuwire.com/uehs/no_updated.html and https://launchpad.net/ubuntu/+bugs?field.tag=needs-packaging [14:48] Hi. Could someone review sphinxbase at REVU ? Thanks :) [14:49] 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:50] kdubois, as far as I know, you can safely ignore the warning. [14:50] kdubois: you can ignore that warning. Also the make sure the standards is 3.8.0 [14:51] tuxmaniac: Do we say 3.8.0 or 3.8.0.1 as the actual lastest standards? [14:51] 3.8.0 is preferred. [14:53] ScottK: kk. Thanks. [14:53] 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:54] 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:55] so i uploaded to revu, but it doesnt show up yet. is there some latency between upload, and seeing it on the site? [14:56] 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:57] 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:58] 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] persia: ok. When does the decision (if ever) to drop the package from universe happen? [14:58] stefanlsd: I was going to suggest if upstream is dead and there are alternatives available consider asking for removal. [14:58] persia: ok, i logged in and tried it again. it looked like it worked, i guess we'll see in 10 minutes [14:58] nhandler: Right. Thi is different than the wiki :) [14:59] stefanlsd: If it's removed from Debian, we remove it semi-automatically. Otherwise it's when someone notices and suggests it. [14:59] Do we have anyway to track userstats - like how many people have apt-get (ed) it? [14:59] 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. [15:00] 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] nhandler: Good idea. Maybe you're up for that? [15:00] persia: I haven't done much wiki work in the past, but I could probably give it a try later today. [15:01] 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] ping huats [15:02] norsetto: pog [15:02] pong [15:02] huats: meeting [15:07] thanks for all the help so far. bbl [15:07] persia: It looks like RainCT took care of updating the REVU wiki page after the update. [15:07] * persia looks again, confused [15:23] hey ho [15:23] i am Alexander [15:24] i had package something, could some one review it? that would be realy great [15:24] here the links http://revu.ubuntuwire.com/details.py?package=digikam-kde4 http://revu.ubuntuwire.com/details.py?package=rubberband [15:24] thx [15:27] moin [15:34] moin emgent [15:46] <[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:52] [GuS]: I think fix the lib is the answer (as I already mentioned on #kubuntu-devel). [15:59] [GuS]: also you don't really want to disable dkpg-shlibdeps... can you pastebin the error messages? [16:00] <[GuS]> sistpoty|work: sure [16:01] <[GuS]> sistpoty|work: http://pastebin.com/m30619d0f [16:04] [GuS]: that's a bug in the phonon package, which doesn't ship an shlibs file. [16:05] <[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:06] <[GuS]> theres is no Qt phonon in repositories to install [16:06] [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:07] <[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:08] [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:09] <[GuS]> sistpoty|work: but that phonon comes from kde if i am not wrong... [16:09] <[GuS]> (of that bug report) [16:10] <[GuS]> mm... [16:10] [GuS]: so you don't have the libphonon-dev package installed but use your own version? [16:11] <[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:12] [GuS]: so you have built your own qt4 debs with phonon enabled and then get this error? [16:13] <[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:14] <[GuS]> i have no make errors, that is what i mean [16:14] [GuS]: and are you putting the resulting files in the correct packages? (libphonon[SONAME], libphonon-dev?) [16:15] [GuS]: otherwise debhelper won't find the info for the shared libraries resulting from the build itself [16:15] <[GuS]> mmmm [16:16] <[GuS]> seems i need more skills bulding a package... (indeed never had this problem..) [16:18] [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:19] <[GuS]> is why i am trying to build the package [16:27] * sistpoty|work heads home... cya [16:29] <[GuS]> damn... this is to much for just build the package of a lib... i dont want to become pro MOTU :S [16:39] 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:41] kdubois: did you check comments? [16:42] comments on revu? yes, i corrected the issues the reviewer found, and am trying to resubmit [16:42] kdubois: so what is the problem? Did you not reupload the package? [16:43] i tried to with dput, and it looks like it did it, but nothing happened [16:43] i.e. my command looks like it worked on my machine, but the site isn't updating [16:43] kdubois: what command did you fire? [16:44] dput revu tv-grab-dvb_0.9-1_i386.changes [16:44] kdubois: you need to use dput -f when uploading second time. [16:44] you need to upload a source, too [16:44] launchpad doesn't accept binaries. [16:44] kdubois: which means force the upload even if same version is alreayd available on revu [16:45] neither does revu [16:45] kdubois: yes, you need to upload source.changes file [16:46]