Re: Anonymous delayed queue?

[Joerg Jaspert]

On 11295 March 1977, Charles Plessy wrote:

> Is there a possibility to make delayed uploads as a DM ?

No.

-- 
bye, Joerg
<[EMAIL PROTECTED]>
Windows ME? Mit 13? Kann der nicht lieber Drogen nehmen wie andere Kinder
in dem Alter?


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

Re: RFS: caudium (updated package)

[Patrick Winnertz]

Am Freitag, 11. Januar 2008 11:17:44 schrieb Henrik Andreasson:
> Hilights from the changelog:
>* New maintainer (Closes: #411675)
>* Repacked caudium as architecture "all", thus caudium now uses
>  /usr/share/caudium as serverdir instead of
>  /usr/lib/caudium (Closes: #21)
>* New package translation Portuguese translation for debconf
>  messages, pt (Closes: #436553)
>(I will also close 459931 after upload.)
Nice extract from the changelog.. but the actuall package on mentors miss 
this completly:
caudium (2:1.4.12-9) unstable; urgency=low

  * Merge caudium-foo on ftp-masters recommendation

 -- Henrik Andreasson <[EMAIL PROTECTED]>  Fri, 25 Jan 2008 07:58:43 +0100

caudium (2:1.4.12-8) unstable; urgency=low

  * Fixes missing directory /var/log/caudium/localhost
  * Fixed permissions on /etc/caudium/servers
  * Fixed removeing dpkg-statoverrides at removal
  * Fixed chmod:ing cache files when upgrading

 -- Henrik Andreasson <[EMAIL PROTECTED]>  Mon, 14 Jan 2008 20:35:15 +0100

caudium (2:1.4.12-7) unstable; urgency=low

  * remove upper limit for pike package in control file

 -- Henrik Andreasson <[EMAIL PROTECTED]>  Mon, 14 Jan 2008 19:52:38 +0100

caudium (2:1.4.12-6) unstable; urgency=low

  * patch for apt-get as a client
  * fix the ssl-patch
  * fixed clean target

 -- Henrik Andreasson <[EMAIL PROTECTED]>  Wed, 09 Jan 2008 12:52:48 +0100

-
Furthermore there is a link in debian/copyright missing to the 
License /usr/share/common-licenses/...

Feel free to ping me again after this if fixed. Then I'll have another 
deeper look :)

Greetings
Winnie

-- 
 .''`.   Patrick Winnertz <[EMAIL PROTECTED]>
:  :' :  GNU/Linux Debian Developer
`. `'`   http://www.der-winnie.de http://people.skolelinux.org/~winnie
  `-  Debian - when you have better things to do than fixing systems


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

How uploaded zerofree?

[Thibaut Paumard]

Hi,

someone was so kind as to upload one of my packages, zerofree (now in  
NEW). I'd like to be sure who that was, so I can contact them later  
for the next upload for instance. How can I find out?


Best regards, Thibaut.






PGP.sig
Description: Ceci est une signature électronique PGP

Re: How uploaded zerofree?

[Kapil Hari Paranjape]

Hello,

On Thu, 14 Feb 2008, Thibaut Paumard wrote:
> someone was so kind as to upload one of my packages, zerofree (now in  
> NEW). I'd like to be sure who that was, so I can contact them later for 
> the next upload for instance. How can I find out?

Usually, "who-uploads" from "devscripts" should provide the answer.

Regards,

Kapil.
--


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

Re: How uploaded zerofree?

[Kumar Appaiah]

On Thu, Feb 14, 2008 at 11:56:49AM +0100, Thibaut Paumard wrote:
> Hi,
>
> someone was so kind as to upload one of my packages, zerofree (now in  
> NEW). I'd like to be sure who that was, so I can contact them later for 
> the next upload for instance. How can I find out?

It was Christoph Haas. You can find out by going to your QA page, and
putting the mouse over the NEW link:

http://qa.debian.org/[EMAIL PROTECTED]

Once uploaded, you may wish to use the who-uploads package in
devscripts.

HTH.

Kumar
-- 
Kumar Appaiah,
458, Jamuna Hostel,
Indian Institute of Technology Madras,
Chennai - 600 036


signature.asc
Description: Digital signature

Re: How uploaded zerofree?

[Patrick Winnertz]

Am Donnerstag, 14. Februar 2008 12:12:23 schrieb Kumar Appaiah:
> On Thu, Feb 14, 2008 at 11:56:49AM +0100, Thibaut Paumard wrote:
> > Hi,
> >
> > someone was so kind as to upload one of my packages, zerofree (now in
> > NEW). I'd like to be sure who that was, so I can contact them later
> > for the next upload for instance. How can I find out?
>
> It was Christoph Haas. You can find out by going to your QA page, and
> putting the mouse over the NEW link:
Sorry.. :) No. It was me. 
He also asks for sponsorship on the pkg-virtualbox-devel list on alioth and 
I replied there that I'll sponsor it. (but as I saw now, I forgot to CC 
him, so he doesn't get that email, since he wasn't subscribed.).

Greetings
Winnie

-- 
 .''`.   Patrick Winnertz <[EMAIL PROTECTED]>
:  :' :  GNU/Linux Debian Developer
`. `'`   http://www.der-winnie.de http://people.skolelinux.org/~winnie
  `-  Debian - when you have better things to do than fixing systems


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

Re: RFS: failmalloc

[Jon Dowland]

On Fri, Feb 08, 2008 at 07:32:18PM +0900, Michal ??iha?? wrote:
> No you should not change orig.tar.gz, it should be exactly the same as
> upstream provides (unless you have good reason to do so). Just delete
> them in clean under same condition you use for copying them
> from /usr/share, this way the change won't be present in diff.

How about

* build-depend on autotools-dev
* move the upstream config.guess and config.sub to
  config.{guess,sub}.upstream in the configure target
* copy the guess/sub from the autotools-dev location into the
  build tree, again in the configure target
* if the *upstream files exist; move them back over sub/guess in
  the clean target

That way you don't modify the orig tarball; you're guaranteed to have an
appropriate and up-to-date sub/guess; the unpacked source is back to
pristine upstream after the make clean target, which is particularly
nice if you have your tree in a VCS and don't want to keep filtering the
sub/guess changes out of commits.

-- 
Jon Dowland


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

Re: How uploaded zerofree?

[Kumar Appaiah]

On Thu, Feb 14, 2008 at 12:08:11PM +0100, Patrick Winnertz wrote:
> > > someone was so kind as to upload one of my packages, zerofree (now in
> > > NEW). I'd like to be sure who that was, so I can contact them later
> > > for the next upload for instance. How can I find out?
> >
> > It was Christoph Haas. You can find out by going to your QA page, and
> > putting the mouse over the NEW link:
> Sorry.. :) No. It was me. 
> He also asks for sponsorship on the pkg-virtualbox-devel list on alioth and 
> I replied there that I'll sponsor it. (but as I saw now, I forgot to CC 
> him, so he doesn't get that email, since he wasn't subscribed.).

Argh! Yes, I am sorry. The first package on that list, which is
yorick-spydr, was uploaded by Christoph. The second one, naturally,
says winnie. :-)

Kumar
-- 
Kumar Appaiah,
458, Jamuna Hostel,
Indian Institute of Technology Madras,
Chennai - 600 036


signature.asc
Description: Digital signature

Re: RFS: failmalloc

[Bernhard R. Link]

* Jon Dowland <[EMAIL PROTECTED]> [080214 12:20]:
> On Fri, Feb 08, 2008 at 07:32:18PM +0900, Michal ??iha?? wrote:
> > No you should not change orig.tar.gz, it should be exactly the same as
> > upstream provides (unless you have good reason to do so). Just delete
> > them in clean under same condition you use for copying them
> > from /usr/share, this way the change won't be present in diff.
> 
> How about
> 
>   * build-depend on autotools-dev
>   * move the upstream config.guess and config.sub to
> config.{guess,sub}.upstream in the configure target
>   * copy the guess/sub from the autotools-dev location into the
> build tree, again in the configure target
>   * if the *upstream files exist; move them back over sub/guess in
> the clean target
> 
> That way you don't modify the orig tarball; you're guaranteed to have an
> appropriate and up-to-date sub/guess; the unpacked source is back to
> pristine upstream after the make clean target, which is particularly
> nice if you have your tree in a VCS and don't want to keep filtering the
> sub/guess changes out of commits.

Again: there is no need to save the old config.guess and config.sub.
Just delete them in clean and copy them in before configuring, all
problems solved.

Hochachtungsvoll,
Bernhard R. Link


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

RFS: asterisk-prompt-es (updated package)

[Victor Seva]

Dear mentors,

I am looking for a sponsor for the new version 1.4-2
of my package "asterisk-prompt-es".

It builds these binary packages:
asterisk-prompt-es - Spanish prompts for the Asterisk PBX

The package appears to be lintian clean.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/non-free/a/asterisk-prompt-es
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget
http://mentors.debian.net/debian/pool/non-free/a/asterisk-prompt-es/asterisk-prompt-es_1.4-2.dsc

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

Kind regards
 Victor Seva
-- 
 -
|   ,''`. Victor Seva |
|  : :' :  [EMAIL PROTECTED] |
|  `. `'   PGP Key ID: 0xDD12F253 |
|`-Debian user, admin and contributor |
 -



signature.asc
Description: OpenPGP digital signature

Re: RFS: asterisk-prompt-es (updated package)

[Faidon Liambotis]

Hi,

Victor Seva wrote:

I am looking for a sponsor for the new version 1.4-2
of my package "asterisk-prompt-es".

Is there any reason why this isn't maintained in pkg-voip's SVN repository?

Regards,
Faidon


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

Re: RFS: asterisk-prompt-es (updated package)

[Victor Seva]

Faidon Liambotis wrote:
> Is there any reason why this isn't maintained in pkg-voip's SVN repository?

No, there isn't. If you think it has to be on svn and I could commit
on it, I have no objection.

-- 
 -
|   ,''`. Victor Seva |
|  : :' :  [EMAIL PROTECTED] |
|  `. `'   PGP Key ID: 0xDD12F253 |
|`-Debian user, admin and contributor |
 -



signature.asc
Description: OpenPGP digital signature

Re: RFS: failmalloc

[Jon Dowland]

On Thu, Feb 14, 2008 at 12:31:16PM +0100, Bernhard R. Link wrote:
> Again: there is no need to save the old config.guess and config.sub.
> Just delete them in clean and copy them in before configuring, all
> problems solved.

Because:

> the unpacked source is back to pristine upstream after the make clean
> target, which is particularly nice if you have your tree in a VCS and
> don't want to keep filtering the sub/guess changes out of commits.

That is, if you branch, make a change, do a build, see it worked, do a
clean, then want to commit your change, you don't have config/sub diffs
in your commit (or have to fix them by hand for each feature add). Also,
if  -> build ->  -> clean ->  and state 0 !=
2, there's the potential for "not the same two builds in a row", which
afaik is a QA goal for lenny.

But I haven't seen anyone actually do this in packages, so I'd love to
hear people's opinions on the matter.


-- 
Jon Dowland


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

Re: RFS: python-twitter

[Mauro Lizaur]

On Wed, Feb 13, 2008 at 4:25 PM, Piotr Ożarowski <[EMAIL PROTECTED]> wrote:
>  > Added the email of the author and Google as a copyright holder too.
>  > I hope this is ok, if not, just tell me.
>
>  I cannot find anything about DeWitt Clinton being a copyright holder,
>  please point me to proper file and line.
>
I assume he was the copyright holder since he started the module,
his name appears in the files PKG-INFO and README in the source.
But appearently Google Inc is the copyright holder, so i'll modify this.

>  > I sent a request to join to the DPMT :)
>
>  you leaved comment field empty, but you're in, welcome :)
>

Yep, i realized that when form was sent :/

>
>  Please add our team to Uploaders or Maintainer field, add these two
>  fields:
>
>   Vcs-Svn: svn://svn.debian.org/python-modules/packages/python-twitter/trunk
>   Vcs-Browser: 
> http://svn.debian.org/wsvn/python-modules/packages/python-twitter/trunk/?op=log
>
>  to source stanza (in debian/control) and inject your package into the
>  repo f.e. using this command:
>
>   svn-inject -o python-twitter_0.5-1.dsc svn+ssh://[EMAIL 
> PROTECTED]/svn/python-modules/packages/
>
>

Okie dokie, i'll do these changes later, right now im at work and
don't have this with me right now.

Thanks,
Mauro


-- 
BEGIN GEEK CODE BLOCK
Version: 3.12
GCM/O d->dpu$ s-:- a-->a+++$ C+++
LU P+ L++ E W+++ N !o K w O !M !V
PS+ PE Y+ PGP t 5– X R tv++ b- DI D++ G+ e
h!>h-- r>r+++ y+
END GEEK CODE BLOCK

Re: Anonymous delayed queue?

[Nico Golde]

Hi Cyril,
* Cyril Brulebois <[EMAIL PROTECTED]> [2008-02-14 08:48]:
> On 14/02/2008, Charles Plessy wrote:
> > If you or somebody else agree that it is of general interest (in
> > private if you want to limit the traffic on this list), I can
> > propose an update for the Developpers Reference.
> 
> Isn't that just basic UNIX knowledge?

Yes :)
Cheers
Nico
-- 
Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.
http://people.debian.org/~nion/sponsoring-checklist.html


pgpVXKKNUQuOW.pgp
Description: PGP signature

RFS: gfxboot

[David Paleino]

Dear mentors,

I am looking for a sponsor for "gfxboot".

* Package name: gfxboot
  Version : 4.0.1-1
  Upstream Author : SUSE LINUX AG, Nuernberg, Germany
Steffen Winterfeldt <[EMAIL PROTECTED]>
* URL :
http://www.novell.com/products/linuxpackages/suselinux/gfxboot.html
* License : GPL-2
  Section : utils

It builds these binary packages:
gfxboot- bootlogo creator for gfxboot compliant boot loaders

 This package is needed to create the graphical boot logos for gfxboot,
 introduced and developed by SuSE, it is suitable for grub, lilo and syslinux.

The package threw some lintian warnings, mainly missing manpages. I've
created two manpages using help2man (and fixing the resulting output),
but I can't make anything "useful" at the moment for other two binaries:

W: gfxboot: binary-without-manpage usr/bin/help2txt
W: gfxboot: binary-without-manpage usr/bin/unpack_bootlogo

I believe this is a minor issue, thus I'm sending my RFS nevertheless. I'll dig
into the source and try to document those binaries ASAP:
- help2txt is a Perl script, which might be easy for some guru, but not for me.
Thus I'll need to look at the code and go by trial-and-error;
- unpack_bootlogo is a simpler script (again, in Perl), and I could write a
short manpage for it, but I'd like to give also some example usage, and I'd
need some time for this;

The upload would fix ITP #465768.

The package can be found on mentors.debian.net:

dget http://mentors.debian.net/debian/pool/main/g/gfxboot/gfxboot_4.0.1-1.dsc

Kindly,
David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: RFS: lynis

[Patrick Schoenfeld]

Hi Francisco,

IANADD so I cannot sponsor your upload. However I think my comments may
be useful for you. CC'ing my AM: Eventually he has additional comments
and/or is willing to sponsor your upload, when everything okay.

On Thu, Feb 14, 2008 at 01:22:42AM +0100, Francisco García wrote:
> - dget http://mentors.debian.net/debian/pool/main/l/lynis/lynis_1.0.8-1.dsc

- debian/changelog:
I would suggest you to remove the changelog entry for 1.0.7-1, as
appearently 1.0.8-1 will be the first release in Debian. Some people argue
that there is no need to hide the development of a package from the target
audience of changelogs, but IMHO the first changelog entry contains
practical no information (its redundant, anyway) and is confusing (due to
its redundance)

- debian/control
- Misses a homepage header to indicate upstream url. See [1]

- debian/copyright:
- Should include a license excerpt. If you have dh-make installed,
see /usr/share/debhelper/dh_make/licenses/gpl for an example.
- IMHO the "," between the copyright year and your name is not needed
- nitpick: Not so beauty are the useless empty spaces at and eof line:)
- What do you think about adding the machine-parseable fields to copyright?
  [2]

- debian/dirs:
Are you sure you need it? Seems to me like you won't need it, if you'd do
minor modifications to your debian/rules file

- debian/rules:
- Dou you really need the (useless) comments that are added by dh-make?
- configure-stamp target misses a touch configure-stamp
- same for build-stamp (simply uncomment your touch ;)
- install: Please remove the commented make install call if you don't need
  it.
- you could use the install -D parameter with your install calls and avoid
  to create directories seperateley. However this only works for the install
  calls where you only install single files.
- it would make sense to delete the useless empty lines (1 or two lines
  between targets is fine, but it does not make much sense two have 5 or
  more onfollowing empty lines)
- where is the point to call dh_makeshlibs - your package does not contain
  shared libraries, does it?

- debian/lynis.manpages is useless as you only install one manpage. you can give
  it as an argument to dh_installmanpages.

- debian/watch is missing but is highly recommended! This enables you to track
  new upstream versions automatically via your qa page (and via mail
  notification!). See [3]

Best Regards,
Patrick

[1] http://wiki.debian.org/DpkgHomepageFieldTransition
[2] http://wiki.debian.org/Proposals/CopyrightFormat
[3] http://wiki.debian.org/DEHS



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

Re: Bug#397939: Lintian: outdated-autotools-helper-file

[Clint Adams]

On Mon, Feb 11, 2008 at 10:53:48AM +0100, Bas Wijnen wrote:
> I suggest to mandate "remove all generated files in the clean target"
> (formulated in a way which includes "generated by upstream", not only
> "generated by the build target), which implies "rebuild everything in
> the build target".

Tell me how I, as an upstream, can use an experimental version of
libtool in that situation.


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

Done. Re: RFS: meritous 1.2-2 (now 1.2+dfsg-1)

[Alexander Schmehl]

* D. Moonfire <[EMAIL PROTECTED]> [080213 18:28]:
> Ended up repackaging parts of the package when I went through a
> licensing audit on the music files. After suggestions from
> #debian-games, I removed the music files and changed it to get version
> 1.2+dfsg-1.

Uploaded.


Yours sincerely,
  Alexander


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

Re: Bug#397939: Lintian: outdated-autotools-helper-file

[Russ Allbery]

Bas Wijnen <[EMAIL PROTECTED]> writes:

> A workaround could be to not regenerate the files.  This is how it is
> usually done now.  IMO that is incorrect, because the compiler for every
> generated file must be in Debian.  The current practise of not rerunning
> autotools makes this rule technically unnecessary, but it can still be
> violated (and that should still be considered a bug, even if it doesn't
> result in a build failure).

Note that libtool is an unusual case here and isn't the same as Autoconf
or Automake.  The files included in the package (libtool.m4 and ltmain.sh)
are not generated files in the same sense.  Running libtoolize basically
just copies those files from the installed libtool into the package.

I think (but am not at all certain) that ltmain.sh is a generated file in
that I don't think it's maintained in that form by the libtool
maintainers, but if so, whatever generation is done is already done as
part of the installation of libtool.

It's not like Autoconf or Automake where a file in the source is used as
input to a compiler which generates a shell script based on it.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Bug#397939: Lintian: outdated-autotools-helper-file

[Bas Wijnen]

On Thu, Feb 14, 2008 at 04:43:52PM -0500, Clint Adams wrote:
> On Mon, Feb 11, 2008 at 10:53:48AM +0100, Bas Wijnen wrote:
> > I suggest to mandate "remove all generated files in the clean target"
> > (formulated in a way which includes "generated by upstream", not only
> > "generated by the build target), which implies "rebuild everything in
> > the build target".
> 
> Tell me how I, as an upstream, can use an experimental version of
> libtool in that situation.

Upstream can do whatever they want, of course.  Policy only applies to
Debian.  So I'll instead answer the question "How can I, as a packager,
follow this rule when upstream uses an experimental version of libtool?"

If a package requires a compiler which currently is not in Debian
(main), then the package cannot be in main either (even if the compiler
is free).  This situation you describe falls in that category IMO.

A workaround could be to not regenerate the files.  This is how it
is usually done now.  IMO that is incorrect, because the compiler for
every generated file must be in Debian.  The current practise of not
rerunning autotools makes this rule technically unnecessary, but it can
still be violated (and that should still be considered a bug, even if it
doesn't result in a build failure).

Another workaround could be to include the experimental libtool
in the package.  This is not a very good idea, and it would probably be
better to package the new libtool as a separate package (not named
"libtool", to avoid it being used as default) and Build-Depend on that.

Even better would probably be to convince upstream to not use features
of experimental versions.  That may of course not always be possible.
:-)

Does this answer your question?

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: Bug#397939: Lintian: outdated-autotools-helper-file

[Bas Wijnen]

On Thu, Feb 14, 2008 at 04:02:41PM -0800, Russ Allbery wrote:
> Bas Wijnen <[EMAIL PROTECTED]> writes:
> > A workaround could be to not regenerate the files.  This is how it is
> > usually done now.  IMO that is incorrect, because the compiler for every
> > generated file must be in Debian.  The current practise of not rerunning
> > autotools makes this rule technically unnecessary, but it can still be
> > violated (and that should still be considered a bug, even if it doesn't
> > result in a build failure).
> 
> Note that libtool is an unusual case here and isn't the same as Autoconf
> or Automake.  The files included in the package (libtool.m4 and ltmain.sh)
> are not generated files in the same sense.  Running libtoolize basically
> just copies those files from the installed libtool into the package.

Oh, ok.  That changes things a bit.  In that case, not copying them, but
using the included copy instead is similar to using an included version
of a library instead of the package containing it.  This is bad for
security, but not a problem with respect to policy.

> I think (but am not at all certain) that ltmain.sh is a generated file in
> that I don't think it's maintained in that form by the libtool
> maintainers, but if so, whatever generation is done is already done as
> part of the installation of libtool.

In that case, my proposal would require it to be copied from there, and
not used from upstream.  That is wise anyway, but if it would just be a
copy of the source, it would strictly not be required.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: Bug#397939: Lintian: outdated-autotools-helper-file

[Russ Allbery]

Bas Wijnen <[EMAIL PROTECTED]> writes:
> On Thu, Feb 14, 2008 at 04:02:41PM -0800, Russ Allbery wrote:

>> Note that libtool is an unusual case here and isn't the same as
>> Autoconf or Automake.  The files included in the package (libtool.m4
>> and ltmain.sh) are not generated files in the same sense.  Running
>> libtoolize basically just copies those files from the installed libtool
>> into the package.

> Oh, ok.  That changes things a bit.  In that case, not copying them, but
> using the included copy instead is similar to using an included version
> of a library instead of the package containing it.  This is bad for
> security, but not a problem with respect to policy.

Given that the files are only used during the build process, it seems
fairly irrelevant to security to me.  (Embedded copies of libltdl are a
different issue, but we already generally disable those.)

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Bug#397939: Lintian: outdated-autotools-helper-file

[Clint Adams]

On Thu, Feb 14, 2008 at 04:02:41PM -0800, Russ Allbery wrote:
> Note that libtool is an unusual case here and isn't the same as Autoconf
> or Automake.  The files included in the package (libtool.m4 and ltmain.sh)
> are not generated files in the same sense.  Running libtoolize basically
> just copies those files from the installed libtool into the package.

libtool.m4 is included via aclocal (unless you're not using automake),
and then processed into configure by autoconf (unless you're not using
autoconf).

So if you build-dep on autoconf and automake and try to use sources
written for libtool 2.1, everything will break horribly even if you keep
the static libtool files the same.

We have been stuck with libtool 1.5 for 4 years.


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

Re: Bug#397939: Lintian: outdated-autotools-helper-file

[Russ Allbery]

Clint Adams <[EMAIL PROTECTED]> writes:
> On Thu, Feb 14, 2008 at 04:02:41PM -0800, Russ Allbery wrote:

>> Note that libtool is an unusual case here and isn't the same as
>> Autoconf or Automake.  The files included in the package (libtool.m4
>> and ltmain.sh) are not generated files in the same sense.  Running
>> libtoolize basically just copies those files from the installed libtool
>> into the package.

> libtool.m4 is included via aclocal (unless you're not using automake),
> and then processed into configure by autoconf (unless you're not using
> autoconf).

Oh, yes, good point.  Sorry about that.

> So if you build-dep on autoconf and automake and try to use sources
> written for libtool 2.1, everything will break horribly even if you keep
> the static libtool files the same.
>
> We have been stuck with libtool 1.5 for 4 years.

I was used to upstreams that include libtool.m4 in the package, in which
case I don't believe that running aclocal will overwrite it (but maybe I'm
wrong?).  If they're pulling in libtool macros using aclocal without
keeping a local copy, that indeed will break.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

RFS: gnome-schedule (updated package)

[Pedro Fragoso]

Dear mentors,

I am looking for a sponsor for the new version 2.0.2-1.1
of my package "gnome-schedule".

It builds these binary packages:
gnome-schedule - GNOME scheduler for automatic tasks

The package appears to be lintian clean.

The upload would fix these bugs: 452458

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/g/gnome-schedule
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/g/gnome-schedule/gnome-schedule_2.0.2-1.1.dsc

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

Kind regards
 Pedro Fragoso


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

Re: RFS: python-twitter

[Mauro Lizaur]

On Wed, Feb 13, 2008 at 5:25 PM, Piotr Ożarowski <[EMAIL PROTECTED]> wrote:
> [Mauro Lizaur, 13.02.2008]
>
> > On Feb 12, 2008 9:28 PM, Piotr Ożarowski <[EMAIL PROTECTED]> wrote:
>  > > One more thing before I upload it: please clarify copyright holder
>  > > issue - the one in sources and in debian/copyright doesn't match
>  > >
>  > Added the email of the author and Google as a copyright holder too.
>  > I hope this is ok, if not, just tell me.
>
>  I cannot find anything about DeWitt Clinton being a copyright holder,
>  please point me to proper file and line.
>
>
>  > I sent a request to join to the DPMT :)
>
>  you leaved comment field empty, but you're in, welcome :)
>
>
>  Please add our team to Uploaders or Maintainer field, add these two
>  fields:
>
>   Vcs-Svn: svn://svn.debian.org/python-modules/packages/python-twitter/trunk
>   Vcs-Browser: 
> http://svn.debian.org/wsvn/python-modules/packages/python-twitter/trunk/?op=log
>
>  to source stanza (in debian/control) and inject your package into the
>  repo f.e. using this command:
>
>   svn-inject -o python-twitter_0.5-1.dsc svn+ssh://[EMAIL 
> PROTECTED]/svn/python-modules/packages/
>
>
>
>  --
>  http://people.debian.org/~piotr/sponsor.txt
>

Hi Piotr,
I've just sent the changes to m.d.n [0] with DPMT in the Uploaders
field and the Vcs fields too.
Also i did the svn-inject to svn.debian.org (I hope everything is OK
since i have little experience using svn)

Just tell me if there's anything wrong.

[0] 
http://mentors.debian.net/debian/pool/main/p/python-twitter/python-twitter_0.5-1.dsc

Thanks,
Mauro
-- 
BEGIN GEEK CODE BLOCK
Version: 3.12
GCM/O d->dpu$ s-:- a-->a+++$ C+++
LU P+ L++ E W+++ N !o K w O !M !V
PS+ PE Y+ PGP t 5– X R tv++ b- DI D++ G+ e
h!>h-- r>r+++ y+
END GEEK CODE BLOCK

Re: RFS: lynis

[Paul Wise]

First, a question:

How does lynis compare with bastille (already in Debian)?

On Fri, Feb 15, 2008 at 5:59 AM, Patrick Schoenfeld
<[EMAIL PROTECTED]> wrote:

>  IANADD so I cannot sponsor your upload. However I think my comments may
>  be useful for you. CC'ing my AM: Eventually he has additional comments
>  and/or is willing to sponsor your upload, when everything okay.

Additional comments below.

>  - debian/control
> - Misses a homepage header to indicate upstream url. See [1]

Another reference: http://wiki.debian.org/HomepageFieldHOWTO

Some description changes:

s/Security/security/
s/create/creates/
s/professionals/professional/
s/adition/addition/
s/finetunning/fine-tuning/

>  - debian/copyright:

Please also reference the correct GPL file, there are both GPL-2 and
GPL-3 in /usr/share/common-licences.

>  - debian/rules:
> - configure-stamp target misses a touch configure-stamp

Removing the configure/configure-stamp targets is another option.

Other issues:

sed -i -e 's/man page/the manual page/' debian/README.Debian

The changes to the lynis script should be moved into a quilt (or
dpatch) patch or you could make the changes using sed in the build
target like so:

build:
...
mkdir build
cp lynis build
sed -i -e 's_PROFILE="default.prf"_PROFILE="/etc/lynis/default.prf"_'
build/lynis
sed -i -e 's_INCLUDEDIR="include"_INCLUDEDIR="/usr/share/lynis/include"_'
build/lynis

clean:
...
rm -rf build

install:
...
install -D $(CURDIR)/build/lynis $(CURDIR)/debian/lynis/usr/sbin/

The postrm script is not necessary, dpkg handles removing conffiles on
purge and you are using a recent debhelper so files in /etc should be
automatically marked as conffiles.

default.prf contains a commented out debian-specific security check,
is there any reason you didn't enable it?

Please run lintian -I in future:

I: lynis: hyphen-used-as-minus-sign usr/share/man/man8/lynis.8.gz:14
I: lynis: hyphen-used-as-minus-sign usr/share/man/man8/lynis.8.gz:28
I: lynis: hyphen-used-as-minus-sign usr/share/man/man8/lynis.8.gz:30
I: lynis: hyphen-used-as-minus-sign usr/share/man/man8/lynis.8.gz:32
I: lynis: hyphen-used-as-minus-sign usr/share/man/man8/lynis.8.gz:34
I: lynis: hyphen-used-as-minus-sign usr/share/man/man8/lynis.8.gz:39
I: lynis: hyphen-used-as-minus-sign usr/share/man/man8/lynis.8.gz:43
I: lynis: hyphen-used-as-minus-sign usr/share/man/man8/lynis.8.gz:47
I: lynis: hyphen-used-as-minus-sign usr/share/man/man8/lynis.8.gz:51

Some remarks to pass upstream:

Upstream should be changed so that the patch to the lynis script is
not necessary. Same with any potential patch to default.prf. The best
way to enable that would be to write a configure script.

Upstream should provide a Makefile or script to install lynis so there
is no Debian-specific installation. Otherwise other distributions will
have to duplicate part of debian/rules.

Upstream CHANGELOG file is more of a NEWS file than a ChangeLog.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: RFS: syslog-summary (updated and adopted package)

[Kapil Hari Paranjape]

Hello,


On Thu, 07 Feb 2008, David Paleino wrote:
> I am looking for a sponsor for the new version 1.13 of the package
> "syslog-summary", which I'm also adopting (ITA: #455005).

Looks like a worthwhile package to keep going.

> The package can be found on mentors.debian.net:
> - dget
> http://mentors.debian.net/debian/pool/main/s/syslog-summary/syslog-summary_1.13.dsc

Could you please clarify the following issues:
1. The package does not seem to be Debian specific.
   Yet it is packaged as such.
2. I think that you have incorporated all changes
   from the Ubuntu patch but please make sure!
3. What is the status of 284708?

Regards,

Kapil.
--



signature.asc
Description: Digital signature

Re: RFS: syslog-summary (updated and adopted package)

[David Paleino]

Il giorno Fri, 15 Feb 2008 09:58:34 +0530
Kapil Hari Paranjape <[EMAIL PROTECTED]> ha scritto:

> Hello,

Hi Kapil,

> On Thu, 07 Feb 2008, David Paleino wrote:
>
> > The package can be found on mentors.debian.net:
> > - dget
> > http://mentors.debian.net/debian/pool/main/s/syslog-summary/syslog-summary_1.13.dsc
> 
> Could you please clarify the following issues:
>   1. The package does not seem to be Debian specific.
>  Yet it is packaged as such.

The previous maintainer did it Debian-specific. I have a *big* TODO list for
this package, and making a sf.net (or freshmeat, or ...) page, thus a
non-Debian-specific release, is one of the primary tasks. :)

>   2. I think that you have incorporated all changes
>  from the Ubuntu patch but please make sure!

Ubuntu just patched:

-#!/usr/bin/python2.2
+#!/usr/bin/env python

>   3. What is the status of 284708?

I've had no time lastly (have 3 exams, one every 10 days), really. But I need
to investigate further to see what can be done.

Thanks,
David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature