Please help upgrading eigensoft

[Andreas Tille]

Hi,

I tried to upgrade eigensoft[1].  The build fails with:

...
cc -Wl,-z,relro  pca.o eigensrc/eigsubs.o eigx.o nicksrc/libnick.a  -lgsl 
-lblas -lgfortran -lrt -lm -o pca
eigx.o: In function `eigx_':
/build/eigensoft-6.1.2+dfsg/src/eigx.c:100: undefined reference to `dspev_'
eigx.o: In function `eigxv_':
/build/eigensoft-6.1.2+dfsg/src/eigx.c:126: undefined reference to `dspev_'
eigx.o: In function `cdc_':
/build/eigensoft-6.1.2+dfsg/src/eigx.c:145: undefined reference to `dpotrf_'
eigx.o: In function `inverse_':
/build/eigensoft-6.1.2+dfsg/src/eigx.c:186: undefined reference to `dgetrf_'
/build/eigensoft-6.1.2+dfsg/src/eigx.c:194: undefined reference to `dgetri_'
eigx.o: In function `solve_':
/build/eigensoft-6.1.2+dfsg/src/eigx.c:223: undefined reference to `dgetrf_'
/build/eigensoft-6.1.2+dfsg/src/eigx.c:230: undefined reference to `dgetrs_'
eigx.o: In function `geneigsolve_':
/build/eigensoft-6.1.2+dfsg/src/eigx.c:250: undefined reference to `dsygv_'
collect2: error: ld returned 1 exit status
: recipe for target 'pca' failed
make[2]: *** [pca] Error 1
...

That's strange sinde the according functions have prototypes in the very
same c file.  Any idea what might be wrong here?

Kind regards

   Andreas.


[1] https://anonscm.debian.org/debian-med/eigensoft.git

-- 
http://fam-tille.de

Re: reproducible-builds

[Adam Borowski]

On Mon, Jul 18, 2016 at 06:20:51PM -0300, Herbert Fortes wrote:
> Em Seg, 2016-07-18 às 20:28 +0800, Paul Wise escreveu:
> > On Mon, Jul 18, 2016 at 8:18 PM, Herbert Fortes wrote:
> > 
> > > I did a QA and reproducible-builds says that
> > > it FTBFS with armhf on 2016-07-09. The
> > > build was not tried again.
> > 
> > Which package ?
> 
> dvbackup

> Sat Jul  9 06:41:09 UTC 2016 - the second build failed, even though the first 
> build was successful.
> https://tests.reproducible-builds.org/debian/unstable/armhf/dvbackup : 
> reproducible ➤ FTBFS

I'm probably missing something, but where's the failure in that log?
All I see is just some warnings but the build finishes successfully.

Can't reproduce at home either, regular (nonreproducible) unstable:

Host: armhf, kernel 3.8, Odroid-U2
* armhf (repeated 4 times)
* armel
Host: amd64, kernel 4.7-rc7+stuff
* amd64
* i386
* x32
* arm64 (qemu)
* armhf (qemu)

-- 
An imaginary friend squared is a real enemy.

Re: reproducible-builds

[Herbert Fortes]

Em Seg, 2016-07-18 às 20:28 +0800, Paul Wise escreveu:
> On Mon, Jul 18, 2016 at 8:18 PM, Herbert Fortes wrote:
> 
> > I did a QA and reproducible-builds says that
> > it FTBFS with armhf on 2016-07-09. The
> > build was not tried again.
> 
> Which package ?


dvbackup
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/dvbackup.html

At the end has:

[...]
I: Current time: Fri Jul  8 18:38:51 GMT+12 2016
I: pbuilder-time-stamp: 1468046331
Sat Jul  9 06:41:09 UTC 2016 - the second build failed, even though the first 
build was successful.

https://tests.reproducible-builds.org/debian/unstable/armhf/dvbackup : 
reproducible ➤ FTBFS
Sat Jul  9 06:41:11 UTC 2016 - total duration: 0h 6m 25s.



regards,
--
Herbert Parentes Fortes Neto (hpfn)


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

Re: uscan for a single text file

[Sergio Durigan Junior]

On Sunday, July 17 2016, Ole Streicher wrote:

> Sergio Durigan Junior  writes:
>> On Saturday, July 16 2016, Ole Streicher wrote:
>>
>>> Sergio Durigan Junior  writes:
> What is wrong here? I thought that mk-orig.tar.gz should be called only
> when it is a tar archive?

 Yeah, uscan is the responsible for invoking mk-origtargz.  That can be a
 problem indeed for cases like yours.
>>>
>>> Hmm, the manpage of uscan says:
>>>
>>> | Please note the repacking of the upstream tarballs by mk-origtargz
>>> | happens only if one of the following conditions is satisfied:
>>> |  · USCAN_REPACK is set in the devscript configuration.
>>> |  · --repack is set on the commandline.
>>> |  · repack is set in the watch line as opts="repack,...".
>>> |  · The upstream archive is of zip type including jar, xpi, ...
>>> |  · Files-Excluded or Files-Excluded-component stanzas are set in
>>> |debian/copyright to make mk-origtargz invoked from uscan remove 
>>> |files from the upstream tarball and repack it.
>>>
>>> Non of these is true in my case. So, isn't this a bug in uscan?
>>
>> This snippet refers to the repacking of the upstream tarball.  Even when
>> no repacking is needed/requested, mk-origtargz is still invoked (it is
>> resposible for creating the symlink to the .orig.tar.gz file, for
>> example).
>
> If mk-origtargz doesn't repack it, why does it look into it? The symlink
> could be created without as well.

It makes sure that there is a tarball compressed using the supported
compression mechanisms, even when it is not interested in unpacking the
tarball.  This is a design decision, and I don't know why it was made
this way.  I obviously agree with you that it could be improved.

I agree with Paul Wise when he says that mk-origtargz should create a
tarball if the file provided by the user is not one.  I guess I'll give
this idea a try later (when I have time).

>> Yeah, it is curious that mk-origtargz and uupdate both create the same
>> symlink from the original tarball to the .orig tarball.
>
> What is the use of uupdate in current workflows (f.e. git-buildpackage)
> at all? In my opinion, it is bound to one very specific workflow, which
> at least I personally never used. And the rest of the watch/uscan
> procedure is workflow-agnostic; it is just the canonical way to get a
> new upstream tarball.

uupdate not only creates the symlink, but also does some "house-keeping"
(it makes sure debian/rules is executable, for example).  It will
perform different tasks depending on the version you specify in your
watch file.

> So wouldn'it it be better to just replace uupdate by an adjusted
> mk-origtargz script? Then, one could replace it by an specific script if 
> needed.

Actually, I think it makes more sense to extend mk-origtargz and make it
honour its name: create an .orig.tar.gz tarball *even* when upstream
does not provide a tarball.

> BTW, in the queue of casacore-data packages we would also need a watch
> file + script for packages which download ~100 individual files and put
> them into a tarball (Upstream doesn't offer a tar download option). Any
> good ideas here?

Hm, I couldn't find any casacore-data package.  But I found the casacore
package, which points me to  as
its upstream.  There, I could find the .tar.gz file provided by git
tags, so I'm not sure if I understood your question, sorry.  Could you
expand it to me, please?

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: uscan for a single text file

[Sergio Durigan Junior]

On Monday, July 18 2016, Gianfranco Costamagna wrote:

>>Seriously, though.  I've also had to do a few modifications to the
>>get-orig-source.sh script, and you'll also need to run uscan with the
>>--no-symlink option, but this should work.  Oh, and you will also need
>>to specify downloadurlmangle like this:
>>
>>  opts="downloadurlmangle=s@(.*)@http:$1@" \
>>  
>> http://download.virtualbox.org/virtualbox/([\d\.\-]+)/VBoxGuestAdditions_([\d\.\-]+).iso
>>  \
>>debian /bin/sh debian/get-orig-source.sh
>
>
> I did this for virtualbox
> "downloadurlmangle=s/^/http:/"
>
> does this works too? I would like to keep it simple, or understand what it is 
> doing :)

Sure!  Even better ;-).

>>if [ $# -ne 2 ]; then
>>  echo "Error: 3 parameters are required."
>>  exit 1
>>fi
>
>
> what is correct? 2 or 3?

Sorry, forgot to change the error message.  The correct is 2.

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: Bug#831694: RFS: shadowsocks-libev/2.4.7+20160630+ds-3 -- lightweight and secure socks5 proxy

[Jakub Wilk]

* Christian Seiler , 2016-07-18, 17:21:

I'm not a DD,


Sounds like a bug to me!

--
Jakub Wilk

Bug#831694: RFS: shadowsocks-libev/2.4.7+20160630+ds-3 -- lightweight and secure socks5 proxy

[Christian Seiler]

On 07/18/2016 05:40 PM, Roger Shimizu wrote:
> On Tue, Jul 19, 2016 at 12:21 AM, Christian Seiler  wrote:
>> Please don't disable the SSP unconditionally, because it's a useful
>> defense-in-depth strategy. Especially since you are packaging a
>> network service, I would really recommend not doing that.
> 
> My bad on wording of changelog.
> Actually it means turn off the broken hardening by upstream, and only
> use hardening by Debian (from dpkg-buildflags)
> So this change won't lower the security check.

Then everything's fine w.r.t. hardening. :-)

I would still recommend you disable -Werror though, in order to
not run into trouble at some later point in time. (As I said:
-Werror is really useful if you're developing the software, but
it should IMHO never be used for production builds.) But it's
not urgent to do so, especially if you plan on uploading newer
versions soon anyway.

>> [0004/0005 patches]
> Indeed.
> This makes more clear.
> I'll update the changelog entry on next release.

Great! :)

Regards,
Christian
(who will take a look at the package because it sounds really
interesting)

Bug#831694: RFS: shadowsocks-libev/2.4.7+20160630+ds-3 -- lightweight and secure socks5 proxy

[Roger Shimizu]

Dear Christian,

Thanks for your review!

On Tue, Jul 19, 2016 at 12:21 AM, Christian Seiler  wrote:
> I'm not a DD, so I can't sponsor, but:
>
> On 07/18/2016 04:53 PM, Roger Shimizu wrote:
>>   * debian/rules:
>> - Add param "--disable-ssp" to dh_auto_configure command.
>>   Thanks to Aaron M. Ucko and Boyuan Yang. (Closes: #829498)
>
> Please don't disable the SSP unconditionally, because it's a useful
> defense-in-depth strategy. Especially since you are packaging a
> network service, I would really recommend not doing that.

My bad on wording of changelog.
Actually it means turn off the broken hardening by upstream, and only
use hardening by Debian (from dpkg-buildflags)
So this change won't lower the security check.

>> - Cherry-Pick two patch from upstream as 0004 and 0005
>
> Generally you should describe in the changelog what these patches
> do. I would hence suggest an entry like:
>
>- Cherry-pick the following upstream patches:
>* Fix typo in argument passed to manager command.
>* Use SO_REUSEADDR for remote socket

Indeed.
This makes more clear.
I'll update the changelog entry on next release.
Thank you!

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#831694: RFS: shadowsocks-libev/2.4.7+20160630+ds-3 -- lightweight and secure socks5 proxy

[Christian Seiler]

I'm not a DD, so I can't sponsor, but:

On 07/18/2016 04:53 PM, Roger Shimizu wrote:
>   * debian/rules:
> - Add param "--disable-ssp" to dh_auto_configure command.
>   Thanks to Aaron M. Ucko and Boyuan Yang. (Closes: #829498)

Please don't disable the SSP unconditionally, because it's a useful
defense-in-depth strategy. Especially since you are packaging a
network service, I would really recommend not doing that.

The actual problem appears to be that the build system of your
package sets -Werror (see the build log [1]), because normally
using -fstack-protector* on unsupported architectures is harmless
and just produces a warning.

-Werror is a really bad idea for Debian packages anyway. It's great
for development to squash bugs, but -Werror can also easily break
binNMUs with a later compiler version that introduced a new warning.
(This has happened many times in the past.)

So I would really suggest you disable -Werror for package builds
(there's probably another configure flag for that; if not, ask
upstream for one), then you don't have to disable the SSP and on
platforms that don't support it you'll just get a warning in the
build logs. (And once they do support SSP at some point in the
future with a newer compiler version, then a simple binNMU will
suffice to make use of that.)

> - Cherry-Pick two patch from upstream as 0004 and 0005

Generally you should describe in the changelog what these patches
do. I would hence suggest an entry like:

   - Cherry-pick the following upstream patches:
   * Fix typo in argument passed to manager command.
   * Use SO_REUSEADDR for remote socket

Regards,
Christian

Bug#831694: marked as done (RFS: shadowsocks-libev/2.4.7+20160630+ds-3 -- lightweight and secure socks5 proxy)

[Debian Bug Tracking System]

Your message dated Mon, 18 Jul 2016 15:19:13 + (UTC)
with message-id <593830157.1708207.1468855153577.javamail.ya...@mail.yahoo.com>
and subject line Re: Bug#831694: RFS: shadowsocks-libev/2.4.7+20160630+ds-3 -- 
lightweight and secure socks5 proxy
has caused the Debian Bug report #831694,
regarding RFS: shadowsocks-libev/2.4.7+20160630+ds-3 -- lightweight and secure 
socks5 proxy
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
831694: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831694
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
package: sponsorship-requests
severity: normal
X-Debbugs-Cc: rogershim...@gmail.com, max.c...@gmail.com, 073p...@gmail.com

Dear mentors,

I am looking for a sponsor for my package "shadowsocks-libev"

 * Package name: shadowsocks-libev
   Version : 2.4.7+20160630+ds-3
   Upstream Author : Max Lv 
 * URL : https://www.shadowsocks.org
 * License : GPL-3+
   Section : net

It builds those binary packages:

 libshadowsocks-dev - lightweight and secure socks5 proxy (development files)
 libshadowsocks1 - lightweight and secure socks5 proxy (shared library)
 shadowsocks-libev - lightweight and secure socks5 proxy

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

  https://mentors.debian.net/package/shadowsocks-libev

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/shadowsocks-libev/shadowsocks-libev_2.4.7+20160630+ds-3.dsc

Changes since the last upload:

  * debian/rules:
- Add param "--disable-ssp" to dh_auto_configure command.
  Thanks to Aaron M. Ucko and Boyuan Yang. (Closes: #829498)
  * debian/patches:
- Add 0003 patch, to fix PATH_MAX for GNU/Hurd.
- Cherry-Pick two patch from upstream as 0004 and 0005

I pushed my changes to git repo:
https://anonscm.debian.org/cgit/collab-maint/shadowsocks-libev.git/log/?h=new

If it's convenient for you, please kindly setup DM upload permission
of this package for me.
Thank you!

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1
--- End Message ---
--- Begin Message ---
Hi,


>I am looking for a sponsor for my package "shadowsocks-libev"


On unstable shortly

G.--- End Message ---

Bug#831692: marked as done (RFS: skiboot/5.2.4-2 update)

[Debian Bug Tracking System]

Your message dated Mon, 18 Jul 2016 15:11:11 + (UTC)
with message-id <1457957365.1676995.1468854671642.javamail.ya...@mail.yahoo.com>
and subject line Re: Bug#831692: RFS: skiboot/5.2.4-2 update
has caused the Debian Bug report #831692,
regarding RFS: skiboot/5.2.4-2 update
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
831692: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831692
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---


Package: sponsorship-requests
Severity: normal

Dear mentors, Gianfranco,

I am looking for a sponsor for the package "skiboot". This is a packaging 
update :

skiboot (5.2.4-2) unstable; urgency=medium

  * Forced no-pie for Ubuntu 16.10 as previous change was not enough : in 16.10
gcc's default change to build PIE by default.

 -- Frederic Bonnard   Mon, 18 Jul 2016 15:52:41 
+0200


 Package name: skiboot
 Version : 5.2.4-2
 Upstream Author : skiboot team
 URL : http://github.com/open-power/skiboot/
 License : Apache-2.0, CC0, BSD-2-Clause, MIT/X11-BSD-like
 Section : admin

It builds those binary packages:

  opal-prd   - OPAL Processor Recovery Diagnostics daemon
  opal-utils - OPAL firmware utilities

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

https://mentors.debian.net/package/skiboot


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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/skiboot/skiboot_5.2.4-2.dsc

More information about skiboot can be obtained from 
http://github.com/open-power/skiboot/


Regards,
 Frederic Bonnard
--- End Message ---
--- Begin Message ---
Hi
>I am looking for a sponsor for the package "skiboot". This is a packaging 
>update :


done

G.--- End Message ---

Bug#831694: RFS: shadowsocks-libev/2.4.7+20160630+ds-3 -- lightweight and secure socks5 proxy

[Roger Shimizu]

package: sponsorship-requests
severity: normal
X-Debbugs-Cc: rogershim...@gmail.com, max.c...@gmail.com, 073p...@gmail.com

Dear mentors,

I am looking for a sponsor for my package "shadowsocks-libev"

 * Package name: shadowsocks-libev
   Version : 2.4.7+20160630+ds-3
   Upstream Author : Max Lv 
 * URL : https://www.shadowsocks.org
 * License : GPL-3+
   Section : net

It builds those binary packages:

 libshadowsocks-dev - lightweight and secure socks5 proxy (development files)
 libshadowsocks1 - lightweight and secure socks5 proxy (shared library)
 shadowsocks-libev - lightweight and secure socks5 proxy

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

  https://mentors.debian.net/package/shadowsocks-libev

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/shadowsocks-libev/shadowsocks-libev_2.4.7+20160630+ds-3.dsc

Changes since the last upload:

  * debian/rules:
- Add param "--disable-ssp" to dh_auto_configure command.
  Thanks to Aaron M. Ucko and Boyuan Yang. (Closes: #829498)
  * debian/patches:
- Add 0003 patch, to fix PATH_MAX for GNU/Hurd.
- Cherry-Pick two patch from upstream as 0004 and 0005

I pushed my changes to git repo:
https://anonscm.debian.org/cgit/collab-maint/shadowsocks-libev.git/log/?h=new

If it's convenient for you, please kindly setup DM upload permission
of this package for me.
Thank you!

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#831692: RFS: skiboot/5.2.4-2 update

[Frederic Bonnard]

Package: sponsorship-requests
Severity: normal

Dear mentors, Gianfranco,

I am looking for a sponsor for the package "skiboot". This is a packaging 
update :

skiboot (5.2.4-2) unstable; urgency=medium

  * Forced no-pie for Ubuntu 16.10 as previous change was not enough : in 16.10
gcc's default change to build PIE by default.

 -- Frederic Bonnard   Mon, 18 Jul 2016 15:52:41 
+0200


 Package name: skiboot
 Version : 5.2.4-2
 Upstream Author : skiboot team
 URL : http://github.com/open-power/skiboot/
 License : Apache-2.0, CC0, BSD-2-Clause, MIT/X11-BSD-like
 Section : admin

It builds those binary packages:

  opal-prd   - OPAL Processor Recovery Diagnostics daemon
  opal-utils - OPAL firmware utilities

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

https://mentors.debian.net/package/skiboot


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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/skiboot/skiboot_5.2.4-2.dsc

More information about skiboot can be obtained from 
http://github.com/open-power/skiboot/


Regards,
 Frederic Bonnard

Re: Help with shlibs system

[Gianfranco Costamagna]

Hi,


>http://abi-laboratory.pro/tracker/


thanks, I asked upstream
https://github.com/open-source-parsers/jsoncpp/issues/499

>It might be interesting to have a service like this for all Debian
>packages containing C/C++/Java libraries.


that would save a lot of segfaults and time :)

thanks,

G.

Re: Help with shlibs system

[Paul Wise]

On Mon, Jul 18, 2016 at 8:47 PM, Gianfranco Costamagna wrote:

> I would like to know if upstream is using some different service now

The replacement service is here but it doesn't check jsoncpp:

http://abi-laboratory.pro/tracker/

It might be interesting to have a service like this for all Debian
packages containing C/C++/Java libraries.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Help with shlibs system

[Gianfranco Costamagna]

Hi,



>I don't see what upstream dedication to ABI compatibility has to to with
>symbol files.


typo :)


>Anyway, the reason we're having this thread is because apparently 
>libjsoncpp broke ABI without SONAME change, so maybe they're not taking 

>it seriously enough. :>

actually after sending this email, I discovered that the service is broken and
moving somewhere else, in fact the latest releases haven't been checked for 
symbols
changes

"Unfortunately, we cannot support the service anymore. Sorry for inconvenience.
The suitable replacement for this tool will be available at github.com/lvc soon.
ROSA Laboratory, 21 July 2015."

I would like to know if upstream is using some different service now

Gianfranco

Re: Help with shlibs system

[Jakub Wilk]

* Gianfranco Costamagna , 2016-07-18, 11:53:

Symbols files are usually better since you get more fine grained

control of dependencies, but they take a lot more time to maintain 
(especially for C++ libraries).


In this very specific case, I think we don't need it, as I explained 
here [1] and you can see how upstream is taking seriously the ABI now 
[2]


I don't see what upstream dedication to ABI compatibility has to to with 
symbol files.


Anyway, the reason we're having this thread is because apparently 
libjsoncpp broke ABI without SONAME change, so maybe they're not taking 
it seriously enough. :>


--
Jakub Wilk

Re: reproducible-builds

[Paul Wise]

On Mon, Jul 18, 2016 at 8:18 PM, Herbert Fortes wrote:

> I did a QA and reproducible-builds says that
> it FTBFS with armhf on 2016-07-09. The
> build was not tried again.

Which package?

> I can do something about the status of the
> package on reproducible-builds ? Or just
> wait for a new try by them ?

You can ask for a retry or other help on the #debian-reproducible IRC channel.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

reproducible-builds

[Herbert Fortes]

Hi,

I did a QA and reproducible-builds says that
it FTBFS with armhf on 2016-07-09. The
build was not tried again.

I did a build with harris (ssh) and the build
ran fine.

I can do something about the status of the 
package on reproducible-builds ? Or just
wait for a new try by them ?



regards,
-- Herbert Parentes Fortes Neto (hpfn)

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

Re: Help with shlibs system

[Gianfranco Costamagna]

Hi,

>Symbols files are usually better since you get more fine grained

>control of dependencies, but they take a lot more time to maintain
>(especially for C++ libraries).


In this very specific case, I think we don't need it, as I explained here [1]
and you can see how upstream is taking seriously the ABI now [2]

cheers,

G.


[1] https://bugs.launchpad.net/ubuntu/+source/libjsoncpp/+bug/1461517

[2] http://upstream.rosalinux.ru/versions/jsoncpp.html

Re: Help with shlibs system

[James Cowgill]

Hi,

On Mon, 2016-07-18 at 12:48 +0200, Peter Spiess-Knafl wrote:
> I would need some advice about the following bug:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820434
> 
> Stephen mentioned there I should provide a shlibs minimum version.
> I am not entirely sure what that means.
> Do I need to put a file under debian/shlibs with the following line?
> 
> libjsoncpp 1 libjsoncpp1
> 
> dh_makeshlibs creates exactly such a file under
> debian/libjsoncpp1/DEBIAN/shlibs.
> 
> What am I missing here?

An "shlibs minimum version" is a change to the shlibs/symbols control
files which causes reverse dependencies to emit something like
'Depends: libjsoncpp1 (>= XX)' instead of 'Depends: libjsoncpp1'

To do this you can either add a symbols file (this is documented in
policy), or override dh_makeshlibs with 'dh_makeshlibs -Vversion' if
you want to use a simple shlibs file. See dh_makeshlibs(1).

Symbols files are usually better since you get more fine grained
control of dependencies, but they take a lot more time to maintain
(especially for C++ libraries).

James

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

Help with shlibs system

[Peter Spiess-Knafl]

Hi!

I would need some advice about the following bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820434

Stephen mentioned there I should provide a shlibs minimum version.
I am not entirely sure what that means.
Do I need to put a file under debian/shlibs with the following line?

libjsoncpp 1 libjsoncpp1

dh_makeshlibs creates exactly such a file under
debian/libjsoncpp1/DEBIAN/shlibs.

What am I missing here?

Thank you and Greetings
Peter



signature.asc
Description: OpenPGP digital signature

Bug#830569: marked as done (RFS: z3/4.4.1-0.1 [NMU] [4xRC])

[Debian Bug Tracking System]

Your message dated Mon, 18 Jul 2016 10:20:53 + (UTC)
with message-id <1147299283.1384565.1468837253651.javamail.ya...@mail.yahoo.com>
and subject line Re: Bug#830569: RFS: z3/4.4.1-0.1 [NMU] [4xRC]
has caused the Debian Bug report #830569,
regarding RFS: z3/4.4.1-0.1 [NMU] [4xRC]
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
830569: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830569
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for a NMU of the z3 package.

The update attempts to fix four RC bugs currently reported for z3.

Changes since the last upload:

   * New upstream release.
   * Remove patches that were fixed upstream:
  - signed_char01
  - signed_char02
  - signed_char03
  - signed_char04
  - disable_test
  - disable_test2
  - disable_test3
  - disable_test4 (upstream issue has been closed:
 https://github.com/Z3Prover/z3/issues/210)
  - fix_conflict
   * Migrate remaining patches to DEP-3 format.
   * Rewrite typos.patch to apply to new version of z3.
   * Add patch fix-dotnet-version.patch (Closes: #808695).
   * Upgrade to Standards version 3.9.8 (no changes).
   * Install shared libraries into new libz3-4 package (Closes: #819884).
   * Install python files directly into /usr/lib/python2.7/dist-packages/
 (Closes: #802272).
   * Clean up debian/rules.
   * Remove unnecessary version restriction of build dependency
 cli-common-dev.
   * Format debian/control with cme.
   * Fix debian/copyright: Change MIT to Expat and move Expat license text
 into separate license block so that it covers both file blocks.
   * Move libz3-ocaml-dev into section ocaml.
   * Add preinst scripts to remove directories from older versions to allow
 debhelper to install symlinks (Closes: #823573).
   * Disable tests as they fail eventually.

As for the Lintian warnings: I've tried building z3 with hardening
flags turned on, but the build failed. I don't know what the problem
with the -dev package is; contrary to what Lintian claims, it *does*
contain a symlink to the respective shared library.

There are a few other issues that I was not able to fix, but I think
closing the four RC bugs has a higher priority right now.

The package is available on Mentors:

  https://mentors.debian.net/package/z3

  dget -x https://mentors.debian.net/debian/pool/main/z/z3/z3_4.4.1-0.1.dsc

Regards,
 Fabian Wolff
--- End Message ---
--- Begin Message ---
Hi

the package should be on its way for unstable.

cheers,

Gianfranco--- End Message ---

Re: uscan for a single text file

[Gianfranco Costamagna]

Hi Sergio,




>Oh, I have a solution!  Get rid of this proprietary software on Debian!
>;-)


lol :)
>Seriously, though.  I've also had to do a few modifications to the
>get-orig-source.sh script, and you'll also need to run uscan with the
>--no-symlink option, but this should work.  Oh, and you will also need
>to specify downloadurlmangle like this:
>
>  opts="downloadurlmangle=s@(.*)@http:$1@" \
>  
> http://download.virtualbox.org/virtualbox/([\d\.\-]+)/VBoxGuestAdditions_([\d\.\-]+).iso
>  \
>debian /bin/sh debian/get-orig-source.sh


I did this for virtualbox
"downloadurlmangle=s/^/http:/"

does this works too? I would like to keep it simple, or understand what it is 
doing :)
>if [ $# -ne 2 ]; then
>  echo "Error: 3 parameters are required."
>  exit 1
>fi


what is correct? 2 or 3?

thanks a lot, I'll give it a try as soon as I reach a stable enough internet 
connection :)

Gianfranco

Bug#831642: RFS: b43-fwcutter/1:019-3

[Andrew Shadura]

Hi,

On 18 July 2016 at 06:55, Paul Wise  wrote:
> On Mon, Jul 18, 2016 at 12:44 PM, Daniel Echeverry wrote:
>
>> Note: This is a small revision because I don't have the hardware
>> appropriate to test the new patches :(

While I don't have access to b43 hardware right now, I can gain such
access (both of my laptops with b43 hardware are now in possession of
my parents), so in theory I could do some testing if needed. No timing
guarantees though.

-- 
Cheers,
  Andrew