[12:14] <Burgundavia> shawarma: -directory
[12:15] <leonel> ScottK-laptop: for  CVE-2007-2650  CVE-2007-2029  for dapper   I can't  fix it because  it's reported and resolved in  0.90.3  and the code has changed    debian has not relased update for sarge's clamav  and for  CVE-2006-6481  debian  added extra functionality and I can't tell what modifications are exactly for that cve  just for the  Dapper's CVE-2007-1745  I have patched 
[12:15] <ubotu> The OLE2 parser in Clam AntiVirus (ClamAV) allows remote attackers to cause a denial of service (resource consumption) via an OLE2 file with (1) a large property size or (2) a loop in the FAT file block chain that triggers an infinite loop, as demonstrated via a crafted DOC file. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2650)
[12:15] <ubotu> File descriptor leak in the PDF handler in Clam AntiVirus (ClamAV) allows remote attackers to cause a denial of service via a crafted PDF file. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2029)
[12:15] <ubotu> Clam AntiVirus (ClamAV) 0.88.6 allows remote attackers to cause a denial of service (stack overflow and application crash) by wrapping many layers of multipart/mixed content around a document, a different vulnerability than CVE-2006-5874 and CVE-2006-6406. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6481)
[12:15] <ubotu> The chm_decompress_stream function in libclamav/chmunpack.c in Clam AntiVirus (ClamAV) before 0.90.2 leaks file descriptors, which has unknown impact and attack vectors involving a crafted CHM file, a different vulnerability than CVE-2007-0897.  NOTE: some of these details are obtained from third party information. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1745)
[12:16] <Q-FUNK> erm...
[12:16] <MrDumbo> spam
[12:16] <leonel> HAM
[12:18] <AndyP> geser: linux/wireless.h includes linux/if.h, the problem is a recent change in linux/wireless.h where some includes have been surrounded by an #ifdef __KERNEL__ block in order to "sanitise" the header. if you're interested the change is at http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=baef186519c69b11cf7e48c26e75feb1e6173baa
[12:19] <ScottK-laptop> leonel: All you can do is what you can do.
[12:20] <ScottK-laptop> leonel: You've been making good contributions.
[12:20] <AndyP> geser: apparently it should be using iwlib.h instead, which I've tried and it built with that but then rt2500-source still doesn't build using module-assistant once it's installed... i'm also wondering if this should be a kernel team thing because feisty's kernel had the rt2500 module in by default (as far as i can see)
[12:21] <AndyP> s/feisty's kernel/& package/
[12:23] <AndyP> so yeah, i guess i should paste all that into a bug report now...
[12:29] <leonel> ScottK-laptop: so .. to  call it unfinish  what's to be done ?
[12:29] <ScottK-laptop> leonel: We need to figure out how to backport the 0.90 versions to Dapper/Edgy as discussed at the last MOTU meeting.
[12:30] <leonel> ScottK-laptop: ok  let's see what can we do  in that  area
[12:45] <geser> AndyP: that would be good. I only looked at the build report and saw there a missing IFNAMSIZ
[12:51] <SlimG> How do I insert a non-ascii character into a ascii document? (using groff_char)
[12:53] <DktrKranz> if you have some time to spend, could you please take a look at http://revu.tauware.de/details.py?upid=5287 ?
[12:53] <DktrKranz> night all :)
[01:15] <StevenK> shawarma: I am now.
[01:16] <SlimG> I'm packaging a game with only one binary, Should I place the binary directly into /usr/games/ or should it still be located in /usr/share/games/<gamename>/  ?
[01:20] <ScottK-laptop> SlimG: /usr/share/games/<gamename>/
[01:21] <SlimG> ScottK-laptop: thanks
[01:24] <minghua> ScottK-laptop: why?  If the binary is compiled, it surely shouldn't be under /usr/share/?
[01:26] <ScottK-laptop> hmmm
[01:26] <crimsun> meaning /usr/games/ ?
[01:27] <crimsun> not sure why /usr/share/ would be relevant
[01:27] <ScottK-laptop> The question I was answering was if it should go in a package name subdir and I think it should.
[01:28] <crimsun> the ones I have installed don't use such
[01:28] <minghua> crimsun: a lot of games put data files in /usr/share/games/<name>/, but I don't see the reason to put executable binary there
[01:28] <crimsun> bsdmainutils, patchutils, gnome-games, fortune-mod
[01:28] <minghua> (even if it's arch-independent)
[01:28] <minghua> crimsun: try wesnoth :-)
[01:29] <crimsun> I'm speaking of executable binaries, of course
[01:29] <crimsun> /usr/share/games/ is trivially useful 
[01:31] <geser> compiled binaries (arch-dependent) shouldn't be below /usr/share
[01:31] <crimsun> right, we're in agreement there
[01:32] <crimsun> the binary, say named foo, should be /usr/games/foo
[01:34] <ScottK-laptop> For usr/share a pacakage specific sub dir is recommended, but not required.  HFS is silent on subdir in usr/games.
[01:34] <StevenK> FHS, even?
[01:34] <ScottK-laptop> Yeah.  That one.
[01:35] <StevenK> I wouldn't suggest a subdirectory under /usr/games. /usr/games is in the PATH, but /usr/games/* isn't.
[01:35] <ScottK-laptop> Sorry.  Trying to do IRC and listen in a meeting at the same time.
[01:35] <ScottK-laptop> Makes sense.
[01:36] <minghua> okay, seems there is a consensus
[01:36] <minghua> SlimG: you should put your game binary in /usr/games/
[01:38] <SlimG> minghua: thanks for clearing that up for me, I'll remember that
[01:41] <SlimG> What's the right way to read /usr/share/doc/<package>/copyright ?
[01:54] <ScottK-laptop> Meeting's over, see you all later....
[02:10] <jrib> if anyone would like to review a new package: http://revu.tauware.de/details.py?upid=5444 thanks! (by the way, is it annoying for me to keep asking every day, should I just post to the mailing list and shutup?)
[02:13] <minghua> jrib: once per day is absolutely fine in my opinion
[02:35] <nixternal> what is the proper way of using the requestsync script?
[02:35] <AndyP> dear thunderbird, grow a reply-to-list button, kthxbai!
[02:36] <StevenK> nixternal: requestsync <source> <release>
[02:37] <StevenK> nixternal: You'll need a deb-src line for <release>, and the DEBEMAIL environment variable set.
[02:38] <nixternal> I have DEBEMAIL set already in .bashrc
[02:38] <nixternal> how do I add the deb-src line, or where?
[02:38] <StevenK> nixternal: /etc/apt/sources.list
[02:38] <nixternal> oh
[02:52] <nixternal> MOTU: bug 120300
[02:52] <ubotu> Launchpad bug 120300 in kftpgrabber "Please synce kftpgrabber (0.8.1-1) from Debian Unstable (main)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120300
[02:52] <nixternal> simple sync
[02:54] <nixternal> all Ubuntu changes (1 of them) can be dropped as Debian included our patch
[02:57] <AndyP> ah i love it when debian does that :)
[02:57] <nixternal> me too
[02:58] <nixternal> fboudra is cool like that though
[03:17] <SlimG> Where should the .svg Icon mentioned in /usr/share/applications/example.desktop be placed?
[03:20] <minghua> /usr/share/icons/<somewhere>/scalable/apps/, I think
[03:21] <minghua> I am also not sure the <somewhere> part
[03:27] <SlimG> minghua: the only icons dirs on my kubuntu is containing scalable folder is mono, crystalsvg and hicolor, so I guess the hicolor is the one I should use..?
[03:28] <SlimG> s/kubuntu is/kubuntu/
[03:30] <AndyP> SlimG: in those situations i usually look at where other packages are putting their similar files (probably not the best way to do it but it's an "if in doubt, go with the flock" solution)
[03:30] <leonel> how do I can  know  what packages without being installed   depend on  some lib ?
[03:30] <minghua> leonel: apt-cache show <packagename>
[03:31] <minghua> or apt-cache rdepends <libpackagename>, not sure what you meant
[03:32] <leonel> minghua: I mean  I have  libclamav2   and I need to know  what packages  need  libclamav2  even  if those packages are not installed
[03:32] <SlimG> AndyP: As I mentioned, I'll go with the flock and use /usr/share/icons/hicolor/scalable/apps , sure hope the flock is right :)
[03:32] <leonel> rdpends ?
[03:32] <minghua> leonel: yes, the rdepends one
[03:32] <leonel> thanks  it is
[03:38] <AndyP> SlimG: "For example, installing a svg icon in $prefix/share/icons/hicolor/scalable/apps means most desktops will have one icon that works for all sizes." -- http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#install_icons
[03:38] <AndyP> yay for definitive answers
[03:40] <SlimG> AndyP: thanks :)
[03:41] <SlimG> what's the difference between .svg and .svgz? is the extra "z" for gzipped svg files?
[03:41] <AndyP> SlimG: yup
[03:43] <SlimG> AndyP: Should the file inside example.svgz also be named example.svgz ?
[03:43] <SlimG> or just .svg ?
[03:45] <AndyP> SlimG: you mean the original uncompressed file? .svg
[03:48] <SlimG> AndyP: (yes, the original uncompressed) should example.desktop refer to example.svg or example.svgz then?
[03:48] <AndyP> SlimG: whichever one you're installing, at a guess :)
[03:49] <bobbob> hey
[03:49] <bobbob> anyone on?
[04:16] <TheMuso> Hey folks.
[04:17] <Hobbsee> hiya TheMuso 
[04:40] <AndyP> good night folks
[04:41] <Hobbsee> night welshbyte
[05:04] <zakame> good day MOTUs
[05:05] <zakame> anyone doing xmms2 merge?
[05:12] <leonel> hey zakame  
[05:12] <zakame> yo leonel how goes clamav?
[05:14] <leonel> bad bad  there are  2 cve which  are for  0.90.X  and  need to backport to 88.2  and I can't tell what to patch  since the code has changed in 0.90
[05:14] <snerfu> I would like to merge my rewrite of stendhal someday.
[05:14] <zakame> have you brought upstream in to help you out?
[05:15] <leonel> no I haven't 
[05:15] <leonel> how can that be done ?  I'm  new  here 
[05:16] <zakame> lookup clamav's debian/copyright for author info, or lookup their website for contacts
[05:22] <leonel> zakame: great  thanks  I'll contact them 
[05:22] <leonel> zakame: what's for  openjdk  in ubuntu   , do you know any plans for it ?
[05:24] <zakame> leonel: np :)
[05:25] <leonel> np == no plans ?
[05:27] <Burgundavia> leonel: icedtea is packaged for Debian
[05:28] <leonel> so a merge has to be done ?
[05:29] <Burgundavia> http://gnu.wildebeest.org/diary-man-di/?p=37
[05:29] <jsgotangco> icedtea is a package? heh
[05:29] <leonel> i've tried those debs  but can't install on feisty 
[05:31] <zakame> jsgotangco: nestea?
[05:32] <jsgotangco> zakame: i like our "local" bottled tea thank you, less sugary
[05:32] <zakame> hmm libfaad isn't in gutsy?
[05:34] <leonel> well got to  go ..
[05:36] <zakame> oh, libfaad2-dev in multiverse
[05:52] <zakame> heya man-di_
[07:16] <ScottK-laptop> Any experienced MOTUs available to answer a newbie MOTU question...
[07:16] <ScottK-laptop> Do I have to dput differently for a NEW package?
[07:21] <crimsun> no.
[07:21] <crimsun> which did you upload?
[07:22] <LucidFox> I have submitted 5 new needs-packaging bugs to Launchpad
[07:22] <LucidFox> https://launchpad.net/ubuntu/+bugs?field.tag=needs-packaging&start=300
[07:23] <ScottK-laptop> nixternal: libreadonly-perl
[07:23] <ScottK-laptop> Oops.  Wrong issue to point nixternal at.
[07:23] <ScottK-laptop> crimsun:  libreadonly-perl
[07:23] <nixternal> heh
[07:24] <crimsun> ScottK-laptop: did you receive an upload accept?
[07:25] <crimsun> maybe I need DRI enabled for this new Flash plugin beta
[07:28] <ScottK-laptop> crimsun: I did not.
[07:28] <crimsun> ScottK-laptop: reupload it
[07:28] <ScottK-laptop> crimsun: Thanks.
[07:28] <crimsun> mm, nope, DRI doesn't do it.
[07:28] <crimsun> 9.0.60.120 is definitely broken.  Not uploading.
[07:28] <ScottK-laptop> crimsun: Did I do something wrong or is this just stuff happens sometimes?
[07:29] <crimsun> ScottK-laptop: it happens sometimes, though it's not supposed to.
[07:29] <ScottK-laptop> This was my first NEW upload...
[07:29] <ScottK-laptop> OK.  Thanks.
[07:29] <crimsun> make sure you signed it with your usual key, etc.
[07:29] <zakame> ooh new perl module :)
[07:30] <ScottK-laptop> I did debsign -m and the usual e-mail address just like I would for someone else's merge.
[07:30] <zakame> usually a debuild -S -sa should do
[07:30] <ScottK-laptop> Not if it's not my name in the changelog because I didn't package it.
[07:30] <crimsun> sure you can, just pass the correct -k0xfoo
[07:31] <zakame> yep
[07:32] <ScottK-laptop> Ah..  That would do it.
[07:36] <crimsun> anyone who feels the urge to fix bug 120319, please realise that the beta version is utterly broken.
[07:36] <ubotu> Launchpad bug 120319 in flashplugin-nonfree "[UPDATE]  New beta of the flashplayer available" [Wishlist,Confirmed]  https://launchpad.net/bugs/120319
[07:37] <crimsun> The release notes mention a workaround, but of course it's impossible to apply the workaround, since it crashes the web browser.
[07:38] <zakame> waah
[07:38] <crimsun> I'm not even sure how they managed to release it; it's a 100% regression from the final 9.0.31.  No sites work at all.
[07:39] <zakame> hmm yet another worse-than-fail?
[07:39] <crimsun> it appears to initialise fine, but it never actually does anything
[07:40] <zakame> I see
[07:40] <ScottK-laptop> For Flash, isn't that a feature?
[07:40] <zakame> hmm what ffmpeg issues are there blocking xmms2?
[07:40] <zakame> bug 84381?
[07:40] <ubotu> Launchpad bug 84381 in ffmpeg "[apport]  ffmpeg crashed with SIGSEGV" [Medium,Unconfirmed]  https://launchpad.net/bugs/84381
[08:03] <zakame> hmm xmm2 seems to build fine now
[08:04] <StevenK> On the buildds?
[08:05] <zakame> no just on my chroot, will check
[08:05] <ScottK-laptop> jdong: According to LP you all published the python-spf backport for edgy last month - https://launchpad.net/ubuntu/+source/pyspf
[08:06] <StevenK> zakame: xmms2 was strange, in that it will build fine everywhere, *aside* from the buildds.
[08:07] <StevenK> case in $(hostname -f) ; *ubuntu.com) fail_build_randomly ;; esac
[08:07] <jussi01> hello everyone...
[08:12] <zakame> hmm the new DrJekyll version seems to have overhauled its build system
[08:12] <StevenK> It moved to cmake, didn't it?
[08:12] <zakame> no more direct scons calls, there's a ./waf script that drives the build
[08:15] <StevenK> zakame: waf is derived from scons.
[08:16] <zakame> ah, cool
[08:30] <zakame> waah xmms2 should really get reorganized into several source pkgs
[08:31] <zakame> no wonder why the build fails selectively, its trying to be a God Package...
[08:47] <dholbach> good morning
[08:56] <zakame> hmm let's see if this new xmms2 builds on the buildds...
[08:56] <Fujitsu> zakame: Good luck.
[08:57] <Fujitsu> You'll need it.
[08:57] <StevenK> Heh
[09:03] <zakame> Fujitsu: thanks, wiping my keyboard with it now. :D
[09:04] <ScottK-laptop> Fujitsu: Any chance you'd take a look at python-scipy.  I managed to break it and am unsure how to proceed.  I test built python-scipy (0.5.2-9ubuntu1) in my pbuilder before I uploaded it and it built (I'd updated it a few days before).  It FTBFS on the buildd's.  I updated my pbuilder and it would no longer build for me.  
[09:05] <Fujitsu> ScottK-laptop: Sure, I'll have a look.
[09:05] <Fujitsu> I'd really like it if LP allowed subscriptions to packages for getting notification of uploads/FTBFSes/etc.
[09:07] <ScottK-laptop> Fujitsu: Thanks.  Here's the traceback from the FTBFS: http://paste.ubuntu-nl.org/25482/
[09:18] <porthose> I uploaded ampache-3.3.3.2-0ubuntu1 to REVU but discovered it has a serious problem can I get a MOTU to nuke that upload please
[09:18] <dholbach> porthose: can't you just re-upload?
[09:18] <porthose> you can do that?
[09:19] <ScottK-laptop> Fujitsu: I need to get to bed.  With luck, this hotel internet connection will stay up.  If you have any suggestions on what I can do to fix it, please let me know and I'll work on it (of course if you want to fix it, don't let me get in your way).
[09:19] <ScottK-laptop> porthose: dput -f
[09:19] <porthose> cool I'll do that thanks
[09:19] <Fujitsu> ScottK-laptop: Sure, I'll probably fix it myself, but maybe not.
[09:19] <Fujitsu> Goodnight.
[09:59] <zakame> ooh xmms2 starts building
[10:23] <zakame> now depwaits on most arches
[10:29] <geser> zakame: is it perheps because libfaad2-dev is in multiverse and xmms2 in universe?
[10:32] <crimsun> speaking of which, shouldn't we merge the new faad2 from Debian?
[10:32] <crimsun> yes, there will be some hellacious package mangling to be done, but it's worth it IMO
[10:32] <dholbach> TheMuso: espeak uploaded - just noticed: shouldn't espeak-data be arch: all?
[10:34] <crimsun> and if faad2 is in Debian main, we should be able to ask for its promotion to Ubuntu universe
[10:34] <zakame> geser: yep
[10:34] <zakame> it should be in universe
[10:34] <zakame> anyway we're early, so I think its doable :)
[10:34] <geser> crimsun: I asked slomo about it during the merges for feisty. IIRC ours faad2 is severely patched which makes merging very difficult
[10:35] <crimsun> I wonder if there's any specific reason we should retain ours instead of using Debian's
[10:35] <geser> zakame: either move xmms2 to universe or don't build-depend on libfaad2-dev till it moved to universe
[10:35] <zakame> geser: xmms2 is in universe
[10:35] <crimsun> *xmms2 to multiverse
[10:36] <geser> yes
[10:38] <zakame> heavily patched? I see only 5 in debian/patches
[10:42] <zakame> just about the big patch is in 09_amd64.diff
[10:43] <zakame> perhaps on the binary pkgs produced may affect this; debian has a different set than ubuntu
[10:44] <zakame> looking at the versions though, I'd say we have a totally different faad2 from debian's
[10:45] <dholbach> REVU DAY TODAY
[10:45] <dholbach> yoohoo
[10:45] <dholbach> oh and Q&A session today
[10:45] <dholbach> was anybody at the 0:00 UTC ones?
[10:46] <dholbach> oh... I won't be able to be at the 12:00 UTC one
[10:46] <dholbach> does anybody feel up to doing it?
[10:46] <geser> zakame: slomo mailed me that Debian's faad2 has 64bit problems which our doesn't and that every version after ours has a GPL incompatible license which makes the Debian packages useless
[10:48] <BugMaN> bug #46013 it's a single line fix, if some universe sponsor can be check... :)
[10:48] <ubotu> Launchpad bug 46013 in backupninja "mail-command instead of rmail" [Medium,Confirmed]  https://launchpad.net/bugs/46013
[10:48] <dholbach> heno: today is a REVU day, not a Universe HUG DAY afaik
[10:48] <zakame> geser: ah, there we go
[10:48] <dholbach> and MOTU Q&A hours at 12:00 UTC
[10:49] <heno> dholbach: ooops, I've been picking up on rumors :/
[10:49] <dholbach> heno: we'll decide on a new Universe HUG DAY in tomorrow's MOTU meeting
[10:49] <heno> oh, well. I'll run my own little universe hug day then
[10:49] <dholbach> heno: best to check the MOTU Team header - it has al lthe dates
[10:49] <zakame> dholbach: hmm like knuth's all questions answered? :)
[10:49] <heno> ah, ok
[10:50] <heno> so it does
[10:51] <zakame> geser: wouldn't xmms2 to multiverse probably surprise users (at least)?
[10:52] <geser> yes, I would prefer to build xmms2 without libfaad2-dev instead of moving it to multiverse
[10:52] <zakame> I gather there's a better way than to just comment out faad2-relevant packages in debian/control, then.
[10:53] <imbrandon> probably --without-faad2 in the debian/rules configure options if it uses autofoo magic
[10:53] <imbrandon> ( and also control )
[10:55] <geser> zakame: without testing: remove libfaad2-dev from B-D and delete the xmms2-plugin-faad package from debian/control
[10:55] <zakame> geser: exactly what I'm doing now :)
[10:56] <zakame> fortunately, its just debian/control; no need to edit debian/rules
[11:04] <dholbach> is adam israel around?
[11:10] <dholbach> highvoltage: it's REVU Day
[11:11] <highvoltage> dholbach: is that until the end of the day?
[11:11] <dholbach> it's always a REVU day
[11:11] <dholbach> today is a special one :)
[11:11] <highvoltage> ah :)
[11:11] <highvoltage> I'm working until 15:00 UTC, I'll get into that brasero package right after that
[11:12] <highvoltage> maybe I can even get it up for revu today
[11:12] <dholbach> highvoltage: it was updated already
[11:13] <highvoltage> dholbach: ok. I'll ping you a bit later then I can start with another package?
[11:13] <dholbach> yes
[11:13] <dholbach> http://wiki.ubuntu.com/DesktopTeam/WIP lists a few
[11:13] <dholbach> other than that we have myriads of bugs marked as 'upgrade' 'packaging' 'needs-packaging' and 'bitesize'
[11:15] <dholbach> can we agree that we archive uploads that had a comment, but no reply back for more than a month and mail all the people involved?
[11:18] <highvoltage> dholbach: was that a question for me?
[11:19] <dholbach> highvoltage: I asked everybody in here :)
[11:19] <highvoltage> ok, just checking :)
[11:20] <MrDumbo> what is the best way to put up a request for having a package updated in gutsy
[11:20] <dholbach> MrDumbo: you can file a bug and tag it as 'upgrade'
[11:20] <MrDumbo> I filed a bug, but I might have forgotten the tag
[11:20] <MrDumbo> because it also got deleted... 
[11:20] <dholbach> deleted?
[11:21] <MrDumbo> to long no confirmation
[11:21] <zakame> dholbach++
[11:21] <dholbach> MrDumbo: did you file a support request?
[11:22] <MrDumbo> might have done it wrong...
[11:22] <MrDumbo> a well going to try it later.
[11:24] <MrDumbo> how do you tag it?
[11:25] <highvoltage> 021-918-2116
[11:25] <highvoltage> ugh, sorry, pasted to wrong window
[11:28] <MrDumbo> grr hate it when bugs are reported at wrong places
[11:28] <MrDumbo> they can't expect me to check all distro's bugtrackers
[11:30] <MrDumbo> https://bugs.launchpad.net/gmpc/+bug/102595 <-- anyway to close that, because it's fixed
[11:30] <ubotu> Launchpad bug 102595 in gmpc "adding all tracks from an album should sort by track number" [Undecided,Unconfirmed]  
[11:32] <imbrandon> MrDumbo, i marked it as fix released upstream but it shouldent be closed in ubuntu untill its uploaded there
[11:32] <imbrandon> and you dont have to check all distros bug trackers, LP tracks bugs upstream in your tracker
[11:32] <imbrandon> just FYI
[11:32] <MrDumbo> no, how can I possible track all the f*** bug trackers
[11:32] <MrDumbo> I don't have time for that
[11:33] <imbrandon> and as i just said why would you need to ?
[11:33] <MrDumbo> I doubt if launchpad does
[11:33] <imbrandon> sure it does, thats one of its deatures
[11:33] <imbrandon> features*
[11:33] <MrDumbo> this bug, I never heard of it, until somewhen sended me a patch (but most of the time it's completely passing me by)
[11:33] <imbrandon> but even if it dident why would you need to ?
[11:34] <MrDumbo> I want to know about bugs in my programs.. so I can fix them?
[11:34] <imbrandon> rigth and upstream bug distros file upstream as well as in their trackers , or should just for that very reason
[11:34] <imbrandon> and thats why LP will track your bug tracker
[11:34] <MrDumbo> I _never_ had that.
[11:35] <MrDumbo> dunno about launchpad have to admit that
[11:35] <MrDumbo> but with other distro's....
[11:35] <imbrandon> MrDumbo, then i am sorry you have not experinced the joys of opensource
[11:35] <MrDumbo> sorry just a bit of a bad mood..
[11:35] <imbrandon> i can see
[11:35] <imbrandon> i'm just trying to tell you you are a bit offbase :)
[11:36] <imbrandon> yes things get over looked from time to time but over all you dont have to 
[11:36] <MrDumbo> imbrandon: I think it's just a waste, it often happens after months I get pointed in a bug in the gentoo tracker, or on some debian ml... 
[11:36] <MrDumbo> anyway, back to why I started..
[11:36] <MrDumbo> gmpc version in ubuntu is years old.
[11:36] <imbrandon> MrDumbo, then do the "right thing" and who ever it is pointing it out to you needs to file it upstream, gentoos tracker is for gentoo specific issues just as debians and ubuntu's
[11:37] <dholbach> zakame: I archived it
[11:37] <dholbach> zakame: it had no reply for more than a month
[11:37] <zakame> dholbach: ok, gotta update my revu page :D
[11:37] <zakame> ajax-ing revu would be great though :D
[11:37] <dholbach> TheMuso: is ardour2 on REVU really necessary?
[11:37] <MrDumbo> anyway, I have to go... 
[11:38] <dholbach> using bzr for package reviews would be nice
[11:38] <dholbach> TheMuso: (given that the new version is in as ardour already)
[11:40] <zakame> now sdlmame
[11:45] <jussi01> evening all
[11:45] <jussi01> hello dholbach
[11:45] <dholbach> heya jussi01
[11:45] <zakame> yo jussi01
[11:45] <zakame> thanks dholbach
[11:46] <jussi01> hey zakame
[11:47] <dholbach> jussi01: take a look at the bugs tagged as 'needs-packaging'
[11:48] <pochu> And RFP in Debian :)
[11:48] <jussi01> dholbach: yeah, will do, just thought someone might have a little something that they didnt have time to do...
[11:48] <jussi01> pochu: of course :D
[11:48] <shawarma> dholbach: You looked at system-config-samba a bit earlier. I've uploaded a new version with fixed dpatch and explained the libuser1-dev dependency. 
[11:53] <shawarma> dholbach: Thanks for looking at it!
[12:00] <TheMuso> dholbach: afaik I archived ardour2 ages ago on revu.
[12:00] <TheMuso> dholbach: Espeak-data is arch specific, as it needs to be either little or big endian.
[12:02] <dholbach> shawarma: ok, will look at it again
[12:02] <dholbach> TheMuso: ah ok
[12:02] <dholbach> TheMuso: I'll archive it now - it's still there
[12:03] <TheMuso> dholbach: Done already.
[12:03] <dholbach> ok
[12:03] <TheMuso> I ts popped up again, because someone commented on it.
[12:03] <TheMuso>  /c
[12:03] <TheMuso> gah
[12:03] <dholbach> ok, the page looks better and better
[12:03] <dholbach> if you all have some spare minutes, please help out :)
[12:05] <zakame> salut jsgotangco
[12:05] <jsgotangco> hi
[12:06] <zakame> hmm folks aren't using the debian/changelog effectively
[12:29] <jussi01> gah, i hate launch pad... how do you search bugs by tag?
[12:34] <StevenK> jussi01: Click the Advanced search link
[12:37] <geser> jussi01: go to the Ubuntu bug list, expand Tags on the left side, and click on the tag you want
[12:39] <zakame> would be nice if it were a tagcloud though, long tag list is long
[12:39] <jussi01> yeah, is true
[12:40] <jsgotangco> yes its one of the things i hate most
[01:23] <zakame> wb \sh
[02:05] <lionel> There is a MOTU Q/A session on classroom now?
[02:06] <pochu> lionel: There is
[02:17] <zakame> hmm xmms2 now builds, but fails on amd64
[02:17] <zakame> > default/src/plugins/sid/sidplay_wrapper.o: relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC
[02:17] <zakame> > default/src/plugins/sid/sidplay_wrapper.o: could not read symbols: Bad value
[02:36] <xxxxx1> morning people!
[02:52] <jussi01> morning xxxxx1
[02:53] <jussi01> FAR OUT!!... :( :( :(
[02:53] <xxxxx1> :)
[02:53] <jussi01> I just had my upload rejected...
[02:53] <jussi01> oh well, I gues i just have to go fix it...
[02:54] <Hobbsee> jussi01: which one?
[02:54] <jussi01> mnemosyne Hobbsee
[02:54] <Hobbsee> ahhh
[02:54] <Hobbsee> why?
[02:54] <Hobbsee> licencing?
[02:54] <jussi01> some small copyright issue
[02:54] <jussi01> yeah
[02:55] <jussi01> I've just rejected the mnemosyne upload to gutsy. Some pyqt_ui files
[02:55] <jussi01> have work from "Jarno Elonen <elonen@iki.fi>" who is not mentionned to
[02:55] <jussi01> debian/copyright, could you fix that and upload a new revision?
[02:56] <jussi01> does that mean, just have to add him to the copyrights?
[02:57] <DarkSun88> Hi all
[02:58] <xxxxx1> hello DarkSun88 
[03:03] <zakame> heya jussi01
[03:03] <jussi01> hi zakame
[03:05] <leonel> hello  everyone
[03:05] <jussi01> hi leonel
[03:05] <jussi01> wha... is it wake up tim in the us or smthing?
[03:05] <Hobbsee> likely, yeah
[03:05] <leonel> in mx  is ...
[03:05] <zakame> yo leonel
[03:05] <leonel> hey zakame
[03:06] <leonel> I'm trying  to make  a debootstrap gutsy  in feisty  but says I don't have  the gutsy script 
[03:07] <zakame> have you updated/
[03:07] <zakame> ?
[03:07] <bluekuja> leonel, anyway when you mark a merge in progress, dont wait 2 weeks to do it
[03:07] <RainCT> hi
[03:07] <bluekuja> (talking about dbmail)
[03:08] <xxxxx1> leonel: update your debootstrap
[03:08] <leonel> bluekuja: ok  I'll quit then
[03:08] <bluekuja> leonel, I've seen it "to do" on mom and I did it
[03:08] <bluekuja> leonel, you can close your bug then
[03:08] <bluekuja> and thanks for working on it
[03:09] <leonel> bluekuja: I've spent this time  finding a way to fix dapper's clamav to take  that  merge   but if you need that merge to be done  I'll quit  clamav  or dbmail  
[03:10] <bluekuja> leonel, no clamav is ok
[03:10] <bluekuja> I just done dbmail
[03:10] <bluekuja> so feel free to do clamav
[03:10] <bluekuja> ;)
[03:10] <zakame> then we'll probably have image macros for REVU day and HUG day :D
[03:10] <leonel> then remove me  from dbmail
[03:10] <Hobbsee> zakame: hrm?
[03:10] <bluekuja> leonel, kk
[03:11] <zakame> Hobbsee: just idling, or prepping up for another REVU round :)
[03:11] <zakame> but first, wash dishes...
[03:11] <Hobbsee> hehe
[03:11] <Hobbsee> REVUing just makes things sit in the NEW queue for longer
[03:12] <leonel> xxxxx1: I've just installed debootstrap 
[03:13] <leonel> xxxxx1: says    no such script   /usr/lib/debootstrap/scripts/gutsy
[03:13] <zakame> leonel: debootstrap from feisty-updates?
[03:13] <xxxxx1> xxxxx1: yep. probably your debootstrap is out-of-date
[03:14] <xxxxx1> No packages found matching deboostrap.
[03:14] <xxxxx1> ops
[03:14] <xxxxx1> ii  debootstrap    0.3.3.3ubuntu3~feisty1 Bootstrap a basic Debian system
[03:14] <xxxxx1> :)
[03:14] <zakame> yes, that's from feisty-updates
[03:15] <xxxxx1> leonel: paste your version
[03:15] <leonel> xxxxx1: 0.3.3.2ubuntu3    but I have  feisty-updates enabled .
[03:16] <Hobbsee> feisty debootstrap wouldnt know about gutsy
[03:16] <Hobbsee> (and why are you wanting to debootstrap anyway?
[03:16] <Hobbsee> )
[03:16] <StevenK> I managed to debootstrap gutsy by symlinking gutsy to feisty
[03:16] <Hobbsee> i was about ot point tha tout
[03:16] <shawarma> zakame: Could you take another peek at http://revu.tauware.de/details.py?upid=5521 ? That would be much appreciated.
[03:17] <leonel> Hobbsee: to use it instread  booting  a virtual server  ..
[03:17] <StevenK> Hobbsee: Beat you. :-P
[03:17] <Hobbsee> leonel: chroot is easier, imo.
[03:17] <xxxxx1> nope. the last version of deboostrap for feisty have gutsy script too
[03:17] <Hobbsee> or last time i checked
[03:17] <StevenK> Hobbsee: Ouch!
[03:17] <xxxxx1> is in feisty-backports
[03:18] <Hobbsee> oh neat
[03:18] <xxxxx1> leonel: is in feisty-backports
[03:18] <Hobbsee> for those of you who actually *run* backports, yes.
[03:18] <leonel> xxxxx1: ok thanks
[03:18] <xxxxx1> :P
[03:18] <xxxxx1> Hobbsee: *little* detail :>
[03:20] <leonel> xxxxx1: thanks
[03:21] <Hobbsee> rather, yes.
[03:23] <mok0> Are you people using cdbs for package building?
[03:23] <xxxxx1> mok0: yep. many packages are using
[03:24] <mok0> It seems like development on it has stopped
[03:24] <mok0> Latest commit I can find is 3 years old
[03:24] <shawarma> mok0: How do you figure that?
[03:24] <shawarma> mok0: http://changelogs.ubuntu.com/changelogs/pool/main/c/cdbs/cdbs_0.4.49ubuntu1/changelog
[03:25] <mok0> 15:24 -!- Subhuman [n=jack@host86-139-44-50.range86-139.btcentralplus.com]  has  quit [Read error: 110 (Connection timed out)] 
[03:25] <mok0> 15:24 < mok0> Latest commit I can find is 3 years old
[03:25] <mok0> 15:24 < shawarma> mok0: How do you figure that?
[03:25] <mok0> ge86-139.btcentralplus.com]  has  quit  [Read error: 110 (Connection timed out)] 
[03:25] <shawarma> 15:24 < shawarma> mok0: http://changelogs.ubuntu.com/changelogs/pool/main/c/cdbs/cdbs_0.4.49ubuntu1/changelog
[03:25] <mok0> ge86-139.btcentralplus.com]  has  quit  [Read error: 110 (Connection timed out)] 
[03:26] <shawarma> "If it works, don't fix it"
[03:26] <mok0> Arrgh my mouse is failing me in cut/paste
[03:26] <shawarma> But cdbs indeed *has* been updated in the last three years.
[03:26] <Riddell> is there a reason for putting two spaces before Homepage in debian/control?
[03:27] <persia> Riddell: It 1) ensures that the line is not broken, and 2) acts as a signal for automatic parsing on packages.ubuntu.com
[03:27] <mok0> ge86-139.btcentralplus.com]  has  quit  [Read error: 110 (Connection timed out)] 
[03:27] <zakame> shawarma: great work, a little more improvement and its a go :)
[03:27] <Riddell> persia: how does it manage 1)?
[03:28] <zakame> Why isn't Homepage promoted to a full debian/control field?
[03:28] <xxxxx1> mok0: https://code.launchpad.net/cdbs/
[03:28] <persia> Riddell: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Description
[03:28] <StevenK> zakame: That why lies madness.
[03:29] <StevenK> way, even
[03:29] <persia> zakame: It's relatively new (a couple of years), and not everything has a homepage.
[03:29] <zakame> well it can be an optional field, maybe X-Homepage
[03:29] <shawarma> zakame: I added the get-orig-source because a previous comment told me to. :)
[03:29] <zakame> StevenK: lolsparta
[03:30] <persia> zakame: If we did that, we'd need mangling to stay consistent with Debian.
[03:30] <zakame> persia: yeah, I guess let Debian do it first then :)
[03:30] <shawarma> zakame: I don't quite understand the third paragraph in your comment?
[03:30] <persia> zakame: If you're curious about that, read debian-devel archives :)
[03:33] <zakame> shawarma: get the SRPM, transform it into a .tar.gz, then make that the .orig tarball; note it in README.Debian and in the changelog
[03:33] <persia> Rather README.Debian-source, no?
[03:33] <shawarma> zakame: That's what the get-orig-source target does?
[03:34] <zakame> if there's a system-config-samba-.+.tar.gz that exists separately of the SRPM, even better to grab that
[03:34] <persia> shawarma: You still need a README.Debian-source, even if it just says "look at get-orig-source:"/
[03:34] <zakame> shawarma: yeah, but instead do it manually
[03:34] <shawarma> zakame: This is not something that the buildd are going to do.. It's something one can do manually to verify that I didn't put stuff into it.
[03:34] <persia> zakame: Why manually?
[03:35] <shawarma> zakame: Well, of course I'd do it manually, too. I need to to so that I can upload my package.
[03:38] <zakame> persia: less confusion, and get-orig-source is optional, after all; I'd prefer to have essential rules as much as possible
[03:39] <shawarma> zakame: So you prefer no get-orig-source ?  I frankly don't care either way.
[03:39] <persia> zakame: Ah.  I'm a strong believer in get-orig-source, as 1) it's easier for the paranoid to verify, and 2) it makes package update much easier (for a well written get-orig-source).  I use it like one might use uupdate (although it requires manual changelog update).
[03:40] <zakame> shawarma: up to you then
[03:40] <persia> shawarma: Either way, you still need README.Debian-source.
[03:40] <zakame> persia: there is already uscan for that
[03:40] <persia> zakame: Doesn't work very well for RCS snapshots :)
[03:41] <persia> (or bz2 dists, or rpm conversions, etc.)
[03:41] <zakame> ah, well there's no argument for RCS snapshots then
[03:41] <shawarma> persia: Just added that.
[03:43] <zakame> persia: but get-orig-source can only work against the current upstream version for a specific package, right?  adding more logic on that rule just to emulate what uupdate/uscan does is overkill
[03:44] <leonel> debootstrap for gutsy in feisty  working ... didn't had  feisty-backports  enabled 
[03:44] <leonel> thanks
[03:44] <persia> zakame: Depends.  I tend to use something like that documented in https://wiki.ubuntu.com/MOTU/Packages/CommonPackagingMistakes/ChangingTheOrigTarball, which isn't that much logic.
[03:48] <zakame> interesting
[03:48] <persia> zakame: The idea being to leverage uscan where possible, and emulate some of it where not, but to not have to go through a manual process for each update.
[03:49] <icf7> What should be the initial changelog entry?
[03:49] <persia> icf7: "Intial Upload (LP: #bugnumber)"
[03:50] <icf7> persia: Thanks, zakame said the opposite. What should the bug on Launchpad contain?
[03:51] <zakame> icf7: I said the opposite because initial ubuntu changes ought to be documented, as should all subsequent changes afterward
[03:51] <persia> icf7: Amusingly, zakame and I have different opinions (both usually correct) about many things.  If you listen to me, the bug should be a "needs-packaging" bug on launchpad, set to "In Progress" and assigned to you.
[03:51] <zakame> persia: actually I'm beginning to agree about the get-orig-source bits
[03:51] <zakame> :_
[03:51] <zakame> :)
[03:52] <persia> In this case, I think I agree with zakame, that any patches or special adjustments needed for packaging should be noted.  For a package that works without anything fancy, you can probably simplify.
[03:52] <zakame> brb, washing dishes :D
[03:52] <persia> zakame: It's the process of debate that leads to a good answer.  I'm not sure it's a good thing that we're both moving towards agreement :)
[03:52] <zakame> thanks persia for the link :)
[03:53] <shawarma> zakame, persia: There. http://revu.tauware.de/details.py?upid=5522 Now it has both get-orig-source and a README.Debian-source. Are we happy?
[03:53] <persia> zakame: It's one of my pet notes.  If you have a good candidate for a RPM conversion, it would be nice to have that too, as the only one I've seen needs a lot of manual work for an upgrade.
[03:54] <zakame> persia: well it makes sense for the RCS case; when there are no pre-existing snapshot tarballs the get-orig-source becomes essential :)
[03:55] <persia> zakame: Exactly.
[03:56] <persia> shawarma: I don't see anything blocking, but the README.Debian-source feels different than those I've seen before (although I don't have a good example), and the get-orig-source would be better abstracted so it didn't need manual update each time (and a watch file might also be good).  All of these could as well be addressed in a later revision.
[03:56] <soc> hi
[03:57] <shawarma> persia: did I just hear you say "ACK"? :)
[03:57] <icf7> another question: How do I set up uscan to work according to the Debian policy so that it works in any directory? Is it intended to temporarily cd to the right directory and run uscan?
[03:57] <persia> shawarma: Hrm.  Let me download and run the standard tests...
[03:58] <persia> icf7: In what context?  Usually uscan is run from the package base directory.
[03:58] <shawarma> persia: Actually, I've never notived neither get-orig-source nor README.Debian-source in any package before. 
[03:58] <icf7> persia: I wanted to use uscan in rules:get-orig-source, is that wrong?
[03:59] <persia> shawarma: Google gives 5000 results for README.Debian-source.  One of these might be a good example.  It's only distributed in the source package, and only sometimes (README.Debian-source is "should" and get-orig-source is at the whim of the maintainer).
[03:59] <shawarma> persia: Oh, it's only in the source package? 
[03:59] <shawarma> persia: I made mine install it.
[04:00] <persia> icf7: You only want get-orig-source if you repack the orig.tar.gz.  If you're doing that, take a look at the example in the wiki.
[04:00] <icf7> persia: Ok, thank you
[04:00] <persia> shawarma: Ah, You don't want to install it - it's just for people investigating the source.
[04:00] <shawarma> persia: Ok, then. When you check the package, just ignore it. When I upload it will be gone.
[04:01] <persia> shawarma: OK, or if you are fast, I'll just grab the new diff.gz & dsc
[04:01] <shawarma> persia: There's not point in uploading it to REVU again, if that's all there's wrong.
[04:01] <shawarma> persia: I'm not. :)
[04:01] <persia> shawarma: Right.  Sounds fine to me.
[04:02] <shawarma> persia: Just ping me when/if you're satisfied with the package.
[04:03] <persia> shawarma: I'm just guessing that you already satisfied ScottK?  I don't understand the python bits.
[04:03] <colinl> hi! does anyone know what's the use of such a package? http://packages.ubuntu.com/gutsy/virtual/claws-mail
[04:04] <shawarma> persia: I think I've argumented sufficiently for my packacing with regard to the python policy. I've also got examples of other packages that do the same thing.
[04:04] <persia> colinl: It's a leftover from some snapshot packaging - it allows plugins that worked with both claws and claws^snapshot to work.
[04:04] <persia> shawarma: OK.
[04:05] <colinl> persia: I see - but how comes I can find no real related package (snapshot or not) on packages.ubuntu.com ?
[04:06] <persia> colinl: In part because claws had some issues lately, and in part because the snapshot merge happened some time back.  The package may no longer be useful (although I haven't investigated in recent releases).
[04:07] <colinl> persia: thanks. do you know where I can find buildbot logs or any other relevant info about these issues?
[04:08] <Riddell> persia: thanks (for Homepage link)
[04:08] <icf7> persia: Sorry for searching the wrong way, but I can't find any repackaging example on wiki.ubuntu.com. COuld you give me a pointer?
[04:11] <persia> shawarma: 1) If you're moving the icon, you shouldn't create /usr/share/pixmaps, and 2) if you could extract the changelog from system-config-samba.spec and dump it (compressed) to /usr/share/doc/$package, it would be great (these are linda errors).
[04:11] <persia> icf7: https://wiki.ubuntu.com/MOTU/Packages/CommonPackagingMistakes/ChangingTheOrigTarball
[04:12] <persia> colinl: I'm really not sure how to easily hunt those down for virtual packages, sorry.
[04:12] <colinl> np. I suppose things will get sorted out eventually :)
[04:12] <colinl> thanks for your answers!
[04:12] <dholbach> thanks lionel for running the Q&A session
[04:12] <shawarma> persia: Am I moving the icon?
[04:12] <lionel> dholbach: no pb
[04:16] <persia> shawarma: My mistake.  I thought you were from 05_fixperms.dpatch, but looking more closely, it appears to be an upstream bug.  The makefile defines PKGIMAGEDIR, but doesn't use it when creating directories, and fails to include a '/' in `install pixmaps/*.png $(DESTDIR)$(PKGIMAGEDIR)`. which has odd results.
[04:17] <icf7> persia: This example requires a newer uscan than the one in feisty. Should I develop in gutsy by now?
[04:18] <persia> icf7: How doesn't it work?  I believe that example was developed on a feisty system.
[04:18] <icf7> persia: --force-download is not available
[04:21] <persia> icf7: I'm sorry.  I remembered it being developed in April, but I guess it was just as the gutsy archives opened, and the developer tracked that.  Sorry for the confusion.
[04:28] <zakame> back from washing dishes :)
[04:30] <persia> zakame: I had a thought about the uscan case (bz2).  Could the output of `uscan --report-status` be parsed to determine $(VER)?
[04:31] <zakame> probably, lemme check
[04:32] <shawarma> persia: I don't get these errors from linda? 
[04:34] <persia> shawarma: I got the output from `linda -v -f long -t E,I,W,X system-config-samba_1.2.35-0ubuntu1_amd64.changes`, but I'd guess the same would come from any architecture.
[04:35] <shawarma> persia: I thought -t was supposed to *limit* the output, but I get *more* warnings, when I use your command line.
[04:36] <persia> shawarma: Yep  "-t" limits the output to the selected types, but the default types are not all of E,I,W,X :)  My command line tells linda to be as verbose as she can be.
[04:37] <shawarma> persia: Gah... 
[04:37] <shawarma> persia: I've been missing out all this time!
[04:37] <leonel> once a merge is done  how long takes to be available  to install  ?
[04:37] <persia> shawarma: use `lintian -iIv` for the equivalent from a perl perspective.
[04:37] <zakame> gaah, uscan is too verbose for use in scripting :/
[04:38] <persia> leonel: After the merge, it is uploaded, built, and then distributed.  Depending on the builds (and failures therein), this may take as much as a month.
[04:39] <leonel> persia: thanks
[04:39] <persia> zakame: That was my problem too :)  I was hoping you might know some nifty make trick to collect only the right information.
[04:39] <zakame> there are blocks caused by FTBFSes as well, check xmms2 for instance.
[04:39] <persia> leonel: I forgot about xmms2 - ignore the part about "as much as a month".  There's not really a limit.
[04:43] <zakame> persia: something ugly like `uscan --report | grep ^Newest | awk '{print $7}'`, needing to chop off the trailing comma
[04:44] <luisbg> where can I read about what debian/install does?
[04:44] <zakame> apropos dh_install
[04:45] <zakame> x/apropos/c/man/
[04:47] <persia> zakame: So, "VER:=$(shell uscan --report | grep ^Newest | cut -f 7)" might work?  On the other hand, I suddenly realise that doing something like this would defeat the point of get-orig-source, and instead be a get-newest-source.  Thanks though :)
[04:47] <zakame> yeah, get-newest-source would be more like it hehe
[04:48] <jussi01> hello persia
[04:48] <persia> hi jussi01
[04:48] <persia> jussi01: Did you find a new package earlier, or are you still looking?
[04:49] <jussi01> no, didnt find, still looking... but i need to fix mnemosyne
[04:49] <zakame> hmmm, if we know at the time of the get-orig-source call about the md5sum of the original source, shouldn't we use that to verify if the source we indeed get later is the right and trusted source?
[04:49] <luisbg> thanks a lot zakame 
[04:49] <jussi01> persia: did you see earlier?
[04:49] <shawarma> persia: http://revu.tauware.de/details.py?upid=5523 There.
[04:49] <persia> zakame: That fails whenever get-orig-source is required, as gzip --best is not guaranteed to generate the same md5sum twice in a row.
[04:51] <zakame> immediately, at the rule's call?
[04:51] <shawarma> persia: ffs... hang on.
[04:52] <persia> shawarma: Too late.  Already built :)  Let me know when you want me to grab a new one.
[04:53] <persia> zakame: No, the rule won't fail, just the md5sum of the orig.tar.gz will only match by accident (and md5sum is designed to make this rare), so the user cannot use it for verification.
[04:53] <shawarma> persia: You can take a look at it. All I've changed now is I've renamed the upstream changelog to changelog.gz (from changelog.upstream.gz).
[04:54] <shawarma> persia: Unless you find anything else I won't bother with uploading to REVU.
[04:54] <soc> hi one question about gimp
[04:54] <soc> i updated it with uupdate to 2.3.18
[04:54] <soc> whats the command to configure, make, package it?
[04:55] <persia> shawarma: Since that's the only remaining error, I'm happy.  Please upload again, just so my ACK is on a clean package :)
[04:55] <mok0> soc!!!
[04:55] <soc> yeah it's me :-)
[04:55] <soc> i decided to just build a package for now, without messing too much
[04:56] <persia> soc: debuild for local build, pbuilder for traball build, or sbuild for schroot build.
[04:56] <persia> s/tra/tar/
[04:56] <soc> if that works i'll start to modify it piece by piece
[04:56] <soc> ok, so just debuild
[04:56] <soc> without arguments?
[04:56] <zakame> persia: ah... I was rather hoping the rule would immediately fail at the md5sum mismatch, instead of propagating to dpkg-source(?)
[04:56] <bluekuja> persia: heya
[04:56] <soc> do i need fakeroot for that=
[04:56] <soc> or sudo?
[04:57] <bluekuja> persia: gonna take care of that missing .desktop you mentored
[04:57] <jussi01> persia: did you see my message about mnemosyne earlier?
[04:57] <zakame> fakeroot
[04:57] <bluekuja> persia: it has been assigned to me
[04:57] <persia> zakame: I think that's part of why get-orig-source is so optional at this point - it's not really decided yet (in Debian) how to do it right.
[04:57] <shawarma> Any revu admins around? I need to have system-config-samba* removed from incoming (ctrl-c by accident)
[04:57] <persia> bluekuja: Great.  Thanks.  Let me know if you need any help.
[04:57] <mok0> How come the debdiffs on revu seem reversed?
[04:57] <persia> shawarma: I'll take care of it.
[04:57] <bluekuja> persia: seems easy, gonna have results this evening/night
[04:58] <shawarma> persia: Oh, great. Didn't know you were "one of them" :)
[04:58] <bluekuja> persia: ;)
[04:59] <zakame> persia: indeed, still, its a great help for the situations you listed :)
[05:00] <mok0> It seems my fixes are getting removed :)
[05:00] <DarkSun88> http://paste.ubuntu-nl.org/25550/
[05:00] <persia> shawarma: Cleaned.  I'm not actually an admin, but I can help :)
[05:00] <DarkSun88> Is there errors in this debdiff?
[05:00] <DarkSun88> s/Is/Are
[05:00] <shawarma> persia: interesting... :)
[05:00] <mok0> Anyways: I have a new upload on revu (upid=5478) that I seek further review on...
[05:00] <persia> mok0: Are you looking at the URL of the latest upload?
[05:01] <soc> mh sudo debuild tells me that:
[05:01] <soc> build conflicts: libgimp2.0
[05:01] <mok0> I'll check...
[05:01] <persia> DarkSun88: it's hard to tell from a pastebin.  Does it apply cleanly (with `patch -p1 < ../mydebiff` from the package directory?
[05:02] <DarkSun88> No, I'll do.
[05:02] <mok0> persia: yes
[05:02] <persia> mok0: Which URL?
[05:02] <shawarma> persia: Final version is up: http://revu.tauware.de/details.py?upid=5524
[05:03] <DarkSun88> persia: I've compiled with a server and tells me this: http://packages.linuxdc.it/gutsy/result/vpnc_0.4.0-3ubuntu1/vpnc_0.4.0-3ubuntu1_i386.build
[05:03] <mok0> persia: Ah! I didn't get that yet
[05:03] <mok0> persia: I am rambling
[05:04] <mok0> http://revu.tauware.de/details.py?upid=5495
[05:05] <mok0> persia: I got confused by your message to shawarma...
[05:05] <persia> DarkSun88: It looks like one of the patches doesn't apply cleanly.  My guess would be that something in 06_stolen_from_head modified a line that affected 07_gcc_optimizations.  You'll need to clean up the latter to match the changes in the former.
[05:06] <DarkSun88> persia: I'll check it. Thanks a lot.
[05:07] <persia> shawarma: Advocated :)
[05:07] <shawarma> persia: Great. Uploaded. :)
[05:07] <shawarma> persia: Thanks a million, dude.
[05:08] <persia> shawarma: Don't forget to archive and send the REVU mail to ubuntu-motu@ :)
[05:08] <shawarma> persia: after the dev-team meeting. :)
[05:09] <persia> mok0: The debdiff links are reverse debdiffs to previous versions.  Your would be reverted if these were applied, but it's handy for reviewers to see what changed.  Take a look at http://revu.tauware.de/details.py?upid=5459 if you want to see forward debdiffs.
[05:10] <persia> shawarma: No rush - just a reminder, as the docs are sparse :)
[05:12] <persia> bluekuja: Did you check that .desktop with desktop-file-validate 0.13?  The updated spec is now implemented.
[05:13] <bluekuja> persia, currently finishing another thing, gonna move there soon
[05:13] <bluekuja> persia, gonna ping you when done, dont worry
[05:13] <bluekuja> ;)
[05:13] <bluekuja> I didnt added it
[05:13] <bluekuja> *add
[05:13] <bluekuja> maurizio did
[05:13] <bluekuja> I think
[05:14] <persia> bluekuja: My apologies - I'm not looking carefully enough :)
[05:14] <bluekuja> persia: :)
[05:16] <zakame> hmm, why a 299KB diff?
[05:17] <zakame> grr kate-in-konqueror should have better folding for aggregated diffs :/
[05:18] <bluekuja> zakame, huh?
[05:18] <bluekuja> zakame, which diff?
[05:18] <zakame> bluekuja: http://revu.tauware.de/revu1-incoming/fische-0705270805/fische_2.0-0ubuntu1.diff
[05:19] <bluekuja> zakame, leave it, gonna be synced from debian
[05:19] <bluekuja> ;)
[05:20] <zakame> should be nuked from REVU then ;)
[05:20] <bluekuja> zakame, yup
[05:20] <bluekuja> should be archived
[05:22] <persia> bluekuja: If you're going to sync, please add a comment on REVU, so that nobody starts reviewing. (sometimes packages get reviewed without announcement, especially on REVU DAY).
[05:22] <bluekuja> persia, yeah, gonna add it now
[05:24] <Hobbsee> archived
[05:24] <bluekuja> Hobbsee, thanks ;)
[05:25] <luisbg> "dpkg-deb: building package `ubuntustudio-menu' in `../ubuntustudio-menu_0.1_all.deb'." <-- but not deb in the .. folder ... :S
[05:26] <shawarma> persia: I'm an idiot. How do I archive stuff on REVU?
[05:27] <zakame> shawarma: there's an archive button on each row at the main page
[05:27] <zakame> one for each package
[05:27] <shawarma> zakame: Not on my machine, there isn't...
[05:27] <Hobbsee> shawarma: if you're listed as a reviewer
[05:28] <persia> shawarma: First comment, then archive (commenting automatically unarchives).  Archiving is done from the front page.
[05:29] <persia> luisbg: Does it claim to build, but doesn't generate the .deb?  Is the source somewhere one may look at it?
[05:30] <shawarma> Hobbsee: Reviewer? Hmm.. That might be it.
[05:30] <luisbg> persia, can upload it to bzr if you want to look at it
[05:31] <persia> luisbg: Sure, if you want another eye.
[05:32] <persia> shawarma: I'll archive it :)
[05:32] <luisbg> persia, sure thanks! give me a sec
[05:32] <shawarma> persia: Thanks!
[05:32] <bddebian> Heya gang
[05:33] <zakame> yo bddebian! :D
[05:33] <bddebian> Hi zakame
[05:35] <shawarma> Hobbsee: Being a reviewer means being member of some team, right? which team is that exactly?
[05:35] <Hobbsee> shawarma: ask siretart 
[05:35] <Hobbsee> it's not a LP team
[05:35] <persia> bddebian: I'm about to upload a fix for bug #119887: do you have any reservations about this?
[05:35] <ubotu> Launchpad bug 119887 in apt-file "merged package contains spurious files" [Wishlist,In progress]  https://launchpad.net/bugs/119887
[05:35] <shawarma> Hobbsee: Ah, ok then.
[05:35] <bddebian> persia: No, thanks!
[05:35] <persia> shawarma: You don't need to be in any more teams than you already are, but you need a REVU-admin to add you.
[05:36] <persia> bddebian: Thanks for the confirmation :)
[05:36] <shawarma> persia: Ok. thanks for clarifying. I thought I was going nuts as I couldn't see that archive button :)
[05:37] <bddebian> Sorry I've been out of the picture lately but I suppose that's probably good for you all ;-P
[05:37] <shawarma> Glad to have you back, bddebian.
[05:37] <persia> bddebian: Not really : REVU has missed you
[05:38] <bddebian> shawarma: I'm probably not "back" until after July but thanks! :-)
[05:39] <persia> zakame: After looking at the most recent REVU upload notice, I am completely changing my advice on initial changelogs.  Thanks.
[05:40] <zakame> persia: works both ways :) I find the get-orig-source option something worth considering to include :)
[05:44] <beuno> persia: +1
[05:45] <beuno> I''ve been downloading packages from Ubuntu to get them into Debian
[05:45] <beuno> and it's been a nightmare  :(
[05:45] <zakame> hmm like kayaking upstream
[05:46] <beuno> zakame: something like that  :D
[05:46] <shawarma> beuno: Why? Too many packages? Too crappy?
[05:47] <persia> beuno: You're probably getting the best feedback.  Would you mind starting a page on the wiki (Category MOTU, under /MOTU/Packages/ namespace)?  I'd be happy to add comments, and later formalise and prettify.
[05:47] <beuno> shawarma: *very* badly packaged, non working packages at all (dependencies that don't compile)
[05:47] <beuno> etc etc etc
[05:48] <beuno> persia: I'm getting a LOT of feedback here
[05:48] <persia> beuno: Also, if you have time, and can take a look at our reviewing practices, I'm sure we could learn to make your job easier :)
[05:48] <beuno> the @ubuntu.com address in my nametag gets me a lot of feedback   :D
[05:48] <luisbg> persia, http://codebrowse.launchpad.net/~luisbg/freemix/base/files/bethencourt%40gmail.com-20070614153440-29evu6xpbquexu00?file_id=ubuntustudiomenu-20070614153254-omrhjatjx93najmz-1
[05:48] <bddebian> hehe
[05:48] <luisbg> persia, thankss!!
[05:48] <persia> beuno: heh :)  Even a very rough list would be a great help in getting started.
[05:48] <persia> luisbg: I'll take a look in a few minutes.  Thanks.
[05:49] <beuno> persia: I'd live to get involved, yes
[05:49] <beuno> I believe much more attention should be paid
[05:49] <luisbg> persia, thanks to you ;)
[05:50] <beuno> and a clear way to remove a crappy package
[05:50] <beuno> I've been filing some bugs against them
[05:50] <beuno> but I'm nopt sure that will get them removed
[05:50] <beuno> I'm also trying to fix them, uplaod them into debian so t hey get downloaded properly
[05:50] <siretart> shawarma: it is a flag in the postgres database on tiber
[05:50] <persia> beuno: There is a mechanism for package removal.  If there are any you want sheparded, please send me a list in email.
[05:50] <beuno> I do think a team specially created for that would help a lot
[05:50] <beuno> persia: great, I will gather a list  :D
[05:51] <persia> beuno: Thanks.
[05:51] <shawarma> siretart: I see. Could it be because I've started to use another e-mail to log in? I believe i used to see the archive button..
[05:51] <siretart> shawarma: right. revu accounts are just emails, and only that
[05:52] <shawarma> siretart: Ok. could you promote soren@ubuntu.com, perhaps?
[05:53] <beuno> persia: how can it be that there is a package that doesn't work at all in the repos?
[05:53] <bluekuja> persia: that desktop file is ok, only thing is about encoding that seems to be deprecated now
[05:54] <persia> beuno: <70 MOTUs >10,000 universe packages.
[05:54] <persia> bluekuja: Right, so we should delete that line.
[05:54] <bluekuja> persia: yup
[05:54] <beuno> persia: I'm trying to get a Debian Collaboration Team back together (it's part of my purpose here), and I believe that would also be part of getting things straightened out
[05:54] <beuno> https://launchpad.net/~dct
[05:54] <Hobbsee> beuno: talked to white?
[05:54] <persia> beuno: I hope so.  I'm looking forward to a reinvigorated DCT.
[05:54] <zakame> just checking: we can override Makefile rules right? not just appending to them...
[05:55] <beuno> Hobbsee: white?
[05:56] <Hobbsee> beuno: debian dev.  interested in the same thing
[05:56] <beuno> persia: I've been trying to, but I'm not getting much help
[05:56] <Hobbsee> beuno: utnubu stuff
[05:56] <beuno> Hobbsee: no, but Ill track him down
[05:56] <persia> beuno: What do you need?
[05:56] <beuno> I've been emailing the DCT mailing list
[05:56] <beuno> and contacting specific people
[05:56] <beuno> persia: first thing is to reorganize objectives to a more "possible" objective
[05:56] <beuno> then start actually doing it and recruiting
[05:56] <beuno> I'd say 50% of the work has to do with coordinating teams and people
[05:57] <ScottK-laptop> beuno: Debian Python Modules Team has been very open to Ubuntu people joining and participating.
[05:57] <beuno> ScottK-laptop: yes they have, I've seen several teams working together, and that's great!
[05:57] <beuno> some work is being done quietly
[05:57] <persia> beuno: I don't follow the mailing list too closely (only reviewing archives 1/month or so), but I thought there was positive response to your efforts.  Could you not just update the wiki page, build a community of interested parties (an IRC channel may or may not help for this), and dig in?
[05:58] <persia> MOTU-Games is now entirely within Debian-games as well.
[05:58] <beuno> I also think we should have a very clear and complete FAQ For DDs mocked up so they can understand what happens with there work, how Ubuntu works inside, and how they can help or get help
[05:58] <beuno> persia: yeap, that is exactly what I'm going to do
[05:59] <beuno> I've just been doing a little bit of everything, got 2 packages in NEW waiting after a few days of learning
[05:59] <beuno> it's great to be surounded by geeks  :D
[05:59] <persia> beuno: That's a good idea, but I would recommend that such a FAQ be built in collaboration with the attempts to reinvigorate utnubu, just to make sure DCT and Utnubu procedures are in sync, and everything is smooth.
[06:00] <beuno> persia: yeap, it's a wiki, so we jkust have to make sure they know about it
[06:00] <siretart> shawarma: done
[06:00] <beuno> gather whatever questions they mnay have
[06:00] <beuno> and get them answered
[06:00] <shawarma> siretart: ta
[06:00] <beuno> which many times takes me to very long and rocky trips :D
[06:01] <siretart> in fact, I think Hobbsee/persia could have done that as well
[06:01] <siretart> /srv/revu1-production/scripts/alter_user.py -e soren@ubuntu.com -lreviewer
[06:01] <siretart> is the command line
[06:01] <Hobbsee> ah right
[06:01] <persia> siretart: Cool.  Thanks.  Could you stick that in /etc/motd to make it easy to remember?
[06:02] <beuno> I'll brb, going to a BoF
[06:02] <beuno> not wsure if I have wireless
[06:03] <siretart> persia: please try it to check that there are no problems with file permissions
[06:03] <infinito> hi
[06:03] <infinito> can anyone take a look at this file, to see it its license would eb aproblem for inclusion on ubuntu? http://svn.infinicode.org/index.cgi/pyrenamer/trunk/pyrenamer/src/TreeViewTooltips.py?revision=5&view=markup
[06:03] <persia> siretart: Is it safe to re-run for the same ID?
[06:04] <infinito> im not very good at license policies
[06:04] <siretart> persia: should be. the script does only do things in the postgresdb
[06:04] <persia> siretart: "Altering soren@ubuntu.com to level reviewer", so I'm guessing it works.
[06:04] <siretart> yes, looks file
[06:05] <persia> Anyone have an opinion on running `apt-file update` in apt-file postinst?
[06:05] <mok0>  infinito: Looks like there are no restrictions whatsoever, so it should be OK
[06:06] <beuno_> ok, in the BoF room  :D
[06:06] <infinito> mok0: should i add something to copyright fiel about this license?
[06:07] <infinito> s/fiel/file
[06:07] <ScottK-laptop> infinito: The license is fine.  For debian/copyright you should include the full text of the license.
[06:07] <infinito> ScottK: ok, thanks!
[06:08] <mok0> infinito: I am no expert, but I would regard this as an "artistic" license
[06:08] <persia> infinito: For comparison, look at the BSD license - it's nearly the same.
[06:08] <xxxxx1> y
[06:08] <xxxxx1> s/y//g
[06:08] <xxxxx1> :)
[06:09] <infinito> so in the copyright file i should use something like: for the file blablabla the license is: blablabla
[06:09] <persia> mok0: Except that Artistic sources can be put in the public domain, whereas that cannot.
[06:10] <siretart> persia: done
[06:11] <persia> siretart: Thanks.
[06:12] <infinito> so the copyright file should be like this? http://pastebin.ca/566713
[06:12] <persia> luisbg: sbuild makes a deb for me.  On what archicture were you compiling?
[06:13] <luisbg> persia, i686
[06:13] <luisbg> or x86
[06:13] <luisbg> however you were expecting me to say it =)
[06:14] <persia> luisbg: Strange.  I was actually expecting amd64, as that doesn't build architecture all packages by default.  Now I'm confused as to why it doesn't work for you.
[06:14] <luisbg> persia, I'm doing... debuild -S ; sudo pbuilder build ../*.dsc
[06:15] <persia> Could someone familiar with pbuilder please help luisbg?  I cannot replicate the problem with sbuild.
[06:15] <luisbg> persia, wait... I think I'm only doing the source package
[06:15] <luisbg> let me check something
[06:15] <luisbg> persia, tell me how you do with sbuild
[06:16] <luisbg> and why sbuild instead of pbuilder?
[06:16] <Hobbsee> where are you checking for the resulting deb?
[06:16] <zakame> gn8 all
[06:16] <persia> luisbg: https://help.ubuntu.com/community/SbuildLVMHowto and `sbuild -A -d gutsy ubuntustudio-menu_0.1.dsc`
[06:17] <persia> luisbg: sbuild is just my personal preference (it's what the buildds use).  pbuilder is also fine.
[06:18] <luisbg> persia, ok =) just wanted to know if I should think about switching a little bit more
[06:18] <persia> luisbg: No need to switch.
[06:21] <luisbg> anyone familiar with pbuilder around?
[06:21] <Hobbsee> yes
[06:21] <Hobbsee> you never answered my question, though
[06:22] <Hobbsee> luisbg: ^
[06:23] <luisbg> ahhhh sorry Hobbsee, didn't saw the question :S
[06:23] <persia> In the absence of dissention, I'm configuring apt-file to run update in the postinst.
[06:24] <luisbg> I'm checking in .. of where I run pbuilder, that is the folder where the .dsc hangs around 
[06:26] <Hobbsee> you need to check in /var/cache/pbuilder/result
[06:27] <luisbg> :( that was dumb
[06:27] <luisbg> sorry about that
[06:27] <luisbg> ok... now a more tricky question
[06:28] <luisbg> I'm creating a directory /usr/share/ubuntustudio-menu/ and then moving our applications.menu file there, how do I tell gnome to use this one instead of the one used by default in /usr/share/app-install/desktop
[06:28] <Hobbsee> no problem
[06:28] <luisbg> ?
[06:29] <persia> luisbg: You can't really.  You need to put things in /etc/xdg/menus, but I think those are conffiles, which means you can't actually edit anything already there.
[06:31] <luisbg> I'm looking at the package edubuntu-menus, and I see where he places the .menu file, but not how he changes gnome
[06:34] <luisbg> should I just move to /etc/xdg/menus ?
[06:34] <eletido> can someone link me to a summary of the process of getting a package into universe?
[06:35] <persia> You might want to morror edubuntu, but there are probably other parts to that solution (it's certainly beyond my understanding of how gnome-menus works).
[06:36] <eletido> nvm, found what i was looking for.
[06:53] <mok0> clear
[07:03] <infinito> can anyone take a little time to review http://revu.tauware.de/details.py?upid=5528 ??
[07:06] <pochu> dholbach: will the meeting be here, or in -meeting? In the mail you say here...
[07:06] <dholbach> urg
[07:06] <dholbach> #ubuntu-meeting of course
[07:06] <dholbach> thinko
[07:07] <Hobbsee> dholbach: meeting?  what meeting?  when?
[07:07] <dholbach> followed up
[07:07] <dholbach> "later" MOTU meeting
[07:07] <pochu> Hobbsee: MOTU meeting, tomorrow 13 UTC
[07:08] <Hobbsee> pochu: define "tomorrow"
[07:08] <crimsun> Fri 15 Jun
[07:08] <Hobbsee> tomorrow is a relative term, please specify a day or date.
[07:08] <Hobbsee> thankyou
[07:08] <pochu> Hobbsee: aren't you subscribed to ubuntu-motu@ ?
[07:09] <Hobbsee> oh goody, i'll actually be alive then.  hopefully.
[07:09] <Hobbsee> pochu: i am - hadnt checked my email in the last hour, and there's nothing in the topic about it
[07:10] <persia> Hobbsee: now+20h
[07:11] <Hobbsee> cool, yeah.  11pm local, it looks like
[07:12] <persia> infinito: I can't give the package proper review (python packaging confuses me), but you probably want to add a note at the bottom of debian/copyright detailing the licensing applicable for the packaging, and you definitely want to List the "needs-packaging" bug in LP as closed.  (If a bug doesn't exist, create it, set to "In Progress", and assign yourself.
[07:13] <infinito> persia: i dont understand the thing about the license note...
[07:13] <infinito> sorry
[07:14] <persia> infinito: There's a good example at the bottom of http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html
[07:18] <dholbach> ScottK: I think it makes more sense, if you start off a clamav discussion on ubuntu-devel-discuss@
[07:22] <dholbach> ScottK: in a meeting without you and without the background - that does not work
[07:22] <ScottK-laptop> dholbach: At the last meeting there was some discussion about looking at the API differences between libclamav1 and libclamav2.  I've got nothing to add to that (I'm hopelessly unqualified).  I'd suggest those of you who might do that, talk about who will do what and get it going.
[07:22] <ScottK-laptop> persia: I think it needs constant pressure or we won't get it fixed because it's a REALLY hard problem.
[07:22] <dholbach> it'd be nice to have a list of stuff that needs backporting etc
[07:22] <leonel> ScottK-laptop: may be  can be done  as  with postgresql that we can have  8.2 and  8.1   installed  
[07:22] <persia> ScottK: I agree, I'm just not sure that's the best venue.  Perhaps the mailing list, or a meeting that someone who is chasing it will attend.  Will any of the others working on it be able to attend?  Perhaps they could represent it.
[07:22] <ScottK-laptop> leonel: That's basically what I proposed and the last meeting and got little traction.
[07:22] <RainCT> persia: hi. where should I write that comment about the Blueprint you said yersterday?
[07:23] <persia> RainCT: Um.  Could you please feed me a little more context?  My heap is lossy.
[07:23] <RainCT> persia:  https://blueprints.launchpad.net/rosetta/+spec/rosetta-desktopfile-ui
[07:23] <infinito> persia: already done both (http://revu.tauware.de/details.py?upid=5530 and https://bugs.launchpad.net/ubuntu/+bug/120436)
[07:23] <ubotu> Launchpad bug 120436 in Ubuntu "[needs-packaging]  pyrenamer" [Undecided,In progress]  
[07:24] <persia> infinito: Great!  Now you just need someone familiar with python packaging to review :)
[07:24] <ScottK-laptop> dholbach: The list of stuff that would need to be backported with it is huge (too big).
[07:24] <dholbach> really?
[07:25] <crimsun> so how's revu day progressing?
[07:25] <dholbach> the list should be clearer now
[07:26] <persia> RainCT: I'd suggest starting by contacting the author of https://wiki.ubuntu.com/RosettaDesktopfileUi, and based on that discussion, updating the spec.
[07:26] <ScottK-laptop> dholbach: Do apt-cache rdepends libclamav2 clamav clamav-daemon
[07:28] <dholbach> daniel@lovegood:~$ apt-cache rdepends libclamav2 clamav clamav-daemon | grep -E ^' ' | xargs apt-cache showsrc | grep Package | sed 's/Package\:\ //g' | sort -u | wc -l
[07:28] <dholbach> 28
[07:28] <dholbach> that has clamav and clamav-data included
[07:35] <persia> Could someone please confirm that http://pastebin.ca/566861 looks like a sensible postinst?
[07:38] <crimsun> for what package
[07:38] <persia> crimsun: apt-file
[07:38] <crimsun> whew
[07:38] <persia> heh
[07:39] <ScottK-laptop> infinito: I'm looking at your package.
[07:39] <infinito> ScottK: thanks :)
[07:39] <persia> I'm just worried about completeness of syntax, so as not to break anything debhelper might want to do (the package previously had no seed).
[07:40] <crimsun> persia: if it doesn't spew ridiculous to std*, then sure.  I'm a bit hesitant on having the package status hinge on an live 'net connection, but that's just me.
[07:41] <persia> crimsun: I'd agree with that reservation.  Is there a standard safe way to check for a network connection prior to attempting to connect?
[07:41] <shawarma> persia: I forget. Was it also you who reviewed those perl packages of mine?
[07:42] <persia> shawarma: Yep.  One was good, for the rest, I suggested you ask someone more knowledgeable about the linda output.
[07:42] <shawarma> persia: Alright, and you uploaded that one, did you not?
[07:43] <shawarma> persia: I got a reject mail about it, which I deleted in an inbox cleaning frenzy.
[07:43] <crimsun> persia: a finite ping to the default gateway? Not sure.
[07:43] <persia> shawarma: No.  Based on your guidelines, I advocated and expected you to upload.  Do you want me to upload?
[07:43] <shawarma> persia: Nono, I'll do it.
[07:43] <persia> crimsun: Thanks for the suggestion anyway.  I'll look through list archives: I seem to remember seeing this discussed in the past.
[07:43] <persia> shawarma: Great.  Thanks.
[07:44] <shawarma> persia: Oh, thank *you*.
[07:44] <crimsun> bddebian: what?
[07:44] <persia> bddebian: You will always be needed
[07:44] <bddebian> Ha, you da man now! :)
[07:45] <crimsun> bddebian is handling alsa for gutsy, yay!
[07:45] <bddebian> crimsun: hahaha.  I would be incapable even if I wanted to :_)
[07:45] <crimsun> nah
[07:48] <ScottK-laptop> infinito: Comment submitted.
[07:48] <ScottK-laptop> bddebian: You are needed because no one is grinding through and giving a first set of REVU comments like you usually do when you aren't here.
[07:49] <bddebian> Heh, heya ScottK-laptop
[07:52] <infinito> ScottK: so u want me to remove the binary-install/pyrenamer... stuff ??
[07:54] <infinito> ScottK-laptop:         ^
[07:54] <persia> ScottK: Does that work without python-distutils?
[07:56] <infinito> it seems that removing the binary-install/pyrenamer stuff doesn't work very well...
[07:57] <infinito> the python stuff goes to /usr/lib/python2.5/site-packages/pyrenamer instead of  /usr/share/python-support/pyrenamer
[08:02] <ScottK-laptop> Yes.  It'd be much easier if upstream used distuils instead of a makefile.
[08:03] <ScottK-laptop> persia: The package doesn't use distutils
[08:03] <xxxxx1> hello bddebian 
[08:03] <bddebian> Heya xxxxx1
[08:03] <persia> ScottK: That's what I thought.  I just thought that binary-install/foo: was required when not using disutils.  Thanks for the clarification.
[08:04] <bmm> persia: are you online? The "minor detail" I changed in the last update to perfect my package seems to be wrong http://revu.tauware.de/details.py?upid=5511
[08:04] <ScottK-laptop> All he was doing in shi binary install was call dh_pysupport directly rather than tell cdbs what python system he was suinjg.
[08:04] <bmm> Should I mention the dpatches in the changelog or not? I'm not sure what to do now.
[08:04] <ScottK-laptop> err usung
[08:05] <ScottK-laptop> bmm: If you are patching the source, it should be mentioned
[08:06] <bmm> ScottK-laptop: so I should put that changelog line back? The only person who advocated the package so far, said it should be removed.
[08:06] <infinito> ScottK-laptop: if i remove the dh_pysupport, it seems that pysupport is not using while building the deb
[08:07] <ScottK-laptop> hmmm
[08:07] <persia> bmm: Both are correct.  Zak has convinced me that documentation is good since my comment, but my advocation for either 5413 or 5511 stands.
[08:07] <ScottK-laptop> did you add DEB_PYTHON_SYSTEM=pysupport?
[08:08] <ScottK-laptop> infinito: Are you upstream for this?
[08:08] <infinito> yeps
[08:08] <ScottK-laptop> Why use a makefile instead of a distutils setup.py?
[08:08] <bmm> persia: Then I'll add the changelog line again, and see if that will get more people to advocate it ;-)
[08:09] <infinito> ScottK-laptop: rules file http://pastebin.ca/566926
[08:09] <vijay2000> hi all 
[08:09] <infinito> ScottK-laptop: because im used to, and translations are easier with autotools...
[08:09] <persia> bmm: It's too late those those far out on the pacific rim, but you might get lucky.
[08:10] <vijay2000> i am trying to build notecase . i am getting the following error when i build http://paste.ubuntu-nl.org/25584/
[08:10] <vijay2000> can anybody help me out 
[08:10] <bmm> persia: what should I be learning from that line?
[08:10] <ScottK-laptop> Hmmm.  I think it's goint to be tough to get the python tools to work right.  Let me play with it a bit...
[08:12] <persia> bmm: The last commenter is away for the next several hours, so you don't have an opportunity to get a quick ACK from a reupload based on the last comment.  If you make a new upload, you might be able to get someone else who is currently actively reviewing packages.
[08:13] <vijay2000> persia: can u help me out 
[08:13] <bmm> persia: I'm willing to do anything (almost) for the package, so an upload is no problem.
[08:13] <persia> vijay2000: Not really.  I'm soon to bed, and still have a list I need to hit before then.
[08:13] <bmm> persia: I just need to know what to do: change it, or just wait another few days?
[08:14] <shawarma> persia: Found the linda bug that made it break on the perl man pages..
[08:14] <vijay2000> persia: no issues 
[08:15] <persia> bmm: If someone else who commented on it would be willing to advocate based on the debian/changelog changes, I'd do a quick upload.  If not, I'd try to catch the last commenter in 10-12 hours, and see if they would ACK based on an upload.  Otherwise, I'd wait.
[08:15] <persia> shawarma: Cool.  If you send the patch quick, and ping the maintainer in about 6 hours (usually), I suspect it might get into the upload that is being prepared.
[08:16] <bmm> persia: thanks! I'll try to contact the commenter then and work from there, if that fails it will just give the package some more time :-D
[08:16] <shawarma> persia: Oh, there's a linda update on the way?
[08:17] <persia> shawarma: One was mentioned here in the last couple days.  I don't know how serious the upload planning is.
[08:18] <shawarma> persia: Alright. It was due to '::' having a magic meaning during some checks. If '::' was in the filename, a line got split in the wrong place and everything blew up.
[08:19] <persia> shawarma: definitely file a bug.  I'd suggest filing in Debian, as the maintainer doesn't check the Ubuntu status as often.
[08:19] <shawarma> StevenK: Please apply http://people.ubuntu.com/~soren/fix_perl_manpages.diff to linda to stop it from breaking on perl man pages.
[08:19] <shawarma> persia: It's StevenK, isn't it?
[08:20] <persia> shawarma: Yes.
[08:20] <infinito> ScottK-laptop: what does this mean? E: pyrenamer source: build-depends-indep-should-be-build-depends python-support (>= 0.3) 
[08:21] <ScottK-laptop> It means you need to move python-support from build-depends-indep to build-depends
[08:22] <bmm> Ibalon zakame or zachy , are you online?
[08:22] <shawarma> persia: If you're bored, you could apply the patch to /usr/share/python-support/linda/linda/collector.py, check out my perl packages and advocate them.
[08:22] <persia> shawarma: It's too late for me to take new activities tonight.  Sorry.
[08:23] <shawarma> persia: Only if you're bored, though. You've helped me plenty today already.
[08:23] <shawarma> persia: Quite alright.
[08:25] <stijn_pol> Hi everyone! 
[08:25] <persia> Hi stijn_pol
[08:25] <stijn_pol> persia: allright, it has been a while..
[08:26] <persia> stijn_pol: Sorry about that.
[08:26] <mok0> Why does help2man never work?
[08:27] <mok0> I _always_ get: help2man: can't get `-h' info from 
[08:27] <stijn_pol> persia: no, due to my exams, anyway: bug 120028, is this a bug to make a patch for. Or is this more a feature request that should be reported upstream?
[08:27] <ubotu> Launchpad bug 120028 in drpython "Default save location" [Low,Unconfirmed]  https://launchpad.net/bugs/120028
[08:28] <persia> stijn_pol: Looks like a good one to me.  It's definitely a distribution level issue (for a change), so it should be a lot easier to see your changes distributed in the archive this time :)
[08:36] <infinito> ScottK-laptop: i'm using the dh_pysupport directly because of this: http://wiki.debian.org/DebianPython/NewPolicy#head-a9676f76c81944360eba13aa9bda1a7fcc7ad724
[08:39] <ScottK-laptop> infinito: You were looking in the python-support section, but you need to look in the cdbs section.
[08:39] <ScottK-laptop> infinito: The python-support section is written with a traditional debhelper rules file in mind and not CDBS.
[08:40] <infinito> ScottK-laptop: im looking at CDBS + the hard way
[08:40] <ScottK-laptop> infinito: OK
[08:40] <infinito> ScottK: it says: "If your package does not uses distutils blablabla..."
[08:40] <ScottK-laptop> infinito: Right.  I take back that part of the comment.
[08:41] <ScottK-laptop> infinito: The way you had it is right for a non-distutils packages.
[08:41] <infinito> ScottK-laptop: so im gonna upload it again right now with the other things fixed...
[08:41] <ScottK-laptop> infinito: Your life will be a lot easier in the long run I think if you use distutils.
[08:42] <ScottK-laptop> OK.  I'll look again.
[08:48] <infinito> ScottK-laptop: http://revu.tauware.de/details.py?upid=5532 ...i think it's fixed...
[08:48] <mok0> I figured out the help2man problem, is anyone interested?
[08:50] <ScottK-laptop> infinito: As a quick look, you didn't change the name of the binary to python-renamer
[08:50] <ScottK-laptop> Binary Python packages are supposed to start with python-
[08:51] <infinito> ScottK-laptop: nops, should i? i mean, the app is called pyrenamer, no python-rename, it's not a python module, but a python app
[08:54] <ScottK-laptop> infinito: Agreed.  I just read the Python policy over and I think you are fine.
[08:56] <jrib> http://revu.tauware.de/details.py?upid=5444 python module is new if anyone has a free minute or two.  Thanks
[09:08] <ScottK-laptop> infinito: It's putting the files in python-support/pyrenamer/pyrenamer dir.  That doesn't seem right...
[09:09] <infinito> ScottK-laptop: yeps, i see...
[09:11] <infinito> ScottK-laptop: i don't know how to fix that...
[09:11] <hendrixski> does anyone have a problem with their dchroot refusing to connect to the repositories after an arbitrary amount of time?
[09:12] <hendrixski> I'm learning packaging inside of chroots so as not to risk my system... and like after 3 reboots it seems to not connect to apt anymore
[09:12] <ScottK-laptop> infinito: I'm not either.  All the Python packages I've done used distutils.
[09:13] <infinito> ScottK-laptop: i dont know how to use distutils :(
[09:14] <hendrixski> infinito, http://docs.python.org/dist/
[09:14] <ScottK-laptop> infinito: It's not so hard.  Take a look at setup.py in the pyyaml source package.
[09:24] <infinito> ScottK-laptop: it seems normal behaviour, take a look for example to this: dpkg -L python-notify
[09:25] <infinito> ScottK-laptop: it seems that it makes a dir for the package, and then a subdir for the class
[10:58] (ScottK-laptop/#ubuntu-motu) Schitso: Others may have other ideas.
[11:04] <mok_> What to do if a package does _not_ have any dependencies (statically linked binaries)
[11:04] <ScottK-laptop> Don't list any
[11:04] <mok_> Lintian complains
[11:04] <ScottK-laptop> What package?
[11:05] <mok_> It's the biomolecular toolkit (btk) that I am building
[11:05] <mok_> not in the repo
[11:08] <mok0> so there is no Depends: null rule ?
[11:08] <ScottK-laptop> crimsun: I got the accept this time.
[11:12] <Q-FUNK> mok0: even then, you'd need the generic libc dependency that's added with 
[11:12] <Q-FUNK> Depends: ${shlibs:Depends}, ${misc:Depends}
[11:14] <shawarma> ScottK-laptop: Not that I mind or anything, but why'd you change the Maintainer field to you in libreadonly-perl?
[11:14] <Q-FUNK> mok0: e2fsck-static seems to be a good example of a statically-linked package.  see if you can learn anything from it.?
[11:15] <ScottK-laptop> shawarma: Probably because I message up.
[11:15] <shawarma> ScottK-laptop: First time, you forgot "-sa" it appears.
[11:15] <ScottK-laptop> Yes
[11:15] <shawarma> ScottK-laptop: The "Maintainer" in .changes is the Maintainer from debian/control is it not?
[11:15] <ScottK-laptop> shawarma: I think that's just in the .changes file, not in debian/control.
[11:16] <ScottK-laptop> Not always
[11:16] <shawarma> 8-|
[11:16] <shawarma> really?
[11:16] <shawarma> Changed-By is from debian/changelog.
[11:16] <shawarma> ah..
[11:16] <ScottK-laptop> shawarma: Look at man dpkg-buildpackage and -m
[11:16] <shawarma> ScottK-laptop: Yes, I was just about to say something to tha teffet.
[11:17] <shawarma> that effect, even.
[11:17] <shawarma> Sheesh, I'm typing like a.. well, a person who doesn't type very well.
[11:17] <pochu> like a shawarma? :p
[11:18] <shawarma> pochu: Right. Like "a shawarma" rather than "the shawarma". :)
[11:18] <pochu> :-)
[11:21] <shawarma> ScottK-laptop: How about the other perl packages? Did you check them out?
[11:22] <ScottK-laptop> Which?
[11:22] <ScottK-laptop> The meeting I'm in is getting close to over, so I don't know how much looking I'll be able to do...
[11:22] <shawarma> http://revu.tauware.de/details.py?upid=5506 http://revu.tauware.de/details.py?upid=5507 http://revu.tauware.de/details.py?upid=5508 
[11:24] <shawarma> ScottK-laptop: linda has a bug that makes it break on the man pages, but apart from that, it should be fine.
[11:25] <ScottK-laptop> OK
[11:27] <ScottK-laptop> shawarma: Why is libnet-cups-perl-0.51.orig/const-c.inc in the debian diff?
[11:28] <shawarma> ScottK-laptop: Um..
[11:28] <shawarma> ScottK-laptop: http://revu.tauware.de/revu1-incoming/libnet-cups-perl-0706131155/libnet-cups-perl-0.51/
[11:28] <shawarma> ScottK-laptop: I don't see it.
[11:29] <ajmitch> git clone git://people.freedesktop.org/~jrmuizel/mmio-trace
[11:29] <ScottK-laptop> shawarma: Look at http://revu.tauware.de/revu1-incoming/libnet-cups-perl-0706131155/libnet-cups-perl_0.51-0ubuntu1.diff
[11:29] <ajmitch> hm
[11:30] <ajmitch> bad paste
[11:30] <ajmitch> hello bddebian 
[11:30] <bddebian> Heya
[11:30] <ajmitch> long long time no see
[11:30] <bddebian> Aye, sorry, work has been killing me :-(
[11:30] <shawarma> ScottK-laptop: Ah.. Good question. Probably some sort of autogenerated cruft that needs to cleaned.
[11:30] <ScottK-laptop> shawarma: Also I would have expected you to be building an architecture independent package..
[11:31] <crimsun> ScottK-laptop: ok
[11:31] <ajmitch> bddebian: it's ok, I've not been active at all
[11:31] <bddebian> Oh, so nothing has changed?
[11:32] <ajmitch> pretty much
[11:32] <shawarma> ScottK-laptop: Um. No. It build .so's and shit.
[11:32] <ScottK-laptop> shawarma: OK.
[11:32] <ajmitch> so there's no real reason for me to still hang around ubuntu channels
[11:33] <shawarma> Hey, ajmitch!
[11:33] <ajmitch> hi
[11:33] <crimsun> ajmitch is trying to pretend he doesn't do stuff in main.  Pfft.
[11:33] <ajmitch> I don't
[11:34] <bddebian> ajmitch: pshaw
[11:34] <ajmitch> oh, new alsa-utils
[11:34] <crimsun> yeah, I broke something again (surprise)
[11:34] <ajmitch> but I point the finger solely at hardware
[11:50] <ScottK-laptop> shawarma: Comments on all 3.
[11:52] <xxxxx1> bye all!
[11:54] <shawarma> ScottK-laptop: Thanks!
[12:02] <Schitso> Ugh, I suck at triaging... -_-
[12:02] <shawarma> ScottK-laptop: I thought about the "all rights reserved" thing, too. The upstream readme gives that and then also says that it's under the same license as perl itself..
[12:03] <ScottK-laptop> Schitso: You'll learn.  It takes practice.
[12:03] <ScottK-laptop> shawarma: I think you need to address it with the upstream.
[12:04] <shawarma> ScottK-laptop: /me lets out a deep sigh
[12:04] <ScottK-laptop> shawarma: Also, don't forget that Perl is licensed under GPL version 1 too.
[12:04] <shawarma> ScottK-laptop: Yes?
[12:04] <ScottK-laptop> shawarma: So "Same terms as Perl" includes GPL 1, GPL 2, and Artistic
[12:04] <ScottK-laptop> IIRC
[12:05] <shawarma> ScottK-laptop: To be honest, the README says "This library is free software; you can redistribute it and/or modify
[12:06] <shawarma> it under the same terms as Perl itself. 
[12:06] <shawarma> "
[12:06] <shawarma> ScottK-laptop: What *I* did was to yank out the stuff from /usr/share/doc/perl/copyright
[12:06] <shawarma> ScottK-laptop: and put that in. That made sense to me.
[12:06] <ScottK-laptop> Sounds reasonable.
[12:06] <shawarma> But I totally agree there's an ambiguity in one sense.
[12:06] <shawarma> In another sense, there's no doubt in my mind what the author meant.
[12:07] <shawarma> He meant it to be released under the same terms as perl. He just made the mistake of putting "all rights reserved", too.
[12:07] <ScottK-laptop> If the copyright holder asserts All Rights Reserved, I don't know that the archive admins are going to be OK with it.
[12:07] <ScottK-laptop> Right, so ask him to fix it.
[12:08] <shawarma> ScottK-laptop: Yeah.
[12:11] <shawarma> ScottK-laptop: I fixed the autogenerated bits in libnet-cups-perl, by the way. http://revu.tauware.de/details.py?upid=5536
[12:12] <Schitso> Anyone know why I can't change the Importance of a bug report?
[12:12] <Schitso> I just need to change it to wish list...
[12:12] <ScottK-laptop> Schitso: You need to be in ubuntu-qa for that.
[12:12] <Schitso> Should I join that, then?