On Thu, 23 Jan 2025 09:25:12 +0100, Julien Plissonneau Duquène wrote:
> Le 2025-01-22 21:15, Phil Wyett a écrit :
> > ratt need not be run against architecture 'all' packages, so for these
> > it will
> > be a 'N/A' result.
> Java libraries are architecture:all, and some updates are breaking build
lad you are doing positive things with
> your time even though you have to deal with significant pain.
>
> > As you say, exceptions. ratt is not for all packages, the test is certainly
> > none blocking, but I hope any issues raised having the test will make for
> > good
On Thu, 2025-01-23 at 19:27 +0100, Salvo Tomaselli wrote:
> Hello,
>
> > * Debian testing on a i5-8265U, 32GB RAM, 1TB NVME laptop.
> > * RHEL 9.x on a Ultra 7 155H, 32GB RAM, 1TB NVME laptop. This has a 100GB
> > Debian testing builder VM. Many other test VMs.
>
&g
On Wed, Jan 22, 2025 at 08:15:43PM +, Phil Wyett wrote:
> ratt (“Rebuild All The Things!”) operates on a Debian .changes file of a just-
> built package, identifies all reverse-build-dependencies and rebuilds them
> with
> the .debs from the .changes file.
>
> The intended use-case is, for ex
Hello,
> * Debian testing on a i5-8265U, 32GB RAM, 1TB NVME laptop.
> * RHEL 9.x on a Ultra 7 155H, 32GB RAM, 1TB NVME laptop. This has a 100GB
> Debian testing builder VM. Many other test VMs.
That is certainly more than what I have at home. I hope it can handle it.
Otherwis
> As you say, exceptions. ratt is not for all packages, the test is certainly
> none blocking, but I hope any issues raised having the test will make for good
> bug reports, communication and avoid unnecessary breakage.
I applaud your efforts.
--
Soren Stoutner
so...@debian.org
signature.as
I have to find out after the fact what got broken and also fix the other
> things. In general breaking other stuff isn't an argument against uploading
> per
> se, but indicates that more uploads become needed, so while a good test in
> general, I think there might be exceptions
ilds (typical causes are that some artifact got renamed, that a
deprecated API got finally removed, or sometimes plain old API/ABI
incompatibilities). Why should they not need this?
The issue I have with that new test (and also with autopkgtests to some
extent) is that the so-called "regre
rgument against uploading per
se, but indicates that more uploads become needed, so while a good test in
general, I think there might be exceptions to the rule.
--
Salvo Tomaselli
"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse ch
new test to the tests currently run against packages.
ratt:
* https://tracker.debian.org/pkg/ratt
* https://manpages.debian.org/unstable/ratt/ratt.1.en.html
ratt (“Rebuild All The Things!”) operates on a Debian .changes file of a just-
built package, identifies all reverse-build-dependencies and
> I can't follow here. Yes, some lines vanished, but they were replaced
> by same lines, but w/o typo. This is mentioned in d/changelog.
Ah sorry my fault I misread the diff!
I will upload then
--
Salvo Tomaselli
"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso,
On 14.01.25 Salvo Tomaselli (ltw...@debian.org) wrote:
Hello,
> I was reviewing this and ran debdiff and there seem to be entries removed
> from
> previous changelogs… this shouldn't really be happening.
>
> Can you fix it?
>
I can't follow here. Yes, some lines vanished, but they were repla
close verbatim environment in tex file (Closes: #1092959)
+ * d/salsa-ci.yml: enable build-twice job
+ * d/watch: adjust to GitHub API change
+
+ -- Christian Göttsche Tue, 14 Jan 2025 00:39:04
+0100
+
check (0.15.2-2) unstable; urgency=medium
* d/{rules,patches}: adjust test suite for P
rg/cgzones/check
Section : devel
The source builds the following 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, you can download the pa
Hi Hilmar,
Thanks for reporting this. CCing the email to debian-ci mail list and
drop mentors@l.d.o.
On Wed, Nov 20, 2024 at 6:55 AM Hilmar Preuße wrote:
>
> Hello,
>
> the debci test for proftpd-dfsg 1.3.8b-3 succeeds unexpectedly on
> riscv64 and only on riscv64. I tried t
Hello,
the debci test for proftpd-dfsg 1.3.8b-3 succeeds unexpectedly on
riscv64 and only on riscv64. I tried to reproduce the issue on a riscv64
porter box and failed. I've asked upstream, what the purpose of the test
is: the answer was that it tries to resolve an unresolvable ad
ritten patches deal with tests so that running tests does not require
> running them only via Makefile. Also package cleaning was extended to
> remove generated test repos and to restore the original 'binary' test
> repos, while they still exist.
Running the tests seems excessivel
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
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.
Than
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 ch
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 c
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, y
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
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
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
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:
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
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/
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 mean
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:
>
>
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
-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
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 o
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
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.
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 doub
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
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
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.c
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
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
(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
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
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 a
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 eith
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
Hi Tobias,
> it seems that check would be a candidate to be ITSed?
Do you mean ITA (Intent To Adopt)?
L-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
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 c
-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
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
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
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) dire
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
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
: 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
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 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 unco
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 complain
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
ted 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 t
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 alre
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-
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
> > >>
>
> 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; @ea
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
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 sig
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
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 buildpacka
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 uncommit
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?
pyth
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 va
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
and 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:
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 b
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 en
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>
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.
>
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
tha
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
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
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.
Re
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
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/exam
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
>
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_consis
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
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
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
t 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:
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
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 % Xfe
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.
>
Thanks all for your reply!
On Mon, Nov 27, 2017 at 3:42 AM, James Cowgill 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
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
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 i
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
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
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
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
1 - 100 of 555 matches
Mail list logo
