=== asac__ is now known as asac === gnomefre1k is now known as gnomefreak === RoAk is now known as RoAkSoAx [00:51] nixternal, around? === pgquiles__ is now known as pgquiles === Martinp24 is now known as Martinp23 [01:02] Jazzva: regarding autoreconf patches: yes, they tend to be huge, but you can make them smaller by running the same autoconf/automake/intltoolize... versions as upstream did [01:02] Jazzva: but that's ok, thanks for the debdiff! [01:03] pochu: No problem... I noticed I missed one change - to add to lintian-overrides that it depends on quilt 0.40-1, lintian produces one warning for depending on -1. [01:04] pochu: So, I'll just add that and upload new patches... to reduce the upload, do you need diffs with or without .po files :)? [01:04] Jazzva: can't you depend on 0.40? === asac_ is now known as asac [01:04] without the -1 [01:04] Jazzva: and regarding the po changes from MoM... always remove them [01:05] pochu: It's introduced in debian, I know I saw a log why it has to depend on -1 [01:06] Jazzva: ok, live it anyway, that's just a warning and we don't want to add more useless diff [01:06] pochu: Ok... [01:08] pochu: Tracker merge seems to be a lot easier ... just to remove some Debian deps we don't use (qdbm), and to check if we still need patches from debian/patches... [01:08] yup [01:09] Jazzva: you will likely need all of them, as Debian has 0.6.6 too [01:12] pochu: Yep... Just checked. I'll do a testbuild and upload the diffs... [01:14] Jazzva: wait, I'm reviewing it [01:21] Jazzva: looks fine, just make the changelog entry a bit more verbose (mention what files you have removed, that we don't build a liferea-webkit package...) [01:21] Jazzva: feel free to copy&paste from older changelog entries for the remaining changes if you want ;) [01:21] Jazzva: but other than that the merge looks perfect, I'd sponsor it if I could :-) [01:23] pochu: Thanks :)... I'll prepare a new patch and subscribe sponsors. === asac_ is now known as asac [02:34] pochu: Uploading new debdiffs. I'll be off when it finishes, too tired. === RoAk is now known as RoAkSoAx === evalles_ is now known as keffie_jayx === boomer` is now known as boomer [05:48] anybody familiar with python conditionals about? [05:54] LaserJock: I'm not familar, but suspect that if you described your test problem, one of you, I, or some lurker might have the answer :) [05:56] sure [05:57] I'm wanting to do a pretty extended if statement [05:57] basically something like: [05:57] if x == y && z == (q|r|s) [06:00] does that even work? [06:00] OK. I think that's if(x==y){if(z=(q|r|s){... [06:00] x1250: no, that's why I'm asking [06:00] :-) [06:01] ok, so x == y and z = ( q or r or s ) it seems to be ok with [06:01] Ah. Maybe you wanted || instead of | ? [06:01] if x == y and z in (q, r, s) [06:01] LaserJock: try #python, they answer fast ;-) [06:01] no, it doesn't like || or && [06:02] * persia retreats from python again, wishing it were slightly less prevalent [06:02] persia: why? [06:03] Amaranth: actually, I want to do x == y and z != (q or r or s) [06:03] then use -> not in [06:03] Amaranth: so you if x==y and z notin (q,r,s) work? [06:03] LaserJock: The syntax is un-C like. Also, whitespace treatment may require bit-analysis, rather than visual analysis. [06:04] persia: C-like syntax is a good thing? [06:04] LaserJock: if x == y and not z in (q, r, s) [06:04] i think that'll work [06:04] LaserJock: (q or r or s) will return true if anyone of them is true, or whatever value != false and != 0 any of the members would have [06:04] is that what you want? [06:05] LaserJock: I think so, but I've been reading C since around the first flight of the Space Shuttle Discovery [06:05] x1250: yeah [06:06] I want it to work if x == y and z != any of q,r,s [06:07] ("text" or false or true") will be == "text" [06:07] (0 or false or True) will be == True [06:07] these conditionals are one thing I just can't get the hang of in Python [06:07] the only case the result is false is when every member is false [06:08] sweet, Amaranth's recipe worked [06:08] :) [06:14] persia: I'm getting somewhere http://laserjock.us/files/ubuntu/buglist.html [06:15] LaserJock: That's looking great! Is it that just approved tasks, or nominations as well? Also, is it possible to pull the descriptions? [06:15] persia: I can pull pretty much anything now that I've hooked into python-launchpad-bugs [06:16] persia: those are bugs that are subscribed to by MOTU SRU [06:16] I'm working now on how to get a list of tasks that haven't been targeted yet [06:17] Interesting. That list would be the list of things that need review/action by the approval team, and there'd be another list of things that need review / approval by the wider stable developers team? [06:18] persia: items that are "Fix Commited" have been accepted into -proposed and need testing [06:18] items that are "Confirmed" are ack'd by the SRU team [06:19] maybe I should seperate out those lists [06:21] Might be nice to have a few lists: things that need testing, things that need review/approval of the proposed solution, and things that need someone to either prepare a proposed solution, or determine that it doesn't qualify for SRU. [06:21] yeah [06:22] actually, those are better categorizations than release [06:22] I'll put the release as a column [06:24] Just out of curiosity, what is the workflow to handle approvals? To me there seem to be two approval stages: firstly whether a given issue meets the criteria for SRU, and secondly whether a given solution is acceptable for upload, (regression analysis, etc.). Are both stages handled by the SRU team? [06:25] *cry* car shopping sucks.... [06:25] The reason I ask is that I wonder if it is possible to generate a list of pending updates that would benefit from someone preparing a patch. [06:28] persia: well, first SRU approves the "worthyness" of it and makes sure things are following policy, then it gets uploaded to -proposed (verification-needed tag is added) [06:28] then once it's been tested it gets a verification-done tag and gets moved to -updates [06:29] Ah, so currently the SRU team determines both whether the bug is suitable for SRU and whether the patch is good at the same time? [06:29] basically [06:29] we don't do testing per se [06:29] but make sure things are being done sanely [06:29] Oh, sure, I wouldn't expect testing. [06:29] we might say "that's too invasive", etc. [06:30] but we expect the contributors and their sponsors to test before upload [06:31] So the contributors end up responsible for determining what gets development attention for SRUs? I'm just thinking it might be awkward for someone to determine that something should be updated, do all the work, and only at the end be advised that they ought have selected a different bug. [06:31] well, we like people sub'ing SRU if they thing something should be an SRU [06:32] and work with us early on [06:32] OK. So there are two cycles: first an approval for the class of bug, and then for the proposed patch? [06:32] sometimes [06:32] depends on if the patch is already there [06:33] but informally yes [06:33] Let's assume it's not. If there is a patch, it falls back to the case where someone didn't get pre-approval, and may be advised they've wasted their time. [06:33] I'll say "looks good, work up the SRU", then once it's ready actually ack it [06:35] I think mostly we get to bugs and comment before people get all that far [06:35] I can't think of any cases where somebody got all the way to having a ready debdiff and I rejected it [06:36] Hmm. Well then, if it's not broke, no point fixing it :) I think it still might be nice to have a supplementary list of all tasks nominated or approved for stable releases, but maybe only as a source for contributors to review when selecting candidates to bring to the SRU team. [06:37] hmm, yeah. I agree [06:38] Might get a little confused with security vs. SRU, but I'd think that would be obvious from the bug description, etc. [06:43] perhaps yeah [06:43] LaserJock: so was your question so you could do something like not status in ("Incomplete", "Invalid", "Won't Fix") ? [06:43] I wouldn't mind having to go through some false positives [06:43] Amaranth: Invalid, Won't Fix, and Fix Released [06:43] ah [06:43] close enough :) [06:45] Does the ALSA device "default" in Hardy correspond to PulseAudio by default? [06:46] LucidFox: No. [06:46] Is "pulse" present by default, then? [06:51] LucidFox: If you install Ubuntu/GNOME, yes. [06:51] LucidFox: But it can be disabled. [06:51] ah [06:51] LucidFox: However when pulse is playing audio, it accesses the audio hardware directly, so alsa apps won't work while pulse plays audio. [06:51] yes, I know that [06:52] persia: ok, so maybe I'll do two pages. One for potential SRUs and one for the tasks we're actively tracking [06:52] I was patching an app that used "plughw:0,0" as the default audio device, and wondered whether to set the default to "default" or "pulse" [06:52] LaserJock: That seems sensible to me. Perhaps for the former, it might make sense to coordinate with SWAT as a common list towards which to point people who want to work on the stable environments. [06:53] persia: agreed [07:10] LucidFox: default. === asac_ is now known as asac [07:47] good morning === asac_ is now known as asac [08:49] G'morning [09:53] If I'm going to upload a NEW package from debian-multimedia.org that requires Ubuntu changes, do I need to submit it to REVU? [09:54] I can't find mpeg4ip on REVU, for one... === lool_ is now known as lool === amachu__ is now known as amachu [10:37] LucidFox: Quite old == latest release? Tracking SVN is foolish. [10:39] We have 1.0rc2 in Hardy, IIRC. [10:39] yes [10:39] They say 1.0rc1 is old. [10:44] Well, smplayer uses some features that aren't even in rc2 - I'll ask upstream which exactly [10:45] If mplayer actually made any vaguely useful releases.. [10:49] also, how about shipping mplayer in Ubuntu with the compiz xv patch? [10:50] the one that enables use of the compiz video output plugin [10:50] LucidFox: Wasn't that patch rejected violently by upstream? [10:50] Or is there another one which is blessed? [10:52] hmm, this was proposed as bug #121476 [10:52] Launchpad bug 121476 in mplayer "Use Compiz' "video" plugin when available" [Wishlist,Won't fix] https://launchpad.net/bugs/121476 [10:54] there was a new version of the patch posted after it was closed as Won't Fix, though [10:55] Doesn't Xv work in Compiz on most cards these days? [10:55] Even textured video should work on Intel soon, at list. [10:55] *at least [10:55] hmm [10:55] "There is an unofficial patch for mplayer/compiz (it'll never be official, it's more like a temporary and dirty hack)" [10:55] looks like that answers it [10:55] Yes. [10:58] Is there a fix/workaround for the pbuilder libc6 issue yet? [11:18] LucidFox: The compiz 'video' plugin is in some sort of perpetual limbo. Davidr consistently threatens to do it again, correctly. So nothing supports it, because it's kinda temporary. [11:19] Also, debhelper 7 is whack. [11:19] RAOF: Please define "whack" [11:20] Two line debian/rules kinda whack. [11:20] Like CDBS, but it seems that doing advanced stuff doesn't require sacrifices to the four dark gods of chaos. [11:21] Simple. Concise. Readable. Says "Nothing to see here. Please move on." to people, and they look at the useful files. Fewer irregular debian/rules hacks. [11:21] Yeah. Whack is not necessarily indicative of disapproval. [11:23] I'm just packaging Do for debian, and playing with dh and cli-common-dev 0.5.7. [11:35] * Hobbsee waves [11:42] Hi Hobbsee [12:27] what benefits does packaging programs as perl5.8, perl5.10 and making other packages depend on them instead of a meta package for perl and depends on the perl5.8 like the linux-image packages [12:28] bardyr: I am not a perl programmer, but I assume that new features were introduced in 5.10 [12:29] another package making use of those features needs to depend on 5.10 [12:30] mok0, but then special packages can depend on certain version of perl [12:30] bardyr: yes [12:30] mok0, im on intrepid and trying to install some perl depended programs but they all depend on 5.8 but its gone [12:31] now i need to manually change dependencies to 5.10 :/ [12:31] which means they need to be updated, which may well require code changes [12:31] or removed. [12:31] bardyr: or just >= 5.8 [12:32] mok0, it has that, but it points to perl5.8 and it has been replaced with perl5.10 [12:34] bardyr: there may be a virtual package perl, that depends on the "current" perl version for any given distribution [13:24] Do FTBFS bugs have a whitelist from motu-sru? [13:26] hi folks [13:26] Hi sistpoty [13:26] hi geser [13:27] * sistpoty merges ghc6... just trying to rebuild itself with the merged version [13:29] Anyone want any REVU packages reviewed? === asac_ is now known as asac [13:58] Hm. Is there a way to get PPA to build the same source package for both hardy and gutsy? [13:59] slicer: Look at the copy package option [14:01] rexbron: Ah, I must be blind :) Thank you. [14:06] slicer: np [14:08] is there a difference between debhelper (>> 5) and debhelper (>> 5.0.0) ? [14:09] sebner: I would guess that >>5.0.0 would be satisfied by 5.0.1 while >>5 would not [14:09] sarah@saturn:~% dpkg --compare-versions 5 lt 5.0.0 && echo true 11:09PM [14:09] true [14:09] interesting [14:10] sarah@saturn:~% dpkg --compare-versions 5 lt 5.0.1 && echo true 11:09PM [14:10] true [14:10] rexbron: both should be satisfied. [14:10] sebner: i don't really think so - there's no number in between 5 and 5.0.0 except for 5.0 [14:10] which all equates to the same thing, in real version #'s, anyway [14:10] Hobbsee: cool. thanks :) [14:13] wow. the debian NM process is complex [14:21] Heya gang [14:23] hi bddebian [14:23] heya :D [14:24] Hi sistpoty, emgent [14:31] Hmm [14:31] In the orig.tar.gz for cairo-dock on REVU, various automake files in the root are symlinks to files in /usr/share/automake-1.10 [14:32] is this allowed? [14:34] LucidFox: hm... looks like a mistake from upstream to me, though (if it b-d on automake 1.10 it imho is ok *packaging* wise) [14:34] LucidFox: if it's gpl (or lgpl) however, the license file must not be a symlink though [14:35] it isn't - only config.guess, depcomp, install-sh, all that stuff [14:36] ok... packaging wise I guess it's ok, but the packager should really ask upstream to fix that (as it defeats the purpose of autoconf/automake actually) [14:38] anyone know if intrepid is currently safe? or are there any big issues? [14:38] (as I'm pondering dist-upgrading) === x1250_ is now known as x1250 [14:42] sistpoty: libxfonts1 is broken. [14:42] But downgrading that gets things working again, I believe. [14:43] sistpoty: I've only a intrepid chroot for working on packages and a intrepid pbuilder. Both doesn't seem to be broken right now. [14:52] hm... apt tries to remove quite a bunch of important packages from me... (e.g. dia, exim4-daemon-heavy, svn-buildpackage)... [14:52] and kvirc! *g* [14:53] oh... apt changes the behaviour when puring old packages... strange [14:53] purging even [14:54] my intrepid chroot is only minimal (enough to work on packages). I'll upgrade my main system to intrepid around the first or second alpha. [14:55] what did change during purging= [14:55] ? [14:55] geser: I'm entirely unsure actuallly... I've thought the packages I purged were entirely unrelated [14:55] geser: it changed from removing many packages to hold back a bunch of others [14:56] however I don't see a pattern yet for apt doing so [14:57] and now it upgraded some packages while purging only other ones... *strange* [15:02] may it be related to recommends? [15:04] do we have recommends by default now? [15:05] hm... there's at least nothing in apt-cache -i unmet for e.g. kvirc or exim *shrug* [15:10] sistpoty: "* enable installation of recommends by default" [from the changelog entry for apt (0.7.14ubuntu1)] [15:12] sistpoty: don't hestiate to upgrade. it's never false to get rid of this kde stuff ^^ ;P [15:14] geser: ah, thanks [15:14] sebner: :P [15:16] sebner: luckily kernel-image got renamed to linux-image so you can do now: "apt-get --purge remove k*" :) [15:17] geser: hrhr :) [15:22] * sistpoty is bold and dist-upgrades *g* [15:30] bug #228997 reported [15:30] Launchpad bug 228997 in apt "[intrepid] apt-get happily removes packages" [Undecided,New] https://launchpad.net/bugs/228997 [15:35] sistpoty: nice comments xD [15:36] hm... I'm still puzzled. maybe the difference is that apt-get install will do an apt-get upgrade (vs. apt-get dist-upgrade) under the hood? === emgent_ is now known as emgent [15:59] as sistpoty isn't swearing, either the upgrade went fine, or is still in progress or sistpoty is fighting to bring his box back to life :) [15:59] * sistpoty is still upgrading (replacing packages right now) [16:06] hi! I have a python app that depends on python-pygame. My app just contains python files with nothing to compile. Can anyone point me to the easiest way to make a .deb with my python files and the pygame dependency? Thanks :) [16:07] penper: https://wiki.ubuntu.com/PackagingGuide/Python [16:07] penper: that should guide you into making a deb package for a Python application [16:08] pochu: perfect! Thanks [16:30] pochu: wow. really great work by Michael Gliwinski for putting your session on the wiki page. [16:33] yeah he did a nice work [16:34] Holy...! [16:34] dh_make was updated just yesterday! [16:35] LucidFox: that means? [16:35] well... it's been long time since the last update [16:37] ah. k [16:37] lol [16:46] It's somewhat ironic that dh_make only updated to debhelper 6 after debhelper 7 was released [16:52] * sistpoty is off again... cya [16:56] btw, if some of you have some spare time can they have a look at : http://revu.tauware.de/details.py?package=emu8051 [16:57] Pierre Ferrari is one of my teachers, trying to learn packaging. It looks good to me but as I only do some packaging updates nowadays I probably missed a lot of things :) [16:59] stgraber: I've only looked at the diff.gz yet, and at first I only see a very minor issue: move the Homepage field to the source stanza in debian/control [17:02] stgraber: and the link to the GPL in debian/copyright should point to GPL-2 as GPL is a symlink to GPL-3 [17:05] geser: ah, right code is not GPL2 and higher. Thanks [17:12] stgraber, geser> I also have doubts about Section: x11 [17:13] to be fair, the Debian section conventions are far from clear === fta_ is now known as fta [17:16] LucidFox: as I can't find a better section and it has a gui, it could stay in x11 [17:16] makes sense to me [17:17] Holy cow... someone submitted a 9.1 MB debdiff for a new upstream release, including upstream changes [17:17] uncompressed to boot [17:18] actually... two people did it [17:25] sebner, congratulations! [17:25] LucidFox: ah.. thanks ^^ [17:26] sebner: congrats [17:26] geser: thanks. :) ehm yes, you made it possible ^^ [17:30] I feel a little lost here, to be frank [17:31] universe-contributors is a recently created team, how is it different from MOTU? [17:31] LucidFox: I have no upload right ;) [17:32] LucidFox: universe-contributors is like ubuntu-members but you don't have to go the CC but to the MC [17:33] LucidFox: it grants ubuntu membership and is a step towards MOTU [17:33] * persia notes that it's possible to be MOTU without being a universe-contributor, but most people will likely reach the threshold for universe-contributor before reaching the threshold for MOTU (lower technical requirements, same community requirements) [17:34] ah [17:36] oh, hello blueyed_ [17:39] I reported a bug on kid3 debian package to add dh_icons on debian/rules and the mantainer forcibly merged this bug to an unsolved previous one (156 days old). Is this a sign she won't fix it again? Can we proceed with the merge? [17:40] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=480246 [17:40] no0tic: Error: Could not parse data returned by Debian: timed out [17:40] merged to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454526 [17:40] no0tic: Error: Could not parse data returned by Debian: timed out [17:42] there's a typo on a REVU page [17:43] "Please consider submitting your package to Debian as well. The Utnubu team would be more than happy to help you to get started. " [17:43] or is that intentional? [17:43] coppro: Utnubu is a team [17:43] ok [17:44] coppro: it's focused on getting Ubuntu packages into Debian [17:44] coppro> A largely defunct one, really [17:45] sebner: congrats :) [17:45] If you can't find a sponsor otherwise, I suggest pitching packages to the Debian team that's involved in similar packages [17:46] pochu: also thanks to you :) [17:46] sebner: congrats! [17:46] * RoAkSoAx hi all [17:46] jdavies: thanks ^^ [17:47] sebner, congrats too (what for? hehexD :P) [17:47] RoAkSoAx: xD. You remind me of me when I started contributing ^^ [17:48] sebner, looool [17:48] hey sebner, congrats! ;) [17:49] warp10: thanks. But I'm now contributing member and not president of the USA ^ [17:49] geser: Do you have time to take a look at merge for lucene2? [17:49] Where can I find debhelper 7 documentation? Other than "man dh" :) [17:49] sebner: How knows, maybe a day you will be the first MOTU-president...! :P [17:49] warp10: hrhr [17:50] also... why do I see so many debdiffs uploaded as text/html? (including yours, slytherin) [17:50] LucidFox: I am filing a bug report about it right now. :-) [17:51] heh [17:52] * LucidFox can't wait for openjdk-6 to get into Debian finally [17:52] slytherin: sure [17:54] geser: As LucidFox has already mentioned, debdiff is shown in html format.:-( You will need to wget it. [17:54] LucidFox: https://bugs.edge.launchpad.net/launchpad/+bug/229040 [17:54] Launchpad bug 229040 in launchpad "debdiff shown as html" [Undecided,New] [17:54] sebner: if you would told me two years ago, I will be a part of the MC I wouldn't believe you. Let's recheck in two years again. [17:55] slytherin: I've changed the filetype of your debdiff from text/html to text/plain so I can review it in firefox [17:55] geser: where did you find that option? [17:56] ahh, in edit attachment [17:56] exactly [17:56] I'm doing a merge, some of the previous Ubuntu patches just modified the source directly. Is it worth me refactoring these to use cdbs or similar, or should I just leave them? [17:57] Laney: does the package use a patch management system (dpatch, quilt, etc)? [17:57] geser: No, there is no debian/patches or anything [17:58] Actually, the Debian patches do it too. I guess it's not worth it, eh? [17:59] then leave them as they are as adding a patch system would increase the Ubuntu delta even more (unless there a many and/or big patches) [17:59] geser: Right then, cheers [18:00] what does this error mean - debian/rules:16: *** target file `build-indep' has both : and :: entries. Stop. [18:01] slytherin: I think that's because you added a 'clean:' target and included a CDBS include which has 'clean::', so if that's the case, change your 'clean:' to 'clean::' [18:01] slytherin: re lucene2: why got the patches 80 and 81 removed from 00list? [18:02] slytherin: err, the same but 's/clean/build-indep/g' [18:02] geser: they were removed on debian side. [18:02] pochu: thanks. There is a debhelper include which is not needed. [18:07] geser: hmmm? [18:12] slytherin: debian/patches/00list from the unmodified Debian package lists 80_prevent-downloading-data-files.dpatch and 81_prevent-network-access.dpatch [18:13] geser: let me take a look [18:13] slytherin: but these are different patches as the patches from the old Debian package with the number 80 and 81 [18:15] geser: Oh, Wait. These patches were included in Debian as fix for FTBFS. Remember 'no-internet-access-on-buildd' problem? We fixed it in different way. [18:15] ah, ok then [18:17] Hello all [18:18] slytherin: does the DTD fix replace also patch 80 (prevent downloading data files) or only patch 81? [18:18] Would someone have a look at my package "gtkvncviewer" on REVU? Its Debian version has been accepted by Debian mentors, so I believe it's not bad. [18:18] geser: both. we patch the unit test to use local DTD. === Lure_ is now known as Lure [18:21] slytherin: please document it better the next time you merge this package, that the ubuntu patch replaces the other two patches [18:22] geser: Can you please wait. Looks like patch 80 should not be dropped. My bad. :-( [18:25] slytherin: so I should readd patch 80 again? [18:26] slytherin: no need to create a new debdiff just for that [18:26] geser: Yes, if that is not much trouble to you. Otherwise I will add it and document things properly [18:27] slytherin: no problem. it's probably easier than to start from fresh [18:30] Bye all [18:37] sebner: Congratulations. [18:37] geser: I have reverted that changed and documented why patch 81 was removed. Should I delete old debdiff and upload new one or simply upload new one? [18:37] ScottK: oh. thanks :) Just hoping that I won't be thrown out of the team after the courier merge ^^ [18:38] sebner, lol... now i know.. you've been the first accepted as a u-u-c member [18:39] RoAkSoAx: exactly :) [18:39] ScottK, did you follow the kid3 merging adventure two days ago? [18:39] no0tic: No. I've been offline the last few days. [18:39] sebner, congrats then ;) [18:39] RoAkSoAx: thanks thanks ^^ [18:40] ScottK, may I bother you anyway? :) [18:40] is there a simple way with debhelper to install a debian/desktop and debian/desktop.png or i have to link in install? [18:40] no0tic: You can ask. Not sure I'll have time to answer. [18:40] congrats sebner ! [18:40] ember: also thanks to you [18:41] ember: Isn't there a dh_desktop for that. [18:41] ScottK, I reported a bug on kid3 debian package to add dh_icons on debian/rules and the mantainer forcibly merged this bug to an unsolved previous one (156 days old) reported by DarkSun88 during hardy merging. Is this a sign she won't fix it again? Can we proceed with the merge? [18:41] Can someone point me to some page that explains you-you-c? [18:41] ScottK yeah that registers the .desktop file [18:41] and the png i link it on .install right? [18:42] no0tic: What bug? [18:42] slytherin: https://wiki.ubuntu.com/UbuntuDevelopers [18:42] slytherin, https://launchpad.net/~universe-contributors [18:42] Note that dh_icons is still somewhat controversial in Debian. Some DDs favor the idea and some don't. [18:42] ScottK, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=480246 was merged to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454526 [18:43] Debian bug 480246 in kid3 "kid3_1.0-1: Add dh_icons in debian/rules" [Normal,Open] [18:43] no0tic: [18:43] no0tic: Looking [18:43] sebner: RoAkSoAx: thanks [18:44] no0tic: Yes. I'd say go ahead. [18:44] slytherin: like you want [18:44] no0tic: I don't think you needed to file your bug as it appears essentially the same as the existing bug. [18:45] geser: I will simply upload the new one so you can compare it with old one if you want. [18:46] ScottK, ok, I'll file the merge wishlist bug on LP, thanks a lot [18:47] no0tic: No problem. Thanks for contributing and working to get Debian and Ubuntu in better sync. [18:50] ScottK: already looked at courier? [18:51] sebner: I have not. I just got back from being out of town. I'll probably look at it tonight (I'm at -0400). [18:52] ScottK: ah ok. sry [18:52] sebner: No problem. [19:19] since kid3 turned out to be a merge and not a sync I set this bug https://bugs.launchpad.net/bugs/227405 to invalid, is it ok? [19:19] Launchpad bug 227405 in kid3 "Please sync kid3 1.0-1 (universe) from Debian unstable (main)." [Wishlist,Invalid] [19:22] geser: Done. Uploaded new debdiff. [19:30] slytherin: Uploaded. [19:32] no0tic: Just edit that bug to be a merge bug. No need to start a new one. [19:33] ScottK, I hope not to miss another merge, but if it will happen I'll do that way [19:33] no0tic: OK. [19:37] is there something like an upload count? [19:47] geser: Thanks. And since you have ack'ed my previous sync bugs, I would be glad if you also did it fro tomcat5.5 :-D === emgent_ is now known as emgent [20:39] geser: I was looking at merging bioperl and noticed you were the merge-o-matic, just wondering if it's cool if I take a crack at merging it? [20:56] huhu no0tic [20:56] huhu norsetto [20:56] err, yes, huhu 2u2 sebner [20:56] ^^ [20:58] sebner: so you made it eh? Bribing the MC with home-made sauchertorte proved to be a worthy tactic after all [20:59] norsetto: hrhr. psst! don't reveal my top secret success plan ;) [20:59] * norsetto didn't realise he wasn't quering :-O [21:00] norsetto: xD xD xD [21:01] norsetto: btw, filed the flightgear bug and reported the changes to debian. We'll see what happenes :) [21:02] sebner: I'm eagerly awaiting [21:03] norsetto: ^^, why? [21:03] sebner: "We'll see what happenes :)" [21:04] norsetto: well, if they accept our changes or not [21:04] sebner: yes, thats why I said that I'm curious to see it too [21:05] norsetto: I thought that was just a joke because you are working on a lot of other packages ^^ [21:05] sebner: do you think this guy (bug 228976) is upset? [21:05] Launchpad bug 228976 in xsensors "The Xsensors program STILL will not install and/or run under Hardy final release version" [Undecided,New] https://launchpad.net/bugs/228976 [21:06] norsetto: STILL, maybe a little bit =) [21:06] sebner: but we are very nice guys, so we will ask debian to update it to 0.60 (supposing the DM is still alive) [21:07] norsetto: 0.6 fixes it? Not worth a SRU or? We are very nice guys, indeed ^^ [21:08] sebner: there are very high chances it will, the version right now in hardy is from beg. 2006 [21:08] norsetto: I see. bug 206862 [21:08] Launchpad bug 206862 in xsensors "New upstream version (0.60) available" [Undecided,New] https://launchpad.net/bugs/206862 [21:09] sebner: if it works in intrepid, we could backport it, but first we need to check [21:09] hmm, unstable still has 0.50-1 [21:09] norsetto: yep. do you want me to file a bug in debian BTS? [21:10] sebner: why not, check if there isn't one already, and if you really feel nice you can try to upgrade it yourself in the meantime, it will be a good exercise for you [21:11] norsetto: well then I have to be pretty quickly. Today is the last the I will work for ubuntu for at least for one week. You know. final exams :) [21:11] sebner: there is a bug alreday btw: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=446530 [21:11]