Bug#848077: dateutils FTBFS on many architectures with parallel build issues

Am 13.12.2016 um 21:26 schrieb Adrian Bunk: Source: dateutils Version: 0.4.0-1 Severity: serious I haven't been able to reproduce this, but I assume passing --no-parallel to dh should be enough to workaround it. Thank you very much for this hint, I've just uploaded a new version to unstable.

Bug#848077: marked as done (dateutils FTBFS on many architectures with parallel build issues)

Your message dated Wed, 14 Dec 2016 09:03:45 + with message-id and subject line Bug#848077: fixed in dateutils 0.4.0-2 has caused the Debian Bug report #848077, regarding dateutils FTBFS on many architectures with parallel build issues to be marked as done. This means that you claim that the

Processing of dateutils_0.4.0-2_amd64.changes

dateutils_0.4.0-2_amd64.changes uploaded successfully to localhost along with the files: dateutils_0.4.0-2.dsc dateutils_0.4.0-2.debian.tar.xz Greetings, Your Debian queue daemon (running on host usper.debian.org)

dateutils_0.4.0-2_amd64.changes ACCEPTED into unstable

Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 14 Dec 2016 09:36:46 +0100 Source: dateutils Binary: dateutils Architecture: source Version: 0.4.0-2 Distribution: unstable Urgency: medium Maintainer: Debian QA Group Changed-By: Dr. Tobias Quathamer Description

Booking Confirmation

Booking Confirmation This email and any attachments are confidential. If you have received it in error - notify the sender immediately, delete it from your system, and do not use, copy or disclose the information in any way. Kirklees Council monitors all emails sent or received. BookingConf

Processing of opencryptoki_3.6+dfsg-2_source.changes

opencryptoki_3.6+dfsg-2_source.changes uploaded successfully to localhost along with the files: opencryptoki_3.6+dfsg-2.dsc opencryptoki_3.6+dfsg-2.debian.tar.xz Greetings, Your Debian queue daemon (running on host usper.debian.org)

opencryptoki_3.6+dfsg-2_source.changes REJECTED

opencryptoki_3.6+dfsg-2.dsc: Refers to non-existing file 'opencryptoki_3.6+dfsg.orig.tar.gz' Perhaps you need to include the file in your upload? === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our c

Processing of opencryptoki_3.6+dfsg-2_source.changes

opencryptoki_3.6+dfsg-2_source.changes uploaded successfully to localhost along with the files: opencryptoki_3.6+dfsg-2.dsc opencryptoki_3.6+dfsg.orig.tar.gz opencryptoki_3.6+dfsg-2.debian.tar.xz Greetings, Your Debian queue daemon (running on host usper.debian.org)

opencryptoki_3.6+dfsg-2_source.changes ACCEPTED into experimental

Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 14 Dec 2016 11:41:02 + Source: opencryptoki Binary: opencryptoki libopencryptoki0 libopencryptoki-dev Architecture: source Version: 3.6+dfsg-2 Distribution: experimental Urgency: medium Maintainer: Debian QA Gr

Processing of imagination_3.0-7_source.changes

imagination_3.0-7_source.changes uploaded successfully to localhost along with the files: imagination_3.0-7.dsc imagination_3.0-7.debian.tar.xz Greetings, Your Debian queue daemon (running on host usper.debian.org)

imagination_3.0-7_source.changes ACCEPTED into unstable

Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 12 Dec 2016 17:53:33 -0200 Source: imagination Binary: imagination imagination-common Architecture: source Version: 3.0-7 Distribution: unstable Urgency: medium Maintainer: Debian QA Group Changed-By: Joao Eribert

Bug#211119: libgdbm3: ordered traversal option for firstkey/nextkey?

control: tag -1 +wontfix control: close -1 [2003-09-16 02:02] Colin Watson > It'd be nice to have a flag to gdbm_setopt() or similar which would > cause gdbm_firstkey() and gdbm_nextkey() to return entries in a > lexicographically sorted fashion, or I suppose even with an arbitrary > comparison

Processed: Re: libgdbm3: gdbm_open(... GDBM_NEWDB ...) keeps old entries

Processing control commands: > tag -1 +unreproducible Bug #447981 [libgdbm3] libgdbm3: gdbm_open(... GDBM_NEWDB ...) keeps old entries Added tag(s) unreproducible. > close -1 Bug #447981 [libgdbm3] libgdbm3: gdbm_open(... GDBM_NEWDB ...) keeps old entries Marked Bug as done -- 447981: http://bug

Processed: Re: libgdbm3: gdbm_open continually reopens file in a loop until it runs out of file descriptors and fails.

Processing control commands: > close -1 Bug #374354 [libgdbm3] libgdbm3: gdbm_open continually reopens file in a loop until it runs out of file descriptors and fails. Marked Bug as done -- 374354: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=374354 Debian Bug Tracking System Contact ow...@b

Processed: Re: libgdbm3: ordered traversal option for firstkey/nextkey?

Processing control commands: > tag -1 +wontfix Bug #29 [libgdbm3] libgdbm3: ordered traversal option for firstkey/nextkey? Added tag(s) wontfix. > close -1 Bug #29 [libgdbm3] libgdbm3: ordered traversal option for firstkey/nextkey? Marked Bug as done -- 29: http://bugs.debian.org/cgi

Bug#374354: libgdbm3: gdbm_open continually reopens file in a loop until it runs out of file descriptors and fails.

control: close -1 > When I try yo invoke gdbm_open, the call appears to internally open and > reopen the specified file until we run out of file descriptors, at which > point gdbm_open fails with gdbm_errno 3(File open failure) and errno 24 > (Too many open files). > > This will officially be my

Bug#447981: libgdbm3: gdbm_open(... GDBM_NEWDB ...) keeps old entries

control: tag -1 +unreproducible control: close -1 > In some software I'm using libgdbm=1.8.3-3. Some routine wants to use > a gdbm file as a kind of non-memory-limited hash, so it tries to open > some filename with GDBM_NEWDB. > > I wondered for some time why this routine gets old entries, until