Bug#1073456: RFS: colorize/0.66-1 -- Colorizes text on terminal with ANSI escape sequences

[Steven Schubiger]

Otto Kekäläinen  wrote:
> I didn't claim that you must use Salsa or CI.
> 
> I was just curious to learn is there a particular reason this package is
> not using Salsa-CI to validate that all easily testable things are correct?

I wasn't even aware of Salsa-CI.  FWIW, colorize is also on github[1].
The current state works for me, but if you insist enough I may change
my mind...

1: https://github.com/stsc/colorize

-stsc

Bug#1075714: (no subject)

[Steven Maddox]

Small omission...

"This reallypromoting the adoption of IPv6!"
 ^isn't

:)

Unless of course I've got this completely wrong and there is a way to do 
both a static IPv4 and a static IPv6 completely through d-i before the 
system even reboots into Debian for the first time.


But if you can, it's certainly not obvious and that's an issue in itself.

Bug#1075714: Can't statically configure both IPv4 and IPv6 using d-i

[Steven Maddox]

Package: debian-installer

There appears to be no way (when using the Debian Installer) to specify 
*both* a static IPv4 address (along with netmask and gateway) and a 
static IPv6 address (along with netmask and gateway).


It would be nice if when you pick 'Configure network manually' that it 
asks you for...

- IPv4 IP
- IPv4 netmask
- IPv4 Gateway
- IPv6 IP (this is missing)
- IPv6 netmask (this is missing)
- IPv6 Gateway (this is missing)

And then it'll ask for nameservers... where you can specify both IPv4 
and IPv6 nameservers together delimited by spaces.


If this is confusing for some users we could have...
- 'Configure IPv4 network manually'
- 'Configure IPv6 network manually'
- 'Configure IPv4 and IPv6 network manually'

Instead of just 'Configure network manually'

The way the manual reads (see section 6.3.1.5.3) ... 
https://www.debian.org/releases/stable/i386/ch06s03.en.html


It claims "All combinations of IPv4 and IPv6 [...] are supported" but 
isn't specific about how you do this, or if it is limited just to 
autoconfiguration alone.


At the moment someone has to pick either IPv4 or IPv6 and then manually 
edit their networking settings once Debian is installed.


This really promoting the adoption of IPv6!

As most people (where they have an IPv4 to use) will definitely 
prioritise making IPv4 connectivity work... more then IPv6.  So if 
forced to enter just one IP address by the Debian Installer, they'll go 
with IPv4.


Then we have to *hope* they remember to manually add IPv6 to their 
network configuration later on.  If they don't just go straight on to 
installing software and other setup.


--
Steven Maddox
Lantizia

Bug#433568: (no subject)

[Steven Maddox]

It's not impossible already to do VLANs with d-i currently (for anyone 
reading this after a temporary work around until this is properly fixed)...


Step 1) Get to the screen where d-i presents you with a list of network 
interfaces


Step 2) Go to VT2 (using alt-F2) and activate the console

Step 3) Add a VLAN interface to whichever physical interface you want it 
on... ip link add link eno1 name eno1.42 type vlan id 42


Step 4) Go back to VT1 (using alt+F1) and choose to go 'Back' and then 
forward by selecting 'Configure the network' to repopulate the list


Step 5) Pick the new VLAN interface until you're at the screen where 
you'd normally pick 'Configure network manually...' (but don't pick this 
option yet)


Step 6) Go BACK to VT2 (using alt-F2)

Step 7) Bring the physical and VLAN interfaces up... ip link set eno1 
up; ip link set eno1.42 up


Step 8) Go BACK to VT1 (using alt+F1) and continue as normal

EASY!.. OK... FINE... I admit that is sarcasm.  It's also laughable that 
it's easier to get d-i to use PPPoE than it is a VLAN.


Now you might think to do the commands on VT2 all at once, but I find 
once you've picked the network interface with d-i it'll bring the 
interface down!


Also these instructions are useless if you're not configuring a static 
IP as you'll have to be super quick before the autoconfiguration fails.


Lastly... (this is the main reason I'm adding to this bug report)...

Does the new patch discussed here address the fact that usually I find I 
have to run this (AFTER the system has booted up for the first time)...


sed -i 's/allow-hotplug/auto/' /etc/network/interfaces

... and then reboot again before any networking works?

Because 'allow-hotplug' just doesn't cut it with VLAN interfaces... it 
seems it must be 'auto'


Frankly I don't see why we don't use 'auto' in the default 
/etc/network/interfaces (whether using a VLAN or not) as it covers 
everything 'allow-hotplug' does but actually works in more cases.


Thoughts?

Bug#1073456: RFS: colorize/0.66-1 -- Colorizes text on terminal with ANSI escape sequences

[Steven Schubiger]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "colorize":

 * Package name : colorize
   Version  : 0.66-1
   Upstream contact : Steven Schubiger 
 * URL  : http://cgit.refcnt.org/colorize.git/about/
 * License  : GPL-3.0+
 * Vcs  : http://cgit.refcnt.org/colorize.git/
   Section  : utils

The source builds the following binary packages:

  colorize - Colorizes text on terminal with ANSI escape sequences

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/colorize/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/c/colorize/colorize_0.66-1.dsc

Changes since the last upload:

colorize (0.66-1) unstable; urgency=low

  * New upstream release.
  * Declare compliance with Debian Policy 4.7.0.
(No changes needed.)
  * debian/copyright: amend years.
  * debian/control: use v13 mode of debhelper-compat package.
  * debian/control: update Homepage link.

Regards,
-- 
  Steven Schubiger

Bug#1073011: nmu: cgal_5.6.1-1

[Steven Robbins]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: c...@packages.debian.org, Joachim Reichel 

Control: affects -1 + src:cgal
User: release.debian@packages.debian.org
Usertags: binnmu

New version of Ipe has been uploaded, which cgal uses.

nmu cgal_5.6.1-1 . ANY . unstable . -m "Rebuild against libipe 7.2.30"


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

Bug#1070753: (no subject)

[Steven Maddox]

I can confirm this patch works

--
Steven Maddox
Lantizia

Bug#1070753: (no subject)

[Steven Maddox]

It would seem the -A argument (for pppoe-discovery not ps) has been 
removed as a result of this bug report... #1042881


However this doesn't change that pppoe-discovery seems to indefinitely 
pause (preventing grep from realising there is an AC) in some 
circumstances.  Ultimately I've logged an issue about this upstream 
here... https://github.com/ppp-project/ppp/issues/490


But none of this would be an issue if this was rewritten to use -Q instead.

--
Steven Maddox
Lantizia

Bug#1070753: (no subject)

[Steven Maddox]

With the help of pham of #debian-boot on OFTC...

Problems found so far with /var/lib/dpkg/info/ppp-udeb.postinst

- Some lines call 'ps' with a -A argument which this build of busybox 
doesn't understand (so it doesn't record the process number correctly to 
try and kill it later)


- The '-A' argument passed to pppoe-discovery doesn't seem to exist and 
so it doesn't run properly


- With *some* (but not all) PPPoE concentrators... if pppoe-discovery 
finds the concentrator... it'll output the details and just sit there 
without exiting indefinably... so grep never has a chance to process the 
contents of stdin and find the string 'AC'.  This wouldn't be an issue 
if the busybox version of grep has --line-buffered but it doesn't :)


- Ultimately if -Q is used (instead of grepping for 'AC') then you'll 
get errcode 1 if one isn't found and errcode 0 if one is found... by 
default this'll take 15 seconds to try (unless you set -t and/or -a). 
But since the script runs this twice (once without -U and once with -U) 
then this means a wait of up to 30 seconds, which d-i has to be patient 
for and allow to happen.


- Ultimately if we're happy that pppoe-discovery will time itself out... 
then does d-i need to kill anything and thus knowing the process ID 
isn't needed?


--
Steven Maddox
Lantizia

Bug#1070753: Can't see PPPoE concentrators via d-i but pppoe-discovery can

[Steven Maddox]

Package: ppp-deb

To recreate this issue... boot the latest Debian 12 netinst ISO and at 
the boot menu hit escape then at the boot: prompt type in...


installgui modules=ppp-udeb

Then d-i will start and after choosing language etc... it'll try to find 
any see PPPoE concentrators and say they're not detected.


After you can go to 'Execute a shell' and you'll find that they're 
actually there and it shouldn't be a problem...


~ # ip link set ens192 up
~ # pppoe-discover -I ens192
   Service-Name: datasuite12.13
Access-Concentrator: datasuite12.13
AC-Ethernet-Address: 00:03:97:40:00:3e
--
   Service-Name: datasuite12.13
Access-Concentrator: datasuite12.13
AC-Ethernet-Address: 00:03:97:3d:80:2b
--

I even made a stupid animated GIF to show these steps in action...

https://5r.tf/temp-bugging-me-files/debian-pppoe-broke.gif

It seems someone else 14 years ago wrote about this in bug #587850 but 
nothing was resolved and he was told to talk to his ISP.


In this case I work for the ISP, so I'm pretty confident in the fact 
that the PPPoE concentrator is there.


I can do more tests if you've got idea where to go from here.

--
Steven Maddox
Lantizia

Bug#1065721: simage: FTBFS: error: conflicti ng types for ‘GifQuantizeBuffer’; have ‘int(unsigned int, unsigned int, int *, GifBy teType *, GifByteType *, GifByteType *, GifByteType *, GifColo

[Steven Robbins]

Control: severity -1 normal
thanks


On Sat, 9 Mar 2024 13:03:05 +0100 Sebastian Ramacher  
wrote:
> Source: simage
> Version: 1.8.3+ds-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the 
past)

The bug is fixed in unstable.  But the promotion to testing is held up by weird 
dependency issues.

I'm downgrading the bug to prevent removal from testing.  I see no reason to 
remove a package that does build properly in unstable.

-Steve


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

Bug#1068901: jupyter notebook fails to start: ModuleNotFoundError: No module named 'jupyter_server.contents'

[Steven Robbins]

Package: jupyter
Version: 5.3.2-1
Severity: normal

$ jupyter notebook
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/notebook/traittypes.py", line 235, in
_resolve_classes
klass = self._resolve_string(klass)
^^^
  File "/usr/lib/python3/dist-packages/traitlets/traitlets.py", line 2015, in
_resolve_string
return import_item(string)
   ^^^
  File "/usr/lib/python3/dist-packages/traitlets/utils/importstring.py", line
33, in import_item
module = __import__(package, fromlist=[obj])
 ^^^
ModuleNotFoundError: No module named 'jupyter_server.contents'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/bin/jupyter-notebook", line 33, in 
sys.exit(load_entry_point('notebook==6.4.12', 'console_scripts', 'jupyter-
notebook')())
^
  File "/usr/lib/python3/dist-packages/jupyter_core/application.py", line 282,
in launch_instance
super().launch_instance(argv=argv, **kwargs)
  File "/usr/lib/python3/dist-packages/traitlets/config/application.py", line
1073, in launch_instance
app = cls.instance(**kwargs)
  ^^
  File "/usr/lib/python3/dist-packages/traitlets/config/configurable.py", line
583, in instance
inst = cls(*args, **kwargs)
   
  File "/usr/lib/python3/dist-packages/traitlets/traitlets.py", line 1292, in
__new__
inst.setup_instance(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/traitlets/traitlets.py", line 1335, in
setup_instance
super(HasTraits, self).setup_instance(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/traitlets/traitlets.py", line 1311, in
setup_instance
init(self)
  File "/usr/lib/python3/dist-packages/notebook/traittypes.py", line 226, in
instance_init
self._resolve_classes()
  File "/usr/lib/python3/dist-packages/notebook/traittypes.py", line 238, in
_resolve_classes
warn(f"{klass} is not importable. Is it installed?", ImportWarning)
TypeError: warn() missing 1 required keyword-only argument: 'stacklevel'


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (700, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.9-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages jupyter depends on:
ii  jupyter-client7.4.9-2
ii  jupyter-console   6.6.3-1
ii  jupyter-core  5.3.2-1
ii  jupyter-nbformat  5.9.1-1

Versions of packages jupyter recommends:
ii  jupyter-nbconvert  6.5.3-4
ii  jupyter-notebook   6.4.12-2.2
ii  python3-ipykernel  6.29.3-1

Versions of packages jupyter suggests:
ii  jupyter-qtconsole  5.5.1-1

-- no debconf information

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

Bug#1067957: [[maude-bugs]] [EXTERNAL] Re: Maude fails to build on armhf

[Steven Eker]

I like that solution since I believe there are 64-bit platforms where 
long is 32-bits. I've updated my development version thus:


  //
  //    timeValue.tv_sec is 64-bit since Linux kernel 5.6 but GMP 
doesn't yet have support
  //    for long long which is a problem on platforms where long is 
less than 8 bytes.

  //
#if SIZEOF_LONG < 8
  double seconds = timeValue.tv_sec;
#else
  long seconds = timeValue.tv_sec;
#endif
  mpz_class nanoSeconds(seconds);

Of course I expect to drop support for 32-bit before 2038 - certainly 
when one our dependencies drops support. But I've gotten a bug report 
for building Maude on a Raspberry Pi.


Steven

On 4/10/24 14:59, Aaron M. Ucko wrote:


Steven Eker  writes:


This is harmless on 64-bit architectures since Index will be a signed
64-bit integer and if it works on 32-bit architectures, it's a work
around until GMP is fixed (hopefully before 2038).

I know this suggestion is unorthodox, and quite possibly moot at this
point in the context of official Debian packages -- but you might want
to consider formally going through double here, at least on the relevant
platforms.  Precision loss shouldn't be a concern for another 140
million years or so by my reckoning, and I expect the additional
conversion overhead would be negligible in practice.

Thanks!

Bug#1067957: [[maude-bugs]] [EXTERNAL] Re: Maude fails to build on armhf

[Steven Eker]

Hi Sebastian,

The lack of long long support in GMP has been the subject of some 
discussions:


https://gmplib.org/list-archives/gmp-bugs/2020-June/thread.html#4771
https://gmplib.org/list-archives/gmp-discuss/2021-January/thread.html#6625

I don't see it happening soon - it took years for the x18 issue on Apple 
silicon to be fixed.

In my development version I've modified the code to:

  Index seconds = timeValue.tv_sec;  // this is 32-bit on 32-bit 
machines so mpz_class constuctor is defined

  mpz_class nanoSeconds(seconds);
  nanoSeconds *= BILLION;
  nanoSeconds += timeValue.tv_nsec;

This is harmless on 64-bit architectures since Index will be a signed 
64-bit integer and if it works on 32-bit architectures, it's a work 
around until GMP is fixed (hopefully before 2038).


Steven

On 4/9/24 00:01, Sebastian Ramacher wrote:

Hi Steven

On 2024-04-08 15:38:50 -0700, Steven Eker wrote:

Hi Nilish,

I don't have a 32-bit machine to test on, but my understanding is that Linux
has moved to a 64-bit signed integer for time_t and this is a long long on
32-bit machines which is explicitly not supported by GMP's C++ API.

This sounds like it needs to fixed in GMP then.


https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Year_2038_problem__;!!DZ3fjg!--tzUBTnQHRKfnkc8PqaPE5gHxPm2QWswg2_MWTbLaWxFFDXu6jiPCjltocalTdckv2oG8G8tDajml0HNO6JIFyo$
https://urldefense.com/v3/__https://gmplib.org/manual/C_002b_002b-Interface-Integers__;!!DZ3fjg!--tzUBTnQHRKfnkc8PqaPE5gHxPm2QWswg2_MWTbLaWxFFDXu6jiPCjltocalTdckv2oG8G8tDajml0HNHAQQdRg$

I'm not happy converting a signed value to an unsigned value for all
architectures. But

   mpz_class nanoSeconds(static_cast(timeValue.tv_sec));

should fix the problem, at least until 2038. Can you check that this works?
If so I'll put it in the next public alpha.

And this does not sound like a fix which we want.

Best
Sebastian

Bug#1067957: [EXTERNAL] Re: [[maude-bugs]] Maude fails to build on armhf

[Steven Eker]

Hi Nilish,

I don't have a 32-bit machine to test on, but my understanding is that 
Linux has moved to a 64-bit signed integer for time_t and this is a long 
long on 32-bit machines which is explicitly not supported by GMP's C++ API.


https://en.wikipedia.org/wiki/Year_2038_problem
https://gmplib.org/manual/C_002b_002b-Interface-Integers

I'm not happy converting a signed value to an unsigned value for all 
architectures. But


  mpz_class nanoSeconds(static_cast(timeValue.tv_sec));

should fix the problem, at least until 2038. Can you check that this 
works? If so I'll put it in the next public alpha.


Steven

On 4/7/24 08:28, Nilesh Patra wrote:

On Sun, Apr 07, 2024 at 07:45:33PM +0530, Nilesh Patra wrote:

Hi,

Maude fails to build on armhf/arm32 arch with:

In file included from timeManagerSymbol.cc:64:
timeActions.cc: In member function ‘void 
TimeManagerSymbol::getTimeSinceEpoch(FreeDagNode*, 
ObjectSystemRewritingContext&)’:
timeActions.cc:43:41: error: call of overloaded ‘__gmp_expr(__time64_t&)’ is 
ambiguous
43 |   mpz_class nanoSeconds(timeValue.tv_sec);
   | ^
In file included from ../../src/BuiltIn/succSymbol.hh:28,
  from timeManagerSymbol.cc:53:
/usr/include/gmpxx.h:1646:3: note: candidate: ‘__gmp_expr<__mpz_struct [1], 
__mpz_struct [1]>::__gmp_expr(double)’
  1646 |   __GMPXX_DEFINE_ARITHMETIC_CONSTRUCTORS
   |   ^~
/usr/include/gmpxx.h:1646:3: note: candidate: ‘__gmp_expr<__mpz_struct [1], 
__mpz_struct [1]>::__gmp_expr(float)’

Full long here: 
https://buildd.debian.org/status/fetch.php?pkg=maude=armhf=3.4-1=1712489526=0
And Debian bug report here: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067957

Would be great if you have the cycles to look into it.

This patch fixes the issue at hand but I am unsure if it is sensible to apply
it.

diff --git a/src/ObjectSystem/timeActions.cc b/src/ObjectSystem/timeActions.cc
index 77395aa..63aa028 100644
--- a/src/ObjectSystem/timeActions.cc
+++ b/src/ObjectSystem/timeActions.cc
@@ -40,7 +40,7 @@ TimeManagerSymbol::getTimeSinceEpoch(FreeDagNode* message, 
ObjectSystemRewriting
DebugSave(r, clock_gettime(CLOCK_REALTIME, ));
Assert(r == 0, "clock_gettime() failed: " << strerror(errno));
  
-  mpz_class nanoSeconds(timeValue.tv_sec);

+  mpz_class nanoSeconds(static_cast(timeValue.tv_sec));
nanoSeconds *= BILLION;
nanoSeconds += timeValue.tv_nsec;
  


Best,
Nilesh

Bug#1062170: glw: NMU diff for 64-bit time_t transition

[Steven Robbins]

Hi,

Package glw has a serious bug against it because of an unapplied 64-bit time 
patch.  I don't know why it is not applied, but Michael Crusoe raised some 
relevant questions about it, quoted in full below.  Would the patch submitter 
be able to review and advise?

On Mon, 11 Mar 2024 13:34:42 +0100 "Michael R. Crusoe"  
wrote:
> I don't think this patch was effective. There is no package rename and 
> the build log from experimental contains the following warning:
> 
>  > dpkg-gencontrol: warning: Provides field of package libglw1-mesa: 
> substitution variable ${t64:Provides} used, but is not defined



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

Bug#1067771: cdk.h file location has changed, breaks application build

[Steven Robbins]

On Thursday, March 28, 2024 8:04:30 P.M. CDT Thomas Dickey wrote:

> I suppose that I _could_ have made a symlink in /usr/include/cdk,
> to address both old/new locations.  You might consider that for
> the package...

That's a good idea.  I've implemented your suggestion and closed the bug.

Thanks!
-Steve


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

Bug#1067771: cdk.h file location has changed, breaks application build

[Steven Robbins]

Hello Thomas!

Thanks for chiming in on this issue.  I had sent a follow-up at about the same 
time you did with a few details on the history as I could reconstruct it.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067771#18

In summary: I believe you changed the default location from  to 
 in 2012, adding a configure option at the same time.  When this version 
was uploaded to Debian (much later), a debian-specific patch was added to 
retain the original location.  Four years ago, the previous debian maintainer 
removed that patch - but was never uploaded to debian unstable.  I took over 
maintenance a month ago and inadvertently uploaded to unstable a version where 
the header change from 2012 was exposed for the first time.

I can see a valid argument for retaining the Debian practice.  But when I 
discovered that the upstream change was 12 years old, I figured that there are 
likely other folks long used to the "new" header location and have adapted 
their code.  So there is also a valid argument to adhering to the upstream 
location and harmonizing the landscape for code using libcdk.

I actually did a search on github and discovered examples of all three cases:
* code using  only
* code using  only
* code that probes both locations and uses the one found

I'm wondering whether you have an opinion on the merits of one path versus the 
other.  Do you have any information about how much currently-maintained 
software is still using ?

At present, I'm leaning towards retaining the default location .

Thanks,
-Steve


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

Bug#1067771: cdk.h file location has changed, breaks application build

[Steven Robbins]

On Tuesday, March 26, 2024 9:37:10 A.M. CDT Harald Welte wrote:
> Package: libcdk5-dev
> Version: 5.0.20230201-3
> Severity: normal
> 
> It used to be the case (for probably more than a decade) that the main cdk.h
> file contained in libcdk5-dev is located in /usr/include/cdk/cdk.h
> 
> This is still the case in debian stable as of 5.0.20180306-3
> 
> However, in currnt unstable (5.0.20230201-3), the location has suddenly
> shifted to /usr/include/cdk.h

That is correct.  I have only recently taken over cdk maintenance, but here's 
what I found in the archives.

Upstream changed the default 12 years ago.  The entry in CHANGES [1] for 
2012/03/23 includes:

+ add configure --enable-hdr-subdir to control whether cdk.h should
  be in /usr/include/cdk for example, or in /usr/include.  Make the
  default the latter, standard layout.

[1] https://salsa.debian.org/debian/libcdk5/-/blob/debian/CHANGES?
ref_type=heads

Previous maintainer added a patch to install cdk/cdk.h in 2016 [2], about 5 
months after the first post-2012 version was uploaded to unstable [3].  I 
didn't find any rationale for including the patch.

[2] 
https://salsa.debian.org/debian/libcdk5/-/blob/debian/debian/patches/cdk-h-old-place.patch?ref_type=heads

[3] https://tracker.debian.org/pkg/libcdk5/news/?page=2

About four years ago, the previous maintainer removed that patch [4].  You 
hadn't seen the effect yet because the packages with that change were only 
uploaded to experimental.  Again, I failed to find a reason for this change.

[4] https://salsa.debian.org/debian/libcdk5/-/commit/
3ee2ab1f1ecb06c7ff4871469f8661f367ebb6f0


> This is breaking applications like osmo-bsc, which is using the following
> autoconf macro to test for cdk.h presence:
> 
> AC_CHECK_HEADERS(cdk/cdk.h, [], AC_MSG_ERROR(Unable to find libcdk))

Given that the upstream change was 12 years ago, I'm genuinely surprised that 
sources are still looking for cdk/cdk.h.  I can see there's a mix of usages 
but at least some sources have adapted [5].  

[5] https://github.com/termux/termux-packages/commit/
6279216b943711ef83b6019fcf4bbe832c7a842b

My feeling is that there is benefit to being in harmony with upstream - as I 
presume other distros are.

Do you think you could adapt osmo-bsc to the new location?

Best,
-Steve


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

Bug#1066892: inventor: Update to 2.1.6 from GitHub

[Steven Robbins]

On Fri, 15 Mar 2024 01:46:05 +0100 Amr Ibrahim  
wrote:
> Package: inventor
> Severity: normal
> 
> Dear Maintainer,
> 
> The current homepage is dead (Invalid URL), and apparently there is an effort
> to maintain Open Inventor on GitHub:
> https://github.com/aumuell/open-inventor

Thank you for the link!

> 2.1.6:
> * build fixes for modern compilers on Linux and macOS
> * bug fixes, most importantly font rendering on 64 bit Linux
> * CMake as a modern alternative to the existing Makefile build system

Nice improvements.  Out of curiousity: are you using the 2.1.6 sources?  Are 
there important bug fixes for your workflow?

-Steve


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

Bug#1066702: libcdk5: FTBFS: configure: error: No curses header-files found

[Steven Robbins]

Control: tags 1066702 + pending



On Wed, 13 Mar 2024 13:08:23 +0100 Lucas Nussbaum  wrote:

> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

Uploaded new upstream version to experimental, which fixes this bug.

-Steve


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

Bug#1065779: libcdk5: FTBFS on arm{el,hf}: configure:7804:12: error: implicit declaration of function 'tgoto' [-Werror=implicit-function-declaration]

[Steven Robbins]

Control: tags 1065779 + pending

On Wednesday, March 13, 2024 5:53:11 A.M. CDT Thomas Dickey wrote:

> upgrading really is the simplest solution - not much depends on this,
> and nothing cares about the actual version:

I have uploaded the latest upstream to experimental, which should fix this.  
Unfortunately, the arm builds fail for an unrelated reason -- build-dep 
installability problems.

-Steve


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

Bug#986936: ITA: libcdk5 -- C-based curses widget library

[Steven Robbins]

Control: owner 986936 !

On Tue, 19 Jul 2022 13:02:08 +0200 "Jose G. López"  
wrote:
> owner 986936 !
> retitle 986936 ITA: libcdk5 -- C-based curses widget library
> thanks
> I intend to adopt it as I worked on it before but never uploaded it as
> maintainer in Debian. I have special affection for it because it was
> one of the first packages I worked with and learned.
> 

Hi again Jose,

I don't mean to take anything away from you, if you truly desire to maintain 
this package.  However, it's been over 18 months with no apparent action and 
emails to you over the last week have not been answered.  So I will 
tentatively conclude that you don't have the time for this package.  If that 
changes, do let me know and you can certainly change the maintainership.

For now, I will adopt this package and upload a new version to unblock this 
package and downstream dependencies.

Best,
-Steve


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

Bug#1065463: debootstrap can deal with native dpkg file replacement feature

[Steven Shiau]

On 3/5/2024 7:25 PM, Holger Levsen wrote:

On Tue, Mar 05, 2024 at 08:36:59AM +0800, Steven Shiau wrote:

debootstrap should be able to solve the libuuid1t64 dependency by installing
libuuid1 only.

just in case you are not aware, bootstrapping using either mmdebstrap or
cdebootstrap works atm. mmdebstrap is faster and mostly a drop-in replacement.
(same applies to cdebootstrap but its less faster :)

daily tests are available at:

https://jenkins.debian.net/job/reproducible_debootstrap_unstable/
https://jenkins.debian.net/job/reproducible_cdebootstrap_unstable/
https://jenkins.debian.net/job/reproducible_mmdebstrap_unstable/

Hi Holger,
Great. Thanks for this useful info.
We have patched Debian live-build and created a merger request to 
support mmdebostrap:

https://salsa.debian.org/live-team/live-build/-/merge_requests/343

Steven

--
Steven Shiau 
Public Key Server PGP Key ID: 4096R/163E3FB0
Fingerprint: EB1D D5BF 6F88 820B BCF5  356C 8E94 C9CD 163E 3FB0

Bug#1065787: 64-bit time_t transition: cargo needs manual intervention

[Steven Robbins]

On Tuesday, March 12, 2024 1:24:25 A.M. CDT Steve Langasek wrote:

> The quickest fix for this based on what we've done in Ubuntu is:
> 
> - unpack cargo and libstd-rust debs to the root via dpkg-deb -x
> - use equivs to mock up packages by these names with no dependencies and
>   install those
> - bootstrap
> - enjoy

Thanks!

I checked the build logs for cargo and noticed that most architectures have 
been built on the buildds.  All release arches except armel & armhf.  How is 
it that these two have build dep installability problems but others do not?

-Steve


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

Bug#1065787: 64-bit time_t transition: cargo needs manual intervention

[Steven Robbins]

Peter convincingly argues (details in bug) that manual intervention is needed 
for package "cargo":

On Sun, 10 Mar 2024 00:48:32 + Peter Michael Green  
wrote:

> This will require manual intervention to resolve, either through
> cross-building or through building manually in a hacked-up build
> environment.
> 
> I've certainly seen mention of rustc on #debian-devel recently,
> so I think the people handling the time_t transition are already
> aware of this.

I'm wondering if the time_t people or the rust people could comment on this?  
This build failure has a surprisingly (to me) long chain of casualties.  Is 
this an easy thing to fix or is going to take weeks?

Thanks,
-Steve


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

Bug#986936: ITA: libcdk5 -- C-based curses widget library

[Steven Robbins]

On Wednesday, March 6, 2024 7:42:55 P.M. CDT Steven Robbins wrote:
> On Tue, 19 Jul 2022 13:02:08 +0200 "Jose G. López" 
 
> > I intend to adopt it as I worked on it before but never uploaded it as
> > maintainer in Debian. I have special affection for it because it was
> > one of the first packages I worked with and learned.
> 
> Just wondering if you still plan to work on curses.  If so: it's failing to
> build on some platforms, so could really use help now!  :-)

This package has become somewhat important to me, since its failure to build 
is affecting packages that I maintain.  

I have worked on packaging the latest upstream version and it builds for me 
locally.  I'm not really wanting another package to maintain so if you can 
update this in the next short while, just let me know.  Otherwise, I can work 
on putting the new version into the archive.  Happy to co-maintain, or 
whatever you think best.

Regards,
-Steve



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

Bug#1065396: ghostscript: Coordinate uploads for German man page transfer

[Steven Robbins]

On Monday, March 4, 2024 11:14:37 A.M. CST Helge Kreutzmann wrote:
> Hello Steven,
> 
> Am Sun, Mar 03, 2024 at 10:25:45PM -0600 schrieb Steven Robbins:
> > Thanks for the note!
> > 
> > On Sun, 3 Mar 2024 19:59:28 + Helge Kreutzmann 

> > > I will then add
> > > Breaks: ghostscript (< > > Replaces: ghostscript (< > > 
> > > In my debian/control. I'm a bit lost about the correct version,
> > > though. So which version is best for "?"
> > 
> > I rarely deal with these situations, so I may be wrong, but
> > I would think the best version is the new one:  10.02.1~dfsg-4.
> 
> Ideally it is the first version which stopped shipping the German man
> pages. Maybe you can browse your git history? 

Git says 10.01.2~dfsg-1.


> > OK.  You titled the bug "coordinate uploads ...".  Do we need to do them
> > together - on the same day or something?
> 
> Well, this would be a good idea, to choose roughly the same day, to
> avoid uninstallable situations for people living on unstable or testing.
> 
> I'm intending to prepare the next upstream release (and then
> immediately the Debian release) on 2024-03-23.

OK.  Let me know when you do the upload and I'll do ghostscript immediately.

-Steve


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

Bug#1065463: debootstrap can deal with native dpkg file replacement feature

[Steven Shiau]

Package: debootstrap
Version: 1.0.134
Severity: wishlist

Dear Maintainer,

As mentioned here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065394#28
For the moment on Mar/5/2024 in the Debian Sid repository, libuuid1 
"Provides:

libuuid1t64 (= 2.39.3-9)", and an exact version of libuuid1t64 which
is not in repos. libuuid1 and libuuid1t64 have "Replaces:" on each other 
already.
debootstrap should be able to solve the libuuid1t64 dependency by 
installing libuuid1 only.

Otherwise now if the following command is run:
$ sudo debootstrap --verbose --arch=amd64 sid sid-chroot
The debootstrap will fail at this:

I: Extracting libunistring5...
I: Extracting libuuid1...
I: Extracting libuuid1t64...
E: Tried to extract package, but tar failed. Exit...

and the log shows:
$ tail sid-chroot/debootstrap/debootstrap.log
Saving to: 
‘sid-chroot//var/cache/apt/archives/partial/zlib1g_1%3a1.3.dfsg-3.1_amd64.deb’


 0K .. .. .. .. .. 58%  845K 0s
    50K .. .. .. .    100% 
2.39M=0.07s


2024-03-03 10:33:06 (1.13 MB/s) - 
‘sid-chroot//var/cache/apt/archives/partial/zlib1g_1%3a1.3.dfsg-3.1_amd64.deb’ 
saved [87580/87580]


tar: ./usr/lib/x86_64-linux-gnu/libuuid.so.1.3.0: Cannot open: File exists
tar: ./usr/lib/x86_64-linux-gnu/libuuid.so.1: Cannot create symlink to 
‘libuuid.so.1.3.0’: File exists

tar: Exiting with failure status due to previous errors

-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')

Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-18-amd64 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debootstrap depends on:
ii  wget  1.21.3-1+b2

Versions of packages debootstrap recommends:
ii  arch-test   0.20-1
ii  debian-archive-keyring  2023.3+deb12u1
ii  gnupg   2.2.40-1.1
ii  mount   2.38.1-5+b1

Versions of packages debootstrap suggests:
ii  binutils 2.40-2
pn  squid-deb-proxy-client   
ii  ubuntu-keyring [ubuntu-archive-keyring]  2020.06.17.1-1
ii  xz-utils 5.4.1-0.2
ii  zstd 1.5.4+dfsg2-5

-- no debconf information


--
Steven Shiau 
Public Key Server PGP Key ID: 4096R/163E3FB0
Fingerprint: EB1D D5BF 6F88 820B BCF5  356C 8E94 C9CD 163E 3FB0

--
Steven Shiau 
Public Key Server PGP Key ID: 4096R/163E3FB0
Fingerprint: EB1D D5BF 6F88 820B BCF5  356C 8E94 C9CD 163E 3FB0

Bug#870679: ghostscript: Annotate debian/conrol for DEB_BUILD_PROFILES=stage1

[Steven Robbins]

Control: tags -1 + moreinfo

Hello,

I'm not sure what is being requested.  

On Thu, 3 Aug 2017 18:51:10 -0700 Daniel Schepler  wrote:
> Source: ghostscript
> Version: 9.21~dfsg-1
> Severity: wishlist
> 
> It would be nice if the source package could be updated with build
> profile annotations for libcups2-dev  and libcupsimage2-dev
> .  

Those packages are generated from the "cups" source package.  Was this bug 
intended for cups?

> Of course, then you would probably either need to split
> off the cups driver into a separate package ghostscript-cups (though I
> don't know if it's even supported to build the driver as a plugin, as
> ghostscript-x support is).  Or otherwise, it would need to produce a
> ghostscript-stage1 package since it would have different binary
> contents from the full ghostscript package.
> -- 
> Daniel Schepler
> 
> 


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

Bug#1065396: ghostscript: Coordinate uploads for German man page transfer

[Steven Robbins]

Hello!

Thanks for the note!

On Sun, 3 Mar 2024 19:59:28 + Helge Kreutzmann  
wrote:
> Package: ghostscript
> Version: 10.0.0~dfsg-11+deb12u3
> Severity: normal
> 
> Hello Steve,
> ghostscript used to contain German man pages, however, they were not
> properly maintained. As detailed in [1] ghostscript removed the 
> German man pages from its git repository on January 4th 2023.
> 
> So the files are gone since Version 10.01.0rc1.
> 
> I imported them into manpages-de and will start shipping them with the
> next release.
> 
> As per transition rules [2] you will need to add 
> Breaks: manpages-l10n (<4.22) 
> in your debian/control.

OK.  Committed to git.  Will be uploaded as version 10.02.1~dfsg-4.

 
> I will then add
> Breaks: ghostscript (< Replaces: ghostscript (< 
> In my debian/control. I'm a bit lost about the correct version,
> though. So which version is best for "?"

I rarely deal with these situations, so I may be wrong, but
I would think the best version is the new one:  10.02.1~dfsg-4.


> I intend to upload around March 23 and I will provide a backport to
> stable (without these translations, of course).

OK.  You titled the bug "coordinate uploads ...".  Do we need to do them 
together - on the same day or something?

Regards,
-Steve


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

Bug#1065394: debootstrap Sid failed to run due to libuuid1t64 and libuuid1 coexist

[Steven Shiau]

Hi,
debootstrap Sid on amd64 failed to run due to libuuid1t64 2.39.3-6.1 and 
libuuid1 2.39.3-9 coexist:

debootstrap --verbose --arch=amd64 sid sid-chroot
...
I: Extracting libunistring5...
I: Extracting libuuid1...
I: Extracting libuuid1t64...
E: Tried to extract package, but tar failed. Exit...

Though libuuid1 2.39.3-9 from util-linux was released, the libuuid1t64 
2.39.3-6.1 still in the repository, therefore causing debootstrap fails.


Steven

--
Steven Shiau 
Public Key Server PGP Key ID: 4096R/163E3FB0
Fingerprint: EB1D D5BF 6F88 820B BCF5  356C 8E94 C9CD 163E 3FB0

Bug#612194: gs: Strange printouts with Nec P6 -- might be typo in necp2x.upp

[Steven Robbins]

Control: -1 tags + moreinfo

I'm having trouble understanding the content of this bug.

On Sat,  6 Sep 2003 12:54:55 +0200 (CEST) Nils Bokermann  
wrote:

> When using magicfilter with Nec P6 filter, a gs commandline with @necp2x.upp 
is 
> fired up. This file says (line 2)
> -sDEVICE=uniprint
> should read:
> -sDEVICE=necp6

Is the complaint about line two of the file /usr/share/ghostscript//
lib/necp2x.upp ?

 
> Was with version 5.5 of gs. 

Are you saying that version 5.5 had "-sDEVICE=necp6" on line 2?


Thanks,
-Steve


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

Bug#661589: [ghostscript] gs error: /usr/lib/cups/filter/pdftoraster failed --> error log attached

[Steven Robbins]

Control:  -1 tags + moreinfo

On Fri, 16 Mar 2012 17:43:25 -0300 ASD Consultoria 
 wrote:
> Em Tue, 28 Feb 2012 16:20:01 +0100
> "Didier 'OdyX' Raboud"  escreveu:
> 
> > b) once "locally" from the stable machine (that's the case I'm
> > interested in)
> 
> Attached file error.

I'm sorry that no action was taken 12 years ago.  

Unfortunately, there's not enough info in this bug for me to take action.
Can you confirm whether this remains an issue?
If so, can you provide an input file and ghostscript command(s) that 
demonstrate the issue?

Thanks,
-Steve




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

Bug#731140: ghostscript: on PDF files with embedded fonts, ps2pdf changes the way fonts are rendered

[Steven Robbins]

Control: tags -1 +moreinfo

On Mon, 2 Dec 2013 13:54:19 +0100 Vincent Lefevre  wrote:
> Package: ghostscript
> Version: 9.05~dfsg-8
> Severity: normal
> 
> ps2pdf should not change the embedded fonts except by optimizing them
> (e.g. compressing them), but a simple test shows that it changes the
> way fonts are rendered. I've attached 3 files.
> 
> font1.pdf is the original file (generated by pdflatex).
> font2.pdf is the file obtained with "ps2pdf font1.pdf font2.pdf".
> font.png shows the text of font1.pdf (left) and font2.pdf (right),
> as obtained with xpdf.

I have repeated the test with ghostscript 10.02.1 and I cannot see any 
difference (using xpdf, or using evince) between font1 and the output of 
ps2pdf.

I'm inclined to close the bug shortly, but let me know if you can still 
reproduce the issue.

Best,
-Steve


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

Bug#1063563: ghostscript: ps2epsi fails with Error: /undefined in /finddevice

[Steven Robbins]

Control: -1 tags + help confirmed

On Sun, 18 Feb 2024 14:10:37 +0100 Stephan Böttcher  wrote:
> 
> Tha attached ps file was made with [ ... ]


Thank you.  I can reproduce the ps2epsi failure.  I have no idea what is 
wrong.

-Steve







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

Bug#721137: ghostscript: ps2pdf produces bad pdf on x86_64 (unreadeable text)

[Steven Robbins]

I've just tested with ghostscript 10.02.1 and found the situation remains as 
described in 2015, below.  Specifically, I checked that:

* the four files attached in message #15 all render without issues using evince

* tp2A_scilab_N1.pdf renders fine with xpdf, but many warning are emitted on 
the console S(yntax Warning: Bad bounding box in Type 3 glyph)

* ps2pdf 10.02.1 produces a pdf file that again renders fine, but shows the 
same 
syntax warnings as noted above

* rendering to png (as below) works fine

-Steve

On Thu, 29 Oct 2015 17:17:50 +0100 (CET) whoami...@free.fr wrote:

> Secondly, the pdf viewers available in Jessie are doing a better job
> at displaying this test.pdf:
>   - Evince (or actually the underlying poppler library) is now displaying 
correctly
> this problematic pdf. Try for instance 'pdftocairo -png test.pdf 
test.png'.
>   - Xpdf is still displaying correctly these pdf, but still with the warning
> about "Bad bounding box in Type 3 glyph".
>   - I tried to use directly gs for rendering to png, and it works fine:
>  gs -dSAFER -dNOPAUSE -sDEVICE=png16m -dTextAlphaBits=4 -dBATCH -
dGraphicsAlphaBits=4 -dQUIET -r100 -sOutputFile=test.png test.pdf
>   - The only issue left is with the mupdf viewer (or its command-line tool 
mudraw).
> I've attached the png obtained from the original test.pdf via:
>  mudraw -o test.png test.pdf
> It looks exactly as the earlier faulty display (three black dots instead 
of
> the expected text) that was obtained via Wheezy's evince.
> 
> Anyway, I still think that ps2pdf is producing an erroneous pdf, and that 
the various
> pdf viewers are doing there best to overcome this issue. Indeed, as hinted 
by the
> xpdf warnings, the /FontBBox [0 0 1 -1] in test.pdf looks quite wrong.
> 


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

Bug#910605: ghostscript ships dangling symlink /usr/share/ghostscript/X.Y/Resource/CIDFSubst/DroidSansFallback.ttf

[Steven Robbins]

Hello,

I've recently adopted ghostscript, so I can't answer the direct question of 
why libgsN-common ships a dangling symlink.  I am curious what folks think of 
this.

It's not clear to me whether there are bad consequences of a dangling symlink.  
For example is it treated differently than a completely missing file?

The target of the link is shipped in package fonts-droid-fallback -- should 
the symlink be created there instead?

Other options?

Thanks,
-Steve


On Mon, 08 Oct 2018 17:59:12 +0200 Michael Prokop  wrote:
> Package: libgs9-common
> Version: 9.25~dfsg-2
> Severity: normal
> 
> Hi,
> 
> is there any specific reason why libgs9-common ships a symlink which
> is a dangling one/dead end until the fonts-droid-fallback package is
> installed?
> 
> , [ demo ]
> | root@buster-demo:~# ls -la /usr/share/ghostscript/9.25/Resource/CIDFSubst/
> | total 8
> | drwxr-xr-x  2 root root 4096 Oct  8 17:21 .
> | drwxr-xr-x 11 root root 4096 Oct  8 17:21 ..
> | lrwxrwxrwx  1 root root   58 Sep 15 14:18 DroidSansFallback.ttf -> 
../../../../fonts/truetype/droid/DroidSansFallbackFull.ttf
> | root@buster-demo:~# ls -la /usr/share/ghostscript/9.25/Resource/CIDFSubst/
DroidSansFallback.ttf
> | lrwxrwxrwx 1 root root 58 Sep 15 14:18 /usr/share/ghostscript/9.25/
Resource/CIDFSubst/DroidSansFallback.ttf -> ../../../../fonts/truetype/droid/
DroidSansFallbackFull.ttf
> | root@buster-demo:~# readlink -f /usr/share/ghostscript/9.25/Resource/
CIDFSubst/DroidSansFallback.ttf
> | root@buster-demo:~#
> |
> | root@buster-demo:~# apt-cache show libgs9-common | grep fonts-droid-
fallback
> | Recommends: fonts-droid-fallback
> `
> 
> JFTR, #613912 might be related.
> 
> regards,
> -mika-
> 
> 


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

Bug#942055: ghostscript in buster partly broken on armel?

[Steven Robbins]

On Wed, 05 Feb 2020 16:13:51 +0100 Jonas Smedegaard  wrote:

> > > I maintain the Ghostscript package, but am not skilled in the various 
> > > tools using Ghostscript.  It seems more sensible to me to first 
> > > investigate toolchain problems further back in the chain, where (I 
> > > assume) it is better known how to isolate the data forwarded down the 
> > > chain.
> > 
> > 
> > I guess this is what I did in previous message 33 ?
> 
> Ohh, indeed!  Great details and smells strongly of the bug being in 
> Ghostscript.  I am hereby re-re-re-assigning and reviving versions...

Dear submitter,

Can you advise whether this is still an issue?  I ran the attached foomatic 
file through gs on amd64 and it still works fine.  But I have no access to an 
armel machine.

Thanks,
-Steve


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

Bug#503191: pdfwrite: AutoRotatePages=/None ignored, PDF rotate

[Steven Robbins]

On Thu, 23 Oct 2008 12:31:07 +0200 martin f krafft  wrote:
> Package: ghostscript
> Version: 8.62.dfsg.1-3.1
> Severity: normal
> File: /usr/bin/gs
> 
> When I run
> 
>   gs -q -sDEVICE=pdfwrite -dAutoRotatePages=/None -sOutputFile='graphs/
snowball-sampling.pdf' - -c quit < graphs/snowball-sampling.eps
> 
> on the attached file, the PDF is rotated 90 degrees, despite
> -dAutoRotatePages=/None. This seems related to #131570 (see also
> http://tolstoy.newcastle.edu.au/R/devel/03b/0795.html).

I tested the supplied example on ghostscript 10.02.1.

The eps file displays "right side up" in landscape mode, while the converted 
PDF displays rotated but in portrait mode.  The PDF file displays the same as 
the EPS if you switch to landscape mode.

It's unclear to me whether this is a bug or expected behaviour.

Can you check and see if the latest ghostscript meets your expectations?  If 
not, then some additional details would be appreciated.

Best,
-Steve


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

Bug#1063563: ghostscript: ps2epsi fails with Error: /undefined in /finddevice

[Steven Robbins]

On Fri, 09 Feb 2024 16:08:00 +0100 Stephan Boettcher  wrote:
> Package: ghostscript
> Version: 10.02.1~dfsg-3
> Severity: normal
> 
> The version 10.0.0~dfsg-10 works and produces the expected output.
> 10.01.2~dfsg-1 works as well.
> 
> 10.02.1~dfsg-3 does not:
> 
> $ ps2epsi hvosc-doc_sch.ps hvosc-doc_sch.eps

It won't be possible to debug this unless you can supply an example  input 
file.  Could you attach one to this bug report?

Thanks,
-Steve


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

Bug#988817: (no subject)

[Steven Maddox]

As I've come to understand it... since fwupd is in main and it 
recommends a package not in main, then it violates policy 2.2.1


Since this directive is a 'must' I've changed the severity to 'serious' 
as per the meanings of those severity levels.

Bug#980049: fwupd: Should fwupd specify dbus as a dependency?

[Steven Maddox]

I can't help but feel this needs to be rethought.   

If I install the current Debian 12 via netinst and choose not to install 
'standard system utilities'... a choice many people take if they prefer 
to install their own set of utilities instead... and a choice which 
doesn't advertise any negative connotations for unchecking it...	


Then it means the debootstrap process that debian-installer did... won't 
install dbus (as it's only a recommends of systemd)... and dbus won't be 
installed from 'standard system utilities' either.	


From this point, there are two scenarios...

If you've got recommends enabled on your system...

Installing the fwupd package will automatically try to start the fwupmgr 
service and fail because the dbus package it just installed (because 
dbus is a recommends of fwupd) won't automatically start and stays 
inactive unless you active it or reboot.  This gives you an ugly **red 
error message** in the apt-get output of...


"dbus.service is not active, cannot reload."

If you've got recommends disabled on your system... (a perfectly valid 
scenario, but there are haters of this!)...


Installing the fwupd package will automatically try to start the fwupmgr 
service and fail because dbus isn't installed.  This gives you an ugly 
**red error message** in the apt-get output of...


"Failed to reload dbus.service: Unit dbus.service not found."

I know that some people just install fwupd to use the fwuptool manually 
which works just fine without fwupdmgr...


But unless this package is split into two (one for the fwupmgr service, 
one for fwupdtool), or unless it is reconfigured so it doesn't try to 
automatically start fwupmgr... then I can't see how dbus shouldn't be 
considered a depend for fwupd.


It literally can't perform one of its main functions, a function that is 
automatically started, and shows an error!.. without it!

Bug#790562: Ghostscript: File has unbalanced q/Q operators (too many Q's)

[Steven Robbins]

On Tue, 30 Jun 2015 09:17:06 +0100 supp...@compress-pdf.co.uk wrote:
> package: ghostscript
> version: 9.06~dfsg-2
> 
> When running ghostscript, the following errors are being generated in
> great quantity:
> stderr: "    File has unbalanced q/Q operators (too many Q's) "
> 
> resulting in log files filling the disk.
> 
> Additionally, kernel soft lockup warnings appear:
> kernel:[406101.560749] BUG: soft lockup - CPU#4 stuck for 31s! [gs:21647]
> 
> 
> Command being run is:
> 
> gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/screen
> -dNOPAUSE -dQUIET -dBandBufferSpace=5 -dBandSpace=10
> -dBATCH -sOutputFile='out.pdf' 'in.pdf'
> 
> 
> It may be related to this bug on the ghostscript bug tracker flagged as
> resolved:
> http://bugs.ghostscript.com/show_bug.cgi?id=694310

In the absence of an example file, I will assume you are correct that this is 
the upstream bug noted.  That fix is now in Debian, so I'll close this bug.
-Steve


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

Bug#704112: ghostscript: gs -dEPSCrop doesn't work

[Steven Robbins]

On Thu, 28 Mar 2013 02:21:25 +0100 Sebastien Desreux  wrote:

> I do realize that the PS file above is not an EPS. Yet this option also 
worked 
> for PS files with AFPL gs and then ESP gs. Besides, a search for "crop" on
>   http://ghostscript.com/doc/7.07/Use.htm
> yielded only the EPS case.
> 

It seems clear that the option EPSCrop is for EPS input, so this doesn't seem 
like a bug.  Though I sympathise that it may be an irritating change in 
behaviour if it did used to work previously.

-Steve



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

Bug#731164: ghostscript: ps2pdf makes highlighted/annotated text unreadable by poppler-based PDF viewers

[Steven Robbins]

On Saturday, January 6, 2024 11:58:56 A.M. CST Vincent Lefevre wrote:
> But all xpdf,
> zathura and atril have no issues with the file generated by the
> current ps2pdf. This confirms a good change in ghostscript.

Excellent!  Thanks for the additional testing and feedback!
-Steve




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

Bug#810080: ghostscript: Infinite loop filling server logs with "File has unbalanced q/Q operators"

[Steven Robbins]

tags -1 + moreinfo
thanks

On Wed, 06 Jan 2016 11:20:41 +0100 Stephan Grossberndt 
 wrote:
> Package: ghostscript
> Version: 9.06~dfsg-2+deb8u1

> * What led up to the situation?
> 
> "gs -o proper.pdf -sDEVICE=pdfwrite -dPDFSETTINGS=/prepress 
programmheft_2016.pdf" with http://www.naturpark-rheinland.de/
programmheft_2016.pdf leads to infinite output of " File has unbalanced q/Q 
operators (too many Q's) " to stderr

I'm sorry that there was no investigation in the last seven years.  
Unfortunately, the file referenced at the above URL is no longer available.  If 
you have a file that demonstrates the problem, can you please attach it to this 
bug?

Thank you,
-Steve




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

Bug#1052652: ghostscript: eps2write fails on test file

[Steven Robbins]

tags 1052652 upstream
forwarded 1052652 https://bugs.ghostscript.com/show_bug.cgi?id=707368
thanks


On Mon, 25 Sep 2023 20:05:27 +0200 Roland Rosenfeld  wrote:
> Package: ghostscript
> Version: 10.02.0~dfsg-2
> Severity: important
> 
> Dear Maintainer,
> 
> upgrading ghostscript from 10.01.2~dfsg-1 to 10.02.0~dfsg-2 triggers a
> regression in the testsuite of fig2dev.

Reproduced with ghostscript 10.02.1.

> By trial-and-error I found out, that removing the option
> "-sPageList=1" avoids the error, but this may result in other side
> effects in fig2dev, since the above commend only wants to convert the
> first page of the document.

Thanks!  This looks like the upstream bug https://bugs.ghostscript.com/
show_bug.cgi?id=707368

-Steve


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

Bug#370397: gs-common: Any chance of ps2pdf16?

[Steven Robbins]

On Sun, 04 Jun 2006 18:54:06 -0500 Ron Johnson  wrote:

> The PDF v1.6 spec has been out for 2 years, but ps2pdf is still "stuck"
> at v1.4.
> 
> Is this because there is nothing more to gain in the v1.5 & v1.6 specs
> in a blind ps-to-pdf converter?

I don't know the answer to that question.  I just wanted to provide one 
breadcrumb into the upstream bug tracker.  It's an unrelated issue, but one 
comment reads:

Ken Sharp 2017-03-20 08:14:30 UTC
(In reply to Ulrich Windl from comment #42)

> Wouldn't the user benefit from some warning being emitted?


My inclination is to scrap the script(s), frankly. They've always been a pain.

 
> From the man page (ps2pdf):


We don't produce or maintain man pages for Ghostscript.

https://bugs.ghostscript.com/show_bug.cgi?id=695847#c43


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

Bug#564546: ghostscript: inferior image scaling

[Steven Robbins]

tags 564546 + moreinfo
thanks

Hello,

Apologies for the massive delay in responding!

On Sat, 09 Jan 2010 23:45:30 -0500 John Lindgren  
wrote:
> Package: ghostscript
> Version: 8.70~dfsg-2
> Severity: wishlist

It's now 13 years on, so I have to first ask whether this issue still remains?

> A PDF file consisting of a 300 DPI page-size image, generated by
> printing from Open Office Draw to the CUPS PDF converter, is poorly
> rendered by both Evince and the GIMP, so I'm making a guess that the
> problem lies in Ghostscript.  It seems to be downsampling images by
> skipping pixels rather than averaging them.  I've attached snippets of
> the image (a) at its original 300 DPI, (b) scaled poorly to 100 DPI by
> Ghostscript, and (c) scaled well to 100 DPI by the GIMP.

If the issue does remain, can you provide a pdf file and command line that 
demonstrates the problem?

Thanks,
-Steve


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

Bug#379901: gs-gpl: `ps2pdf' fails to embed URW++ fonts from `gsfonts'

[Steven Robbins]

On Mon, 7 Feb 2011 13:09:45 -0600 Jonathan Nieder  wrote:
> reopen 379901
> submitter 379901 !
> severity 379901 normal
> tags 379901 = upstream moreinfo
> done
> 
> Ludovic Courtès wrote:
> 
> > This is a 5-year old bug report, I changed email addresses in the
> > meantime (congrats for finding a new one), and I even changed distros.
> > :-)
> 
> Thanks for an update.  I'll take the bug. :)

Can you attach an example file for this issue please?

Thanks,
-Steve



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

Bug#469761: epstool: crashes

[Steven Robbins]

On Tue, 16 Sep 2014 01:06:55 +0200 Philip Rinn  wrote:
> reassign 469761 ghostscript
> retitle 469761 file crashes ps2pdf/epstool/ghostscript
> 
> thanks
> 
> Hi,
> 
> I think it's actually a bug in ghostscript as ps2pdf throws the same error 
as epstool.

Tested with ghostscript 10.02.1 and the issue remains:

$ ps2pdf tmp.eps 
Error: /typecheck in --aload--
Operand stack:   --nostringval--
Execution stack:   %interp_exit   .runexec2   --nostringval--   --
nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --
nostringval--   --nostringval--   false   1   %stopped_push   1944   1   3   
%oparray_pop   1943   1   3   %oparray_pop   1942   1   3   %oparray_pop   --
nostringval--   1928   1   3   %oparray_pop   1801   1   3   %oparray_pop   --
nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--  
 
--nostringval--   2   %stopped_push   --nostringval--   --nostringval--
Dictionary stack:   --dict:748/1123(ro)(G)--   --dict:0/20(G)--   --dict:
111/200(L)--
Current allocation mode is local
Current file position is 291380
GPL Ghostscript 10.02.1: Unrecoverable error, exit code 1



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

Bug#1059883: "reply to" links should include message body

[Steven Robbins]

Package: lists.debian.org
Severity: normal

When reading lists via the web archive, there are three links below each
message that allow a reply.  The reply contains the Subject and In-Reply-To
headers, but the message body is blank.

In contrast, the BTS archives provide the body of the message being replied 
to, escaped with leading "> " on each line.  That would be nice to add to the 
list archives.


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

Bug#1022718: O: ghostscript -- interpreter for the PostScript language and for PDF

[Steven Robbins]

retitle 1022718 'ITA: ghostscript -- interpreter for the PostScript language 
and for PDF'
owner  1022718 s...@debian.org
done 1036869


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

Bug#1036869: O: ghostscript -- interpreter for the PostScript language and for PDF

[Steven Robbins]

On Mon, 24 Oct 2022 15:17:20 +0200 Jonas Smedegaard  wrote:

> I have orphaned the ghostscript package, due to lack of time.

I'm willing to take on -- and hopefully, share -- the ghostscript maintenance.
If anyone wants to team up, let me know!

-Steve



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

Bug#1057344: libgmp10: major formatted output function bug with %c and the value 0

[Steven Robbins]

severity 1057344 normal
thanks


On Sun, 3 Dec 2023 21:10:39 +0100 Vincent Lefevre  wrote:
> Package: libgmp10
> Version: 2:6.2.1+dfsg1-1.1
> Severity: grave
> Tags: security upstream
> Justification: user security hole

I understand the bug may have severe consequences but it doesn't appear to 
rise to the level of grave in my opinion.  

-Steve





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

Bug#1051939: ubpm_1.9.0+20230923-1_amd64.changes REJECTED

[Steven Robbins]

Hi,

Re-uploaded to NEW with requested changes.

On Thursday, October 26, 2023 12:37:25 P.M. CST Thorsten Alteholz wrote:
> Hi Steve,
> 
> On 26.10.23 05:23, Steven Robbins wrote:
> > On Monday, October 23, 2023 1:00:09 P.M. CDT Thorsten Alteholz wrote:
> >> Hi,
> >> 
> >> please ask upstream to add all licenses of embedded stuff like
> >> ./sources/plugins/shared/hidapi
> > 
> > Could you expand on this request?  Each file notes "At the discretion of
> > the user of this library,  this software may be licensed under the terms
> > of the GNU General Public License v3, a BSD-Style license, ..."
> 
> yes, but the sentence goes on: "..., or the original HIDAPI license as
> outlined in the LICENSE.txt,
> LICENSE-gpl3.txt, LICENSE-bsd.txt, and LICENSE-orig.txt"
> 
> The GPL is ok, but the BSD-Style license is not at all unambiguous and
> what is the contents of LICENSE.txt and LICENSE-orig.txt?
> They should be "located at the root of the source distribution.", but
> they are not, hence my request.

Added the four licenses files in sources/plugins/shared/hidapi:
LICENSE-bsd.txt  LICENSE-gpl3.txt  LICENSE-orig.txt  LICENSE.txt


Regarding the PDF files:
> > Sorry, that is a clear miss on my part.  I will clarify the license or
> > remove these before re-uploading.

PDF files have been removed.

-Steve


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

Bug#1056216: clinfo: Info Center...Graphics...OpenCL requires clinfo. Debian12 didn't install it.

[Steven Friedrich]

Package: clinfo
Severity: normal
X-Debbugs-Cc: freebsdlouisvi...@gmail.com

Dear Maintainer,



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

Kernel: Linux 6.1.0-13-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 clinfo depends on:
ii  libc62.36-9+deb12u3
ii  ocl-icd-libopencl1 [libopencl1]  2.3.1-1

clinfo recommends no packages.

clinfo suggests no packages.

Bug#1056215: vulkan-tools: vulkaninfo tool can't be installed

[Steven Friedrich]

Package: vulkan-tools
Severity: important

Dear Maintainer,

Vulcan Info Center missing vulkaninfo, apt can't find package.

-- System Information:
Debian Release: 12.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')

Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-13-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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

Bug#1055163: gnome-control-center: Intel Management Engine disabled in BIOS but reporting out-of-date (active)

[Steven Jay Cohen]

Package: gnome-control-center
Version: 1:45.1-1
Severity: normal
X-Debbugs-Cc: steven.jay.co...@gmail.com

Dear Maintainer,

Gnome-Control-Center > Privacy > Device Security

Security Events:
Intel Management Engine Version
The Intel Management Engine controls device components and needs to have a
recent version to avoid security issues.

I booted into the BIOS and found that IME was already disabled and has been
since before the original Linux Install on this device.

SUGGESTION:
Can IME state be detected?
If so, is this still an issue?
If it is not an issue, then it should not be reported or it should be reported
differently and not treated as a Security Event Failure.

Disabling IME reports as LOCKED (see below). Which is why a valid IME version
is not being reported back.

So, if both IME Mode and IME Override report back Pass(Locked) and IME Version
reports back (Not Valid) then IME is Disabled, right?

Device Security Report
==

Report details
  Date generated:  2023-11-01 08:28:16
  fwupd version:   1.9.6

System details
  Hardware model:  Dell Inc. Latitude 7210
2-in-1
  Processor:   Intel(R) Core(TM) i7-10610U
CPU @ 1.80GHz
  OS:  Debian GNU/Linux trixie/sid
  Security level:  HSI:0! (v1.9.6)

HSI-1 Tests
  Firmware BIOS Region:Pass (Locked)
  UEFI Platform Key:   Pass (Valid)
  UEFI Bootservice Variables:  Pass (Locked)
  MEI Key Manifest:Pass (Valid)
  TPM v2.0:  ! Fail (Not Found)
  Firmware Write Protection Lock:  Pass (Enabled)
  Platform Debugging:  Pass (Not Enabled)
  Intel Management Engine Manufacturing Mode:  Pass (Locked)
  UEFI Secure Boot:Pass (Enabled)
  BIOS Firmware updates:   Pass (Enabled)
  Firmware Write Protection:   Pass (Not Enabled)
  Intel Management Engine Override:Pass (Locked)
  Intel Management Engine Version:   ! Fail (Not Valid)

HSI-2 Tests
  Platform Debugging:  Pass (Locked)
  Intel BootGuard ACM Protected:   Pass (Valid)
  IOMMU Protection:Pass (Enabled)
  Intel BootGuard Fuse:Pass (Valid)
  Intel GDS Mitigation:Pass (Enabled)
  BIOS Rollback Protection:  ! Fail (Not Enabled)
  Intel BootGuard Verified Boot:   Pass (Valid)
  Intel BootGuard: Pass (Enabled)

HSI-3 Tests
  Intel CET: ! Fail (Not Supported)
  Intel BootGuard Error Policy:Pass (Valid)
  Pre-boot DMA Protection: Pass (Enabled)
  Suspend To RAM:  Pass (Not Enabled)
  Suspend To Idle: Pass (Enabled)

HSI-4 Tests
  Encrypted RAM: ! Fail (Not Supported)
  Intel SMAP:  Pass (Enabled)

Runtime Tests
  Firmware Updater Verification:   Pass (Not Tainted)
  Linux Swap:! Fail (Not Encrypted)
  Linux Kernel Lockdown:   Pass (Enabled)
  Linux Kernel Verification:   Pass (Not Tainted)

Host security events
  2022-07-05 18:46:50   Intel Management Engine Versi! Fail (Valid → Not Valid)

For information on the contents of this report, see
https://fwupd.github.io/hsi.html


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 gnome-control-center depends on:
ii  accountsservice   23.13.9-4
ii  apg   2.2.3.dfsg.1-5+b2
ii  colord1.4.6-3
ii  desktop-base  12.0.6+nmu1
ii  desktop-file-utils0.26-1
ii  gnome-control-center-data 1:45.1-1
ii  gnome-desktop3-data   44.0-2
ii  gnome-settings-daemon 45.0-1
ii  gsettings-desktop-schemas 45.0-1
ii  libaccountsservice0   23.13.9-4
ii  libadwaita-1-01.4.0-1
ii  libc6 2.37-12
ii  libcairo2 1.18.0-1
ii  libcolord-gtk4-1  0.3.0-4
ii  libcolord21.4.6-3
ii  libcups2  2.4.7-1
ii  

Bug#1051939: ubpm_1.9.0+20230923-1_amd64.changes REJECTED

[Steven Robbins]

On Monday, October 23, 2023 1:00:09 P.M. CDT Thorsten Alteholz wrote:
> Hi,
> 
> please ask upstream to add all licenses of embedded stuff like
> ./sources/plugins/shared/hidapi 

Could you expand on this request?  Each file notes "At the discretion of the 
user of this library,  this software may be licensed under the terms of the 
GNU General Public License v3, a BSD-Style license, ..."  The debian/copyright 
specifies GPL-3:

Files: sources/plugins/shared/hidapi/*
Copyright: 2022, 2023 libusb/hidapi Team
License: GPL-3

What are you asking to be added?

> As upstream didn't wrote the PDFs, please
> add their licenses as well. I doubt that Debian is allowed to distribute
> them but I am open to conviction.

Sorry, that is a clear miss on my part.  I will clarify the license or remove 
these before re-uploading.

Best,
-Steve


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

Bug#1015809: 1015809: isc-dhcp-client: DHCPv6 doesn't work on ppp interface, got `Unsupported device type` error

[Steven Haigh]

I don't run Debian on that system anymore due to other issues I came 
across - however, if I can extract the dhclient binary, I can probably 
test that on my current setup. That was my workaround using the Fedora 
dhclient binary for a while on the Debian install.

--
Steven Haigh

 net...@crc.id.au <mailto:net...@crc.id.au>
 https://crc.id.au <https://www.crc.id.au/>

On Mon, Oct 23 2023 at 10:00:20 -0300, Santiago Ruano Rincón 
 wrote:

Hi,

El 15/09/23 a las 22:40, Steven Haigh escribió:
 I'd suggest that even if nothing else, the package is updated with 
the same
 patches that Fedora have done - just to make the functionality the 
same - ie

 it actually works.

 I know IPv6-PD isn't really wide-spread, but its enough that there 
should be

 at least one functional method to do it within Debian.


Regarding IPv6-PD in stable, I am preparing an upload, but I am unable
to actually test it. Are you able to give it a try?

You can use the repo described here:
<https://debian.pages.debian.net/-/isc-dhcp/-/jobs/4842324/artifacts/aptly/index.html>

Cheers,

 -- Santiago

Bug#1053502: mailman3-web: Package failed to install during upgrade from Debian 11 to 12

[Steven Verhulst]

Hello Pierre-Elliot,

Here is the log you requested.

Kind regards,

Steven Verhulst
SISC (Shared ICT Services Centre) - SoftWeb
[M] sverhu...@vub.be<mailto:sverhu...@vub.be>


From: Pierre-Elliott Bécue
Sent: Friday, October 06, 2023 15:07
To: Steven Verhulst
Cc: 1053...@bugs.debian.org
Subject: Re: Bug#1053502: mailman3-web: Package failed to install during 
upgrade from Debian 11 to 12

Please keep the bug report CC-ed.

Steven Verhulst  wrote on 06/10/2023 at 13:16:09+0200:

> Hi,
>
>
>
> /etc/mysql/debian.cnf is a config file auto generated by some debian scripts.
>
> It contains host / user information for mysql connection.
>
> According to the contents this file is deprecated and should no longer be 
> used:
>
>
>
> # THIS FILE IS OBSOLETE. STOP USING IT IF POSSIBLE.
>
> # This file exists only for backwards compatibility for
>
> # tools that run '--defaults-file=/etc/mysql/debian.cnf'
>
> # and have root level access to the local filesystem.
>
> # With those permissions one can run 'mariadb' directly
>
> # anyway thanks to unix socket authentication and hence
>
> # this file is useless. See package README for more info.
>
> # THIS FILE WILL BE REMOVED IN A FUTURE DEBIAN RELEASE.
>
>
>
>
>
> “sed: -e expression #2, char 82: unterminated `s' command”
>
> Makes me believe that there is an issue with with one the sed
> expression in the post-installation script.

Yes, I am aware of your beliefs, and they're probably founded, but to be
able to dig in I need some context.

If you did not fix manually the issue, could you add "set -x" at the
beginning of /var/lib/dpkg/info/mailman3-web.postinst script and run a
dpkg --configure mailman3-web and give me the output?

If some passwords fall in the output, of course feel free to censor
them.

--
PEB
Determining localhost credentials from /etc/mysql/debian.cnf: failed (hosts not 
equal).
+ . /usr/share/debconf/confmodule
+ [ ! 1 ]
+ [ -z  ]
+ exec
+ [  ]
+ exec
+ DEBCONF_REDIR=1
+ export DEBCONF_REDIR
+ . /usr/share/dbconfig-common/dpkg/postinst
+ dbc_dbfile_owner=www-data:www-data
+ dbc_dbfile_perms=0640
+ dbc_go mailman3-web configure 0+20200530-2.1
+ local importing_from_non_dbc upgrading reconfiguring f tsubstfile 
upgrades_pending dbc_dumpfile _dbc_asuser reinstall nowtime need_adminpw 
_tmp_result
+ . /usr/share/dbconfig-common/dpkg/common
+ . /usr/share/dbconfig-common/internal/common
+ [  ]
+ _dbc_logfile=/var/log/dbconfig-common/dbc.log
+ _dbc_debug (postinst) dbc_go() mailman3-web configure 0+20200530-2.1
+ [  ]
+ dbc_no_thanks
+ local no_thanks_status
+ dpkg-query -W -f=${db:Status-Want} dbconfig-no-thanks
+ no_thanks_status=unknown
+ [ unknown = install ]
+ [ unknown = hold ]
+ return 1
+ dbc_config mailman3-web configure 0+20200530-2.1
+ _dbc_debug dbc_config() mailman3-web configure 0+20200530-2.1
+ [  ]
+ dbc_share=/usr/share/dbconfig-common
+ dbc_package=mailman3-web
+ echo mailman3-web
+ cut -d_ -f1
+ dbc_basepackage=mailman3-web
+ dbc_command=configure
+ dbc_oldversion=0+20200530-2.1
+ _dbc_sanity_check package command
+ [ 2 -ne 0 ]
+ [ -z mailman3-web ]
+ shift
+ [ 1 -ne 0 ]
+ [ -z configure ]
+ shift
+ [ 0 -ne 0 ]
+ dbc_confdir=/etc/dbconfig-common
+ dbc_globalconfig=/etc/dbconfig-common/config
+ dbc_packageconfig=/etc/dbconfig-common/mailman3-web.conf
+ dbc_standard_templates=database-type dbconfig-install dbconfig-upgrade 
dbconfig-remove dbconfig-reinstall password-confirm app-password-confirm purge 
upgrade-backup passwords-do-not-match install-error upgrade-error remove-error 
internal/reconfiguring internal/skip-preseed missing-db-package-error
+ dbc_mysql_templates=mysql/authplugin mysql/method remote/host remote/newhost 
mysql/app-pass mysql/admin-user mysql/admin-pass remote/port db/dbname 
db/app-user
+ dbc_pgsql_templates=pgsql/method remote/host remote/newhost pgsql/app-pass 
pgsql/admin-user pgsql/admin-pass remote/port pgsql/authmethod-admin 
pgsql/authmethod-user pgsql/changeconf pgsql/manualconf db/dbname db/app-user 
pgsql/no-empty-passwords
+ dbc_sqlite_templates=db/dbname db/basepath
+ dbc_authenticated_dbtypes=mysql pgsql
+ dbc_remote_dbtypes=mysql pgsql
+ dbc_fs_dbtypes=sqlite sqlite3
+ [ -f /etc/dbconfig-common/config ]
+ . /etc/dbconfig-common/config
+ dbc_remember_admin_pass=false
+ dbc_remote_questions_default=false
+ [ !  ]
+ dbc_prio_low=low
+ [ !  ]
+ dbc_prio_medium=medium
+ [ !  ]
+ dbc_prio_high=high
+ [ !  ]
+ dbc_prio_critical=critical
+ [ false = true ]
+ dbc_remote_questions_priority=low
+ dbc_default_pgsql_authmethod_admin=ident
+ dbc_set_dbtype_defaults
+ local happy supported_dbtypes comma
+ _dbc_debug dbc_set_dbtype_defaults() 
+ [  ]
+ [  ]
+ [  ]
+ dbc_default_basepath=
+ dbc_db_installed_cmd=dbc__db_installed
+ dbc_register_templates=database-type dbconfig-install dbconfig-upgrade 
dbconfig-remove dbconfig-reinstall password-confirm app

Bug#1053374: qgnomeplatform-qt5 fails to style window titlebar buttons

[Steven Jay Cohen]

> Just to clarify: This is just the window titlebars ? Does the "dark"
> mode still work for you ?

Correct, just the titlebars. The Dark Mode still works.

The workaround I found was not needed previously and might provide a clue?

WORKAROUND:
Add the following line to ~/.profile:
export QT_QPA_PLATFORM=xcb

On Wed, Oct 11, 2023 at 4:25 AM Matthias Geiger 
wrote:

> On 09.10.23 18:55, Matthias Geiger wrote:
> > On Mon, 02 Oct 2023 16:27:28 -0400 Steven Jay Cohen
> >  wrote:
> > > Package: qgnomeplatform-qt5
> > > Version: 0.9.2-1
> > > Severity: important
> > > X-Debbugs-Cc: steven.jay.co...@gmail.com
> > >
> > > Dear Maintainer,
> > >
> > > * What led up to the situation?
> > > Upgraded 1 computer from Stable (Bookworm) to Testing (Trixie).
> > >
> > > * What exactly did you do (or not do) that was effective (or
> > > ineffective)?
> > > Opened OcenAudio (ocenaudio.com) which had been properly styled when
> > running
> > > Stable.
> > >
> > > * What was the outcome of this action?
> > > OcenAudio displays KDE-like titlebar buttons.
> > >
> > > * What outcome did you expect instead?
> > > OcenAudio should display Gnome-like (Adwaita) titlebar buttons like
> > it does
> > > when running Stable.
> > >
> > >
> > > -- System Information:
> > > Debian Release: trixie/sid
> > > APT prefers testing
> > > APT policy: (500, 'testing')
> > > Architecture: amd64 (x86_64)
> > > Foreign Architectures: i386
> > >
> > > Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
> > > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 qgnomeplatform-qt5 depends on:
> > > ii libadwaitaqt1 1.4.2-3
> > > ii libc6 2.37-10
> > > ii libgcc-s1 13.2.0-4
> > > ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1
> > > ii libglib2.0-0 2.78.0-2
> > > ii libgtk-3-0 3.24.38-5
> > > ii libpango-1.0-0 1.51.0+ds-2
> > > ii libqt5core5a [qtbase-abi-5-15-10] 5.15.10+dfsg-3
> > > ii libqt5dbus5 5.15.10+dfsg-3
> > > ii libqt5gui5 5.15.10+dfsg-3
> > > ii libqt5quickcontrols2-5 5.15.10+dfsg-2
> > > ii libqt5waylandclient5 [qtwayland-client-abi-5-15-10] 5.15.10-2
> > > ii libqt5widgets5 5.15.10+dfsg-3
> > > ii libstdc++6 13.2.0-4
> > >
> > > qgnomeplatform-qt5 recommends no packages.
> > >
> > > qgnomeplatform-qt5 suggests no packages.
> > >
> > > -- no debconf information
> > >
> >
> > >
> >
> > Hi Steven.
> >
> > Just to clarify: This is just the window titlebars ? Does the "dark"
> > mode still work for you ?
> >
> > I suspect upstream dropped the titlebar support in favour of
> > qadwaita-decorations [0]. fwiw, I started packaging it, and my local
> > package restores titlebars for me.
> >
> > Enabling both features at the same time works. I'll see that I'll
> > upload it soon.
> >
> > [0] https://github.com/FedoraQt/QAdwaitaDecorations
> >
> > best,
> forgot to cc the submitter.
>
> --
> Matthias Geiger 
> Debian Maintainer
> "Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg
>
>

Bug#1053502: mailman3-web: Package failed to install during upgrade from Debian 11 to 12

[Steven Verhulst]

Package: mailman3-web
Version: 0+20200530-2.1
Severity: important

Dear Maintainer,

When we upgraded our test mailingserver from Debian 11 to 12 we noticed the 
following error:

Setting up mailman3-web (0+20200530-2.1) ...
Determining localhost credentials from /etc/mysql/debian.cnf: failed (hosts not 
equal).
dbconfig-common: writing config to /etc/dbconfig-common/mailman3-web.conf
dbconfig-common: flushing administrative password
sed: -e expression #2, char 82: unterminated `s' command
dpkg: error processing package mailman3-web (--configure):
installed mailman3-web package post-installation script subprocess returned 
error exit status 1

>From what I understand there seems to be an issue with the post-installation 
>script.

Since the post-installation script did not run it left us with a broken 
listserver.
Further it is not possible to use APT to update packages as it keep warning 
about mailman3-web package being broken.

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

Kernel: Linux 6.1.0-12-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 mailman3-web depends on:
ii  dbconfig-sqlite3   2.0.24
ii  debconf [debconf-2.0]  1.5.82
ii  init-system-helpers1.65.2
ii  lsb-base   11.6
ii  python33.11.2-1+b1
ii  python3-django-hyperkitty  1.3.7-1
ii  python3-django-postorius   1.3.8-3
ii  python3-mysqldb1.4.6-2+b1
ii  python3-psycopg2   2.9.5-1+b1
ii  python3-whoosh 2.7.4+git6-g9134ad92-7
ii  sysvinit-utils [lsb-base]  3.06-4
ii  ucf3.0043+nmu1
ii  uwsgi-core 2.0.21-5.1
ii  uwsgi-plugin-python3   2.0.21-5.1

Versions of packages mailman3-web recommends:
ii  libapache2-mod-proxy-uwsgi  2.4.57-2

Versions of packages mailman3-web suggests:
ii  mariadb-server [virtual-mysql-server]  1:10.11.3-1

-- Configuration Files:
/etc/mailman3/apache.conf changed [not included]
/etc/mailman3/uwsgi.ini changed [not included]

-- debconf information excluded

Bug#1053374: qgnomeplatform-qt5 fails to style window titlebar buttons

[Steven Jay Cohen]

Package: qgnomeplatform-qt5
Version: 0.9.2-1
Severity: important
X-Debbugs-Cc: steven.jay.co...@gmail.com

Dear Maintainer,

   * What led up to the situation?
Upgraded 1 computer from Stable (Bookworm) to Testing (Trixie).

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Opened OcenAudio (ocenaudio.com) which had been properly styled when running
Stable.

   * What was the outcome of this action?
OcenAudio displays KDE-like titlebar buttons.

   * What outcome did you expect instead?
OcenAudio should display Gnome-like (Adwaita) titlebar buttons like it does
when running Stable.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 qgnomeplatform-qt5 depends on:
ii  libadwaitaqt11.4.2-3
ii  libc62.37-10
ii  libgcc-s113.2.0-4
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.78.0-2
ii  libgtk-3-0   3.24.38-5
ii  libpango-1.0-0   1.51.0+ds-2
ii  libqt5core5a [qtbase-abi-5-15-10]5.15.10+dfsg-3
ii  libqt5dbus5  5.15.10+dfsg-3
ii  libqt5gui5   5.15.10+dfsg-3
ii  libqt5quickcontrols2-5   5.15.10+dfsg-2
ii  libqt5waylandclient5 [qtwayland-client-abi-5-15-10]  5.15.10-2
ii  libqt5widgets5   5.15.10+dfsg-3
ii  libstdc++6   13.2.0-4

qgnomeplatform-qt5 recommends no packages.

qgnomeplatform-qt5 suggests no packages.

-- no debconf information

Bug#1039529: applied patch to ITK

[Steven Robbins]

Hi,

Just FYI: I applied the suggested patch  (thanks Flavien!) to ITK.  Let me 
know if "sight" now builds.

-Steve


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

Bug#1015809: 1015809: isc-dhcp-client: DHCPv6 doesn't work on ppp interface, got `Unsupported device type` error

[Steven Haigh]

I'd suggest that even if nothing else, the package is updated with the 
same patches that Fedora have done - just to make the functionality the 
same - ie it actually works.


I know IPv6-PD isn't really wide-spread, but its enough that there 
should be at least one functional method to do it within Debian.


At that point, you're right - it'll probably not get much attention 
again afterwards.

--
Steven Haigh

 net...@crc.id.au <mailto:net...@crc.id.au>
 https://crc.id.au <https://www.crc.id.au/>

On Fri, Sep 15 2023 at 13:02:44 +0530, Santiago Ruano Rincón 
 wrote:
On Sun, 23 Jul 2023 12:45:34 +1000 Steven Haigh <mailto:net...@crc.id.au>> wrote:

 Ok, so after a day of messing around with Debian 12, it looks like
 without these patches applied, there is no way to get a IPv6 PD 
working

 with a PPPoE connection. Given the majority of ISPs in Australia use
 PPPoE as their connection method, this is a much bigger issue in 
this

 country than where the maintainers of this package live.

 wide-dhcpv6-client doesn't seem to interpret the reply from the ISP 
as

 a valid one.

 dibbler-client binds to the wrong LL address and fails to open a 
socket.


 Copying the dhclient binary from a Fedora 38 install and using that
 works perfectly - which is using the Fedora patches for dhclient 
v4.4.3.


 The current, functioning patch from Fedora is here:
 
<<https://src.fedoraproject.org/rpms/dhcp/blob/rawhide/f/0013-DHCPv6-over-PPP-support-626514.patch>>


 How are we able to fix this properly instead of a 'copy the binary 
from

 Fedora' type fix?


Sorry, I really missed this bug report. That said, since the EOL of
isc-dhcp-server, I reduced the priority given to isc-dhcp.

If isc-dhcp is that broken for .au, I could consider a stable update,
after this has been solved in unstable and confirmed doesn't break
anything.

Cheers,

 -- Santiago

Bug#1051939: ITP: ubpm - Universal Blood Pressure Manager

[Steven Robbins]

Package: wnpp
Severity: wishlist
Owner: "Steve M. Robbins" 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-...@lists.debian.org

* Package name: ubpm
  Version : 1.9.0
  Upstream Contact: Thomas Löwe 
* URL : https://codeberg.org/LazyT/ubpm
* License : GPL v3
  Programming Lang: C++
  Description : Universal Blood Pressure Manager

The UBPM manages blood pressure readings, imported directly from supported
devices,
from files (CSV, JSON, XML, SQL), or entered manually.  Readings may be viewed,
printed, or mailed as a chart, table, or statistics.

Features:
  * export data to CSV, JSON, XML, SQL or PDF format
  * migrate data from vendor software
  * analyze data via SQL queries
  * plugin interface for blood pressure monitors with a computer interface
(USB, Bluetooth)

My intention is to maintain this under the Debian-med umbrella
https://salsa.debian.org/med-team

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

Bug#1042376: Digikam with illegal instruction on an AMD Athlon II.

[Steven Robbins]

On Sunday, August 27, 2023 12:43:31 P.M. CDT Karine Crèvecœur wrote:


>   (gdb) disassemble
>…
>0x76cc20e8 <+136>:   movaps %xmm8,%xmm4
>0x76cc20ec <+140>:   mov%edx,-0x4c(%rsp)
>0x76cc20f0 <+144>:   mov0x38(%r9),%rdx
>0x76cc20f4 <+148>:   mulss  %xmm5,%xmm4
>0x76cc20f8 <+152>:   movss  0x3c(%r9),%xmm10
>0x76cc20fe <+158>:   movq   %r10,%xmm7
> => 0x76cc2103 <+163>:   extractps $0x3,%xmm12,%r11d
>0x76cc210a <+170>:   mov%rdx,%r15
>0x76cc210d <+173>:   mov0x28(%rax),%rdx
>0x76cc2111 <+177>:   movshdup %xmm7,%xmm7
>0x76cc2115 <+181>:   extractps $0x2,%xmm12,%edi
>0x76cc211c <+188>:   mulss  %xmm6,%xmm2
>0x76cc2120 <+192>:   movq   %rdx,%xmm15
>0x76cc2125 <+197>:   mov%rdx,-0x40(%rsp)
>…
> 
> The instruction that leads to crash seems to be "extractps".According
> to  it is an instruction
> related to SSE4.1.

Thank you!  That is exactly what I needed to know.  

So it is clear that some folks need a build with SSE4 disabled.  But SSE2 is 
supported on the machines of you and the original reporter so I'll try first 
with SSE2 but not SSE4.

The remaining issue is: I need to figure a way to build two binary packages 
from the source.  The other alternative is to disable SSE4 for everyone but I 
have no idea what performance impact that might have.

Regards,
-Steve


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

Bug#1049952: csh: maintained by ubuntu-devel-disc...@lists.ubuntu.com

[Steven Robbins]

On Thu, 17 Aug 2023 11:34:56 +0200 Lucas Nussbaum  wrote:
> Source: csh
> Version: 20110502-7
> Severity: serious

Is this really a serious enough issue to warrant removal from Debian?

> 
> Hi,
> 
> this package is maintained by ubuntu-devel-disc...@lists.ubuntu.com,
> which is not a suitable contact point for Debian packages maintenance
> according to https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
> 
> This is most likely due to generating the source package on an Ubuntu
> machine. I think there's some magic that replaces the Maintainer field
> in the Ubuntu tooling.
> 
> 


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

Bug#1034310: Another issue which is not fixed in 7.x.x

[Steven Robbins]

Hello Rainer,

Debian now has 8.1.0 uploaded to testing.  I'm wondering if you can test that 
and report back whether the issue persists or not.

Thanks,
-Steve

On Mon, 01 May 2023 23:37:00 +0200 Rainer Dorsch  wrote:
> Comment 35 in upstream bugreport:
> 
> https://bugs.kde.org/show_bug.cgi?id=466170#c35
> 
> Thanks for the backtrace, the problem in slotEmptyMessageTimer() is known 
and 
> was fixed about 5 months ago. We seem to have forgotten the backport to 
> digiKam-7.x.x when I look at the history. Only with digiKam-8.0.0 will the 
> problem no longer occur.


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

Bug#1042376: digikam crashes with "Illegal instruction"

[Steven Robbins]

On Saturday, August 19, 2023 11:53:35 A.M. CDT you wrote:
>Hi Steve,
> 
>I'm afraid, it doesn't prevent digikam from crashing.
> 
>Here is what I did (after fetching the latest updates from "testing" this
> morning):

[ ... ]

>Not sure if my approach is the preferred way to test something across
> different branches, though. I didn't want to switch my entire system to
> "sid" (this is my main machine, after all :) ). Hope that's OK. If there's
> a better way of testing your version, please let me know.

The testing approach is fine.  Thanks for this.  

Given the gdb stack trace, this result is what I expected.  I don't understand 
what the illegal instruction is at that address.  I have two ideas at this 
point.

1. Test a build without SSE4.  If you feel up to it, this would be easiest to 
do on your machine because the build-time detection should simply work fine.  
If you have sufficient time and interest, please look at https://
www.linuxfordevices.com/tutorials/debian/build-packages-from-source

If you aren't able to build from sources, let me know.  The alternative is for 
me to build it here after hacking the sources to disable SSE4 detection.


2. Dig further with the debugger to understand what the illegal instruction 
is.  I may be completely wrong in assuming it is an SSE4 instruction -- 
particularly given the fact that the test code we discussed August 13/14 
builds the same with/without the -msse4.1 flag.  If you are handy with gdb you 
can probably dig into the assembly and figure out what the instruction is.

Regards,
-Steve


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

Bug#1042376: digikam crashes with "Illegal instruction"

[Steven Robbins]

On Monday, August 14, 2023 8:52:14 A.M. CDT Steven Robbins wrote:

> So I'm back to square 1, very confused by your crash.

I have made a change to digikam and uploaded 8.1.0-3 last night.   It should 
avoid calling SSE 4 functions if only SSE 2 is detected.  I'd appreciate if 
you could try it out and report back to this bug whether it fixes your crash or 
not.

It's a bit of a shot in the dark since it doesn't affect the specific function 
pointed at in your back trace.

Best,
-Steve


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

Bug#1042376: digikam crashes with "Illegal instruction"

[Steven Robbins]

On Monday, August 14, 2023 1:25:23 A.M. CDT Detlef Matthiessen wrote:
>Hi Steve,
> 
>right after I replied to the bug report, I noticed:
> 
> dm@fluke:/tmp$ diff test-no-sse4 test-sse4
> dm@fluke:/tmp$
> 
>Can you confirm that the attached binaries are identical?

Nice catch.  They are identical.  I repeated the compilations this morning 
with/without -
msse4.1 and the result is indeed identical.  In fact, it is the same when I 
omit *both* -
msse2 and -msse4.1.

I notice also that nowhere does the code reference the matrix computed.  I 
wondered 
whether all that code was being optimized away -- so I added code to reference 
it:

std::cout << "Element[0][0] = " << yuv2rgb_bt601(0,0) << "\n";

However, there is no change: the binary is identical regardless of the -m 
options.  

So I'm back to square 1, very confused by your crash.

-Steve



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

Bug#1042376: digikam crashes with "Illegal instruction"

[Steven Robbins]

On Sun, 30 Jul 2023 07:27:51 +0200 Detlef Matthiessen 
 
wrote:
> 
>Hi Steve,
> 
>I've got:
> 
> Program received signal SIGILL, Illegal instruction.
> 0x76cc20d3 in operator* (m1=..., m2=...) at 
> /usr/include/x86_64-linux-gnu/qt5/
QtGui/qmatrix4x4.h:642
> Downloading source file /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix4x4.h
> 642 /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix4x4.h: Directory not 
> empty.
> 
>HTH, Detlef

There must be more than this?  Normally a backtrace shows a number of stack 
frames.  
Did you type "bt" in the gdb propmpt after the crash?

Example:
(gdb) bt 
#0  0x747199ef in __GI___poll (fds=0x607d36a0, nfds=13, 
timeout=4978) at ../
sysdeps/unix/sysv/linux/poll.c:29 
#1  0x7fffe5918517 in g_main_context_poll_unlocked (priority=, 
n_fds=13, fds=0x607d36a0, timeout=, context=0x7fff48000ec0) 
at 
../../../glib/gmain.c:4653 
#2  g_main_context_iterate_unlocked (context=context@entry=0x7fff48000ec0, 
block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
../../../glib/
gmain.c:4344 
#3  0x7fffe5918bac in g_main_context_iteration (context=0x7fff48000ec0, 
may_block=1) at ../../../glib/gmain.c:4414 
#4  0x74f1c8d6 in 
QEventDispatcherGlib::processEvents(QFlags) 
(this=0x55c298c0, flags=...) at kernel/qeventdispatcher_glib.cpp:423 
#5  0x74ec1b7b in 
QEventLoop::exec(QFlags) 
(this=this@entry=0x7fffd690, flags=..., flags@entry=...) 
   at ../../include/QtCore/../../src/corelib/global/qflags.h:69 
#6  0x74eca020 in QCoreApplication::exec() () at 
../../include/QtCore/../../src/
corelib/global/qflags.h:121 
#7  0x7533258c in QGuiApplication::exec() () at 
kernel/qguiapplication.cpp:1863 
#8  0x75b62ca5 in QApplication::exec() () at 
kernel/qapplication.cpp:2832 
#9  0xa0e6 in main(int, char**) (argc=, 
argv=) at ./core/app/main/main.cpp:478



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

Bug#1042376: digikam crashes with "Illegal instruction"

[Steven Robbins]

On Sun, 30 Jul 2023 10:22:19 +0200 Detlef Matthiessen 
 wrote:
> On 30.07.23 07:45, Detlef Matthiessen wrote:
> > 642QMatrix4x4 m = m1;
> 
>On a related note: a quick search for "digikam" and "642" yields the 
following bug report:
> https://bugs.launchpad.net/ubuntu/+source/digikam/+bug/2000718
> https://bugs.kde.org/show_bug.cgi?id=465548
> 
>Admittedly, I'm not familiar with the similarities of the instruction 
sets of an AMD Athlon II vs. my own Intel Q6700
> (or more precise, their lack of complex instructions), but the problem 
sounds quite similar to mine.
> 
>FWIW, comment https://bugs.kde.org/show_bug.cgi?id=465548#c16 points to 
AppImages provided by the KDE team. 8.1.0 is no
> longer available, but I was able to successfully start https://files.kde.org/
digikam/digiKam-8.2.0-20230724T132443-x86-64.appimage
> on my machine. So to me it looks as this bug probably already has been fixed 
upstream.


Thanks for this.  Oddly, the KDE bug notes indicate that the fix was put into 
8.1.0 -- which is the version that this bug's originator reported on.  So it's 
unclear whether this is the same issue.

-Steve




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

Bug#1043294: Bluetooth keeps disconnecting mouse

[Steven Friedrich]

Package: Bluetooth
Version: unknown

Synopsis: Bluetooth keeps disconnecting mouse
Expectation: The mouse should only be disconnected when powered off or 
commanded by user in settings.

Bug#1024793: gmp: update symbols and add definition for loongarch64

[Steven Robbins]

tag 1024793 + wontfix
thanks

On Fri, 25 Nov 2022 11:18:41 +0800 zhangdandan  wrote:
> Package: gmp
> Version: 6.2.1+dfsg1-1.1
> Severity: wishlist
> Tags: patch
> User: debian-de...@lists.debian.org
> Usertags: loongarch64
> 
> Hi gmp maintainers,
> 
> - update symbols for loongarch64.
> gmp would fail to build from source on mips64r6el if we had bootstrapped 
> this port due to symbol issues. Methods for updating symbol files:
> sed -i -e 's/!hppa/& !loongarch64/' libgmp10.symbols

The symbols file was removed in 2021:

gmp (2:6.2.1+dfsg-2~exp1) experimental; urgency=medium 

 * Drop symbols-file to make the work of porters easier. 
   (Closes: #984744, #989440, #788411) 
 * [05e73e2] Add myself as uploader 
 * Add autopkgtests. 

-- Anton Gladky   Tue, 07 Sep 2021 21:42:39 +0200

> - definition for mixed size 64 bit arithmetic.
> I have added patch for loongarch64. The patch:
> gmp-6.2.1-add-loongarch64-definition.patch

I'm not comfortable enough with the code to assess correctness of the patch.  
Please 
forward it to the upstream authors.  

Best,
-Steve



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

Bug#1028507: digikam: downloads binary blobs from the internet

[Steven Robbins]

clone 1028507 -1
retitle -1 Create face-recognition data package
thanks

On Tuesday, July 18, 2023 5:38:21 A.M. CDT Gregor Riepl wrote:
 
> Would it be possible to create a separate Debian package with this data
> and add it as a Recommends: dependency?

Yes, and thanks for the reminder.  The facility exists since DigiKam 8.1.0: 
https://mail.kde.org/pipermail/digikam-devel/2023-May/112408.html

> I believe there is enough precedent for large optional companion data
> packages in Debian. (0ad-data and kicad-packages3d come to mind)
> This would make it much clearer what the user is getting and from whom,
> and it would reduce the burden on the upstream CDN.

-Steve


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

Bug#1042376: digikam crashes with "Illegal instruction"

[Steven Robbins]

On Thursday, July 27, 2023 3:23:07 A.M. CDT Detlef Matthiessen wrote:

> after updating digikam from 7.9.0-2 to 8.1.0-2, it crashes almost instantly:
> dm@fluke:~$ digikam
> Illegal instruction
> 
> (...)
> 
> If you need more information, please let me know.

Thanks -- we'll need a backtrace from your system.

To obtain the trace, there are instructions here: https://wiki.debian.org/
HowToGetABacktrace

I got a trace using the following simple recipe:

apt install gdb
export DEBUGINFOD_URLS="https://debuginfod.debian.net;
gdb digikam
- answer 'y' when asked "Enable debuginfod for this session?"
run

Then reproduce your crash, and cut/paste the output into an email to this bug.

Thanks,
-Steve



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

Bug#1015809: 1015809: isc-dhcp-client: DHCPv6 doesn't work on ppp interface, got `Unsupported device type` error

[Steven Haigh]

Ok, so after a day of messing around with Debian 12, it looks like 
without these patches applied, there is no way to get a IPv6 PD working 
with a PPPoE connection. Given the majority of ISPs in Australia use 
PPPoE as their connection method, this is a much bigger issue in this 
country than where the maintainers of this package live.


wide-dhcpv6-client doesn't seem to interpret the reply from the ISP as 
a valid one.


dibbler-client binds to the wrong LL address and fails to open a socket.

Copying the dhclient binary from a Fedora 38 install and using that 
works perfectly - which is using the Fedora patches for dhclient v4.4.3.


The current, functioning patch from Fedora is here:
<https://src.fedoraproject.org/rpms/dhcp/blob/rawhide/f/0013-DHCPv6-over-PPP-support-626514.patch>

How are we able to fix this properly instead of a 'copy the binary from 
Fedora' type fix?


--
Steven Haigh

 net...@crc.id.au <mailto:net...@crc.id.au>
 https://crc.id.au <https://www.crc.id.au/>

Bug#1015809: 1015809: isc-dhcp-client: DHCPv6 doesn't work on ppp interface, got `Unsupported device type` error

[Steven Haigh]

It looks like this report is over a year old - but there's been no 
movement on it.


It seems that a PD request won't work on Debian 12 either using 4.4.3.

Is there any reason as to why this patch hasn't been added?
--
Steven Haigh

 net...@crc.id.au <mailto:net...@crc.id.au>
 https://crc.id.au <https://www.crc.id.au/>

Bug#1040334: facet-analyser - build-depends on conflicting packages

[Steven Robbins]

On Tuesday, July 4, 2023 10:03:27 A.M. CDT Peter Green wrote:
> Package: facet-analyser
> Version: 0.0~git20221121142040.6be10b8+ds1-3
> Tags: trixie, sid
> Severity: serious
> Justification: rc policy - "packages must be buildable within the same
> release" User: debian...@lists.debian.org
> Usertags: edos-uninstallable
> x-debbugs-cc: s...@debian.org
> 
> facet-analyser build-depends on both python3-paraview and
> libinsighttoolkit5-dev
> 
> unfortunately, libinsighttoolkit5-dev recently added a dependency on
> libvtk9-dev which depends on python3-vtk9 which conflicts with
> python3-paraview.
> 
> I am not familiar enough with the packages in question to know what the
> most appropriate way to untangle this is.

That's curious.  I don't know either.  My questions are: why do python3-vtk9 
and python3-paraview conflict, and could the issue be solved another way?

-Steve


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

Bug#1039903: libinsighttoolkit5-dev: Forcing C++14 makes plastimatch FTBFS

[Steven Robbins]

On Thu, 29 Jun 2023 13:40:42 +0300 Adrian Bunk  wrote:

>  1153 | #error\
>   |  ^~
>  1154 | DCMTK was configured to use C++17 features, but your compiler does 
not or was not configured to provide them.
>   | ~
> ...
> 
> 
> 
> This is due to:
> /usr/lib/x86_64-linux-gnu/cmake/ITK-5.3/ITKInitializeCXXStandard.cmake:  
set(CMAKE_CXX_STANDARD 14) # Supported values are 14, 17, 20, and 23.

That is just the default.  Override it for the plastimatch build by adding

set(CMAKE_CXX_STANDARD 17) 

to the plastimatch CMakeLists.txt file.

-Steve


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

Bug#1039897: ipe: Toolbar icons do not show due to missing dependency on libqt6svg6

[Steven]

Package: ipe
Version: 7.2.27+dfsg1-1+b1
Severity: normal
X-Debbugs-Cc: steven3k+deb...@gmail.com

Dear Maintainer,
Ipe 7.2.27 fails to display toolbar icons on Debian Trixie unless the package
libqt6svg6 is installed.
However, the ipe Debian package does not depend on libqt6svg6. Please consider
adding libqt6svg6 as a dependency.

Related bug report upstream: https://github.com/otfried/ipe/issues/401

   * What led up to the situation?
Running ipe after upgrading to Trixie from Bookworm.

   * What exactly did you do (or not do) that was effective (or ineffective)?
Manually installing the libqt6svg6 fixed the problem.


Thank you for your work,
Steven


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.3.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ipe depends on:
ii  fonts-urw-base3520200910-7
ii  libc6   2.36-9
ii  libcairo2   1.16.0-7
ii  libgcc-s1   13.1.0-6
ii  libipe7.2.277.2.27+dfsg1-1+b1
ii  liblua5.4-0 5.4.4-3
ii  libqt6core6 6.4.2+dfsg-11
ii  libqt6gui6  6.4.2+dfsg-11
ii  libqt6widgets6  6.4.2+dfsg-11
ii  libstdc++6  13.1.0-6
ii  sensible-utils  0.0.20
ii  texlive-latex-base  2022.20230122-3
ii  xdg-utils   1.1.3-4.1

Versions of packages ipe recommends:
ii  lua5.4  5.4.4-3

Versions of packages ipe suggests:
ii  texlive-latex-recommended  2022.20230122-3

-- no debconf information

Bug#1039528: plastimatch: FTBFS: Could not find a package configuration file provided by "VTK"

[Steven Robbins]

On Monday, June 26, 2023 6:15:06 P.M. CDT Adrian Bunk wrote:
> Control: reassign -1 libinsighttoolkit5-dev 5.3.0-3
> Control: affects -1 src:plastimatch
> 
> There are actually tow separate issues, both in libinsighttoolkit5-dev:

Thanks for bringing this to my attention.

> 1. The VTK build dependencies for the recent VTK changes also hae to
>become dependencies of libinsighttoolkit5-dev.

I confirmed this bug, and fixed it in a rev -4 upload of ITK.  I confirmed the 
issue and the fix by building elastix, which depends on ITK in the same manner.


> In file included from
> /<>/src/plastimatch/base/dcmtk_config.h:16, from
> /<>/src/plastimatch/base/metadata.h:12, from
> /<>/src/plastimatch/base/astroid_dose.h:8, from
> /<>/src/plastimatch/base/astroid_dose.cxx:7:
> /usr/include/dcmtk/config/osconfig.h:1153:2: error: invalid preprocessing
> directive #errorDCMTK 1153 | #error\
> 
>   |  ^~
> 
>  1154 | DCMTK was configured to use C++17 features, but your compiler does
> not or was not configured to provide them.
>   | ~
> 
> 2. This is caused by libinsighttoolkit5-dev injecting -std=c++14 into
>reverse dependencies, the fix is likely something like


This is less clear to me.  Elastix also build-depends on dcmtk and doesn't 
show this issue.  I think ITK uses C++14 as a minimum but you ought to be able 
to build with higher levels.  At work, we build with a C++20 compiler.

Thus: I am closing this bug with rev -4 fixing the first mentioned issue.  If I 
am wrong about the second, please open a second bug.

Regards,
-Steve


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

Bug#1036883: unblock: inventor/2.1.5-10+dfsg-2

[Steven Robbins]

On Sunday, May 28, 2023 11:08:52 A.M. CDT Martin Hostettler wrote:

> [ Risks ]
> 
> Steven Robbins described the problem the following way:
> > I couldn't say "harmless", but "mostly harmless", I'd think.

If it helps: Inventor is a system for visualizing 3D scenes.  The elements in 
the scenes are geometric objects like spheres, cuboids, cones, etc, described 
in a structured "scene graph" input file.  One possible node type in the scene 
is "text".  This bug will manifest only for input data that contains a text 
node; when it manifests the text will be absent in the view but no other ill 
effects are observed.
 
> And uploaded a fix to unstable.
> 
> The risks should be minimal given that the change in the package are
> minimal.

The fix is just to link to the new file names.  I tested the fix by viewing an 
example scene file that does contain text: 

ivview /usr/share/inventor/data/demos/jackInTheBox.iv

Regards,
-Steve



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

Bug#1036603: libinventor1: broken symlinks: /usr/share/inventor/fonts/Century-Schoolbook-* -> /usr/share/fonts/X11/Type1/c0590*l.pfb

[Steven Robbins]

On Tue, 23 May 2023 10:21:29 +0200 Andreas Beckmann  wrote:

> fonts-urw-base35 does not provide the old "numeric" font names
> gsfonts-x11 had.

Thanks for this.  Do you happen to know of a package that does ship those 
fonts, even if a different name?

> (gsfonts-x11 is now an empty transitional package,
> so you could drop that alternative dependency.)
> 
> Feel free to downgrade the severity if the missing fonts are harmless.

I couldn't say "harmless", but "mostly harmless", I'd think.  

-Steve


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

Bug#1036587: samba: named crashes on DLZ zone update

[Steven Monai]

On 2023-05-23 3:04 a.m., Michael Tokarev wrote:

At this point I don't plan to push new samba release to debian. Next
upstream 4.17 is planned - I guess now when the issue is rehashed by
you, next stable upstream release will include the fix.  I definitely
plan to push this to bookworm, hopefully the first point release of
it.  If I were to push it now, I'll have to add a new patch now and
remove it when next 4.17 is out, making double work for the release
managers, - first to review the patch, next to review patch move to
upstream source, - the latter is always more difficult than to review
just the upstream differences.  I understand you want to see it in
debian before 12.1, but having in mind the amount of work being done
by the release managers now.. 


No worries, I can wait for 12.1. In the meantime, Bullseye still works 
for me.



I can make it available in my usual repository.


Please do! Where can I find your repo?


Thank you for being persistent, despite some of the samba members
being not as useful.. ;)


Bah, I've seen worse. I've been in IT/tech-support for 10+ years. :)

Cheers,
--
-S.M.

Bug#1036587: samba: named crashes on DLZ zone update

[Steven Monai]

Package: samba
Version: 2:4.17.8+dfsg-1
Severity: important
X-Debbugs-Cc: stevem...@gmail.com

Dear Maintainer,

Using samba 4.17.8 with bind_dlz DNS backend. A new DC is joined to an 
existing domain with a single 4.17.8 DC.


When samba_dnsupdate runs on the newly joined DC, it causes the local 
named to abort with an assertion failure when adding the necessary DNS RRs.


This issue is potentially show-stopping for new Bookworm DCs, as it 
prevents the necessary DNS RRs (NS and SRV records) from being created.


There is a patch upstream for this issue, for both 4.18.latest and 
4.17.latest (see: https://bugzilla.samba.org/show_bug.cgi?id=14030 ).


Upstream says the patch is vetted (see: 
https://lists.samba.org/archive/samba/2023-May/245231.html ).


I hope this fix can make it into Bookworm!

Thanks for your time.

Cheers,
-S.M.
--


-- Package-specific info:
* /etc/samba/smb.conf present, but not attached
* /var/lib/samba/dhcp.conf not present

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

Kernel: Linux 6.1.0-9-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages samba depends on:
ii  init-system-helpers  1.65.2
ii  libbsd0  0.11.7-2
ii  libc62.36-9
ii  libcups2 2.4.2-3
ii  libgnutls30  3.7.9-2
ii  libldap-2.5-02.5.13+dfsg-5
ii  libldb2  2:2.6.2+samba4.17.8+dfsg-1
ii  libpam-modules   1.5.2-6
ii  libpam-runtime   1.5.2-6
ii  libpopt0 1.19+dfsg-1
ii  libtalloc2   2.4.0-f2
ii  libtasn1-6   4.19.0-2
ii  libtdb1  1.4.8-2
ii  libtevent0   0.14.1-1
ii  passwd   1:4.13+dfsg1-1+b1
ii  procps   2:4.0.2-3
ii  python3  3.11.2-1+b1
ii  python3-dnspython2.3.0-1
ii  python3-samba2:4.17.8+dfsg-1
ii  samba-common 2:4.17.8+dfsg-1
ii  samba-common-bin 2:4.17.8+dfsg-1
ii  samba-libs   2:4.17.8+dfsg-1
ii  tdb-tools1.4.8-2

Versions of packages samba recommends:
ii  attr1:2.5.1-4
ii  logrotate   3.21.0-1
ii  python3-markdown3.4.1-2
ii  samba-ad-provision  2:4.17.8+dfsg-1
ii  samba-dsdb-modules  2:4.17.8+dfsg-1
ii  samba-vfs-modules   2:4.17.8+dfsg-1

Versions of packages samba suggests:
ii  bind9 1:9.18.12-1
ii  bind9-utils [bind9utils]  1:9.18.12-1
ii  chrony4.3-2+deb12u1
pn  ctdb  
ii  ldb-tools 2:2.6.2+samba4.17.8+dfsg-1
pn  ufw   
ii  winbind   2:4.17.8+dfsg-1

-- no debconf information

Bug#1028507: digikam: downloads binary blobs from the internet

[Steven Robbins]

forwarded 1028507 https://bugs.kde.org/show_bug.cgi?id=438317
thanks

On Thu, 12 Jan 2023 06:24:07 +0100 Christoph Anton Mitterer 
 wrote:

> Every time when starting digikam, a dialog pops up asking to download
> some engines for redeye removal and face detection from the internet,
> which would cause them to be stored in /home/calestyo/.local/share/digikam/ 
> 
> Could that please be disabled?

It's coming in version 8.

> a) It's a security risk. It's aboslutely unclear who controls these files
>(at least not debian).

I hear your concerns.  These files are data that used to be shipped as part of 
digikam and were later unbundled, which led to the download prompt.  You can 
read through the upstream bug for a full discussion. 

-Steve


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

Bug#1034310: [digikam] [Bug 466170] Digikam 7.9.0 (and 7.8.0) crashes on startup

[Steven Robbins]

Severity: normal
thanks

On Tue, 25 Apr 2023 22:49:03 -0500 Steven Robbins  wrote:

> Given that no-one else has reported this, 
> I'm leaning towards downgrading the severity to keep digikam in the upcoming 
> release.

Setting severity to normal.  If anyone reading this has encountered this bug, 
please reply to let us know.

-Steve


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

Bug#1033088: ntpsec: mssntp in ntp.conf breaks time service to all clients

[Steven Monai]

On 2023-04-29 9:04 p.m., Richard Laager wrote:

Quick approach is try this:
python3 waf configure ...
python3 waf build


I tried this, but the bundled 'waf' tool did not work in Python3. I 
could not get past the 'configure' step. Here's the output I got on a 
Bookworm host with all the ntpsec build dependencies installed:


t...@book.test:~$ python3 -V
Python 3.11.2
t...@book.test:~$ wget -q 
https://ftp.ntpsec.org/pub/releases/ntpsec-1.1.3.tar.gz

t...@book.test:~$ tar -xf ntpsec-1.1.3.tar.gz
t...@book.test:~$ cd ntpsec-1.1.3/
t...@book.test:~/ntpsec-1.1.3$ python3 waf configure
Waf: The wscript in '/home/tech/ntpsec-1.1.3' is unreadable
Traceback (most recent call last):
  File 
"/home/tech/ntpsec-1.1.3/.waf3-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Scripting.py", 
line 106, in waf_entry_point


set_main_module(os.path.normpath(os.path.join(Context.run_dir,Context.WSCRIPT_FILE)))
  File 
"/home/tech/ntpsec-1.1.3/.waf3-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Scripting.py", 
line 137, in set_main_module

Context.g_module=Context.load_module(file_path)
 ^^
  File 
"/home/tech/ntpsec-1.1.3/.waf3-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Context.py", 
line 352, in load_module

code=Utils.readf(path,m='rU',encoding=encoding)
 ^^
  File 
"/home/tech/ntpsec-1.1.3/.waf3-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Utils.py", 
line 127, in readf

f=open(fname,m)
  ^
ValueError: invalid mode: 'rUb'


A longer, but possibly better, approach might be something like:
git clone g...@salsa.debian.org:debian/ntpsec.git
cd ntpsec
git checkout debian/1.1.3+dfsg1-1
debuild -uc -us


I tried this too, but the result was similar: the bundled 'waf' failed 
to work, which broke the build.


I don't believe I will be able to "forward-port" old ntpsec releases to 
Bookworm without a lot more time and effort. Perhaps someone more 
familiar with the build system would have better luck?


An intermediate approach might be to test with the binary package from 
buster. You can get download links here, by architecture, plus there are 
links to related packages, some of which (like python3-ntp) you might need:

https://packages.debian.org/buster/ntpsec


I could spin up a Buster VM to try this. I don't have a domain 
controller running on Buster, so I can't test whether Windows clients 
will get properly signed responses from the server. But I can still test 
whether the 'mssntp' configuration in ntp.conf causes ntpsec to stop 
serving non-auth clients. I will try to get to this in the next few days.


-S.M.

Bug#1034908: Processed: Please ship libgtest.so and libgmock.so for building libabsl-dev

[Steven Robbins]

On Friday, April 28, 2023 2:45:05 A.M. CDT Debian Bug Tracking System wrote:
> Processing control commands:
> > block 1034908 by -1
> 
> Bug #1034908 [libabsl-dev] Update libabsl-dev to new upstream
> version/snapshot for newer protobuf 1034908 was not blocked by any bugs.
> 1034908 was blocking: 1034668
> Added blocking bug(s) of 1034908: 1035045

The reported build error is:

dpkg-shlibdeps: error: cannot find library libgtest.so.1.12.1 needed by 
debian/libabsl20230125/usr/lib/x86_64-linux-gnu/
libabsl_per_thread_sem_test_common.so.20230125.0.0 
(ELF format: 'elf64-x86-64' abi: '0201003e'; RPATH: '')

How did libabsl20230125 get such a dependency?  Debian has never shipped 
libgtest.so -- was this built against a locally-built libgtest somehow?

My recommendation is to preferably build libgtest in your own build process -- 
this ensures gtest is built with the same compiler options as your test code; 
or else link against the provided static libgtest.a.

-Steve




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

Bug#1033088: ntpsec: mssntp in ntp.conf breaks time service to all clients

[Steven Monai]

On 2023-04-28 10:20 p.m., Richard Laager wrote:
Can you confirm whether you get either of these messages to stderr on 
startup:


A) MS-SNTP signd operations currently block ntpd degrading service to 
all clients.


Definitely this one, A.

Is there any chance you could test with ntpsec 1.1.3? You'd have to 
build from source (and note that upstream stores the config file in 
/etc/ntp, not /etc/ntpsec). It is available here:

https://ftp.ntpsec.org/pub/releases/ntpsec-1.1.3.tar.gz


I downloaded and unpacked this source on a Bookworm host. The build 
system bundled with the source ("waf") seems to assume python 2.x, but, 
unfortunately, Bookworm provides only python3. Any hints?


I've forwarded the bug 
upstream. You can see the URL in the control commands at the top of this 
message.


Thanks, much appreciated!

Cheers,
-S.M.

Bug#1034310: [digikam] [Bug 466170] Digikam 7.9.0 (and 7.8.0) crashes on startup

[Steven Robbins]

On Tuesday, April 25, 2023 12:50:39 P.M. CDT Rainer Dorsch wrote:
> Am Dienstag, 25. April 2023, 03:51:44 CEST schrieben Sie:
> > I'd be interested to know if the issue persists on your system after
> > upgrading.
> 
> Yes, it repros always.

OK.

> -- System Information:
> Debian Release: 12.0
>   APT prefers testing-security
>   APT policy: (500, 'testing-security'), (500, 'testing-debug'), (105,
> 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.1.0-7-amd64 (SMP w/6 CPU threads; PREEMPT)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
> LANGUAGE=de:en_US

I'm still not able to reproduce the issue.  Today I was trying with the same 
locale as you (de_DE.UTF-8).   I have seen issues in the past with certain 
locales -- typically in software that isn't careful enough and gets into 
trouble when a locale switches the period and comma in number formats.  

Even though I wasn't able to reproduce the problem here, it would be 
interesting if you can try with locale set to en_US for example:

I have no idea where else to look.  Given that no-one else has reported this, 
I'm leaning towards downgrading the severity to keep digikam in the upcoming 
release.

-Steve


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

Bug#1034310: [digikam] [Bug 466170] Digikam 7.9.0 (and 7.8.0) crashes on startup

[Steven Robbins]

Hi Rainer,

On Sun, 16 Apr 2023 09:38:07 +0200 Rainer Dorsch  wrote:

> Let me elaborate a somewhat:
> 
> The spash screen bug I found is visible in the backtrace in comment 5:
> 
> https://bugs.kde.org/show_bug.cgi?id=466170#c5
> 
> According to Maik, the bug is triggered by a race condition (comment 6). 
I.e. 
> even with exact the same software configuration, there is a good chance that 
> you don't see it, because the timing on your hardware might be different 
> (different CPU, memory latencies, cache configurations,). In particular 
> if 
> it is hard to hit the race condition, as it seems to be the case.

That's fair.  Is it hard for you to hit the race condition?


> But the more important issue is the crash which I see after disabling splash
> screen. The backtrace is provided in comment 7

Right, this is the one that concerns me more.

A couple of days ago I thought I had reproduced the issue.  But I can't 
reproduce it today.  I think that either (a) I was mistaken the other day; or 
(b) updating the "testing" distribution fixed the bug.   I did "apt upgrade" 
today before trying to investigate so unfortunately I can't tell which of the 
two possibilities is true.

I'd be interested to know if the issue persists on your system after 
upgrading.


> How do you generate this list?

reportbug --template digikam


> Do you know if I can disable the faces download? 

I don't know if that is possible.  

-Steve


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

Bug#1034310: [digikam] [Bug 466170] Digikam 7.9.0 (and 7.8.0) crashes on startup

[Steven Robbins]

Just a note to say that I have used a Debian "testing" chroot environment and 
can reproduce the reported crash.  I will be investigating more in the coming 
days.

-Steve


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

Bug#1034310: [digikam] [Bug 466170] Digikam 7.9.0 (and 7.8.0) crashes on startup

[Steven Robbins]

On Fri, 14 Apr 2023 14:24:31 +0200 Rainer Dorsch  wrote:
> Thanks Marco, that is a good link.
> 
> I provided a backtrace and upstream acknowledged the bug to be fixed in 
8.1.0:

Hello Rainer,

I've looked at the upstream bug, and all the information you provided.  That's 
awesome -- I wish that every bug submitter would be as thorough as you!

It seems that, even with disabling the splash screen, you still experience the 
bug -- is that correct?

I can say that I'm not experiencing any such crash.  I created a new user to 
test from scratch.  I see the splash screen come and go, then the pop-up that 
offers to download the faces data files.  I can download them or not and it all 
works fine either way.

So it's puzzling.  I'm also using an x64 system, but I run on the "sid/
unstable" distribution so I have slightly different versions of the dependency 
packages.   Maybe it's worth attempting an upgrade of some or all of these to 
see if the problem goes away?

Perhaps start with libkf5configcore5, since the failing assert seems to be in 
that library:

qt_assert_x(char const*, char const*, char const*, int) () at /lib/
x86_64-linux-gnu/libQt5Core.so.5


Here is the list from my system today.

Versions of packages digikam depends on:
ii  digikam-data  4:7.9.0-1
ii  digikam-private-libs  4:7.9.0-1+b2
ii  libc6 2.36-9
ii  libgcc-s1 12.2.0-14
ii  libkf5configcore5 5.103.0-2
ii  libkf5coreaddons5 5.103.0-1
ii  libkf5i18n5   5.103.0-1
ii  libmagick++-6.q16-8   8:6.9.11.60+dfsg-1.6
ii  libqt5core5a  5.15.8+dfsg-7
ii  libqt5gui55.15.8+dfsg-7
ii  libqt5sql55.15.8+dfsg-7
ii  libqt5sql5-mysql  5.15.8+dfsg-7
ii  libqt5sql5-sqlite 5.15.8+dfsg-7
ii  libqt5widgets55.15.8+dfsg-7
ii  libstdc++612.2.0-14
ii  perl  5.36.0-7

Versions of packages digikam recommends:
ii  brave-browser [www-browser] 1.50.119
ii  ffmpegthumbs4:22.12.3-1
ii  firefox-esr [www-browser]   102.10.0esr-1
ii  google-chrome-stable [www-browser]  112.0.5615.121-1
ii  konqueror [www-browser] 4:22.12.3-1
ii  lynx [www-browser]  2.9.0dev.12-1
ii  w3m [www-browser]   0.5.3+git20230121-2

Versions of packages digikam suggests:
ii  breeze-icon-theme  4:5.103.0-1
pn  digikam-doc
ii  systemsettings 4:5.27.2-1

Best,
-Steve


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