Upload commands to debomatic-amd64

[Mathieu Malaterre]

Dear all,

I am trying to follow documentation from:

* http://debomatic-amd64.debian.net/

and:

* https://deb-o-matic.readthedocs.io/en/stable/upload.html#prepare-command-files

Which does not seems to be working for me today;

% dcut -U debomatic jxl.commands
usage: dcut [-h] [-d] [-f] [-c FILE] [-m MAINTAINER] [-k KEYID] [-S]
[-O FILENAME] [-P] [-s] [-v]
[HOST]
{debomatic-binnmu,debomatic-builddep,debomatic-kill,debomatic-porter,debomatic-rebuild,debomatic-rm}
...
dcut: error: argument
{debomatic-binnmu,debomatic-builddep,debomatic-kill,debomatic-porter,debomatic-rebuild,debomatic-rm}:
invalid choice: 'jxl.commands' (choose from 'debomatic-binnmu',
'debomatic-builddep', 'debomatic-kill', 'debomatic-porter',
'debomatic-rebuild', 'debomatic-rm')

Would anyone spot the issue ?

Thanks

For reference:

% cat /etc/dput.d/profiles/debomatic.json
{
"allow_dcut": true,
"meta": "debomatic",
"fqdn": "debomatic-amd64.debian.net",
"incoming": "/srv/debomatic-amd64",
"login": "debomatic",
"method": "sftp",
"check-debs": { "skip": true }
}

% apt-cache policy dput-ng
dput-ng:
  Installed: 1.35+deb12u1
  Candidate: 1.35+deb12u1
  Version table:
 *** 1.35+deb12u1 500
500 http://deb.debian.org/debian bookworm/main amd64 Packages
500 http://deb.debian.org/debian bookworm/main i386 Packages
100 /var/lib/dpkg/status

% cat jxl.commands
rebuild ffmpeg_7:6.0-7 unstable experimental
rebuild geeqie_1:2.1-1 unstable experimental
rebuild gimp_2.10.34-1 unstable experimental
rebuild graphicsmagick_1.4+really1.3.42-1 unstable experimental
rebuild imlib2_1.12.1-1 unstable experimental
rebuild kimageformats_5.107.0-3 unstable experimental
rebuild krita_1:5.2.0+dfsg-1 unstable experimental
rebuild swayimg_1.12-1 unstable experimental
rebuild vips_8.14.5-1 unstable experimental
rebuild webkit2gtk_2.42.1-2 unstable experimental
rebuild wpewebkit_2.42.1-1 unstable experimental

Should #1033656 be fixed on stable ?

[Mathieu Malaterre]

[cc me please]

Dear mentors,

I messed up src:highway on armhf (neon-less system). This makes the
package unusable on those systems.

Should I prepare an upload for stable-updates ?

Thanks !

Re: The following packages will be REMOVED: libhwy1

[Mathieu Malaterre]

On Tue, Aug 29, 2023 at 11:15 AM Sebastiaan Couwenberg
 wrote:
>
> On 8/29/23 10:38, Mathieu Malaterre wrote:
> >> FTBFS on several architectures:
> >
> > That's actually a related issue, I am working with upstream to fix
> > those. In order to do so, I'd like to co-install i386 and amd64. Right
> > now I can only install one *or* the other. I'd like to install *both*:
>
> You can't because 1.0.5-1 is available for amd64, but not i386 where it
> FTBFS:
>
>   https://buildd.debian.org/status/logs.php?pkg=highway=amd64
>   https://buildd.debian.org/status/logs.php?pkg=highway=i386
>
> # aptitude install libhwy1:amd64 libhwy1:i386
> libhwy1:i386 is already installed at the requested version (1.0.4-1)
> libhwy1:i386 is already installed at the requested version (1.0.4-1)
> The following NEW packages will be installed:
>libhwy1{b}
> 0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
> Need to get 0 B/538 kB of archives. After unpacking 3471 kB will be used.
> The following packages have unmet dependencies:
>   libhwy1 : Breaks: libhwy1:i386 (!= 1.0.5-1) but 1.0.4-1 is installed
>   libhwy1:i386 : Breaks: libhwy1 (!= 1.0.4-1) but 1.0.5-1 is to be installed
> The following actions will resolve these dependencies:
>
>   Remove the following packages:
> 1) libhwy1:i386 [1.0.4-1 (now, unstable)]

Thanks for your kind help here. It seems aptitude output is much more
readable than what I used.

snapshot.d.o did work quite well for me so I am able to run creduce after all.

Thanks again
-M

Re: The following packages will be REMOVED: libhwy1

[Mathieu Malaterre]

[CC me please]

> FTBFS on several architectures:

That's actually a related issue, I am working with upstream to fix
those. In order to do so, I'd like to co-install i386 and amd64. Right
now I can only install one *or* the other. I'd like to install *both*:

% sudo apt install -y libhwy1:i386
% apt-cache policy libhwy1:i386
libhwy1:i386:
  Installed: 1.0.4-1
  Candidate: 1.0.4-1
  Version table:
 *** 1.0.4-1 500
500 http://deb.debian.org/debian sid/main i386 Packages
100 /var/lib/dpkg/status

The following packages will be REMOVED: libhwy1

[Mathieu Malaterre]

Dear DD,

Could someone please review what I did wrong for src:highway. For some
reason I cannot install libhwy1:amd64 + libhwy1:i386 on my system:

% apt-cache policy libhwy1:amd64
libhwy1:
  Installed: 1.0.5-1
  Candidate: 1.0.5-1
  Version table:
 *** 1.0.5-1 500
500 http://deb.debian.org/debian sid/main amd64 Packages
100 /var/lib/dpkg/status

Gives:

 % sudo apt install libhwy1:i386
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
  libhwy1
The following NEW packages will be installed:
  libhwy1:i386
0 upgraded, 1 newly installed, 1 to remove and 0 not upgraded.
Need to get 512 kB of archives.
After this operation, 161 kB of additional disk space will be used.
Do you want to continue? [Y/n] n

Thanks !

ModuleNotFoundError: No module named 'vtkdicom.vtkDICOM'

[Mathieu Malaterre]

Dear Mentors,

I am looking for help on vtk-dicom package. Current issue is here (1),
repeated here:

autopkgtest [23:14:01]: test autodep8-python3: set -e ; for py in
$(py3versions -d 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo
"Testing with $py:" ; $py -c "import vtkdicom; print(vtkdicom)" ; done
autopkgtest [23:14:01]: test autodep8-python3: [---
Testing with python3.10:
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/vtkdicom/__init__.py", line 1,
in 
from .vtkDICOM import *
ModuleNotFoundError: No module named 'vtkdicom.vtkDICOM'

I did talk with upstream and I am using the correct python module
name. Indeed from my current sid64 schroot:

% python3
Python 3.11.1 (main, Dec 31 2022, 10:23:59) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import vtkdicom
>>> print(vtkdicom)


with

% apt-cache policy python3-vtk-dicom
python3-vtk-dicom:
  Installed: 0.8.14-3
  Candidate: 0.8.14-3
  Version table:
 *** 0.8.14-3 500
500 http://deb.debian.org/debian sid/main amd64 Packages
100 /var/lib/dpkg/status

autopkg test seems to be using python *3.10* while the python module
is built using *3.11*:

[...]
/usr/lib/python3/dist-packages/vtkdicom/vtkDICOM.cpython-311-x86_64-linux-gnu.so
[...]

What am I missing here ? My understanding of python module is quite limited.
Thanks !

(1) 
https://ci.debian.net/data/autopkgtest/testing/amd64/v/vtk-dicom/30492694/log.gz

Re: autopkgtest : s390x is considered regression but out of sync

[Mathieu Malaterre]

On Fri, Jan 13, 2023 at 8:14 AM Mathieu Malaterre  wrote:
>
> Hi there,
>
> On Fri, Oct 7, 2022 at 8:48 AM Mathieu Malaterre  wrote:
> >
> > Hi Paul !
> >
> > On Thu, Oct 6, 2022 at 9:59 AM Paul Wise  wrote:
> > >
> > > On Thu, 2022-10-06 at 09:18 +0200, Tobias Frost wrote:
> > >
> > > > Oh, sorry; I missed that you meant d/test/control…
> > > > (Though, Reading [1], I'm not sure if there is support for "!", but I
> > > > guess it is worth a try…)
> > >
> > > elbrus confirmed on #debci that ! is supported in d/t/c Architecture.
> >
> > Ok then, thanks for the update. I'll wait a bit more maybe "s390x: No
> > test results" will clear out at some point:
> >
> > https://tracker.debian.org/pkg/jpeg-xl
>
> This is a follow-up to my previous message. This time libjxl is build
> on s390x but the autopkgtest does not seems to see the new binaries:
>
> [...]
> E: Unable to locate package libjxl-devtools
> E: Unable to locate package libjpegxl-java
> run-unit-testFAIL badpkg
> [...]
>
> https://ci.debian.net/data/autopkgtest/testing/s390x/j/jpeg-xl/30151566/log.gz
>
> Is there anything I should be doing on my side ?

I found the 'retry' button. Let's see how it goes.

Sorry for the noise

autopkgtest : s390x is considered regression but out of sync

[Mathieu Malaterre]

Hi there,

On Fri, Oct 7, 2022 at 8:48 AM Mathieu Malaterre  wrote:
>
> Hi Paul !
>
> On Thu, Oct 6, 2022 at 9:59 AM Paul Wise  wrote:
> >
> > On Thu, 2022-10-06 at 09:18 +0200, Tobias Frost wrote:
> >
> > > Oh, sorry; I missed that you meant d/test/control…
> > > (Though, Reading [1], I'm not sure if there is support for "!", but I
> > > guess it is worth a try…)
> >
> > elbrus confirmed on #debci that ! is supported in d/t/c Architecture.
>
> Ok then, thanks for the update. I'll wait a bit more maybe "s390x: No
> test results" will clear out at some point:
>
> https://tracker.debian.org/pkg/jpeg-xl

This is a follow-up to my previous message. This time libjxl is build
on s390x but the autopkgtest does not seems to see the new binaries:

[...]
E: Unable to locate package libjxl-devtools
E: Unable to locate package libjpegxl-java
run-unit-testFAIL badpkg
[...]

https://ci.debian.net/data/autopkgtest/testing/s390x/j/jpeg-xl/30151566/log.gz

Is there anything I should be doing on my side ?

Thanks again
-M

src:jpeg-xl stuck in Needs-Build states / 7d

[Mathieu Malaterre]

[cc me please]

Hi there,

I am trying to understand why src:jpeg-xl is in Needs-Build state for
the past 7 days:

* https://buildd.debian.org/status/package.php?p=jpeg-xl=sid

I cannot remember where else I should be looking for a hint of this
state ? I tried there but did not see anything related to jpeg-xl:

* https://release.debian.org/britney/hints/

Thanks for your help !

hurd-i386: Right way to disable tests

[Mathieu Malaterre]

[cc me please]

Hi there,

I see that jpeg-xl test suite is running of out time hurd-i386:

* 
https://buildd.debian.org/status/fetch.php?pkg=jpeg-xl=hurd-i386=0.7.0-5=1664979667=0

What would be the "right" way to disable the test in d/rules ? Should
I inject nocheck ? Should I ifdef based on arch ?

Thanks

Re: autopkgtest : s390x is considered regression but never built

[Mathieu Malaterre]

Hi Paul !

On Thu, Oct 6, 2022 at 9:59 AM Paul Wise  wrote:
>
> On Thu, 2022-10-06 at 09:18 +0200, Tobias Frost wrote:
>
> > Oh, sorry; I missed that you meant d/test/control…
> > (Though, Reading [1], I'm not sure if there is support for "!", but I
> > guess it is worth a try…)
>
> elbrus confirmed on #debci that ! is supported in d/t/c Architecture.

Ok then, thanks for the update. I'll wait a bit more maybe "s390x: No
test results" will clear out at some point:

https://tracker.debian.org/pkg/jpeg-xl

Thanks all !

Re: autopkgtest : s390x is considered regression but never built

[Mathieu Malaterre]

On Thu, Oct 6, 2022 at 8:33 AM Tobias Frost  wrote:
>
> On Tue, Oct 04, 2022 at 09:02:07AM +0200, Mathieu Malaterre wrote:
> > On Tue, Oct 4, 2022 at 8:50 AM Mathieu Malaterre  wrote:
> > >
> > > [cc me please]
> > >
> > > Hi there,
> > >
> > > I am staring at the autopkgtest results for jpeg-xl:
> > >
> > > * https://tracker.debian.org/pkg/jpeg-xl
> > >
> > > It seems CI consider there is a regression for s390x:
> > >
> > > [...]
> > > Reading state information...
> > > E: Unable to locate package libjxl-tools
> > > [...]
> > >
> > > * 
> > > https://ci.debian.net/data/autopkgtest/testing/s390x/j/jpeg-xl/26649194/log.gz
> > >
> > > Is there a way to de-activate explicitly s390x from the default
> > > autpkgtest list ?
> >
> > I'll try a
> >
> > Architecture: !s390x
>
> The "!" syntax is not supported in Architecture:, you'd
> have to spell out all archs in d/control..

I stole the syntax from:

https://salsa.debian.org/toolchain-team/gcc/-/commit/1d32ce5e1a28d741e2bc97e5db7d0df5f330e058

> There was a recent discussion on -devel, and one suggestion [1]
> was to do something like:
>
>  Build-Depends: package-is-broken-on-ppc64el [ppc64el],...
>
> [1] https://lists.debian.org/debian-devel/2022/09/msg00293.html

oh, well. I'll try yet-another-cross-finger upload then

thanks !

Re: autopkgtest : s390x is considered regression but never built

[Mathieu Malaterre]

On Tue, Oct 4, 2022 at 8:50 AM Mathieu Malaterre  wrote:
>
> [cc me please]
>
> Hi there,
>
> I am staring at the autopkgtest results for jpeg-xl:
>
> * https://tracker.debian.org/pkg/jpeg-xl
>
> It seems CI consider there is a regression for s390x:
>
> [...]
> Reading state information...
> E: Unable to locate package libjxl-tools
> [...]
>
> * 
> https://ci.debian.net/data/autopkgtest/testing/s390x/j/jpeg-xl/26649194/log.gz
>
> Is there a way to de-activate explicitly s390x from the default
> autpkgtest list ?

I'll try a

Architecture: !s390x

Thanks,

autopkgtest : s390x is considered regression but never built

[Mathieu Malaterre]

[cc me please]

Hi there,

I am staring at the autopkgtest results for jpeg-xl:

* https://tracker.debian.org/pkg/jpeg-xl

It seems CI consider there is a regression for s390x:

[...]
Reading state information...
E: Unable to locate package libjxl-tools
[...]

* https://ci.debian.net/data/autopkgtest/testing/s390x/j/jpeg-xl/26649194/log.gz

Is there a way to de-activate explicitly s390x from the default
autpkgtest list ?

Thanks,

Re: gcc vs clang

[Mathieu Malaterre]

Answering myself

On Mon, Aug 22, 2022 at 5:28 PM Mathieu Malaterre  wrote:
>
> [cc me please]
>
> Hi there,
>
> I have a package stuck in sid because gcc-11 and above fails to
> compile what seems to be legit c++-11 code.
>
> Is it ok to switch to clang instead for the time being (with proper
> documentation in d/rules) ?

Seems like object files generated by clang are not support in the
python-debian world:

[...]
dwz: debian/libopenvdb-tools/usr/bin/vdb_view: Unknown debugging
section .debug_addr
dwz: Too few files for multifile optimization
dh_dwz: error: dwz
[...]

gcc vs clang

[Mathieu Malaterre]

[cc me please]

Hi there,

I have a package stuck in sid because gcc-11 and above fails to
compile what seems to be legit c++-11 code.

Is it ok to switch to clang instead for the time being (with proper
documentation in d/rules) ?

cmake: compat 11 vs 13 (-indep)

[Mathieu Malaterre]

[cc me please]

Symptoms:

I've recently discovered the following change in behavior for
dh_missing + cmake + -indep. Basically using compat 13 it is now an
error when build-indep rule install stuff other than just the -indep
files (1).

This means that the following d/rules is going to fails when using compat=13:

https://salsa.debian.org/multimedia-team/openvdb/-/blob/master/debian/rules

As you can see, during debuild -A I only build one target (not 'all'):

https://salsa.debian.org/multimedia-team/openvdb/-/blob/master/debian/rules#L94

In compat 13 I was able to take advantage of `make -C`:

https://salsa.debian.org/debian-phototools-team/imath/-/blob/master/debian/rules#L35-37

This 'trick' will fail if someone switch from --buildsystem=cmake into
--buildsystem=cmake+ninja.

---

Root issue. As far as I understand cmake install() command (2)
documentation, there is a single 'install' for the entire project. In
other words, it is not possible using regular cmake logic to do:

$ cmake . && make  doc && make install_doc_related_stuff_only

Could someone with better understanding of dh_missing + cmake please
review the above and suggest a potential better solution than my
correct "hack" of using `-C docs`. I could also remove stuff installed
in debian/tmp just before `dh_missing` is run, but this is also a
hack.

Thanks much in advance,

(1) 
https://buildd.debian.org/status/fetch.php?pkg=imath=amd64=3.1.3-7=1642087594=0
(2) https://cmake.org/cmake/help/latest/command/install.html

Re: Possible lex issue for ppc64el (Was: Bug#976906: libpll: FTBFS on ppc64el: lex_utree.l:22:10: fatal error: parse_utree.h: No such file or directory)

[Mathieu Malaterre]

"make -j160"

that would be my guess :)

remove parallel from the dh option, and try again (fixes symptoms)

On Thu, Dec 10, 2020 at 10:49 AM Andreas Tille  wrote:
>
> Control: tags -1 help
>
> Hi,
>
> I tried to investigate the situation below and my guess is that lex has
> somehow problems to create the missing header files.  I've found the
> files in upstreams .gitignore file so these need to be created but this
> does not seem to work on ppc64el (any more - since the package has build
> successfully before).
>
> Any hint to tackle this is welcome
>
>   Andreas.
>
> On Wed, Dec 09, 2020 at 09:37:42AM +0100, Lucas Nussbaum wrote:
> > Source: libpll
> > Version: 0.3.2-3
> > Severity: serious
> > Justification: FTBFS on ppc64el
> > Tags: bullseye sid ftbfs
> > Usertags: ftbfs-20201209 ftbfs-bullseye ftbfs-ppc64el
> >
> > Hi,
> >
> > During a rebuild of all packages in sid, your package failed to build
> > on ppc64el. At the same time, it did not fail on amd64.
> >
> > I'm marking this bug as severity:serious since your package currently has
> > ppc64el binary packages in unstable (so this is a regression).
> >
> > Relevant part (hopefully):
> > > /bin/bash ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
> > > -I..   -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE 
> > > -std=c99 -O3 -fPIC -g -c -o libpll_la-lex_utree.lo `test -f 'lex_utree.c' 
> > > || echo './'`lex_utree.c
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c fasta.c  -fPIC -DPIC -o .libs/libpll_la-fasta.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c pll.c  -fPIC -DPIC -o .libs/libpll_la-pll.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c likelihood.c  -fPIC -DPIC -o .libs/libpll_la-likelihood.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c maps.c  -fPIC -DPIC -o .libs/libpll_la-maps.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c output.c  -fPIC -DPIC -o .libs/libpll_la-output.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c utree.c  -fPIC -DPIC -o .libs/libpll_la-utree.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c utree_moves.c  -fPIC -DPIC -o .libs/libpll_la-utree_moves.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c models.c  -fPIC -DPIC -o .libs/libpll_la-models.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c parsimony.c  -fPIC -DPIC -o .libs/libpll_la-parsimony.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c core_partials.c  -fPIC -DPIC -o .libs/libpll_la-core_partials.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c derivatives.c  -fPIC -DPIC -o .libs/libpll_la-derivatives.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c utree_svg.c  -fPIC -DPIC -o .libs/libpll_la-utree_svg.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c gamma.c  -fPIC -DPIC -o .libs/libpll_la-gamma.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c rtree.c  -fPIC -DPIC -o .libs/libpll_la-rtree.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c list.c  -fPIC -DPIC -o .libs/libpll_la-list.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c partials.c  -fPIC -DPIC -o .libs/libpll_la-partials.o
> > > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC 
> > > -g -c 

Overwriting files and not replacing packages - (no Replaces)

[Mathieu Malaterre]

Dear mentors,

I have uploaded CharLS 2.1.0+dfsg-7 with a single Breaks statement (no
Replaces statement):

$ cat d/control
...
Breaks: libdcmtk-dev (<< 3.6.4-2.1)

In this specific case I do not need 'Replaces:' (*), because
'libcharls.so' from libdcmtk-dev is not meant to be replaced by the
one shipped in libcharls-dev (2.1.0+dfsg-7) (this is not the normal
breaks+replaces pattern).

Is my understanding correct?

(*) https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

Re: dh_link -p$(pkg_dev) usr/include/charls usr/include/CharLS

[Mathieu Malaterre]

On Tue, Nov 3, 2020 at 9:27 AM Sebastiaan Couwenberg  wrote:
>
> On 11/3/20 8:50 AM, Mathieu Malaterre wrote:
> > I am trying to use the following dh_link command:
> >
> > $ cat d/rules
> > [...]
> > dh_link -p$(pkg_dev) usr/include/charls usr/include/CharLS
> >
> > Which gives:
> >
> > $ dpkg -c ../libcharls-dev_2.1.0+dfsg-5_amd64.deb
> > [...]
> > lrwxrwxrwx root/root 0 2020-10-29 17:58 ./usr/include/CharLS -> 
> > charls
> >
> > It seems that the above *only* works (give expected results of
> > directory symlink) when there is no existing /usr/include/CharLS
> > directory.
> >
> > What is the right black magic to get a nice upgrade path for
> > libcharls-dev 2.0 (which provides a /usr/include/CharLS directory), to
> > libcharls-dev 2.1 which provides a /usr/include/CharLS symlink to
> > /usr/include/charls.
>
> dpkg-maintscript-helper dir_to_symlink may do what you want, see:
>
>  
> https://manpages.debian.org/unstable/dpkg/dpkg-maintscript-helper.1.en.html#Switching_a_directory_to_symlink

Full credit at dac981f ;)

Thanks

> Kind Regards,
>
> Bas
>
> --
>  GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

dh_link -p$(pkg_dev) usr/include/charls usr/include/CharLS

[Mathieu Malaterre]

[cc me please]

Dear mentors,

I am trying to use the following dh_link command:

$ cat d/rules
[...]
dh_link -p$(pkg_dev) usr/include/charls usr/include/CharLS

Which gives:

$ dpkg -c ../libcharls-dev_2.1.0+dfsg-5_amd64.deb
[...]
lrwxrwxrwx root/root 0 2020-10-29 17:58 ./usr/include/CharLS -> charls

It seems that the above *only* works (give expected results of
directory symlink) when there is no existing /usr/include/CharLS
directory.

What is the right black magic to get a nice upgrade path for
libcharls-dev 2.0 (which provides a /usr/include/CharLS directory), to
libcharls-dev 2.1 which provides a /usr/include/CharLS symlink to
/usr/include/charls.

Code is at:

https://salsa.debian.org/med-team/charls

Thanks for your help

d/watch: uscan for pixelmed-codec

[Mathieu Malaterre]

Hi uscan guru,

Could someone help me write (update actually) the d/watch file for
pixelmed-codec. The steps are:

* http://www.dclunie.com/pixelmed/software/codec/index.html
** 20200328_current
*** 
http://www.dclunie.com/pixelmed/software/codec/20200328_current/pixelmedjavacodec_sourcerelease.20200328.tar.bz2

How would/should one do this ?

Thanks,

Illegal seek Distribution field may be wrong!!!

[Mathieu Malaterre]

[cc me please]

Hi there,

Does anyone understand the following non-fatal error:

[...]
/<>/pixelmed_20200416-2_all-buildd.changes.new could not be
renamed to /<>/pixelmed_20200416-2_all-buildd.changes:
Illegal seek
Distribution field may be wrong!!!
[...]

ref:
* 
https://buildd.debian.org/status/fetch.php?pkg=pixelmed=all=20200416-2=1596440330=0

Thanks

sse4.2-support usage ?

[Mathieu Malaterre]

[cc me]

Hi mentors,

Could someone please point me to an example d/control where
sse4.2-support is used ?

Thanks

Re: uscan die: OpenPGP signature did not verify. at /usr/share/perl5/Devscripts/Uscan/Output.pm line 58.

[Mathieu Malaterre]

[cc me]

On Tue, Oct 1, 2019 at 9:00 AM Mathieu Malaterre  wrote:
>
> Hi there,
>
> Here is what I see when I try to update libkcapi upstream package
> (Debian/buster):
>
> $ uscan --verbose --force-download --rename
> [...]
> uscan info: Downloading OpenPGP signature from
>http://www.chronox.de/libkcapi/libkcapi-1.1.5.tar.xz.asc (pgpsigurlmangled)
>as libkcapi-1.1.5.tar.xz.asc
> uscan info: Requesting URL:
>http://www.chronox.de/libkcapi/libkcapi-1.1.5.tar.xz.asc
> uscan info: Verifying OpenPGP signature ../libkcapi-1.1.5.tar.xz.asc
> for ../libkcapi-1.1.5.tar.xz
> uscan info: Execute: gpgv --homedir /dev/null --keyring
> /tmp/VZrTWy04zw/trustedkeys.gpg ../libkcapi-1.1.5.tar.xz.asc
> ../libkcapi-1.1.5.tar.xz...
> gpgv: Signature made Wed 31 Jul 2019 10:01:53 AM CEST
> gpgv:using RSA key 3BCC43D4D2C87D1784B69EE4421EE936326AC15B
> gpgv: Can't check signature: No public key
> uscan die: OpenPGP signature did not verify. at
> /usr/share/perl5/Devscripts/Uscan/Output.pm line 58.
>
> Indeed there something that has changed with gpg:
>
> $ wget http://www.chronox.de/libkcapi/libkcapi-1.1.5.tar.xz.asc
> $ wget http://www.chronox.de/libkcapi/libkcapi-1.1.5.tar.xz
> $ gpg --verify libkcapi-1.1.5.tar.xz.asc
> gpg: assuming signed data in 'libkcapi-1.1.5.tar.xz'
> gpg: Signature made Wed 31 Jul 2019 10:01:53 AM CEST
> gpg:using RSA key 3BCC43D4D2C87D1784B69EE4421EE936326AC15B
> gpg: Can't check signature: No public key

Very very odd. Seems to be a server side issue.

$ gpg -vv --receive-keys  3BCC43D4D2C87D1784B69EE4421EE936326AC15B
gpg: data source: https://keys.openpgp.org:443
gpg: armor: BEGIN PGP PUBLIC KEY BLOCK
# off=0 ctb=c6 tag=6 hlen=3 plen=269 new-ctb
:public key packet:
version 4, algo 1, created 1521023736, expires 0
pkey[0]: [2048 bits]
pkey[1]: [17 bits]
keyid: 421EE936326AC15B
# off=272 ctb=ce tag=14 hlen=3 plen=269 new-ctb
:public sub key packet:
version 4, algo 1, created 1521023736, expires 0
pkey[0]: [2048 bits]
pkey[1]: [17 bits]
keyid: 1DFA16573D623177
# off=544 ctb=c2 tag=2 hlen=3 plen=310 new-ctb
:signature packet: algo 1, keyid 421EE936326AC15B
version 4, created 1521023736, md5len 0, sigclass 0x18
digest algo 8, begin of digest 13 c2
hashed subpkt 33 len 21 (issuer fpr v4 3BCC43D4D2C87D1784B69EE4421EE936326AC15B)
hashed subpkt 2 len 4 (sig created 2018-03-14)
hashed subpkt 27 len 1 (key flags: 20)
subpkt 16 len 8 (issuer key ID 421EE936326AC15B)
data: [2048 bits]
# off=857 ctb=ce tag=14 hlen=3 plen=269 new-ctb
:public sub key packet:
version 4, algo 1, created 1521023736, expires 0
pkey[0]: [2048 bits]
pkey[1]: [17 bits]
keyid: D1786B6EA5543FED
# off=1129 ctb=c2 tag=2 hlen=3 plen=310 new-ctb
:signature packet: algo 1, keyid 421EE936326AC15B
version 4, created 1521023736, md5len 0, sigclass 0x18
digest algo 8, begin of digest 96 38
hashed subpkt 33 len 21 (issuer fpr v4 3BCC43D4D2C87D1784B69EE4421EE936326AC15B)
hashed subpkt 2 len 4 (sig created 2018-03-14)
hashed subpkt 27 len 1 (key flags: 0C)
subpkt 16 len 8 (issuer key ID 421EE936326AC15B)
data: [2042 bits]
gpg: pub  rsa2048/421EE936326AC15B 2018-03-14
gpg: key 421EE936326AC15B: new key but contains no user ID - skipped
gpg: Total number processed: 1
gpg:   w/o user IDs: 1


But !

$ gpg --keyserver hkps.pool.sks-keyservers.net  --receive-keys
3BCC43D4D2C87D1784B69EE4421EE936326AC15B
gpg: key 421EE936326AC15B: public key "Stephan Mueller " imported
gpg: Total number processed: 1
gpg:   imported: 1

Everything is back in shape:

$ gpg libkcapi-1.1.5.tar.xz.asc
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
gpg: assuming signed data in 'libkcapi-1.1.5.tar.xz'
gpg: Signature made Wed 31 Jul 2019 10:01:53 AM CEST
gpg:using RSA key 3BCC43D4D2C87D1784B69EE4421EE936326AC15B
gpg: Good signature from "Stephan Mueller " [unknown]
gpg: aka "Stephan Mueller " [unknown]
gpg: aka "Stephan Mueller " [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 3BCC 43D4 D2C8 7D17 84B6  9EE4 421E E936 326A C15B


Donno what is wrong with https://keys.openpgp.org:443

> $ gpg --show-key libkcapi-1.1.5.tar.xz.asc
> gpg: no valid OpenPGP data found.
>
> Where:
>
> $ file libkcapi-1.1.5.tar.xz.asc
> libkcapi-1.1.5.tar.xz.asc: PGP signature Signature (old)
>
> I have not been able to find much help from the uscan documentation:
>
> https://wiki.debian.org/debian/watch#pgpsigurlmangle
>
> What did I miss ?
>
> Thanks for pointers,
>
> -M

uscan die: OpenPGP signature did not verify. at /usr/share/perl5/Devscripts/Uscan/Output.pm line 58.

[Mathieu Malaterre]

Hi there,

Here is what I see when I try to update libkcapi upstream package
(Debian/buster):

$ uscan --verbose --force-download --rename
[...]
uscan info: Downloading OpenPGP signature from
   http://www.chronox.de/libkcapi/libkcapi-1.1.5.tar.xz.asc (pgpsigurlmangled)
   as libkcapi-1.1.5.tar.xz.asc
uscan info: Requesting URL:
   http://www.chronox.de/libkcapi/libkcapi-1.1.5.tar.xz.asc
uscan info: Verifying OpenPGP signature ../libkcapi-1.1.5.tar.xz.asc
for ../libkcapi-1.1.5.tar.xz
uscan info: Execute: gpgv --homedir /dev/null --keyring
/tmp/VZrTWy04zw/trustedkeys.gpg ../libkcapi-1.1.5.tar.xz.asc
../libkcapi-1.1.5.tar.xz...
gpgv: Signature made Wed 31 Jul 2019 10:01:53 AM CEST
gpgv:using RSA key 3BCC43D4D2C87D1784B69EE4421EE936326AC15B
gpgv: Can't check signature: No public key
uscan die: OpenPGP signature did not verify. at
/usr/share/perl5/Devscripts/Uscan/Output.pm line 58.

Indeed there something that has changed with gpg:

$ wget http://www.chronox.de/libkcapi/libkcapi-1.1.5.tar.xz.asc
$ wget http://www.chronox.de/libkcapi/libkcapi-1.1.5.tar.xz
$ gpg --verify libkcapi-1.1.5.tar.xz.asc
gpg: assuming signed data in 'libkcapi-1.1.5.tar.xz'
gpg: Signature made Wed 31 Jul 2019 10:01:53 AM CEST
gpg:using RSA key 3BCC43D4D2C87D1784B69EE4421EE936326AC15B
gpg: Can't check signature: No public key

$ gpg --show-key libkcapi-1.1.5.tar.xz.asc
gpg: no valid OpenPGP data found.

Where:

$ file libkcapi-1.1.5.tar.xz.asc
libkcapi-1.1.5.tar.xz.asc: PGP signature Signature (old)

I have not been able to find much help from the uscan documentation:

https://wiki.debian.org/debian/watch#pgpsigurlmangle

What did I miss ?

Thanks for pointers,

-M

Re: Best way to patch a public header file before installation

[Mathieu Malaterre]

Hi Paul,

On Thu, Nov 8, 2018 at 2:53 AM Paul Wise  wrote:
>
> On Thu, Nov 8, 2018 at 4:14 AM Mathieu Malaterre wrote:
>
> > I'd like to patch a header file just before it gets installed. In
> > particular I'd like to remove a line that contains
> > ILMBASE_HAVE_CONTROL_REGISTER_SUPPORT (it is either #define or #undef
> > depending on the arch). This way I make sure that my header files are
> > arch independent.
>
> Sounds like something that should be fixed upstream.

I reported that already, but needed a fix for an existing release.

> As a workaround, run this in override_dh_auto_install:
>
> sed -i /ILMBASE_HAVE_CONTROL_REGISTER_SUPPORT/ debian/*/usr/include/*.h

Thanks, I should have thought about this myself.

> BTW, there are multi-arch dirs for arch-specific headers:
>
> /usr/include/x86_64-linux-gnu/

Long story short, I believe this fixes the symptoms and not the actual
bug. I would even go one step further and make that arch specific
include be restricted (Debian policy) to only a subset of packages
(gcc, libc...), since I fail to understand why there would be arch
specific information in public header (obviously for a package not
dealing with low level arch specific).
In my case, and I suspect in the vast majority of packages, this is
just lazy programming where a public header contains an implementation
detail that was used during the build but is meaningless to expose to
the final user.

-M

Best way to patch a public header file before installation

[Mathieu Malaterre]

[CC me please]

Hi there,

I'd like to patch a header file just before it gets installed. In
particular I'd like to remove a line that contains
ILMBASE_HAVE_CONTROL_REGISTER_SUPPORT (it is either #define or #undef
depending on the arch). This way I make sure that my header files are
arch independent.

Thanks for suggestion

-M

/boot/config-$(shell uname -r) on buildds ?

[Mathieu Malaterre]

Hi there,

Could someone please confirm that the config file:
/boot/config-$(shell uname -r) is not present on buildds ? Is there an
alternate way to grep the configuration of the running kernel ?

Bug#887870: RFS: pcc/1.2.0~DEVEL+20180120-1 [ITP]

[Mathieu Malaterre]

On Sun, Jan 21, 2018 at 1:19 PM, Yangfl  wrote:
> Hi,
>
> Sorry for including wrong deps. I've fixed them all and reuploaded the
> package into mentors.d.o.
>
> I'd like to mention that pcc alone *won't* work without the pcc-libs
> (which I've already packaged and tested). But I'd want pcc-libs to be
> built with pcc, so pcc must be uploaded prior to pcc-libs.

Are you saying that #638309 is still there then ?

$ pcc --version
Portable C Compiler 1.2.0.DEVEL 20171212 for x86_64-pc-linux-gnu
$ echo 'main() {}' > junk.c
$ pcc junk.c
/usr/bin/x86_64-linux-gnu-ld: cannot find crtbegin.o: No such file or directory
/usr/bin/x86_64-linux-gnu-ld: cannot find -lpcc
error: /usr/bin/x86_64-linux-gnu-ld terminated with status 1

Bug#887870: RFS: pcc/1.2.0~DEVEL+20180120-1 [ITP]

[Mathieu Malaterre]

Are you using the package ? I cannot even install it.

$ dget -u 
https://mentors.debian.net/debian/pool/main/p/pcc/pcc_1.2.0~DEVEL+20180120-1.dsc
$ cd pcc-1.2.0\~DEVEL+20180120
$ debuild
$ sudo dpkg -i ../pcc_1.2.0~DEVEL+20180120-1_amd64.deb
Selecting previously unselected package pcc.
(Reading database ... 483634 files and directories currently installed.)
Preparing to unpack .../pcc_1.2.0~DEVEL+20180120-1_amd64.deb ...
Unpacking pcc (1.2.0~DEVEL+20180120-1) ...
dpkg: dependency problems prevent configuration of pcc:
 pcc depends on pcc-for-x86-64-linux-gnu; however:
  Package pcc-for-x86-64-linux-gnu is not installed.

dpkg: error processing package pcc (--install):
 dependency problems - leaving unconfigured
Processing triggers for man-db (2.7.6.1-2) ...
Errors were encountered while processing:
 pcc

Testing kernel version and kernel modules for testing

[Mathieu Malaterre]

[CC me please]

Hi there,

I am debating whether or not I should be running the unit test of one
of my package: libkcapi.

I tried a naive solution:

$ cat debian/rules
[...]
KCAPI_RNG ?= $(shell grep CONFIG_CRYPTO_USER_API_RNG
/boot/config-$(shell uname -r) | cut -f2 -d=)
[...]
override_dh_auto_test-arch:
ifeq ($(KCAPI_RNG), m)
# required to be run within 'test' subdir:
(cd test ; ENABLE_FUZZ_TEST=1 NO_32BIT_TEST=1 ./test-invocation.sh)
endif

But that seems to be (totally!) inaccurate for buildds:

https://buildd.debian.org/status/fetch.php?pkg=libkcapi=amd64=1.0.2-2=1516386027=0

Since CONFIG_CRYPTO_USER_API_RNG is only available since bug 868291 I
am wondering if this makes sens to run the test suite or not ? Most
buildds do not seems to be running a kernel new enough anyway.

Comments/suggestions welcome

-M

Re: C++ help needed for new version of tifffile

[Mathieu Malaterre]

On Thu, Oct 5, 2017 at 9:56 PM, Sven Joachim  wrote:
> On 2017-10-05 21:00 +0200, Andreas Tille wrote:
>
>> I migrated the Debian packaging of tifffile from SVN to Git[1].  After
>> upgrading to the latest upstream version (dated 2017-09-14) I get:
>>
>> ...
>> x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall 
>> -Wstrict-prototypes -fno-strict-aliasing -g -O2 
>> -fdebug-prefix-map=/build/tifffile-20170914=. -fstack-protector-strong 
>> -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC 
>> -I/usr/lib/python2.7/dist-packages/numpy/core/include 
>> -I/usr/include/python2.7 -c tifffile.c -o 
>> build/temp.linux-x86_64-2.7/tifffile.o
>> tifffile.c:575:1: warning: return type defaults to 'int' [-Wimplicit-int]
>>  py_decodelzw(PyObject* obj, PyObject* args)
>>  ^~~~
>> tifffile.c: In function 'py_decodelzw':
>> tifffile.c:590:16: warning: return makes integer from pointer without a cast 
>> [-Wint-conversion]
>>  return NULL;
>> ^~~~
>> tifffile.c:634:9: error: expected identifier or '(' before 'if'
>>  if (code == 257) break;  /* end of information */
>>  ^~
>> tifffile.c:645:32: error: expected identifier or '(' before '}' token
>>  do { GET_NEXT_CODE } while (code == 256);
>> ^
>> tifffile.c:648:11: error: expected 'while' before 'else'
>>  } else {
>>^~~~
>> tifffile.c:704:9: error: expected identifier or '(' before 'if'
>>  if (code == 257) break;  /* end of information */
>>  ^~
>> tifffile.c:713:32: error: expected identifier or '(' before '}' token
>>  do { GET_NEXT_CODE } while (code == 256);
>> ^
>> ...
>>
>>
>> It seems that the definition of GET_NEXT_CODE is just wrong - but
>> what would be correct?
>
> Remove the last backslash, or include a blank line after it.  This
> prevents the "static PyObject*" line from becoming part of the macro
> definition.

Or use the latest upstream version. A mirror is at:

https://github.com/malaterre/tifffile/commit/f45cdfb5cc5f3f649d0c22e08254de0a97baf59c

HTH

uscan warning: pgpsigurlmangle option exists, but the upstream keyring does not exist

[Mathieu Malaterre]

[CC me please]

Hi all,

I am starring at my d/watch file and cannot understand what I did wrong.
I've copy/paste debian/watch from ilmbase into openexr, while it works for
ilmbase it is failing with openexr:

$ uscan --verbose
-- Scanning for watchfiles in .
-- Found watchfile in ./debian
-- In debian/watch, processing watchfile line:
   opts=pgpsigurlmangle=s/$/.sig/
http://download.savannah.gnu.org/releases/openexr/openexr-([\d\.]+)\.tar\.gz
uscan warning: pgpsigurlmangle option exists, but the upstream keyring does
not exist
  in debian/watch, skipping:

http://download.savannah.gnu.org/releases/openexr/openexr-([\d\.]+)\.tar\.gz
-- Scan finished


Everything seems -however- ok to me:

$ wget
http://download.savannah.gnu.org/releases/openexr/openexr-2.2.0.tar.gz
$ wget
http://download.savannah.gnu.org/releases/openexr/openexr-2.2.0.tar.gz.sig
$ gpg --verify openexr-2.2.0.tar.gz.sig
gpg: assuming signed data in `openexr-2.2.0.tar.gz'
gpg: Signature made Sun 10 Aug 2014 07:12:01 AM CEST using RSA key ID
AC103A8D
gpg: Good signature from Ed Hanway (OpenEXR Admin) ehan...@ilm.com
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the
owner.
Primary key fingerprint: D31B EF17 F9EA A92A F3C0  FD59 CE76 547B AC10 3A8D


Source code is at:

http://anonscm.debian.org/cgit/pkg-phototools/openexr.git

Thanks for comments

Re: uscan warning: pgpsigurlmangle option exists, but the upstream keyring does not exist

[Mathieu Malaterre]

On Mon, Jun 29, 2015 at 9:38 PM, Guilhem Moulin guil...@guilhem.org wrote:


 gpg --export-option export-minimal --armor --export \
   D31BEF17F9EAA92AF3C0FD59CE76547BAC103A8D
 debian/upstream/signing-key.asc


Thanks for the reminder :)

Re: Making a package multiarch (for real)

[Mathieu Malaterre]

On Thu, Nov 6, 2014 at 6:43 PM, Jakub Wilk jw...@debian.org wrote:
 Hi Mathieu,

 * Mathieu Malaterre ma...@debian.org, 2014-11-06, 18:10:

 [CC me please]


 [done!]

 $ sudo apt-get upgrade
 Reading package lists... Done
 Building dependency tree
 Reading state information... Done
 You might want to run 'apt-get -f install' to correct these.
 The following packages have unmet dependencies:
 libcharls1:i386 : Conflicts: libcharls1 but 1.0-5 is installed
 E: Unmet dependencies. Try using -f.


 My guess is that apt tries to upgrade your local package to the one in the
 archive. But that won't work, because the archive version lacks  the
 Multi-Arch field.

 Solution: don't reuse version numbers. :-)

Works nicely thanks much !


-- 
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/ca+7wuszpva+azxb5xsj9dhb4zovr5mbazd2ekghk-grkxvv...@mail.gmail.com

Re: Making a package multiarch (for real)

[Mathieu Malaterre]

On Thu, Nov 6, 2014 at 6:57 PM, Wookey woo...@wookware.org wrote:
 +++ Mathieu Malaterre [2014-11-06 18:10 +0100]:
 [CC me please]

 I am trying to make CharLS a true multiarch capable package. However I
 fail to understand what I did wrong.

 Steps:
 $ apt-get source charls
 $ cd charls-1.0
 $ vim debian/control
 - mark libcharls-dev as `Multi-Arch: foreign` and libcharls1 as
 `Multi-Arch: same`

 In general -dev packages should be :same, along with the library
 packages, then -dev packages for build and host arches can be
 co-installed for cross-compiling. I know the docs are out of date on
 this point, but please do both unless it is difficult for some reason.

Ok. I'll upload new charls packages with Multiarch: same set on both
-dev and real shared lib package. Thanks for the clarification.

-M


-- 
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/ca+7wusyybzztkzzygax6iqmwt3z9kvvb-nhfcaqqyp7ab7q...@mail.gmail.com

Making a package multiarch (for real)

[Mathieu Malaterre]

[CC me please]

I am trying to make CharLS a true multiarch capable package. However I
fail to understand what I did wrong.

Steps:
$ apt-get source charls
$ cd charls-1.0
$ vim debian/control
- mark libcharls-dev as `Multi-Arch: foreign` and libcharls1 as
`Multi-Arch: same`

Build on both amd64 and i386:

$ dpkg -I libcharls1_1.0-5_amd64.deb | grep same
 Multi-Arch: same
$ dpkg -I libcharls1_1.0-5_i386.deb | grep same
 Multi-Arch: same

shared lib are using proper multiarch paths:

$ dpkg -c libcharls1_1.0-5_amd64.deb
drwxr-xr-x root/root 0 2014-11-06 17:53 ./
drwxr-xr-x root/root 0 2014-11-06 17:53 ./usr/
drwxr-xr-x root/root 0 2014-11-06 17:53 ./usr/share/
drwxr-xr-x root/root 0 2014-11-06 17:53 ./usr/share/doc/
drwxr-xr-x root/root 0 2014-11-06 17:53 ./usr/share/doc/libcharls1/
-rw-r--r-- root/root   750 2014-11-06 16:23
./usr/share/doc/libcharls1/changelog.Debian.gz
-rw-r--r-- root/root  1860 2014-11-06 16:23
./usr/share/doc/libcharls1/copyright
drwxr-xr-x root/root 0 2014-11-06 17:53 ./usr/lib/
drwxr-xr-x root/root 0 2014-11-06 17:53 ./usr/lib/x86_64-linux-gnu/
-rw-r--r-- root/root198824 2014-11-06 17:53
./usr/lib/x86_64-linux-gnu/libCharLS.so.1.0
lrwxrwxrwx root/root 0 2014-11-06 17:53
./usr/lib/x86_64-linux-gnu/libCharLS.so.1 - libCharLS.so.1.0

and:

$ dpkg -c libcharls1_1.0-5_i386.deb
drwxr-xr-x root/root 0 2014-11-06 17:54 ./
drwxr-xr-x root/root 0 2014-11-06 17:54 ./usr/
drwxr-xr-x root/root 0 2014-11-06 17:54 ./usr/share/
drwxr-xr-x root/root 0 2014-11-06 17:54 ./usr/share/doc/
drwxr-xr-x root/root 0 2014-11-06 17:54 ./usr/share/doc/libcharls1/
-rw-r--r-- root/root   750 2014-11-06 16:23
./usr/share/doc/libcharls1/changelog.Debian.gz
-rw-r--r-- root/root  1860 2014-11-06 16:23
./usr/share/doc/libcharls1/copyright
drwxr-xr-x root/root 0 2014-11-06 17:54 ./usr/lib/
drwxr-xr-x root/root 0 2014-11-06 17:54 ./usr/lib/i386-linux-gnu/
-rw-r--r-- root/root198060 2014-11-06 17:54
./usr/lib/i386-linux-gnu/libCharLS.so.1.0
lrwxrwxrwx root/root 0 2014-11-06 17:54
./usr/lib/i386-linux-gnu/libCharLS.so.1 - libCharLS.so.1.0


Install:

$ sudo dpkg -i libcharls1_1.0-5_amd64.deb libcharls1_1.0-5_i386.deb
(Reading database ... 252480 files and directories currently installed.)
Preparing to unpack libcharls1_1.0-5_amd64.deb ...
Unpacking libcharls1:amd64 (1.0-5) over (1.0-5) ...
Preparing to unpack libcharls1_1.0-5_i386.deb ...
Unpacking libcharls1:i386 (1.0-5) over (1.0-5) ...
Setting up libcharls1:amd64 (1.0-5) ...
Setting up libcharls1:i386 (1.0-5) ...
Processing triggers for libc-bin (2.19-12) ...

But then:

$ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run 'apt-get -f install' to correct these.
The following packages have unmet dependencies:
 libcharls1:i386 : Conflicts: libcharls1 but 1.0-5 is installed
E: Unmet dependencies. Try using -f.


How do I get a detailed diagnosis of the conflicting files ?


-- 
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/CA+7wUszc=5cp_yy+wroxmorr3mgajogx8w4yrtznh4ky19+...@mail.gmail.com

iipimage-server: unknown substitution variable ${shlibs:Depends}

[Mathieu Malaterre]

hi,

for some reason, if I recompile iipimage from a sid chroot I keep
getting a warning:

[...]
dpkg-gencontrol: warning: Depends field of package iipimage-server:
unknown substitution variable ${shlibs:Depends}
[...]

It did worked well in the past. Now even libc is not part of the
Depends fields. Does anyone see anything wrong in the iipimage package
? Thanks.

Steps:

$ schroot -c sid
$ apt-get source iipimage
$ cd iipimage-0.9.9
$ dpkg-buildpackage -rfakeroot -us -uc
[...]


-- 
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/ca+7wusxpr2rvb71cqxzgxoqcvq97cqs9gpgxkmx3tbpzbn2...@mail.gmail.com

Same binary package / different source package

[Mathieu Malaterre]

[CC me please]

Hi,

I am trying to solve:

https://bugs.debian.org/760874

Clearly my plan in the long term is to have src:openjpeg2 superseed
src:openjpeg. However most package currently rely on src:openjpeg API
to compile. src:openjpeg2 does break most package in debian archive.

Would that be ok if I rename src:openjpeg2 binary packages to have a
different name (technically even the cli tools from openjpeg have been
renamed) from those of src:openjpeg ? This will make some users doing
an upgrade (in the distant future) unhappy, but it will solve the
current conflict.

Any suggestion appreciated.


-- 
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/ca+7wusyuxjnvkkbjtpoersr1yhpzkup+ngqviqq-b3ituw+...@mail.gmail.com

Bug#752897:

[Mathieu Malaterre]

Hi,

On Tue, Aug 26, 2014 at 9:30 PM, Tobias Frost t...@debian.org wrote:
 Malat, this is great, but could you also drop a note to the BTS if you
 are doing that to avoid double work, especially if there is activiy and
 the owner of the RFS-bug has been set to indicate that someone is
 working on it.. Thanks ;).

I understood from Gianfranco that no sponsor was available and did not
took the time to check for an opened RFS. I'll leave you guys handle
the new upload.

Sorry for the troubles :(


-- 
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/ca+7wusz6hsdwwjdf33q-okfpzjvkhygdluujrmu3vzadboq...@mail.gmail.com

Improper shared lib package (SONAME contains python version)

[Mathieu Malaterre]

Dear all,

  I am starring at the libvtk6 package:

https://packages.debian.org/sid/amd64/libvtk6/filelist

  This package provides 363 shared lib (SOVERSION set to the same
value). However as per policy:

https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-runtime

[...]
If you have several shared libraries built from the same source tree,
you may lump them all together into a single shared library package
provided that all of their SONAMEs will always change together. Be
aware that this is not normally the case, and if the SONAMEs do not
change together, upgrading such a merged shared library package will
be unnecessarily difficult because of file conflicts with the old
version of the package. When in doubt, always split shared library
packages so that each binary package installs a single shared library.
[...]

Reading this section make me feel that lib such as:

$ readelf -d libvtkImagingColorPython27D-6.1.so.6.1.0

Dynamic section at offset 0xa020 contains 32 entries:
  TagType Name/Value
 0x0001 (NEEDED) Shared library:
[libvtkImagingColor-6.1.so.6.1]
 0x0001 (NEEDED) Shared library:
[libvtkWrappingPython27Core-6.1.so.6.1]
 0x0001 (NEEDED) Shared library:
[libvtkImagingCorePython27D-6.1.so.6.1]
 0x0001 (NEEDED) Shared library:
[libvtkCommonExecutionModelPython27D-6.1.so.6.1]
 0x0001 (NEEDED) Shared library: [libpython2.7.so.1.0]
 0x0001 (NEEDED) Shared library:
[libvtkCommonCore-6.1.so.6.1]
 0x0001 (NEEDED) Shared library: [libstdc++.so.6]
 0x0001 (NEEDED) Shared library: [libc.so.6]
 0x000e (SONAME) Library soname:
[libvtkImagingColorPython27D-6.1.so.6.1]


Should be removed from the package since the SONAME will change when
python 2.7 will not be the default python version (for example).
Indeed the SONAME contains the Python version (per upstream
convention).

However the debian policy does not make it a strict requirement.

Comments ?


-- 
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/CA+7wUswrC4cTV=u1zbl265eo7reijul+qubhgl9_u3anudn...@mail.gmail.com

Re: library linking, missing libB.so

[Mathieu Malaterre]

Hi,

On Wed, Mar 26, 2014 at 10:12 AM, Nico Schlömer
nico.schloe...@gmail.com wrote:
 I consider this as an important[*] bug. People should not
 know about the low level LAPACK/ BLAS implementation.

 That's right. I already checked back with the CMake crowd (the
 critical lines are automatically created by CMake) and we might find

Well it is automatically generated by CMake, *because* you told it so.
Just set the LINK_INTERFACE_LIBRARIES properties of libA to empty.

 ourselves in a little bit of a tricky situation here: If a library
 libA is merely linked against libB, we of course don't want to know
 about the implementation details of libB.
 If the headers in libA-dev include something of libA-dev though,
 libA-dev should depend on libB-dev. Correct?

Rephrasing the second 'libA-dev' in 'libB-dev']

Yes, it's a *should* (well really a *must*)

 If the headers of libB-dev only appear in the sources of libA, i.e.,
 libA doesn't provide an interface to libB, libA-dev should *not*
 depend on libB-dev. Correct?

*should* is a little strong here. But really libA should not be
pulling the whole world, so yes, please restrict to the minimum dep.

 Right now, the dependency structure in debian/control looks like

 libA:
 Depends: ${shlibs:Depends}, ${misc:Depends}

 libA-dev:
 Depends: libA (= ${binary:Version}), ${shlibs:Depends},
 ${misc:Depends}, libB-dev

Ok then. this happens sometimes.

 Would you consider this sane? Will whatever magic acts in
 ${shlibs:Depends}, ${misc:Depends} be able to identify libB as a
 dependency of libA?

That's the magic behind ${shlibs:Depends}. It will read the output of
`readelf -d` to figure that (magic is lot less fun when you know the
tricks) [*].

2cts
[*] black magic will even generate proper version dependencies
figuring out which minimum version is required :-P


--
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/ca+7wuszpk1xwapyfrjk13i+etotswvzrpjsse_xkmk14rpv...@mail.gmail.com

Re: library linking, missing libB.so

[Mathieu Malaterre]

On Sat, Mar 22, 2014 at 1:31 PM, Nico Schlömer nico.schloe...@gmail.com wrote:
 No, the 'linker' does not complain.

 You're right, it is the CMake dependency checker. The linking is all
 right, but there's something amiss with the CMake export files. I'll
 investigate.

I think you should find online reference with those keywords cmake
transitive linking debian

If you have access to upstream source, simply set the target properties with:
set_properties(target LINK_INTERFACE_LIBRARIES )


--
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/CA+7wUszÐykthyrvyogwq-nasgokbbd9kmfwsu5ue2voaw...@mail.gmail.com

Re: library linking, missing libB.so

[Mathieu Malaterre]

On Mon, Mar 24, 2014 at 11:18 AM, Nico Schlömer
nico.schloe...@gmail.com wrote:
 Thanks for the hints!

 If you have access to upstream source, simply set the target properties with:
 set_properties(target LINK_INTERFACE_LIBRARIES )

 I might. The culprit right now are CMake property settings of the kind
 ```
 set_target_properties(teuchosnumerics PROPERTIES
   IMPORTED_LINK_INTERFACE_LIBRARIES_RELWITHDEBINFO
 teuchoscomm;teuchoscore;/usr/lib/liblapack.so;/usr/lib/libblas.so
   IMPORTED_LOCATION_RELWITHDEBINFO
 ${_IMPORT_PREFIX}/lib/libteuchosnumerics.so.11.7
   IMPORTED_SONAME_RELWITHDEBINFO libteuchosnumerics.so.11
   )
 ```
 where references to /usr/lib/liblapack.so (from lapack-dev) appear
 needlessly. Those files are created automatically by CMake, but I'll
 check if we can influence those in any way. Otherwise I'll just patch
 the export files directly.

I would suggest you report this as a bug to 'teuchosnumerics' debian
package. I consider this as an important[*] bug. People should not
know about the low level LAPACK/ BLAS implementation.

[*] Technically this would make your package FTBFS in some case, so
severity 'serious' could even be used.


--
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/CA+7wUswHAqxfVD+UU9TnAYpo8QusG5Q68V=jzluqg2j-ltf...@mail.gmail.com

Re: library linking, missing libB.so

[Mathieu Malaterre]

Hi

On 3/20/14, Nico Schlömer nico.schloe...@gmail.com wrote:
 I'm building a package for a library A that depends on another
 library, libB.so (from its dev-version). When installing library A,
 the package libb is installed, containing libB.so.7.2 and libB.so.7.
 When linking an executable against libA.so, the linker rightfully
 complains about a missing libB.so.

No, the 'linker' does not complain.

 What is the correct fix here?

You should check your build system. It seems to be broken. libB is an
implementation details of libA. Application programmer linking to libA
should *not* know about those low level technical details. Unless of
course explicitely stated in the documentation and/or provided in the
*.pc file (or cmake exported file). So unless you know what you are
doing libB should not appear on the link line.

In any case if you have an application using libA API, but complains
about missing libB symbols, you have a case where libA is underlinked
which is a serious issue and should not happen in debian package.


--
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/CA+7wUszFEC=nbkjkhqrzq3mvmv-qwsownuyhl4kp3szyyau...@mail.gmail.com

Re: public extension linked with libpython* vs. -Wl,-no-undefined

[Mathieu Malaterre]

On Tue, Mar 18, 2014 at 12:05 AM, Nico Schlömer
nico.schloe...@gmail.com wrote:
 Understood, thanks!

 I'll just ignore the warnings of the type
 ```
 dpkg-shlibdeps: warning:
 debian/python-pytrilinos/usr/lib/python2.7/dist-packages/PyTrilinos/NOX/_Abstract.so
 contains an unresolvable reference to symbol PyString_FromFormat: it's
 probably a plugin.
 ```
 then.

I am pretty sure that you should not ignore this warning. Could you
please send the output of:

$ readelf -d 
debian/python-pytrilinos/usr/lib/python2.7/dist-packages/PyTrilinos/NOX/_Abstract.so

Thx


--
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/CA+7wUsw=cl4kpmbua2_7dmf8zmuejii80sgrh-mhe7zcnbg...@mail.gmail.com

Preparing openjpeg 2.0

[Mathieu Malaterre]

Hi,

  I am preparing to upload openjpeg 2.0. This is a major API (yes API)
change from previous openjpeg 1.x. I am thinking of doing something
similar to gtk+1.2 and gtk+2.0. Basically we will have two source
packages src:openjpeg and src:openjpeg2 until people move to newer
(better!) API.

  Other people have handled it the other way around. See tiff3 package
that was created only for a short timeframe.

  Which way should I go:

1. Upload a src:openjpeg1 which will contains the legacy openjpeg 1.x
branch and src:openjepg will get openjpeg 2.x or
2. Upload a new src:openjpeg2 with the goal to get rid of src:openjpeg
in a couple of debian release.

Thanks for comments,


-- 
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/ca+7wuszkkwe63ohdxvjusqdboxaop7q-9rrz3frgkr3umor...@mail.gmail.com

Re: Preparing openjpeg 2.0

[Mathieu Malaterre]

In case debian-release is reading this

On Tue, Mar 18, 2014 at 5:39 PM, Mathieu Malaterre ma...@debian.org wrote:
[...]
 1. Upload a src:openjpeg1 which will contains the legacy openjpeg 1.x
 branch and src:openjepg will get openjpeg 2.x or

This is *future* plans, I am not going to trash the current openjpeg transition.


-- 
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/ca+7wuszk6oxpfy9camesb4o5dnw0bh2qzzs9va0kl2+zw3d...@mail.gmail.com

Re: public extension linked with libpython* vs. -Wl,-no-undefined

[Mathieu Malaterre]

On Mon, Mar 17, 2014 at 3:49 PM, Nico Schlömer nico.schloe...@gmail.com wrote:
 $ readelf -d /path/to/_ML.so
 [...]
  0x0001 (NEEDED) Shared library: [libpython2.7.so.1.0]
 [...]

 but when I don't, builds with -Wl,-no-undefined will fail.

Well then do not use -Wl,-no-undefined. You are building a python
*module*, not a *shared lib* (SONAME is set) where all symbols needs
to get resolved (as per Debian policy).

2cts


--
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/ca+7wusybruk-pgrj64zg7fsl72xq05ismbrarhjh1xhvanr...@mail.gmail.com

Bug#740982: liblas does not build

[Mathieu Malaterre]

On Fri, Mar 7, 2014 at 8:10 AM, Andreas Tille andr...@an3as.eu wrote:
 /usr/include/boost/atomic/atomic.hpp:202:16: error: 'uintptr_t' was not 
 declared in this scope
  typedef atomicuintptr_t atomic_uintptr_t;

That really looks like:
https://lists.debian.org/debian-med/2014/02/msg00269.html

What version of boost are you using ?


-- 
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/ca+7wusy_thwjhborgewodbp-mj5u-ab0+hrjan1-aahileu...@mail.gmail.com

Re: RFS: read-edid/3.0.1-2

[Mathieu Malaterre]

On Fri, Feb 14, 2014 at 12:55 PM, Dariusz Dwornikowski
dariusz.dwornikow...@cs.put.poznan.pl wrote:
 Ok I created such code in rules:

 override_dh_auto_configure:
 ifeq ($(DEB_HOST_ARCH), $(filter $(DEB_HOST_ARCH),amd64 i386))
   dh_auto_configure -- -DCLASSICBUILD=YES -DI2CBUILD=YES
 else
   dh_auto_configure -- -DI2CBUILD=NO -DCLASSICBUILD=YES
 endif

 Can somebody review it for me ? I checked and it works on amd64 and i386.

I don't think this works for -say- kfreebsd-amd64, which would require
-DI2CBUILD=OFF
You need to handle each option independantly, depending on arch

2cts


-- 
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/ca+7wusxvmc3vlsksnyu9svopz8dw-aps+rmqpfs5egod7uq...@mail.gmail.com

Re: RFS: read-edid/3.0.1-2

[Mathieu Malaterre]

In which case you would need to have -DCLASSICBUILD=ON on
ksfreebsd-amd64 if I understand the previous exchange correctly.

On Fri, Feb 14, 2014 at 1:07 PM, Dariusz Dwornikowski
dariusz.dwornikow...@cs.put.poznan.pl wrote:
 I did not include the line, I take DEB_HOST_ARCH from:
 DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH)

 So on ksfreebsd-amd64 it will give me: ksfreebsd-amd64, so DI2CBUILD would
 be set to NO. Or is it not ?


 On 14 February 2014 12:59, Mathieu Malaterre mathieu.malate...@gmail.com
 wrote:

 On Fri, Feb 14, 2014 at 12:55 PM, Dariusz Dwornikowski
 dariusz.dwornikow...@cs.put.poznan.pl wrote:
  Ok I created such code in rules:
 
  override_dh_auto_configure:
  ifeq ($(DEB_HOST_ARCH), $(filter $(DEB_HOST_ARCH),amd64 i386))
dh_auto_configure -- -DCLASSICBUILD=YES -DI2CBUILD=YES
  else
dh_auto_configure -- -DI2CBUILD=NO -DCLASSICBUILD=YES
  endif
 
  Can somebody review it for me ? I checked and it works on amd64 and
  i386.

 I don't think this works for -say- kfreebsd-amd64, which would require
 -DI2CBUILD=OFF
 You need to handle each option independantly, depending on arch

 2cts




 --
 Pozdrawiam,
 Dariusz Dwornikowski, Assistant
 Institute of Computing Science, Poznań University of Technology
 www.cs.put.poznan.pl/ddwornikowski/
 room 2.7.2 BTiCW | tel. +48 61 665 29 41




-- 
Mathieu


--
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/CA+7wUsx0hc-d-GazozqK0ES9njuDBpgPqib01juPi0=vojd...@mail.gmail.com

Re: RFS: read-edid/3.0.1-2

[Mathieu Malaterre]

Hi,

Okay I did not read your code carefully. You need to handle a matrix
of 4 cases, where only 2 were shown in your code. The actual counter
example was:  -DCLASSICBUILD=YES and powerpc. Please handle powerpc
(any non-x86 actually) in your if statement. sorry for the confusion
with kfreebsd-*

Thanks.

On Fri, Feb 14, 2014 at 1:20 PM, Dariusz Dwornikowski
dariusz.dwornikow...@cs.put.poznan.pl wrote:
 And I think it is set. It is the else clause. ksfreebsd-amd64 will be
 caught there and -DI2CBUILD=NO -DCLASSICBUILD=YES will be set.

 I think I am a little confused now.


 On 14 February 2014 13:12, Mathieu Malaterre mathieu.malate...@gmail.com
 wrote:

 In which case you would need to have -DCLASSICBUILD=ON on
 ksfreebsd-amd64 if I understand the previous exchange correctly.

 On Fri, Feb 14, 2014 at 1:07 PM, Dariusz Dwornikowski
 dariusz.dwornikow...@cs.put.poznan.pl wrote:
  I did not include the line, I take DEB_HOST_ARCH from:
  DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH)
 
  So on ksfreebsd-amd64 it will give me: ksfreebsd-amd64, so DI2CBUILD
  would
  be set to NO. Or is it not ?
 
 
  On 14 February 2014 12:59, Mathieu Malaterre
  mathieu.malate...@gmail.com
  wrote:
 
  On Fri, Feb 14, 2014 at 12:55 PM, Dariusz Dwornikowski
  dariusz.dwornikow...@cs.put.poznan.pl wrote:
   Ok I created such code in rules:
  
   override_dh_auto_configure:
   ifeq ($(DEB_HOST_ARCH), $(filter $(DEB_HOST_ARCH),amd64 i386))
 dh_auto_configure -- -DCLASSICBUILD=YES -DI2CBUILD=YES
   else
 dh_auto_configure -- -DI2CBUILD=NO -DCLASSICBUILD=YES
   endif
  
   Can somebody review it for me ? I checked and it works on amd64 and
   i386.
 
  I don't think this works for -say- kfreebsd-amd64, which would require
  -DI2CBUILD=OFF
  You need to handle each option independantly, depending on arch
 
  2cts
 
 
 
 
  --
  Pozdrawiam,
  Dariusz Dwornikowski, Assistant
  Institute of Computing Science, Poznań University of Technology
  www.cs.put.poznan.pl/ddwornikowski/
  room 2.7.2 BTiCW | tel. +48 61 665 29 41
 



 --
 Mathieu




 --
 Pozdrawiam,
 Dariusz Dwornikowski, Assistant
 Institute of Computing Science, Poznań University of Technology
 www.cs.put.poznan.pl/ddwornikowski/
 room 2.7.2 BTiCW | tel. +48 61 665 29 41




-- 
Mathieu


--
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/CA+7wUsy8Rd9nwvQ5buPqy+9Vqxc2=1mcuxwqd9os4zdibhs...@mail.gmail.com

Re: continue on a failing test (dh7)

[Mathieu Malaterre]

override_dh_auto_test:
  dh_auto_test || true

On Tue, Feb 11, 2014 at 5:16 PM, Roelof Wobben rwob...@hotmail.com wrote:
 Hello,

 Is there a way with dh7 to continue the build even if a test is failing ?

 Roelof

 --
 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/dub121-w18095c0416b3bd37e5ececae...@phx.gbl




-- 
Mathieu


-- 
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/CA+7wUszZEHJ1nETJMwGWmES73SLYHBBd43_vh=ts6eiw9ug...@mail.gmail.com

Bug#732758: RFS: chrony/1.29-1 [ITA, RC] -- Set the computer clock from time servers

[Mathieu Malaterre]

On Sat, Dec 21, 2013 at 10:37 AM, Joachim Wiedorn ad_deb...@joonet.de wrote:
 Package: sponsorship-requests
 Severity: important

 Dear mentors,

 I am looking for a sponsor for my package chrony

Uploaded, thanks very much for your contribution !

-M


-- 
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/ca+7wusxa0xfwm-xvqodoajpc+e04m1kg-dtpt0udrf3wzwf...@mail.gmail.com

Re: [Help] code is using openmp, but does not set gcc flags

[Mathieu Malaterre]

On Thu, Dec 19, 2013 at 9:23 AM, Andreas Tille andr...@an3as.eu wrote:
 tags 721931 help
 thanks

 Hi,

 in Debian Med team we do not have any clue how to fix #721931.

I do.

I use the BTS to log bugs as I discover them, and will fix them ASAP.
The openmp flag is simply commented out in the build system (from
memory)

2cts


-- 
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/ca+7wusw6phfprhp9upovwhaegca9u-+fuvdep3tmgok5gs4...@mail.gmail.com

Debian package from a bzr checkout

[Mathieu Malaterre]

Hi,

  I would like to prepare a package from a code source that is
currently only delivered from a bazar repository. What did people use
for package version naming convention ?

  If that matter the code is on Launchpad

Thanks,


-- 
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/ca+7wuszrqcd2+_z1b6_q8w5f6e4pddcme+hebxig0y8esmx...@mail.gmail.com

(uscan) Files-Excluded mecanism documentation ?

[Mathieu Malaterre]

It looks like uscan is now able to remove some files automatically, as per:

http://bugs.debian.org/685787

However I fail to see where this new mecanism is being documented. I
am starring at:

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

with no luck so far.

Thanks for comments,


-- 
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/ca+7wuswdpipzp7tjka9tckqnoxbdhurs8mwqkzicvbxpnnb...@mail.gmail.com

Re: Watchfile (and version numbers) for a braindead scheme

[Mathieu Malaterre]

Hi,

On Wed, Nov 27, 2013 at 2:29 PM, Olе Streicher
debian-de...@liska.ath.cx wrote:
 I want to write a watch file for the esomidas package, which has
 download URLs like

 ftp://ftp.eso.org/pub/midaspub/13SEP/sources/13SEPpl1.1.tar.gz

 (12 is the two-digit year, FEB the month of the release). I have some
 problems with it:

 1. What should the version number look like for Debian? 13.09.1.1?

 2. How do I convert these Month names into a number?

 3. How can I access the subdirectory and search there for the same name?

 Upstream will not change name or directory structure at all, since the
 structure is such since 15 years.

Here is what I have for mrmpi:

http://anonscm.debian.org/viewvc/debian-science/packages/mrmpi/trunk/debian/watch?view=markup

Kudos to Bart Martens for the months translation code.


--
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/CA+7wUsybqzsZ5kyQgCOe2vphSqRXQgn+qGh=5tnamanwva6...@mail.gmail.com

Bug#728292: sane-backends

[Mathieu Malaterre]

Hi,

  What is the status of sane backends in mentors ? I see at least a
lintian error.

license-problem-gfdl-invariants
- http://mentors.debian.net/package/sane-backends

Thanks,


-- 
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/ca+7wuszm8zvlnyabr5oy915ghfgxjxq9khpjyev0v2veavv...@mail.gmail.com

Bug#715142: E: ocrodjvu: bad-provided-package-name python:any

[Mathieu Malaterre]

Hi,

  I am trying to sponsor ocrodjvu but if I build it in a recent
sid/chroot here is what I see:

$ lintian -I 
/tmp/d/d/ocrodjvu-0.7.16/../build-area/ocrodjvu_0.7.16-1_amd64.changes
E: ocrodjvu: bad-provided-package-name python:any
I: ocrodjvu: spelling-error-in-manpage
usr/share/man/man1/ocrodjvu.1.gz specifing specifying

  Would it be possible to have this fixed ?

Thanks,


-- 
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/ca+7wusyeoprctv3exhxxyjjmz2daw+ameyqz+xmwdssiqgk...@mail.gmail.com

Re: RFS: nfft -- Library for computing Non-uniform Fast Fourier Transforms

[Mathieu Malaterre]

[cross posting to debian mentors since multiple requests]

On Tue, Oct 8, 2013 at 9:47 AM, Ghislain Vaillant ghisv...@gmail.com wrote:
 Hello everyone,

 Following the ITP filed here:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725705

Could you please update your package and indicate why:
- your d/control needs dh-exec
- your d/rules needs autoreconf

thanks,


-- 
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/CA+7wUswUe+9iGtvROjkzMbTA6_10zvE_bObc438O=hg-yfu...@mail.gmail.com

(override) dh_compress

[Mathieu Malaterre]

Hi,

  I am trying to skip the dh_compress steps for the following package:

http://packages.debian.org/sid/all/tbb-examples/filelist

  Instead of manually checking all possible combinations (-Xcpp
-Xpbxproj, -Xvcproj ... ), I thought I could just do:

$ cat debian/rules
...
# Makefiles should not be compressed (tbb-examples)
override_dh_compress-indep:

  Technically this is adapted from the dh man page. However this is an
error *not* to compress debian changelog.

  What would you do:

- fill a bug report to dh, at least get the man page fixed ?
- grep all possible extensions, watching out for conflict with
d/*changelog and pass that to dh_compress -X .. ?

Thanks for comments,


-- 
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/CA+7wUswMgpizar_O6-_LrwF=1XZHXBc7NbQ=rbuftyh54z9...@mail.gmail.com

build: in debian/rules

[Mathieu Malaterre]

Hi,

  Does anyone sees anything wrong with:

...
$ cat debian/rules:
VERSION = $(shell dpkg-parsechangelog | grep '^Version' | cut -d' '
-f2 | cut -f1 -d-)
debian/tbb.pc: debian/tbb.pc.in
sed -es/@VERSION@/$(VERSION)/g $  $@

build: debian/tbb.pc
...

It used to work, but completely destroyed my latest upload of tbb in
experimental:

https://buildd.debian.org/status/fetch.php?pkg=tbbarch=i386ver=4.2~20130725-1.2~exp2stamp=1378901879

Thanks for comments,


-- 
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/CA+7wUsy9AMzbA-zAFKUYz9fqs+WO=V=r=5JW3AKjs4RBF=z...@mail.gmail.com

Re: mentors.d.n upload issues

[Mathieu Malaterre]

On Thu, Jul 18, 2013 at 5:08 AM, Bill Blough de...@blough.us wrote:
 I had an upload rejected due to a signing key issue.  I fixed that (I
 think), then rebuilt, re-signed, and re-uploaded the package.

I would either dput -f just in case. What is the exact message you are
getting when uploading ?


-- 
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/ca+7wuszxyooycdsnnfi6jz7afmcpmtuuadnhnd0qnxrmksp...@mail.gmail.com

Re: PostScript with Copyright from Adobe Systems

[Mathieu Malaterre]

On Mon, Jul 15, 2013 at 7:41 PM, Russ Allbery r...@debian.org wrote:
 Mathieu Malaterre ma...@debian.org writes:

   On of my upload was recently rejected. The reason was that an icon
 file generated using Adobe did contained a copyright statement:

 $ apt-get source pixelmed-java
 $ strings ./com/pixelmed/web/favicon.ill |grep Copyright
 %%Copyright: ((C) 1987-1996 Adobe Systems Incorporated All Rights Reserved)
 %%Copyright: ((C) 1987-1996 Adobe Systems Incorporated All Rights Reserved)
 %%Copyright: ((C) 1987-1996 Adobe Systems Incorporated All Rights Reserved)
 %%Copyright: ((C) 1987-1998 Adobe Systems Incorporated All Rights Reserved)
 %%Copyright: ((C) 1987-1996 Adobe Systems Incorporated All Rights Reserved)
 %%Copyright: ((C) 1992-1996 Adobe Systems Incorporated All Rights Reserved)
 %%Copyright: ((C) 1987-1997 Adobe Systems Incorporated All Rights Reserved)

 This problem, perhaps?

 http://wiki.debian.org/qa.debian.org/type1nondfsg

 Seems weird to have it in a favicon, though.

Well the tool only manage to corrupt my input file:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717228

Will see.

Thanks for the link.


-- 
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/CA+7wUswQo1WL=kiqpnw+vom+nluspd_cc+9qlq3htcpuv2x...@mail.gmail.com

Re: mentors.d.n upload issues

[Mathieu Malaterre]

On Thu, Jul 18, 2013 at 10:35 AM, Bill Blough de...@blough.us wrote:
 On Thu, Jul 18, 2013 at 08:40:48AM +0200, Mathieu Malaterre wrote:
 I would either dput -f just in case. What is the exact message you are
 getting when uploading ?

 If I don't wait long enough between uploads, then it errors because the
 files are still in the upload directory.  But I stumbled across old list
 messages detailing that, so I've kept all of my retries at least 6+ hours
 apart.

 Here's the log from my most recent attempt (gpg signature stuff snipped
 for brevity) -


 bblough@prometheus:~/devel/debian/xalan$ dput -f mentors 
 xalan_1.11-2_source.changes

You could:

$ dcut --input xalan_1.11-2_source.changes

If you do not want to wait another 6 hours.


-- 
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/CA+7wUsz836o29EWC3_=g5igo4kwmnw+b4vwwl5vlr8k1e0e...@mail.gmail.com

Files with All rights reserved.

[Mathieu Malaterre]

Hi,

  My pixelmed-java upload has been rejected for the following reason:

 o com/pixelmed/web/package.html is Copyright all rights reserved

  The only reference I could find about this, is the following [1]:

http://forums.debian.net/viewtopic.php?f=20t=62656#p363466

  Could someone please point me to proper debian documentation
explaining the issue with all rights reserved.

Thanks much,

[1]
The all rights reserved notice is an archaism which stems from the
period when it was required that an author explicitly proclaim his
copyright in order for his work to be protected under copyright law.
It generally has not been necessary to mark your work as copyrighted
for about two decades now (in some jurisdictions, the change was made
about 60 years ago); and the phrase, all rights reserved, no longer
has any legal impact on copyright status.

Nowadays, all creative works such as computer programs are afforded
copyright protection whether the creator wants it or not. Amongst the
rights reserved to the copyright holder is the right to offer a
license so that others may copy, modify, and/or distribute the
program. It is my understanding that QT Creator is now offered under
terms of GNU's Lesser General Public License, but you can contact the
copyright owners to try for alternative licensing terms if you wish.


-- 
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/CA+7wUsyLWK00CHcoh2gYE2-Do3SRJ7fth9_OiF-_JL=wnps...@mail.gmail.com

PostScript with Copyright from Adobe Systems

[Mathieu Malaterre]

Hi,

  On of my upload was recently rejected. The reason was that an icon
file generated using Adobe did contained a copyright statement:

$ apt-get source pixelmed-java
$ strings ./com/pixelmed/web/favicon.ill |grep Copyright
%%Copyright: ((C) 1987-1996 Adobe Systems Incorporated All Rights Reserved)
%%Copyright: ((C) 1987-1996 Adobe Systems Incorporated All Rights Reserved)
%%Copyright: ((C) 1987-1996 Adobe Systems Incorporated All Rights Reserved)
%%Copyright: ((C) 1987-1998 Adobe Systems Incorporated All Rights Reserved)
%%Copyright: ((C) 1987-1996 Adobe Systems Incorporated All Rights Reserved)
%%Copyright: ((C) 1992-1996 Adobe Systems Incorporated All Rights Reserved)
%%Copyright: ((C) 1987-1997 Adobe Systems Incorporated All Rights Reserved)

Has anyone seen this before ? Before I contact upstream, does anyone
know how to generate 'clean' file using Adobe ?

Thanks,


-- 
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/ca+7wuszneyqdx7g2rvfcdfff0zntnxnzgs8eyx1n6mqjczm...@mail.gmail.com

[OT] Re: RFS seeking interim sponsor for dov4l and setpwc

[Mathieu Malaterre]

Anders your mail server is down, you did not get my mails.

On Sat, Jun 15, 2013 at 8:45 PM, Anders Lennartsson
and...@lennartsson.se wrote:
 Great. Thanks for your assistance.

 Anders


 On Sat, 2013-06-15, at 16:21:58 +0200, Mathieu Malaterre wrote:
 Uploaded both. I did add d/watch as per package page (thanks Bart!),
 and lintian reports. I also fixed the hardening compilation of setpwc.

 Thanks for your contribution

 On Fri, Jun 14, 2013 at 9:45 PM, Anders Lennartsson
 and...@lennartsson.se wrote:
  Dear mentors,
 
  I seek an interim sponsor that can upload the packages dov4l and
  setpwc. I have a sponsor but he is rather busy with stuff other than
  Debian at the moment.
 
 snip


-- 
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/ca+7wuszs81qfp9br7sfwiltvdsjvjp7bxcfa-j+jrdzm8kh...@mail.gmail.com

Bug#712544: RFS: xalan/1.11-1 [ITA]

[Mathieu Malaterre]

On Tue, Jun 18, 2013 at 8:36 AM, Bill Blough de...@blough.us wrote:


 Thanks Jakub!

 On Mon, Jun 17, 2013 at 10:40:44PM +0200, Jakub Wilk wrote
 X: libxalan111: binary-file-built-without-LFS-support 
 usr/lib/i386-linux-gnu/libxalan-c.so.111.0
 (It might be worth fixing upstream, but I'm not sure if opening
 files larger than 2GB is a realistic use-case for this library.)

 I believe I have addressed all of the issues you listed except for this one. 
 I may pose it as a question to the upstream dev mailing list and see
 what they say.

 I have uploaded the updated package to mentors.d.n.

Package looks pretty good. However I cannot build it a second time.
Looks like the clean rule is missing something:

$ dpkg-buildpackage -rfakeroot -us -uc
[...]
dh_clean
 dpkg-source -b xalan-1.11
dpkg-source: info: using source format `3.0 (quilt)'
dpkg-source: info: building xalan using existing ./xalan_1.11.orig.tar.gz
dpkg-source: warning: ignoring deletion of file c/config.guess
dpkg-source: warning: ignoring deletion of file c/config.sub
dpkg-source: info: local changes detected, the modified files are:
 xalan-1.11/c/configure
dpkg-source: info: you can integrate the local changes with dpkg-source --commit
dpkg-source: error: aborting due to unexpected upstream changes, see
/tmp/xalan_1.11-1.diff.w5Wkdf
dpkg-buildpackage: error: dpkg-source -b xalan-1.11 gave error exit status 2

thanks


-- 
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/CA+7wUswb9u1Pi6ZoFx9jdccyhKN5AeKZGz7Ac7Scw6wO=xq...@mail.gmail.com

Bug#712056: RFS: scantailor [ITP] -- interactive post-processing tool for scanned document pages

[Mathieu Malaterre]

On Sat, Jun 15, 2013 at 6:20 PM, Dmitry Smirnov only...@debian.org wrote:
 Build type is better to leave as RELWITHDEBINFO. This might be
 useful if you decide to provide -dbg package or just to (re-)build
 with debugging info with command like


Technically RelWithDebInfo should not be used anymore with cmake from sid:

http://lists.debian.org/debian-devel/2013/06/msg00278.html

It now appends -DNDEBUG ... see #701231 for more info

2cts


-- 
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/ca+7wuszxrsb7cpda3aqb9ufvgmauzpoe9ub+2uydp0uujtm...@mail.gmail.com

Re: RFS seeking interim sponsor for dov4l and setpwc

[Mathieu Malaterre]

Uploaded both. I did add d/watch as per package page (thanks Bart!),
and lintian reports. I also fixed the hardening compilation of setpwc.

Thanks for your contribution

On Fri, Jun 14, 2013 at 9:45 PM, Anders Lennartsson
and...@lennartsson.se wrote:
 Dear mentors,

 I seek an interim sponsor that can upload the packages dov4l and
 setpwc. I have a sponsor but he is rather busy with stuff other than
 Debian at the moment.

 It would be good if these packages are uploaded as it would close
 critical bugs (build dependency on the long deprecated dbs).

 The upstream software is created by Folkert van Heusden.

 dov4l:
 Homepage: http://www.vanheusden.com/dov4l/
 Description: program to set and query settings of video4linux devices
  The dov4l program can set properties such as frequency, tuner,
  inputchannel, mode, brightness, hue, color, contrast, whiteness,
  palette, width, and height of a video4linux device.  It can also
  query current settings.

 setpwc:
 Homepage: http://www.vanheusden.com/setpwc/
 Description: program to set and query settings of (mainly) Philips WebCams
  The setpwc program can set and list various settings of Philips
  WebCams, and also some WebCams from other manufacturers, but based on
  the PWC chipset. The program can set properties such as compression
  preference, framerate, gain control, shutter speed, white red and
  blue balance, etc. It can also query current settings.
  .
  In addition, setpwc can store the settings in nonvolatile RAM, as well as
  restore factory defaults.



 The Debian packages are available from:

 deb http://lennartsson.se/debian/ ./
 deb-src http://lennartsson.se/debian/ ./

 The key used to sign packages and Release file is available in
 http://lennartsson.se/anders_lennartsson.asc


 Regards,
 Anders Lennartsson


 --
 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/20130614194530.ga7...@isis.lennartsson.se



-- 
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/ca+7wusymm6r7isa7qunjg7wx1eefrct4-ajv8ayqsbzxkxj...@mail.gmail.com

f2c and autotools

[Mathieu Malaterre]

Hi there,

  I am trying to work on #702882

  Upstream is basically doing:

if test $internal_f2c = no; then
  AC_CHECK_LIB([f2c], [f77_alloc_], [],
 AC_CHECK_LIB([f2c], [f77_alloc], [],
AC_CHECK_LIB([f2c], [F77_ALLOC_], [],
   AC_CHECK_LIB([f2c], [F77_ALLOC], [],
  [AC_MSG_RESULT(not found, trying to use -lf2c anyway.)]
  LDFLAGS=${LDFLAGS}
else  AC_DEFINE([INTERNAL_F2C], [1], [Define to 1 if you use the internal
F2C library])
fi


  As explained in #702882#5, this fails on debian system since one
cannot link to f2c without first defining a MAIN__ symbol. Has anyone
work on autotools and f2c issue on debian in the past ? How should one
use the autotools *F77* macros to handle this case ?

Thanks,


-- 
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/CA+7wUsz_7tiT67JEb1WnF2tGF4RQZJe+t4OEDRtLJeUG+K=x...@mail.gmail.com

Re: install rule in Makefile

[Mathieu Malaterre]

On Sat, Mar 9, 2013 at 6:06 PM, Alfonso Sabato Siciliano
alfi...@gmail.com wrote:
 I am making a package, the original Makefile has not install rule so
 it install anything then I have to add it.
 Where must I install this rule?

All 3 options are possible.

 -Patching  original Makefile

Choose this solution if you are very close to upstream. In this case
they will surely accept your patch, and it will get quickly integrate.
This server as temporary solution.

 -In debian/rules

If you need to script or do funky stuff within your d/rules file, then
use dh_install

 -In debian/package.install

By far the easiest option. Simply put the name of the file you want to
install, and you are done.


-- 
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/CA+7wUswmXEhUoq958ixTBwkx358faSk8OZZ=cV_uK=pxmiz...@mail.gmail.com

Bug#699669: RFS: agar/1.4.1+repack1-1 [ITP] -- toolkit for graphical applications

[Mathieu Malaterre]

On Fri, Feb 8, 2013 at 5:23 PM, Stephen M. Webb
stephen.w...@bregmasoft.ca wrote:
 On 02/06/2013 08:55 AM, Mathieu Malaterre wrote:
 

 All requested changes made and a new source package uploaded to 
 mentors.debian.net.

Uploaded ! Thanks.

Please `dch -r` next time.

Thanks,


-- 
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/CA+7wUsyryWNF5GSJ2yqwS0sjewDVr8u=cst7mpemnquoveq...@mail.gmail.com

Bug#699669: RFS: agar/1.4.1+repack1-1 [ITP] -- toolkit for graphical applications

[Mathieu Malaterre]

On Tue, Feb 5, 2013 at 4:22 AM, Stephen M. Webb
stephen.w...@bregmasoft.ca wrote:
 This was because a pre-built Windows binary was included in the upstream 
 source tarball.  The complete source for the
 binary is included.  After some discussion, the executable is now being left 
 in and the pristine tarball is being
 included.  I change the package version accordingly and re-uploaded to m.d.n.

Looks good now:

$ dget -u http://mentors.debian.net/debian/pool/main/a/agar/agar_1.4.1-1.dsc

 The package builds as-is in a current sid pbuilder environment.  Those 
 symbols are only built when the package
 configuration can successfully detect the presence of working GLX headers.  
 It would be useful to check the config.log
 to identify the reason why this was unsuccessful for you.

I cannot reproduce this from another computer. We'll leave this as-is.


New comments:

1.
Please do not use version for png-dev and jpeg-dev package. This helps
in preventing source upload everytime package -dev gets updated.

2.
There is an issue with the d/copyright, some file are not listed:

$ head ./vg/vg_line.h
/*  Public domain   */

but d/copyright indicate only BSD...


3. Currently Std-Vers is 3.9.4


Thanks,
-M


-- 
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/CA+7wUswiqBSb=rOBsszzDZOTjPq0cPkxc5kB8LtRWJm=heu...@mail.gmail.com

Bug#699669: RFS: agar/1.4.1+repack1-1 [ITP] -- toolkit for graphical applications

[Mathieu Malaterre]

On Wed, Feb 6, 2013 at 2:48 PM, Mathieu Malaterre ma...@debian.org wrote:
 On Tue, Feb 5, 2013 at 4:22 AM, Stephen M. Webb
 stephen.w...@bregmasoft.ca wrote:
 This was because a pre-built Windows binary was included in the upstream 
 source tarball.  The complete source for the
 binary is included.  After some discussion, the executable is now being left 
 in and the pristine tarball is being
 included.  I change the package version accordingly and re-uploaded to m.d.n.

 Looks good now:

 $ dget -u http://mentors.debian.net/debian/pool/main/a/agar/agar_1.4.1-1.dsc

 The package builds as-is in a current sid pbuilder environment.  Those 
 symbols are only built when the package
 configuration can successfully detect the presence of working GLX headers.  
 It would be useful to check the config.log
 to identify the reason why this was unsuccessful for you.

 I cannot reproduce this from another computer. We'll leave this as-is.


 New comments:

 1.
 Please do not use version for png-dev and jpeg-dev package. This helps
 in preventing source upload everytime package -dev gets updated.

 2.
 There is an issue with the d/copyright, some file are not listed:

 $ head ./vg/vg_line.h
 /*  Public domain   */

 but d/copyright indicate only BSD...


 3. Currently Std-Vers is 3.9.4

4. I believe there is an issue:

$ dpkg -c libag-vg4_1.4.1-1_amd64.deb
[...]
lrwxrwxrwx root/root 0 2013-02-06 14:42
./usr/lib/libag_vg.so.4 - libag_vg.so.4.0.0

Looks like there is an issue with multiarch path installation. shared
lib should not be in usr/lib, but usr/lib/x86_64-linux-gnu (at least
on my machine).

Thanks,


-- 
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/CA+7wUsybeJ+T6vERCyDK46C2G1Agngk3Yi5S76xK5j=p=4+...@mail.gmail.com

Bug#699669: RFS: agar/1.4.1+repack1-1 [ITP] -- toolkit for graphical applications

[Mathieu Malaterre]

Package looks pretty good !

Some quick comments:

What's with the renaming (Please add a REAMDE.source for explanation thanks) ?

$ uscan --verbose --force-download
[...]
Newest version on remote site is 1.4.1, local version is 1.4.1+repack1
 = remote site does not even have current version
-- Scan finished

$ wget http://stable.hypertriton.com/agar/agar-1.4.1.tar.gz
$ md5sum  agar_1.4.1+repack1.orig.tar.gz agar-1.4.1.tar.gz
3483244d3be644f769f5b79fe4817063  agar_1.4.1+repack1.orig.tar.gz
ce71fb11ad79c926a968a4ed29053820  agar-1.4.1.tar.gz



And I have not look carefully if this is an issue with private glx
implementation, but package currently FTBFS on my system:


dpkg-gensymbols: warning: some symbols or patterns disappeared in the
symbols file: see diff output below
dpkg-gensymbols: warning: debian/libag-gui4/DEBIAN/symbols doesn't
match completely debian/libag-gui4.symbols
--- debian/libag-gui4.symbols (libag-gui4_1.4.1+repack1-1_amd64)
+++ dpkg-gensymbolsXVrKDS   2013-02-04 15:46:19.0 +0100
@@ -931,7 +931,7 @@
  agDefaultFont@Base 1.4.1
  agDirDlgClass@Base 1.4.1
  agDriverClass@Base 1.4.1
- agDriverGLX@Base 1.4.1
+#MISSING: 1.4.1+repack1-1# agDriverGLX@Base 1.4.1
  agDriverList@Base 1.4.1
  agDriverListSize@Base 1.4.1
  agDriverMwClass@Base 1.4.1
@@ -1074,4 +1074,4 @@
  agWindowToFocus@Base 1.4.1
  agnKeySyms@Base 1.4.1
  agnUnitGroups@Base 1.4.1
- modMasks@Base 1.4.1
+#MISSING: 1.4.1+repack1-1# modMasks@Base 1.4.1
dh_makeshlibs: dpkg-gensymbols -plibag-gui4
-Idebian/libag-gui4.symbols -Pdebian/libag-gui4
-edebian/libag-gui4/usr/lib/libag_gui.so.4.0.0
 returned exit code 1
make: *** [binary] Error 1


Thanks,


-- 
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/CA+7wUsyy3rU9PGndtH0s5i9kRMeR8O43tR1+FH4HRF-UCuek=g...@mail.gmail.com

Re: Scantailor 0.9.11.1: Cmake test suite fails

[Mathieu Malaterre]

On Wed, Dec 12, 2012 at 11:35 AM, Daniel Stender
dan...@danielstender.com wrote:
 test: cannot connect to X server :0

You do not have X11 on buildd. You need to use Xvfb during execution
of your test suite.

Eg.
https://lists.debian.org/debian-java/2012/11/msg6.html

HTH


-- 
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/CA+7wUszXTSW6M5iaqTK5EfoZczMABj-d2c6y=fpauhjf8za...@mail.gmail.com

Bug#689041: Re: Orthanc

[Mathieu Malaterre]

Sébastien,

On Fri, Oct 5, 2012 at 6:35 PM, Mathieu Malaterre
mathieu.malate...@gmail.com wrote:
 Why did you choose gnutls ? Your code seems to be using the openssl
 one. And your copyright is explicitely setup to deal with openssl
 exception anyway ?

Another set of minor comments.

1.
$ man -l -k docs/orthanc.1
docs/orthanc.1: nothing appropriate.
You can use help2man to quickly generate a proper man page.

2.
Some leftover:
$ more debian/copyright
[...]
Files: ThirdPartyDownloads/jsoncpp-src-0.5.0.tar.gz
Copyright: Baptiste Lepilleur b...@users.sourceforge.net
License: Public Domain

3.
d/changelog, one entry is enough.

4.
You can use quilt refresh to refresh dynamic-jsoncpp, to get rid of:
dpkg-source: warning: diff
`orthanc-0.2.2/debian/patches/dynamic-jsoncpp' patches file
orthanc-0.2.2/Resources/CMake/JsonCppConfiguration.cmake twice

Technically it would be nice to use DEP3 for patch, but I assume
'upstream' is aware of those ...

Thanks
-- 
Mathieu


--
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/ca+7wusypfdqw1ga5yerqwxu+u_ywuezhibzrmxlrc-mytgp...@mail.gmail.com

Bug#689041: Re: Orthanc

[Mathieu Malaterre]

On Fri, Oct 5, 2012 at 6:02 PM, Sebastien Jodogne
s.jodo...@chu.ulg.ac.be wrote:
 Dear Gregor,


 * why libcurl4-gnutls-dev | libcurl4-nss-dev | libcurl4-openssl-dev ?
 shouldn't that be something simplier like libcurl4-dev ? libcurl-dev ?
 libcurl-ssl-dev ?


 If I use libcurl4-dev, libcurl-dev or libcurl-ssl-dev, I
 obtain the following Lintian warning:

 http://lintian.debian.org/tags/virtual-package-depends-without-real-package-depends.html

 For this reason, I have preferred to keep my explicit enumeration.


 An alternative would be to use libcurl4-gnutls-dev | libcurl4-dev.


 Thank for your reply! I have just uploaded another version of the package
 with your suggested improvement:
 http://mentors.debian.net/debian/pool/main/o/orthanc/orthanc_0.2.2-3.dsc

Why did you choose gnutls ? Your code seems to be using the openssl
one. And your copyright is explicitely setup to deal with openssl
exception anyway ?

thx
-- 
Mathieu


-- 
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/CA+7wUszeoi3MJ76OkAirb0AYNQbyfX=0gpSC5=vh7bhd4eh...@mail.gmail.com

Bug#689041: Re: Orthanc

[Mathieu Malaterre]

Sébastien,

On Thu, Oct 4, 2012 at 4:02 PM, Sebastien Jodogne
s.jodo...@chu.ulg.ac.be wrote:
 Salut Mathieu,

 Many thanks for your feedback. I have just uploaded a new version of the
 Orthanc package:
 http://mentors.debian.net/package/orthanc
 http://mentors.debian.net/debian/pool/main/o/orthanc/orthanc_0.2.2-1.dsc

Much better indeed ! Some comments below:

d/rules:
* Why are you override_ing everything in d/rules ? Why not let dh
decide what to do, where to compile ? Also cmake support --parallel
(cf man dh)

d/control:
* why libcurl4-gnutls-dev | libcurl4-nss-dev | libcurl4-openssl-dev ?
shouldn't that be something simplier like libcurl4-dev ? libcurl-dev ?
libcurl-ssl-dev ?
* do not use libpng12-dev, prefer the version less
* no such thing as libdcmtk1-dev (= 3.5) AFAIK
* I would use debhelper = 9; to get hardening working in cmake
* Section: misc ? Really ?
* libgtest-dev is listed but configure reveals:
...
-- Could NOT find GTest (missing:  GTEST_LIBRARY GTEST_MAIN_LIBRARY)
...
* why use oflog and libwrap ? They are not used:
...
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/orthanc/usr/bin/orthanc was not linked against libwrap.so.0 (it
uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/orthanc/usr/bin/orthanc was not linked against liboflog.so.2
(it uses none of the library's symbols)
...

d/orthanc.lintian-overrides
* I: orthanc: unused-override spelling-error-in-binary usr/bin/orthanc
negotation negotiation
* what's wrong with sqlite in debian ? Which version exactly do you need ?

ThirdPartyDownloads/jsoncpp-src-0.5.0.tar.gz
* why convenient copy and not debian one: libjsoncpp-dev

d/changelog:
* just keep a single entry, with ref to ITP#. This is fine.

d/copyright:
* where is the copyright/license for jsoncpp, mongoose  sqlite-amalgamation ?
* You need to explicitly state the license you are using for debian/*
files. Something like Same as above is fine.

d/compat:
* use 9

d/orthanc.init:
* /var/run is deprecated: http://wiki.debian.org/ReleaseGoals/RunDirectory


Thanks !


--
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/CA+7wUswyMTpV6+rnkUFywe+BokC2tdiBKmfaseKat=ovibq...@mail.gmail.com

Bug#689041: RFS: orthanc/0.2.1-3 [ITP] -- Lightweight, RESTful DICOM server for healthcare and medical research

[Mathieu Malaterre]

Salut Sébastien,

  Have you thought of maintaining your package within the debian-med
umbrella org ?

http://www.debian.org/devel/debian-med/

On Fri, Sep 28, 2012 at 5:54 PM, Sébastien Jodogne s.jodo...@gmail.com wrote:
 Package: sponsorship-requests
 Severity: wishlist


 Dear mentors,

 I am looking for a sponsor for my package orthanc:

  * Package name: orthanc
Version : 0.2.1-3
Upstream Author : Sebastien Jodogne s.jodo...@gmail.com
  * URL : https://code.google.com/p/orthanc/
  * License : GPL

 It builds those binary packages:

   orthanc - A lightweight, RESTful DICOM server for healthcare and
 medical research

 To access further information about this package, please visit the
 following URL:
 http://mentors.debian.net/package/orthanc

 Alternatively, one can download the package with dget using this command:
 dget -x 
 http://mentors.debian.net/debian/pool/main/o/orthanc/orthanc_0.2.1-3.dsc

 More information about orthanc can be obtained from:
 https://code.google.com/p/orthanc/.

 Regards,
 S. Jodogne-


 --
 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/CA+Rg+VxAnw9RX4=yluq1dgyug7xveffzd2_ay9qwbr7q21g...@mail.gmail.com



--
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/CA+7wUswQPih9hD4vmWBLhUCFqHoÞg66l9pfbb8uajyusn...@mail.gmail.com

pkgkde-gensymbols / Std-Vers: 3.9.4 and § 8.6 for C++ libs

[Mathieu Malaterre]

Hi there,

  I am trying to update one of my package to Std-Vers: 3.9.4. In
particular I am looking at §8.6 which now recommends symbols files.
According to recent post on -dev handling of c++ libs should be done
using pkgkde-gensymbols. So I followed instructions from:

 http://pkg-kde.alioth.debian.org/symbolfiles.html

  I did ran:

$ pkgkde-gensymbols -V -plibgdcmMSFF2.2 -v2.2.1 -Osymbols.amd64
-edebian/tmp/usr/lib/libgdcmMSFF.so.2.2.1

where:

$ readelf -d debian/tmp/usr/lib/libgdcmMSFF.so.2.2.1
[...]
 0x000e (SONAME) Library soname: [libgdcmMSFF.so.2.2]

However pkgkde-gensymbols neither output *anything*, nor create a
symbols.amd64 file.

Anyone knows how to use this tool ? Using:

$ apt-cache policy pkg-kde-tools
pkg-kde-tools:
  Installed: 0.15.3
  Candidate: 0.15.3
  Version table:
 *** 0.15.3 0
500 http://ftp.fr.debian.org/debian/ sid/main amd64 Packages
100 /var/lib/dpkg/status

Thanks !


--
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/ca+7wusyeu5wlzkdotsfhhcc+f-qoo6hmqcek5oonbeizep3...@mail.gmail.com

Re: Bug#683336: RFS: ninja-build/120508+git638b033

[Mathieu Malaterre]

Gary,

  Thanks for packaging ninja. Here are a few comments:

- Please use format 1.0 [1] for copyright. Do not forget to list your
own copyright (debian/* files).
- You are missing proper version check in d/control. On my stable system I get:

g++-4.4.real: no input files
[10/24] CXX build/build_test.o
ninja: build stopped: subcommand failed.
make[1]: *** [override_dh_auto_build] Error 1

- looks like you need a min version for gtest-dev

- I believe you can simplify d/rules. Since you use d/compat=9, you do
not need to specify the explicit hardening settings in d/rules.
- On a side chroot, the build fails with:

PYTHON=python' -O2 -DNDEBUG -g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security  -fPIE
-fstack-protector --param ssp-buffer-size=4  -D_FORTIFY_SOURCE=2
-Wformat -Wformat-security -Werror=format-security  -c
src/build_log_perftest.cc -o build/build_log_perftest.o
src/build_log_perftest.cc: In function 'int main()':
src/build_log_perftest.cc:135:23: error: 'unlink' was not declared in this scope
[21/24] CXX build/util_test.o
ninja: build stopped: subcommand failed.

- Thanks.

[1] http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/


-- 
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/ca+7wuszgn_apw3bjv1qo8mmqjzcpju1vzlyufp+x5zvm1-y...@mail.gmail.com

Bug#674291: Olena - packages updated

[Mathieu Malaterre]

On Fri, Jun 8, 2012 at 2:40 PM, Guillaume Lazzara
guillaume.lazz...@lrde.epita.fr wrote:
 On Wed, Jun 6, 2012 at 4:05 PM, Mathieu Malaterre ma...@debian.org wrote:
Why is d/rules so complicated ? It should just be:

#!/usr/bin/make -f
%:
 dh $@

 I took an example but it was definitely not the best. I updated the file
 and made it shorter.

looks much readable :)


Why don't you build the gdcm plugin ?

 Actually we don't really have a gdcm plugin. We have parts of code which
 can use it (I/O functions).
 Our project is made of a full template library and no program using
 GDCM, except in the test suites, is compiled.

 Currently, headers using GDCM are installed even if the library is not
 present on the system. We do so without forcing libgdcm dependency since
 it is not a prerequisite to use the library.

 Do you think we should set libgdcm as dependency to ensure the usability?

Your call. That was just a suggestion, but I guess I am biased :)

Anyway why is the package on mentors so damn huge !

$ dget -u http://mentors.debian.net/debian/pool/main/o/olena/olena_2.0-1.dsc
$ wget http://www.lrde.epita.fr/dload/olena/2.0/olena-2.0.tar.gz
$ du -sh *.tar.gz
104Molena_2.0.orig.tar.gz
38M olena-2.0.tar.gz

Even upstream source seems full of weird stuff:

$ tar xvfz olena-2.0.tar.gz | grep pdf
olena-2.0/milena/doc/user-refman.pdf
olena-2.0/milena/doc/technical.pdf
olena-2.0/milena/doc/user-refman/latex/d4/daf/a03819.pdf
olena-2.0/milena/doc/user-refman/latex/d4/d5e/a03686.pdf
olena-2.0/milena/doc/user-refman/latex/d4/d7d/a03702.pdf
olena-2.0/milena/doc/user-refman/latex/d4/db6/a04062.pdf
olena-2.0/milena/doc/user-refman/latex/d4/db4/a03520.pdf
olena-2.0/milena/doc/user-refman/latex/d4/db7/a03863.pdf
olena-2.0/milena/doc/user-refman/latex/d4/dd9/a03599.pdf
olena-2.0/milena/doc/user-refman/latex/d4/dd6/a04031.pdf
olena-2.0/milena/doc/user-refman/latex/d4/d2b/a03662.pdf
olena-2.0/milena/doc/user-refman/latex/d4/d60/a03463.pdf
olena-2.0/milena/doc/user-refman/latex/d4/d60/a03446.pdf
olena-2.0/milena/doc/user-refman/latex/d4/d43/a03700.pdf
olena-2.0/milena/doc/user-refman/latex/d4/d6e/a03784.pdf
olena-2.0/milena/doc/user-refman/latex/d4/df0/a03763.pdf
olena-2.0/milena/doc/user-refman/latex/d4/db1/a03678.pdf
olena-2.0/milena/doc/user-refman/latex/d4/d9a/a04024.pdf
olena-2.0/milena/doc/user-refman/latex/d4/dc4/a03647.pdf
olena-2.0/milena/doc/user-refman/latex/d4/d5f/a03778.pdf
olena-2.0/milena/doc/user-refman/latex/d4/d16/a03859.pdf


Please get in touch with upstream and/or repack the source. ftpmasters
will reject the package if it contains generated stuff (including
documentation).

thanks
-- 
Mathieu



-- 
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/CA+7wUsxZeb6L4L3W5PPwXrN2T9A=+yy2-_eq+p3qwpyfnhw...@mail.gmail.com

Bug#674291: Olena - packages updated

[Mathieu Malaterre]

On Wed, Jun 6, 2012 at 2:12 PM, Guillaume Lazzara glazz...@gmail.com wrote:
 Dear mentors,

 According to the comment posted
 on http://mentors.debian.net/package/olena we have updated the packages and
 fixed several warnings found by Lintian.
 Thanks for the first review.

Why is d/rules so complicated ? It should just be:

#!/usr/bin/make -f
%:
  dh $@

Why don't you build the gdcm plugin ?

Thanks



--
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/ca+7wusyc00+n4vsotxam2w4xgkhd7pyt60gdaiep027sg5p...@mail.gmail.com

man page and version

[Mathieu Malaterre]

I have been packaging the OpenGL 4.2 reference page:

http://mentors.debian.net/package/khronos-opengl-man4

I am now debating whether or not to package the equivalent legacy pre
3.x and 3.x opengl man page.
The issue is that most diffs will be in the actual man pages. Since
man page mechanism do not allow for multiple installation of the same
man page with difference version, I guess this is just not possible.

Would it make sense to have them conflicts with each other ?

Any hints appreciated,
-- 
Mathieu


-- 
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/CA+7wUswdkEOxZhbvOkCOOdZWW=szzgxvceoalspgs3rqcv2...@mail.gmail.com

Re: Bug#669585: RFS: bibtexconv/0.8.14-1 -- Looking for a Debian sponsor

[Mathieu Malaterre]

Thomas,

  Couple of quick comments:

*  d/copyright does not contains copyrights for debian/* files. I
found also suspicious that Copyright is 2010-2011 Thomas Dreibholz,
shouldn't it be 2010-2012 ?
*  d/control lists an empty 'Recommends:'
*  d/rules I am not an autotools expert but I believe you want  dh $@
--with autotools_dev

HTH

On Fri, Apr 20, 2012 at 8:49 AM, Thomas Dreibholz dre...@iem.uni-due.de wrote:
 Package: sponsorship-requests
 Severity: wishlist

 Dear mentors,

 I am looking for a sponsor for my package bibtexconv. BibTeXConv is a BibTeX
 file converter which allows one to export BibTeX entries to other formats,
 including customly defined text output. Furthermore, it provides the
 possibility to check URLs (including MD5, size and MIME type computations)
  and to verify ISBN and ISSN numbers. Examples are provided on the BibTeXConv
 website at http://www.iem.uni-due.de/~dreibh/bibtexconv/index.html .

  * Package name    : bibtexconv
   Version         : 0.8.14-1
   Upstream Author : Thomas Dreibholz dre...@iem.uni-due.de
  * URL             : http://www.iem.uni-due.de/~dreibh/bibtexconv/index.html
  * License         : GPL, version 3
   Section         : tex

 It builds those binary packages:

  bibtexconv - BibTeX Converter

 To access further information about this package, please visit the following
 URL:

  http://mentors.debian.net/package/bibtexconv


 Alternatively, one can download the package with dget using this command:

 dget -x
 http://mentors.debian.net/debian/pool/main/b/bibtexconv/bibtexconv_0.8.14-1.dsc

 More information about bibtexconv can be obtained from http://www.iem.uni-
 due.de/~dreibh/bibtexconv/.


 Best regards,
   Thomas Dreibholz



-- 
Mathieu


--
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/CA+7wUsyvKP0bZfvfH7z7DSL92aUhuU_60JVSsP-fA=owlkv...@mail.gmail.com

Re: hints for creating deb packages with cmake build system

[Mathieu Malaterre]

On Mon, Apr 9, 2012 at 2:19 PM, Werner Detter wer...@aloah-from-hell.de wrote:
 Hi,

 I am looking for instructions on how to create a debian package that uses 
 cmake as build
 system as I'm wondering how the debian/rules should look and what it should 
 contain for
 cmake? Can anyone tell me a small package that uses cmake as build system, 
 where i could
 peak for a debian/rules file? Any other good hints or links? :)

I use dh directly (no cdbs):

http://anonscm.debian.org/gitweb/?p=collab-maint/kwstyle.git;a=blob;f=debian/rules;h=2e854096a086a53312ec488891a5f75e2d5294d2;hb=HEAD

HTH


-- 
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/CA+7wUsw4-EevcdJd=eeN5kjBc_sVLWsuwFnM=QpN=qjT=gj...@mail.gmail.com

Status of B-D-I ?

[Mathieu Malaterre]

Hi mentors,

  I am starring at the buildd status page of mrmpi:

https://buildd.debian.org/status/package.php?p=mrmpi

  I cannot make any sense of the results on armel, armhf, i386, ia64,
mips and powerpc. Why are those arch running *-indep rules ?

Thanks much,
-- 
Mathieu


-- 
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/ca+7wuszm0jy4ryoa+kifydairyj9co1f_4adlhn5bi6py0e...@mail.gmail.com

Re: upstream source is a source rpm!

[Mathieu Malaterre]

Paul,

On Mon, Mar 12, 2012 at 6:50 AM, Paul Elliott
pelli...@blackpatchpanel.com wrote:
 I can unpack this thingy with:
 rpm2cpio source.rpm | cpio -i

 But I have questions:

 Assuming I have the url of the source rpm, how would one write the watch file
 and get-orig-source: in rules to create a proper .ds tarball?

watch file should be easy to write: this is just a regex and it should
not care about the file extension. What you need to do is something
like this:

http://anonscm.debian.org/viewvc/pkg-java/trunk/fop/debian/watch?view=markup

See how watch files are flexible ? Just provide an orig-tar.sh script
yourself (using rpm2cpio for example)

 Do I need to put rpm2cpio and cpio in Build-depends: ? Do I need to note this
 dependancy anywhere?

No. You should repack the source using .xy, .gz, .bz2 only in your
orig-tar.sh script. Make sure to exit with an error in orig-tar.sh
when rpmcpio is not present, and you should be ready to roll.

2cts
-- 
Mathieu


-- 
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/CA+7wUsyG5HK5VNUTkzO4OR=yob3vx+bevoxpe5a+nmecgqm...@mail.gmail.com

Re: upstream source is a source rpm!

[Mathieu Malaterre]

On Mon, Mar 12, 2012 at 11:54 AM, Goswin von Brederlow
goswin-...@web.de wrote:
 Mathieu Malaterre mathieu.malate...@gmail.com writes:

 Paul,

 On Mon, Mar 12, 2012 at 6:50 AM, Paul Elliott
 pelli...@blackpatchpanel.com wrote:
 I can unpack this thingy with:
 rpm2cpio source.rpm | cpio -i

 But I have questions:

 Assuming I have the url of the source rpm, how would one write the watch 
 file
 and get-orig-source: in rules to create a proper .ds tarball?

 watch file should be easy to write: this is just a regex and it should
 not care about the file extension. What you need to do is something
 like this:

 http://anonscm.debian.org/viewvc/pkg-java/trunk/fop/debian/watch?view=markup

 See how watch files are flexible ? Just provide an orig-tar.sh script
 yourself (using rpm2cpio for example)

 Do I need to put rpm2cpio and cpio in Build-depends: ? Do I need to note 
 this
 dependancy anywhere?

 No. You should repack the source using .xy, .gz, .bz2 only in your
 orig-tar.sh script. Make sure to exit with an error in orig-tar.sh
 when rpmcpio is not present, and you should be ready to roll.

 I always hate when you patch a source or update the upstream part and
 suddenly things break because some tools are missing.

 I know they don't fall under Build-Depends and buildds should not need
 to install them. But maybe there could be a new Build-Depends-Extras
 field for things like this?

That seems terribly complicated instead of adding another compression
backend to uscan. uscan properly support repacking .zip into .tgz.
I have seen java package distributing source files in a .jar file :)

2cts
-- 
Mathieu


-- 
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/ca+7wusy3oyu0quxs6ynwf7yl7jp4jvadq2deh9qfyxvhehn...@mail.gmail.com

Re: Proable multiarch related problem in finding header file (Was: Problem finding posix_types_32.h when using pbuilder on the fis-gtm package)

[Mathieu Malaterre]

Hi Luis,

This was a mistake, linux-libc-dev still contains posix_*.h files.
However the compilation failure seems to be coming from the use of -I-
apparently, see thread at:

http://lists.debian.org/debian-devel/2012/02/msg00592.html

HTH

On Wed, Feb 15, 2012 at 12:51 PM, Luis Ibanez luis.iba...@kitware.com wrote:
 Mathieu,

 Thanks for the hint,


 This is what dpkg --status pbuilder reports in the
 VM where I'm building the fis-gtm package:


 $ dpkg --status pbuilder

 Package: pbuilder
 Status: install ok installed
 Priority: extra
 Section: devel
 Installed-Size: 1212
 Maintainer: Debian pbuilder maintenance team
 pbuilder-ma...@lists.alioth.debian.org
 Architecture: all
 Version: 0.199+nmu1squeeze1
 Depends: debootstrap | cdebootstrap, wget, debianutils (= 1.13.1),
 coreutils (= 4.5.8-1), debconf (= 0.5) | debconf-2.0
 Recommends: fakeroot, sudo, devscripts
 Suggests: pbuilder-uml, gdebi-core, cowdancer
 Conffiles:
  /etc/bash_completion.d/pbuilder 6af3c8c99796ab77971de5ffac83a0f8
  /etc/pbuilder/buildd-config.sh 48b942cabcc5fcfe94f28538239573ba
 ...


 Is this an old version ?


     Thanks


           Luis


 -
 On Tue, Feb 14, 2012 at 3:47 AM, Mathieu Malaterre
 mathieu.malate...@gmail.com wrote:
 Andreas,

  Doing a quick check on packages.d.o I can see the file your are
 talking about. However:

 http://packages.debian.org/search?suite=sidarch=anymode=pathsearchon=contentskeywords=posix_types.h

  returns an empty list. Are you sure your pbuilder is up to date ?

 2cts

 On Mon, Feb 13, 2012 at 1:42 PM, Andreas Tille andr...@an3as.eu wrote:
 Hi,

 just a comment on this: I suspect a multiarch issue and

   http://lists.debian.org/debian-devel-announce/2011/06/msg2.html

  Multiarch handling of header files (/usr/include) will require
   more per-package attention, ...

 so Luis is asking for some hints how to deal with this like the need to
 specify explicite header search path via -I options or something like
 this.  Any more detailed hint than the above would be helpful.

 Kind regards

      Andreas.

 On Sun, Feb 12, 2012 at 05:14:47PM -0500, Luis Ibanez wrote:
 Debian-mentors,


 I'm working on packaging fis-gtm,


 The configuration files that I'm using are here:

 svn+ssh://svn.debian.org/svn/debian-med/trunk/packages/fis-gtm/fis-gtm/trunk/debian

 http://anonscm.debian.org/viewvc/debian-med/trunk/packages/fis-gtm/fis-gtm/trunk/debian/

 These are setup to get the tarball by using:

        uscan --verbose --force-depends

 I manage to build the package locally by using debuild,
 but, when I use the pdebuild command, I get the following
 output:


 - Start the build -
 Linux Host 32
 Linux Host linux i386 x86_regs
 Source Directory List: sr_linux sr_i386 sr_x86_regs sr_unix_gnp
 sr_unix_cm sr_unix_nsb sr_unix sr_port_cm sr_port
 make[2]: Entering directory `/tmp/buildd/fis-gtm-5.4-002B'
 mkdir -p /tmp/buildd/fis-gtm-5.4-002B/pro/map
 tcsh -f /tmp/buildd/fis-gtm-5.4-002B/sr_unix/gen_gtm_threadgbl_deftypes.csh
 /tmp/buildd/fis-gtm-5.4-002B sr_port pro/obj sr_linux sr_i386
 sr_x86_regs sr_unix_gnp sr_unix_cm sr_unix_nsb sr_unix sr_port_cm
 sr_port
 Entering gen_gtm_threadgbl_deftypes.csh to build gtm_threadgbl_deftypes.h
 ~/fis-gtm-5.4-002B/pro/obj ~/fis-gtm-5.4-002B
 Replacing /tmp/buildd/fis-gtm-5.4-002B/sr_linux/gtm_threadgbl_deftypes.h
 ~/fis-gtm-5.4-002B
 Exiting gen_gtm_threadgbl_deftypes.csh
 make -C /tmp/buildd/fis-gtm-5.4-002B/pro/obj
 -I/tmp/buildd/fis-gtm-5.4-002B/pro/obj
 -I/tmp/buildd/fis-gtm-5.4-002B/sr_linux
 -I/tmp/buildd/fis-gtm-5.4-002B/sr_i386
 -I/tmp/buildd/fis-gtm-5.4-002B/sr_x86_regs
 -I/tmp/buildd/fis-gtm-5.4-002B/sr_unix_gnp
 -I/tmp/buildd/fis-gtm-5.4-002B/sr_unix_cm
 -I/tmp/buildd/fis-gtm-5.4-002B/sr_unix_nsb
 -I/tmp/buildd/fis-gtm-5.4-002B/sr_unix
 -I/tmp/buildd/fis-gtm-5.4-002B/sr_port_cm
 -I/tmp/buildd/fis-gtm-5.4-002B/sr_port -f
 /tmp/buildd/fis-gtm-5.4-002B/sr_unix/comlist.mk CURRENT_BUILDTYPE=pro
 all
 Linux Host 32
 Linux Host linux i386 x86_regs
 Source Directory List: sr_linux sr_i386 sr_x86_regs sr_unix_gnp
 sr_unix_cm sr_unix_nsb sr_unix sr_port_cm sr_port
 make[3]: Entering directory `/tmp/buildd/fis-gtm-5.4-002B/pro/obj'
 cc1: note: obsolete option -I- used, please use -iquote instead
 /usr/include/i386-linux-gnu/asm/posix_types.h:2:30: fatal error:
 posix_types_32.h: No such file or directory
 compilation terminated.
 cc1: note: obsolete option -I- used, please use -iquote instead
 cc1: note: obsolete option -I- used, please use -iquote instead
 /usr/include/i386-linux-gnu/asm/posix_types.h:2:30: fatal error:
 posix_types_32.h: No such file or directory
 compilation terminated.
 ...

 and goes on an on,
 repeating the error about  posix_types_32.h.


 BTW: Please disregard the message:

 cc1: note: obsolete option -I- used, please use -iquote instead


 This is a known issue, and probably not related to the
 problem with posix_types_32.h.   I get the same cc1
 warnings when building with dbuild and yet

Re: Proable multiarch related problem in finding header file (Was: Problem finding posix_types_32.h when using pbuilder on the fis-gtm package)

[Mathieu Malaterre]

Andreas,

  Doing a quick check on packages.d.o I can see the file your are
talking about. However:

http://packages.debian.org/search?suite=sidarch=anymode=pathsearchon=contentskeywords=posix_types.h

  returns an empty list. Are you sure your pbuilder is up to date ?

2cts

On Mon, Feb 13, 2012 at 1:42 PM, Andreas Tille andr...@an3as.eu wrote:
 Hi,

 just a comment on this: I suspect a multiarch issue and

   http://lists.debian.org/debian-devel-announce/2011/06/msg2.html

  Multiarch handling of header files (/usr/include) will require
   more per-package attention, ...

 so Luis is asking for some hints how to deal with this like the need to
 specify explicite header search path via -I options or something like
 this.  Any more detailed hint than the above would be helpful.

 Kind regards

      Andreas.

 On Sun, Feb 12, 2012 at 05:14:47PM -0500, Luis Ibanez wrote:
 Debian-mentors,


 I'm working on packaging fis-gtm,


 The configuration files that I'm using are here:

 svn+ssh://svn.debian.org/svn/debian-med/trunk/packages/fis-gtm/fis-gtm/trunk/debian

 http://anonscm.debian.org/viewvc/debian-med/trunk/packages/fis-gtm/fis-gtm/trunk/debian/

 These are setup to get the tarball by using:

        uscan --verbose --force-depends

 I manage to build the package locally by using debuild,
 but, when I use the pdebuild command, I get the following
 output:


 - Start the build -
 Linux Host 32
 Linux Host linux i386 x86_regs
 Source Directory List: sr_linux sr_i386 sr_x86_regs sr_unix_gnp
 sr_unix_cm sr_unix_nsb sr_unix sr_port_cm sr_port
 make[2]: Entering directory `/tmp/buildd/fis-gtm-5.4-002B'
 mkdir -p /tmp/buildd/fis-gtm-5.4-002B/pro/map
 tcsh -f /tmp/buildd/fis-gtm-5.4-002B/sr_unix/gen_gtm_threadgbl_deftypes.csh
 /tmp/buildd/fis-gtm-5.4-002B sr_port pro/obj sr_linux sr_i386
 sr_x86_regs sr_unix_gnp sr_unix_cm sr_unix_nsb sr_unix sr_port_cm
 sr_port
 Entering gen_gtm_threadgbl_deftypes.csh to build gtm_threadgbl_deftypes.h
 ~/fis-gtm-5.4-002B/pro/obj ~/fis-gtm-5.4-002B
 Replacing /tmp/buildd/fis-gtm-5.4-002B/sr_linux/gtm_threadgbl_deftypes.h
 ~/fis-gtm-5.4-002B
 Exiting gen_gtm_threadgbl_deftypes.csh
 make -C /tmp/buildd/fis-gtm-5.4-002B/pro/obj
 -I/tmp/buildd/fis-gtm-5.4-002B/pro/obj
 -I/tmp/buildd/fis-gtm-5.4-002B/sr_linux
 -I/tmp/buildd/fis-gtm-5.4-002B/sr_i386
 -I/tmp/buildd/fis-gtm-5.4-002B/sr_x86_regs
 -I/tmp/buildd/fis-gtm-5.4-002B/sr_unix_gnp
 -I/tmp/buildd/fis-gtm-5.4-002B/sr_unix_cm
 -I/tmp/buildd/fis-gtm-5.4-002B/sr_unix_nsb
 -I/tmp/buildd/fis-gtm-5.4-002B/sr_unix
 -I/tmp/buildd/fis-gtm-5.4-002B/sr_port_cm
 -I/tmp/buildd/fis-gtm-5.4-002B/sr_port -f
 /tmp/buildd/fis-gtm-5.4-002B/sr_unix/comlist.mk CURRENT_BUILDTYPE=pro
 all
 Linux Host 32
 Linux Host linux i386 x86_regs
 Source Directory List: sr_linux sr_i386 sr_x86_regs sr_unix_gnp
 sr_unix_cm sr_unix_nsb sr_unix sr_port_cm sr_port
 make[3]: Entering directory `/tmp/buildd/fis-gtm-5.4-002B/pro/obj'
 cc1: note: obsolete option -I- used, please use -iquote instead
 /usr/include/i386-linux-gnu/asm/posix_types.h:2:30: fatal error:
 posix_types_32.h: No such file or directory
 compilation terminated.
 cc1: note: obsolete option -I- used, please use -iquote instead
 cc1: note: obsolete option -I- used, please use -iquote instead
 /usr/include/i386-linux-gnu/asm/posix_types.h:2:30: fatal error:
 posix_types_32.h: No such file or directory
 compilation terminated.
 ...

 and goes on an on,
 repeating the error about  posix_types_32.h.


 BTW: Please disregard the message:

 cc1: note: obsolete option -I- used, please use -iquote instead


 This is a known issue, and probably not related to the
 problem with posix_types_32.h.   I get the same cc1
 warnings when building with dbuild and yet in that
 case the build is successful.

 I'm doing this in a Virtual Machine,
 in which uname -a returns:
 Linux debian-med 2.6.32-5-686 #1 SMP Mon Jan 16 16:04:25 UTC 2012 i686 
 GNU/Linux

 The host of this VM, returns for uname -a:
 Linux macondo 2.6.32-38-generic #83-Ubuntu SMP Wed Jan 4 11:12:07 UTC
 2012 x86_64 GNU/Linux


 Login into pbuilder, it was possible to verify
 that the header file is actually there, under:

 ls ./usr/include/i386-linux-gnu/asm/posix* -l
 -rw-r--r-- 1 root root   92 Feb  6 01:32
 ./usr/include/i386-linux-gnu/asm/posix_types.h
 -rw-r--r-- 1 root root 1316 Feb  6 01:32
 ./usr/include/i386-linux-gnu/asm/posix_types_32.h
 -rw-r--r-- 1 root root 1306 Feb  6 01:32
 ./usr/include/i386-linux-gnu/asm/posix_types_64.h

 I'm having trouble understanding why
 is that the build process finds:

    ./usr/include/i386-linux-gnu/asm/posix_types.h

 but fails to find

                  posix_types_32.h


 Any suggestions will be appreciated,


       Thanks


            Luis


 --
 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/cabauzprbxvinepvnkjtgcobgobf83ukuy8dvxcy8a7i4yj5...@mail.gmail.com



 --
 

Re: RFS: vera++

[Mathieu Malaterre]

2012/2/7 Vincent Hobeïka vincent.hobe...@gmail.com:
 - dget http://mentors.debian.net/debian/pool/main/v/vera++/vera++_1.1.1-3.dsc

Looks good. However I would

1. Simplify d/changelog. No-one cares I did work on this package
initially. Redo d/changelog with only one entry.
2. remove quilt reference from d/rules this is undeeded (thanks to
d/source/format).
3. Prefer DEP5 for copyright
4. I think you can remove d/dirs file
5. Prefer DEP3 for d/patches/*
6. rework d/watch file, you are supposed to use regex to find out the
latest possible version
7. I see VCS urls in d/control but they do not reflect the latest of
your package, right ?
8. In d/control, you do not need explicit ref to quilt (again thanks
to d/source/format)

As a side note I see ref to tcl8.4 which is about to be removed AFAIK

HTH
-- 
Mathieu


--
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/CA+7wUswmrEpk_X4orKMWXNTbNuqoSdfAVUuMHsrZ=vg8ieq...@mail.gmail.com

build-indep and buildd

[Mathieu Malaterre]

Hi,

  Could someone please gives an update on the status of build-indep
target and buildd machine ? I am using the following pattern (as per
dh documentation):

   #!/usr/bin/make -f
   %:
   dh $@

   override_dh_auto_build-indep:
   $(MAKE) -C docs

   # No tests needed for docs
   override_dh_auto_test-indep:

  However buildd machine are still running -indep target. I'd like to
test my package first on my local machine to mimic what would a buildd
machine do (I cant find the dpkg-buildpackage command line option used
for buildd)

Thanks
-- 
Mathieu


-- 
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/ca+7wusyamczlfbo90x5r+htl5rykrdmpnwp0+e0qfqhyowm...@mail.gmail.com

Re: build-indep and buildd

[Mathieu Malaterre]

On Wed, Feb 1, 2012 at 2:07 PM, Roger Leigh rle...@codelibre.net wrote:
 On Wed, Feb 01, 2012 at 01:59:41PM +0100, Jakub Wilk wrote:
 * Roger Leigh rle...@codelibre.net, 2012-02-01, 12:52:
 Could someone please gives an update on the status of
 build-indep target and buildd machine ? I am using the following
 pattern (as per dh documentation):
 
               #!/usr/bin/make -f
               %:
                       dh $@
 
               override_dh_auto_build-indep:
                       $(MAKE) -C docs
 
               # No tests needed for docs
               override_dh_auto_test-indep:
 
 However buildd machine are still running -indep target. I'd like
 to test my package first on my local machine to mimic what would
 a buildd machine do (I cant find the dpkg-buildpackage command
 line option used for buildd)
 
 I would make sure you are Build-Depending upon a new enough
 debhelper; some versions were buggy until recently. The earliest
 non-broken version is 8.9.10, though at this point = 9 is
 probably best.

 But that of course won't help, as dpkg-buildpackage doesn't use
 build-indep.

 Argh.  I keep forgetting it's still calling build.  Hopefully
 soon now...  In the meantime, you can test the targets by hand.

In summary, before upload

1. run dpkg-buildpackage -b to reproduce buildd behavior
2. Build the package as usual, upload

What should I do about debhelper version = 9 ?

Thanks
-- 
Mathieu


--
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/CA+7wUsyd1rVh-VwJ5hBhQu3kc8u_sVxc0BxtCRo0-=mv8fx...@mail.gmail.com