[00:03] <desertc> I am trying to run svn-buildpackage and it keeps giving me an eror that I am in a working copy of SVN trunk directory.  Anyone have an idea where those acceptable directories are listed?
[00:07] <desertc> Well, I've worked on this all day and gotten no where.  Are the SVN tools a messy kludge, or is that just my first impression?
[00:10] <minghua> Well, if you've never used svn before, svn-buildpackage is not going to be easy.
[00:13] <desertc> ... so, for example, why did the subversion not install a ~/.svn directory?  Seems like it is needed.
[00:15] <minghua> It's not supposed to be "installed".  And you don't need ~/.svn directory unless all of your home directory is under version control.
[00:16] <minghua> The configuration directory of subversion is ~/.subversion.
[00:19] <desertc> Ah, okay.  Hmm, had some weird documentation.
[00:21] <desertc> Maybe it is that I need to create a configuration in ./.svn
[00:22]  * StevenK appears from PDX airport
[00:22] <desertc> Anyway, feels kludgy.  Be working on it again tomorrow.  Night all.
[00:25] <minghua> Airport codes are so cryptic.
[00:26] <StevenK> Portland, Oregon
[00:26] <minghua> StevenK: Thanks, but google helped on that, too. :-)
[00:26] <StevenK> Heh
[00:26] <minghua> Better than Houston's, at least.
[00:46] <ryanakca> ScottK2: no, sponsored into debian, through new, and then sync into Ubuntu... last package I sent to debian, it took 2-3 weeks for steps 1&2
[00:46] <ryanakca> ScottK2: still need those packages to be tested?
[00:47] <minghua> Debian NEW processing has been reasonably fast these days.
[00:47] <zul> evening
[00:51] <ryanakca> minghua: nice :{
[00:51] <ryanakca> :)
[01:04] <emgent> heya *
[01:04] <ScottK2> ryanakca: No.  Thanks though.
[01:04] <ryanakca> ScottK2: okies :)
[01:34] <joejaxx> anyone know how to apply a bzr diff patch?
[01:35] <joejaxx> to a bzr branch
[01:36] <pochu> patch -p1 <patch won't work?
[01:36] <joejaxx> nope :( it just sits :(
[01:36] <joejaxx> i even used --verbose and it just sits
[01:36] <Vadi> I need to compile a program that uses the zlib.h library. However when I search on packages.ubuntu.com, there's a whole list of programs that comes up: http://packages.ubuntu.com/cgi-bin/search_contents.pl?word=zlib.h&searchmode=searchfiles&case=insensitive&version=gutsy&arch=i386 and I don't know which one to get
[01:37] <Vadi> Can anyone suggest one? I'm on hardy too (broke my gutsy with the installation of this)
[01:37] <pochu> joejaxx: you didn't forget the "<" did you? :)
[01:37] <joejaxx> Vadi: usr/include/zlib.h    libdevel/zlib1g-dev
[01:37] <joejaxx> pochu: :P no i did not forget that :P
[01:38] <blueyed> joejaxx: is it a unified patch / or some bzr bundle that you want to apply?
[01:38] <joejaxx> patch from bzr diff > drop2patch.patch
[01:38] <pochu> joejaxx: heh, ok. because it has happened to me that I forgot it and I wondered why nothing was happening ;)
[01:38] <Vadi> joejaxx: thanks!
[01:58] <pwnguin> is this java stuff on the motu list a new feature i can disable?
[02:01] <ScottK2> What java stuff on what MOTU list?
[02:51] <jdong> ScottK2: I think pwnguin was talking about the influx of NEW: packages?
[02:51] <jdong> a good chunk of which were java related
[03:14] <pwnguin> example
[03:14] <pwnguin> New: libbeansbinding-java 1.2.1-0ubuntu1 (source)
[03:19] <Hobbsee> effie_jayx: does it make more sense to remove the makefile.in stuff, or to add both files, so they both get made in the makefile.in?
[03:32] <ScottK2> jdong: Got it
[03:32] <ScottK2> Thanks
[03:32] <jdong> sure thing
[03:32]  * jdong hunts around for an awake ubuntu-main-sponsor :)
[03:33]  * ScottK2 looks up at Hobbsee
[03:33]  * Hobbsee isn't here
[03:33] <ScottK2> Oh.  Sorry.
[03:33] <Hobbsee> :)
[03:33] <Hobbsee> well, i can try, anyway
[03:34] <jdong> Hobbsee: so is that a really mean it isn't here, or can I convince you to be here? :)
[03:35] <Hobbsee> depends what it's for
[03:35] <jdong> Hobbsee: just another upstream version of transmission :)
[03:35] <jdong> Hobbsee: you core-devs stole it from us so now we have to pester to update it :)
[03:36] <jdong> bug  187234
[03:36] <ubotu> Launchpad bug 187234 in transmission "New upstream version: 1.03" [Low,Confirmed] https://launchpad.net/bugs/187234
[04:11] <effie_jayx> Hobbsee, Aparently no
[04:11] <effie_jayx> Hobbsee,  getting stuff done on the makefile will replace the postinst stuff
[04:12] <effie_jayx> which means each time you install a new revision all your high schores will be gone
[04:12] <Hobbsee> ah right.  yay
[04:12] <effie_jayx> Hobbsee,  albert23 help me reach that conclusion
[04:13] <Hobbsee> effie_jayx: uploaded, thanks :)
[04:13] <Hobbsee> effie_jayx: well done!  :)
[04:13] <Hobbsee> effie_jayx: mind sending the patch to debian?
[04:13] <Hobbsee> they have a bug open about it already
[04:13] <effie_jayx> Hobbsee,  not at all, but which one shall I send... the stuf in debian/patch?
[04:14]  * effie_jayx has never sent anything to debian, plain bug reports
[04:14] <Hobbsee> effie_jayx: yeah, and the reasons for why it works that way
[04:14] <Hobbsee> in particular, the answer to the question that i just asked you
[04:15] <effie_jayx> Hobbsee,  thank you :D
[04:16]  * Hobbsee assumes persia will want to follow https://bugs.edge.launchpad.net/ubuntu/+source/gweled/+bug/90499 through
[04:16] <ubotu> Launchpad bug 90499 in gweled "gweled on Feisty Herd5 plays annoying sound" [Medium,Confirmed]
[04:22] <effie_jayx> Hobbsee,  I just write an email with an attachment?
[04:23] <Hobbsee> effie_jayx: yeah, i think so
[04:23] <ScottK2> effie_jayx: Yes.  Add the words "Tags: patch" in it
[04:24] <ScottK2> If you look at the debian bug it'll give you the address to reply to that bug.
[04:24] <effie_jayx> ScottK, in the subject line... or body?
[04:24] <ScottK2> In the body
[04:24] <effie_jayx> ScottK,  I have seen it
[04:24] <effie_jayx> ScottK,  cool
[04:25] <ScottK2> effie_jayx: http://www.debian.org/Bugs/Reporting has an example of tags
[04:38] <Aloha> lintian is complaining about CHANGELOG not being .gz but if i make it .gz it says i changed a binary. how do i solve this problem?
[04:39] <blueyed> Aloha: are you using dh_installchangelogs?
[04:39] <Aloha> blueyed, yes
[04:39] <Aloha> dh_installchangelogs CHANGELOG
[04:39] <Aloha> it still complains
[04:39] <blueyed> maybe use dh_compress, too?
[04:39] <Aloha> blueyed, ok thnx
[04:40] <Aloha> blueyed, should i do it before or after dh_installchangelogs?
[04:40] <blueyed> after, near to the end.. it will compress other files, too.
[04:41] <Aloha> blueyed, thnx
[04:41] <blueyed> Aloha: you're welcome :)
[04:41] <Aloha> blueyed, doh... its already in my debian/rules.... any other ideas?
[04:42] <LucidFox> Aloha> yes
[04:42] <LucidFox> perhaps you install CHANGELOG in debian/docs as well?
[04:43] <Aloha> LucidFox, howso?
[04:43] <LucidFox> no, I mean... maybe you already do?
[04:43] <LucidFox> you should remove it from debian/docs
[04:46] <Aloha> LucidFox, i have no debian/docs
[04:46] <blueyed> Aloha: and you don't copy/install the file manually? does it show up zipped and unchanged in the .deb?
[04:47] <Aloha> blueyed, there is no zipped version in the deb
[04:47] <LucidFox> blueyed, I wanted to ask you something, but I forgot what :(
[04:48] <ScottK2> Aloha: Is dh_compress before or after dh_installchangelogs
[04:49] <Aloha> blueyed, installed in /usr/share/doc/sadms/CHANGELOG  maybe the Makefile puts it there
[04:49] <Aloha> ScottK, after
[04:49] <ScottK2> Aloha: Put it before
[04:49] <Aloha> ScottK, ok
[04:51] <LucidFox> Wait
[04:51] <LucidFox> dh_compress should be after dh_installchangelogs
[04:51] <LucidFox> Aloha> just delete the version upstream installs
[04:51] <LucidFox> before calling dh_installchangelogs
[04:51] <Aloha> LucidFox, in debian/make?
[04:52] <Aloha> s/make/rules
[04:52] <LucidFox> yes
[04:52] <LucidFox> after make install, call rm -f debian/sadms/usr/share/doc/sadms/CHANGELOG
[04:53] <Aloha> LucidFox, k thnx
[04:54] <Aloha> i put that after $(MAKE) DESTDIR=$(CURDIR)/debian/sadms install
[04:55] <effie_jayx> should I mention the bug has been fixed in ubuntu?
[04:55] <LucidFox> yes, that's right
[04:56] <LucidFox> effie_jayx> what bug?
[04:56] <effie_jayx> LucidFox,  LP: #110268
[04:57]  * effie_jayx writes a report to debian... first patch I send
[04:58] <effie_jayx> ScottK,  should I mention that it was fixed in ubuntu already?
[04:58] <LucidFox> effie_jayx> yes, I think it's best
[04:58] <LucidFox> to say that it's fixed in Ubuntu, and to link to the Ubuntu bug
[04:58]  * Aloha wishes he had his ipod
[04:58] <Aloha> staring at the screen while a package builds gets boring after awhile
[04:59] <LucidFox> At the risk of starting a flamewar, iPods suck.
[04:59] <Aloha> LucidFox, i got it for free
[05:00] <LucidFox> poor you...
[05:00] <Aloha> LucidFox, omg... i'm not even gonna say anything
[05:00] <Aloha> heh
[05:00] <ScottK2> effie_jayx: Sometimes that's good and sometimes it's bad.  It kind of depends on how that DD feels about Debian.
[05:01] <ScottK2> effie_jayx: I usually don't because it really isn't relevant to is the patch right or not.  Others worry more about making sure Ubuntu gets credit for giving back.
[05:02] <effie_jayx> ScottK2,  That's why I asked
[05:02] <effie_jayx> ScottK,  I am sending it with no ubuntu reference though
[05:02] <ScottK2> Your call
[05:03] <Aloha> woohoo i beat level one of frozen bubble ;)
[05:03] <jdong> Aloha: congrats!
[05:04] <effie_jayx> ScottK,  a reference to ubuntu had been made already
[05:04] <effie_jayx> ScottK2, some guy making reference to the bug in ubuntu nad posting the URL
[05:04] <Aloha> woohoo lintian isn't complaining about CHANGELOG anymore now i just have to learn how to write a decent manpage
[05:05] <effie_jayx> Here's a link to an Ubuntu bug, tracking the same problem. Might be
[05:05] <effie_jayx> worth to keep an eye on if someone writes a patch.
[05:05] <effie_jayx> https://bugs.launchpad.net/ubuntu/+source/gweled/+bug/110268
[05:05] <effie_jayx> -
[05:05] <ubotu> Launchpad bug 110268 in gweled "gweled does not record high scores" [Undecided,Fix released]
[05:05] <effie_jayx> and we did :D
[05:06] <effie_jayx> Hobbsee,  done.. thanks a buch
[05:06] <effie_jayx> s/buch/bunch... Should you have another interesting bug like that please let me know
[05:06] <Hobbsee> effie_jayx: :)
[05:06] <Hobbsee> effie_jayx: well, you could fix rbot please :)
[05:07] <effie_jayx> Hobbsee,  well I am off to bed... it past midnight here :D. but tomorrow I could throw some arrows and see
[05:07] <Hobbsee> :)
[05:08] <effie_jayx> I feel much more confident with tools ... I need a bit of reading cdbs.
[05:08] <effie_jayx> but my basic bash skills do help me
[05:09] <effie_jayx> anyway... off to bed... see you guys tomorrow...
[05:11] <Aloha> effie_jayx, night
[05:11] <Hobbsee> night!
[05:11] <ScottK2> Good night
[05:34] <Aloha> muhahahahaha finally after 3 days lintian -i doesn't report any errors
[05:34] <Aloha> i am victorious
[05:35]  * Fujitsu uploads a new, yet more pedantic, lintian.
[05:35] <Aloha> nooooooo
[05:41] <Hobbsee> heh
[05:43] <ScottK2> Fujitsu: Don't forget more obtuse.  That's always fun too.
[05:43] <Fujitsu> Indeedily.
[05:45] <Aloha> I'm getting Error '553 Could not create file.' during ftp transfer of sadms_2.0.12-0ubuntu1.dsc from revu when i try to dput
[05:57] <Aloha> woohoo i learned some dcut-fu
[05:59] <Hobbsee> Aloha: dcut doesn't work on revu.
[05:59]  * ScottK2 thinks what Aloha learned is about to be humility
[05:59] <ScottK2> ;-)
[05:59] <Aloha> Hobbsee, oh i guess it just cleaned itself then. what a coincidence
[05:59] <ScottK2> Aloha: There's a cron job
[06:00] <Aloha> cool
[06:00] <Aloha> whats the time cycle?
[06:17] <Aloha> i i have to run builder everytime i want to run lintian/linda?
[06:17] <Aloha> s/builder/pbuilder
[06:17] <Aloha> or can i just debuild it?
[06:18] <Aloha> Please review http://revu.tauware.de/details.py?package=sadms
[06:20] <ScottK2> Aloha: if you want to run lintian/linda run lintian -I ....dsc and ....deb
[06:20] <ScottK2> i.e. run it against both source and binary
[06:20] <Aloha> ScottK, i've been running it against the .changes file
[06:23] <ScottK> IIRC that works too
[06:24] <Fujitsu> As long as it's the binary .changes.
[06:24] <Aloha> ok cool thnx
[06:24] <Aloha> linda complains about using policy 3.7.3 but someone told me to use that
[06:25] <ScottK> linda hasn't been updated
[06:26] <Aloha> ok. thnx
[06:29] <ScottK> I thought you all might enjoy this ... http://sourceforge.net/mailarchive/message.php?msg_name=47A4A5DA.6050106%40hetnet.nl
[06:31] <Fujitsu> Loathing Debian. I see. Makes sense.
[06:33] <Aloha> switch to debian!
[06:33] <imbrando1> heh someone prefers rpm to deb? nevar!
[06:33] <Aloha> s/debian/ubuntu/
[06:34] <Aloha> he thinks red hat is YUMmy
[06:34] <ScottK2> People have opinions for reasons that don't always make sense
[06:37] <imbrando1> anyone know what the handheld in this pic is ? ( not the usb device ) http://www.thinkgeek.com/gadgets/electronic/80ce/action/
[06:37] <imbrando1> looks nice
[08:33] <emgent> heya
[08:34] <LucidFox> emgent> but... you've been here all along :)
[08:34] <emgent> heheh hi LucidFox :)
[08:44] <nixternal> imbrando1: that is a Zaurus SL-C1000..you can find them every now and then on Ebay...actually a bit old and crappy for today
[08:45] <nixternal> that one might actually be an older model than the C1000
[08:55] <LucidFox> You know what would be a convenient feature in gnome-terminal?
[08:55] <LucidFox> "Open current directory in Nautilus"
[09:05] <TheMuso> LucidFox: I vaguely remember seeing something to do that somewhere.
[09:28]  * persia catches up on backscroll
[09:29] <persia> Hobbsee: Is background music really improtant to you?
[09:30] <persia> nixternal: Is there anything since the Zaurus that fits in a pocket and has a usable keyboard?
[09:31] <persia> LucidFox: Either `gnome-open .` or `nautilus .` should work.
[09:31] <LucidFox> ah, yes... and "nautilus ." doesn't hold the command line, it's perfect
[09:31] <emgent> heya persia
[09:32] <LucidFox> thanks for the tip!
[09:58] <slytherin> Hi all. Dows anyone know what is exactly the reason for grub FTBFS on powerpc? I have checked the build logs but since I am not a good C developer, I am unable to know the reason.
[10:06] <persia> It's REVU Day again.  The last one for Hardy.
[10:06] <persia> Who has a package ready for review?  Who has time for a review?
[10:06] <persia> Peer review is up, so packagers are welcome to review each others packages, to make sure they are in best shape for MOTU Review.
[10:10] <LucidFox> I'd like to have http://revu.tauware.de/details.py?package=tovid reviewed
[10:11] <LucidFox> as well as http://revu.tauware.de/details.py?package=libgee - the uploader has cleared all my previous objections and I have no new ones
[10:14] <slytherin> is it possible to discard a package? I had packaged it as it was suppposed to be dependency of new version of batik. but I didn get enough time to address the comments and these days I have better things to do. ;-)
[10:14] <LucidFox> slytherin> You can ask a REVU admin to archive it
[10:15] <LucidFox> wait...
[10:15] <persia> slytherin: Packages can be archived, but if you'd like someone else to take over, you'd do better to unassign yourself from the bug, and leave a comment on REVU saying you'd be happy if someone took over.
[10:15] <LucidFox> I'm interested in getting the new version of batik in
[10:15] <LucidFox> to unbreak FOP builds
[10:15]  * persia cheers collaboration
[10:16] <Fujitsu> Oh I hate some Debian maintainers.
[10:16] <slytherin> LucidFox: I think Debain guys are already working on that. That is the main reason I am no more interested in taking my package forward.
[10:16] <Fujitsu> They put all the bug numbers on one line, rather than next to their respective changes. Fun.
[10:16] <LucidFox> Fujitsu> o_O
[10:17] <geser> slytherin: re grub: without checking the source I guess because it contains architecture specific code
[10:17] <LucidFox> slytherin> I really hope they get it ready before FF :)
[10:24] <vemon> http://revu.tauware.de/details.py?package=lashwrap & http://revu.tauware.de/details.py?package=ghostess
[10:24] <vemon> the latter hasn't been reviewd at all and the first one should be ready for upload (just need someone to do that :D)
[10:26] <Hobbsee> persia: no, but getting rid of the bugs on that page is :)  anyway, i like that music
[10:26] <persia> Hobbsee: which page?
[10:26] <Hobbsee> the bugs for gweled
[10:27] <persia> Hobbsee: Ah.  I'll take another look after FF then.
[10:29] <Hobbsee> :)
[10:29] <Hobbsee> all the "there are no bugs for this package" pages are very good
[10:34] <LucidFox> When filing a MOTU re-application, should I re-C the sponsors I CC'd the first time around, or only CC new ones?
[10:35] <persia> LucidFox: I'd recommend re-cc'ing, as not all sponsors are subscribed to that mailing list.
[10:46] <RainCT> Hey
[10:47] <LucidFox> hi RainCT
[10:51] <RainCT> isn't the FF the 14th?
[10:51] <laga> i think so
[10:51] <Hobbsee> oh goody.  the day after i go away
[10:52]  * Hobbsee won't see the great rush to get things in
[10:52] <geser> Hobbsee: go away?
[10:52] <RainCT> why is this then the last REVU Day?
[10:52] <rexbron> RainCT: So that the archive admins have time to clear the queue before the FF I would think
[10:53] <Hobbsee> geser: interstate
[10:55] <RainCT> rexbron: ah, that would explain it :)
[11:01] <geser> Hobbsee: sorry, I still don't understand it where you're going
[11:02]  * Hobbsee is going to another state
[11:02]  * Hobbsee lives in sydney, and is flying to adelaide for a holiday
[11:03] <geser> ah
[11:20] <RainCT> is anyone going to update openbox and obconf?
[11:20] <jpatrick> RainCT: you?
[11:21] <RainCT> jpatrick: I might do it myself later if anyone is working already on it :)
[11:25] <warp10> Good morning
[11:37] <rulus> Can anyone have a look at gtkvd please (http://revu.ubuntuwire.com/details.py?package=gtkvd)? Thanks :)
[11:49] <jpatrick> where can I find Ubuntu packages not in Debian?
[11:50] <geser> in the mdt output on qa.ubuntuwire.com
[11:50] <rexbron> jpatrick: http://qa.ubuntuwire.com/multidistrotools/
[11:50]  * Fujitsu checks that that's actually still working properly.
[11:51]  * jpatrick gets to work getting the KDE ones into Debian
[12:04] <RainCT> strange.. obconf's debian/copyright was totally wrong :S
[12:30] <pochu> Morning folks
[12:30] <DktrKranz> hey pochu! :)
[12:30] <pochu> hey DktrKranz!
[12:40] <bddebian> Heya gang
[12:41] <pochu> morning bddebian
[12:41] <bddebian> Hello pochu
[13:02] <geser> Hi bddebian
[13:03] <bddebian> Heya geser
[13:10] <RainCT> is anyone free for checking obconf 2.0.3 before I upload it?
[13:10] <persia> RainCT: how much checking does it need?
[13:12] <LucidFox> RainCT> debian/copyright tends to get neglected after the first upload
[13:13] <LucidFox> F-Spot, for instance, got a _massive_ debian/copyright overhaul when it switched maintainers in Debian
[13:13] <LucidFox> and a potential GPL violation had to be resolved along the way, which wasn't noticed until it was too late
[13:15] <RainCT> persia: well.. any checking is good :)
[13:16] <cyberix> I'm looking after first advocate for my package Malbolge. I've fixed all broblems that have been brought up. http://revu.tauware.de/details.py?package=malbolge
[13:16] <persia> RainCT: Where is it?
[13:17] <RainCT> LucidFox: the fun thing here is that it mentioned a Ben Jansens to whom I couldn't find any mention now (but instead contributions from a Dana Jansens dating back to 2003) lol
[13:20] <LucidFox> heh
[13:20] <RainCT> persia: http://rainct.homelinux.net/obconf_2.0.3-0ubuntu1.dsc
[13:21] <effie_jayx> morning all
[13:22] <persia> effie_jayx: Thanks for fixing the gweled scores issue.  It's been bugging me for years, and somehow it never reached the investigation threshold :)
[13:22] <effie_jayx> persia,  ahhh It was just with a little help from you guys...
[13:23] <persia> RainCT: That server is painfully slow :(
[13:25] <RainCT> persia: that's my PC and, I think I already noticed that :P :(
[13:25] <persia> RainCT: modem?
[13:26] <RainCT> persia: 3G modem
[13:26] <persia> RainCT: Hrm.  Maybe time to look into downgrading to wireless ISDN to avoid marketing hype.
[13:29] <asbin> Hi everybody
[13:29] <asbin> Can anyone look at my package on REVU ? http://revu.tauware.de/details.py?package=libdlna
[13:29] <RainCT> persia: isn't that bad.. normally it downloads at 200-400kbps, just sometimes it gets slow :(
[13:29] <asbin> I'm quite new to REVU/MOTU ...
[13:30] <asbin> Should I have to open a bug to launchpad to have a package added ?
[13:31] <RainCT> persia: we also have ADSL (8mb iirc) but it doesn't arrive here, the lines are shit, (althought the IP says that it does :P).. waiting for months now for a technician to come.. :/
[13:32] <persia> asbin: Yes.
[13:32] <RainCT> asbin: yes, open a bug with "[needs-packaging] package name" as short summary, and add the "needs-packaging" tag to it
[13:32] <persia> RainCT: Ah.  I thought that part of the world had some fancy fiber mesh installed.  Perhaps it just hasn't reached the edges yet.
[13:32] <RainCT> asbin: then write the bug number down in the debian/changelog file, with this syntax:  (LP: #xxxxx)
[13:33] <asbin> ok thanx !
[13:33] <RainCT> persia: Barcelona probably yes, but not the towns
[13:33] <persia> RainCT: looks relatively sane, except that the menu file doesn't check for the existence of the package.
[13:34] <asbin> RainCT: and if someone had time to look at the package and tell me what needs to be fixed, it should be awful
[13:34] <RainCT> asbin: I guess you mean awesome? :P
[13:35] <asbin> RainCT: yes ! lol (I'm not english-mother-language)
[13:35] <RainCT> asbin: I'll look later at it :)
[13:36] <RainCT> persia: hm.. how would it do that? (beside, should there be a menu file if the package isn't installed? :P)
[13:36] <persia> RainCT: ?package(somepackage)
[13:37] <RainCT> persia: ?package(obconf):\
[13:37] <persia> RainCT: Also, you're right, but policy dicates it be tested.
[13:37]  * persia looks harder
[13:38] <persia> RainCT: It looks like I trust lintian too much :)  Perhaps it's the extra blank line at the end?
[13:39] <asbin> RainCT: ok great :)
[13:39] <RainCT> persia: ah, I see. I forgot a \ on line 5. thanks :)
[13:39] <asbin> RainCT: I have an other package to review : http://revu.tauware.de/details.py?package=ushare , but this one needs libdlna packages as dependencies ...
[13:41] <RainCT> persia: ok, fixed & uploading :)
[13:42] <tsmithe> hi, could i get a review of alsa-firmware? it's lintian clean, as far as it can be
[13:42] <tsmithe> http://revu.tauware.de/details.py?package=alsa-firmware thanks :)
[13:45] <persia> tsmithe: There's a new upstream of mscore, if you haven't already seen it.  Is it worth updating?
[13:45] <tsmithe> it is, but i'm trying to persue getting it in debian
[13:46] <persia> tsmithe: OK.  Just remember the FeatureFreeze deadline.  Good luck.
[13:48] <tsmithe> persia, yeah. it's slow :s
[13:48] <tsmithe> but seeing as there's already a package in ubuntu, can't i get new versions in after featurefreeze?
[13:51] <persia> tsmithe: It requires a freeze exception to get a new upstream after FeatureFreeze.  It might be possible, but it's certainly a lot harder than now.
[13:52] <tsmithe> oh right. i was forgetting the merge of UpstreamVersionFreeze and FeatureFreeze
[13:55] <mok0> I just checked the New Queue, and was wondering: how does an app like netcat get in there?
[13:56] <RainCT> tsmithe: I doubt that you'll get it through NEW in debian before FF
[13:57] <persia> mok0: Possibly new source name, or additional binary package included.
[13:57] <tsmithe> RainCT, thank you for that, i'll upload an update for ubuntu then
[14:00] <RainCT> asbin: please add a watch file as suggested by persia (see `man uscan`), add the bug number to the changelog and check that upstream's changelog really gets installed (there should be two in the package, debian/changelog and upstream's). ping me once you have a new candidate :)
[14:00] <RainCT> persia: should I send a mail to ubuntu-motu@ for new versions or is that just for REVU?
[14:01] <persia> mok0: Checking again, it's the netcat-traditional binary package that is in NEW: the rest of netcat just gets updated normally.
[14:01] <asbin> OK, persia = emmet hikory :)
[14:01] <persia> RainCT: Only for for NEW source.  Updates should close bugs though.
[14:01] <mok0> persia: I see, so that does not just constitute an update
[14:01] <persia> mok0: Well, it's a special sort of update.
[14:02] <pyRunner> I was wondering if ubuntu could use something like the Windows equivalent of WMI? Like OpenPegasus? Any comments?
[14:03] <mok0> Is compat level 5 reason for rejecting packages in revu?
[14:03] <persia> pyRunner: A better question to ask is: could you use software like that on Ubuntu?  If so, you might consider filing a needs-packaging bug and seeing if someone confirms it.
[14:04] <RainCT> mok0: why should it be?
[14:04] <persia> mok0: Oughtn't be this close.  On the other hand, anything less than 4 is definitely too old.
[14:04] <mok0> Because debhelper is version 6 in hardy
[14:04] <RainCT> mok0: and this means that packages should be made incompatible with older versions?
[14:04] <mok0> I was told to bump it on xtide-wvs1-data
[14:05] <persia> mok0: We've heaps of v4 and v5 stuff around.  As this is the last REVU day, rejections should be for a good reason, rather than to help improve the package.
[14:05] <mok0> persia: ok. I was just wondering if I should do anything about it before revu-day
[14:05] <asbin> RainCT: OK, I'll try to do the watchfile thing, and I will put another package
[14:05] <DaveMorris> although if the package where online they could upgrade it and have it reuploaded in around 20 mins
[14:06] <persia> mok0: Umm.  It's already 4 hours into REVU Day :)
[14:06] <mok0> Ah, it's monday for you :-) Here it's still sunday...
[14:06] <RainCT> here too :)
[14:08] <mok0> So actually, revu day is close to 48 hours...
[14:09] <persia> mok0: Still Sunday here too.  REVU Day goes from 0:00 UTC+14 to 24:00 UTC-11.
[14:10] <pyRunner> persia: It is distributed with RedHat Enterprise to interface with HP-OpenView, should make ubuntu more attractive for companies with large installed base of users
[14:12] <persia> pyRunner: OK.  I still think that would benefit from a needs-packaging bug rather than discussion here, and further doubt it can be packaged, reviewed, and accepted in time for hardy, as there are only 10 days before the freeze.
[14:12] <pyRunner> persia: Thanks...  I will consider doing that... but let me build it first... :)
[14:13] <pyRunner> persia: er... package it first
[14:14] <persia> pyRunner: Best to open the bug first, to let others know it is maybe wanted.  If you assign yourself the bug, others know you are working on it.  This is one of the ways we avoid duplicate effort.
[14:15] <squentin> Anyone wants to review this http://revu.tauware.de/details.py?package=gmusicbrowser ?
[14:15] <tuxist> hi
[14:15] <tuxist> have anybody get kde_luks runnable ?
[14:15] <tuxist> i got only the dialog
[14:16] <persia> squentin: Grab lintian & linda from backports, and run them against your source and binary changes files.  This should provide you with a list of things to update.
[14:16] <tuxist> and nothing happens
[14:16] <persia> For maximum verbosity, use lintian -iIv and linda -v -f long -t E,I,W,X
[14:16] <asbin> RainCT: should I clean the changelog history of libdlna package as suggested by persia ? The package was already distributed privately before ...
[14:17] <squentin> persia: this will be different than the linda and lintian files in http://revu.tauware.de/details.py?package=gmusicbrowser ?
[14:17] <RainCT> asbin: IMO yes. I'd only keep the changelog if it comes from another Debian/Ubuntu-based distribution, not from private repos
[14:19] <persia> squentin: Yes.  Firstly, those don't run with maximum verbosity, and secondly, they don't run against the binary package.  From a quick glance at your debian/control, I can see a couple points lintian would note.
[14:20] <squentin> perisa: ok thanks, will do
[14:23] <asbin> RainCT: OK, in this case, which version number package to use ? 0ubuntu1 ?
[14:23] <RainCT> asbin: yes
[14:25] <mok0> Anyone fresh for a quick revu of ssm (http://revu.ubuntuwire.com/details.py?package=ssm) It's in pretty good shape imho
[14:28] <asbin> RainCT: this can't be a problem if I've already uploaded a version "0ubuntu2" in REVU ?
[14:28] <mok0> asbin: no
[14:31] <RainCT> mok0: I'm checking it :)
[14:31] <mok0> RainCT: cool, thx.
[14:40] <tsmithe> RainCT, if you're reviewing, could you check out alsa-firmware?
[14:43] <RainCT> tsmithe: ok :)
[14:43] <tsmithe> thank you very much :)
[14:46] <RainCT> mok0: advocated :)
[14:46] <asbin> RainCT: OK, I've uploaded a new version in REVU, can you check it please ? http://revu.tauware.de/details.py?package=libdlna
[14:46] <mok0> RainCT: that's great, thanks!
[14:57] <rexbron> Do README.debian-source files need to be installed to anywhere?
[14:58] <bddebian> I don't think so since they will be in the source package anyway
[15:00] <effie_jayx> where can I check the logs for this channel
[15:02] <dcordero> hi
[15:02] <rulus> Can someone review my package gtkvd (http://revu.ubuntuwire.com/details.py?package=gtkvd) please? It should be ready to advocate. Thanks.
[15:02] <dcordero> how can i notify a revision of a bug by a motu for by marked as fixed?
[15:03]  * DaveMorris pokes persia to set my package building before they goto bed
[15:04] <steveire> Hi. Anyone know how often packages get backported?
[15:05] <LucidFox> steveire> irregularly, that's all I can say
[15:05] <DaveMorris> Don't you need to request a backport
[15:05] <steveire> LucidFox: That's a shame.
[15:06] <shibata> effie_jayx: http://irclogs.ubuntu.com/
[15:06] <LucidFox> Indeed. I myself have a couple of backport requests waiting.
[15:06] <LucidFox> For a long time.
[15:06] <jdong> *sigh* I really do need to dedicate one evening to backports processing
[15:07] <jdong> and this is my last day before term begins too
[15:07] <steveire> What's the url for the backlog of those items again?
[15:07] <jdong> steveire: whatever's the bug view for gutsy-backports, feisty-backports, etc in launchpad
[15:07] <LucidFox> jdong> in this case, can I pimp some requests? :)
[15:08] <jdong> LucidFox: haha, mail but sure :)
[15:10] <LucidFox> you mean send you the links by mail?
[15:11] <jdong> yes
[15:11] <jdong> my first priority for the day has to be figuring out the scheduling for my next term of classes
[15:11] <steveire> jdong: Is there someone less busy who can do that stuff?
[15:12] <jdong> steveire: look at the members for the ~ubuntu-backporters team and see if anyone else on that list is less busy
[15:12] <squentin> ok, I uploaded a new version : http://revu.tauware.de/details.py?package=gmusicbrowser if anyone wants to review it
[15:12] <jdong> if you can find any victi^H^H^H^H^H volunteers who are MOTU's interested in joining the backporter team, I'd love to talk to them too :)
[15:13] <steveire> https://launchpad.net/projects/?text=ubuntu-backporters&x=0&y=0 <<< I'm not seeing it here.
[15:14] <jdong> https://edge.launchpad.net/~ubuntu-backporters
[15:15] <LucidFox> well, at least jpatrick and imbrandon are active here
[15:15] <rexbron> Hey everyone, I have a package in desperate need of a review. http://revu.ubuntuwire.com/details.py?package=openlibraries
[15:16] <LucidFox> If my MOTU application passes, I'll immediately join the backports, multimedia and Java teams
[15:16] <jdong> let's hope it does :)
[15:16] <steveire> jdong: Does the member need to be an admin? ie you or merdith?
[15:16]  * jpatrick waves at LucidFox 
[15:17] <jdong> steveire: no. All members of the team have the authority to approve a backport
[15:17] <steveire> jpatrick: Any chance of approving the backports of libsoprano and libxine?
[15:17] <jpatrick> steveire: I thought jdong was on the libxine on
[15:19] <steveire> jpatrick: The status is in progress, but I don't know what has to happen for me to get an updated package through the pipes.
[15:19] <LucidFox> squentin> looking
[15:19] <jdong> steveire: In Progress = waiting for archive admin
[15:19] <jdong> i.e. already approved
[15:19] <jpatrick> steveire: what jdong said :)
[15:20] <squentin> LucidFox; thanks
[15:20] <steveire> jdong: That's you or meredith is it?
[15:20] <jpatrick> steveire: nop
[15:20] <jpatrick> LucidFox, steveire: http://paste.ubuntu-nl.org/54603/
[15:21] <jpatrick> steveire: https://launchpad.net/~ubuntu-archive
[15:21] <jdong> steveire: haha, that would be REALLY cool if I had the archive admin buttons in launchpad :D
[15:21] <jdong> but alas, only in weird nightmares do I posess bionic archive powers (Tm)
[15:22] <steveire> my libxine bug is still marked as new, not in progress.
[15:22] <steveire> So who are the archive admins?
[15:22] <jpatrick> steveire: see the LP page
[15:22] <steveire> oh, I got alink
[15:25] <steveire> * Status 'In Progress' and subscribe ubuntu-archive on backports ready
[15:25] <steveire>   to go into the archive.
[15:25] <steveire> Does that mean I have to sub ubuntu-archive?
[15:25] <jdong> is ubuntu-archive not subscribed?
[15:26] <steveire> They are not.
[15:26] <jdong> oops
[15:26] <LucidFox> squentin> commented on REVU
[15:26] <steveire> They are on the soprano one
[15:26] <jdong> then please do subscribe them :)
[15:26] <jdong> has the xine one been approved?
[15:27] <steveire> jdong: It's still 'New'
[15:27] <steveire> and unconfirmed. Don't know if that's relevant.
[15:27] <LucidFox> steveire> you probably mean Undecided?
[15:27] <jdong> steveire: did you find siretart like I asked earlier?
[15:28] <steveire> jdong: https://bugs.launchpad.net/gutsy-backports/+bug/180577 Yes. He commented
[15:28] <ubotu> Launchpad bug 180577 in gutsy-backports "libxine1-plugins depends on libxine1-gnome" [Undecided,New]
[15:28] <steveire> LucidFox: Yes, that's what I meant
[15:28] <jdong> steveire: ok, that's the version that bug 188340 recently filed requests
[15:28] <ubotu> Launchpad bug 188340 in baltix "backport xine-lib 1.1.10-1 from hardy - there are several security, flash playing and other important fixes" [Undecided,New] https://launchpad.net/bugs/188340
[15:29] <jdong> has any build-tested xine-lib 1.1.10-1?
[15:29] <LucidFox> speaking of xine...
[15:30] <LucidFox> how do I stop dh_shlibdeps from auto-including libxine1 in shlib:Depends?
[15:30] <LucidFox> (because I want to explicitly depend on libxine1-x | libxine1)
[15:30] <squentin> LucidFox: thanks, those things were done by Andy Price, who made the first attempt to package it. (should I reply on REVU) Anyway, I'll fix it
[15:31] <steveire> jdong: Do I need to mark one of the bugs as a dup?
[15:31] <LucidFox> squentin> wait a bit
[15:31] <LucidFox> I missed one very important thing
[15:31] <squentin> ok
[15:31] <jdong> steveire: I've already done that
[15:32] <jdong> steveire: bug 188340 should be used for this backport from this point forward, as it's clearer to what we want to do
[15:32] <ubotu> Launchpad bug 188340 in baltix "backport xine-lib 1.1.10-1 from hardy - there are several security, flash playing and other important fixes" [Undecided,New] https://launchpad.net/bugs/188340
[15:32] <LucidFox> squentin> added another comment
[15:32] <squentin> ok, looking
[15:33] <steveire> jdong: Really? Maybe I need to give both pages a few mins to update. Neither have changed
[15:34] <asbin> can someone review my package at http://revu.tauware.de/details.py?package=libdlna please ?
[15:34] <squentin> LucidFox: where did you see the debian dir in upstream ? There used to be one but no longer is in the stable version. Maybe I made a mistake when packaging it ? (btw I'm upstream :) )
[15:37] <RainCT> asbin: commented
[15:37] <LucidFox> squentin> ah, fine then
[15:38] <steveire> jdong: I don't think ubuntu-archives is subbed to that bug.
[15:39] <LucidFox> And I like it when upstreams package their own software.
[15:39] <squentin> LucidFox: I'll mention my renewed involvement in the debianization in the copyright. Should the xpm icon be in the debian dir ?
[15:40] <LucidFox> yes
[15:40] <LucidFox> oh wait
[15:40] <LucidFox> you're upstream!
[15:40] <LucidFox> so you can just as easily add it to the upstream install system :)
[15:41] <LucidFox> Of course, if you feel like making a new release just for that - otherwise, it can go into debian until the next release
[15:41] <squentin> yes but I'm not going to release a new stable version for this, I'll do it in the next one
[15:41] <LucidFox> All right then
[15:42] <LucidFox> then into debian it goes
[15:43] <squentin> ok, fixing it, thanks
[15:44] <asbin> RainCT: Thanks !
[15:50] <RainCT> tsmithe: about alsa-firmware, I just submitted a comment noting 3 minor issues, and I'm checking the binary now. But look for another to review it as I'm afraid that this package surpases me (I've mostly done Python stuff so far) (however, if you get 1 advocate but have problems finding a second one by the end of the day ping me and I'll advocate ;))
[15:52] <tsmithe> RainCT, what do i do about (1). it cannot require "make distclean", as the makefiles have not necessarily been configured/built at that point
[15:53] <rexbron> hey everyone, I am looking for a review of openfx. http://revu.ubuntuwire.com/details.py?package=openfx
[15:53] <RainCT> tsmithe: "[ -f Makefile ] && make distclean" or somewhat like that,  lintian --info *.dsc  will tell you
[15:53] <tsmithe> hmm yes that looks quite nice, thanks
[15:54] <RainCT> tsmithe: (F5, lintian had some more complains about the binary)
[15:54] <RainCT> tsmithe: yw
[15:54] <tsmithe> plus, i don't really wanna consolidate the changelog, as someone upgrading from my PPA will want to have the full caboodle
[15:55] <RainCT> tsmithe: well, add a  * Initial upload to Ubuntu.  then
[15:55] <tsmithe> the lintian binary errors regarding the firmware files themselves i cannot really do much about (miXart8.elf), but i can fix the error about the Section (left over from using the PPA)
[15:56] <tsmithe> RainCT, kk
[15:56] <dcordero> i need some help with fixing a bug. I have send a debdiff for fix the bug but in debian there are a new version of the same package but that dont fix this bug. What should i do? merge-request? sync-request? Send my debdiff and wait for motu answer?
[15:57] <RainCT> dcordero: merge it
[15:58] <tsmithe> so, RainCT, do i need to bother adding a lintian override for miXart8.elf?
[15:58] <tsmithe> or is it ok just to add a not to README.Debian?
[15:58] <tsmithe> *note
[15:59] <RainCT> dcordero: and forward your fix to Debian so that it can be synced for Gutsy+1
[15:59] <RainCT> tsmithe: either would do, but I think an override would be cleaner
[15:59] <tsmithe> ok
[16:01] <dcordero> ups my first merge, i'm going to read first
[16:07] <dcordero> RainCT, but i have to wait first until my debdiff are uploaded by a motu?
[16:08] <RainCT> dcordero: no, get the source from Debian, replace debian/changelog with that one in Ubuntu (adding the new entries in Debian to the top) and apply the changes from your debdiff
[16:08] <RainCT> dcordero: then upload the .diff.gz
[16:08] <RainCT> dcordero: and subscribe u-u-s
[16:09] <dcordero> i see i thought that it was an automatically process
[16:09] <dcordero> it's like a simple upstream but with carefully
[16:10] <superm1> tsmithe, once your package is in, where did you see it destined for (what component)?  also, what package was going to depend on it?
[16:11] <tsmithe> alsa-firmware? annoyingly, it will be going to multiverse, but we at Ubuntu Studio want it at least in the archive to enable many professional sound cards to work
[16:11] <tsmithe> superm1, ^
[16:11] <superm1> tsmithe, its a shame it can't make it into restricted
[16:12] <tsmithe> yes. originally, i was working on including it in l-r-m, as the dvb firmwares, but i realised that would be inappropriate: in no way does alsa-firmware depend on the kernel version, and does not require any kernel sources to build
[16:12] <superm1> neither do the dvb firmwares though
[16:12] <superm1> i hope you didn't get them booted out :)
[16:13] <tsmithe> oh no, i didn't mention it. i just thought it wasn't worth my effort, when it could be much more easily maintained, and more appropriately so, as a standalone package
[16:14] <superm1> but it would be most sensible if it could get into restricted, and then either l-u-m or l-r-m could depend on it
[16:14] <superm1> after you get it into the archive in some sense, you should try to convince the kernel guys to promote it for that reason
[16:15] <tsmithe> yes. i think i might try and get that to happen when the package is uploaded :)
[16:16] <guest22> Anyone here use the imagemagick packages? Why is the hardy version so old (6.2.4) compared with the current release (6.3.x)?
[16:16] <tsmithe> superm1, are you able to review the package when i've uploaded the next revision?
[16:16] <superm1> i should be able to in a little bit sure
[16:18] <tsmithe> superm1, thanks :)
[16:27] <LucidFox> superm1> I assume l-r-m are linux-restricted-modules, but what are l-u-m?
[16:27] <LucidFox> linux-unrestricted-modules?
[16:27] <superm1> LucidFox, linux-ubuntu-modules
[16:27] <LucidFox> ah
[16:27] <jdong> LucidFox: -ubuntu-modules
[16:27] <jdong> LucidFox: but your name is better IMO :D
[16:28] <asbin> RainCT: new candidate for libdlna package uploaded ! Can you review it please ? :)
[16:31] <RainCT> guest22: file a bug about this on https://bugs.launchpad.net/ubuntu/+source/imagemagick/+filebug?field.tag=upgrade and subscribe me, I might have a look at it
[16:31] <squentin> I've made the changes suggested by LucidFox, anyone wants to review my package : http://revu.tauware.de/details.py?package=gmusicbrowser ?
[16:32] <tsmithe> RainCT, superm1, please see http://revu.tauware.de/details.py?package=mscore for the lastest revision of alsa-firmware, thanks.
[16:33] <DaveMorris> superm1:  fancy giving opensg another look over for me?
[16:35] <RainCT> asbin: did you do any change beside those on my comment?
[16:36] <asbin> RainCT: yes, I've made all the changes you suggested
[16:36] <RainCT> btw, sistpoty, I'll send you a diff (for REVU) later :)
[16:36] <sistpoty> RainCT: cool, what will it do?
[16:36] <guest22> RainCT: Thanks for responding. After a bit more searching, I see there is already a bug report on this (#110178), but it doesn't seem to be going anywhere (the bug was reported in April last year).
[16:37] <RainCT> sistpoty: make the comment box bigger :D
[16:37] <sistpoty> RainCT: great :)
[16:38] <sistpoty> RainCT: oh, iirc the sql field for the comments was always a little bit small to store lengthy comments, maybe we should fix this as well
[16:38] <dcordero> Can someone tell me if is it right? Bug #177443
[16:38] <ubotu> Launchpad bug 177443 in photoprint "photoprint should recommend or require icc-profiles package" [Undecided,In progress] https://launchpad.net/bugs/177443
[16:39] <superm1> tsmithe, why is there all this information in the changelog?
[16:40] <superm1> debian/changelog that is
[16:40] <tsmithe> i have distributed the package in my PPA
[16:40] <superm1> PPAs don't display changelogs i thought
[16:41] <superm1> because their changelogs are not uploaded to changelogs.ubuntu.com
[16:41] <tsmithe> but the package has still been downloaded, and i want the information to be there for users when upgrading into ubuntu
[16:41] <RainCT> sistpoty: does that require anything beside changing the database?
[16:41] <tsmithe> superm1, even if the changelog isn't shown on c.u.c, it doens't mean the changelog hasn't been distributed
[16:42] <sistpoty> RainCT: nope... however it would be great if create_schema.sql would also get updated ;)
[16:42] <RainCT> sistpoty: ok, tell me what it should be and I'll add it to the diff
[16:42] <sistpoty> RainCT: no idea actually... maybe 4k or s.th.?
[16:42] <RainCT> sistpoty: btw, where is the HTML code for the comments? I couldn't find it anywhere.. (the <tr><td>.. stuff)
[16:43]  * sistpoty looks
[16:43] <LucidFox> By the way
[16:43] <RainCT> sistpoty: ok, changed it to 4096 (2x what it was before)
[16:43] <sistpoty> :)
[16:43] <LucidFox> Is it known when the name of Hardy+1 will be announced?
[16:44] <sistpoty> RainCT: looks like the <tr><td> stuff is in scripts/Comments.py
[16:45] <RainCT> sistpoty: ah, thanks
[16:46] <superm1> tsmithe, the problem is that the history doesn't consistently follow a good naming scheme
[16:46] <superm1> causing this: Description: Package switches from native to non-native version number.
[16:48] <tsmithe> superm1, so you think, in the circumstances, it would be wiser to collapse it?
[16:48] <DaveMorris> tsmithe: couldn't you do the one for ubuntu as superm1 suggest.  Then release a update on your ppa that depends on the one in Ubuntu, with the full changelog?
[16:48] <DaveMorris> since it's only your ppa users who will want the full changelog
[16:49] <tsmithe> i don't think i can depend cross-distribution?
[16:49] <tsmithe> i really don't think it's too much of a problem, just a nicety for users
[16:49] <superm1> tsmithe, actually multiple distributions are supported in debian/changelog entries
[16:49] <superm1> tsmithe, I understand that you want to preserve the history, but i agree with DaveMorris's suggestion
[16:50] <tsmithe> right, but how do i "release a update on your ppa that depends on the one in Ubuntu"?
[16:51] <superm1> well the way i interpreted it was have a package on your ppa with the full changelog
[16:51] <superm1> and then the one in ubuntu has the chopped one
[16:51] <tsmithe> ok, i can do that ;)
[16:52] <DaveMorris> then the ppa one simply has the ubuntu one as the depends
[16:52] <DaveMorris> like a meta package
[16:52]  * DaveMorris suggest you worry about the ppa one later though, and get the one for Ubuntu sorted for the end of revu day
[16:52] <sistpoty> isaac: just FYI (because I'm cleaning up revu's incoming queue): revu will accept only source uploads, not binary ones
[16:53] <dcordero> RainCT, have i wait until a motu tell me that the diff.gz is ok before send it to debian bugs?
[16:53] <dcordero> should i*
[16:54] <sistpoty> laga: same info for you: revu will only accept source uploads, not binary ones
[16:54] <RainCT> dcordero: I usually did so :)
[16:55] <dcordero> ok, i dont want laughts for my diff.gz in debian project :)
[16:56] <RainCT> dcordero: ah, and you should send a debdiff to Debian, not the diff.gz
[16:57] <RainCT> dcordero: (debdiff from their version to the merged one)
[16:58] <dcordero> without "Modify Maintainer value" i guess
[16:59] <RainCT> dcordero: right
[17:00] <laga> sistpoty: thanks, was a mistake
[17:00] <sistpoty> np, just cleaning up ;)
[17:04] <RainCT> sistpoty: hm.. has Comments.py a cache or somewhat?
[17:04] <sistpoty> RainCT: no, it doesn't
[17:05] <sistpoty> RainCT: sometimes, mod_python doesn't correctly pick up the new files, so maybe an apache2 reload will help?
[17:06] <RainCT> sistpoty: worked, thanks :)
[17:06] <sistpoty> np
[17:07] <tsmithe> RainCT, superm1; latest upload has a compacted changelog
[17:07] <sistpoty> it get's really funny if firefox also thinks the page needs to get cached... I've seen really, really strange stuff then *g*
[17:07] <superm1> tsmithe, i just left you some comments
[17:09] <tsmithe> superm1, thanks
[17:09] <RainCT> sistpoty: heh. I also have squid here, but it didn't make problems yet :P
[17:10] <sistpoty> heh
[17:10] <superm1> DaveMorris, i've still got an ack on yours from before
[17:10] <superm1> i dont see why i should go through it again?
[17:11] <DaveMorris> IMO you should ack your happy with what ever changes I made
[17:11] <DaveMorris> which lucky for you is just debain/copyright
[17:12] <mohbana> hi guys is it possible to get wxDownload Fast in the repo?
[17:12] <DaveMorris> mohbana: yes, however it's unlikey to happen for hardy
[17:13] <mohbana> ah :(
[17:13] <DaveMorris> as feature freeze is next week
[17:13] <laga> 11 days left, right?
[17:13] <DaveMorris> however you could look at the packaging guide (!packaging) and work on it for hardy+1
[17:13] <asbin> RainCT: did you take some time to review my libdlna package ?
[17:14] <RainCT> laga: yep
[17:14] <mohbana> does what mean that i can't that program even when hardy is officially released?
[17:14] <superm1> mohbana, you can always add things to a PPA
[17:14] <mohbana> !packaging
[17:14] <ubotu> The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
[17:14] <superm1> mohbana, but any new packages need to be in before that freeze
[17:14] <RainCT> asbin: oops sorry. advocated :)
[17:14] <DaveMorris> laga: yeah 14th
[17:14] <firefly2442> how long does it take to review a package?
[17:15] <superm1> this isn't to say that the final version needs to be in by then, but you'll need to justify a newer version after the freeze
[17:15] <asbin> RainCT: Thank you very much !! (first time for me :p )
[17:15] <superm1> firefly2442, depends on how well done the package is :)
[17:15] <asbin> RainCT: so I should find an other MOTU to look at it ?
[17:16] <superm1> there's some that get in and out in a few hours, and some that take a month or two
[17:16] <DaveMorris> firefly2442: also on the size
[17:16] <superm1> jdong, aren't you supposed to look at tovid?
[17:16] <RainCT> asbin: right
[17:16] <firefly2442> ok, it's pretty simple, I'm gonna try to figure out this package system this afternoon ;)
[17:16] <superm1> from a few nights ago :)
[17:16] <DaveMorris> my package has been on Revu since 5/12/07
[17:17] <asbin> can someone please review my package ? http://revu.tauware.de/details.py?package=libdlna
[17:17] <RainCT> sistpoty: http://img85.imageshack.us/img85/4969/screenhy7.png
[17:18] <firefly2442> if there is no ubuntu source package (new package) what do I do?
[17:18] <DaveMorris> !packaging | firefly2442
[17:18] <ubotu> firefly2442: The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
[17:18] <dcordero> i thought that in ubuntu development there was a lot of people but i am here since january and i think that i just know everyone :)
[17:19] <RainCT> hehe
[17:19] <jdong> superm1: I started looking at it this morning already
[17:19] <RainCT> dcordero: there are more people beside those on #ubuntu-motu, but yes, we need more :)
[17:19] <superm1> jdong, just giving you a hard time since i like being the second reviewer on things :)
[17:20] <superm1> jdong, btw i finally fixed my touch
[17:20] <jdong> superm1: sweet
[17:20] <superm1> jdong, i went into the apple store with a flash drive, the older firmware, and a usb cable and flashed it when they were busy :)
[17:20] <jdong> gpg -d <<EOF
[17:20] <jdong> GRR
[17:22] <jdong> superm1: haha, NICE :)
[17:23] <superm1> jdong, i was going to upgrade it to 1.1.3 while i was there again, but they used opendns to block the jailbreak website in the store
[17:23] <jdong> superm1: the iPhone Dev Team really needs to get a client for accessing the iPod via USB :)
[17:23] <superm1> yeah i know
[17:23] <jdong> of course it's easy for us to sit back and say that :D
[17:24] <superm1> it's not as urgent though by them because they can just use itunes libraries to access it on windows and mac i believe
[17:28] <superm1> asbin, i've got some comments on the way in a few minutes here
[17:28] <asbin> superm1:
[17:28] <asbin> superm1: ok thanks !
[17:28] <sistpoty> RainCT: nice!
[17:29] <jdong> superm1: well their hack still only works with iTunes 7.4.2
[17:29] <superm1> ah
[17:29] <jdong> superm1: and on firmware 1.1.3 iPHUC panics my iPod
[17:29] <jdong> so the tool is nearly useless
[17:30] <MetalMusicAddict> Hi all. If anyone wants to tackle a little bug please look at bug #188678.
[17:30] <ubotu> Launchpad bug 188678 in scribus "Menu entry for Scribus does not show icon." [Undecided,New] https://launchpad.net/bugs/188678
[17:30] <superm1> jdong, well i haven't even  loaded any music on mine since restoring.  as long as i can use last.fm, i'm fine
[17:35] <sistpoty> mok0: just taking a look at ssm... while I'm not familiar with the new debian/copyright format yet, I guess it should be LGPL-2.1+ instead of LGPL-2.1 for the sources (at least according to the headers)
[17:36] <mok0> sistpoty: you are right
[17:37] <mok0> sistpoty: if you are willing to advocate, can you make that change for me?
[17:37] <sistpoty> mok0: I'm just taking a final look, one second please ;)
[17:38] <sistpoty> mok0: ok, others than that looks good! I'd say just make the change yourself and upload to the archive ;)
[17:38] <mok0> sistpoty: errr? I can't
[17:38] <sistpoty> mok0: you aren't a MOTU yet?
[17:38] <mok0> sistpoty: nope
[17:38] <sistpoty> mok0: heh, thought you were *g*
[17:38] <sistpoty> mok0: sure, will do that
[17:39] <mok0> sistpoty: thanks!
[17:39] <mok0> sistpoty: I still have some things I want to do before I submit my application for MOTU
[17:39] <sistpoty> kk
[17:41] <firefly2442> is there a tool to create a .dsc file?
[17:42] <mok0> firefly2442: It is created by dpkg-buildpackage
[17:42] <firefly2442> ok thanks, and I run that after my debian folder is setup correctly?
[17:43] <mok0> firefly2442: yes
[17:43] <mok0> firefly2442: If you add the -S flag
[17:45] <RainCT> sistpoty: http://paste.ubuntu.com/4147/ - that's the diff to get what's shown on the screenshot
[17:46] <RainCT> sistpoty: I'm planning some more changes to the table that shows the comments but I'm not sure I'll do that this week because of exams
[17:47] <firefly2442> is this correct for ubuntu version number for initial new release? (1.0.5-0ubuntu1) hardy; urgency=low
[17:47] <james_w> firefly2442: yep.
[17:47] <mok0> firefly2442: looks good
[17:47]  * firefly2442 is getting excited ;)
[17:47] <sistpoty> RainCT: looks great, thanks a lot!
[17:48] <RainCT> sistpoty: np :)
[17:48] <RainCT> who wanted me to review something? :P
[17:49] <ScottK2> mok0: Interested in a merge that will excercise your skills?
[17:49] <mok0> ScottK2: What is it?
[17:50] <ScottK2> mok0: courier
[17:50] <mok0> ScottK2: the imap server?
[17:50] <ScottK2> mok0: imap, pop, mta, webmail, all of it (except the authlib part)
[17:50] <jdong> LucidFox: commented on tovid (cc: superm1)
[17:50] <mok0> ScottK2: I can take a look
[17:51] <ScottK2> mok0: I'll be glad to sponsor it when you've got a debdiff.
[17:51]  * LucidFox looks
[17:51] <mok0> ScottK2: I'll give you a ping, then
[17:52] <LucidFox> yes, I think the mplayer dependency makes sense - tovid is going to end up in multiverse anyway
[17:52] <jdong> LucidFox: right
[17:52] <jdong> diverting some of the binaries into a private dir also saves you a lot of manpage work :D
[17:52] <jdong> but shhhh that's not the primary motivation ;-)
[17:53] <LucidFox> I already diverted quite a few scripts to /usr/share/tovid
[17:53] <jdong> I did see that
[17:53] <jdong> but I think more needs to be diverted
[17:53] <crimsun> that's a copout, really, and the more stringent sponsors will call you on it.
[17:53] <jdong> postproc, pymakexml both IMO are too generically named to live in the $PATH
[17:53] <nixternal> persia: I haven't seen anything since the Zaurus, at least not that I can think of, that has a decent keyboard and can fit into a pocket..I have seen the newer Sharp Zaurus, is is much nicer and smaller
[17:54] <LucidFox> jdong> sadly, tovidgui generates conversion scripts that rely on them being in PATH
[17:54] <jdong> I think to{disc,vid}* for sure should live in path... even like make* I think are  too generically named
[17:54] <jdong> LucidFox: yuck :(
[17:55] <jdong> LucidFox: they're bash scripts, right? Why don't we source a common file that sets up an expanded PATH for to*
[17:56] <jdong> LucidFox: and yikes, tovid uses mplayer extensively, we should make that a Depends:
[17:57] <LucidFox> that makes sense, I could look into the tovidgui code and see how it generates the scripts
[17:58] <jdong> crimsun: re diverting the helper scripts, what do you recommend doing? Installing a binary called "makexml" into /usr/bin that is specific to generating DVD layouts is a bit unreasonable to me
[17:58] <jdong> I agree that it's no excuse to  skip writing manpages, I meant that jokingly :)
[17:58] <LucidFox> Wait.....
[17:58] <LucidFox> so I need a manpage for _every_ script in /usr/share/tovid?
[17:59] <jdong> LucidFox: would you expect the average user to need to call any of them?
[17:59] <LucidFox> No
[17:59] <jdong> LucidFox: I think manpages only for the scripts you've already listed in debian/control's long descriptions
[17:59] <jdong> regardless of whether we divert them int /usr/share
[17:59] <LucidFox> the average user _may_, however, use makexml
[17:59] <jdong> because those are scripts that average users might need
[17:59] <LucidFox> in scripts
[18:00] <emgent> heya
[18:00] <LucidFox> (if said users don't use the GUI)
[18:00] <LucidFox> How about renaming them? tovid-makexml, tovid-makedvd...
[18:01] <firefly2442> are the postinst and prerm scripts optional?
[18:01] <jdong> LucidFox: that's also a good alternative
[18:01] <jdong> LucidFox: or $origname.tovid
[18:02] <crimsun> jdong: while avoiding namespace pollution is Good, consider whether the script(s) is useful to an unprivileged user /and/ is useful solely from the CLI.
[18:03] <LucidFox> Renaming would require a _lot_ of patching, though :(
[18:03] <tsmithe> hmm. i want to do something like http://paste.ubuntu.com/4148/ in my debian/rules, but it won't work, because of the way Make executes commands, i suppose. what could i do instead, or to fix it?
[18:03] <tsmithe> i suppose it is clear what i am trying to achieve
[18:04] <jdong> LucidFox: I think diverting + supplementing $PATH is easier for now...
[18:04] <LucidFox> I think if the user is advanced enough to write scripts featuring tovid CLI commands, they might as well slap PATH=/usr/share/tovid:$PATH at the beginning
[18:04] <jdong> LucidFox: agreed
[18:04] <jdong> LucidFox: this should be mentioned in a README.Debian though
[18:05] <LucidFox> Indeed.
[18:05] <crimsun> tsmithe: why do they need to be in /usr/share/alsa/firmware in the first place?  Does using debian/*.install not suffice?
[18:06] <LucidFox> So, we can divert make*, postproc and pymakexml, and leave the following in /usr/bin: idvid, tovid, tovid-*, todisc, tovidgui, todiscgui, and todraw
[18:06] <LucidFox> (I'm not sure if todraw is even needed, frankly)
[18:06] <tsmithe> crimsun, they don't need to, but i just want to preserve compatibility, and using symlinks is better than overwriting /usr/share/alsa/firmware/*
[18:06] <tsmithe> i could just not bother, of course
[18:06] <cyberix> I'm looking after first advocate for my package Malbolge. I've fixed all broblems that have been brought up. http://revu.tauware.de/details.py?package=malbolge
[18:06] <crimsun> tsmithe: preserve compatibility with which Ubuntu releases?
[18:07] <tsmithe> none :) so i suppose it won't matter; i don't need to fix other people's broken systems
[18:07] <jdong> LucidFox: I agree with the diversions; let's leave todraw in there for now. I also feel it's a pretty pointless app but we are the packagers and it's not our job/jurisdiction to decide that :)
[18:08] <crimsun> tsmithe: right.  [In any case, it would have been better to use debian/*.links; see dh_link(1).]
[18:09] <sistpoty> superm1: heh, lost update... was just looking at libdlna as well
[18:09] <superm1> sistpoty, well the more the merrier i suppose
[18:09] <tsmithe> crimsun, ah yes i'd totally forgotten about dh_link; thanks
[18:09] <crimsun> tsmithe: np
[18:10] <mohbana> 1) ok since its not likely that wxDownload Fast is going to be included into hardy can we expect to see it in gusty? 2) how long does actually packing a program take?
[18:11] <sistpoty> superm1: btw.: what do you mean with 4?
[18:11] <superm1> sistpoty, dhslibs doesnt catch those dependencies
[18:11] <superm1> sistpoty, so thats why he explicitly listed them
[18:12] <sistpoty> superm1: which dependencies?
[18:12] <superm1> sistpoty, and i couldnt get it to myself either, i suspect because libtool isn't used by the project
[18:12] <emgent> sistpoty, heya
[18:12] <sistpoty> hi emgent
[18:12] <superm1> sistpoty, the dependencies on libdlna-dev
[18:12] <superm1> sistpoty, eg libdlna0
[18:13] <sistpoty> superm1: afaik there is no automatic way to get the dependencies for a -dev package
[18:14] <sistpoty> superm1: it cannot be done through the dh_shlibdeps way, and I'm not aware of a different mechanism
[18:14] <superm1> sistpoty, i had thought that they would be generated when you had a library*.la?
[18:14] <sistpoty> superm1: from which tool?
[18:14] <superm1> well I had thought dh_shlibdeps handled it when it worked on the .la, but i was mistaken i suppose :)
[18:15] <sistpoty> it didn't do it some time ago at least... *g*
[18:15] <cyberix> What are my odds of getting my package reviewed by two reviewers before revu day ends?
[18:15] <crimsun> 50%.
[18:16] <crimsun> either it will be reviewed by two, or it won't.
[18:16] <cyberix> :-D
[18:16] <asbin> superm1: the dh_shlibdeps generate the debian/*.substvars
[18:16] <asbin> used in the debian/control file with "${shlibs:Depends}"
[18:17] <asbin> but it's not handle the deps between bin and -dev package
[18:17] <asbin> (can't find the man where I've read that ...)
[18:17] <jdong> crimsun: oh btw do you feel like sponsoring yet another transmission release?
[18:17] <jdong> :D
[18:17] <superm1> okay, so I was mistaken there.  my apologies
[18:18] <nixternal> man, the 3rd got here rather quickly...did you attempt to leave some work for me? :)
[18:18]  * sistpoty didn't find anything about libtool stuff in there as well (and actually /me would have put *that* in a different program)
[18:18] <nixternal> gotta do my work before the superbowl commercials kick in
[18:18] <superm1> nixternal, there's plenty of stuff left for you
[18:18] <superm1> worry not
[18:19] <nixternal> dang, I was actually hoping for the opposite :p  anything need attention right now, a 2nd "yes", or something that hasn't been hit on yet?
[18:19] <superm1> i was gonna look at tovid, but you can take it
[18:20] <nixternal> roger
[18:20] <yamal> Any motu willing to review the latest revision of http://revu.tauware.de/details.py?package=sabnzbdplus please? thanks.
[18:20] <superm1> that and you should queue up opensg to build during the game nixternal
[18:20] <superm1> it takes forever to build (which is why no one looks at it i suppose)
[18:20] <nixternal> heh
[18:21] <nixternal> I can build that on my server and not even look at it
[18:21] <tsmithe> i've uploaded a new upstream release of mscore to revu <http://revu.tauware.de/details.py?package=mscore> (a previous version is already included in hardy). persia, bddebian, you were the last reviewers, if you're interested in this new upload :) anyone else, feel free!
[18:21] <crimsun> jdong: sure; URL?
[18:22] <nixternal> superm1: tovid already has a "no" response with no new updates, so next then
[18:23] <superm1> nixternal, oh sorry.  jdong had looked at it and said something to me, but i didnt click yet, i assumed it was a yes :)
[18:23] <superm1> take opensg then i say
[18:23] <nixternal> lovely, the first comment is "I have a super computer and it take more than 4 hours to build"
[18:23] <jdong> crimsun: bug 187234
[18:23] <ubotu> Launchpad bug 187234 in transmission "New upstream version: 1.03" [Low,Confirmed] https://launchpad.net/bugs/187234
[18:23] <jdong> the last dsc I posted
[18:23] <nixternal> hey, I give him points for at least providing a warning
[18:24] <tsmithe> also, superm1, (crimsun?), i've uploaded a new revision of alsa-firmware fixing all previously mentioned issues, if you want to check it out
[18:24] <jdong> superm1: I thought you'd be interested in looking at my comments and possibly adding to them as the second reviewer :)
[18:24] <tsmithe> crimsun, did you get my e-mail regarding the rationale against working on inclusion in l-r-m?
[18:24] <nixternal> Possibly more to follow in ~ 4 hours.  <- hahaha persia :)
[18:25] <crimsun> tsmithe: no, sorry.  (E-mail is the most unreliable method of reaching me, which is why I don't act as the bug contact on most of the source packages I work on.)
[18:26] <tsmithe> crimsun, ah, well, basically, i decided that as it does not depend on kernel sources, nor is it kernel-version specific, i thought maintaining a chunk in l-r-m would not be worth the effort, especially when i had a functioning standalone package already
[18:26] <crimsun> tsmithe: sounds sane enough
[18:26] <tsmithe> :)
[18:29] <Coper> Can someone review my new package http://revu.ubuntuwire.com/details.py?package=console-freecell
[18:32] <LucidFox> jdong> tovid will have to have a hard dependency on ffmpeg as well - it's used by toyoutube
[18:33] <jdong> LucidFox: ok, that's fine too :)
[18:34] <LucidFox> I swear, if this gets into Ubuntu, I'll join upstream to rewrite todiscgui in something less out of the 90s than Tk.
[18:35] <squentin> Anyone wants to look at http://revu.tauware.de/details.py?package=gmusicbrowser ?
[18:35] <LucidFox> squentin> Now that I test-built it, it looks clean to me, but IANAMOTU
[18:36] <squentin> LucidFox: ok thanks, any MOTU ?
[18:37] <LucidFox> jdong> What should I do with manpages for diverted scripts?
[18:38] <nixternal> opensg in the process of building now
[18:40] <RainCT> squentin: looking :)
[18:40] <squentin> thanks
[18:44] <tsmithe> superm1, thanks for the advocation of alsa-firmware :) any other motu who wants to do the same would be much appreciated
[18:45] <ScottK2> tsmithe: For that one a +1 from crimsun would be a really good thing.
[18:47] <tsmithe> crimsun, if you have the time ^ :)
[18:47] <asbin> my package (libdlna) was just been approved, thanks to sistpoty, superm1, and RainCT (thank you very much !!) ... what is ne next step ? Is it long to have it avalaible on the official repository ?
[18:48] <DaveMorris> nixternal, I didn't wanna run it on the cluster at work
[18:48] <sistpoty> asbin: usually the last one to approve it will upload it
[18:48] <superm1> sistpoty, which i did
[18:48] <asbin> sistpoty: yes, superm1did it
[18:48] <sistpoty> asbin: then it will need to go through source new
[18:48] <superm1> asbin, so you'll just need to hang tight now
[18:48] <superm1> asbin, an archive admin has to ack it and put it into the right section
[18:48] <sistpoty> asbin: i.e. a archive-admin will need to check again for copyright and other big errors
[18:49] <sistpoty> asbin: the it gets built, and will need to go through binary new (usually w.o. much delay)
[18:49] <asbin> sistpoty: ok ! good :)
[18:49] <superm1> if there are any troubles either asbin or I will get an email, (if i do and asbin doesn't, i'll send you a copy)
[18:49] <sistpoty> asbin: then you can install it (unless you use a mirror, which is always one day behind, like I do *g*)
[18:49] <asbin> I have an other package to review (ushare), but it depend on libdlna0 and libdlna-dev packages ...
[18:50] <asbin> any chances to have it on hardy at time ?
[18:50] <superm1> asbin, i'm taking a look at that right now too
[18:50] <nixternal> DaveMorris: if this thing needs a cluster for building, I QUIT :D
[18:50] <asbin> superm1: you're the best
[18:51] <nixternal> asbin: I have been telling him that for a while, so we might want to chill a little bit on that so his head doesn't get any bigger :p
[18:51] <nixternal> I mean come on, who comes to a LUG even with a laptop that has those rabbit ears, tv antennae, on it? :D
[18:51] <nixternal> s/even/event
[18:52] <asbin> lol
[18:54] <nixternal> superm1: speaking of which, I was watching TV yesterday and heard your last name on there...talking about a desert of course :)
[18:55] <desertc> Can I ask some general terminology questions please?  When someone talks about a package namespace, do they refer to SONAME or the package name?  Or something else?
[18:56] <desertc> maybe it would have been more clear to say, an application's namespace
[19:03] <LucidFox> jdong> reuploaded tovid
[19:13] <sistpoty> desertc: sorry, got just disconnected
[19:15] <superm1> nixternal, yeah its a liquor
[19:15] <superm1> its very good
[19:15] <superm1> i've made it in the past
[19:15] <superm1> its spelled a little differently though
[19:15] <nixternal> ahh, didn't know that...but I was like hey! that's Mario's last nmae
[19:15] <superm1> limoncello is the liquor
[19:15] <superm1> limonciello is the last name
[19:15] <nixternal> pronounced the same though?
[19:15] <superm1> yeah
[19:15] <superm1> it comes from the same area that my family comes from
[19:16] <nixternal> ya, I only heard them say, didn't see how they spelled it
[19:16] <superm1> well if you are ever at an event that they have it, be sure to try some
[19:17] <superm1> if i can get a hold of some more grappa from my family soon, i'll make it again
[19:18] <RainCT> squentin: commented
[19:19] <superm1> when something is sitting at MANUALDEPWAIT, is there a cron job that goes through to check for those depends again, or is that literally manual waiting for someone to touch it?
[19:19] <ScottK2> superm1: IIRC it's not really manual.
[19:20] <superm1> okay that's good. thanks
[19:23] <hellboy195> Hey guys. A config.guess is modified every time ./configure was called right?
[19:24] <mohbana> 1) ok since its not likely that wxDownload Fast is going to be included into hardy can we expect to see it in gusty? 2) how long does actually packing a program take?
[19:25] <mohbana> hey guys are we going to see eclipse 3.3 in hardy?
[19:25] <RainCT> yamal: sabnzbdplus advocated :)
[19:25] <RainCT> hellboy195: I think so
[19:26] <hellboy195> RainCT: thx, because I'm doing a merge and the debdiff shows me things I haven't changed at all and all in the config.guess file
[19:26] <RainCT> mohbana: 2) depending on the program.. somewhat between 20 minutes to days.. :P
[19:26] <RainCT> hellboy195: yes, just remove the stuff that you didn't change from the debdiff
[19:26] <hellboy195> mohbana: well, eclipse 3.3 isn't even in Sid -.-
[19:26] <ScottK2> RainCT: You've done one in 20 minutes?
[19:26] <ScottK2> 1 hour is my best.
[19:27] <RainCT> ScottK2: no, but I guess that one-script packages, metapackages and such don't need much more :P
[19:27] <jdong> ScottK2: I guess it's possible with a very clean upstream
[19:27] <hellboy195> RainCT: sure?
[19:27] <yamal> great! thanks, RainCT :)
[19:27] <jdong> ScottK2: and a lot of trust with them, too :)
[19:27]  * sistpoty is now off again (cooking, enjoying the sunday evening)... cya
[19:27] <jdong> mohbana: as I've answered this before, not at this rate unless someone steps up to the job
[19:27] <jdong> mohbana: eclipse tends to be very difficult to package
[19:28] <ScottK2> I think debian/copyright took me about 30 of the 60 minutes.
[19:28] <hellboy195> ScottK: what if I leave the changes in the debdiff? anything wrong with it?
[19:29] <ScottK2> hellboy195: Context please?
[19:30] <RainCT> hellboy195: yes, that the reviewer might not like it
[19:30] <hellboy195> ScottK: ah sry. false guy :\
[19:30] <hellboy195> RainCT: k, I'll delete the changes. thx :)
[19:30] <jdong> jeez deluge takes forever to build
[19:32] <hellboy195> RainCT: also the timestamp?
[19:32] <RainCT> hellboy195: yes
[19:32] <hellboy195> :)
[19:32] <RainCT> hellboy195: everything that you didn't touch yourself
[19:32] <jpatrick> ...
[19:36]  * jdong is a big confused by backports testers
[19:36] <jdong> https://bugs.edge.launchpad.net/gutsy-backports/+bug/177692/comments/1
[19:36] <ubotu> Launchpad bug 177692 in gutsy-backports "Please backport fftw3 3.1.2-3ubuntu1 from hardy" [Undecided,Incomplete]
[19:36] <jdong> Built with prevu, installed..everything seems to work fine, even packages that depends from fftw3 (line zynaddsubfx) removed when I'd installed libfftw3-3
[19:36] <jdong> err... wait... WHAT was that last part?
[19:37] <jdong> obviously we all have different things that we call "fine" :)
[19:37] <ScottK2> Yeah
[19:37] <pochu> "Hey, this backport conflicted with the kernel so I removed it and it installed fine, please backport it kthxbye!"
[19:38] <jdong> :D pretty much
[19:38] <jdong> "Basically all the reverse deps are uninstallable now, it's working great! please backport"
[19:38] <pochu> heh
[19:38] <pochu> Who cares about reverse dependencies? ;)
[19:39] <ScottK2> fine == as expected maybe?
[19:40] <jdong> Maybe. At any rate I set it to incomplete asking for the commenter to elaborate
[19:40] <jdong> I hope I'm misunderstanding him
[19:40] <ScottK2> BTW, I'm about ready to embark on another round of clamav.  Dapper seems to have gone just fine.
[19:40] <jdong> ScottK2: fun :)
[19:40] <ScottK2> That was the hardest one.
[19:41] <ScottK2> Speaking of reverse dependencies.
[19:41] <ScottK2> jdong: I think that the process we're using for clamav could be a model for other wanted library backports.
[19:42] <jdong> ScottK2: what specifically is the process being used?
[19:43] <desertc> When you build a package from source, it ends up being for your architecture.  Just curious, but how does this package ultimately become available for all other architectures?
[19:43] <superm1> desertc, buildd's of each architecture
[19:43] <superm1> they each will build the source package
[19:44]  * jdong approves the firefox-3.0 backport pair. Let the crack ensue
[19:45] <asbin> superm1: nex upload/comments for ushare package
[19:45] <asbin> *new
[19:47] <ScottK2> jdong: We have a wiki to track test progress.  All needed packages are built against the new lib in a ppa so testers don't have to make there own.  Once we've got full test coverage, then the backport can be executed.
[19:47] <ScottK2> jdong: https://wiki.ubuntu.com/MOTU/Clamav and https://launchpad.net/~ubuntu-clamav/+archive
[19:47] <ScottK2> It's not a small effort.
[19:48] <jdong> ScottK2: that's beautiful, and I believe it can scale well to libraries with an isolated pocket of reverse dependencies AND it's acceptable to break compatibility
[19:49] <jdong> ScottK2: something like clamav, sure, but for ffmpeg, even if revdeps were rebuilt I still wouldn't like to break libav{format,codec}'s ABI/API for the potential of 3rd party software building on it
[19:51] <ScottK2> jdong: Agreed, but right now the policy is "No libraries".  I think we can relax that a bit and use this as a pointer (or for non-library packages with lots of rdpends).
[19:53] <jdong> ScottK2: The wiki page I believe is looser than no libraries
[19:53] <jdong> #
[19:53] <jdong> New versions of libraries are strongly discouraged:
[19:53] <jdong>    1.
[19:53] <jdong>       If the new version does not break its API and ABI, then it should be fine.
[19:53] <jdong>    2.
[19:53] <jdong>       If there is an API/ABI breakage, but it only affects few (1 or 2) packages that can be fixed by rebuilding or backporting, an exception can be made.
[19:54] <ScottK2> OK.  Fair enough.
[19:54] <ScottK2> So I didn't break the rules when I did clamav.  Darn.
[19:55] <jdong> ScottK2: the clamav process is more like the way I'd like to see #2 handled for n >> 2
[19:55] <ScottK2> Yeah.
[19:59] <nixternal> opensg building for 1 hour now
[19:59] <nixternal> 3 to go? :)
[19:59] <nixternal> stay tuned
[20:00] <ScottK2> nixternal: You could start a build of pypy and eclipse in parallel if you need to warm up the room.
[20:00] <nixternal> heh
[20:00] <nixternal> my server fans are in over drive
[20:00] <nixternal> and you know how my 64 desktop is acting with scribus
[20:00] <ScottK2> Yeah.
[20:00] <nixternal> but I should try another package and see if it behaves differently
[20:00] <martoss> hi all,
[20:00] <nixternal> actually, I built kdelibs on it this morning just fine
[20:01] <martoss> what should I do if a package want's to create /usr/lib/python2.5/site-packages/eric4plugins?
[20:01] <ScottK2> martoss: Are you messing with eric?
[20:01] <nixternal> w00t, eric4!
[20:01] <martoss> yepp
[20:01] <ScottK2> eric 4 is already in the archive
[20:01] <nixternal> I hope so, we (I) need Eric 4 badly in the repos
[20:01] <nixternal> is it?
[20:02] <ScottK2> Yeah.  I did it last week or the week before.
[20:02] <martoss> porting the 4.0.4 to 4.1.0
[20:02] <nixternal> ahh so it is still in new then
[20:02] <nixternal> ScottK2: you are my hero!
[20:02] <martoss> ScottK, so you packaged it already?
[20:03] <ScottK2> nixternal: No.  In the archive https://launchpad.net/ubuntu/hardy/+source/eric/4.0.4-1ubuntu1
[20:03] <ScottK2> martoss: I merged 4.0.4 so it worked in Ubuntu
[20:03] <ScottK2> It was packaged by Debian.
[20:04] <martoss> yes, but guidon (the debian maintainer) was asking me if I could do the 4.1.0
[20:04] <ScottK2> Ah.
[20:04] <martoss> which came out  today ;-)
[20:04] <doofy`> Theres about 50 different packaging guides... where does everyone suggest I start?
[20:04] <nixternal> hrmm, isn't showing up with apt-cache
[20:05] <ScottK2> martoss: Give me a link to your .dsc and I'll have a look at it.
[20:06] <martoss> can I create a dsc if packaging fails?
[20:06] <ScottK2> martoss: debuild -S just makes a source package.
[20:06] <martoss> ah, ok ...
[20:07] <cyberix> /me is hoping to get his package malbolge approved before freeze. Please give me any feedback. Advocating would be appreciated too. ;-) http://revu.tauware.de/details.py?package=malbolge
[20:12] <martoss> ok, uploading it to revu atm.
[20:12] <jdong> Ok, all Confirmed status gutsy-backports have been processed
[20:13] <dcordero> hi
[20:13] <martoss> ScottK2, ok is up
[20:15] <dcordero> when is freezen hardy?
[20:16] <jpatrick> dcordero: 14th
[20:17] <dcordero> thanks
[20:17] <vorian> afternoon all :)
[20:20] <ScottK2> martoss: Where?
[20:21] <martoss> oh, i used my standard revu dput profile...
[20:21] <ScottK2> Ah.  OK.  Leave a comment that it's not up there to try and get uploaded and shouldn't be reviewed.
[20:22] <martoss> I see...
[20:23] <ScottK2> martoss: Got it
[20:26] <doofy`> i'm trying to run debuild -S and im getting gpg: [stdin]: clearsign failed: secret key not available at the end... my key is in my environment variables in ~/.bashrc
[20:26] <dcordero> doofy`, do you have .gnupg ?
[20:27] <dcordero> ~/.gnupg i mean
[20:28] <doofy`> yep theres a few things in there
[20:29] <dcordero> mmm debuild -S asked you by your phrase for your key?
[20:29] <ScottK2> slangasek: Would you be up for a qa upload in Debian to clear an RC bug?
[20:30] <doofy`> i can paste the whole build output to a pastebin or something if that helps? I'm just trying to learn this stuff so im not really sure what the whole process is doing anyways ;)
[20:30] <dcordero> ok, great idea :)
[20:32] <doofy`> while im doing this im a little confused about a few things... dh_make is just setting up all the necesarry files in debian/ correct?
[20:32] <ScottK2> Yes.
[20:32] <ScottK2> Often many more than necessary
[20:32] <doofy`> appears so :)
[20:34] <vemon> is it ok to put a package into my ppa when thre are still some problems with the licensing of "recipes" included with the package. i mean if a gpl2 licensed soft synth package doesn't say anything specific about the synth patches shipped with it
[20:35] <vemon> (the stuff should be public domain or something similar if licensed)
[20:35] <rexbron> Hey everyone, I am looking to get two packages reviewed: http://revu.tauware.de/details.py?package=openlibraries and http://revu.ubuntuwire.com/details.py?package=openfx
[20:35] <squentin> I've made the changes suggested by RainCT, anyone to review http://revu.tauware.de/details.py?package=gmusicbrowser ?
[20:35] <doofy`> im also getting Could not find hello-debhelper_2.1.1.orig.tar.gz
[20:35] <doofy`>  with dh_make... i can fix that by renaming the tarball to that that I downloaded and extracted, but im a little confused as to whats going on with the orig stuff?
[20:38] <asbin> superm1: new upload/comment for ushare package :)
[20:38] <dcordero> doko, .orig.tar.gz is create with dh_make if you indicate to dh_make the tar.gz you have, for example: dh_make -e your@email.com -f ../hello.tar.gz
[20:38] <ScottK2> dcordero: doofy`, not doko.
[20:39] <doofy`> i knew he was talking to me :) I suppose what im confused about is what the orig is used for
[20:39] <dcordero> ups
[20:39] <doofy`> to make diffs?
[20:39] <dcordero> my tab failed :)
[20:40] <doofy`> so for example you would download the original, dh_make it... then make necesarry pathches and build it with pdebuild or debuild?
[20:40] <dcordero> the orig.tar.gz alway contain the original fails without the changes that you do for create the package
[20:40] <dcordero> files*
[20:41] <doofy`> just to have as a reference? or is it actually used in the building process?
[20:42] <superm1> asbin, only this is use dh_installman instead i'd say
[20:42] <superm1> or package.manpages
[20:42] <superm1> in the debian/directory
[20:42] <doofy`> dcordero, http://pastebin.ca/890536 there is the output of debuild -S
[20:43] <superm1> makes it easier to add new pages, and possibly sections
[20:44] <dcordero> doofy`, check character by character that you are using exactly the same name and email that you have in your gpg key
[20:44] <doofy`> where is the GPG key kept?
[20:45] <dcordero> do you use gnome?
[20:46] <dcordero> i suggest you "seahorse" for your keys
[20:46] <doofy`> dcordero, yes
[20:46] <dcordero> i have to go
[20:46] <doofy`> alright ill check the key, thanks a lot
[20:47] <ScottK2> martoss: Looks like modDir is set to the wrong place.  Look at the 4.0.4 package for where the plugins should go.
[20:47] <desertc> Regarding the proposed Mumble package: I am unsure on what the Ubuntu MOTU Team's position is any more.  My impression was that a new version of Speex was required, so that Mumble would not need it's own embedded libraries.
[20:48] <martoss> ScottK, ok
[20:48] <desertc> So, I have been working with the groups involved to determine what needed to be done to get the latest Speex libraries in place.
[20:49] <doofy`> .dsc are just package files? They can be either source or binary correct?
[20:50] <desertc> Now however, I get the feeling we are going to move forward with putting the present Mumble into Hardy even with the embedded Speex libraries.  This is because (1) it sounds like Mumble actually needs an unreleased 1.2~beta4, and (2) Mumble package was just approved today in REVU
[20:50] <desertc> All of this change in direction is fine and good, but I wonder if I should be working on the new Speex library packages, or not.
[20:50] <jmspeex> 1) There's no such thing as 1.2-beta4
[20:51] <desertc> jmspeex: Exactly
[20:51] <jmspeex> and never will be...
[20:51] <jmspeex> What Mumble depends on is hooks it put to break the abstraction on some features.
[20:51] <desertc> Well, replace 'unreleased 1.2~beta4' with  'an unreleased version', I guess
[20:51] <geser> doofy`: .dsc belongs to source packages
[20:52] <jmspeex> The author is trying to convince me to add some of these to libspeexdsp itself, but we'll see
[20:52] <DRebellion> Could someone give me a pointer to a guide/faq on how one would go about porting a debian package to ubuntu?
[20:52] <Adri2000> doofy`: a debian source package is usually a .orig.tar.gz + a .diff.gz + a .dsc. the orig is the original tarball provided by upstream. the .diff.gz is basically the content of the debian/ directory (actually it's all what is needed for the package), and the .dsc is a text file containing some information about the package
[20:52] <jmspeex> desertc: What I mean is that it's not something that's in the Speex svn/git, but something he did himself
[20:52] <ScottK2> jmspeex: It's certainly make distro's lives easier only having to support one copy of speex.
[20:53] <jmspeex> ScottK: What happens is that Mumble uses a *customized* version of Speex, not just a prerelease.
[20:53]  * Fujitsu prepares the weapons.
[20:53] <doofy`> the .diff.gz would contain source changes too?
[20:54] <Adri2000> yes
[20:54] <ScottK2> jmspeex: I understand.  I was expressing a hope that the need for those customizations would go away.  I don't know if that's a reasonable hope or not.
[20:55] <doofy`> so sudo pbuilder build ../*.dsc builds the binary... what does it do with it once its built?
[20:55] <jmspeex> ScottK: It's reasonable, but I can't say whether it'll actually happen. We need to find a way to put the features he needs without ending up restricting the implementation
[20:55] <desertc> jmspeex: This seems like an opportunity to get Debian/Ubuntu off that developmental and experimental Speex version that seems to have been embraced for the last several years.
[20:56] <jmspeex> Another option is to mark that part of the API as "unstable", but then we'll run into the same kind of problem as before
[20:56] <DRebellion> doofy`: puts it in /var/cache/pbuilder/result/
[20:56] <slicer> jmspeex: I can adapt :)
[20:57] <doofy`> DRebellion, as a .deb correct?
[20:57] <DRebellion> doofy`: yes
[20:57] <jmspeex> slicer: first, is st->ps really useful?
[20:57] <slicer> jmspeex: I've done so all through the different 1.1 and lately the SVN releases. I can guarantee that when you release an updated API for Speex, there will be an updated version of Mumble to use it :)
[20:57] <DRebellion> Could someone give me a pointer to a guide/faq on how one would go about porting a debian package to ubuntu? Or at least give a newbie some guidance ;)
[20:57] <slicer> jmspeex: Perhaps we should move the patch-techincal discussion to #speex?
[20:58] <jmspeex> slicer: second, would st->prop be enough for the AEC instead of st->W?
[20:58] <jmspeex> slicer: OK
[20:59] <desertc> jmspeex: I know I am speaking out of my place here, but maybe it is time to stabilize 1.2 and start on 1.4 ?  Seems like your concerns are whether you can change those exposed APIs that slicer wants.
[21:00] <desertc> Just tossing the idea out there.  :-)
[21:00] <doofy`> I'm a little confused as to what happens when you want to modify the upstream tarball you downloaded... You download it, extract it, dh_make it so you end up with the orig. Then you would modify it and debuild it. You end up with a .diff.gz and a .dsc. Where do are your source changes found?
[21:00] <ScottK2> in the diff.gz
[21:00] <jmspeex> desertc: You're indeed speaking out of your place
[21:02] <doofy`> ScottK2, so then what is done with that stuff? Uploaded to bzr? and is just the .diff.gz that is sent?
[21:03] <vemon> shouldn't that be attached to a launchpad bug?
[21:03] <vemon> the diff.gz i mean
[21:03] <doofy`> ah yes
[21:04] <doofy`> im just trying to get a feel for how this whole process works
[21:04] <RainCT> DRebellion: nothing :)
[21:04] <DRebellion> RainCT: just download the debian source, edit versions, and re-compile for ubuntu? :)
[21:05] <RainCT> DRebellion: no, request a sync and an archive admin will copy the sources into Ubuntu (and the binary will be recompiled)
[21:05] <RainCT> DRebellion: that is, what you said, but without editing the changelog (version) :)
[21:06]  * DRebellion is slightly confused
[21:07] <doofy`> once diffs are uploaded to launchpad are they reviewed and then added to compilation servers or what?
[21:08] <DRebellion> RainCT: can you elaborate a bit>
[21:08] <RainCT> DRebellion: Ubuntu is using *exactly* the same packages as they are in Debian whenever this is possible, they are just rebuilded but the source is left intact
[21:08] <doofy`> err that was confusing... forget that question
[21:10] <DRebellion> RainCT: okay, so how can I get a debian package into ubuntu?
[21:10] <RainCT> !sync
[21:10] <ubotu> Sorry, I don't know anything about sync - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[21:12] <RainCT> DRebellion: just report a bug on https://bugs.launchpad.net/ubuntu with the title "Please sync <package name> <version> from Debian unstable (<main/contrib/nonfree>)", explain in the description what it is and say that it isn't already in Ubuntu (if it isn't) and subscribe ubuntu-universe-sponsors to it
[21:13] <DRebellion> RainCT: ok, thanks
[21:15] <RainCT> squentin: advocated :)
[21:16] <asbin> can someone please review my package http://revu.tauware.de/details.py?package=ushare ? needs 1 more advocating :)
[21:16] <squentin> RainCT: great, thanks :), anyone else wants to examine it : http://revu.tauware.de/details.py?package=gmusicbrowser ?
[21:18] <squentin> btw, I'm surprised we don't get mail when someone comments on our package. Any reason why it is so ?
[21:18] <superm1> RainCT, might be better telling in the future of the requestsync tool alternatively?
[21:19] <superm1> that way to make sure they get *everything* necessary in the bug
[21:19] <RainCT> squentin: because not everybody would like that
[21:20] <ScottK2> squentin: There's a ML you can subscribe to where all the comments go
[21:20] <squentin> ok, I'll take a look
[21:22] <mok0> ScottK: bug 188746
[21:23] <ubotu> Launchpad bug 188746 in ubuntu "[needs-merge] courier_0.58.0.20080127-1" [Undecided,New] https://launchpad.net/bugs/188746
[21:23] <mok0> ScottK2: ^^^
[21:23]  * ScottK2 looks
[21:24] <ScottK2> mok0: It has a lot of .po file cruft in it that'll have to be removed.
[21:25] <mok0> ScottK2: There were diffs in a whole bunch of po files
[21:25] <doofy`> ScottK, .diff.gz just contains information about the changes correct? Im looking at it and it doesn't contain any source. The source is still kept in its original directory to be uploaded later or what?
[21:26] <mok0> doofy`: yes, source is extra
[21:27] <doofy`> so when/how does source get commited to ubuntu? and how to people review launchpad bug pathches if the actual source isnt uploaded?
[21:27] <doofy`> well to the universe that is
[21:27] <vemon> the motu's download the original sources according to debian/watch or another files in debian/
[21:27] <ScottK2> doofy`: We get the source from the archives and then look at your changes.
[21:27] <ScottK2> mok0: Yes, but if you look, you'll see that most of them aren't actual changes.
[21:27] <vemon> (my answer was for new upstream versions.. :D)
[21:28] <doofy`> hmm this is confusing... so if i needed to patch a bug where would i start?
[21:29] <mok0> ScottK2: They have changes in the "Report-Msgid-Bugs-To:" field
[21:29] <mok0> ScottK2: I must have misunderstood what to do
[21:30] <rexbron> doofy`: https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff
[21:30] <mok0> ScottK2: I just went through the list and resolved the conflicts
[21:30] <vemon> doofy`, get the source, build it w/ dpkg-buildpackage (now you have build-tree dir), make your changes to the build tree, check that it builds, make clean, create diff and add it as a patch to debian/patches, modify changelog and build the new source package
[21:31] <ScottK2> mok0: Is that's all that's left?
[21:31] <rexbron> doofy`: once you have a debdiff (note that any patches should be using the patchsys of the package if there is one), attach it to the LP bug report and subscribe ubuntu-universe-sponsers
[21:31] <mok0> ScottK2: yeah
[21:31] <mok0> I can see the debdiff contains a bunch of stuff; I don't know why
[21:31] <vemon> doofy, that's how i do it. there really isn't one and only way to do it :)
[21:32] <mok0> ScottK2: Ah, the debdiff is wrong
[21:32] <doofy`> vemon, what do you mean add it as a path to debian/patches
[21:33] <vemon> doofy`, if you intend to make changes to the original package then you should create a patch with the diff tool and put it to debian/patches
[21:33] <dcordero> hi
[21:33] <ScottK2> mok0: Courier really messes with the tools.  Get your debdiff to where you understand the why of what's in there.  The "Report-Msgid-Bugs-To:" stuff isn't needed.  That'll get regenerated by LP.
[21:34] <vemon> i mean to the original distribution, changes that are made under the debian/ inside the source package are not made into patches in debian/patches dir :D
[21:34] <mok0> ScottK2: I see
[21:34] <mok0> ScottK2: I have to start over, then
[21:35] <vemon> doofy, i'm probably too tired to make any sense at the moment :) you should read the packaging guide. it's not as clear as it could be but pretty much covers fixing bugs
[21:35] <ScottK2> mok0: You aren't the first one I've given courier to as a torture test (ask nixternal).
[21:35] <mok0> ScottK2: Evil :-)
[21:35] <nixternal> hehe
[21:35] <mok0> ScottK2: The file ja.po has som real changes
[21:36] <doofy`> vemon, most packages would be uploaded to bzr?
[21:36] <mok0> so, nixternal what's the trick?
[21:37] <vemon> doofy, well.. if i've patched a package i've just attached it to the launchpad bug which i've fixed
[21:37] <vemon> never tried bzr
[21:37] <vemon> maybe someone could enlighten when to use bzr?
[21:37] <rexbron> bzr is more useful for when you are the maintainer of a package
[21:38] <rexbron> and team maintenence of a package
[21:38] <ScottK2> mok0: There are a couple of those, IIRC.
[21:39]  * rexbron is sad that neither his message to -motu or -devel-discuss re: rpath have had any responces
[21:39] <ScottK2> bzr would probably be fine if it weren't yet another VCS that I have to learn just for Ubuntu.
[21:40]  * mok0 knows nothing about the po system :-(
[21:40]  * mok0 doesn't understand how all these diffs come about
[21:40] <vemon> use trial & error. it's pretty effective :D
[21:41] <ScottK2> mok0: Go through and delete the ones that aren't meaningful and that's all you need to do with .po's really.
[21:41] <mok0> ScottK2: you mean edit the debdiff?
[21:43] <ScottK2> mok0: Yes
[21:44] <ScottK2> As long as you remove entire chunks of diff it's safe.
[21:44] <ScottK2> That or edit just within a single line.
[21:44] <mok0> ScottK2: I just don't understand why these chunks appear
[21:44] <mok0> ScottK2: because I did not introduce any changes there
[21:45] <ScottK2> I wish I had a good answer.  My guess is tool chain differences.
[21:45] <mok0> ScottK2: the .po files are the "source" files, right?
[21:46] <ScottK2> I think so.  I've got to run out, so maybe someone else can answer.
[21:46] <mok0> ScottK2: ok see you later
[22:06] <asbin> is there any MOTU here ?
[22:09] <RainCT> !ask > asbin
[22:10] <asbin> OK :)
[22:11] <asbin> I'm quite new here :p sorry
[22:11] <cyberix> !ask > cyberix
[22:12] <RAOF> That's OK.  Everyone's new once.
[22:12] <asbin> When is the "Last REVU Day" ? this sunday ? more days ? ...
[22:12] <RAOF> Today!
[22:12] <RAOF> Right now.
[22:12] <asbin> but today in US, Europe, Japan ?
[22:13] <asbin> :p
[22:13] <RAOF> Yes.
[22:13] <RAOF> If it's Monday, your time, it's revu day.
[22:13] <asbin> because in Japan it's monday already ...
[22:14] <MetalMusicAddict> ScottK: Thanx for the Scribus fix.
[22:14] <asbin> and when it will end ?
[22:14] <cyberix> I hope my package is ok already as I've fixed all the issues I've been told about. How ever, if there is something wrong I'd like to start working on it as soon as possible. Could someone take a look? I'm eager to get it into Hardy as I told the upstream developers I was going to.
[22:14] <RAOF> When it is no longer Monday anywhere.
[22:15] <asbin> RAOF: I see ...
[22:15] <cyberix> I'm not sure how many Ubuntu-motus live in Pago Pago. :-D
[22:17] <cyberix> http://revu.tauware.de/details.py?package=malbolge
[22:20] <cyberix> Malbolge may sound a complicated topic. How ever the software and the package should be fairly simple.
[22:20] <asbin> can someone please review my package http://revu.tauware.de/details.py?package=ushare ? it already has 1 advocating :)
[22:25] <slangasek> ScottK2: QA upload> sure
[22:27] <RainCT> asbin: I'll look at it tomorrow if it hasn't yet a 2nd advocate
[22:27]  * RainCT is off now, good night
[22:27] <asbin> RainCT: thank you !!
[22:31] <nixternal> 4 hours for opensg is almost complete..I am finally seeing dh_installs
[22:31] <Lutin> DktrKranz: is it you who added the DaD comment on pd-zexy ?
[22:32] <crimsun> nixternal: better hope you don't have --fail-missing
[22:32] <nixternal> all I am doing is double checking the build
[22:32] <DktrKranz> Lutin, probable
[22:34] <Lutin> DktrKranz: why not asking for a sync instead ?
[22:35] <DktrKranz> Lutin, basically because it contains the identical fix we have in 2.1-1ubuntu1
[22:36] <Lutin> DktrKranz: indeed. and as this is the only ubuntu change, I don't really see the point
[22:37] <DktrKranz> I didn't want to add burden to ubuntu-archive when there is really no need to do
[22:43] <nixternal> DaveMorris: you still around?
[22:44]  * RainCT decided that he will have a look at asbin's package today, now that he finished his homework :P
[22:44]  * asbin is happy
[22:45] <nixternal> DaveMorris: just so you know, I didn't find any build, install, uninstall, reinstall issues with your package and you have fixed everything persia asked of you...so I will go ahead and upload since superm1 also gave his advocation
[22:46] <blueyed> Is it ok to ask for revu with an incomplete debian/copyright file? I have the luck to have it all messy with those (lots of different copyrights, incompatible licenses). But I think to get this finished/cleaned up in the next days.
[22:47] <blueyed> I'm packaging jedit and there are so many different copyright, e.g. for different macros included..
[23:00] <RainCT> blueyed: shouldn't be a problem, just leave a comment telling that the copyright file isn't complete and that you are working on it
[23:02] <blueyed> Fine, so I'll upload it in an hour or so.
[23:02] <blueyed> btw: if there are files e.g. (c)2003 by foo and other (c)2005 by foo, do you have to list them separately, or is the year not so important then?
[23:05] <blueyed> i.e. can you group files (c)2001, (c)2003 and (c)2000-2005 with (c)2000-2005?
[23:07] <rexbron> blueyed: Are they from the same author and work?
[23:07] <blueyed> yes
[23:07] <rexbron> Then that should be ok
[23:08] <blueyed> phew.. at least something..
[23:08] <RainCT> asbin: the source looks great but I can't build it.. :(
[23:09] <RainCT> ah
[23:10] <RainCT> is it possible to install arbitrary .deb's with «pbuilder login»?
[23:11] <RainCT> or rather.. how can I get a .deb into the pbuilder environment?
[23:12] <blueyed> RainCT: yes, but you should save-after-login. You can also use a local archive (that's what I'm doing). Documented somewhere on the wiki
[23:13] <RainCT> blueyed: do you know how I can get the .deb into the pbuilder environment?
[23:14] <blueyed> RainCT: upload it to the local archive and then use that in pbuilder's sources.list.. or login with save-after-login and install it.
[23:15] <asabil> hi all
[23:15] <asabil> reviews ?
[23:15] <asabil> http://revu.tauware.de/details.py?package=libgee
[23:16] <RainCT> blueyed: ah ok, thanks
[23:27] <emgent> heya
[23:37] <slangasek> does anyone have any insight into why the changelog entry for openldap2.3 2.4.7-4 (e.g., /usr/share/doc/libldap-2.4-2/changelog.Debian.gz) didn't close bug #185257 in LP?
[23:37] <ubotu> Launchpad bug 185257 in openldap2.3 "E: slapd: subprocess post-installation script returned error exit status 1 - "checkpoint" must occur after "suffix"" [Unknown,Fix released] https://launchpad.net/bugs/185257
[23:38] <slangasek> heh, ^^ ubotu is showing the state of the linked Debian bug, interesting
[23:42] <persia> slangasek: The syntax looks right, but sometimes gets confused.  Did the .changes file have a Launchpad-Bugs-Closed: header?
[23:43] <geser> slangasek: I guess it because LP acts on the Launchpad-Bugs-Fixed (or whatever the field is named) in the .changes file and the mail to hardy-changes doesn't show that the field was set
[23:43] <geser> https://lists.ubuntu.com/archives/hardy-changes/2008-January/005469.html doesn't show it
[23:44] <persia> slangasek: Did you by any chance generate the .changes file on a Debian system?
[23:44] <RainCT> asbin: nice :)
[23:45] <slangasek> persia: it was a synced package; the synced .changes would have been generated on drescher...
[23:45] <geser> persia: doesn't the sync script generate a fake .changes file?
[23:45] <slangasek> so I guess that's a bug in sync-source
[23:45] <persia> slangasek: In that case, I'd suspect the sync script doesn't parse for LP: #nnnnnn and add the right header.
[23:45] <persia> geser: Yes, which would be the issue.
[23:45] <RainCT> if I upload a package which build-depends on another packages which was uploaded some hours ago, the build servers will wait for the dependency to be build, right?
[23:46] <slangasek> persia: yeah, looking at the source of sync-source, I can confirm this is the bug, thanks
[23:46] <geser> RainCT: they should
[23:47] <RainCT> asbin: uploaded :)
[23:48] <RainCT> geser: ok, thx
[23:48] <RainCT> good night
[23:51] <DaveMorris> nixternal: thanks
[23:59]  * StevenK finally gets home, after travelling for ~ 30 hours
[23:59] <Fujitsu> Hi StevenK
[23:59]  * StevenK waves