Re: cppcheck: Incorrect minimum version requirement for Depends: on libc

[Joachim Reichel]

Hi,

On 19.11.21 18:35, Joachim Reichel wrote:

I'd appreciate some help with a problem I don't understand.

Bug #1000146 against cppcheck 2.6-1 (in testing and unstable) is about the fact 
that /usr/bin/cppcheck seems to require "libc6 >= 2.32" while the Depends: line 
in the binary package cppcheck contains "libc6 (>= 2.29)".


I debugged this a bit further and found that dpkg-shlibdeps does not take 
certain symbols into account. Details are in bug #1000421.


Best regards,
  Joachim

cppcheck: Incorrect minimum version requirement for Depends: on libc

[Joachim Reichel]

Dear mentors,

I'd appreciate some help with a problem I don't understand.

Bug #1000146 against cppcheck 2.6-1 (in testing and unstable) is about the fact 
that /usr/bin/cppcheck seems to require "libc6 >= 2.32" while the Depends: line 
in the binary package cppcheck contains "libc6 (>= 2.29)".


Of course I can specify that version requirement manually in the source package, 
but shouldn't "Depends: ${shlibs:Depends}, ${misc:Depends} [...]" take care of that?


1. Just running cppcheck with libc6 2.32 (from testing/unstable) works:

$ cppcheck
Cppcheck - A tool for static C/C++ code analysis
[...]

2. Using libc.so.6 from libc6 2.31-13+deb11u2 (from stable) results in

$ LD_PRELOAD=./libc.so.6 cppcheck
cppcheck: ./libc.so.6: version `GLIBC_2.32' not found (required by cppcheck)
cppcheck: ./libc.so.6: version `GLIBC_2.32' not found (required by 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6)
cppcheck: ./libc.so.6: version `GLIBC_2.32' not found (required by 
/lib/x86_64-linux-gnu/libpthread.so.0)


3. Inspecting the cppcheck binary gives

$ readelf -a /usr/bin/cppcheck | grep "2\.32"
004670e0  041e0005 R_X86_64_COPY 004670e0 
__libc_single_threaded@GLIBC_2.32 + 0

   1054: 004670e0 1 OBJECT  GLOBAL DEFAULT   26 [...]@GLIBC_2.32 
(20)
   41c:   1 (*global*)  1 (*global*) 14 (GLIBC_2.32)1 (*global*)
   0x0070:   Name: GLIBC_2.32  Flags: none  Version: 20

Do I interpret that correctly that cppcheck itself requires libc6 >= 2.32 (and 
not just one of its dependencies)? Why doesn't that requirement make it into the 
Depends: of the binary package?


The problem can be reproduced by building cppcheck 2.6-1 in an unstable chroot. 
So it is not just some transient glitch when the package was build for the 
archive ~4 weeks ago. Build log for amd64 is at 
https://buildd.debian.org/status/fetch.php?pkg=cppcheck&arch=amd64&ver=2.6-1&stamp=1634837839&raw=0


Best regards,
   Joachim

Re: Workaround for "Architecture: any [!armel !armhf]" in debian/control

[Joachim Reichel]

Hi,

On 04/21/2016 10:32 PM, Jakub Wilk wrote:
> * Joachim Reichel , 2016-04-19, 20:38:
>> background: on armel and armhf Qt is using OpenGL ES, but my package cgal 
>> does
>> not support OpenGL ES (yet). The OpenGL functionality is only needed for some
>> demos and their support library which are already in separate binary 
>> packages.
>> Therefore I just want to not build the OpenGL-related binary packages on 
>> armel
>> and armhf.
>>
>> But how can I do that? Putting "Architecture: any [!armel !armhf]" in
>> debian/control is not supported:
>>
>> dpkg-source: error: architecture any only allowed on its own (list for 
>> package
>> libcgal-qt5-11 is 'any')
>>
>> Do I really need to expand the architecture list manually?
> 
> I'd avoid it if I could.
> 
> I believe this should work: keep the packages in question as "Architecture: 
> any"
> but tell debhelper to not act on them ("-N cgal-foo") when the host 
> architecture
> is arm*.

Yes, works. Thanks for the suggestion!

  Joachim

Workaround for "Architecture: any [!armel !armhf]" in debian/control

[Joachim Reichel]

Hi,

background: on armel and armhf Qt is using OpenGL ES, but my package cgal does
not support OpenGL ES (yet). The OpenGL functionality is only needed for some
demos and their support library which are already in separate binary packages.
Therefore I just want to not build the OpenGL-related binary packages on armel
and armhf.

But how can I do that? Putting "Architecture: any [!armel !armhf]" in
debian/control is not supported:

dpkg-source: error: architecture any only allowed on its own (list for package
libcgal-qt5-11 is 'any')

Do I really need to expand the architecture list manually? Why is it supported
in Build-Depends etc., but not in Architecture?

Joachim

Re: Please help creating shared *and* static library with cmake

[Joachim Reichel]

Hi,

On 04/08/2016 05:30 PM, Andreas Tille wrote:
> I need to package libsdsl[1] as some precondition for a Debian Med
> package.  The default cmake build only creates a static library and I
> found a patch to create a shared library.  But since library packages
> should include both I wonder how to get both shared and static library
> without doing to much tricky things.

in the "cgal" package I basically build the package twice:

override_dh_auto_configure-arch:
mkdir -p static
cd static && cmake .. -DBUILD_SHARED_LIBS=FALSE
mkdir -p shared
cd shared && cmake .. -DBUILD_SHARED_LIBS=TRUE -DCMAKE_SKIP_RPATH=TRUE

override_dh_auto_build-arch:
$(MAKE) $(NJOBS) -C static
$(MAKE) $(NJOBS) -C shared

override_dh_install-arch:
$(MAKE) -C static DESTDIR=$(CURDIR)/debian/tmp install
$(MAKE) -C shared DESTDIR=$(CURDIR)/debian/tmp install

Not sure what you mean with "found a patch to create a shared library". Are you
saying that your project files do not support -DBUILD_SHARED_LIBS?

Joachim

Re: automatic dependency generation for << ${source:Next-Upstream-Version}

[Joachim Reichel]

Hi,

On 01/28/2012 08:03 PM, Alessio Treglia wrote:
> On Sat, Jan 28, 2012 at 7:33 PM, Joachim Reichel  
> wrote:
>> to one of my binary packages I want to add a dependency like
>> Depends: foo (>= ${source:Upstream-Version}), foo (<<
>> ${source:Next-Upstream-Version})
> 
> I usually rely on:
> 
>  package (<< ${source:Upstream-Version}+1~),
>  package (>= ${source:Version}),

after sending the mail I was thinking about

package (<< ${source:Upstream-Version}.1)

But + is better than . because it sorts before . (actually + is the
lexicographically smallest character allowed in upstream versions, see
policy 5.6.12).

I wonder about the "1~" though. Isn't

package (<< ${source:Upstream-Version}+)

sufficient (and tighter)? (though it looks a bit weird)

(It's not sufficient if upstream adds a "~", but that's probably
unlikely, and I don't see a way to handle that case.)

Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f245062.2060...@gmx.de

automatic dependency generation for << ${source:Next-Upstream-Version}

[Joachim Reichel]

Hi,

(see #657720 for the background details and rationale)

to one of my binary packages I want to add a dependency like
Depends: foo (>= ${source:Upstream-Version}), foo (<<
${source:Next-Upstream-Version})

The question: how to achieve that given that
${source:Next-Upstream-Version} does not exist (and is not trivial to
compute in general)? I want to avoid hard-coding the next upstream
version because then the package is uninstallable whenever a new
upstream version of foo is uploaded (which is not bad in this specific
context, but it requires a sourceful change for the next upload).

I suppose "foo (= ${source:Upstream-Version})" does not work because it
will never match for non-native packages, right? Is there something like
"foo (upstream version of foo = ${source:Upstream-Version})"

I guess this can be implemented using debian/substvars. But I don't want
to reinvent the wheel. I'm probably not the first one with this problem.
Are there any examples how to do that easily?

Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f243f8e.2040...@gmx.de

Re: RFS: cppcheck, new upstream version 1.50

[Joachim Reichel]

Hi,

On 08/31/2011 10:22 PM, Reijo Tomperi wrote:
>  George Danchev wrote:
>> On Monday, August 15, 2011 12:41:29 AM Reijo Tomperi wrote:
> 
>>> http://mentors.debian.net/package/cppcheck
>>>
>>> Alternatively, one can download the package with dget using this
>>> command:
>>>
>>> dget -x
>>> http://mentors.debian.net/debian/pool/main/c/cppcheck/cppcheck_1.50-1.dsc
>>>
> 
>> JFYI, also hinting co-sponsors :)
>> I'll try to have a look in the coming days, unless someone did it
>> before me.
> 
> A couple of weeks has passed. Any progress with this?

uploaded, after a build failure in the first version was fixed.

Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e652d2...@gmx.de

Re: RFS: cppcheck, 1.47-4

[Joachim Reichel]

Hi,

> http://mentors.debian.net/debian/pool/main/c/cppcheck/cppcheck_1.47-4.dsc

uploaded.

  Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d767453.70...@gmx.de

Re: RFS: cppcheck, new upstream version 1.45

[Joachim Reichel]

Hi,

>> New upstream version was released, so I made a new Debian package
> of it.
>
> I'm again looking for a sponsor for it.
 Your package looks fine to me (as far as I have checked). Are you
 aware of the freeze for Debian's squeeze release? Do you want this to
 indeed go to unstable right now? Putting into experimental would be
 another option.
>>> It fixes at least one segfault which occurs with old version (1.44) (No
>>> Debian ticket about it):
>>> http://sourceforge.net/apps/trac/cppcheck/ticket/1944
>>>
>>> There are a lot of other changes (170 closed upstream tickets).
>>>
>>> If it is up to me, I would put this into unstable, but someone with
>>> better knowledge about Debian policy and rules might have other opinion.
>>
>> I guess what Christoph meant is the following: if you upload 1.45 to
>> unstable
>> you block this way for fixes to 1.44 in testing (and the RM will most
>> probably
>> not allow 1.45 to migrate to testing).
> 
> Can this be asked from the RM?

You want to ask the RM whether they would accept 1.45 into testing? You can
contact the release team at debian-rele...@lists.debian.org.

As far as I know their last statement is
http://lists.debian.org/debian-devel-announce/2010/10/msg2.html
which basically says "RC bug fixes only" (the other categories don't seem to
apply here). And I don't see any RC bugs filed against cppcheck.

Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4cb22fa2.7060...@gmx.de

Re: RFS: cppcheck, new upstream version 1.45

[Joachim Reichel]

Hi Reijo,

>> Reijo Tomperi  writes:
>>> New upstream version was released, so I made a new Debian package of it.
>>>
>>> I'm again looking for a sponsor for it.
>>
>> Your package looks fine to me (as far as I have checked). Are you
>> aware of the freeze for Debian's squeeze release? Do you want this to
>> indeed go to unstable right now? Putting into experimental would be
>> another option.
> 
> It fixes at least one segfault which occurs with old version (1.44) (No
> Debian ticket about it):
> http://sourceforge.net/apps/trac/cppcheck/ticket/1944
> 
> There are a lot of other changes (170 closed upstream tickets).
> 
> If it is up to me, I would put this into unstable, but someone with
> better knowledge about Debian policy and rules might have other opinion.

I guess what Christoph meant is the following: if you upload 1.45 to unstable
you block this way for fixes to 1.44 in testing (and the RM will most probably
not allow 1.45 to migrate to testing).

You could upload 1.45 to experimental for now. This allows you to upload
1.44-2, -3, and so on which just fix RC bugs in 1.44-1, upload them to
unstable and request a freeze exception.

Not sure whether the segfault is a RC bug and whether it is easy to backport
the fix. Same for other issues that got closed in 1.45.

Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4cae1a29.9060...@gmx.de

Re: RFS: cppcheck, new upstream version 1.44

[Joachim Reichel]

Hi,

Reijo Tomperi wrote:
> New version with the same number should be uploaded now. Fixed both
> mentioned issues I hope. Not sure why that line was removed. I must have
> pressed a button at a wrong place I assume.

ok, uploaded.

Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c3cab3c.6030...@gmx.de

Re: RFS: cppcheck, new upstream version 1.44

[Joachim Reichel]

Hi,

>> Reijo Tomperi wrote:
>>> I am looking for a sponsor for my package "cppcheck".

Patrick Matthäi wrote:
> Why are you removing old changelog entries?

in addition, you should probably mention that you removed the patch
debian-changes-1.43-3, presumably because it was applied upstream?
Otherwise the package looks good and I would sponsor it again.

Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c3c9847.1070...@gmx.de

Re: RFS: notorious-women

[Joachim Reichel]

Hi Benoît,

> Since last comments, I removed notorious-women package by twice
> package named : fortunes-nortorious-women and
> fortunes-notorious-women-fr according of your advices.
> I add a watch file in debian directory and the original tarball
> contains now some french and english quotes.
> Do you make another RFS request for this new version ?

if these are the only changes then your package still contains a couple of
issues that have been pointed out in previous reviews (including warnings from
lintian). In this state I don't see the point of another review.

Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c1f07d1.8040...@gmx.de

Re: RFS: notorious-women

[Joachim Reichel]

Hi Benoît,

> I am looking for a sponsor for my package "notorious-women".
> 
> * Package name: notorious-women
[...]

since this is the third RFS message for this package and most issues pointed out
in the initial reply haven't been addressed:

When you post repeated RFS messages, can you please tell us

- what you changed/which issues have been fixed
- which issues are still open/known problems
- answer questions/comment suggestions from potential sponsors

Most issues mentioned in
http://lists.debian.org/debian-mentors/2010/06/msg00340.html
have not been fixed nor the questions were answered. See also Paul's mail about
the license problem, and Boyd's mail about the package name.

Just for reference: the only differences to the first RFS in this thread are
- Standards-Version: s/3.8.3/3.8.4/
- ${misc:Depends} added to Depends:
- short description improved
- debian/source/format added (3.0 quilt)

And please do run lintian on the package.

Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c1a8e14.8070...@gmx.de

Re: RFS: notorious-women

[Joachim Reichel]

Hi,

> I am looking for a sponsor for my package "notorious-women".
> 
> * Package name: notorious-women
>   Version : 0.1-1
>   Upstream Author : TUDURI Benoît 
> * URL : http://alioth.debian.org/~bent-guest/notorious-women/
> * License : Creative Commons
> Attribution-NonCommercial-ShareAlike 3.0 Unported
> 
>   Section : games
> 
> It builds these binary packages:
> notorious-women - french famous french women quotes
> 
> My motivation for maintaining this package is: [fill in].
> 
> The package can be found on mentors.debian.net:
> - URL: http://mentors.debian.net/debian/pool/main/n/notorious-women
> - Source repository: deb-src http://mentors.debian.net/debian unstable
> main contrib non-free
> - dget 
> http://mentors.debian.net/debian/pool/main/n/notorious-women/notorious-women_0.1-1.dsc

apart from the license issue mentioned by Paul:

Most of the issues mentioned in
http://lists.debian.org/debian-mentors/2010/06/msg00233.html
are still present in this package:

Why is this a separate package at all? Have you contacted the fortunes-fr
maintainer and asked him to include these quotes? I still think this should not
be a separate package.

If it is going to be maintained as a separate packge: As far as I can see all
fortunes modules start with the prefix "fortunes-". And since the packages
contains French quotes, the name should end up in "-fr".

Lintian output:

I: notorious-women source: debian-watch-file-is-missing
W: notorious-women source: debhelper-but-no-misc-depends notorious-women
W: notorious-women source: out-of-date-standards-version 3.8.3 (current is 
3.8.4)
W: notorious-women: new-package-should-close-itp-bug
W: notorious-women: wrong-bug-number-in-closes l3:#
W: notorious-women: extra-license-file usr/share/doc/notorious-women/COPYING

Please use lintian before posting another RFS request.

debian/changelog: Fill with content.
debian/rules: Please remove the comments that do not apply to/are not needed in
your package.
debian/control: Syntax errors in short/long description.
debian/README.Debian: Useless, it's current content is contained in the long
description. Fill with real content, or remove the file.

Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c19c578.1000...@gmx.de

Re: RFS: femmes-celebres

[Joachim Reichel]

Hi,

I think the quotes should be added to fortunes-fr. A seperate package for  ~100
quotes is IMHO not the right way.

A few comments for the sake of feedback and learning (but as explained above I
will not upload the package if you fix these issues).

> > I am looking for a sponsor for my package "femmes-celebres".
> >
> > * Package name: femmes-celebres

I think all fortunes modules start with "fortunes-". Since the quotes are in
French, a better name would be fortunes-femmes-celebres-fr.

> >   Version : 0.1-1
> >   Upstream Author : TUDURI Benoît
> > * URL : N/A

missing

> > * License : [fill in]

missing

> >   Section : games
> >
> > It builds these binary packages:
> > femmes-celebres - french distinguish french women quotes.

"Distinguished quotes from French women (in French)" ?

> > My motivation for maintaining this package is: To have some women
> > favorite quote. It's a pleasant stuff to learn a quote.

Can you please contact the fortunes-fr maintainer and ask him to include your
quotes?

Moreover, the debian/ directory still contains lots of the template texts,
comments that do not apply for your package, etc. Please clean that up.

Lintian thinks the version is an NMU. Not sure why, maybe because you use
different email adresses in changelog and control.

There are also the following warnings/errors (partly mentioned already above).
Please see the lintian documentation for their meaning.

W: femmes-celebres source: debhelper-but-no-misc-depends femmes-celebres
W: femmes-celebres source: binary-arch-rules-but-pkg-is-arch-indep
W: femmes-celebres source: out-of-date-standards-version 3.8.1 (current is 
3.8.4)
W: femmes-celebres: possible-unindented-list-in-extended-description
E: femmes-celebres: helper-templates-in-copyright
W: femmes-celebres: copyright-has-url-from-dh_make-boilerplate
E: femmes-celebres: copyright-contains-dh_make-todo-boilerplate
W: femmes-celebres: readme-debian-contains-debmake-template
W: femmes-celebres: new-package-should-close-itp-bug
W: femmes-celebres: wrong-bug-number-in-closes l3:#

Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c13b91b.9010...@gmx.de

Re: RFS: cppcheck, new upstream version 1.43

[Joachim Reichel]

Hi,

Reijo Tomperi wrote:
> George Danchev wrote:
>> Joachim Reichel writes:
> 
>>> I checked the package and found no problems. Can't you just remove the
>>> --enable=possibleError option from the manpage (it's not listed in
>>> the -h
>>> output)?
>>>
>>> Then I'll upload the package right away.
> 
> I removed --enable=possibleError, --all and --auto-dealloc. I missed the
> --all from the changelog, I hope that doesn't matter?

not a big deal, but

> These are in version 1.43-3, which was uploaded, but doesn't yet show on
> http://mentors.debian.net/debian/pool/main/c/cppcheck/

I still do not see -3. Are you sure your upload did not fail? If you have to
upload again: why not fixing the small mistake in the changelog? I wouldn't mind
if it was a big packages, but since it is a small package ...

> (After uploading 1.43-2 I noticed that --auto-dealloc should be removed
> also.)

BTW I think it is not necessary to increment the Debian revision for each upload
to m.d.n.

>> halfway 557045, both are low priority and I hesitate to judge they
>> worth the risk upon release [1]. OTOH, to be honest I haven't seen
>> cppcheck 1.42-1 (from unstable and testing) to choke on or to omit any
>> blatant programming error, but perhaps I was just being lucky. I don't
>> mind an upload, I'm just unsure of gain/risk ratio with 1.43.
> 
> Well I can't guarantee that the version is error free, nor can I can
> even guarantee that it is better than the previous version.
> 
> But Cppcheck has 89.7% line coverage in unit tests and the tests cover a
> lot of different situations, so the checking part itself should be quite
> stable.

Among the obvious checks (md5sum of orig.tar.gz, license) I run the unit tests
and tested it on a few of my own programs. I briefly looked at the diff, but of
course, did not check the code for possible programming errors. Since we do not
have any indication that 1.43 is worse, I think it is worth the risk. It is a
leaf package, so we could reupload 1.42 anytime before the release if necessary.

Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4be8f5b9.9080...@gmx.de

Re: RFS: cppcheck, new upstream version 1.43

[Joachim Reichel]

Hi,

> http://mentors.debian.net/debian/pool/main/c/cppcheck/cppcheck_1.43-1.dsc
> 
> 
> Now, a few things worth mentioning:
> - This version is not compatible with previous version, because:
> --enable=possibleError prints out error message with this version
> (possibleError feature is complitely disabled in this version, so to fix
> it one should just remove that option if it is used)
> - Man page (which comes from upstream) is not up-to-date considering the
> above change (I filed a ticket about it to upstream and will probably
> fix it myself for the next release).
> 
> Should this version still be uploaded?

I checked the package and found no problems. Can't you just remove the
--enable=possibleError option from the manpage (it's not listed in the -h 
output)?

Then I'll upload the package right away.

Joachim




-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4be848fb.6060...@gmx.de

Re: RFS: aaphoto

[Joachim Reichel]

Hi Andras,

> I've already changed that in the next upstream version.
> 
> I updated the package on mentors too.
> http://mentors.debian.net/debian/pool/main/a/aaphoto/aaphoto_0.36-1.dsc

everything is fine now. I've uploaded your package.

Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bae4c95.3030...@gmx.de

Re: RFS: aaphoto

[Joachim Reichel]

Hi Andras,

please avoid top-posts (replying above the quoted mail, quoting the
entire mail).

> I changed the standard version in the control file and recreated the
> package in a SID chroot environment.

The standard version is ok now. I noticed that you also converted the
package to 3.0 quilt format. Unfortunately, this caused two more problems:

- Remove debian/README.source: it's not needed in your case and
currently contains only a template.

- debian/copyright: At the very beginning of the file: it seems you did
not modify the template here.

Hint: use debdiff to compare package versions and to avoid unwanted changes.

The debian/watch file does no longer work (you can check with "uscan
--no-download"). Either fix the permissions on your webserver or use
this line:

http://log69.com/aaphoto.html downloads/aaphoto_sources_v(.*)\.tar\.gz

Your versions tries to read the directory "downloads", while my version
parses the HTML page.

> I've uploaded it to mentors again.

For future uploads: please include the URL of the .dsc file in your
mail. That makes it much easier for potential sponsors (using dget).

Another hint for the next upstream version: do not link with -lz. It's
not needed (you are not using zlib directly).

Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4babaee8.8040...@gmx.de

Re: RFS: git-fast-export (hg/svn-to-git import)

[Joachim Reichel]

Hi,

> On Mar 23, 2010, at 5:30 PM, Obey Arthur Liu wrote:
>> I am looking for a sponsor for my package "git-fast-export".
>>
>> * Package name: git-fast-export
>>
>> It builds these binary packages:
>> hg-fast-export - Mercurial fast incremental exporter to Git
>> svn-fast-export - Subversion fast incrementer exporter to Git
> 
>The package name seems to be a bit confusing to me, considering that
> there is already a git-fast-export command available in the git-core
> package...

and reading the description it seems to contain exporters for *other*
VCSs, or the other way round, *importers* for git.

Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ba94969.6050...@gmx.de

Re: RFS: aaphoto

[Joachim Reichel]

Hi Andras,

> I made further changes to the package according to Chris:
> 
> - i opened an ITP bug and closed it with the reference bug id in the
> debian/changelog

Ok

> - i removed the mentioned extra slashes from the debian/copyright file

Ok

> - standards version was out of date, i corrected it in the control file

Not ok. Why is it 3.8.0? The current policy version for sid is 3.8.4.

In case you considered the Debian policy for lenny (3.8.0): Your package
is targeted to sid, and shall conform to the most recent policy for sid
(3.8.4). You also need to build and test your package in a sid
installation, preferably in a sid chroot. To test that your package
builds in a pristine sid environment, you can use pbuilder with a sid
setup. It's not necessary to do that for this upload, since I checked
that for you. But you should do that yourself for the following uploads.

Anyway you need to correct the standard version for this upload (plus
necessary changes required by the new policy).

> - i changed the Architecture tag to 'any' (it was amd64, but it should
> compile on every arch)

Ok

> - i changed the debian/watch file to contain only 2 lines (version and
> source URL)

Ok

> - i cleaned up the debian/copyright file and formatted it properly
> (with 4 spaces before license and authors text too)

Ok

Apart from the standards version the package looks good for upload.

BTW: I cannot no longer resolve your domain log69.com. (I noticed that
the orig.tar.gz changed, but I was not able to verify that it is now
identical to the one on your webpage.)

Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ba943ba.9000...@gmx.de

Re: RFS: aaphoto

[Joachim Reichel]

Hi Andras,

> In some of the previous mail i got this:
> 
>> in addition to the items already mentioned by Chris:
>>
>> - the orig.tar.gz is different from
>> http://log69.com/downloads/aaphoto_sources_v0.36.tar.gz. The
>> orig.tar.gz has to be identical to the upstream one, unless you have
>> good reasons (which I could not spot).
>>
>> - please remove the "*" in the front of some option explanations in
>> the manpage
>>
>> - debian/rules: please remove the commented commands that do not
>> apply to your package
> 
> I think i changed all the above. I used now the upstream tgz for the
> package. I also removed the '*' chars from the manual, and removed the
> commented commands too (# dh_anything) from rules file.
> 
> Could you be so kind to provide me more info about the things that i'm
> missing here. It must be my misunderstanding probably if i didn't do
> what you meant.
> 
> Or can it be that my upload didn't overwrite the former version? I
> simply run 'dpu mentors *.changes' once i corrected the things.

I've noticed the new orig tgz, the removed * in the manpage, and the
removed comments in debian/rules. I did not find any changes related to
the issues mentioned by Chris in
http://lists.debian.org/debian-mentors/2010/03/msg00226.html

Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ba7cbd5.6020...@gmx.de

Re: RFS: aaphoto

[Joachim Reichel]

Hi

> I've made the following changes:
> [...]
> I have uploaded the aaphoto package to mentors.

as far as I can see your upload to mentors.d.n from yesterday evening
does not address any of the issues pointed out by Chris.

Best regards,
  Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ba7c4b3.8060...@gmx.de

Re: RFS: aaphoto

[Joachim Reichel]

Hi Horvath,

> I've made the following changes:
> - the orig.tar.gz is the same now as the upstream version
> - i removed the '*' chars from everywhere in manual and in sources too
> (only next release)
> - i removed the commented commands from debian/rules
> - i renamed REMARKS file to EXTRA_DIST (only next release)

I think this was a misunderstanding. I did not want you to rename
REMARKS to EXTRA_DIST. If you use "make dist" to generate a tarball that
contains all relevant files you have to include additional text files
and other stuff that is not known to automake in an EXTRA_DIST rule,
otherwise they are missing in the generated tarball.

> - i made sure that included generated files are removed (could you
> please check that? i removed these: autom4te.cache, config.guess,
> config.status, config.sub, config.log, stamp-h1, config.h, build-stamp)
> - i edited README everywhere to be within 80 chars width (only next
> release, i'm sill working on NEWS and ChangeLog)
> 
> I have uploaded the aaphoto package to mentors.

Ok, I'll check the package tomorrow.

  Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ba6b12f.20...@gmx.de

Re: RFS: aaphoto

[Joachim Reichel]

Hi,

> Thank You for the help and the suggestions. I appreciate it.
> 
> I can fix the things mentioned below.
> 
> The orig.tar.gz differs in the hash only because i recompressed it
> before making the debian package from it. So it was my mistake that i
> didn't copy the upstream tgz file instead.
> 
> What to do about the '*' character in the manual at the options? I use
> it for marking which option needs input file. Should i use a different
> character?

I simply missed the explanation of the meaning of "*". So please ignore
this. I've never seen in other man pages, though.

> I will remove the included generated files from the next version then
> (0.37), thanks for mentioning.
> 
> I think i won't include REMARKS in the next version either, it's not
> necessary. I make it available for download in another tgz version
> anyway.
> 
> Should i change NEWS, ChangeLog and README to 80 char width now in the
> fixed debian package?

This is not a technical requirement for the Debian package, just a
general comment about the software itself (because you are also the
upstream author). I would change it in the next upstream version.

> About the original compression quality. I was planning the make a
> comment on my site about this why i didn't implement it yet. Regarding
> the research i made on JPEG format, AFAIK the image that is
> recompressed with the same quality will have worse quality after the
> recompression,

Are you sure? I'm not an export on JPEG at all, but from what I know
about the general principle I would expect that certain transformation
do not incur a (or only a very small) quality loss when recompressed
with the same quality setting, e.g., brightness/contrast adjustments.

> so we can say that we have to use higher value for
> recompression than originally to get the same image quality, and this is
> not so trivial. Therefore i made a 95% default according to the balance
> between quality and size, and the user can change it on demand. Anyway
> if someone needs to have an image without quality loss, then there is
> the option to use PNG instead. If he sticks with JPEG, then i think the
> default value is a good choice.

The point why I mentioned the compression quality: I tested your
software on a few of my pictures. While the contrast etc. of a few bad
pictures has been clearly improved, the size of all files is now roughly
twice the old size (even if there is no visible difference). I assumed
that this is due to the fixed compression quality, but maybe there is a
different reason.

A special value "auto" or "same" for --quality would be quite handy to
maintain (almost) the same quality without increased file size and/or
manually adjusting the --quality value.

This discussion is a bit off-topic for d-mentors. So I suggest to
continue the discussion offline.

Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ba634cc.7020...@gmx.de

Re: RFS: aaphoto

[Joachim Reichel]

Hi Horvath,

in addition to the items already mentioned by Chris:

- the orig.tar.gz is different from
http://log69.com/downloads/aaphoto_sources_v0.36.tar.gz. The orig.tar.gz
has to be identical to the upstream one, unless you have good reasons
(which I could not spot).

- please remove the "*" in the front of some option explanations in the
manpage

- debian/rules: please remove the commented commands that do not apply
to your package

I'm interested in sponsoring this package if you fix these issues (and
the ones mentioned by Chris).

Since you are also the upstream author:

- Please make sure in the next version not to include generated files,
e.g., config.status or autom4te.cache. This should also make the package
significantly smaller. Hint: "make dist" and "make distcheck" are your
friend. Use EXTRA_DIST for files like REMARKS.

- NEWS, ChangeLog, and README would be much better readable if formatted
to a page width of 80 or less characters

- The feature I miss most is maintaining the original jpeg compression
quality.

Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ba611a8.9030...@gmx.de

Re: RFS: vera++

[Joachim Reichel]

Hi Mathieu,

>> Unfortunately, you changed the original tarball locally (size 52320)
>> compared to revision -1 (size 53263), but did not upload it (because the
>> Debian revision is -2, and you did not pass -sa to dpkg-buildpackage).
>> And mentors.d.o still has the old tarball.
>>
>> $ dpkg-source -x vera++_1.1.1-2.dsc
>> dpkg-source: error: File ./vera++_1.1.1.orig.tar.gz has size 53263
>> instead of expected 52320
>>
>> Before simply using -sa please check why the original tarball changed.
> 
> I used dget to get the original src and reuploaded version -2. I have
> absolutely no idea what could have happen.
> 
> I believe this should works now:
> 
> $ dget http://mentors.debian.net/debian/pool/main/v/vera++/vera++_1.1.1-2.dsc
> $ dpkg-source -x vera++_1.1.1-2.dsc
> dpkg-source: extracting vera++ in vera++-1.1.1
> dpkg-source: info: unpacking vera++_1.1.1.orig.tar.gz
> dpkg-source: info: applying vera++_1.1.1-2.diff.gz

yes, works. Sorry for the delay, I missed your last mail.

- While you fixed the lintian warnings I mentioned in the first review,
there are new warnings that should get fixed:

I: vera++ source: debian-watch-file-is-missing
W: vera++ source: out-of-date-standards-version 3.8.2 (current is 3.8.3)
I: vera++: possible-documentation-but-no-doc-base-registration

- It is very inconvenient to use the program, even with the default
rules. The examples given in the man page do not work in the form they
are given there: You have to set VERA_ROOT or copy the rules to
~/.vera++ or the current directory. It would be nice if the program
would as last possibility check a predefined location where the default
rules get installed (see also (*) below). You should talk with upstream
about this. Maybe you can patch the program to do that.
(This is not a blocker for an upload, but improving the manpage
accordingly is).

These issues are still open:

- debian/copyright: You should mention the GPL version for the Debian
packaging (and adjust the link if necesary).

- manpage: Please fix the layout of the OPTIONS section (have a look at
other manpages). Please change the synopsis section to describe the
basic invocation syntax (see other manpages). The man page should
mention the location of the example scripts (maybe in the examples
section, a demonstration how to set VERA_ROOT to use the provided rules).

Best regards,
  Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: vera++

[Joachim Reichel]

Hi,

Mathieu Malaterre wrote:
> I made a new upload which I believe fixes all of the above. Thanks again.
> 
> $ dupload -t mentors ../vera++_1.1.1-2_amd64.changes
> dupload note: no announcement will be sent.
> Checking signatures before upload..signatures are ok
> Uploading (ftp) to mentors.debian.net:/
> [ job vera++_1.1.1-2_amd64 from vera++_1.1.1-2_amd64.changes
>  vera++_1.1.1-2_amd64.deb, size ok, md5sum ok, sha1sum ok, sha256sum ok
>  vera++_1.1.1-2.dsc, size ok, md5sum ok, sha1sum ok, sha256sum ok
>  vera++_1.1.1-2.diff.gz, size ok, md5sum ok, sha1sum ok, sha256sum ok
>  vera++_1.1.1-2_amd64.changes ok ]
> Uploading (ftp) to mentors (mentors.debian.net)
> + FTP passive mode selected
> [ Uploading job vera++_1.1.1-2_amd64
>  vera++_1.1.1-2_amd64.deb 111.4 kB, ok (2 s, 55.70 kB/s)
>  vera++_1.1.1-2.dsc 1.2 kB, ok (0 s, 1.16 kB/s)
>  vera++_1.1.1-2.diff.gz 6.3 kB, ok (2 s, 3.14 kB/s)
>  vera++_1.1.1-2_amd64.changes 1.5 kB, ok (1 s, 1.47 kB/s) ]

we don't need the information above. Instead please include the URL of
the .dsc file in future requests.

Unfortunately, you changed the original tarball locally (size 52320)
compared to revision -1 (size 53263), but did not upload it (because the
Debian revision is -2, and you did not pass -sa to dpkg-buildpackage).
And mentors.d.o still has the old tarball.

$ dpkg-source -x vera++_1.1.1-2.dsc
dpkg-source: error: File ./vera++_1.1.1.orig.tar.gz has size 53263
instead of expected 52320

Before simply using -sa please check why the original tarball changed.

Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: vera++

[Joachim Reichel]

Hi Mathieu,

>> I am looking for a sponsor for my package "vera++".
> 
> I might be interested in sponsoring this package. I'll have a closer
> look at the weekend.

I found a couple of issues in your package:

- Your package does not build in an up-to-date pbuilder sid environment.
Please test your package with pbuilder.

- There are a couple of lintian messaged (info level). Although not
warnings or errors it would be nice to fix them:

I: vera++ source: quilt-patch-missing-description vera.patch
I: vera++: hyphen-used-as-minus-sign usr/share/man/man1/vera++.1.gz:51
(and many more)
I: vera++: package-contains-empty-directory usr/sbin/
I: vera++: copyright-with-old-dh-make-debian-copyright

- The package contains a copy of cpptcl 1.1.4 from the same author (see
the list archives for discussions about embedded copies of other
libraries). Since cpptcl is not yet packaged for Debian I would accept
this for now (in particular since this version 1.1.4 does not seem to be
available from the project page yet).

- debian/copyright: You should mention the GPL version for the Debian
packaging (and adjust the link if necesary).

- debian/watch: Does not work (use uscan to test).

- debian/dirs: Remove /usr/sbin.

- debian/README.Debian: Not really necessary since it just describes
standard modifications to the build process (in contrast to reasons for
repackaging the source for example). On the other hand, it does not hurt.

- debian/changelog, README.Debian: Please update the date (dch -a).

- debian/rules: Please remove the dummy comments and commented lines.

- manpage: The first five occurrences of VERA++ refer directly to the
executable and should be in all-lowercase. Please fix the layout of the
OPTIONS section (have a look at other manpages). Please change the
synopsis section to describe the basic invocation syntax (see other
manpages). The man page should mention the location of the example scripts.

- /usr/share/doc/vera++: Do not install README.Debian (useless for the
binary package) and LICENSE_1_0.txt (contained in copyright).


Cheers,
  Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: vera++

[Joachim Reichel]

Hi Mathieu,

> I am looking for a sponsor for my package "vera++".

I might be interested in sponsoring this package. I'll have a closer
look at the weekend.

Cheers,
  Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: ecm -- prepares CD image files so they compress better

[Joachim Reichel]

Hi,

>> I am looking for a sponsor for my package "ecm"
>>
>> * Package name: ecm
>>   Version : 1.00
>>   Upstream Author :  Neill Corlett 
>> * URL : http://www.neillcorlett.com/ecm/
>> * License : GPL2+
>>   Programming Lang: C
>>   Description : prepares CD image files so they compress better
> 
> I had a quick look at your package and did not find a problem, though I
> would have to give it a closer look before upload.
> 
> Unfortunately, ecm seems to have a problem with files larger than 2 or 4
> GB (I tried the 1st Debian Lenny DVD). I ended up with a file of size
> 381 MB :-((. I'm aware that ecm does not claim to handle DVD images, but
> it also does not refuse to handle them. I consider this a grave bug
> (data loss).
> 
> I did another test with the first Debian Etch CD. ecm reduced the size
> of the image by 0.03%. Compressing the original ISO and the ecm-prepared
> version with bzip2 gave a 0.097% advantage for the ecm-prepared version.
> Do you have any number where ecm shows a reasonable gain?

Ruben Molina kindly pointed out to me that my test setup was flawed. ecm
should be applied to RAW files, not to ISO files. Another test with a
RAW image gave a similar improvement to what is reported on the ecm
homepage (~15% after compression).

Loic: I'm happy to sponsor this upload if you can get the data loss bug
fixed. There might be some small changes to the packaging needed, but
I'm confident that these can be easily sorted out.

Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: ecm -- prepares CD image files so they compress better

[Joachim Reichel]

Hi Loïc,

> I am looking for a sponsor for my package "ecm"
> 
> * Package name: ecm
>   Version : 1.00
>   Upstream Author :  Neill Corlett 
> * URL : http://www.neillcorlett.com/ecm/
> * License : GPL2+
>   Programming Lang: C
>   Description : prepares CD image files so they compress better

I had a quick look at your package and did not find a problem, though I
would have to give it a closer look before upload.

Unfortunately, ecm seems to have a problem with files larger than 2 or 4
GB (I tried the 1st Debian Lenny DVD). I ended up with a file of size
381 MB :-((. I'm aware that ecm does not claim to handle DVD images, but
it also does not refuse to handle them. I consider this a grave bug
(data loss).

I did another test with the first Debian Etch CD. ecm reduced the size
of the image by 0.03%. Compressing the original ISO and the ecm-prepared
version with bzip2 gave a 0.097% advantage for the ecm-prepared version.
Do you have any number where ecm shows a reasonable gain?

Don't most CDs/DVDs contain data (software, music, video) that is
already compressed in one way or another? Therefore I would guess that
removing some very small amount of hard-to-compress data doesn't improve
the overall situation.

For these reasons I'm currently inclined not to sponsor this package.
Also, ecm-prepared/compressed images don't seem to be widespread as far
as I can say (and the software is 7 years old).

Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

cgal build failure on alpha and hppa

[Joachim Reichel]

Hi,

building the recently uploaded version 3.4-3 of cgal fails on alpha and
hppa with

The following packages have unmet dependencies:
  libqt3-mt-dev:
Depends: libgl1-mesa-dev but it is not going to be installed or
 libgl-dev
Depends: libglu1-mesa-dev but it is not going to be installed or
 libglu-dev
  libqt4-opengl-dev:
Depends: libgl1-mesa-dev but it is not going to be installed or
 libgl-dev
Depends: libglu1-mesa-dev but it is not going to be installed or
 libglu-dev

http://experimental.debian.net/fetch.php?&pkg=cgal&ver=3.4-3&arch=alpha&stamp=1240105463&file=log&as=raw
http://experimental.debian.net/fetch.php?&pkg=cgal&ver=3.4-3&arch=hppa&stamp=1240078855&file=log&as=raw

I understand that libgl1-mesa-glx and libglu1-mesa are not available on
hppa in the required versions (>= 7.4). But what is the problem on alpha?

How can I debug such problems (for architectures where I don't have root
access, so I can't just use aptitude)? Browsing packages.d.o is not that
convenient for more complicated dependencies.

Kind regards,
  Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFH:outguess.

[Joachim Reichel]

Hi,

> I have problems to know what I must do to adopt the package outguess:
> I read the new maintainer's guide, but here it is described how to package
> from scratch ( I mean the soft was not package first ).
> I guess I shouldn't exactly process as in this guide ( as the soft was
> already a package in debian ).
> 
> I did those things :
> First update changelog with dch -i,
> then try to conforms with 3.8.0 version.
> rebuild , check lintian warning and correct it.

in principle, that's the right way.

But since the last non-QA upload was in 2002 it might be worth re-packaging the
package from scratch. But take into account the modifications in the current
package, and make sure not to loose them if they are needed/required.

> It seems not to be the right way,

Why do you think that?

> then where I can find an explanation to
> how
> adopt a package correctly.

Have a look at the developer's reference and the policy.

HTH,
  Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS:outguess

[Joachim Reichel]

Hi,

> Package Name: outguess
> Version : 1:0.2-7
> Licence: GPL
> Description:OutGuess is a universal steganographic tool that allows the

I didn't do a thorough review, just a few general comments:

- Is http://www.outguess.org/ the current homepage? (the Homepage: field is
missing in the description)
- Why do you package 0.2 instead of 0.6?
- There was no upstream release since 2004. I wonder whether there are similar
software packages, which are still maintained upstream.
- The meta information in the dsc file does not match the tarball (file size).
- The orig tarball does not match the upstream orig tarball. Why?
- There is no README.souce, your package does *not* conform to policy version 
3.8.0.
- The license is not GPL (at least not all files).
- Your package does not build:

make[1]: Entering directory `/tmp/outguess-0.2.orig'
make[1]: *** No rule to make target `distclean'.
make[1]: Leaving directory `/tmp/outguess-0.2.orig'

Joachim


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

RFS: zimpl (updated package, 2nd try)

[Joachim Reichel]

Dear mentors,

I am looking for a sponsor for the new version 2.07.ds1-1 of my package
"zimpl".

It builds these binary packages:
zimpl  - mathematical modeling language for optimization problems

The package is lintian and linda clean and builds fine with pbuilder.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/z/zimpl
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/z/zimpl/zimpl_2.07.ds1-1.dsc

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

Kind regards
 Joachim Reichel


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

RFS: zimpl (updated package)

[Joachim Reichel]

Dear mentors,

I am looking for a sponsor for the new version 2.07.ds1-1 of my package
"zimpl". Usually, Anibal Monsalve Salazar sponsors the package, but I
haven't got a reply for a few days, so I assume he is busy right now.

It builds these binary packages:
zimpl  - mathematical modeling language for optimization problems

The package is lintian and linda clean and builds fine with pbuilder.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/z/zimpl
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/z/zimpl/zimpl_2.07.ds1-1.dsc

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

Kind regards
 Joachim Reichel


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

Re: RFS: zimpl (updated package)

[Joachim Reichel]

Hi,

> I am looking for a sponsor for the new version 2.07.ds1-1
> of my package "zimpl". Usually, Anibal Monsalve Salazar sponsors the
> package, but I haven't got a reply for a few days, so I assume he is
> busy right now.

meanwhile Anibal replied that he'll review the package, so I withdraw my
request.

Regards,
  Joachim


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

RFS: zimpl (updated package)

[Joachim Reichel]

Dear mentors,

I am looking for a sponsor for the new version 2.07.ds1-1
of my package "zimpl". Usually, Anibal Monsalve Salazar sponsors the
package, but I haven't got a reply for a few days, so I assume he is
busy right now.

It builds these binary packages:
zimpl  - mathematical modeling language for optimization problems

The package is lintian and linda clean and builds fine with pbuilder.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/z/zimpl
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/z/zimpl/zimpl_2.07.ds1-1.dsc

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

Kind regards
 Joachim Reichel


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

Re: RFS: normalize-audio (updated package)

[Joachim Reichel]

Hi Kevin,

> You need to complete the debian/copyright a little more as it does
> not even reference GPL v2, which it is. See the package tnef for an
> example. A good habit is to run
> 
> licensecheck -r .
> 
> from the working directory on every package you work on.

I fixed the copyright file.

> A bit picky on my part, but remove the:
> 
> ## All lines beginning with `## DP:' are a description of the patch.
> 
> line in debian/patches/*.dpatch files. It just takes up space. You
> might also consider slightly more verbose descriptions in each patch
> just to make it easier on yourself (or the next maintainer) a few
> years from now. Also, make sure to pass on the patches to upstream.

I removed that comment and added proper descriptions. Upstream is aware
of all patches.

> Other than that, looking O.K. although I'm unable to build it right
> now because pbuilder can't seem to pull down the packages:
> 
> libvorbis0a
> libvorbisenc2
> libvorbisfile3
> 
> from the ftp.us.debian.org archives. I'll try again in a little bit.

IIRC there have been various problem reports with ftp.us.d.o from time
to time. You might want to try a different mirror.

An updated package is at
http://mentors.debian.net/debian/pool/main/n/normalize-audio/normalize-audio_0.7.7-2.dsc

Thanks,
  Joachim


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

Re: RFS: normalize-audio (updated package)

[Joachim Reichel]

Hi Kevin,


>>> I am looking for a sponsor for the new version 0.7.7-2
>>> of my package "normalize-audio".

>> I haven't checked this in detail but a quick look shows additional
>> build-dependencies:
>>  Build-Depends: debhelper (>= 5), dpatch, autotools-dev,
>>libaudiofile-dev, libmad0-dev, mpg321, vorbis-tools, flac
>>
>> as compared with:
>>  Build-Depends: debhelper (>= 5), autotools-dev,
>>libaudiofile-dev, libmad0-dev, vorbis-tools
> 
> I think you do need dpatch though ...

Did you confuse both stanzas? Kapil listed them in reverse order: I
*added* the dpatch dependency.

> Separately, in the control file, is it still necessary to keep:
> 
> Replaces: normalize
> Conflicts: normalize
> 
> since normalize was removed from unstable back in Jan. 2005? I guess
> it is possible that a system was built back in 2004, or off of an
> old install disk, and that that system had normalize installed and
> is still using it. Just wondering how long it makes sense to keep
> Conflicts/Replaces statements for packages no longer in the
> archives

Good point. Since they are not a large burden, it prefer to keep them
for now -- unless someone has a good point to drop them. Is there a
general consensus? I couldn't find anything in the docs.

Regards,
   Joachim


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

Re: RFS: normalize-audio (updated package)

[Joachim Reichel]

Hi,

>> I am looking for a sponsor for the new version 0.7.7-2
>> of my package "normalize-audio".
> 
> I haven't checked this in detail but a quick look shows additional
> build-dependencies:
>   Build-Depends: debhelper (>= 5), dpatch, autotools-dev,
> libaudiofile-dev, libmad0-dev, mpg321, vorbis-tools, flac
> 
> as compared with:
>   Build-Depends: debhelper (>= 5), autotools-dev,
> libaudiofile-dev, libmad0-dev, vorbis-tools
> 
> As far as I could see the build does not depend on mpg321,
> vorbis-tools or flac as no audio files are being converted during the
> build.

the reason for the Build-Depends is the configure script. If these
packages are not present at build time, the configure script does not
generate the default settings needed to call these tools. You can still
supply the necessary command line arguments for the enconder/decoder on
the command line, but it is quite convenient to have working defaults.

Joachim


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

RFS: normalize-audio (updated package)

[Joachim Reichel]

Dear mentors,

I am looking for a sponsor for the new version 0.7.7-2
of my package "normalize-audio".

It builds these binary packages:
normalize-audio - adjusts the volume of WAV, MP3 and OGG files to a
standard volume

The package is lintian and linda clean and works with pbuilder.

The upload would fix these bugs: 336808, 337396, 406511

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/n/normalize-audio
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/n/normalize-audio/normalize-audio_0.7.7-2.dsc

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

Kind regards
 Joachim Reichel


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

Re: debian/control - Build-Depends vs. Build-Depends-Indep for newbies (+solution)

[Joachim Reichel]

Hi,

> I had the idea to finally separate the build-dependencies between
> Build-Depends and Build-Depends-Indep in debian/control.  The criterion is the
> following: put in Build-Depends all those packages that are absolutely
> necessary to build architecture-dependent files (e.g. you compile a few .c
> files into executable binaries).  The rest goes into Build-Depends-Indep.

the last time I tried this I did not work because sbuild used on the
autobuilders did not confirm to policy (has this changed?). See the
thread starting at
http://lists.debian.org/debian-mentors/2006/12/msg00252.html

> Go back to your cowbuilder login, cd to root/ and run "dpkg-source -x
> foo.dsc".  Then do an "apt-get install" for all the packages in 
> Build-Dependent.
> 
> Now here's the part that I forgot: debian/rules usually has a binary-arch and
> binary-indep target.  Run "debian/rules clean binary-arch" and now you can
> check whether the package will also run fine on a Debian autobuilder.

The problem is that sbuild invokes the build target (which also depends
on build-indep), but does not pay attention to Build-Depends-Indep.

Regards,
  Joachim


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

RFS: cgal (updated package)

[Joachim Reichel]

Dear mentors,

usually Steve M. Robbins sponsors this package, but he is probably busy
right now, so I am looking for another sponsor for the new version 3.3-1
of my package "cgal".

It builds these binary packages:
libcgal-demo - C++ library for computational geometry (demos)
libcgal-dev - C++ library for computational geometry (development files)
libcgal2   - C++ library for computational geometry

The package is lintian and linda clean and builds fine with pbuilder.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/non-free/c/cgal
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget http://mentors.debian.net/debian/pool/non-free/c/cgal/cgal_3.3-1.dsc

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

BTW I will on vacation starting Thursday, so I won't be able to answer
mails for some time (but I don't expect any problems with the package).

Kind regards,
 Joachim Reichel

-- 
"It is better to have loved and lost than never to have loved at all."
  (Samuel Butler, 1835 - 1902)


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

RFS: smpeg 0.4.5+cvs20030824-1.10 (NMU)

[Joachim Reichel]

Hi,

I'm looking for a sponsor for my NMU -1.10 of smpeg. This NMU fixes a
quoting problem in a m4 file. While at it, I also fixed two types in the
manpages. The maintainer supports this NMU. The NMU can be found at
http://www.joachim-reichel.de/debian/pool/main/s/smpeg/smpeg_0.4.5+cvs20030824-1.10.dsc

+smpeg (0.4.5+cvs20030824-1.10) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Fix quoting problem in smpeg.m4 (Closes: #310636, #418292).
+  * Fix typos in gtv.1 and plaympeg.1 (Closes: #302664, #350354).
+
+ -- Joachim Reichel <[EMAIL PROTECTED]>  Thu, 17 May 2007 09:54:52
+0200

Kind regards,
  Joachim


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

RFS: core++

[Joachim Reichel]

Hi,

I'm looking for a sponsor for the recent revision of my core++ package:

dget http://www.joachim-reichel.de/debian/sid/core++_1.7-7.dsc

Usually, Steve M. Robbins sponsors this package, but he seems to be busy
these days. So I'd welcome if someone else would upload this revision.
The package takes about 30 minutes to build (extensive testsuite).

Thanks,
  Joachim


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

Re: Build-Depends-Indep and build target

[Joachim Reichel]

Hi,

> The underlying problem is that build-arch/indep are not mandatory and
> thus building must call the "build" target.

Any chance that this will be changed for lenny? If build-arch and
build-indep are optional and there is no reliable way to find out
whether these targets exist, what's the use? The logic behind it looks
flawed to me (in particular in combination with Build-Depends-Indep).

> If build-indep does take a considerable time then you can use the
> following hack:
[...]

Which is basically the same as moving the build-indep stuff to
binary-indep, and the build-arch stuff to build. Not nice, but maybe
worth the effort if build-indep takes much time.

On the other side, policy says that build should depend on build-arch
and build-indep (ok, just a "should" not a "must").

Regards,
  Joachim


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

Build-Depends-Indep and build target

[Joachim Reichel]

Hi,

section 7.6 of the policy states that Build-Depends-Indep must be
satisfied if the build target is invoked. Consider the log file of
core++ on ia64:

http://experimental.debian.net/fetch.php?&pkg=core%2B%2B&ver=1.7-6&arch=ia64&stamp=1165413626&file=log&as=raw

The build target is invoked, but Build-Depends-Indep is not satisfied
(at the beginning you can see that the dependencies are not checked),
and the build fails when invoking latex (at the very end).

Why does the autobuilder not respect the Build-Depends-Indep when
invoking build?

At first, I did not realize that the autobuilder does not conform to
policy, so I prepared a new revision of the package, splitting the build
target into build-arch and build-indep. build depends on build-arch and
build-indep. binary-arch depends on build-arch.

"fakeroot debian/rules binary-arch" works as expected.

"dpkg-buildpackage -rfakeroot -B" unfortunately invokes the build target
(instead of build-arch), which also invokes build-indep, but still it works.

Now, if my sponsor uploads this package, it will still fail, right? If
Build-Depends-Indep is not satisfied by accident, the build will fail
again ...

So what should I do?

Regards,
  Joachim


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

Re: RFC: AKFQuiz

[Joachim Reichel]

Hi,

James Westby wrote:
> There is a cleaner method of handling them though that some packages
> use, where the files are updated as required, but they do not appear in
> the diff.

can you explain the procedure in a few words, or give a package as
reference?

Thanks,
  Joachim


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

RFS: zimpl -- mathematical modeling language for optimization problems

[Joachim Reichel]

Hi,

I'm looking for a sponsor for zimpl, a mathematical modeling language for
optimization problems.

RFP/ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=365073


* Package name: zimpl
  Version : 2.04
  Upstream Author : Thorsten Koch 
* URL : http://www.zib.de/koch/zimpl/
* License : GPL
  Programming Lang: C
  Description : mathematical modeling language for optimization problems

 Zimpl allows the specification of certain optimization problems - linear
 programs (LPs) and mixed integer programs (MIPs) - in a high-level
 description language. These descriptions can be converted into the
 LP or MPS file formats which are understood by LP and MIP solvers.
 .
 Homepage: http://www.zib.de/koch/zimpl/


The package is linda and lintian clean and was build with pbuilder. The package 
is
available at http://www.joachim-reichel.de/debian/sid/

Thanks,
  Joachim


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

RFS: cgal 3.2 (Computational Geometry Algorithms Library)

[Joachim Reichel]

Hi,

I'm looking for a sponsor for the CGAL 3.2 package (ITP #251885). CGAL is a
C++ library providing data structures and algorithms for computational
geometry (e.g., convex hull, triangulation, smalles enclosing circle,
multidimensional query structures). CGAL depends on GMP, MPFR, Boost, Qt and
CORE (the last one is also maintained by me).

CGAL 3.2 was released two days ago. This release fixes all license problems
that prevented earlier versions from entering the archive (see summary at the
end of the ITP).

The packages were built with pbuilder and are lintian/linda-clean (except for
one bogus linda warning). The packages are available at
http://www.joachim-reichel.de/debian/sid/

Thanks,
  Joachim


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