Re: FTBFS: how to test fixes

hi, On 09/05/2016 09:11 PM, Christian Seiler wrote: > On 09/05/2016 08:59 PM, Muri Nicanor wrote: >> On 09/05/2016 08:33 PM, Christian Seiler wrote: >>>Since you depend on systemd.pc, which is part of the >>>systemd package, just Build-Depend on systemd to make >>>systemd.pc

Re: FTBFS: how to test fixes

On 09/05/2016 08:59 PM, Muri Nicanor wrote: > On 09/05/2016 08:33 PM, Christian Seiler wrote: >>Since you depend on systemd.pc, which is part of the >>systemd package, just Build-Depend on systemd to make >>systemd.pc available. You won't need porterbox access >>to fix that issue.

Re: FTBFS: how to test fixes

Hi, On 09/05/2016 08:33 PM, Christian Seiler wrote: > On 09/05/2016 07:20 PM, Andrey Rahmatullin wrote: >> On Mon, Sep 05, 2016 at 07:07:51PM +0200, Muri Nicanor wrote: >>> so, i've got my first two FTBFS bugs (on mips and hppa)- what the >>> recommended way of testing fixes for architectures i

Re: FTBFS: how to test fixes

s it to the linker flags. 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. :-( I've build-tested (inc

Re: FTBFS: how to test fixes

On Mon, Sep 05, 2016 at 05:39:16PM +, Gianfranco Costamagna wrote: > (I don't think every architecture has a porterbox machine, so some of them > might be out of possibility I think all release one have. > e.g. mips good, hppa not. I'm not sure it's worth one's time to test packag

Re: FTBFS: how to test fixes

* Muri Nicanor <m...@immerda.ch>, 2016-09-05, 19:07: 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? Ask on porters' mailing lists (debian-hppa@, debian-mips@) for someone to test it f

Re: FTBFS: how to test fixes

Hi, >Porterboxes. See https://dsa.debian.org/doc/guest-account/ about getting >access for non-DDs. or if you aren't a DM, and have some patches to test, send them to me and I'll try to do test builds. (note: my time is limited, so try to avoid ~100 patches to test, unless I can scrip

Re: FTBFS: how to test fixes

On 05/09/16 18:20, Andrey Rahmatullin wrote: On Mon, Sep 05, 2016 at 07:07:51PM +0200, Muri Nicanor wrote: 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? Porterboxes. See

Re: FTBFS: how to test fixes

On Mon, Sep 05, 2016 at 07:07:51PM +0200, Muri Nicanor wrote: > 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? Porterboxes. See https://dsa.debian.org/doc/guest-account/ about getting access for

FTBFS: how to test fixes

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 signature.asc Description: OpenPGP digital signature

Re: Test suite needs script built after dh_auto_test is run

Dear Barry, On Fri, Feb 05, 2016 at 02:17:51PM -0500, Barry Warsaw wrote: > If ocrmypdf supports Python's -m option, you could consider patching the test > suite to run `python -m ocrmydf` instead. Season to taste for python3 and or > both if you're using pybuild. > > [snip]

Re: Test suite needs script built after dh_auto_test is run

On Feb 04, 2016, at 09:08 PM, Sean Whitton wrote: >I'm packaging a Python application, ocrmypdf [1], that has a test suite >run by py.test. Most of the tests fail because they try to call the >/usr/bin/ocrmypdf script. This script doesn't exist until after >debhelper has run set

Test suite needs script built after dh_auto_test is run

Hello, I'm packaging a Python application, ocrmypdf [1], that has a test suite run by py.test. Most of the tests fail because they try to call the /usr/bin/ocrmypdf script. This script doesn't exist until after debhelper has run setup.py, which generates it using its "entry points s

Re: Autopkgtest: long test

On Sat, Nov 7, 2015 at 9:51 AM, Jerome BENOIT wrote: > Is there a simple way to prolong the default authorized time ? The adt-run manual page mentions some in the TIMEOUT section, I would suggest trying those. -- bye, pabs https://wiki.debian.org/PaulWise

Autopkgtest: long test

Hello Forum: For one of my package, gmp-ecm not to mention it, I set up a test based on a longcheck provided by the upstream team. As the name indicates, the test is long but I would say it is not that long in its category: it is numerical test. Whatever, this test fails the autopkgtest test

Re: How to accomodate test files that move after installation?

Hi Jeffrey, On 2015-09-30 14:17, Jeffrey Walton wrote: > Crypto++ has test files. When they are run from $PWD, them they work > fine. After installation into, say, /usr/share/, they break because > the location is an implicit dependency. So the two requirements are > self test mus

How to accomodate test files that move after installation?

Hi Everyone, I have one last question related to packaging and installation. (I hope it is the last question). Crypto++ has test files. When they are run from $PWD, them they work fine. After installation into, say, /usr/share/, they break because the location is an implicit dependency. So

Re: Access to Debian Test Farm for s390 Testing

gt; > > Hi Jeffrey, > > Thanks for your interest. :) > > I am directing you over to debian-mentors, since your enquiry is > probably better fitted there (debian-testing is intended for upgrade > reports etc.) > >> I have a lot of systems available to me for testing (inc

Bug#786641: marked as done (RFS: tap.py/1.4-2 [ITP] -- Test Anything Protocol (TAP) tools for Python)

Your message dated Wed, 16 Sep 2015 04:24:48 + with message-id <e1zc4h2-0001ch...@quantz.debian.org> and subject line closing RFS: tap.py/1.4-2 [ITP] -- Test Anything Protocol (TAP) tools for Python has caused the Debian Bug report #786641, regarding RFS: tap.py/1.4-2 [ITP] -- Test An

Re: Access to Debian Test Farm for s390 Testing

iry is probably better fitted there (debian-testing is intended for upgrade reports etc.) > I have a lot of systems available to me for testing (including GCC's > test farm), but none of them provide an s390 environment. I tried to > add QEMU's qemu-system-s390x, but ran into De

Re: java pacakge: maven material: how to test

Hi Jerome, I know absolutely nothing about Java, but I have found 2 pages which may help you: and . Also you may want to seek help on these Java-specific mailing lists: and

java pacakge: maven material: how to test

Hello List: I am package a Java library. It will come with maven material: how can I check that the maven is well set up ? Thanks in advance, Jerome

Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number

Hi Gianfranco, An old message is inlined below. 2015-08-21 20:46 GMT+08:00, Gianfranco Costamagna costamagnagianfra...@yahoo.it: d/rules: I personally do not like calling bootstrap, specially when the only thing needed there seems to be applying one patch and calling and generating

Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number

Hi Alex, What do you mean by not preferring the bootstrap script? I have included the script in upstream's tarball, so that devs can re-generate build scripts, man page and friends. Besides, according to

Bug#795704: marked as done (RFS: mlucas/14.1-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number)

Your message dated Fri, 28 Aug 2015 10:08:57 + (UTC) with message-id 585801580.2419019.1440756537583.javamail.ya...@mail.yahoo.com and subject line Re: Bug#795704: RFS: mlucas/14.1-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number has caused the Debian Bug report #795704

Bug#795704: RFS: mlucas/14.1-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number

Hi Gianfranco, Thanks! I will let upstream know. Cheers, Alex 2015-08-28 18:08 GMT+08:00, Gianfranco Costamagna costamagnagianfra...@yahoo.it: Hi Alex, BuiltSignedUploaded, thanks for your contribution to Debian! cheers, G.

Bug#795704: Fwd: Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number

Hi Alex, I contacted Ernst (upstream dev) and he agreed to integrate the build system into his dev branch. Wonderful! Good news are good :) I think the above should solve the version string problem as well. Or if it doesn't we can use the old method based on date string. I think it should

Bug#795704: Fwd: Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number

: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number To: Alex Vong alexvong1...@gmail.com Hi, Alex: I am fine with option [1], integrating the build system into my main-dev. Just need a bit of clarification - what files does the 'build system' encompass, and where

Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number

Version : 14.1+dfsg-1 Upstream Author : Ernst W. Mayer ewma...@aol.com * URL : http://hogranch.com/mayer/README.html * License: GPL-2+ Section : math It builds those binary packages: mlucas - program to perform Lucas-Lehmer test on a Mersenne number

Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number

Hi Gianfranco, Thanks for the quick reply, I have just finished dinner. 2015-08-21 20:46 GMT+08:00, Gianfranco Costamagna costamagnagianfra...@yahoo.it: Hi Alex, let's review :) d/changelog please set to unstable, and update the timestamp Okay. d/rules: wl-asneeded is good if enable, does

Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number

Hi Gianfranco, 2015-08-21 22:15 GMT+08:00, Gianfranco Costamagna costamagnagianfra...@yahoo.it: so basically the tarball found with uscan has nothing in common with the actual Debian packaging? you grab the tarball, you add a build system and you pack again, right? Actually no. I think

Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number

+ 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: http://mentors.debian.net/package/mlucas Alternatively, one can download

Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number

Hi, Actually no. I think this needs clarification. The upstream tarball contains .c .h files and some (non-dfsg-compliant) temporary files. The repack script removes the (non-dfsg-compliant) temporary files and move all the .c .h files into a directory called src/. The build system and friends

Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number

Hi Okay. I think this needs further explaination. Upstream does not include a build system, not even a Makefile. Building is done by invoking gcc directly using different flags for different platform. This is however cumbersome, so I add autotools to ease building. I use git for development

Bug#795704: RFS: mlucas/14.1-dfsg1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number

2015-08-16 23:56 GMT+08:00, Jakub Wilk jw...@debian.org: * Alex Vong alexvong1...@gmail.com, 2015-08-16, 19:42: http://mentors.debian.net/debian/pool/main/m/mlucas/mlucas_14.1-dfsg1.dsc I don't intend to sponsor this package, but I had a quick look at it: Thanks for the quick look! Don't

Bug#795704: RFS: mlucas/14.1-dfsg1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number

: 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: http://mentors.debian.net/package/mlucas Alternatively, one can download the package with dget using

Bug#795704: RFS: mlucas/14.1-dfsg1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number

: mlucas Version : 14.1-dfsg1 Upstream Author : * URL : http://hogranch.com/mayer/README.html * License: GPL-2+ Section : math It builds those binary packages: mlucas - program to perform Lucas-Lehmer test on a Mersenne number To access

Bug#795704: RFS: mlucas/14.1-dfsg1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number

* Alex Vong alexvong1...@gmail.com, 2015-08-16, 19:42: http://mentors.debian.net/debian/pool/main/m/mlucas/mlucas_14.1-dfsg1.dsc I don't intend to sponsor this package, but I had a quick look at it: Don't assume that kfreebsd-any means only kfreebsd-i386 and kfreebsd-amd64. It is the case

Strange *.so names in pbuild do require tricks for test suite (Was: Trying to run build time tests using nosetest for python-pysam)

: override_dh_auto_test: PYBUILD_SYSTEM=custom \ PYBUILD_TEST_ARGS=cd tests {interpreter} pysam_test.py dh_auto_test || echo Ignoring test failures Also note the following in tests/00README.txt: Seems this README is outdated - the file pysam_test.py is not provided any more and the tests

Bug#786641: RFS: tap.py/1.4 [ITP] -- Test Anything Protocol (TAP) tools for Python

You shouldn't make separate changelog entries for versions that were never published. Commented Vcs-* fields in d/control should be removed if not used. X(3)-Python-Version conditions are satisfied even in oldstable so may safely be dropped. lintian says dep5-copyright-license-name-not-unique

Bug#786641: RFS: tap.py/1.4 [ITP] -- Test Anything Protocol (TAP) tools for Python

Package: sponsorship-requests Severity: normal Dear Debian Mentors, I am looking for a sponsor for the tap.py package: * Package name: tap.py Version : 1.4 Upstream Author : Matt LAYMAN * URL : https://github.com/mblayman/tappy * License : BSD-2

Bug#781847: marked as done (RFS: python-tappy/1.3-1 [ITP] -- Test Anything Protocol (TAP) tools for Python)

Your message dated Sat, 23 May 2015 22:34:28 +0200 with message-id caowzrlabxgejsf+khrha4-nofq0tm8gppdaomql9k4j+sxk...@mail.gmail.com and subject line Re: Bug#781847: RFS: python-tappy/1.3-1 [ITP] -- Test Anything Protocol (TAP) tools for Python has caused the Debian Bug report #781847

Bug#781847: RFS: python-tappy/1.3-1 [ITP] -- Test Anything Protocol (TAP) tools for Python

Control: tags -1 + moreinfo On Fri, Apr 03, 2015 at 08:50:14PM +0200, Nicolas CANIART wrote: Packages are available for review on debian mentors They aren't on mentors. and here: http://www.caniart.net/debian/NEW/ Nor are they there. -- WBR, wRAR signature.asc Description: Digital

Bug#781847: RFS: python-tappy/1.3-1 [ITP] -- Test Anything Protocol (TAP) tools for Python

tap.py is a python package that provides: - a test runner that produces a TAP compliant output; - facilities to load and parse the output produced by TAP compliant test runners. - Provides a lexer to colorize TAP output with Pygments. There are a few other python packages that do similar stuff

RFS: python-tappy/1.3-1 [ITP] -- Test Anything Protocol (TAP) tools for Python

tap.py is a python package that provides: - a test runner that produces a TAP compliant output. - facilities to load and parse the output produced by TAP compliant test runners. - Provides a lexer to colorize TAP output with Pygments. There are a few other python packages that to similar stuff

Re: Re: Re: Re: Big data is needed for unit test

doing the unit tests on your own hardware against the installed package, rather than doing the unit tests at build time on Debian hosts. You could also place the test files on your website and have a README file or test-me script that people could use to download the test files and run the tests

Re: Re: Re: Big data is needed for unit test

for this unit test is the same for all the others unit test... I've more than 4GB of data, so in all cases, I will have a big data's quantity. Anyway, I don't consider the size to be a big issue as long as you put the data in a second orig.tar.gz. I guess that this new orig.tar.gz would

Re: Re: Re: Big data is needed for unit test

the orig tarball. Copyright and license information should go in debian/copyright as usual. So I have to upload my data (4GB) somewhere where uscan could find it. But I've no idea about where upload it, given Github doesn't accept files bigger than 100MB. Have you any idea ? The test file is only

Re: Re: Re: Big data is needed for unit test

Hi Can you link to the file we are talking about? With the authorization of the responsibles of the project, I published the file here [2] [2]http://goo.gl/53sAzM this looks a bit weird. I guess this google thing allows you to inspect the content of zip files? Yes indeed. I simply

Re: Re: Re: Re: Big data is needed for unit test

find it. But I've no idea about where upload it, given Github doesn't accept files bigger than 100MB. Have you any idea ? The test file is only 200MB, where is this 4GB coming from? The file is just used by one of the unit tests. But there are more than 20 unit tests which need their own specific

Re: Re: Re: Re: Big data is needed for unit test

. Personally I'm now leaning towards you doing the unit tests on your own hardware against the installed package, rather than doing the unit tests at build time on Debian hosts. You could also place the test files on your website and have a README file or test-me script that people could use to download

Re: Big data is needed for unit test

this test, or can I include the data file in the package ? Can you include more details about this data file? What data format is the file in? It is a .jsonz file. What license is the file under? It hasn't any license. Does upstream ship the file in the same source package? Actually

Re: Big data is needed for unit test

permission from it's copyright holder. Of course you can't upload it to the debian archive (see DFSG). Please check better, given that it is the test case of a free software maybe also the data are free. -- regards, Mattia Rizzolo GPG Key: 4096R/B9444540

Re: Big data is needed for unit test

that it is the test case of a free software maybe also the data are free. In fact I'm not sure that the file hasn't license. I meant that I've not found any indication about the license of this file. But, I work for the company which develops the software, so I've asked the question

Re: Big data is needed for unit test

to do that. I don't understand. I've just one single data file for the test. How can I include a smaller test-case ? I don't know enough about the software and the file we are talking about to answer that. Can you link to the file we are talking about? -- bye, pabs https://wiki.debian.org

Re: Re: Big data is needed for unit test

I don't know enough about the software and the file we are talking about to answer that. The software (fw4spl) is a framework focused on processing and visualization of medical images. Here, the repository of the project : [1] Can you link to the file we are talking about? With the

Re: Re: Big data is needed for unit test

Hi, Quoting Corentin Desfarges (2014-12-02 17:29:12) Can you link to the file we are talking about? With the authorization of the responsibles of the project, I published the file here [2] [2] http://goo.gl/53sAzM this looks a bit weird. I guess this google thing allows you to inspect the

Re: Re: Big data is needed for unit test

On Wed, Dec 3, 2014 at 12:29 AM, Corentin Desfarges wrote: With the authorization of the responsibles of the project, I published the file here [2] It contains the names of one patient and his birth date so that probably wasn't a good idea. This file appears to contain CT scan results in a

Big data is needed for unit test

Dear Mentors, I'm working on the packaging of fw4spl (a medical software), and I'm faced with a new problematic : One of the unit tests needs to load an important data file, which has a big size (~200 Mo). Should I simply remove this test, or can I include the data file in the package ? Thank

Re: Big data is needed for unit test

simply remove this test, or can I include the data file in the package ? Can you include more details about this data file? What data format is the file in? What license is the file under? Does upstream ship the file in the same source package? If you can get upstream to include a smaller test

Re: Big data is needed for unit test

Hi, Quoting Paul Wise (2014-12-01 17:03:39) Should I simply remove this test, or can I include the data file in the package ? Can you include more details about this data file? What data format is the file in? depending on the answer to this question it might be very simple to compress

Re: Big data is needed for unit test

Le lundi 01 décembre 2014 à 17:28 +0100, Johannes Schauer a écrit : Hi, Quoting Paul Wise (2014-12-01 17:03:39) Should I simply remove this test, or can I include the data file in the package ? Can you include more details about this data file? What data format is the file

[help] Test of samtools breaks build on armel and sparc

Hi, I realised that the samtools package is not build for armel and sparc[1] in both cases since a test running at build time failed: armel: make[1]: Entering directory `/build/buildd-samtools_0.1.19-1-armel-DBqlzN/samtools-0.1.19/examples' ../samtools faidx ex1.fa ../samtools import ex1

Re: [help] Test of samtools breaks build on armel and sparc

Looks like SPARC is having a bus error, which almost always means unaligned data is being accessed. Running this test with gdb attached will break on the line where there is a problem and should give enough information to the original developer to resolve it. Andreas -- can you send me (off-list

Bug#749532: marked as done (RFS: goldeneye/0.0~git20140221.7a38fe93-1 [ITP] -- HTTP DoS test tool)

Your message dated Wed, 30 Jul 2014 15:56:35 -0300 with message-id 20140730155635.a5b47cbe3ff4b73fc7b95...@debian.org and subject line Re: RFS: goldeneye/0.0~git20140221.7a38fe93-1 [ITP] -- HTTP DoS test tool has caused the Debian Bug report #749532, regarding RFS: goldeneye/0.0

Re: How to do a test sbuild with additional package, not in the repositories?

to be one jump ahead of them when they do do the transition. I have grabed the source from experimental built it under unstable, and used it to test build my package with debuild. However I want to test build my package with sbuild. Sometimes debuild succeeds when it should not, because my test

How to do a test sbuild with additional package, not in the repositories?

the transition. I have grabed the source from experimental built it under unstable, and used it to test build my package with debuild. However I want to test build my package with sbuild. Sometimes debuild succeeds when it should not, because my test system has some unlisted dependancy. How do I

How to do a test sbuild with additional package, not in the repositories?

. I have grabed the source from experimental built it under unstable, and used it to test build my package with debuild. However I want to test build my package with sbuild. Sometimes debuild succeeds when it should not, because my test system has some unlisted dependancy. How do I get the one

Re: How to do a test sbuild with additional package, not in the repositories?

On 28/06/14 20:37, Paul Elliott wrote: How do I get the one package that is not in unstable (libwxsqlite3-3.0-dev) into sbuild's list of packages for a test build? I thought I'd seen this on the Debian sbuild wiki page... but alas it's not there! The only thing I was able to find

Re: How to do a test sbuild with additional package, not in the repositories?

On Jun 28, 2014, at 09:13 PM, Daniel Lintott wrote: The only thing I was able to find was this- http://www.wefearchange.org/2011/09/sbuild-with-local-newer-dependencies.html I still use that setup extensively, most recently while adding Python 3 support to a stack of zope.* and other packages.

Bug#749532: RFS: goldeneye/0.0~git20140221.7a38fe93-1 [ITP] -- HTTP DoS test tool

* URL : https://github.com/jseidl/GoldenEye * License : GPL-3.0 Section : net It builds those binary packages: goldeneye - HTTP DoS test tool To access further information about this package, please visit the following URL: http://mentors.debian.net

How to trigger running unit test suite with cdbs

Hi, since GNU R packages are using a nice cdbs helper but this helper does not have the dh_auto_test feature of dh I wonder, how I could trigger the unit tests provided by upstream anyway. As an example package you could have a look at r-cran-qtl where I provided the unit tests as autopkgtest

Re: Test builds in gbp patch-queue branch [was: Re: Is there a way to preserve pbuilder chroot environment?]

+++ Ross Gammon [2014-03-01 23:37 +0100]: Now you have all helped me to realise that I can spam with 'debian/rules build' to test if it fixes a FTBFS, or 'fakeroot debian/rules binary' to go all the way to a 'deb' which I can try installing. (And very usefully, just retry the packaging step

Re: Test builds in gbp patch-queue branch [was: Re: Is there a way to preserve pbuilder chroot environment?]

this when I wanted to test changes to e.g. d/rules before committing the fix. Ok. What I was probably not clear about, was that I meant changes made outside the debian directory. Ah, indeed, I had not realized this; and I hadn't thought about this issue because ... dpkg-source: info: building

Test builds in gbp patch-queue branch [was: Re: Is there a way to preserve pbuilder chroot environment?]

' to test if it fixes a FTBFS, or 'fakeroot debian/rules binary' to go all the way to a 'deb' which I can try installing. But if I don't want to install all the build dependencies on the machine I am using, how can I pass these commands to pbuilder? Or can I override gbp buildpackage (with pbuilder

Re: Test builds in gbp patch-queue branch [was: Re: Is there a way to preserve pbuilder chroot environment?]

On Sat, 01 Mar 2014 23:37:22 +0100, Ross Gammon wrote: 'gbp buildpackage' fails because it detects altered files in the source code. Or can I override gbp buildpackage (with pbuilder as an option) in some way so that it ignores the fact that there are altered files? Yes, you can: ==

Re: Test builds in gbp patch-queue branch [was: Re: Is there a way to preserve pbuilder chroot environment?]

INDEX exports the current index whereas the special name WC exports the current working copy as is. Cheers, gregor Thanks Gregor, but I was already aware of --git-export=WC --git-ignore-new. I have used this when I wanted to test changes to e.g. d/rules before

Re: continue on a failing test (dh7)

On Wed, Feb 12, 2014 at 06:21:24AM +, Roelof Wobben wrote: But then Im going to need a javascript expert. I'm not that! One of the test gives undefined where it schould be given a exception. The whole file can be found here : https://github.com/linuxmint/cjs/blob/master/test/js

continue on a failing test (dh7)

Hello, Is there a way with dh7 to continue the build even if a test is failing ? Roelof -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http

Re: continue on a failing test (dh7)

override_dh_auto_test: dh_auto_test || true On Tue, Feb 11, 2014 at 5:16 PM, Roelof Wobben rwob...@hotmail.com wrote: Hello, Is there a way with dh7 to continue the build even if a test is failing ? Roelof -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org

Re: continue on a failing test (dh7)

Mathieu Malaterre mathieu.malate...@gmail.com writes: override_dh_auto_test: dh_auto_test || true In idiomatic make, override_dh_auto_test: -dh_auto_test Though probably less clear, given how few are make experts :-) -- To UNSUBSCRIBE, email to

Re: continue on a failing test (dh7)

On Wed, Feb 12, 2014 at 12:16 AM, Roelof Wobben wrote: Is there a way with dh7 to continue the build even if a test is failing ? Please don't do that , tests are there for a reason. It is better to fix the problem or fix the test than ignore the test. -- bye, pabs http://wiki.debian.org

Re: continue on a failing test (dh7)

On Wed, Feb 12, 2014 at 09:20:06AM +0800, Paul Wise wrote: Please don't do that , tests are there for a reason. It is better to fix the problem or fix the test than ignore the test. To give an example of why this is important. procps had a problem where it would fail on certain buildds

RE: continue on a failing test (dh7)

Date: Wed, 12 Feb 2014 12:37:28 +1100 From: csm...@debian.org To: debian-mentors@lists.debian.org Subject: Re: continue on a failing test (dh7) On Wed, Feb 12, 2014 at 09:20:06AM +0800, Paul Wise wrote: Please don't do that , tests

Cjs failing test

Hello, I have a failing test on the package cjs. I have asked upstream how to solve this and thet say use this : DEB_BUILD_OPTIONS=nocheck Is this acceptable for a package which is hopefully once a part of Debian. According to upstream the failing test is Always failing but solving

Re: Cjs failing test

2014-02-05 Roelof Wobben rwob...@hotmail.com: Hello, I have a failing test on the package cjs. I have asked upstream how to solve this and thet say use this : DEB_BUILD_OPTIONS=nocheck Is this acceptable for a package which is hopefully once a part of Debian. According to upstream

RE: Cjs failing test

Date: Wed, 5 Feb 2014 18:09:32 +0100 Subject: Re: Cjs failing test From: matth...@tenstral.net To: rwob...@hotmail.com CC: debian-mentors@lists.debian.org 2014-02-05 Roelof Wobben rwob...@hotmail.com: Hello, I have a failing test on the package

Re: Cjs failing test

On Wed, Feb 5, 2014 at 6:14 PM, Roelof Wobben rwob...@hotmail.com wrote: oke, and how can I override to not using test or not using a particular test. What the test actually test I do not know. I made a issue on the githb page of cjs : https://github.com/linuxmint/cjs/issues/5 In my

Unrreproducible bug in autopkg test

Greetings, all. A package I'm maintaining as part of the Debian Med team has a bug reported against it which I can't reproduce locally [1]. Since I can't reproduce it, I'm not sure it will not fail again even with the potential fix we've found. Before going for the solution of disabling the test

Re: Unrreproducible bug in autopkg test

by Andreas the solution is to use the same arguments to the test suite in the autopkgtest as you do in the build-time test: PYTHONPATH=$(CURDIR):$(PYTHONPATH) PYTHONWARNINGS=d python csb/test/app.py --generated-resources /tmp vs PYTHONWARNINGS=d $python test/app.py 21 -- bye, pabs http

Re: How to handle a package requiring external test data for its test suite?

* Charles Plessy ple...@debian.org, 2013-06-18, 08:33: Have you considered running the tests with autopkgtest ? http://dep.debian.net/deps/dep8/ Then, you can either download the data or install it from a separate data package. No, you can't assume that Internet connectivity will be

Re: How to handle a package requiring external test data for its test suite?

and now the test suite is running fine - I added a autopkgtest to check that a simple program can be compiled after installing the packages. However I am not aware of a way to run a CMake test suite against installed software so I let it go for now. Thanks again for you help. -- Thomas Moulard

How to handle a package requiring external test data for its test suite?

Dear all, I am currently packaging a computer vision software[1] which test suite requires external data (images). Considering the weight of the images (~75Mb) compared to the package size (a few Mb) they decided to distribute them separately. Right now, 30% of the tests are failing due

Re: How to handle a package requiring external test data for its test suite?

Le Tue, Jun 18, 2013 at 08:10:29AM +0900, Thomas Moulard a écrit : I am currently packaging a computer vision software[1] which test suite requires external data (images). Considering the weight of the images (~75Mb) compared to the package size (a few Mb) they decided to distribute them

Re: How to handle a package requiring external test data for its test suite?

Since upstream distributes the data in a separate source package, I would suggest packaging it separately and then build-depending on the data package. We have larger packages in the archive so the size isn't a problem. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to

Bug#707300: RFS: f3/2.2-1 [ITP] -- test real flash memory capacity

Section : utils It builds this binary package: f3- test real flash memory capacity To access further information about this package, please visit the following URL: http://mentors.debian.net/package/f3 Alternatively, one can download the package with dget using

Bug#694778: A little test message to see whether our filters work now

Sorry for the hijack of your RFS, I'm testing our new mail filter. Please ignore me :) -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature

Bug#694778: A little test message to see whether our filters work now

ok :) 2013/1/15 Arno Töll a...@debian.org Sorry for the hijack of your RFS, I'm testing our new mail filter. Please ignore me :) -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D

Bug#694778: A little test message to see whether our filters work now

On Tue, Jan 15, 2013 at 9:58 AM, Arno Töll a...@debian.org wrote: Sorry for the hijack of your RFS, I'm testing our new mail filter. Please ignore me :) (don't tell me what to do) -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -- :wq --

Bug#694778: A little test message to see whether our filters work now

I should also note a review for this package was sent off-report :) Cheers, T On Tue, Jan 15, 2013 at 10:01 AM, Paul Tagliamonte paul...@debian.org wrote: On Tue, Jan 15, 2013 at 9:58 AM, Arno Töll a...@debian.org wrote: Sorry for the hijack of your RFS, I'm testing our new mail filter.

<    1   2   3   4   5   6   >