Bug#1077271: systemd broken after 256.4-2 upgrade

[Richard B]

Package: systemd
Version: 256.4-2
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

Upgrading systemd and its dependencies to 256.4-2 on Trixie results in any 
systemd operation
timing out at 25000ms.  This includes checking service status, suspending, and 
attempting
to reboot my machine.

* What led up to the situation?

Executing this command:
sudo apt install discover nftables systemd udev


* What exactly did you do (or not do) that was effective (or ineffective)?

Attempted to check status of systemd-networkd, systemd-timesyncd, and other 
services that
apt listed errors for (all of which resulted in timeouts), attempted to roll 
systemd back
to 256.2-1 (no longer available in Trixie), and tried to reboot and power off 
(which also
resulted in timeouts in the CLI.  Gnome shell doesn't display any power options 
after the
upgrade).

* What was the outcome of this action?

A successful upgrade.

* What outcome did you expect instead?

Here is the output of my upgrade:

sudo apt install discover nftables systemd udev

Upgrading:
  discover  libnftables1   libnss-systemd  libsystemd-shared  libudev1  
systemd systemd-dev   systemd-timesyncd
  libdiscover2  libnss-myhostname  libpam-systemd  libsystemd0nftables  
systemd-cryptsetup  systemd-sysv  udev

Summary:
  Upgrading: 16, Installing: 0, Removing: 0, Not Upgrading: 9
  Download size: 0 B / 9,419 kB
  Space needed: 114 kB / 17.3 GB available

Continue? [Y/n] 
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Reading changelogs... Done
Preconfiguring packages ...
(Reading database ... 227401 files and directories currently installed.)
Preparing to unpack .../0-libnss-systemd_256.4-2_amd64.deb ...
Unpacking libnss-systemd:amd64 (256.4-2) over (256.2-1) ...
Preparing to unpack .../1-systemd-dev_256.4-2_all.deb ...
Unpacking systemd-dev (256.4-2) over (256.2-1) ...
Preparing to unpack .../2-systemd-sysv_256.4-2_amd64.deb ...
Unpacking systemd-sysv (256.4-2) over (256.2-1) ...
Preparing to unpack .../3-libpam-systemd_256.4-2_amd64.deb ...
Unpacking libpam-systemd:amd64 (256.4-2) over (256.2-1) ...
Preparing to unpack .../4-systemd_256.4-2_amd64.deb ...
Unpacking systemd (256.4-2) over (256.2-1) ...
Preparing to unpack .../5-systemd-timesyncd_256.4-2_amd64.deb ...
Unpacking systemd-timesyncd (256.4-2) over (256.2-1) ...
Preparing to unpack .../6-systemd-cryptsetup_256.4-2_amd64.deb ...
Unpacking systemd-cryptsetup (256.4-2) over (256.2-1) ...
Preparing to unpack .../7-libsystemd-shared_256.4-2_amd64.deb ...
Unpacking libsystemd-shared:amd64 (256.4-2) over (256.2-1) ...
Preparing to unpack .../8-libsystemd0_256.4-2_amd64.deb ...
Unpacking libsystemd0:amd64 (256.4-2) over (256.2-1) ...
Setting up libsystemd0:amd64 (256.4-2) ...
...
Setting up systemd-dev (256.4-2) ...
Setting up libsystemd-shared:amd64 (256.4-2) ...
Setting up libnss-myhostname:amd64 (256.4-2) ...
Setting up discover (2.1.2-10.1) ...
Setting up systemd (256.4-2) ...
/usr/lib/tmpfiles.d/legacy.conf:13: Duplicate line for path "/run/lock", 
ignoring.
Failed to list units: Failed to activate service 'org.freedesktop.systemd1': 
timed out (service_start_timeout=25000ms)
Failed to expand names: Connection timed out
Failed to try-restart systemd-networkd.service: Failed to activate service 
'org.freedesktop.systemd1': timed out (service_start_timeout=25000ms)
See system logs and 'systemctl status systemd-networkd.service' for details.
Failed to try-restart systemd-journald.service: Failed to activate service 
'org.freedesktop.systemd1': timed out (service_start_timeout=25000ms)
See system logs and 'systemctl status systemd-journald.service' for details.
Setting up systemd-cryptsetup (256.4-2) ...
Setting up systemd-timesyncd (256.4-2) ...
Reload daemon failed: Failed to activate service 'org.freedesktop.systemd1': 
timed out (service_start_timeout=25000ms)
Failed to get unit file state for systemd-time-wait-sync.service: Failed to 
activate service 'org.freedesktop.systemd1': timed out 
(service_start_timeout=25000ms)
Failed to retrieve unit state: Failed to activate service 
'org.freedesktop.systemd1': timed out (service_start_timeout=25000ms)
systemd-time-wait-sync.service is a disabled or a static unit not running, not 
starting it.
Failed to get unit file state for systemd-timesyncd.service: Failed to activate 
service 'org.freedesktop.systemd1': timed out (service_start_timeout=25000ms)
Failed to retrieve unit state: Failed to activate service 
'org.freedesktop.systemd1': timed out (service_start_timeout=25000ms)
systemd-timesyncd.service is a disabled or a static unit not running, not 
starting it.
Setting up udev (256.4-2) ...
Reload daemon failed: Failed to activate service 'org.freedesktop.systemd1': 
timed out (service_start_timeout=25000ms)
Failed to get unit file state for systemd-udevd.service: Failed to activate 
service 'org.freedesktop.systemd1': timed out (service_start_timeout=25000ms)
Setting up systemd-s

Bug#1063900: gstreamer1.0-plugins-good: missing Breaks+Replaces: gstreamer1.0-plugins-ugly (<< 1.23)

[Richard B]

Hello.

Upgrading gstreamer1.0-plugins-ugly to 1.24.3-1 on Trixie didn't produce 
the error that was originally reported.  Here's my output:


   Retrieving bug reports... Done
   Parsing Found/Fixed information... Done
   serious bugs of gstreamer1.0-plugins-good (1.22.10-1 → 1.24.3-1)
   
 b1 - #1063900 - gstreamer1.0-plugins-good: missing
   Breaks+Replaces: gstreamer1.0-plugins-ugly (<< 1.23)
   Merged with: 1063921
   Summary:
 gstreamer1.0-plugins-good(1 bug)
   Are you sure you want to install/upgrade the above packages?
   [Y/n/?/...] y
   Reading changelogs... Done
   ...
   Preparing to unpack .../gstreamer1.0-plugins-good_1.24.3-1_amd64.deb ...
   Unpacking gstreamer1.0-plugins-good:amd64 (1.24.3-1) over
   (1.22.10-1) ...
   Preparing to unpack .../gstreamer1.0-plugins-bad_1.24.3-1_amd64.deb ...
   Unpacking gstreamer1.0-plugins-bad:amd64 (1.24.3-1) over (1.22.10-1) ...
   ...
   Preparing to unpack
   .../04-libgstreamer-plugins-bad1.0-0_1.24.3-1_amd64.deb ...
   Unpacking libgstreamer-plugins-bad1.0-0:amd64 (1.24.3-1) over
   (1.22.10-1) ...
   Preparing to unpack
   .../05-gir1.2-gst-plugins-bad-1.0_1.24.3-1_amd64.deb ...
   Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.24.3-1) over
   (1.22.10-1) ...
   ...
   Setting up libgstreamer-plugins-bad1.0-0:amd64 (1.24.3-1) ...
   Setting up gir1.2-gst-plugins-bad-1.0:amd64 (1.24.3-1) ...
   Setting up gstreamer1.0-plugins-good:amd64 (1.24.3-1) ...
   Setting up gstreamer1.0-plugins-bad:amd64 (1.24.3-1) ...
   Processing triggers for libc-bin (2.38-7) ...

I see that the conflicting files mentioned are on my system, but that 
didn't seem to impact my upgrade:


   -rw-r--r-- 1 root root 27K Apr 30 04:18
   /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstamrnb.so
   -rw-r--r-- 1 root root 19K Apr 30 04:18
   /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstamrwbdec.so
   -rw-r--r-- 1 root root 208 Apr 29 18:15
   /usr/share/gstreamer-1.0/presets/GstAmrnbEnc.prs

gstreamer1.0-plugins-ugly was upgraded to a matching version before 
this.  Here's what dpkg reports:


   ii  gstreamer1.0-plugins-ugly:amd64
   1.24.3-1 amd64    GStreamer plugins
   from the "ugly" set

Best.

Richard

Bug#1061731: fwupd: Failed to load daemon: failed to load engine: Failed to load config: Key file does not have group “redfish”

[Richard B]

Hello.

I can confirm that upgrading fwupd and libfwupd2 on Trixie to 1.9.14-1 
and installing the package maintainer's version of /etc/fwupd/fwupd.conf 
allowed the fwupd status to start:


   sudo apt upgrade
   Reading package lists... Done
   Building dependency tree... Done
   Reading state information... Done
   Calculating upgrade... Done
   The following packages will be upgraded:
  fwupd libfwupd2
   2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
   Need to get 0 B/3,833 kB of archives.
   After this operation, 54.3 kB of additional disk space will be used.
   Do you want to continue? [Y/n] y
   Retrieving bug reports... Done
   Parsing Found/Fixed information... Done
   serious bugs of fwupd (1.9.11-1 → 1.9.14-1) 
 b1 - #1061731 - fwupd: Failed to load daemon: failed to load
   engine: Failed to load config: Key file does not have group “redfish”
   Summary:
 fwupd(1 bug)
   Are you sure you want to install/upgrade the above packages?
   [Y/n/?/...] y
   Reading changelogs... Done
   ...
   Configuration file '/etc/fwupd/fwupd.conf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
  D : show the differences between the versions
  Z : start a shell to examine the situation
 The default action is to keep your current version.
   *** fwupd.conf (Y/I/N/O/D/Z) [default=N] ? y
   Installing new version of config file /etc/fwupd/fwupd.conf ...
   fwupd-offline-update.service is a disabled or a static unit not
   running, not starting it.
   fwupd-refresh.service is a disabled or a static unit not running,
   not starting it.
   fwupd.service is a disabled or a static unit not running, not
   starting it.
   Processing triggers for libc-bin (2.37-15) ...
   Processing triggers for man-db (2.12.0-3) ...
   Processing triggers for dbus (1.14.10-4) ...
   Processing triggers for hicolor-icon-theme (0.17-2) ...

   systemctl status fwupd
   ○ fwupd.service - Firmware update daemon
 Loaded: loaded (/usr/lib/systemd/system/fwupd.service; static)
 Active: inactive (dead)
   Docs: https://fwupd.org/

   sudo systemctl start fwupd

   systemctl status fwupd
   ● fwupd.service - Firmware update daemon
 Loaded: loaded (/usr/lib/systemd/system/fwupd.service; static)
 Active: active (running) since Thu 2024-03-07 16:37:27 CST; 3s ago
   Docs: https://fwupd.org/
   Main PID: 22184 (fwupd)
  Tasks: 7 (limit: 18110)
 Memory: 23.7M (peak: 108.7M)
    CPU: 988ms
 CGroup: /system.slice/fwupd.service
 └─22184 /usr/libexec/fwupd/fwupd

I kept fwupd at 1.9.11-1 since this bug was reported, but the new 
version seems to be in the clear.


Best.

Richard

Bug#1027506: Status of mozillavpn in Debian

[Richard B. Kreckel]

On Wed, 11 Jan 2023 09:43:31 +0100 Sylvestre Ledru 
 wrote:
go: could not create module cache: mkdir /sbuild-nonexistent: permission 
denied

To make this go away, the package must Build-Depend on dh-golang.

However, that does not seem to be enough. The way subpackages are 
fetched or not during build is not very clear to me. How did you put 
together the 2.9.0 source package?


  -richard.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1027506: Status of mozillavpn in Debian

[Richard B. Kreckel]

On 1/9/23 23:26, Sylvestre Ledru wrote:

Le 08/01/2023 à 00:46, Richard B. Kreckel a écrit :


2) Based on mozillavpn_2.9.0-1.debian.tar.xz, apply some changes to 
debian/ directory:
   a) -DBUILD_TESTING=OFF to dh_auto_configure argument in 
debian/rules (without it it FTBFS trying to run some tests and that is 
also in upstream's rules file)
   d) change rm -rf debian/mozillavpn/etc/opt/chrome to rm -rf 
debian/mozillavpn/etc/opt in debian/rules so purge won't remove 
/etc/opt/ since there's nothing in there anyway
   c) Add packages python3-click and python3-jinja2 to Build-Depnds in 
debian/control (without these, it FTBFS)
   d) remove libqt6* and qt6-qpa-plugins dependencies in 
debian/control (see #1026957).



I tried with these changes but I am getting:


/<>/src/connectionbenchmark/benchmarktaskdownload.cpp:50:4: 
error: #error Check if QT added support for QDnsLookup::lookup() on Android
    50 | #  error Check if QT added support for QDnsLookup::lookup() on 
Android

   |    ^
[ 56%] Building CXX object 
src/CMakeFiles/mozillavpn.dir/connectionbenchmark/benchmarktaskping.cpp.o


rings a bell?


Sure.

Mozillavpn 2.9.0 #errors out there if QT_VERSION >= 0x060400.

The current qt6-base-dev in the archive is 6.4.2+dfsg~rc1-3 and that 
#defines QT_VERSION 060402. Hence, #error...


You must have been compiling Mozillavpn version 2.9.0, and not 2.12.0, 
as I recommended! (It was Andrea Marchesini who changed this upstream 
2022-10-06.)


All my best,
  -richard.
--
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1027506: Status of mozillavpn in Debian

[Richard B. Kreckel]

On 1/9/23 10:38, Sylvestre Ledru wrote:

Or just push a fork on github. I can take it for there :)


For work-related reasons this isn't going to happen the next few weeks.

Can you, please, update to 1.12.0 and include the minor described fixes 
to debian/*? It should work, afaict.


  -richard.

Bug#1027506: Status of mozillavpn in Debian

[Richard B. Kreckel]

On 1/8/23 12:36, Richard B. Kreckel wrote:

I am unfamiliar with GitLab. Sorry.


Well, then I thought that could give it a try...

Is there a simple walk-through what to do to create salsa MRs in a case 
like this package?


(I've spent the whole Sunday now and I'm giving up frustrated by the 
existing documentation now.)


  -richard.

Bug#1027506: Status of mozillavpn in Debian

[Richard B. Kreckel]

Szlvestre,

On 1/8/23 00:54, Sylvestre Ledru wrote:
Could you please submit a MR here ? 
https://salsa.debian.org/sylvestre/mozillavpn


I will be happy to upload it then


Is that really necessary?
I am unfamiliar with GitLab. Sorry.

  -richard.

Bug#1027506: Status of mozillavpn in Debian

[Richard B. Kreckel]

Could we just upgrade to version 1.12.0 for sid/bookworm, please?

Right now, the mozillavpn package is slated for removal from bookworm. I 
would be very happy if we could avoid this.


After some tinkering, I got v1.12.0 to work on sid/bookworm. Here's what 
it takes:


1) Create mozillavpn_2.12.0.orig.tar.gz
   a) download 
https://github.com/mozilla-mobile/mozilla-vpn-client/archive/refs/tags/v2.12.0.tar.gz
   b) unpack it (and discover that directories under 3rdparty/ subdir 
are empty)
   c) drop the contents of 
https://github.com/mozilla/glean/archive/refs/tags/v52.0.0.tar.gz into 
3rdparty/glean/
   d) drop the contents of 
https://github.com/WireGuard/wireguard-tools/archive/refs/heads/master.zip 
into 3rdparty/wireguard-tools/


2) Based on mozillavpn_2.9.0-1.debian.tar.xz, apply some changes to 
debian/ directory:
   a) -DBUILD_TESTING=OFF to dh_auto_configure argument in debian/rules 
(without it it FTBFS trying to run some tests and that is also in 
upstream's rules file)
   d) change rm -rf debian/mozillavpn/etc/opt/chrome to rm -rf 
debian/mozillavpn/etc/opt in debian/rules so purge won't remove 
/etc/opt/ since there's nothing in there anyway
   c) Add packages python3-click and python3-jinja2 to Build-Depnds in 
debian/control (without these, it FTBFS)
   d) remove libqt6* and qt6-qpa-plugins dependencies in debian/control 
(see #1026957).


This builds for me on amd64.

An alternative to step 1) above is of course to clone from 
https://github.com/mozilla-mobile/mozilla-vpn-client.git and then git 
submodule update --init. That only adds some stuff not needed for Debian 
into the orig.tar.gz.


For the record, I've placed copies of the files at 
https://in.terlu.de/~kreckel/mozillavpn/.


Also, debian-release should be contacted because of the build failure on 
mipsel and mpis64el. It makes little sense to insist on these 
architectures if upstream doesn't care.


Please decide how to proceed and let me know if I can help in any way.

  -richard.
--
   .''`.  Richard B. Kreckel
  : :' :  
  `. `'   
`-<http://in.terlu.de/~kreckel/>

Bug#1026072: Fix for the bug

[Richard B. Kreckel]

I am having it too and downgrading to 107.0.1-1 fixes the problem.

It seems like someone was seeing something similar before and reported 
it here <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024351> but 
the bug got closed?


  -richy.
--
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#1016283: onetbb: FTBFS: _segment_table.h:63:63: error: member ‘tbb::detail::d1::segment_table, 128>, tbb::detail::d1::cache_aligned_alloc

[Richard B. Kreckel]

I am unable to reproduce the above compile-time error.

Bug#1016363: libx11-6 1.8.1 also breaks glxinfo

[Richard B. Kreckel]

On Wed, 3 Aug 2022 11:33:13 -0700 Max Bell  wrote:
> Why isn't the bug being fixed? That is obviously the correct solution.
So far, they argue that it's correct and only exposed bugs in all those
other packages. Which may even be correct. But without a clear
perspective of getting those fixed anytime soon, it's best to work
around in Debian.

  -richy.
-- 
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#1016363: libx11-6 1.8.1 also breaks glxinfo

[Richard B. Kreckel]

This is issue 157 upstream:
https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/157
Apparently, they do not want to revert it.

So, should Debian build with --disable-thread-safety-constructor, at
least for a while?

(Remember that this bug will soon block other packages from migrating,
e.g. thunderbird 102.)

  -richy.
-- 
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#906777: ginac: FTBFS in buster/sid (-I: command not found)

[Richard B. Kreckel]

This is because makeinfo is missing in your build environment.
Will add a build-depend on texinfo to fix this.

  -richy.

Bug#900511: libcurl4 Conflicts: libcurl3

[Richard B. Kreckel]

On Sat, 2 Jun 2018 23:14:40 +0300 Adrian Bunk  wrote:
> libcurl3 is not part of buster, and using libraries from previous 
> releases that are no longer present in a new stable Debian release is 
> not strictly supported - it works most of the time, but when problems
> are reported a Breaks/Conflicts against that library is usually the
> solution.

Yeah, I have read this:
https://salsa.debian.org/debian/curl/merge_requests/2.

Still, the question remains: Why can different libssl packages coexist
fine (even if they are from a previous Debian version) but libcurl
packages cannot?

There are external software packages shipped as .deb which require
libcurl3. (I've seen that the LightWorks video editor and several games
are affected.) To support those, there should be a way to provide libcurl3.

Bug#850149: shotwell: Freezes when trying to open an image in fullscreen mode

[Richard B. Kreckel]

Looking back at the original description, it might be this upstream bug:
.

Bug#850149: shotwell: Freezes when trying to open an image in fullscreen mode

[Richard B. Kreckel]

On Wed, 15 Feb 2017 13:04:43 +0200 Alberto Garcia  wrote:
> On Tue, Feb 14, 2017 at 06:36:05PM +, Debian Bug Tracking System wrote:
> >  shotwell (0.25.4+really0.24.5-0.1) unstable; urgency=medium
> >  .
> >* Revert to last stable release 0.24.5 (Closes: #850149).
> 
> Thanks for this! Shotwell is finally usable again.
> 
> However the original problem (as described in the first comment) is
> still present, do you want me to file a separate bug for that, or what
> do you prefer?

Is there a reference to an upstream bug?

  -richy.
-- 
Richard B. Kreckel
<http://in.terlu.de/~kreckel/>

Bug#849688: Acknowledgement (package in debian/testing is development version, severely broken)

[Richard B. Kreckel]

On 12/29/2016 08:59 PM, Richard B. Kreckel asked:
> Can a user downgrade to 0.24 once he has started using 0.25.1?

On 12/29/2016 09:22 PM, Jens Georg replied:
> Yes, that's perfectly fine as long as you go for shotwell-0.24.3,
> otherwise you re-introduce an db index issue.

Bug#849688: package in debian/testing is development version, severely broken

[Richard B. Kreckel]

Package: shotwell
Version: 0.25.1
Severity: grave

The version 0.25.1 of shotwell that is packaged for Debian/testing is
unsuitable for release in stretch. As Jens Georg points out on his Blog
at http://jensge.org/, the odd-numbered versions are unstable
development versions that should not be packaged by distributions.

According to Jens Georg, there has recently been a major change in the
menu handling code, temporarily causing severe usability regressions.
(I've added several bugs to Gnome's bugzilla database about that:
776527, 776298, 776590, 776592, 776593...)

The version in Debian/testing is plagued by all of these problems and
the overall user experience of this package has the potential to turn
people off. That would be a shame.

Having an eye on the Debian/stretch release and impeding freeze, there
are two options:
1) either downgrade to the latest stable version (0.24.2) or
2) move along with the version from git and hope for the best.

I don't know which option is more feasible. This is a question for Jens
Georg: Can a user downgrade to 0.24 once he has started using 0.25.1?

  -richy.
-- 
Richard B. Kreckel
<http://in.terlu.de/~kreckel/>

Bug#830532: package should be re-built with gcc-6

[Richard B. Kreckel]

Package: ginac
Version: 1.7.0-1
Severity: serious

The uploaded amd64 package was built with gcc-6. But on other
architectures, it was built with gcc-5 -std=c++11. To avoid any ABI
breakage or yet anther soname bump, this package should not migrate to
testing.

A new package should be uploaded as soon as gcc-6 has become the default
compiler.

Bug#768922: [Debian-ha-maintainers] Bug#768922: pacemaker in jessie

[Richard B Winters]

Hello,

On Wed, 2015-05-06 at 05:37 +, Sam McLeod wrote:
> Any progress with Pacemaker on Jessie?
> I've had to revert back to Wheezy but that has the much older
> Pacemaker 1.1.7

Please see:

http://lists.alioth.debian.org/pipermail/debian-ha-maintainers/2015-May/004182.html


Best,


-- 
Rik


signature.asc
Description: This is a digitally signed message part

Bug#768618: [Debian-ha-maintainers] Bug#768618: pacemaker: stopped working after upgrade to 1.1.10+git20130802-4.1

[Richard B Winters]

Hello,

On Mon, 2015-04-27 at 14:40 +1000, Sam McLeod wrote:
> Any progress on Pacemaker for Jessie - Is there an alternative or do I
> have to downgrade back to Wheezy?

We are working on the stack and expect to be back in business in the
near future.

You can see our progress by looking through the public packaging
repositories [1], as well as keep up to date on the team's discussions
by subscribing to the team's mailing list [2], or reviewing the public
archives [3].

We also have a wiki page which sums up some information [4]

> I'm surprised to see Jessie was released with so many packages
> missing.

Yes unfortunately pacemaker and friends missed the freeze-date for
Jessie, and there was nothing to be done at that point.


References:

[1] http://anonscm.debian.org/cgit/debian-ha/
[2] debian-ha-maintain...@lists.alioth.debian.org
[3] http://lists.alioth.debian.org/pipermail/debian-ha-maintainers/
[4] https://wiki.debian.org/Debian-HA


Best,



-- 
Rik


signature.asc
Description: This is a digitally signed message part

Bug#781222: mpmath.polyroots fails with "NameError: global name 'orig' is not defined"

[Richard B. Kreckel]

Package: python-mpmath
Version: 0.19-1
Severity: serious
Tags: patch

How to reproduce:
$ python
Python 2.7.9 (default, Mar  1 2015, 12:57:24)
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from mpmath import mp
>>> mp.polyroots([4,3,2], error=True)
Traceback (most recent call last):
  File "", line 1, in 
  File
"/usr/lib/python2.7/dist-packages/mpmath/calculus/polynomials.py", line
201, in polyroots
err = max(err, ctx.ldexp(1, -orig+1))
NameError: global name 'orig' is not defined

Jeez, this silly glitch renders a significand portion of mpmath unusable!

Fix is (stolen from upstream git repository):
--- a/usr/lib/python2.7/dist-packages/mpmath/calculus/polynomials.py
+++ b/usr/lib/python2.7/dist-packages/mpmath/calculus/polynomials.py
@@ -156,6 +156,7 @@
 # Constant polynomial with no roots
 return []

+orig = ctx.prec
 tol = +ctx.eps
     with ctx.extraprec(extraprec):
 deg = len(coeffs) - 1

  -richy.
-- 
Richard B. Kreckel
<http://in.terlu.de/~kreckel/>


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#768922: [Debian-ha-maintainers] pacemaker in jessie

[Richard B Winters]

On Mon, 9 Mar 2015 12:28:44 +0100 franz schaefer  wrote:
> 
> > > the libqb0 version 0.17.0-2 compiled on jessie out of the box. 
> > >
> > > so that should be quick and easy. who is going to do it?
> > 
> > In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768922#35 Jonathan
> > Wiltshire (member of the release team) stated that migrating libqb isn't
> > an option.  And the pacemaker reversion did not happen either.  Lacking
> > direction, other people couldn't do anything about this either.
> 
> Ok. but what i do not understand: as it seems libqb is only used by
> pacemaker and its daemons only anyway.  so even if it is not as clean as one
> would wish for: why cant we still have it? as i said: it compiled fine and
> with that library all the pacemaker stuff seems to work well. 
> 
> i would say it is better to have pacemaker then to not have it in the
> distribution...
> 
> 
> mond
> 
> 
> -- 
> ~~
>.Franz Schaefer GPG KeyID: CFA2F632
>   ..  +43 699 106 14 590 +43 720502048  Fingerprint: 57C2 C0CC
>   ... schae...@mond.at 6F0A 54C7 0D88 D37E 
> ...  http://www.mond.at/   C17C CB16 CFA2 F632
> 
> 
> 


That cluster stack really doesn't actually work fine though, it just
starts up - but then nothing else works; and that's if it even starts
for you.

Firstly, let me help by providing these links (provided by digimer of
clusterlabs - and he did say to take it with a grain of salt):

https://alteeve.ca/w/AN!Cluster_Tutorial_2
https://alteeve.ca/w/History_of_HA_Clustering

The biggest issue is that the clusterlabs stack no longer uses cman (its
deprecated...or even worse than deprecated; abandoned much like
heartbeat). CLI tools include (but are not limited to) crmsh and pcs.

Pacemaker 1.10.x doesn't come with cman support, but libcorosync 1.4.6
and any of the other non-sid/experimental packages from Debian are meant
to work with cman, because prior to 2.x: Corosync didn't handle quorum
on its own. RHEL only used cman until the new configuration was ready
and they were able to migrate (upgrading breaks the cluster).

You can upgrade to libcorosync 2.3.3 from unstable or experimental, but
it was built with the improper dependencies for the modern stack
configuration -> as evident by the massive errors you get by installing
all of the newest corosync libraries (cpg, cfg, cmap, totem, quorum,
etc) from Debian, and trying to run corosync and pacemaker (CMAP via
pacemaker complains about database API errors, other cmap errors,
connections refused errors, etc - I've been in the clusterlabs channel
for days now sorting this out).

Attempting to use libcorosync 2.3.3 with older dependency packages won't
work because those older packages expect cman or crmsh to be installed
and of course yields API errors (naturally).

There is no crmsh package or pcs/pcsd package to replace cman, in fact
you need to install cman to get crmsh on Debian at this time without
building from source. Yet for clarity, beekof (pacemaker author)
recommends pcs, and clusterlabs associates state crmsh is good too.

---

So what we really need are new packages across the board (and they
should be brand new packages):

1. libqb (latest from github)

2  libcorosync (latest from github --enable-systemd). And I think we 
   should keep all the libraries in the exact same package, rather than 
   all broken up (cfg, cpg, sam, etc - this will make it easier to 
   choose an older stack or the modern one. How often does anyone 
   use those libraries outside of pacemaker/corosync anyhow?)

3. pacemaker (latest from github --with-corosync --with-cs-quorum )

4. crmsh & pcs/pcsd.  I've gotten both to build on Debian and work with 
   no issue, they are what modern documentation is based on, and are 
   the recommended 'editors' to use with the modern stack.


Lastly, it wasn't just yesterday that clusterlabs updated the
stack...its been corosync 2.x and pacemaker 1.x for years now. Debian is
just extraordinarily out of date sticking with corosync 1.4.6 and
recommending backports to users.


I've offered to help, I can package any of the components, contribute to
code, etc. I've requested to join Debian-HA on alioth (Devrik-Guest).
I'll post pacemaker, corosync, libqb, and crmsh/pcs/pcsd to debian
mentors if I'm not allowed to join the team.  Hopefully something can be
done.


Best,


-- 
Rik


signature.asc
Description: This is a digitally signed message part

Bug#535323: libcln-dev: inappropriately ships /usr/share/info/dir.gz

[Richard B. Kreckel]

Richard B. Kreckel wrote:
I can and will work around the problem, but this does not look like the 
right place to fix it. I don't know which build system component is the 
culprit, though.


I removed usr/share/info from libcln-dev.dirs and provided a 
libcln-dev.info containing usr/share/info/cln.info*. But the package 
still contains usr/share/info/dir.gz. Oh, Why?


   -richy.
--
  .''`.  Richard B. Kreckel
 : :' :  
 `. `'   
   `-<http://www.ginac.de/~kreckel/>



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#535323: libcln-dev: inappropriately ships /usr/share/info/dir.gz

[Richard B. Kreckel]

Aaron M. Ucko wrote:

libcln-dev inappropriately ships /usr/share/info/dir.gz, leading to a
file conflict with the latest version of pinfo, not to mention checksum
mismatches on account of its autogeneration.  The last time I
encountered such a bug (back in 2006), it was symptomatic of using old,
broken versions of automake, per #214769; however, libcln-dev has only
recently gained the file, so it's likely that the recent install-info
transition somehow threw it (or some other build system component) off.

At any rate, could you please leave it out?


Out of curiosity, I just re-built cln_1.3.0~beta1, which I've uplodaed 
two months ago and which did not contain the dir.gz file. It turns out 
that the re-built package does contain that file.


I can and will work around the problem, but this does not look like the 
right place to fix it. I don't know which build system component is the 
culprit, though.


  -richy.
--
  .''`.  Richard B. Kreckel
 : :' :  
 `. `'   
   `-<http://www.ginac.de/~kreckel/>




--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#455681: Attaching a patch to fix this bug

[Richard B. Kreckel]

Maximiliano Curia wrote:

Please notice that there is a new upstream release available (1.4.2) [1], it
might be worth the extra effort and upload that one.


I will upload 1.4.3 from upstream soon.
It does contain a fix for that problem.

  -richy.
--
  .''`.  Richard B. Kreckel
 : :' :  <[EMAIL PROTECTED]>
 `. `'   <[EMAIL PROTECTED]>
   `-<http://www.ginac.de/~kreckel/>



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#392578: ginac: FTBFS on arm

[Richard B. Kreckel]

Thomas Weber wrote:


please see
http://buildd.debian.org/fetch.php?&pkg=ginac&ver=1.3.5-2&arch=arm&stamp=1160247427&file=log&as=raw



Please see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=392054

--
 .''`.  Richard B. Kreckel
: :' :  <[EMAIL PROTECTED]>
`. `'   <[EMAIL PROTECTED]>
  `-<http://www.ginac.de/~kreckel/>



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#357231: Dupe of #340590 ?

[Richard B. Kreckel]

YL wrote:

I think that this bug is a dupe of bug #340590 
<http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=340590>. 
Am I right or wrong ?



I don't think you're right. #340590 was about an improper version of 
libcln and was fixed Fri, 25 Nov 2005. #357231 was about improper 
versions of libs from GCC and was fixed Thu, 16 Mar 2006.


Anyway, both bugs are archived. Why should anyone care?

-richy.

--
 .''`.  Richard B. Kreckel
: :' :  <[EMAIL PROTECTED]>
`. `'   <[EMAIL PROTECTED]>
  `-<http://www.ginac.de/~kreckel/>



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#340716: missing conflict/replaces

[Richard B. Kreckel]

Matthias Klose wrote:


Package: libginac1.3c2a
Severity: serious

Unpacking libginac1.3c2a (from .../libginac1.3c2a_1.3.3-2_hppa.deb)
...
dpkg: error processing
/var/cache/apt/archives/libginac1.3c2a_1.3.3-2_hppa.deb (--unpack):
trying to overwrite `/usr/lib/libginac-1.3.so.2.1.0', which is also
in package libginac1.3c2
dpkg-deb: subprocess paste killed by signal (Broken pipe)

 

Thanks. BTW: is it enough to add a Replaces:-field to the library 
packages or must I add a Conflicts:-field, too? My reading of the 
document would be to just add a Replaces:, but the subject irritates me.


-richy.

--
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#325841: ginac_1.3.2-1 (ia64/unstable): FTBFS: no matching function for call to 'GiNaC::registered_class_options::print_func(void (GiNaC::add::*)(const GiNaC::print_context&, unsigned int)const)'

[Richard B. Kreckel]

On Wed, 31 Aug 2005, Richard B. Kreckel wrote:
> On Wed, 31 Aug 2005, Steve Langasek wrote:
> > This looks like a cascading failure, but I don't really know what the
> > first failure means in this case, as I don't understand the code well
> > enough to know why it works on the *other* architectures. :)
>
> Indeed, that's the interesting question.  It works on every compiler
> version I've tried on any platform, it's just ia64 that doesn't seem to
> like it.  Strange.

Update: after updating to the g++ from unstable it stopped working on
my i386 machine, too.  I'm not entirely sure, but maybe it's this:

struct lala {
void takemeplease() const {}
};

struct holder {
template
holder(void (T::*)())
{ /* ... */ }
};

holder froobazz(&lala::takemeplease);

This code appears to compile with all but the latest g++.  Is it valid, or
should there be a const in the function pointer parameter in the ctor?

Was there some patch to Debian's GCC which might be responsible for the
change?

I'm going to bootstrap a vanilla GCC now...

Regards
  -richy.
-- 
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#325841: ginac_1.3.2-1 (ia64/unstable): FTBFS: no matching function for call to 'GiNaC::registered_class_options::print_func(void (GiNaC::add::*)(const GiNaC::print_context&, unsigned int)const)'

[Richard B. Kreckel]

On Wed, 31 Aug 2005, Steve Langasek wrote:
> This looks like a cascading failure, but I don't really know what the
> first failure means in this case, as I don't understand the code well
> enough to know why it works on the *other* architectures. :)

Indeed, that's the interesting question.  It works on every compiler
version I've tried on any platform, it's just ia64 that doesn't seem to
like it.  Strange.

Regards
  -richy.
-- 
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#323119: build still fails same way

[Richard B. Kreckel]

On Sat, 20 Aug 2005, Martin Waitz wrote:
[...]
> previously, it couldn't find cln-config, because libcln-dev was missing.
> now it does, but it can't compile a test program.
>
> could you please send me the config.log from your machine?
>
> Richard: do you have any idea?

CLN's autoconf macro collection cln/m4/gmp.m4 contains a macro called
CL_GMP_CHECK that basically defines $LIBS=-lgmp.  Invoking `cln-config
--libs` returns that variable.  But you cannot link against it since
libgmp.so (provided by libgmp3-dev package)  is missing, only libgmp.so.3
is there (provided by libgmp3c2).

This has never been spotted before because all other packages using cln
seem to build-depend on libgmp3-dev, in addition to libcln-dev.

So, who's wrong?  Can I safely omit -lgmp from the output of `cln-config
--libs`?  I'm inclined to say no, because generally, I cannot assume that
-lcln implies -lgmp.  The library libcln.so.x.y.z may depend on a Linux
ELF system on libgmp.so.3, but that might not be true on other Unix
systems.  After all, that is what `cln-config --libs` is all about!

Maybe, `cln-config --libs` could be improved.  But it would have to take
into account situations like configure --disable-shared.  This is because
a libcln.a library doesn't bring a linker dependency on libgmp.a.  :-(

Lacking a better analysis how `cln-config --libs` could be improved, I
suggest to add libgmp3-dev to qalculate's bulid-depend line.

Regards
  -richy.
-- 
  .''`.  Richard B. Kreckel
 : :' :  <[EMAIL PROTECTED]>
 `. `'   <[EMAIL PROTECTED]>
   `-<http://www.ginac.de/~kreckel/>



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]