Re: Help fixing a gettext translation test

[Mathias Gibbens]

On Tue, 2023-11-07 at 02:02 +0100, Santiago Vila wrote:
> Hi.
> 
> A similar bug which was fixed in a similar way:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052859#40
> 
> See what Aurelien Jarno (glibc maintainer) said:
> > I have seen that in the meantime you have done a new upload with
> > the en_US.UTF-8 locale, that's a perfectly valid workaround.

  Thanks for that pointer!

Mathias


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

Re: Help fixing a gettext translation test

[Santiago Vila]

Hi.

A similar bug which was fixed in a similar way:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052859#40

See what Aurelien Jarno (glibc maintainer) said:

I have seen that in the meantime you have done a new upload with the
en_US.UTF-8 locale, that's a perfectly valid workaround.


Thanks.

Help fixing a gettext translation test

[Mathias Gibbens]

Hi all,

  I'm working on fixing bug #1052803 for golang-github-gosexy-gettext.
That package's tests started failing, and I'm pretty sure it was caused
by the upload of src:glibc 2.37-8 which backported a patch from bug
#874160 that treats language encodings like C.UTF-8 as the C locale.

  This change effectively "turns off" translations, unless you specify
some specific encoding like "en_US.utf8". While I can apply the
attached patch that fixes the tests, it feels less than ideal. And as
this will be a NMU to prevent the package from being AUTORM'ed and
taking src:lxd along with it, I'd like to fix this properly. I'm just
not familiar enough with gettext to know if there's a better solution.

  A simple reproducer is listed below. On a sid system, the first
invocation will fail to return the properly translated string, but the
second will (substitute with your preferred locale).

  Thanks for any advice!

Mathias
(BCC: bug #1052803)

> $ dget 
> https://deb.debian.org/debian/pool/main/g/golang-github-gosexy-gettext/golang-github-gosexy-gettext_0~git20130221-2.1.dsc
> $ cd golang-github-gosexy-gettext-0~git20130221/
> $ LC_ALL=C.UTF-8 LANGUAGE="es_MX.utf8" TEXTDOMAINDIR=./examples/ gettext -d 
> example "Hello, world!"
> $ LC_ALL=en_US.utf8 LANGUAGE="es_MX.utf8" TEXTDOMAINDIR=./examples/ gettext 
> -d example "Hello, world!"
diff --git a/debian/control b/debian/control
index d1364e1..18690eb 100644
--- a/debian/control
+++ b/debian/control
@@ -4,7 +4,7 @@ Priority: optional
 Maintainer: Steve Langasek 
 Build-Depends: debhelper (>= 11~),
dh-golang,
-   golang-any,
+   golang-any, locales-all
 Standards-Version: 4.2.1
 Homepage: https://github.com/gosexy/gettext
 XS-Go-Import-Path: github.com/gosexy/gettext
diff --git a/debian/rules b/debian/rules
index 2d9b72c..1451b07 100755
--- a/debian/rules
+++ b/debian/rules
@@ -20,7 +20,7 @@ override_dh_auto_build:
rm obj-*/src/github.com/gosexy/gettext/examples/*/*.pot
 
 override_dh_auto_test:
-   LC_ALL=C.UTF-8 dh_auto_test
+   LC_ALL=en_US.utf8 dh_auto_test
 
 get-orig-source:
rm -rf $(PKG)

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

Bug#1034282: RFS: ukui-app-widget/1.0.1-1 [ITP] -- ukui app widget test

[handsome_feng]

Hi, Boyuan,


Sorry for this rookie, stupid mistake, Bowen only checked the results of 
'lintian' and 'licensecheck -r' when reviewing the package, not the other 
parts, including the incorrect copyright statement.
And I also confirmed the problem with the upstream author, when she took over 
the code, the headers of some files in QtSingleApplication have been 
accidentally blanked out, and she added the company's copyrights without 
checking in order to deal with the "No copyright Unknow"  warnings. 
The problem has been fixed upstream, and we'll improve the guidebook and 
training to avoid this kind of problem from occurring again.


> Your package embeds multiple copies of QtSimpleApplication. This is not a good
> practice at all. Can you work with upstream to only include one copy?

This is fixed upstream.


> Besides, I don't understand upstream commit 2e15e13. Can you explain why you
> revert version 4.x to 1.0.1?

Yes, It's no need to revert version 4.x to 1.0.1, we will upload the fixed 
version to mentors later.


Regards,

handsome_feng

Bug#1034282: RFS: ukui-app-widget/1.0.1-1 [ITP] -- ukui app widget test

[Boyuan Yang]

Control: tags -1 +moreinfo

Hi,

On Thu, 13 Apr 2023 01:11:05 +0800 xibowen  wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "ukui-app-widget":
>   https://mentors.debian.net/package/ukui-app-widget/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>   dget -x https://mentors.debian.net/debian/pool/main/u/ukui-app-widget/ukui-
> app-widget_1.0.1-1.dsc

Several issues:

* Your package embeds multiple copies of QtSimpleApplication. This is not a good
practice at all. Can you work with upstream to only include one copy?

* All QtSimpleApplication source code files have executable permission. Please
consider fixing it upstream as well.

* Your debian/copyright file did not include copyright information for most
QtSimpleApplication source code files. Please fix it.

Thanks,
Boyuan Yang


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

Bug#1037241: RFS: php-fig-log-test/1.1.0-1 [ITP] -- Test utilities for the psr/log package that backs the PSR-3 specification

[Athos Ribeiro]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "php-fig-log-test":

 * Package name : php-fig-log-test
   Version  : 1.1.0-1
   Upstream contact : Anton Ukhanev 
 * URL  : https://github.com/php-fig/log-test
 * License  : Expat
 * Vcs  : https://salsa.debian.org/athos/php-fig-log-test
   Section  : php

The source builds the following binary packages:

  php-fig-log-test - Test utilities for the psr/log package that backs the 
PSR-3 specification

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

  https://mentors.debian.net/package/php-fig-log-test/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/php-fig-log-test/php-fig-log-test_1.1.0-1.dsc

Changes for the initial release:

 php-fig-log-test (1.1.0-1) experimental; urgency=medium
 .
   * Initial release. (Closes: #1037154)

Note that, as stated in the ITP for this package, at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037154,
this should be uploaded to experimental until symfony 6 is ready to land
in unstable.

Regards,
--
Athos Ribeiro

Bug#1034282: RFS: ukui-app-widget/1.0.1-1 [ITP] -- ukui app widget test

[xibowen]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "ukui-app-widget":

 * Package name : ukui-app-widget
   Version  : 1.0.1-1
   Upstream contact : wangyan 
 * URL  : https://gitee.com/openkylin/ukui-app-widget
 * License  : BSD-3-clause, GPL-3
 * Vcs  : https://gitee.com/openkylin/ukui-app-widget
   Section  : x11

The source builds the following binary packages:

  libukui-appwidget-manager-dev - libukui app widget manager dev
  libukui-appwidget-manager0 - libukui app widget manager
  libukui-appwidget-provider-dev - libukui app widget provider dev
  libukui-appwidget-qmlplugin0 - ukui app widget plugin
  libukui-appwidget-provider0 - libukui app widget provider
  ukui-appwidget-manager - ukui app widget manager
  ukui-appwidget-test - ukui app widget test

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

  https://mentors.debian.net/package/ukui-app-widget/

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

  dget -x https://mentors.debian.net/debian/pool/main/u/ukui-app-widget/ukui-
app-widget_1.0.1-1.dsc

Changes for the initial release:

 ukui-app-widget (1.0.1-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1034274)

Regards,
--
  xibowen

Bug#1021051: marked as done (RFS: bats-support/0.3.0-1 [ITP] -- Supporting library to test bats helper libraries)

[Debian Bug Tracking System]

Your message dated Sat, 1 Oct 2022 14:15:48 +0200
with message-id 
and subject line Re: Bug#1021051: RFS: bats-support/0.3.0-1 [ITP] -- Supporting 
library to test bats helper libraries
has caused the Debian Bug report #1021051,
regarding RFS: bats-support/0.3.0-1 [ITP] -- Supporting library to test bats 
helper libraries
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.)


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

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "bats-support":

 * Package name : bats-support
   Version  : 0.3.0-1
 * URL  : https://github.com/bats-core/bats-support
 * License  : CC0-1.0
 * Vcs  : https://salsa.debian.org/bats-team/bats-support
   Section  : libdevel

The source builds the following binary packages:

  bats-support - Supporting library to test bats helper libraries

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


  https://mentors.debian.net/package/bats-support/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/bats-support/bats-support_0.3.0-1.dsc


Changes for the initial release:

 bats-support (0.3.0-1) unstable; urgency=medium
 .
   * Initial release (Closes: #1021048).

Regards,

--
Gioele Barabucci
--- End Message ---
--- Begin Message ---
On Sat, Oct 01, 2022 at 09:37:23AM +0200, Gioele Barabucci wrote:
>  * Package name : bats-support
>Version  : 0.3.0-1

>  bats-support (0.3.0-1) unstable; urgency=medium
>  .
>* Initial release (Closes: #1021048).

LGTM, in NEW.

-- 
⢀⣴⠾⠻⢶⣦⠀ Genetics say, virgin birth may not possibly produce male offspring.
⣾⠁⢠⠒⠀⣿⡁ Thus, either Jesus was fathered by (Abdes?) Pantera, or she was trans.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄ In neither case Joseph is involved, making Jesus a bastard.--- End Message ---

Bug#1021051: RFS: bats-support/0.3.0-1 [ITP] -- Supporting library to test bats helper libraries

[Gioele Barabucci]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "bats-support":

 * Package name : bats-support
   Version  : 0.3.0-1
 * URL  : https://github.com/bats-core/bats-support
 * License  : CC0-1.0
 * Vcs  : https://salsa.debian.org/bats-team/bats-support
   Section  : libdevel

The source builds the following binary packages:

  bats-support - Supporting library to test bats helper libraries

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


  https://mentors.debian.net/package/bats-support/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/bats-support/bats-support_0.3.0-1.dsc


Changes for the initial release:

 bats-support (0.3.0-1) unstable; urgency=medium
 .
   * Initial release (Closes: #1021048).

Regards,

--
Gioele Barabucci

Bug#1008930: RFS: go-junit-report/1.0.0-1 -- Convert go test output to junit xml (program)

[Bastian Germann]

Control: tags -1 moreinfo

On Mon, 4 Apr 2022 10:32:31 -0300 "Gabriel M. Dutra"  
wrote:

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "go-junit-report":

* Package name : go-junit-report
Version : 1.0.0-1
Upstream Author : TODO
* URL : https://github.com/jstemmer/go-junit-report
* License : Expat
* Vcs : https://salsa.debian.org/go-team/packages/go-junit-report
Section : golang

The source builds the following binary packages:

go-junit-report - Convert go test output to junit xml (program)

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


https://mentors.debian.net/package/go-junit-report/

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

dget -x 
https://mentors.debian.net/debian/pool/main/g/go-junit-report/go-junit-report_1.0.0-1.dsc


Changes for the initial release:

go-junit-report (1.0.0-1) UNRELEASED; urgency=medium


Please address unstable or experimental with a new package upload.


.
* Initial release (Closes: TODO)


You have to file an ITP first and fill the TODO.

Please untag moreinfo from this bug when you are done.

Bug#1008930: RFS: go-junit-report/1.0.0-1 -- Convert go test output to junit xml (program)

[Gabriel M. Dutra]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "go-junit-report":

* Package name : go-junit-report
Version : 1.0.0-1
Upstream Author : TODO
* URL : https://github.com/jstemmer/go-junit-report
* License : Expat
* Vcs : https://salsa.debian.org/go-team/packages/go-junit-report
Section : golang

The source builds the following binary packages:

go-junit-report - Convert go test output to junit xml (program)

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


https://mentors.debian.net/package/go-junit-report/

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

dget -x 
https://mentors.debian.net/debian/pool/main/g/go-junit-report/go-junit-report_1.0.0-1.dsc


Changes for the initial release:

go-junit-report (1.0.0-1) UNRELEASED; urgency=medium

Bug#998882: marked as done (RFS: tsctp/0.7.6-1 [ITP] -- SCTP Test Tool)

[Debian Bug Tracking System]

Your message dated Thu, 23 Dec 2021 23:36:29 +0100
with message-id <31508bd0-118e-2e19-4f99-a1146ce07...@debian.org>
and subject line Re: RFS: tsctp/0.7.6~test0-1
has caused the Debian Bug report #998882,
regarding RFS: tsctp/0.7.6-1 [ITP] -- SCTP Test Tool
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.)


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

Dear mentors,

I am looking for a sponsor for my package "tsctp
<https://www.uni-due.de/~be0001/tsctp/>":

  * Package name: tsctp
Version: 0.7.6~test0-1
Upstream Author: Michael Tüxen mailto:tue...@fh-muenster.de>>
  * URL: https://www.uni-due.de/~be0001/tsctp/
<https://www.uni-due.de/~be0001/tsctp/>
  * License: BSD-3-clause, GPL-3+
  * Section: net

TSCTP is an SCTP test tool. Its purpose is to perform basic SCTP
functionality tests to check implementations interoperability and to
verify that the SCTP stack is working.

"tsctp <https://www.uni-due.de/~be0001/tsctp/>" builds these binary
packages:

  * tsctp - SCTP Test Tool

To access further information about this package, please visit the
following URL:
https://mentors.debian.net/package/tsctp
<https://mentors.debian.net/package/tsctp>.

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

dget -x 
https://mentors.debian.net/debian/pool/main/t/tsctp/tsctp_0.7.6~test0-1.dsc 
<https://mentors.debian.net/debian/pool/main/t/tsctp/tsctp_0.7.6~test0-1.dsc>

More information about "tsctp <https://www.uni-due.de/~be0001/tsctp/>"
can be obtained from https://www.uni-due.de/~be0001/tsctp/
<https://www.uni-due.de/~be0001/tsctp/>.

Most recent changelog entry:

tsctp (0.7.6~test0-1ubuntu1) unstable; urgency=medium

  * New upstream release.
  * Closes: #998879 (ITP).
  * debian/control: Updated standards version to 4.6.0.1.

-- Thomas Dreibholz > Tue, 09 Nov 2021
11:04:28 +0100


-- 
Best regards / Mit freundlichen Grüßen / Med vennlig hilsen

===
 Thomas Dreibholz

 SimulaMet — Simula Metropolitan Centre for Digital Engineering
 Centre for Resilient Networks and Applications
 Pilestredet 52
 0167 Oslo, Norway
---
 E-Mail: dre...@simula.no
 Homepage:   http://simula.no/people/dreibh
===



OpenPGP_signature
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---

Hi Thomas,

Please be sure to have exactly one changelog entry which closes the ITP.
Do not add old random versions that have never been in the Debian archive.
I think I commented this on almost all of your uploads, so please apply that in 
any future RFS.
Closing this request.

Merry Christmas,
Bastian--- End Message ---

Fw: RFS: mlucas/20.1.1-1 [RC] -- program to perform Lucas-Lehmer test on a Mersenne number

[alexvong1995]

Forwarding my RFS to the debian-mentors list for attention. Thanks!
(Last message bounced, resending again...)


--
Alex

My PGP public key: 
https://notabug.org/alexvong1995/gpg-key-transition/raw/master/A5FCA28E0FF8E4C57F7CDD66FE5CB79F5A5E.asc

‐‐‐ Original Message ‐‐‐
On Tuesday, December 21, 2021 8:19 AM, alexvong1995 
 wrote:

> Package: sponsorship-requests
> Severity: important
> 

> Dear mentors,
> 

> I am looking for a sponsor for my package "mlucas":
> 

> -   Package name : mlucas
> Version : 20.1.1-1
> Upstream Author : Ernst W. Mayer 
> 

> -   URL : https://www.mersenneforum.org/mayer/README.html
> 

> -   License : GPL-2+, permissive-nowarranty-fsf, public-domain, CC0, 
> GNU-All-Permissive-License, Expat and GPL-2+, GPL-3, GPL-3+ with Autoconf 
> exception, GPL-2+ with Autoconf exception, Makefile-in-fsf, X11 and 
> public-domain-fsf, configure-fsf, CC-BY-3.0, BSD-3-clause and 
> permissive-disclaimer and GPL-2+
> 

> -   Vcs : https://notabug.org/alexvong1995/mlucas
> Section : math
> 

> It builds those binary packages:
> 

> mlucas - program to perform Lucas-Lehmer test on a Mersenne number
> 

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

> https://mentors.debian.net/package/mlucas/
> 

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

> dget -x 
> https://mentors.debian.net/debian/pool/main/m/mlucas/mlucas_20.1.1-1.dsc
> 

> Changes since the last upload:
> 

> mlucas (20.1.1-1) unstable; urgency=medium
> .
> -   New upstream release.
> -   RC bug fix release (Closes: #957547), fix FTBFS.
> -   Add dependency python3 and remove dependency python. (Closes: 
> #945666).
> -   Add dependency libgmp-dev.
> 

> Regards,
> --
> Alex Vong
>



signature.asc
Description: OpenPGP digital signature

Re: Test

[alexvong1995]

This is the final test. Feel free to ignore this message.


--
Alex

My PGP public key: 
https://notabug.org/alexvong1995/gpg-key-transition/raw/master/A5FCA28E0FF8E4C57F7CDD66FE5CB79F5A5E.asc

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Thursday, December 23, 2021 9:37 AM, alexvong1995 
 wrote:

> This is a test. Feel free to ignore this message.
> 

> 

> ---
> 

> Alex
> 

> My PGP public key: 
> https://notabug.org/alexvong1995/gpg-key-transition/raw/master/A5FCA28E0FF8E4C57F7CDD66FE5CB79F5A5E.asc



signature.asc
Description: OpenPGP digital signature

Test

[alexvong1995]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This is a test. Feel free to ignore this message.


--
Alex

My PGP public key: 
https://notabug.org/alexvong1995/gpg-key-transition/raw/master/A5FCA28E0FF8E4C57F7CDD66FE5CB79F5A5E.asc

-BEGIN PGP SIGNATURE-
Version: ProtonMail

wnUEARYKAAYFAmHEQ2EAIQkQbUC6DjvmAQUWIQTvKBEZiuFHFt8q4/JtQLoO
O+YBBeSDAQChwTazv0Bmj6N2fqVkW53/lCzthAGW6JmqKlvS2iWcqwEAsxrk
umP4yarU4cJDBkgKC+nuyKDnRhbStgT2bpenOQg=
=kr/C
-END PGP SIGNATURE-

Re: Suggestion needed on test failures due to double arithmetics

[Andrey Rahmatullin]

On Thu, Nov 25, 2021 at 01:45:49PM +0100, Giulio Paci wrote:
> Moreover I am still wondering if the compiler behavior is correct in this
> case and why it is so unstable. 
It's correct when you don't care about the amount of precision, and it's
unstable for the reasons described in gcc(1) for the options you
mentioned, e.g. "This option prevents undesirable excess precision on
machines such as the 68000 where the floating registers (of the 68881)
keep more precision than a "double" is supposed to have.  Similarly for
the x86 architecture. For most programs, the excess precision does only
good, but a few programs rely on the precise definition of IEEE floating
point.", as in different circumstances the temporary values will have or
not have the x87 80-bit precision, leading to different calculation
results.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Suggestion needed on test failures due to double arithmetics

[Giulio Paci]

Il gio 25 nov 2021, 13:21 Andrey Rahmatullin  ha scritto:

> On Thu, Nov 25, 2021 at 01:13:20PM +0100, Giulio Paci wrote:
> > The double values refer to timing information. The specific format,
> > known as CTM, stores information in seconds in decimals (e.g. "30.66"
> > seconds) from the beginning of the stream.
> > The failing tool reads this information into double variables
> Sounds like it just shouldn't read this data into a float type but use
> some fixed-point data type instead.
>

This is also my opinion (and already suggested upstream), although it would
make the code a little bit less readable.

Moreover I am still wondering if the compiler behavior is correct in this
case and why it is so unstable. Apart from this corner case (which in my
opinion should also work), I have not seen bad assumptions about double
arithmetics in the rest of the failing tool.

Bests,
Giulio

Re: Suggestion needed on test failures due to double arithmetics

[Giulio Paci]

Hi Paul,

On Thu, Nov 25, 2021 at 3:24 AM Paul Wise  wrote:
> Giulio Paci wrote:
>
> > 3) what is the most appropriate solution.
>
> As I understand it, floating point values should not be compared
> without some kind of accuracy/precision factor. Zero idea about the
> best reference for how to do it correctly, but here is a random one:
>
>
https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/

Thanks for this link.
It is a very great resource and summarizes very well what I already
know about double/float and much more.

Since the test case is dealing with timings, I think the most related
article is [1].
However even after reading that article it seems to me that in this
case it should be reasonable to expect stable behavior of those
operators.

I have uploaded simplified code that showcase the issue and some of
the instabilities [2]. The code seems to behave as if the last value
is different from the other 3, supposed equal values.
I am not even sure what I am seeing in the debugger, since most of the
values are optimized out (and I am not so skilled with debuggers).

[1] https://randomascii.wordpress.com/2012/02/13/dont-store-that-in-a-float/
[2] https://pastebin.com/embed_js/T3g560UV

Bests,
Giulio

Re: Suggestion needed on test failures due to double arithmetics

[Andrey Rahmatullin]

On Thu, Nov 25, 2021 at 01:13:20PM +0100, Giulio Paci wrote:
> The double values refer to timing information. The specific format,
> known as CTM, stores information in seconds in decimals (e.g. "30.66"
> seconds) from the beginning of the stream.
> The failing tool reads this information into double variables
Sounds like it just shouldn't read this data into a float type but use
some fixed-point data type instead.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Suggestion needed on test failures due to double arithmetics

[Giulio Paci]

On Thu, Nov 25, 2021 at 8:54 AM Andrey Rahmatullin  wrote:
>
> On Wed, Nov 24, 2021 at 06:38:07PM +0100, Giulio Paci wrote:
> > Dear mentors,
> >   while updating SCTK package I enabled the execution of the test suite
> > which was previously disabled. The tests are working fine on x86_64
> > architecture, but a couple of them are failing on i386.
> > After investigation [1] I found out that tests are failing because they
> > rely on the assumptions that, when a and b have the same double value:
> > 1) "a < b" is false;
> > 2) "a - b" is 0.0.
> What do they actually test, why do they use these assumptions?

SCTK is a toolkit to evaluate speech recognition (and other related
tasks) tools performance.
These tools usually read audio streams and produce simple text files
containing the transcriptions and time information (relative to the
stream) to synchronize the transcription to the stream. These files
are very similar to video subtitles files.
The SCTK compares two textual files (usually one is a manually created
file and the other is created by an automatic tool) to score how
different these outputs are.
The tests are checking that SCTK produces the same score reports when
provided with the same input files.

The double values refer to timing information. The specific format,
known as CTM, stores information in seconds in decimals (e.g. "30.66"
seconds) from the beginning of the stream.
The failing tool reads this information into double variables and, to
simplify, it compares "up to when the timings in one file is less than
the timings in the other files. If it exceeds or is the same, it
checks the difference".

In this kind of application you are not usually going beyond what you
can store uncompressed on a filesystem in PCM. So, even assuming audio
samples of 1 byte, int64 should be a reasonable type to store timings
(in samples, rather then seconds). But I understand that doing so
would complicate the logic of the tool, especially since it is very
unlikely that math approximation would be an issue. To be honest I did
not expect the corner case above would fail since it is comparing a
value against another value that should just be the same.

I have uploaded simplified code that showcase the issue and some of
the instabilities [1]. The code seems to behave as if the last value
is different from the other 3, supposed equal values.

[1] https://pastebin.com/embed_js/T3g560UV

Bests,
Giulio

Re: Suggestion needed on test failures due to double arithmetics

[Andrey Rahmatullin]

On Wed, Nov 24, 2021 at 06:38:07PM +0100, Giulio Paci wrote:
> Dear mentors,
>   while updating SCTK package I enabled the execution of the test suite
> which was previously disabled. The tests are working fine on x86_64
> architecture, but a couple of them are failing on i386.
> After investigation [1] I found out that tests are failing because they
> rely on the assumptions that, when a and b have the same double value:
> 1) "a < b" is false;
> 2) "a - b" is 0.0.
What do they actually test, why do they use these assumptions?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Suggestion needed on test failures due to double arithmetics

[Paul Wise]

Giulio Paci wrote:

> 3) what is the most appropriate solution.

As I understand it, floating point values should not be compared
without some kind of accuracy/precision factor. Zero idea about the
best reference for how to do it correctly, but here is a random one:

https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Suggestion needed on test failures due to double arithmetics

[Giulio Paci]

Dear mentors,
  while updating SCTK package I enabled the execution of the test suite
which was previously disabled. The tests are working fine on x86_64
architecture, but a couple of them are failing on i386.
After investigation [1] I found out that tests are failing because they
rely on the assumptions that, when a and b have the same double value:
1) "a < b" is false;
2) "a - b" is 0.0.
Unfortunately, these assumptions do not always hold on i386 as the behavior
of those operators seem to change according to compilation flags (e.g.,
optimization or debug flags) or the surrounding instructions (e.g., if a
function is invoked nearby or not).

I think the reason for this behavior is probably related to gcc
options -mfpmath
[2] and -ffloat-store [3]. Using -ffloat-store option indeed seems to fix
the issue.

However I am wondering:
1) if enabling -ffloat-store is an acceptable solution;
2) if this is a compiler bug (I always expect approximated results with
double arithmetics, but the above assumptions seem very basic to me,
considering that they cover the special case where a and b are equal);
3) what is the most appropriate solution.

Do you have any suggestion?

I just asked the same question upstream, but I would appreciate your
opinion as well.

Bests,
Giulio

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981030#39
[2]
https://gcc.gnu.org/onlinedocs/gcc-10.3.0/gcc/x86-Options.html#x86-Options
[3]
https://gcc.gnu.org/onlinedocs/gcc-10.3.0/gcc/Optimize-Options.html#Optimize-Options

Bug#973371: RFS: pytest-dependency/0.5.1-1 [ITP] -- Manages dependencies of pytest test cases

[Bastian Germann]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "pytest-dependency":

 * Package name: pytest-dependency
   Version : 0.5.1-1
   Upstream Author : Rolf Krahl 
 * URL : https://github.com/RKrahl/pytest-dependency
 * License : Apache-2.0
   Section : python
 * Vcs: https://salsa.debian.org/python-team/packages/pytest-dependency

It builds those binary packages:

  python-pytest-dependency-doc - Manages dependencies of pytest test
cases (common documentation)
  python3-pytest-dependency - Manages dependencies of pytest test cases
(Python 3)

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

  https://mentors.debian.net/package/pytest-dependency/

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

  dget -x
https://mentors.debian.net/debian/pool/main/p/pytest-dependency/pytest-dependency_0.5.1-1.dsc

Changes for the initial release:

 pytest-dependency (0.5.1-1) unstable; urgency=medium
 .
   * Initial release (Closes: #972718)

Regards,
Bastian

Speeding up test builds Re: Building a few of packages

[Rebecca N. Palmer]

(These are general hints, I haven't looked at your particular package.)

Since the binary you want is arch-specific (_amd64 rather than _all), 
use dpkg-buildpackage --build=source,any.


If the tests are long, you can skip them with DEB_BUILD_OPTIONS=nocheck. 
 If you're trying to fix a test failure bug, it is often possible to 
manually run a single test afterwards.  (How depends on what test 
framework upstream are using.)


If you still have the previous build tree, or expect to need more than 
one additional build, consider using dpkg-buildpackage --no-pre-clean to 
re-use the parts that haven't changed.  (Warning: this may not have the 
same result as a normal build.)


Tong Sun wrote:

The only way I can think of is to change d/control file, comment out
all other packages.


This probably won't be much faster: it's likely to build everything and 
just not package up the pieces you didn't ask for.


To do only part of the actual build, you probably need to modify 
debian/rules and/or the upstream build system.



But that will cause trouble to dpkg-buildpackage


Changes under debian/ shouldn't.  Changes to upstream files do need to 
be made into an actual patch (dpkg-source --commit), but this is not the 
same as committing to git.



or gbp buildpackage, which requires me checking in those temporary
changes before starting


This gbp check can be turned off with --git-ignore-new.

Bug#956731: marked as done (RFS: check/0.14.0-0.1 [NMU] -- unit test framework for C)

[Debian Bug Tracking System]

Your message dated Mon, 13 Jul 2020 20:32:19 +0200
with message-id 

and subject line Re: RFS: check/0.14.0-0.1 [NMU] -- unit test framework for C
has caused the Debian Bug report #956731,
regarding RFS: check/0.14.0-0.1 [NMU] -- unit test framework for C
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.)


-- 
956731: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956731
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: rober...@semistable.com


Dear mentors,

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

 * Package name: check
   Version : 0.14.0-0.1
   Upstream Author : Branden Archer
https://github.com/libcheck/check/blob/master/AUTHORS
 * URL : https://libcheck.github.io/check/
 * License : LGPL-2.1+
 * Vcs : None
   Section : devel

It builds those binary packages:

  check - unit test framework for C

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/check/check_0.14.0-0.1.dsc

Changes since the last upload:

   * Non-maintainer upload.
   * New upstream version 0.14.0
   * d/{control,compat}: switch to debhelper v12
   * d/control:
 - bump std-version to 4.5.0 (no further changes)
 - drop dependency fulfilled since jessie
   * d/patches: add patch to correct misspelling
   * d/rules:
 - drop unneeded dh option '--buildsystem=autoconf --with autoreconf'
 - break configure lines
 - add 'dh_missing --fail-missing'
   * debian: cleanup unnecessary .dirs and .files items
   * d/tests: add simple autopkgtest

Best regards,
  Christian Göttsche
--- End Message ---
--- Begin Message ---
Opened an ITS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964977

Closing as there is already a new upstream release.--- End Message ---

Bug#960572: RFS: vim-ale/2.6.0-1 [ITP] (Asynchronous Lint Engine for Vim 8 and NeoVim), vim-vader/0.3.0+git20200213.6fff477-1 [ITP] (simple vimscript test framework)

[Pierre-Elliott Bécue]

Control: owner -1 james...@debian.org

Le lundi 25 mai 2020 à 14:44:20+0200, Pierre-Elliott Bécue a écrit :
> Dear Nicholas,
> 
> Thanks for your work, I'll review it!
> 
> A few preliminary remarks:
> 
> on salsa's repo for vim-ale, you've created a debian/master branch that
> is merely the same as upstream/latest for now, and a mymedia/master one
> which seems to contain the debian packaging files.
> 
> I'd suggest you either remove mymedia/master in favour of debian/master
> (it'd seem more relevant to upload the package from the content of
> debian/master), or at least make the mymedia/master branch being the
> default branch of the repository on salsa, and discard the debian/master
> branch that seems to be useless.
> 
> The same goes for vim-vader.
> 
> My preference would be to rename mymedia/master to debian/master.
> 
> I'll handle both packages, but, next time, please open one RFS per
> source package. The fact that both are closely related doesn't really
> change a thing to that, and one bug for multiple packages makes it
> harder to follow what has already been done and what is to be done.

Hi,

Since James decided to upload these packages right away, I'll leave that
to him.

Anyway, you should get your branches sorted out.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#960572: RFS: vim-ale/2.6.0-1 [ITP] (Asynchronous Lint Engine for Vim 8 and NeoVim), vim-vader/0.3.0+git20200213.6fff477-1 [ITP] (simple vimscript test framework)

[Pierre-Elliott Bécue]

Dear Nicholas,

Thanks for your work, I'll review it!

A few preliminary remarks:

on salsa's repo for vim-ale, you've created a debian/master branch that
is merely the same as upstream/latest for now, and a mymedia/master one
which seems to contain the debian packaging files.

I'd suggest you either remove mymedia/master in favour of debian/master
(it'd seem more relevant to upload the package from the content of
debian/master), or at least make the mymedia/master branch being the
default branch of the repository on salsa, and discard the debian/master
branch that seems to be useless.

The same goes for vim-vader.

My preference would be to rename mymedia/master to debian/master.

I'll handle both packages, but, next time, please open one RFS per
source package. The fact that both are closely related doesn't really
change a thing to that, and one bug for multiple packages makes it
harder to follow what has already been done and what is to be done.

Cheers.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#960572: RFS: vim-ale/2.6.0-1 [ITP] (Asynchronous Lint Engine for Vim 8 and NeoVim), vim-vader/0.3.0+git20200213.6fff477-1 [ITP] (simple vimscript test framework)

[Nicholas Guriev]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "vim-ale"

 * Package name: vim-ale
   Version : 2.6.0-1
   Upstream Author : d...@w0rp.com

 * URL : https://github.com/dense-analysis/ale
 * License : BSD-2-Clause
 * Vcs : https://salsa.debian.org/mymedia/vim-ale
   Section : editors

It builds those
binary packages:

  vim-ale - Asynchronous Lint Engine for Vim 8 and NeoVim

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

  https://mentors.debian.net/package/vim-ale

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

  dget -x 
https://mentors.debian.net/debian/pool/main/v/vim-ale/vim-ale_2.6.0-1.dsc

I have also opened a merge request on
salsa.d.o:

  https://salsa.debian.org/mymedia/vim-ale/-/merge_requests/1/diffs

Changes since the last upload:

   * Initial upload. (Closes: #960543)


In addition, there is its dependence, vim-vader. Please upload it before. I am
not sending second sponsorship request because at the moment both packages are
closely related.

 * Package name: vim-vader
   Version : 0.3.0+git20200213.6fff477-1
   Upstream Author : Junegunn Choi
 * URL : https://github.com/junegunn/vader.vim
 * License : Expat
 * Vcs : https://salsa.debian.org/mymedia/vim-vader
   Section : devel

It builds those binary packages:

  vim-vader - simple vimscript test framework

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

  https://mentors.debian.net/package/vim-vader

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

  dget -x 
https://mentors.debian.net/debian/pool/main/v/vim-vader/vim-vader_0.3.0+git20200213.6fff477-1.dsc

I have also opened a merge request on salsa.d.o:

  https://salsa.debian.org/mymedia/vim-vader/-/merge_requests/1/diffs

Changes since the last upload:

   * Initial upload. (Closes: #960544)

Regards,

--
  Nicholas Guriev

Bug#956731: RFS: check/0.14.0-0.1 [NMU] -- unit test framework for C

[Christian Göttsche]

Hi Tobias,

> it seems that check would be a candidate to be ITSed?

Do you mean ITA (Intent To Adopt)?

Bug#959740: RFS: libr4d/1.4-1 [ITP] -- Remote For Device-under-test Helper Library (development files)

[Bastian Germann]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: libr4d
   Version : 1.4-1
   Upstream Author : Benedikt Spranger 
 * URL : https://github.com/ci-rt/libr4d
 * License : GPL-2.0 with OpenSSL exception
 * Vcs : https://github.com/ci-rt/libr4d
   Section : libs

It builds those binary packages:

  libr4d-dev - Remote For Device-under-test Helper Library (development
files)
  libr4d0 - Remote For Device-under-test Helper Library

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/libr/libr4d/libr4d_1.4-1.dsc

Changes since the last upload:

   * Initial release (Closes: #955610)

Regards,
Bastian Germann

Bug#956731: RFS: check/0.14.0-0.1 [NMU] -- unit test framework for C

[Tobias Frost]

Hi Christian,

it seems that check would be a candiate to be ITSed?
So if you are interested I would suggest to start the ITS process…

(Its ok if not, let me know, I will then take a look at the RFS.
However, it looks like that at least some of the changes are out of scope for an
NMU. Also, your changelog should close the cited bugs.)

-- 
Cheers,
tobi

Bug#959171: RFS: r4d/1.5-1 [ITP] -- Remote For Device-under-test (R4D) Daemon

[Bastian Germann]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: r4d
   Version : 1.5-1
   Upstream Author : Benedikt Spranger 
 * URL : https://github.com/ci-rt/r4d
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/python-team/applications/r4d
   Section : net

It builds those binary packages:

  r4d - Remote For Device-under-test (R4D) Daemon

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

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

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

  dget -x https://mentors.debian.net/debian/pool/contrib/r/r4d/r4d_1.5-1.dsc

Changes since the last upload:

   * Initial release (Closes: #955616)

Regards,
Bastian Germann

Bug#956731: Acknowledgement (RFS: check/0.14.0-0.1 [NMU] -- unit test framework for C)

[Christian Göttsche]

I uploaded a new version, which switches to debhelper compat level 13,
updates the copyright file and disables the auto-test step on ppc architectures.

Changes since the last upload:

   * Non-maintainer upload.
   * New upstream version 0.14.0
   * d/{control,compat}: switch to debhelper compat level 13
   * d/control:
 - bump std-version to 4.5.0 (no further changes)
 - drop dependency fulfilled since jessie
   * d/patches: add patch to correct misspelling
   * d/rules:
 - drop unneeded dh option '--buildsystem=autoconf --with autoreconf'
 - break configure lines
 - add 'dh_missing --fail-missing'
 - disable auto-test for ppc architectures (Closes: #918572, #951667)
   * debian: cleanup unnecessary .dirs and .files items
   * d/tests: add simple autopkgtest
   * d/copyright: update


The unstable version 0.12.0-0.1 is currently prevented from migration
to testing due to #918572 [1].
Also #951667 [2] will be resolved with this new version.

Check 0.11.0 introduces the common check macros 'ck_assert_ptr_null'
and 'ck_assert_ptr_nonnull',
which are e.g. required for SELint [3] which I'd like to package perspectively.


[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918572
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951667
[3]: https://github.com/TresysTechnology/selint

p.s.: due to timeout tests the build can take up to 15 minutes, see
https://salsa.debian.org/cgzones/check/-/jobs/705379

Bug#956731: RFS: check/0.14.0-0.1 [NMU] -- unit test framework for C

[Christian Göttsche]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: rober...@semistable.com


Dear mentors,

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

 * Package name: check
   Version : 0.14.0-0.1
   Upstream Author : Branden Archer
https://github.com/libcheck/check/blob/master/AUTHORS
 * URL : https://libcheck.github.io/check/
 * License : LGPL-2.1+
 * Vcs : None
   Section : devel

It builds those binary packages:

  check - unit test framework for C

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/check/check_0.14.0-0.1.dsc

Changes since the last upload:

   * Non-maintainer upload.
   * New upstream version 0.14.0
   * d/{control,compat}: switch to debhelper v12
   * d/control:
 - bump std-version to 4.5.0 (no further changes)
 - drop dependency fulfilled since jessie
   * d/patches: add patch to correct misspelling
   * d/rules:
 - drop unneeded dh option '--buildsystem=autoconf --with autoreconf'
 - break configure lines
 - add 'dh_missing --fail-missing'
   * debian: cleanup unnecessary .dirs and .files items
   * d/tests: add simple autopkgtest

Best regards,
  Christian Göttsche

Re: Help to enable test suite precondition for covid-19 relevant R package

[Andreas Tille]

Hi,

thanks a lot for these helpful hints.

On Mon, Apr 06, 2020 at 08:51:57PM +0100, jnq...@gmail.com wrote:
> 
> without looking at any of the packages, at all, you say you're
> unfamiliar with Rust, so perhaps the following hints will be helpful:
>  1. you can use the Rustc compiler (rustc) directly unless you actually
> need to make use of a Cargo project file (Cargo.toml).

I was simply following what upstream code was specifying as requriement
(which probably makes perfectly sense when not using a Debian chroot
that has no remote access).

>  2. `cargo` has an `--offline` option to run without network access.
> Cargo is built around the concept of "crates" (libraries) being
> available on crates.io, which projects can depend upon by specifying
> dependencies in Cargo.toml (though it is also possible to have
> dependencies hosted elsewhere), and which cargo can automatically
> download, compile and link when building your project. Cargo can thus
> have a need to retrieve an updated index of available crates (just like
> apt update), requiring internet access, as well as needing internet
> access to fetch depended upon crates that you have not already got
> cached. You can however as I just mentioned run it in offline mode
> whereby it tries to proceed with cached dependencies only.

I'll keep a record of these helpful hints in Git of that package.  It
turned out that I can use r-cran-av as an alternative which for the
intended purpose works out of the box.  So I'll delay this for the
future if there might be some need, thought. 

Thanks again

  Andreas.

-- 
http://fam-tille.de

Re: Help to enable test suite precondition for covid-19 relevant R package

[jnqnfe]

On Mon, 2020-04-06 at 21:17 +0200, Andreas Tille wrote:
> Hi,
> 
> the cran package r-cran-gganimate requires r-cran-gifski to run its
> test
> suite.  I've prepared the latter in Git[1].  To build the package a
> rust
> compiler is needed which I provided via Build-Depends:
> cargo.  Unfortunately
> there will be some Rust modules needed which the build process tries
> to
> download:
> 
> ...
> gcc -std=gnu99 -I"/usr/share/R/include" -DNDEBUG-pthread
> -fvisibility=hidden -fpic  -g -O2 -fdebug-prefix-map=/build/r-base-
> j1tBvV/r-base-3.6.3=. -fstack-protector-strong -Wformat -W
> /usr/bin/cargo build --release --manifest-path=myrustlib/Cargo.toml
> Updating crates.io index
> warning: spurious network error (2 tries remaining): failed to
> resolve address for github.com: Temporary failure in name resolution;
> class=Net (12)
> warning: spurious network error (1 tries remaining): failed to
> resolve address for github.com: Temporary failure in name resolution;
> class=Net (12)
> error: failed to fetch `https://github.com/rust-lang/crates.io-index`
> 
> Caused by:
>   failed to resolve address for github.com: Temporary failure in name
> resolution; class=Net (12)
> make[1]: *** [Makevars:12: myrustlib/target/release/libmyrustlib.a]
> Error 101
> ...
> 
> Since I have no idea about rust:  How can I find out what extra
> module
> is needed and do we possibly have a package of it I could use as
> Build-Depends?
> 
> Kind regards
> 
>   Andreas.
> 
> 
> [1] https://salsa.debian.org/r-pkg-team/r-cran-gifski
> 

without looking at any of the packages, at all, you say you're
unfamiliar with Rust, so perhaps the following hints will be helpful:
 1. you can use the Rustc compiler (rustc) directly unless you actually
need to make use of a Cargo project file (Cargo.toml).
 2. `cargo` has an `--offline` option to run without network access.
Cargo is built around the concept of "crates" (libraries) being
available on crates.io, which projects can depend upon by specifying
dependencies in Cargo.toml (though it is also possible to have
dependencies hosted elsewhere), and which cargo can automatically
download, compile and link when building your project. Cargo can thus
have a need to retrieve an updated index of available crates (just like
apt update), requiring internet access, as well as needing internet
access to fetch depended upon crates that you have not already got
cached. You can however as I just mentioned run it in offline mode
whereby it tries to proceed with cached dependencies only.

Help to enable test suite precondition for covid-19 relevant R package

[Andreas Tille]

Hi,

the cran package r-cran-gganimate requires r-cran-gifski to run its test
suite.  I've prepared the latter in Git[1].  To build the package a rust
compiler is needed which I provided via Build-Depends: cargo.  Unfortunately
there will be some Rust modules needed which the build process tries to
download:

...
gcc -std=gnu99 -I"/usr/share/R/include" -DNDEBUG-pthread 
-fvisibility=hidden -fpic  -g -O2 
-fdebug-prefix-map=/build/r-base-j1tBvV/r-base-3.6.3=. -fstack-protector-strong 
-Wformat -W
/usr/bin/cargo build --release --manifest-path=myrustlib/Cargo.toml
Updating crates.io index
warning: spurious network error (2 tries remaining): failed to resolve address 
for github.com: Temporary failure in name resolution; class=Net (12)
warning: spurious network error (1 tries remaining): failed to resolve address 
for github.com: Temporary failure in name resolution; class=Net (12)
error: failed to fetch `https://github.com/rust-lang/crates.io-index`

Caused by:
  failed to resolve address for github.com: Temporary failure in name 
resolution; class=Net (12)
make[1]: *** [Makevars:12: myrustlib/target/release/libmyrustlib.a] Error 101
...

Since I have no idea about rust:  How can I find out what extra module
is needed and do we possibly have a package of it I could use as
Build-Depends?

Kind regards

  Andreas.


[1] https://salsa.debian.org/r-pkg-team/r-cran-gifski

-- 
http://fam-tille.de

Bug#951227: RFS: catch2/2.11.1-1 -- C++ Automated Test Cases in Headers

[Mathieu Mirmont]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: catch2
   Version : 2.11.1-1
   Upstream Author : Martin Hořeňovský 
 * URL : https://github.com/catchorg/Catch2
 * License : Boost-1.0
 * Vcs : https://salsa.debian.org/mat-guest/catch2
   Section : devel

It builds those binary packages:

  catch2 - C++ Automated Test Cases in Headers

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/catch2/catch2_2.11.1-1.dsc

Changes since the last upload:

   * Initial package (Closes: #901783)

Regards,

--
Mathieu Mirmont 

Re: gbp buildpackage test build with uncommitted changes

[Tong Sun]

On Tue, Mar 19, 2019 at 1:39 PM Andrey Rahmatullin wrote:
>
> On Tue, Mar 19, 2019 at 01:32:46PM -0400, Tong Sun wrote:
> > > Haven't you seen my email with the correct answer?
> >
> > Too short to figure out what you were trying to say.
> I see.
>
> > In my mind the correct answer is the solution on how to use "gbp
> > buildpackage" to build the package *using* any uncommitted files
> I pointed you to --git-export=WC in that email.

Thanks -- `--git-export=WC` is the solution to my problem.

- - - - - - - - - - - - - - -
--git-export=TREEISH

Instead of exporting the current branch head, export the treeish
object TREEISH. The special name INDEX exports the current index
whereas the special name WC exports the current working copy as is.
Note that using WC enables the --git-ignore-branch and
--git-ignore-new options as well since when exporting the working copy
there's no point in enforcing any branch or modification checks.
- - - - - - - - - - - - - - -

Re: gbp buildpackage test build with uncommitted changes

[Andrey Rahmatullin]

On Tue, Mar 19, 2019 at 01:32:46PM -0400, Tong Sun wrote:
> > Haven't you seen my email with the correct answer?
> 
> Too short to figure out what you were trying to say.
I see.

> In my mind the correct answer is the solution on how to use "gbp
> buildpackage" to build the package *using* any uncommitted files
I pointed you to --git-export=WC in that email.

> what  `--git-ignore-new` does or does not.
That is important to understand too, as my impression was you only read
the option name and not its description in the manpage.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: gbp buildpackage test build with uncommitted changes

[Tong Sun]

On Tue, Mar 19, 2019 at 1:28 PM Andrey Rahmatullin wrote:
>
> On Tue, Mar 19, 2019 at 12:27:15PM -0400, Tong Sun wrote:
> > Yes, I noticed that `--git-ignore-new` will ignore my changes entirely
> It doesn't do that.
> Also, it all is described in the manpage.
>
> > and the build will keep complaining about the same error that I've
> > already fixed.
> Haven't you seen my email with the correct answer?

Too short to figure out what you were trying to say.

In my mind the correct answer is the solution on how to use "gbp
buildpackage" to build the package *using* any uncommitted files, not
what  `--git-ignore-new` does or does not.

Re: gbp buildpackage test build with uncommitted changes

[Andrey Rahmatullin]

On Tue, Mar 19, 2019 at 12:27:15PM -0400, Tong Sun wrote:
> Yes, I noticed that `--git-ignore-new` will ignore my changes entirely
It doesn't do that.
Also, it all is described in the manpage.

> and the build will keep complaining about the same error that I've
> already fixed.
Haven't you seen my email with the correct answer?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: gbp buildpackage test build with uncommitted changes

[Andrey Rahmatullin]

On Tue, Mar 19, 2019 at 08:25:53AM -0700, Adam Lewenberg wrote:
> The original question was asking how to use "gbp buildpackage" to build the
> package using any uncommitted files. Doesn't --git-ignore-new _ignore_ the
> uncommitted files?
No, gbp already ignores uncommitted files (without --git-export=WC),
--git-ignore-new just allows you to proceed with building.

> One possibility would be to create a test branch, commit your changes to
> this test branch, and then use the --git-debian-branch option to build on
> this test branch. You can then throw away the branch when you are done.
This is completely unnecessary, of course.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: gbp buildpackage test build with uncommitted changes

[Tong Sun]

On Tue, Mar 19, 2019 at 11:42 AM Adam Lewenberg wrote:
>
> On 3/19/2019 3:08 AM, Emmanuel Arias wrote:
> > HI,
> >
> >
> >>> Using `--git-ignore-new` will get my changes ignore entirely, and the
> >>> build will keep complaining about the same error.
> >>>
> >>> What's the solution? Thx
> >>>
> > That is weird. Currently I am working with gbp and --git-ignore-new work
> > for me.
>
>
> The original question was asking how to use "gbp buildpackage" to build
> the package using any uncommitted files. Doesn't --git-ignore-new
> _ignore_ the uncommitted files?

Thanks a lot Adam for paraphrasing what I meant.

Yes, I noticed that `--git-ignore-new` will ignore my changes entirely, and the
build will keep complaining about the same error that I've already fixed.

> One possibility would be to create a test branch, commit your changes to
> this test branch, and then use the --git-debian-branch option to build
> on this test branch. You can then throw away the branch when you are done.

Gotya. Thx.

Re: gbp buildpackage test build with uncommitted changes

[Adam Lewenberg]

On 3/19/2019 3:08 AM, Emmanuel Arias wrote:

HI,



Using `--git-ignore-new` will get my changes ignore entirely, and the
build will keep complaining about the same error.

What's the solution? Thx


That is weird. Currently I am working with gbp and --git-ignore-new work
for me.



The original question was asking how to use "gbp buildpackage" to build 
the package using any uncommitted files. Doesn't --git-ignore-new 
_ignore_ the uncommitted files?


One possibility would be to create a test branch, commit your changes to 
this test branch, and then use the --git-debian-branch option to build 
on this test branch. You can then throw away the branch when you are done.

Re: gbp buildpackage test build with uncommitted changes

[Andrey Rahmatullin]

On Tue, Mar 19, 2019 at 09:01:30AM -0400, Tong Sun wrote:
> On Tue, Mar 19, 2019 at 6:08 AM Emmanuel Arias wrote:
> 
> > >> Using `--git-ignore-new` will get my changes ignore entirely, and the
> > >> build will keep complaining about the same error.
> > >>
> > >> What's the solution? Thx
> > >>
> > That is weird. Currently I am working with gbp and --git-ignore-new work
> > for me.
> 
> Thanks a lot *everyone* for the confirmation!
> 
> Now I need to figure out why it didn't work for me...
What exactly doesn't work now?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: gbp buildpackage test build with uncommitted changes

[eamanu15]

> Thanks a lot *everyone* for the confirmation!
>
> Now I need to figure out why it didn't work for me...
>

Are you working on a particular salsa repo?

Could you let's me know what is it? Could you send me the patch
that you want to add?




-- 
Arias Emmanuel
http://eamanu.com
Github/Gitlab; @eamanu
Debian: @eamanu-guest

Re: gbp buildpackage test build with uncommitted changes

[Tong Sun]

On Tue, Mar 19, 2019 at 6:08 AM Emmanuel Arias wrote:

> >> Using `--git-ignore-new` will get my changes ignore entirely, and the
> >> build will keep complaining about the same error.
> >>
> >> What's the solution? Thx
> >>
> That is weird. Currently I am working with gbp and --git-ignore-new work
> for me.

Thanks a lot *everyone* for the confirmation!

Now I need to figure out why it didn't work for me...

Re: gbp buildpackage test build with uncommitted changes

[Emmanuel Arias]

HI,


>> Using `--git-ignore-new` will get my changes ignore entirely, and the
>> build will keep complaining about the same error.
>>
>> What's the solution? Thx
>>
That is weird. Currently I am working with gbp and --git-ignore-new work
for me.






signature.asc
Description: OpenPGP digital signature

Re: gbp buildpackage test build with uncommitted changes

[Andrey Rahmatullin]

On Mon, Mar 18, 2019 at 11:47:06PM -0400, Tong Sun wrote:
> Using `--git-ignore-new` will get my changes ignore entirely
That's not what --git-ignore-new does. Not using --git-export=WC does
that.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: gbp buildpackage test build with uncommitted changes

[Geert Stappers]

On Mon, Mar 18, 2019 at 11:47:06PM -0400, Tong Sun wrote:
> Hi,
> 
> I'm new to Debian packaging and gbp buildpackage, and many time I want
> to try out my fixes without checking them in, would that be possible
> with `gbp buildpackage`?
> 
> Because whenever, I have above situation, gbp buildpackage will complains:
> 
> - - - - - - - - - - - -
> gbp:error: You have uncommitted changes in your source tree:
> gbp:error: On branch master
> Changes not staged for commit:
> . . .
> gbp:error: Use --git-ignore-new to ignore.
> - - - - - - - - - - - -
> 
> Using `--git-ignore-new` will get my changes ignore entirely, and the
> build will keep complaining about the same error.
> 
> What's the solution? Thx
> 

The `--git-ignore-new` works for me.
Currently I have no project at hand to verify   (sorry)

For me is it OK to publish the `gbp clone` URL here.


Groeten
Geert Stappers
-- 
Leven en laten leven

gbp buildpackage test build with uncommitted changes

[Tong Sun]

Hi,

I'm new to Debian packaging and gbp buildpackage, and many time I want
to try out my fixes without checking them in, would that be possible
with `gbp buildpackage`?

Because whenever, I have above situation, gbp buildpackage will complains:

- - - - - - - - - - - -
gbp:error: You have uncommitted changes in your source tree:
gbp:error: On branch master
Changes not staged for commit:
. . .
gbp:error: Use --git-ignore-new to ignore.
- - - - - - - - - - - -

Using `--git-ignore-new` will get my changes ignore entirely, and the
build will keep complaining about the same error.

What's the solution? Thx

autopkgtest - "error: invalid command 'test'"

[Herbert Fortes]

Hi,

Genshi package failed in one Debian CI. And I ended using
'tox -e py37'. There is no deps[0].

[0] - https://sources.debian.org/src/genshi/0.7.1-5/tox.ini/

Can someone tell me why the "error: invalid command 'test'"?

Maybe using the word as a string?
python3 setup.py 'test'



Regards,
Herbert


autopkgtest [03:16:48]: test command1: python3 setup.py test
autopkgtest [03:16:48]: test command1: [---
/usr/lib/python3.7/distutils/dist.py:274: UserWarning: Unknown distribution 
option: 'test_suite'
  warnings.warn(msg)
/usr/lib/python3.7/distutils/dist.py:274: UserWarning: Unknown distribution 
option: 'extras_require'
  warnings.warn(msg)
/usr/lib/python3.7/distutils/dist.py:274: UserWarning: Unknown distribution 
option: 'entry_points'
  warnings.warn(msg)
/usr/lib/python3.7/distutils/dist.py:274: UserWarning: Unknown distribution 
option: 'features'
  warnings.warn(msg)
/usr/lib/python3.7/distutils/dist.py:274: UserWarning: Unknown distribution 
option: 'use_2to3'
  warnings.warn(msg)
/usr/lib/python3.7/distutils/dist.py:274: UserWarning: Unknown distribution 
option: 'convert_2to3_doctests'
  warnings.warn(msg)
/usr/lib/python3.7/distutils/dist.py:274: UserWarning: Unknown distribution 
option: 'use_2to3_fixers'
  warnings.warn(msg)
/usr/lib/python3.7/distutils/dist.py:274: UserWarning: Unknown distribution 
option: 'include_package_data'
  warnings.warn(msg)
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

error: invalid command 'test'
autopkgtest [03:16:49]: test command1: ---]
autopkgtest [03:16:49]: test command1:  - - - - - - - - - - results - - - - - - 
- - - -
command1 FAIL non-zero exit status 1
autopkgtest [03:16:49]:  summary
command1 FAIL non-zero exit status 1

Re: Help for SIGSEGV in test suite needed when built with gcc 8.2 what works nicely with gcc 6.3

[Yavor Doganov]

On Wed, 09 Jan 2019 22:42:43 +0200,
Andreas Tille wrote:
> The values of the structure are set in line 350[3] and are OK there.

What looks suspicious to me is that an unsigned long long value is
assigned to struct members of type size_t.  In the previous upstream
release that worked, the return value of ffparse_ulong was used which
was unsigned long.

I doubt this is the culprit but may be something worth looking at.

> I admit I fail to see why the code works under stretch with gcc 6.3
> but fails with gcc 8.2.

If the code works with an old compiler but fails with a modern one, in
99.99% of the cases it's a bug in the code.  These bugs are revealed
due to new and more aggressive optimization techniques/algorithms that
assume undefined behavior.  IOW, the code was/is buggy by definition
but you got away with it somehow.  The remaining 0.01% is due to
compiler bugs but I bet that's not the case here.

Re: Help for SIGSEGV in test suite needed when built with gcc 8.2 what works nicely with gcc 6.3

[Andreas Tille]

Hi Sune,

On Thu, Jan 10, 2019 at 06:27:47PM +, Sune Vuorela wrote:
> ...
> I looked briefly at the code, but I didn't feel like actually trying to
> understand what's going on.

Thanks a lot for this detailed analysis.  I'll forward it to bug #907624
and the upstream issue[1].  I admit I also will not try to understand
the code since I not even have an idea what the program is supposed to
do.

I think we have now provided sufficient input for upstream to track down
the issue.

Thanks again

   Andreas.

[1] https://github.com/soedinglab/ffindex_soedinglab/issues/7

-- 
http://fam-tille.de

Re: Help for SIGSEGV in test suite needed when built with gcc 8.2 what works nicely with gcc 6.3

[Sune Vuorela]

On 2019-01-09, Andrey Rahmatullin  wrote:
> As usual: reading the code, debugging, printfs. Address sanitizer and/or
> valgrind may or may not help too.

I just tried throwing some tools at it.

Apparantly you need a three step thing to get to it.

address-sanitizer. First issue. The command to create the test data to
get the error.

$ ./ffindex_build -s ./test.data ./test.ffindex test/data test/data2

=
==824==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 304 byte(s) in 1 object(s) allocated from:
#0 0x7f3393888ed0 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xe8ed0)
#1 0x7f33937994f1 in ffindex_index_parse 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/ffindex.c:325
#2 0x56072c890783 in main 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/ffindex_build.c:243
#3 0x7f33935f9b16 in __libc_start_main ../csu/libc-start.c:310

SUMMARY: AddressSanitizer: 304 byte(s) leaked in 1 allocation(s).


Oh well. rebuild without address sanitizer and run the first two steps.
Then rebuild with address sanitizer for the last step.

$ ./ffindex_modify -u ./test.ffindex b
AddressSanitizer:DEADLYSIGNAL
=
==1453==ERROR: AddressSanitizer: SEGV on unknown address 0x000ca3ff8001 (pc 
0x7f459600a9f7 bp 0x7ffd6674b8d0 sp 0x7ffd6674b8a0 T0)
==1453==The signal is caused by a READ memory access.
#0 0x7f459600a9f6 in action 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/ffindex.c:554
#1 0x7f45960076ed in trecursemisc 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/twalkmisc.h:26
#2 0x7f459600775d in trecursemisc 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/twalkmisc.h:31
#3 0x7f4596007827 in twalkmisc 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/twalkmisc.h:44
#4 0x7f459600aac3 in ffindex_tree_write 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/ffindex.c:563
#5 0x7f4596009f60 in ffindex_write 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/ffindex.c:443
#6 0x55c8564c3fa8 in main 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/ffindex_modify.c:182
#7 0x7f4595e69b16 in __libc_start_main ../csu/libc-start.c:310
#8 0x55c8564c3259 in _start 
(/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/build/src/ffindex_modify+0x2259)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/ffindex.c:554 
in action
==1453==ABORTING

I'm not sure that gives more new info.

Lets try valgrind.

$ valgrind ./ffindex_modify -u ./test.ffindex b
==32176== Memcheck, a memory error detector
==32176== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==32176== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==32176== Command: ./ffindex_modify -u ./test.ffindex b
==32176== 
==32176== Invalid read of size 8
==32176==at 0x4846525: trecursemisc (twalkmisc.h:25)
==32176==by 0x484658E: trecursemisc (twalkmisc.h:31)
==32176==by 0x4846633: twalkmisc (twalkmisc.h:44)
==32176==by 0x4847CE0: ffindex_tree_write (ffindex.c:563)
==32176==by 0x48477C2: ffindex_write (ffindex.c:443)
==32176==by 0x10985E: main (ffindex_modify.c:182)
==32176==  Address 0x4a536e1 is 17 bytes inside a block of size 24 alloc'd
==32176==at 0x483577F: malloc (vg_replace_malloc.c:299)
==32176==by 0x4986160: tsearch (tsearch.c:338)
==32176==by 0x4847C02: ffindex_index_as_tree (ffindex.c:533)
==32176==by 0x1094D7: main (ffindex_modify.c:122)
==32176== 
==32176== Invalid read of size 8
==32176==at 0x4847C6D: action (ffindex.c:554)
==32176==by 0x4846543: trecursemisc (twalkmisc.h:26)
==32176==by 0x484658E: trecursemisc (twalkmisc.h:31)
==32176==by 0x4846633: twalkmisc (twalkmisc.h:44)
==32176==by 0x4847CE0: ffindex_tree_write (ffindex.c:563)
==32176==by 0x48477C2: ffindex_write (ffindex.c:443)
==32176==by 0x10985E: main (ffindex_modify.c:182)
==32176==  Address 0x4a53d is not stack'd, malloc'd or (recently) free'd
==32176== 
==32176== 
==32176== Process terminating with default action of signal 11 (SIGSEGV)
==32176==  Access not within mapped region at address 0x4A53D
==32176==at 0x4847C6D: action (ffindex.c:554)
==32176==by 0x4846543: trecursemisc (twalkmisc.h:26)
==32176==by 0x484658E: trecursemisc (twalkmisc.h:31)
==32176==by 0x4846633: twalkmisc (twalkmisc.h:44)
==32176==by 0x4847CE0: ffindex_tree_write (ffindex.c:563)
==32176==by 0x48477C2: ffindex_write (ffindex.c:443)
==32176==by 0x10985E: main (ffindex_modify.c:182)
==32176==  If you believe this happened as a result of a stack
==32176==  overflow in your program's main thread (unlikely but
==32176==  possible), you can try to in

Re: Help for SIGSEGV in test suite needed when built with gcc 8.2 what works nicely with gcc 6.3

[Andrey Rahmatullin]

On Wed, Jan 09, 2019 at 10:49:48PM +0100, Andreas Tille wrote:
> > > to find the exact code line[2] where the SIGSEGV is thrown.  It turns out
> > > that the elements of a structure are not accessible:
> > > 
> > >(gdb) print entry->offset
> > >Cannot access memory at address 0x7
> > It's because entry is 0x7.
> 
> When I was running the code with some more debugging info activated[1]
> I had pretty valid looking adresses 0x555666 
And still SEGV?

> > > The values of the structure are set in line 350[3] and are OK there.
> > The problem is not about the structure fields but about the structure
> > pointer itself though.
> > ...
> > You need to find out why one of the tree nodes has an invalid address.
> 
> Can you propose any means to find this out?
As usual: reading the code, debugging, printfs. Address sanitizer and/or
valgrind may or may not help too.

> I have no idea about specific compiler differences.
I don't think pondering compiler differences can be helpful here, it's
most likely bad code that is working file with some compilers but is still
bad code.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Help for SIGSEGV in test suite needed when built with gcc 8.2 what works nicely with gcc 6.3

[Andreas Tille]

Hi,

On Thu, Jan 10, 2019 at 02:14:14AM +0500, Andrey Rahmatullin wrote:
> On Wed, Jan 09, 2019 at 09:42:43PM +0100, Andreas Tille wrote:
> > to find the exact code line[2] where the SIGSEGV is thrown.  It turns out
> > that the elements of a structure are not accessible:
> > 
> >(gdb) print entry->offset
> >Cannot access memory at address 0x7
> It's because entry is 0x7.

When I was running the code with some more debugging info activated[1]
I had pretty valid looking adresses 0x555666 (or something in that line
just remembering by heart - can activate the patch if needed).  I have
no idea why the address is this without that extra debug code.
 
> > The values of the structure are set in line 350[3] and are OK there.
> The problem is not about the structure fields but about the structure
> pointer itself though.
> ...
> You need to find out why one of the tree nodes has an invalid address.

Can you propose any means to find this out?  I have no idea about
specific compiler differences.  BTW, I also tried to set -O0 but this
did not avoided the SIGSEGV.

Thanks for your hint anyway

  Andreas.

[1] 
https://salsa.debian.org/med-team/ffindex/blob/master/debian/patches/debug_segfault

-- 
http://fam-tille.de

Re: Help for SIGSEGV in test suite needed when built with gcc 8.2 what works nicely with gcc 6.3

[Ole Streicher]

Hi Andreas,

one thing I usually do in such cases is to rebuild the package adding
"-fsanitize=address -O0" flags (optimization just to understand better
what happens in the source). This switches the address sanitizer on
<https://github.com/google/sanitizers/wiki/AddressSanitizer>. This can
test if a local variable is accidently overwritten (by an off-by-one
error or similar). Often it finds many more bugs which one can turn
upstream into bonus points...

Otherwise I see no other chance than to go through the debugger and see
where the strange address was set. 0x7 however sounds that somewhere a
small integer was assigned to the pointer, so I would try the sanitizing
stuff first.

Cheers

Ole

Andreas Tille  writes:
> Hi,
>
> as reported in bug #907624 ffindex autopkgtest fails with SIGSEGV in sid
> and buster.  I've tested in stretch (gcc 6.3) and the code works fine.
> I've reported upstream[1] the results of my gdb session where I was able
> to find the exact code line[2] where the SIGSEGV is thrown.  It turns out
> that the elements of a structure are not accessible:
>
>(gdb) print entry->offset
>Cannot access memory at address 0x7
>
> (full gdb log under [1] or in the bug log).
>
> In fact I tried in some more detailed debugging that any attempt to
> access one of the structure elements even for instance only injecting
> something like 
>
>if ( !entry->offset ) {
>
> in line 554 will trigger the SIGSEGV.  The values of the structure are
> set in line 350[3] and are OK there.  The funktion that contains the
> failing line is action() [4] and called via a pointer to this function
> in line 563[5] (I admit I have no real idea why this pointer to a
> function should be needed.  Its the only function that is used in this
> place and IMHO only adds an extra layer of complexity.)
>
> The structure is declared in the header file[6].
>
> I admit I fail to see why the code works under stretch with gcc 6.3
> but fails with gcc 8.2.
>
> Any idea?
>
> Kind regards
>
>Andreas.
>
>
> [1] https://github.com/soedinglab/ffindex_soedinglab/issues/7
> [2] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.c#L554
> [3] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.c#L350
> [4] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.c#L541
> [5] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.c#L563
> [6] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.h#L30

Re: Help for SIGSEGV in test suite needed when built with gcc 8.2 what works nicely with gcc 6.3

[Andrey Rahmatullin]

On Wed, Jan 09, 2019 at 09:42:43PM +0100, Andreas Tille wrote:
> to find the exact code line[2] where the SIGSEGV is thrown.  It turns out
> that the elements of a structure are not accessible:
> 
>(gdb) print entry->offset
>Cannot access memory at address 0x7
It's because entry is 0x7.

> In fact I tried in some more detailed debugging that any attempt to
> access one of the structure elements even for instance only injecting
> something like 
> 
>if ( !entry->offset ) {
Of course this won't work, entry is 0x7.

> The values of the structure are set in line 350[3] and are OK there.
The problem is not about the structure fields but about the structure
pointer itself though.

> The funktion that contains the failing line is action() [4] and called
> via a pointer to this function in line 563[5] (I admit I have no real
> idea why this pointer to a function should be needed.  Its the only
> function that is used in this place and IMHO only adds an extra layer of
> complexity.)
No? line 563 calls twalkmisc() which walks the tree and calls action() for
each node. 

You need to find out why one of the tree nodes has an invalid address.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Help for SIGSEGV in test suite needed when built with gcc 8.2 what works nicely with gcc 6.3

[Andreas Tille]

Hi,

as reported in bug #907624 ffindex autopkgtest fails with SIGSEGV in sid
and buster.  I've tested in stretch (gcc 6.3) and the code works fine.
I've reported upstream[1] the results of my gdb session where I was able
to find the exact code line[2] where the SIGSEGV is thrown.  It turns out
that the elements of a structure are not accessible:

   (gdb) print entry->offset
   Cannot access memory at address 0x7

(full gdb log under [1] or in the bug log).

In fact I tried in some more detailed debugging that any attempt to
access one of the structure elements even for instance only injecting
something like 

   if ( !entry->offset ) {

in line 554 will trigger the SIGSEGV.  The values of the structure are
set in line 350[3] and are OK there.  The funktion that contains the
failing line is action() [4] and called via a pointer to this function
in line 563[5] (I admit I have no real idea why this pointer to a
function should be needed.  Its the only function that is used in this
place and IMHO only adds an extra layer of complexity.)

The structure is declared in the header file[6].

I admit I fail to see why the code works under stretch with gcc 6.3
but fails with gcc 8.2.

Any idea?

Kind regards

   Andreas.


[1] https://github.com/soedinglab/ffindex_soedinglab/issues/7
[2] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.c#L554
[3] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.c#L350
[4] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.c#L541
[5] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.c#L563
[6] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.h#L30

-- 
http://fam-tille.de

Bug#905928: marked as done (RFS: phoronix-test-suite/8.0.1-2 [ITP])

[Debian Bug Tracking System]

Your message dated Sun, 30 Dec 2018 10:24:11 +
with message-id 
and subject line closing RFS: phoronix-test-suite/8.0.1-2 [ITP]
has caused the Debian Bug report #905928,
regarding RFS: phoronix-test-suite/8.0.1-2 [ITP]
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.)


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

Dear mentors,

I am looking for a sponsor for my package "phoronix-test-suite"

* Package name: phoronix-test-suite
  Version : 8.0.1-2
  Upstream Author : Phoronix 
* URL : https://phoronix-test-suite.com
* License : GPL-3+
  Section : utils

It builds those binary packages:

phoronix-test-suite - Benchmarking and system testing framework

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

  https://mentors.debian.net/package/phoronix-test-suite

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/phoronix-test-suite/phoronix-test-suite_8.0.1-2.dsc

More information about hello can be obtained from 
https://phoronix-test-suite.com.

Due to it downloading tests from OpenBenchmark.org, I think this belongs
in contrib.

This is a new package, and would therefore need to pass the NEW queue. I
plan on using this package to benchmark an assortment of systems, and
prefer installing with a Debian package to running a shell script any
day.

This package was removed between wheezy and jessie, and much time has
passed since then, so I completely repackaged it for the latest version.
A new version will be released soon ("Milestone 1" of 8.2.0 was released
21 days ago), so I will need an update upload sponsored then as well
(and far into the future, at least until I'm a DM; I plan on ensuring
this package doesn't get removed again).

Apologies for already bumping this to -2, I had forgotten to change the
release from UNRELEASED to unstable in the changelog, so I released -2
to fix that.

Regards,
-- 
Zebulon McCorkle
zebmccor...@asymptote.club | https://keybase.io/zebMcCorkle
803A 0F47 82AD DDEA 46BE  055F F8F9 DB8C 1A54 6398

   |
   |
__/
  __  Asymptote Club
 /(bad ASCII graph by yours truly)
 |
 |


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Package phoronix-test-suite has been removed from mentors.--- End Message ---

Re: How to test interactive and GUI programs with autopkgtest?

[Joël Krähemann]

Hi,

I have integration tests for GSequencer. It uses mainly:

https://developer.gnome.org/gdk2/stable/GdkDisplay.html#gdk-display-warp-pointer
https://developer.gnome.org/gdk2/stable/gdk2-Testing.html#gdk-test-simulate-button

In gsequencer I have a timeout that can be synchronized with the test
runner. This
has to be done because of concurrent access.

We run the integration tests as part of continues integration:
https://salsa.debian.org/multimedia-team/gsequencer/tree/master/debian/tests

Bests,
Joël

On Sun, Sep 30, 2018 at 9:01 PM Eriberto Mota  wrote:
>
> Hi all,
>
> As the subject said, I would like to know how to test non-command line
> programs as sniffit, hexedit and gconjugue, using autopkgtest
> (debian/tests/* method).
>
> I think that an auxiliary program should be used to test these
> environments but I don't know one.
>
> Thanks in advance.
>
> Regards,
>
> Eriberto
>

How to test interactive and GUI programs with autopkgtest?

[Eriberto Mota]

Hi all,

As the subject said, I would like to know how to test non-command line
programs as sniffit, hexedit and gconjugue, using autopkgtest
(debian/tests/* method).

I think that an auxiliary program should be used to test these
environments but I don't know one.

Thanks in advance.

Regards,

Eriberto

Bug#905928: RFS: phoronix-test-suite/8.0.1-2 [ITP]

[Zebulon McCorkle]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "phoronix-test-suite"

* Package name: phoronix-test-suite
  Version : 8.0.1-2
  Upstream Author : Phoronix 
* URL : https://phoronix-test-suite.com
* License : GPL-3+
  Section : utils

It builds those binary packages:

phoronix-test-suite - Benchmarking and system testing framework

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

  https://mentors.debian.net/package/phoronix-test-suite

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/phoronix-test-suite/phoronix-test-suite_8.0.1-2.dsc

More information about hello can be obtained from 
https://phoronix-test-suite.com.

Due to it downloading tests from OpenBenchmark.org, I think this belongs
in contrib.

This is a new package, and would therefore need to pass the NEW queue. I
plan on using this package to benchmark an assortment of systems, and
prefer installing with a Debian package to running a shell script any
day.

This package was removed between wheezy and jessie, and much time has
passed since then, so I completely repackaged it for the latest version.
A new version will be released soon ("Milestone 1" of 8.2.0 was released
21 days ago), so I will need an update upload sponsored then as well
(and far into the future, at least until I'm a DM; I plan on ensuring
this package doesn't get removed again).

Apologies for already bumping this to -2, I had forgotten to change the
release from UNRELEASED to unstable in the changelog, so I released -2
to fix that.

Regards,
-- 
Zebulon McCorkle
zebmccor...@asymptote.club | https://keybase.io/zebMcCorkle
803A 0F47 82AD DDEA 46BE  055F F8F9 DB8C 1A54 6398

   |
   |
__/
  __  Asymptote Club
 /(bad ASCII graph by yours truly)
 |
 |


signature.asc
Description: PGP signature

Help for build-time test failure of libhmsbeagle (phylogeny algorithms using GPU) needed

[Andreas Tille]

Hi,

I'm trying to update libhmsbeagle[1] to its latest upstream version.
Unfortunately I'm running into a build time test where I have no idea
how to deal with:

...
make[4]: Entering directory 
'/build/libhmsbeagle-3.0.2+dfsg/examples/matrixtest'

  -
make  matrixtest
make[5]: Entering directory '/build/libhmsbeagle-3.0.2+dfsg/examples/matrixtest'
g++ -DHAVE_CONFIG_H -I. -I../../libhmsbeagle  -I../.. -I../.. -Wdate-time 
-D_FORTIFY_SOURCE=2 -I/usr/lib/jvm/java-10-openjdk-amd64/include 
-I/usr/lib/jvm/java-10-openjdk-amd64/include/linux -O3 -std=c++11 -pthread -g 
-O2 -fdebug-prefix-map=/build/libhmsbeagle-3.0.2+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -c -o matrixtest.o 
matrixtest.cpp
/bin/bash ../../libtool  --tag=CXX   --mode=link g++ -O3 -std=c++11 -pthread -g 
-O2 -fdebug-prefix-map=/build/libhmsbeagle-3.0.2+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security  -Wl,-z,relro 
-Wl,-z,now -o matrixtest matrixtest.o ../../libhmsbeagle/libhmsbeagle.la -ldl 
libtool: link: g++ -O3 -std=c++11 -pthread -g -O2 
-fdebug-prefix-map=/build/libhmsbeagle-3.0.2+dfsg=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wl,-z -Wl,relro -Wl,-z -Wl,now -o 
.libs/matrixtest matrixtest.o  ../../libhmsbeagle/.libs/libhmsbeagle.so -ldl 
-pthread
make[5]: Leaving directory '/build/libhmsbeagle-3.0.2+dfsg/examples/matrixtest' 

 e 
make  check-TESTS   

  -
make[5]: Entering directory '/build/libhmsbeagle-3.0.2+dfsg/examples/matrixtest'
make[6]: Entering directory 
'/build/libhmsbeagle-3.0.2+dfsg/examples/matrixtest'

 md
FAIL: matrixtest

  -

   libhmsbeagle 3.0.2: examples/matrixtest/test-suite.log


# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: matrixtest



OpenCL error: CL_INVALID_VALUE from file , line 923.
Using resource 1:
Rsrc Name : pthread-Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz (OpenCL 
1.2 pocl HSTR: pthread-x86_64-pc-linux-gnu-haswell)
Impl : OpenCL-Single
Impl Desc : none

FAIL matrixtest (exit status: 255)


Before I contact upstream I wonder whether I might have missed some GPU
specific things that might help here.

Kind regards

Andreas.


[1] https://salsa.debian.org/med-team/libhmsbeagle

-- 
http://fam-tille.de

Re: numpy boolean subtract, the `-` operator, is deprecated, use the bitwise_xor, the `^` operator, or the logical_xor function instead (Was: Bug#899205: python-cogent: Test suite fails with latest ma

[Daniele Nicolodi]

On 05/06/2018 01:00, Andreas Tille wrote:

> ==
> ERROR: test_consistent_gap_degen_handling 
> (test_core.test_sequence.ModelSequenceTests)
> gap degen character should be treated consistently
> --
> Traceback (most recent call last):
>   File 
> "/tmp/autopkgtest-lxc.5a99fnj6/downtmp/autopkgtest_tmp/tests/test_core/test_sequence.py",
>  line 660, in test_consistent_gap_degen_handling
> self.assertEqual(dna.stripBadAndGaps(), raw_ungapped)
>   File "/usr/lib/python2.7/dist-packages/cogent/core/sequence.py", line 1251, 
> in stripBadAndGaps
> valid_indices -= self._data == i
> TypeError: numpy boolean subtract, the `-` operator, is deprecated, use the 
> bitwise_xor, the `^` operator, or the logical_xor function instead.
> 
> ==
> 
> 
> I would be happy for some suggested patch how to solve this.  The line
> in question is
> 
>
> https://salsa.debian.org/med-team/python-cogent/blob/master/cogent/core/sequence.py
> 
>Line 1251
> 
> If my feeling is not totally wrong the correct patch would be 
> 
>valid_indices -= (self._data == i)
> 
> since the left value is rather an integer than boolean.
> 
> What do you think?

Without analyzing the code in the fine details, and assuming self._data
is a numpy array or a subclass, I think the name of the variable is
misleading.  Looking at the whole function it seems to be a bool array.
It should be easy to confirm this with pdb or simply inserting a print()
statement in the right place.

def stripBadAndGaps(self):
"""Returns copy of self with bad chars and gaps excised."""
gap_indices = map(self.Alphabet.index, self.MolType.Gaps)
valid_indices = self._data < len(self.Alphabet)
for i in gap_indices:
valid_indices -= self._data == i
result = compress(valid_indices, self._data)
return self.__class__(result, Info=self.Info)

The fix should be to replace the subtraction with:

valid_indices ^= self._data == i

Cheers,
Dan

numpy boolean subtract, the `-` operator, is deprecated, use the bitwise_xor, the `^` operator, or the logical_xor function instead (Was: Bug#899205: python-cogent: Test suite fails with latest matplo

[Andreas Tille]

Control: tags -1 help

Hi,

I have reported the issue upstream but no response so far.  While the
error message contains some hint how to solve the issue I would like
to backup this by some competent advise.


==
ERROR: test_consistent_gap_degen_handling 
(test_core.test_sequence.ModelSequenceTests)
gap degen character should be treated consistently
--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.5a99fnj6/downtmp/autopkgtest_tmp/tests/test_core/test_sequence.py",
 line 660, in test_consistent_gap_degen_handling
self.assertEqual(dna.stripBadAndGaps(), raw_ungapped)
  File "/usr/lib/python2.7/dist-packages/cogent/core/sequence.py", line 1251, 
in stripBadAndGaps
valid_indices -= self._data == i
TypeError: numpy boolean subtract, the `-` operator, is deprecated, use the 
bitwise_xor, the `^` operator, or the logical_xor function instead.

==


I would be happy for some suggested patch how to solve this.  The line
in question is

   
https://salsa.debian.org/med-team/python-cogent/blob/master/cogent/core/sequence.py

   Line 1251

If my feeling is not totally wrong the correct patch would be 

   valid_indices -= (self._data == i)

since the left value is rather an integer than boolean.

What do you think?

Kind regards

Andreas.

-- 
http://fam-tille.de

Re: piuparts - installation and purging test

[Gianfranco Costamagna]

Hello,

>I am maintaining vim-lastplace. A few days ago I saw on my Debian
>Maintainer Dashboard that piuparts was failing at the installation and
>purging test. Today I wanted to fix this, but the message was gone. So
>piuparts now succeeds on piuparts.d.o .
>
>But when I run piuparts on my local machine, it still fails at the
>installation and purging test. I had a look at the test and have no idea
>what it fails.
>Are there any known issues like that?


yes, sometimes unrelated packages leave stuff on the system, for unrelated 
reasons,
stuff fix itself after some days (with some new uploads!)

G.

piuparts - installation and purging test

[David Rabel]

Hi there,

I am maintaining vim-lastplace. A few days ago I saw on my Debian
Maintainer Dashboard that piuparts was failing at the installation and
purging test. Today I wanted to fix this, but the message was gone. So
piuparts now succeeds on piuparts.d.o .

But when I run piuparts on my local machine, it still fails at the
installation and purging test. I had a look at the test and have no idea
what it fails.

Are there any known issues like that?

Yours
  David



signature.asc
Description: OpenPGP digital signature

Test failure due to C++ error

[Andreas Tille]

control: reopen -1

While the header that was formerly missing is provided the C++ file
used for testing has syntax errors:


khmer/src/oxli(master) $ c++ -o test-prog-static -static -std=c++11 
-I/usr/local/include -I/usr/include/oxli/smhasher test-compile.cc 
-L/usr/local/lib -loxli -lbz2 -lz
test-compile.cc: In function ‘int main()’:
test-compile.cc:46:26: error: variable ‘oxli::Countgraph test’ has initializer 
but incomplete type
 oxli::Countgraph test(1,1);
  ^


So I'm reopening this bug.

Any help how to fix this would be welcome.

Kind regards

Andreas.

See also
  
https://ci.debian.net/data/autopkgtest/unstable/amd64/k/khmer/20171215_215850/log.gz

-- 
http://fam-tille.de

Re: How to get debian ci test passed for proxy application

[Roger Shimizu]

Dear Antonio,

Thanks for your informative email!
With the upload last night, I confirm now the issue got solved [0].

[0] 
https://ci.debian.net/data/autopkgtest/unstable/amd64/s/shadowsocks-libev/20171212_175154/log.gz

On Tue, Dec 5, 2017 at 3:14 AM, Antonio Terceiro <terce...@debian.org> wrote:
>
> You do not need anything Restrictions: to be able to start a daemon or
> listen on a local TCP port.

Thanks for your confirmation!
Now I removed the Restrictions for isolation-*.

> | $ ./tests/test.sh
> | running test:  python tests/test.py -c tests/aes.json
> |  2017-12-04 16:07:02 INFO: UDP relay enabled
> |  2017-12-04 16:07:02 INFO: initializing ciphers... aes-256-cfb
> |  2017-12-04 16:07:02 ERROR: bind: Address already in use
> |  2017-12-04 16:07:02 ERROR: bind() error
> |  2017-12-04 16:07:02 INFO: initializing ciphers... aes-256-cfb
> |  2017-12-04 16:07:02 INFO: listening at 127.0.0.1:1081
> |  2017-12-04 16:07:02 INFO: initializing ciphers... aes-256-cfb
> |  2017-12-04 16:07:02 INFO: UDP relay enabled
> |  2017-12-04 16:07:02 INFO: listening at 127.0.0.1:1082
>
> 
>
> | *   Trying 127.0.0.1...
> | * TCP_NODELAY set
> |   % Total% Received % Xferd  Average Speed   TimeTime Time  
> Current
> |  Dload  Upload   Total   SpentLeft  
> Speed
> |   0 00 00 0  0  0 --:--:-- --:--:-- --:--:--
>  0* SOCKS5 communication to www.google.com:80
> |  2017-12-04 16:07:04 INFO: connect to www.google.com:80
> | * SOCKS5 request granted.
> | * Connected to 127.0.0.1 (127.0.0.1) port 1081 (#0)
> 
> | > GET / HTTP/1.1
> | > Host: www.google.com
> | > User-Agent: curl/7.57.0
> | > Accept: */*
> | >
> |  2017-12-04 16:07:04 ERROR: remote_recv_cb_recv: Connection reset by peer
> | * Empty reply from server
> |   0 00 00 0  0  0 --:--:-- --:--:-- --:--:--
>  0
> | * Connection #0 to host 127.0.0.1 left intact
> | curl: (52) Empty reply from server
> |  2017-12-04 16:07:04 INFO: closed gracefully
> | test failed:  python tests/test.py -c tests/aes.json
>
> Why this happens? Because on autopkgtest, you assume the package is already
> *installed*. I assume the the daemon provided by the binary package is already
> listening to port 1081, so the test server starts on 1082.

Thanks for your hint!
Yes, previous failure on debci was because of installation of the
package, with the default config, so with the default port to open.

However the test opens both 1081 and 1082, which is expected.
The root cause is the application opens more than 1 port, and 8388 is
both listed in default config [1] and test config.
So here's the conflict.
After I add a patch [2] to change the port for the test from 8388 to
8389, now the test can be passed on debci [0].

[1] 
https://anonscm.debian.org/cgit/collab-maint/shadowsocks-libev.git/tree/debian/config.json
[2] 
https://anonscm.debian.org/cgit/collab-maint/shadowsocks-libev.git/tree/debian/patches/0001-Change-the-port-to-listen-from-8388-to-8389.patch

I'm happy that one more package is starting to enjoy the benefit of
continuous integration practice in debian.
It's really appreciated there's debci framework in debian.
Thanks for your work!

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

Suspected change in test dependencies - where is "discover" (Was: [Help] Re: Bug#884040: python-matplotlib-venn FTBFS: test failure)

[Andreas Tille]

Hi again,

On Mon, Dec 11, 2017 at 09:27:57AM +0100, Andreas Tille wrote:
> 
> On Sun, Dec 10, 2017 at 09:05:07PM +0200, Adrian Bunk wrote:
> > === warnings summary 
> > ===
> > None
> >   [pytest] section in setup.cfg files is deprecated, use [tool:pytest] 
> > instead.
> 
> I've fixed this in Git[1]
>  
> > -- Docs: http://doc.pytest.org/en/latest/warnings.html
> > == 1 warnings in 0.00 seconds 
> > ==
> > ERROR: file not found: discover
> 

I tried to build on local host (not in a pbuilder chroot) and than this
issue does not occure.  Seems I need to add a new Build-Depends for
whatever reason.  Any hint which one?  I parsed the package pool for
anything Python related containing a file "discover" / "discover.py" but
besides many hits there was no real helpful one.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: How to get debian ci test passed for proxy application

[Antonio Terceiro]

On Mon, Dec 04, 2017 at 04:59:12PM +0100, gregor herrmann wrote:
> On Mon, 04 Dec 2017 22:45:21 +0900, Roger Shimizu wrote:
> 
> > On Mon, Nov 27, 2017 at 5:36 AM, gregor herrmann <gre...@debian.org> wrote:
> > > On Sun, 26 Nov 2017 18:42:22 +, James Cowgill wrote:
> > >> I think you might need a "Restrictions: isolation-container" to get
> > >> network access, but that's only a guess.
> > > That's not my experience. We have quite a few perl packages where the
> > > tests do something networky and haven't experienced problems on
> > > ci.debian.net (modulo failing requests to external resources but
> > > that's of course a different story).
> > Maybe out bound network activity is OK, but not for open tcp port to
> > listen, as James said.
> 
> Sorry for being not more clear in my first mail: we also start all
> kinds of daemons, either from the package itself or some other
> packages (mysql, mariadb, memcached, …), and the tests successfully
> connect to them.

You do not need anything Restrictions: to be able to start a daemon or
listen on a local TCP port.

I tried the package locally both under autopkgtest+lxc, and on my host
system, and got the same results as the ones in ci.debian.net, i.e.
stuff like

running test:  python tests/test.py -c tests/chacha20-ietf-poly1305.json
*   Trying 127.0.0.1...
* TCP_NODELAY set
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0* 
SOCKS5 communication to www.google.com:80
* SOCKS5 request granted.
* Connected to 127.0.0.1 (127.0.0.1) port 1081 (#0)
> GET / HTTP/1.1
> Host: www.google.com
> User-Agent: curl/7.57.0
> Accept: */*
>
* Empty reply from server
  0 00 0    0 0  0  0 --:--:-- --:--:-- --:--:-- 0
* Connection #0 to host 127.0.0.1 left intact
curl: (52) Empty reply from server
test failed:  python tests/test.py -c tests/chacha20-ietf-poly1305.json


I tried messing with tests/test.py like this:

diff --git a/tests/test.py b/tests/test.py
index 0a1297b..ec8f3e3 100755
--- a/tests/test.py
+++ b/tests/test.py
@@ -60,9 +60,9 @@ if config.client_args:
 else:
 server_args.extend(config.client_args.split())

-p1 = Popen(server_args, stdin=PIPE, stdout=PIPE, stderr=PIPE, close_fds=True)
-p2 = Popen(client_args, stdin=PIPE, stdout=PIPE, stderr=PIPE, close_fds=True)
-p5 = Popen(tunnel_args, stdin=PIPE, stdout=PIPE, stderr=PIPE, close_fds=True)
+p1 = Popen(server_args, stdin=PIPE, close_fds=True)
+p2 = Popen(client_args, stdin=PIPE, close_fds=True)
+p5 = Popen(tunnel_args, stdin=PIPE, close_fds=True)
 p3 = None
 p4 = None
 p3_fin = False

and discovered that the test server is not listening to the port you think it 
is:

| $ ./tests/test.sh 
| running test:  python tests/test.py -c tests/aes.json
|  2017-12-04 16:07:02 INFO: UDP relay enabled
|  2017-12-04 16:07:02 INFO: initializing ciphers... aes-256-cfb
|  2017-12-04 16:07:02 ERROR: bind: Address already in use
|  2017-12-04 16:07:02 ERROR: bind() error
|  2017-12-04 16:07:02 INFO: initializing ciphers... aes-256-cfb
|  2017-12-04 16:07:02 INFO: listening at 127.0.0.1:1081
|  2017-12-04 16:07:02 INFO: initializing ciphers... aes-256-cfb
|  2017-12-04 16:07:02 INFO: UDP relay enabled
|  2017-12-04 16:07:02 INFO: listening at 127.0.0.1:1082



| *   Trying 127.0.0.1...
| * TCP_NODELAY set
|   % Total% Received % Xferd  Average Speed   TimeTime Time  
Current
|  Dload  Upload   Total   SpentLeft  Speed
|   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 
0* SOCKS5 communication to www.google.com:80
|  2017-12-04 16:07:04 INFO: connect to www.google.com:80
| * SOCKS5 request granted.
| * Connected to 127.0.0.1 (127.0.0.1) port 1081 (#0)

| > GET / HTTP/1.1
| > Host: www.google.com
| > User-Agent: curl/7.57.0
| > Accept: */*
| > 
|  2017-12-04 16:07:04 ERROR: remote_recv_cb_recv: Connection reset by peer
| * Empty reply from server
|   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
| * Connection #0 to host 127.0.0.1 left intact
| curl: (52) Empty reply from server
|  2017-12-04 16:07:04 INFO: closed gracefully
| test failed:  python tests/test.py -c tests/aes.json

Why this happens? Because on autopkgtest, you assume the package is already
*installed*. I assume the the daemon provided by the binary package is already
listening to port 1081, so the test server starts on 1082.

In this case, I think you want connect to the daemon that is already running,
i.e. the one that is provided by the binary package, instead of some daemon
th

Re: How to get debian ci test passed for proxy application

[gregor herrmann]

On Mon, 04 Dec 2017 22:45:21 +0900, Roger Shimizu wrote:

> On Mon, Nov 27, 2017 at 5:36 AM, gregor herrmann  wrote:
> > On Sun, 26 Nov 2017 18:42:22 +, James Cowgill wrote:
> >> I think you might need a "Restrictions: isolation-container" to get
> >> network access, but that's only a guess.
> > That's not my experience. We have quite a few perl packages where the
> > tests do something networky and haven't experienced problems on
> > ci.debian.net (modulo failing requests to external resources but
> > that's of course a different story).
> Maybe out bound network activity is OK, but not for open tcp port to
> listen, as James said.

Sorry for being not more clear in my first mail: we also start all
kinds of daemons, either from the package itself or some other
packages (mysql, mariadb, memcached, …), and the tests successfully
connect to them.
 
Maybe Antonio as the ci.d.n guru and maintainer can give an
authoritative answer :)


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: U2: Kite


signature.asc
Description: Digital Signature

Re: How to get debian ci test passed for proxy application

[Roger Shimizu]

Thanks all for your reply!

On Mon, Nov 27, 2017 at 3:42 AM, James Cowgill <jcowg...@debian.org> wrote:
> Hi,
>
> On 26/11/17 17:00, Roger Shimizu wrote:
>
>> The last test.sh script invokes the test, which creates local proxy
>> listen to 127.0.0.1:1081, and then it calls curl command to get index
>> page of google via local proxy, 127.0.0.1:1081.
>>
>> My local test shows all pass, while debian ci test [1] shows a
>> connection timeout message.
>> So I'm wondering whether debian ci support network activity, and how
>> can I configure the test to get it passed.
>
> I think you might need a "Restrictions: isolation-container" to get
> network access, but that's only a guess.

Thanks for the hint!

I find a supporting document [2], which state this flag is to allow
open network TCP ports.

[2] https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html

However, I tried "Restrictions: isolation-container", but it still failed [3]

[3] 
https://ci.debian.net/data/autopkgtest/unstable/amd64/s/shadowsocks-libev/20171201_180744/log.gz

So I'll try to use "Restrictions: isolation-machine" next.


On Mon, Nov 27, 2017 at 5:36 AM, gregor herrmann <gre...@debian.org> wrote:
> On Sun, 26 Nov 2017 18:42:22 +, James Cowgill wrote:
>
>> > My local test shows all pass, while debian ci test [1] shows a
>> > connection timeout message.
>> > So I'm wondering whether debian ci support network activity, and how
>> > can I configure the test to get it passed.
>> I think you might need a "Restrictions: isolation-container" to get
>> network access, but that's only a guess.
>
> That's not my experience. We have quite a few perl packages where the
> tests do something networky and haven't experienced problems on
> ci.debian.net (modulo failing requests to external resources but
> that's of course a different story).

Maybe out bound network activity is OK, but not for open tcp port to
listen, as James said.


On Wed, Nov 29, 2017 at 5:45 PM, gustavo panizzo <g...@zumbi.com.ar> wrote:
>
> I'd suggest to install apache as part of the tests and connect to
> localhost:80, that way it always works even if ci.debian.net moves to
> China or google goes down
>
> to test python-openstackclient; MySQL, RabbitMQ, Apache and others are
> installed, I haven't check its tests in a while but happy to help you

Thanks for your idea!
Maybe it'a a last resort, but I want to avoid currently.
It's too big for just a simple test.

And actually the package I'm try to make the test to work is helping
people to fight with censorship in mid- or far- east area.
So your example is not so proper IMHO.

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

Re: How to get debian ci test passed for proxy application

[gustavo panizzo]

Hello

On Mon, Nov 27, 2017 at 02:00:00AM +0900, Roger Shimizu wrote:

Dear mentors list,

I maintain a proxy application, shadowsocks-libev.
I want to let it pass debian ci test. And I already confirm the test
all passed on my local environment, and debomatic [0].
However it failed on debian ci infrastructure [1].

[0] 
http://debomatic-amd64.debian.net/distribution#unstable/shadowsocks-libev/3.1.1+ds-1/autopkgtest
[1] https://ci.debian.net/packages/s/shadowsocks-libev/unstable/amd64/

For local test, it just need the commands below:

$ sudo apt install shadowsocks-libev curl dnsutils
$ git clone https://anonscm.debian.org/git/collab-maint/shadowsocks-libev.git
$ cd shadowsocks-libev
$ ./tests/test.sh

The last test.sh script invokes the test, which creates local proxy
listen to 127.0.0.1:1081, and then it calls curl command to get index
page of google via local proxy, 127.0.0.1:1081.

My local test shows all pass, while debian ci test [1] shows a
connection timeout message.
So I'm wondering whether debian ci support network activity, and how
can I configure the test to get it passed.


I'd suggest to install apache as part of the tests and connect to
localhost:80, that way it always works even if ci.debian.net moves to
China or google goes down

to test python-openstackclient; MySQL, RabbitMQ, Apache and others are
installed, I haven't check its tests in a while but happy to help you



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



--
IRC: gfa
GPG: 0X44BB1BA79F6C6333

Re: How to get debian ci test passed for proxy application

[gregor herrmann]

On Sun, 26 Nov 2017 18:42:22 +, James Cowgill wrote:

> > My local test shows all pass, while debian ci test [1] shows a
> > connection timeout message.
> > So I'm wondering whether debian ci support network activity, and how
> > can I configure the test to get it passed.
> I think you might need a "Restrictions: isolation-container" to get
> network access, but that's only a guess.

That's not my experience. We have quite a few perl packages where the
tests do something networky and haven't experienced problems on
ci.debian.net (modulo failing requests to external resources but
that's of course a different story).


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Die Tontauben: jonny


signature.asc
Description: Digital Signature

Re: How to get debian ci test passed for proxy application

[James Cowgill]

Hi,

On 26/11/17 17:00, Roger Shimizu wrote:
> Dear mentors list,
> 
> I maintain a proxy application, shadowsocks-libev.
> I want to let it pass debian ci test. And I already confirm the test
> all passed on my local environment, and debomatic [0].
> However it failed on debian ci infrastructure [1].
> 
> [0] 
> http://debomatic-amd64.debian.net/distribution#unstable/shadowsocks-libev/3.1.1+ds-1/autopkgtest
> [1] https://ci.debian.net/packages/s/shadowsocks-libev/unstable/amd64/
> 
> For local test, it just need the commands below:
> 
> $ sudo apt install shadowsocks-libev curl dnsutils
> $ git clone https://anonscm.debian.org/git/collab-maint/shadowsocks-libev.git
> $ cd shadowsocks-libev
> $ ./tests/test.sh

Running autopkgtest as described on this page might help:
https://ci.debian.net/doc/file.MAINTAINERS.html

> The last test.sh script invokes the test, which creates local proxy
> listen to 127.0.0.1:1081, and then it calls curl command to get index
> page of google via local proxy, 127.0.0.1:1081.
> 
> My local test shows all pass, while debian ci test [1] shows a
> connection timeout message.
> So I'm wondering whether debian ci support network activity, and how
> can I configure the test to get it passed.

I think you might need a "Restrictions: isolation-container" to get
network access, but that's only a guess.

James



signature.asc
Description: OpenPGP digital signature

How to get debian ci test passed for proxy application

[Roger Shimizu]

Dear mentors list,

I maintain a proxy application, shadowsocks-libev.
I want to let it pass debian ci test. And I already confirm the test
all passed on my local environment, and debomatic [0].
However it failed on debian ci infrastructure [1].

[0] 
http://debomatic-amd64.debian.net/distribution#unstable/shadowsocks-libev/3.1.1+ds-1/autopkgtest
[1] https://ci.debian.net/packages/s/shadowsocks-libev/unstable/amd64/

For local test, it just need the commands below:

$ sudo apt install shadowsocks-libev curl dnsutils
$ git clone https://anonscm.debian.org/git/collab-maint/shadowsocks-libev.git
$ cd shadowsocks-libev
$ ./tests/test.sh

The last test.sh script invokes the test, which creates local proxy
listen to 127.0.0.1:1081, and then it calls curl command to get index
page of google via local proxy, 127.0.0.1:1081.

My local test shows all pass, while debian ci test [1] shows a
connection timeout message.
So I'm wondering whether debian ci support network activity, and how
can I configure the test to get it passed.

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

Test - Please ignore

[Phil Wyett]

This is a test after two of my mails have arrived here via BTS not correct.

Will a direct mail to the list appear here the same way.

Regards

Phil

-- 
*** If this is a mailing list, I am subscribed, no need to CC me.***

Playing the game for the games sake.

Web: https://kathenas.org

Github: https://github.com/kathenas

Twitter: kathenasorg

Instagram: kathenasorg

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

Re: mpgrafic - mpirun test program as root in automatic build

[Sean Whitton]

On Thu, Jan 19, 2017 at 08:21:36AM +0800, Paul Wise wrote:
> On Thu, Jan 19, 2017 at 7:44 AM, Sean Whitton wrote:
> 
> > This is temporarily false: #852071
> 
> Is there a typo in that bug? I get a 404

#851071, sorry!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: mpgrafic - mpirun test program as root in automatic build

[Paul Wise]

On Thu, Jan 19, 2017 at 7:44 AM, Sean Whitton wrote:

> This is temporarily false: #852071

Is there a typo in that bug? I get a 404

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: mpgrafic - mpirun test program as root in automatic build

[Sean Whitton]

Hello,

On Wed, Jan 18, 2017 at 02:25:41PM +0800, Paul Wise wrote:
> On Wed, Jan 18, 2017 at 5:13 AM, Boud Roukema wrote:
> 
> > I've looked a bit at buildd.debian.org, but it's not completely
> > trivial to decide which is correct - do the buildd builds on the
> > debian build machines run dh_auto_tests as (i) root, as (ii) an unprivileged
> > user running fakeroot, or as (iii) an unprivileged user?
> 
> (iii) an unprivileged user
> 
> fakeroot is only used at `debian/rules install` time.

This is temporarily false: #852071

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: mpgrafic - mpirun test program as root in automatic build

[Ole Streicher]

Paul Wise  writes:
> On Wed, Jan 18, 2017 at 3:58 PM, Ole Streicher wrote:
>
>> Also when using cowbuilder? At least I see the whole build done by root
>> when running in my cowbuilder chroot. That was the point that lead to
>> the trouble here...
>
> Yep. I tested this with id and override_dh_auto_* in cowbuilder:
>
>  fakeroot debian/rules clean
>debian/rules override_dh_auto_clean
> uid=0(root) gid=0(root) groups=0(root),1234(pbuilder)
>  debian/rules build
>debian/rules override_dh_auto_configure
> uid=1234(pbuilder) gid=1234(pbuilder) groups=1234(pbuilder)
>debian/rules override_dh_auto_build
> uid=1234(pbuilder) gid=1234(pbuilder) groups=1234(pbuilder)
>debian/rules override_dh_auto_test
> uid=1234(pbuilder) gid=1234(pbuilder) groups=1234(pbuilder)
>  fakeroot debian/rules binary
>debian/rules override_dh_auto_install
> uid=0(root) gid=0(root) groups=0(root),1234(pbuilder)

OK, I finally found it: I had a line 

BUILDUSERNAME=

in my .pbuilderrc, which was obviously interpreted as root.

Thanks

Ole

Re: mpgrafic - mpirun test program as root in automatic build

[Paul Wise]

On Wed, Jan 18, 2017 at 3:58 PM, Ole Streicher wrote:

> Also when using cowbuilder? At least I see the whole build done by root
> when running in my cowbuilder chroot. That was the point that lead to
> the trouble here...

Yep. I tested this with id and override_dh_auto_* in cowbuilder:

 fakeroot debian/rules clean
   debian/rules override_dh_auto_clean
uid=0(root) gid=0(root) groups=0(root),1234(pbuilder)
 debian/rules build
   debian/rules override_dh_auto_configure
uid=1234(pbuilder) gid=1234(pbuilder) groups=1234(pbuilder)
   debian/rules override_dh_auto_build
uid=1234(pbuilder) gid=1234(pbuilder) groups=1234(pbuilder)
   debian/rules override_dh_auto_test
uid=1234(pbuilder) gid=1234(pbuilder) groups=1234(pbuilder)
 fakeroot debian/rules binary
   debian/rules override_dh_auto_install
uid=0(root) gid=0(root) groups=0(root),1234(pbuilder)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: mpgrafic - mpirun test program as root in automatic build

[Ole Streicher]

Paul Wise <p...@debian.org> writes:
> On Wed, Jan 18, 2017 at 3:37 PM, Boud Roukema wrote:
>
>> I guess by "both of these" you mean "most of the build steps (apart from
>> the 'debian/rules install' step)"?
>
> What I wrote wasn't clear and wasn't strictly true, sorry!
>
> When manually building from source:
>
> You always build/test as a normal user.
> You install as either root or normal user, depending on the install
> prefix.
>
> When doing Debian package builds:
>
> You always build/test as a normal user.
> You always install using fakeroot.

Also when using cowbuilder? At least I see the whole build done by root
when running in my cowbuilder chroot. That was the point that lead to
the trouble here...

Best

Ole

Re: mpgrafic - mpirun test program as root in automatic build

[Boud Roukema]

On Wed, 18 Jan 2017, Paul Wise wrote:


When manually building from source:

You always build/test as a normal user.
You install as either root or normal user, depending on the install prefix.

When doing Debian package builds:

You always build/test as a normal user.
You always install using fakeroot.


Thanks for the clarification :). That's consistent
with my experience, and seems like reasonable policy.

Cheers
Boud

Re: mpgrafic - mpirun test program as root in automatic build

[Paul Wise]

On Wed, Jan 18, 2017 at 3:37 PM, Boud Roukema wrote:

> I guess by "both of these" you mean "most of the build steps (apart from
> the 'debian/rules install' step)"?

What I wrote wasn't clear and wasn't strictly true, sorry!

When manually building from source:

You always build/test as a normal user.
You install as either root or normal user, depending on the install prefix.

When doing Debian package builds:

You always build/test as a normal user.
You always install using fakeroot.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: mpgrafic - mpirun test program as root in automatic build

[Boud Roukema]

On Wed, 18 Jan 2017, Paul Wise wrote:


On Wed, Jan 18, 2017 at 5:13 AM, Boud Roukema wrote:


I've looked a bit at buildd.debian.org, but it's not completely
trivial to decide which is correct - do the buildd builds on the
debian build machines run dh_auto_tests as (i) root, as (ii) an unprivileged
user running fakeroot, or as (iii) an unprivileged user?


(iii) an unprivileged user

fakeroot is only used at `debian/rules install` time.

Both of these are the same as if you were building manually from source.


I guess by "both of these" you mean "most of the build steps (apart from
the 'debian/rules install' step)"?

cheers
boud

Re: mpgrafic - mpirun test program as root in automatic build

[Paul Wise]

On Wed, Jan 18, 2017 at 5:13 AM, Boud Roukema wrote:

> I've looked a bit at buildd.debian.org, but it's not completely
> trivial to decide which is correct - do the buildd builds on the
> debian build machines run dh_auto_tests as (i) root, as (ii) an unprivileged
> user running fakeroot, or as (iii) an unprivileged user?

(iii) an unprivileged user

fakeroot is only used at `debian/rules install` time.

Both of these are the same as if you were building manually from source.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: mpgrafic - mpirun test program as root in automatic build

[Boud Roukema]

On Tue, 17 Jan 2017, James Cowgill wrote:


I'm not sure I follow. Debhelper runs the testsuite during the build
target so it shouldn't be run as root anyway. I don't think you need any
workarounds at all for this.


I agree in terms of principles :), but I don't know what actually happens
on the buildd machines.

I've looked a bit at buildd.debian.org, but it's not completely
trivial to decide which is correct - do the buildd builds on the
debian build machines run dh_auto_tests as (i) root, as (ii) an unprivileged
user running fakeroot, or as (iii) an unprivileged user?

Looking at git://git.debian.org/buildd-tools/sbuild.git it looks like
the user is "buildd" - but this is just a guess.

The mpirun exit-if-root mechanism is in

openmpi-2.0.2~git.20161225/orte/orted/orted_submit.c

Isolating this to lines 319-335, this is easy to test as a standalone
main program (see snippet.c below) - the exit-if-root test is triggered either 
(i) using
root directly, or (ii) as ordinary user running fakeroot.

Even as fakeroot, both geteuid() and getuid() in the snippet below
report an identity of 0.

My own pbuilder setup - closely following the maint-guide.en.txt advice -
appears *not* to run "make check" as fakeroot or root, since I
do not see the error and exit due to running as root.

The snippet below can be tested:

user$ ./snippet
user$ fakeroot ./snippet
root# ./snippet

Cheers
Boud

--

/* inspired by openmpi-2.0.2~git.20161225/orte/orted/orted_submit.c root 
detection */

/* (C) 2017 GPL-3+ B. Roukema if copyright is needed */

#include 
#include 
#include 

int main(void)
{
  int uid = 77 , euid = ;
  euid = geteuid();
  uid = getuid();
  if (0 == euid){
printf("WARNING: You are effectively root.\n");
  };
  if (0 == uid){
printf("WARNING: You are really root.\n");
  };
  if (0 != uid && 0 != euid){
printf("You are not running as root :).\n");
  }
  return 0;
}

--

Re: mpgrafic - mpirun test program as root in automatic build

[Ole Streicher]

James Cowgill <jcowg...@debian.org> writes:
> On 16/01/17 23:58, Boud Roukema wrote:
>> Since, in general, there is no reason for mpirun to run as root,
>> the sid version of mpirun (from openmpi) apparently refuses to run as root.
>> (I have not reproduced this behaviour myself - Ole Streicher
>> has warned me about it.) The openmpi developers provide an option
>> --allow-run-as-root.
>
> I'm not sure I follow. Debhelper runs the testsuite during the build
> target so it shouldn't be run as root anyway. I don't think you need any
> workarounds at all for this.

I (as Bouds sponsor) have the problem that in my cowbuilder the build is
done as root, leading to the questioned error message and a failure of
the test and the build. Maybe in my setup something is wrong?

Best regards

Ole

Re: mpgrafic - mpirun test program as root in automatic build

[James Cowgill]

Hi,

On 16/01/17 23:58, Boud Roukema wrote:
> hi Debian-mentors,
> 
> Is it reasonable to override the mpirun (openmpi_2.0.2~git.20161225-8)
> default preference of refusing to run as root?
> 
> I've started packaging mpgrafic for debian - this is my first
> debianisation, apart from minor private hacks after extracting debian
> source packages:
> 
> https://anonscm.debian.org/cgit/debian-astro/packages/mpgrafic.git/
> 
> I've added regression-test-0.3.7.sh to the upstream version of
> mpgrafic. This is a "reproducible run" test. The test runs the main
> binary, mpgrafic, with a frontend "mpirun", which, in general, allows
> a program to run on many different machines, without shared memory.
> This test runs explicitly on exactly one processor, for reproducibility.
> 
> Since, in general, there is no reason for mpirun to run as root,
> the sid version of mpirun (from openmpi) apparently refuses to run as root.
> (I have not reproduced this behaviour myself - Ole Streicher
> has warned me about it.) The openmpi developers provide an option
> --allow-run-as-root.
> 
> In version 0.3.7.4-1, the debian-only, openmpi-only use of this option in
> debian/rules + regression-test-0.3.7.sh
> 
> https://anonscm.debian.org/cgit/debian-astro/packages/mpgrafic.git/tree/debian/rules
> 
> https://anonscm.debian.org/cgit/debian-astro/packages/mpgrafic.git/tree/regression-test-0.3.7.sh
> 
> 
> should presumably allow debian automatic builds to pass "make check".

I'm not sure I follow. Debhelper runs the testsuite during the build
target so it shouldn't be run as root anyway. I don't think you need any
workarounds at all for this.

James



signature.asc
Description: OpenPGP digital signature

mpgrafic - mpirun test program as root in automatic build

[Boud Roukema]

hi Debian-mentors,

Is it reasonable to override the mpirun (openmpi_2.0.2~git.20161225-8)
default preference of refusing to run as root?

I've started packaging mpgrafic for debian - this is my first
debianisation, apart from minor private hacks after extracting debian
source packages:

https://anonscm.debian.org/cgit/debian-astro/packages/mpgrafic.git/

I've added regression-test-0.3.7.sh to the upstream version of
mpgrafic. This is a "reproducible run" test. The test runs the main
binary, mpgrafic, with a frontend "mpirun", which, in general, allows
a program to run on many different machines, without shared memory.
This test runs explicitly on exactly one processor, for reproducibility.

Since, in general, there is no reason for mpirun to run as root,
the sid version of mpirun (from openmpi) apparently refuses to run as root.
(I have not reproduced this behaviour myself - Ole Streicher
has warned me about it.) The openmpi developers provide an option
--allow-run-as-root.

In version 0.3.7.4-1, the debian-only, openmpi-only use of this option in
debian/rules + regression-test-0.3.7.sh

https://anonscm.debian.org/cgit/debian-astro/packages/mpgrafic.git/tree/debian/rules
https://anonscm.debian.org/cgit/debian-astro/packages/mpgrafic.git/tree/regression-test-0.3.7.sh

should presumably allow debian automatic builds to pass "make check".

Is the choice to use the option --allow-run-as-root safe from a general
system security point of view?

My arguments against (i.e. it would be unsafe):

* A newbie might download/extract the debian source as root,
unintentionally modify the fortran source to do some dangerous things
with files and directories, change the -n 1 option to -n 32 for a cluster
of 4 machines each with 8 processors, and then try "make check".
Since the --allow-run-as-root option is enabled in regression-test-0.3.7.sh,
the newbie does some dangerous root operations.

Counterarguments (i.e. it would be safe):

** If the newbie has ignored the recommendation of building
debian packets from source with fakeroot debian/rules binary, then s/he
is already taking superuser risks, and we can't do much to help him/her;

** Introducing system-dangerous operations in fortran is possible, but unlikely
for someone just wishing to make a cosmology calculation;

** If the newbie modifies the -n 1 option, then s/he would see
the much more obvious --allow-run-as-root option and should learn
enough to realise that running as root is unlikely to be needed when
compiling/running the package as an ordiner user.

An alternative I see to enabling --allow-run-as-root would be e.g.

adduser --no-create-home --disabled-password mpgrafic
mpirun -n 1 ... ;
deluser mpgrafic

but that would unnecessarily require build dependence on adduser, and
creating/removing users is itself a security-related issue that
automated checkers (e.g. lintian) might (or should?) be concerned
about.

I'd like to rename mpgrafic-0.3.7.4 to 0.3.8 upstream, along with the
debian versions 0.3.7.4-1 and 0.3.8-1, but first it would be
good to hear some opinions on this.

tracker: https://tracker.debian.org/pkg/mpgrafic

Cheers
Boud

Re: FTBFS: how to test fixes

[殷啟聰]

Hi Muri,

With qemu-user-static binfmt-support and debootstrap you can establish
a Debian root filesystem of any architecture supported by QEMU. Then
you chroot into the directory and you basically entered a
not-so-perfect virtual environment. You can test yout packages there.

By following the instructions at <https://wiki.debian.org/Arm64Qemu>
you can get what you want.

Cheers,
Kai-Chung Yan

2016-09-06 1:07 GMT+08:00 Muri Nicanor <m...@immerda.ch>:
> hi,
>
> so, i've got my first two FTBFS bugs (on mips and hppa)- what the
> recommended way of testing fixes for architectures i don't have
> testmachines of?
>
> cheers,
> --
> muri
>



-- 
/*
* 殷啟聰 | Kai-Chung Yan
* 一生只向真理與妻子低頭
* Undergraduate student in National Taichung University of Education
* LinkedIn: <https://linkedin.com/in/seamlik>
* Blog: <http://seamlik.logdown.com>
*/

atomic_LIBS (was: FTBFS: how to test fixes)

[Muri Nicanor]

hi,

On 09/06/2016 12:44 PM, Christian Seiler wrote:
[...]
> I didn't think about adding -latomic to the linker flag list
> directly via -Wl. I just tested your suggestion and it's really
> funny; libtool does mangle your line and separate it into:
> 
>  -Wl,--push-state -Wl,--as-needed -Wl,-latomic -Wl,--pop-state
> 
> but since there's no direct -l argument, it actually does work
> and the things are kept together and in order.
> 
> @Muri: use this line in the patch instead:
> AC_CHECK_LIB([atomic], [__atomic_add_fetch_8], 
> [atomic_LIBS="-Wl,--push-state,--as-needed,-latomic,--pop-state"], 
> [atomic_LIBS=""]) 
> 
> That way, the libatomic dependency will only be picked up on
> platforms where it's necessary.

i've created a pull request for that change upstream[0], but the ci
seems not to like the patch:
https://travis-ci.org/dkopecek/usbguard/builds/158517934 - i'm not sure
what to make of that, i don't really see a difference in the successfull
builds and the ones that failed.

[0] https://github.com/dkopecek/usbguard/pull/126

cheers,
-- 
muri



signature.asc
Description: OpenPGP digital signature

Re: FTBFS: how to test fixes

[Christian Seiler]

On 09/06/2016 11:57 AM, Jakub Wilk wrote:
> * Christian Seiler , 2016-09-05, 20:33:
>> Also note that there are plans to make init non-Essential in the future,
> 
> The future is now! init is non-essential already. You can remove it
> from your unstable chroot if you want to.

Oh cool, didn't know that was already done. Then this just
means that the buildd chroots for most archs (except apparently
hppa) were only upgraded but never rebuilt from scratch - so
the fact that the package builds at all at the moment is an
artifact of how buildd chroots are maintained. ;-)

>> MIPS (at least 32bit) doesn't support 64bit atomic operations
>> intrinsically (_8 == 8 bytes) - and your software uses
>> std::atomic (found that by grepping).
>>
>> However, gcc provides an emulation library called libatomic. You
>> should link against that emulation library if present in order to
>> use those intrinsics.
> 
> You shouldn't need to care about this. This should be the compiler's
> job.

You're right, I agree. I'll file a bug against gcc later.

>> This might result in a spurious dependency on libatomic on other
>> platforms, but unfortunately I don't know of any way to properly
>> pass --as-needed for just this library without libtool reordering
>> the entire list of linker flags. :-(
> 
> Not tested against libtool, but this should do the trick:
> 
> -Wl,--push-state,--as-needed,-latomic,--pop-state
> 
> (Since this is just one g++ argument, libtool doesn't have room to
> reorder much.)

Hrmpf, my try yesterday was

  -Wl,--push-state,--as-needed -latomic -Wl,--pop-state

I didn't think about adding -latomic to the linker flag list
directly via -Wl. I just tested your suggestion and it's really
funny; libtool does mangle your line and separate it into:

 -Wl,--push-state -Wl,--as-needed -Wl,-latomic -Wl,--pop-state

but since there's no direct -l argument, it actually does work
and the things are kept together and in order.

@Muri: use this line in the patch instead:
AC_CHECK_LIB([atomic], [__atomic_add_fetch_8], 
[atomic_LIBS="-Wl,--push-state,--as-needed,-latomic,--pop-state"], 
[atomic_LIBS=""]) 

That way, the libatomic dependency will only be picked up on
platforms where it's necessary.

Regards,
Christian

Re: FTBFS: how to test fixes

[Jakub Wilk]

* Christian Seiler , 2016-09-05, 20:33:
Also note that there are plans to make init non-Essential in the 
future,


The future is now! init is non-essential already. You can remove it from 
your unstable chroot if you want to.


MIPS (at least 32bit) doesn't support 64bit atomic operations 
intrinsically (_8 == 8 bytes) - and your software uses 
std::atomic (found that by grepping).


However, gcc provides an emulation library called libatomic. You should 
link against that emulation library if present in order to use those 
intrinsics.


You shouldn't need to care about this. This should be the compiler's 
job.


This might result in a spurious dependency on libatomic on other 
platforms, but unfortunately I don't know of any way to properly pass 
--as-needed for just this library without libtool reordering the entire 
list of linker flags. :-(


Not tested against libtool, but this should do the trick:

-Wl,--push-state,--as-needed,-latomic,--pop-state

(Since this is just one g++ argument, libtool doesn't have room to 
reorder much.)


--
Jakub Wilk