Bug#991496: libsndfile: CVE-2021-3246
I m not longer the maintainer of libsndfile. You can contact the new maintainers at https://github.com/libsndfile/ Erik Moritz Mühlenhoff wrote: > Source: libsndfile > X-Debbugs-CC: t...@security.debian.org > Severity: grave > Tags: security > > Hi, > > The following vulnerability was published for libsndfile. > > CVE-2021-3246[0]: > | A heap buffer overflow vulnerability in msadpcm_decode_block of > | libsndfile 1.0.30 allows attackers to execute arbitrary code via a > | crafted WAV file. > > https://github.com/libsndfile/libsndfile/issues/687 > > Patch is here: > https://github.com/libsndfile/libsndfile/commit/deb669ee8be55a94565f6f8a6b60890c2e7c6f32 > > > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. > > For further information see: > > [0] https://security-tracker.debian.org/tracker/CVE-2021-3246 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3246 > > Please adjust the affected versions in the BTS as needed. > -- -- Erik de Castro Lopo http://www.mega-nerd.com/
Bug#912633: Possible conflict betwwen courier-imap and courier-imap-ssl?
Erik de Castro Lopo wrote: > I removed courier-imap-ssl and no i no longer get the "No supported cipher > suite ..." error message. > > I no longer see this problem. Bah, turned out I was connecting to IMAP instead of IMAPS and that is why it was working. After making sure I was using IMAPS I was not longer able to connect, again with the "No supported cipher suite ..." error. I did however manage to fix it my doing "apt purge courier-imap" and then "apt install courier-imap" and after acccepting the new certificate all was well! Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/
Bug#912633: Possible conflict betwwen courier-imap and courier-imap-ssl?
Markus Wanner wrote: > I removed courier-imap-ssl, as it's a transitional package in stretch, > already. It can be removed safely. I removed courier-imap-ssl and no i no longer get the "No supported cipher suite ..." error message. I no longer see this problem. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/
Bug#912633: Possible conflict betwwen courier-imap and courier-imap-ssl?
Hi all, I have just run into this same issue and its a bit of a pain. One thing I notivce however is that I have: # dpkg -l | grep courier-imap ii courier-imap 5.0.5+1.0.5-1 amd64 Courier mail server - IMAP server ii courier-imap-ssl 4.18.1+0.78.0-2 all Courier mail server - IMAP over TLS [transitional] I also notice thatt these two are compiled from different source packages: # apt-cache show courier-imap Package: courier-imap Source: courier (1.0.5-1) Version: 5.0.5+1.0.5-1 # apt-cache show courier-imap-ssl Package: courier-imap-ssl Source: courier (0.78.0-2) Version: 4.18.1+0.78.0-2 I also know that courier-imap-ssl depends on courier-imap but I wonder if the fact they are compiled from different versions of the source package is relevant. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/
Bug#770918: Two CVEs against FLAC
Erik de Castro Lopo wrote: Package: flac Version: 1.3.0-2+b1 Severity: serious Tags: security From: http://lists.xiph.org/pipermail/flac-dev/2014-November/005226.html Google Security Team member, Michele Spagnuolo, recently found two potential problems in the FLAC code base. They are : CVE-2014-9028 : Heap buffer write overflow CVE-2014-8962 : Heap buffer read overflow For Linux distributions, the specific fixes for these two CVEs are available from Git here: https://git.xiph.org/?p=flac.git;a=commit;h=fcf0ba06ae12ccd7c67cee3c8d948df15f946b85 https://git.xiph.org/?p=flac.git;a=commit;h=5b3033a2b355068c11fe637e14ac742d273f076e and are simple enough that they should apply cleanly to the last official release 1.3.0 and possibly even the previous one, 1.2.1. One more patch to cherry pick: https://git.xiph.org/?p=flac.git;a=commit;h=5a365996d739bdf4711af51d9c2c71c8a5e14660 A pre-release (version 1.3.1pre1) for the next version which includes these fixes and more is available here: http://downloads.xiph.org/releases/flac/beta/ A full release (version 1.3.1) will be available in the next couple of days. The 1.3.1 release is available here: http://downloads.xiph.org/releases/flac/ Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770918: Two CVEs against FLAC
Package: flac Version: 1.3.0-2+b1 Severity: serious Tags: security From: http://lists.xiph.org/pipermail/flac-dev/2014-November/005226.html Google Security Team member, Michele Spagnuolo, recently found two potential problems in the FLAC code base. They are : CVE-2014-9028 : Heap buffer write overflow CVE-2014-8962 : Heap buffer read overflow For Linux distributions, the specific fixes for these two CVEs are available from Git here: https://git.xiph.org/?p=flac.git;a=commit;h=fcf0ba06ae12ccd7c67cee3c8d948df15f946b85 https://git.xiph.org/?p=flac.git;a=commit;h=5b3033a2b355068c11fe637e14ac742d273f076e and are simple enough that they should apply cleanly to the last official release 1.3.0 and possibly even the previous one, 1.2.1. A pre-release (version 1.3.1pre1) for the next version which includes these fixes and more is available here: http://downloads.xiph.org/releases/flac/beta/ A full release (version 1.3.1) will be available in the next couple of days. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (500, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.17-rc5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_AU.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages flac depends on: ii libc6 2.19-13 ii libflac8 1.3.0-2+b1 flac recommends no packages. flac suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669156: Illegal bang-pattern (use -XBangPatterns)
Hi all, I have managed to debug this issue. The problem is that upstream ships a file src/Language/JavaScript/Parser/Lexer.hs that was generated by the alex lexer generator. However, compiling alex generated files on big endian systems (like powerpc) requires the BangPatterns LANGUAGE pragma. The reason we don't see this elsewhere is that other projects ship the alex source and Debian's alex is patched to fix this. Unfortunately I was never able to push that patch upstream [0], but maybe its time to try again with a slightly different version of the patch. That brings us to the language-javascript problem. Firstly, we should really ask upstream to ship the Lexer.x file from which the Lexer.hs file is generated. However the reason they reason they ship the haskell source rather than the lexer source is so that its possible to install language-javascript using cabal install. Cabal has one rather severe limitation, it cannot reliably install build tools like alex. Firstly there is no way to specify a dependency on a build tool, secondly cabal install will install it by default in $HOME/.cabal/bin/ and if that is not on the user's PATH, language-javascript will not compile. Cheers, Erik [0] http://trac.haskell.org/haskell-platform/ticket/171 -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669156: Illegal bang-pattern (use -XBangPatterns)
Joachim Breitner wrote: this is just a reminder that alex might have to be fixed to prevent these build errors of haskell-language-javascript on unregistered arches (mips, s390, s390x, sparc): https://buildd.debian.org/status/package.php?p=haskell-language-javascript This is not a problem with unregistered arches so much as big-endian arches (ie it also affects powerpc which is registered I believe). Furthermore, from memorym, the alex generated haskell files have bang patterns on big endian arches but not on little endian. Still working on this. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657414: libsamplerate0: fails to upgrade from squeeze - trying to overwrite man1/sndfile-resample.1.gz
Andreas Beckmann wrote: Package: libsamplerate0 Version: 0.1.8-3 Followup-For: Bug #657414 Hi, still not fixed in 0.1.8-3: Preparing to replace samplerate-programs 0.1.8-2 (using .../samplerate-programs_0.1.8-3_amd64.deb) ... Unpacking replacement samplerate-programs ... dpkg: error processing /var/cache/apt/archives/samplerate-programs_0.1.8-3_amd64.deb (--unpack): trying to overwrite '/usr/share/man/man1/sndfile-resample.1.gz', which is also in package libsamplerate0 0.1.8-2 Are you shipping two copies of the manpage? Package 0.1.8-2 is broken (ie has the manpage in the lib package instead of the samplerate-programs package). What I was trying to fix was the upgrade from 0.1.7 to 0.1.8-3 which was working correctly. I suggest you try downgrading to the 0.1.7 package and then upgrading to 0.1.8-3. That should work correctly. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632494: FTBFS on smd64 if /bin/sh - dash
Mehdi Dogguy wrote: On 0, Erik de Castro Lopo er...@mega-nerd.com wrote: I get a FTBFS even on amd64 if /bin/sh is dash instead of bash. Its the same test that fails: issue1763-pull-fails-on-non-ascii-filenames.sh I saw that you worked around these failures by s@/bin/sh@/bin/bash. I think that this is not the right fix. The real problem is in dash, not in darcs. The next upload of dash should fix this problem (there is nothing to change in darcs's sources, imho). For more details, you can have a look at #642922. Can you please test again (with a fixed dash) and report back? I've just looked at #642922 which states that this should be fixed in dash 0.5.7-2. I am running that version and I disabled the tests-use-bash is the darcs patches and it now fails again with: Running issue1763-pull-fails-on-non-ascii-filenames.sh ...hlibrary.setup: interrupted make: *** [build/libghc-darcs-dev] Error 1 Re-enabling the tests-use-bash patch and the package builds. There is still some important difference between dash and bash. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635113: Generated code fails to compile: uses bang patterns without corresponding {-# LANGUAGE BangPatterns #-} pragma
Josh Triplett wrote:
Package: alex
Version: 2.3.5-2
Severity: grave
The fix for bug 623067 makes alex -g use bang patterns, but doesn't add
the corresponding BangPatterns extension to the list of extensions in
the LANGUAGE pragma at the top of the file. This makes the generated
code fail to compile:
dist/build/apters/apters-tmp/Scanner.hs:294:18:
Illegal bang-pattern (use -XBangPatterns):
! (base)
Any idea which file is it that is missing this pragma? I've just
looked at the patch (which I generated) and it does add the pragma
to alex-2.3.5/src/Scan.x.
--- alex-2.3.5.orig/src/Scan.x
+++ alex-2.3.5/src/Scan.x
@@ -11,7 +11,7 @@
---
{
-{-# OPTIONS_GHC -w #-}
+{-# OPTIONS_GHC -w -XBangPatterns #-}
module Scan(lexer, AlexPosn(..), Token(..), Tkn(..), tokPosn) where
I'm quite a regular user of alex and I'm surprised I haven't run
into this yet.
Cheers,
Erik
--
--
Erik de Castro Lopo
http://www.mega-nerd.com/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635113: Generated code fails to compile: uses bang patterns without corresponding {-# LANGUAGE BangPatterns #-} pragma
Josh Triplett wrote:
That looks like Alex's own lexer, used to build Alex; adding
BangPatterns there seems like the wrong fix, and it *only* fixes Alex
itself, not other users of Alex.
Ah, right.
Instead, Alex should automatically add
{-# LANGUAGE BangPatterns #-} to the generated lexer (or rather, extend
the existing LANGUAGE pragma to include BangPatterns) when it uses
BangPatterns (specifically, when using -g). That would avoid forcing
the project that uses Alex to know that it needs BangPatterns
internally.
Ok, I'll purse that issue.
Projects using Cabal automatically invoke alex with -g when building
with GHC, so this change breaks any project using Cabal and Alex (or any
other project using -g). A quick search turns up various build logs
(from Debian packages and otherwise) of lexers failing to build with
this error.
Also, I hope that the fixed version of this patch can go upstream to fix
other users of alex, since otherwise a project building on Debian and
using -Wall -Werror will fail to build when not using Debian alex.
I have definitely tried:
http://trac.haskell.org/haskell-platform/ticket/141
http://trac.haskell.org/haskell-platform/ticket/171
Apparently this will be fixed in ghc-7.2 which should be released
around september this year.
Erik
--
--
Erik de Castro Lopo
http://www.mega-nerd.com/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632494: FTBFS on smd64 if /bin/sh - dash
Hi, I get a FTBFS even on amd64 if /bin/sh is dash instead of bash. Its the same test that fails: issue1763-pull-fails-on-non-ascii-filenames.sh Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576250: I get the same with both fedora-10 and fedora-12.
Richard W.M. Jones wrote: On Thu, Apr 08, 2010 at 01:39:00PM +1000, Erik de Castro Lopo wrote: Hi, I ran the commands (also tried with fedora-12 with same result): mkdir fed10-64 febootstrap fedora-10 fed10-64 http://mirror/pub/fedora/linux/releases/10/Everything/x86_64/os Which package is this? ii febootstrap 2.1-4tool for bootstrapping a Fedora system (like Debian debootstrap) Segfaults are in any case caused by incompatibilities between glibc in the host and appliance. You have to only install an operating system which is compatible with the host OS. I use debootstrap to install debian and ubuntu versions in chroots. I have installed ubuntu 8.04 on debian testing and a bunch of other combinations and never seen that before. In Fedora we recommend only installing (eg) Fedora 12 on Fedora 12, because that way you know that glibc won't have problems. So why is febootstrap even made available to be installed under debian? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576250: I get the same with both fedora-10 and fedora-12.
Richard W.M. Jones wrote: On Thu, Apr 08, 2010 at 08:17:16PM +1000, Erik de Castro Lopo wrote: Which package is this? ii febootstrap 2.1-4tool for bootstrapping a Fedora system (like Debian debootstrap) This is kind of old, I really need to update this to the latest version. Thanks. I'll try again when the new version is available. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576250: I get the same with both fedora-10 and fedora-12.
Hi, I ran the commands (also tried with fedora-12 with same result): mkdir fed10-64 febootstrap fedora-10 fed10-64 http://mirror/pub/fedora/linux/releases/10/Everything/x86_64/os which seemed to go ok but than at the end it does this: Failed: filesystem.x86_64 0:2.4.19-1.fc10 Complete! /usr/bin/fakeroot: line 1: 5294 Segmentation fault exit $RESULT /usr/bin/fakeroot: line 1: 5295 Segmentation fault exit $RESULT /usr/bin/fakeroot: line 1: 5296 Segmentation fault exit $RESULT /usr/bin/fakeroot: line 1: 5297 Segmentation fault exit $RESULT /usr/bin/fakeroot: line 1: 5298 Segmentation fault exit $RESULT /usr/bin/fakeroot: line 1: 5299 Segmentation fault exit $RESULT /usr/bin/fakeroot: line 1: 5300 Segmentation fault exit $RESULT /usr/bin/fakeroot: line 1: 5301 Segmentation fault exit $RESULT /usr/bin/fakeroot: line 1: 5302 Segmentation fault exit $RESULT /usr/bin/fakeroot: line 1: 5303 Segmentation fault exit $RESULT /usr/bin/fakeroot: line 1: 5304 Segmentation fault exit $RESULT /usr/bin/fakeroot: line 1: 5305 Segmentation fault exit $RESULT /usr/bin/fakeroot: line 1: 5306 Segmentation fault exit $RESULT /usr/bin/fakeroot: line 1: 5307 Segmentation fault exit $RESULT /usr/bin/fakeroot: line 1: 5308 Segmentation fault exit $RESULT /usr/bin/fakeroot: line 1: 5309 Segmentation fault exit $RESULT /usr/bin/fakeroot: line 1: 5310 Segmentation fault exit $RESULT /usr/bin/fakeroot: line 1: 5311 Segmentation fault exit $RESULT /usr/bin/fakeroot: line 1: 5312 Segmentation fault exit $RESULT /usr/bin/febootstrap: line 246: 5313 Segmentation fault rm -rf $target/var/cache/yum/febootstrap /usr/bin/febootstrap: line 246: 5314 Segmentation fault rm -rf $target/var/cache/yum/febootstrap-updates /usr/bin/febootstrap: line 93: 5315 Segmentation fault rm -rf $target/var/cache/yum/febootstrap-updates Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574112: Shotwell startup bug
Adam, you reported that Shotwell won't start up on your system. Are you still having this problem? Funny enough, no I'm not. I'm pretty sure that I would have had librsvg2-2 last time I tried, but now the problem is gone. Feel free to close this bug. Thanks, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574112: shotwell: Crashes with 'Couldn't recognize the image file format'
Package: shotwell Version: 0.5.0+dfsg-1 Severity: grave Justification: renders package unusable Running shotwell from the command line results in: ** ERROR **: Resources.vala:314: Couldn't recognize the image file format for file '/usr/share/shotwell/icons/object-rotate-right.svg' aborting... Aborted -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.31-19-generic (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to POSIX) Shell: /bin/sh linked to /bin/dash Versions of packages shotwell depends on: ii libatk1.0-0 1.28.0-1The ATK accessibility toolkit ii libc62.10.2-6Embedded GNU C Library: Shared lib ii libcairo21.8.10-3The Cairo 2D vector graphics libra ii libdbus-1-3 1.2.20-2simple interprocess messaging syst ii libdbus-glib-1-2 0.84-1 simple interprocess messaging syst ii libexif120.6.19-1library to parse EXIF files ii libfontconfig1 2.8.0-2 generic font configuration library ii libfreetype6 2.3.11-1FreeType 2 font engine, shared lib ii libgconf2-4 2.28.0-1GNOME configuration database syste ii libgee2 0.5.0-3 GObject based collection library ii libglib2.0-0 2.22.4-1The GLib library of C routines ii libgphoto2-2 2.4.6-1 gphoto2 digital camera library ii libgphoto2-port0 2.4.6-1 gphoto2 digital camera port librar ii libgtk2.0-0 2.18.7-1The GTK+ graphical user interface ii libgudev-1.0-0 151-3 GObject-based wrapper library for ii libpango1.0-01.26.2-1Layout and rendering of internatio ii libsoup2.4-1 2.29.91-1 an HTTP library implementation in ii libsqlite3-0 3.6.23-1SQLite 3 shared library ii libunique-1.0-0 1.1.6-1 Library for writing single instanc ii libusb-0.1-4 2:0.1.12-14 userspace USB programming library ii libwebkit-1.0-2 1.1.22-1Web content engine library for Gtk ii libxml2 2.7.6.dfsg-2+b1 GNOME XML library shotwell recommends no packages. shotwell suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556819: [Pkg-haskell-maintainers] Bug#556819: What about fixing those trivial bugs?
Cyril Brulebois wrote: Those trivial bugs have been around for quite some time. Any chance to get them fixed? Some packages are blocked in the BD-Uninstallable state because of those missing packages. I am working on this one: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=556819 All of may changes so far are in Git: http://git.debian.org/?p=pkg-haskell/haskell-convertible.git;a=summary Unfortunately it is not as trivial as you make out. The probelms I am still stuck with are: a) It won't build with git-buildpackage (git issue, possibly a missing upstream branch?). b) It fails under pbuilder: Building convertible-1.0.6... hlibrary.setup: Distribution/Simple/PreProcess.hs:342:8-69: Irrefutable pattern failed for pattern Data.Maybe.Just cpphsProg I had planned to spend some more time on this over this weekend. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558230: libghc6-regex-compat-dev: Package is uninstallable
Package: libghc6-regex-compat-dev Version: 0.92-3 Severity: grave Justification: renders package unusable Package is not installable: prompt apt-get install libghc6-regex-compat-dev Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libghc6-regex-compat-dev: Depends: libghc6-regex-posix-dev ( 0.93.1+) but 0.93.2-4 is to be installed -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.31-14-generic (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to POSIX) Shell: /bin/sh linked to /bin/dash Versions of packages libghc6-regex-compat-dev depends on: ii ghc6 6.10.4-1 GHC - the Glasgow Haskell Compilat ii libc6 2.10.2-2 GNU C Library: Shared libraries ii libffi5 3.0.9~rc3-1Foreign Function Interface library ii libghc6-regex-base-dev0.93.1-5 GHC 6 library providing an API for pn libghc6-regex-posix-dev none (no description available) ii libgmp3c2 2:4.3.1+dfsg-3 Multiprecision arithmetic library libghc6-regex-compat-dev recommends no packages. Versions of packages libghc6-regex-compat-dev suggests: pn libghc6-regex-compat-doc none (no description available) pn libghc6-regex-compat-prof none (no description available) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550769: [Pkg-haskell-maintainers] Bug#550769: haskell-regex-compat: FTBFS: Missing Build-Depends
Daniel Schepler wrote: [ ! -x /usr/bin/haddock ] || debian/hlibrary.setup haddock --hyperlink-source hlibrary.setup: hscolour version =1.8 is required but it could not be found. This has been fixed in Darcs: http://darcs.debian.org/pkg-haskell/haskell-regex-compat/changelog but has not yet been released. Probably time to push that one out. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518037: Progress made
Hi, Progress has been made. Building libsndfile on MIPS (very, very slow qemu emulation) with debian sid passed all tests, while on powerpc debian testing still fails. It turns out this is indeed a problem with libvorbis. Sid has libvorbis version 1.2.3 which does not display this problem (at least on powerpc) while Testing has libvorbis 1.2.0 which fails on powerpc. I have raised this bug against libvorbis in Testing: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549899 and I am now in the process of rolling a new package for libsndfile which depends on libvorbis = 1.2.3. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549620: ssh: slogin segfaults on MIPS
repla ssh recommends no packages. ssh suggests no packages. -- no debconf information -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518037: What can I do to help?
Kurt Roeckx wrote: It is not fixed. The test suite error is just being ignored. The bug report indicated this already. The version in testing does not have this bug. So what needs to happen is to fix the regression tests. It would probably also be helpful that the testsuite error resulted in a failure to built again. libsndfile came up for adoption earlier this week and since I am the upstream developer I filed an ITA. I have a day off work on Friday and intend to put a good number of hours into libsndfile on Debian. One of the first things I will be doing is to make testsuite failures a fail to build. I am also trying to get access to a MIPS or MIPSEL machine which has been proving difficult. I'm going to try running up a Debian MIPS image under QEMU. Failing that I will spending some time hacking with a DD and he's going to see if he can get access to one of the Debian porter machines. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539687: marked as done (libogg-dev: Removal of .la should have been coordinated with other packages)
Ron wrote: At least upstream seems active on that one. And the maintainer was around to respond to #518037 in March, even if their response wasn't entirely satisfactory and upstream themselves asked to reopen it :/ So he's not entirely MIA ... OTOH, Erik, the upstream maintainer, does seem to be maintaining some other packages, so perhaps we should give him a thumbs up to hijack this one and look after it himself. Added to the CC also. Erik, how do you feel about that ;? Sorry, what question is it that I'm supposed to be answering here? Yes, I am a DM, but I am not a DD. Most of my debian work has been around the Haskell programming language. I've been pretty happy with the way libsndfile has been maintained, but if it was to be orphaned, I'd be happy to adopt it. AFAICS, libsndfile is currently maintained. Did you contact the maintainers announcing you would drop the .la file? If so, then one could indeed argue that the maintainers should know what is happening. Though now it looks like the maintainers are not aware and most probably think there is an issue with libogg AFAICS. Not all of them. There was mail traded with John Ferlito, who should be adopting libtheora, libvorbis, libspiff, vorbis-tools, uriparser, libao, so I considered those covered, likewise the other xiph codecs I maintain which already have their .la removed. I'm think I'm coming in rather late on this, but why were these .la files removed? I've read through bug#539687 and its still not clear. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539687: marked as done (libogg-dev: Removal of .la should have been coordinated with other packages)
Ron wrote: My apologies then, Luk was querying if the regular maintainer was MIA, if you don't think so, that's pretty much all the answer we need on that. #518037 is release critical though, and remains open still. Is there a suitable fix for that in the works? That one is basically down to me. I have found someone on the debian-mips list that is willing to give me access to a MIPS machine. Unfortunately, I've been busy and not had a chance to start work on it. I hope that will change over the next couple of weeks. On Debian systems they add nothing but another point of failure. At best, if they are perfectly correct, they are exactly equivalent to not having one at all, in almost every case and certainly for this library. Well, until libogg.la was removed all evidence I am aware of pointed to them as being in perfect working order. At worst, when they are wrong, the effects range from what was reported in #539889, That was an aesthetic bug at best. to what has happened here until all the rdeps have been rebuilt again. For this one libsndfile was working and a change in libogg broke it. Futhermore, the use of the .la file is the default mode of operation for autoconf/automake/libtool that libsndfile uses for configuration. it was not brought about by some custom hack. Basically all we really need to know from you or Samuel is will this package be uploaded in the near future, preferably with a fix to the outstanding RC bug, or should it be added to the list of packages that will just get a binNMU. Thats Samuel's call, but if it was up to me, I would say that whoever broke libsndfile by removing libogg.la should be doing a binNMU. Regards, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539687: marked as done (libogg-dev: Removal of .la should have been coordinated with other packages)
Peter Samuelson wrote: [Erik de Castro Lopo] I'm think I'm coming in rather late on this, but why were these .la files removed? I've read through bug#539687 and its still not clear. I can't speak for Ron, Thanks Peter, you'll do. but in general, the reason to remove .la files is that pkg-config (and the .pc files in /usr/lib/pkgconfig) offers the same functionality, and more, with considerably less brokenness. I'm a big fan of pkg-config. Its a good solution to the problem. We'd like to encourage upstreams to ship .pc files and use pkg-config in their configure.ac scripts as the primary means of detecting the presence of other libraries and how to use them. And libsndfile has been using pkg-config for detecting all the libraries it uses for at least three years. The problem is that using the default pkg-config/autoconf/automake/libtool behaviour to detect libxyz that ships libxyz.la file will create a (probably unnecessary) dependency on that libxyz.la file. I know this is 20/20 hindsight, but this could have been handled much better by raising bugs against and fixing all the client libraries *before* removing the libogg.la. It would probably also be a good idea to discourage the shipping .la files in the debian policy manual and adding it as a lintian warning. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539687: marked as done (libogg-dev: Removal of .la should have been coordinated with other packages)
Ron wrote: Just to be clear, this has nothing to do with pkg-config at all. Using pkg-config isn't an alternate solution to the problem, since there is no problem that the .la are solving for us here. I could remove the .pc files for this lib too, and it would still be perfectly functional, but that could be genuinely disruptive and may require some people to edit their source, so I'm not currently planning that. Even if I do think it's a gross overkill for this particular package to be using it in the first place. I think your view is way too narrow. I'm a developer. As well as hacking on libsndfile, I also hack on libogg and libvorbis (I have SVN commit access). While hacking on these I often install the current SVN versions in my home directory, and then test other packages compiling against my home dir versions. With pkg-config the above scenario works perfectly and I don't have to un-install the Debian versions (and all the programs that depend on them). Most importantly I don't have to hack my configure.ac just to test an alternate version of the library. The pkg-config solution also works really well for cross compiling: http://www.mega-nerd.com/erikd/Blog/CodeHacking/MinGWCross/pkg-config.html http://www.mega-nerd.com/erikd/Blog/CodeHacking/MinGWCross/cross_compiling.html http://www.mega-nerd.com/erikd/Blog/CodeHacking/MinGWCross/cross_compiling_2.html I should mention here that I release pre-compiled win32 and win64 binaries for libsndfile on my web site. These binaries (including support for Ogg/Vorbis and FLAC) are cross-compiled from a Debian system and the test suite for the win32 version is run under Wine (which does not yet support win64 binaries). I released the first version of libsndfile in 1998 targeted mainly at Linux systems (it now runs on just aboue everything). I've seen a lot of change and I can tell you that no solution to the above problems has ever worked as well as pkg-config. Just because *you* don't see a use for pkg-config doesn't mean that it isn't valuable to anyone else. On any system with a functional linker and properly installed libraries (ie. every Debian system), ALL you need for this library is '-logg'. That's it. That is true if and only if you are targeting Debian at end users. I chose Debian because it was a good development system. I need to be able to point my compiles at other versions of libogg with minimal fuss and bother. pkg-config lets me (and many others) do that. If you want to use Big Hammer infrastructure, designed for horrors like gtk dependencies, and a more complex incantation to get that, then that's your choice. But you don't _need_ any of those things to use this library. So how do you suggest I test more recent versions of libogg or libvorbis? How do you suggest I cross compile for windows or even for arm-linux. Regards, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540177: libsndfile1-dev: libsndfile.la references now non-existant libogg.la
Tim Muller wrote: since the latest (August 2nd) libogg package no longer ships libogg.la, libsndfile.la now references a non-existant libogg.la, which leads to link failures when trying to link libshout with libtool. I'm not the Debian maintainer, just the upstream author. I think what is needed here is a binNUM as suggested here: http://lists.debian.org/debian-release/2009/08/msg00034.html Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518037: What can I do to help?
Kurt Roeckx wrote: This bug is indeed blocking the transition. Version 1.0.20-1 was built succesfully, but the testsuite error is now being ignored and the package built succesfully. Personally I think ignoring errors thrown up by the test suite is a bad idea. For instance the libsndfile testsuite found a bug in gcc's code generator when generating ARMEL code for libvorbis. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515949 So the question is: - Do you think it should migrate to testing as is or not? No I don't. There is still a question mark over the functionality on MIPS. It should be investigated properly. Reason why you could think it should migrate: - This bug affects the version in stable (1.0.17-4+lenny2) and/or This bug affects functionality that was not present in 1.0.17. testing (1.0.18-2), and so is not a regression. If you mark it as found in those version, it will migrate. This bug did not affect 1.0.18 because Ogg/Vorbis support was not enabled at build time (missing Build-Depends). Hence, it is not a regression. - It's not a release critical bug, it's only a minor functionaly that's broken and it's mostly ussable even with this. You could change the severity so it's not release critical. I'm concerned about people using libsndfile to convert audio data to Ogg/Vorbis and deleting the source before listening to output files. Doing this could result in lost input files and garbage output files. Anyway, try to fix this bug, I see this in the various built logs: arm: Line 231: Actual SNR ( 0.0) target SNR (-31.0). Arm we know about. Thats a code generator bug in the ARM gcc. mips: Line 231: Actual SNR ( 57.4) target SNR (-31.0). hppa: Line 231: Actual SNR ( 57.4) target SNR (-31.0). ia64: Line 231: Actual SNR ( 58.7) target SNR (-31.0). mipsel: Line 231: Actual SNR ( 57.4) target SNR (-31.0). powerpc: Line 279: Actual SNR ( 59.3) target SNR (-29.0). These are probably instances of the same bug. alpha: test_wrapper.sh: line 33: 20915 Floating point exception./floating_point_test And that is another issue. If you want access to a certain arch, it's probably best to mail the porter list for that arch. If you can make a standalone test program for any of those issues I can test them on the various arches for you, but it will probably go faster if you can test things yourself. I'll try the porters lists, probably starting with MIPS. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518037: What can I do to help?
Hi all, I am the main upstream author of libsndfile and I am also a Debain Maintainer (ie not a DD). This bug is currently blocking the transition of libsndfile from unstable to testing. Is there anything I can do to help? Does anyone have a MIPS machine they can give me SSH access to? Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525800: Please close this bug
It was logged agains the wrong package. The subject line is right, but the Pakcage and Version in the bug report test are not. I will resubmit against the right package. -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527987: haxml : Source package has broken build depenancies
Package: haxml Version: 1.17-6 Severity: grave Justification: renders package unusable Can't build this on Sid. Trying to get build-deps: prompt # apt-get build-dep libghc6-haxml-dev Reading package lists... Done Building dependency tree Reading state information... Done Pack age libghc6-base-doc is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package libghc6-base-doc has no installation candidate E: Failed to satisfy Build-Depends-Indep dependency for haxml: libghc6-base-doc -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.27-7-generic (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/bash -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525800: haxml : Source package has broken build depenancies
Package: haskell-vty Version: 3.0.1-1build1 Severity: grave Justification: renders package unusable Try to get build-deps on Sid: prompt # apt-get build-dep libghc6-haxml-dev Reading package lists... Done Building dependency tree Reading state information... Done Pack age libghc6-base-doc is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package libghc6-base-doc has no installation candidate E: Failed to satisfy Build-Depends-Indep dependency for haxml: libghc6-base-doc -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.27-7-generic (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/bash -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519789: libghc6-regex-base-dev: Doesn't install on Debian unstable
Stefano Zacchiroli wrote: On Sun, Mar 15, 2009 at 07:26:43PM +1100, Erik de Castro Lopo wrote: Package: libghc6-regex-base-dev Severity: grave Justification: renders package unusable The package doesn't install because it is compiled against ghc-6.8.2 and debian unstable has ghc-6.10.1. Trying to install in a sid chroot results in: Works for me, at least on Debian/unstable of today, amd64 architecture. Yep, just tried it and it works. From /usr/share/doc/libghc6-regex-base-dev/changelog.Debian.gz: haskell-regex-base (0.93.1-3.1) unstable; urgency=low * Rebuild against GHC 6.10. * NMU with permission of maintainer. -- John Goerzen jgoer...@complete.org Mon, 16 Mar 2009 10:09:14 -0500 about a day after I logged the bug :-). This bug can be closed. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523296: haskell-vty: libghc6-vty-dev won't install on sid
Package: haskell-vty Version: 3.0.1-1build1 Severity: grave Justification: renders package unusable prompt # apt-get install libghc6-vty-dev Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libghc6-vty-dev: Depends: ghc6 ( 6.8.2dfsg1-999) but 6.10.1+dfsg1-13 is to be installed E: Broken packages -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.27-7-generic (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/bash -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522742: libghc6-haxml-dev does not install in sid
Package: libghc6-haxml-dev Severity: grave Justification: renders package unusable Package does not install because it depends on an earlier version of ghc. prompt apt-get install libghc6-haxml-dev Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libghc6-haxml-dev: Depends: ghc6 ( 6.8.2+) but 6.10.1+dfsg1-13 is to be installed -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.27-7-generic (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/bash -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522766: libghc6-http-dev does not install on sid
Package: libghc6-http-dev Severity: grave Justification: renders package unusable Package does not install because it depends on an earlier version of ghc. prompt # apt-get install libghc6-http-dev Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libghc6-http-dev: Depends: ghc6 ( 6.8.2+) but 6.10.1+dfsg1-13 is to be installed Depends: libghc6-network-dev ( 2.1.0.0+) but 2.2.0.1-4 is to be installed Depends: libghc6-parsec-dev ( 2.1.0.0+) but 3.0.0-4 is to be installed E: Broken packages -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.27-7-generic (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/bash -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518037: Update : armel failure is a gcc bug
Erik de Castro Lopo wrote: I'll see if I can come up with a suitable standalone test program for the Arm case. Standalone test case for arm posted to the other bug here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515949 Cheers, Erik -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520454: libghc6-haxml-dev: Needs to be rebuilt with ghc-6.10.1.
Package: libghc6-haxml-dev Severity: grave Justification: renders package unusable Package on unstable requires ghc-6.8.2 but unstable has ghc-6.10.1. Needs to be rebuilt. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.27-7-generic (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518037: Update : armel failure is a gcc bug
I am the upstream author of libsndfile. Earlier in the the history of this bug Kurt Roeckx reported: test_wrapper.sh: line 33: 31486 Floating point exception./floating_point_test - ia64, mips, mipsel, hppa, armel show one of: Line 231: Actual SNR ( 58.7) target SNR (-31.0). Line 231: Actual SNR ( 57.4) target SNR (-31.0). Line 279: Actual SNR ( 59.3) target SNR (-29.0). Line 231: Actual SNR ( 0.0) target SNR (-31.0). I assume this last one is for armel which turned out to be a bug in gcc for that platform: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515949 There is more info in the upstream vorbis bug tracker: https://trac.xiph.org/ticket/1526#comment:6 If someone can run my hacked together test from the bzr repo in that trac comment on ia64, mips, mipsel, hppa etc I'll take a look at it. Cheers, Erik -- - Erik de Castro Lopo - C offers you enough rope to hang yourself. C++ offers a fully equipped firing squad, a last cigarette and a blindfold. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518037: Update : armel failure is a gcc bug
Kurt Roeckx wrote: Line 231: Actual SNR ( 58.7) target SNR (-31.0). Line 231: Actual SNR ( 57.4) target SNR (-31.0). Line 279: Actual SNR ( 59.3) target SNR (-29.0). Line 231: Actual SNR ( 0.0) target SNR (-31.0). Actually, looking at this some more, the failure on Arm (0.0) was vastly different that the one on the other architectures suggesting that the Arm bug is different. It would be nice if this could be reduces to a simple c file that shows the problem. It would simplify testing it on all the arches. This would also help to submit it to the gcc bugtracker if it's a bug in gcc. I'll see if I can come up with a suitable standalone test program for the Arm case. For the others, I am still pretty sure that this is a bug that has been fixed in vorbis SVN. If I could get access to one of these machine I could test it. Any Debian Developer should be able to test all those arches on Debian porter machines. I'm not a DD, but I'm on my way to becoming a DM. I have already had my GPG key signed by two DDs who will vouch for me and I know at least a couple more who would do the same :-). But we'll probably need to ask to install all the required packages first. All thats needed is build-essentials and the SVN and Bzr clients. Erik -- - Erik de Castro Lopo - The question of whether a computer can think is no more interesting than the question of whether a submarine can swim. -- edsger dijkstra -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518037: Update : armel failure is a gcc bug
Kurt Roeckx wrote: DMs don't get access. But I can run any test you want. Ah, so there is an advantage to being a DD :-). All thats needed is build-essentials and the SVN and Bzr clients. I at least needed libogg-dev to be able to build it. Ah yes, forgot that one. It probably also required automake/autoconf. I thought that was part of build-essential. Anyway, the test is as follows: svn co http://svn.xiph.org/trunk/vorbis cd vorbis ./autogen.sh --disable-docs make check If the (rather minimal) test suite passes then this is almost certainly this bug: https://trac.xiph.org/ticket/1229 which was fixed with this commit: https://trac.xiph.org/changeset/13657 For a final sanity check, you could probably test either side of that changeset. Erik -- - Erik de Castro Lopo - Everything that I've learned about computers I have boiled down into three principles: PC/Windows: You think it won't work, and it won't. Macintosh: You think it will work, but it won't. Unix: You think it won't work, but if you find the right guru, you can make it work. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518037: Please reopen this bug.
I am the upstream author of libsndfile. From the 1.0.19-2 debian/changelog: * Ignore failures of check since it causes too many false negatives, closes: #518037, #519338. The second one (#519338) reported on amd64 : vorbis_test: vorbis_test.oga . Error : max_abs 1.020731 should be 1.02. This one is definitely fixed by the patch I provided. The first one (#518037) reported : float_scaled_test : flac_16.flac -90.7dB SNR ... ok float_scaled_test : flac_24.flac -138.6dB SNR ... ok float_scaled_test : vorbis.oga .. Line 231: Actual SNR ( 57.4) target SNR (-31.0). This one is definitely not fixed and should not be ignored. I am however pretty certain that this is test failure is related to this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515949 In general I think it is a bad idea to ignore the pass/fail status of these tests, especially with an upstream as responsive as I am. Cheers, Erik -- - Erik de Castro Lopo - C++ : Where friends have access to your private members. -- Gavin Russell Baker -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519789: libghc6-regex-base-dev: Doesn't install on Debian unstable
Package: libghc6-regex-base-dev Severity: grave Justification: renders package unusable The package doesn't install because it is compiled against ghc-6.8.2 and debian unstable has ghc-6.10.1. Trying to install in a sid chroot results in: The following packages have unmet dependencies: libghc6-regex-base-dev: Depends: ghc6 ( 6.8.2+) but 6.10.1+dfsg1-13 is to be installed Depends: libghc6-mtl-dev ( 1.1.0.0+) but 1.1.0.2-6 is to be installed -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.27-7-generic (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/bash -- - Erik de Castro Lopo - Question #2459: Ruling on shaking hands with the opposite sex http://islamqa.com/index.php?ln=engds=qalv=browseQR=2459dgn=4 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519338: libsndfile1: FTB - When building on AMD64 built in test suite fails for vorbis audio
Erik de Castro Lopo wrote: There is another issue that affects mips, hppa and some others which I haven't managed to fix yet. I have an old mipsel machine, but I currently can't find the power supply for it. I strongly suspect that this second issue is related to this bug: http://bugs.debian.org/515949 If anyone can give me ssh access to a Debian machine with one of the problematic architectures I can have a look. Erik -- - Erik de Castro Lopo - Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519338: libsndfile1: FTB - When building on AMD64 built in test suite fails for vorbis audio
Steve Fosdick wrote:
Package: libsndfile1
Version: 1.0.19-1
Severity: serious
Justification: no longer builds from source
Attempting to build this from source the built in test suite fails. Here is
the last few lines:
ogg_seek_test : vorbis_double.oga ... ok
ogg_stereo_seek_test : vorbis_seek.ogg . ok
vorbis_test: vorbis_test.oga .
Error : max_abs 1.020731 should be 1.02.
I'm the upstream author of libsndfile. I have already supplied a patch
for this issue (max_abs 1.020731 should be 1.02). See below.
There is another issue that affects mips, hppa and some others which
I haven't managed to fix yet. I have an old mipsel machine, but I
currently can't find the power supply for it.
Cheers,
Erik
--- libsndfile-1.0.19/tests/vorbis_test.c 2009-02-22 10:06:45.0
+1100
+++ libsndfile-1.0.19-hacked/tests/vorbis_test.c2009-03-04
11:41:07.0 +1100
@@ -96,8 +96,8 @@
for (k = 0 ; k ARRAY_LEN (float_data) ; k ++)
max_abs = max_float (max_abs, fabs (float_data [k])) ;
- if (max_abs 1.02)
- { printf (\n\nError : max_abs %f should be 1.02.\n\n,
max_abs) ;
+ if (max_abs 1.021)
+ { printf (\n\nError : max_abs %f should be 1.021.\n\n,
max_abs) ;
exit (1) ;
} ;
make[2]: *** [check] Error 1
make[2]: Leaving directory
`/home/fozzy/computing/software/debian/libsndfile-1.0.19/tests'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory
`/home/fozzy/computing/software/debian/libsndfile-1.0.19'
make: *** [build-stamp] Error 2
dpkg-buildpackage: failure: debian/rules build gave error exit status 2
-- System Information:
Debian Release: 5.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.28.7-ecrins
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libsndfile1 depends on:
ii libc6 2.7-18 GNU C Library: Shared libraries
ii libflac8 1.2.1-1.2 Free Lossless Audio Codec -
runtim
libsndfile1 recommends no packages.
libsndfile1 suggests no packages.
-- no debconf information
--
-
Erik de Castro Lopo
-
Software is largely a service industry operating under the persistent
but unfounded delusion that it is a manufacturing industry.
-- Eric S. Raymond
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518037: libsndfile_1.0.19-1(mips/unstable): FTBFS on mips. regression test failure.
Kurt Roeckx wrote: On Wed, Mar 04, 2009 at 11:42:37AM +1100, Erik de Castro Lopo wrote: Samuel Mimram wrote: The thing is that the build failed on every arch (except i386), see : https://buildd.debian.org/build.php?pkg=libsndfile I've just confirmed this on Debian Testing on Amd64. Note that there are 3 errors in the buildd logs: - alpha shows: test_wrapper.sh: line 33: 31486 Floating point exception./floating_point_test - ia64, mips, mipsel, hppa, armel show one of: Line 231: Actual SNR ( 58.7) target SNR (-31.0). Line 231: Actual SNR ( 57.4) target SNR (-31.0). Line 279: Actual SNR ( 59.3) target SNR (-29.0). Line 231: Actual SNR ( 0.0) target SNR (-31.0). Those are a separate issue that I missed before. I'll have a look. - amd64, s390 and powerpc show: Error : max_abs 1.020731 should be 1.02. This is the one my patch fixed. I have no idea what this test is testing exactly. As the upstream author of libsndfile I can tell you that for what that is testing, the difference between 1.02 and 1.021 is irrelevant. Its a product of floating point rounding inside libvorbis. I did all my development and testing with libvorbis from SVN which due to some improvements, gave results 1.02. The libvorbis in debian is older and produces slightly worse results for that test. But either the test is wrong, or the result is wrong. The test is right for libvorbis-1.2.1 (still unreleased) and later but wrong for libvorbis 1.2.1. Erik -- - Erik de Castro Lopo - life is too long to be an expert at harmful things, including such evilness as C++ and perl. -- Erik Naggum -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518037: libsndfile_1.0.19-1(mips/unstable): FTBFS on mips. regression test failure.
Peter De Schrijver wrote: Package: libsndfile Version: 1.0.19-1 Severity: serious There was an error while trying to autobuild your package: Automatic build of libsndfile_1.0.19-1 on mayr by sbuild/mips 99.999 Build started at 20090303-1511 snip float_scaled_test : pcm_16.sds .. -140.5dB SNR ... ok float_scaled_test : pcm_24.sds .. -181.3dB SNR ... ok float_scaled_test : flac_8.flac . -41.9dB SNR ... ok float_scaled_test : flac_16.flac -90.7dB SNR ... ok float_scaled_test : flac_24.flac -138.6dB SNR ... ok float_scaled_test : vorbis.oga .. Line 231: Actual SNR ( 57.4) target SNR (-31.0). This is highly unlikely to be a bug in libsndfile and very much more likely to be a bug in libvorbis or the tool chain used to build it. Unfortunately, without access to a MIPS machine there's very little I can do to help ATM. Erik -- - Erik de Castro Lopo - Reality is just a crutch for people that can't handle CyberSpace!! - Hank Duderstadt -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518037: libsndfile_1.0.19-1(mips/unstable): FTBFS on mips. regression test failure.
Samuel Mimram wrote:
The thing is that the build failed on every arch (except i386), see :
https://buildd.debian.org/build.php?pkg=libsndfile
I've just confirmed this on Debian Testing on Amd64.
The following patch fixes it.
Cheers,
Erik
--- libsndfile-1.0.19/tests/vorbis_test.c 2009-02-22 10:06:45.0
+1100
+++ libsndfile-1.0.19-hacked/tests/vorbis_test.c2009-03-04
11:41:07.0 +1100
@@ -96,8 +96,8 @@
for (k = 0 ; k ARRAY_LEN (float_data) ; k ++)
max_abs = max_float (max_abs, fabs (float_data [k])) ;
- if (max_abs 1.02)
- { printf (\n\nError : max_abs %f should be 1.02.\n\n,
max_abs) ;
+ if (max_abs 1.021)
+ { printf (\n\nError : max_abs %f should be 1.021.\n\n,
max_abs) ;
exit (1) ;
} ;
--
-
Erik de Castro Lopo
-
I run Linux on pretty much everything except the microwave and
washing machine. Those are tempting targets but would probably
make Telsa extremely cross. -- Alan Cox
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#443386: CVE-2007-4974 heap overflow via crafted PCM data
Nico Golde wrote: If you fix this bug please include the CVE id in the changelog data. I has already beedn fixed, so there is no mention of the CVE id in the changelog. [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4974 Err, that URL doesn't give me anything useful. Erik -- - Erik de Castro Lopo - Unsolicited Broadcast Email is Forced Pay-per-view Advertising. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443386: CVE-2007-4974 heap overflow via crafted PCM data
Nico Golde wrote: Hi, * Erik de Castro Lopo [EMAIL PROTECTED] [2007-09-21 02:16]: Nico Golde wrote: If you fix this bug please include the CVE id in the changelog data. I has already beedn fixed, so there is no mention of the CVE id in the changelog. At least 1.0.17-3, testing and stable were vulnerable when reporting this issue. Ah, I'm the upstream author and I was talking about my changelog for the code currently in Bzr. [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4974 Err, that URL doesn't give me anything useful. It does give you a link to the gentoo bts where you find a patch. Ok, got it. That was my patch. Cheers, Erik -- - Erik de Castro Lopo - Microsoft VISTA : Virus Infection Spyware Trojans and Adware! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427749: libsndfile - FTBFS: error: 'FLAC_PRIVATE' has no member named 'encbuffer'
Michael Ablassmeier wrote: Package: libsndfile Version: 1.0.17-1 Severity: serious User: [EMAIL PROTECTED] Usertags: qa-ftbfs hi, while doing an archive wide package rebuild your package failed to build from source for the following reason: snip I think this is related to an API change and recent upload of a new FLAC Library, from libflac-dev's changelog: Yep, thats probably right. The upcoming version of libsndfile contains its own subset of the FLAC sources so this won't happen again. Unfortunately, that new version is not quite ready for release yet. Erik -- - Erik de Castro Lopo - There are two kinds of people in the world, those that have children and those that ARE children. Children are selfish, or more accurately ego-centric. Children have a very short-sighted view of the world. Offer a child one lolly now or the whole bag later and before you can say ''Don't chop the dinosaur Daddy!'', it's in the gob. -- my friend Scott -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427749: libsndfile - FTBFS: error: 'FLAC_PRIVATE' has no member named 'encbuffer'
Michael Ablassmeier wrote: indeed, shipping your own flac source and linking against it is more error prone and might lead to further bugs .. (and means also more work ..) Firstly, the main reason I am shipping a subset of the FLAC sources as part of libsndfile is to make building a FLAC enabled libsndfile easier on MacOSX and windows. Secondly, I intend to sync the FLAC sources in libsndfile against FLAC CVS and test it thoroughly before each release. Finally, the current bug in libsndfile (ie not building) was caused by changes to the FLAC API, a problem which can never occur again if I ship a verify subset of the FLAC sources with libsndfile. Erik -- - Erik de Castro Lopo - ...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver. -- Daniel Pead -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427749: libsndfile - FTBFS: error: 'FLAC_PRIVATE' has no member named 'encbuffer'
Michael Ablassmeier wrote: as long as libsndfile can still be dynamically linked against the version in debian this is no problem. Why so that breakages in the FLAC API can break libsndfile again? Ive been in the same situation with streamripper. Thats streamripper this is libsndfile. You are the maintainer of streamripper but not as far as I am aware the maintainer of libsndfile. I think that is Anand Kumria and I do not believe that Anand has any problems with the way I have been releasing libsndfile so far and I know him well enough that he would say something if I screwed up. Erik -- - Erik de Castro Lopo - Only wimps use tape backup: *real* men just upload their important stuff on FTP, and let the rest of the world mirror it ;) -- Linus Torvalds -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336286: libghc6-plugins-dev: Broken paakage.
Package: libghc6-plugins-dev Severity: grave When trying to install this package I get: libghc6-plugins-dev: Depends: ghc6 (= 6.4.1) but 6.4-4.1 is to be installed The ghc version seems a little screwy :-). -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (700, 'testing'), (650, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to POSIX) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336274: libcryptokit-ocaml-dev: Inconsistent assumptions over interface Numerix
Package: libcryptokit-ocaml-dev Version: 1.2-8 Severity: grave The package Numerix (libnumerix-ocaml-dev) is required when linking to to package Cryptokit (libcryptokit-ocaml-dev), but when I try to link I get: ocamlopt -o test -I /usr/lib/ocaml/3.08.3/numerix -I /usr/lib/ocaml/3.08.3/cryptokit \ -ccopt -L/usr/lib/ocaml/3.08.3/cryptokit -cclib -lcryptokit unix.cmxa nums.cmxa \ numerix.cmxa cryptokit.cmxa test.cmx Files /usr/lib/ocaml/3.08.3/cryptokit/cryptokit.cmxa and /usr/lib/ocaml/3.08.3/numerix/numerix.cmxa make inconsistent assumptions over interface Numerix I think that this means that the package libcryptokit-ocaml-dev needs to be recompiled against libnumerix-ocaml-dev. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (700, 'testing'), (650, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to POSIX) Versions of packages libcryptokit-ocaml-dev depends on: ii libcryptokit-ocaml1.2-8 cryptographic algorithm library fo ii libnumerix-ocaml-dev 0.21-1 Numerix big integer library for ii ocaml-nox [ocaml-nox-3.08.3] 3.08.3-8 ML language implementation with a libcryptokit-ocaml-dev recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
