Bug#806773: RFS: normaliz/3.0.0+ds-3 [FTBFS fix]

[Jerome Benoit]

Package: sponsorship-requests
Severity: normal

Dear Mentors:

I am looking for a sponsor for the package normaliz [1] that
I am maintaining on behalf of the Debian Science-Team.
This version fix the FTBFS issue #806769 that pointed random emitting
of `Bus error' from GOMP on mipsel architectures machines: OpenMP is
now disabled on mipsel architecture machines.

Thanks,
Jerome

[1] https://anonscm.debian.org/cgit/debian-science/packages/normaliz.git



-- System Information:
Debian Release: Jessie*
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.7-ckt11-amd64-mbp62 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Re: Problem with buid in AMD64

[Andrey Rahmatullin]

On Mon, Nov 30, 2015 at 05:51:12PM -0500, Daniel Echeverry wrote:
> My package doesnt build in amd64
> http://paste.debian.net/hidden/7253bf53/, I want to know, if I need
> add  -fPIC flag only amd64 or in any arch in the configure?
All shared libraries should be compiled with -fPIC.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: general question about quilt patch handling

[Werner Detter]

Hi,

> For example, if 3.patch has not been forwarded upstream yet, then I
> would definitely modify it (instead of creating a new patch).

I've modified 3.patch - in the course of the modification one line has
been deleted (perl "use" statement) as it's not needed anymore.
Therefore some subsequent patches now complain, e.g.

Applying patch 4.patch
patching file xxx
Hunk #1 succeeded at 482 (offset -1 lines).
Hunk #2 succeeded at 2211 (offset -1 lines).

Subsequent patches apply successfully but I'd like to get rid of
those messages. What is the recommendation here?

a) instead of removing the use line, just leave it in?
b) just add another empty line for the deleted one in 3.patch (testet -
works)? But IMHO also "not nice"
c) add a new patch which just deletes the use statement which would be
the last in series file?

Thanks for your suggestions,
Werner

Problem with buid in AMD64

[Daniel Echeverry]

Hi mentors,

My package doesnt build in amd64
http://paste.debian.net/hidden/7253bf53/, I want to know, if I need
add  -fPIC flag only amd64 or in any arch in the configure?

Thanks!

-- 
Daniel Echeverry
http://wiki.debian.org/DanielEcheverry
Linux user: #477840
Debian user
Software libre

Bug#806754: RFS: gmp-ecm/6.4.4+ds-5 [FTBFS fix]

[Jerome Benoit]

Package: sponsorship-requests
Severity: normal

Dear Mentors:

I am looking for a sponsor for the package gmp-ecm [1] that
I am maintaining on behalf of the Debian Science-Team.
This version fix the FTBFS issue #806619 that pointed that
the gmp-ecm package did not honour the arch/indep built scheme:
this release introduce a fully working arch/indep built scheme.

Thanks in advance,
Jerome

[1] https://anonscm.debian.org/cgit/debian-science/packages/gmp-ecm.git

-- System Information:
Debian Release: Jessie*
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.7-ckt11-amd64-mbp62 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Re: Copyright of composite Makefile.in files

[Ferenc Wagner]

Vincent Bernat  writes:

>  ❦ 30 novembre 2015 10:41 +0100, Ferenc Wagner  :
>
>> Makefile.in files distributed in an upstream tarball often have several
>> copyright notices: the FSF copyleft at the top added by Automake and
>> later those carried over from other macro packages included into
>> Makefile.am (for example: include doxygen.am).  The result is like
>> this:
>
> Usually, autoconf generated files are ignored in debian/copyright.
> That's a "special unwritten" rule. You don't need to mention them, you
> don't need to exclude them from the tarball. It's better to regenerate
> them from source during build time.

This would be a serious improvement indeed, especially if teamed with
all the libtool helpers!  Debian/copyright is a real drag: I feel like
I'm pouring half of the total packaging time into creating this file,
and still wouldn't dare to trust the result.  I know of licensecheck,
but this area really cries for more automation and checking.

But until that: why not write this "special rule" somewhere, and start
using it for good?
-- 
Thanks,
Feri.

Re: Copyright of composite Makefile.in files

[Ferenc Wagner]

Alex Vong  writes:

> I am not a mentor, the following is just my opinions:

I'm afraid that if you answer a question on debian-mentors, you're a
mentor by definition. :)

> I don't know how Makefile.in is being handled in particular, but I
> think in general, if one file has more than one copyright notice, then
> we should use `and` to connect compatible licenses and add all authors
> (or organizations) as copyright-holders.
>
> So, in this case I would suggest the following:
>
> Files: */Makefile.in
> Copyright: 1994-2014 Free Software Foundation, Inc.
>2004 Oren Ben-Kiki
> License: FSF-unlimited
>
> Of course, one should always follow
> 
> if possible.

It says: "The Copyright field collects all relevant copyright notices
for the files of this paragraph. Not all copyright notices may apply to
every individual file, and years of publication for one copyright holder
may be gathered together."  So your suggestion really fits this mixed
situation.  But I should probably also add the upstream copyright and
license, which do not appear explicitly in the Makefile.am files.
-- 
Thanks,
Feri.

Re: .symbols or shlibs file

[hpfn]

> * Herbert Parentes Fortes Neto , 2015-11-29, 16:12:
> >I removed the 'override_dh_makeshlibs' and now 'dpkg-gensymbols' is 
> >warning that:
> 
> I certainly didn't advocate removing this override.

A little rush of mine.

> 
> The override passed -X options to dh_makeshlibs. They are needed to 
> prevent debhelper from treating private libraries like if they were 
> shared libraries (see bug #205142).

Ok.

> 
> >dpkg-gensymbols: warning: new libraries appeared in the symbols file:
> >
> >dpkg-gensymbols: warning: debian/libgphoto2-6/DEBIAN/symbols
> > doesn't match completely debian/libgphoto2-6.symbols
> >
> >dpkg-gensymbols: warning: debian/libgphoto2-port12/DEBIAN/symbols
> > doesn't match completely debian/libgphoto2-port12.symbols
> >
> >How 'new libraries', 'doesn't match completely'?
> 
> Now that the -X options are gone, dh_makeshlibs tries to generate 
> symbols for the private libraries, but they are not in debian/*.symbols, 
> hence the warnings.

Thanks to clarify that.

> 
> >I made new files for this version. 2 commands as it is on the wiki.
> 
> Which wiki page do you have in mind?

https://wiki.debian.org/UsingSymbolsFiles

The 2.5.9-2 seems to be ok (on sid). This chat would
result in 2.5.9-3.

[from previous email]
> That said, I wonder if there's any point in passing -V to dh_makeshlibs 
> if the package uses symbols. It doesn't seem useful.

The option started to be used in version 2.4.1-1 (2008),
I believe. From debian/changelog:

* New upstream release (Closes: #480127):
 - Not bumping shlibs, no new symbol.
 - To achieve this, use two dh_makeshlibs calls (one for
   libgphoto2-port0 and one for libgphoto2-$(major), and provide with
   the last upstream version sharing the same ABI. Using 2.4.0 here
   although some former versions might have been specified. That
   shouldn't make any difference from a testing migration point of
   view.

Do you know when the .symbols file started to be in use ?

I did a build without the '-V' option. I don't see errors
messages.

My objective is to do a clean on the package control files
(e.g. it had maintainer scripts doing nothing for some years). 

regards,
-- 
Herbert Parentes Fortes Neto (hpfn)

How to find out why debuild -S dislikes dpkg-source --commit ?

[Thomas Schmitt]

Hi,

after a few weeks of other leisures i came back to Debian
packaging for a new upstream release of my software.
Currently i feel plain stupid because i fail to install
a patch which shall silence a few lintian warnings about
the man pages.

I unpacked the upstream tarball, moved it to the parent of the
unpacked upstream tree and renamed it to libisoburn_1.4.2.orig.tar.gz.
Then i copied the ./debian subtree from my local packaging svn
instance into the unpacked upstream tree.
I wrote a new version section into debian/changelog and removed
an obsolete patch from debian/patches.

All is well as long as i have no debian/patches. I can build
and install the .deb files (debuild -S, debuild -b, dpkg -i).

But if i make changes to the upstream files and run 
  debclean
  dpkg-source --commit
then afterwards
  debuild -S
fails with
  dpkg-source: info: local changes detected, the modified files are:
...
  dpkg-source: error: aborting due to unexpected upstream changes, see 
/tmp/libisoburn_1.4.2-1.diff.ARfBHF

The file /tmp/libisoburn_1.4.2-1.diff.ARfBHF contains the reverse
changeset of the patch which was created by dpkg-source --commit.
All affected files have new timestamps and show the old content
before my changes. I.e. the state as in
  libisoburn_1.4.2.orig.tar.gz


The error abort of  debuild -S  persists even after a previous
failed run restored the old content of the files.
The problem vanishes only after i remove the patch.

So i appears that my patch does influence the expectations of
dpkg-source. But it either does not get applied after unpacking
the source, or the result is in some way overridden by a later
copying from original tarball.


I created the work directory tree by

  cd ~
  wget http://files.libburnia-project.org/releases/libisoburn-1.4.2.tar.gz
  cd ...path.../debian_dir
  tar xzf ~/libisoburn-1.4.2.tar.gz
  mv ~/libisoburn-1.4.2.tar.gz libisoburn_1.4.2.orig.tar.gz
  cd libisoburn-1.4.2
  cp -a ...path.../svn/libisoburn/debian debian

The last action copied the ./debian directory of the local SVN
instance of 
  svn://anonscm.debian.org/pkg-libburnia/trunk/libisoburn/
(Changes to ./debian will later be copied back and committed to SVN.)

As said: Except the patching problem, this setup does what i expect.
I deem it quivalent to what is described in
  https://www.debian.org/doc/manuals/maint-guide/first.en.html
Am i wrong ?


Have a nice day :)

Thomas

Bug#790412: RFS: circus/0.12.0-1

[David Douard]

On 11/09/2015 08:51 AM, David Douard wrote:
> On 11/06/2015 04:30 PM, Gianfranco Costamagna wrote:
>> Hi,
>>
> 


Hi,

I've (at last) reuploaded a version of circus (0.12.1) on mentors. 
I've disabled the tests, as suggested by Gianfranco, in order to have a package.

I'll try to figure out how to reenable them properly in a next release.

Cheers,

David


> Hi
> 
> sorry I had no time to spend on this RFS, but yes I'm still interested in 
> finishing it (I do currently 
> use circus it on several setups).
> 
> I'll take time this week to respond and fix the packaging.
> 
> cheers,
> 
> David
>   
> 
>> ping, if you are still interested, please answer and fix the above :)
>> (or ask about how to fix it)
>>
>> otherwise I'll close the RFS and unassign myself, I do not like to
>> keep RFS bugs open for too long time, and there is no need to upload
>> if you aren't interested anymore :)
>>
>> cheers,
>>
>> G.
>>
>> On Mon, 19 Oct 2015 10:31:25 + (UTC) Gianfranco Costamagna
>>  wrote:
>>> I use pbuilder-dist, and it doesn't work either
>>
>>> ['sudo', 'HOME=/home/locutus', 'ARCHITECTURE=amd64',
>>> 'DISTRIBUTION=sid', 'ARCH=amd64', 'DIST=sid', 'DEB_BUILD_OPTIONS=',
>>> 'pbuilder', '--build', '--distribution', 'sid', '--buildresult',
>>> '/home/locutus/pbuilder/sid_result', '--basetgz',
>>> '/home/locutus/pbuilder/sid-base.tgz', '--logfile',
>>> u'/home/locutus/pbuilder/sid_result/circus_0.12.1+dfsg-1_amd64.build',
>>> '--mirror', 'http://ftp.debian.org/debian', '--debootstrapopts',
>>> '--keyring=/usr/share/keyrings/debian-archive-keyring.gpg',
>>> '--aptcache', '/home/locutus/pbuilder/aptcache/debian',
>>> '--components', 'main contrib non-free',
>>> '/tmp/circus_0.12.1+dfsg-1.dsc']
>>
>>
>>
>>> pbuilder 0.219 from sid/stretch
>>
>>> cheers,
>>
>>> G.
>>
>>
>>
>>
>>> Il Lunedì 19 Ottobre 2015 12:24, Mattia Rizzolo
>>>  ha scritto: On Mon, Oct 19, 2015 at 10:50:21AM
>>> +0200, David Douard wrote:
 After a quick search, Luca Falavigna pointed me to the fact that
 debomatic uses a no-network wrapper for sbuild (runs sbuild in an
 "unshare -n" env) in which the lo device was not up. He uploaded
 a fix for this a couple of days ago, so I'd like to try a new
 build from the same source package.
>>
>>> Well, this afaik is not supported. packages are allowed to use the
>>> lo device during the build. In pbuilder we use this wrapper to set
>>> it up:
>>
>>> ``` % cat
>>> /usr/lib/pbuilder/pbuilder-unshare-wrapper #!/bin/sh
>>
>>> die() { echo >&2 E: "$2" returned error code "$1" echo >&2 N: Could
>>> not set up the loopback interface. exit 1 }
>>
>>> if test -x /sbin/ifconfig; then /sbin/ifconfig lo up || die $?
>>> ifconfig elif test -x /sbin/ip; then /sbin/ip link set lo up || die
>>> $? ip elif test -x /bin/ip; then /bin/ip link set lo up || die $?
>>> ip else echo >&2 E: Neither ifconfig nor ip found. echo >&2 N:
>>> Could not set up the loopback interface. exit 1 fi
>>
>>> # having this variable set could cause programs looking for
>>> unreachable machines unset http_proxy
>>
>>> exec "$@"
>>
>>> 
>>
 I'm not sure wether the package must be reuploaded on debomatic
 or if a rebuild dcut command is enough (since the source package
 has not been uploaded in the main debian queues for now).
>>
>>> Gian, can you try build it in pbuilder (which unshare the network
>>> by default) and see if it builds there?  if it does I'd just blame
>>> the debomatic unshare setup :)
>>
> 


-- 

David DOUARD LOGILAB
Directeur du département Outils & Systèmes

+33 1 45 32 03 12david.dou...@logilab.fr
+33 1 83 64 25 26http://www.logilab.fr/id/david.douard

Formations - http://www.logilab.fr/formations
Développements - http://www.logilab.fr/services
Gestion de connaissances - http://www.cubicweb.org/
<>

signature.asc
Description: OpenPGP digital signature

Re: Copyright of composite Makefile.in files

[Vincent Bernat]

 ❦ 30 novembre 2015 10:41 +0100, Ferenc Wagner  :

> Makefile.in files distributed in an upstream tarball often have several
> copyright notices: the FSF copyleft at the top added by Automake and
> later those carried over from other macro packages included into
> Makefile.am (for example: include doxygen.am).  The result is like
> this:

Usually, autoconf generated files are ignored in
debian/copyright. That's a "special unwritten" rule. You don't need to
mention them, you don't need to exclude them from the tarball. It's
better to regenerate them from source during build time.
-- 
Parenthesise to avoid ambiguity.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Copyright of composite Makefile.in files

[Alex Vong]

Hi,

I am not a mentor, the following is just my opinions:

I think if possible, Makefile.in should not be included in tarball,
since dh_autoreconf will re-generate it at build-time anyway. But I
think it is fine to keep it if the upstream tarball provides it since
it does not worth repacking the tarball just to remove generated
files.

I don't know how Makefile.in is being handled in particular, but I
think in general, if one file has more than one copyright notice, then
we should use `and` to connect compatible licenses and add all authors
(or organizations) as copyright-holders.

So, in this case I would suggest the following:

Files: */Makefile.in
Copyright: 1994-2014 Free Software Foundation, Inc.
   2004 Oren Ben-Kiki
License: FSF-unlimited

Of course, one should always follow

if possible.

Cheers,
Alex

On 30/11/2015, Ferenc Wagner  wrote:
> Dear mentors,
>
> Makefile.in files distributed in an upstream tarball often have several
> copyright notices: the FSF copyleft at the top added by Automake and
> later those carried over from other macro packages included into
> Makefile.am (for example: include doxygen.am).  The result is like this:
>
>
> # Makefile.in generated by automake 1.15 from Makefile.am.
> # @configure_input@
>
> # Copyright (C) 1994-2014 Free Software Foundation, Inc.
>
> # This Makefile.in is free software; the Free Software Foundation
> # gives unlimited permission to copy and/or distribute it,
> # with or without modifications, as long as this notice is preserved.
>
> # This program is distributed in the hope that it will be useful,
> # but WITHOUT ANY WARRANTY, to the extent permitted by law; without
> # even the implied warranty of MERCHANTABILITY or FITNESS FOR A
> # PARTICULAR PURPOSE.
>
> @SET_MAKE@
>
> # Copyright (C) 2004 Oren Ben-Kiki
> # This file is distributed under the same terms as the Automake macro
> files.
> [...]
>
>
> In debian/copyright I have the following paragraphs:
>
>
> Files: */Makefile.in
> Copyright: 1994-2014 Free Software Foundation, Inc.
> License: FSF-unlimited
>
> Files: doxygen.am
> Copyright: 2004 Oren Ben-Kiki
> License: FSF-unlimited
>
>
> Shall I note that ./Makefile.in includes ./doxygen.am and thus carries
> both copyright notices?
> --
> Thanks,
> Feri.
>
>

Copyright of composite Makefile.in files

[Ferenc Wagner]

Dear mentors,

Makefile.in files distributed in an upstream tarball often have several
copyright notices: the FSF copyleft at the top added by Automake and
later those carried over from other macro packages included into
Makefile.am (for example: include doxygen.am).  The result is like this:


# Makefile.in generated by automake 1.15 from Makefile.am.
# @configure_input@

# Copyright (C) 1994-2014 Free Software Foundation, Inc.

# This Makefile.in is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.

# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE.

@SET_MAKE@

# Copyright (C) 2004 Oren Ben-Kiki
# This file is distributed under the same terms as the Automake macro files.
[...]


In debian/copyright I have the following paragraphs:


Files: */Makefile.in
Copyright: 1994-2014 Free Software Foundation, Inc.
License: FSF-unlimited

Files: doxygen.am
Copyright: 2004 Oren Ben-Kiki
License: FSF-unlimited


Shall I note that ./Makefile.in includes ./doxygen.am and thus carries
both copyright notices?
-- 
Thanks,
Feri.