Re: RFS: bluemindo

[Patrick Schoenfeld]

Hi Vincent,

On Sun, Aug 03, 2008 at 11:34:25PM +0200, Vincent Bernat wrote:
> > Uarg. Another reason not to like CDBS, but apart from this, this seems
> > to be adequate.
>
> cdbs also supports quilt (/usr/share/cdbs/1/rules/patchsys-quilt.mk).
>
> You cannot  ask for  a "simple patch  system" and ask  numerous features
> (like series) that you find in more complex patch systems like quilt.

Thats a valid objection, indeed. So in this case just ignore what I
said.

Best Regards,
Patrick


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: daptup (new package, 3rd try)

[Eugene V. Lyubimkin]

Ben Finney wrote:
> "Eugene V. Lyubimkin" <[EMAIL PROTECTED]> writes:
> 
>> It builds these binary packages:
>> daptup - see changes in new & upgradeable lists after aptitude update
> 
> The package synopsis should be an appositive clause as described in
> http://www.debian.org/doc/developers-reference/ch-best-pkging-practices#s-bpp-pkg-synopsis>.
> Essentially this means the synopsis should make sense when inserted
> into the template " is {the,a,an} ".
> 
> A possible improved synopsis might be:
> 
> reporter of changes in list of available packages from repositories
> 
> Other improvements are certainly possible.
Thanks for this correction. Done as how you suggested and re-uploaded:
http://mentors.debian.net/debian/pool/main/d/daptup/daptup_0.4.0-2.dsc

-- 
Eugene V. Lyubimkin aka JackYF, Ukrainian C++ developer.



signature.asc
Description: OpenPGP digital signature

RFS: libmarkdown-php

[Daniel Watkins]

Dear mentors,

I am looking for a sponsor for my package "libmarkdown-php".

* Package name: libmarkdown-php
  Version : 1.0.1m
  Upstream Author : Michel Fortin <[EMAIL PROTECTED]>
* URL : http://michelf.com/projects/php-markdown/
* License : BSD
  Section : web

It builds these binary packages:
libmarkdown-php - a port to PHP of the Markdown program

The package appears to be lintian clean.

The upload would fix these bugs: 493683

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/l/libmarkdown-php
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/l/libmarkdown-php/libmarkdown-php_1.0.1m.dsc

I would be glad if someone uploaded this package for me.

Kind regards
-- 
Daniel Watkins (Odd_Bloke)


signature.asc
Description: PGP signature

Re: upstream has license which is an edited GPL

[Ben Finney]

Stanislav Maslovski <[EMAIL PROTECTED]> writes:

> I was going to package CDDE [1] but noticed that upstream ships it
> with a license file which is GPL v.2 without the preamble and the
> appendix 
[…]

> I have e-mailed the upstream explaining that changing GPL and
> removing its copyright is not allowed

The copyright license on the document containing the GPL says:

=
 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.
=

So, even if they preserve the copyright notice, they still may not
redistribute changed copies of the GPL document. Only verbatim copies
may be redistributed.

> but I am interested in the following. If he does not reply can I
> repackage or even fork his source which is under such a license?

The recommended way to license a work under the GNU GPL is to
specifically grant license under the terms of "the GNU General Public
License as published by the Free Software Foundation" etc., and give
instructions on how to get a copy of the license. If they've followed
that recommendation, then you have license to redistribute under the
terms of the GNU GPL even if the work doesn't include that license
text.

You are, as far as I can tell, free to obtain a verbatim copy of the
GNU GPL as described in the specific license grant (e.g. "either
version 2 of that License, or, at your option, any later version") and
exercise the license under the terms you find there.

You may even be within your rights to excise the copyright-infringing
modified document of the GPL and substitute a verbatim copy of the
real license text in the source you distribute. I'm not sure, though,
so I'm including debian-legal in this discussion for further input.

> Technically, it has all the terms of GPL, however I am worrying if
> what the upstream has done makes his resulting license legally void.

The inclusion of a license document doesn't imply anything about the
grant of license you have to the work. Likewise, I think the terms
that apply are those granted in the copyright holder's license grant.

Their license to the text of the GPL may be void, but the work under
discussion is (presumably) not a derivative work of the GPL document
itself. They can license the work in which they hold copyright however
they like, regardless of violating the copyright in a separate work,
and such license grant to third parties (such as you) should be
unaffected.

-- 
 \“Consider the daffodil. And while you're doing that, I'll be |
  `\  over here, looking through your stuff.” —Jack Handey |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: libmarkdown-php

[Daniel Watkins]

On Mon, 04 Aug 2008 19:25:16 +1000
Ben Finney <[EMAIL PROTECTED]> wrote:
> Daniel Watkins <[EMAIL PROTECTED]> writes:
> 
> > libmarkdown-php - a port to PHP of the Markdown program
> 
> Again, please make the synopsis an appositive clause (no leading
> article).
D'oh!

> It seems confusing to refer to a package named 'libfoo' as "a
> program"; if it's a library, better to use that more-specific term.
> 
> A better synopsis for this package might be:
> 
> PHP library for rendering Markdown data
Yeah, that's much better.  Fix uploaded.


Cheers,
-- 
Daniel Watkins (Odd_Bloke)


signature.asc
Description: PGP signature

Re: RFS: libmarkdown-php

[Ben Finney]

Daniel Watkins <[EMAIL PROTECTED]> writes:

> libmarkdown-php - a port to PHP of the Markdown program

Again, please make the synopsis an appositive clause (no leading
article).

It seems confusing to refer to a package named 'libfoo' as "a
program"; if it's a library, better to use that more-specific term.

A better synopsis for this package might be:

PHP library for rendering Markdown data

-- 
 \ “I must say that I find television very educational. The minute |
  `\   somebody turns it on, I go to the library and read a book.” |
_o__)—Groucho Marx |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: gtkmm-utils

[Iulian Udrea]

Hello Ben!

Ben Finney wrote:

You might like to show the full description here to inform better
>
synopses for these packages (and to help prospective sponsors more
>
easily decide on your packages).


libgtkmm-utils2:

 Library using gtkmm adding utility functions including:
 - tile widgets
 - dialog helpers

libglibmm-utils2:

Library using glibmm adding utility functions including:
- logging framework
- option parsing, date and string utilities


Package has been updated.

Thanks,
-- 
Iulian

PS: Please CC me because I'm not yet subscribed to [EMAIL PROTECTED]

Re: upstream has license which is an edited GPL

[Stanislav Maslovski]

On Mon, Aug 04, 2008 at 07:20:09PM +1000, Ben Finney wrote:
> So, even if they preserve the copyright notice, they still may not
> redistribute changed copies of the GPL document. Only verbatim copies
> may be redistributed.

That is true. That is what I ment.

> The recommended way to license a work under the GNU GPL is to
> specifically grant license under the terms of "the GNU General Public
> License as published by the Free Software Foundation" etc., and give
> instructions on how to get a copy of the license. If they've followed
> that recommendation, then you have license to redistribute under the
> terms of the GNU GPL even if the work doesn't include that license
> text.

As I mentioned in my e-mail to d-m, all upstream source files have this
standard GPL v.2 header. The only problem is that the COPYING file which
is distributed with the sources has been changed in the described way (GPL
preamble and appendix removed, terms kept).

One thing that I have to note also that after this standard header
the author writes: "For more details see the file COPYING." which
is the changed GPL.

> You are, as far as I can tell, free to obtain a verbatim copy of the
> GNU GPL as described in the specific license grant (e.g. "either
> version 2 of that License, or, at your option, any later version") and
> exercise the license under the terms you find there.

I see. This is good.

> You may even be within your rights to excise the copyright-infringing
> modified document of the GPL and substitute a verbatim copy of the
> real license text in the source you distribute. I'm not sure, though,
> so I'm including debian-legal in this discussion for further input.
> 
> > Technically, it has all the terms of GPL, however I am worrying if
> > what the upstream has done makes his resulting license legally void.
> 
> The inclusion of a license document doesn't imply anything about the
> grant of license you have to the work. Likewise, I think the terms
> that apply are those granted in the copyright holder's license grant.
> 
> Their license to the text of the GPL may be void, but the work under
> discussion is (presumably) not a derivative work of the GPL document
> itself. They can license the work in which they hold copyright however
> they like, regardless of violating the copyright in a separate work,
> and such license grant to third parties (such as you) should be
> unaffected.

I see, thank you for clarifications!

-- 
Stanislav


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RFS: liboauth-php

[Daniel Watkins]

Dear mentors,

I am looking for a sponsor for my package "liboauth-php".

* Package name: liboauth-php
  Version : 0.0~svn620
  Upstream Author : Andy Smith <[EMAIL PROTECTED]>
* URL : http://oauth.net/
* License : MIT
  Section : web

It builds these binary packages:
liboauth-php - open protocol to allow secure API authentication

The package appears to be lintian clean.

The upload would fix these bugs: 493691

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/l/liboauth-php
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/l/liboauth-php/liboauth-php_0.0~svn620.dsc

I would be glad if someone uploaded this package for me.

Kind regards
-- 
Daniel Watkins (Odd_Bloke)


signature.asc
Description: PGP signature

Re: upstream has license which is an edited GPL

[Ben Finney]

Stanislav Maslovski <[EMAIL PROTECTED]> writes:

> On Mon, Aug 04, 2008 at 07:20:09PM +1000, Ben Finney wrote:
> 
> > You are, as far as I can tell, free to obtain a verbatim copy of
> > the GNU GPL as described in the specific license grant (e.g.
> > "either version 2 of that License, or, at your option, any later
> > version") and exercise the license under the terms you find there.
> 
> One thing that I have to note also that after this standard header
> the author writes: "For more details see the file COPYING." which is
> the changed GPL.

That's not so good. (Referring the license recipient to the terms of
the GPL via an included file is good; that they've violated the
copyright on the GPL document itself is bad.)

I would expect the explicit word of the license grant "For more
details see the file COPYING" to indicate the explicit wishes of the
copyright holder, and hence have significance in determining what the
license is.

It might be that, since the copyright holder has explicitly referenced
that document for specific terms, you cannot legally just substitute
the correct GPL document in place of their copyright-violating
document. Of course, you cannot legally redistribute the
copyright-violating document either.

Certainly the best way to resolve this is for the copyright holder in
the work to ship a verbatim GPL document as the COPYING file to which
they refer.

-- 
 \  “Pity the meek, for they shall inherit the earth.” —Donald |
  `\  Robert Perry Marquis |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: liboauth-php

[Ben Finney]

Daniel Watkins <[EMAIL PROTECTED]> writes:

> It builds these binary packages:
> liboauth-php - open protocol to allow secure API authentication

The package doesn't seem to be correctly described by this synopsis.
The package is not a protocol; it's a PHP library.

Perhaps a better synopsis would be:

PHP library implementing the OAuth secure authentication protocol

-- 
 \  “It is well to remember that the entire universe, with one |
  `\   trifling exception, is composed of others.” —John Andrew Holmes |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: upstream has license which is an edited GPL

[Walter Landry]

Ben Finney <[EMAIL PROTECTED]> wrote:
> Stanislav Maslovski <[EMAIL PROTECTED]> writes:
> 
> > I was going to package CDDE [1] but noticed that upstream ships it
> > with a license file which is GPL v.2 without the preamble and the
> > appendix 
> […]
> 
> > I have e-mailed the upstream explaining that changing GPL and
> > removing its copyright is not allowed
> 
> The copyright license on the document containing the GPL says:
> 
> =
>  Everyone is permitted to copy and distribute verbatim copies
>  of this license document, but changing it is not allowed.
> =
> 
> So, even if they preserve the copyright notice, they still may not
> redistribute changed copies of the GPL document. Only verbatim copies
> may be redistributed.

Not quite.  From

  http://www.fsf.org/licensing/licenses/gpl-faq.html#ModifyGPL

  Can I modify the GPL and make a modified license?

You can use the GPL terms (possibly modified) in another license
provided that you call your license by another name and do not
include the GPL preamble, and provided you modify the
instructions-for-use at the end enough to make it clearly
different in wording and not mention GNU (though the actual
procedure you describe may be similar).

Cheers,
Walter Landry
[EMAIL PROTECTED]

Re: RFS: salasaga

[Vincent Bernat]

OoO  Pendant le  temps de  midi du  dimanche 03  août 2008,  vers 12:33,
"Iulian Udrea" <[EMAIL PROTECTED]> disait :

> salasaga_keycapture is not shipped any more. Is it intentional?


> Yes,  we already  ship  salasaga_screencapture and  keycapture is  for
> taking screenshots using Control and Print Screen.

OK.  The  package  seems fine.  I  have  uploaded  it. Thanks  for  your
contribution.
-- 
 /* After several hours of tedious analysis, the following hash
  * function won.  Do not mess with it... -DaveM
  */
2.2.16 /usr/src/linux/fs/buffer.c


pgpCg8BtJo769.pgp
Description: PGP signature

Re: RFS: bzr-cvsps-import

[Vincent Bernat]

OoO Vers  la fin de l'après-midi  du dimanche 03 août  2008, vers 16:24,
Jelmer Vernooij <[EMAIL PROTECTED]> disait :

>> > I am looking for a sponsor for my package "bzr-cvsps-import".
>> You can try to seek sponsorship inside Debian Bazaar Maintainers team.
> I'm a member of that team but unfortunately all of the active members
> are DMs these days, hence my asking here.

> Vorlon sponsored bzr-cvsps-import(thanks!), but I'm still looking for
> sponsors for bzr-stats and bzr-avahi.

Hi Jelmer!

For bzr-avahi, there is  a lot of things in diff.gz. I  think there is a
packaging problem  here, like using an unsynced  orig.tar.gz. You should
only have modifications concerning debian/ directory in diff.gz.

I don't  quite understand  your answer to  James Henstridge  about 0.2.0
version. Where did you put your fixed version?

In debian/compat, you should put 5.

In debian/control,  you should also  add a Vcs-Browser field.  I suppose
that there  is some  web interface  to browse the  source for  Bazaar as
well.

I think that  most things in Build-Depends are not  needed for the clean
rule, so  you can move them  in Build-Depends-Indep (and  just keep cdbs
and debhelper).

To avoid a lintian warning,  you should provide a debian/watch file with
just a comment about, for example, the URL to upstream repository.

For bzr-stats, there is no statement  about the license and I think that
the  GPL mention  in setup.py  is a  bit weak.  You should  arrange with
upstream  to  ask  him  to  add  a proper  copyright  statement  in  the
distributed files.

Apart from  the diff.gz which is  OK, the same remarks  as for bzr-avahi
apply.

Well,  this may  be a  bit late  since some  packages have  already been
sponsored,  but since  all those  plugins  are rather  small, you  could
bundle them in  a single package (like gnus-bonus-el  for example). This
will be a  bit harder to follow upstream since there  is no mechanism to
track  several upstreams  but  this will  ease  your work  in finding  a
sponsor, I think  and will allow you to ship more  plugins once you will
get an  upload with DM  field enabled. I  am not sure this  is something
encouraged or  something to  avoid. Maybe some  people will  give better
advices here about this.
-- 
panic("Attempted to kill the idle task!");
2.2.16 /usr/src/linux/kernel/exit.c


pgp6KKOQgHzXU.pgp
Description: PGP signature

Re: RFS: sclapp and pytagsfs (updated packages)

[Vincent Bernat]

OoO Peu  avant le début de  l'après-midi du dimanche 03  août 2008, vers
13:02, Y Giridhar Appaji Nag <[EMAIL PROTECTED]> disait :

> I did declare a stronger dependency, but 0.7 onwards pytagsfs also
> build-depends on sclapp and I don't know how I ignored this.  I fixed this and
> also updated pytagsfs to 0.7.1 (a bugfix release).

> The package is ready for upload:

>  http://mentors.debian.net/debian/pool/main/p/pytagsfs/

Hi Giridhar!

I have uploaded this new version.

I don't  know if I have already  told it (if so,  excuse the repetition)
but  since pytagsfs  has unittests,  you can  run them  unless  there is
nocheck in DEB_BUILD_OPTIONS.

somerule: # for example install
ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
# run tests
# clean tests (some pyc for example)
endif

It is up to you to decide if you want to run unittests. It should not be
too CPU intensive but unittests are generally quick.
-- 
printk("Penguin %d is stuck in the bottle.\n", i);
2.0.38 /usr/src/linux/arch/sparc/kernel/smp.c


pgpljx5D5iOvQ.pgp
Description: PGP signature

Re: RFS: desktop-data-model

[Vincent Bernat]

OoO  En ce  début de  soirée du  mercredi 23  juillet 2008,  vers 21:37,
Julien Lavergne <[EMAIL PROTECTED]> disait :

> I am looking for a sponsor for my package "desktop-data-model".

Hi Julien!

You  are  adding org.freedesktop.od.Engine.service.  Put  it in  debian/
directory instead and  use debian/rules or *.install files  to put it in
the right place. It is better that your diff.gz only contains changes to
debian/ directory.

Why did you name libddm-1-0 like this instead of libddm1? (well, I think
that I have found why).

The  long  description  does  not  explain  me  what  purpose  has  this
library. Can this library be used for something else than MugShot?

The   COPYING   file   containsLGPLv2.1+.   You   say   LGPLv2+   in
debian/copyright.  Moreover,  I don't  see  any  copyright statement  in
upstream  sources. You  should ask  upstream to  add a  proper copyright
statement. Just having a COPYING  file is a bit scarce (the instructions
of a proper copyright statement is at the end of the COPYING file ;-) ).

I  think that you  can improve  your debian/watch  by allowing  to track
changes for  version like 1.3 (for  example). Tell me if  you don't know
how.

Since you are  shipping a library, you should  call ldconfig in postinst
and postrm, as per policy 8.1.1.
-- 
BOFH excuse #312:
incompatible bit-registration operators


pgpW4qyimzRBH.pgp
Description: PGP signature

Re: RFS: sqlline

[Damien Raude-Morvan]

Le Monday 04 August 2008 06:47:41 Ola Lundqvist, vous avez écrit :
> Hi
>
> I have two comments on this package.
>
> 1) Please consider to name the package sqlline-java or similar. Not
> strictly necessary but it do not clutter the namespace as much. :)

AFAIK (and i'm not currently a DD :), and as said in [1], Java program "are 
ordinary programs, from the user point of view" so I dont see the need of 
appending "-java" to package name. For example, we don't append "-python" to 
every python program (take GRAMPS or apt-listchanges). We don't need to 
clutter package's names with programming language :)

> 2) Do not strip the .orig.tar.gz file unless strictly necessary. In this
> case I can not see that it is necessary. It would be good to ask upstream
> if it is possible to release one version without GPL references... If that
> is necessary is up to the ftp masters to decide though when accepting the
> package.

You're right, it's best to get a new release from upstream without GPL crufts 
but Marc Prud'hommeaux (upstream author) answer to me :
"
Unfortunately, I'm not going to have any time to make a new SQLLine  
release in the near future correcting the issue of the license file.
"

So for now, I'll revert to pristine upstream tarball and make a note in 
debian/README.source. Is it ok for you ?

[1] http://www.debian.org/doc/packaging-manuals/java-policy/x86.html
-- 
Damien Raude-Morvan / www.drazzib.com



signature.asc
Description: This is a digitally signed message part.

RFS and ITA: jzlib (updated package)

[Damien Raude-Morvan]

Dear mentors,

I am looking for a sponsor for the new version 1.0.7-1
of package "jzlib".

I'd like to adopt this orphaned package with this new upstream version and 
simplified packaging (using Ant CDBS).

It builds these binary packages:
libjzlib-java - Reimplementation of zlib in pure java

The package appears to be lintian clean.

The upload would fix these bugs: 491858

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/j/jzlib
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget http://mentors.debian.net/debian/pool/main/j/jzlib/jzlib_1.0.7-1.dsc

I would be glad if someone uploaded this package for me.

Regards,
-- 
Damien Raude-Morvan / www.drazzib.com



signature.asc
Description: This is a digitally signed message part.

Re: RFS: bzr-cvsps-import

[Jelmer Vernooij]

Hi Vincent,

Am Montag, den 04.08.2008, 21:03 +0200 schrieb Vincent Bernat:
> OoO Vers  la fin de l'après-midi  du dimanche 03 août  2008, vers 16:24,
> Jelmer Vernooij <[EMAIL PROTECTED]> disait :
> 
> >> > I am looking for a sponsor for my package "bzr-cvsps-import".
> >> You can try to seek sponsorship inside Debian Bazaar Maintainers team.
> > I'm a member of that team but unfortunately all of the active members
> > are DMs these days, hence my asking here.
> 
> > Vorlon sponsored bzr-cvsps-import(thanks!), but I'm still looking for
> > sponsors for bzr-stats and bzr-avahi.
Thanks for reviewing!

> For bzr-avahi, there is  a lot of things in diff.gz. I  think there is a
> packaging problem  here, like using an unsynced  orig.tar.gz. You should
> only have modifications concerning debian/ directory in diff.gz.
> 
> I don't  quite understand  your answer to  James Henstridge  about 0.2.0
> version. Where did you put your fixed version?
I simply merged a snapshot from upstream but hadn't noticed 0.2.0 was
released already. I'm not sure what missed up the diff.gz, but it should
be fixed now (only includes debian/). The new version depends on a very
recent version of bzr-dbus that I just uploaded to Sid.

> In debian/compat, you should put 5.
Fixed.

> In debian/control,  you should also  add a Vcs-Browser field.  I suppose
> that there  is some  web interface  to browse the  source for  Bazaar as
> well.
There is one, but it's not running on bzr.debian.org at the moment. 

> I think that  most things in Build-Depends are not  needed for the clean
> rule, so  you can move them  in Build-Depends-Indep (and  just keep cdbs
> and debhelper).
Fixed.

> To avoid a lintian warning,  you should provide a debian/watch file with
> just a comment about, for example, the URL to upstream repository.
Fixed.

> For bzr-stats, there is no statement  about the license and I think that
> the  GPL mention  in setup.py  is a  bit weak.  You should  arrange with
> upstream  to  ask  him  to  add  a proper  copyright  statement  in  the
> distributed files.
Fixed.

> Well,  this may  be a  bit late  since some  packages have  already been
> sponsored,  but since  all those  plugins  are rather  small, you  could
> bundle them in  a single package (like gnus-bonus-el  for example). This
> will be a  bit harder to follow upstream since there  is no mechanism to
> track  several upstreams  but  this will  ease  your work  in finding  a
> sponsor, I think  and will allow you to ship more  plugins once you will
> get an  upload with DM  field enabled. I  am not sure this  is something
> encouraged or  something to  avoid. Maybe some  people will  give better
> advices here about this.
Even if it's all inside a single source package, it would still be
necessary for the package to go through NEW whenever a new binary
package is added. Putting the multiple plugins into the same binary
package is probably a bad idea since they each have different
dependencies.

I've uploaded new versions to mentors.debian.net.

Cheers,

Jelmer
-- 
Jelmer Vernooij <[EMAIL PROTECTED]> - http://samba.org/~jelmer/
Jabber: [EMAIL PROTECTED]


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: RFS: desktop-data-model

[Robert Collins]

On Mon, 2008-08-04 at 21:29 +0200, Vincent Bernat wrote:
> OoO  En ce  début de  soirée du  mercredi 23  juillet 2008,  vers 21:37,
> Julien Lavergne <[EMAIL PROTECTED]> disait :
> 
> > I am looking for a sponsor for my package "desktop-data-model".
> 
> Hi Julien!
> 
> You  are  adding org.freedesktop.od.Engine.service.  Put  it in  debian/
> directory instead and  use debian/rules or *.install files  to put it in
> the right place. It is better that your diff.gz only contains changes to
> debian/ directory.

Urgh, I find this assertion really quite annoying, and seeing it in two
consecutive . Jumping through hoops to keep the diff contained in debian
harms reviewability as much as having arbitrary changes scattered over
the source tree.

Really, we want things to be as clear as possible; and if that means
changes outside the debian directory, then *that is fine*. We're not
just writing meta-data to install software in a debian package (though
that is a fine goal to be aiming for), we're fixing such bugs as needed
to have the software work well on debian (or at least however many bus a
particular DD feels up to fixing :)).

-Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

How can I commit code to svn.debian.org?

[Ding Honghui]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I want to update the new upstream code for curlftpfs to svn
repository[1]. I has register as a site user at alioth.debian.org as
user hhding-guest. I tried the command[2] to check code out and
authorization failed. I tried command[3], it works for check out but I
can't commit in and error message is "Authorization failed". What should
I do so that I can update the code to the svn?

[1] http://svn.debian.org/wsvn/collab-maint/deb-maint/curlftpfs/
[2] svn co
svn+ssh://[EMAIL PROTECTED]/collab-maint/deb-maint/curlftpfs/trunk/
[3] svn co
svn://[EMAIL PROTECTED]/collab-maint/deb-maint/curlftpfs/trunk/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiX5s0ACgkQJo9Njjkvy34f3QCgxkniY0052m/iUgkAieOsSbQT
7OEAmwR1W8R+tqYZ1QS2vmmn2Brs5M8R
=KOOm
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How can I commit code to svn.debian.org?

[Sandro Tosi]

Hi Ding,

On Tue, Aug 5, 2008 at 07:36, Ding Honghui <[EMAIL PROTECTED]> wrote:
> I want to update the new upstream code for curlftpfs to svn
> repository[1]. I has register as a site user at alioth.debian.org as
> user hhding-guest. I tried the command[2] to check code out and
> authorization failed. I tried command[3], it works for check out but I
> can't commit in and error message is "Authorization failed". What should
> I do so that I can update the code to the svn?
>
> [1] http://svn.debian.org/wsvn/collab-maint/deb-maint/curlftpfs/
> [2] svn co
> svn+ssh://[EMAIL PROTECTED]/collab-maint/deb-maint/curlftpfs/trunk/
> [3] svn co
> svn://[EMAIL PROTECTED]/collab-maint/deb-maint/curlftpfs/trunk/

To have commit access in collab-maint project, you got to go into
project page[1] and click on "Request to join"[2] link at the bottom
of the page. Once done, admins will approve you shortly (hopefully ;)
).

Kindly,
Sandro

[1] https://alioth.debian.org/projects/collab-maint/
[2] https://alioth.debian.org/project/request.php?group_id=30755

-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: sqlline

[Ola Lundqvist]

Ok with me. On both parts. :)

Best regards,

// Ola

On Mon, Aug 04, 2008 at 09:34:18PM +0200, Damien Raude-Morvan wrote:
> Le Monday 04 August 2008 06:47:41 Ola Lundqvist, vous avez écrit :
> > Hi
> >
> > I have two comments on this package.
> >
> > 1) Please consider to name the package sqlline-java or similar. Not
> > strictly necessary but it do not clutter the namespace as much. :)
> 
> AFAIK (and i'm not currently a DD :), and as said in [1], Java program "are 
> ordinary programs, from the user point of view" so I dont see the need of 
> appending "-java" to package name. For example, we don't append "-python" to 
> every python program (take GRAMPS or apt-listchanges). We don't need to 
> clutter package's names with programming language :)
> 
> > 2) Do not strip the .orig.tar.gz file unless strictly necessary. In this
> > case I can not see that it is necessary. It would be good to ask upstream
> > if it is possible to release one version without GPL references... If that
> > is necessary is up to the ftp masters to decide though when accepting the
> > package.
> 
> You're right, it's best to get a new release from upstream without GPL crufts 
> but Marc Prud'hommeaux (upstream author) answer to me :
> "
> Unfortunately, I'm not going to have any time to make a new SQLLine  
> release in the near future correcting the issue of the license file.
> "
> 
> So for now, I'll revert to pristine upstream tarball and make a note in 
> debian/README.source. Is it ok for you ?
> 
> [1] http://www.debian.org/doc/packaging-manuals/java-policy/x86.html
> -- 
> Damien Raude-Morvan / www.drazzib.com
> 



-- 
 - Ola Lundqvist ---
/  [EMAIL PROTECTED] Annebergsslingan 37  \
|  [EMAIL PROTECTED]  654 65 KARLSTAD  |
|  http://inguza.com/  +46 (0)70-332 1551   |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]