Re: Bug#744280: RFS: cpl-plugin-xshoo/2.4.0+dfsg-1 (name change)

[Ole Streicher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Thibaut,

Am 13.04.2014 17:24, schrieb Thibaut Paumard:


The problem here is that B *is* actually A. All files that were
originally in A are now in B. There is no conflict just because the
package has them in version (and package) dependent subdirectories.

So, if you want to keep up-to-date, you should at some point remove
package A and install package B instead. This is what I think is the
use of "replaces".

Apart from special situations, there is no reason to keep package A
installed at all. At least, there no better reason than to keep
package versions A-r and A-(r+1) or B-r and B-(r+1) installed at the
same time.

After B (cpl-plugin-xshoo) is in testing, I will remove A
(cpl-plugin-xsh) from the Debian archive, so this is anyway just for
the translation.



I already removed the Conflicts field.



I think it is also helpful if there is no A anymore and a user wants
to install it.



So, if one renames a package and the renamed package has no conflict
to the old one, there should be no flag set? Just to be sure: it is
correct that there will be no indication at all that cpl-plugin-xsh
was renamed to cpl-plugin-xsh?

Sounds weird to me but if you thinkt it is right, I'll do this.

Best

Ole


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTS3ROAAoJEHEVr9B3ENz3BecP/A75E/aaDmbYTeFVOnKfr+GM
2LZyxEm/h/gh8UA0rBLL/egNnbqJax+SXcFqG3o3Bma7HO+etmWWLpT9z81eM4sD
OF+1wOj5338/rzR+xlhh8JzCoZUyHld45JyBCQfm6Co9/HdAy5tdK4fnANni2OdS
jH9vfroSFykmC5LMKkmw17RMyEey3poN64d0LumhWZpX8Trq6dvZDjewiGizkQc1
P7YU4sKcusS1mGo221fLKGFQvgE+cX3JdkB3k41hkURtZKDHJ3m9k5G6JyjTKsNY
YgejeTVOVNzqWfi07Q+5f9V3HJA7yGYmPnVdkyaXjleEzAej09YfaxpAwuDu3XtB
FMXwPqmjQ75XbuOFCzxA+hro0vqJUHhAh9AcCkgRo3PrPJVktmE2WcYIwxLy0kXG
6M9EQHGJn6nvI68x8iFR2bxpi1Gm79crKlrl9yjq6qsX7dUPg0ZScxT4TLdl9M1N
H5qchByudxHn90yY4CwihIKGhosn8Lt1P9eJIIwxXIEArTD0Q6er1m6YaUBgIflk
IV63o3pJqhhUWPae2dnFmenh1LxNCFEndlWQ9hQVR8CnYNU/Dx5YxAq3VGaH/mCR
zoHh4i6m+t0SAYgexNZT/BcI0zAIQw8fVhDc9knRAMqm5+ycxtVkMjGAmd11Ydyj
+IaZixez1TvO5Oi/LeiP
=xVJZ
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/534b744e.1090...@liska.ath.cx

Re: Real newbie ....

[Tobias Frost]

Am Sonntag, den 13.04.2014, 21:49 +0100 schrieb Barry Drake:
> On 13/04/14 20:40, Wookey wrote:
> > So the simple fix is to update your pbuilder chroot, or build with 
> > sbuild instead (which probably involves running sbuild-createchroot to 
> > set up an unstable chroot for it to use (and running sbuild-update 
> > --keygen once to make some keys for apt to use). Each build gives you 
> > a nice log file showing exactly what was installed to satisfy the 
> > build deps, so you shoul dbe able to see which libicu version was 
> > installed. I've not checked anything, so it could be more subtle than 
> > this, but that's my first guess.
> 
> Thanks for such an amazingly quick reply guys.  I've re-initilised the 
> chroot environment, with no difference.  My source is at: 
> https://www.dropbox.com/sh/urhm7iekss5a6a4/I7FveejRSd
> and the packages it built are at: 
> https://www.dropbox.com/sh/s748z00c3zxiupp/-SdnD2xcHR
> 
> Regards,  Barry.

First remark (as you seem somehow associated with upstream): in the
orig.tarball there is a .svn directory.. A good upstream does not ship
them in their tarballs ;-)

BTW, the changelog misses "-1" (The Debian revision). This is weird as
my pbuilder refuses to build non-native packages with a native version,
but yours seems more forgiving in this case... You should check if
your're really on unstable :) (My pbuilder is at 0.215)

(My pbuilder builds also against libicu52; so it's not the source)

Best regards,
Tobi
> 
> 


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1397426886.20086.9.ca...@ithilien.loewenhoehle.ip

Re: Real newbie ....

[Wookey]

+++ Barry Drake [2014-04-13 22:06 +0100]:
> On 13/04/14 20:40, Wookey wrote:
> >Looking at the build log should give some clues about which
> >dependencies get installed. I would guess that your problem is
> >that the chroot pbuilder is using is out of date (and thus has
> >libicu48 still around, or is not set to use only unstable
> >packages?). 

> >Each build gives you a nice log file
> >showing exactly what was installed to satisfy the build deps, so
> >you shoul dbe able to see which libicu version was installed. I've
> >not checked anything, so it could be more subtle than this, but
> >that's my first guess.

I built your source in an uptodate unstable chroot (after fixing the
package version number to have a '-1' on the end). It built fine,
installing libicu52 to do so, and ended up with that dep in the final
packages. So the problem is in your environment (chroot), not the
sources or the tools.
 
> I've attached the log.  Thanks.

It doesn't mention icu at all, so presumably libicu48 is already
installed in your chroot.

> Setting up pbuilder-satisfydepends-dummy (0.invalid.0) ...
> Reading package lists...
> Building dependency tree...
> Reading state information...
> Initializing package states...
> Writing extended state information...
> The following NEW packages will be installed:
>   apparmor-easyprof{a} bsdmainutils{a} debhelper{a} dh-apparmor{a} 
>   dh-python{a} diffstat{a} file{a} gettext{a} gettext-base{a} groff-base{a} 
>   intltool-debian{a} libasprintf-dev{a} libasprintf0c2{a} libcroco3{a} 
>   libexpat1{a} libffi6{a} libgettextpo-dev{a} libgettextpo0{a} 
>   libglib2.0-0{a} libmagic1{a} libpipeline1{a} libpython3-stdlib{a} 
>   libpython3.3-minimal{a} libpython3.3-stdlib{a} libunistring0{a} 
>   libxml2{a} man-db{a} mime-support{a} po-debconf{a} python3{a} 
>   python3-minimal{a} python3.3{a} python3.3-minimal{a} quilt{a} 
> 0 packages upgraded, 34 newly installed, 0 to remove and 0 not upgraded.
> Need to get 309 kB/11.9 MB of archives. After unpacking 40.6 MB will be used.
> The following packages have unmet dependencies:
>  pbuilder-satisfydepends-dummy : Depends: libsword-dev (>= 1.5.11) which is a 
> virtual package.
>  Depends: libclucene-dev but it is not going 
> to be installed.
>  Depends: poxml which is a virtual package.
>  Depends: libboost-dev but it is not going to 
> be installed.
>  Depends: cmake but it is not going to be 
> installed.
>  Depends: pkg-config but it is not going to 
> be installed.
>  Depends: zlib1g-dev but it is not going to 
> be installed.
>  Depends: libcurl4-gnutls-dev but it is not 
> going to be installed.
>  Depends: libqtwebkit-dev but it is not going 
> to be installed. or
>   libqt4-dev (<= 4:4.7.0~beta1) but 
> it is not going to be installed.
> Unable to resolve dependencies!  Giving up...

This doesn't look like it is building anything - it can't install the
build-deps. perhaps your issue is that you have old .debs around and
they are not being rebuilt when you think they are.

Make a new, clean, unstable chroot and use that for the builds. Things
should start working better then.

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140413215930.gp15...@stoneboat.aleph1.co.uk

Re: Real newbie ....

[Daniel Lintott]

On 13/04/14 21:49, Barry Drake wrote:
> On 13/04/14 20:40, Wookey wrote:
>> So the simple fix is to update your pbuilder chroot, or build with
>> sbuild instead (which probably involves running sbuild-createchroot to
>> set up an unstable chroot for it to use (and running sbuild-update
>> --keygen once to make some keys for apt to use). Each build gives you
>> a nice log file showing exactly what was installed to satisfy the
>> build deps, so you shoul dbe able to see which libicu version was
>> installed. I've not checked anything, so it could be more subtle than
>> this, but that's my first guess.
> 
> Thanks for such an amazingly quick reply guys.  I've re-initilised the
> chroot environment, with no difference.  My source is at:
> https://www.dropbox.com/sh/urhm7iekss5a6a4/I7FveejRSd
> and the packages it built are at:
> https://www.dropbox.com/sh/s748z00c3zxiupp/-SdnD2xcHR
> 
> Regards,  Barry.
> 

I've just attempted a build using both sbuild and pbuilder under Debian
sid (unstable).

sbuild - builds fine... and gets the libicu52 dependency

Depends line from libsword9:

Depends: libsword-common, libc6 (>= 2.14), libclucene-core1 (>=
2.3.3.4), libcurl3-gnutls (>= 7.16.2), libgcc1 (>= 1:4.1.1), libicu52
(>= 52~m1-1~), libstdc++6 (>= 4.6), zlib1g (>= 1:1.1.4)

pbuilder - doesn't build and fails with:

dpkg-source: error: can't build with source format '3.0 (quilt)':
non-native package version does not contain a revision

As the correct version number should be: 1.7.3+dfsg-1

Not sure I can be much more help than that... but it would definitely
seem to be an issue with your chroot.

Regards,
-- 
Daniel Lintott
GPG Key: 4096R/5D73EC6E



signature.asc
Description: OpenPGP digital signature

Re: Real newbie ....

[Barry Drake]

On 13/04/14 20:40, Wookey wrote:
Looking at the build log should give some clues about which 
dependencies get installed. I would guess that your problem is that 
the chroot pbuilder is using is out of date (and thus has libicu48 
still around, or is not set to use only unstable packages?). pbuilder 
does not update the chroot for each build by default, you have to 
update it separately. sbuild does do an update/upgrade every time by 
default, which is one major reason I recommend using it for builds. So 
the simple fix is to update your pbuilder chroot, or build with sbuild 
instead (which probably involves running sbuild-createchroot to set up 
an unstable chroot for it to use (and running sbuild-update --keygen 
once to make some keys for apt to use). Each build gives you a nice 
log file showing exactly what was installed to satisfy the build deps, 
so you shoul dbe able to see which libicu version was installed. I've 
not checked anything, so it could be more subtle than this, but that's 
my first guess.


I've attached the log.  Thanks.

Regards,Barry.
W: /home/barry/.pbuilderrc does not exist
I: Building the build Environment
I: extracting base tarball [/var/cache/pbuilder/base.tgz]
I: creating local configuration
I: copying local configuration
I: mounting /proc filesystem
I: mounting /run/shm filesystem
I: mounting /dev/pts filesystem
I: Mounting /home/barry/prog/32
I: policy-rc.d already exists
I: Obtaining the cached apt archive contents
Reading package lists...
Building dependency tree...
Reading state information...
passwd is already the newest version.
The following extra packages will be installed:
  debootstrap libidn11 libssl1.0.0 wget
Suggested packages:
  pbuilder-uml gdebi-core cowdancer
Recommended packages:
  fakeroot sudo devscripts
The following NEW packages will be installed:
  debootstrap libidn11 libssl1.0.0 pbuilder wget
debconf: delaying package configuration, since apt-utils is not installed
0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/1798 kB of archives.
After this operation, 5029 kB of additional disk space will be used.
Selecting previously unselected package libssl1.0.0:i386.
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 11806 files and directories currently installed.)
Unpacking libssl1.0.0:i386 (from .../libssl1.0.0_1.0.1e-3ubuntu1_i386.deb) ...
Selecting previously unselected package libidn11:i386.
Unpacking libidn11:i386 (from .../libidn11_1.28-1ubuntu1_i386.deb) ...
Selecting previously unselected package wget.
Unpacking wget (from .../wget_1.14-2ubuntu1_i386.deb) ...
Selecting previously unselected package debootstrap.
Unpacking debootstrap (from .../debootstrap_1.0.53_all.deb) ...
Selecting previously unselected package pbuilder.
Unpacking pbuilder (from .../pbuilder_0.215ubuntu2_all.deb) ...
Setting up libssl1.0.0:i386 (1.0.1e-3ubuntu1) ...
Setting up libidn11:i386 (1.28-1ubuntu1) ...
Setting up wget (1.14-2ubuntu1) ...
Setting up debootstrap (1.0.53) ...
Setting up pbuilder (0.215ubuntu2) ...
Processing triggers for libc-bin ...
I: Setting DEBBUILDOPTS=
I: Setting DEBBUILDOPTS=
W: no hooks of type D found -- ignoring
 -> Attempting to satisfy build-dependencies
 -> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: i386
Maintainer: Debian Pbuilder Team 
Description: Dummy package to satisfy dependencies with aptitude - created by 
pbuilder
 This package was created automatically by pbuilder to satisfy the
 build-dependencies of the package being currently built.
Depends: quilt (>= 0.46-7~), debhelper (>= 7.0.50~), libsword-dev (>= 1.5.11), 
libclucene-dev, poxml, libboost-dev, cmake, pkg-config, zlib1g-dev, 
libcurl4-gnutls-dev, libqtwebkit-dev | libqt4-dev (<= 4:4.7.0~beta1)
dpkg-deb: building package `pbuilder-satisfydepends-dummy' in 
`/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 12000 files and directories currently installed.)
Unpacking pbuilder-satisfydepends-dummy (from 
.../pbuilder-satisfydepends-dummy.deb) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring 
anyway as you requested:
 pbuilder-satisfydepends-dummy depends on quilt (>= 0.46-7~); however:
  Package quilt is not installed.
 pbuilder-satisfydepends-dummy depends on debhelper (>= 7.0.50~); however:
  Package debhelper is not installed.
 

Re: Real newbie ....

[Barry Drake]

On 13/04/14 20:40, Wookey wrote:
So the simple fix is to update your pbuilder chroot, or build with 
sbuild instead (which probably involves running sbuild-createchroot to 
set up an unstable chroot for it to use (and running sbuild-update 
--keygen once to make some keys for apt to use). Each build gives you 
a nice log file showing exactly what was installed to satisfy the 
build deps, so you shoul dbe able to see which libicu version was 
installed. I've not checked anything, so it could be more subtle than 
this, but that's my first guess.


Thanks for such an amazingly quick reply guys.  I've re-initilised the 
chroot environment, with no difference.  My source is at: 
https://www.dropbox.com/sh/urhm7iekss5a6a4/I7FveejRSd
and the packages it built are at: 
https://www.dropbox.com/sh/s748z00c3zxiupp/-SdnD2xcHR


Regards,  Barry.




--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/534af858.5090...@gmail.com

Re: Real newbie ....

[Wookey]

+++ Barry Drake [2014-04-13 17:51 +0100]:
> Hi ...  Can I introduce myself.  I've been involved in 'The Sword
> Project' for some years and am now going along the very steep
> learning curve in order to update the packages which are some five
> years out of date.  I'm running Ubuntu Trusty 14.04 beta and can
> build the packages with no problem using pdebuild.  But - the build
> puts in a dependency on libicu48 which is now removed from the
> Ubuntu repos and replaced with libicu52 which is what the actual
> build from source is using.  The control file produced is identical
> to that in the current out-of-date package (1.6.2).  I am packaging
> version 1.7.3.
 
> I've worked out that dpkg is being used to get the dependencies (I
> think) but I haven't a clue as to where it gets them from, or how I
> can change this behaviour.  The builder puts them into the
> ${shlibs:Depends} string, and I can't see any method of controlling
> what gets into that string.  I've read and re-read the packaging
> startup manual and haven't managed to find what to do.  The control
> file produced by the build has the line:
> 
> Depends: libsword-common, libc6 (>= 2.4), libclucene-core1 (>=
> 2.3.3.4), libcurl3-gnutls (>= 7.16.2), libgcc1 (>= 1:4.1.1),
> libicu48 (>= 4.8-1), libstdc++6 (>= 4.6), zlib1g (>= 1:1.1.4)
> 
> and it needs to have libicu52 (>= 0) as the correct dependency.

I've always been a little vague about the details, but essentiaqlly
the ${shlibs:Depends} variable gets populated by the shlibpeps
mechanism which actually looks at the libraries linked and puts in the
corresponding package names. So if it's putting in libicu48 then
that's almost certainly because that's the library that's actually
getting used in the build.

Looking at the build log should give some clues about which
dependencies get installed.

I would guess that your problem is that the chroot pbuilder is using
is out of date (and thus has libicu48 still around, or is not set to
use only unstable packages?). pbuilder does not update the chroot for
each build by default, you have to update it separately. sbuild does
do an update/upgrade every time by default, which is one major reason
I recommend using it for builds.

So the simple fix is to update your pbuilder chroot, or build with
sbuild instead (which probably involves running sbuild-createchroot to
set up an unstable chroot for it to use (and running sbuild-update
--keygen once to make some keys for apt to use).

Each build gives you a nice log file showing exactly what was
installed to satisfy the build deps, so you shoul dbe able to see
which libicu version was installed.

I've not checked anything, so it could be more subtle than this, but
that's my first guess.

> I hope I've come to the right place to ask this kind of newbie
> question. 

You have :-)

> I don't want to become a maintainer, jut to produce the
> build source files and pass them on to one of the existing
> maintainers to sign and submit.
> 
> Kind regards,Barry Drake.
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: https://lists.debian.org/534ac0af.20...@gmail.com
> 
Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140413194040.go15...@stoneboat.aleph1.co.uk

Re: Real newbie ....

[Tobias Frost]

Hi Barry,


Am Sonntag, den 13.04.2014, 17:51 +0100 schrieb Barry Drake:
> Hi ...  Can I introduce myself.  I've been involved in 'The Sword 
> Project' for some years and am now going along the very steep learning 
> curve in order to update the packages which are some five years out of 
> date.  I'm running Ubuntu Trusty 14.04 beta and can build the packages 
> with no problem using pdebuild.  But - the build puts in a dependency on 
> libicu48 which is now removed from the Ubuntu repos and replaced with 
> libicu52 which is what the actual build from source is using.  The 
> control file produced is identical to that in the current out-of-date 
> package (1.6.2).  I am packaging version 1.7.3.

Can you please give a reference to your package? Maybe taking a look at
it gives some clues :) Best would be to upload it to mentors.debian.net

One possibility just came to my mind: Did you update your pbuilder
environment before building it? 

> I've worked out that dpkg is being used to get the dependencies (I 
> think) but I haven't a clue as to where it gets them from, or how I can 
> change this behaviour.  The builder puts them into the ${shlibs:Depends} 
> string, and I can't see any method of controlling what gets into that 
> string.  I've read and re-read the packaging startup manual and haven't 
> managed to find what to do.  The control file produced by the build has 
> the line:
> 
> Depends: libsword-common, libc6 (>= 2.4), libclucene-core1 (>= 2.3.3.4), 
> libcurl3-gnutls (>= 7.16.2), libgcc1 (>= 1:4.1.1), libicu48 (>= 4.8-1), 
> libstdc++6 (>= 4.6), zlib1g (>= 1:1.1.4)
> 
> and it needs to have libicu52 (>= 0) as the correct dependency.

Usually dpkg-shlibdeps is right in determining the dependencies.
Without source its hard to check the root-cause.
Maybe the Build-Dependencies are wrong, or you still have the old
library installed (and/or the old -dev package)? Are you building with
the unstable repositories (and your e.g chroot up-to-date)?

> I hope I've come to the right place to ask this kind of newbie 
> question.  I don't want to become a maintainer, jut to produce the build 
> source files and pass them on to one of the existing maintainers to sign 
> and submit.

Well, that's usually not that easy... Of course you can prepare the
upload, but still the maintainer has to do several extra checks before
he can sign it off and indeed upload it. A well-prepared patch certainly
is of great value, but the best would be to offer co-maintaince ... Or
if you "upstream" to help as the upstream contact. I my experience this
helps a lot, as in my experience "upstream" perceives the details of
packaging work different than the actually needs of Debian. (This is
usually well-meant, don't get me wrong, but there a just so many details
to consider. This is for example why upstream never should ship
a /debian directory in its source tarball ...)

> Kind regards,Barry Drake.
> 
> 


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1397417469.3870.50.ca...@ithilien.loewenhoehle.ip

Real newbie ....

[Barry Drake]

Hi ...  Can I introduce myself.  I've been involved in 'The Sword 
Project' for some years and am now going along the very steep learning 
curve in order to update the packages which are some five years out of 
date.  I'm running Ubuntu Trusty 14.04 beta and can build the packages 
with no problem using pdebuild.  But - the build puts in a dependency on 
libicu48 which is now removed from the Ubuntu repos and replaced with 
libicu52 which is what the actual build from source is using.  The 
control file produced is identical to that in the current out-of-date 
package (1.6.2).  I am packaging version 1.7.3.


I've worked out that dpkg is being used to get the dependencies (I 
think) but I haven't a clue as to where it gets them from, or how I can 
change this behaviour.  The builder puts them into the ${shlibs:Depends} 
string, and I can't see any method of controlling what gets into that 
string.  I've read and re-read the packaging startup manual and haven't 
managed to find what to do.  The control file produced by the build has 
the line:


Depends: libsword-common, libc6 (>= 2.4), libclucene-core1 (>= 2.3.3.4), 
libcurl3-gnutls (>= 7.16.2), libgcc1 (>= 1:4.1.1), libicu48 (>= 4.8-1), 
libstdc++6 (>= 4.6), zlib1g (>= 1:1.1.4)


and it needs to have libicu52 (>= 0) as the correct dependency.

I hope I've come to the right place to ask this kind of newbie 
question.  I don't want to become a maintainer, jut to produce the build 
source files and pass them on to one of the existing maintainers to sign 
and submit.


Kind regards,Barry Drake.


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/534ac0af.20...@gmail.com

Bug#744340: RFS: jamnntpd/1.2-1 [ITP]

[RJ Clay]

On 04/13/2014 10:38 AM, Paul Wise wrote:

On Sun, Apr 13, 2014 at 11:58 AM, RJ Clay wrote:


I am looking for a sponsor for my package "jamnntpd"

Based on the number of GCC warnings, the code quality looks pretty bad.


  I know.  Unlike with the existing crashmail package (for which I am 
also both the maintainer and upstream, and for which I am currently 
working on packaging v1.5) I haven't yet had a chance to work on 
cleaning those warnings up.


  Note also that JamNNTPd provides access to the JAM message bases that 
Crashmail maintains;  currently, there isn't another program that does that.





RJ Clay, j...@rocasa.com


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/534aab96.8030...@rocasa.us

Bug#743691: RFS: wcslib-contrib/4.20 [ITP] -- Draw and label curvilinear coordinate grids with pgplot

[Thibaut Paumard]

Control: owner -1 !
Control: tag -1 + pending

I'll take care of this one


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/534ab6df.8010...@free.fr

Bug#744280: RFS: cpl-plugin-xshoo/2.4.0+dfsg-1 (name change)

[Thibaut Paumard]

Le 13/04/2014 15:33, Ole Streicher a écrit :
> Hi Thibaut,
> 
> my mail program seemed to eat the citations. 2nd attempt:
> 
> Am 13.04.2014 14:45, schrieb Thibaut Paumard:
>> Why does the package Conflict and Replace cpl-plugin-xsh? None of
>> the files are the same (so at least the Replace is wrong).
> 
> I mainly followed the rule of renaming a package.
> "Replaces" is correct wrt policy:
> 
> 7.6 Overwriting files and replacing packages - Replaces
> 
> Packages can declare in their control file that they should overwrite
> files in certain other packages, or completely replace other packages.
> The Replaces control field has these two distinct purposes.

Dear Ole,

I think you misunderstood the uses of Replaces. Like the other types of
dependencies, "Replaces" is a technical tool to warrant a certain
behaviour of the package manager. The fact that you are trying to
replace a package by another one in the archive does not mean that
Replaces is useful or even right for your purpose. The two use cases are:

- file f was is package A, now it is in package B. Either package A is
removed from the archive, or there is a new version of package A without
file f. (Normally, Breaks+Replaces).

- packages A and B provide the same functionality, but should not be
installed at the same time on the system. (Only real use case for
Conflicts+Replaces).*

You are in neither of those two situations. Now in Policy there is also
this sentence (near the end of 7.4):

"Neither Breaks nor Conflicts should be used unless two packages cannot
be installed at the same time or installing them both causes one of them
to be broken or unusable."

The Provides field is really useful only if there are other packages
already depending on package A.

I think you should just completely remove the three fields. Conflicts is
wrong, Breaks seems wrong too since nothing is broken, and Replaces is
useless without either Conflicts or Breaks.

Kind regards, Thibaut.



signature.asc
Description: OpenPGP digital signature

Bug#744026: RFS: isbg/0.99-1 [#587458]

[Paul Wise]

On Wed, Apr 9, 2014 at 8:38 PM, Werner Mahr wrote:

>   I am looking for a sponsor for my package "isbg"

I don't intend to sponsor this but here is a review:

Please include the manual page upstream and make setup.py install it properly.

The url= line in setup.py is incorrectly indented with spaces instead of tabs.

debian/copyright is missing the license information.

debian/copyright contains a bogus URL to different software.

You might want to use the machine-readable copyright format:

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

The empty Recommends/Suggests in debian/control are unnecessary.

debian/changelog should only contain one entry not two:

  * Initial packaging (Closes: #587458)

I would suggest using the new dh command from debhelper to reduce
debian/rules to 3 lines, see the dh manual page for examples.

http://manpages.debian.org/man0/dh
https://penta.debconf.org/dc9_schedule/events/418.en.html

Generally DH_VERBOSE is commented out in debian/rules.

The package FTBFS when built twice in a row:

dpkg-source: info: local changes detected, the modified files are:
 isbg-0.99/build/scripts-2.7/isbg.py
 isbg-0.99/isbg.egg-info/PKG-INFO
 isbg-0.99/isbg.egg-info/SOURCES.txt
 isbg-0.99/isbg.egg-info/dependency_links.txt
 isbg-0.99/isbg.egg-info/top_level.txt
dpkg-source: error: aborting due to unexpected upstream changes, see
/tmp/isbg_0.99-1.diff.c121eq
dpkg-source: info: you can integrate the local changes with dpkg-source --commit

Automated checks:

https://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package

lintian:

I: isbg source: debian-watch-file-is-missing
I: isbg: hyphen-used-as-minus-sign usr/share/man/man1/isbg.1.gz:46

dpkg-gencontrol:

warning: package isbg: unused substitution variable ${python:Versions}

duck:

debian/control: Homepage: http://redmine.ookook.fr/projects/isbg:  ERROR
Curl:28 HTTP:0 Timeout was reached Connection timed out after 60001 milliseconds

lintian4py:

p: isbg source: insufficient-build-dependency-on-python-helper
dh_python2 => python (>= 2.6.6-3~)
x: isbg: except-without-exception-type usr/bin/isbg:207
x: isbg: except-without-exception-type usr/bin/isbg:214
x: isbg: except-without-exception-type usr/bin/isbg:356
x: isbg: except-without-exception-type usr/bin/isbg:370
x: isbg: except-without-exception-type usr/bin/isbg:383
x: isbg: except-without-exception-type usr/bin/isbg:434
x: isbg: except-without-exception-type usr/bin/isbg:461
x: isbg: except-without-exception-type usr/bin/isbg:501
x: isbg: except-without-exception-type usr/bin/isbg:527
x: isbg: except-without-exception-type usr/bin/isbg:552
x: isbg: except-without-exception-type usr/bin/isbg:601
p: isbg: SOURCES.txt-in-binary-package
e: isbg: pyflakes-undefined-name usr/bin/isbg:377: imap

pyflakes:

./isbg.py:377: undefined name 'imap'

pep8:

lots of warnings

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6fy30k8tom_gbqsjc_ratrrei7scu15g8mbpwxwgvf...@mail.gmail.com

Bug#744340: RFS: jamnntpd/1.2-1 [ITP]

[Paul Wise]

On Sun, Apr 13, 2014 at 11:58 AM, RJ Clay wrote:

> I am looking for a sponsor for my package "jamnntpd"

Based on the number of GCC warnings, the code quality looks pretty bad.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6g3lzzjao-8uv5jk46--_y5rvhkz528v35fm2ykxlg...@mail.gmail.com

Re: Bug#744045: RFS: xsd/3.3.0.2-1 [ITA]

[Jörg Frings-Fürst]

Hallo,

Am Samstag, den 12.04.2014, 01:12 -0700 schrieb Vincent Cheng:
> Control: tag -1 + moreinfo
> 
> On Wed, Apr 9, 2014 at 7:17 AM, Jörg Frings-Fürst
>  wrote:
> > Package: sponsorship-requests
> >   Severity: normal [important for RC bugs, wishlist for new packages]
> >
[...]
> 
> Please use upstream's tarball (assuming that [1] is the correct
> source, please use the ones that don't have dependencies bundled
> inside) directly as your orig tarball, and apply the contents of
> "bug604256.tar.gz" and any other diffs as quilt patches, unless
> there's a good reason for the current tarball-in-a-tarball approach
> (if there is, please explain). Also remove your debian packaging from
> the source tarball.
> 

Changes since the last upload:

  * rename version from the orig-tarball
  * replace old tarball-in-tarball with the the orig-tarball
  * remove 
- patches included in tarball
- debian/README.source
  * add hardenning-wrapper to Build-Depends
  * rewrite debian/rules
  * rename debian/patches/xsd_xsdcxx-rename.patch to 
  0001-xsd_xsdcxx-rename.patch
  * add file xsdcxx.lintian-overrides
- duplicate-files
- debian-watch-may-check-gpg-signature
- no-upstream-changelog
  * change debian/compat to 9


> Regards,
> Vincent

Regards,
Jörg

-- 
pgp Fingerprint: 7D13 3C60 0A10 DBE1 51F8  EBCB 422B 44B0 BE58 1B6E
pgp Key: BE581B6E
CAcert Key S/N: 0E:D4:56

Jörg Frings-Fürst
54526 Niederkail





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

Bug#744280: RFS: cpl-plugin-xshoo/2.4.0+dfsg-1 (name change)

[Ole Streicher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Thibaut,

my mail program seemed to eat the citations. 2nd attempt:

Am 13.04.2014 14:45, schrieb Thibaut Paumard:
> Why does the package Conflict and Replace cpl-plugin-xsh? None of
> the files are the same (so at least the Replace is wrong).

I mainly followed the rule of renaming a package.
"Replaces" is correct wrt policy:

7.6 Overwriting files and replacing packages - Replaces

Packages can declare in their control file that they should overwrite
files in certain other packages, or completely replace other packages.
The Replaces control field has these two distinct purposes.

> - are there any files in common in the two packages?

No.

> - what happens when the two packages are installed together? + are
> the two packages still usable somehow?

Yes.

> + is one package simply shadowed by the other?

On default, yes. However, they can (with python-cpl) both separately
accessed by using the version number as argument

> + is cpl completely broken in that case?

No.

> - remove the Replaces line;

That one should stay, see above.

> - replace Conflicts with Breaks or remove it altogether;

Removing the "Conflicts" field would create the special case that the
old version and the new version of the pipeline are co-installable,
what is not the case for the other recipes. This is however not a real
problem.

> - keep Provides if the new package really provides the same API;

It does. The recipes are still named as before.

> - optional: build cpl-plugin-xsh* as meta-packages that will pull 
> their cpl-plugin-xshoo counterpart.

Seems a bit complicated for a popconn-zero package.

So, maybe the best would be just to remove the Conflicts field. Would
you agree?

Best

Ole

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTSpI3AAoJEHEVr9B3ENz3QMgP/i6tjIq07Xi9FzHqkcJhENhP
0j44KZ1Nb5ecgt/t9tUCBubyBa+2h6esMxseB+KJOiR+WzKmO5JlDSnv0nhFoIHH
0dMIz/L1UIwAhDnO2HJY8fmD/at0XXCqD51pt2YwHpCkUDcuqZCS5V6IWd5lckYH
DJY29ziEGwkgw1H+OxYfW8Qs8Ra0Ps9K1N9RJ6mnA7HiRBABVb0ISchhnVvzDYtn
/2jFvt9tJ2oElW4UZBy/tASXxsk+ERJYyWsDGQtaMOL5PxcnYcz4EXV9K5rVcHmV
+CS6fnyWL69KjNYFBrG10DSaM6PykqJEf1uKLfl4vCfNDdvtW4cS0zutxE+7OHpw
vkPJWJsRNAIM7DUTVNJQKW3yapi4+BsR1lT1fLOnHFQOg3AGOVqBAJNX95pZKZYB
GiDRWL79XvApmBy9jjVMIKHPz/Kor0GhYcsBNUV3vXRPisAkjbxNLXn/OvHl37FN
wt1yx48lIJFGxC+QGVR1jxNz31bZy2VEn6YBrjigtCxPLvBUw+70LMUSrME2Vo+W
7mSMLwR6TJiJ3Ve9B83WierBzYWBUQHB93YTpSCGCak08JS7QLGglUVfL5jF4gzR
MtpPmQkSKVl0GT5Tw697DnP/V0qVu8uPulUg7oM4ROZY84+36lU9sPhkux1aVLe8
rE4h9PfE3F5/uSUCQJwz
=D1xA
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/534a9237.7030...@liska.ath.cx

Bug#743691: RFS: wcslib-contrib/4.20 [ITP] -- Draw and label curvilinear coordinate grids with pgplot

[Ole Streicher]

X-Debbugs-Cc: debian-as...@lists.debian.org, debian-scie...@lists.debian.org

> I am looking for a sponsor for my package "wcslib-contrib"
> 
> * Package name: wcslib-contrib
>   Version : 4.20-1

Since upstream released the new version 4.22, I updated the package on
mentors. So, the "dget" is now

 dget -x
http://mentors.debian.net/debian/pool/contrib/w/wcslib-contrib/wcslib-contrib_4.22-1.dsc

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/534a8c3f.5070...@liska.ath.cx

Bug#744280: RFS: cpl-plugin-xshoo/2.4.0+dfsg-1 (name change)

[Ole Streicher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Thibaut,

Am 13.04.2014 14:45, schrieb Thibaut Paumard:


I mainly followed the rule of renaming a package.
"Replaces" is correct wrt policy:

7.6 Overwriting files and replacing packages - Replaces

Packages can declare in their control file that they should overwrite
files in certain other packages, or completely replace other packages.
The Replaces control field has these two distinct purposes.



No.



Yes.



On default, yes. However, they can (with python-cpl) both separately
accessed by using the version number as argument



No.



That one should stay, see above.



Removing the "Conflicts" field would create the special case that the
old version and the new version of the pipeline are co-installable,
what is not the case for the other recipes. This is however not a real
problem.



It does. The recipes are still named as before.



Seems a bit complicated for a popconn-zero package.

So, maybe the best would be just to remove the Conflicts field. Would
you agree?

Best

Ole

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTSosDAAoJEHEVr9B3ENz367kQALCXxtFkM3R01hgfL1jIAMsk
OG2UWKbUZ7aq3Ue3HghbBwRMfbkRLi/rM+ptFa6vrGOSPSL+Biuqokw4l9L3sK3y
euJ4r9Vd0zL4o4h1z7WrR1mrPArIU2PUOPS5YpE4BrOf8zBA0ujSQq4MXJdR8BQq
7scYcaQPfYUkbu3n7LsxlTzgb/hiuYw0wSHOj3WVA08S/d2/SvP7JNP1Z+PLDWSo
6Ny2efUdFZXg31xFQxqGwRxNcv4eX9syB+3y0oWuv+RQuU+6qftNPp/48rRKU28n
F0fsaU00uWqwayYDVy6yNEHysrsi/pfnxzLXfy3xhYOXxo02trh0zaHcq+vns8nm
LkYZnMmu/kBTMuvKVfAsG0j/nRpU8sn36fzr/YOjTECUhVbWMNr7NTYc6n5amufm
VipZonK5AhH6HwsXTP1ox4k2a6Hs1uZdCN7fEnfUr3yRN+oN+mrz4KHCXZ153lu2
gsexxTRpjaBQ1tYELjmqfyU7fRyJgcYH3mI1TIiAR9PoI2VqraKGQExagB6OGPl6
RNmzpi6QLmAia33nfole0lRnHCd14JJFPoJ+islfTt1khA+eh+BbqLxMDtR0XVlj
Bsf3f0njzxiDGyPU3uOMdsUc4SzYE+hBrpy+rn6scFawjNAPbv4nYEaiqVh8+hCm
Wd8ZPPPnNSXBIIasmuFS
=m2GS
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/534a8b03.2030...@liska.ath.cx

Bug#744280: RFS: cpl-plugin-xshoo/2.4.0+dfsg-1 (name change)

[Thibaut Paumard]

Le 12/04/2014 13:55, Ole Streicher a écrit :
> Package: sponsorship-requests
> Severity: normal
> X-Debbugs-Cc: debian-as...@lists.debian.org, debian-mentors@lists.debian.org
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "cpl-plugin-xshoo"

Hi Ole,

Why does the package Conflict and Replace cpl-plugin-xsh? None of the
files are the same (so at least the Replace is wrong). Conflicts is a
very strong type of dependency, that should be avoided if at all
possible, for instance using Breaks instead.

So the questions are:
 - are there any files in common in the two packages?
 - what happens when the two packages are installed together?
   + are the two packages still usable somehow?
   + is one package simply shadowed by the other?
   + is cpl completely broken in that case?

Depending on the answers to those questions, I would think you could:
 - remove the Replaces line;
 - replace Conflicts with Breaks or remove it altogether;
 - keep Provides if the new package really provides the same API;
 - optional: build cpl-plugin-xsh* as meta-packages that will pull
   their cpl-plugin-xshoo counterpart.

Kind regards, Thibaut.




signature.asc
Description: OpenPGP digital signature

Trilinos: to split or not to split

[Nico Schlömer]

Hi all,

I would like to hear your opinion on the following question:

I'm packaging a rather large software, Trilinos, a collection of
libraries (libbelos, libml, libaztecoo,...) for numerical
high-performance computing.

Upstream supports monolithic builds, i.e., the collection of libraries
is assumed to be fully present on the system, and the user picks out
what parts of it he or she wants to use. This makes for a very simple
debian/rules and debian/control, cf.
.
Downsides of this include the size of the package, and the fact that
the package name "trilinos" does not correspond with the library names
(libbelos.*, libml.*,...).

Given its subpackage structure, Felix helped out creating a packaging
format that splits the build up into subpackages. Debian's shlibs
magic takes care of the dependency hierarchy, but a couple of things
problems need to be worked around
.

Which approach is better suited for Debian in your opinion?

Cheers,
Nico


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAK6Z60fUwHeS+ADHe--q=0s2rf+zyucr_+sxlaeuhp94yu3...@mail.gmail.com

Re: Bug#726533: RFS: 0install/2.3.3-2 [ITP] -- rename and split zeroinstall-injector package

[Thomas Leonard]

On 2014-02-09 09:27, Vincent Cheng wrote:

On Sat, Feb 8, 2014 at 6:33 AM, Thomas Leonard  wrote:

On 7 February 2014 22:18, Vincent Cheng  wrote:

On Fri, Feb 7, 2014 at 4:02 AM, Thomas Leonard  wrote:

Hi Vincent,

Many thanks for uploading this. However, the package has been stuck in
NEW for the last few weeks. I'm not sure what the problem is, but
possibly it's because the 0install package didn't contain any files
(it was just a meta-package for pulling in the GUI dependencies),
which someone mentioned might be a problem.

I've uploaded a new version now which puts the GUI plugin files in the
"0install" package while leaving the rest in "0install-core":

   https://mentors.debian.net/package/zeroinstall-injector

Any chance you could upload that version to (hopefully) unstick the process?


Your updated package FTBFS in a clean sid pbuilder chroot; it looks
like you might need to add unzip to build-depends? I've attached the
build log.


Oops. Sorry about that.

I've uploaded a new version that now builds correctly under pbuilder.

http://mentors.debian.net/package/zeroinstall-injector


Built, signed, and uploaded, thanks!


Hi Vincent,

Sorry to bother you again, but do you know how long it will take to be 
approved? It has been more than 2 months now and the upload is still in 
NEW. Is there anything I can do to speed this along?


  http://packages.qa.debian.org/z/zeroinstall-injector.html

Thanks,



--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lidmo9$v3j$1...@ger.gmane.org