Processing of libytnef_1.5-9_amd64.changes
libytnef_1.5-9_amd64.changes uploaded successfully to localhost along with the files: libytnef_1.5-9.dsc libytnef_1.5-9.debian.tar.xz libytnef0-dev_1.5-9_amd64.deb libytnef0_1.5-9_amd64.deb Greetings, Your Debian queue daemon (running on host franck.debian.org)
Bug#742146: marked as done (libytnef: fails to build with clang instead of gcc)
Your message dated Sat, 22 Aug 2015 09:41:32 +
with message-id
and subject line Bug#742146: fixed in libytnef 1.5-9
has caused the Debian Bug report #742146,
regarding libytnef: fails to build with clang instead of gcc
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
742146: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742146
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: libytnef
Version: 1.5-6
Severity: minor
Tags: patch
User: pkg-llvm-t...@lists.alioth.debian.org
Usertags: clang-ftbfs
Dear Maintainer,
Your package fails to build with clang instead of gcc. [-Wreturn-type]
The attached patch fixes it.
Buildlogs and patch are here:
https://github.com/nonas/debian-clang/tree/master/buildlogs/libytnef
Regards,
Nicolas
-- System Information:
Debian Release: jessie/sid
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Description: fix FTBFS with clang instead of gcc
Author: Nicolas Sévelin-Radiguet
Last-Update: 2014-03-19
--- a/ytnef.c
+++ b/ytnef.c
@@ -565,7 +565,7 @@
int TNEFHexBreakdown STD_ARGLIST {
int i;
if (TNEF->Debug == 0)
-return;
+return -1;
printf("%s: [%i bytes] \n", TNEFList[id].name, size);
@@ -580,7 +580,7 @@
int TNEFDetailedPrint STD_ARGLIST {
int i;
if (TNEF->Debug == 0)
-return;
+return -1;
printf("%s: [%i bytes] \n", TNEFList[id].name, size);
--- End Message ---
--- Begin Message ---
Source: libytnef
Source-Version: 1.5-9
We believe that the bug you reported is fixed in the latest version of
libytnef, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 742...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Ricardo Mones (supplier of updated libytnef package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Sat, 22 Aug 2015 11:10:24 +0200
Source: libytnef
Binary: libytnef0 libytnef0-dev
Architecture: source amd64
Version: 1.5-9
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group
Changed-By: Ricardo Mones
Description:
libytnef0 - improved decoder for application/ms-tnef attachments
libytnef0-dev - headers for application/ms-tnef attachments decoder
Closes: 742146
Changes:
libytnef (1.5-9) unstable; urgency=medium
.
* QA upload.
* Add patch to fix FTBFS with clang. Closes: #742146.
Checksums-Sha1:
0225a4ac224b2497c5929ff5b4739f0e62421cda 1782 libytnef_1.5-9.dsc
dcc8a55172f4ac4fa8b09ce7d90794b90d0c2806 218724 libytnef_1.5-9.debian.tar.xz
2742cd7e75a910a16a6292cb2d8cd02306352134 24122 libytnef0-dev_1.5-9_amd64.deb
49ae20bea4d624150cf9c217881c47e018f9e501 20074 libytnef0_1.5-9_amd64.deb
Checksums-Sha256:
a060397a803ebac89e87776d7b5cf240b8a5711edaa810bb49a601f0115b0427 1782
libytnef_1.5-9.dsc
70fa86e9bddc2f4cf394ea8f39a2aa21b4a0a5e6fcad12550df06bf5f7a44d11 218724
libytnef_1.5-9.debian.tar.xz
9ddbbe32e0f33126b6773fb243931b12f421b4bd0a7c12f769c609602b957c12 24122
libytnef0-dev_1.5-9_amd64.deb
04819b0b79e16f361f81397630c4a5551fabd22da3ab4c46ab204a0e013e4aad 20074
libytnef0_1.5-9_amd64.deb
Files:
f12aa06c0b2653085cf7d5819e058a7c 1782 utils extra libytnef_1.5-9.dsc
1b5409ae94addade0c03fbd4e205d407 218724 utils extra
libytnef_1.5-9.debian.tar.xz
f2b147c4f6768bff3481f7bda033ecf8 24122 libdevel extra
libytnef0-dev_1.5-9_amd64.deb
fda886f365fca5a91181983ebf3c967f 20074 libs extra libytnef0_1.5-9_amd64.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQIcBAEBCAAGBQJV2D3bAAoJEB8PCojeW8ymW+gP/RWt9qxKKN1lqTydZimf9r70
TedNkJ6CiNmJRykc/evdCQfq1Er2b9o7GUEKbbjl7Az+tkXMK5mdVFFhpx0USDMy
q1++m3+UM3p1pNB/qomR/BCxnuP/VbINmZ4daO4HnoE0CUIaBFX2D8kMJA7sg5Cp
Fqh50Ctvfhb9nODMs4Y07qrKDGmRNg6eZujLxpHrSMAzsPy8ca3/E9F+hFlNHe5S
ykpQsy1y0nYYQgpc8l2jY0nqWrEOIPxOc2YqRtVOVCNfoULMuHuJn3VZ/xUu++OZ
nQUk4q70lZl2FADQfgNz4rU3EC+Bw50IeOyLiU7jUhN/rvzrdf9YTJa1BwyAXD3F
2R0uTtlOVuNdzYVAqLHkzy0hX82jtYz+mUf+aI/D8gDL76J8q8x7sFMqvWrPu2On
S6mlG53y9vq4G2WNJwpBaSe/vKFQTl
libytnef_1.5-9_amd64.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 22 Aug 2015 11:10:24 +0200 Source: libytnef Binary: libytnef0 libytnef0-dev Architecture: source amd64 Version: 1.5-9 Distribution: unstable Urgency: medium Maintainer: Debian QA Group Changed-By: Ricardo Mones Description: libytnef0 - improved decoder for application/ms-tnef attachments libytnef0-dev - headers for application/ms-tnef attachments decoder Closes: 742146 Changes: libytnef (1.5-9) unstable; urgency=medium . * QA upload. * Add patch to fix FTBFS with clang. Closes: #742146. Checksums-Sha1: 0225a4ac224b2497c5929ff5b4739f0e62421cda 1782 libytnef_1.5-9.dsc dcc8a55172f4ac4fa8b09ce7d90794b90d0c2806 218724 libytnef_1.5-9.debian.tar.xz 2742cd7e75a910a16a6292cb2d8cd02306352134 24122 libytnef0-dev_1.5-9_amd64.deb 49ae20bea4d624150cf9c217881c47e018f9e501 20074 libytnef0_1.5-9_amd64.deb Checksums-Sha256: a060397a803ebac89e87776d7b5cf240b8a5711edaa810bb49a601f0115b0427 1782 libytnef_1.5-9.dsc 70fa86e9bddc2f4cf394ea8f39a2aa21b4a0a5e6fcad12550df06bf5f7a44d11 218724 libytnef_1.5-9.debian.tar.xz 9ddbbe32e0f33126b6773fb243931b12f421b4bd0a7c12f769c609602b957c12 24122 libytnef0-dev_1.5-9_amd64.deb 04819b0b79e16f361f81397630c4a5551fabd22da3ab4c46ab204a0e013e4aad 20074 libytnef0_1.5-9_amd64.deb Files: f12aa06c0b2653085cf7d5819e058a7c 1782 utils extra libytnef_1.5-9.dsc 1b5409ae94addade0c03fbd4e205d407 218724 utils extra libytnef_1.5-9.debian.tar.xz f2b147c4f6768bff3481f7bda033ecf8 24122 libdevel extra libytnef0-dev_1.5-9_amd64.deb fda886f365fca5a91181983ebf3c967f 20074 libs extra libytnef0_1.5-9_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJV2D3bAAoJEB8PCojeW8ymW+gP/RWt9qxKKN1lqTydZimf9r70 TedNkJ6CiNmJRykc/evdCQfq1Er2b9o7GUEKbbjl7Az+tkXMK5mdVFFhpx0USDMy q1++m3+UM3p1pNB/qomR/BCxnuP/VbINmZ4daO4HnoE0CUIaBFX2D8kMJA7sg5Cp Fqh50Ctvfhb9nODMs4Y07qrKDGmRNg6eZujLxpHrSMAzsPy8ca3/E9F+hFlNHe5S ykpQsy1y0nYYQgpc8l2jY0nqWrEOIPxOc2YqRtVOVCNfoULMuHuJn3VZ/xUu++OZ nQUk4q70lZl2FADQfgNz4rU3EC+Bw50IeOyLiU7jUhN/rvzrdf9YTJa1BwyAXD3F 2R0uTtlOVuNdzYVAqLHkzy0hX82jtYz+mUf+aI/D8gDL76J8q8x7sFMqvWrPu2On S6mlG53y9vq4G2WNJwpBaSe/vKFQTlD1wszVJ4AaL5JdhuMBXjoYxyM3j74vjdhR atb+v4hz5r6Ubdxr/pk4w2wiqBsKzAcJnBNyyfBL1+3oGxnOFcMEJPzGPpQoDxwB VBzVSZIFM+Cjh/VGm4e6YY2NxrkBfu+mvZFVfuLtvT06l5/Q6msg/l++VS7Bd5hY TUSdLaL51yao2WFEqo2pD2Yt99V6xMxgW33/kz7ndLyM96ohRwnv7b8+Da0XLjbf Zf2CYjS/0B66mSUkrW7m =xgF7 -END PGP SIGNATURE- Thank you for your contribution to Debian.
Bug#796483: Removed package(s) from unstable
Version: 0.99.3-4+rm Dear submitter, as the package colrconv has just been removed from the Debian archive unstable we hereby close the associated bug reports. We are sorry that we couldn't deal with your issue properly. For details on the removal, please see https://bugs.debian.org/796483 The version of this package that was in Debian prior to this removal can still be found using http://snapshot.debian.org/. This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org. Debian distribution maintenance software pp. Scott Kitterman (the ftpmaster behind the curtain)
Bug#796483: Removed package(s) from unstable
We believe that the bug you reported is now fixed; the following package(s) have been removed from unstable: colrconv | 0.99.3-4 | source, amd64, arm64, armel, armhf, i386, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, ppc64el, s390x colrconv | 0.99.3-4+b1 | hurd-i386 --- Reason --- RoQA; abandoned upstream; buggy -- Note that the package(s) have simply been removed from the tag database and may (or may not) still be in the pool; this is not a bug. The package(s) will be physically removed automatically when no suite references them (and in the case of source, when no binary references it). Please also remember that the changes have been done on the master archive and will not propagate to any mirrors until the next dinstall run at the earliest. Packages are usually not removed from testing by hand. Testing tracks unstable and will automatically remove packages which were removed from unstable when removing them from testing causes no dependency problems. The release team can force a removal from testing if it is really needed, please contact them if this should be the case. We try to close bugs which have been reported against this package automatically. But please check all old bugs, if they were closed correctly or should have been re-assigned to another package. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 796...@bugs.debian.org. The full log for this bug can be viewed at https://bugs.debian.org/796483 This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org. Debian distribution maintenance software pp. Scott Kitterman (the ftpmaster behind the curtain)
Bug#796472: zshdb: update to latest upstream 0.09
Package: zshdb Followup-For: Bug #796472 Control: notforwarded -1 Hi, The problems with the tests that have been seen are a bug in zsh, not a bug in the upstream zshdb project. From #pkg-zsh: ft ╡ I bet this is caused by what is fixed in 35412 ∟ ╡ zsh-workers reference number that is. ∟ ╡ http://www.zsh.org/mla/workers/2015/msg01336.html ∟ ╡ So that's fixed upstream already. ∟ ╡ There are talks about a 5.1 release in the immediate future. I'll pick this up once again after this has been fixed in the zsh package. Thanks, Iain. -- e: i...@fsfe.orgw: iain.learmonth.me x: i...@jabber.fsfe.org t: EPVPN 2105 c: 2M0STB g: IO87we p: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49 pgpLWDXxtl57F.pgp Description: PGP signature
Processed: Re: zshdb: update to latest upstream 0.09
Processing control commands: > notforwarded -1 Bug #796472 [zshdb] zshdb: update to latest upstream 0.09 Unset Bug forwarded-to-address -- 796472: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796472 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#796588: adjtimex: Has init script in runlevel S but no matching service file
Package: adjtimex Severity: important User: pkg-systemd-maintain...@lists.alioth.debian.org Usertags: init-rcs-service Hi, Your package adjtimex has an initscript that is enabled in runlevel S, but it does not provide a corresponding systemd service unit. Systemd generates units for all sysv init scripts that do not have a corresponding systemd unit. By default, it sets DefaultDependencies=yes, which means they get ordered after early boot has finished. The problem is that to preserve the runlevel S semantics, systemd in debian is currently[1] ordering all S services Before=sysinit.target. This target is particularly early in the boot sequence, which means that it is most of the time too strict. In turn, this means it is fairly easy to end up with dependency cycles. For an example, see bug [763315]. Do note that the cycle still exists with sysvinit, it is just that systemd complains more loudly. Please add a systemd unit for the given service with the appropriate dependencies, which most of the time will be less strict than Before=sysinit.target. In other cases, the script is simply not applicable in systemd, in which case the package should ship a symlink to /dev/null as /lib/systemd/system/.service. We have prepared a transition wiki page[2] explaining the issue in more detail, and outlining some general guidance. Please refer to it as it will have useful information. If you have any other doubts, feel free to ask in pkg-systemd-maintain...@lists.alioth.debian.org -- [1] http://sources.debian.net/src/systemd/222-2/debian/patches/Add-support-for-rcS.d-init-scripts-to-the-sysv-gener.patch/ [763315] https://bugs.debian.org/763315 [2] https://wiki.debian.org/Teams/pkg-systemd/rcSMigration
Bug#796630: rdnssd: Has init script in runlevel S but no matching service file
Package: rdnssd Severity: important User: pkg-systemd-maintain...@lists.alioth.debian.org Usertags: init-rcs-service Hi, Your package rdnssd has an initscript that is enabled in runlevel S, but it does not provide a corresponding systemd service unit. Systemd generates units for all sysv init scripts that do not have a corresponding systemd unit. By default, it sets DefaultDependencies=yes, which means they get ordered after early boot has finished. The problem is that to preserve the runlevel S semantics, systemd in debian is currently[1] ordering all S services Before=sysinit.target. This target is particularly early in the boot sequence, which means that it is most of the time too strict. In turn, this means it is fairly easy to end up with dependency cycles. For an example, see bug [763315]. Do note that the cycle still exists with sysvinit, it is just that systemd complains more loudly. Please add a systemd unit for the given service with the appropriate dependencies, which most of the time will be less strict than Before=sysinit.target. In other cases, the script is simply not applicable in systemd, in which case the package should ship a symlink to /dev/null as /lib/systemd/system/.service. We have prepared a transition wiki page[2] explaining the issue in more detail, and outlining some general guidance. Please refer to it as it will have useful information. If you have any other doubts, feel free to ask in pkg-systemd-maintain...@lists.alioth.debian.org -- [1] http://sources.debian.net/src/systemd/222-2/debian/patches/Add-support-for-rcS.d-init-scripts-to-the-sysv-gener.patch/ [763315] https://bugs.debian.org/763315 [2] https://wiki.debian.org/Teams/pkg-systemd/rcSMigration
Bug#796635: nvi: Has init script in runlevel S but no matching service file
Package: nvi Severity: important User: pkg-systemd-maintain...@lists.alioth.debian.org Usertags: init-rcs-service Hi, Your package nvi has an initscript that is enabled in runlevel S, but it does not provide a corresponding systemd service unit. Systemd generates units for all sysv init scripts that do not have a corresponding systemd unit. By default, it sets DefaultDependencies=yes, which means they get ordered after early boot has finished. The problem is that to preserve the runlevel S semantics, systemd in debian is currently[1] ordering all S services Before=sysinit.target. This target is particularly early in the boot sequence, which means that it is most of the time too strict. In turn, this means it is fairly easy to end up with dependency cycles. For an example, see bug [763315]. Do note that the cycle still exists with sysvinit, it is just that systemd complains more loudly. Please add a systemd unit for the given service with the appropriate dependencies, which most of the time will be less strict than Before=sysinit.target. In other cases, the script is simply not applicable in systemd, in which case the package should ship a symlink to /dev/null as /lib/systemd/system/.service. We have prepared a transition wiki page[2] explaining the issue in more detail, and outlining some general guidance. Please refer to it as it will have useful information. If you have any other doubts, feel free to ask in pkg-systemd-maintain...@lists.alioth.debian.org -- [1] http://sources.debian.net/src/systemd/222-2/debian/patches/Add-support-for-rcS.d-init-scripts-to-the-sysv-gener.patch/ [763315] https://bugs.debian.org/763315 [2] https://wiki.debian.org/Teams/pkg-systemd/rcSMigration
