Bug#753442: debootstrap: host's /run/shm gets unmounted after debootstrap run

[Cyril Brulebois]

Petter Reinholdtsen  (2014-11-23):
> Control: notfound -1 1.0.51
> 
> Probably a good idea to make BTS aware of when this issue was fixed.

notfound != fixed.

> Not sure if it should be closed or if an stable update is needed, so I
> leave it open.

Figuring it out is the plan:
  https://lists.debian.org/20141106161851.ge25...@mraw.org

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#770647: marked as done (double free in libclamunrar_iface + memory leak in read_block())

[Debian Bug Tracking System]

Your message dated Sun, 23 Nov 2014 05:18:46 +
with message-id 
and subject line Bug#770647: fixed in libclamunrar 0.98.5-1
has caused the Debian Bug report #770647,
regarding double free in libclamunrar_iface + memory leak in read_block()
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.)


-- 
770647: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770647
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libclamunrar
Version: 0.96.4-1
Severity: serious
Tags: security pending

The debian security tracker references a problem ("clamav: double-free
error libclamunrar_iface/unrar_iface.c") which it learned from
http://www.openwall.com/lists/oss-security/2013/11/29/6
This got marked as fixed in Debian because the Clamav version we use a
high enough version. However the file / part of code is not used from
the clamav package but from the libclamunrar package instead. It is
split into another package due to the non-free license of the unrar code.

To double check, the report mentions the file unrar_iface.c. If you
check the buildlog of the clamav package you won't find it together with
gcc. If you check libclamunrar's buildlog then you will see it. Also if
you check libclamunrar_iface.so.6.1.20 you will find the function named
libclamunrar_iface_LTX_unrar_extract_next_prepare which is part of the
libclamunrar package.

To conclude: this problem as such is still not fixed in Wheezy.
The only clamunrar related change between 0.98.1-1 and 0.98.5-1 is a
memory leak fix in read_block(). For that reason and to keep it in sync
with the clamav package I would prefer to have the 0.98.5 version in Wheezy.

Sebastian
--- End Message ---
--- Begin Message ---
Source: libclamunrar
Source-Version: 0.98.5-1

We believe that the bug you reported is fixed in the latest version of
libclamunrar, 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 770...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Sebastian Andrzej Siewior  (supplier of updated 
libclamunrar 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 Nov 2014 22:25:35 +0100
Source: libclamunrar
Binary: libclamunrar6
Architecture: source i386
Version: 0.98.5-1
Distribution: unstable
Urgency: medium
Maintainer: ClamAV Team 
Changed-By: Sebastian Andrzej Siewior 
Description:
 libclamunrar6 - anti-virus utility for Unix - unrar support
Closes: 770647
Changes:
 libclamunrar (0.98.5-1) unstable; urgency=medium
 .
   [ Sebastian Andrzej Siewior ]
   * Update to new upstream version.
 - Finaly address "double-free error exists within the
   unrar_extract_next_prepare()" (Closes: #770647)
   * Drop automake workaround, the bug was fixed.
   * Fix LFS support using the same approach as clamav for compatibility and
 correctness
 .
   [ Scott Kitterman ]
   * Add build-dep on libssl-dev, needed for configure even if not used
 in libclamunrar
   * Update debian/copyright to add openssl exception per COPYING
Checksums-Sha1:
 e838e38e561a3138ab232591247d37cb1b81f1c6 2124 libclamunrar_0.98.5-1.dsc
 6d4a3441e142002ffdaa76ad313bc018985e1999 304828 libclamunrar_0.98.5.orig.tar.xz
 66ac3c83ff3fe33d471862f399f5d1e96c09d749 4676 
libclamunrar_0.98.5-1.debian.tar.xz
 451fd25e0b73e90d002b61b1fbd02f698379217d 33906 libclamunrar6_0.98.5-1_i386.deb
Checksums-Sha256:
 2bc9a40a08dcad1c2a45964165cf4d41685d89fba817836a0eb0750a483eb595 2124 
libclamunrar_0.98.5-1.dsc
 3d957d584bee260f11c7b5b211899c4cacfc3849b1d0485b3f21eb2d4aac 304828 
libclamunrar_0.98.5.orig.tar.xz
 ad8fe1d1b895d2779ce0be4c469d971ec66fce0876ccad31a8a13af44cd01553 4676 
libclamunrar_0.98.5-1.debian.tar.xz
 7c8641cb9bb064fea19e59a5a3dd68a1ead0a1c013d18d020c3a8eb3ca91b326 33906 
libclamunrar6_0.98.5-1_i386.deb
Files:
 f9df12c8f3adf55a228da6b856d13c28 2124 non-free/libs extra 
libclamunrar_0.98.5-1.dsc
 ecd3acdec22118338d3d5fbe41fba011 304828 non-free/libs extra 
libclamunrar_0.98.5.orig.tar.xz
 82f622806aff1d1b07d02afd7be9fad0 4676 non-free/libs extra 
libclamunrar_0.98.5-1.debian.tar.xz
 7ecd162969323c59d7bde3b9ee374b5b 33906 non-free/libs extra 
libclamunrar6_0.98.5-1_i386.deb

-BEGIN PGP S

Bug#766670: Security fix without feature enhancement for 4.32.0 and 4.20.0

[Charles Cazabon]

Osamu Aoki  wrote:
> On Sat, Nov 22, 2014 at 01:30:41PM -0600, Charles Cazabon wrote:
> > 
> > As Linus Torvalds says, there's no real difference between "bugfix" and
> > "security fix", and I would argue there's almost as little difference
> > between "bugfix" and "new feature".
> 
> If you added an unrelated HTTP-server feature to getmail for the remote
> configuration, I call it a feature changes (, enhancement, bloat, or
> ...).

Yes.  I note I should have been more specific with the above: I meant
specifically in regards to getmail in its "mature" state, where pretty much
the only changes going in are bugfixes and minor feature enhancements, which
are difficult to distinguish between.

> > I don't think you need to drop *anything*.  getmail hasn't had much in
> > the way of new features in many years, and I try to maintain
> > compatibility as much as is practical.  Just update to the latest
> > version.
> 
> Thank you.

I hope Debian can simply accept the newer version of getmail; as I said, I try
very hard to keep it compatible when things like the additional SSL
certificate options were added, and getmail v.4 by itself is more than ten
years old at this point, long into its quiescent "adult" period as far as
software goes ;)

Charles
-- 
---
Charles Cazabon
GPL'ed software available at:   http://pyropus.ca/software/
---


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#769301: java3d: FTBFS error: unknown type name 'GLintptr'

[tony mancill]

On 11/22/2014 03:34 PM, Markus Koschany wrote:
> tags 769301 patch
> severity 765933 important
> thanks
> 
> On Wed, 12 Nov 2014 16:57:45 +0100 Markus Koschany  wrote:
> [...]
>> apparently bug #765933 in mesa causes a FTBFS in java3d. I think this is
>> a regression and easier to fix in mesa itself during the freeze instead
>> of patching affected packages.
> 
> At a second glance fixing Java3d was easier than expected. We just
> define the typedefs in Java3d. However I still think this is a bug in
> mesa-common-dev but not necessarily a release-critical one. I am
> downgrading #765933 to important again.
> 
> Please find the proposed patch attached to this bug report.

Hi Markus,

Thank you for the patch.  I have uploaded the package, including a few
packaging updates I had already pushed to the packaging repo.  I will
file an unblock request.

Cheers,
tony




signature.asc
Description: OpenPGP digital signature

Bug#769301: marked as done (java3d: FTBFS error: unknown type name 'GLintptr')

[Debian Bug Tracking System]

Your message dated Sun, 23 Nov 2014 03:35:04 +
with message-id 
and subject line Bug#769301: fixed in java3d 1.5.2+dfsg-10
has caused the Debian Bug report #769301,
regarding java3d: FTBFS error: unknown type name 'GLintptr'
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.)


-- 
769301: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769301
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: java3d
Version: 1.5.2+dfsg-4
Severity: important

Hi,

that's another FTBFS on armel:
| dh_installdirs -plibjava3d-jni 
| install -m 644 -D j3d-core/build/default/opt/native/libj3dcore-ogl.so \
|   debian/libjava3d-jni/usr/lib/jni/libj3dcore-ogl.so
| install: cannot stat `j3d-core/build/default/opt/native/libj3dcore-ogl.so': 
No such file or directory
| make: *** [install/libjava3d-jni] Error 1
| dpkg-buildpackage: error: /usr/bin/fakeroot debian/rules binary-arch gave 
error exit status 2

Logs still at:
  https://buildd.debian.org/status/package.php?suite=unstable&p=java3d

Mraw,
KiBi.


--- End Message ---
--- Begin Message ---
Source: java3d
Source-Version: 1.5.2+dfsg-10

We believe that the bug you reported is fixed in the latest version of
java3d, 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 769...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Markus Koschany  (supplier of updated java3d 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: SHA512

Format: 1.8
Date: Sun, 23 Nov 2014 00:10:37 +0100
Source: java3d
Binary: libjava3d-java libjava3d-jni libjava3d-java-doc
Architecture: source all amd64
Version: 1.5.2+dfsg-10
Distribution: unstable
Urgency: medium
Maintainer: Debian Java Maintainers 

Changed-By: Markus Koschany 
Description:
 libjava3d-java - Java 3D API (java library)
 libjava3d-java-doc - Documentation for the Java3D API
 libjava3d-jni - Java3D API (java jni library)
Closes: 758413 769301
Changes:
 java3d (1.5.2+dfsg-10) unstable; urgency=medium
 .
   * Team upload.
 .
   [ tony mancill ]
   * Updated Standards-Version to 3.9.6 (no changes)
   * Update Upstream URL in d/control and d/copyright. (Closes: #758413)
   * Use canonical Vcs URLs for packaging repo.
   * Use debhelper 9.
 .
   [ Markus Koschany ]
   * Add typedef.patch. Define GLsizeiptr and GLintptr explicitly to
 prevent a FTBFS. (Closes: #769301)
Checksums-Sha1:
 954713425cc9edda4f7aaf689908431bb586796f 2243 java3d_1.5.2+dfsg-10.dsc
 003e47595fd191a352ebb2759fc4a7ff9fe34cd6 10196 
java3d_1.5.2+dfsg-10.debian.tar.xz
 02081421e0916e3e4ccbf352dc90e4c1b62bcbb2 1084290 
libjava3d-java_1.5.2+dfsg-10_all.deb
 bfdfb1d405915a88aa00fa549f407a7ff3ded4a3 877734 
libjava3d-java-doc_1.5.2+dfsg-10_all.deb
 9e03408dc10c3f76cf376505652c23bb8a4cb36b 43986 
libjava3d-jni_1.5.2+dfsg-10_amd64.deb
Checksums-Sha256:
 50ef29855d58d9bf9dee7e84159a143446e4c1c7e4cb6b4653ae8e2fb8d0bd38 2243 
java3d_1.5.2+dfsg-10.dsc
 fc4d70b368ce5f92e8510e1be1e114b74f0c97167cae9dfa9e985b7469b520ae 10196 
java3d_1.5.2+dfsg-10.debian.tar.xz
 9935a3daec3955158e65f1324ed83deac0479857e047ee3631824a23f579b90a 1084290 
libjava3d-java_1.5.2+dfsg-10_all.deb
 d6f66803ad5ef99ce6d0c9e21476cb17c8a9a6a3051888f6f7d4ff890bed679b 877734 
libjava3d-java-doc_1.5.2+dfsg-10_all.deb
 b3555dd24a051cf1b6e972c3cee98b4d4d49f33ea930ad21ac312f8272b4f4fb 43986 
libjava3d-jni_1.5.2+dfsg-10_amd64.deb
Files:
 28f10d4e014bf4f201cffc6630b6c8ef 2243 java optional java3d_1.5.2+dfsg-10.dsc
 8c5496b9eb9379fe75242c93bc483ea7 10196 java optional 
java3d_1.5.2+dfsg-10.debian.tar.xz
 cdedd0feb5a754d5c5b90cdb2943dab0 1084290 java optional 
libjava3d-java_1.5.2+dfsg-10_all.deb
 314ca9837a0221f5ca5c6d9e100d56ca 877734 doc optional 
libjava3d-java-doc_1.5.2+dfsg-10_all.deb
 1a7e2695e7c9e9b862f5be34a206ba07 43986 java optional 
libjava3d-jni_1.5.2+dfsg-10_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJUcVHiAAoJECHSBYmXSz6W94EP/iSbXp+wTx8ohi1KwgCbXIbI
AjwHoU+B/MhQEG0opYdf63ARm7piWHhiZu6ZtORkBzxSgjZrqJ+eVJY2i+3uN8nC
DiyAKI2v2y2BsNg7wpm0/kaHrl9Mc6Sr2bI271rXm1kFVBfFh5cRqRlMk2Nis70f
TF+5IwEJgK+vgHyT6qjRc/3Q9mWVEPiAgPGvLFZXJ0oXDw78DM5SOF+MDzyXA+Yz
pd8DMXGKMp9ZvfuJ/sn3M3H9O4IaaFRXyAkvGnxwSGCEXy/H1g9xezhm

Bug#769191: Bug#769072: #769191: nvidia-opencl-icd breaking non-nvidia systems

[Andreas Beckmann]

On 2014-11-23 00:30, Rebecca N. Palmer wrote:
> I think the trigger is nvidia-opencl-icd adding a new dependency on
> libcuda1 (changelog: Add libcuda1 dependency to libraries that seem to
> be capable of doing dlopen("libcuda.so") or dlopen("libcuda.so.1").),
> which pulls in the rest of nvidia-* as libcuda1 Recommends:
> nvidia-kernel-dkms which Recommends: nvidia-driver.

Damn, ensuring that there are proper dependencies for all the NVIDIA
packages breaks (well, sort of breaks) the upgrade in case
nvidia-opencl-icd was installed in wheezy for no good reason ...

I've now prepared two changes in SVN (n-g-d branches/jessie):

nvidia-graphics-drivers (340.46-6) UNRELEASED; urgency=medium

  * nvidia-kernel-dkms: Switch to Recommends: nvidia-driver | libcuda1
to break the chain libcuda1 -> nvidia-kernel-dkms -> nvidia-driver.
  * nvidia-opencl-icd: Downgrade the Depends: libcuda1 to Suggests. This
should avoid pulling in too many NVIDIA packages on wheezy -> jessie
upgrades of systems that have no NVIDIA hardware, but nvidia-opencl-icd
installed nevertheless.  (Closes: #769072, #770588, #769191)

In upgrade tests in minimal wheezy chroots with nvidia-opencl-icd
installed that seemed to work and did no longer pull nvidia-driver into
the system.

I don't know how seriously the missing libcuda1 breaks
nvidia-opencl-icd. I can see that this is being dlopen()ed, but at least
clinfo still reports something about the GPU. I don't have a better
testcase right now, suggestions welcome.

A more proper solution could be to rename nvidia-opencl-icd to e.g.
nvidia-icd and add an empty nvidia-opencl-icd package that only
Suggests: nvidia-icd. That would prevent inadvertent "users" of
nvidia-opencl-icd from getting anything new from the nvidia stack but
everyone who really wants to use nvidia-icd would have to install it
manually.
(but we could Recommend it from nvidia-opencl-dev
(src:nvidia-cuda-toolkit)).

Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#768905: FTBFS: fails test "CHECK INVALID KEY TYPE"

[Adam Borowski]

On Sun, Nov 23, 2014 at 02:07:42AM +0100, Christian Kastner wrote:
> On 2014-11-23 01:16, Adam Borowski wrote:
> > On Sat, Nov 22, 2014 at 09:09:55PM +0100, Tomasz Buchert wrote:
> >> On 10/11/14 10:56, Christian Kastner wrote:
> >> I cannot confirm this bug in both cases I've tried:
> >>
> >>   * amd64 (Linux 3.14-2-amd64 #1 SMP Debian 3.14.15-2 (2014-08-09) x86_64 
> >> GNU/Linux)
> >>   * amrhf (Linux 3.14.4.1-bone-armhf.com #1 SMP Tue Jun 3 12:37:22 UTC 
> >> 2014 armv7l GNU/Linux)
> > 
> > My tests:
> > armhf 3.8.13.28: FTBFS
> 
> Was this either a Debian or a vanilla kernel? I ask because 3.8 kernels
> are often vendor-provided variants of certain ARM devices.

I have heard myths of ARM devices that can run upstream kernels, but I have
yet to see one :p.  This one is git://github.com/hardkernel/linux, a pretty
well behaved one as vendor kernels go.

(They can go bad.  Really bad.  Let's not speak about test results on my
laptop that needs a 3.0 kernel for which the vendor doesn't even provide
source, with a config written by a deranged monkey.)

> > amd64 Debian 3.16.3: builds ok
> > amd64 vanilla 3.16.7: builds ok
> > amd64 vanilla 3.17.3: FTBFS
> 
> I'll try to reproduce the 3.17 FTBFS with Debian's version in
> experimental, and the vanilla version.

I just tried: Debian experimental 3.17-1 FTBFSes on my machine.


-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#768905: FTBFS: fails test "CHECK INVALID KEY TYPE"

[Christian Kastner]

Control: tag -1 +confirmed -unreproducible

On 2014-11-23 01:16, Adam Borowski wrote:
> amd64 vanilla 3.16.7: builds ok
> amd64 vanilla 3.17.3: FTBFS

I can confirm that is issue exists with 3.17.

The syscall is returning ENOKEY where until 3.16 it was returning EPERM.

I'll try to investigate the cause tomorrow, and reassign to the
src:linux once I have located it. Either way, this shouldn't be a
problem for Jessie where we will have 3.16.

Regards,
Christian


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Processed: Re: Bug#768905: FTBFS: fails test "CHECK INVALID KEY TYPE"

[Debian Bug Tracking System]

Processing control commands:

> tag -1 +confirmed -unreproducible
Bug #768905 [src:keyutils] FTBFS: fails test "CHECK INVALID KEY TYPE"
Added tag(s) confirmed.
Bug #768905 [src:keyutils] FTBFS: fails test "CHECK INVALID KEY TYPE"
Removed tag(s) unreproducible.

-- 
768905: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768905
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#766670: RC bug in stable and oldstable for getmail4

[Henrique de Moraes Holschuh]

On Sun, 23 Nov 2014, Osamu Aoki wrote:
> By the way, I uploaded getmail4_4.46.0-1~bpo70+1_amd64
> 
> https://ftp-master.debian.org/new/getmail4_4.46.0-1~bpo70%2B1.html
> 
> What do I have to do to get it pushed to backports?  Did I have to
> upload it to another server?  I do not know why it is stack there.  I

No, now you just have to wait.  It works just as in unstable.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#768905: FTBFS: fails test "CHECK INVALID KEY TYPE"

[Christian Kastner]

On 2014-11-23 01:16, Adam Borowski wrote:
> On Sat, Nov 22, 2014 at 09:09:55PM +0100, Tomasz Buchert wrote:
>> On 10/11/14 10:56, Christian Kastner wrote:
>> I cannot confirm this bug in both cases I've tried:
>>
>>   * amd64 (Linux 3.14-2-amd64 #1 SMP Debian 3.14.15-2 (2014-08-09) x86_64 
>> GNU/Linux)
>>   * amrhf (Linux 3.14.4.1-bone-armhf.com #1 SMP Tue Jun 3 12:37:22 UTC 2014 
>> armv7l GNU/Linux)
> 
> My tests:
> armhf 3.8.13.28: FTBFS

Was this either a Debian or a vanilla kernel? I ask because 3.8 kernels
are often vendor-provided variants of certain ARM devices.

> amd64 Debian 3.16.3: builds ok
> amd64 vanilla 3.16.7: builds ok
> amd64 vanilla 3.17.3: FTBFS

I'll try to reproduce the 3.17 FTBFS with Debian's version in
experimental, and the vanilla version.


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#769557: education-common: package fails to upgrade properly from wheezy

[Don Armstrong]

On Sun, 23 Nov 2014, Holger Levsen wrote:

> Hi owner@bugs + listmasters,
> 
> any idea why #769557 (Message-ID: <20141114122853.ga11...@xanadu.blop.info>) 
> wasn't send to debian-...@lists.debian.org?

Nov 14 12:46:12 s_local@bendel postfix/smtp[22501]: A9DE96F5: 
to=, orig_to=, 
relay=127.0.0.1[127.0.0.1]:2525, delay=20, delays=2.2/0/0.01/18, dsn=2.0.0, 
status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued 
as DC49A6EE)
 
is it accepted by bendel (lists.debian.org)

And then it gets discarded by the mailing list because the message was
too large. I think the limit is 200K, and that message exceeds it.

-- 
Don Armstrong  http://www.donarmstrong.com

Vimes hated and despised the privileges of rank, but they had this to
be said for them: At least they meant that you could hate and despise
them in comfort.
 -- Terry Pratchett _The Fifth Elephant_ p111


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#770621: marked as done (ruby-twitter-text cannot be loaded)

[Debian Bug Tracking System]

Your message dated Sun, 23 Nov 2014 00:48:50 +
with message-id 
and subject line Bug#770621: fixed in ruby-twitter-text 1.10.0+gem-1
has caused the Debian Bug report #770621,
regarding ruby-twitter-text cannot be loaded
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.)


-- 
770621: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770621
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
package: ruby-twitter-text
version: 1.10.0-1
severity: grave

# irb
irb(main):001:0> require 'twitter-text'
Errno::ENOENT: No such file or directory @ rb_sysopen -
/usr/lib/ruby/test/twitter-text-conformance/tld_lib.yml
from /usr/lib/ruby/2.1.0/psych.rb:464:in `initialize'
from /usr/lib/ruby/2.1.0/psych.rb:464:in `open'
from /usr/lib/ruby/2.1.0/psych.rb:464:in `load_file'
from /usr/lib/ruby/vendor_ruby/twitter-text/regex.rb:29:in 
`'
from /usr/lib/ruby/vendor_ruby/twitter-text/regex.rb:8:in
`'
from /usr/lib/ruby/vendor_ruby/twitter-text/regex.rb:3:in `'
from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in
`require'
from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in
`require'
from /usr/lib/ruby/vendor_ruby/twitter-text.rb:21:in `block in '
from /usr/lib/ruby/vendor_ruby/twitter-text.rb:20:in `each'
from /usr/lib/ruby/vendor_ruby/twitter-text.rb:20:in `'
from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in
`require'
from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in
`require'
from (irb):1
from /usr/bin/irb:11:in `'
irb(main):002:0>



signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
Source: ruby-twitter-text
Source-Version: 1.10.0+gem-1

We believe that the bug you reported is fixed in the latest version of
ruby-twitter-text, 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 770...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Pirate Praveen  (supplier of updated ruby-twitter-text 
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 Nov 2014 22:33:44 +0530
Source: ruby-twitter-text
Binary: ruby-twitter-text
Architecture: source all
Version: 1.10.0+gem-1
Distribution: unstable
Urgency: medium
Maintainer: Hideki Yamane 
Changed-By: Pirate Praveen 
Description:
 ruby-twitter-text - library that does auto linking and extraction items in 
tweets
Closes: 770621
Changes:
 ruby-twitter-text (1.10.0+gem-1) unstable; urgency=medium
 .
   * Team upload.
   * Use gem file as upstream source (closes: #770621)
 - github tarball has missing files
   * Rebuild to include gemspec file (remove git usage).
   * Bump standards version to 3.9.6 (no changes).
Checksums-Sha1:
 beeae016e351af5e281ad3bafcbf2356ba79e20a 2013 
ruby-twitter-text_1.10.0+gem-1.dsc
 47eef7c82cc7ed425a272e6c285cbeea4edd7d89 41027 
ruby-twitter-text_1.10.0+gem.orig.tar.gz
 df8fb5ca2c5828592d7ff02eb450ab9b029b3dd0 2888 
ruby-twitter-text_1.10.0+gem-1.debian.tar.xz
 e70879c1bbfe17577764c2340cda2d6251c78fad 21248 
ruby-twitter-text_1.10.0+gem-1_all.deb
Checksums-Sha256:
 ebf52497c5f2f06531fd1ead42d8d1b6c280d1fe2b66fb188eaf3d5bf1ac69d7 2013 
ruby-twitter-text_1.10.0+gem-1.dsc
 56086cd6a2f2b98fad415a034fd9f1f696557cba0e33e3aa7be3eae2c5eeb1be 41027 
ruby-twitter-text_1.10.0+gem.orig.tar.gz
 c569d606afce2cc471c130faf7990e0ab8cb9f93a803f9a12d421a57a464dd2c 2888 
ruby-twitter-text_1.10.0+gem-1.debian.tar.xz
 52d4dc1f9cf9bd0fc85c3680e3fea01fdfcb46eb324a39b55da3b12e378fb8f9 21248 
ruby-twitter-text_1.10.0+gem-1_all.deb
Files:
 0d087ad19f40ad25d9fb7acb21e962a1 2013 ruby optional 
ruby-twitter-text_1.10.0+gem-1.dsc
 36778ad36c149f40f71f35cfca4e58eb 41027 ruby optional 
ruby-twitter-text_1.10.0+gem.orig.tar.gz
 6ab8b2acd0bdd45f9f344c04470ac046 2888 ruby optional 
ruby-twitter-text_1.10.0+gem-1.debian.tar.xz
 14ea9cb012ae7e39c62caa5b0ac9271a 21248 ruby optional 
ruby-twitter-text_1.10.0+gem-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUcSuMAAoJEM4fnGdFEsIqX1UP/2YTKWTYquD8E56G4Ns1c1qJ
IdgFVKwCAr5bp+XMGtXTUoiEYYwHzHw60u1ZrUS

Bug#767559: geoip-database-contrib: diff for NMU version 1.17+nmu1

[Johann Felix Soden]

Control: tags 767559 + patch
Control: tags 767559 + pending

Dear maintainer,

to solve the #767559 RC bug, I've prepared an NMU for geoip-database-contrib
(versioned as 1.17+nmu1) and uploaded it to DELAYED/5. 
It adds to debian/control Conflicts/Replaces/Provides:
geoip-database-extra.

Please feel free to tell me if I should delay it longer.

Best regards,
 Johann Felix

--
Johann Felix Soden, joh...@debian.org, DD
diff -Nru geoip-database-contrib-1.17/debian/changelog geoip-database-contrib-1.17+nmu1/debian/changelog
--- geoip-database-contrib-1.17/debian/changelog	2014-09-22 03:36:37.0 +0200
+++ geoip-database-contrib-1.17+nmu1/debian/changelog	2014-11-23 01:12:56.0 +0100
@@ -1,3 +1,11 @@
+geoip-database-contrib (1.17+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Provides/Conflicts/Replaces also new geoip-database-extra package 
+(Closes: #767559).
+
+ -- Johann Felix Soden   Sun, 23 Nov 2014 00:53:44 +0100
+
 geoip-database-contrib (1.17) unstable; urgency=low
 
   * Rename geoip-database-contrib_update to update-geoip-database
diff -Nru geoip-database-contrib-1.17/debian/control geoip-database-contrib-1.17+nmu1/debian/control
--- geoip-database-contrib-1.17/debian/control	2014-09-22 03:36:37.0 +0200
+++ geoip-database-contrib-1.17+nmu1/debian/control	2014-11-23 00:55:55.0 +0100
@@ -15,9 +15,9 @@
  ucf (>= 0.28),
  ${misc:Depends}
 Suggests: cron-daemon
-Provides: geoip-database
-Replaces: geoip-database
-Conflicts: geoip-database
+Provides: geoip-database, geoip-database-extra
+Replaces: geoip-database, geoip-database-extra
+Conflicts: geoip-database, geoip-database-extra
 Description: GeoLite binary database (downloader)
  GeoIP is a C library that enables the user to find the country that any IP
  address or hostname originates from. It uses a file-based database.

Processed: geoip-database-contrib: diff for NMU version 1.17+nmu1

[Debian Bug Tracking System]

Processing control commands:

> tags 767559 + patch
Bug #767559 [geoip-database-contrib] geoip-database-extra, 
geoip-database-contrib: error when trying to install together
Added tag(s) patch.
> tags 767559 + pending
Bug #767559 [geoip-database-contrib] geoip-database-extra, 
geoip-database-contrib: error when trying to install together
Added tag(s) pending.

-- 
767559: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767559
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#766670: RC bug in stable and oldstable for getmail4

[Osamu Aoki]

Hi,

By the way, I uploaded getmail4_4.46.0-1~bpo70+1_amd64

https://ftp-master.debian.org/new/getmail4_4.46.0-1~bpo70%2B1.html

What do I have to do to get it pushed to backports?  Did I have to
upload it to another server?  I do not know why it is stack there.  I
just used "dput".  In
https://qa.debian.org/developer.php?login=osamu&comaint=yes this
package is listed under new for testing/unstable.

Regards,

Osamu


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#769215: witty: diff for NMU version 3.3.3+dfsg-4.1

[Pau Garcia i Quiles]

Hello,

Please go ahead with the NMU.

Due to lack of public CC to me, I had not noticed the bugreport, that's why
I had not uploaded it myself.

Thank you




On Sun, Nov 23, 2014 at 1:04 AM, Sebastian Ramacher 
wrote:

> Control: tags 769215 + patch
> Control: tags 769215 + pending
>
> Dear maintainer,
>
> Andreas Stührk has prepared an NMU for witty (versioned as
> 3.3.3+dfsg-4.1) and I have uploaded it for him to DELAYED/2. Please feel
> free to tell me if I should delay it longer.
>
> Cheers
> --
> Sebastian Ramacher
>



-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

Bug#766670: Security fix without feature enhancement for 4.32.0 and 4.20.0

[Osamu Aoki]

Hi,

Thanks for your comment. (Charles is the upstream,)

On Sat, Nov 22, 2014 at 01:30:41PM -0600, Charles Cazabon wrote:
> Osamu Aoki  wrote:
> > 
> > In Debian, its security update policy prohibits any new feature added
> > with security updates.
> 
> It's kind of a bogus distinction.  As Linus Torvalds says, there's no real
> difference between "bugfix" and "security fix", and I would argue there's
> almost as little difference between "bugfix" and "new feature".

If you added an unrelated HTTP-server feature to getmail for the remote
configuration, I call it a feature changes (, enhancement, bloat, or
...).

> > There are needs for updating 4.32.0 and 4.20.0 for the MITM security
> > issues.  
> >  CVE-2014-7273
> >  CVE-2014-7274
> >  CVE-2014-7275
> 
> The changes in getmail to allow it to perform server SSL certificate
> validation and various other advanced SSL options: would you call
> those a new feature?  Because it clearly is.  

It is a boarder line case.

> But on the other hand, some people consider the previous behavior a
> bug, so perhaps its a bugfix.  But others say it closes a security
> hole, so it's a security fix.

I forward your insightful argument to the Debian security team.

> I see no way to make a clear-cut distinction between any of those three
> possibilities.

I concur.

> > I for one as being its maintainer in Debian see it theoretically
> > possible but am scared to make mistakes when dropping non-security fix
> > changes.
> 
> I don't think you need to drop *anything*.  getmail hasn't had much in
> the way of new features in many years, and I try to maintain
> compatibility as much as is practical.  Just update to the latest
> version.

Thank you.

Osamu


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#768905: FTBFS: fails test "CHECK INVALID KEY TYPE"

[Adam Borowski]

On Sat, Nov 22, 2014 at 09:09:55PM +0100, Tomasz Buchert wrote:
> On 10/11/14 10:56, Christian Kastner wrote:
> I cannot confirm this bug in both cases I've tried:
> 
>   * amd64 (Linux 3.14-2-amd64 #1 SMP Debian 3.14.15-2 (2014-08-09) x86_64 
> GNU/Linux)
>   * amrhf (Linux 3.14.4.1-bone-armhf.com #1 SMP Tue Jun 3 12:37:22 UTC 2014 
> armv7l GNU/Linux)

My tests:
armhf 3.8.13.28: FTBFS
amd64 vanilla 3.11.0: FTBFS
amd64 Debian 3.16.3: builds ok
amd64 vanilla 3.16.7: builds ok
amd64 vanilla 3.17.3: FTBFS

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#753442: debootstrap: host's /run/shm gets unmounted after debootstrap run

[Petter Reinholdtsen]

Control: notfound -1 1.0.51

Probably a good idea to make BTS aware of when this issue was fixed.
Not sure if it should be closed or if an stable update is needed, so I
leave it open.

-- 
Happy hacking
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#769557: education-common: package fails to upgrade properly from wheezy

[Holger Levsen]

Hi owner@bugs + listmasters,

any idea why #769557 (Message-ID: <20141114122853.ga11...@xanadu.blop.info>) 
wasn't send to debian-...@lists.debian.org?

+thanks for all your work on keeping the infrastructure running so nicely 
99,999% of the time! :-)


signature.asc
Description: This is a digitally signed message part.

Processed: Re: debootstrap: host's /run/shm gets unmounted after debootstrap run

[Debian Bug Tracking System]

Processing control commands:

> notfound -1 1.0.51
Bug #753442 [debootstrap] debootstrap: host's /run/shm gets unmounted after 
debootstrap run
Ignoring request to alter found versions of bug #753442 to the same values 
previously set

-- 
753442: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753442
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Processed: witty: diff for NMU version 3.3.3+dfsg-4.1

[Debian Bug Tracking System]

Processing control commands:

> tags 769215 + patch
Bug #769215 [src:witty] witty: FTBFS in jessie: Error parsing arguments in: 
AuthModel.js
Added tag(s) patch.
> tags 769215 + pending
Bug #769215 [src:witty] witty: FTBFS in jessie: Error parsing arguments in: 
AuthModel.js
Added tag(s) pending.

-- 
769215: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769215
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#769215: witty: diff for NMU version 3.3.3+dfsg-4.1

[Sebastian Ramacher]

Control: tags 769215 + patch
Control: tags 769215 + pending

Dear maintainer,

Andreas Stührk has prepared an NMU for witty (versioned as
3.3.3+dfsg-4.1) and I have uploaded it for him to DELAYED/2. Please feel
free to tell me if I should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -u witty-3.3.3+dfsg/debian/changelog witty-3.3.3+dfsg/debian/changelog
--- witty-3.3.3+dfsg/debian/changelog
+++ witty-3.3.3+dfsg/debian/changelog
@@ -1,3 +1,10 @@
+witty (3.3.3+dfsg-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Adapt uglifyjs parameters to new uglifyjs version (Closes: #769215).
+
+ -- Andreas Stührk   Sun, 23 Nov 2014 00:37:25 +0100
+
 witty (3.3.3+dfsg-4) unstable; urgency=medium
 
   * Fix FTBFS due to Doxygen 1.8.8-3 leaving a stale doxygen_sqlite3.db.
diff -u witty-3.3.3+dfsg/debian/rules witty-3.3.3+dfsg/debian/rules
--- witty-3.3.3+dfsg/debian/rules
+++ witty-3.3.3+dfsg/debian/rules
@@ -49,7 +49,7 @@
 
 MINIFIER=$(shell which uglifyjs)
 ifneq ($(MINIFIER),)
-  MINIFIER_FLAGS=-c --no-seqs -nc
+  MINIFIER_FLAGS=-c sequences=false
 else
   MINIFIER=/usr/bin/yui-compressor
   MINIFIER_FLAGS=--nomunge


signature.asc
Description: Digital signature

Bug#769557: education-common: package fails to upgrade properly from wheezy

[Petter Reinholdtsen]

I suspect this metapackage upgrade problem was triggered by bug #768600
fixed in readahead-fedora version 2:1.5.6-5.2.  If I got it right, it
was a problem exposed/triggered by a new dpkg version changing how
triggers were handled, and not really something we can fix in
education-common.

-- 
Happy hacking
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Processed: Re: Creepy: Plugins not working

[Debian Bug Tracking System]

Processing control commands:

> found -1 1.2~alpha-1
Bug #770591 [creepy] Creepy: Plugins not working
Marked as found in versions creepy/1.2~alpha-1.
> notfound -1 1.2~alpha
Bug #770591 [creepy] Creepy: Plugins not working
There is no source info for the package 'creepy' at version '1.2~alpha' with 
architecture ''
Unable to make a source version for version '1.2~alpha'
No longer marked as found in versions 1.2~alpha.

-- 
770591: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770591
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#770591: Creepy: Plugins not working

[Petter Reinholdtsen]

Control: found -1 1.2~alpha-1
Control: notfound -1 1.2~alpha

I suspect this only affect trying to change the plugin configuration,
which is required to add personal login credentials for flickr and
twitter (and perhaps instagram, but that plugin is missing a python
dependency too).

So if we could provide working plugin configuration in the package,
there would be less need to update the configuration to get the
searching and data extraction working.  Not sure if that is possible.

But I would very much welcome help creating patches for upstream to work
better as a Debian package.  I've pushed my patches upstream, but more
is needed. :)

-- 
Happy hacking
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#769191: xorg: apt-get dist-upgrade somehow reconfigured my system to use the nvidia driver, even though I have no nvidia hardware

[Nathaniel Smith]

I don't seem to have ever had pyopencl installed, so that can't be the culprit.

Looking through my apt history, it looks like the critical operation
that gave me nvidia stuff was the installation of libboost (!?):

Start-Date: 2014-06-01  13:05:09
Commandline: apt-get install libboost-all-dev
Install: libboost-timer-dev:amd64 (1.55.0.2, automatic),
libboost-coroutine-dev:amd64 (1.55.0.2, automatic),
libboost-thread-dev:amd64 (1.55.0.2, automatic),
libboost-timer1.55-dev:amd64 (1.55.0+dfsg-1, automatic),
nvidia-libopencl1:amd64 (331.67-2, automatic),
libboost-chrono1.55.0:amd64 (1.55.0+dfsg-1, automatic),
libboost-log1.55-dev:amd64 (1.55.0+dfsg-1, automatic),
libboost-chrono1.55-dev:amd64 (1.55.0+dfsg-1, automatic),
libboost-math1.55-dev:amd64 (1.55.0+dfsg-1, automatic),
libboost-signals1.55.0:amd64 (1.55.0+dfsg-1, automatic),
libboost-tools-dev:amd64 (1.55.0.2, automatic),
libboost-signals1.55-dev:amd64 (1.55.0+dfsg-1, automatic),
libboost-wave-dev:amd64 (1.55.0.2, automatic),
libboost-context1.55-dev:amd64 (1.55.0+dfsg-1, automatic),
libboost-random1.55-dev:amd64 (1.55.0+dfsg-1, automatic),
libopenmpi-dev:amd64 (1.6.5-8, automatic), libboost-test-dev:amd64
(1.55.0.2, automatic), libboost1.55-tools-dev:amd64 (1.55.0+dfsg-1,
automatic), libboost-context-dev:amd64 (1.55.0.2, automatic),
libboost-mpi-python1.55-dev:
amd64 (1.55.0+dfsg-1, automatic),
openmpi-common:amd64 (1.6.5-8, automatic), libboost-python-dev:amd64
(1.55.0.2, automatic), libboost-context1.55.0:amd64 (1.55.0+dfsg-1,
automatic), nvidia-opencl-common:amd64 (331.67-2, automatic),
libboost-filesystem-dev:amd64 (1.55.0.2, automatic),
mpi-default-bin:amd64 (1.0.2+nmu1, automatic),
libboost-system1.55-dev:amd64 (1.55.0+dfsg-1, automatic),
libboost-graph1.55.0:amd64 (1.55.0+dfsg-1, automatic),
libpci-dev:amd64 (3.2.1-2, automatic), libboost-random1.55.0:amd64
(1.55.0+dfsg-1, automatic), libboost-math1.55.0:amd64 (1.55.0+dfsg-1,
automatic), libboost-mpi1.55-dev:amd64 (1.55.0+dfsg-1, automatic),
libboost-filesystem1.55.0:amd64 (1.55.0+dfsg-1, automatic),
libboost-all-dev:amd64 (1.55.0.2), libboost-program-options-dev:amd64
(1.55.0.2, automatic), libboost-system-dev:amd64 (1.55.0.2,
automatic), openmpi-bin:amd64 (1.6.5-8, automatic),
libboost-atomic1.55-dev:amd64 (1.55.0+dfsg-1, automatic),
libboost-exception1.55-dev:amd64 (1.55.0+dfsg-1, automatic),
libboost-random-dev:amd64 (1.55.0.2, automatic), libnuma1:amd64
(2.0.9~rc5-1, automatic), libboost-graph1.55-dev:amd64 (1.55.0+dfsg-1,
automatic), libboost-log-dev:amd64 (1.55.0.2, automatic),
libboost-test1.55.0:amd64 (1.55.0+dfsg-1, automatic),
libboost-dev:amd64 (1.55.0.2, automatic),
libboost-locale1.55-dev:amd64 (1.55.0+dfsg-1, automatic),
libboost1.55-dev:amd64 (1.55.0+dfsg-1, automatic),
libboost-program-options1.55.0:amd64 (1.55.0+dfsg-1, automatic),
libboost-chrono-dev:amd64 (1.55.0.2, automatic),
libboost-serialization1.55.0:amd64 (1.55.0+dfsg-1, automatic),
libboost-date-time-dev:amd64 (1.55.0.2, automatic),
nvidia-opencl-icd:amd64 (331.67-2, automatic),
libboost-graph-parallel1.55.0:amd64 (1.55.0+dfsg-1, automatic),
libboost-filesystem1.55-dev:amd64 (1.55.0+dfsg-1, automatic),
libboost-Tmpi-python-dev:amd64 (1.55.0.2, automatic),
libboost-python1.55-dev:amd64 (1.55.0+dfsg-1, automatic), libcr0:amd64
(0.8.5-2.1, automatic), libibverbs1:amd64 (1.1.8-1, automatic),
libhwloc-dev:amd64 (1.9-3, automatic), libboost-regex1.55-dev:amd64
(1.55.0+dfsg-1, automatic), libboost-signals-dev:amd64 (1.55.0.2,
automatic), libicu-dev:amd64 (52.1-3, automatic),
libboost-locale1.55.0:amd64 (1.55.0+dfsg-1, automatic),
libnvidia-compiler:amd64 (331.67-2, automatic), libibverbs-dev:amd64
(1.1.8-1, automatic), libboost-timer1.55.0:amd64 (1.55.0+dfsg-1,
automatic), libboost-date-time1.55-dev:amd64 (1.55.0+dfsg-1,
automatic), libboost-python1.55.0:amd64 (1.55.0+dfsg-1, automatic),
libboost-thread1.55.0:amd64 (1.55.0+dfsg-1, automatic),
libboost-wave1.55.0:amd64 (1.55.0+dfsg-1, automatic),
libboost-mpi-python1.55.0:amd64 (1.55.0+dfsg-1, automatic),
libboost-graph-parallel1.55-dev:amd64 (1.55.0+dfsg-1, automatic),
libtorque2:amd64 (2.4.16+dfsg-1.4, automatic),
libboost-test1.55-dev:amd64 (1.55.0+dfsg-1, automatic),
libboost-wave1.55-dev:amd64 (1.55.0+dfsg-1, automatic),
libboost-graph-dev:amd64 (1.55.0.2, automatic),
libboost-iostreams-dev:amd64 (1.55.0.2, automatic),
libboost-mpi-dev:amd64 (1.55.0.2, automatic),
libboost-iostreams1.55-dev:amd64 (1.55.0+dfsg-1, automatic),
libhwloc5:amd64 (1.9-3, automatic), libopenmpi1.6:amd64 (1.6.5-8,
automatic), libboost-program-options1.55-dev:amd64 (1.55.0+dfsg-1,
automatic), mpi-default-dev:amd64 (1.0.2+nmu1, automatic),
libhwloc-plugins:amd64 (1.9-3, automatic), libboost-regex1.55.0:amd64
(1.55.0+dfsg-1, automatic), libboost-math-dev:amd64 (1.55.0.2,
automatic), libboost-atomic1.55.0:amd64 (1.55.0+dfsg-1, automatic),
libboost-regex-dev:amd64 (1.55.0.2, automatic), icu-devtools:amd64
(52.1-3, automatic), libboost-log1.55.0:amd64 (1.55.0+dfsg-1,
automatic), libboost-coroutine1.55-d

Processed: java3d: FTBFS error: unknown type name 'GLintptr'

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 769301 patch
Bug #769301 [java3d] java3d: FTBFS error: unknown type name 'GLintptr'
Added tag(s) patch.
> severity 765933 important
Bug #765933 [mesa-common-dev] mesa-common-dev: glx.h should not include 
glxext.h when GL_GLEXT_LEGACY is defined
Severity set to 'important' from 'serious'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
765933: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765933
769301: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769301
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#766943: reassign 766943 to systemd

[Christoph Anton Mitterer]

Hey.

On Tue, 2014-11-11 at 20:01 +0100, Michael Biebl wrote: 
> We discussed this a bit more yesterday, and we came to the conclusion,
> that for jessie, it's probably the simplest solution, if we explicitly
> call "udevadm settle" in /etc/init.d/networking before it ifup's any
> devices.
> A "udevadm settle" will block, until all events in the udev event queue
> have been processed. This doesn't necessarily guarantee that all networ
> interfaces actuall do exist, it's behvaiour is more like the one in
> wheezy under sysvinit.
Well not a perfect long term solution... but for the moment perhaps
really an idea.



> Attached is a patch against /etc/init.d/networking.
> While we discussed yesterday, to only run "udevadm settle" if there are
> any auto interfaces, I changed it, to also cover allow-hotplug.
> I also changed the init script to handle allow-hotplug interfaces.
Which probably explains why with allow-hotplug, I no longer saw services
which couldn't bind to their respective addresses.

Doesn't that basically mak the ifup@.service useless?


> I'll followup with more details later.
okay...


> First, it would be great if you Christop could test this patch. Both
> using allow-hotplug and auto.
Done (with the v2 patch, of course). I did about 5-7 boots for each of
the two, the network always came up by "itself" (i.e. my cron script
never needed to repair things), and in both cases, it seemed that all
the services could bind to their addresses.


> P.S: The patch also has a downside, i.e. it will serialize early boot
> and make it slower.
Sure :-(


Thanks so far :)

Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#765933: java3d: FTBFS error: unknown type name 'GLintptr'

[Markus Koschany]

tags 769301 patch
severity 765933 important
thanks

On Wed, 12 Nov 2014 16:57:45 +0100 Markus Koschany  wrote:
[...]
> apparently bug #765933 in mesa causes a FTBFS in java3d. I think this is
> a regression and easier to fix in mesa itself during the freeze instead
> of patching affected packages.

At a second glance fixing Java3d was easier than expected. We just
define the typedefs in Java3d. However I still think this is a bug in
mesa-common-dev but not necessarily a release-critical one. I am
downgrading #765933 to important again.

Please find the proposed patch attached to this bug report.

Markus
diff -Nru java3d-1.5.2+dfsg/debian/changelog java3d-1.5.2+dfsg/debian/changelog
--- java3d-1.5.2+dfsg/debian/changelog  2013-05-27 14:47:41.0 +0200
+++ java3d-1.5.2+dfsg/debian/changelog  2014-11-23 00:22:20.0 +0100
@@ -1,3 +1,11 @@
+java3d (1.5.2+dfsg-10) unstable; urgency=medium
+
+  * Team upload.
+  * Add typedef.patch. Define GLsizeiptr and GLintptr explicitly to
+prevent a FTBFS. (Closes: #769301)
+
+ -- Markus Koschany   Sun, 23 Nov 2014 00:10:37 +0100
+
 java3d (1.5.2+dfsg-9) unstable; urgency=low
 
   * Team upload.
diff -Nru java3d-1.5.2+dfsg/debian/patches/series 
java3d-1.5.2+dfsg/debian/patches/series
--- java3d-1.5.2+dfsg/debian/patches/series 2013-05-27 14:47:41.0 
+0200
+++ java3d-1.5.2+dfsg/debian/patches/series 2014-11-23 00:22:20.0 
+0100
@@ -5,3 +5,4 @@
 05_pic_amd64.patch
 05_pic_i586.patch
 06_java-compat.patch
+typedef.patch
diff -Nru java3d-1.5.2+dfsg/debian/patches/typedef.patch 
java3d-1.5.2+dfsg/debian/patches/typedef.patch
--- java3d-1.5.2+dfsg/debian/patches/typedef.patch  1970-01-01 
01:00:00.0 +0100
+++ java3d-1.5.2+dfsg/debian/patches/typedef.patch  2014-11-23 
00:22:20.0 +0100
@@ -0,0 +1,27 @@
+From: Markus Koschany 
+Date: Sat, 22 Nov 2014 23:54:59 +0100
+Subject: typedef
+
+Define GLsizeiptr and GLintptr explicitly to prevent a FTBFS.
+This patch may be removed in the future when
+https://bugs.debian.org/765933 gets fixed.
+
+Bug: https://bugs.debian.org/769301
+Forwarded: no
+---
+ j3d-core/src/native/ogl/gldefs.h | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/j3d-core/src/native/ogl/gldefs.h 
b/j3d-core/src/native/ogl/gldefs.h
+index bf4434f..d20de17 100644
+--- a/j3d-core/src/native/ogl/gldefs.h
 b/j3d-core/src/native/ogl/gldefs.h
+@@ -65,6 +65,8 @@
+ #include 
+ #include 
+ 
++typedef ptrdiff_t GLsizeiptr;
++typedef ptrdiff_t GLintptr;
+ #include 
+ #include 
+ #ifdef Java3D_undef__glext_h_


signature.asc
Description: OpenPGP digital signature

Bug#764730: dh_systemd_start: un-escapes - in unit/directory names

[Ivo De Decker]

Control: severity -1 important

Hi,

On Fri, Oct 10, 2014 at 06:21:34PM +0200, Bernd Zeimetz wrote:
> On 10/10/2014 06:14 PM, Michael Biebl wrote: 
> > Do you have an example where this actually is a practical issue and not
> > just a theoretical one? I.e, which package makes use escaped unit names?
> > 
> 
> https://github.com/bzed/pkg-open-vm-tools/commit/1130d9e91b696f1a364ce6a73b84d2a2d41fcc1f
> 
> just not uploaded yeat because of this and other systemd-related issues...
> (which are not a bug in systemd, just an annoying thing).

As there is a workaround, this isn't really RC. Changing it could break
existing packages (and that would be RC). This certainly doesn't look like
something that should be changed for jessie.

Cheers,

Ivo


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Processed: Re: Bug#764730: dh_systemd_start: un-escapes - in unit/directory names

[Debian Bug Tracking System]

Processing control commands:

> severity -1 important
Bug #764730 [dh-systemd] dh_systemd_start: un-escapes - in unit/directory names
Severity set to 'important' from 'serious'

-- 
764730: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764730
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#769191: #769072,#769191: nvidia-opencl-icd breaking non-nvidia systems

[Rebecca N. Palmer]

I think the trigger is nvidia-opencl-icd adding a new dependency on 
libcuda1 (changelog: Add libcuda1 dependency to libraries that seem to 
be capable of doing dlopen("libcuda.so") or dlopen("libcuda.so.1").), 
which pulls in the rest of nvidia-* as libcuda1 Recommends: 
nvidia-kernel-dkms which Recommends: nvidia-driver.



Next question, why did you have nvidia-opencl-icd in the first place?
I suspect the answer is probably https://bugs.debian.org/739176
which has already been fixed.


It can't be pyopencl if it's still installed (that now Depends: 
libopencl-1.2-1 and both providers of that Conflict: libopencl1 as 
provided by nvidia-libopencl1), but it could have been if it were then 
removed (perhaps after noticing that it didn't work).  The only other 
Depends or Recommends on opencl-icd in the current archive is bfgminer.


(If you actually want to use OpenCL on Intel hardware, you need beignet 
from experimental (the version in unstable/testing is too old to support 
Haswell) and ocl-icd-libopencl1, but the absence of those shouldn't 
break graphics.)



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#765154: gwave: FTBFS: build-dependency not installable: libgwrap-runtime-dev

[peter green]

I just tried to get this building for raspbian (due to our setup I 
preffer not to remove stuff from raspbian jessie until/unless it is 
removed from debian sid) but even making some pretty horrible hacks I 
just hit problem after problem after problem.


My final debdiff is attached . It now fails with

gcc -pthread -I/usr/include/gtk-2.0 
-I/usr/lib/arm-linux-gnueabihf/gtk-2.0/include 
-I/usr/include/gio-unix-2.0/ -I/usr/include/cairo 
-I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo 
-I/usr/include/pixman-1 -I/usr/include/libpng12 
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng12 
-I/usr/include/pango-1.0 -I/usr/include/harfbuzz 
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0 
-I/usr/lib/arm-linux-gnueabihf/glib-2.0/include 
-I/usr/include/freetype2  -pthread -I/usr/include/guile/2.0  -std=gnu99 
-pthread -I/usr/include/cairo -I/usr/include/glib-2.0 
-I/usr/lib/arm-linux-gnueabihf/glib-2.0/include -I/usr/include/pixman-1 
-I/usr/include/freetype2 -I/usr/include/libpng12 
-I/usr/include/guile-gnome-2 -I/usr/include/guile/2.0 
-I/usr/include/guile-cairo -DDATADIR=\"/usr/share\" 
-DBINGWAVE=\"/usr/bin/gwave\" -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -lm -lm -Wl,--as-needed -o gwave cmd.o wavewin.o 
draw.o gwave.o event.o gtkmisc.o pixmaps.o wavelist.o dnd.o scwm_guile.o 
guile-compat.o init_scheme_string.o wavepanel.o rgeval.o xgserver.o 
measurebtn.o GtkTable_indel.o ../spicefile/libspicefile.a  -lgtk-x11-2.0 
-lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 
-lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 
-lfontconfig -lfreetype  -lguile-gnome-gobject-2 -lgobject-2.0 
-lglib-2.0 -lgwrap-guile-runtime -lgwrap-core-runtime -lguile-2.0 -lgc 
-lffi -lguile-cairo -lcairo  -lX11

/usr/bin/ld: scwm_guile.o: undefined reference to symbol 'gh_lookup'
//usr/lib/libguile.so.17: error adding symbols: DSO missing from command 
line


It seems pretty clear to me that bringing this package back to life will 
require significant effort from someone with a deep understanding of guile.


Also fun it looks like theres a build-dependency loop between this and 
guile-gnome-platform, so if this is removed then reintroducing it will 
be fun :(
diff -Nru gwave-20090213/debian/changelog gwave-20090213/debian/changelog
--- gwave-20090213/debian/changelog 2014-09-12 07:02:54.0 +
+++ gwave-20090213/debian/changelog 2014-11-22 22:42:48.0 +
@@ -1,3 +1,14 @@
+gwave (20090213-5+rpi1) jessie-staging; urgency=medium
+
+  * Add patch from 
http://anonscm.debian.org/cgit/pkg-electronics/gwave.git/commit/?id=431d303a7b99472fcc5b4281f48e0c4f6c6c817f
+to fix include.
+  * Fix more instances of the same include issue
+  * Comment out some broken error handling code.
+  * Force linking with libm to fix missing symbols error
+  * Fix clean target
+
+ -- Peter Michael Green   Sat, 22 Nov 2014 17:05:17 
+
+
 gwave (20090213-5) unstable; urgency=medium
 
   * debian/control:
diff -Nru gwave-20090213/debian/patches/guile2.0.diff 
gwave-20090213/debian/patches/guile2.0.diff
--- gwave-20090213/debian/patches/guile2.0.diff 1970-01-01 00:00:00.0 
+
+++ gwave-20090213/debian/patches/guile2.0.diff 2014-11-22 17:45:00.0 
+
@@ -0,0 +1,58 @@
+Description: Update header for Guile 2.0
+Forwarded: https://sourceforge.net/p/gwave/patches/3/attachment/guile2.0.diff
+Author: أحمد المحمودي (Ahmed El-Mahmoudy) 

+Author: Peter Michael Green 
+Bug: https://sourceforge.net/p/gwave/patches/3/
+Bug-Debian: http://bugs.debian.org/746003
+
+Index: gwave-20090213/src/scwm_guile.h
+===
+--- gwave-20090213.orig/src/scwm_guile.h
 gwave-20090213/src/scwm_guile.h
+@@ -12,7 +12,7 @@
+ #define SCWM_GUILE_H__
+ 
+ #include "arg_unused.h"
+-#include 
++#include 
+ #include "validate.h"
+ #include 
+ 
+Index: gwave-20090213/src/scwm_guile.c
+===
+--- gwave-20090213.orig/src/scwm_guile.c
 gwave-20090213/src/scwm_guile.c
+@@ -31,7 +31,6 @@
+ #include 
+ #include 
+ 
+-#include 
+ #include 
+ #include 
+ 
+Index: gwave-20090213/src/guile-compat.c
+===
+--- gwave-20090213.orig/src/guile-compat.c
 gwave-20090213/src/guile-compat.c
+@@ -24,7 +24,7 @@
+ #include 
+ #endif
+ #include 
+-#include 
++#include 
+ 
+ #include "guile-compat.h"
+ 
+Index: gwave-20090213/src/rgeval.c
+===
+--- gwave-20090213.orig/src/rgeval.c
 gwave-20090213/src/rgeval.c
+@@ -8,7 +8,7 @@
+  */
+ #include 
+ #include 
+-#include 
++#include 
+ 
+ #ifdef HAVE_CONFIG_H
+ #include "config.h"
diff -Nru gwave-20090213/debian/patches/remove-broken-error-handling.diff 
gwave-20090213/debian/patches/remove-broken-error-handling.diff
--- gwave-20090213/debian/patches/remove-broken-error-handling.diff

Bug#767541: jenkins: CVE-2014-3665

[intrigeri]

Hi Emmanuel,

Emmanuel Bourg wrote (16 Nov 2014 12:06:07 GMT) :
> The new LTS is probably too big to be pushed to testing now. As an
> alternative I'm considering either disabling the master/slave mechanism,
> or adding a big red warning in the UI to inform the user about the risks.

Disabling the master/slave mechanism by default sounds good, as long
as there are means for users to re-enable it (I assume that's what you
meant, but let's make it clear).

Cheers,
--
intrigeri


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#766943: reassign 766943 to systemd

[Christoph Anton Mitterer]

On Mon, 2014-11-10 at 04:36 +0100, Michael Biebl wrote: 
> To provide such a syncronisation point, i.e. having network.target and
> network-online.target [1] properly hooked up, I've implemented a PoC
> ifupdown-wait-online service. You can get it from [2] and enable it via
> "systemctl enable ifupdown-wait-online.service".
> 
> This service is hooked up into network.target and network-online.target
> and blocks until one interface has been successfully configured or a
> timeout is reached.
> SysV init scripts which require $network will therefore be started after
> at least one interface has been configured, no matter if auto or
> allow-hotplug.
> 
> As said, this is  PoC and we can further discuss what "network up"
> actually is supposed to mean: one interface up, all interfaces up, etc.
That's why I hate network.target, network-online.target and especially
network-pre.target.
They're far too vaguely defined which makes their use very problematic.
Especially network-pre.target brings systemd IMHO[0] kinda back into the
stone-age of sysvinit schemes.


Your PoC seems nice,... but I guess it just tries to work-around a quite
broken situation:
- Basically we must expect that a network interface appears anywhere in
time,... even long after boot.
- services may depend on these very interfaces, especially when they
directly bind to it for listening, it's typical that daemons do this
only once in the beginning, and they often even fail if they can't.
Using NICs that appear later for outgoing connections is probably less
of a problem for such services.

The ideal situation might be, that daemons should start even if they
can't bind to their addresses, continue doing nothing while polling if
the interface becomes available.
That would have the nice effect that we don't need to serialise any
longer with network.target or have any hotplug issues.
But I doubt that (all) services will do so during my lifetime ;-)


So for the long term, we must assure, that if systemd runs a service
that does networking, the NICs are available.

Which? Good question.
"One" as you did it in your PoC is probably not enough.
Take my server, I use different IPs (v4 and v6) for vhosted services, so
many of them need to be up, for Apache to start.


Maybe an idea is really to educate people the following:
- If you have services that statically bind to an interface once they're
started up (i.e. classic daemons which do no polling and reconfiguration
when they discover new network interface) -> only allow-auto/auto is
guaranteed to be brought up.
- Use allow-hotplug only for such cases, where all networking is
dynamically discovered over and over again.



Cheers,
Chris.


[0] see my top comment there 
https://plus.google.com/111049168280159033135/posts/7467oqXVoTS


smime.p7s
Description: S/MIME cryptographic signature

Bug#768677: marked as done (node-redis: FTBFS in jessie: Tests failures)

[Debian Bug Tracking System]

Your message dated Sat, 22 Nov 2014 23:39:54 +0100
with message-id 

and subject line Not reproducible
has caused the Debian Bug report #768677,
regarding node-redis: FTBFS in jessie: Tests failures
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.)


-- 
768677: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768677
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: node-redis
Version: 0.12.1-2
Severity: serious
Tags: jessie sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20141108 qa-ftbfs
Justification: FTBFS in jessie on amd64

Hi,

During a rebuild of all packages in jessie (in a jessie chroot, not a
sid chroot), your package failed to build on amd64.

Relevant part (hopefully):
> - optional_callback: 1 ms
> - optional_callback_undefined: 0 ms
> - enable_offline_queue_true:node_redis: no callback to send error: Length: 84
> Uncaught exception: Error: Length: 84
> at ReplyParser. (/«PKGBUILDDIR»/index.js:317:31)
> at ReplyParser.emit (events.js:95:17)
> at ReplyParser.send_error (/«PKGBUILDDIR»/lib/parser/javascript.js:296:10)
> at ReplyParser.execute (/«PKGBUILDDIR»/lib/parser/javascript.js:181:22)
> at RedisClient.on_data (/«PKGBUILDDIR»/index.js:547:27)
> at Socket. (/«PKGBUILDDIR»/index.js:102:14)
> at Socket.emit (events.js:95:17)
> at Socket. (_stream_readable.js:748:14)
> at Socket.emit (events.js:92:17)
> at emitReadable_ (_stream_readable.js:410:10)
> make[1]: *** [override_dh_auto_test] Error 1
> debian/rules:13: recipe for target 'override_dh_auto_test' failed

The full build log is available from:
   
http://aws-logs.debian.net/ftbfs-logs/2014/11/08/node-redis_0.12.1-2_jessie.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.
--- End Message ---
--- Begin Message ---
Hi,

I can't reproduce the issue. The package builds in a jessie and in a sid
chroot.

Regards,
Andreas
--- End Message ---

Bug#766943: reassign 766943 to systemd

[Christoph Anton Mitterer]

Hey guys...

On Mon, 2014-11-10 at 04:08 +0100, Michael Biebl wrote: 
> > But you have seen what I've wrote previously,.. that I *do* in fact also
> > have issues with allow-hotplug... so there most likely is something
> > fishy there (or in unit files of services) as well..
> > So is this something that I should deal with in another bug?
> 
> You are conflating two issues.
> Bringing an interface up with ifup@.service is not racy, since it runs
> when the hardware is actually added. *BUT* you lose the synchronisation
> point that is /etc/init.d/networking, since ifup@.service can be
> triggered at any time and doesn't delay boot.
Well but then we must have some other issue, cause it can't be that
services are started before networking is there.

Either that means that people should be advised *not* to use
allow-hotplug, when they have services which only once statically bind
to their addresses,...

Or services would need to depends on network.target (which is kinda ugly
IMHO)... which would need to be guaranteed to be only reached after the
hotplugged interfaces came up as well.

Apart from that, AFAIR, the services which didn't came up correctly with
allow-hotplug were only such whose init-scripts were used in LSB-compat
mode by systemd (sks, apache httpd don't seem to have native unit
files).
So is it assured, that their $network is the same then network.target?
Cause then I wouldn't understand, why they couldn't bind.

> SysV init script (or other services which depend on $network or
> network.target) therefor have a problem with allow-hotplug.
ah... here you say it...

Shouldn't network.target mean, "the network is up"? I.e. also the
hotplugged devices which are available on boot?



> >> For auto interfaces, ifupdown runs the /etc/init.d/networking init
> >> script and assumes that at the time the script runs during boot, those
> >> interfaces exist.
> > Uhm... I though systemd would at a certain point run networking.service
> > via LSB compatibility (i.e. /etc/init.d/networking), and that in turn
> > runs ifup?
> 
> Sure, that's what I said. What's your point?
Guess we've just had a misunderstanding,... you wrote "ifupdown runs
the..." so I though you really meant some part of ifupdown and not just
what systemd runs from it.



> >> My suggestion would be, to make "ifup -a" wait for all auto interfaces
> >> to become available with a configurable timeout (60 seconds seems like a
> >> good compromise) after which it gives up waiting for the devices, prints
> >> a warning and proceeds.
> > 
> > From the systemd side:
> > What the long term goals in the sense of:
> > If a service needs networking, but networking didn't start, the service
> > isn't even tried to be started?
> > Or even more detailed: If service postfix, needs eth3, but that didn's
> > show up, and wasn't configured,.. postfix won't start either.
> > 
> > Cause if things are ever to be going in such direction, than exiting
> > ifup (and ultimately networking) with a timeout, would of course somehow
> > need to communicate something like "hey systemd, eth0 and eth3 failed to
> > come up, but wlan0 just went up fine".
> 
> Not sure what you're saying.

Well right now we have that really strange and troublesome situation
that different things bring up different parts of the network (i.e.
allow-auto + /etc/init.d/networking  vs.  allow-hotplug + native system
units).
And services which need networking also depend on it in a variety of
ways: network.target, $network or some do not specify anything at all.

But as we all know, network.target/$network are only very loosely
defined - people may have multiple network interfaces coming up at
different points during boot or even only much later, they may have
virtual interfaces like from VPNs, and so on.

So what should services (postfix, ssh, etc.) do in the long term to
express their network dependency?
Depend on network.target (which may or may not include what they
actually want - e.g. a VPN interface may only be initialised much later
when e.g. openvpn starts), depend on the very network interface which is
known to be responsible for their respective address e.g. something like
sys-subsystem-net-devices-eth0.device or
sys-devices-virtual-net-virbr1.device.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Processed: gamera: FTBFS on arm64

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> merge 766740 770646
Bug #766740 [gamera] gamera FTBFS on arm64, testsuite failure.
Bug #766740 [gamera] gamera FTBFS on arm64, testsuite failure.
There is no source info for the package 'gamera' at version '3.4.1+svn1423-1' 
with architecture ''
Unable to make a source version for version '3.4.1+svn1423-1'
There is no source info for the package 'gamera' at version '3.4.1+svn1423-2' 
with architecture ''
Unable to make a source version for version '3.4.1+svn1423-2'
Marked as found in versions 3.4.1+svn1423-2.
Bug #770646 [gamera] gamera: FTBFS on arm64
There is no source info for the package 'gamera' at version '3.4.1+svn1423-1' 
with architecture ''
Unable to make a source version for version '3.4.1+svn1423-1'
There is no source info for the package 'gamera' at version '3.4.1+svn1423-2' 
with architecture ''
Unable to make a source version for version '3.4.1+svn1423-2'
Marked as found in versions 3.4.1+svn1423-1.
Added tag(s) pending.
Merged 766740 770646
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
766740: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766740
770646: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770646
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Processed: Re: systemd: can't start dbus if dbus is not running

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 770644 systemd: systemd is completely unusable after a fatal signal
Bug #770644 [systemd] systemd: can't start dbus if dbus is not running
Changed Bug title to 'systemd: systemd is completely unusable after a fatal 
signal' from 'systemd: can't start dbus if dbus is not running'
> # Justification: breaks the whole system, not suitable for release
> severity 770644 serious
Bug #770644 [systemd] systemd: systemd is completely unusable after a fatal 
signal
Severity set to 'serious' from 'important'
> kthxbye
Stopping processing here.

Please contact me if you need assistance.
-- 
770644: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770644
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#768369: Acknowledgement ([libjpeg62-turbo] [DOS] Stack smashing)

[DRC]

I find that by setting the AC coefficients to alternating values of 
32767 and -32768 in the JPEG scanning order (1, 8, 16, 9, 2, 3, etc.), I 
can make the Huffman encoder exceed 200 bytes/block every single time. 
So that further confirms that 256 is the worst case.  I've checked in an 
upstream patch to subversion trunk, as well as branches/1.4.x and 
branches/1.3.x.



On 11/22/14 2:06 PM, roucaries bastien wrote:

On Sat, Nov 22, 2014 at 6:58 PM, DRC  wrote:

I can readily reproduce the failure with the supplied test case, but what
I'm tripping on right now is understanding why a Huffman-encoded block can
grow so much larger than the size of the source block (128 bytes.)  While
this test case is very unusual, there may be others out there, and I want to
understand what the worst case is for Huffman encoding.  That would
determine the appropriate value for BUFSIZE. Generally speaking,
libjpeg-turbo will only need to use the local Huffman buffer when the buffer
supplied in the destination manager is nearly exhausted-- that is, when
libjpeg-turbo feels like the size of the encoded Huffman data for a given
block would overrun the destination manager's buffer.  But we don't want to
make the local Huffman buffer too big, else it might affect performance
(since it introduces an extra memcpy() for all of the bytes that are encoded
into the local buffer.) Hence the desire to understand exactly how big a
Huffman-encoded block can grow in theory.


Could you exactly describe that you are doing (mathematically) ?

Bastien




On 11/22/14 12:43 AM, Bernhard Übelacker wrote:


Hello,
I created a minimal test case in around 200 lines.

It uses a file with the intercepted scanlines of the calls to
jpeg_write_scanlines.

Also the Exif marker is read from such a file.
(And without this Exif marker the stack smash does not happen...)

The partial output file is byte equal to that generated by imagemagick
before it crashes.

The number of calls to encode_mcu_huff and the stack seem also to be the
same.

Kind regards,
Bernhard



Place all three files in the same directory and open a shell there:
(I just created the breakpoint to see how often it is called.)


$ bunzip2 jpeg_write_marker.bin.bz2
$ bunzip2 jpeg_write_scanlines.bin.bz2
$ gcc -g -O0 -fstack-protector-all test-768369.c -ljpeg
$ gdb --args ./a.out
...
(gdb) b encode_mcu_huff
Breakpoint 1 (encode_mcu_huff) pending.
(gdb) ignore 1 1
Will ignore next 1 crossings of breakpoint 1.
(gdb) run
Starting program:
/home/bernhard/data/entwicklung/2014/debian/libjpegturbo/a.out
*** stack smashing detected ***:
/home/bernhard/data/entwicklung/2014/debian/libjpegturbo/a.out terminated
...
(gdb) info break
Num Type   Disp Enb AddressWhat
1   breakpoint keep y   0x77b8c190 in encode_mcu_huff at
jchuff.c:593
  breakpoint already hit 9842 times
  ignore next 158 hits

(gdb) bt
#0  0x77811107 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x778124e8 in __GI_abort () at abort.c:89
#2  0x7784f044 in __libc_message (do_abort=do_abort@entry=2,
fmt=fmt@entry=0x7793f6ab "*** %s ***: %s terminated\n") at
../sysdeps/posix/libc_fatal.c:175
#3  0x778d2147 in __GI___fortify_fail
(msg=msg@entry=0x7793f693 "stack smashing detected") at
fortify_fail.c:31
#4  0x778d2110 in __stack_chk_fail () at stack_chk_fail.c:28
#5  0x77b96553 in encode_mcu_huff (cinfo=0x7fffdd70,
MCU_data=0x602720) at jchuff.c:641
#6  0x77b89717 in compress_output (cinfo=0x7fffdd70,
input_buf=) at jccoefct.c:381
#7  0x77b89006 in jpeg_finish_compress (cinfo=0x7fffdd70) at
jcapimin.c:183
#8  0x00401196 in main () at test-768369.c:205









--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#770648: hiredis: FTBFS: Test failure

[Daniel Schepler]

Source: hiredis
Version: 0.11.0-4
Severity: serious

>From my pbuilder build log (on amd64):

echo \
"daemonize yes\n" \
"pidfile /tmp/hiredis-test-redis.pid\n" \
"port 56379\n" \
"bind 127.0.0.1\n" \
"unixsocket /tmp/hiredis-test-redis.sock" \
| redis-server -
./hiredis-test -h 127.0.0.1 -p 56379 -s /tmp/hiredis-test-redis.sock || \
( kill `cat /tmp/hiredis-test-redis.pid` && false )
#01 Format command without interpolation: PASSED
#02 Format command with %s string interpolation: PASSED
#03 Format command with %s and an empty string: PASSED
#04 Format command with an empty string in between proper interpolations: PASSED
#05 Format command with %b string interpolation: PASSED
#06 Format command with %b and an empty string: PASSED
#07 Format command with literal %: PASSED
#08 Format command with printf-delegation (int): PASSED
#09 Format command with printf-delegation (char): PASSED
#10 Format command with printf-delegation (short): PASSED
#11 Format command with printf-delegation (long): PASSED
#12 Format command with printf-delegation (long long): PASSED
#13 Format command with printf-delegation (unsigned int): PASSED
#14 Format command with printf-delegation (unsigned char): PASSED
#15 Format command with printf-delegation (unsigned short): PASSED
#16 Format command with printf-delegation (unsigned long): PASSED
#17 Format command with printf-delegation (unsigned long long): PASSED
#18 Format command with printf-delegation (float): PASSED
#19 Format command with printf-delegation (double): PASSED
#20 Format command with invalid printf format: PASSED
#21 Format command by passing argc/argv without lengths: PASSED
#22 Format command by passing argc/argv with lengths: PASSED
#23 Error handling in reply parser: PASSED
#24 Memory cleanup in reply parser: PASSED
#25 Set error on nested multi bulks with depth > 7: PASSED
#26 Works with NULL functions for reply: PASSED
#27 Works when a single newline (\r\n) covers two calls to feed: PASSED
#28 Don't reset state after protocol error: PASSED
#29 Don't do empty allocation for empty multi bulk: PASSED
#30 Returns error when host cannot be resolved: FAILED
#31 Returns error when the unix socket path doesn't accept connections: PASSED

Testing against TCP connection (127.0.0.1:56379):
#32 Is able to deliver commands: PASSED
#33 Is a able to send commands verbatim: PASSED
#34 %s String interpolation works: PASSED
#35 %b String interpolation works: PASSED
#36 Binary reply length is correct: PASSED
#37 Can parse nil replies: PASSED
#38 Can parse integer replies: PASSED
#39 Can parse multi bulk replies: PASSED
#40 Can handle nested multi bulk replies: PASSED
#41 Returns I/O error when the connection is lost: PASSED
#42 Returns I/O error on socket timeout: PASSED
#43 Throughput:
(1000x PING: 0.016s)
(1000x LRANGE with 500 elements: 0.105s)
(1x PING (pipelined): 0.007s)
(1x LRANGE with 500 elements (pipelined): 1.162s)

Testing against Unix socket connection (/tmp/hiredis-test-redis.sock):
#44 Is able to deliver commands: PASSED
#45 Is a able to send commands verbatim: PASSED
#46 %s String interpolation works: PASSED
#47 %b String interpolation works: PASSED
#48 Binary reply length is correct: PASSED
#49 Can parse nil replies: PASSED
#50 Can parse integer replies: PASSED
#51 Can parse multi bulk replies: PASSED
#52 Can handle nested multi bulk replies: PASSED
#53 Returns I/O error when the connection is lost: PASSED
#54 Returns I/O error on socket timeout: PASSED
#55 Throughput:
(1000x PING: 0.010s)
(1000x LRANGE with 500 elements: 0.097s)
(1x PING (pipelined): 0.007s)
(1x LRANGE with 500 elements (pipelined): 1.189s)
*** 1 TESTS FAILED ***
Makefile:86: recipe for target 'check' failed
make[2]: *** [check] Error 1
make[2]: Leaving directory '/tmp/buildd/hiredis-0.11.0'
debian/rules:30: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 2
make[1]: Leaving directory '/tmp/buildd/hiredis-0.11.0'
debian/rules:13: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
E: Failed autobuilding of package

This is with the default pbuilder configuration which disables network access
for the build.  However, I've also reproduced it with USENETWORK=yes, which
just makes the test take much longer to fail.

It would also seem that the source package doesn't honor
DEB_BUILD_OPTIONS=nocheck, which makes it difficult to disable the tests to get
a package built despite the test failures.
-- 
Daniel Schepler


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#768798: marked as done (libgdbm3:i386: changelog.Debian.gz different from libgdbm3:amd64)

[Debian Bug Tracking System]

Your message dated Sat, 22 Nov 2014 23:05:31 +0100
with message-id <2014110528.ga7...@ugent.be>
and subject line Re: Bug#768798: libgdbm3:i386: changelog.Debian.gz different 
from libgdbm3:amd64
has caused the Debian Bug report #768798,
regarding libgdbm3:i386: changelog.Debian.gz different from libgdbm3:amd64
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.)


-- 
768798: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768798
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libgdbm3
Version: 1.8.3-13+b1
Severity: serious

libgdbm3:i386 and libgdbm3:amd64 fail to install at the same time.

The reason is the binNMU changelog entry from the buildd.
I thought this issue was fixed!???

Preparing to unpack .../libgdbm3_1.8.3-13+b1_i386.deb ...
Unpacking libgdbm3:i386 (1.8.3-13+b1) over (1.8.3-13) ...
dpkg: error processing archive 
/var/cache/apt/archives/libgdbm3_1.8.3-13+b1_i386.deb (--unpack):
 trying to overwrite shared '/usr/share/doc/libgdbm3/changelog.Debian.gz', 
which is different from other instances of package libgdbm3:i386
Errors were encountered while processing:
 /var/cache/apt/archives/libgdbm3_1.8.3-13+b1_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- End Message ---
--- Begin Message ---
Version: 1.8.3-13.1

On Mon, Nov 17, 2014 at 08:25:13PM +0100, gregor herrmann wrote:
> This seems to be a duplicate of #752465 / fixed in 1.8.3-13.1 which
> closes #752465.

It is. Closing.

Ivo--- End Message ---

Bug#770647: double free in libclamunrar_iface + memory leak in read_block()

[Sebastian Andrzej Siewior]

Package: libclamunrar
Version: 0.96.4-1
Severity: serious
Tags: security pending

The debian security tracker references a problem ("clamav: double-free
error libclamunrar_iface/unrar_iface.c") which it learned from
http://www.openwall.com/lists/oss-security/2013/11/29/6
This got marked as fixed in Debian because the Clamav version we use a
high enough version. However the file / part of code is not used from
the clamav package but from the libclamunrar package instead. It is
split into another package due to the non-free license of the unrar code.

To double check, the report mentions the file unrar_iface.c. If you
check the buildlog of the clamav package you won't find it together with
gcc. If you check libclamunrar's buildlog then you will see it. Also if
you check libclamunrar_iface.so.6.1.20 you will find the function named
libclamunrar_iface_LTX_unrar_extract_next_prepare which is part of the
libclamunrar package.

To conclude: this problem as such is still not fixed in Wheezy.
The only clamunrar related change between 0.98.1-1 and 0.98.5-1 is a
memory leak fix in read_block(). For that reason and to keep it in sync
with the clamav package I would prefer to have the 0.98.5 version in Wheezy.

Sebastian


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#770646: gamera: FTBFS on arm64

[Ivo De Decker]

package: gamera
severity: serious
version: 3.4.1+svn1423-2

Hi,

The latest upload of gamera FTBFS on arm64, but builds fine on other
architectures. As it built on arm64 before, this is blocking migration to
testing (even though it was unblocked).

Cheers,

Ivo


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#769830: [subsurface] Some sources are not included in your package

[Simon McVittie]

On Sun, 16 Nov 2014 at 22:18:29 +0100, Bastien ROUCARIES wrote:
> Package: src:subsurface
[...]
> Your package seems to include some files that lack sources
> in prefered forms of modification:
> 
> theme/jquery.min.js

This appears to be a virtually unmodified jquery 1.6.4: it only differs from
https://code.jquery.com/jquery-1.6.4.min.js by one trailing space.
So downloading https://code.jquery.com/jquery-1.6.4.js (or getting it
from the appropriate Debian package) and adding it to debian/missing-sources/
would be sufficient to address that.

However, there is other minified JS in the same directory which is
less well-known than jquery, and should get the same treatment.

Regards,
S


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#754003: marked as done (el-get: please switch to emacs24)

[Debian Bug Tracking System]

Your message dated Sat, 22 Nov 2014 21:34:12 +
with message-id 
and subject line Bug#754003: fixed in el-get 3.1-1.1
has caused the Debian Bug report #754003,
regarding el-get: please switch to emacs24
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.)


-- 
754003: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754003
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: el-get
Severity: normal
Tags: patch
User: r...@debian.org
Usertags: emacs24
Control: block 753885 by -1

Dear maintainer,

we're hoping to remove emacs23 from unstable/testing in future:

  https://bugs.debian.org/753885

Please migrate your dependencies to "emacs | emacsen" (or whatever's
more appropriate for your package) as soon as possible.  The attached
patch may help.

Thanks for considering.

--
mass bug filer on behalf of Rob Browning, emacs maintainer
--- debian/control.orig	2014-07-06 13:27:13.140863556 +0200
+++ debian/control	2014-07-06 13:27:19.748945115 +0200
@@ -10,7 +10,7 @@
 
 Package: el-get
 Architecture: all
-Depends: emacs23 | emacsen, ${misc:Depends}
+Depends: emacs | emacsen, ${misc:Depends}
 Description: install and manage elisp code for Emacs
  Allows you to install and manage elisp code for Emacs. It supports lots of
  differents types of sources and is able to 'install' them, 'update' them
--- End Message ---
--- Begin Message ---
Source: el-get
Source-Version: 3.1-1.1

We believe that the bug you reported is fixed in the latest version of
el-get, 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 754...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Herbert Parentes Fortes Neto  (supplier of updated el-get 
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: SHA1

Format: 1.8
Date: Sat, 22 Nov 2014 16:53:59 -0200
Source: el-get
Binary: el-get
Architecture: source all
Version: 3.1-1.1
Distribution: unstable
Urgency: medium
Maintainer: Julien Danjou 
Changed-By: Herbert Parentes Fortes Neto 
Description:
 el-get - install and manage elisp code for Emacs
Closes: 754003
Changes:
 el-get (3.1-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * add a debian/watch file
   * change depends field in debian/control file.
 thanks Gabriele Giacone (Closes: #754003)
Checksums-Sha1:
 26da27839f2768896a91867a4ff9b8d5c39f3af4 1791 el-get_3.1-1.1.dsc
 479c981e41d15461db0eaed8c19ff62bc785eed1 3004 el-get_3.1-1.1.debian.tar.xz
 89d04f25f101937399e34183472ee1d2d03fae2c 83224 el-get_3.1-1.1_all.deb
Checksums-Sha256:
 009bba3318ee1ac36e01bd75c206fb0f8ebfef522202255cecefe47ccd8097b5 1791 
el-get_3.1-1.1.dsc
 3b2f44144530a26a32367eb4857011a37879685131badbe951c9f2bec02ded88 3004 
el-get_3.1-1.1.debian.tar.xz
 d450130ed61e9d589b41b168fffadfc26e0b79e55927eab95cb99cc72030ed1f 83224 
el-get_3.1-1.1_all.deb
Files:
 2533ba9080be02d77bbd3896b24a37cc 1791 editors extra el-get_3.1-1.1.dsc
 aab0fbe943ca6a4d0ff200dc3c1099c8 3004 editors extra 
el-get_3.1-1.1.debian.tar.xz
 0293e6df4a1d605f2e30a255f6f3252b 83224 editors extra el-get_3.1-1.1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJUcP90AAoJEN5juccE6+nvTc0P/irUi5i3fIQICEdB8PiICdaP
c2YYmUaKv52zR7Pw3QdI394goT6TFI6lrTqlrYMTXcgmt2U3G7y/FuDnjjIa3vG8
rzELeBDJoPNt24QI/0ZWLPNTU7+C/RQwqTuQWVdU9cjVvrvGptOJvkUhWY89BCWO
F2I4aO1K3Iauu+1mg6oRfU88NL737rHggjkmUvOiCzv93fbc8TuYmkkHzIEoHRg5
okSZrxuxZ7aEO4y7N3y6v7UrBUZtThDdZUHMtIhfzibstOP7bUYHF011xSQ43Wmx
D14B4bWozdYUiUnYczEoTs6joZP4xEdhXIXidONe3QSNxZuIjSGoCZRbYNW/O3BK
/I9L4i3FZ7dQNEAIsJnv1yoZAm1Vgcji/wV6RCX2SdSjpwFLhoJnBxZVgsq7paEp
px9totD0w4rU92JGxPzzTUVt4DYFNhQXMbR4IoNDEtKauHf67NEHlzSEBxX0ACg0
skTXOmdxXF3DrbOcC8FGtVTr2YC9p+p1jmuNA9NfIXK79K/Rz2FfmU4NjdqR8TX6
wh4xw5pveSVP5zsDHlv5gcpr2W3eihm0LOe72OUvBCZqotTzmCHLA8/TD6j4n/se
Ht9DEx3oW7PrhyBh9UHdmK5D6ogigeTvYPG1C5dr7vQvYz0YaAhVXloplcM7DI9F
EZ8RfSqazj63/WHmZQmj
=9YNa
-END PGP SIGNATURE End Message ---

Bug#770084: marked as done (spamassassin: Spamassassin not installable)

[Debian Bug Tracking System]

Your message dated Sat, 22 Nov 2014 16:24:14 -0500
with message-id <20141122212414.gb3...@morgul.net>
and subject line Re: Bug#770084: spamassassin: Spamassassin not installable
has caused the Debian Bug report #770084,
regarding spamassassin: Spamassassin not installable
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.)


-- 
770084: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770084
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: spamassassin
Version: 3.4.0-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

Find hereafter what I obtained when I try to install spamassassin

# aptitude install spamassassin
# Les NOUVEAUX paquets suivants vont être installés : 
#   libnetaddr-ip-perl{a} spamassassin 
#   Les paquets suivants sont RECOMMANDÉS mais ne seront pas installés :
# libmail-spf-perl sa-compile spamc 
# 0 paquets mis à jour, 2 nouvellement installés, 0 à enlever et 0 non mis 
à jour.
# Il est nécessaire de télécharger 1 212 ko d'archives. Après dépaquetage, 
4 036 ko seront utilisés.
# Voulez-vous continuer ? [Y/n/?] 
# Prendre :  1 http://ftp.fr.debian.org/debian/ testing/main 
libnetaddr-ip-perl i386 4.075+dfsg-1+b1 [108 kB]
# Prendre :  2 http://ftp.fr.debian.org/debian/ testing/main spamassassin 
all 3.4.0-3 [1 105 kB]
#  1 212 ko téléchargés en 1s (1 068 ko/s)
#  Récupération des rapports de bogue… Fait
#  Analyse des informations Trouvé/Corrigé… Fait
#  Sélection du paquet libnetaddr-ip-perl précédemment désélectionné.
#  (Lecture de la base de données... 363515 fichiers et répertoires déjà 
installés.)
#  Préparation du dépaquetage de 
.../libnetaddr-ip-perl_4.075+dfsg-1+b1_i386.deb ...
#  Dépaquetage de libnetaddr-ip-perl (4.075+dfsg-1+b1) ...
#  Sélection du paquet spamassassin précédemment désélectionné.
#  Préparation du dépaquetage de .../spamassassin_3.4.0-3_all.deb ...
#  Dépaquetage de spamassassin (3.4.0-3) ...
#  Traitement des actions différées (« triggers ») pour man-db (2.7.0.2-3) 
...
#  Paramétrage de libnetaddr-ip-perl (4.075+dfsg-1+b1) ...
#  Paramétrage de spamassassin (3.4.0-3) ...
#
#  Fichier de configuration « /etc/default/spamassassin »
#   ==> Fichier du système créé par vous ou par un script.
#==> Fichier également présent dans le paquet fourni par le responsable 
du paquet.
#   Que voulez-vous faire ? Vos options sont les suivantes :
#   Y ou I  : installer la version du responsable du paquet
#   N ou O  : garder votre version actuellement installée
# D : afficher les différences entre les versions
#   Z : suspendre ce processus pour examiner la 
situation
#L'action par défaut garde votre version 
actuelle.
#*** spamassassin (Y/I/N/O/D/Z) [défaut=N] ? Y
#Installation de la nouvelle version du fichier 
de configuration /etc/default/spamassassin ...
#Job for spamassassin.service failed. See 
'systemctl status spamassassin.service' and 'journalctl -xn' for details.
#invoke-rc.d: initscript spamassassin, action 
"start" failed.
#dpkg: erreur de traitement du paquet 
spamassassin (--configure) :
# le sous-processus script post-installation 
installé a retourné une erreur de sortie d'état 1
# Des erreurs ont été rencontrées pendant 
l'exécution :
#  spamassassin
#
[ Rootkit Hunter version 1.4.2 ]
File updated: searched for 176 files, found 150
E: Sub-process /usr/bin/dpkg returned an error code (1)
Failed to perform requested operation on package.  Trying to recover:
Paramétrage de spamassassin (3.4.0-3) ...
Job for spamassassin.service failed. See 'systemctl status 
spamassassin.service' and 'journalctl -xn' for details.
invoke-rc.d: initscript spamassassin, action "start" failed.
dpkg: erreur de traitement du paquet spamassassin (--configure) :
 le sous-processus script post-installation installé a retourné une erreur 
de sortie d'état 1
 Des erreurs ont été rencontrées pendant l'exécution :
  spamassassin
  
# systemctl status spamassassin.service
# ● spamassassin.service - Perl-

Bug#766944: marked as done (slime: Emacs"M-x slime"+sbcl fails with "Package SWANK-REPL does not exist." if cl-swank cache not deleted)

[Debian Bug Tracking System]

Your message dated Sat, 22 Nov 2014 21:20:00 +
with message-id 
and subject line Bug#766944: fixed in slime 2:2.10.1-3
has caused the Debian Bug report #766944,
regarding slime: Emacs"M-x slime"+sbcl fails with "Package SWANK-REPL does not 
exist." if cl-swank cache not deleted
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.)


-- 
766944: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766944
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: slime
Version: 2:2.10.1-2
Severity: normal

slime: Emacs"M-x slime"+sbcl fails with "Package SWANK-REPL does not exist." if
cl-swank cache not deleted

Steps to reproduce:
$ sudo apt-get inatall emacs sbcl slime
$ echo '(setq inferior-lisp-program "/usr/bin/sbcl")' > ~/.emacs
$ emacs
M-x slime  # works OK

$ emacs # start emacs again
M-x slime   # fails with error below.

When I ran slime first in Emacs after installing, it worked OK. However if I
started it again with another "M-x slime" (either in the same first session or
by quitting Emacs and starting again), it generates this message:



READ error during LOAD:

  Package SWANK-REPL does not exist.

Line: 244, Column: 47, File-Position: 8405

Stream: #
   [Condition of type SB-C::INPUT-ERROR-IN-LOAD]

(full backtrace attached to this bug report as file)



Workaround: After deleting the cl-swank compiled file cache, this works
perfectly again. However it also compiles the cache again, which causes it to
fail the next time its run.

$ rm -rf ~/.cache/common-lisp
$ emacs
M-x slime   # works OK



-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.14-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages slime depends on:
ii  emacsen-common  2.0.8

Versions of packages slime recommends:
ii  cl-swank2:2.10.1-2
ii  emacs24 [info-browser]  24.4+1-4
ii  info [info-browser] 5.2.0.dfsg.1-5

slime suggests no packages.

-- no debconf information
--- End Message ---
--- Begin Message ---
Source: slime
Source-Version: 2:2.10.1-3

We believe that the bug you reported is fixed in the latest version of
slime, 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 766...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Milan Zamazal  (supplier of updated slime 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: SHA1

Format: 1.8
Date: Sat, 22 Nov 2014 21:05:22 +0100
Source: slime
Binary: slime cl-swank
Architecture: source all
Version: 2:2.10.1-3
Distribution: unstable
Urgency: low
Maintainer: Debian Common Lisp Team 

Changed-By: Milan Zamazal 
Description:
 cl-swank   - Superior LISP Interaction Mode for Emacs (Lisp-side server)
 slime  - Superior LISP Interaction Mode for Emacs
Closes: 766944
Changes:
 slime (2:2.10.1-3) unstable; urgency=low
 .
   * Prevent error on startup; thanks to Robert J. Macomber;
 closes: #766944.
Checksums-Sha1:
 7555903d610fa59d092169df2a656d2f2ca26b45 1479 slime_2.10.1-3.dsc
 730553e25e51dc47e1ffd5f938e1420d1022ebdf 14840 slime_2.10.1-3.debian.tar.xz
 8a5b160700d09ca163e28d20b0fa85c1e14f1693 1223308 slime_2.10.1-3_all.deb
 0578d849a5fef2fabac4b6c4e68616de8a4a0c00 407284 cl-swank_2.10.1-3_all.deb
Checksums-Sha256:
 a0e80312ca36d24eba5ac878d501b784aafa5f818c619f8e19340e74091e8dd2 1479 
slime_2.10.1-3.dsc
 aa61fe43c66ea1e4d054dc14f45a768ba8636d0b1e7ca58d327b8490c0675a05 14840 
slime_2.10.1-3.debian.tar.xz
 308364d8fa1389058e933781fd3d9c55ff034d417bd12bec35f34d4579b33afe 1223308 
slime_2.10.1-3_all.deb
 4d30639736f8be345d63cdc4a1e001af297c9ef945fe60188c3178d8e620e848 407284 
cl-swank_2.10.1-3_all.deb
Files:
 925e4a806ec9b82ffcbf641574b6f07c 1479 lisp optional slime_2.10.1-3.dsc
 dea7a056e5b9325a320d4d7de36899e5 14840 lisp optional 
slime_2.10.1-3.debian.tar.xz
 0acc16e34a50feb43b1c6c5e65772998 1223308 lisp optional slime_2.10.1-3_all.deb
 5b234729067a82a8cf819c0486b9ace0 407284 lisp optional cl-swank_2.10.1-3_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYF

Processed: Re: Bug#770193: glib2.0: FTBFS in jessie: gsettings test hangs during /gsettings/no-write-binding

[Debian Bug Tracking System]

Processing control commands:

> retitle 770193 glib2.0: FTBFS if built by root: gsettings test hangs during 
> /gsettings/no-write-binding
Bug #770193 [libglib2.0-0] glib2.0: FTBFS in jessie: gsettings test hangs 
during /gsettings/no-write-binding
Changed Bug title to 'glib2.0: FTBFS if built by root: gsettings test hangs 
during /gsettings/no-write-binding' from 'glib2.0: FTBFS in jessie: gsettings 
test hangs during /gsettings/no-write-binding'

-- 
770193: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770193
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#770193: glib2.0: FTBFS in jessie: gsettings test hangs during /gsettings/no-write-binding

[Simon McVittie]

Control: retitle 770193 glib2.0: FTBFS if built by root: gsettings test hangs 
during /gsettings/no-write-binding

On Sat, 22 Nov 2014 at 19:26:53 +, Simon McVittie wrote:
> Actually, spoke too soon; a build under sudo does eventually fail
> for me. I'm re-running the build as an ordinary user and under sudo
> just to be sure, but it seems plausible that this is why it's failing.

Yes, this is reproducible on a jessie system. The build succeeds if
you aren't root (you'll need to apt-get install fakeroot) but fails
if you are building as uid 0 via sudo.

S


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Processed: Re: Bug#766944: slime: Emacs"M-x slime"+sbcl fails with "Package SWANK-REPL does not exist." if cl-swank cache not deleted

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 766944 serious
Bug #766944 [slime] slime: Emacs"M-x slime"+sbcl fails with "Package SWANK-REPL 
does not exist." if cl-swank cache not deleted
Severity set to 'serious' from 'normal'
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
766944: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766944
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#769264: Bug #769264: freebirth: FTBFS in jessie/i386: XXX

[Michael Banck]

On Sat, Nov 22, 2014 at 03:20:26PM -0500, Paul Brossier wrote:
> thanks a lot for looking at this. it sounds like a fairly safe option,
> given how awkward and ancient this code is.
> 
> i will give it a go and upload it in a few days.

OTOH, I couldn't get it to run in order to test it - even after loading
OSS compat support etc., it segfaulted on startup...

Michael


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#768816: fwbuilder crashes in libqtgui

[Michael Banck]

severity 768816 important
thanks

On Fri, Nov 14, 2014 at 11:01:45AM +0100, Sylvestre Ledru wrote:
> Could you provide the backtrace? I cannot reproduce this issue on
> amd64

I tried in a i386 chroot and cannot reproduce it there either, so
downgrading this bug to non-RC severity.


Michael


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Processed: Re: fwbuilder crashes in libqtgui

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 768816 important
Bug #768816 [fwbuilder] fwbuilder crashes in libqtgui
Severity set to 'important' from 'grave'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
768816: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768816
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#769264: Bug #769264: freebirth: FTBFS in jessie/i386: XXX

[Paul Brossier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Michael,

thanks a lot for looking at this. it sounds like a fairly safe option,
given how awkward and ancient this code is.

i will give it a go and upload it in a few days.

best, Paul


On 22/11/2014 15:14, Michael Banck wrote:
> tags 769264 +patch thanks
> 
> Hi,
> 
> On Wed, Nov 12, 2014 at 11:45:28AM +0100, Lucas Nussbaum wrote:
>>> ./fusebirth > fused_loop.c 2>/dev/null make[1]: ***
>>> [fused_loop.c] Error 139
> 
> So what happens here is that fusebirth segfaults on i386 in
> topo_sort(), while trying to sort whatever in order to generate
> fused_loop.c.
> 
> Tracing through topo_sort() with a debugger, it seems that after a
> dozen or so recursions into it, get_children(node) returns an
> invalid (but not NULL) pointer, and on the next iteration we get a
> segfault in it.
> 
> I stared at the code for a few hours, but it doesn't look like this
> is how GLib is supposed to be used nowadays, so I went for an
> alternative solution: I just included the auto-generated .c code
> into the source package and changed the build system to not
> generate/delete that .c file.
> 
> I made sure the generated source is the same on amd64 and s390x and
> will test on a couple more architectures to make sure.
> 
> Proposed Debdiff attached.
> 
> 
> Michael
> 

-BEGIN PGP SIGNATURE-

iKYEARECAGYFAlRw8ApfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJEMkE4NDdFMkMzMUJDNzg4NjMxQ0RFNTky
RTBCREU3QzYwMDJDQkQACgkQkuC958YALL0SnACfaD7nuZdOTT3OUuAG8j6bQF40
IoMAn19WyR25AK5KP1Mr1cHI9TlWIPPd
=1Iy/
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#770425: wordpress: 4.0.1 security release

[Yves-Alexis Perez]

On Sat, 22 Nov 2014 19:13:26 +1100 Craig Small  wrote:
> On Fri, Nov 21, 2014 at 08:19:03AM +0100, Salvatore Bonaccorso wrote:
> > Setting this as severity grave as it is mentioned as critical update.
> > See https://wordpress.org/news/2014/11/wordpress-4-0-1/ for details.
> Thanks for the heads-up, I knew it was out there but was waiting for 
> some free time. Better to be sure anyhow!
> 
> > There are no CVEs assigned yet for these issues.
> Oh good, I couldn't find any either and figured I was doing something
> wrong.
> 
> The 4.0.1 should be pretty easy, it will take some time for backporting
> as that is a lot more fiddly as you know.
> 
By the way, as 3.6 is now unsupported, would it make sense to update
stable to 3.7 (or later), like we did in DSA 2670-1, DSA 2718-1 and DSA
2757-1?

Regards,
-- 
Yves-Alexis


signature.asc
Description: This is a digitally signed message part

Bug#768369: Acknowledgement ([libjpeg62-turbo] [DOS] Stack smashing)

[DRC]

Never mind.  I think I answered my own question.  Although I don't 
understand the Huffman algorithm well enough to know whether this is 
algorithmically possible, a naive analysis of the code shows that it 
calls PUT_BITS 128 times for each block, and the "size" argument in all 
of those cases can theoretically be as high as 16.  So it seems to me 
that 2048 bits = 256 bytes (twice the size of the unencoded block) is 
the worst-case size for the Huffman-encoded block.  Thus, 256 seems like 
the best value for BUFSIZE, to be 100% sure that this sort of thing 
cannot possibly happen again in the future.



On 11/22/14 2:06 PM, roucaries bastien wrote:

On Sat, Nov 22, 2014 at 6:58 PM, DRC  wrote:

I can readily reproduce the failure with the supplied test case, but what
I'm tripping on right now is understanding why a Huffman-encoded block can
grow so much larger than the size of the source block (128 bytes.)  While
this test case is very unusual, there may be others out there, and I want to
understand what the worst case is for Huffman encoding.  That would
determine the appropriate value for BUFSIZE. Generally speaking,
libjpeg-turbo will only need to use the local Huffman buffer when the buffer
supplied in the destination manager is nearly exhausted-- that is, when
libjpeg-turbo feels like the size of the encoded Huffman data for a given
block would overrun the destination manager's buffer.  But we don't want to
make the local Huffman buffer too big, else it might affect performance
(since it introduces an extra memcpy() for all of the bytes that are encoded
into the local buffer.) Hence the desire to understand exactly how big a
Huffman-encoded block can grow in theory.


Could you exactly describe that you are doing (mathematically) ?

Bastien




On 11/22/14 12:43 AM, Bernhard Übelacker wrote:


Hello,
I created a minimal test case in around 200 lines.

It uses a file with the intercepted scanlines of the calls to
jpeg_write_scanlines.

Also the Exif marker is read from such a file.
(And without this Exif marker the stack smash does not happen...)

The partial output file is byte equal to that generated by imagemagick
before it crashes.

The number of calls to encode_mcu_huff and the stack seem also to be the
same.

Kind regards,
Bernhard



Place all three files in the same directory and open a shell there:
(I just created the breakpoint to see how often it is called.)


$ bunzip2 jpeg_write_marker.bin.bz2
$ bunzip2 jpeg_write_scanlines.bin.bz2
$ gcc -g -O0 -fstack-protector-all test-768369.c -ljpeg
$ gdb --args ./a.out
...
(gdb) b encode_mcu_huff
Breakpoint 1 (encode_mcu_huff) pending.
(gdb) ignore 1 1
Will ignore next 1 crossings of breakpoint 1.
(gdb) run
Starting program:
/home/bernhard/data/entwicklung/2014/debian/libjpegturbo/a.out
*** stack smashing detected ***:
/home/bernhard/data/entwicklung/2014/debian/libjpegturbo/a.out terminated
...
(gdb) info break
Num Type   Disp Enb AddressWhat
1   breakpoint keep y   0x77b8c190 in encode_mcu_huff at
jchuff.c:593
  breakpoint already hit 9842 times
  ignore next 158 hits

(gdb) bt
#0  0x77811107 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x778124e8 in __GI_abort () at abort.c:89
#2  0x7784f044 in __libc_message (do_abort=do_abort@entry=2,
fmt=fmt@entry=0x7793f6ab "*** %s ***: %s terminated\n") at
../sysdeps/posix/libc_fatal.c:175
#3  0x778d2147 in __GI___fortify_fail
(msg=msg@entry=0x7793f693 "stack smashing detected") at
fortify_fail.c:31
#4  0x778d2110 in __stack_chk_fail () at stack_chk_fail.c:28
#5  0x77b96553 in encode_mcu_huff (cinfo=0x7fffdd70,
MCU_data=0x602720) at jchuff.c:641
#6  0x77b89717 in compress_output (cinfo=0x7fffdd70,
input_buf=) at jccoefct.c:381
#7  0x77b89006 in jpeg_finish_compress (cinfo=0x7fffdd70) at
jcapimin.c:183
#8  0x00401196 in main () at test-768369.c:205









--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#770605: bundle install fails with missing openssl error

[Christian Hofstaedtler]

reassign 770605 libssl1.0.0 1.0.2~beta3-1
thanks


* Pirate Praveen  [141122 16:12]:
> package: ruby
> version: 1:2.1.0.4
> severity: critical
> justification: bundle command fails
> 
> On a sid chroot, bundle install fails with the following error message
> 
> when following steps at https://wiki.debian.org/Diaspora (tried two
> times in and old chroot as well as an updated chroot)
> 
> Could not load OpenSSL.
> You must recompile Ruby with OpenSSL support or change the sources in your
> Gemfile from 'https' to 'http'. Instructions for compiling with OpenSSL
> using
> RVM are available at http://rvm.io/packages/openssl.
> 
> On a fresh chroot with just bundler installed, this error does not come.

As you have indicated in a follow up, this only happens with
libssl1.0.0 from experimental.

A closer look gives:

$ irb
irb(main):001:0> require "openssl"
LoadError: /usr/lib/x86_64-linux-gnu/ruby/2.1.0/openssl.so: symbol 
SSLv3_method, version OPENSSL_1.0.0 not defined in file libssl.so.1.0.0 with 
link time reference - /usr/lib/x86_64-linux-gnu/ruby/2.1.0/openssl.so
from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in 
`require'
from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in 
`require'
from /usr/lib/ruby/2.1.0/openssl.rb:17:in `'
from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in 
`require'
from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in 
`require'
from (irb):1
from /usr/bin/irb:11:in `'
irb(main):002:0> 

Installing stuff from experimental (AKA 'rc-buggy') may very well
yield such results. Reassigning this to libssl1.0.0, but I suspect
Kurt would very well already know about that.

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-



signature.asc
Description: Digital signature

Processed: Re: Bug#770605: bundle install fails with missing openssl error

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 770605 libssl1.0.0 1.0.2~beta3-1
Bug #770605 [ruby] bundle install fails with missing openssl error
Bug reassigned from package 'ruby' to 'libssl1.0.0'.
No longer marked as found in versions ruby-defaults/1:2.1.0.4.
Ignoring request to alter fixed versions of bug #770605 to the same values 
previously set
Bug #770605 [libssl1.0.0] bundle install fails with missing openssl error
Marked as found in versions openssl/1.0.2~beta3-1.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
770605: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770605
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#769264: Bug #769264: freebirth: FTBFS in jessie/i386: XXX

[Michael Banck]

tags 769264 +patch
thanks

Hi,

On Wed, Nov 12, 2014 at 11:45:28AM +0100, Lucas Nussbaum wrote:
> > ./fusebirth > fused_loop.c 2>/dev/null
> > make[1]: *** [fused_loop.c] Error 139
 
So what happens here is that fusebirth segfaults on i386 in topo_sort(),
while trying to sort whatever in order to generate fused_loop.c.

Tracing through topo_sort() with a debugger, it seems that after a dozen
or so recursions into it, get_children(node) returns an invalid (but not
NULL) pointer, and on the next iteration we get a segfault in it.

I stared at the code for a few hours, but it doesn't look like this is
how GLib is supposed to be used nowadays, so I went for an alternative
solution: I just included the auto-generated .c code into the source
package and changed the build system to not generate/delete that .c file.  

I made sure the generated source is the same on amd64 and s390x and will
test on a couple more architectures to make sure.

Proposed Debdiff attached.


Michael
diff -u freebirth-0.3.2/Makefile freebirth-0.3.2/Makefile
--- freebirth-0.3.2/Makefile
+++ freebirth-0.3.2/Makefile
@@ -19,14 +19,11 @@
 all: freebirth 
 
 clean: Makefile.deps
-   -rm -f *.o freebirth fusebirth fused_loop.c Makefile.deps *~ 
+   -rm -f *.o freebirth fusebirth Makefile.deps *~ 
 
 freebirth: $(OFILES) fused_loop.o freebirth.o
$(CC) $(CFLAGS) -o $@ $^ $(LDFLAGS)
 
-fused_loop.c: fusebirth
-   ./fusebirth > fused_loop.c 2>/dev/null
-
 fusebirth: $(OFILES) fuse_loops.o fusebirth.o
$(CC) $(CFLAGS) -o $@ $^ $(LDFLAGS)
 
diff -u freebirth-0.3.2/debian/changelog freebirth-0.3.2/debian/changelog
--- freebirth-0.3.2/debian/changelog
+++ freebirth-0.3.2/debian/changelog
@@ -1,3 +1,11 @@
+freebirth (0.3.2-9.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * fused_loop.c: Include auto-generated C-file (closes: #769264).
+  * Makefile: Do not generate or remove fused_loop.c.
+
+ -- Michael Banck   Sat, 22 Nov 2014 20:36:11 +0100
+
 freebirth (0.3.2-9) unstable; urgency=medium
 
   * debian/control: add homepage, thanks to Francisco Javier Garrote Cruz
only in patch2:
unchanged:
--- freebirth-0.3.2.orig/fused_loop.c
+++ freebirth-0.3.2/fused_loop.c
@@ -0,0 +1,597 @@
+/* generated file -- don't edit */
+#include 
+#include 
+#include 
+#include "freebirth.h"
+/* borrowed from glib2 */
+#define SHORT_SWAP_LE_BE(val)  ((short) ( \
+(short) ((short) (val) >> 8) | \
+(short) ((short) (val) << 8)))
+static void swap_endian(short *data, int length)
+{
+   int i;
+   for (i = 0; i < length; i += 1, data++)
+   *data = SHORT_SWAP_LE_BE(*data);
+}
+
+sample_producer *sp[31];
+
+int play_buffer(gpointer data, gint source, GdkInputCondition condition)
+{
+  int i;
+  short buffer[TBASS_BUFF_SIZE * 2];
+  
+  sample samp0;
+  sample samp1;
+  sample samp2;
+  sample samp3;
+  sample samp4;
+  sample samp5;
+  sample samp6;
+  sample samp7;
+  sample samp8;
+  sample samp9;
+  sample samp10;
+  sample samp11;
+  sample samp12;
+  sample samp13;
+  sample samp14;
+  sample samp15;
+  sample samp16;
+  sample samp17;
+  sample samp18;
+  sample samp19;
+  sample samp20;
+  sample samp21;
+  sample samp22;
+  sample samp23;
+  sample samp24;
+  sample samp25;
+  sample samp26;
+  sample samp27;
+  sample samp28;
+  sample samp29;
+  sample samp30;
+
+  int seq_off = sequencer->current_sample_offset;
+  int seq_spb = sequencer->spb;
+  event_list *el;
+  int j;
+
+  sample *n0_table = ((raw_wave *)sp[0])->table;
+  int n0_length = ((raw_wave *)sp[0])->length;
+  sample n0_s1, n0_s2;
+  double n0_ci_w, n0_ci_f, n0_pitch = ((raw_wave *)sp[0])->pitch;
+
+  sample *n1_table = ((raw_wave *)sp[1])->table;
+  int n1_length = ((raw_wave *)sp[1])->length;
+  sample n1_s1, n1_s2;
+  double n1_ci_w, n1_ci_f, n1_pitch = ((raw_wave *)sp[1])->pitch;
+
+  sample *n2_table = ((raw_wave *)sp[2])->table;
+  int n2_length = ((raw_wave *)sp[2])->length;
+  sample n2_s1, n2_s2;
+  double n2_ci_w, n2_ci_f, n2_pitch = ((raw_wave *)sp[2])->pitch;
+
+  sample *n3_table = ((raw_wave *)sp[3])->table;
+  int n3_length = ((raw_wave *)sp[3])->length;
+  sample n3_s1, n3_s2;
+  double n3_ci_w, n3_ci_f, n3_pitch = ((raw_wave *)sp[3])->pitch;
+
+  sample *n4_table = ((raw_wave *)sp[4])->table;
+  int n4_length = ((raw_wave *)sp[4])->length;
+  sample n4_s1, n4_s2;
+  double n4_ci_w, n4_ci_f, n4_pitch = ((raw_wave *)sp[4])->pitch;
+
+  int n5_phase_offset = ((osc *)sp[5])->phase_offset;
+  double n5_freq_offset = ((osc *)sp[5])->freq_offset;
+  int n5_freq = ((osc *)sp[5])->freq;
+  int n5_phase_factor = n5_phase_offset / n5_freq;
+  sample *n5_table = ((osc *)sp[5])->table;
+  int n5_i = ((osc *)sp[5])->current_index;
+
+  int n6_phase_offset = ((osc *)sp[6])->phase_offset;
+  double n6_freq_offset = ((osc *)sp[6])->freq_offset;
+  int n6_freq = ((osc *)sp[6])->freq;
+  int n6_phase_factor = n6_phase_offset / n6_freq;
+  sample *n6_table = ((osc *)sp[6])->table;
+  int n6_i = ((osc *)sp[6])->current_index;
+
+  int n7

Processed: Re: Bug #769264: freebirth: FTBFS in jessie/i386: XXX

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 769264 +patch
Bug #769264 [src:freebirth] freebirth: FTBFS in jessie/i386: XXX
Added tag(s) patch.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
769264: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769264
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Processed: Unreproducible

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 768905 +unreproducible
Bug #768905 [src:keyutils] FTBFS: fails test "CHECK INVALID KEY TYPE"
Added tag(s) unreproducible.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
768905: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768905
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#768905: FTBFS: fails test "CHECK INVALID KEY TYPE"

[Tomasz Buchert]

On 10/11/14 10:56, Christian Kastner wrote:
> Darn, I CCed submit. Sorry about that. I blame my webmail.
>
Hi,
I cannot confirm this bug in both cases I've tried:

  * amd64 (Linux 3.14-2-amd64 #1 SMP Debian 3.14.15-2 (2014-08-09) x86_64 
GNU/Linux)
  * amrhf (Linux 3.14.4.1-bone-armhf.com #1 SMP Tue Jun 3 12:37:22 UTC 2014 
armv7l GNU/Linux)

(I'm sorry, but I cannot verify this on testing kernel on armhf)
So for me the bug does not exist. Christian, I propose to downgrade
it to "normal", or even closing it if Adam doesn't provide more info.

Tomasz


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#768369: Acknowledgement ([libjpeg62-turbo] [DOS] Stack smashing)

[roucaries bastien]

On Sat, Nov 22, 2014 at 6:58 PM, DRC  wrote:
> I can readily reproduce the failure with the supplied test case, but what
> I'm tripping on right now is understanding why a Huffman-encoded block can
> grow so much larger than the size of the source block (128 bytes.)  While
> this test case is very unusual, there may be others out there, and I want to
> understand what the worst case is for Huffman encoding.  That would
> determine the appropriate value for BUFSIZE. Generally speaking,
> libjpeg-turbo will only need to use the local Huffman buffer when the buffer
> supplied in the destination manager is nearly exhausted-- that is, when
> libjpeg-turbo feels like the size of the encoded Huffman data for a given
> block would overrun the destination manager's buffer.  But we don't want to
> make the local Huffman buffer too big, else it might affect performance
> (since it introduces an extra memcpy() for all of the bytes that are encoded
> into the local buffer.) Hence the desire to understand exactly how big a
> Huffman-encoded block can grow in theory.

Could you exactly describe that you are doing (mathematically) ?

Bastien

>
>
> On 11/22/14 12:43 AM, Bernhard Übelacker wrote:
>>
>> Hello,
>> I created a minimal test case in around 200 lines.
>>
>> It uses a file with the intercepted scanlines of the calls to
>> jpeg_write_scanlines.
>>
>> Also the Exif marker is read from such a file.
>> (And without this Exif marker the stack smash does not happen...)
>>
>> The partial output file is byte equal to that generated by imagemagick
>> before it crashes.
>>
>> The number of calls to encode_mcu_huff and the stack seem also to be the
>> same.
>>
>> Kind regards,
>> Bernhard
>>
>>
>>
>> Place all three files in the same directory and open a shell there:
>> (I just created the breakpoint to see how often it is called.)
>>
>>
>> $ bunzip2 jpeg_write_marker.bin.bz2
>> $ bunzip2 jpeg_write_scanlines.bin.bz2
>> $ gcc -g -O0 -fstack-protector-all test-768369.c -ljpeg
>> $ gdb --args ./a.out
>> ...
>> (gdb) b encode_mcu_huff
>> Breakpoint 1 (encode_mcu_huff) pending.
>> (gdb) ignore 1 1
>> Will ignore next 1 crossings of breakpoint 1.
>> (gdb) run
>> Starting program:
>> /home/bernhard/data/entwicklung/2014/debian/libjpegturbo/a.out
>> *** stack smashing detected ***:
>> /home/bernhard/data/entwicklung/2014/debian/libjpegturbo/a.out terminated
>> ...
>> (gdb) info break
>> Num Type   Disp Enb AddressWhat
>> 1   breakpoint keep y   0x77b8c190 in encode_mcu_huff at
>> jchuff.c:593
>>  breakpoint already hit 9842 times
>>  ignore next 158 hits
>>
>> (gdb) bt
>> #0  0x77811107 in __GI_raise (sig=sig@entry=6) at
>> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
>> #1  0x778124e8 in __GI_abort () at abort.c:89
>> #2  0x7784f044 in __libc_message (do_abort=do_abort@entry=2,
>> fmt=fmt@entry=0x7793f6ab "*** %s ***: %s terminated\n") at
>> ../sysdeps/posix/libc_fatal.c:175
>> #3  0x778d2147 in __GI___fortify_fail
>> (msg=msg@entry=0x7793f693 "stack smashing detected") at
>> fortify_fail.c:31
>> #4  0x778d2110 in __stack_chk_fail () at stack_chk_fail.c:28
>> #5  0x77b96553 in encode_mcu_huff (cinfo=0x7fffdd70,
>> MCU_data=0x602720) at jchuff.c:641
>> #6  0x77b89717 in compress_output (cinfo=0x7fffdd70,
>> input_buf=) at jccoefct.c:381
>> #7  0x77b89006 in jpeg_finish_compress (cinfo=0x7fffdd70) at
>> jcapimin.c:183
>> #8  0x00401196 in main () at test-768369.c:205
>>
>>
>>
>>
>


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#768690: latex-mk: FTBFS in jessie: build-dependency not installable: tgif

[Tobias Frost]

Control: tags -1 pending

Uploaded to DELAYED/5

Thanks Thomasz!

-- 
tobi


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Processed: latex-mk: FTBFS in jessie: build-dependency not installable: tgif

[Debian Bug Tracking System]

Processing control commands:

> tags -1 pending
Bug #768690 [src:latex-mk] latex-mk: FTBFS in jessie: build-dependency not 
installable: tgif
Added tag(s) pending.

-- 
768690: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768690
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Processed: Re: Bug#770193: glib2.0: FTBFS in jessie: gsettings test hangs during /gsettings/no-write-binding

[Debian Bug Tracking System]

Processing control commands:

> tags 770193 - unreproducible
Bug #770193 [libglib2.0-0] glib2.0: FTBFS in jessie: gsettings test hangs 
during /gsettings/no-write-binding
Removed tag(s) unreproducible.
> severity 770193 serious
Bug #770193 [libglib2.0-0] glib2.0: FTBFS in jessie: gsettings test hangs 
during /gsettings/no-write-binding
Severity set to 'serious' from 'important'

-- 
770193: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770193
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#770631: statsmodels: Build-Depends on nodejs not satisfiable on some architectures

[Sebastian Ramacher]

Source: statsmodels
Version: 0.6.0~rc2-1
Severity: serious
Justification: fails to build from source

statsmodels now build-depends on nodejs, but nodejs is not available on
some architectures where statsmodels built before. This affects at least
mipsel, powerpc, and s390x.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: Digital signature

Bug#768134: Ready...

[Pietro Battiston]

3.8.0-2 is ready...
http://anonscm.debian.org/cgit/collab-maint/gedit-latex.git/log/
I'm just waiting a couple of days to see if #768134 gets fixed, then I
will upload in any case.

Pietro


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#769646: Bug#769251: android-platform-build: FTBFS in jessie/i386: libutils.so: undefined reference to `android_atomic_or'

[Simon McVittie]

Control: reassign 769646 android-libcutils-dev
Control: found 769646 21-3
Control: fixed 769646 21-4

> You closed 769646 with version 21-4, but 769646 is assigned to
> android-libutils, which doesn't seem to have a version 21-4.

Sorry, I had intended to reassign to android-libcutils-dev, but then
mixed up android-libutils with android-libcutils and thought no
reassignment was needed. Everything should be correct now, I think.

android-liblog{,-dev} are also implicated, but they're from the same
source as android-libcutils{,-dev} (I've double-checked this time :-)
and were fixed in the same upload.

>> I think #769236, #769251 could just be merged with #769646. They aren't
>> really separate bugs, and would be fixed automatically by letting the
>> fix for #769646 migrate.
> 
> Once the metadata for this bug is fixed (see above), you can file an unblock
> request to clarify what needs to be done.

Will do. There doesn't seem much point asking for an unblock until
#770328 is also fixed, since that's a regression in unstable which will
require a subsequent upload. I've sent a proposed patch to that bug already.

Regards,
S


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Processed: Re: Bug#769251: android-platform-build: FTBFS in jessie/i386: libutils.so: undefined reference to `android_atomic_or'

[Debian Bug Tracking System]

Processing control commands:

> reassign 769646 android-libcutils-dev
Bug #769646 [android-libutils] android-libutils: undefined references in 
/usr/lib/android/libutils.so
Bug reassigned from package 'android-libutils' to 'android-libcutils-dev'.
No longer marked as found in versions android-platform-frameworks-native/21-1.
Ignoring request to alter fixed versions of bug #769646 to the same values 
previously set
> found 769646 21-3
Bug #769646 [android-libcutils-dev] android-libutils: undefined references in 
/usr/lib/android/libutils.so
Marked as found in versions android-platform-system-core/21-3.
> fixed 769646 21-4
Bug #769646 [android-libcutils-dev] android-libutils: undefined references in 
/usr/lib/android/libutils.so
Marked as fixed in versions android-platform-system-core/21-4.

-- 
769646: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769646
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#768494: marked as done ([imagemagick] Some special crafted jpeg file could lead to DOS)

[Debian Bug Tracking System]

Your message dated Sat, 22 Nov 2014 19:04:35 +
with message-id 
and subject line Bug#768494: fixed in imagemagick 8:6.6.0.4-3+squeeze5
has caused the Debian Bug report #768494,
regarding [imagemagick] Some special crafted jpeg file could lead to DOS
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.)


-- 
768494: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768494
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: imagemagick
Version: 8:6.8.9.9-2
Severity: normal
Tags: security
X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org
control: tags -1 + fixed-upstream
control: forwarded -1 
http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=26456

Some special crafted jpeg file lead to crash of imagemagick (SEGV) and thus DOS 
(remotly trigerable through imagick).

I have asked for CVE

Bastien
--- End Message ---
--- Begin Message ---
Source: imagemagick
Source-Version: 8:6.6.0.4-3+squeeze5

We believe that the bug you reported is fixed in the latest version of
imagemagick, 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 768...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Thorsten Alteholz  (supplier of updated imagemagick 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: SHA512

Format: 1.8
Date: Sat, 22 Nov 2014 18:54:04 +0100
Source: imagemagick
Binary: imagemagick imagemagick-dbg imagemagick-doc libmagickcore3 
libmagickcore3-extra libmagickcore-dev libmagickwand3 libmagickwand-dev 
libmagick++3 libmagick++-dev perlmagick
Architecture: source i386 all
Version: 8:6.6.0.4-3+squeeze5
Distribution: squeeze-lts
Urgency: high
Maintainer: ImageMagick Packaging Team 

Changed-By: Thorsten Alteholz 
Description: 
 imagemagick - image manipulation programs
 imagemagick-dbg - debugging symbols for ImageMagick
 imagemagick-doc - document files of ImageMagick
 libmagick++-dev - object-oriented C++ interface to ImageMagick - development 
files
 libmagick++3 - object-oriented C++ interface to ImageMagick
 libmagickcore-dev - low-level image manipulation library - development files
 libmagickcore3 - low-level image manipulation library
 libmagickcore3-extra - low-level image manipulation library - extra codecs
 libmagickwand-dev - image manipulation library - development files
 libmagickwand3 - image manipulation library
 perlmagick - Perl interface to the ImageMagick graphics routines
Closes: 768494
Changes: 
 imagemagick (8:6.6.0.4-3+squeeze5) squeeze-lts; urgency=high
 .
   * Non-maintainer upload by the Squeeze LTS Team.
   * Add 0008-CVE-2014-8716-crafted-jpeg-file-could-lead-to-DOS.patch
 to fix CVE-2014-8716 (Closes:  #768494)
Checksums-Sha1: 
 0248949c9587edaa458463b9f3097d110729ab53 2667 
imagemagick_6.6.0.4-3+squeeze5.dsc
 598de8cf7d988634762d400ec25b41699f4868a2 8779677 
imagemagick_6.6.0.4.orig.tar.bz2
 a29a00d146b105069c7f4e1543e5fc0aa605d299 41254 
imagemagick_6.6.0.4-3+squeeze5.debian.tar.bz2
 c757352e51797fc034873e5c93983a14c5f795e1 105066 
imagemagick_6.6.0.4-3+squeeze5_i386.deb
 3331c00a65f15f0faa47b59ccb54354f06f3aa35 3384218 
imagemagick-dbg_6.6.0.4-3+squeeze5_i386.deb
 9cb803625e97b9062c7e02eaf2c29857ac0915cf 4351124 
imagemagick-doc_6.6.0.4-3+squeeze5_all.deb
 fbd56a6b1bef3c1a7f368cf0d82d4c590c8ec10f 1679104 
libmagickcore3_6.6.0.4-3+squeeze5_i386.deb
 53baad2073afdfb8eb71ba48ca0c582df1f859c5 117072 
libmagickcore3-extra_6.6.0.4-3+squeeze5_i386.deb
 42c7927d492370f3c10b4a4fb9ff4331053f5463 1097682 
libmagickcore-dev_6.6.0.4-3+squeeze5_i386.deb
 382bbb683b5d45eb0bc427c073f5abc7dc5b57b0 359702 
libmagickwand3_6.6.0.4-3+squeeze5_i386.deb
 6ef9509c613534782b89bb292f3959c5222d0bc8 447130 
libmagickwand-dev_6.6.0.4-3+squeeze5_i386.deb
 365701c0121745ee6c311cfd770e6bf72461854b 215222 
libmagick++3_6.6.0.4-3+squeeze5_i386.deb
 dd22d95adb29f89f82f95ebf96907cc37a588103 250602 
libmagick++-dev_6.6.0.4-3+squeeze5_i386.deb
 fde165c8c1e7ed668adb2f507ca9f6f5783083ff 220194 
perlmagick_6.6.0.4-3+squeeze5_i386.deb
Checksums-Sha256: 
 0bbe64b9399de754e84da28be2019e9af8e52c9c379c4c599aecf0b6121f98c9 2667 
imagemagick_6.6.0.4-3+squeeze5.dsc
 55285b81c5e3bfb537cc6ce404a490b54b4d67b33c7f64990acc4f3c6008880

Processed: closing 769231

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> close 769231
Bug #769231 [xul-ext-adblock-plus] xul-ext-adblock-plus: incompatible with 
iceweasel in stable-security
Marked Bug as done
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
769231: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769231
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#769231: closing 769231

[David Prévot]

close 769231 
thanks


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#769265: marked as done (libmarpa-r2-perl: FTBFS in jessie/i386: Bailout called. Further testing stopped: Could not load Marpa::R2)

[Debian Bug Tracking System]

Your message dated Sat, 22 Nov 2014 18:48:50 +
with message-id 
and subject line Bug#769265: fixed in libmarpa-r2-perl 2.086000~dfsg-4
has caused the Debian Bug report #769265,
regarding libmarpa-r2-perl: FTBFS in jessie/i386: Bailout called.  Further 
testing stopped:  Could not load Marpa::R2
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.)


-- 
769265: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769265
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: libmarpa-r2-perl
Version: 2.086000~dfsg-3
Severity: serious
Tags: jessie sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20141112 qa-ftbfs
Justification: FTBFS in jessie on i386

Hi,

During a rebuild of all packages in jessie (in a jessie chroot, not a
sid chroot), your package failed to build on i386.

Relevant part (hopefully):
> make[2]: Entering directory '/«PKGBUILDDIR»'
> /bin/bash ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
> -I/«PKGBUILDDIR»/libmarpa_dist  -Wundef -Wendif-labels -D_FORTIFY_SOURCE=2 
> -Wall -Wextra -Wdeclaration-after-statement -Wpointer-arith 
> -Wstrict-prototypes -Wwrite-strings -Wshadow -Wmissing-declarations 
> -Wconversion -ansi -pedantic  -g -O2 -fstack-protector-strong -Wformat 
> -Werror=format-security -Wall -c -o marpa.lo 
> /«PKGBUILDDIR»/libmarpa_dist/marpa.c
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. "-I/«PKGBUILDDIR»/libmarpa_dist" 
> -Wundef -Wendif-labels -D_FORTIFY_SOURCE=2 -Wall -Wextra 
> -Wdeclaration-after-statement -Wpointer-arith -Wstrict-prototypes 
> -Wwrite-strings -Wshadow -Wmissing-declarations -Wconversion -ansi -pedantic 
> -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -c 
> "/«PKGBUILDDIR»/libmarpa_dist/marpa.c"  -fPIC -DPIC -o marpa.o
> /bin/bash ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
> -I/«PKGBUILDDIR»/libmarpa_dist  -Wundef -Wendif-labels -D_FORTIFY_SOURCE=2 
> -Wall -Wextra -Wdeclaration-after-statement -Wpointer-arith 
> -Wstrict-prototypes -Wwrite-strings -Wshadow -Wmissing-declarations 
> -Wconversion -ansi -pedantic  -g -O2 -fstack-protector-strong -Wformat 
> -Werror=format-security -Wall -c -o marpa_obs.lo 
> /«PKGBUILDDIR»/libmarpa_dist/marpa_obs.c
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. "-I/«PKGBUILDDIR»/libmarpa_dist" 
> -Wundef -Wendif-labels -D_FORTIFY_SOURCE=2 -Wall -Wextra 
> -Wdeclaration-after-statement -Wpointer-arith -Wstrict-prototypes 
> -Wwrite-strings -Wshadow -Wmissing-declarations -Wconversion -ansi -pedantic 
> -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -c 
> "/«PKGBUILDDIR»/libmarpa_dist/marpa_obs.c"  -fPIC -DPIC -o marpa_obs.o
> /bin/bash ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
> -I/«PKGBUILDDIR»/libmarpa_dist  -Wundef -Wendif-labels -D_FORTIFY_SOURCE=2 
> -Wall -Wextra -Wdeclaration-after-statement -Wpointer-arith 
> -Wstrict-prototypes -Wwrite-strings -Wshadow -Wmissing-declarations 
> -Wconversion -ansi -pedantic  -g -O2 -fstack-protector-strong -Wformat 
> -Werror=format-security -Wall -c -o marpa_avl.lo 
> /«PKGBUILDDIR»/libmarpa_dist/marpa_avl.c
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. "-I/«PKGBUILDDIR»/libmarpa_dist" 
> -Wundef -Wendif-labels -D_FORTIFY_SOURCE=2 -Wall -Wextra 
> -Wdeclaration-after-statement -Wpointer-arith -Wstrict-prototypes 
> -Wwrite-strings -Wshadow -Wmissing-declarations -Wconversion -ansi -pedantic 
> -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -c 
> "/«PKGBUILDDIR»/libmarpa_dist/marpa_avl.c"  -fPIC -DPIC -o marpa_avl.o
> /bin/bash ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
> -I/«PKGBUILDDIR»/libmarpa_dist  -Wundef -Wendif-labels -D_FORTIFY_SOURCE=2 
> -Wall -Wextra -Wdeclaration-after-statement -Wpointer-arith 
> -Wstrict-prototypes -Wwrite-strings -Wshadow -Wmissing-declarations 
> -Wconversion -ansi -pedantic  -g -O2 -fstack-protector-strong -Wformat 
> -Werror=format-security -Wall -c -o marpa_tavl.lo 
> /«PKGBUILDDIR»/libmarpa_dist/marpa_tavl.c
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. "-I/«PKGBUILDDIR»/libmarpa_dist" 
> -Wundef -Wendif-labels -D_FORTIFY_SOURCE=2 -Wall -Wextra 
> -Wdeclaration-after-statement -Wpointer-arith -Wstrict-prototypes 
> -Wwrite-strings -Wshadow -Wmissing-declarations -Wconversion -ansi -pedantic 
> -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -c 
> "/«PKGBUILDDIR»/libmarpa_dist/marpa_tavl.c"  -fPIC -DPIC -o marpa_tavl.o
> /bin/bash ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
> -I/«PKGBUILDDIR»/libmarpa_dist  -Wundef -Wendif-labels -D_FORTIFY_SOURCE=2 
> 

Bug#750356: marked as done (libmarpa-r2-perl: FTBFS on i386: Could not load XS)

[Debian Bug Tracking System]

Your message dated Sat, 22 Nov 2014 18:48:50 +
with message-id 
and subject line Bug#769265: fixed in libmarpa-r2-perl 2.086000~dfsg-4
has caused the Debian Bug report #769265,
regarding libmarpa-r2-perl: FTBFS on i386: Could not load XS
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.)


-- 
769265: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769265
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: libmarpa-r2-perl
Version: 2.084000~dfsg-1
Severity: important
Justification: fails to build from source

The i386 build of libmarpa-r2-perl failed because all tests aborted
with the error

  Could not load XS version of Marpa::R2: Can't locate object method 
"bootstrap" via package "Dynaloader" at /«PKGBUILDDIR»/blib/lib/Marpa/R2.pm 
line 46.

It's not clear what went wrong, as the actual module build reported no
errors, or even warnings, and the hurd-i386 and kfreebsd-i386 builds
both succeeded.

Could you please take a look?

Thanks!
--- End Message ---
--- Begin Message ---
Source: libmarpa-r2-perl
Source-Version: 2.086000~dfsg-4

We believe that the bug you reported is fixed in the latest version of
libmarpa-r2-perl, 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 769...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Jonas Smedegaard  (supplier of updated libmarpa-r2-perl 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: SHA512

Format: 1.8
Date: Sat, 22 Nov 2014 19:11:45 +0100
Source: libmarpa-r2-perl
Binary: libmarpa-r2-perl
Architecture: source amd64
Version: 2.086000~dfsg-4
Distribution: unstable
Urgency: medium
Maintainer: Debian Perl Group 
Changed-By: Jonas Smedegaard 
Description:
 libmarpa-r2-perl - BNF grammar parser
Closes: 769265
Changes:
 libmarpa-r2-perl (2.086000~dfsg-4) unstable; urgency=medium
 .
   * Add patch 1001 to work around segfault on i386 on XS auto-generated
 C code.
 Closes: bug#769265. Thanks to Michael Banck.
Checksums-Sha1:
 975b6a5b52a8908c01675deb4820fa3ccbd007b8 2592 
libmarpa-r2-perl_2.086000~dfsg-4.dsc
 229afa7d974e84e2078fbbdef2aadddfe1fc0019 10052 
libmarpa-r2-perl_2.086000~dfsg-4.debian.tar.xz
 3edbb8530388f5fbd03a226477fcb983124417d8 568932 
libmarpa-r2-perl_2.086000~dfsg-4_amd64.deb
Checksums-Sha256:
 b21307573919c07f25d50f9056fdbc0c15c7e3c30f2f5b9f084846cf886e9521 2592 
libmarpa-r2-perl_2.086000~dfsg-4.dsc
 cc34c8f0839494f7fdeb69870f5734034cd2e6b3434b7efc23f04bcc9d059dc5 10052 
libmarpa-r2-perl_2.086000~dfsg-4.debian.tar.xz
 15aafea465a667dac22ca79f669fa0a9d9c395c1b60b52613e5cf515a9e18965 568932 
libmarpa-r2-perl_2.086000~dfsg-4_amd64.deb
Files:
 1271c995036a724846e8f7fc83873254 2592 perl optional 
libmarpa-r2-perl_2.086000~dfsg-4.dsc
 1bb4bd917a413fd5826176455f6f32c9 10052 perl optional 
libmarpa-r2-perl_2.086000~dfsg-4.debian.tar.xz
 cc583a870cc7e0cd72d1a89e2089ec7e 568932 perl optional 
libmarpa-r2-perl_2.086000~dfsg-4_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJ8BAEBCgBmBQJUcNhXXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5RkUzRTlDMzY2OTFBNjlGRjUzQ0M2ODQy
QzdDMzE0NkMxQTAwMTIxAAoJECx8MUbBoAEhk2QQAKAZS3nBu3oLK2L676VGgtoy
3WV9YpWPfweb98M4WOAU49rWjvKNBV2fzpHJumo2HcwkOJBPQZBtzaTTkzFNO9i3
S49S/bMIE0tCyPZRc1Ii+Qpp8a9BK/Ci/ebsQA3z+Gq/fnn6XoH88RbRfXEMrdT2
zqKxuXEvKWA5oGlzMlNA6G5VISwXu6oC9cc4PlUgob/kfHDpKH/KvFumjKPpk+De
u54fjg8B0n7PV9wWc2jfNqc1N6tTibhoYHvR33bBD/x3wolmMgKL/LEEjaDEu2o2
fuiVoe7RygZ77oTE8ByOsZZZVoNaPwzDxX542errQpCtK2iB3sntuo1O50tStOTl
JrX5kRpKdg/lxflBWhB8tlkvIpR6iAMODPF15+EYcSxSrrXbiBpBUFUf68dGZYX8
KgLYEQdBJiU2YFdP7NzSQPvECx2z2YO1FsQKobeHD8JJAd4x8A8LnZM4h/QGRNvi
TaH/i/KTo/MfCLgcPs7qE9Axw23HQNrlU+pf6gVLfy45+IBY3oSO/P9YWIhllbNy
eE2OTIZlU2QhmtPcQzBR6a0ptRHqAZXESoX/810R1jhonMYKGdQiIsGKh8yOTyR7
vVvc9HOF/ntL5TEe9vNOvxZjfv7TJlC1yLXSjqWsIERrXuHQM8MQo+3h+KBj5Mr6
nhqPbYTLAZ0kkxiVT/xP
=C2j0
-END PGP SIGNATURE End Message ---

Processed: Re: Bug#769251: android-platform-build: FTBFS in jessie/i386: libutils.so: undefined reference to `android_atomic_or'

[Debian Bug Tracking System]

Processing control commands:

> reopen 769646
Bug #769646 {Done: Simon McVittie } [android-libutils] 
android-libutils: undefined references in /usr/lib/android/libutils.so
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions 21-4.
> tags 769646 sid
Bug #769646 [android-libutils] android-libutils: undefined references in 
/usr/lib/android/libutils.so
Added tag(s) sid.

-- 
769646: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769646
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#769646: Bug#769251: android-platform-build: FTBFS in jessie/i386: libutils.so: undefined reference to `android_atomic_or'

[Ivo De Decker]

Control: reopen 769646
Control: tags 769646 sid

Hi Simon,

On Sat, Nov 22, 2014 at 02:53:22PM +, Simon McVittie wrote:
> Version: 21-4

You closed 769646 with version 21-4, but 769646 is assigned to
android-libutils, which doesn't seem to have a version 21-4. Either the fix is
in another package, or you mistyped the version. I reopened the bug for now.
Please adjust as necessary.

> Control: tags 769646 - sid

Please don't do that. That's not how these tags are supposed to work. If the
bug is fixed in a newer version, version tracking will take care of it. If the
fix is in another package, I might have misunderstood. In that case, please
clarify how this bug is fixed.

> I think this has already been fixed in 21-4: libcutils and liblog didn't
> have shlibs metadata at all, but now they do. The diff looks small enough
> for an unblock request to be reasonable.
> 
> Unfortunately, 21-4 has its own new RC bug, #770328, because the maintainer
> didn't add the correct Breaks/Replaces when moving files between binary
> packages; so it can't just be unblocked as-is. I attach a possible patch
> for that.

> I think #769236, #769251 could just be merged with #769646. They aren't
> really separate bugs, and would be fixed automatically by letting the
> fix for #769646 migrate.

Once the metadata for this bug is fixed (see above), you can file an unblock
request to clarify what needs to be done.

Cheers,

Ivo


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#769508: apt-spacewalk: diff for NMU version 1.0.6-4.1

[Andreas Bombe]

Control: tags 769508 + patch
Control: tags 769508 + pending

Dear maintainer,

I've prepared an NMU for apt-spacewalk (versioned as 1.0.6-4.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer. Also attached are the two commits which I
haven't pushed to collab-maint yet (I will push them later).

Regards.
diff -u apt-spacewalk-1.0.6/debian/changelog apt-spacewalk-1.0.6/debian/changelog
--- apt-spacewalk-1.0.6/debian/changelog
+++ apt-spacewalk-1.0.6/debian/changelog
@@ -1,3 +1,11 @@
+apt-spacewalk (1.0.6-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Check for post_invoke.py to exist before attempting to invoke it
+(Closes: 769508)
+
+ -- Andreas Bombe   Sat, 22 Nov 2014 18:42:41 +0100
+
 apt-spacewalk (1.0.6-4) unstable; urgency=medium
 
   * [99f9479e] Integrate NMU that went missing.
only in patch2:
unchanged:
--- apt-spacewalk-1.0.6.orig/50spacewalk
+++ apt-spacewalk-1.0.6/50spacewalk
@@ -11,5 +11,5 @@
   }
 };
 DPkg::Post-Invoke {
-"/usr/lib/apt-spacewalk/post_invoke.py";
+"[ ! -e /usr/lib/apt-spacewalk/post_invoke.py ] || /usr/lib/apt-spacewalk/post_invoke.py";
 };
>From 085f07ace47fc5a852b14ebd2dbc1e47d892ed79 Mon Sep 17 00:00:00 2001
From: Andreas Bombe 
Date: Sat, 22 Nov 2014 18:38:14 +0100
Subject: [PATCH 1/2] Check for post_invoke.py to exist before attempting to
 invoke it

This is run as DPkg::Post-Invoke, but during package removal the file
stops existing before the Post-Invoke is actually started. Checking for
its existance beforehand prevents the Post-Invoke reporting an error.

Closes: 769508
---
 50spacewalk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/50spacewalk b/50spacewalk
index 2c3264c..e86ffa1 100644
--- a/50spacewalk
+++ b/50spacewalk
@@ -11,5 +11,5 @@ APT {
   }
 };
 DPkg::Post-Invoke {
-"/usr/lib/apt-spacewalk/post_invoke.py";
+"[ ! -e /usr/lib/apt-spacewalk/post_invoke.py ] || /usr/lib/apt-spacewalk/post_invoke.py";
 };
-- 
2.1.3

>From aa35cae6a4421cb499b488b2f6bf09e41ce717d3 Mon Sep 17 00:00:00 2001
From: Andreas Bombe 
Date: Sat, 22 Nov 2014 18:44:05 +0100
Subject: [PATCH 2/2] Changelog for NMU upload 1.0.6-4.1

---
 debian/changelog | 8 
 1 file changed, 8 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 4adf866..0479a87 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+apt-spacewalk (1.0.6-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Check for post_invoke.py to exist before attempting to invoke it
+(Closes: 769508)
+
+ -- Andreas Bombe   Sat, 22 Nov 2014 18:42:41 +0100
+
 apt-spacewalk (1.0.6-4) unstable; urgency=medium
 
   * [99f9479e] Integrate NMU that went missing.
-- 
2.1.3

Processed: apt-spacewalk: diff for NMU version 1.0.6-4.1

[Debian Bug Tracking System]

Processing control commands:

> tags 769508 + patch
Bug #769508 [apt-transport-spacewalk] apt-transport-spacewalk: package removal 
fails
Added tag(s) patch.
> tags 769508 + pending
Bug #769508 [apt-transport-spacewalk] apt-transport-spacewalk: package removal 
fails
Added tag(s) pending.

-- 
769508: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769508
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#770193: glib2.0: FTBFS in jessie: gsettings test hangs during /gsettings/no-write-binding

[Simon McVittie]

Control: retitle 770193 glib2.0: FTBFS in jessie: gsettings test hangs during 
/gsettings/no-write-binding
Control: tags 770193 + unreproducible
Control: severity 770193 important

On Wed, 19 Nov 2014 at 15:57:34 +, Pietro wrote:
> I am running a testing debian system and I would like to upgrade the
> libglib2.0-0 to the latest from the unstable repo.

Given that you have unstable in your sources.list already, you should
be able to upgrade the packages from src:glib2.0 to their unstable
versions without rebuilding them. In fact, since you don't
seem to have any apt pinning active, an ordinary upgrade would
result in installing the unstable versions anyway... if you
don't want that, you should only have deb-src lines for unstable,
not deb.

> 1 - sudo apt-get build-dep libglib2.0-0 
> 2 - sudo apt-get -b source libglib2.0-0

Step 2 doesn't need sudo, and it's probably better if you don't,
but that doesn't seem to be relevant here.

> The compilation gets stuck here and never finishes, my expectation was
> to be able to install the resulting package with dpkg -i.
> [...]
> PASS: gsettings 21 /gsettings/writable-binding
> PASS: gsettings 22 /gsettings/typesafe-binding
> PASS: gsettings 23 /gsettings/no-read-binding
> [ never exits ]

I've successfully built glib2.0/2.42.1-1 in an up-to-date testing
environment from today, both as an ordinary user and as root.

Also, both glib2.0/2.42.0-2 (from testing) and glib2.0/2.42.1-1
from unstable) are also building successfully for me in an up-to-date
testing chroot under sbuild (which is what matters for Debian's
autobuilders).

The rest of that test is:

PASS: gsettings 24 /gsettings/no-write-binding
PASS: gsettings 25 /gsettings/keyfile
PASS: gsettings 26 /gsettings/child-schema
PASS: gsettings 27 /gsettings/strinfo
PASS: gsettings 28 /gsettings/enums
PASS: gsettings 29 /gsettings/flags
PASS: gsettings 30 /gsettings/range
PASS: gsettings 31 /gsettings/list-items
PASS: gsettings 32 /gsettings/list-schemas
PASS: gsettings 33 /gsettings/mapped
PASS: gsettings 34 /gsettings/get-range
PASS: gsettings 35 /gsettings/schema-source
PASS: gsettings 36 /gsettings/actions
PASS: gsettings 37 /gsettings/null-backend
PASS: gsettings 38 /gsettings/memory-backend
PASS: gsettings 39 /gsettings/read-descriptions
PASS: gsettings 40 /gsettings/test-extended-schema
PASS: gsettings 41 /gsettings/default-value

I'm not sure why any of those would hang.

Since I couldn't reproduce this, I'm downgrading it to be
non-release-critical; I'm also retitling it for clarity, since
glibc is not the same thing as glib.

Regards,
S


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Processed: fix version for 770071

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> # found and fixed version can't be the same
> notfixed 770071 0.11.0-1.1
Bug #770071 {Done: Johann Felix Soden } [src:cpp-netlib] 
cpp-netlib: FTBFS under pbuilder: Test failure
No longer marked as fixed in versions 0.11.0-1.1.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
770071: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770071
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Processed: Re: Bug#770193: glib2.0: FTBFS in jessie: gsettings test hangs during /gsettings/no-write-binding

[Debian Bug Tracking System]

Processing control commands:

> retitle 770193 glib2.0: FTBFS in jessie: gsettings test hangs during 
> /gsettings/no-write-binding
Bug #770193 [libglib2.0-0] libglib2.0-0: Failing to compile package libglibc 
(importing a unstable package on a testing system)
Changed Bug title to 'glib2.0: FTBFS in jessie: gsettings test hangs during 
/gsettings/no-write-binding' from 'libglib2.0-0: Failing to compile package 
libglibc (importing a unstable package on a testing system)'
> tags 770193 + unreproducible
Bug #770193 [libglib2.0-0] glib2.0: FTBFS in jessie: gsettings test hangs 
during /gsettings/no-write-binding
Added tag(s) unreproducible.
> severity 770193 important
Bug #770193 [libglib2.0-0] glib2.0: FTBFS in jessie: gsettings test hangs 
during /gsettings/no-write-binding
Severity set to 'important' from 'serious'

-- 
770193: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770193
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Processed: found 769264 in 0.3.2-9, tagging 769264

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> found 769264 0.3.2-9
Bug #769264 [src:freebirth] freebirth: FTBFS in jessie/i386: XXX
Marked as found in versions freebirth/0.3.2-9.
> tags 769264 + confirmed
Bug #769264 [src:freebirth] freebirth: FTBFS in jessie/i386: XXX
Added tag(s) confirmed.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
769264: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769264
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#768690: NMU patch

[Tomasz Buchert]

Of course I meant:

 " by DISABLING tgif in ..." (spurious "not")

Tomasz

On 22/11/14 19:06, Tomasz Buchert wrote:
> Hi,
>
> this is a lazy solution to this bug: we remove tgif dependency
> altogether by not disabling tgif in latex-mk. tgif does not seem to be
> available anyway so it is a compromise that has to be made.  The user
> will see an error message if tgif functionality will be used.
>
> You may notice that some unit tests fail during the build - it is
> ok-ish since they were failing before anyway.
>
> Tomasz

> diff -Nru latex-mk-2.1/debian/changelog latex-mk-2.1/debian/changelog
> --- latex-mk-2.1/debian/changelog 2014-04-25 16:45:24.0 +0200
> +++ latex-mk-2.1/debian/changelog 2014-11-22 18:15:40.0 +0100
> @@ -1,3 +1,10 @@
> +latex-mk (2.1-1.3) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Disable support and dependency on tgif (Closes: #768690)
> +
> + -- Tomasz Buchert   Sat, 22 Nov 2014 18:14:45 +0100
> +
>  latex-mk (2.1-1.2) unstable; urgency=medium
>
>* Non-maintainer upload.
> diff -Nru latex-mk-2.1/debian/control latex-mk-2.1/debian/control
> --- latex-mk-2.1/debian/control   2014-04-25 16:44:02.0 +0200
> +++ latex-mk-2.1/debian/control   2014-11-22 18:14:34.0 +0100
> @@ -6,7 +6,7 @@
>  Build-Depends-Indep: texlive-base, texlive-latex-base, texlive-latex-extra,
>   texlive-latex-recommended, texlive-fonts-recommended, texinfo, xsltproc,
>   docbook-xsl, graphicsmagick-imagemagick-compat, gv, hevea, latex2rtf, 
> cups-bsd,
> - ghostscript, tgif, transfig, csh, autoconf
> + ghostscript, transfig, csh, autoconf
>  Standards-Version: 3.9.2
>  Homepage: http://latex-mk.sourceforge.net/
>
> @@ -15,7 +15,7 @@
>  Depends: ${misc:Depends}
>  Recommends: make, texlive-latex-recommended, texlive-base
>  Suggests: graphicsmagick-imagemagick-compat, gv, hevea, latex2rtf, cups-bsd,
> - ghostscript, tgif, transfig
> + ghostscript, transfig
>  Description: tool for managing LaTeX projects
>   LaTeX-Mk is a collection of Makefile fragments and shell scripts for
>   managing small to large sized LaTeX projects. The typical LaTeX-Mk
> diff -Nru latex-mk-2.1/debian/patches/disable-tgif.patch 
> latex-mk-2.1/debian/patches/disable-tgif.patch
> --- latex-mk-2.1/debian/patches/disable-tgif.patch1970-01-01 
> 01:00:00.0 +0100
> +++ latex-mk-2.1/debian/patches/disable-tgif.patch2014-11-22 
> 18:57:09.0 +0100
> @@ -0,0 +1,28 @@
> +Description: Disables build dependency on tgif
> + tgif was removed from testing for various reasons.
> + First, its dependencies are not in testing (see 
> https://bugs.debian.org/699301)
> + and then its own status is ambiguous (see https://bugs.debian.org/668249).
> + This patch disables tgif-related functionality by showing error
> + message if the user wants to use it.
> + .
> + latex-mk (2.1-1.3) unstable; urgency=medium
> + .
> +   * Non-maintainer upload.
> +   * Disable support and dependency on tgif (Closes: #768690)
> +Author: Tomasz Buchert 
> +Bug-Debian: https://bugs.debian.org/768690
> +
> +--- a/latex.mk.in.in
>  b/latex.mk.in.in
> +@@ -432,9 +432,11 @@
> + # pull in tgif.[g]mk if needed
> +
> + BMK:.if defined(_USE_TGIF_MK)
> ++BMK:.error Support for tgif files is not available, see 
> https://bugs.debian.org/768690
> + BMK:.include "${LATEX_MK_DIR}/tgif.mk"
> + BMK:.endif
> + GMK:ifdef _USE_TGIF_MK
> ++GMK:$(error Support for tgif files is not available, see 
> https://bugs.debian.org/768690)
> + GMK:include ${LATEX_MK_DIR}/tgif.gmk
> + GMK:endif
> +
> diff -Nru latex-mk-2.1/debian/patches/series 
> latex-mk-2.1/debian/patches/series
> --- latex-mk-2.1/debian/patches/series2011-06-22 04:36:52.0 
> +0200
> +++ latex-mk-2.1/debian/patches/series2014-11-22 18:17:49.0 
> +0100
> @@ -2,3 +2,4 @@
>  use-fancyhdr.patch
>  new-nomencl.patch
>  use-gunzip-instead-of-gzcat.patch
> +disable-tgif.patch


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#768690: NMU patch

[Tomasz Buchert]

Hi,

this is a lazy solution to this bug: we remove tgif dependency
altogether by not disabling tgif in latex-mk. tgif does not seem to be
available anyway so it is a compromise that has to be made.  The user
will see an error message if tgif functionality will be used.

You may notice that some unit tests fail during the build - it is
ok-ish since they were failing before anyway.

Tomasz
diff -Nru latex-mk-2.1/debian/changelog latex-mk-2.1/debian/changelog
--- latex-mk-2.1/debian/changelog	2014-04-25 16:45:24.0 +0200
+++ latex-mk-2.1/debian/changelog	2014-11-22 18:15:40.0 +0100
@@ -1,3 +1,10 @@
+latex-mk (2.1-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Disable support and dependency on tgif (Closes: #768690)
+
+ -- Tomasz Buchert   Sat, 22 Nov 2014 18:14:45 +0100
+
 latex-mk (2.1-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru latex-mk-2.1/debian/control latex-mk-2.1/debian/control
--- latex-mk-2.1/debian/control	2014-04-25 16:44:02.0 +0200
+++ latex-mk-2.1/debian/control	2014-11-22 18:14:34.0 +0100
@@ -6,7 +6,7 @@
 Build-Depends-Indep: texlive-base, texlive-latex-base, texlive-latex-extra,
  texlive-latex-recommended, texlive-fonts-recommended, texinfo, xsltproc,
  docbook-xsl, graphicsmagick-imagemagick-compat, gv, hevea, latex2rtf, cups-bsd,
- ghostscript, tgif, transfig, csh, autoconf
+ ghostscript, transfig, csh, autoconf
 Standards-Version: 3.9.2
 Homepage: http://latex-mk.sourceforge.net/
 
@@ -15,7 +15,7 @@
 Depends: ${misc:Depends}
 Recommends: make, texlive-latex-recommended, texlive-base
 Suggests: graphicsmagick-imagemagick-compat, gv, hevea, latex2rtf, cups-bsd,
- ghostscript, tgif, transfig
+ ghostscript, transfig
 Description: tool for managing LaTeX projects
  LaTeX-Mk is a collection of Makefile fragments and shell scripts for
  managing small to large sized LaTeX projects. The typical LaTeX-Mk
diff -Nru latex-mk-2.1/debian/patches/disable-tgif.patch latex-mk-2.1/debian/patches/disable-tgif.patch
--- latex-mk-2.1/debian/patches/disable-tgif.patch	1970-01-01 01:00:00.0 +0100
+++ latex-mk-2.1/debian/patches/disable-tgif.patch	2014-11-22 18:57:09.0 +0100
@@ -0,0 +1,28 @@
+Description: Disables build dependency on tgif
+ tgif was removed from testing for various reasons.
+ First, its dependencies are not in testing (see https://bugs.debian.org/699301)
+ and then its own status is ambiguous (see https://bugs.debian.org/668249).
+ This patch disables tgif-related functionality by showing error
+ message if the user wants to use it.
+ .
+ latex-mk (2.1-1.3) unstable; urgency=medium
+ .
+   * Non-maintainer upload.
+   * Disable support and dependency on tgif (Closes: #768690)
+Author: Tomasz Buchert 
+Bug-Debian: https://bugs.debian.org/768690
+
+--- a/latex.mk.in.in
 b/latex.mk.in.in
+@@ -432,9 +432,11 @@
+ # pull in tgif.[g]mk if needed
+ 
+ BMK:.if defined(_USE_TGIF_MK)
++BMK:.error Support for tgif files is not available, see https://bugs.debian.org/768690
+ BMK:.include "${LATEX_MK_DIR}/tgif.mk"
+ BMK:.endif
+ GMK:ifdef _USE_TGIF_MK
++GMK:$(error Support for tgif files is not available, see https://bugs.debian.org/768690)
+ GMK:include ${LATEX_MK_DIR}/tgif.gmk
+ GMK:endif
+ 
diff -Nru latex-mk-2.1/debian/patches/series latex-mk-2.1/debian/patches/series
--- latex-mk-2.1/debian/patches/series	2011-06-22 04:36:52.0 +0200
+++ latex-mk-2.1/debian/patches/series	2014-11-22 18:17:49.0 +0100
@@ -2,3 +2,4 @@
 use-fancyhdr.patch
 new-nomencl.patch
 use-gunzip-instead-of-gzcat.patch
+disable-tgif.patch

Bug#768369: Acknowledgement ([libjpeg62-turbo] [DOS] Stack smashing)

[DRC]

I can readily reproduce the failure with the supplied test case, but 
what I'm tripping on right now is understanding why a Huffman-encoded 
block can grow so much larger than the size of the source block (128 
bytes.)  While this test case is very unusual, there may be others out 
there, and I want to understand what the worst case is for Huffman 
encoding.  That would determine the appropriate value for BUFSIZE. 
Generally speaking, libjpeg-turbo will only need to use the local 
Huffman buffer when the buffer supplied in the destination manager is 
nearly exhausted-- that is, when libjpeg-turbo feels like the size of 
the encoded Huffman data for a given block would overrun the destination 
manager's buffer.  But we don't want to make the local Huffman buffer 
too big, else it might affect performance (since it introduces an extra 
memcpy() for all of the bytes that are encoded into the local buffer.) 
Hence the desire to understand exactly how big a Huffman-encoded block 
can grow in theory.



On 11/22/14 12:43 AM, Bernhard Übelacker wrote:

Hello,
I created a minimal test case in around 200 lines.

It uses a file with the intercepted scanlines of the calls to 
jpeg_write_scanlines.

Also the Exif marker is read from such a file.
(And without this Exif marker the stack smash does not happen...)

The partial output file is byte equal to that generated by imagemagick before 
it crashes.

The number of calls to encode_mcu_huff and the stack seem also to be the same.

Kind regards,
Bernhard



Place all three files in the same directory and open a shell there:
(I just created the breakpoint to see how often it is called.)


$ bunzip2 jpeg_write_marker.bin.bz2
$ bunzip2 jpeg_write_scanlines.bin.bz2
$ gcc -g -O0 -fstack-protector-all test-768369.c -ljpeg
$ gdb --args ./a.out
...
(gdb) b encode_mcu_huff
Breakpoint 1 (encode_mcu_huff) pending.
(gdb) ignore 1 1
Will ignore next 1 crossings of breakpoint 1.
(gdb) run
Starting program: /home/bernhard/data/entwicklung/2014/debian/libjpegturbo/a.out
*** stack smashing detected ***: 
/home/bernhard/data/entwicklung/2014/debian/libjpegturbo/a.out terminated
...
(gdb) info break
Num Type   Disp Enb AddressWhat
1   breakpoint keep y   0x77b8c190 in encode_mcu_huff at 
jchuff.c:593
 breakpoint already hit 9842 times
 ignore next 158 hits

(gdb) bt
#0  0x77811107 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x778124e8 in __GI_abort () at abort.c:89
#2  0x7784f044 in __libc_message (do_abort=do_abort@entry=2, 
fmt=fmt@entry=0x7793f6ab "*** %s ***: %s terminated\n") at 
../sysdeps/posix/libc_fatal.c:175
#3  0x778d2147 in __GI___fortify_fail (msg=msg@entry=0x7793f693 "stack 
smashing detected") at fortify_fail.c:31
#4  0x778d2110 in __stack_chk_fail () at stack_chk_fail.c:28
#5  0x77b96553 in encode_mcu_huff (cinfo=0x7fffdd70, 
MCU_data=0x602720) at jchuff.c:641
#6  0x77b89717 in compress_output (cinfo=0x7fffdd70, 
input_buf=) at jccoefct.c:381
#7  0x77b89006 in jpeg_finish_compress (cinfo=0x7fffdd70) at 
jcapimin.c:183
#8  0x00401196 in main () at test-768369.c:205







--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#736139: marked as done (blockdiag: Fails to build from source in stable)

[Debian Bug Tracking System]

Your message dated Sat, 22 Nov 2014 18:56:06 +0100
with message-id <1416678966.23390.1.ca...@debian.org>
and subject line blockdiag: Fails to build from source in stable
has caused the Debian Bug report #736139,
regarding blockdiag: Fails to build from source in stable
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.)


-- 
736139: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736139
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: blockdiag
Version: 1.1.6-1.1
Severity: serious

Hi,
blockdiag fails to build from source in Wheezy (sid properly builds from 
source):

Cheers,
Moritz

--
copying src/blockdiag/tests/diagrams/errors/unknown_group_orientation.diag -> 
_build/lib.linux-x86_64-2.7/blockdiag/tests/diagrams/errors
copying src/blockdiag/tests/diagrams/errors/unknown_group_shape.diag -> 
_build/lib.linux-x86_64-2.7/blockdiag/tests/diagrams/errors
copying src/blockdiag/tests/diagrams/errors/unknown_node_attribute.diag -> 
_build/lib.linux-x86_64-2.7/blockdiag/tests/diagrams/errors
copying src/blockdiag/tests/diagrams/errors/unknown_node_class.diag -> 
_build/lib.linux-x86_64-2.7/blockdiag/tests/diagrams/errors
copying src/blockdiag/tests/diagrams/errors/unknown_node_shape.diag -> 
_build/lib.linux-x86_64-2.7/blockdiag/tests/diagrams/errors
copying src/blockdiag/tests/diagrams/errors/unknown_node_style.diag -> 
_build/lib.linux-x86_64-2.7/blockdiag/tests/diagrams/errors
copying src/blockdiag/tests/diagrams/errors/unknown_plugin.diag -> 
_build/lib.linux-x86_64-2.7/blockdiag/tests/diagrams/errors
   debian/rules override_dh_auto_test
make[1]: Entering directory `/home/jmm/scratch/wheezy/blockdiag-1.1.6'
set -e; \
PYTHONPATH=/home/jmm/scratch/wheezy/blockdiag-1.1.6/src nosetests -d 
..E
==
ERROR: 
blockdiag.tests.test_generate_diagram.test_generator_svg('node_icon.diag', 
'svg')
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File "/home/jmm/scratch/wheezy/blockdiag-1.1.6/src/blockdiag/tests/utils.py", 
line 14, in wrap
func(*args, **kwargs)
  File "/home/jmm/scratch/wheezy/blockdiag-1.1.6/src/blockdiag/tests/utils.py", 
line 29, in wrap
func(*args, **kwargs)
  File 
"/home/jmm/scratch/wheezy/blockdiag-1.1.6/src/blockdiag/tests/test_generate_diagram.py",
 line 51, in __build_diagram
raise RuntimeError(sys.stderr.getvalue())
RuntimeError: ERROR: cannot identify image file

 >> begin captured stdout << -
('node_icon.diag', 'svg') {}
---[ stderr ] ---
ERROR: cannot identify image file


- >> end captured stdout << --

--
Ran 299 tests in 4.219s

FAILED (errors=1)
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory `/home/jmm/scratch/wheezy/blockdiag-1.1.6'
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
--
--- End Message ---
--- Begin Message ---
As already tagged in the BTS: Fixed in version 1.3.2-1
Seems that the bug was forgotten to be closed. --- End Message ---

Bug#769265: Bug #769265: libmarpa-r2-perl: FTBFS in jessie/i386: Bailout called. Further testing stopped: Could not load Marpa::R2

[Michael Banck]

On Sat, Nov 22, 2014 at 06:44:31PM +0100, Jonas Smedegaard wrote:
> Quoting Michael Banck (2014-11-22 17:33:17)
> > Attached is a proposed NMU debdiff with an expanded comment in the patch.
> 
> Are you ok licensing your patch as "Same as Marpa::R2 code", 

Sure.


Michael


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#768881: [Debian-ha-maintainers] Bug#768881: FTBFS: unable to parse drbdsetup.xml.in

[Apollon Oikonomopoulos]

Control: tags -1 + moreinfo unreproducible
Control: severity -1 normal

Hi,

After looking a bit into this, it looks as if the parser state of 
xsltproc got messed up for some reason. Note that I am unable to 
reproduce this in any way, so I tend to think this might have been a 
problem with the build environment. Thus I'm downgrading this to normal 
for the time being. Please let us know if you can reliably reproduce 
this in any way.

Regards,
Apollon


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Processed: Re: [Debian-ha-maintainers] Bug#768881: FTBFS: unable to parse drbdsetup.xml.in

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + moreinfo unreproducible
Bug #768881 [src:drbd-utils] FTBFS: unable to parse drbdsetup.xml.in
Added tag(s) unreproducible and moreinfo.
> severity -1 normal
Bug #768881 [src:drbd-utils] FTBFS: unable to parse drbdsetup.xml.in
Severity set to 'normal' from 'serious'

-- 
768881: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768881
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#769265: Bug #769265: libmarpa-r2-perl: FTBFS in jessie/i386: Bailout called. Further testing stopped: Could not load Marpa::R2

[Jonas Smedegaard]

Quoting Michael Banck (2014-11-22 17:33:17)
> Attached is a proposed NMU debdiff with an expanded comment in the patch.

Are you ok licensing your patch as "Same as Marpa::R2 code", or do you 
prefer not claiming copyright for it, or something else?

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#768708: sphinxcontrib-nwdiag: diff for NMU version 0.9.0-1.1

[Tobias Frost]

Control: tags 768708 + patch
Control: tags 768708 + pending

Dear maintainer,

I've prepared an NMU for sphinxcontrib-nwdiag (versioned as 0.9.0-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru sphinxcontrib-nwdiag-0.9.0/debian/changelog 
sphinxcontrib-nwdiag-0.9.0/debian/changelog
--- sphinxcontrib-nwdiag-0.9.0/debian/changelog 2014-10-25 06:47:15.0 
+0200
+++ sphinxcontrib-nwdiag-0.9.0/debian/changelog 2014-11-22 18:42:30.0 
+0100
@@ -1,3 +1,11 @@
+sphinxcontrib-nwdiag (0.9.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Disable tests for now, required depedencies are not available in Jessie:
+sphinx-testing, python3-sphinx-testing (Closes: #768708)
+
+ -- Tobias Frost   Sat, 22 Nov 2014 18:42:30 +0100
+
 sphinxcontrib-nwdiag (0.9.0-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru sphinxcontrib-nwdiag-0.9.0/debian/control 
sphinxcontrib-nwdiag-0.9.0/debian/control
--- sphinxcontrib-nwdiag-0.9.0/debian/control   2014-10-25 06:46:02.0 
+0200
+++ sphinxcontrib-nwdiag-0.9.0/debian/control   2014-11-22 18:41:44.0 
+0100
@@ -8,13 +8,11 @@
python-sphinx (>= 0.6),
python-mock,
python-nwdiag (>= 1.0.3),
-   python-sphinx-testing,
python3-all,
python3-setuptools,
python3-sphinx (>= 0.6),
python3-mock,
python3-nwdiag (>= 1.0.3),
-   python3-sphinx-testing
 Standards-Version: 3.9.6
 X-Python-Version: 2.7
 Homepage: http://blockdiag.com/
diff -Nru sphinxcontrib-nwdiag-0.9.0/debian/rules 
sphinxcontrib-nwdiag-0.9.0/debian/rules
--- sphinxcontrib-nwdiag-0.9.0/debian/rules 2014-09-01 05:52:03.0 
+0200
+++ sphinxcontrib-nwdiag-0.9.0/debian/rules 2014-11-22 18:41:59.0 
+0100
@@ -4,7 +4,8 @@
 #export DH_VERBOSE=1
 
 export PYBUILD_NAME=sphinxcontrib.nwdiag
-export PYBUILD_BEFORE_TEST=cp -r {dir}/tests {build_dir}
+#export PYBUILD_BEFORE_TEST=cp -r {dir}/tests {build_dir}
+export PYBUILD_DISABLE=test
 
 %:
dh $@ --with python2,python3 --buildsystem=pybuild


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Processed: sphinxcontrib-nwdiag: diff for NMU version 0.9.0-1.1

[Debian Bug Tracking System]

Processing control commands:

> tags 768708 + patch
Bug #768708 [src:sphinxcontrib-nwdiag] sphinxcontrib-nwdiag: FTBFS in jessie: 
unsatisfiable build-dependencies: python-sphinx-testing, python3-sphinx-testing
Added tag(s) patch.
> tags 768708 + pending
Bug #768708 [src:sphinxcontrib-nwdiag] sphinxcontrib-nwdiag: FTBFS in jessie: 
unsatisfiable build-dependencies: python-sphinx-testing, python3-sphinx-testing
Added tag(s) pending.

-- 
768708: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768708
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Processed: Re: Bug#765071: Change in severity

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + moreinfo unreproducible
Bug #765071 [mediatomb] mediatomb: No icons in web ui
Added tag(s) unreproducible and moreinfo.
> severity -1 normal
Bug #765071 [mediatomb] mediatomb: No icons in web ui
Severity set to 'normal' from 'grave'

-- 
765071: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765071
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#765071: Change in severity

[Sebastian Ramacher]

Control: tags -1 + moreinfo unreproducible
Control: severity -1 normal

On 2014-11-17 20:38:25, Michele Cane wrote:
> Hi,
> 
> I decided to change the severity to grave since I am not able to use
> the program.
> When I reach the webpage from any device the icons are not displayed
> and therefore I cannot add folders.
> 
> Here the errors from the chromium console:
> 
> Uncaught SyntaxError: Unexpected token { prototype.js:2636
> Uncaught SyntaxError: Unexpected identifier nanotree.js:51
> Uncaught SyntaxError: Unexpected token } tree.js:31
> Uncaught TypeError: Cannot read property 'src' of null
> chrome-extension://mmoheajlpfaigefceljflpohdehkjbli/findblog.js:12
> Uncaught ReferenceError: Try is not defined 192.168.2.101/:65
> Error in response to storage.get: TypeError: Cannot read property
> 'data-pin-hover' of undefined
> at Object.eval [as callback] (eval at 
> (chrome-extension://gpdjojdkbbmdfjfahjcgigfpmkopogic/hoverbuttons.js:4:11),
> :579:28) 192.168.2.101/:1
> 
> I am available for providing any additional info.
> 
> Cheers

This is not reproducible with a fresh install of mediatomb. We have
tried it with iceweasel and chromium and all icons are displayed
correctly.

Do you have any extensions installed that mess with your browser?

I'm downgrading the bug since I don't think this is a bug in mediatomb.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: Digital signature

Processed: sphinxcontrib-seqdiag: diff for NMU version 0.8.0-1.1

[Debian Bug Tracking System]

Processing control commands:

> tags 768765 + patch
Bug #768765 [src:sphinxcontrib-seqdiag] sphinxcontrib-seqdiag: FTBFS in jessie: 
unsatisfiable build-dependencies: python-sphinx-testing, python3-sphinx-testing
Added tag(s) patch.
> tags 768765 + pending
Bug #768765 [src:sphinxcontrib-seqdiag] sphinxcontrib-seqdiag: FTBFS in jessie: 
unsatisfiable build-dependencies: python-sphinx-testing, python3-sphinx-testing
Added tag(s) pending.

-- 
768765: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768765
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#768765: sphinxcontrib-seqdiag: diff for NMU version 0.8.0-1.1

[Tobias Frost]

Control: tags 768765 + patch
Control: tags 768765 + pending

Dear maintainer,

I've prepared an NMU for sphinxcontrib-seqdiag (versioned as 0.8.0-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru sphinxcontrib-seqdiag-0.8.0/debian/changelog 
sphinxcontrib-seqdiag-0.8.0/debian/changelog
--- sphinxcontrib-seqdiag-0.8.0/debian/changelog2014-10-25 
06:43:22.0 +0200
+++ sphinxcontrib-seqdiag-0.8.0/debian/changelog2014-11-22 
18:35:50.0 +0100
@@ -1,3 +1,11 @@
+sphinxcontrib-seqdiag (0.8.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Disable tests for now, required depedencies are not available in Jessie:
+sphinx-testing, python3-sphinx-testing (Closes: #768765)
+
+ -- Tobias Frost   Sat, 22 Nov 2014 18:33:23 +0100
+
 sphinxcontrib-seqdiag (0.8.0-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru sphinxcontrib-seqdiag-0.8.0/debian/control 
sphinxcontrib-seqdiag-0.8.0/debian/control
--- sphinxcontrib-seqdiag-0.8.0/debian/control  2014-10-25 06:43:53.0 
+0200
+++ sphinxcontrib-seqdiag-0.8.0/debian/control  2014-11-22 18:34:57.0 
+0100
@@ -7,13 +7,11 @@
python-mock,
python-sphinx (>= 0.6),
python-seqdiag (>= 0.9.3),
-   python-sphinx-testing,
python3-all,
python3-setuptools,
python3-mock,
python3-sphinx (>= 0.6),
python3-seqdiag (>= 0.9.3),
-   python3-sphinx-testing
 Standards-Version: 3.9.6
 Section: python
 X-Python-Version: 2.7
diff -Nru sphinxcontrib-seqdiag-0.8.0/debian/rules 
sphinxcontrib-seqdiag-0.8.0/debian/rules
--- sphinxcontrib-seqdiag-0.8.0/debian/rules2014-09-01 04:55:16.0 
+0200
+++ sphinxcontrib-seqdiag-0.8.0/debian/rules2014-11-22 18:34:54.0 
+0100
@@ -4,7 +4,8 @@
 #export DH_VERBOSE=1
 
 export PYBUILD_NAME=sphinxcontrib.seqdiag
-export PYBUILD_BEFORE_TEST=cp -r {dir}/tests {build_dir}
+#export PYBUILD_BEFORE_TEST=cp -r {dir}/tests {build_dir}
+export PYBUILD_DISABLE=test
 
 %:
dh $@ --with python2,python3 --buildsystem=pybuild


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org