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

Bug#1031953: libkf5screen8: Second monitor issues with NVIDIA

[Steven Robbins]

On Saturday, February 25, 2023 3:57:45 P.M. CST you wrote:

> Please don’t. I plan to upload the whole of Plasma 5.27.2 targeting
> bookworm.

Awesome, thanks!

> But please do follow-up on this and if the patch doesn’t make into the
> 5.27.2 upstream release you’re welcome to report it here so we can apply
> the fix on top of that release.

Yep, I'll re-test and update/close the bug once 5.27.2 hits me.

Best
-Steve


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

Bug#1028163: sshfs-fuse bug

[Steven Robbins]

On Sunday, February 5, 2023 7:04:26 P.M. CST Santiago Vila wrote:
> El 5/2/23 a las 21:54, Steven Robbins escribió:
> > the test manifestly runs fine on buildds
> 
> Actually, that's not really true.
> 
> The tests do not even *run* on the buildds, because they are skipped.

Indeed!  I must have skipped over that output :-)

But I think the larger point remains: there is no build failure in practice.  
What is different in your environment that makes it fail?  

-Steve


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

Bug#1028163: sshfs-fuse bug

[Steven Robbins]

There are a couple of odd things about this bug.

First: it doesn't seem like an RC bug because the test manifestly runs fine on 
buildds -- see https://buildd.debian.org/status/package.php?p=sshfs-fuse

I'd suggest to downgrade the bug on this basis.

Second: the bug log shows python 3.9.2 is used.  That hasn't been the default 
python since 2021 -- so it's an unusual test environment.

-Steve


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

Bug#1027965: Fix for the RC bug in vtk

[Steven Robbins]

Hello,

Was looking yesterday for an RC bug to fix and noticed #1027965 against VTK -- 
a build failure in gdcm caused by missing dependency.  The fix proposed by 
Mathieu seems reasonable to me.

Anton: I'm writing to ask your opinion about the commits in salsa since the 
last upload (June 2022); specifically, do you feel they are suitable for 
inclusion now?   

Should I:

1. apply the patch to the lastest in salsa?
2. apply the patch to the last upload sources ignoring salsa?
3. leave it alone and let you deal with it?
4. something else?

Appreciate your insight.
-Steve


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

Bug#1024141: gtest: Normal execution is halted

[Steven Robbins]

On Sunday, January 29, 2023 11:10:22 A.M. CST Mathieu Malaterre wrote:
> On Tue, Nov 15, 2022 at 3:05 PM Steven Robbins  wrote:
> > On Tuesday, November 15, 2022 7:44:13 A.M. CST Mathieu Malaterre wrote:
> > > jpeg-xl unit tests cannot be run on GNU/Hurd. It seems to be stuck for
> > > infinite time.
> > 
> > That is curious.  It would help greatly if you had a minimal example.
> 
> Looks like an Heisenbug. Sometime I can reproduce it some time not. 

That's good information.  I had set out to report this bug upstream today, but 
then noticed that a new version 1.13 was released two weeks ago.  

Before reporting to upstream on a 6 month old version, it may be wise to first 
test on 1.13.  I have uploaded that to experimental.

-Steve


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

Bug#780659: insighttoolkit only built on amd64 and i386

[Steven Robbins]

On Tue, 17 Mar 2015 14:53:06 +0100 Matthias Klose  wrote:
> Package: src:insighttoolkit4
> Version: 4.6.0-3
> 
> insighttoolkit is only built on amd64 and i386, while insighttoolkit3 worked 
on
> some more architectures.  

True.  It became untenable to support other architectures and that hasn't 
changed so I'm closing this bug.

-Steve


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

Bug#1025672: RM: digikam [armel ppc64el s390x] -- RoQA; marble not available

[Steven Robbins]

On Wednesday, December 7, 2022 4:12:09 A.M. CST Bas Couwenberg wrote:
> Package: ftp.debian.org
> Severity: normal
> User: ftp.debian@packages.debian.org
> Usertags: remove
> X-Debbugs-Cc: digi...@packages.debian.org
> Control: affects -1 + src:digikam
> Control: block 1025671 by -1
> 
> Please remove digikam from the architectures where marble is not available.

I don't understand this request -- digikam appears to be built on those three 
architectures.  Where's the problem?




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

Bug#1024960: digikam: New upstream release 7.8.0

[Steven Robbins]

On Sunday, November 27, 2022 3:49:18 P.M. CST you wrote:
> Package: digikam
> Version: 4:7.7.0-3+b1
> Severity: normal
> 
> Dear Maintainer,
> 
> Would be nice to ave this version in bookworm

Will certainly get a new version into bookworm.  It looks like there will be a 
7.9.0 in the next week [1] so I think I'll wait for that.  

[1] https://mail.kde.org/pipermail/digikam-users/2022-November/034311.html

Best,
-Steve


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

Bug#1024141: gtest: Normal execution is halted

[Steven Robbins]

On Tuesday, November 15, 2022 7:44:13 A.M. CST Mathieu Malaterre wrote:

> jpeg-xl unit tests cannot be run on GNU/Hurd. It seems to be stuck for
> infinite time.

That is curious.  It would help greatly if you had a minimal example.

-Steve



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

Bug#1020397: reverse dependency

[Steven Robbins]

Hi,

I'll start by a short digression.  If you know the answer to this: what must I 
do to get reliable replies to bugs sent to my email box?  In my recollection 
that was routine a number of years ago but nowadays I essentially never see 
replies and only find them by happenstance -- when perusing bugs via the web 
interface.


On Fri, 23 Sep 2022 17:24:03 + (UTC) Thorsten Alteholz 
 wrote:

> Checking reverse dependencies...
> # Broken Depends:
> matrix-mirage: matrix-mirage

Yes.  That is orphaned.  I thought it would be simply removed.  Do you need me 
to file a RM bug for it?

-Steve


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

Bug#1019393: hdf5 breaks libsis-jhdf5-java autopkgtest: Could not initialize class

[Steven Robbins]

On Thu, 8 Sep 2022 16:11:33 +0200 Paul Gevers  wrote:

> With a recent upload of hdf5 the autopkgtest of libsis-jhdf5-java fails 
> in testing when that autopkgtest is run with the binary packages of hdf5 
> from unstable. It passes when run with only packages from testing.

I find the same holds for simple BUILDING of the libsis-jhdf5-java source 
package.  The build succeeds when using libhdf5-dev from testing, but fails 
with the  package from  unstable. 

The failure happens when running tests.  Below is output from first test 
failure.

-Steve

FAILED: testCreateVerifyContentArtificialRootRoundtripOK
java.lang.ExceptionInInitializerError
at hdf.hdf5lib.HDF5Constants.(HDF5Constants.java:29)
at 
ch.systemsx.cisd.hdf5.IHDF5WriterConfigurator$FileFormatVersion.(IHDF5WriterConfigurator.java:
74)
at 
ch.systemsx.cisd.hdf5.IHDF5WriterConfigurator$FileFormatVersionBounds.(IHDF5WriterConfigurator.java:
127)
at 
ch.systemsx.cisd.hdf5.h5ar.HDF5Archiver.(HDF5Archiver.java:112)
at 
ch.systemsx.cisd.hdf5.h5ar.HDF5ArchiverFactory.open(HDF5ArchiverFactory.java:
41)
at 
ch.systemsx.cisd.hdf5.h5ar.HDF5ArchiverTest.testCreateVerifyContentArtificialRootRoundtripOK(HDF5ArchiverTest.java:
330)
at java.base/
jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:
104)
at java.base/java.lang.reflect.Method.invoke(Method.java:577)
at 
org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:
100)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:646)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:811)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1129)
at 
org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:
129)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:
112)
at org.testng.TestRunner.privateRun(TestRunner.java:746)
at org.testng.TestRunner.run(TestRunner.java:600)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:366)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319)
at org.testng.SuiteRunner.run(SuiteRunner.java:268)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1264)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1189)
at org.testng.TestNG.runSuites(TestNG.java:1104)
at org.testng.TestNG.run(TestNG.java:1076)
at org.testng.TestNG.privateMain(TestNG.java:1405)
at org.testng.TestNG.main(TestNG.java:1374)
Caused by: java.lang.UnsupportedOperationException: No suitable HDF5 native 
library found for this platform.
at hdf.hdf5lib.H5.loadH5Lib(H5.java:240)
at hdf.hdf5lib.H5.(H5.java:230)
... 28 more

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

Bug#1016831: closed by Steven Robbins (Re: libminc: FTBFS on mipsel, mips64el)

[Steven Robbins]

On Mon, 22 Aug 2022 09:24:41 +0200 Sebastian Ramacher  
wrote:


> > I can't reproduce this.  The main difference between the one that built and 
the 
> > one that didn't is the new libc, so that's the most likely culprit.
> 
> The 4th attempt on the buildds filed again: https://buildd.debian.org/status/
fetch.php?pkg=libminc=mips64el=2.4.03-5+b1=1661136219=0
> 
> Reopening. Please only close this bug when libminc is able to build on
> the buildds again.

I can't debug this!  It builds OK in both the mipsel and mips64el chroots on 
porterbox eller.  See https://lists.debian.org/debian-devel/2022/08/
msg00200.html

Is there something broken on the buildd? 

-Steve


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

Bug#1004628: qtav: FTBFS with ffmpeg 5.0

[Steven Robbins]

Heads up for those following this bug: qtav appears to be unmaintained 
upstream.  

My only interest in the package was to enable video playback in digikam.  
Digikam upstream has taken most of the qtav  code, incorporated into digikam 
source tree and fixed it up.  The next release of digikam will not need qtav 
and therefore I will no longer be maintaining qtav. 

The only other usage in Debian I can find is "matrix-mirage" (which is itself 
orphaned).

My suggestion is to simply remove qtav from Debian.  If you do need qtav for 
some other purpose, please respond here and consider yourself the new 
maintainer.

Best,
-Steve


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

Bug#1004769: Processed: severity of 1004769 is important

[Steven Robbins]

On Thursday, July 21, 2022 11:24:03 A.M. CDT Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> > severity 1004769 important
> 
> Bug #1004769 [src:digikam] Video support missing (FTBFS with ffmpeg 5.0)
> Severity set to 'important' from 'serious'

I had deliberately set the severity as serious to make it appear in apt-
listbugs.  Of course, one is free to disagree with my rationale, but it would 
be nice to document the reasons.  

I'm willing to concede that "important" is appropriate but: the concern 
expressed by Vincent Danjean is that folks may not be adequately alerted (by 
apt-listbugs) when upgrading that the video support is going away and there is 
no reasonable way to downgrade once you've installed this version.  

Is that  unreasonable?

Regards,
-Steve


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

Bug#1004769: Video not handled anymore for now

[Steven Robbins]

On Sunday, July 17, 2022 4:09:20 A.M. CDT you wrote:
> Le 16/07/2022 à 18:50, Steven Robbins a écrit :
> > I would say that there may well be others in your situation so if you do
> > find a method please report back to this bug.
> 
>For my personnal use, until upstream provides a correct fix, I recompile
> digikam 7.7.0-1 (-2 was not pushed in the git ;-) ) 

Now pushed, thanks!

-Steve


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

Bug#1004831: transition: ffmpeg

[Steven Robbins]

On Saturday, July 16, 2022 12:28:33 P.M. CDT Christian Marillat wrote:
> On 16 juil. 2022 12:02, Steven Robbins  wrote:
> 
> [...]
> 
> > Certainly one can propose.  However, one cannot really expect upstream to
> > change their architecture away from ffmpeg by a given time any more than
> > one can expect them to adapt to ffmeg ABI break in that time.
> 
> Removed functions in version 5 have been deprecated in version 4
> released in July 2018
> 
> 4 years is more than enough to fix that. 

That's a judgement.  I respect your opinion on this.  Equally, I would suggest 
one should respect the upstream opinion on how they spend their development 
resources.  I'm not part of digikam upstream so I have no special knowledge of 
this, but perhaps the existing usage of ffmpeg sufficed and they had other 
priorities to work on.


> Some packages like mpd or mpv
> have been fixed since a long time.

Some have and clearly others have not.

Respectfully,
-Steve


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

Bug#1004831: transition: ffmpeg

[Steven Robbins]

On Tue, 5 Jul 2022 10:13:20 +0200 Sebastian Ramacher  
wrote:

> > > Reverse dependencies had 4 months to fix their bugs, so I'm going
> > > ahead with this one.
> > 
> > Not even close to enough time for all affected upstream teams.
> 
> The 4 months only reflects the Debian timeline. If upstreams are not
> able to track the constant changes in ffmpegs API, please propose to
> them to switch to higher level abstractions such as ffms2 or gstreamer.

Certainly one can propose.  However, one cannot really expect upstream to 
change their architecture away from ffmpeg by a given time any more than one 
can expect them to adapt to ffmeg ABI break in that time.

> > Debian has GTK3 and GTK4, Qt5 and Qt6 etc., it's not ideal and it is a
> > lot of work but it may be necessary to have libavcodec4-dev and
> > libavcodec-dev with a new source package ffmpeg4 alongside ffmpeg.
> 
> ffmpeg has a bad history of security issues including RCEs. 

That's a fair observation, and one that deserves to be taken into 
consideration.  Another observation: the ffmeg hard transition means that some 
packages will either be removed or seriously degraded -- as one example, 
digikam has lost ability to process video over this [1].

I think that overall usability of the distribution is an important 
consideration in making design choices.  Certainly one doesn't want a 
distribution riddled with security issues; nor does one want functionality 
removed.  So the question is really one of balance.  If ffmpeg 4 and 5 are both 
offered, with packages strongly encouraged to migrate: the distribution overall 
has improved security stance AND it retains more functionality.

-Steve

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004769

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

Bug#1004769: Video not handled anymore for now

[Steven Robbins]

On Friday, July 15, 2022 6:27:51 P.M. CDT you wrote:
>Hi,
> 
>This bug is rather anoying as I'm using digikam to manage my video.

I agree it is annoying.  I feel the same pain.

Given the hard-transition of ffmpeg [1], it is not possible to build with video 
in unstable today.  Digikam was temporarily removed from Debian and the only 
way to re-introduce it is to not use ffmpeg at all which has the serious side 
effect to drop video.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004831


> The low severity (and the title of the bug) does not allow one to stop
> the upgrade with apt-listbugs. In my opinion, this bug is at lease
> important (to be seen by apt-listbugs) and its title should reflect
> that video is not handle by digikam for now (or a new bug can be
> created and blocked by this one)

Thank you for the suggestion.  I was completely unaware of "apt-listbugs".  

I have just re-titled and changed the severity of this bug.  

The manpage for apt-listbugs says it displays serious and above by default.  
Therefore, I have made it 'serious' according to the criteria "in the package 
maintainer's or release manager's opinion, makes the package unsuitable for 
release".

>Due to the large dependencies, it is probably very difficult to
> downgrade digikam to a version with video support once 4:7.7.0-1
> is installed. I did not try for now.

I haven't tried either, so I don't know.  Maybe one can just pull the packages 
from the last stable release?  Build the 7.6 source package ?

I would say that there may well be others in your situation so if you do find a 
method please report back to this bug.  

> I hope video will be soon back.

Upstream is certainly aware of the issue and work is underway to migrate to 
the newer ffmpeg.  I am monitoring the upstream mailing list and sources.  
Based on what I see at present, I'm not optimistic for the short term, so if 
you're using testing or unstable you may want to  look into the downgrade 
option.

I am more hopeful that things will be resolved in time for the next Debian 
release. 

Best,
-Steve

Bug#1014648: digikam: Unable to display .heic correctly

[Steven Robbins]

On Monday, July 11, 2022 1:38:31 A.M. CDT Christian Marillat wrote:

> After a rebuild under pbuilder, I confirm that libheif-dev is missing
> from Build-Depends. Adding libheif-dev in Build-Depends fix this issue.

Thank you for debugging this.  I have uploaded -2 with the added build-
depends.

For what it's worth: on my system your HEIC file displayed correctly even with 
digikam 7.7.0-1.  Weird!

-Steve



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

Bug#1014648: digikam: Unable to display .heic correctly

[Steven Robbins]

On Monday, July 11, 2022 1:02:23 A.M. CDT you wrote:

> (The more problems I see related to major library upgrades in debian,
> the less convinced I am that only supporting a single (major) version
> for all libraries really is a good idea. Then I again I am not the one
> doing the work, so I am definitely not complaining, just thinking.)

100% agree.  The whole reason for the shared library naming scheme is to allow 
simultaneous installs.  I never understood the fetish for wholesale 
"transitions".

-Steve


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

Bug#1014648: digikam: Unable to display .heic correctly

[Steven Robbins]

On Saturday, July 9, 2022 8:26:21 A.M. CDT Christian Marillat wrote:
> Package: digikam
> Version: 4:7.7.0-1
> Severity: normal
> 
> Dear Maintainer,
> 
> Since the last version .heic files aren't
> displayed correctly. See attached screen capture.

I agree that does look odd.  Can you share the original HEIC file?

I downloaded the sample HEIC file from https://filesamples.com/formats/heic and 
it views correctly in both DigiKam and ShowFoto.  Specifically it showed as 
seen in this web page: https://fileinfo.com/extension/heic

Would be interested to know what your system displays for that sample image.

Regards,
-Steve



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

Bug#1013090: digikam: Regression : when batch renaming file (F2), only the first modifier is taken into account

[Steven Robbins]

On Thursday, June 16, 2022 2:06:04 P.M. CDT Vincent Danjean wrote:

>   According to the answer, this bug is already fixed in 7.7.0.

Digikam 7.7.0 was uploaded to Debian a few days ago; closing bug.

-Steve



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

Bug#1004769: digikam: FTBFS with ffmpeg 5.0

[Steven Robbins]

control: severity -1 normal

On Fri, 25 Feb 2022 22:55:12 +0100 Sebastian Ramacher  
wrote:
> On 2022-02-21 16:05:37 -0600, Steven Robbins wrote:
> > On Tue, 1 Feb 2022 21:01:39 +0100 Sebastian Ramacher 
 
> > wrote:
> > > Source: digikam
> > > Version: 4:7.1.0-2
> > 
> > I have just uploaded Digikam 7.5.0 to unstable.  If you have a chance to 
re-
> > try the build, would appreciate knowing if it now builds with new ffmpeg.
> 
> 7.5.0 fails to build with the same error.

I have temporarily disabled video player in Digikam 7.7.0-1 upload, so 
lowering this bug severity.

-Steve


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

Bug#1004831: transition: ffmpeg

[Steven Robbins]

Hello,

On Wed, 22 Jun 2022 22:13:11 +0200 Sebastian Ramacher  
wrote:

> ffmpeg got a new major release including API and ABI breakage. Hence, it
> needs a transition. The reverse dependencies are not yet ready, so this
> bug is just a heads up and should help to track progress. Due to
> ffmpeg's security record, we should complete this transition for
> bookworm.

Reverse dependencies had 4 months to fix their bugs, so I'm going ahead
with this one.

Yes, well as noted: this is a major release with ABI and API breakage.  It is 
unrealistic to expect the entire open source world to adopt this all at once.  
Digikam upstream, for example, is working on the transition, but it is not 
straightforward.  Current recommendation is to continue to build against the 
version 4 API [1].

Consider reintroducing the ffmpeg 4 libraries alongside version 5.

Thank you,
-Steve

[1] https://mail.kde.org/pipermail/digikam-users/2022-July/033796.html



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

Bug#1013752: Transition KDE PIM 22.04

[Steven Robbins]

Hello,

Patrick suggested I chime in here, as the Digikam maintainer.


On Sat, 25 Jun 2022 23:42:47 +0200 Sebastian Ramacher  
wrote:
> On 2022-06-25 20:45:37 +0200, Patrick Franz wrote:
> > Hi Sebastian,
> > 
> > Am Samstag, 25. Juni 2022, 20:30:32 CEST schrieb Sebastian Ramacher:
> > [...]
> > > > A fixed version of kgpg is in experimental and just needs to be
> > > > uploaded to unstable once KDE PIM 22.04 is uploaded there. There
> > > > are patches available for both digikam and kjots. I can patch kjots
> > > > myself and point the digikam maintainers to the existing patch.
> > > 
> > > Just to be clear: is the patch for digikam for kdepim compat or does
> > > it also fix the build failure with ffmpeg 5.0?
> > 
> > It would be purely for KDE PIM (https://invent.kde.org/graphics/
> > digikam/-/commit/51efe295a222070743187af0367b0bf957879337).
> 
> I see. If you (and the KDE team) are okay with temporarly removing
> digikam from testing, then please feel free to go ahead.

I'm comfortable with digikam being temporarily removed from testing.  As was 
pointed out, we still have the ffmpeg issue to deal with and I don't see any 
value in holding up kdepim for that.

Regards,
-Steve


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

Bug#1011051: libssl3: upgrade to libssl3 broke my dovecot setup

[Steven Robbins]

On Monday, June 6, 2022 6:11:38 A.M. CDT Bernhard Übelacker wrote:

> The recent dovecot upload contains this fix:
> 
>dovecot (1:2.3.19+dfsg1-1) unstable; urgency=medium
>  * [d223bbd] d/patches: add patch to support openssl 3.0 (Closes:
> #996273)
> 
>   
> https://salsa.debian.org/debian/dovecot/-/commit/d223bbd1d0968ad2b46c4316c1
> 02c11bde8c5075

That's good news.  Does it mean one can remove the workaround (commenting out 
"providers = provider_sect") ?

Regards,
-Steve
 

Bug#1010057: digikam: Failed when generated data-base

[Steven Robbins]

On Saturday, April 23, 2022 7:23:48 A.M. CDT Hoareau Jean Pierre wrote:
> Package: digikam
> Version: 4:7.6.0-1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> I installed Debian "Bookworm" in order to test this version. When launching
> "Digikam" I get a database loading/generation error.

Are you using an external DB like mysql/mariadb?  
Does the workaround in this report help?  
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007220

If not, can you provide reproduction steps?  Digikam 7.6.0 works for me so the 
reproduction will need explicit configuration steps.  Maybe you can configure 
from scratch for a new folder and share those steps?

Regards,
-Steve


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

Bug#1004769: digikam: FTBFS with ffmpeg 5.0

[Steven Robbins]

On Tue, 1 Feb 2022 21:01:39 +0100 Sebastian Ramacher  
wrote:
> Source: digikam
> Version: 4:7.1.0-2

I have just uploaded Digikam 7.5.0 to unstable.  If you have a chance to re-
try the build, would appreciate knowing if it now builds with new ffmpeg.

Thanks,
-Steve



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

Bug#987997: Wrong (too low) version of libcharls2 referenced

[Steven Robbins]

On Mon, 03 May 2021 14:54:07 +0200 Philipp Marek  
wrote:
> Package: digikam
> Version: 4:7.1.0-2
> Severity: normal
> X-Debbugs-Cc: phil...@marek.priv.at
> 
> Just "apt-get install digikam -t testing" doesn't work - libcharls2 is 
> left at 2.0.0+dfsg-1, but this digikam needs at least 2.2.0+dfsg-2 to 
> run.

Hi,

I am sorry that you ran into trouble but happy that you were able to diagnose 
and fix.

It turns out that digikam itself doesn't directly depend on any version of 
libcharls2.  The dependency appears to be picked up via libgdal30 and 
libgdcm3.0 -- which are themselves not directly used by digikam during build.



> 
> 
> -- System Information:
> Debian Release: 11.0
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-
debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT:de
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> 
=<162004644786.145723.13839356111643438268.report...@rs232.brz.gv.at>

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

Bug#984063: [Debian-med-packaging] Bug#984063: Closing bug (Was: Bug#984063: itk libtiff test issues (Was: Bug#984063))

[Steven Robbins]

On Saturday, January 22, 2022 12:15:25 P.M. CST Étienne Mollier wrote:
> Hi Andreas,
> 
> Andreas Tille, on 2022-01-16:
> > I think the roadmap that ITK4 will be deleted as soon as possible
> > is clear.  However, if it might serve as an intermediate means
> > to support some remaining dependencies temporarily I think it
> > is OK to do some tricks that would not be acceptable as long
> > term means.
> 
> I have been working on a rewrap of insighttoolkit4 to include
> the embedded tiff library, and with all the previous patching to
> address the initial issue described in this bug, the build went
> through.  The package should be in shape for upload tomorrow.

Neat!   I'm  sure that those using ITK 4 will appreciate your work.

As far as the existing Salsa repository is concerned: I would encourage you to 
consider using a v4 branch to maintain it.  If you prefer to do something 
else, that is also fine with me.  Just want to be clear that I haven't any 
objection to keeping v4 and v5 in a single repository.

-Steve


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

Bug#984063: itk libtiff test issues (Was: Bug#984063)

[Steven Robbins]

On Saturday, December 11, 2021 3:02:02 A.M. CST Étienne Mollier wrote:

> I considered pushing a change yesterday to disable those tests
> on insighttoolkit4, 

Let's please agree to NEVER do that.


> not to hide dust under the carpet, but to
> give a chance to reverse dependencies to make it to testing in a
> decent enough shape hopefuly.  

I appreciate the sentiment, but medical & scientific software -- probably the 
only consumers of ITK -- is generally the sort that you never want to 
knowingly ship with failed tests.  

-Steve


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

Bug#995829: Please lets coordinate itk4/itk5 issues (Was: Bug#984063)

[Steven Robbins]

On Monday, November 8, 2021 1:09:43 A.M. CST Andreas Tille wrote:
> Hi,
> 
> this mail from Jose
> 
> Am Sat, Nov 06, 2021 at 01:33:29AM +0100 schrieb Jose Luis Rivero:
> > Hello! Gazebo maintainer here, affected by this RC bug. Looking into
> > upstream repository there is a potential commit that can be used to patch
> > this problem until new versions land in Debian:
> > 
> > https://github.com/InsightSoftwareConsortium/ITK/commit/840f22feb351739359
> > a8fdb55304124823a3a8c9

Are you saying this will allow ITKv4 to be built with current gcc?  At 
present, ITK is about to be removed from testing tomorrow because it won't 
build.

> caused me having a look into the Git repository of insighttoolkit4[1].
> It is missing the NMU 4.13.3withdata-dfsg1-4.1 by Andreas Beckmann and
> there are now the first commits done by Steve for insighttoolkit5
> version 5.2.1 which was ITPed by Ghislain[2].

Yep, I've already uploaded ITK 5 to Debian.
https://ftp-master.debian.org/new/insighttoolkit5_5.2.1-1.html

> I think we need to discuss whether
> 
>   1. We want to simply replace insighttoolkit4 (which makes the
>  usage of the existing repository[1] sensible - but please inject
>  the NMU changes at least in d/changelog

Yes.  This is what I've communicated already 2-3 times on the list -- going 
back a year -- and in Ghislain's ITP.

https://lists.debian.org/debian-med/2020/11/msg00212.html
https://lists.debian.org/debian-med/2021/10/msg00149.html
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995829#10


>   2. We should start ITK5 in a new repository and maintain both
>  versions at least for some time in parallel until all packages
>  that currently use ITK4 are migrated.

If we can get ITK4 to build with current compilers, my suggestion would be to 
make a v4 branch in the current repository.  On the other hand, it's kind of 
11th hour here.  I'm much more focused on replacing v4 with v5 -- which, to be 
fair is already more than two years old.  ITK v4 is no longer supported 
upstream.
 
> In any case people who are interested in ITK should coordinate their
> work and talk to each other which I'd like to kindly invite you to
> do here on the Debian Med mailing list (any other channel is fine for
> sure).

Yes, I've always used debian-med for communications.  Additional hands are 
always welcomed.

-Steve


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

Bug#995829: ITK v5 in salsa

[Steven Robbins]

Hi,

I finally spent a few hours last night to get ITK v5 sources building.  There's 
still packaging work to do but I've pushed the interim results into salsa.  
Note: as previously discussed, python bindings are removed.

On Tuesday, October 12, 2021 1:34:22 A.M. CDT ghisv...@gmail.com wrote:

> I am indeed familiar with the existing ITK v4 packaging. I am also
> aware that the medical community is very unlickly to switch all their
> ITK dependencies from v4 to v5 overnight. Having handled some of these
> transitions upstream myself, I know from personal experience that these
> things take time.

Yep.  But ITK v4 has issues building with C++11 and is currently scheduled for 
removal from Debian.  I spent some time a week or two ago to see if I could fix 
this and it seems like more work than I'm willing to put in.  So I think 
Debian itself is going to force a removal of ITK v4.  For this reason, I've 
just committed v5 into mainline of salsa.  If desired, a branch can be made to 
continue v4 development.

-Steve


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

Bug#995829: ITP: itk5 -- extensive suite of software tools for image analysis

[Steven Robbins]

On Wednesday, October 6, 2021 10:18:15 A.M. CDT Ghislain Vaillant wrote:

> * Package name: itk5
>   Version : 5.2.1

Hi Ghislain.  You surely know that ITK v4 is already in Debian.  The salsa 
project is called "insighttoolkit" and was where we had intended to put the 
ITK v5 packaging.  Feel free to use it.

-Steve