Bug#1068024:

[Jeffrey Walton]

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 sabotaged Landlock sandbox check.

It never enabled it.

Bug#1068024:

[Jeffrey Walton]

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 verification..." Also see
.

Bug#1068024:

[Jeffrey Walton]

Lasse Collin provided a statement at .

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

[Jeffrey Walton]

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 is
> >CubieTruck 5 (Cortex-A7, ARMv7 with NEON and VFPv4). Both work, but I
> >don't use them much anymore. I've mostly moved on to Aarch64.
>
> That is certainly an option, if you don’t want them any more and want
> to ship them to .de, although it’ll likely take longer than just getting
> access on a suitable project machine. RAM is tight on them, but with
> swap the compiling should work. Both seem to have serial console, good.

Nothing beats a native compile in your basement. It sure beats the
snot out of a cross-compile, or an emulator like a Debian QEMU/Chroot.
I switched to the dev boards after getting frustrated with
cross-compiles. (So many makefiles are poorly written, and can't
handle a simple cross-compile).

And I run a first class swap file on all of my dev boards. SDcards are
easy to replace. A SDcard lasts 6 to 9 months before you start seeing
unexplained file system errors. That's around the time you know it's
time to replace the SDcard.

> Do they run stock Debian armhf?

So the CubieTruck is embarrassingly down level:

cubietruck:~$ lsb_release -a
Distributor ID: Linaro
Description:Linaro 14.04
Release:14.04
Codename:   trusty

The Wandboard is doing better:

wandboard:~$ lsb_release -a
Distributor ID: Debian
Description:Debian GNU/Linux 11 (bullseye)
Release:11
Codename:   bullseye

I don't mind shipping to Europe if you don't mind paying the VAT. I
think you will be the fourth or fifth Debian maintainer I've sent
hardware to.

Jeff

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

[Jeffrey Walton]

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 makes it hard to use apt to
> install the other ones unless you also edit /var/lib/dpkg/status
> by hand first, something I was already used to from my reviving
> m68k back in 2012–2015) into the chroot then rebuild there.
>
> I will gladly help if it’s made possible for me to help. This
> cannot be done on a porterbox because it’s still impossible to
> either install arbitrary .debs into a chroot there or to obtain
> root in the chroot to be able to force installation in the absence
> of some Depends.
>
> So if you have a fast armhf box or two, ideally with chroots
> already made for sid, which you don’t mind temporarily giving
> me root on, I’m in, otherwise I’ll answer questions from these
> doing that work if needed.

I can send you two dev boards, if you want them. The first is
Wandboard Dual (Cortex-A9, ARMv7 with NEON), and the second is
CubieTruck 5 (Cortex-A7, ARMv7 with NEON and VFPv4). Both work, but I
don't use them much anymore. I've mostly moved on to Aarch64.

Provide your postal mailing address, if you want them.

Jeff

Bug#1065567: timedatectl does not recognize ntpsec

[Jeffrey Walton]

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 such a ntp-units.d snippet
> and you have further questions, please ask.

Thank you sir!

Bug#1065567: timedatectl does not recognize ntpsec

[Jeffrey Walton]

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 time: Wed 2024-03-06 17:35:32
Time zone: America/New_York (EST, -0500)
System clock synchronized: yes
  NTP service: n/a
  RTC in local TZ: no

According to , ntpsec
is an option for Debian 11 and below; and default for Debian 12 and
above.

I searched for an upstream bug at 
(is that the right place?), but there were no relevant hits. See
.

Also see .
That's the debian-users mailing list discussion with GW's comment.

Bug#1063916:

[Jeffrey Walton]

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 have already reached out to Canonical Legal for assessment on the
concerns with regards to Ubuntu.  If they rule similarly, then we face
a similar hurdle, which will prohibit us from using the Debian or
Ubuntu repositories to distribute freenginx.

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

[Jeffrey Walton]

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 
> ngnix project will play out re. cross-merges, security issues (which are very 
> likely to be the same for both projects for quite a while given the shared 
> code), etc.
>
> If nginx and freenginx diverge too much on functionality, it might make sense 
> to have both in Debian.  If they do not, we more likely should stick with 
> either one, but not both (and it is way too early to even guess which one 
> would make sense to stick to)...
>
> There are other potential issues as well, it is best to wait a couple months 
> at the very least.

Thank you sir!

And my apologies for selecting the wrong license. That was a
copy/paste error from the sample wnpp request.

Jeff

Bug#1063916:

[Jeffrey Walton]

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

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

[Jeffrey Walton]

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: C
  Description : a fork of nginx maintained by Maxim Dounin and the
development community

-

In February 2024, Maxim Dounin forked Nginx and created the freenginx
project. According to Maxim's announcement on the nginx-users mailing
list 
():


Hello!

As you probably know, F5 closed Moscow office in 2022, and I no
longer work for F5 since then.  Still, we’ve reached an agreement
that I will maintain my role in nginx development as a volunteer.
And for almost two years I was working on improving nginx and
making it better for everyone, for free.

Unfortunately, some new non-technical management at F5 recently
decided that they know better how to run open source projects.  In
particular, they decided to interfere with security policy nginx
uses for years, ignoring both the policy and developers’ position.

That’s quite understandable: they own the project, and can do
anything with it, including doing marketing-motivated actions,
ignoring developers position and community.  Still, this
contradicts our agreement.  And, more importantly, I no longer able
to control which changes are made in nginx within F5, and no longer
see nginx as a free and open source project developed and
maintained for the public good.

As such, starting from today, I will no longer participate in nginx
development as run by F5.  Instead, I’m starting an alternative
project, which is going to be run by developers, and not corporate
entities:

http://freenginx.org/

The goal is to keep nginx development free from arbitrary corporate
actions.  Help and contributions are welcome.  Hope it will be
beneficial for everyone.

-- 
Maxim Dounin
http://freenginx.org/

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

[Jeffrey Walton]

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

[Jeffrey Walton]

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: initramfs-tools
Version: 0.142
Installed-Size: 113
Maintainer: Debian kernel team 
Architecture: all
Provides: linux-initramfs-tool
...
Section: utils
Priority: optional
Filename: pool/main/i/initramfs-tools/initramfs-tools_0.142_all.deb
Size: 72864
MD5sum: b00b1c4ad31046ed1f80852bf20161f2
SHA256: dd1b867fd967471b0f775fdb3b4a534d4ae70bdb56a93b1ffcf60965813b

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

[Jeffrey Walton]

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) ...
update-initramfs: Generating /boot/initrd.img-6.5.0-5-amd64
cp: warning: behavior of -n is non-portable and may change in future;
use --update=none instead
cp: warning: behavior of -n is non-portable and may change in future;
use --update=none instead
cp: warning: behavior of -n is non-portable and may change in future;
use --update=none instead
cp: warning: behavior of -n is non-portable and may change in future;
use --update=none instead
...

I'm not sure how '--update=none' is more portable than '-n'. It seems
like '--update=none' would be less portable (to me). But nevertheless,
there's lots of warnings during the upgrade.

-
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux trixie/sid
Release:n/a
Codename:   trixie
-
$ apt-cache show plymouth
Package: plymouth
Version: 24.004.60-1
Installed-Size: 758
Maintainer: Laurent Bigonville 
Architecture: amd64
...
Priority: optional
Filename: pool/main/p/plymouth/plymouth_24.004.60-1_amd64.deb
Size: 140764
MD5sum: 32f3d19c3cb53480ffee9c0156a60de4
SHA256: c5ee6a2708d6f92054cc4b6110d3b6026f1a31119b26ab3f86747f9fab6807cc

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

[Jeffrey Walton]

It looks like tn5250j has moved to GitHub, .

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

[Jeffrey Walton]

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 + src:graph-tool
>
> the latest version of graph-tool did not build on ppc64el[1].
> There is the following error in the log:
>
> /usr/include/boost/math/tools/promotion.hpp:267:27: error: static assertion 
> failed: Sorry, but this platform does not have sufficient long double support 
> for the special functions to be reliably implemented.
>   267 |  static_assert((0 == std::is_same::value), 
> "Sorry, but this platform does not have sufficient long double support for 
> the special functions to be reliably implemented.");
>   |~~~^~
>
> It seems the latest boost is doing some check that can not be fulfilled
> on ppc64el.  Thus I think it is best to remove the binary package for
> ppc64el for the moment to enable the testing migration of graph-tool
> (and completing the boost transition by doing so).
>
> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=graph-tool=ppc64el=2.59%2Bds-1=1704656087=0

I wonder if you are seeing the effects of a 128-bit long double. If it
is, then -mlong-double-80 may help. I've had to use -mlong-double-80
in the past with some GNU software because it lacked support for
128-bit floats.

The companion option is -mlong-double-128. Also see
.

Jeff

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

[Jeffrey Walton]

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]:
>
> -- Looking for pow in m - found
> -- Looking for pthread_create in pthread
> -- Looking for pthread_create in pthread - found
> -- Looking for backtrace in execinfo
> Segmentation fault
>
> I have performed a local LLVM test build and obtained a backtrace with gdb
> which also indicates a crash in libuv:
>
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x in ?? ()
> [Current thread is 1 (Thread 0x7fff811f6e60 (LWP 2635470))]
> (gdb) bt
> #0  0x in ?? ()
> #1  
> #2  0x7fff82eee784 in __GI_epoll_pwait (epfd=4, events=0x7fffd3808cc8, 
> maxevents=1024, timeout=-1, set=0x0) at 
> ../sysdeps/unix/sysv/linux/epoll_pwait.c:40
> #3  0x7fff83545238 in uv__io_poll (loop=0x10015e8edd0, timeout=-1) at 
> ./src/unix/linux.c:1365
> #4  0x7fff8352aa84 in uv_run (loop=0x10015e8edd0, mode=UV_RUN_ONCE) at 
> ./src/unix/core.c:447
> #5  0x000132669d8c in cmExecuteProcessCommand (args=..., status=...) at 
> ./Source/cmExecuteProcessCommand.cxx:358
> #6  0x000132561d38 in InvokeBuiltinCommand (status=..., args=..., 
> command=@0x133045248: 0x1326682b0 
>  std::char_traits,
> std::allocator >, std::allocator std::char_traits, std::allocator > > > const&, 
> cmExecutionStatus&)>)
> at ./Source/cmState.cxx:420
> #7  operator() (status=..., args=..., __closure=) at 
> ./Source/cmState.cxx:430
> #8  std::__invoke_impl BuiltinCommand)::&, 
> cmExecutionStatus&)>&, const
> std::vector >&, 
> cmExecutionStatus&> (__f=...) at /usr/include/c++/13/bits/invoke.h:61
> #9  std::__invoke_r BuiltinCommand)::&, 
> cmExecutionStatus&)>&, const std::vector std::allocator >&, cmExecutionStatus&> (__fn=...) at 
> /usr/include/c++/13/bits/invoke.h:114
> #10 std::_Function_handler std::allocator >&, cmExecutionStatus&), 
> cmState::AddBuiltinCommand(const std::string&,
> BuiltinCommand):: std::allocator >&, cmExecutionStatus&)> 
> >::_M_invoke(const std::_Any_data &, const std::vector std::allocator > &, cmExecutionStatus &) (__functor=..., 
> __args#0=..., __args#1=...) at /usr/include/c++/13/bits/std_function.h:290
>
> This bug has also been reported for openSUSE [2] and Simon Lees at SUSE said 
> he
> would be looking into it. In case he comes up with a solution, I will report 
> it
> here.
>
> > [1] 
> > https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-17=ppc64=1%3A17.0.6-4%2Bb2=1704985815=0
> > [2] https://bugzilla.suse.com/show_bug.cgi?id=1218365

It may be a good idea to give the CMake folks the first chance at the
fix. It does not look like it has been reported to them:
. Searching with
'ppc' and 'llvm' tags returned 0 hits:
.
(Maybe I missed it in their bug tracker).

Jeff

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

[Jeffrey Walton]

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 clears
most (not all) of the ShellCheck warnings.

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

[Jeffrey Walton]

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

[Jeffrey Walton]

Also see .

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

[Jeffrey Walton]

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

[Jeffrey Walton]

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 with ShellCheck, it looks like there are some
opportunities for improvement in the script.

In the past, I've had problems with the way `read` was used when I
created subdirectories under /usr/local/share/ca-certificates and
placed certificates in them (re: SC2162 below).

-

# shellcheck $(command -v update-ca-certificates)

In /usr/sbin/update-ca-certificates line 101:
  sed -e '$a\' "$CERT" >> "$TEMPBUNDLE"
^-- SC1003 (info): Want to escape a single quote? echo
'This is how it'\''s done'.

In /usr/sbin/update-ca-certificates line 117:
  find . -type l -print | while read symlink
^--^ SC2162 (info): read without -r
will mangle backslashes.

In /usr/sbin/update-ca-certificates line 120:
  $CERTSDIR*|$LOCALCERTSDIR*) rm -f $symlink;;
^--^ SC2086 (info): Double
quote to prevent globbing and word splitting.

Did you mean:
  $CERTSDIR*|$LOCALCERTSDIR*) rm -f "$symlink";;

In /usr/sbin/update-ca-certificates line 123:
  find . -type l -print | while read symlink
^--^ SC2162 (info): read without -r
will mangle backslashes.

In /usr/sbin/update-ca-certificates line 134:
  find -L "$CERTSDIR" -type f -name '*.crt' | sort | while read crt
   ^--^ SC2162
(info): read without -r will mangle backslashes.

In /usr/sbin/update-ca-certificates line 142:
sed -n -e '/^$/d' -e 's/^!//p' "$CERTSCONF" | while read crt
^--^ SC2162
(info): read without -r will mangle backslashes.

In /usr/sbin/update-ca-certificates line 147:
sed -e '/^$/d' -e '/^#/d' -e '/^!/d' "$CERTSCONF" | while read crt
  ^--^ SC2162
(info): read without -r will mangle backslashes.

In /usr/sbin/update-ca-certificates line 161:
  find -L "$LOCALCERTSDIR" -type f -name '*.crt' | sort | while read crt
^--^
SC2162 (info): read without -r will mangle backslashes.

In /usr/sbin/update-ca-certificates line 175:
  find $ETCCERTSDIR -type l ! -exec test -e {} \; -print | while read orphan
   ^--^ SC2086 (info): Double quote to prevent globbing
and word splitting.
 ^--^
SC2162 (info): read without -r will mangle backslashes.

Did you mean:
  find "$ETCCERTSDIR" -type l ! -exec test -e {} \; -print | while read orphan

In /usr/sbin/update-ca-certificates line 207:
  eval run-parts "$VERBOSE_ARG" --test -- "$HOOKSDIR" | while read hook
  ^--^
SC2162 (info): read without -r will mangle backslashes.

For more information:
  https://www.shellcheck.net/wiki/SC1003 -- Want to escape a single quote? ec...
  https://www.shellcheck.net/wiki/SC2086 -- Double quote to prevent globbing ...
  https://www.shellcheck.net/wiki/SC2162 -- read without -r will mangle backs...

-

# dpkg -S /usr/sbin/update-ca-certificates
ca-certificates: /usr/sbin/update-ca-certificates

-

# apt show ca-certificates
Package: ca-certificates
Version: 20230311
Priority: standard
Section: misc
Maintainer: Julien Cristau 
Installed-Size: 393 kB
Depends: openssl (>= 1.1.1), debconf (>= 0.5) | debconf-2.0
Breaks: ca-certificates-java (<< 20121112+nmu1)
Enhances: openssl
Tag: protocol::ssl, role::app-data, security::authentication
Download-Size: 153 kB
APT-Manual-Installed: yes
APT-Sources: http://deb.debian.org/debian unstable/main amd64 Packages
Description: Common CA certificates
...

Bug#1050878: Emacsen fails to install in Debian Chroot

[Jeffrey Walton]

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 other chroots, like aarch64 and powerpc.

--

Setting up emacs-nox (1:28.2+1-7) ...
Install emacsen-common for emacs
emacsen-common: Handling install of emacsen flavor emacs
>>Error occurred processing /usr/share/emacs/site-lisp/debian-startup.el: File 
>>error (("Doing chmod" "Operation not supported" 
>>"/usr/share/emacs/site-lisp/debian-startup.elcSfHxT7"))
ERROR: install script from emacsen-common package failed
dpkg: error processing package emacs-nox (--configure):
 installed emacs-nox package post-installation script subprocess
returned error exit status 1
Setting up emacsen-common (3.0.5) ...
Install emacsen-common for emacs
emacsen-common: Handling install of emacsen flavor emacs
>>Error occurred processing /usr/share/emacs/site-lisp/debian-startup.el: File 
>>error (("Doing chmod" "Operation not supported" 
>>"/usr/share/emacs/site-lisp/debian-startup.elcSCq0OS"))
ERROR: install script from emacsen-common package failed
dpkg: error processing package emacsen-common (--configure):
 installed emacsen-common package post-installation script subprocess
returned error exit status 1
Errors were encountered while processing:
 emacs-nox
 emacsen-common
E: Sub-process /usr/bin/dpkg returned an error code (1)

--

$ apt-cache show emacsen-common
Package: emacsen-common
Version: 3.0.5
Installed-Size: 55
Maintainer: Rob Browning 
Architecture: all
Conflicts: emacs19, emacs20, emacs21-common, emacs22-common,
emacs23-common, emacs24-common, emacs25-common, xemacs21-support (<<
21.4.24-6~)
Description-en: Common facilities for all emacsen
 This package contains code that is needed by all the (x)emacs
 packages.  It will be automatically installed when needed.
Description-md5: 181ad2d7eef0b855d8f6d9bbf2373d8a
Tag: admin::configuring, devel::editor, implemented-in::lisp, role::app-data,
 role::plugin, role::program, suite::emacs, use::configuring,
 use::editing, works-with::text
Section: editors
Priority: optional
Filename: pool/main/e/emacsen-common/emacsen-common_3.0.5_all.deb
Size: 12296
MD5sum: a6eb6b8921f977740f03b2bcee477c95
SHA256: 74d972556adf85fbbfb0b3b10dcf16687547a9ef521c7c86f5cda454e11a60df

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

[Jeffrey Walton]

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 exists in the archive, but is severely outdated and
> likely to have a very large number of security vulnerabilities. Newer
> versions of firefox do not build successfully on mipsel. I think it would
> be better for this package to be missing from mipsel altogether (the same
> as firefox-esr), rather than existing but being old and dangerous.

That's probably a good choice.

> It's also one of the few packages still depending on the transitional
> libgdk-pixbuf2.0-0 package, which should be removed in trixie (ideally
> it should have been removed already in bookworm, but that didn't happen).

Is there an upgrade path for users on mipsel? Do they have a graphical
web browser they can install, even if it is not Firefox or Chrome?

Jeff

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

[Jeffrey Walton]

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.
> https://security-tracker.debian.org/tracker/source-package/c-ares and 
> CVE-specific pages, e.g.
> https://security-tracker.debian.org/tracker/CVE-2023-31147

Be careful with trying to classify as important (security related) and
unimportant (not security related). It depends on proper
classification, and that does not always happen. Folks missed the
unimportant TTY1 layer bug for years until it became a CVE. CF.,
https://thenewstack.io/design-system-can-update-greg-kroah-hartman-linux-security/
.

I've also seen CVE-worthy bugs go without a CVE because someone could
not get the form on mitre.org to submit. At release time the Changelog
just said, "fixed bug XXX. This probably should have gotten a CVE."

And finally, many developers just fix important bugs without giving
them much thought. Fix it, check-in, move onto the next bug. No time
to analyze impact. In the past, I've cleared some memory problems and
wondered if someone could exploit them.

> This is a little misleading, since those packages are not actually vulnerable.
> It would be nice if such "unimportant" issues it would instead display
> "unfixed (no/negligible security impact)" instead. And instead of red maybe
> in grey.

Grey or orange might make a good choice to differentiate them from
important or security updates. Grey almost feels like "disabled" and
you won't be acting on it. Maybe orange would be the better choice.

Jeff

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

[Jeffrey Walton]

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
> Author: Lasse Collin 
> Date:   2022-11-14 17:58:07 +0200
>
> Build: Omit x86_64 from --enable-assembler.
>
> It didn't do anything. There are only 32-bit x86 assembly files
> and it feels likely that new files won't be added as intrinsics
> in C are more portable across toolchains and OSes.
>
> The attached patch fixes that by dropping that option, since it's not
> useful for amd64 ports anyway.

I think it is a bad idea to rely solely on intrinsics. Intrinsics have
their own problems. For example, suppose you have a function that is
implemented in C, SSE4 and AVX. Your project would be setup with:

* my_func.c compiled with base ISA options
* my_func_sse4.c compiled with -march=sse_41
* my_func_avx.c compiled with -march=avx
* a function pointer to select a C, SSE4 or AVX implementation
* an initializer that sets the function pointer at startup.

If you run on a SSE4 machine (or below), then you could segfault in
my_func_avx translation unit _if_ the compiler uses AVX instructions
in the TU.

I've had the exact situation happen to me with both GCC and Clang. My
code was guarded behind a feature test, but the GCC and Clang code was
not guarded. The unguarded compiler code caused a SIGILL. I had it
happen to me with both GCC and Clang on PowerPC, i686, and x86_64.
See, for example,
https://lists.llvm.org/pipermail/llvm-dev/2018-December/128159.html .

The fix is to have the compiler _stop_ hijacking my ISA. We are forced
to use an option like -march=avx. That does not mean the compiler
should assume it can use it. But the GCC and Clang compilers got it
wrong.

Microsoft compilers got it right. You can use any intrinsic the
compiler supports without an option. If you supply an option, like
/arch:avx, then Microsoft compilers take that as a signal they can
generate code for AVX. Otherwise, Microsoft compilers just use the
base ISA.

So be careful about using those intrinsics.

> -- System Information:
> Debian Release: 12.0
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
> 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
> 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 
> 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 
> 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), 
> (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386, arm64
>
> Kernel: Linux 6.2.0 (SMP w/8 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages xz-utils depends on:
> ii  libc6 2.36-9
> ii  liblzma5  5.4.1-0.2
>
> xz-utils recommends no packages.
>
> xz-utils suggests no packages.
>
> -- no debconf information

Bug#1028917: passwd package missing dependency

[Jeffrey Walton]

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

[Jeffrey Walton]

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
https://cryptopp.com/wiki/Debian_Chroot#SH-4 .

Start with Debian Unstable/Sid.

Then add the following packages:

# apt install qemu qemu-user-static binfmt-support debootstrap
debian-archive-keyring debian-ports-archive-keyring

And then setup the SH-4 guest:

# qemu-debootstrap --arch=sh4 --keyring
/usr/share/keyrings/debian-ports-archive-keyring.gpg \
  --variant=buildd --exclude=debfoster unstable debian-sh4
http://ftp.ports.debian.org/debian-ports

Finally, enter the SH-4 guest with:

# chroot debian-sh4

Jeff

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

[Jeffrey Walton]

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 to build from source on mipsel, where it built
> > successfully in the past.
> >
> > https://buildd.debian.org/status/fetch.php?pkg=r-cran-glmmtmb=mipsel=1.1.5%2Bdfsg-1=1669057119=0
> > ...
> > cc1plus: out of memory allocating 1058400 bytes after a total of 59473920 
> > bytes
>
> Isn't this just a matter of the autobuilders hardware?
>
> If not I do not see any other clue but removing the package for mipsel.

You might also see how many make jobs the build system is using. If
it's more than 1, then halve the number of jobs.

I used to experience the crash often on early ARM dev-boards with 1GB
of RAM and no swap file when building Crypto++. I used to run 'make -j
4' and it would crash the compiler. The workaround (for us) was to run
'make -j 1'.

Eventually I decided to add a swap file to the SDcard and set
swappiness to a low number, like 2. That fixed most of the performance
problems, but we would eat SDcards about every 3 to 6 months.

Jeff

Bug#1025176: libicu71 missing on SH4 port

[Jeffrey Walton]

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 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 its upstream?
> > > At least this is what I see without access to any sh4 machine. As we
> > > know each other, I may check it for you if I can access that machine.
> > > But I think you are much more skilled in these things.
> >
> > Yes, sure. Let me take a look at python-greenlet on SH4.
>
> Ok, so I had a look at this last night. I don't think I am going to be
> able to help with improving Greenlet. For Greenlet, I think the best
> course of action is to ping the Greenlet developers and ask them for
> help with SH4.
>
> The #error is triggered because there's no switch_sh4_linux.h in [1].
> The file provides a function called slp_switch(), and it is inline
> ASM. Based on other arch files, it looks like the function does some
> sort of manual switching on app-managed lightweight threads. So the
> function uses inline ASM to save/restore registers and move the stack
> pointer around (if I am parsing things correctly).
>
> Unfortunately, I think that's a bit outside my comfort zone. I don't
> know Greenlet, and I don't know SH4 ASM. For completeness, here is the
> SH4 software manual: [2].
>
> If the Greenlet developers decline to port to SH4, then I think the
> next step is to remove the Greenlet dependency on SH4. Maybe there's a
> configure option in GDB, Boost or Python that can ultimately sidestep
> the dependency on SH4. I think the first team to engage is the GDB
> team. They may have a suggestion to shed the Boost dependency.
>
> [1] 
> https://github.com/python-greenlet/greenlet/tree/master/src/greenlet/platform
> [2] https://www.renesas.com/us/en/document/mas/sh-4-software-manual

Ok, so it looks like the Greenlet developers have an open bug report
at [1]. It was opened Apr 19, 2020. I'm guessing the Greenlet
developers are not going to provide the support given they've had over
2 years to do so.

I think that leaves contacting the GDB folks to see if there's a way
to sidestep Boost dependency.

[1] https://github.com/python-greenlet/greenlet/issues/166

Bug#1025176: libicu71 missing on SH4 port

[Jeffrey Walton]

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 would be to
> > port python-greenlet to sh4 or just fix its build - can you give a
> > helping hand to its upstream?
> > At least this is what I see without access to any sh4 machine. As we
> > know each other, I may check it for you if I can access that machine.
> > But I think you are much more skilled in these things.
>
> Yes, sure. Let me take a look at python-greenlet on SH4.

Ok, so I had a look at this last night. I don't think I am going to be
able to help with improving Greenlet. For Greenlet, I think the best
course of action is to ping the Greenlet developers and ask them for
help with SH4.

The #error is triggered because there's no switch_sh4_linux.h in [1].
The file provides a function called slp_switch(), and it is inline
ASM. Based on other arch files, it looks like the function does some
sort of manual switching on app-managed lightweight threads. So the
function uses inline ASM to save/restore registers and move the stack
pointer around (if I am parsing things correctly).

Unfortunately, I think that's a bit outside my comfort zone. I don't
know Greenlet, and I don't know SH4 ASM. For completeness, here is the
SH4 software manual: [2].

If the Greenlet developers decline to port to SH4, then I think the
next step is to remove the Greenlet dependency on SH4. Maybe there's a
configure option in GDB, Boost or Python that can ultimately sidestep
the dependency on SH4. I think the first team to engage is the GDB
team. They may have a suggestion to shed the Boost dependency.

[1] 
https://github.com/python-greenlet/greenlet/tree/master/src/greenlet/platform
[2] https://www.renesas.com/us/en/document/mas/sh-4-software-manual

Bug#1025176: libicu71 missing on SH4 port

[Jeffrey Walton]

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 its upstream?
> At least this is what I see without access to any sh4 machine. As we
> know each other, I may check it for you if I can access that machine.
> But I think you are much more skilled in these things.

Yes, sure. Let me take a look at python-greenlet on SH4.

I would have done that already, but I could not figure out which
package was the problem. Sorry about that!

One word of caution... python-greenlet is described as "greenlets are
lightweight coroutines for in-process sequential concurrent
programming." I know Git has a problem with threads on SH4.[1] So the
problem may be a little deeper than a library port. It may be down in
libc or the kernel. Put another way, it may be beyond my skill level.

[1] 
https://lore.kernel.org/git/cah8yc8niurchnxprzseba7g1z5af3pqydf1x0rm03rdanec...@mail.gmail.com/

Jeff

Bug#1025176: libicu71 missing on SH4 port

[Jeffrey Walton]

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 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:
 libboost-regex1.74.0 : Depends: libicu71 (>= 71.1-1~) but it is not installable
E: Unable to correct problems, you have held broken packages.

The rub is, SH4 is not listed at
https://packages.debian.org/sid/libicu71 . The package page also shows
version 71.1-3, not 71.1-1.

I'm not really sure how to proceed.

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

[Jeffrey Walton]

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 various atomic
> > builtins:
> >
> > > (.text+0x0): multiple definition of `__sync_fetch_and_add_4'; 
> > > /home/smcv/mozjs91-armel/debian/build/armv5te-unknown-linux-gnueabi/release/libjsrust.a(compiler_builtins-23c2fc8f8ef06d87.compiler_builtins.bdb7b41d-cgu.153.rcgu.o):/usr/src/rustc-1.59.0/vendor/compiler_builtins/src/arm_linux.rs:94:
> > >  first defined here
>
> Reported upstream as https://bugzilla.mozilla.org/show_bug.cgi?id=1786623

Also see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104248#c2 (and
more generally https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358).

> > (For completeness: 91.10.0-1 and 91.12.0-1 have an additional failure
> > reason involving undefined references to
> > std::type_info::operator==(std::type_info const&) const, but I believe
> > that was fixed in 91.12.0-2 by removing an obsolete patch.)
>
> Correction, it was fixed by a patch removing an obsolete workaround.
> Reported as https://bugzilla.mozilla.org/show_bug.cgi?id=1786621 (but we
> already have a patch for this, so it's an upstream bug but not a Debian bug)

Jeff

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

[Jeffrey Walton]

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 dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  lldb
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

I think there may be something wrong with the lldb package at the moment.

-

# apt-cache show lldb
Package: lldb
Source: llvm-defaults (0.55.1)
Version: 1:14.0-55.1
Installed-Size: 23
Maintainer: LLVM Packaging Team 
Architecture: amd64
Depends: lldb-14 (>= 14~)
Description-en: Next generation, high-performance debugger
...
This is a dependency package providing the default version of lldb.
Description-md5: ead6eb91f74bd6143cb488df627284c1
Multi-Arch: same
Section: devel
Priority: optional
Filename: pool/main/l/llvm-defaults/lldb_14.0-55.1_amd64.deb
Size: 9344
MD5sum: 7f5a61adfe6837cd29001fae18f98b9a
SHA256: f97706b38c0d7293b9b9529584101854b035bf6fe013083a51411a2c0d34bdba

Package: lldb
Status: install ok installed
Priority: optional
Section: devel
Installed-Size: 22
Maintainer: LLVM Packaging Team 
Architecture: amd64
Source: llvm-defaults (0.51+nmu5)
Version: 1:11.0-51+nmu5
Depends: lldb-11 (>= 11~)
Description-en: Next generation, high-performance debugger
...
This is a dependency package providing the default version of lldb.
Description-md5: ead6eb91f74bd6143cb488df627284c1

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

[Jeffrey Walton]

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 questions
over at the kernel's b43 mailing list
(http://lists.infradead.org/mailman/listinfo/b43-dev).

# apt-get install firmware-b43-installer
Reading package lists... Done
Building dependency tree... Done
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:
 firmware-b43-installer : Depends: b43-fwcutter (>= 1:019-7) but it is
not installable
E: Unable to correct problems, you have held broken packages.

And then

# apt-get install b43-fwcutter
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package b43-fwcutter 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 'b43-fwcutter' has no installation candidate

$ apt-cache show b43-fwcutter
N: Can't select versions from package 'b43-fwcutter' as it is purely virtual
N: No packages found

$ apt-cache search b43-fwcutter
$

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux bookworm/sid
Release:unreleased
Codename:   sid

$ uname -a
Linux PowerMac 5.16.0-6-powerpc64 #1 SMP Debian 5.16.18-1 (2022-03-29)
ppc64 GNU/Linux

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

[Jeffrey Walton]

> -- 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 directly.
> You have filed an issue upstream with the filezilla project and you must wait 
> for the developer(s)
> to assist you.
>
> This is not a Debian bug, so is being closed.

Debian provides Filezilla. See
https://packages.debian.org/stable/filezilla,
https://packages.debian.org/stable/filezilla-common and friends.

Jeff

Bug#1006554: Update Filezilla packages

[Jeffrey Walton]

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 from source, but
configure is failing. The version of Filezilla client is from trunk.
It was checked out with 'svn co
https://svn.filezilla-project.org/svn/FileZilla3/trunk filezilla'.

$ autoreconf -i
...
$ ./configure
...
checking for libfilezilla >= 0.36.0... no
configure: error: libfilezilla not found: Requested 'libfilezilla >=
0.36.0' but version
of libfilezilla is 0.19.3
You may find new versions of libfilezilla at
https://lib.filezilla-project.org/. You can
download it from https://lib.filezilla-project.org/

It would be nice if the Filezilla client built all the stuff it needs,
but that's not happening here.

Please update libfilezilla when you have some time.

Thanks in advance.

==

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 20.04.4 LTS
Release:20.04
Codename:   focal

==

$ apt-cache show filezilla
Package: filezilla
Architecture: amd64
Version: 3.46.3-1build1
Priority: optional
Section: universe/net
Origin: Ubuntu
Maintainer: Adrien Cunin 
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 7065
Depends: filezilla-common (= 3.46.3-1build1), libc6 (>= 2.28),
libdbus-1-3 (>= 1.9.14),
libfilezilla0 (>= 0.19.3), libgcc-s1 (>= 3.0), libgtk-3-0 (>= 3.0.0),
libpugixml1v5 (>=
1.7), libsqlite3-0 (>= 3.5.9), libstdc++6 (>= 5.2), libwxbase3.0-0v5
(>= 3.0.4+dfsg), li
bwxgtk3.0-gtk3-0v5 (>= 3.0.4+dfsg-10~)
Recommends: xdg-utils
Breaks: libfilezilla (<< 0.18.2-2)
Filename: pool/universe/f/filezilla/filezilla_3.46.3-1build1_amd64.deb
Size: 1925380
MD5sum: eb1324b091aefe2c592ffb36a8b53e99
SHA1: ca0826b6ed74dffc67f1542c96e5860ddc702e81

Bug#1001995: libcrypto++: ftbfs on armhf

[Jeffrey Walton]

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 will be part of Crypto++ 8.7. We should be
releasing Crypto++ 8.7 within the next 15 days or so. I plan on early
March 2022.

Jeff

Bug#1001995: libcrypto++: ftbfs on armhf

[Jeffrey Walton]

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 not using fp or neon, so we don't declare
it.

This could be GCC's bug because GCC knows a fp unit is used, and knows
it is hardfloat ABI, but it fails to compile/assemble the source
because we did not specify an option we are not using. If GCC knows
the ABI, then it should use that knowledge. And it makes no sense to
me to declare options we are not using. I'm not getting into that
business.

This could be a Debian bug because the compiler configuration could be
incomplete. Apparently an ABI is specified, but a fp is not. Debian
should supply both or neither. Supplying half of the configuration
seems like a mistake because it is confusing the compiler. For what
it's worth, I sympathize with Debian here. How can you have an
architecture with a hardfloat ABI but not have a fp unit? It makes no
sense to me.

Maybe Debian will have better luck helping the GCC folks to sort out
their twisted logic.

Jeff

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

[Jeffrey Walton]

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 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 Debian's builder (?) environment.
> > Years ago I was told to do the Qemu/Chroot thing when trying to
> > reproduce the bugs.
> >
> > For ARM I am kind of following
> > https://wiki.debian.org/ArmHardFloatChroot .
>
> Right, that's the first page I found on Google as well. That doesn't
> reference ports.debian.org though and even when it did never used
> "debian-armhf" as part of the path.
>
> If there's still documentation out there that suggests using the
> ports.d.o archive for armhf then it's _very_ out of date and may well
> have other issues.

https://www.debian.org/ports/

Jeff

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

[Jeffrey Walton]

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 Debian's builder (?) environment.
Years ago I was told to do the Qemu/Chroot thing when trying to
reproduce the bugs.

For ARM I am kind of following https://wiki.debian.org/ArmHardFloatChroot .

Jeff

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

[Jeffrey Walton]

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 https://ftp-master.debian.org/keys.html.

'apt-get update && apt-get upgrade && apt-get dist-upgrade' was run on
this Sid machine after changing sources.list. The machine is fully
patched, and nothing has been held back.

root@debian-unstable:~# qemu-debootstrap --arch=armhf --keyring
/usr/share/keyrings/debian-archive-keyring.gpg --variant=buildd
--exclude=debfoster unstable debian-armhf
http://ftp.ports.debian.org/debian-ports
W: qemu-debootstrap is deprecated. Please use regular debootstrap directly
I: Running command: debootstrap --arch=armhf --keyring
/usr/share/keyrings/debian-archive-keyring.gpg --variant=buildd
--exclude=debfoster unstable debian-armhf
http://ftp.ports.debian.org/debian-ports
I: Target architecture can be executed
I: Retrieving InRelease
I: Checking Release signature
E: Release signed by unknown key (key id E852514F5DF312F6)
   The specified keyring
/usr/share/keyrings/debian-archive-keyring.gpg may be incorrect or out
of date.
   You can find the latest Debian release key at
https://ftp-master.debian.org/keys.html

root@debian-unstable:~# debootstrap --arch=armhf --keyring
/usr/share/keyrings/debian-archive-keyring.gpg --variant=buildd
--exclude=debfoster unstable debian-armhf
http://ftp.ports.debian.org/debian-ports
I: Target architecture can be executed
I: Checking Release signature
E: Release signed by unknown key (key id E852514F5DF312F6)
   The specified keyring
/usr/share/keyrings/debian-archive-keyring.gpg may be incorrect or out
of date.
   You can find the latest Debian release key at
https://ftp-master.debian.org/keys.html

# cat /etc/apt/sources.list
deb http://deb.debian.org/debian/ unstable main
deb-src http://deb.debian.org/debian/ unstable main

# dpkg --list debian-archive-keyring
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---==>
ii  debian-archive-keyring 2021.1.1 all  GnuPG archive
keys of the Debian a>

# apt-cache show debian-archive-keyring
Package: debian-archive-keyring
Version: 2021.1.1
Installed-Size: 234
Maintainer: Debian Release Team 
Architecture: all
Description-en: GnuPG archive keys of the Debian archive
 The Debian project digitally signs its Release files. This package
 contains the archive keys used for that.
Description-md5: 4ee78d6fd2292b9893b8eb4f5d5dd91d
Multi-Arch: foreign
Tag: role::data, security::authentication, suite::debian
Section: misc
Priority: important
Filename: 
pool/main/d/debian-archive-keyring/debian-archive-keyring_2021.1.1_all.deb
Size: 93592
MD5sum: 250bbeab4b680dbc2c4da9b10ccd773f
SHA256: 56beca470dcd9b6d7e6c3c9e9d702101e01e9467e62810a8c357bd7b9c26251d

Bug#1001995: libcrypto++: ftbfs on armhf

[Jeffrey Walton]

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

[Jeffrey Walton]

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 using -march=armv7-a+fp instead
SL > of just -march=armv7-a.

I have to admit I am a bit confused. armhf is hard floats, so the
value can only be -mfloat-abi=hard unless it is explicitly changed. We
don't change it.

As far as I know, the code does not need the floating point unit or
neon. In fact, we stopped using -mfloat-abi because we don't care what
it is. The compiler default is fine by us.

Would adding -mfpu=auto [1] be acceptable to you? I think that conveys
the "don't care" attitude when compiling and assembling this source
file.

SL > However, I have not tested that this results in correct
SL > behavior on armel, which is also still a Debian
SL > architecture but not an Ubuntu architecture.

LB > confirmed the problem and the fix as well on armhf in a
LB > Sid chroot. Still need to check it on armel.

armel is going to need CRYPTOPP_DISABLE_ARM_NEON defined in CPPFLAGS
or CXXFLAGS. The reason is my ignorance. I don't know how to
differentiate between armel and armhf in the preprocessor. They both
look the same to us. Preprocessor macros don't change until we start
adding options like -mfpu=neon.

So, we assume armhf and make folks do something special for armel.
armhf is the default because we believe it is the dominant use case.
That is, we think there are more armv7 devices than armv6 or below
devices.

Bug#1003847: binutils breaks glibc autopkgtest on ppc64el: unrecognized opcode: `vspltisb' (and others)

[Jeffrey Walton]

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
> > https://buildd.debian.org/status/fetch.php?pkg=glibc=ppc64=2.33-3=1642542055=0
>
> > https://buildd.debian.org/status/fetch.php?pkg=linux=powerpc=5.15.15-1=1642579068=0
> > https://buildd.debian.org/status/fetch.php?pkg=linux=ppc64=5.15.15-1=1642578946=0

This seems to be related to the ones stamped 1642542048 and 1642542055
(the first two):
https://patchwork.sourceware.org/project/glibc/patch/20210925202746.819385-1...@us.ibm.com/

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

[Jeffrey Walton]

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 associated with SNI is leaking the
server name to a passive adversary in TLS 1.2 and below. TLS 1.3 and
above provide for encrypted server names.

> It certainly ought to be disabled by default. Perhaps add some
> environment variable to enable SNI in the SSL library, and if
> it’s not present or explicitly set to 0, disable SNI (which also
> would disable TLSv1.3 as it requires SNI). Hmm, yes, this sounds
> completely like a good idea.

If you disable SNI, then you won't be able to setup an encrypted
channel. SNI is needed to setup the encrypted channel. During the
client_hello, the server needs to know which server/virtual host to
route the client_hello to.

The user:password@ is for the application layer or HTTP/HTTPS. It
should not be present in the transport layer. It is a bug in the
application layer, not the transport layer.

The transport layer does have a password based authentication scheme,
but it is going to be either Thomas Wu's Secure Remote Password (SRP)
or Preshared Key (PSK). SRP is based on Diffie-Hellman (something like
a^password), while PSK uses a symmetric cipher (something like
enc_k(password)).

> (Considering SNI also leaks the vhost addressed by the end user,
> which is otherwise hidden with wildcard certificates or grouped
> with tone others in multi-subjectAltName certificates, it ought
> to have been anyway.)

Yes, the client will learn the server's IP address. That is not
related to SNI. That's just how TLS works under the IETF's threat
model.

Maybe you are thinking of (or need) something like a Tor hidden
service. Transport Layer Security does not provide a guarantee like a
hidden service.

Wildcards are garbage. You should be wary of an operator that uses
them nowadays. A wildcard certificate could be used by an attacker to
have you connect to the receptionist's machine in the lobby running a
fake site rather than the organization's web server.

Jeff

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

[Jeffrey Walton]

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 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 for this.
> >
> > There are different philosophies about SIZE_MAX. The one that wins on
> > Hurd is, SIZE_MAX is a vulnerability.
> >
> > Also see https://lists.debian.org/debian-hurd/2021/04/msg00045.html.
>
> Could it be that you are confusing PATH_MAX and SIZE_MAX?

Oh, you're right. My bad.

Here's the patch I use for missing SIZE_MAX
(https://github.com/noloader/Build-Scripts/blob/master/patch/p11kit.patch).
I believe it works with HURD also.

--- p11-kit/lists.c
+++ p11-kit/lists.c
@@ -43,12 +43,21 @@
 #include 
 #include 
 #include 
+#include 

 #include "message.h"
 #include "p11-kit.h"
 #include "tool.h"
 #include "uri.h"

+#ifndef SIZE_MAX
+# ifdef SIZE_T_MAX
+#  define SIZE_MAX SIZE_T_MAX
+# else
+#  define SIZE_MAX MAX_SIZE
+# endif
+#endif
+
 int p11_kit_list_modules (int argc,
   char *argv[]);

Jeff

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

[Jeffrey Walton]

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 for this.

There are different philosophies about SIZE_MAX. The one that wins on
Hurd is, SIZE_MAX is a vulnerability.

Also see https://lists.debian.org/debian-hurd/2021/04/msg00045.html.

Jeff

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

[Jeffrey Walton]

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 reads and writes also appear at amd64.
>
> After some digging I gave up to understand the pointer
> calculations and such and tried to just increase the
> allocations and came up with the attached three patches.
>
> (While working at #974828 I found one such "+ 32" in
> HPCupsFilter.cpp which might be already a workaround by upstream?)
>
> With these three applied a valgrind run shows no more errors
> with amd64 or armhf, and also does not abort at armhf.
>
> As this just allocates a few extra bytes I assume that the
> print result should not be different by these patches.
> And I hope that memset'ing these buffers has no security
> related effects.
>
> For the crash is just the Halftoner patch important.
> The other two are currently just for valgrind, but that
> might change in future with compiler changes or similar.
>
> What do you think?

For the 0079 patch, this is probably a little more efficient since it
avoids a mod which may be implemented as a division:

PlaneSize= (OutputWidth[i]+7)/8; // doublecheck ... should already
be divisible by 8

The thing that is not clear to me... What is the datatype of
OutputWidth[i]? If it is a 16-bit type (or larger), then you may want:

const size_t width = sizeof(OutputWidth[0])*CHAR_BITS;
PlaneSize= (OutputWidth[i]+width-1)/8;

Jeff

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

[Jeffrey Walton]

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 $(DEB_HOST_ARCH), mipsel))
> > +override_dh_auto_configure:
> > + dh_auto_configure -- --without-openmp
> > +endif
> > +
> >  override_dh_auto_build-indep:
> >   # nothing to do here
>
> I've now uploaded now with this patch closing the bug - but as I tried to
> express I'd sleep a bit better if this issue would be recorded somewhere
> else than in a closed bug.

Maybe GCC? I believe the component is libgomp.

If you have a good idea of the problematic source file, then add the
preprocessoed source with the report. Also see
https://gcc.gnu.org/bugs/.

If you don't have an idea, then maybe someone like Andrew or Ian can
provide some suggestions.

Jeff

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

[Jeffrey Walton]

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)
> > ==13209==by 0x119410: AlignmentOrder (clustal-omega.c:835)
> > ==13209==by 0x11A6C4: Align (clustal-omega.c:1221)
> > ==13209==by 0x1171C8: MyMain (mymain.c:1192)
> > ==13209==by 0x113CCC: main (main.cpp:469)
>
> Here is line 346 in
> https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/pair_dist.c#L346:
>
> NewProgress(, LogGetFP(, LOG_INFO),
> "Ktuple-distance calculation progress", bPrintCR);
>
> For testing, change LogGetFP(, LOG_INFO) for stdout for testing. I.e.,
>
> NewProgress(, stdout,,
> "Ktuple-distance calculation progress", bPrintCR);
>
> It looks like LogGetFP retrieves an entry in an array of FILE*. From
> https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/log.h:
>
> typedef struct {
> /* the higher the level, the more priority it has. numbers must be
>  *  sequential
>  */
>
> /* array of function pointers */
> void (*prFunc[LOG_NUM_LEVELS]) (FILE *prFP, char *pcFormat,
> va_list rVArgList);
> FILE *prFP[LOG_NUM_LEVELS];
> char *prPrefix[LOG_NUM_LEVELS];
>
> /* everything above this level will be printed */
> int iLogLevelEnabled;
> } log_t;
>
> And 
> https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/log.c:
>
> FILE *
> LogGetFP(log_t *prLog, int iLevel)
> {
> assert(iLevel>=0 && iLevel<=LOG_NUM_LEVELS);
> return prLog->prFP[iLevel];
> }
>
> That should help determine if something is sideways in the log_t structure.

Also, I think this should be:

> FILE *
> LogGetFP(log_t *prLog, int iLevel)
> {
> assert(iLevel>=0 && iLevel return prLog->prFP[iLevel];
> }

That is, 'iLevel

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

[Jeffrey Walton]

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 (clustal-omega.c:1221)
> ==13209==by 0x1171C8: MyMain (mymain.c:1192)
> ==13209==by 0x113CCC: main (main.cpp:469)

Here is line 346 in
https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/pair_dist.c#L346:

NewProgress(, LogGetFP(, LOG_INFO),
"Ktuple-distance calculation progress", bPrintCR);

For testing, change LogGetFP(, LOG_INFO) for stdout for testing. I.e.,

NewProgress(, stdout,,
"Ktuple-distance calculation progress", bPrintCR);

It looks like LogGetFP retrieves an entry in an array of FILE*. From
https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/log.h:

typedef struct {
/* the higher the level, the more priority it has. numbers must be
 *  sequential
 */

/* array of function pointers */
void (*prFunc[LOG_NUM_LEVELS]) (FILE *prFP, char *pcFormat,
va_list rVArgList);
FILE *prFP[LOG_NUM_LEVELS];
char *prPrefix[LOG_NUM_LEVELS];

/* everything above this level will be printed */
int iLogLevelEnabled;
} log_t;

And https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/log.c:

FILE *
LogGetFP(log_t *prLog, int iLevel)
{
assert(iLevel>=0 && iLevel<=LOG_NUM_LEVELS);
return prLog->prFP[iLevel];
}

That should help determine if something is sideways in the log_t structure.

Jeff

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

[Jeffrey Walton]

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
https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/progress.c#L53.
It uses a progress_t at
https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/progress.h#L25.

typedef struct {
/* where to write to */
FILE *prFile;
/* prefix printed before each step */
char *pcPrefix;
bool bPrintCR;
char pcLastLogMsg[1024];
Stopwatch_t *prStopwatch;
} progress_t;

And stopwatch_t at
https://salsa.debian.org/med-team/clustalo/-/blob/master/src/squid/stopwatch.h:

struct stopwatch_s {
  time_t t0; /* Wall clock time, ANSI time()  */
#ifdef SRE_STRICT_ANSI
  clock_t cpu0; /* CPU time, ANSI clock()*/
#else
  struct tms cpu0; /* CPU/system time, POSIX times()*/
#endif

  double elapsed; /* elapsed time, seconds */
  double user; /* CPU time, seconds */
  double sys; /* system time, seconds */
};

There are your doubles that are likely the problem.

And what do we have here at
https://salsa.debian.org/med-team/clustalo/-/blob/master/src/squid/stopwatch.c#L276
...

void
StopwatchPVMPack(Stopwatch_t *w)
{
  pvm_pkdouble(&(w->elapsed), 1, 1);
  pvm_pkdouble(&(w->user),1, 1);
  pvm_pkdouble(&(w->sys), 1, 1);
}
void
StopwatchPVMUnpack(Stopwatch_t *w)
{
  pvm_upkdouble(&(w->elapsed), 1, 1);
  pvm_upkdouble(&(w->user),1, 1);
  pvm_upkdouble(&(w->sys), 1, 1);
}

I can't track the trail any further. The source code is missing for
pvm_pkdouble and pvm_upkdouble. I would be very suspect of
pvm_pkdouble and pvm_upkdouble.

Jeff

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

[Jeffrey Walton]

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 debian/tests/biopython_testdata/f002 --guidetree-out 
> temp_test.dnd -o temp_test.aln --outfmt clustal --force
> make[1]: *** [debian/rules:25: override_dh_auto_test-arch] Bus error

You can sometimes locate a bus error at build time with -Wcast-align.
At runtime you can usually locate them with -fsanitize=undefined.

On x86 -Wcast-align usually triggers when casting to/from floats and
doubles. I don't know what triggers on MIPS, bit it may include
integers. You should look for all calls that perform casts to/from
void* and uint8_t* with a dereference. I.e.,

uint8_t y[8] = ...;
double x = *(double*)y;

If MIPS is sensitive to alignment (beyond x86 slop), then something
like this will get you into trouble, too:

uint8_t y[8] = ...;
unsigned long x = *(unsigned long*)y;

I don't know about MIPS, but... I've experienced the problem with
long's on SPARCv8. SPARCv8 needs 8-byte alignments because they have a
specialized 64-bit move instruction. Or SPARCv8 needs an extra
compile/link switch that disables the 64-bit move. The option is
-xmemalign, which tells the toolchain what alignments can be assumed.

Jeff

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

[Jeffrey Walton]

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 install Valgrind either.
> >
> > Well, I guess apt-get is permitted for sudo but not apt-file.  So I can
> > probably install valgrind inside the chroot environment.  I've never
> > worked with valgrind.  What am I supposed to do?
>
> Valgrind, in its default mode, checks for a variety of memory issues 
> (use-after-free, write out-of bounds, …). You don’t need any special 
> configure/build options, but you probably want to enable debug symbols 
> (`export CFLAGS=-g; export CXXFLAGS=-g`). Then you can prefix the test you’re 
> running with Valgrind: `valgrind ./src/clustalo -i 
> debian/tests/biopython_testdata/f002 …`.

One small issue... Valgrind recommends -O0 or -O1:


Compile your program with -g to include debugging information so that
Memcheck's error messages include exact line numbers. Using -O0 is
also a good idea, if you can tolerate the slowdown. With -O1 line
numbers in error messages can be inaccurate, although generally
speaking running Memcheck on code compiled at -O1 works fairly well,
and the speed improvement compared to running -O0 is quite
significant. Use of -O2 and above is not recommended as Memcheck
occasionally reports uninitialised-value errors which don't really
exist.


Also see the Valgrind Quick Start Guide, Section 2. Preparing Your
Programs, at http://valgrind.org/docs/manual/QuickStart.html.

Jeff

Bug#926748: cargo: Cargo is too old

[Jeffrey Walton]

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 through WebDriver.

Debian and Raspbian do not provide geckodriver so I have to build it from 
sources. That means I need Cargo and Rust.

Attempting to build geckodriver results in a lot of errors. Cf., 
https://github.com/rust-lang/cargo/issues/6836. According to the Cargo folks 
Debian's Cargo is too old.

Please consider providing a more modern Cargo.

In the system info below, Raspbian is fully patched. There is nothing to 
install or update.

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 9.8 (stretch)
Release:9.8
Codename:   stretch
Architecture: armv7l

Kernel: Linux 4.14.98-v7+ (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cargo depends on:
ii  binutils2.28-5
ii  gcc [c-compiler]4:6.3.0-4
ii  gcc-6 [c-compiler]  6.3.0-18+rpi1+deb9u1
ii  libc6   2.24-11+deb9u4
ii  libcurl3-gnutls 7.52.1-5+deb9u9
ii  libgcc1 1:6.3.0-18+rpi1+deb9u1
ii  libhttp-parser2.1   2.1-2
ii  libssh2-1   1.7.0-1
ii  libssl1.0.2 1.0.2r-1~deb9u1
ii  rustc   1.24.1+dfsg1-1~deb9u2+rpi1
ii  zlib1g  1:1.2.8.dfsg-5

cargo recommends no packages.

Versions of packages cargo suggests:
pn  cargo-doc  

-- no debconf information

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

[Jeffrey Walton]

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 non-free
deb-src http://security.debian.org/ stretch/updates main contrib non-free
deb http://http.debian.net/debian/ stretch-updates main contrib non-free
deb-src http://http.debian.net/debian/ stretch-updates main contrib non-free
deb http://tprd.asus.com:8000 stretch main contrib non-free
deb-src http://tprd.asus.com:8000 stretch main contrib non-free

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

[Jeffrey Walton]

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 GB SDcard. 
The board runs Debian 9.8.

I have a program that tries to use MySQL, but MySQL/MariaDB is mostly unusable 
on this board due to poor performance.

I installed the following packages (and recommends) and ran 
mysql_secure_installation. Everything else is a Debian default.

* mysql-server
* mysql-client
* mysql-utilities
* libmariadbd-dev

The test program/SQL below attempts to create two small tables and two users. 
It takes 13 seconds to complete. I've read about the changes Debian made to 
MySQL at 
https://mariadb.com/kb/en/library/moving-from-mysql-to-mariadb-in-debian-9/, 
but I don't know what is causing this problem. This is not my area of expertise.

The smae program and SQL runs fine on Fedora 29 and dev-boards. Performance is 
about where one expects, give or take.

The command to setup the test database is:

# Password set using mysql_secure_installation
$ time mysql -uroot -p < testdb.sql

real0m12.799s
user0m0.040s
sys 0m0.000s

The contents of testdb.sql are:

DROP DATABASE IF EXISTS testdb;
CREATE DATABASE IF NOT EXISTS testdb;
USE testdb;

#

CREATE TABLE IF NOT EXISTS name_number
(
`nn_id` INT PRIMARY KEY AUTO_INCREMENT,
`nn_name` VARCHAR(64) CHARACTER SET utf8,
`nn_number` VARCHAR(18) CHARACTER SET utf8
);

CREATE INDEX IF NOT EXISTS number_index ON name_number(nn_number);

#

CREATE TABLE IF NOT EXISTS whitelist
(
`list_id` INT PRIMARY KEY AUTO_INCREMENT,
`nn_id` INT NOT NULL,
`list_date` DATETIME,
FOREIGN KEY fk1_id (nn_id)
REFERENCES name_number(nn_id)
);

#

CREATE TABLE IF NOT EXISTS blacklist
(
`list_id` INT PRIMARY KEY AUTO_INCREMENT,
`nn_id` INT NOT NULL,
`list_date` DATETIME,
FOREIGN KEY fk2_id (nn_id)
REFERENCES name_number(nn_id)
);

#

CREATE USER IF NOT EXISTS 'testdb_admin'@'localhost' IDENTIFIED BY 
'';
CREATE USER IF NOT EXISTS 'testdb_admin'@'%' IDENTIFIED BY 
'';

CREATE USER IF NOT EXISTS 'testdb_user'@'localhost' IDENTIFIED BY 
'';
CREATE USER IF NOT EXISTS 'testdb_user'@'%' IDENTIFIED BY 
'';

GRANT ALL PRIVILEGES ON testdb.* TO 'testdb_admin'@'localhost';
GRANT ALL PRIVILEGES ON testdb.* TO 'testdb_admin'@'%';

GRANT SELECT,INSERT,UPDATE,DELETE ON testdb.* TO 'testdb_user'@'localhost';
GRANT SELECT,INSERT,UPDATE,DELETE ON testdb.* TO 'testdb_user'@'%';

-- System Information:
Debian Release: 9.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 4.4.132+ (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mariadb-client-core-10.1 depends on:
ii  libaio1 0.3.110-3
ii  libc6   2.24-11+deb9u4
ii  libncurses5 6.0+20161126-1+deb9u2
ii  libreadline55.2+dfsg-3+b1
ii  libstdc++6  6.3.0-18+deb9u1
ii  libtinfo5   6.0+20161126-1+deb9u2
ii  mariadb-common  10.1.37-0+deb9u1
ii  zlib1g  1:1.2.8.dfsg-5

mariadb-client-core-10.1 recommends no packages.

mariadb-client-core-10.1 suggests no packages.

-- no debconf information

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

[Jeffrey Walton]

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 that was fixed: 
https://bugs.kde.org/show_bug.cgi?id=362935
 
-- System Information:
Debian Release: 9.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 4.4.132+ (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages valgrind depends on:
ii  libc6  2.24-11+deb9u4
ii  libc6-dbg  2.24-11+deb9u4

Versions of packages valgrind recommends:
ii  gdb   7.12-6
pn  valgrind-dbg  

Versions of packages valgrind suggests:
pn  alleyoop  
pn  kcachegrind   
pn  valgrind-mpi  
pn  valkyrie  

-- no debconf information

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

[Jeffrey Walton]

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 /dev/hwrng device was not
online when rng-tools started. By adding a small delay and retry count
we could side-step udev rules to support rng-tools.

The Conflicts was needed because the Beagleboards were hanging on
shutdowns and reboots. It seems the Restart was restarting the service
during shutdown.

The unit file can be dropped in /etc/systemd/system without deleting
the old service. 'systemctl enable rng-tools.service' will actually
enable the unit file even though systemd reports something about the
old service file.

I have other ARM dev-boards without a RNG. I did not test rng-tools on
them because haveged runs on them.

Robert, you may want to grab this for the images you build for the
4.1.15-ti-rt-r40 kernel. It is an improvement over the old service
file. The old service actually fails to run but no one realized it.

Jeff


rng-tools.service
Description: Binary data

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

[Jeffrey Walton]

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 the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

if [ -e /usr/sbin/rngd ]; then
/usr/sbin/rngd -r /dev/hwrng -f
fi

exit 0

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

[Jeffrey Walton]

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 /dev/random is suffering depletion. After
draining /dev/random, it takes 646 seconds to read 10 bytes in
blocking mode.

The problem seems to be the wrapper script of systemd around the old
sysinit script. Or maybe the wrapper is OK but systemd is the problem.
I don't know what the problem is at the moment.

Manually running '/etc/init.d/rng-tools start' and things work as
expected. /dev/random has a bountiful stream of bits.

A related question where I tried to troubleshoot it is at
https://unix.stackexchange.com/q/475489/56041. Unfortunately, I don't
know enough about the system components and they way they are supposed
to interact.

This report may be related:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776597 .

This may be CVE worthy. It is effectively a security related DoS due
to a configuration problem.

At this point I think it would be wise to provide a proper systemd
service file for rng-tools.

I am happy to manually install and test an updated *.deb package for
rng-tools. Just point me to a download.

-

Some hardware information.

$ cat /proc/cpuinfo
processor   : 0
model name  : ARMv7 Processor rev 2 (v7l)
BogoMIPS: 996.14
Features: half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part: 0xc08
CPU revision: 2

Hardware: Generic AM33XX (Flattened Device Tree)
Revision: 
Serial  : 

-

$ apt-cache show rng-tools
Package: rng-tools
Version: 2-unofficial-mt.14-1
Installed-Size: 148
Maintainer: Henrique de Moraes Holschuh 
Architecture: armhf
Replaces: intel-rng-tools
Provides: intel-rng-tools
Depends: libc6 (>= 2.4), udev (>= 0.053) | makedev (>= 2.3.1-77)
Conflicts: intel-rng-tools
Description: Daemon to use a Hardware TRNG
Description-md5: 6da2aca3dd07b55b609d9cf3d5d7cd57
Tag: interface::daemon, network::server, role::program
Section: utils
Priority: optional
Filename: pool/main/r/rng-tools/rng-tools_2-unofficial-mt.14-1_armhf.deb
Size: 47364
MD5sum: eb9bde7feaec413754e4b1f255865c8d
SHA1: 4ab63f0ec0f84499decbfe916c248580f51ab560
SHA256: a017aa416bda627a20cf5fdcf51f2a46471b800225a3b3abb5c6774b3cd94c6e

-

$ apt-cache show systemd
Package: systemd
Version: 230-7~bpo8+2
Architecture: armhf
Maintainer: Debian systemd Maintainers

Installed-Size: 6490
Pre-Depends: libc6 (>= 2.8), libgcc1 (>= 1:4.4.0)
Depends: libacl1 (>= 2.2.51-8), libapparmor1 (>= 2.9.0-3+exp2),
libaudit1 (>= 1:2.2.1), libblkid1 (>= 2.19.1), libc6 (>= 2.17),
libcap2 (>= 1:2.10), libcryptsetup4 (>= 2:1.4.3), libgcrypt20 (>=
1.6.1), libgpg-error0 (>= 1.14), libidn11 (>=1.13), libkmod2 (>= 5~),
liblzma5 (>= 5.1.1alpha+20120614), libmount1 (>= 2.20.1), libpam0g (>=
0.99.7.1), libseccomp2 (>= 2.1.0), libselinux1 (>= 2.1.9), libsystemd0
(= 230-7~bpo8+2), util-linux (>= 2.25.2-6), mount (>= 2.25.2-6),
adduser, libcap2-bin
Recommends: libpam-systemd, dbus
Suggests: systemd-ui, systemd-container, policykit-1
Conflicts: klogd
Breaks: apparmor (<< 2.9.2-1), ifupdown (<< 0.8.5~), laptop-mode-tools
(<< 1.68~), lsb-base (<< 4.1+Debian4), lvm2 (<< 2.02.104-1),
systemd-shim (<< 8-2), udev(<< 228-5)
Replaces: udev (<< 228-5)
Multi-Arch: foreign
Homepage: http://www.freedesktop.org/wiki/Software/systemd
Priority: important
Section: admin
Filename: pool/main/s/systemd/systemd_230-7~bpo8+2_armhf.deb
Size: 2146126
SHA256: b8ad0cd78f01d14980fa728baa841a2a59d85c706e6a3843930a8d932d289d04
SHA1: cf280cd4a7564a50404b95c04967be9ba468
MD5sum: bb29e98702695017bc9241c6b81d600f
Description: system and service manager
 systemd is a system and service manager for Linux. It provides aggressive
 parallelization capabilities, uses socket and D-Bus activation for starting
 services, offers on-demand starting of daemons, keeps track of processes
 using Linux control groups, supports snapshotting and restoring of the system
 state, maintains mount and automount points and implements an elaborate
 transactional dependency-based service control logic.
 .
 systemd is compatible with SysV and LSB init scripts and can work as a
 drop-in replacement for sysvinit.
 .
 Installing the systemd package will not switch your init system unless you
 boot with init=/bin/systemd or install systemd-sysv in addition.
Description-md5: daa2c3e0044c2c2f5adc47475a3d6969

Package: systemd
Version: 215-17+deb8u7
Installed-Size: 7977
Maintainer: Debian systemd Maintainers

Architecture: armhf
Depends: libacl1 (>= 2.2.51-8), libaudit1 (>= 1:2.2.1), libblkid1 (>=
2.19.1), libcap2 (>= 1:2.10), libcryptsetup4 (>= 2:1.4.3), libkmod2
(>= 5~), libpam0g (>=0.99.7.1), 

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

[Jeffrey Walton]

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

[Jeffrey Walton]

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.

If the program is run outside the debugger everything is fine. If the
program is run inside the debugger without a breakpoint everything is
fine. However, if the program has a breakpoint added, it eventually
crashes due to a SIGILL.

We don't rule out a program bug on our part. However, stable code is
now producing the issue, too. In the past when I added the code and
debugged it, the issue did not surface.

A question was asked on Stack Overflow:
https://stackoverflow.com/q/45649778/608639. In the comments, this bug
report was discussed:
https://sourceware.org/bugzilla/show_bug.cgi?id=10833.

Start reading the 10833 bug around Comment 8. Comment 11 and Comment
12 are definitely what we are experiencing.

Comment 15 says its fixed after a 2.6 kernel, but I am experiencing it
under 3.4.113-bananian and 4.1.15-ti-rt-r40-beaglebone kernels.

Thanks in advance.

**

$ apt-cache show gdb
Package: gdb
Version: 7.7.1+dfsg-5
Installed-Size: 4374
Maintainer: Héctor Orón Martínez 
Architecture: armhf
Replaces: gdb
Depends: libc6 (>= 2.15), libexpat1 (>= 2.0.1), liblzma5 (>=
5.1.1alpha+20110809), libncurses5 (>= 5.5-5~), libpython2.7 (>= 2.7),
libreadline6 (>= 6.0), libtinfo5, zlib1g (>= 1:1.2.0)
Recommends: libc-dbg, gdbserver
Suggests: gdb-doc
Conflicts: gdb
Description-en: GNU Debugger
 GDB is a source-level debugger, capable of breaking programs at
 ...
Priority: optional
Filename: pool/main/g/gdb/gdb_7.7.1+dfsg-5_armhf.deb
Size: 2000128
MD5sum: 8d67f1b96b4482cf26411082298b71b2
SHA1: fecc657b9fcab4b455aafbd51b15ced9af98e8a8
SHA256: 9afd43d6b460c6865c1c9e55728314d63c352c55c208a2ae28b5682f933484b2

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

[Jeffrey Walton]

>> 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.
>
> that's not a gcc-7 issue. please make sure that the dependent libraries are 
> in sync.

My bad. I was under the impression Debian's package system handles dependencies.

Thanks.

On Thu, Mar 2, 2017 at 4:12 AM, Debian Bug Tracking System
<ow...@bugs.debian.org> wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the gcc-7 package:
>
> #856528: Unable to install GCC7 on Debian 8/i386 with Experimental enabled
>
> It has been closed by Matthias Klose <d...@debian.org>.
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Matthias Klose 
> <d...@debian.org> by
> replying to this email.
>
>
> --
> 856528: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856528
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
> -- 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 
> Experimental enabled
> On 02.03.2017 02:27, Jeffrey Walton wrote:
>> 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.
>
> that's not a gcc-7 issue. please make sure that the dependent libraries are 
> in sync.
>
> -- Forwarded message --
> From: Jeffrey Walton <noloa...@gmail.com>
> To: sub...@bugs.debian.org
> Cc:
> Bcc:
> Date: Wed, 1 Mar 2017 20:27:50 -0500
> Subject: 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 fully patched.
> The following sources are enabled. The last one, experimental, came
> from https://wiki.debian.org/DebianExperimental.
>
> deb http://ftp.us.debian.org/debian/ jessie main
> deb-src http://ftp.us.debian.org/debian/ jessie main
>
> deb http://security.debian.org/ jessie/updates main contrib
> deb-src http://security.debian.org/ jessie/updates main contrib
>
> deb http://ftp.us.debian.org/debian/ jessie-updates main contrib
> deb-src http://ftp.us.debian.org/debian/ jessie-updates main contrib
>
> deb http://httpredir.debian.org/debian experimental main
>
> =
>
> # apt-get -t experimental install gcc-7 g++-7
>
> Reading package lists...
> Building dependency tree...
> Reading state information...
> 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:
>  g++-7 : Depends: libstdc++-7-dev (= 7-20170226-1) but it is not going
> to be installed
>  Depends: libisl15 (>= 0.15) but it is not installable
>  Depends: libmpfr4 (>= 3.1.3) but 3.1.2-2 is to be installed
>  gcc-7 : Depends: cpp-7 (= 7-20170226-1) but it is not going to be installed
>  Depends: libcc1-0 (>= 7-20170226-1) but it is not going to be 
> installed
>  Depends: binutils (>= 2.27.90.20170221) but 2.25-5 is to be installed
>  Depends: libgcc-7-dev (= 7-20170226-1) but it is not going to
> be installed
>  Depends: libisl15 (>= 0.15) but it is not installable
>  Depends: libmpfr4 (>= 3.1.3) but 3.1.2-2 is to be installed
>  Depends: libstdc++6 (>= 5) but 4.9.2-10 is to be installed
> E: Unable to correct problems, you have held broken packages.
>
> =
>
> Here is GCC7's information from x86_64. It installed fine on x86_64.
> The problem appears to be i386.
>
> $ apt-cache show gcc-7
> Package: gcc-7
> Version: 7-20170226-1
> Installed-Size: 145900
> Maintainer: Debian GCC Maintainers <debian-...@lists.debian.org>
> Archit

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

[Jeffrey Walton]

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 fully patched.
The following sources are enabled. The last one, experimental, came
from https://wiki.debian.org/DebianExperimental.

deb http://ftp.us.debian.org/debian/ jessie main
deb-src http://ftp.us.debian.org/debian/ jessie main

deb http://security.debian.org/ jessie/updates main contrib
deb-src http://security.debian.org/ jessie/updates main contrib

deb http://ftp.us.debian.org/debian/ jessie-updates main contrib
deb-src http://ftp.us.debian.org/debian/ jessie-updates main contrib

deb http://httpredir.debian.org/debian experimental main

=

# apt-get -t experimental install gcc-7 g++-7

Reading package lists...
Building dependency tree...
Reading state information...
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:
 g++-7 : Depends: libstdc++-7-dev (= 7-20170226-1) but it is not going
to be installed
 Depends: libisl15 (>= 0.15) but it is not installable
 Depends: libmpfr4 (>= 3.1.3) but 3.1.2-2 is to be installed
 gcc-7 : Depends: cpp-7 (= 7-20170226-1) but it is not going to be installed
 Depends: libcc1-0 (>= 7-20170226-1) but it is not going to be installed
 Depends: binutils (>= 2.27.90.20170221) but 2.25-5 is to be installed
 Depends: libgcc-7-dev (= 7-20170226-1) but it is not going to
be installed
 Depends: libisl15 (>= 0.15) but it is not installable
 Depends: libmpfr4 (>= 3.1.3) but 3.1.2-2 is to be installed
 Depends: libstdc++6 (>= 5) but 4.9.2-10 is to be installed
E: Unable to correct problems, you have held broken packages.

=

Here is GCC7's information from x86_64. It installed fine on x86_64.
The problem appears to be i386.

$ apt-cache show gcc-7
Package: gcc-7
Version: 7-20170226-1
Installed-Size: 145900
Maintainer: Debian GCC Maintainers 
Architecture: amd64
Replaces: gccgo-7 (<< 7-20170226-1)
Provides: c-compiler
Depends: cpp-7 (= 7-20170226-1), gcc-7-base (= 7-20170226-1), libcc1-0
(>= 7-20170226-1), binutils (>= 2.27.90.20170221), libgcc-7-dev (=
7-20170226-1), libc6 (>= 2.14), libgcc1 (>= 1:3.0), libgmp10 (>=
2:5.0.1~), libisl15 (>= 0.15), libmpc3, libmpfr4 (>= 3.1.3),
libstdc++6 (>= 5), zlib1g (>= 1:1.1.4)
Recommends: libc6-dev (>= 2.13-5)
Suggests: gcc-7-multilib, gcc-7-doc (>= 7), gcc-7-locales (>= 7),
libgcc1-dbg (>= 1:7-20170226-1), libgomp1-dbg (>= 7-20170226-1),
libitm1-dbg (>= 7-20170226-1), libatomic1-dbg (>= 7-20170226-1),
libasan4-dbg (>= 7-20170226-1), liblsan0-dbg (>= 7-20170226-1),
libtsan0-dbg (>= 7-20170226-1), libubsan0-dbg (>= 7-20170226-1),
libcilkrts5-dbg (>= 7-20170226-1), libmpx2-dbg (>= 7-20170226-1),
libquadmath0-dbg (>= 7-20170226-1)
Description-en: GNU C compiler
 This is the GNU C compiler, a fairly portable optimizing compiler for C.
Description-md5: 394374e688b1afb3af5f419895d29698
Homepage: http://gcc.gnu.org/
Section: devel
Priority: optional
Filename: pool/main/g/gcc-7/gcc-7_7-20170226-1_amd64.deb
Size: 31564834
MD5sum: 137210eb781915b8331db7fc626d83fb
SHA256: 002326bacb91b6ad4844231608378da12080bdf2b904d095a1a6527a8c15e564

$ gcc-7 --version
gcc-7 (Debian 7-20170226-1) 7.0.1 20170226 (experimental) [trunk
revision 245744]
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

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

[Jeffrey Walton]

> 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 setting
swapiness to a low value.

Nearly every ARM gadget I had was suffering OOM kills on two C++
libraries that made heavy use of templates. The swapfile and
swappiness avoided most of the build problems I was encountering.

The SD Cards are dirt cheap, so I don't care if they wear them out 15%
faster than normal. Its an easier problem to solve than daily broken
compiles.

Jeff

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

[Jeffrey Walton]

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

[Jeffrey Walton]

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 bullshit on Message 65 at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826043#65. The
report should not have been closed.

Debian has a major engineering problem if it does not realize how
broken some of this stuff is. Its ridiculous to suffer the same
problems and errors for nearly two years. Its ridiculous to have bug
reports like 826043 with all the details but manage to avoid fixing a
problem.

See for yourself. Follow the directions at
http://ftp.ports.debian.org/debian-ports-cd/hurd-i386/current/YES_REALLY_README.txt.
Download today's image. Then try to update the VM.

It sure would be nice if someone stepped up, took ownership of these
ports, and fixed the god damn things so they "just worked".

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

[Jeffrey Walton]

Thank you very much Don't I feel like a freak'ing asshole

On Thu, Sep 8, 2016 at 6:42 AM, Debian Bug Tracking System
<ow...@bugs.debian.org> wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the qemu package:
>
> #837048: QEMU chroot broken
>
> It has been closed by Riku Voipio <riku.voi...@iki.fi>.
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Riku Voipio 
> <riku.voi...@iki.fi> by
> replying to this email.
>
>
> --
> 837048: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837048
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
> -- Forwarded message --
> 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 certain nearly all of Debian's chroots are broken. I think
>> the X32 chroot is the only one that actually works.
>
> ...
>
>> debian-8-x64-vm:~# chmod debian-armel
>> chmod: missing operand after ‘debian-armel’
>> Try 'chmod --help' for more information.
>>
>> debian-8-x64-vm:~# SHELL=sh chmod debian-armel
>> chmod: missing operand after ‘debian-armel’
>> Try 'chmod --help' for more information.
>
> Try using "chroot" instead of chmod if you intend
> to chroot.
>
> -- Forwarded message --
> From: Jeffrey Walton <noloa...@gmail.com>
> To: sub...@bugs.debian.org
> Cc:
> Date: Thu, 8 Sep 2016 05:19:44 -0400
> Subject: 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 to ensure our
> project works under Debian so Debian users do not experience troubles.
> Its mostly become a waste of our time to try to use them or submit
> bugs for them since nothing seems to get fixed.
>
> Perhaps Debian should try to automate some testing against its QEMU
> chroots so it discovers its breaks.
>
> $ cat debian-armel-chroot.txt
>
> # qemu-debootstrap --arch=armel --keyring
> /usr/share/keyrings/debian-archive-keyring.gpg \
>>   --variant=buildd --exclude=debfoster unstable debian-armel 
>> http://ftp.debian.org/debian
> I: Running command: debootstrap --arch armel --foreign --keyring
> /usr/share/keyrings/debian-archive-keyring.gpg --variant=buildd
> --exclude=debfoster unstable debian-armel http://ftp.debian.org/debian
> I: Retrieving Release
> I: Retrieving Release.gpg
> I: Checking Release signature
> I: Valid Release signature (key id 126C0D24BD8A2942CC7DF8AC7638D0442B90D010)
> I: Retrieving Packages
> ...
> I: Extracting mount...
> I: Extracting util-linux...
> I: Extracting liblzma5...
> I: Extracting zlib1g...
> I: Running command: chroot debian-armel /debootstrap/debootstrap 
> --second-stage
> I: Keyring file not available at
> /usr/share/keyrings/debian-archive-keyring.gpg; switching to https
> mirror https://mirrors.kernel.org/debian
> I: Installing core packages...
> I: Unpacking required packages...
> I: Unpacking libacl1:armel...
> I: Unpacking libattr1:armel...
> I: Unpacking libaudit-common...
> I: Unpacking libaudit1:armel...
> ...
> I: Configuring g++...
> I: Configuring build-essential...
> I: Configuring libc-bin...
> I: Base system installed successfully.
>
> debian-8-x64-vm:~# chmod debian-armel
> chmod: missing operand after ‘debian-armel’
> Try 'chmod --help' for more information.
>
> debian-8-x64-vm:~# SHELL=sh chmod debian-armel
> chmod: missing operand after ‘debian-armel’
> Try 'chmod --help' for more information.
>
> **
>
> $ lsb_release -a
> No LSB modules are available.
> Distributor ID:Debian
> Description:Debian GNU/Linux unstable (sid)
> Release:unstable
> Codename:sid
>
> $ uname -a
> Linux debian-8-x64-vm 4.7.0-1-amd64 #1 SMP Debian 4.7.2-1 (2016-08-28)
> x86_64 GNU/Linux
>

Bug#837048: QEMU chroot broken

[Jeffrey Walton]

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 to ensure our
project works under Debian so Debian users do not experience troubles.
Its mostly become a waste of our time to try to use them or submit
bugs for them since nothing seems to get fixed.

Perhaps Debian should try to automate some testing against its QEMU
chroots so it discovers its breaks.

$ cat debian-armel-chroot.txt

# qemu-debootstrap --arch=armel --keyring
/usr/share/keyrings/debian-archive-keyring.gpg \
>   --variant=buildd --exclude=debfoster unstable debian-armel 
> http://ftp.debian.org/debian
I: Running command: debootstrap --arch armel --foreign --keyring
/usr/share/keyrings/debian-archive-keyring.gpg --variant=buildd
--exclude=debfoster unstable debian-armel http://ftp.debian.org/debian
I: Retrieving Release
I: Retrieving Release.gpg
I: Checking Release signature
I: Valid Release signature (key id 126C0D24BD8A2942CC7DF8AC7638D0442B90D010)
I: Retrieving Packages
...
I: Extracting mount...
I: Extracting util-linux...
I: Extracting liblzma5...
I: Extracting zlib1g...
I: Running command: chroot debian-armel /debootstrap/debootstrap --second-stage
I: Keyring file not available at
/usr/share/keyrings/debian-archive-keyring.gpg; switching to https
mirror https://mirrors.kernel.org/debian
I: Installing core packages...
I: Unpacking required packages...
I: Unpacking libacl1:armel...
I: Unpacking libattr1:armel...
I: Unpacking libaudit-common...
I: Unpacking libaudit1:armel...
...
I: Configuring g++...
I: Configuring build-essential...
I: Configuring libc-bin...
I: Base system installed successfully.

debian-8-x64-vm:~# chmod debian-armel
chmod: missing operand after ‘debian-armel’
Try 'chmod --help' for more information.

debian-8-x64-vm:~# SHELL=sh chmod debian-armel
chmod: missing operand after ‘debian-armel’
Try 'chmod --help' for more information.

**

$ lsb_release -a
No LSB modules are available.
Distributor ID:Debian
Description:Debian GNU/Linux unstable (sid)
Release:unstable
Codename:sid

$ uname -a
Linux debian-8-x64-vm 4.7.0-1-amd64 #1 SMP Debian 4.7.2-1 (2016-08-28)
x86_64 GNU/Linux

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

[Jeffrey Walton]

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
http://ftp.ports.debian.org/debian-ports
I: Running command: debootstrap --arch m68k --foreign --keyring
/usr/share/keyrings/debian-ports-archive-keyring.gpg --no-check-gpg
--variant=buildd --exclude=debfoster unstable debian-m68k
http://ftp.ports.debian.org/debian-ports
I: Retrieving Release
I: Retrieving Packages
I: Validating Packages
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...

I: Extracting util-linux...
I: Extracting zlib1g...
I: Running command: chroot debian-m68k /debootstrap/debootstrap --second-stage
qemu: fatal: Illegal instruction: ebc0 @ f67c3712
D0 = 6ef5   A0 = f67dbf58   F0 =  (   0)
D1 = 010a   A1 =    F1 =  (   0)
D2 = 000f   A2 =    F2 =  (   0)
D3 =    A3 = f67be000   F3 =  (   0)
D4 =    A4 =    F4 =  (   0)
D5 =    A5 = f67dc000   F5 =  (   0)
D6 = f6fdf234   A6 = f6fdf484   F6 =  (   0)
D7 =    A7 = f6fdf230   F7 =  (   0)
PC = f67c3712   SR =  - FPRESULT =0
Aborted

**

# apt-cache show qemu
Package: qemu
Version: 1:2.1+dfsg-12+deb8u6
Installed-Size: 402
Maintainer: Debian QEMU Team 
Architecture: amd64
Depends: qemu-system (>= 1:2.1+dfsg-12+deb8u6), qemu-user (>=
1:2.1+dfsg-12+deb8u6), qemu-utils (>= 1:2.1+dfsg-12+deb8u6)
Suggests: qemu-user-static
Description-en: fast processor emulator
 QEMU is a fast processor emulator: currently the package supports
 ARM, CRIS, i386, M68k (ColdFire), MicroBlaze, MIPS, PowerPC, SH4,
 SPARC and x86-64 emulation. By using dynamic translation it achieves
 reasonable speed while being easy to port on new host CPUs. QEMU has
 two operating modes:
 .
  * User mode emulation: QEMU can launch Linux processes compiled for
one CPU on another CPU.
  * Full system emulation: QEMU emulates a full system, including a
processor and various peripherals. It enables easier testing and
debugging of system code. It can also be used to provide virtual
hosting of several virtual machines on a single server.
 .
 As QEMU requires no host kernel patches to run, it is very safe and
 easy to use.
 .
 This package is a metapackage depending on all qemu-related packages.
Description-md5: 976dc9e06bc50e9bc7637e1a34042953
Multi-Arch: foreign
Homepage: http://www.qemu.org/
Tag: admin::virtualization, hardware::emulation, role::metapackage
Section: otherosfs
Priority: optional
Filename: pool/main/q/qemu/qemu_2.1+dfsg-12+deb8u6_amd64.deb
Size: 122770
MD5sum: 1eacd4c2396b4a63ea37fda360da4978
SHA1: c546281b93c14ecc5dde8562e7363e7825997ac9
SHA256: d98d6c6ba9c98f0d5b5b2161281862eaa157198ba0df4c43ea9810bc1484a219

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

[Jeffrey Walton]

>>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 Release.gpg
>>I: Checking Release signature
>>I: Valid Release signature (key id 69DDB0560EA86E87E83599B3B4C86482705A2CE1)
>>E: Invalid Release file, no entry for main/binary-armel/Packages
>
> Why are you trying to use debian-ports for armel? armel is a standard
> Debian release architecture...

Primarily because its a port: https://www.debian.org/ports/ and
https://www.debian.org/ports/arm/ .

Other, lesser reasons include there's no documentation (follow the
links above), and using non-port procedures fails sooner than the
ports procedure:

I: Running command: debootstrap --arch armel --foreign --keyring
/usr/share/keyrings/debian-archive-keyring.gpg --variant=buildd
--exclude=debfoster unstable debian-armel http://ftp.debian.org/
I: Retrieving Release
E: Failed getting release file http://ftp.debian.org/dists/unstable/Release

I would be awesome if someone would clearly document the procedure.

Jeff

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

[Jeffrey Walton]

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 unstable debian-armel
http://ftp.ports.debian.org/debian-ports
I: Retrieving Release
I: Retrieving Release.gpg
I: Checking Release signature
I: Valid Release signature (key id 69DDB0560EA86E87E83599B3B4C86482705A2CE1)
E: Invalid Release file, no entry for main/binary-armel/Packages

sources.list from host computer:

deb http://ftp.us.debian.org/debian/ sid main contrib
# deb http://ftp.us.debian.org/debian/ sid/updates main contrib

# deb http://ftp.us.debian.org/debian/ sid-updates main
# deb http://security.debian.org/ sid/updates main

debootstrap from host computer:

Package: debootstrap
Version: 1.0.81
Installed-Size: 249
Maintainer: Debian Install System Team 
Architecture: all
Depends: wget
Recommends: gnupg, debian-archive-keyring
Description-en: Bootstrap a basic Debian system
 debootstrap is used to create a Debian base system from scratch,
 without requiring the availability of dpkg or apt. It does this by
 downloading .deb files from a mirror site, and carefully unpacking them
 into a directory which can eventually be chrooted into.
Description-md5: 883a8efb3ed16248b0d2091d9c0b60c9
Tag: admin::virtualization, devel::debian, implemented-in::shell,
 interface::commandline, protocol::http, role::program, scope::utility,
 suite::debian, works-with-format::tar, works-with::software:package
Section: admin
Priority: extra
Filename: pool/main/d/debootstrap/debootstrap_1.0.81_all.deb
Size: 65524
MD5sum: 1e445b445adb9316a62b2fc1981c10a4
SHA256: 688fbb3f414778437fe81f776dff15eaa797428f9dd99efe9cfa23eab7a38780

Bug#828052: Please update Ports wiki page

[Jeffrey Walton]

> 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 weeks ago without wasting roughly 40 or
60 man hours.

Jeff

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

[Jeffrey Walton]

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
Debian carries our package, and our package maintainer, László
Böszörményi, manages to find issues despite our sincerest efforts.



First issue: in a Sparc64 QEMU/Chroot guest, the lightweight VM fails
to start. The corresponding Debian bug report is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828041:

# chroot debian-sparc64
*** longjmp causes uninitialized stack frame ***: /bin/bash terminated
Unhandled trap: 0x34
pc: 00163860  npc: 00163864
%g0-3:  8004  
%g4-7: 0002 0008 476574434641 004000ee2700
...
%f48:     
%f56:  0001   
pstate: 0092 ccr: 44 (icc: -Z-- xcc: -Z--) asi: f0 tl: 0 pil: 0
cansave: 5 canrestore: 1 otherwin: 0 wstate: 0 cleanwin: 7 cwp: 2
fsr:  y:  fprs: 0004



Second issue: in a S/390x QEMU/Chroot guest, bash crashes when
attempting to run Emacs self tests (Emacs 24.5 built from sources):

# make
...

make[2]: Leaving directory '/root/emacs-24.5/lisp'
if test "no" = "yes"; then \
  rm -f bootstrap-emacs; \
  ln temacs bootstrap-emacs; \
else \
  ./temacs --batch --load loadup bootstrap || exit 1; \
  test "X" = X ||  -zex emacs; \
  mv -f emacs bootstrap-emacs; \
fi
Loading loadup.el (source)...
Using load-path (/root/emacs-24.5/lisp
/root/emacs-24.5/lisp/emacs-lisp /root/emacs-24.5/lisp/language
/root/emacs-24.5/lisp/international /root/emacs-24.5/lisp/textmodes
/root/emacs-24.5/lisp/vc)
Loading emacs-lisp/byte-run...
/bin/bash: line 7: 17256 Segmentation fault  ./temacs --batch
--load loadup bootstrap
Makefile:815: recipe for target 'bootstrap-emacs' failed
make[1]: *** [bootstrap-emacs] Error 1
make[1]: Leaving directory '/root/emacs-24.5/src'
Makefile:387: recipe for target 'src' failed
make: *** [src] Error 2



The following was taken from the S/390x machine:

# /bin/bash --version
GNU bash, version 4.3.46(1)-release (s390x-ibm-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.

# apt-cache show bash
Package: bash
Essential: yes
Status: install ok installed
Priority: required
Section: shells
Installed-Size: 5283
Maintainer: Matthias Klose 
Architecture: s390x
Multi-Arch: foreign
Version: 4.3-15
Replaces: bash-completion (<< 20060301-0), bash-doc (<= 2.05-1)
Depends: base-files (>= 2.1.12), debianutils (>= 2.15)
Pre-Depends: dash (>= 0.5.5.1-2.2), libc6 (>= 2.15), libncurses5 (>=
6), libtinfo5 (>= 6)
Recommends: bash-completion (>= 20060301-0)
Suggests: bash-doc
Conflicts: bash-completion (<< 20060301-0)
Conffiles:
 /etc/bash.bashrc 87b895cef45b8090d628a1d9a0f4bfb8
 /etc/skel/.bash_logout 22bfb8c1dd94b5f3813a2b25da67463f
 /etc/skel/.bashrc ee35a240758f374832e809ae0ea4883a
 /etc/skel/.profile 905f748ceda81747600e9a593b42f3e4
Description-en: GNU Bourne Again SHell
 Bash is an sh-compatible command language interpreter that executes
 commands read from the standard input or from a file.  Bash also
 incorporates useful features from the Korn and C shells (ksh and csh).
 .
 Bash is ultimately intended to be a conformant implementation of the
 IEEE POSIX Shell and Tools specification (IEEE Working Group 1003.2).
 .
 The Programmable Completion Code, by Ian Macdonald, is now found in
 the bash-completion package.
Description-md5: 3522aa7b4374048d6450e348a5bb45d9
Homepage: http://tiswww.case.edu/php/chet/bash/bashtop.html
Package: bash
Source: bash (4.3-14)
Version: 4.3-14+b1
Essential: yes
Installed-Size: 5280
Maintainer: Matthias Klose 
Architecture: s390x
Replaces: bash-completion (<< 20060301-0), bash-doc (<= 2.05-1)
Depends: base-files (>= 2.1.12), debianutils (>= 2.15)
Pre-Depends: dash (>= 0.5.5.1-2.2), libc6 (>= 2.15), libncurses5 (>=
6), libtinfo5 (>= 6)
Recommends: bash-completion (>= 20060301-0)
Suggests: bash-doc
Conflicts: bash-completion (<< 20060301-0)
Description-en: GNU Bourne Again SHell
 Bash is an sh-compatible command language interpreter that executes
 commands read from the standard input or from a file.  Bash also
 incorporates useful features from the Korn and C shells (ksh and csh).
 .
 Bash is ultimately intended to be a conformant implementation of the
 IEEE POSIX Shell and Tools specification (IEEE Working Group 1003.2).
 .
 The Programmable Completion Code, by Ian Macdonald, is now found in
 the bash-completion package.
Description-md5: 3522aa7b4374048d6450e348a5bb45d9
Multi-Arch: foreign
Homepage: 

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

[Jeffrey Walton]

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 --without-x --without-sound --without-xpm \
  --without-jpeg --without-tiff --without-gif --without-png --without-rsvg \
  --without-imagemagick --without-xft --without-libotf --without-m17n-flt \
  --without-xaw3d --without-toolkit-scroll-bars --without-gpm --without-dbus \
  --without-gconf --without-gsettings

-

# apt-get install emacs-nox
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  dbus emacs24-bin-common emacs24-common emacs24-el emacs24-nox emacsen-common
  libasound2 libasound2-data libcap-ng0 libdbus-1-3 libglib2.0-0
  libglib2.0-data libgpm2 liblockfile-bin liblockfile1 libxml2 sgml-base
  shared-mime-info xdg-user-dirs xml-core
Suggested packages:
  dbus-user-session | dbus-x11 emacs24-common-non-dfsg ncurses-term
  libasound2-plugins alsa-utils gpm sgml-base-doc debhelper
The following NEW packages will be installed:
  dbus emacs-nox emacs24-bin-common emacs24-common emacs24-el emacs24-nox
  emacsen-common libasound2 libasound2-data libcap-ng0 libdbus-1-3
  libglib2.0-0 libglib2.0-data libgpm2 liblockfile-bin liblockfile1 libxml2
  sgml-base shared-mime-info xdg-user-dirs xml-core
0 upgraded, 21 newly installed, 0 to remove and 0 not upgraded.
Need to get 39.6 MB of archives.
After this operation, 125 MB of additional disk space will be used.
Do you want to continue? [Y/n]

-

# apt-cache show emacs24-nox
Package: emacs24-nox
Source: emacs24 (24.5+1-6)
Version: 24.5+1-6+b2
Installed-Size: 16384
Maintainer: Rob Browning 
Architecture: s390x
Replaces: emacs24, emacs24-lucid
Provides: editor, emacs24, emacsen, info-browser, mail-reader, news-reader
Depends: emacs24-bin-common (= 24.5+1-6+b2), libacl1 (>= 2.2.51-8),
libasound2 (>= 1.0.16), libc6 (>= 2.16), libdbus-1-3 (>= 1.9.14),
libglib2.0-0 (>= 2.18.0), libgnutls30 (>= 3.4.2), libgpm2 (>= 1.20.4),
libselinux1 (>= 1.32), libtinfo5 (>= 6), libxml2 (>= 2.7.4), zlib1g
(>= 1:1.1.4)
Suggests: emacs24-common-non-dfsg
Conflicts: emacs24, emacs24-lucid
Description-en: GNU Emacs editor (without GUI support)
 GNU Emacs is the extensible self-documenting text editor.  This
 package contains a version of Emacs compiled without support for X,
 and provides only a text terminal interface.
Description-md5: d7627aff9867f2ba95f2b9dcfc399d6a
Homepage: http://www.gnu.org/software/emacs/
Section: editors
Priority: optional
Filename: pool/main/e/emacs24/emacs24-nox_24.5+1-6+b2_s390x.deb
Size: 3099814
MD5sum: a71d7536020950e53d01c780527f0b3e
SHA1: 69d6880851b4c6624d2930217336a5b971ba874e
SHA256: a0d5da36853bec5e455f702cc8d44d603e4b396f55ff9c4e03656fa03d50c4f8

-

# apt-cache show emacs-nox
Package: emacs-nox
Source: emacs-defaults
Version: 46.1
Installed-Size: 25
Maintainer: Rob Browning 
Architecture: all
Depends: emacs24-nox
Description-en: GNU Emacs editor (metapackage, without X support)
 GNU Emacs is the extensible self-documenting text editor.
 This is a metapackage that will always depend on the latest
 recommended Emacs release, without support for X.
Description-md5: 948b6cf34c11bb622035c56f70f707e2
Section: editors
Priority: optional
Filename: pool/main/e/emacs-defaults/emacs-nox_46.1_all.deb
Size: 1652
MD5sum: 6373e38178b404a66b30cb3efb9ee6b8
SHA1: d938c9bcdb3332a54cfbf7acc4981a209680ca4f
SHA256: 80e14e492f704c5c24e9e80b4624dc472b9864edc6cc1b202a12ec2ff5613176

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

[Jeffrey Walton]

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
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
2 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y

E: Can not write log (Is /dev/pts mounted?) - posix_openpt (2: No such
file or directory)
Setting up emacs24-nox (24.4+1-5) ...
Install emacsen-common for emacs24
emacsen-common: Handling install of emacsen flavor emacs24
Unsupported socketcall: 20
Symbol's value as variable is void: boundp
ERROR: install script from emacsen-common package failed
dpkg: error processing package emacs24-nox (--configure):
 subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of emacs-nox:
 emacs-nox depends on emacs24-nox; however:
  Package emacs24-nox is not configured yet.
dpkg: error processing package emacs-nox (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 emacs24-nox
 emacs-nox
E: Sub-process /usr/bin/dpkg returned an error code (1)

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

[Jeffrey Walton]

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:  8004  
%g4-7: 0002 0008 476574434641 004000ee2700
%o0-3: 0004 0040007fde59 0040007fde59 002f09a8
%o4-7: 0003 002ef400 0040007fdd99 0040007fdf01
%l0-3: 005b 002fced8 0010 
%l4-7: 002fced8 0001 005d 004000edc000
%i0-3: 004000d778a0 0040007ff568  0004
%i4-7: 004000ee08c8 004000ee08b0 0040007fecb1 004000d77b00
%f00:     
%f08:     
%f16:  0003   
%f24:    0001 
%f32:     
%f40:     
%f48:     
%f56:  0001   
pstate: 0092 ccr: 44 (icc: -Z-- xcc: -Z--) asi: f0 tl: 0 pil: 0
cansave: 5 canrestore: 1 otherwin: 0 wstate: 0 cleanwin: 7 cwp: 2
fsr:  y:  fprs: 0004

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

[Jeffrey Walton]

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 stack frame ***: /bin/bash terminate
Unhandled trap: 0x34
pc: 00163860 ...
...

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

[Jeffrey Walton]

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
/usr/share/keyrings/debian-ports-archive-keyring.gpg \
  --variant=buildd --exclude=debfoster unstable debian-sparc
http://ftp.ports.debian.org/debian-ports

The command results in:

I: Running command: debootstrap --arch sparc --foreign --keyring
/usr/share/keyrings/debian-ports-archive-keyring.gpg --variant=buildd
--exclude=debfoster unstable debian-sparc
http://ftp.ports.debian.org/debian-ports
I: Retrieving Release
I: Retrieving Release.gpg
I: Checking Release signature
I: Valid Release signature (key id 69DDB0560EA86E87E83599B3B4C86482705A2CE1)
E: Invalid Release file, no entry for main/binary-sparc/Packages

According to the Debian Ports page at https://www.debian.org/ports/,
Sparc is an official and supported.

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

[Jeffrey Walton]

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.
>
>> I: Running command: debootstrap --arch sparc --foreign --keyring
>> /usr/share/keyrings/debian-ports-archive-keyring.gpg --variant=buildd
>> --exclude=debfoster unstable debian-sparc
>> http://ftp.ports.debian.org/debian-ports
>> I: Retrieving Release
>> I: Retrieving Release.gpg
>> I: Checking Release signature
>> I: Valid Release signature (key id 69DDB0560EA86E87E83599B3B4C86482705A2CE1)
>> E: Invalid Release file, no entry for main/binary-sparc/Packages
>
> Maybe this is debootstrap bug? :)

Thanks.

How do I transfer it to debootstrap? Debian still uses a 1980's bug
tracker, and I don't have the experience an knowledge needed to
operate it as an occasional reporter.

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

[Jeffrey Walton]

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
/usr/share/keyrings/debian-ports-archive-keyring.gpg \
  --variant=buildd --exclude=debfoster unstable debian-sparc
http://ftp.ports.debian.org/debian-ports

The command results in:

I: Running command: debootstrap --arch sparc --foreign --keyring
/usr/share/keyrings/debian-ports-archive-keyring.gpg --variant=buildd
--exclude=debfoster unstable debian-sparc
http://ftp.ports.debian.org/debian-ports
I: Retrieving Release
I: Retrieving Release.gpg
I: Checking Release signature
I: Valid Release signature (key id 69DDB0560EA86E87E83599B3B4C86482705A2CE1)
E: Invalid Release file, no entry for main/binary-sparc/Packages

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

[Jeffrey Walton]

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
/usr/share/keyrings/debian-ports-archive-keyring.gpg \
  --variant=buildd --exclude=debfoster unstable debian-sparc64
http://ftp.ports.debian.org/debian-ports/

When I attempt to enter the QEMU guest environment:

# chroot debian-sparc64
pc: 00163860  npc: 00163864
%g0-3:  8004  
%g4-7: 0002 0008 476574434641 004000ee2700
%o0-3: 0004 0040007fe839 0040007fe839 002f09a8
%o4-7: 0003 002ef400 0040007fe779 0040007fe8e1
%l0-3: 005b 002fc268 0010 
%l4-7: 002fc268 0001 005d 004000edc000
%i0-3: 004000d778a0 0040007fff48  0004
%i4-7: 004000ee08c8 004000ee08b0 0040007ff691 004000d77b00
%f00:     
%f08:     
%f16:  0003   
%f24:    0001 
%f32:     
%f40:     
%f48:     
%f56:  0001   
pstate: 0092 ccr: 44 (icc: -Z-- xcc: -Z--) asi: f0 tl: 0 pil: 0
cansave: 5 canrestore: 1 otherwin: 0 wstate: 0 cleanwin: 7 cwp: 2
fsr:  y:  fprs: 0004

Unhandled trap: 0x34

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

[Jeffrey Walton]

Package: gdb
Version: 7-10.1
Severity: important
X-Debbugs-CC: zu...@debian.org, g...@debian.org

Nine months later, and its still broken. Even better, GDB 7.11 fails
to build from sources on X32.

It sure would be nice if the upstream patch was applied before the end
of the year.


On Sun, Sep 20, 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
> Installed-Size: 6419
> Maintainer: Héctor Orón Martínez <zu...@debian.org>
> Architecture: x32
> Version: 7.10-1
> Replaces: gdb
> Depends: libc6 (>= 2.16), libexpat1 (>= 2.0.1), liblzma5 (>=
> 5.1.1alpha+20110809), libncurses5 (>= 6), libpython3.4 (>= 3.4.2),
> libreadline6 (>= 6.0), libtinfo5 (>= 6), zlib1g (>= 1:1.2.0)
> Recommends: libc-dbg, gdbserver
> Suggests: gdb-doc
> Conflicts: gdb
> Filename: pool-x32/main/g/gdb/gdb_7.10-1_x32.deb
> Size: 2398182
> MD5Sum: 53d794fd2bfb5b4b1cfc88c2601d0063
> SHA1: d6063dadcd8548b735c82734fe354b425d7c3781
> SHA256: 643e29f266a396d39d6ef91d0f72a6eeb7f3478577274ce22d10403fd702bdc7
> SHA512: 
> ab8429c16c7f7c8824306b8e55dfc2f674ff2071213210ee41e316e50497ba8efe7425d5c1bad7a3c53255d0c01a9bbbf95c415b7dd6917c70682ea53ae3097b
> Description: GNU Debugger
>  GDB is a source-level debugger, capable of breaking programs at
>  any specific line, displaying variable values, and determining
>  where errors occurred. Currently, gdb supports C, C++, D,
>  Objective-C, Fortran, Java, OpenCL C, Pascal, assembly, Modula-2,
>  Go, and Ada. A must-have for any serious programmer.
> Description-md5: 4f2b8eb95df2ba7a5b11e0301c48b8e4
> Homepage: http://www.gnu.org/s/gdb/

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

[Jeffrey Walton]

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 predefined
(see 6.5.4), but in order to access NEON intrinsics it is necessary to
include the  header.

Jeff

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

[Jeffrey Walton]

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 to be missing arm and neon instrinsics provided by arm_neon.h:

  $ find /usr/include -name 'arm_neon.h'
  $

In fact, grepping for the basic intrinsics like CRC32 returns no hits.
For example, according to Section 9.2. of
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053c/IHI0053C_acle_2_0.pdf,
there should be a __crc32ch, __crc32cw and a __crc32cd available
somewhere.

-

It looks like GCC took a bug report on it around the GCC 4.3 days
circa 2009; see "arm_neon.h missing from ARM gcc in jaunty"
(https://bugs.launchpad.net/ubuntu/+source/gcc-4.3/+bug/360819).

A down stream/Linaro bug report is available at
https://bugs.linaro.org/show_bug.cgi?id=2231.

-

$ gcc --version
gcc (Debian/Linaro 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

-

$ uname -a
Linux hikey 3.18.0-linaro-hikey #1 SMP PREEMPT Mon Nov 30 00:11:03 UTC
2015 aarch64 GNU/Linux

-

$ apt-cache show gcc-4.9
Package: gcc-4.9
Version: 4.9.2-10
Installed-Size: 13703
Maintainer: Debian GCC Maintainers 
Architecture: arm64
Replaces: gccgo-4.9 (<< 4.9.2-10)
Provides: c-compiler
Depends: cpp-4.9 (= 4.9.2-10), gcc-4.9-base (= 4.9.2-10), binutils (>=
2.25), libgcc-4.9-dev (= 4.9.2-10), libc6 (>= 2.17), libcloog-isl4 (>=
0.17), libgmp10 (>= 2:5.0.1~), libisl10 (>= 0.10), libmpc3, libmpfr4
(>= 3.1.2), zlib1g (>= 1:1.1.4)
Recommends: libc6-dev (>= 2.13-5)
Suggests: gcc-4.9-doc (>= 4.9), gcc-4.9-locales (>= 4.9), libgcc1-dbg
(>= 1:4.9.2-10), libgomp1-dbg (>= 4.9.2-10), libitm1-dbg (>=
4.9.2-10), libatomic1-dbg (>= 4.9.2-10), libasan1-dbg (>= 4.9.2-10),
liblsan0-dbg (>= 4.9.2-10), libtsan0-dbg (>= 4.9.2-10), libubsan0-dbg
(>= 4.9.2-10), libcilkrts5-dbg (>= 4.9.2-10), libquadmath-dbg (>=
4.9.2-10)
Description-en: GNU C compiler
 This is the GNU C compiler, a fairly portable optimizing compiler for C.
Description-md5: 394374e688b1afb3af5f419895d29698
Homepage: http://gcc.gnu.org/
Section: devel
Priority: optional
Filename: pool/main/g/gcc-4.9/gcc-4.9_4.9.2-10_arm64.deb
Size: 4148946
MD5sum: d14d2ab1869bf1bf7e33b75b30953f22
SHA1: a1cd98d5af9b3259414cf01f9a4b8494c0a23b4a
SHA256: f3c18034483a4e6289b233dcb97547c2ab73862c40b30d03da81cb226fdb8d79

-

$ cat /proc/cpuinfo
Processor: AArch64 Processor rev 3 (aarch64)
processor: 0
processor: 1
processor: 2
processor: 3
processor: 4
processor: 5
processor: 6
processor: 7
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer: 0x41
CPU architecture: AArch64
CPU variant: 0x0
CPU part: 0xd03
CPU revision: 3

Hardware: HiKey Development Board

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

[Jeffrey Walton]

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

--

debian-s390:~# apt-get install git
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:
 git : Depends: libcurl3-gnutls (>= 7.16.2) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

--

# apt-get install libcurl-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package libcurl-dev is a virtual package provided by:
  libcurl4-openssl-dev 7.38.0-4+deb8u3
  libcurl4-nss-dev 7.38.0-4+deb8u3
  libcurl4-gnutls-dev 7.38.0-4+deb8u3
You should explicitly select one to install.

E: Package 'libcurl-dev' has no installation candidate

--

# cat /etc/apt/sources.list
deb ftp://ftp.us.debian.org/debian jessie main contrib
deb http://httpredir.debian.org/debian jessie-updates main contrib

--

# apt-cache show git
Package: git
Version: 1:2.1.4-2.1+deb8u2
Installed-Size: 23910
Maintainer: Gerrit Pape 
Architecture: s390x
Replaces: git-core (<< 1:1.7.0.4-1.), gitweb (<< 1:1.7.4~rc1)
Provides: git-completion, git-core
Depends: libc6 (>= 2.16), libcurl3-gnutls (>= 7.16.2), libexpat1 (>=
2.0.1), libpcre3 (>= 1:8.35), zlib1g (>= 1:1.2.0), perl-modules,
liberror-perl, git-man (>> 1:2.1.4), git-man (<< 1:2.1.4-.)
Recommends: patch, less, rsync, ssh-client
Suggests: gettext-base, git-daemon-run | git-daemon-sysvinit, git-doc,
git-el, git-email, git-gui, gitk, gitweb, git-arch, git-cvs,
git-mediawiki, git-svn
Breaks: bash-completion (<< 1:1.90-1), cogito (<= 0.18.2+),
git-buildpackage (<< 0.6.5), git-core (<< 1:1.7.0.4-1.), gitosis (<<
0.2+20090917-7), gitpkg (<< 0.15), gitweb (<< 1:1.7.4~rc1), guilt (<<
0.33), stgit (<< 0.15), stgit-contrib (<< 0.15)
Description-en: fast, scalable, distributed revision control system
 Git is popular version control system designed to handle very large
 projects with speed and efficiency; it is used for many high profile
 open source projects, most notably the Linux kernel.
 .
 Git falls in the category of distributed source code management tools.
 Every Git working directory is a full-fledged repository with full
 revision tracking capabilities, not dependent on network access or a
 central server.
 .
 This package provides the git main components with minimal dependencies.
 Additional functionality, e.g. a graphical user interface and revision
 tree visualizer, tools for interoperating with other VCS's, or a web
 interface, is provided as separate git* packages.
Description-md5: c1f968556452a190fe359bffd151c012
Multi-Arch: foreign
Homepage: http://git-scm.com/
Tag: devel::rcs, implemented-in::c, implemented-in::perl,
 implemented-in::shell, interface::text-mode, network::client,
 network::server, protocol::ssh, protocol::tcp, role::program,
 works-with::file, works-with::software:source, works-with::vcs
Section: vcs
Priority: optional
Filename: pool/main/g/git/git_2.1.4-2.1+deb8u2_s390x.deb
Size: 3104486
MD5sum: 5460c84b88b8423168b57ef3478727a9
SHA1: 8eaba9a503b54015c86252979789b76b7a6cd871
SHA256: cd5cbc908b82229776a8a9440adeac0a4b4c78e77fde1567905a0eedf92180eb

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

[Jeffrey Walton]

On Wed, Mar 23, 2016 at 3:18 PM, Simon McVittie <s...@debian.org> wrote:
> [Removing debian-devel from Cc]
>
> 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 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 not warn him about the problems, so the
>> >>report trickled downhill to us.
>
> it isn't clear to me whether that would have helped: dpkg-buildflags
> only affects the warnings emitted when Debian packages are built, whereas
> a change in gcc would also affect the warnings emitted when upstream
> software is built on Debian.
> ...

Maybe fast uptake of the patches discussed here would be most helpful:
http://llvm.org/bugs/show_bug.cgi?id=23529#c61.

Jeff

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

[Jeffrey Walton]

>> - 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 events, and that's what is making it
> tricky to nail down.
>
> -Wabi-tag is somewhat of a mystery at the moment. Though introduced in
> GCC 5.1, its still not documented at 5.3 (cf.,
> http://gcc.gnu.org/onlinedocs/gcc-5.3.0/gcc/Warning-Options.html#Warning-Options).
> According to 
> http://allanmcrae.com/2015/06/the-case-of-gcc-5-1-and-the-two-c-abis/,
> its intended to catch the mixing and matching that's causing the pain.

I can't really offer anything useful at the moment because I don't
have a clear understanding of what's going on. Sorry about that.

Here are the three references I am aware. The Red Hat one made my radar tonight:

 * "GCC5 and the C++11 ABI",
http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/
 * "Dual ABIs",
http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
 * "The Case of GCC-5.1 and the Two C++ ABIs",
http://allanmcrae.com/2015/06/the-case-of-gcc-5-1-and-the-two-c-abis/

I'm also aware that GCC appears to lack documentation on -Wabi-tag
(cf., 
http://gcc.gnu.org/onlinedocs/gcc-5.1.0/gcc/Warning-Options.html#Warning-Options.).

I *thought* -Wabi-tag could be used to detect the differences between
ABIs when compiling and linking. That would, in turn alert the user,
but I'm not sure that was correct. For example, the following warns of
an ABI problem even though C++03 does not have this problem:

  $ cat test.cxx
  #include 

  std::string foo __attribute__ ((visibility ("default")));
  std::string bar __attribute__ ((visibility ("default")));

And:

$ g++ -g3 -O2 -Wabi-tag -std=c++03 -shared test.cxx -o test.so
test.cxx:3:13: warning: ‘foo’ inherits the "cxx11" ABI tag that
‘std::__cxx11::string {aka std::__cxx11::basic_string}’ (used in
its type) has [-Wabi-tag]
 std::string foo __attribute__ ((visibility ("default")));
 ^
In file included from /usr/include/c++/5/string:52:0,
 from test.cxx:1:
/usr/include/c++/5/bits/basic_string.h:71:11: note:
‘std::__cxx11::string {aka std::__cxx11::basic_string}’ declared
here
 class basic_string
   ^
test.cxx:4:13: warning: ‘bar’ inherits the "cxx11" ABI tag that
‘std::__cxx11::string {aka std::__cxx11::basic_string}’ (used in
its type) has [-Wabi-tag]
 std::string bar __attribute__ ((visibility ("default")));
 ^
In file included from /usr/include/c++/5/string:52:0,
 from test.cxx:1:
/usr/include/c++/5/bits/basic_string.h:71:11: note:
‘std::__cxx11::string {aka std::__cxx11::basic_string}’ declared
here
 class basic_string
   ^

Then, I thought I could side step the problem by building a library
with both old and new symbols that coexist as discussed in the Red Hat
blog. But I can't seem to get a definitive answer on what it means to
coexist, and how to do it.

I asked a couple of questions on the GCC Help mailing list. They may
help you more than they helped me:

 * "Why does -Wabi-tag complain when -std=c++03?",
https://gcc.gnu.org/ml/gcc-help/2016-03/msg00123.html
 * "How to provide coexisting std::string's (with and without
abi:cxx11) in GCC 5.1 and above?",
https://gcc.gnu.org/ml/gcc-help/2016-03/msg00118.html

"What a fine mess we're in" comes to mind right about now...

Sorry again about not being able to help.

Jeff

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

[Jeffrey Walton]

> 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 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 not warn him about the problems, so the
>> >>report trickled downhill to us.
>
> it isn't clear to me whether that would have helped: dpkg-buildflags
> only affects the warnings emitted when Debian packages are built, whereas
> a change in gcc would also affect the warnings emitted when upstream
> software is built on Debian.

When Debian builds its packages, I don't believe it {was|is} an issue.

The problem is a confluence, and there's no single point of failure
per se. It appears when a user builds their userland programs using
Debian libraries *and* the user's compiler and/or options are
different than when Debian built the library.

> Jeffrey: who is "us",

"We" is the Crypto++ project (https://www.cryptopp.com/). Crypto++ is
a C++ class library of cryptographic schemes and algorithms created by
a fellow named Wei Dai.

> and does the problematic link step involve libraries
> from Debian packages, libraries you have previously compiled yourself, or
> both?

Yes (but its not a hard yes).

We (Crypto++) do not maintain Debian's Crypto++ library. We are
fortunate that László Böszörményi maintains it for us since it
relieves us from the task. We are also fortunate that László is a
friend of the project, and he works closely with us to ensure the
library is trouble free when integrating with the Debian ecosystem. A
number of bug fixes are credited to him. He also mentors us in Debian
ways to ensure a trouble free experience for both maintainers and
user. (Sorry about the shameless plug for László).

We believe the issue would surface regardless of who is building the
library under Debian when different compilers and or options are used
by the user. László could build it, we could build it, or the user
could build it from sources.

The problem should not be limited to Crypto++. I believe PCRE has a
C++ component, and it should experience the problem too *if* the user
selects a different compiler and/or options. You should be able to
 and duplicate the issue the user selects
a different compiler and/or options.

> During which compilation/linking step would you have expected to see
> this warning?

Here are the cases I would expect to see the warning. Below, "library"
means the Crypto++ library; and "program" means the program build by
the user linking to the library. "By Debian" implies the GCC compiler
with _GLIBCXX_USE_CXX11_ABI because that's the "out of the box"
configuration.

 (1) library supplied by Debian, program built by user using different
options (say -std=c++03)
 (2) library supplied by Debian, program built by user using different
compiler (say Clang)
 (3) library built by user using GCC with Debian settings, program
built by user using different options (say -std=c++03)
 (4) library built by user using GCC with Debian settings, program
built by user using different compiler (say Clang)
 (5) library built by user using Clang, program built by user using
Debian's GCC with _GLIBCXX_USE_CXX11_ABI

For completeness, here's what works as excepted. It avoids the
"different compiler and/or options" that's causing the pain point at
link time:

 (6) library supplied by Debian, program built by user using GCC with
Debian settings

> - 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 events, and that's what is making it
tricky to nail down.

-Wabi-tag is somewhat of a mystery at the moment. Though introduced in
GCC 5.1, its still not documented at 5.3 (cf.,
http://gcc.gnu.org/onlinedocs/gcc-5.3.0/gcc/Warning-Options.html#Warning-Options).
According to 
http://allanmcrae.com/2015/06/the-case-of-gcc-5-1-and-the-two-c-abis/,
its intended to catch the mixing and matching that's causing the pain.

Jeff

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

[Jeffrey Walton]

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):
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797917
> https://llvm.org/bugs/show_bug.cgi?id=23529

Yes, correct.

That's why we are asking that -Wabi-tag be enabled for GCC and Clang,
similar to the way other options are pushed/enabled, like
_FORTIFY_SOURCES (unless the user specifies -Wno-abi-tag).

In our case, we are a library (Crypto++, https://www.cryptopp.com/),
and we don't control how the library is compiled by a distro or how
users compile their programs. A distro compiling the library is always
OK; its the user and their choices that are creating the issues. The
-Wabi-tag warning will serve to alert the user they've wandered into a
problem area based on their choices.

Jeff

Bug#715505: Updated OpenChrome driver available

[Jeffrey Walton]

Hi Everyone,

I tested the updated OpenChrome driver tonight. The driver fixes the
crash I was experiencing under the existing driver.

I would strongly encourage Debian's Xorg team to get this driver into
Unstable or Testing as soon as possible.

Test results:

  * https://bugs.freedesktop.org/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

[Jeffrey Walton]

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

[Jeffrey Walton]

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 provided in xserver-xorg-video-openchrome. An
updated version of the OpenChrome driver is available from the
freedesktop.org folks, but it is not available in Unstable. The driver
is installed at /usr/lib/xorg/modules/drivers/openchrome_drv.so.

For the freedesktop.org announcement and instruction for obtaining the
updated driver, see "Getting ready to release OpenChrome Version
0.3.4", 
https://lists.freedesktop.org/archives/openchrome-users/2016-February/007234.html.

Related freedesktop.org and downstream bugs due to the driver:

* "Unknown Card-Ids (3371|1019|2125), Chipset: P4M900/VN896/CN896 [and
Xserver crash]", http://bugs.freedesktop.org/show_bug.cgi?id=94130
* "Light Display Manager fails to load [due to Xserver crash]",
http://bugs.launchpad.net/lightdm/+bug/1540774

Also see the following on the debian-x mailing list:

* "Freedesktop and OpenChrome Version 0.3.4",
http://lists.debian.org/debian-x/2016/02/msg00114.html



debian-unstable:/# apt-cache show xserver-xorg-video-openchrome
Package: xserver-xorg-video-openchrome
Version: 1:0.3.3-2
Installed-Size: 546
Maintainer: Debian X Strike Force 
Architecture: amd64
Provides: xorg-driver-video
Depends: libc6 (>= 2.14), libdrm2 (>= 2.3.1), libx11-6 (>=
2:1.4.99.1), libxext6, libxv1, libxvmc1, xorg-video-abi-20,
xserver-xorg-core (>= 2:1.17.99.902)
Description-en: X.Org X server -- VIA display driver
 OpenChrome is a project for the development of free and open-source drivers
 for the VIA UniChrome video chipsets.
 .
 Originally called the 'snapshot' release, since it was a snapshot of an
 experimental branch of the unichrome cvs code, this is a continued development
 of the open source unichrome driver (from http://unichrome.sf.net) which
 also incorporates support for the unichrome-pro chipsets.
 .
 Support for hardware acceleration (XvMC) for all chipsets has subsequently
 been ripped out of the unichrome.sf.net driver. Therefore your only option if
 you wish to make use of the acceleration features of your VIA chip with free
 and open-source drivers is to use this version of the driver.
Description-md5: 11d4a7275218ad33ccc6479463963d83
Homepage: https://www.freedesktop.org/wiki/Openchrome/
Tag: hardware::video, implemented-in::c, role::plugin, use::driver
Section: x11
Priority: optional
Filename: 
pool/main/x/xserver-xorg-video-openchrome/xserver-xorg-video-openchrome_0.3.3-2_amd64.deb
Size: 199654
MD5sum: ff4710469045b8e878164c3f204557fe
SHA1: d142e843e64059da6581c1c0615eba5046c31cb8
SHA256: 96a60c621021a2f3924e371c7be395eb274bb9725362cd5539fe74b61d3be0cf

Bug#715505: Updated OpenChrome driver available

[Jeffrey Walton]

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
http://bugs.freedesktop.org/show_bug.cgi?id=94130.

Bug#801424: Installing Chroot for Debian Sid breaks X32

[Jeffrey Walton]

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"

[Jeffrey Walton]

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. (-fsanitize=address produces a warning, and
we skip the configuration during testing).

...
g++ -DDEBUG -g2 -O1 -std=c++03  -pipe -fsanitize=undefined -c fipsalgt.cpp
g++ -DDEBUG -g2 -O1 -std=c++03  -pipe -fsanitize=undefined -c dlltest.cpp
g++ -o cryptest.exe -DDEBUG -g2 -O1 -std=c++03  -pipe
-fsanitize=undefined bench.o bench2.o test.o validat1.o validat2.o
validat3.o adhoc.o datatest.o regtest.o fipsalgt.o dlltest.o
./libcryptopp.a -pthread
/usr/bin/ld: cannot find -lubsan
collect2: error: ld returned 1 exit status
GNUmakefile:367: recipe for target 'cryptest.exe' failed

**

# 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++ --version
g++ (Debian/Linaro 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

**

# apt-cache show g++
Package: g++
Source: gcc-defaults (1.136)
Version: 4:4.9.2-2
Installed-Size: 34
Maintainer: Debian GCC Maintainers 
Architecture: arm64
Provides: c++-compiler
Depends: cpp (>= 4:4.9.2-2), gcc (>= 4:4.9.2-2), g++-4.9 (>=
4.6.4-1~), gcc-4.9 (>= 4.6.4-1~)
Description-en: GNU C++ compiler
 This is the GNU C++ compiler, a fairly portable optimizing compiler for C++.
 .
 This is a dependency package providing the default GNU C++ compiler.
Description-md5: 4d44b18774ae5123b7c3f70d940cf655
Build-Essential: yes
Tag: devel::compiler, devel::lang:c++, implemented-in::c,
 interface::commandline, role::dummy, role::metapackage, suite::gnu,
 works-with::software:source
Section: devel
Priority: optional
Filename: pool/main/g/gcc-defaults/g++_4.9.2-2_arm64.deb
Size: 1518
MD5sum: 6f12e1b386fb7056857365db6d8829d6
SHA1: e7e9581bdc59d2254e9a3636e0f7605da48d4270
SHA256: 28ec989b9e4e47ad25588fd2082ff5767767bb49ee37a30d184dd4a9bfa06a89

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

[Jeffrey Walton]

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 tested

12 errors detected

25584:/usr/bin/../lib/gcc/x86_64-linux-gnu/5.2.1/../../../../include/c++/5.2.1/bits/ios_base.h:102:24:
runtime error: load of value 4294967221, which is not a valid value
for type 'std::_Ios_Fmtflags'
25585:/usr/bin/../lib/gcc/x86_64-linux-gnu/5.2.1/../../../../include/c++/5.2.1/bits/ios_base.h:82:67:
runtime error: load of value 4294967221, which is not a valid value
for type 'std::_Ios_Fmtflags'
2:./usr/bin/../lib/gcc/x86_64-linux-gnu/5.2.1/../../../../include/c++/5.2.1/bits/ios_base.h:102:24:
runtime error: load of value 4294967221, which is not a valid value
for type 'std::_Ios_Fmtflags'
26667:/usr/bin/../lib/gcc/x86_64-linux-gnu/5.2.1/../../../../include/c++/5.2.1/bits/ios_base.h:82:67:
runtime error: load of value 4294967221, which is not a valid value
for type 'std::_Ios_Fmtflags'
26844:/usr/bin/../lib/gcc/x86_64-linux-gnu/5.2.1/../../../../include/c++/5.2.1/bits/ios_base.h:102:24:
runtime error: load of value 4294967221, which is not a valid value
for type 'std::_Ios_Fmtflags'
26845:/usr/bin/../lib/gcc/x86_64-linux-gnu/5.2.1/../../../../include/c++/5.2.1/bits/ios_base.h:82:67:
runtime error: load of value 4294967221, which is not a valid value
for type 'std::_Ios_Fmtflags'
27920:./usr/bin/../lib/gcc/x86_64-linux-gnu/5.2.1/../../../../include/c++/5.2.1/bits/ios_base.h:102:24:
runtime error: load of value 4294967221, which is not a valid value
for type 'std::_Ios_Fmtflags'
27921:/usr/bin/../lib/gcc/x86_64-linux-gnu/5.2.1/../../../../include/c++/5.2.1/bits/ios_base.h:82:67:
runtime error: load of value 4294967221, which is not a valid value
for type 'std::_Ios_Fmtflags'
30604:/usr/bin/../lib/gcc/x86_64-linux-gnu/5.2.1/../../../../include/c++/5.2.1/bits/ios_base.h:102:24:
runtime error: load of value 4294967221, which is not a valid value
for type 'std::_Ios_Fmtflags'
30605:/usr/bin/../lib/gcc/x86_64-linux-gnu/5.2.1/../../../../include/c++/5.2.1/bits/ios_base.h:82:67:
runtime error: load of value 4294967221, which is not a valid value
for type 'std::_Ios_Fmtflags'
31680:./usr/bin/../lib/gcc/x86_64-linux-gnu/5.2.1/../../../../include/c++/5.2.1/bits/ios_base.h:102:24:
runtime error: load of value 4294967221, which is not a valid value
for type 'std::_Ios_Fmtflags'
31681:/usr/bin/../lib/gcc/x86_64-linux-gnu/5.2.1/../../../../include/c++/5.2.1/bits/ios_base.h:82:67:
runtime error: load of value 4294967221, which is not a valid value
for type 'std::_Ios_Fmtflags'