Bug#599639: libcrypto++/libcryptopp and Shared Objects

over time. Crypto++ can also be fetched from SourceForge, which is always up to date. Issue svn checkout https://cryptopp.svn.sourceforge.net/svnroot/cryptopp/trunk/c5 cryptopp/ Jeffrey Walton, Friend of the Crypto++ Library, [1] RTLD_GLOBAL and libcryptopp.so crash, http://groups.google.com

Bug#600128: libcrypto++ shared object missing symbols (library archive OK)

...@bruno:/# nm /usr/lib64/libcryptopp.so | grep g_nullNameValuePairs nm: /usr/lib64/libcryptopp.so: no symbols Jeffrey Walton [1] Errors with multiple loading cryptopp as shared lib on Linux, http://groups.google.com/group/cryptopp-users/browse_thread/thread/68fbc22e8c6e2f48 r...@bruno:/# uname

Bug#600128: Acknowledgement (libcrypto++ shared object missing symbols (library archive OK))

Please close this erroneous report. r...@bruno:/# nm -D /usr/lib/libcrypto++.so | grep g_nullNameValuePairs 006b7cc0 B _ZN8CryptoPP20g_nullNameValuePairsE r...@bruno:/# nm -D /usr/lib64/libcrypto++.so | grep g_nullNameValuePairs 006b7cc0 B _ZN8CryptoPP20g_nullNameValuePairsE Many

Bug#736126: /dev/random entropy depletion on a fresh install

Package: haveged Version: 1.4.4 I installed Debian 7.3 x64 on a Core i5 laptop for some testing (real hardware, not a VM). When testing a program I wrote, I noticed it was not getting the full number of bytes requested from /dev/random: unsigned char buffer[32]; fd = open(/dev/random,

Bug#736126: Processed: Re: Bug#736126: /dev/random entropy depletion on a fresh install

On Mon, Jan 20, 2014 at 8:33 AM, Ben Hutchings b...@decadent.org.uk wrote: noloa...@gmail.com wrote: I installed Debian 7.3 x64 on a Core i5 laptop for some testing (real hardware, not a VM). When testing a program I wrote, I noticed it was not getting the full number of bytes requested from

Bug#733208: Screen Saver Lock Latency: does not activate until computer awakens; ~10 to ~20 second latency after waking computer (desktop is available)

Package: gnome-control-center Version: 1:3.4.3.1-2 I'm working on an old machine that's been re-purposed. The machine is an HP5850 and from circa 2008. It has on Athlon dual-core running about 2.3 GHz with 4GB of RAM. Worse, I'm running two VirtualBox guests on it for OpenStack testing

Bug#804561: GCC can't compile a program using RDSEED intrinsics

Package: g++ Version: 4:5.2.1-4 Severity: normal Control: tags jessie sid Tags: jessie sid ** Another Debian specific bug... GCC can't compile a program using RDSEED intrinsics. It results in an error "error: ‘_rdseed64_step’ was not declared in this scope". According the Intel (which

Bug#804521: Undefined Behavior cleared upstream

tags 804521 + upstream tags 804521 + fixed Jonathan Wakely cleared this issue upstream. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158.

Bug#804521: Thanks for the prompt handling....

I'm still getting the undefined behavior findings. I'd like to thank the Debian folks for their prompt handling of the issue Its pretty clear to me taking the time to report bugs and follow up under this antiquated (and painful) system is a waste of my time. * 30 configurations

Bug#804521: Undefined Behavior in libstdc++ with GCC 5.2.1 in ios_base.h

Package: libstdc++6 Version: 5.2.1-20 Severity: normal Control: tags jessie sid ** On Linux, the distros often use libstdc++ (GNU) rather than libc++ (LLVM) for Clang. Building libcxx is an art that I have never been able to untangle, and I think the maintainers have discovered the same

Bug#803545: C++ header includes AES intrinsics

Package: g++ Version: 4:4.9.2-2 Severity: normal ** I'm catching a compile failure when building a library (not a program). The library is a crypto library called Crypto++ (https://cryptopp.com). Here's the project's bug report on the issue: https://github.com/weidai11/cryptopp/issues/53

Bug#804102: Update on host/platform configuration

Here's an update since using clang++ with -stdlib-libstdc++ (GNU's runtime) may seem odd or cause confusion. I just used whatever the host platform provided. The machine is an old Athlon system I use for testing. This test system happens to include Clang, so the Sanitizer test under Clang gets

Bug#804102: Undefined Behavior in .../include/c++/4.9/bits/ios_base.h

Package: libstdc++6 Source: gcc-4.9 Version: 4.9.2-10 ** I believe the fix is to cast from an Ios_Fmtflags to an unsigned type, perform the bit operations, and then cast back to a Ios_Fmtflags before returning it. I recall seeing this one in some Apple headers. Also see

Bug#804180: Please update Remake

Package: normal Version: 3.82+dbg0.9+dfsg-2 Severity: normal Control: tags jessie sid ** I'm trying to use Remake to debug a problem with a Makefile under a Debian Jessie host with a Debian ARM64 Chroot guest. Its not going well, and I am getting ready to build Remake from sources. It

Bug#804180:

Package remake

Bug#801055: Adding platform ARM64/AARCH64

I'm catching the issue under ARM64/AARCH64, too. debian-arm64:/# uname -a Linux core2 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u5 (2015-10-09) aarch64 GNU/Linux debian-arm64:/# g++ -v Using built-in specs. COLLECT_GCC=/usr/bin/g++

Bug#802546: /usr/sbin/debootstrap: 399: cd: can't cd to http://ftp.debian.org

Package: debootstrap Version: 1.0.72 Severity: normal ** I'm trying to setup a ppc64 QEMU chroot. I'm not sure if PPC64 is available, but I usually get a different error when its not available. The following packages are already installed: qemu binfmt-support qemu-user-static

Bug#802546: /usr/sbin/debootstrap: 399: cd: can't cd to http://ftp.debian.org

On Tue, Oct 20, 2015 at 7:03 PM, Vagrant Cascadian <vagr...@aikidev.net> wrote: > On 2015-10-20, Jeffrey Walton wrote: >> # qemu-debootstrap --arch=ppc64 --keyring >> /usr/share/keyrings/debian-archive-keyring.gpg --variant=buildd >> --exclude=debfoster debian-ppc64 h

Bug#801055: Update with compiler information

My bad... I probably should have sent this with the original report. # g++ -Wall -c test.cxx test.cxx:13:9: warning: #pragma GCC target is not supported for this machine [-Wpragmas] #pragma GCC pop_options ^ ** # gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc

Bug#801055: ARMHF and "pragma GCC target is not supported for this machine" for QEMU/ARMHF

Package: qemu-user-static Version: 1:2.1+dfsg-12+deb8u4 Severity: normal ** This is kind of odd. I'm in a QEMU chroot environment. The compiler accepts "pragma GCC push_options", but complains about "pragma GCC pop_options". My apologies in advance if this is mis-classified. I have

Bug#801424: Installing Chroot for Debian Sid breaks X32

Package: qemu-user-static Version: 1:2.1+dfsg-12+deb8u4 Severity: normal ** I had a working X32 installation. A Debian maintainer reported a problem under Debian Sid, and he provided instructions on duplicating his environment (below). After installing Debian Sid under chroot, X32

Bug#805422: ARM64 (AARCH64): Compiler accepts -fsanitize=undefined, without warning, but fails to link with "/usr/bin/ld: cannot find -lubsan"

Package: g++ Version: 4:4.9.2-2 Severity: normal A compiler warning would be nice if the linker does not accept the option. Otherwise, the compiler should not advertise it accepts the option. Accepting it without warning has wasted hours of build time in this emulated environment.

Bug#799120: cc1/cc1plus fails with "execv: exec format error” under QEMU s390x, can't compile C++ program

Package: qemu-system Version: 1:2.4+dfsg-3 Severity: important - Attempting to compile Crypto++ (http://www.cryptopp.com/) under s390x chroot environment: # chroot debian-s390x # g++ -dumpmachine s390x-linux-gnu # cd /cryptopp-5.6.3/ # make g++ -DNDEBUG -g2 -O2 -pipe -c osrng.cpp g++:

Bug#799130: s390 chroot fails with "specification exception insn 0xb9860062b904"

Package: qemu-system Version: 1.1.2+dfsg-6a+deb7u9 Severity: important - Attempting to install a QEMU s390 emulator for testing on Debian 7: $ sudo apt-get install qemu binfmt-support qemu-user-static debootstrap $ su - # update-binfmts --display | grep s390 qemu-s390x (enabled):

Bug#799130: s390 chroot fails with "specification exception insn 0xb9860062b904"

>> In the future, should I err to qemu-user? (Obviously I don't quite >> understand things, so I'm happy to do what I am told). > > Heh. I read this like "for any bug I encounter in my life, I've been > told to bug qemu-user" :) No, please don't, use common sense please :) > OK, will do :)

Bug#799120: closed by Michael Tokarev <m...@tls.msk.ru> (Re: Bug#799120: cc1/cc1plus fails with "execv: exec format error” under QEMU s390x, can't compile C++ program)

pile C++ program > Control: reassign -1 qemu-user > Version: 1:2.4+dfsg-3 > > 16.09.2015 02:47, Jeffrey Walton wrote: >> Package: qemu-system >> Version: 1:2.4+dfsg-3 >> Severity: important > > This has nothing to do with qemu-system. It is the user-mode emulation

Bug#799341: x32 and failure to install chroot environment due to mount failure

Package: debootstrap Version: 1.0.72 Severity: important * I work with a free/open source project (http://www.cryptopp.com/). A Debian maintainer reported a failure for X32. I'm trying to get a test rig setup to duplicate the issue. I'm following Debian's X32Port wiki page

Bug#800112: "Unsupported socketcall: 20" when using apt-get under s390 chroot

>> I assume we are talking about a foreign chroot setup with qemu rather >> than real hardware as I can't see such output in the buildlogs on real >> hardware, but some searching suggests that it happens in emulation. >> (In which case: which qemu setup and in which version?) > > Yes, its a chroot

Bug#800112: "Unsupported socketcall: 20" when using apt-get under s390 chroot

On Mon, Sep 28, 2015 at 4:58 PM, David Kalnischkies wrote: > On Mon, Sep 28, 2015 at 10:12:30PM +0300, Andrei POPESCU wrote: >> > # chroot debian-s390x/ >> > debian-s390:/# apt-get update >> > 0% [Working]Unsupported socketcall: 20 >> > 0% [Working]Unsupported socketcall:

Bug#800112: "Unsupported socketcall: 20" when using apt-get under s390 chroot

Hi David, Sorry about the late reply. I just got back on testing that utilizes the Debian QEMU chroot's. Also note that this might be better assigned to qemu-user static (my apologies if it was mis-classified): $ sudo update-binfmts --display ... interpreter =

Bug#800322: X32 enabled kernel and "Build of vmhgfs.ko failed for: 4.2.0-1-amd64 (x86_64)"

Package: open-vm-tools Version: 2:9.4.6-1770165-8 Severity: normal * I'm working with a machine configured for an X32 port. It was not really by choice; a Debian maintainer broke us on the platform, so we had to add it to the testing repertoire. The machine requires we boot with

Bug#800322: Status update

It appears reinstalling open-vm-tools after performing an "apt-get autoclean" followed by "apt-get autoremove" cleared the issue. I'm guessing open-vm-tools got confused because of multiple 4.x kernels or tried to compile against the wrong headers. ** # apt-get autoremove Reading

Bug#800112: "Unsupported socketcall: 20" when using apt-get under s390 chroot

Package: apt-get Version: 1.0.10.2 Severity: normal X-Debbugs-CC: m...@tls.msk.ru ** # chroot debian-s390x/ debian-s390:/# apt-get update 0% [Working]Unsupported socketcall: 20 0% [Working]Unsupported socketcall: 20 Get:1 http://httpredir.debian.org unstable InRelease [236 kB] Get:2

Bug#800112: Changing package from "apt-get" to "apt"

Control: package -1 apt

Bug#799556: GDB cannot debug a program on the X32 platform (internal-error: find_new_threads_once...)

Package: gdb Version: 7-10.1 Severity: important X-Debbugs-CC: zu...@debian.org, g...@debian.org * A Debian maintainer informed us of some problem on the X32 platform. I'm attempting to perform the port to X32, but I can't seem to get GDB to execute/debug a program on the X32 platform (see

Bug#799556: Upstream GDB bug report with suggested fix

See GDB Issue 18987, https://sourceware.org/bugzilla/show_bug.cgi?id=18987

Bug#799606: [Pkg-openssl-devel] Bug#799606: Cannot compile OpenSSL 1.0.2d under X32 (fatal error: sys/cdefs.h: No such file or directory)

On Sun, Sep 20, 2015 at 4:25 PM, Kurt Roeckx <k...@roeckx.be> wrote: > On Sun, Sep 20, 2015 at 03:52:34PM -0400, Jeffrey Walton wrote: >> >> # find /usr -name cdefs.h >> /usr/include/x86_64-linux-gnux32/sys/cdefs.h > > If you want to show include directories, you

Bug#799556: Warning possibly contributing to the error in 799556

Building GDB 7.10 from sources reveals: # export CFLAGS="-mx32" # export CXXFLAGS="-mx32" # ./configure --prefix=/usr/local checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type...

Bug#799556: Unwanted assert causing failure

There's an unwanted assert causing the failure in gdb/linux-thread-db.c. Around line 1675, guard the assert based on __ILP32__: #if !defined(__ILP32__) && !defined(_ILP32) /* See comment in thread_db_update_thread_list. */ gdb_assert (!target_has_execution || thread_db_use_events ()); #endif

Bug#799556: Control updates

Control: user debian-...@lists.debian.org Control: usertags -1 + port-x32 Control: tags -1 + patch upstream

Bug#799606: Cannot compile OpenSSL 1.0.2d under X32 (fatal error: sys/cdefs.h: No such file or directory)

Package: openssl Version: 1.0.2d-1 Severity: important * >From within the X32 chroot environment (http://wiki.debian.org/X32Port)... Download and unpack OpenSSL with: curl -k https://www.openssl.org/source/openssl-1.0.2d.tar.gz -o openssl-1.0.2d.tar.gz tar xzfi

Bug#799606: [Pkg-openssl-devel] Bug#799606: Cannot compile OpenSSL 1.0.2d under X32 (fatal error: sys/cdefs.h: No such file or directory)

> Why are you reporting something about the upstream source to > Debian while the Debian package build fine? It has an debian-x32 > target that uses -mx32. > Debian wants all bugs reported to them, and not upstream. See "Don't file bugs upstream" at https://www.debian.org/Bugs/Reporting. Jeff

Bug#801424: Installing Chroot for Debian Sid breaks X32

On Sun, Nov 29, 2015 at 6:05 AM, Michael Tokarev wrote: > Jeffrey, are you going to reply with more information, > or should I just close this bugreport? > Close it. I don't have the time to work on it. Sorry about circumstances.

Bug#827862: GDB cannot debug a program on the X32 platform (internal-error: find_new_threads_once...)

, 2015 at 6:05 AM, Jeffrey Walton <noloa...@gmail.com> wrote: > Package: gdb > Version: 7-10.1 > Severity: important > X-Debbugs-CC: zu...@debian.org, g...@debian.org > > > # apt-cache show gdb > Package: gdb > Priority: optional > Section: devel > Install

Bug#828041: Panic when attempting to enter Sparc64 QEMU guest

There's some information missing from this bug. I'm not sure why tee did not capture it because I used `choot debian-sparc64 2>&1 | tee ...` Here's the missing preamble that tee failed to capture. I transcribed it, so my apologies for typos: # choot debian-sparc64 *** longjmp causes unintialized

Bug#828041: Panic when attempting to enter Sparc64 QEMU guest

I can reproduce the issue on a Debian kernel booted with 'syscall.x32=y'. The failure looks a little different: # chroot debian-sparc64 *** longjmp causes uninitialized stack frame ***: /bin/bash terminated Unhandled trap: 0x34 pc: 00163860 npc: 00163864 %g0-3:

Bug#828052: Sparc and "Invalid Release file, no entry for main/binary-sparc/Packages"

Package: debootstrap Version: 1.0.67 Severity: important I have a Debian 8.5 host on amd64/x86_64 with Testing enabled. I am attempting to setup a Sparc guest with Unstable enabled using the following command: qemu-debootstrap --arch=sparc --keyring

Bug#828058: emacs-nox, failed install and "Symbol's value as variable is void: boundp"

Package: emacs-nox Version: 46.1 Severity: important I'm trying to install emacs-nox on a Debian s/390x Chroot with Unstable enabled. The results ar ebolw. The "Unsupported socketcall: 20" was reported about 6 or 9 months ago. it looks like it still has not been fixed. # apt-get dist-upgrade

Bug#828041: Panic when attempting to enter Sparc64 QEMU guest

Package: qemu-user-static Version: 1:2.6+dfsg-3 Severity: important I have a Debian 8.5 on amd64/x86_64 host with Testing enabled. I setup a QEMU Sparc64 guest with Unstable enabled using the following command: qemu-debootstrap --arch=sparc64 --keyring

Bug#828043: Sparc and "Invalid Release file, no entry for main/binary-sparc/Packages"

Package: qemu-user-static Version: 1:2.6+dfsg-3 Severity: important I have a Debian 8.5 host on amd64/x86_64 with Testing enabled. I attempted to setup a QEMU Sparc guest with Unstable enabled using the following command: qemu-debootstrap --arch=sparc --keyring

Bug#828043: Sparc and "Invalid Release file, no entry for main/binary-sparc/Packages"

On Fri, Jun 24, 2016 at 6:12 AM, Michael Tokarev <m...@tls.msk.ru> wrote: > 24.06.2016 12:47, Jeffrey Walton wrote: >> Package: qemu-user-static >> Version: 1:2.6+dfsg-3 >> Severity: important > > I'm not sure at all why you're filing this for qemu. > >&

Bug#828702: Emacs bloat; emacs-nox includes windowing components

Package: emacs-nox Version: 46.1 The emacs-nox installation appears to be suffering from bloat. Its over 125 MB even though a minimum build is usually less than 25 MB. The 25 MB minimum build can be achieved with the following Configure using 24.5: ./configure --with-xml2 --with-zlib

Bug#828704: Issue in Bash; causing failures in Sparc64 and S/390x Chroots

Package: bash Source: bash (4.3-14) Version: 4.3-14+b1 This is a crummy bug report. I've been having some trouble with Bash in some QEMU/Chroot environments. I'm guessing the Bash maintainers don't know about the issues. I use quite a few Debian Ports (https://www.debian.org/ports/) because

Bug#814682: Detailed instructions for building OpenChrome 0.3.4 from sources

Kevin Brace of freedesktop.org provided detailed instructions for obtaining, building and installing the updated driver. See "Detailed instructions on how to backup, restore, compile, and install OpenChrome," http://lists.freedesktop.org/archives/openchrome-users/2016-February/007237.html.

Bug#814682: Updated OpenChrome driver available

Package: xserver-xorg-video-openchrome Version: 1:0.3.3-2 The current The OpenChrome provided in Debian causes an Xserver crash on VIA P4M900 chipset. Though its a less popular chipset, its still used in production for lower end systems, like Netbooks and POS systems. The OpenChrome driver is

Bug#715505: Updated OpenChrome driver available

Also see "Updated OpenChrome driver available", http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814682. It does not appear to be available in Debian Unstable yet. Fir the VIA and Unknown Card-Ids (3371|1019|2125), Chipset: P4M900/VN896/CN896, and Xserver crash, also see

Bug#715505: Updated OpenChrome driver available

/show_bug.cgi?id=94130#c4. Git instructions: * https://lists.freedesktop.org/archives/openchrome-devel/2016-February/001753.html Jeffrey Walton

Bug#818996: Please enable -Wabi-tag warning for C++ programs

On Tue, Mar 22, 2016 at 6:03 PM, Rebecca N. Palmer wrote: >> The user then compiled with Clang and caught a link error. > > clang can't handle abi tags (i.e. can't link to new-ABI code even if you > aren't trying to mix it with old-ABI code): >

Bug#818996: Please enable -Wabi-tag warning for C++ programs

>> - compile and link a program that uses libfoo and libbar with uvw compiler > > Let me follow up with some real result from a minimal test case. > >> (but I'm probably getting the sequence of events totally wrong so please >> specify what is actually going on) > > Not at all. Its a confluence of

Bug#818996: Please enable -Wabi-tag warning for C++ programs

al report: > >> >On Tue, 22 Mar 2016 at 10:34:29 -0400, Jeffrey Walton wrote: >> >>It appears Debian built the library with GCC, and GCC used >> >>_GLIBCXX_USE_CXX11_ABI. The user then compiled with Clang and caught a >> >>link error. The tools did

Bug#818996: Please enable -Wabi-tag warning for C++ programs

> On Wed, 23 Mar 2016 at 13:31:32 +0100, Matthias Klose wrote: >> If you want to change that, that change should be made in dpkg-buildflags. > > From the original report: > >> >On Tue, 22 Mar 2016 at 10:34:29 -0400, Jeffrey Walton wrote: >> >>It appears Deb

Bug#823519: GCC 4.9 missing ARM and Neon Intrinsics for AARCH64

This is also kind of interesting in a morbid sort of way: $ cpp -dM http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053c/IHI0053C_acle_2_0.pdf, Section 12.1, __ARM_NEON is defined when ARM Neon Intrinsics are available: NEON intrinsics are available if the __ARM_NEON macro is

Bug#823519: GCC 4.9 missing ARM and Neon Intrinsics for AARCH64

Package: gcc-4.9 Version: 4.9.2-10 - I have a LeMaker HiKey (http://www.96boards.org/products/ce/hikey-lemaker/). Its AARCH64 and Neon is mandatory feature (https://community.arm.com/groups/android-community/blog/2014/10/10/runtime-detection-of-cpu-features-on-an-armv8-a-cpu). GCC appears

Bug#821846: Can't install Git on S/390 Chroot

Package: git Version: 1:2.1.4-2.1+deb8u2 My apologies if this is Qemu, Qemu-static or some other package. According to apt-cache below, its just Git. -- debian-s390:~# uname -a Linux debian-8-x64 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) s390x GNU/Linux --

Bug#833072: Can't create armel chroot using debootstrap - Invalid Release file, no entry for main/binary-armel/Packages

Package: debootstrap Version: 1.0.81 Severity: important The host computer is running Debian Sid, fully patched. Results from host computer: I: Running command: debootstrap --arch armel --foreign --keyring /usr/share/keyrings/debian-ports-archive-keyring.gpg --variant=buildd --exclude=debfoster

Bug#833072: Can't create armel chroot using debootstrap - Invalid Release file, no entry for main/binary-armel/Packages

>>Results from host computer: >> >>I: Running command: debootstrap --arch armel --foreign --keyring >>/usr/share/keyrings/debian-ports-archive-keyring.gpg --variant=buildd >>--exclude=debfoster unstable debian-armel >>http://ftp.ports.debian.org/debian-ports >>I: Retrieving Release >>I: Retrieving

Bug#833093: qemu: fatal: Illegal instruction: ebc0 @ f67c3712

Package: qemu Version: 1:2.1+dfsg-12+deb8u6 Severity: Important I'm trying to setup a m68k chroot from Sid: # qemu-debootstrap --arch=m68k --keyring /usr/share/keyrings/debian-ports-archive-keyring.gpg --no-check-gpg --variant=buildd --exclude=debfoster unstable debian-m68k

Bug#828052: Please update Ports wiki page

> I think the status field saying "released", "discontinued" etc provides the > information with the current layout. > > Thanks for caring about the ports page. I marked the patches for review (in > my TODO) but couldn't find time :/ > Convert it to a wiki page. The work would have been done

Bug#852959: [pkg-go] Bug#852959: Bug#852959: prometheus FTBFS on armhf: github.com/prometheus/prometheus/storage/local fails

> Sadly, it turns out armhf fails to build due to one test taking a bit > too much memory[1], and there is an RC bug open for that: #852959[2]. > > So now I don't know what to do, except asking for removal of prometheus > from armhf. As a stopgap, you might consider adding a small swapfile and

Bug#856528: Unable to install GCC7 on Debian 8/i386 with Experimental enabled

Package: gcc-7 Version: 7-20170226-1 Severity: important I'm unable to install GCC7 on Debian 8/i386 with Experimental enabled. Things worked well under x86_64; the issue seems to be limited to i386. = A fresh install of Debian 8.7 for i386. The machine is

Bug#856528: closed by Matthias Klose <d...@debian.org> (Re: Bug#856528: Unable to install GCC7 on Debian 8/i386 with Experimental enabled)

t; -- Forwarded message -- > From: Matthias Klose <d...@debian.org> > To: noloa...@gmail.com, 856528-d...@bugs.debian.org > Cc: > Bcc: > Date: Thu, 2 Mar 2017 10:08:54 +0100 > Subject: Re: Bug#856528: Unable to install GCC7 on Debian 8/i386 with > Experi

Bug#837048: QEMU chroot broken

Package: qemu Version: 1:2.6+dfsg-3 Severity: Important I'm fairly certain nearly all of Debian's chroots are broken. I think the X32 chroot is the only one that actually works. The broken QEMU chroots coupled with lack of documentation really hinders our ability to do our job. Here, our job is

Bug#837048: closed by Riku Voipio <riku.voi...@iki.fi> (Re: Bug#837048: QEMU chroot broken)

- > From: Riku Voipio <riku.voi...@iki.fi> > To: noloa...@gmail.com, 837048-d...@bugs.debian.org > Cc: > Date: Thu, 8 Sep 2016 10:39:01 +0000 > Subject: Re: Bug#837048: QEMU chroot broken > On Thu, Sep 08, 2016 at 05:19:44AM -0400, Jeffrey Walton wrote: >> I'm fairly c

Bug#842307: Ports still broken with error "unknown key (key id B4C86482705A2CE1)"

Package: apt Version: 1.0.9.8 Severity: important Ports and Apt are still broken. And Apt does not honor --no-check-gpg or --allow-unauthenticated. I'm going to call bullshit on Message 15 at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826043#15. The shit does not work. I'm going to call

Bug#842307: closed by Julian Andres Klode <j...@debian.org> (Re: Bug#842307: Ports still broken with error "unknown key (key id B4C86482705A2CE1)")

> I'm closing this bug. Get your shit together My shit is sprayed all over the place because you guys cannot seem to get your shit together. What a surprise yet another bug was closed without fixing it

Bug#871952: GDB Crash due to GDB/Kernel generated SIGILL

Package: gdb Version: 7.7.1+dfsg-5 Severity: important X-Debbugs-CC: zu...@debian.org, g...@debian.org We are trying to track down the source of a program termination under the debugger due to a SIGILL. The program does not perform feature probing, so we don't believe its coming from the program.

Bug#852854: Here's the upstream GDB bug report: 10833

Here's the upstream GDB bug report: https://sourceware.org/bugzilla/show_bug.cgi?id=10833#c8

Bug#911043: rng-tools does not perform as expected on Beaglebone Black with OMAP hw rng

Package: rng-tools Version: 2-unofficial-mt.14-1 X-Debbugs-CC: robertcnel...@gmail.com, pkg-systemd-maintain...@lists.alioth.debian.org rng-tools does not perform as expected on a Beaglebone Black. The dev-board has a built-in rng, and the kernel driver loads as expected. /dev/hwrng is full, but

Bug#911043: rng-tools does not perform as expected ...

Here is the workaround. I don't know what the fix is. I was never able to get systemd to enable the service (or subsequently start the service). Nothing I attempted would get the service out of the "generated" status. $ cat /etc/rc.local #!/bin/sh -e # # rc.local # # This script is executed at

Bug#911043: rng-tools does not perform as expected ...

Attached is a rng-tools.service that tested well on two BeagleBoards. The service file avoids the logger dependencies, avoids udev rules, and tries to recover from failure on startup. The recovery part was important on the Beagleboards. The service failed during startup because the udev

Bug#925385: /usr/bin/mysql: Poor MariaDB performance

Package: mariadb-client-core-10.1 Version: 10.1.37-0+deb9u1 Severity: important File: /usr/bin/mysql Dear Maintainer, I am working on a Tinkerboard (https://www.asus.com/us/Single-Board-Computer/Tinker-Board/), which is an ARM dev-board. The board has a Cortex-A17 1.4 GHz cpu, 2 GB RAM, and 16

Bug#925385: /usr/bin/mysql: Poor MariaDB performance

In case it matters, here are the repos being used for the Tinkerboard. $ cat /etc/apt/sources.list deb http://http.debian.net/debian/ stretch main contrib non-free deb-src http://http.debian.net/debian/ stretch main contrib non-free deb http://security.debian.org/ stretch/updates main contrib

Bug#924906: valgrind: m_transtab.c:2459 (vgPlain_init_tt_tc): Assertion 'sizeof(TTEntryC) <= 88' failed.

Package: valgrind Version: 1:3.12.0~svn20160714-1+b1 Severity: serious Tags: upstream Justification: 4 Dear Maintainer, * What led up to the situation? valgrind ./myprog * What exactly did you do (or not do) that was effective (or ineffective)? Looks like an upstream

Bug#926748: cargo: Cargo is too old

Package: cargo Version: 0.15.0~dev-1+rpi1 Severity: normal Dear Maintainer, I am working on a RaspberryPi 3B+ running Raspian. I have a Python program that fills out a multi-page webform. To do so, I need Firefox, Selenium, WebDriver and geckodriver. Python-Selenium odes the heavy lifting

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

On Fri, Apr 17, 2020 at 7:21 AM Andreas Tille wrote: > > Control: tags -1 help > > as it can be seen on the recent build log of clustalo on mips[1] the > build fails with > > # Run additional test from python-biopython package to verify that > # this will work as well > src/clustalo -i

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

On Thu, Apr 30, 2020 at 10:33 AM Matthew Fernandez wrote: > > > On Apr 30, 2020, at 00:31, Andreas Tille wrote: > > > > On Wed, Apr 29, 2020 at 05:51:26PM -0700, Matthew Fernandez wrote: > > > >> The other option I suggested was Valgrind, but if you can’t run apt-file > >> you probably can’t

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

On Fri, Apr 17, 2020 at 7:21 AM Andreas Tille wrote: > ... > So it seems the bus error occures somehow here: > > > https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/pair_dist.c#L346 NewProgress is at

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

On Fri, May 1, 2020 at 3:05 AM Jeffrey Walton wrote: > > On Fri, May 1, 2020 at 2:14 AM Andreas Tille wrote: > > > > ... > > ==13209== Process terminating with default action of signal 10 (SIGBUS) > > ==13209==at 0x12D5CC: PairDistances (pair_dist.c:346

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

On Fri, May 1, 2020 at 2:14 AM Andreas Tille wrote: > > ... > ==13209== Process terminating with default action of signal 10 (SIGBUS) > ==13209==at 0x12D5CC: PairDistances (pair_dist.c:346) > ==13209==by 0x119410: AlignmentOrder (clustal-omega.c:835) > ==13209==by 0x11A6C4: Align

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

On Sun, May 10, 2020 at 2:57 PM Andreas Tille wrote: > > ... > > --- clustalo-1.2.4/debian/rules 2020-04-14 12:19:44.0 +0300 > > +++ clustalo-1.2.4/debian/rules 2020-04-14 12:19:44.0 +0300 > > @@ -9,6 +9,11 @@ > > %: > > dh $@ > > > > +ifneq (,$(filter

Bug#989235: p11-kit FTBFS on hurd-any

On Sun, May 30, 2021 at 9:22 AM Helmut Grohne wrote: > > On Sat, May 29, 2021 at 06:17:09PM -0400, Jeffrey Walton wrote: > > On Sat, May 29, 2021 at 5:00 PM Helmut Grohne wrote: > > > ... > > > p11-kit fails to build from source on hurd-any. The immediate reas

Bug#989235: p11-kit FTBFS on hurd-any

On Sat, May 29, 2021 at 5:00 PM Helmut Grohne wrote: > ... > p11-kit fails to build from source on hurd-any. The immediate reason is > an undefined macro SIZE_MAX in p11-kit/lists.c. It happens that this > file fails to #include , which is generally required for > SIZE_MAX. I'm attaching a patch

Bug#972339: armhf: hpcups crashes with free() invalid pointer for some printers

On Sat, Feb 27, 2021 at 1:21 PM Bernhard Übelacker wrote: > > I have retried with the patch in #974828, but it still > crashed with the test files from this bug, therefore > I guess #974828 is similar but unrelated. > > Then I took another look at the valgrind runs and found > that these invalid

Bug#991971: [oss-security] SNI is a security vulnerability all by itself (was Re: [Lynx-dev] bug in Lynx' SSL certificate validation -> leaks password in clear text via SNI (under some circumstances))

On Sat, Aug 7, 2021 at 8:29 AM Thorsten Glaser wrote: > > >Axel Beckert dixit: > > >>IMHO this nevertheless needs a CVE-ID. > > I wonder… perhaps the use of SNI, both in the TLSv1.3 standard > and in some TLSv1.2 implementations, should receive CVEs as well? As far as I know, the only problem

Bug#1001995: libcrypto++: ftbfs on armhf

Hi Everyone, The patch to work around the failed compile is located at https://github.com/weidai11/cryptopp/issues/1094#issuecomment-1035656572 . The patch is against Crypto++ 8.6. The patch was tested in a Debian Unstable QEMU/Chroot for armel and armhf. It tested Ok. The changes in the diff

Bug#1006554: Update Filezilla packages

Package: filezilla Version: 3.46.3-1build1 Hi Everyone, Filezilla is having trouble opening my SSH keys for use in SFTP on Ubuntu 20.04.5 LTS. I have a patch and I am trying to test it. Also see https://trac.filezilla-project.org/ticket/12668 . I am trying to build an updated Filezilla client

Bug#1006554: closed by Philip Wyett (reply to philip.wy...@kathenas.org) (Update Filezilla packages)

> -- Forwarded message -- > From: Philip Wyett > To: 1006554-d...@bugs.debian.org > Cc: > Bcc: > Date: Sun, 27 Feb 2022 19:05:56 + > Subject: Update Filezilla packages > Hi Jeffrey, > > This is an Ubuntu build and also a from source build and nothing to with > Debian builds

Bug#1001995: libcrypto++: ftbfs on armhf

Hi Everyone, My apologies for the late reply. SL > There are various ways to reconcile this incompatibility between SL > build options, but given this is armhf which is guaranteed to have SL > floating-point support, I think the simplest may be as in the SL > attached patch, which adjusts to

Bug#1001995: libcrypto++: ftbfs on armhf

I opened this for the GCC folks: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104455. I'm not sure if they are aware things no longer work. Jeff

Bug#1005249: Sid debian-archive-keyring is missing key id E852514F5DF312F6

Package: debian-archive-keyring Version: 2021.1.1 X-Debbugs-CC: g...@debian.org Tags: sid Ah, the never ending problem of Debian keys... I'm trying to setup a Qemu Chroot for testing Debian bug 1001995. Key id E852514F5DF312F6 cannot be found in debian-archive-keyring, and it cannot be found at

  1   2   >