Re: Help fixing a gettext translation test

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

Re: Help fixing a gettext translation test

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.

Help fixing a gettext translation test

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

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

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

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

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,

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

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-fi

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

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 acce

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

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

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

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:

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

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 furth

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

cs : 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/

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

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

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

f 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: &

Re: Test

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

Test

-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

Re: Suggestion needed on test failures due to double arithmetics

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

Re: Suggestion needed on test failures due to double arithmetics

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

Re: Suggestion needed on test failures due to double arithmetics

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.

Re: Suggestion needed on test failures due to double arithmetics

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

Re: Suggestion needed on test failures due to double arithmetics

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 ar

Re: Suggestion needed on test failures due to double arithmetics

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 i

Re: Suggestion needed on test failures due to double arithmetics

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:

Suggestion needed on test failures due to double arithmetics

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

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

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

Speeding up test builds Re: Building a few of packages

(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

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

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

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)

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

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)

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

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)

r - 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

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

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)

: 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 i

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

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

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

-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/p

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

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

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

lob/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 fol

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

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)

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

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 B

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

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

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

: 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.n

Re: gbp buildpackage test build with uncommitted changes

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

Re: gbp buildpackage test build with uncommitted changes

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

Re: gbp buildpackage test build with uncommitted changes

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

Re: gbp buildpackage test build with uncommitted changes

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

Re: gbp buildpackage test build with uncommitted changes

iles (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

Re: gbp buildpackage test build with uncommitted changes

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. >

Re: gbp buildpackage test build with uncommitted changes

. 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-bra

Re: gbp buildpackage test build with uncommitted changes

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 > > >> >

Re: gbp buildpackage test build with uncommitted changes

> 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;

Re: gbp buildpackage test build with uncommitted changes

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

Re: gbp buildpackage test build with uncommitted changes

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

Re: gbp buildpackage test build with uncommitted changes

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

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

gbp buildpackage test build with uncommitted changes

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

autopkgtest - "error: invalid command 'test'"

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'

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

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

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

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

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

ommand 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:

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

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

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

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

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

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>

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

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. >

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

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

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

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

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

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

How to test interactive and GUI programs with autopkgtest?

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

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

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

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

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

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

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 >

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

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:

Re: piuparts - installation and purging test

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 pi

piuparts - installation and purging test

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

Test failure due to C++ error

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

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

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 > |

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

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,

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

P 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 %

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

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

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

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 the

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

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

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

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 pas

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

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

How to get debian ci test passed for proxy application

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

Test - Please ignore

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

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

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

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

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

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

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

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

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:

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

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.

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

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

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

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 alw

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

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

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

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

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

://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

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

arounds 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

rt 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

mpgrafic - mpirun test program as root in automatic build

://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 r

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

atomic_LIBS (was: FTBFS: how to test fixes)

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

Re: FTBFS: how to test fixes

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.

Re: FTBFS: how to test fixes

* 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

  1   2   3   4   5   6   >