Hi,

On Sat, September 12, 2009 08:26, Christian Perrier wrote:
> Quoting Christian Perrier (bubu...@debian.org):
>
>> I succeeded in building the package. So, I can fix the FTBFS as well
>> as l10n stuff (that first bringed me on the package) as well.
>>
>> While building the package, I noticed a lintian warning about binary
>> packages not having "${misc:Depends} listed in their dependencies
>> while the package uses dh_ commands that might trigger extra
>> dependencies. That lintian warning is fairly recent and the fix is
>> trivial and does not hurt. Would you agree for me to fix this as well?
>>
>> There are othere lintian warnings which could deserve some fixes as
>> well but I first wanted to get your input about this one. It is
>> generally discouraged to do such fixes in NMU's, particularly when the
>> maintainer is unresponsive...but, here you *are* responsive..:-)
>>
>> Another item is the debhelper compatibility level (debian/compat). I
>> think it could safely be raised to 7 (with a few side adaptations such
>> as Build-Depends on "debhelper > 7") which is the common practice
>> nowadays.
>
>
> Here's the patch I come up with. Without objection, I'd like to upload
> in the upcoming week.

I say go ahead, thanks.

> Relevant changelog:
>
> root-system (5.18.00-2.4) unstable; urgency=low
>
>   * Non-maintainer upload with maintainer's agreement
>   * Fix build failure caused by the use of a no longer exported
>     function from krb5 library. Thansk to Jurij Smakov for the
>     patch. Closes: #529998
>   * Trivial lintian fixes:
>     - Add ${misc:Depends] to binary packages dependencies as the
>       package uses debhelper
>     - Drop dh_desktop calls in debian/rules (does nothing)
>   * Raise debhelper compatibility level to 7:
>     - Change debian/compat
>     - Raise Build-Depends on debhelper
>     - drop dh_clean -k calls in favor of dh_prep
>   * libroot-roofit5.18: not only list root-fitter (virtual package
>     in Depends but provide libroot-minuit as alternative.
>     This is the virtual-package-depends-without-real-package-depends
>     lintian warning.
>   * Debconf templates and debian/control reviewed by the debian-l10n-
>     english team as part of the Smith review project. Closes: #514827
>   * [Debconf translation updates]
>     - Galician. Closes: #515481
>     - Vietnamese. Closes: #515596
>     - Swedish. Closes: #515939
>     - Basque. Closes: #516013
>     - Italian. Closes: #516445
>     - Spanish. Closes: #517177
>     - Portuguese. Closes: #517185
>     - German. Closes: #517381
>     - Russian. Closes: #517492
>     - Czech. Closes: #517536
>     - Finnish. Closes: #518187
>     - French. Closes: #517806
>     - Japanese. Closes: #546187
>
>
> As you see, there are several lintian warnings that get fixed by this
> patch.

OK, good.

> Some are remaining, but I can't decently fix them as that would be too
> invasive:
>
> W: root-system source: out-of-date-standards-version 3.7.3 (current is
> 3.8.3)
> N:
> N:    The source package refers to a Standards-Version older than the one
> that
> N:    was current at the time the package was created (according to the
> N:    timestamp of the latest debian/changelog entry). Please consider
> N:    updating the package to current Policy and setting this control
> field
> N:    appropriately.
> N:
> N:    If the package is already compliant with the current standards, you
> N:    don't have to re-upload the package just to adjust the
> Standards-Version
> N:    control field. However, please remember to update this field next
> time
> N:    you upload the package.
> N:
> N:    See /usr/share/doc/debian-policy/upgrading-checklist.txt.gz in the
> N:    debian-policy package for a summary of changes in newer versions of
> N:    Policy.
> N:
> N:    Severity: normal, Certainty: certain

I think the standards version can be upgraded without problems, but lets
leave this for another time (next upstream release).

> W: root-system source: outdated-autotools-helper-file
> asimage/src/libAfterImage/config.guess 2005-02-10
> N:
> N:    The referenced file has a time stamp older than June of 2006 and the
> N:    package does not build-depend on autotools-dev or automake and
> therefore
> N:    apparently does not update it. This usually means that the source
> N:    package will no build correctly on AVR32, for which a Debian port
> is
> N:    currently in progress, and may not support other newer
> architectures.
> N:
> N:    Read /usr/share/doc/autotools-dev/README.Debian.gz (from the
> N:    autotools-dev package) for information on how to fix this problem.
> cdbs
> N:    will automatically update these files if autotools-dev is installed
> N:    during build, but the build dependency on autotools-dev is still
> N:    necessary.
> N:
> N:    Severity: normal, Certainty: possible
> N:
> W: root-system source: outdated-autotools-helper-file
> asimage/src/libAfterImage/config.sub 2005-02-10

These files should be removed in the debian/rules 'clean' target and
possibly be replaced by the Debian ones form autotools-dev.

> E: root-system-common: package-modifies-ld.so-search-path
> etc/ld.so.conf.d/root-system-common.conf
> N:
> N:    This package installs a file in /etc/ld.so.conf.d, presumably to
> modify
> N:    the search path of the run-time linker, and does not appear to be
> part
> N:    of libc.
> N:
> N:    Packages containing shared libraries should either install them into
> N:    /usr/lib or should require binaries built against them to set RPATH
> to
> N:    find the library at run-time. Installing libraries in a different
> N:    directory and modifying the run-time linker path is equivalent to
> N:    installing them into /usr/lib except now conflicting library
> packages
> N:    may cause random segfaults and difficult-to-debug problems instead
> of
> N:    conflicts in the package manager.
> N:
> N:    Refer to Debian Policy Manual section 10.2 (Libraries) for details.
> N:
> N:    Severity: important, Certainty: possible
> N:

Right.  This one I have fixed in my current sandbox of version 5.24.00-1
so I think this should hold on till I can upload that one.  Basically, I
move the shared libraries out of /usr/lib/root and into /usr/lib - and
then we hope there will be no file conflicts with other packages.  I can't
remember where we had this discussion - I think it was in a bug report -
but it was sort of decided to do it like that.

Thanks for you work.  I really appriciate it.

Yours,


 ___  |  Christian Holm Christensen
  |_| |  -------------------------------------------------------------
    | |  Address: Sankt Hansgade 23, 4    Phone:     (+45) 35 35 96 91
     _|           DK-2200 Copenhagen N    Cell:      (+45) 24 61 85 91
    _|            Denmark                 Office:    (+45) 353  25 447
 ____|   Email:   ch...@nbi.dk            Web:    http://cern.ch/cholm
 | |






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

Reply via email to