Bug#1053752: emacs metapackage only depends on emacs-{gtk,nox,…} >= 27.1; should depend on >= {Version of metapackage}

2023-10-10 Thread Marcus Müller
Package: emacs
Version: 1:29.1+1-5~bpo12+1
Severity: normal
X-Debbugs-Cc: marcus_deb...@hostalia.de

Dear Maintainer,

when upgrading the `emacs` metapackage, one would expect the providing
emacs-gtk, emacs-nox, emacs-lucid… package to be upgraded. That's not
happening. For example:

on bookworm:

#install emacs 28
apt install emacs
#enable the bookworm backports repo
sed -i 's/Suites:.*$/& bookworm-backports/'
#update emacs to 29
apt update
apt install emacs/bookworm-backports

effectlessly updates the metapackage, and leaves the actual emacs
installation alone. This leads to user confusion¹.

The reason becomes obvious when one checks the dependencies:

#> apt depends emacs
emacs
 |Depends: emacs-gtk (>= 1:27.1)
 |Depends: emacs-pgtk (>= 1:27.1)
 |Depends: emacs-lucid (>= 1:27.1)
  Depends: emacs-nox (>= 1:27.1)

#> apt depends emacs/bookworm-backports
emacs
 |Depends: emacs-gtk (>= 1:27.1)
 |Depends: emacs-pgtk (>= 1:27.1)
 |Depends: emacs-lucid (>= 1:27.1)
  Depends: emacs-nox (>= 1:27.1)

So, the metapackage in either case doesn't depend on
emacs-implementation of the same version, but on a much older version
(or anything after).

Proposed solution: make `emacs~version` depend on `emacs-gtk==version`,
not on `>=much-older-version`

Best,
Marcus Müller


¹ 
https://unix.stackexchange.com/questions/758547/i-have-2-versions-of-emacs-installed-in-debian-how-do-i-remove-one-of-them/758553#758553

-- System Information:
Debian Release: 12.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.4.15-200.fc38.x86_64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages emacs depends on:
ii  emacs-pgtk  1:29.1+1-5~bpo12+1

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information


Bug#991414: volk no longer supports neon on armhf

2021-07-22 Thread Marcus Müller
Hi Peter,

thanks for digging in so deeply!

First thing I'm going to do: Loop Johannes Demel in here, he's the most 
knowledgeable
person on the CPU detection and build issues.

Johannes, see below. There's two things to unpack here:

1. It looks like debian disables NEON. Do we need to check with Mait on that? 
Or is this
somehow "right"?
2. see the build problem; that looks like an archi/µarch mismatch, but I don't 
know how to
interpret it.

Maybe you can shine some light on this?

Best regards,
Marcus


On 23.07.21 00:07, peter green wrote:
> Package: volk
> Version: 2.0.0-1
> Severity: important
> X-debbugs-cc: mmuel...@gnuradio.org
> 
> Hi,
> 
> While raspbian and Debian armhf have different baselines what they share in
> common is that neon is not part of the baseline configuration but is present 
> on
> a large proportion of the systems people use in practice (for Debian armhf I
> suspect nearly all users have neon, for raspbian it's less because we still
> have pi1/pi0 users around) . So where upstream supports runtime detection
> of neon said runtime detection should be enabled and used.
> 
> Back in 2015 I disabled neon in raspbian's volk package, I can't remember why
> but I suspect it was because at the time I had no means of determining whether
> the package had runtime CPU   detection.
> 
> alle_die_mit_der from gnuradio upstream came into #raspbian on irc (to ask 
> about
> options for building stuff) and I took the opportunity to talk about the issue
> of runtime CPU detection. He guided me on how to test volk (quotes below) and
> I thus decided to revert our raspbian neon-disabling changes and build a 
> package
> for testing on raspbian bullseye.
> 
>>  The volk package in raspbian currently has neon disabled. from 
>> what you have
>> said I strongly suspect it could be re-enabled but before I actually 
>> re-enable it I need
>> a test plan that I can use to make sure i'm not breaking anything.
>>  VOLK has a unit test for every single "kernel"
>>  `make test` is your friend :)
>>  is there a way to run the tests against an installed version of 
>> volk?
>>  yeah
>>  `volk_profile` essentially does the same, while 
>> benchmarking them
>> <--snip-->
>>  does volk_profile use the same runtime cpu detection as normal 
>> use of volk?
>>  yes
>>  it should
>> <--snip-->
>>  you can query the runtime-available platforms with 
>> `volk-config-info
>> --avail-machines`
> 
> However to my surprise I discovered that the package built on raspbian from
> unmodified Debian sources didn't have any neon support either. I discovered 
> that
> the CMake scripts were failing to detect Neon because they were not using
> -mfpu=neon when building test programs.
> 
> I have confirmed this is not a raspbian specific issue and it seems to have
> been this way since version 2.0.0, this makes it a regression between buster
> and bullseye.
> 
> I modified the cmake scripts to use -mfpu=neon when detecting neon support
> but then the build itself failed with.
> 
>> cd /volk-2.4.1.new/obj-arm-linux-gnueabihf/lib && /usr/bin/cc -DHAVE_DLFCN_H
>> -DHAVE_FENV_H -D_GLIBCXX_USE_CXX11_ABI=1 
>> -I/volk-2.4.1.new/kernels/volk/asm/neon
>> -I/usr/include/orc-0.4 -I/volk-2.4.1.new/obj-arm-linux-gnueabihf/include
>> -I/volk-2.4.1.new/include -I/volk-2.4.1.new/kernels
>> -I/volk-2.4.1.new/obj-arm-linux-gnueabihf/lib -I/volk-2.4.1.new/lib
>> -I/usr/include/cpu_features -O2 -g -DNDEBUG -fPIC -o
>> CMakeFiles/volk_obj.dir/__/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s.o
>>  -c
>> /volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s
>> /volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s: 
>> Assembler
>> messages:
>> /volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:11: 
>> Error:
>> selected FPU does not support instruction -- `vmov.i32 q12,#0'
>> /volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:18: 
>> Error:
>> selected processor does not support `vld2.16 {d16-d19},[r4]!' in ARM mode
>> /volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:22: 
>> Error:
>> selected FPU does not support instruction -- `vsub.i16 q10,q8,q9'
>> /volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:23: 
>> Error:
>> selected processor does not support `vcge.s16 q11,q10,#0' in ARM mode
>> /volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:24: 
>> Error:
>> selected processor does not support `vcgt.s16 q10,q12,q10' in ARM mode
>> /volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:25: 
>> Error:
>> selected processor does not support `vand.i16 q11,q8,q11' in ARM mode
>> /volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:26: 
>> Error:
>> selected processor does not support `vand.i16 q10,q9,q10' in ARM mode
>> /volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:27: 
>> Error:
>> selected FPU does not support instruction --