[12:15] <tsmithe> ok i've got to go to bed, exams and all
[12:15] <tsmithe> if B-D is fine, then there's that upload 
[12:15] <tsmithe> if not, then there's
[12:15] <tsmithe> http://revu.tauware.de/details.py?upid=5562
[12:15] <tsmithe> thanks :)
[12:19] <geser> crimsun: should all build-deps after cdbs be moved to b-d-i?
[12:20] <geser> does it really matter for an arch-all only package? as it got only build once
[12:21] <crimsun> (looking)
[12:22] <DarkSun88> G'night.
[12:26] <crimsun> geser: python definitely needs to be moved.  It should be safe to move them all as you suggest.
[12:29] <geser> ok will move them and upload
[12:31] <ryanakca> would it be worth making a motu-mud team, since there's a pile of unpackaged MUD servers and clients out there? or would it all fall to another team?
[12:33] <crimsun> ryanakca: a subteam of motugames, mayhap?
[12:33] <crimsun> ryanakca: would probably make sense to see to it in Debian first
[12:35] <ryanakca> crimsun: maybe. hmm... yeah
[12:40] <crimsun> what persia typed.
[12:41] <ryanakca> persia: ok
[12:44] <persia> ryanakca: http://wiki.debian.org/Games/Development may be of interest.
[12:49] <persia> Those performing merges: please check the +bugs page for the package, and include a section detailing bugfixes from upstream or Debian in the changelog with (LP: #bugnumber) tags to close any bugs addressed by the new Debian revision.
[12:51] <ryanakca> hmm... what do I do if there's already a package in the repos with the same name as the one I want to package? ex: mcl , http://micans.org/mcl/
[12:51] <ryanakca> (in repo), and http://www.andreasen.org/mcl/ , that I want to package
[12:52] <persia> ryanakca: Pick a new name (mcl-mud maybe?).
[12:52] <ryanakca> persia: ok
[12:54] <ryanakca> persia: hmmm... I don't know if it's worth packaging... abandoned, uses python 2.2... gcc-3.3, etc
[12:55] <persia> ryanakca: Unless you use it, and especially like it, it's probably better to skip then: lots of work to keep it in the archives, and likely lots of bugs that must be fixed in packaging.
[12:55] <ryanakca> persia: ok
[12:59] <persia> More generally, it's not best practice to package everything out there: only the "best-of-class" apps for each category, or programs you find beneficial for your preferred activities.
[01:01] <geser> we have currently over 600 packages that aren't in Debian
[01:01] <geser> if no MOTU looks after them, they don't get updated
[01:03] <persia> I wonder if we shouldn't add the filing of an RFP as a requirement for package inclusion, except where the package would only be interesting to Ubuntu.
[01:05] <geser> does somebody know if http://tiber.tauware.de/~lucas/versions/ tracks gutsy or still feisty?
[01:08] <persia> geser: It looks like feisty to me - I don't see the merges being reported as having happened.
[01:20] <bluekuja> persia, geser can you look at https://bugs.launchpad.net/ubuntu/+source/telepathy-mission-control/+bug/120633?
[01:20] <ubotu> Launchpad bug 120633 in telepathy-mission-control "Sync telepathy-mission-control 4.24-1 from debian unstable" [Undecided,Confirmed]  
[01:20] <bluekuja> persia, geser seems that unstable guy made an error on the changelog
[01:20] <bluekuja> written from daniel
[01:21] <bluekuja> I've debdiffed it
[01:21] <bluekuja> and there's no changes
[01:21] <bluekuja> any idea on how can we process it?
[01:22] <persia> bluekuja: 1) It's best to ask the channel generally, rather than specific individuals.  2) That's the result of a Debian sync from Ubuntu.  Nice when it happens.  It's probably safe to sync back, but you might want to check with Daniel.
[01:22] <geser> if he took the ubuntu package and uploaded it to debian unstable, it's ok to credit dholback in the changelog
[01:23] <bluekuja> persia, ok thanks
[01:23] <bluekuja> persia, gonna ping daniel for it
[01:23] <bluekuja> to be sure that we want a sync
[01:23] <bluekuja> thanks guys, gonna sleep
[01:23] <bluekuja> cu tomorrow
[01:25] <geser> cu
[04:08] <TheMuso> Heya folks.
[04:18] <joejaxx> hello TheMuso :)
[04:21] <TheMuso> Hey joejaxx.
[05:02] <StevenK> Maintainer: Ubuntu MOTU developers <ubuntu-motu@lists.ubuntu.com>
[05:02] <StevenK> XSBC-Original-Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
[05:02] <StevenK> Original-Maintainer: Martin v. Lwis <martin@v.loewis.de>
[05:02] <Fujitsu> Um... Which package?
[05:03] <StevenK> python-xlib
[05:03] <StevenK> I'm 80% certain it can get sync'd, so the point is moot.
[05:05] <dmb> whats the best way to get a folder in /usr/lib to be in the library search path when creating a package?
[05:05] <dmb> /usr/lib/yourprogramname
[05:15] <zakame> good day MOTUs
[06:08] <brylie> hello, can anybody point me to an article related to creating a metapackage for the apt repository so that the devs of a project can change the name of the .deb and allow anyone with the old version installed to migrate to the new naming standard?
[06:08] <brylie> specifically, the current naming standard is 'python2.x-exe_x.xx.x.deb' and the new name would [hopefully]  be 'exe_x.xx.x.deb'
[06:14] <crimsun> you don't need a metapackage to accomplish that
[06:15] <crimsun> simply amend debian/control's current python2.x-exe entry to Depends: exe
[06:17] <crimsun> it would also be a good idea to amend python2.x-exe's one-line [short]  Description to mention [transitional package] 
[06:18] <brylie> ok cool
[06:19] <brylie> I'll forward that info to the devs
[06:20] <brylie> the package hasn't actually made it to the universe repository yet and I want to encourage them to rename the .deb 
[06:20] <brylie> so when/if a MOTU submits it it will be more relevant
[06:25] <crimsun> interesting transition.  Why exe and not python-exe?
[07:12] <_MMA_> Hobbsee: You might be interested in this: http://ubuntuforums.org/showthread.php?t=475227
[07:12] <Hobbsee> _MMA_: neat.
[07:12] <Hobbsee> _MMA_: riddell pointed that out yesterday iirc.  looks cool.
[07:13] <_MMA_> Cool. :)
[08:05] <lucas> geser: the cron is disabled due to resources problems on tiber
[08:22] <bonii> j #ubuntu-motu-classroom
[09:14] <Fujitsu> Hmmmmmm. Why has Xorg eaten 230MiB of RAM?
[09:15] <Flannel> Fujitsu: it's hungry
[09:15] <Fujitsu> Obviously. Even Epiphany has eaten less, and I've got at least a hundred tabs open.
[09:17] <lathiat> has it been running for a month? :)
[09:17] <lathiat> epiphany is probably using all that ram for X server resources it leaked ;)
[09:18] <Fujitsu> Hahah. No, it was rebooted a couple of days ago after I left it running on the kitchen table, unplugged.
[09:18] <Hobbsee> hiya lathiat, Fujitsu, Flannel 
[09:18] <Fujitsu> Hi Hobbsee.
[09:18] <Flannel> Howdy Hobbsee 
[09:24] <tsmithe> geser, are you michael vorlon.ping.de? if so, thanks for the upload and the B-D-I stuff :) why are debhelper and cdbs still kept as Build-Depends?
[09:24] <tsmithe> well, that question could be for anyone
[10:39] <tobiasschulz> all MOTUs: can you check and maybe advocate http://revu.tauware.de/details.py?upid=5552 ?
[10:54] <geser> tsmithe: yes, that's me. debhelper is still in B-D as everything (like dh_clean) which isn't only used in the binary-arch-indep target in debian/rules must be in B-D
[10:54] <geser> the same for cdbs
[11:01] <geser> lucas: ups, didn't notice that the files are outdated (as yesterday was also a 15th). I found this service useful.
[11:04] <tobiasschulz> MOTUs: can you check and maybe advocate http://revu.tauware.de/details.py?upid=5552 ?
[11:06] <pochu> tobiasschulz: any reason you're packaging it as a native package?
[11:09] <tobiasschulz> pochu: ??
[11:09] <tobiasschulz> "native package"?
[11:10] <pochu> tobiasschulz: why the upstream tarball has the "0ubuntu7"?
[11:10] <pochu> And why it hasn't "-0ubuntuX" (the 0 is the Debian revision)
[11:10] <tobiasschulz> it has
[11:10] <tobiasschulz> ...0ubuntu7
[11:11] <tobiasschulz> 0ubuntu8
[11:11] <pochu> Sorry, why it hasn't a slash (-)
[11:11] <pochu> -0ubuntuX
[11:12] <tobiasschulz> why a shlash?
[11:12] <Fujitsu> pochu: That's a minus, hyphen, or dash.
[11:12] <Fujitsu> slash == /
[11:13] <tobiasschulz> why msut there be a - in the version number bofore 0ubuntuX?
[11:13] <tobiasschulz> #
[11:14] <pochu> tobiasschulz: yes, dash :)
[11:14] <pochu> tobiasschulz: It's the policy
[11:14] <Fujitsu> tobiasschulz: Because that's how the Debian versioning scheme works, unless it's a native package (ie. is specifically for Debian; there's no upstream releases as such)
[11:14] <tobiasschulz> there is an upstream release ^^
[11:15] <pochu> tobiasschulz: also, please rename the upstream tarball so it's jeliza_<upstream-release-number>.orig.tar.gz, but skip the ubuntu revision number.
[11:18] <pochu> tobiasschulz: also, since it's the first release, use -0ubuntu1, rather than 7
[11:21] <tobiasschulz> but i've iploaded it 8 times to http://revu.tauware.de/details.py?upid=5552 while i corrected bugs in the package
[11:21] <pochu> It doesn't matter, as long as you don't upload to the archive :)
[11:24] <Kmos> tobiasschulz: you'll learn more with time :)
[11:24] <pochu> As I do :)
[11:41] <Kmos> pochu: liferea v1.2.17 is out, you want to update ?
[11:42] <Kmos> current: https://launchpad.net/ubuntu/+source/liferea/1.2.16b-0ubuntu1
[11:43] <pochu> Kmos: already updated :)
[11:43] <pochu> I'm waiting slomo to sponsor me ;)
[11:43] <Kmos> ha :) ok.. nice work
[12:01] <man-di> Can some someone please look at http://revu.tauware.de/details.py?upid=5564 ? This fixes the runtime dependencies so that you can use every java runtime with it
[12:32] <afflux> the source package swfdec0.4 had a ftbfs due to a dependency problem on 2007-05-03, which seems fixed now (at least it works in my pbuilder). Can someone restart the build-process (or tell me who I have to contact for that)?
[12:34] <pochu> afflux: ask in #ubuntu-devel, any archive admin will reprocess it.
[12:35] <afflux> okay, thank you
[12:36] <crimsun> cd
[12:38] <StevenK> persia: Okay, a few issues with sbuild.
[12:39] <StevenK> persia: Number one, I miss my pdebuild, since it seems I have to make a source package before I can let sbuild loose on it. Secondly, my amd64 sbuild won't build arch all packages.
[12:40] <persia> StevenK: `sbuild -A -d gutsy foo.dsc`, and it's handy to generate the right source first, as that way one can just dput source.changes if everything worked well.
[12:41] <StevenK> persia: But pdebuild does it for me!
[12:42] <persia> StevenK: pdebuild builds a source package, then builds the binary from the source in the manner of the buildds, then gives you all the logs and a dput'able source to upload?
[12:43] <StevenK> persia: It will do everything but log by default. Logging can be turned on.
[12:44] <persia> StevenK: You could always write sdebuild, which would build the source, and call sbuild :)
[12:44] <man-di> persia: time to look at http://revu.tauware.de/details.py?upid=5564 ?
[12:45] <persia> Let's see: first decide if it's -S or -S -sa, then build the source, then sbuild.  Hmm.  I'd use such a script, if it existed.
[12:45] <persia> man-di: Sure.
[12:45] <StevenK> persia: Personally, if I want logs from pdebuild, I pipe it to tee
[12:46] <persia> StevenK: I think this is a care of preference for different automation :)
[12:47] <persia> man-di: You don't need REVU for this.  Just attach the debdiff to 81876, and subscribe U-U-S (and I'm archiving the REVU, as it's hard to distinguish the latest changes from previous changes).
[12:49] <man-di> persia: ok, thx
[12:49] <StevenK> persia: Seems to be. :-)
[12:50] <StevenK> sbuild seems a little fragile, too.
[12:50] <StevenK> persia: Oh, a complete lack of usage information for sbuild is incredibly irritating.
[12:50] <persia> StevenK: That's one of the reasons I prefer it.  I want it to break locally before it breaks on the buildds.
[12:51] <StevenK> persia: I was actually refering to the lvm-snapshot bit, which the buildds don't use. I've seen that go boom twice
[12:51] <persia> StevenK: Yep.  The documentation needs work.  I wanted to have a working sbuild for years, but didn't actually get one working until the instructions were put on the wiki.
[12:52] <persia> StevenK: Are you using the latest schroot, with all the patches?  I'm still holding on to sbuild 0.53, but the latest schroot seemed to fix a lot of the LVM-snapshot issues I was having before.
[12:53] <persia> (Alternately, Kees posted some patches for feisty schroot, if you prefer that)
[12:54] <StevenK> I'm using the schroot in Feisty
[12:55] <persia> StevenK: You need the patches from debian bug 391319 then :)
[12:55] <ubotu> Debian bug 391319 in schroot "schroot: leftover processes cause umount to fail" [Normal,Fixed]  http://bugs.debian.org/391319
[12:55] <persia> (otherwise, yes, it's terribly broken)
[01:00] <man-di> persia: is https://bugs.launchpad.net/ubuntu/+source/libcommons-dbcp-java/+bug/81876 okay this way?
[01:00] <ubotu> Launchpad bug 81876 in libcommons-dbcp-java "Dependency on java2-runtime removed" [Undecided,Confirmed]  
[01:01] <persia> man-di: In terms of bug processing that's perfect.  I'll look at the debdiff now (also if you just say "bug nnnnnn", the bot will spew the URL).
[01:02] <man-di> the url was still in m paste buffer so it was easier ;-)
[01:03] <StevenK> Naughty TheMuso!
[01:03] <man-di> persia: thanks for taking a look
[01:03] <StevenK> (His the GPG key id the Debian upload processor complained about)
[01:03] <coNP> Anyone can help me why I cannot sign a package?
[01:03] <coNP> Or better provide a detalied howto?
[01:04] <bluekuja> StevenK, he tried to upload my package :P
[01:04] <bluekuja> StevenK, but he missed archive
[01:04] <bluekuja> ^^
[01:04] <StevenK> He was aiming for Ubuntu?
[01:04] <bluekuja> yea
[01:04] <StevenK> Heh
[01:04] <bluekuja> that's a merge I did
[01:05] <bluekuja> and he was following
[01:05] <bluekuja> ;)
[01:05] <geser> coNP: what's the problem?
[01:05] <coNP> gpg: problem with the agent - disabling agent use
[01:05] <coNP> debsign: gpg error occurred!  Aborting....
[01:05] <coNP> debuild: fatal error at line 1166:
[01:05] <coNP> running debsign failed
[01:06] <persia> coNP: put "DEBUILD_PRESERVE_ENVVARS=DISPLAY" in ~/.devscripts, or disable your gpg-agent.
[01:07] <coNP> persia: many thanks, seems to work now
[01:11] <persia> man-di: Um..  Why do we want to revert that change?  It looks like Mathias intentionally applied it for dapper, and I don't have enough context to know either 1) why it was applied, or 2) why it can be dropped now.
[01:13] <man-di> persia: the fix makes it possible to not install gcj/kaffe when e.g. using eclipse with SUN JDK
[01:13] <man-di> this fix was never correct
[01:17] <geser> persia: see also bug #119560 which was acked by you
[01:17] <ubotu> Launchpad bug 119560 in libcommons-dbcp-java "Please sync libcommons-dbcp-java 1.2.1-5 from Debian unstable" [Wishlist,Fix released]  https://launchpad.net/bugs/119560
[01:17] <geser> and then a merge reintroduced the changes
[01:19] <persia> geser: That's part of why I asked.  I personally think the sync was best, don't understand why the merge was processed, and don't want to be involved in an upload war.
[01:20] <geser> as bluekuja is here, we can ask him why it was merged
[01:21] <bluekuja> geser: didnt see the bug on lp
[01:21] <bluekuja> so I processed it like every merge
[01:21] <bluekuja> I already talked about it with man-di 
[01:22] <man-di> ???
[01:22] <bluekuja> man-di, are you talking about libcommons-java ?
[01:23] <bluekuja> you pinged me that day?
[01:23] <persia> bluekuja: Please check more carefully for package bugs and package versions in the future.  Also, based on your comment, I'll upload the reversion for ibcommons-dbcp-java
[01:23] <bluekuja> persia, yeah sorry, really didnt see it on lp
[01:23] <bluekuja> so I cannot do anything
[01:23] <bluekuja> ;)
[01:23] <man-di> bluekuja: libcommons-dbcp-java
[01:23] <bluekuja> man-di, yeah
[01:49] <coNP> Can you please sync revu keyring (I joined u-u-c team in lp recently)?
[01:50] <Hobbsee> coNP: sure, i'tll be ~10 mins, iirc
[01:52] <coNP> Thanks, I guess I can figure it when it is done, since I can start uploading packages then. Am I right?
[01:53] <Hobbsee> coNP: i'll tell you
[01:53] <coNP> oh, thanks :)
[01:53] <Hobbsee> coNP: seeing as i can see the output here :)
[01:53] <coNP> wow :)
[02:00] <Hobbsee> coNP: it's done
[02:00] <Hobbsee> wow, exactly 10 :P
[02:00] <coNP> thanks, Hobbsee 
[02:01] <Hobbsee> no problem
[02:01] <coNP> It is a pity I am not done yet. Can someone hint if it is a pbuilder setup error or a dependency error in my package: http://pastebin.ca/569742
[02:02] <Hobbsee> coNP: means you dont have libpango1.0-dev as a build-dep
[02:03] <Hobbsee> (apt-cache search pango, and pick a -dev package that looks likely, and try it)
[02:03] <coNP> Oh, thanks!
[02:04] <Hobbsee> no problem
[02:05] <Q-FUNK> stange that something would depend on pango alone without gtk2.
[02:06] <coNP> it is Openbox
[02:06] <coNP> no gtk.* for sure
[02:06] <DarkMageZ> if openbox doesn't use gtk then what toolkit does it use?
[02:07] <coNP> I guess none
[02:08] <Q-FUNK> coNP: http://icculus.org/openbox/index.php/Help:Installing
[02:08] <coNP> thanks, Q-FUNK
[02:10] <Q-FUNK> coNP: no problemo.  it's generally a good idea to look at a project's homepage before building.  they usually include a fairly accurate description of the dependencies.
[02:11] <coNP> I wanted to update the package and first tried to build without adding anything. Actually I wasn't even sure if it is a pbuilder or a packaging error.
[02:11] <coNP> but now configure is done, make is invoked
[02:12] <Hobbsee> it's a packaging error
[02:12] <Hobbsee> as in, you need the extra build dep
[02:12] <coNP> Okay, thanks. I understand now.
[02:12] <coNP> It is even compiling now properly.
[02:13] <coNP> This dependency was the only one missing
[02:13] <Hobbsee> :)
[02:13] <Q-FUNK> groovy :)
[02:15] <afflux> geser: before you start working on the quodlibet-plugins bug: I just got a mail from gutsy-changes that Andrea Veri has already uploaded -1ubuntu2
[02:16] <SlimG> How do I make my .deb package respond correctly to a apttitude purge  ? I guess I have to add an additional script to remove config files..?
[02:16] <SlimG> s/apttitude/aptitude/
[02:16] <bluekuja> heya TheMuso 
[02:16] <man-di> SlimG: thats normally done all by dpkg automatically
[02:16] <bluekuja> afflux, what's the problem?
[02:16] <man-di> SlimG: when the files are known as conffiles
[02:17] <geser> afflux: I know, guess who sponsored the upload :)
[02:17] <Q-FUNK> SlimG: unless your package manually copies files during postinst, it should be removed by dpkg automatically.
[02:17] <man-di> SlimG: configurations files need to handled in *.postrm
[02:17] <Q-FUNK> sync :)
[02:17] <afflux> geser, bluekuja: oops. Maybe the launchpad mailinglist was a bit slow :)
[02:18] <Q-FUNK> coNP: brownie points?  what's the recipe?
[02:18] <coNP> Q-FUNK: :) https://wiki.ubuntu.com/MOTU/Recipes/PackageUpdate
[02:18] <bluekuja> afflux, np ;)
[02:19] <SlimG> man-di: I'm referring to those files stored in $HOME/.appname/  ,I guess these have to be removed with a .postrm file then
[02:19] <Q-FUNK> SlimG: files in someone's home directory should never be touched, as a ground rule.
[02:19] <SlimG> Q-FUNK: not even with purge?
[02:21] <SlimG> Q-FUNK: well, thanks for your ground rule
[02:21] <SlimG> man-di: thanks for your help!
[02:21] <Q-FUNK> SlimG: the user might end up installing a locally-compiled package or re-use configs with a similar package, so no.
[02:21] <Q-FUNK> lovely updating guide he wrote, dholbach.
[02:22] <Q-FUNK> here, I guess i'm just used to the wonders of uscan.
[02:38] <coNP> Oh I guess something went wrong. Can someone help me delete the wrong files from revu?
[02:38] <tobiasschulz> MOTUs: can someone look at this and maybe advocate please: http://revu.tauware.de/details.py?upid=5565
[02:38] <coNP> dput says dcut might help for  official Debian uploads which is not the case I guess
[02:46] <pochu> tobiasschulz: you need to create a file called "compat" in the debian/ dir, with a '5' in it (which is the debhelper compatibility)
[02:48] <Q-FUNK> tobiasschulz: echo 5 > debian/compat
[02:49] <Q-FUNK> sync :)
[02:49] <tobiasschulz> ok
[02:51] <coNP> pochu: can you help me how to delete an uploaded file from REVU? 
[02:51] <persia> coNP: Which files?
[02:51] <pochu> coNP: I'm not a REVU admin, but you can archive it, can't you?
[02:52] <coNP> persia: openbox_3.4*
[02:52] <pochu> tobiasschulz: also, you'd have to fix this: http://revu.tauware.de/revu1-incoming/jeliza-0706160705/linda
[02:52] <coNP> I uploaded the wrong files (i386 instead of the source)
[02:52] <coNP> and as I wanted to dput it again it said it were not possible
[02:52] <persia> coNP: Deleted.  Try again.
[02:53] <coNP> persia: thanks
[02:53] <persia> For general consumption: REVU does not support dcut (as far as I can tell).
[02:53] <coNP> Yep, I tried and failed. Therefore I asked if someone can please help :)
[02:54] <pochu> Hobbsee: are you a REVU admin?
[02:54] <Hobbsee> pochu: not admin - but i have access. why?
[02:54] <pochu> siretart and ajmitch are, but they don't seem to be around...
[02:54] <Hobbsee> what do you need?
[02:55] <Hobbsee> no, revu doesnt support dcut, neither does upload.ubuntu.com
[02:55] <xxxxx1> morning all!
[02:56] <coNP> How can I provide a file to a pbuilder that is not in Ubuntu yet? Actually I want to compile obconf that depends on openbox. I only have a self-built package from this version.
[02:57] <geser> is aurora.ubuntuwire.com offline?
[02:57] <persia> coNP: You can either 1) create a local repository, modify sources.list in the tarfile, pbuilder update, or 2) manually install the new software in the tarball.  #1 is much better.
[02:57] <tobiasschulz> pochu: how can i fix that: http://revu.tauware.de/revu1-incoming/jeliza-0706160705/linda
[02:58] <coNP> persia: sorry, which tarball you mean?
[02:58] <persia> geser: Dead for me (I can reach the router).
[02:58] <Hobbsee> ew.  i tend to prefer 2.
[02:58] <persia> coNP: the pbuilder tarfile.
[02:58] <Hobbsee> geser: has been for the last week, i think
[02:59] <persia> Hobbsee: After one is done with experimenting with #2, one needs to regenerate the tarball.
[02:59] <Hobbsee> dpkg-buildpackge -S -as
[02:59] <Hobbsee> coNP: personal package archives.  LP thing.  sor tof exists
[02:59] <persia> (not really yet - hasn't been announced)
[03:00] <geser> is the arch-all packages bug in PPA fixed already?
[03:00] <tobiasschulz> how can i fix that: http://revu.tauware.de/revu1-incoming/jeliza-0706160705/linda
[03:01] <tobiasschulz> ?
[03:01] <mok0> Who is the person in charge of the REVU programming?
[03:01] <Hobbsee> mok0: siretart 
[03:01] <Hobbsee> geser: no idea
[03:01] <mok0> Hobbsee: thx
[03:03] <siretart> mok0: yes?
[03:04] <mok0> siretart: Oh, I just thought it would be cool to have an XML feed of the revu comments etc.
[03:05] <mok0> siretart: There's a python module to do it
[03:08] <coNP> How could I check out PPA?
[03:08] <coNP> Is it possible?
[03:08] <mok0> siretart: I guess the correct term is RSS feed
[03:09] <mok0> siretart: just a suggestion
[03:10] <pochu> tobiasschulz: I'm not sure, but try changing "Its" with "It's"
[03:11] <mok0> siretart: gotta go, email me if you want to discuss further
[03:11] <bluekuja> pochu, same thing I said him to do
[03:11] <bluekuja> :)
[03:11] <bluekuja> that char is not allowed
[03:12] <pochu> bluekuja: hmm, I can't see where you told him that :)
[03:13] <bluekuja> pochu, he pmed me ;)
[03:13] <pochu> Ah, that explains it :)
[03:13] <bluekuja> :)
[03:13] <tobiasschulz> ^^
[03:16] <pochu> tobiasschulz: also, create jeliza.desktop inside debian/, instead of usr/share/applications. Then install it with dh_install
[03:19] <coNP> persia: how can I create an own repository? Or maybe add a source package to the pbuilder tgz?
[03:22] <persia> coNP: For real private repository management, I believe falcon is the current recommendation, but you can cheat by uploading to any FTP or HTTP (including 127.0.0.1), with a subdirectory for your private distribution, and a correctly formatted Packages.gz.  Someone else might be able to give more detailed advice.
[03:23] <persia> coNP: Also, dpkg-scanpackages might help (depending on what you do).
[03:29] <tobiasschulz> i've fixed the bug, it was the "" char!
[03:29] <tobiasschulz> http://revu.tauware.de/details.py?upid=5568
[03:34] <DarkSun88> Hi all
[03:35] <coNP> persia: What exactly should I insert to a "Source.gz" file (I guess from debian/control, etc.)
[03:35] <TheMuso> Ok. I have a very frustrating problem with a package. Attempting to upload a merged qjackctl package for someone, and no matter what I try, even using Ubuntu's .orig.tar.gz file, I still get an MD5sum error.
[03:35] <TheMuso> Sid's orig and gutsy's orig have different MD5sums, even though there is no difference in package contents.
[03:35] <Hobbsee> TheMuso: where does teh md5sum error come in?
[03:35] <TheMuso> Suggestions welcome.
[03:36] <TheMuso> Hobbsee: Soyuz says the MD5sum of a file, I assume its the orig, but it doesn't say, doesn't match.
[03:36] <TheMuso> I don't have an email to refer to, as I deleted it in frustration.
[03:37] <Hobbsee> right
[03:37] <man-di> persia: when will the bugfix for libcommons-dbcp-java be marked fix released? Will be it done automatically?
[03:38] <Hobbsee> TheMuso: can you dump the packages somewhere, or maybe uplaod it again, and get the rejected email?
[03:38] <Hobbsee> TheMuso: dunno how best to help, when i cant see the thig
[03:38] <TheMuso> Hobbsee: I have done the latter.
[03:38] <Hobbsee> *thing
[03:38] <Hobbsee> okay
[03:39] <persia> man-di: Um.  Let me check the .changes file.  It's supposed to be automated.
[03:39] <shawarma> TheMuso: The md5sums typically come from different timestamps in the gzip part.
[03:39] <shawarma> TheMuso: Um.. The *differing* md5sums typically.. etc.
[03:39] <persia> coNP: In the root of the target archive directory.
[03:40] <coNP> sorry I might not be clear I know the structure of a repository
[03:40] <coNP> I just don't know what to put in the Sources  file
[03:40] <shawarma> coNP: Are you publishing source files?
[03:41] <TheMuso> Rejected:
[03:41] <TheMuso> MD5 sum of uploaded file does not match existent file in archive
[03:41] <TheMuso> Files specified in DSC are broken or missing, skipping package unpack
[03:41] <TheMuso> verification.
[03:41] <man-di> coNP: dpkg-scansources ... | gzip > Sources.gz does everything for you
[03:41] <coNP> thanks man-di 
[03:42] <coNP> shawarma: no I try to build packages depending on other packages built by myself
[03:42] <persia> man-di: Not in this case.  The syntax is (LP: #bugnumber) rather than (LP: bugnumber).  Sorry for missing that.  Please mark "FIx Released" when you think appropriate (some say upload, some say build.  I generally follow build).
[03:42] <shawarma> coNP: Then you don't need a Sources.gz.
[03:42] <TheMuso> http://www.themuso.id.au/ubuntu/qjackctl
[03:42] <TheMuso> changes file and dsc file aren't signed, but thats basically it.
[03:42] <man-di> persia: sorry for my mistake
[03:43] <coNP> shawarma: then how do I tell my pbuilder to use the my brand new source package?
[03:43] <shawarma> coNP: You.. Um.. don't?
[03:43] <shawarma> coNP: You need you brand new *binary* packages?
[03:44] <coNP> Err I am wrong, they build-depend on my brand new source package.
[03:44] <tobiasschulz> (http://revu.tauware.de/details.py?upid=5568):
[03:44] <tobiasschulz> > 2) The package doesnt appear to do anything dur to the build: rule. Is the C++ code intended to compile? If not, why not? (README.Debian-source is a good place for the answer to this question). 
[03:44] <tobiasschulz> > 3) If the C++ is intended to be compiled, you may want to check the library packaging guidelines.
[03:44] <tobiasschulz> It's a QT application, so it is compiled using 
[03:44] <tobiasschulz> qmake jeliza.pro -o Makefile && make
[03:45] <Hobbsee> TheMuso: looking
[03:45] <shawarma> coNP: No. They build-depend on binary packages.
[03:45] <coNP> Yep. You are right.
[03:46] <persia> TheMuso: I have a qjackctl_0.2.22-2ubuntu1 already installed.  Doesn't one need an upstream version bump before making an upload that includes orig.tar.gz in source.changes?
[03:46] <TheMuso> Hobbsee: As I said, the md5 of the orig in sid is different to Ubuntu's, but I used the ubuntu one for the pkg.
[03:46] <Hobbsee> TheMuso: did you have a bug # that you were working from?  this is a sponsorship?
[03:46] <TheMuso> Hobbsee: Yes.
[03:47] <persia> TheMuso: Which bug?
[03:47] <TheMuso> hang on...
[03:47] <Hobbsee> i've found the problem
[03:47] <bluekuja> persia, I did it
[03:47] <bluekuja> e.g the debdiff
[03:47] <persia> bluekuja: No.  Your sponsor did it :)  You were helping.  Thanks again.
[03:48] <Hobbsee> TheMuso: use this widely.  lionel is your target.
[03:48] <TheMuso> Ok, twas me just not checking if it already existed, just like the original merger didn't.
[03:48] <bluekuja> persia, oh :D
[03:48] <Hobbsee> er, wisely
[03:48] <shawarma> Hobbsee: There's already a 0.2.22-2ubuntu1 in the archive?
[03:48] <shawarma> TheMuso: ^^
[03:48] <Hobbsee> shawarma: yep
[03:48] <TheMuso> shawarma: I know.
[03:48] <shawarma> Hobbsee: Not for you :)
[03:48] <persia> shawarma: yes
[03:48] <TheMuso> I didn't check, as I assumed...
[03:48] <shawarma> So.. Why upload it againg?
[03:48] <lionel> Hobse: What I did ?
[03:49] <lionel> rah
[03:49] <lionel> Hobbsee: What I did ?
[03:49] <TheMuso> bluekuja: DId you check before you filed the bug?
[03:49] <bluekuja> TheMuso, yes
[03:49] <bluekuja> who did it?
[03:49] <Hobbsee> lionel: wasnt what i thought.  i thought you'd sponsored without marking teh bug as such
[03:50] <Hobbsee> TheMuso: lionel's done the merge, without checking if anyone else had first, it looks like.  or bluekuja hasnt seen that lionel's already done the merge.
[03:50] <lionel> Which package?
[03:50] <TheMuso> lionel: qjackctl
[03:50] <persia> bluekuja: Where did you look (remembering libcommons-dbcp-java)?
[03:50] <lionel> Oh. I've done it yesterday yes
[03:50] <bluekuja> persia, I've pushed a bug on lp
[03:51] <bluekuja> for it
[03:51] <lionel> You're talking about the mail we received on ubuntu-motu ?
[03:51] <TheMuso> lionel: Please check if there is already a bug requesting a merge before you do it.
[03:51] <bluekuja> and someone did it
[03:51] <bluekuja> ..
[03:51] <TheMuso> lionel: No, that was an accident by me.
[03:51] <persia> bluekuja: Before doing the merge, did you search on LP for bugs on the package?
[03:51] <TheMuso> merge sponsorship even
[03:51] <TheMuso> persia: he said he did.
[03:52] <persia> bluekuja: My apologies.
[03:52] <bluekuja> persia, lionel did *NOT*
[03:52] <bluekuja> and made the merge
[03:52] <lionel> TheMuso: I think I checked before doing the merge. But I may be wrong
[03:52] <bluekuja> so it's not my fault
[03:52] <TheMuso> Its nobody's fault.
[03:52] <TheMuso> We just need to check before we start the merge, and then just before we upload.
[03:52] <Hobbsee> looks like they've filed on the same day.
[03:52] <TheMuso> persia: Thats what I have been doing.
[03:53] <bluekuja> yeah
[03:53] <lionel> It's a 5min merge, we are not going to spend 1h discussing a 5min merge:)
[03:53] <bluekuja> TheMuso, followed the policy correctly
[03:53] <bluekuja> lionel, yeah
[03:53] <bluekuja> dont worry for it then
[03:53] <TheMuso> Will close the bug.
[03:53] <Hobbsee> TheMuso: already done
[03:54] <TheMuso> Hobbsee: Thanks.
[03:54] <lionel> But I'm sorry If I did not notive something
[03:54] <Hobbsee> :)
[03:54] <Hobbsee> lionel: i'd guess it'
[03:54] <bluekuja> lifeless, np ;)
[03:54] <Hobbsee> s been filed at around the same time, so oh well
[03:54] <bluekuja> *lionel: np
[03:54] <bluekuja> ;)
[03:55] <bluekuja> lionel, qgis FTBFS in debian too
[03:56] <bluekuja> lionel, reported a bug to have it fixed
[03:56] <bluekuja> (all archsa affected)
[03:56] <lionel> I've seen your comment on the bug
[03:56] <bluekuja> *archs
[03:56] <bluekuja> gnight TheMuso 
[03:56] <TheMuso> Night folks.
[03:56] <bluekuja> lionel, we will wait till it get fixed in debian
[03:56] <bluekuja> for the merge
[04:05] <coNP> Someone up to review my brand new package (http://revu.tauware.de/details.py?upid=5566)?
[04:22] <xxxxx1> anyone here is running at amd64?
[04:23] <persia> xxxxx1: What do you need tested?
[04:24] <xxxxx1> i've got a "bug" of ecryptfs on ia64 and create a fix branch
[04:24] <xxxxx1> can you test?
[04:24] <xxxxx1> it's *64* related.
[04:25] <persia> xxxxx1: Do you have a testcase?  Is there a bugnumber?
[04:29] <bmm> zakame: are you online? I've uploaded the new ccbuild package with the changelog line added: http://revu.tauware.de/details.py?upid=5560
[04:30] <bmm> thanks!
[04:30] <zakame> np :)
[04:31] <coNP> If I uploaded some packages should I ask someone to review it (explicitly) or just wait?
[04:32] <Hobbsee> coNP: ask explicitely
[04:32] <Hobbsee> -e
[04:32] <zakame> bmm: hmm ccClass and ccFunction are still patched outside of dpatch
[04:33] <bmm> zakame: oh?? Oooh.. I've only replaced the ".sh" files when doing the dpatch... stupid of me.
[04:33] <coNP> Hobbsee: whom can I ask? Maybe you? http://revu.tauware.de/details.py?upid=556{6,9}
[04:33] <bmm> zakame: Thanks, I'll fix it now, if you find any other problems, please let me know.
[04:34] <zakame> bmm: do check the build as well
[04:35] <bmm> zakame: is that going wrong? I havn't had any problems yet with that... any hints on the problem?
[04:36] <persia> coNP: Best practice is to announce the URL here, with the name of the package, any special considerations (python, java, library, etc.) and whether it is initial review, updated review, or seeking a second advocate.  If there is no response, try again the next day (there is usually a response).
[04:38] <coNP> Okay. It is an Openbox update package, initial review. Two packges: one for Openbox (http://revu.tauware.de/details.py?upid=5566) and one for its configurator, Obconf (http://revu.tauware.de/details.py?upid=5569).
[04:38] <persia> zakame: What's wrong with the build?  It works for me.
[04:38] <bmm> persia: might be a 64bit thing??
[04:39] <zakame> persia: not that there's anything wrong, just that always do a rebuild at every change. :)
[04:40] <persia> zakame: Ah.  My confusion.  I concur.
[04:40] <bmm> zakame: few... thought I had a problem with some weird architecture or someting.... :-D
[04:40] <zakame> hehe... I've recently updated some of my debian packages, and while rebuilding's slow, its worth the time
[04:44] <bmm> How does one check for bashisms?? I'm just guessing at the moment (I know about some things like "{}" etc), but there must be a script or something
[04:44] <Hobbsee> dash -n script, iirc
[04:45] <bmm> thanks
[04:46] <leonel> hello motus
[04:46] <leonel> did this  was canceled ??  bug  115269 
[04:46] <ubotu> Launchpad bug 115269 in dapper-backports "[backport]  python-psycopg2 From Feisty to Dapper" [Undecided,Unconfirmed]  https://launchpad.net/bugs/115269
[04:46] <Hobbsee> leonel: ask jdong, we dont control backprots
[04:48] <leonel> Hobbsee: ok 
[05:00] <bmm> zakame: I've created a new dpatch and used checkbashisms to find any problems and updated the changelog. Currently I'm running a full rebuild . Did you find anything else?
[05:02] <bluekuja> Hobbsee, do you have a min for a main debdiff (patch)?
[05:17] <bmm> zakame: I've made a new upload with a complete rewrite of the dpatch using checkbashisms to check for problems, updated the changelog and of course a full rebuild to check it all  ;-)
[05:17] <bmm> Any MOTU: ccbuild is looking for it's first advocate of the newest revision http://revu.tauware.de/details.py?upid=5560
[05:22] <bluekuja> persia: :D
[05:23] <bluekuja> persia: nice hint :D
[05:24] <zakame> bmm: what is in test.xx?
[05:24] <bmm> oh ff
[05:24] <bmm> that's my bad. A test program for the checkbashisms, wasn't sure it worked :-S
[05:24] <bmm> bummer.. I'll remove that and repack it :-(
[05:27] <bmm> zakame: I'm ready to do a new upload, do you want that or are you expecting more problems soon?
[05:27] <zakame> cool, go on :)
[05:33] <bmm> zakame: it has arrived http://revu.tauware.de/details.py?upid=5572
[05:36] <zakame> bmm: advocated :)
[05:37] <bmm> Yeah!
[05:37] <zakame> bmm: the package synopsis could still be improved per http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-pkg-synopsis , but it's not urgent :)
[05:38] <bmm> zakame: I'll take a look at that then, thanks!
[05:43] <zakame> np :D
[06:00] <zakame> gn8 folks :D
[07:09] <porthose> good mourning all
[07:10] <ScottK> good morning (I hope you meant good morning and not good mourning)...
[07:11] <porthose> Could I please get a MOTU to review ampache-3.3.3.2.  http://revu.tauware.de/details.py?upid=5519
[07:13] <pochu> porthose: The orig.tar.gz shouldn't have the Ubuntu version (the -XubuntuY)
[07:13] <pochu> slomo!
[07:14] <slomo> hi pochu :)
[07:14] <pochu> :)
[07:14] <pochu> slomo: I've packaged liferea 1.2.17, which fixes some memory leaks, and other things. It's at http://emilio.pozuelo.org/~deb, if you can take a look at it...
[07:14] <porthose> k thanks
[07:15] <pochu> slomo: I've tested it, and works fine so far. I haven't changed anything in debian/ but the changelog :-)
[07:15] <slomo> pochu: merged with debian? :)
[07:15] <slomo> pochu: they got 1.2.16something
[07:15] <pochu> slomo: They have just dropped dbus-1-utils, which we've already done
[07:15] <slomo> pochu: and you merged the changelog entry :)
[07:15] <pochu> slomo: so I didn't think it did worth...
[07:16] <pochu> slomo: I didn't, but I can :)
[07:16] <pochu> Gimme a second!
[07:16] <slomo> please do so to keep the delta smaller and save you some work next time ;)
[07:16] <pochu> Right :)
[07:21] <pochu> slomo: uploaded :-)
[07:21] <slomo> pochu: perfect
[07:22] <pochu> Hmm, I haven't mentioned a "Merge with Debian". Is it neccesary?
[07:23] <slomo> yes
[07:27] <slomo> pochu: new version there?
[07:28] <pochu> slomo: Yeah :) http://emilio.pozuelo.org/~deb/
[07:28] <pochu> Just uploaded with the Merge message and that :)
[07:29] <slomo> pochu: ok, looking and it and then uploading .)
[07:31] <pochu> Thanks :)
[07:35] <slomo_> pochu: uploaded
[07:37] <pochu> slomo_: rock on :)
[07:51] <polopolo> hello all, does someoen know how I can import my GPG key from keyserver.ubuntu.com?
[07:52] <Nafallo> gpg --keyserver keyserver.ubuntu.com --recv-key <your key>
[07:52] <polopolo> thank you :D
[07:54] <polopolo> th server is off :(
[07:55] <Nafallo> that would surprise me
[07:56] <polopolo> http://keyserver.ubuntu.com/
[07:56] <polopolo> :(
[07:56] <Nafallo> you forgot the portnumber
[07:56] <polopolo> Can I ask what you mean with <your key>?
[07:56] <Nafallo> anyway, esperanza is up.
[07:56] <polopolo> wich is it then>
[07:56] <polopolo> ?
[07:57] <Nafallo> your fingerprint
[07:57] <Nafallo> in my case 509CBA71
[07:57] <polopolo> ah
[07:57] <polopolo> what is the portnumber then?
[07:58] <polopolo> I know the portnumber know
[07:58] <Nafallo> why not just use the commandline?
[07:58] <polopolo> I lost my key in the reinstall
[07:58] <Nafallo> then you've probably lost the private key too then?
[07:59] <polopolo> I lost the key yes, but uploaded the key to the server
[07:59] <Nafallo> the public key yes...
[07:59] <Nafallo> you should have had backup of your private key...
[07:59] <man-di> polopolo: then you are totally lost
[07:59] <polopolo> ouch fine :(
[07:59] <man-di> polopolo: private key is only on your system normally
[08:00] <polopolo> how can I make it then?
[08:00] <man-di> polopolo: create a new key?
[08:00] <Nafallo> no! it's on the system and in all the secure backupplaces :-)
[08:00] <polopolo> no, backup
[08:00] <man-di> polopolo: and backup the key 
[08:01] <man-di> polopolo: then you even cant revoke it when you have no revocation key
[08:02] <polopolo> BRB
[08:02] <polopolo> back in few min
[08:25] <polopolo> for the people who helped my with PGP, I have downloaded my key, and it works :P
[08:47] <tsmithe> geser, thanks :)
[08:55] <LaserJock> hello MOTU land
[08:55] <pochu> Hi LaserJock 
[08:55] <LaserJock> hola pochu 
[08:58] <ScottK> Hello LaserJock
[08:59] <LaserJock> hiya ScottK 
[09:00] <jburd> Are the GNU Autotools manuals available for devhelp?
[09:00] <tsmithe> hi LaserJock 
[09:01] <LaserJock> jburd: I don't remember them being in devhelp, but I could be wrong
[09:01] <LaserJock> heah tsmithe, get your packages into Debian yet?
[09:01] <jburd> I remember browsing them in devhelp long ago, but that was probably Gentoo, I think.
[09:02] <LaserJock> hmm
[09:02] <tsmithe> LaserJock unfortunately no; wired's upstream have been a bit slow in getting back to me. so i'm just gonna go ahead and hack about with it
[09:02] <tsmithe> LaserJock, wanna do some reviewing for me later? :p
[09:03] <LaserJock> hmm, I'm not sure I can
[09:03] <tsmithe> heh ok :)
[09:03] <LaserJock> I'm at my  grandfather's house and I don't know if I'll have access to my build machine at home
[09:03] <man-di> tsmithe: just mail me when you are ready with the package
[09:03] <LaserJock> I suppose I could try imbrandon's build farm
[09:03] <tsmithe> man-di, will do for wired; i meant about ubuntustudio's art packages :p
[09:04] <tsmithe> LaserJock, nah don't worry - unless you desperately want to
[09:04] <man-di> tsmithe: aah, I thought its only about wired
[09:04] <tsmithe> nope :)
[09:05] <jburd> There seem to be references to devhelp-book-autotools in warty.
[09:06] <LaserJock> perhaps Debian got rid of them for some reason
[09:07] <jburd> Hmmm.  It's really easier to search devhelp within gedit + documentation plugin you know.
[09:07] <jburd> Just place the cursor on whatever you want lookup and press F7.
[09:08] <jburd> I'd really like http://htmlhelp.berlios.de/wiki/Devhelp_Books  these available.
[09:08] <man-di> LaserJock, jburd: this was AFAIR becuase of GFDL
[09:08] <jburd> Oh
[09:08] <man-di> ...if I remember correctly...
[09:08] <jburd> Bah.  licensing.
[09:10] <LaserJock> man-di: that's what I was thinking
[09:10] <LaserJock> Debian lost a lot of documentation to GFDL "stuff"
[09:10] <man-di> LaserJock: most of it just got moved to non-free
[09:11] <LaserJock> yeah
[09:11] <LaserJock> it caused some issues with TeX
[09:11] <man-di> LaserJock: debian still allows GFDL for main, just not with invariant sections
[09:11] <man-di> LaserJock: and glibc and gcc and a lot more stuff
[09:11] <LaserJock> yeah, but it's pretty common to have an invariant section for the license of the doc
[09:12] <LaserJock> so it seems like there's a lot of stuff that got dumped into non-free
[09:12] <man-di> yes
[09:12] <man-di> how does ubuntu handle this today?
[09:12] <LaserJock> we accept GFDL as far as I know
[09:12] <man-di> LaserJock: always?
[09:12] <LaserJock> as far as I know, yes
[09:13] <LaserJock> we've got some of the non-free doc packages in I believe
[09:13] <man-di> interesting
[09:13] <LaserJock> we also have Creative Commons licenses too
[09:13] <LaserJock> for some things
[09:14] <LaserJock> which Debian doesn't accept
[09:14] <LaserJock> but I think it's a bit more of a case-by-case basis
[09:14] <jburd> I'd really *love* it if free software and open-source licenses cooperated with each other instead of figthing like street cocks.  In the end, nobody wins and everybody loses.
[09:14] <LaserJock> I've never seen a policy doc on it
[09:15] <LaserJock> jburd: well, people have to define free and open-source
[09:15] <LaserJock> and some people are bound to define it a bit differently
[09:16] <LaserJock> Debian tends to take the "strictest" approach to free
[09:17] <jburd> Honestly, I don't really care about definitions.  I hate the fact that I cannot use extremely well-written code in my application simply because of license incompatibilities or the other way around.
[09:18] <LaserJock> well, it certainly better than not being able to do anything, IMO
[09:18] <jburd> GPL does not allow me to use a lot of software written by Apache (which produces really well-engineered stuff).
[09:18] <jburd> Re-inventing the wheel is expensive and a waste of time.
[09:18] <xxxxx1> hello LaserJock 
[09:18] <LaserJock> but it's still the software authors right to define how they want their software used
[09:19] <LaserJock> but yes, licensing can be a real pain in the butt
[09:19] <LaserJock> and documentation licensing even more so
[09:19] <jburd> Having to think a thousand times before I can touch someone's "free software" and care about their definitions is a pain.
[09:19] <jburd> Agreed.
[09:20] <jburd> I'd just like to write some software while reusing some really good code and that's that.
[09:20] <LaserJock> sure, once GPL takes over the world it won't be a problem ;-)
[09:20] <jburd> Heh.
[09:20] <LaserJock> hence why it is sometimes called a viral license
[09:21] <luisbg> hey LaserJock =)
[09:21] <LaserJock> luisbg!
[09:23] <LaserJock> personally if I were to write a program I'd probably MIT it or make it non-free, I think
[09:25] <jburd> If everything were up to me, I'd leave everything in public domain.  Do whatever you want to with it.  No warranties.
[09:26] <Burgundavia> jburd: the problem with that is that people will do evil things with it
[09:26] <jburd> Don't they otherwise? :-)
[09:26] <Burgundavia> because what really matters is the community and people, not the code
[09:26] <ScottK> For me it depends on my purpose.  If I'm trying to evangelize a technology via a new program I'd go MIT.  If I'm trying to push Free Software, I'd go GPL.  If I didn't want to distribute source, I'd do it as a service and not distribute at all.
[09:26] <Burgundavia> and while the gpl does not create a community, it creates an incentive to do so
[09:27] <LaserJock> jburd: well, public domain doesn't really work so well. There are several countries where you can't make things public domain
[09:27] <LaserJock> well, the GPL sucks for libraries
[09:27] <Toadstool> jburd: use this http://sam.zoy.org/wtfpl/ instead :)
[09:27] <Toadstool> hi guys
[09:27] <LaserJock> hence the LGPL
[09:28] <LaserJock> I've come across several problems where a community was split because a library was GPL
[09:28] <mwolson> jburd: GPLv3 will be compatible with the Apache license
[09:28] <Toadstool> uh gotta go, tennis time, that was quick
[09:28] <jburd> Heh @ Toadstool
[09:31] <jburd> The GPL reminds me of this "We'll speak your native language as long as it is English."
[09:39] <jburd> Excellent stuff:  http://htmlhelp.dotsrc.org/
[09:40] <jburd> :-)
[09:44] <polopolo> is it a problem if a 32 bit computer package a  64 bit program?
[09:44] <pochu> I don't think it's possible
[09:45] <polopolo> ah o
[09:45] <polopolo> k
[09:45] <pochu> Though it is the other way, afaik :)
[09:56] <DarkSun88> Hi all
[09:56] <DarkSun88> :)
[09:56] <polopolo> hello
[09:57] <pochu> beuno: rock on with the stats :-)
[09:57] <beuno> pochu, thanks  :D   was my pet project, I'm glad I got *something* out there
[10:01] <pochu> It's cool!
[10:01] <pochu> beuno: btw, do you have ubuntu-es.org forums support?
[10:01] <beuno> pochu: nope, we haven't added it, would be great to have local forums added
[10:01] <pochu> Yeah :)
[10:01] <beuno> if would be great if you could file a bug so we can track requests
[10:01] <beuno> :D
[10:01] <pochu> Sure, doing :)
[10:01] <beuno> thanks, it's going to hard to keep track of all requests  :p
[10:01] <pochu> heh
[10:01] <beuno> debconf is really taking up most of my time though
[10:02] <beuno> happily so   :D
[10:04] <pochu> beuno: also, what's 'LoCos (other languages)' purpose?
[10:05] <beuno> pochu: should be other planets
[10:07] <pochu> Doesn't seem to be atm
[10:07] <beuno> no, it doesn't  :p
[10:10] <pochu> beuno: bug 120743
[10:10] <ubotu> Launchpad bug 120743 in ubuntu-stats "Please add support for the ubuntu-es forums" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120743
[10:12] <beuno> pochu: thanks
[10:14] <polopolo> Must you install the program before you package the program?
[10:15] <beuno> polopolo: it would be nice to, yes
[10:16] <polopolo> mmm
[10:18] <polopolo> ok, and I want to package swiftfox, I have a pentium 4, should I package the pentium 4 version, and upload it on the I386 section?
[10:18] <Burgundavia> polopolo: swiftfox has a completely non-free license
[10:19] <polopolo> so not approved for ubuntu?
[10:20] <beuno> polopolo: yes, it just goes into multiverse afaik
[10:20] <polopolo> afaik?
[10:20] <beuno> as far as I know  :D
[10:21] <polopolo> So no problem if I upload?
[10:21] <Burgundavia> umm, I don't think you can even distribute it
[10:21] <beuno> Burgundavia: but multiverse is all non.free software
[10:21] <polopolo> why?
[10:21] <Burgundavia> beuno: multiverse is only for stuff we can legally distribute
[10:22] <LaserJock> beuno: Multiverse is non-free that we can legally distribute
[10:22] <polopolo> lol
[10:22] <LaserJock> heh, Corey beat me to it
[10:22] <beuno> heh
[10:22] <polopolo> hmm ok
[10:22] <polopolo> Then I stop
[10:22] <beuno> you two really spend too much time together...  :p
[10:23] <Burgundavia> polopolo: lets check first
[10:23] <Burgundavia> http://www.answers.com/topic/swiftfox
[10:25] <polopolo> ah I see
[10:25] <polopolo> MPL 1.1
[10:26] <polopolo> Therefor the Swiftfox Debian package would not pass requirement #1 of Debian Free Software Guidelines
[10:26] <polopolo> I see
[10:27] <polopolo> I see not the problem :P
[10:29] <ScottK> It's not the MPL, it's the Trademark on the name.  You can probably call it something like Swift-weasel and package it.
[10:31] <polopolo> so, change the package name and not the proogram ??
[10:31] <polopolo> I think I package another program
[10:36] <polopolo> !bug 120699
[10:36] <polopolo> #bug 120699
[10:36] <ubotu> Launchpad bug 120699 in firefox "[needs packaging]  swiftfox" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120699
[10:36] <polopolo> not working :(
[10:36] <polopolo> https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/120699
[10:37] <polopolo> what must I do then with this bug?
[10:41] <pochu> probably reject it.
[10:52] <tsmithe> hmm revu doesn't want to diff between archived and new uploads, it seems
[10:52] <tsmithe> siretart, ping re ^^
[10:52] <tsmithe> i guess that's the cause
[10:52] <tsmithe> check http://revu.tauware.de/diff.py?upid1=4896&upid2=5582
[10:54] <xxxxx1> bye all
[11:03] <tsmithe> what does "E: ubuntustudio-sounds: copyright-should-refer-to-common-license-file-for-gpl" mean?
[11:04] <tsmithe> lhttp://revu.tauware.de/revu1-incoming/ubuntustudio-sounds-0704240025/ubuntustudio-sounds-0.4/debian/copyright is the file
[11:05] <ogra_> tsmithe, lintian -i :)
[11:06] <ScottK> tsmithe: It means that a copy of the GPL is installed in all Debian systems and you should refer to that instead of putting the whole text in debian/copyright.
[11:06] <tsmithe> ahh of course
[11:06] <tsmithe> thanks
[11:06] <crimsun> you're missing a reference to /usr/share/common-licenses/Artistic
[11:07] <crimsun> and /usr/share/common-licenses/GPL
[11:10] <tsmithe> thanks
[11:39] <Kmos> crimsun: http://revu.tauware.de/details.py?upid=5586
[11:40] <crimsun> Kmos: the Debian maintainer has been active recently; have you conversed with him regarding a newer version in Debian unstable?
[11:41] <Kmos> crimsun: I don't see debian package 
[11:41] <Kmos> or talked to him
[11:42] <Kmos> ubuntu can't have their own ? :) i've changed everything necessary
[11:42] <crimsun> I recommend sending him an email inquiring whether he plans to update soon
[11:42] <Kmos> the maintainer can also backport it to debian
[11:43] <crimsun> the problem is not that Ubuntu can{,'t} have its own version.  It's that we don't want orig.tar.gz skew.
[11:43] <Kmos> crimsun: why we need to wait for debian ?
[11:43] <Kmos> .orig.tar.gz is from website of phpmyadmin
[11:43] <crimsun> see above
[11:45] <Kmos> crimsun: i mailed him
[11:45] <crimsun> great
[11:45] <Kmos> so phpmyadmin can only be a debdiff from debian unstable ?
[11:46] <crimsun> no
[11:46] <Kmos> the diff applied correctly to this new version and tested with pbuilder
[11:47] <crimsun> unless you have a good reason to, I recommend you wait for new upstream versions to enter Debian first
[11:47] <crimsun> a good reason _not_ to,
[11:47] <Kmos> for example, i've updated ddclient to 3.7.1 and debian has an old version
[11:48] <crimsun> Kmos: yes, and how active has the Debian maintainer been for ddclient?
[11:48] <Kmos> 3.7.0
[11:48] <Kmos> I think he isn't..
[11:48] <crimsun> right.  Now compare that to the activity of phpmyadmin's maintainer.
[11:51] <Kmos> crimsun: it's different :)
[11:51] <Kmos> i understand now
[11:53] <Lamego> btw, phpmyadmin on feisty is broken
[11:54] <crimsun> we know.  See bug report referenced in -devel.
[11:54] <crimsun> Feel free to propose an SRU.
[11:57] <Lamego> it is far more easy to use a backported version, and I like to spend my time on a more efficient fashion
[11:57] <Lamego> I guess someone noted the problem before the release
[11:58] <Kmos> crimsun: http://revu.tauware.de/details.py?upid=5587
[11:59] <Kmos> crimsun: i needed to remove a patch from it
[11:59] <Lamego> is there any exception case for doing an SRU with a full version update ?
[12:00] <crimsun> SRUs should not be full version updates.
[12:01] <Lamego> My question is, can they be ? I understand they should not be
[12:01] <Burgundavia> Lamego: what app are you talking about?
[12:01] <Lamego> Burgundavia, phpmyadmin
[12:01] <Burgundavia> ahh
[12:01] <Burgundavia> sru are supposed to fix specific bugs
[12:02] <crimsun> Lamego: no.
[12:02] <Lamego> SRU are restricted to sec/critical fixes, to avoid regressions, which is kind of pointless because the released package is itself a regression
[12:02] <Kmos> crimsun: are you checking my ddclient update ?
[12:02] <crimsun> Kmos: no, I'm doing upstream alsa work ATM.
[12:02] <Kmos> :(
[12:02] <crimsun> I don't multitask well.  If you wait a few minutes, I'll get around to it.
[12:02] <Kmos> pochu: can you check http://revu.tauware.de/details.py?upid=5587
[12:03] <Kmos> crimsun: ok
[12:03] <Burgundavia> Lamego: if there is a specific bug, with a specific fix, that is a good candidate for an sru
[12:05] <Lamego> ok, too much work to fix a single bug, when there are are potentially a lot of other bugs to be fixed
[12:05] <crimsun> if everyone thought that way about every bug, then F/LOSS would suck.
[12:07] <Lamego> crimsun, naming a blind update policy as F/LOSS is a bit of an abuse :)
[12:09] <Burgundavia> Lamego: it is not a blind policy update
[12:09] <Burgundavia> it has a clear purpose: to keep stable as stable
[12:09] <Burgundavia> and not "today's crap that might be stable"