Bug#1068024:

An important comment from oss-security mailing list message, : commit f9cf4c05edd14dedfe63833f8ccbe41b55823b00 (HEAD -> master, origin/master, origin/HEAD) Author: Lasse Collin Date: Sat Mar 30 14:36:28 2024 +0200 CMake: Fix

Bug#1068024:

It looks like more analysis has revealed this is a RCE with the payload in the modulus of a public key: "The payload is extracted from the N value (the public key) passed to RSA_public_decrypt, checked against a simple fingerprint, and decrypted with a fixed ChaCha20 key before the Ed448 signature

Bug#1068024:

Lasse Collin provided a statement at .

Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf

On Tue, Mar 26, 2024 at 7:44 PM Thorsten Glaser wrote: > > I’m answering back from the $dayjob address because Googlemail > cannot communicate with normal mailservers. > > >I can send you two dev boards, if you want them. The first is > >Wandboard Dual (Cortex-A9, ARMv7 with NEON), and the second

Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf

On Tue, Mar 26, 2024 at 6:30 PM Thorsten Glaser wrote: > > [...] > > The options for the armel/armhf porters are to either get the > .debs from me, install them in a chroot, and then the other B-D, > and rebuild the packages, or to use dpkg --force-depends to > install the dependencies (which

Bug#1065567: timedatectl does not recognize ntpsec

On Wed, Mar 6, 2024 at 1:29 PM Michael Biebl wrote: > > Control: reassign -1 ntpsec > > Actually, I think it's better to just reassign the bug report and let > Richard decide whether he closes it as wontfix or ships such an > integration snippet. > > Richard, if you are interested in shipping

Bug#1065567: timedatectl does not recognize ntpsec

Package: systemd Version: 255.4-1 Tags: sid It looks like Systemd's timedatectl does not recognize ntpsec. Using it results in 'NTP service: n/a': $ timedatectl Local time: Wed 2024-03-06 12:35:32 EST Universal time: Wed 2024-03-06 17:35:32 UTC RTC

Bug#1063916:

Also see : Debian-legal has already taken an interest in this, and consensus is to steer clear of your freenginx fork due to copyright and trademark infringement risks. Because of that edict, I am unable to get this into Debian. I

Bug#1063916: RFP: freenginx -- a fork of nginx maintained by Maxim Dounin and the development community

On Thu, Feb 15, 2024 at 4:57 PM Henrique de Moraes Holschuh wrote: > > Is there *any* point on packaging this nginx fork this early? > > We don't yet know the bus factor (i.e. uptake of the fork, size of core team, > etc) of this fork yet. We don't know how the dynamics with the F5-controlled

Bug#1063916:

X-Debbugs-CC: mdou...@mdounin.ru

Bug#1063916: RFP: freenginx -- a fork of nginx maintained by Maxim Dounin and the development community

Package: wnpp Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org * Package name: freenginx Version : 1.24.0 Upstream Author : Maxim Dounin and the development community Section: web * URL : http://freenginx.org/ * License : GPL Programming Lang:

Bug#1063775: initramfs-tools, and cp: warning: behavior of -n is non-portable and may change in future; use --update=none instead

This issue is likely Debian Bug #62572. Also see . (Thanks Wesley).

Bug#1063775: initramfs-tools, and cp: warning: behavior of -n is non-portable and may change in future; use --update=none instead

I think I incorrectly attributed the warnings to the Plymouth package. I now think this is an issue with update-initramfs. I saw the warnings again when manually running initramfs-tools. My apologies if I got the package wrong (again). - # apt-cache show initramfs-tools Package:

Bug#1063775: Plymouth, and cp: warning: behavior of -n is non-portable and may change in future; use --update=none instead

Package: plymouth Version: 24.004.60-1 Tags: trixie This is just a heads up. Maybe to get out in front of things... I just performed an 'aptitude safe-upgrade' on a Debian Unstable machine. When the Plymouth installer ran, it produced 50 or so of these: Setting up plymouth (24.004.60-1) ...

Bug#826643: ITP: tn5250j -- A 5250 terminal emulator for the AS/400

It looks like tn5250j has moved to GitHub, .

Bug#1060832: RM: graph-tool [ppc64el] -- ROM; Does not build on ppc64el

On Mon, Jan 15, 2024 at 4:03 AM Andreas Tille wrote: > > Package: ftp.debian.org > Severity: normal > User: ftp.debian@packages.debian.org > Usertags: remove > X-Debbugs-Cc: graph-t...@packages.debian.org, 1056...@bugs.debian.org, > debian-powe...@lists.debian.org > Control: affects -1 +

Bug#1057717: cmake ftbfs on ppc64el (and ppc64)

On Thu, Jan 11, 2024 at 1:16 PM John Paul Adrian Glaubitz wrote: > > the bug is definitely still present and I'm therefore not sure whether > downgrading the priority to normal is justified. > > On ppc64, cmake still crashes regularly when configuring the LLVM build > for example [1]: > > --

Bug#1058658: ca-certificates and update-ca-certificates script

Merge request at and . The first pull request updates documentation for the existing version of the script. The second pull request updates the script, and

Bug#1058658: ca-certificates and update-ca-certificates script

It looks like the `read -r` fix was already proposed at . Perhaps it is a good time to make the change?

Bug#981663: ca-certificates package fails when certificate name includes backslash

Also see .

Bug#1058658: ca-certificates and update-ca-certificates script

My bad, I should have included this: # lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux trixie/sid Release:n/a Codename: trixie I suspect the ShellCheck findings apply to other Debian distros, too.

Bug#1058658: ca-certificates and update-ca-certificates script

Package: ca-certificates Version: 20230311 Tags: sid Hi Everyone, Adding local certificates to Debian's store came up recently on the debian-users mailing list. I needed to look up some options in the update-ca-certificates script, and a couple of things caught my eye. Investigating further

Bug#1050878: Emacsen fails to install in Debian Chroot

Package: emacsen-common Version: 3.0.5 Severity: Important X-Debbugs-CC: r...@defaultvalue.org I'm trying to install emacs-nox in an armel chroot. The install is failing due to emacsen-common. Please see below. This seems to be unique to armel chroot. I believe I have emacs-nox installed for

Bug#1040827: RM: firefox [mipsel] -- RoQA; severely outdated, depends on transitional libgdk-pixbuf2.0-0

On Tue, Jul 11, 2023 at 5:09 AM Simon McVittie wrote: > > Package: ftp.debian.org > Severity: normal > User: ftp.debian@packages.debian.org > Usertags: remove > X-Debbugs-Cc: fire...@packages.debian.org, debian-m...@lists.debian.org > Control: affects -1 + src:firefox > > firefox:mipsel still

Bug#1039606: Don't display unimportant issues as "vulnerable"

On Tue, Jun 27, 2023 at 2:36 PM Moritz Muehlenhoff wrote: > > Package: security-tracker > Severity: wishlist > > "unimportant" issues don't have security impact, but currently they get shown > as "vulnerable" in red, both in a package overview page, e.g. >

Bug#1035615: xz-utils: Fix hurd-amd64 build

On Sat, May 6, 2023 at 10:41 AM Samuel Thibault wrote: > > Package: xz-utils > Version: 5.4.1-0.2 > Severity: important > Tags: patch > > debian/rules is passing --enable-assembler=x86_64 to configure, but that > case was removed, see ChangeLog: > > commit ac10b1b3622e70881595586edfb8a3ebdcd76bb6

Bug#1028917: passwd package missing dependency

Package: passwd Version: 1:4.8.1-1 Tags: bullseye As reported at https://lists.debian.org/debian-user/2023/01/msg00319.html : Package: passwd (1:4.8.1-1) does not work without libpam-ldap , being a library which is not listed on the dependency section of the page dedicated to the package passwd

Bug#1025176: libicu71 missing on SH4 port

On Fri, Dec 16, 2022 at 9:23 PM Rob Landley wrote: > [...] > How does one do an 'entirely from source' debootstrap, anyway? (If I wanted to > reproduce your current sh4 build on my system, where would I start?) For SH-4 I use a Debian Chroot and follow

Bug#1025203: r-cran-glmmtmb: FTBFS on mipsel

On Thu, Dec 1, 2022 at 1:15 AM Andreas Tille wrote: > > Hi, > > Am Wed, Nov 30, 2022 at 10:08:14PM +0100 schrieb Paul Gevers: > > Source: r-cran-glmmtmb > > Version: 1.1.4+dfsg-3 > > Severity: serious > > Tags: ftbfs > > Justification: ftbfs > > > > Dear maintainer(s), > > > > Your package failed

Bug#1025176: libicu71 missing on SH4 port

On Thu, Dec 1, 2022 at 9:53 AM Jeffrey Walton wrote: > > On Wed, Nov 30, 2022 at 8:26 PM Jeffrey Walton wrote: > > > > On Wed, Nov 30, 2022 at 5:14 PM László Böszörményi (GCS) > > wrote: > > > ... > > > You may locally hack the build of boost1.74

Bug#1025176: libicu71 missing on SH4 port

On Wed, Nov 30, 2022 at 8:26 PM Jeffrey Walton wrote: > > On Wed, Nov 30, 2022 at 5:14 PM László Böszörményi (GCS) > wrote: > > ... > > You may locally hack the build of boost1.74 not to require Python > > (and drop its related binary packages). Of course, best

Bug#1025176: libicu71 missing on SH4 port

On Wed, Nov 30, 2022 at 5:14 PM László Böszörményi (GCS) wrote: > ... > You may locally hack the build of boost1.74 not to require Python > (and drop its related binary packages). Of course, best would be to > port python-greenlet to sh4 or just fix its build - can you give a > helping hand to

Bug#1025176: libicu71 missing on SH4 port

Package: libicu71 Version: 71.1-1~ Tags: sid I'm working on a Debian Chroot for SH4 machine. I am trying to install GDB. The GDB installation fails: # apt install gdb Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be

Bug#1017979: mozjs91: FTBFS on armel with gcc 12: multiple definition of `__sync_fetch_and_add_4' etc.

On Tue, Aug 23, 2022 at 4:40 PM Simon McVittie wrote: > > Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1786623 > Control: affects -1 + src:mozjs102 > > On Tue, 23 Aug 2022 at 13:23:30 +0100, Simon McVittie wrote: > > The final link fails with multiple definitions of the

Bug#1016790: lldb is not upgraded during dist-upgrade

Package: lldb Version: 1:14.0-55.1 Tags: unstable Hi Everyone. I' working on a GCC 12 specific bug present in Debian Unstable. I am also using LLVM's tools to investigate the bug. Running dist-upgrade results in lldb being held back: # apt-get update ... # apt-get upgrade ... # apt-get

Bug#1009338: PowerPC and Package 'b43-fwcutter' has no installation candidate

Package: b43-fwcutter Version: 1:019-7 X-Debbugs-CC: glaub...@physik.fu-berlin.de Tags: sid I am working on an old PowerMac G5 running Debian Sid. I am trying to install firmware-b43-installer. It is having some trouble. I'm not sure how to fix it. I'm going to report it and then ask some

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#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#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#1001995: libcrypto++: ftbfs on armhf

Hi Everyone, I think this is a GCC or Debian bug. Here is my reasoning. Developers are responsible to declare the ISA they are using through options. In our case, we are using armv4 and armv7, so we let the compiler know via -march=armv7-a. That's where a developer's responsibility ends. We are

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

On Wed, Feb 9, 2022 at 5:09 PM Adam D. Barratt wrote: > > On Wed, 2022-02-09 at 17:02 -0500, Jeffrey Walton wrote: > > On Wed, Feb 9, 2022 at 4:48 PM Adam D. Barratt < > > a...@adam-barratt.org.uk> wrote: > > > ... > > > I have to admit that I'm slightly

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

On Wed, Feb 9, 2022 at 4:48 PM Adam D. Barratt wrote: > ... > I have to admit that I'm slightly confused as to why you're attempting > to use the ports archive to build an armhf chroot in any case, when > it's been in the main archive for over a decade now. I'm trying to reproduce a bug from

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

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#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#1003847: binutils breaks glibc autopkgtest on ppc64el: unrecognized opcode: `vspltisb' (and others)

On Wed, Jan 19, 2022 at 4:08 PM John Paul Adrian Glaubitz wrote: > > Unfortunately, glibc no longer builds with this change on powerpc and ppc64 > and kernel builds still fails on both targets: > > > https://buildd.debian.org/status/fetch.php?pkg=glibc=powerpc=2.33-3=1642542048=0 > >

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#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#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#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 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, 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#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#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#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#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#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#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 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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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

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#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#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#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#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#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#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#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#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

>> - 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

> 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#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#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#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#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#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#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

  1   2   >