Bug#820490: ITP: streflop -- STandalone REproducible FLOating-Point library

[Kip Warner]

Package: wnpp
Severity: wishlist
Owner: Kip Warner 

* Package name: streflop
  Version : 0.3
  Upstream Author : Nicolas Brodu 
* URL : http://nicolas.brodu.net/en/programmation/streflop/
* License : LGPL-2.1
  Programming Lang: C++
  Description : ITP: streflop -- STandalone REproducible FLOating-Point
library

A computer has a finite memory, and cannot represent an infinity of numbers. If
you add 0.1 + 0.1 in C++ you will probably not get the mathematical result 0.2.
The problem is that what you get depends on many parameters. On one
configuration, you may get something like 0.1995, and on another 0.1999. For
the vast majority of programs, these small differences do not matter. But if
you want to reproduce the same results twice, for a scientific experiment for
example, on different machines or even on the same machine but with different
options, then you have to be more careful. Much more careful, because these
small differences can occasionally accumulate quite fast.

The STandalone REproducible FLOating-Point library allows you to control how
the computations are done in C++. The goal is to make your programs give
reliable and reproducible results.

Bug#820490: PPA for streflop

[Kip Warner]

I should have also added that I have prepared a PPA for my attempt at
Debianization:

https://launchpad.net/~kip/+archive/ubuntu/streflop

Note that it fails to build on some versions of GCC due to a bug that
has since been patched upstream.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69715

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

Bug#820490: ITP: streflop -- STandalone REproducible FLOating-Point library

[Kip Warner]

On Mon, 2016-04-18 at 08:05 +0800, Paul Wise wrote:
> There are some embedded code copies of this already in Debian, it
> would be great if you could get them to use the package you are
> preparing instead of the code copies in the packages. Please also
> ensure the security team knows about these embedded code copies.
> 
> https://codesearch.debian.net/search?perpkg=1&q=streflop
> https://wiki.debian.org/EmbeddedCodeCopies

Hey Paul,

Nice to hear from you again. MegaGlest I will liaise with, but Spring
RTS is already aware of my effort to Debianize streflop:

https://springrts.com/mantis/view.php?id=5058

This is partially why I had prepared a PPA, for situations like that
(or at least for those developers using Ubuntu):

https://launchpad.net/~kip/+archive/ubuntu/streflop

After some discussion upstream (Spring RTS), they were at first
reluctant to rely on an external package (or even pkg-config at build
time for that matter!), but eventually they came around. Nevertheless,
I still haven't heard back from them on their efforts to test the
package.

-- 
Kip Warner -- Senior Software Engineer
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com



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

Bug#820490: ITP: streflop -- STandalone REproducible FLOating-Point library

[Kip Warner]

On Mon, 2016-04-18 at 09:51 +0800, Paul Wise wrote:
> Hmm, compile-time choice of CPU instructions doesn't sound like a 
> good idea, because if I build on an old crappy build machine or a 
> base-level  qemu virtual machine then I won't be getting SSE4 when I 
> run on my fast powerful desktop machine. Please ask upstream to 
> switch to runtime choice based on the available instructions on the
> user's CPU.

Upstream has been pretty much MIA for a long time. But even if I
managed to track him down, I reckon I know what he would say: Portable
floating point calculations can come at the expense of performance and
in order to mitigate this as much as possible, hardware level
optimizations are necessary and heavily tied to the method of
implementation.

The user can still select the best library during configure time. e.g.
with autoconf like so...

# Select correct library based on host hardware...
case "$host_cpu" in

# For Intel based hardware, use SSE2 hardware accelerated variant...
i?86) ;&
x86_64) 
PKG_CHECK_MODULES(
[streflop], [streflop-sse >= 0.3], [],
[AC_MSG_ERROR([streflop-sse >= 0.3 missing...])])
;;

# Otherwise fallback to software emulated variant...
*)
PKG_CHECK_MODULES(
[streflop], [streflop-soft >= 0.3], [],
[AC_MSG_ERROR([streflop-soft >= 0.3 missing...])])
;;
esac

> Please talk to upstream about the test suite stuff too.

Believe me, I've tried. He's MIA. The test suite I've "rigged up" in
one of my quilt patches might be sufficient, but we'll never know for
certain until he checks.

> The upstream website says that it uses the SoftFloat library for the
> software floating-point implementation. Since this is a modified
> embedded code copy too, please document this in the security team's
> embedded code copies file and talk to the upstreams about it. 
> Likewise for the old libc code and for Random.cpp.

Yup. And ideally the package would depend on SoftFloat, but I'm really
not sure how much of the latter he's modified or dependent on in the
way it was back when he wrote streflop.

> Great work convincing them!

Yeah. I think it will end up saving them time in not having to maintain
their own embedded copy and be responsible for it.

-- 
Kip Warner -- Senior Software Engineer
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com



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

Bug#1061511: gedit-source-code-browser-plugin: Upstream unmaintained for over a decade

[Kip Warner]

On Sat, 2024-01-27 at 12:46 +0100, Pietro Battiston wrote:
> I'm still using Gedit 44, I will try to investigate as soon as I have
> a 46 to test.

Hey Pietro,

Following up to see if there's been any new developments on getting the
plugin working with Gedit 46.

-- 
Kip Warner
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#1059953: libceres3: ceres-solver built without CUDA support

[Kip Warner]

Package: libceres3
Version: 2.1.0+really2.1.0+dfsg-2
Severity: wishlist
X-Debbugs-Cc: k...@thevertigo.com

Dear Maintainer,

The current ceres-solver source package may not always build with CUDA support,
even though it is enabled by default. In upstream's CMakeLists.txt CUDA is
enabled by default, but if it is not found it will silently continue building
with CUDA disabled.

The CUDA headers and libraries are not in the package's list of build
dependencies. It might be present anyways by accident on the system because
something else pulled it.

I think the solution is to simply explicitly add nvidia-cuda-dev to the Build-
Depends stanza of of the ceres-solver source package in debian/control.


-- System Information:
Debian Release: trixie/sid
  APT prefers mantic-updates
  APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 
'mantic'), (100, 'mantic-proposed'), (100, 'mantic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libceres3 depends on:
ii  libatlas3-base [liblapack.so.3]3.10.3-13ubuntu1
ii  libc6  2.38-1ubuntu6
ii  libcxsparse4   1:7.1.0+dfsg-3
ii  libgcc-s1  13.2.0-4ubuntu3
ii  libgoogle-glog0v6  0.6.0-2
ii  liblapack3 [liblapack.so.3]3.11.0-2build1
ii  libopenblas0-pthread [liblapack.so.3]  0.3.23+ds-3
ii  libstdc++6 13.2.0-4ubuntu3

libceres3 recommends no packages.

libceres3 suggests no packages.

-- no debconf information

Bug#1068632: dh-exec still broken

[Kip Warner]

Hello Debian Bug Tracking System,

I would like to keep this bug report open still.

I did try Craig's potential fix here:

   
https://salsa.debian.org/debian/dh-exec/-/commit/6f273ea8c362eea825a418c5a110a8dcd3959bfa

I can confirm that it does not work. dh_missing does not report any
warnings anymore, but the resulting package does not contain anything
that I specified in my .install file.

-- 
Kip Warner
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#1068632: dh-exec still broken

[Kip Warner]

On Mon, 2024-05-20 at 21:28 +1000, Craig Small wrote:
> OK, that's a start I guess.
> To debug this further, I'm going to need some sort of test setup.
> 
> You can see my test package
> at https://salsa.debian.org/csmall/test-dh-exec
> Obviously its a simple package but it does have a file that is
> created in the build phase and
> renamed in the install phase.
> 
> Could you have a look at it and see what differences there could be?
> I'm not seeing any errors with that example.

Hey Craig,

I'm afraid I'm not able to reproduce the issue with your minimal and
your patch to dh-exec-install-rename. It seemed to work fine.

My project's build environment is a lot more complicated and it would
be difficult to reduce down to a minimal.

Perhaps something to try is adding more debugging dh-exec output while
my package is building somehow?

-- 
Kip Warner
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#1068846: pykwalify aborts on KeyError: 'object'

[Kip Warner]

Package: pykwalify
Version: 1.8.0-2
Severity: important
X-Debbugs-Cc: k...@thevertigo.com

Dear Maintainer,

When attempting to validate the attached YAML minimal with pykwalify(1) against
the OpenAPI schema I noticed the pykwalify(1) binary fails to launch. It raises
a Python exception while trying to find the binary's entry point. This appears
to not be an upstream issue, but probably a problem with the packaging itself.

I am running Ubuntu Mantic, but I tried with the bookwork package pykwalify and
python3-pykwalify and same problem.

Here is how you can reproduce the issue:

$ sudo apt install pykwalify openapi-specification
$ pykwalify --data-file minimal.yaml --schema-file /usr/share/openapi-
specification/schemas/v3.0/schema.yaml
Traceback (most recent call last):
  File "/usr/bin/pykwalify", line 33, in 
sys.exit(load_entry_point('pykwalify==1.8.0', 'console_scripts',
'pykwalify')())
^^
  File "/usr/lib/python3/dist-packages/pykwalify/cli.py", line 98, in
cli_entrypoint
run(parse_cli())
  File "/usr/lib/python3/dist-packages/pykwalify/cli.py", line 85, in run
c.validate()
  File "/usr/lib/python3/dist-packages/pykwalify/core.py", line 183, in
validate
self._start_validate(self.source)
  File "/usr/lib/python3/dist-packages/pykwalify/core.py", line 225, in
_start_validate
root_rule = Rule(schema=self.schema)

  File "/usr/lib/python3/dist-packages/pykwalify/rule.py", line 66, in __init__
self.init(schema, "")
  File "/usr/lib/python3/dist-packages/pykwalify/rule.py", line 408, in init
self.init_type_value(t, rule, path)
  File "/usr/lib/python3/dist-packages/pykwalify/rule.py", line 713, in
init_type_value
self.type_class = type_class(v)
  ^
  File "/usr/lib/python3/dist-packages/pykwalify/types.py", line 49, in
type_class
return _types[type]
   ~~^^
KeyError: 'object'


-- System Information:
Debian Release: trixie/sid
  APT prefers mantic-updates
  APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 
'mantic'), (100, 'mantic-proposed'), (100, 'mantic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages pykwalify depends on:
ii  python33.11.4-5
ii  python3-pykwalify  1.8.0-2

pykwalify recommends no packages.

pykwalify suggests no packages.

-- no debconf information
openapi: 3.0.0
info:
  title: Sample API
  description: Optional multiline or single-line description in 
[CommonMark](http://commonmark.org/help/) or HTML.
  version: 0.1.9
servers:
  - url: http://api.example.com/v1
description: Optional server description, e.g. Main (production) server
  - url: http://staging-api.example.com
description: Optional server description, e.g. Internal staging server for 
testing
paths:
  /users:
get:
  summary: Returns a list of users.
  description: Optional extended description in CommonMark or HTML.
  responses:
'200':# status code
  description: A JSON array of user names
  content:
application/json:
  schema: 
type: array
items: 
  type: string
id: https://spec.openapis.org/oas/3.0/schema/2019-04-02
$schema: http://json-schema.org/draft-04/schema#
description: Validation schema for OpenAPI Specification 3.0.X.
type: object
required:
  - openapi
  - info
  - paths
properties:
  openapi:
type: string
pattern: ^3\.0\.\d(-.+)?$
  info:
$ref: '#/definitions/Info'
  externalDocs:
$ref: '#/definitions/ExternalDocumentation'
  servers:
type: array
items:
  $ref: '#/definitions/Server'
  security:
type: array
items:
  $ref: '#/definitions/SecurityRequirement'
  tags:
type: array
items:
  $ref: '#/definitions/Tag'
uniqueItems: true
  paths:
$ref: '#/definitions/Paths'
  components:
$ref: '#/definitions/Components'
patternProperties:
  '^x-': {}
additionalProperties: false
definitions:
  Reference:
type: object
required:
  - $ref
patternProperties:
  '^\$ref$':
type: string
format: uri-reference
  Info:
type: object
required:
  - title
  - version
properties:
  title:
type: string
  description:
type: string
  termsOfService:
type: string
format: uri-reference
  contact:
$ref: '#/definitions/Contact'
  license:
$ref: '#/definitions/License'
  version:
type: string
patternProperties:
  '^x-':

Bug#1059953: libceres3: ceres-solver built without CUDA support

[Kip Warner]

On Thu, 2024-01-04 at 16:17 +0100, Francois Mazen wrote:
> The nvidia-cuda-dev package is part of the non-free area in the
> Debian archive [1] because if does not comply with the DFSG [2].
> If we set it as a build dependency of ceres-solver (and also the
> nvidia runtime as a package dependency), it would move ceres-solver
> from the "main" area to the "contrib" area of the Debian archive [3]
> which is likely unwanted.

Perhaps another option is having a libceres-cuda-dev / libceres3-cuda
packages that are built with CUDA?

-- 
Kip Warner
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#990852: nicotine-plus appears to be maintained again: upgrade to latest version

[Kip Warner]

On Fri, 2021-07-09 at 13:05 +0200, boyska wrote:
> Package: nicotine
> Severity: normal
> 
> Dear Maintainer,

Hey Boyska,

> I see that updates to the nicotine package are pretty low, and it has
> even been removed from unstable.
> However, I see activity on  
> https://github.com/nicotine-plus/nicotine-plus
> and it seems to me that nicotine should now support gtk3
> 
> So I think that removing the package from the repositories is not the
> only choice; upgrading to new version with modern dependencies should
> be 
> possible. It would be fantastic if you could do that!

I've actually been trying to write Josselin a number of times since
June 2020 about this, but I haven't managed to get a substantive
response yet. I'm not sure if he's still the Debian maintainer or if he
is gone now.

Fortunately the project has been resurrected and is actively
maintained. It's even Debianized for a stable and unstable PPA. But
that's not much help to Debian users if they don't know about it
because we can't get it back into the respository.

-- 
Kip Warner -- Senior Software Engineer
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#992478: autopkgtest: Possible race condition leading to build-needed being ignored

[Kip Warner]

Package: autopkgtest
Version: 5.17
Severity: important
Tags: upstream
X-Debbugs-Cc: k...@thevertigo.com

Dear Maintainer,

My source tree contains DEP-8 tests in debian/tests. My debian/tests/control
contains the following test:

Tests: test-in-tree-unit-tests.sh
Depends: @builddeps@, postgresql-13
Restrictions: rw-build-tree, build-needed, allow-stderr, isolation-
container

I have another DEP-8 test, but it tests the installed artifacts without any
issue. The above test, however, calls a simple one liner (after the sh-bang),
to test local in-tree unit tests:

make -j check || { find . -iname "test-suite.log" -exec cat {} \; ; exit
99; }

Some times these tests are run as expected. Other times they don't ever run.
When they don't, it is because autopkgtest reports a failure when make(1) is
unable to run the `check` target. It appears as though there is no Makefile.

When I shell into the test bed into the location in which make was being run,
the source tarball has been unpacked as expected, but it has not been
configured. That is, I see my Makefile.am and other source files, but not the
generated Makefile or any other files generated after ./configure does its
thing.

Sometimes this happens and sometimes it does not. There does not appear to be
any rhyme or reason to it, so I suspect this may be a race condition.

-- System Information:
Debian Release: bullseye/sid
  APT prefers hirsute-updates
  APT policy: (500, 'hirsute-updates'), (500, 'hirsute-security'), (500,
'hirsute-proposed'), (500, 'hirsute'), (100, 'hirsute-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages autopkgtest depends on:
ii  apt-utils   2.2.4ubuntu0.1
ii  libdpkg-perl1.20.9ubuntu1
ii  procps  2:3.3.16-5ubuntu3.1
ii  python3 3.9.4-1
ii  python3-debian  0.1.39

Versions of packages autopkgtest recommends:
ii  autodep8  0.24ubuntu1

Versions of packages autopkgtest suggests:
ii  fakemachine   0.0~git20201127.9e6ee78-1
ii  lxc   1:4.0.6-0ubuntu1
ii  lxd   1:0.9
ii  ovmf  2020.11-4
ii  ovmf-ia32 2020.11-4
ii  qemu-efi-aarch64  2020.11-4
ii  qemu-efi-arm  2020.11-4
ii  qemu-system   1:5.2+dfsg-9ubuntu3.1
ii  qemu-utils1:5.2+dfsg-9ubuntu3.1
ii  schroot   1.6.10-11ubuntu2
ii  vmdb2 0.22-1

Bug#992478: autopkgtest logs, pass and fail

[Kip Warner]

Dear Maintainer,

Apologies for the delay in providing logs. It took several days to be
able to reproduce the above problem.

Here is an example of a pass:

   https://pastebin.com/edit/Nnqkhsdr

Here is an example of a fail:

   https://pastebin.com/FZ5qRQ1m

These are both in respect of the same source package with nothing
material changed between runs.

I'll draw your attention to L2996-3002 of the pass log, but apparently
not in the fail. I am not sure if these lines are important to take
note of.

-- 
Kip Warner -- Senior Software Engineer
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#992478: autopkgtest logs, pass and fail

[Kip Warner]

On Mon, 2021-08-23 at 10:36 +0200, Paul Gevers wrote:
> Hi Kip,

Hey Paul,

> Can you please provide the command line that you used?

Certainly:

   $ autopkgtest @/home/me/Projects/sbuild/autopkgtest/autopkgtest.cfg &> 
log.txt

And the autopkgtest.cfg is as follows:

   $ cat /home/me/Projects/sbuild/autopkgtest/autopkgtest.cfg
   --shell-fail
   --apt-upgrade
   --setup-commands=/home/me/Projects/sbuild/scripts/setup.sh
   --
   qemu
   --ram-size=8192
   --cpus=8
   --show-boot
   /home/me/Projects/sbuild/images/autopkgtest-hirsute-amd64.img
   --qemu-options=-enable-kvm

And inside of the setup.sh:

   $ cat /home/me/Projects/sbuild/scripts/setup.sh
   #!/bin/bash
   
   # Bail on errors...
   set -e
   
   apt install squid-deb-proxy-client avahi-utils --assume-yes
   echo 'Acquire::http::proxy "http://my-workstation:3142";;' | tee
   /etc/apt/apt.conf.d/01acng > /dev/null
   sed -i 's/^nameserver.*$/nameserver 192.168.1.1/' /etc/resolv.conf
   
   apt install software-properties-common gnupg2 --assume-yes --no-
   install-recommends
   
   ( ... add a private PPA ... )
   
   add-apt-repository ppa:pistache+team/unstable --component main --component 
main/debug


> I'm seeing this twice in the successful log while it's only there once
> in the failed one and I don't understand where it's coming from:
>
> Adding repository.
> Adding deb entry to
> /etc/apt/sources.list.d/pistache_team-ubuntu-unstable-hirsute.list
> Adding disabled deb-src entry to
> /etc/apt/sources.list.d/pistache_team-ubuntu-unstable-hirsute.list
> Adding key to /etc/apt/trusted.gpg.d/pistache_team-ubuntu-unstable.gpg
> with fingerprint 2EEA295DCBF66B6DE281E0A193E2268577BD194B
> 
> Also, I'm even missing the "build needed" log line in your successful
> run. Which backend are you using?

I'm using the QEMU backend with both host and guest amd64. I've also
regenerated the logs, this time redirecting stderr and stdout to the
log. This time they shouldn't be truncated, though I did make some
redactions because this is a non-free source package:

   Pass (1/2):
  https://pastebin.com/Nnqkhsdr
   
   Pass (2/2):
  https://pastebin.com/jfEFh6Wy
   
   Fail:
  https://pastebin.com/FZ5qRQ1m

-- 
Kip Warner -- Senior Software Engineer
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#929593: RFP: pistache -- elegant C++ REST framework

[Kip Warner]

Package: wnpp
Severity: wishlist

* Package name: pistache
  Version : 0.0.001
  Upstream Author : Dennis Jenkins 
* URL : https://www.github.com/oktal/pistache
* License : Apache-2.0
  Programming Lang: (C++)
  Description : elegant C++ REST framework

Pistache is a C++ REST framework originally written by Mathieu Stefani at
Datacratic, since maintained by other volunteers. It is written in pure C++11
with no external dependency and provides a low-level HTTP abstraction. Pistache
provides both an HTTP client and server that can be used to create and query
complex web and REST APIs.

It is free as in freedom and released under the Apache 2.0 license.

It should build the following packages:

libpistache0 - runtime library
libpistache-dev - C++ development headers

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



Upstream has already provided partial Debianization for user convenience via a
stable and unstable PPA, but we are not DPM subject matter experts and would
like to see the project enter the official Debian repositories so everyone can
use it.

Our current users increase daily and vary from hobbyist router firmware hackers
to large fintech firms and the commercial music space.

Bug#947279: apt SIGABRT's with `malloc(): unsorted double linked list corrupted`

[Kip Warner]

bol table info available.
   #16 0x557faf17e3ea in ?? ()
   No symbol table info available.
   #17 0x7fd1dde681e3 in __libc_start_main (main=0x557faf17e320,
   argc=3, argv=0x7ffc2ecb3718, init=, fini=, rtld_fini=, stack_end=0x7ffc2ecb3708) at
   ../csu/libc-start.c:308
   self = 
   result = 
   unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0,
   3588779076796669643, 94006886786240, 140721093555984, 0, 0,
   7262868277543689931, 7246575941430795979}, mask_was_saved = 0}},
   priv = {pad = {0x0, 0x0, 0x7ffc2ecb3738, 0x7fd1de4fa190}, data =
   {prev = 0x0, cleanup = 0x0, canceltype = 785069880}}}
   not_first_call = 
   #18 0x557faf17e4ee in ?? ()
   No symbol table info available.

It is apparent that a lot of information has been optimized out by the
compiler. But based on the signatures in #8 and #9, I'm guessing this
may have something to do with saving the state file.

I am using Ubuntu Eoan (19.10) on amd64 with kernel 5.3.0-24-lowlatency 
#26-Ubuntu and libc6 2.30-0ubuntu2.

Yours truly,

-- 
Kip Warner -- Senior Software Engineer
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#947279: apt SIGABRT's with `malloc(): unsorted double linked list corrupted`

[Kip Warner]

On Mon, 2019-12-23 at 23:36 +0100, Julian Andres Klode wrote:
> The coredump should be useless, as this sounds like a memory
> corruption issue, which would need debugging in valgrind to find the
> first illegal write.

I can make available any of the following, should it help:

   Architecture, CoreDump, ExecutablePath, ProblemType, ProcEnviron,
   Signal, Date, ExecutableTimestamp, ProcCmdline, ProcMaps, Uname,
   DistroRelease, _LogindSession, ProcCwd, ProcStatus

-- 
Kip Warner -- Senior Software Engineer
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#992478: autopkgtest logs, pass and fail

[Kip Warner]

On Thu, 2022-02-03 at 13:37 +0100, Paul Gevers wrote:
> I ran across this issue again. Just a sanity check, you did take care
> of this, right?
> 
> """
> rw-build-tree

Hey Paul,

Yes, indeed. The test's Restrictions stanza is as follows: rw-build-
tree, build-needed, allow-stderr, isolation-container.

-- 
Kip Warner -- Senior Software Engineer
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#992478: autopkgtest logs, pass and fail

[Kip Warner]

On Sat, 2022-02-05 at 08:44 +0100, Paul Gevers wrote:
> Sorry, that was not what I meant. I spotted rw-build-tree and noticed
> in the description that *you* have to take care of things if you use
> this restriction. Did you do that?

Hey Paul,

This is all the aforementioned DEP-8 test does. It's a trivial two-
liner:

   # Bail on any errors...
   set -e
   
   # Perform all in-tree unit tests or show log on failure...
   make -j check || { find . -iname "test-suite.log" -exec cat {} \; ; exit 99; 
}

All build artifacts are automatically cleaned up when debian/rules
clean is invoked. Nothing in these unit tests should affect any other
DEP-8 test, nor affect any binary packages produced by the build tree
in the future as far as I am aware.

-- 
Kip Warner -- Senior Software Engineer
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#994151: yt-dlp in Debian

[Kip Warner]

Hey Andreas,

I can't thank you enough for helping to Debianize the source of yt-dlp.
My friend Paul (cc'd) pointed me to it.

   https://salsa.debian.org/debian/yt-dlp

Do you have a rough estimate when you anticipate it will be accepted
downstream?

Yours truly,

-- 
Kip Warner -- Senior Software Engineer
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#994151: yt-dlp in Debian

[Kip Warner]

On Sat, 2021-12-18 at 08:47 +0100, Andreas Tille wrote:
> I admit I do not have any estimation.  While I did the initial
> packaging work I'm swamped with so many Debian packages that I'm
> hesitating to take over the maintenance (please see the according bug
> report[1])  

I totally understand. I'll also be sure not to request your mentorship
or sponsorship with two other upstream projects I'm co-maintainer of
until long after things have settled down for you!

> I simply took over since the former maintainer of youtube-dl and my
> friend died under dramatic circumstances last year from Covid and I
> considered maintaining youtube-dl as some last service I could do for
> him.

That's a very honourable thing to do. I actually totally forgot about
that, but I seem to recall someone had mentioned that. I think most of
the community does not know that, and it might be worth asking youtube-
dl maintainers, whomever is left, that is, to post something mentioning
that on the issue tracker.

> However, I see no capacity for myself to be the *main* Uploader of
> yt-dlp.  I'm seeking someone else who can join me in that effort and
> before nobody has shown up I will not consider uploading.

I would suggest Paul, but only Paul can decide that. He knows much more
about Debianization than I do and, unlike me, is an actual Debian
developer.

I suppose what could be done quite easily is to create a PPA that
builds from your Salsa repository. A lot of people would use it and it
would attract more attention to the project. Possibly the kind you need
in order to get assistance.
> 
> PS: I would love to forward my mail to the bug report log[1] but I'm
>     not sure whether you give me permission to expose your e-mail
>     address and the content of your mail there.

No problem and thanks for asking.

-- 
Kip Warner -- Senior Software Engineer
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#994151: yt-dlp in Debian

[Kip Warner]

On Sun, 2021-12-19 at 09:22 +0800, Paul Wise wrote:
> FTR: I don't really have the time for this, and using it from a git
> checkout is relatively easy so I don't have motivation to package it.

Andreas, I can help you setup a PPA, if you like. I need it anyways for
my non-free project:

   https://www.heliosmusic.io
   

-- 
Kip Warner -- Senior Software Engineer
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#1001933: yt-dlp in Debian

[Kip Warner]

On Sun, 2021-12-19 at 11:42 +0100, Andreas Tille wrote:
> Yes, that should be granted.  Feel free to post this to the RFP bug
> once you have it up and running.  

Ok, will do.

> However, I wonder whether it would be even less work for you to
> simply care for updating the salsa repository and ask me for
> sponsering the package from there to establish some co-maintenance.

The problem is that my packaging kung-fu is not as strong as Paul's (or
probably yours either). I can package things I need for personal or
work use relatively well, but I don't know whether it would actually
meet DPM quality controls. I'm probably the wrong person to ask.

-- 
Kip Warner -- Senior Software Engineer
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#1001933: yt-dlp in Debian

[Kip Warner]

On Mon, 2021-12-20 at 08:25 +0100, Andreas Tille wrote:
> Hi Kip,

Hey Andreas,

> May be you want to look here:
> 
>    https://salsa.debian.org/med-team/community/MoM/-/wikis/home
> 
> I'm fine to teach you about packaging and make an exemption from the
> requirement that it needs to be Debian Med related.
> 
> Moreover the packaging itself is just done.  In principle you just
> need to clone the repository and run
> 
>    sudo apt install routine-update
>    routine-update
> 
> on it and test the result - if it works ping me.
> 
> I think the technical knowledge you need to setup a PPA is higher
> than this.

Sorry for the communication latency. I had my head buried in a debugger
the last few days.

I think you are probably right. What I'll do is circle back to you
within the next few weeks to become a student. I need this package
anyways, and it's always good to learn more about the DPM.

-- 
Kip Warner -- Senior Software Engineer
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#288778: [DPKG] Add --quiet option to suppress chatter during install/upgrade

[Kip Warner]

I am in agreement with the O/P that too much verbosity has in the past
made people, including myself, miss errors raised within maintainer
scripts. 

Besides his suggestion for a --quiet option, another solution could be
to colourize the output on terminals that support it (e.g. red on
errors). But I don't know how this could be implemented without
modifying every maintainer script (not desirable).

-- 
Kip Warner -- Senior Software Engineer
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#1016003: yt-dlp: create youtube-dl compatability package

[Kip Warner]

On Mon, 2022-07-25 at 08:06 +0200, michel wrote:
> Several applications expect to find youtube-dl, not yt-dlp. Yet, the
> two are almost the same.
> It would be nice to have a new package, that wraps around yt-dlp and
> make it look like youtube-dl.

I think the way to handle this might be for the yt-dlp source package
to also generate a virtual package with a Provides stanza for youtube-
dl, like so:

   
https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides

Of course this assumes that the two interfaces are the same. Right now
for 99 % of users in the simple ways that they use the two, I think
they probably are. Over time though they will inevitably diverge in the
same way mplayer's descendants did, or ffmpeg and libav's CLI tools.

-- 
Kip Warner
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#927839: RFS: pistache/0.0.001

[Kip Warner]

Package: sponsorship-requests
Severity: wishlist

I am looking for a sponsor for package pistache. I am an upstream co-
maintainer. Jonathan Carter  has offered to do this if
he has time.

Pistache is a C++ REST framework originally written by Mathieu Stefani at
Datacratic, since maintained by other volunteers. It is written in pure C++11
with no external dependency and provides a low-level HTTP abstraction.

Pistache provides both an HTTP client and server that can be used to create and
query complex web and REST APIs.

It is free as in freedom and released under the Apache 2.0 license.

 * Package name: pistache
   Version : 0.0.001
   Upstream Author : Dennis Jenkins 
 * URL : https://www.github.com/oktal/pistache
 * License : Apache-2.0
   Section : libdevel

It builds the following packages:

libpistache0 - runtime library
libpistache-dev - C++ development headers

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

<https://mentors.debian.net/package/pistache>

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

$ dget -x
https://mentors.debian.net/debian/pool/main/p/pistache/pistache_0.0.001-kip1~unstable.dsc

More information about Pistache can be obtained from
https://www.github.com/oktal/pistache.

Yours truly,

Kip Warner



-- System Information:
Debian Release: buster/sid
  APT prefers disco-updates
  APT policy: (500, 'disco-updates'), (500, 'disco-security'), (500, 'disco')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.0.0-13-lowlatency (SMP w/8 CPU cores; 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 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1061511: gedit-source-code-browser-plugin: Upstream unmaintained for over a decade

[Kip Warner]

Package: gedit-source-code-browser-plugin
Version: 3.0.3-6
Severity: important
Tags: upstream
X-Debbugs-Cc: k...@thevertigo.com

Dear Maintainer,

Thank you for continuing to maintain the Debian gedit-source-code-
browser-plugin:

As you may be aware there has been no activity in more than a decade
upstream. Bit rot is making the plugin no longer usable with recent
versions of GEdit.

There is a fork that is maintained by ildar below:

   https://github.com/ildar/gedit-source-code-browser

Unfortunately I am advised by the maintainer that it too is currently
no longer compatible with the latest GEdit. 

   
https://github.com/MicahCarrick/gedit-source-code-browser/issues/40#issuecomment-1909725836

I have asked ildar if he intends to continue maintaining it. If he
does, then you you might want to consider switching from the old
upstream to ildar's release.

-- System Information:
Debian Release: trixie/sid
  APT prefers mantic-updates
  APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500,
'mantic'), (100, 'mantic-proposed'), (100, 'mantic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages gedit-source-code-browser-plugin depends on:
ii  dconf-gsettings-backend [gsettings-backend]   0.40.0-4
ii  gedit 44.2-1
ii  python3   3.11.4-5
ii  universal-ctags [ctags]   5.9.20210829.0-1
ii  xfconf-gsettings-backend [gsettings-backend]  4.16.0-2vanir1~21.04

gedit-source-code-browser-plugin recommends no packages.

gedit-source-code-browser-plugin suggests no packages.

-- no debconf information

-- 
Kip Warner
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#1061511: gedit-source-code-browser-plugin: Upstream unmaintained for over a decade

[Kip Warner]

On Fri, 2024-01-26 at 08:11 +0100, Pietro Battiston wrote:
> Dear Kip,
> 
> thanks for your mail and references. I have asked ildar, in the bug
> you referred to, additional details on what broke in the last Gedit
> versions. If anybody is able to fix his fork, or produce another one
> and make some minimal commitment to update it (or accept
> contributions for it) over time, I will be happy to switch the Debian
> package to it.
> 
> The best thing would clearly be having an up to date fork owned by a
> project, rather than an individual who (legitimately) writes "I
> personally don't plan to maintain this regularly". I would be happy
> to be in such a project and occasionally contribute - while I would
> not want to simply package my personal fork.

Thanks Pietro. It might well be that it's only a few trivial lines of a
patch to get it working again with the latest GEdit. I don't know
though because it's not an area I'm familiar with. I just know that his
last fix kept it alive for a while.

-- 
Kip Warner
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#1085128: RFP: python3-gravatar -- A library that provides a Python 3 interface for the Gravatar APIs.

[Kip Warner]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: k...@thevertigo.com

* Package name: python3-gravatar
  Version : 1.0.4
  Upstream Contact: Name 
* URL : https://github.com/pabluk/libgravatar
* License : GPLv3
  Programming Lang: Python
  Description : A library that provides a Python 3 interface for the
Gravatar APIs.

A library that provides a Python 3 interface for the Gravatar API.

  https://github.com/pabluk/libgravatar
  https://pypi.org/project/libgravatar/
  https://libgravatar.readthedocs.io/en/latest/

Note that this is not the C++ KDE library by the same upstream name,
libgravatar:

  https://invent.kde.org/pim/libgravatar
  https://tracker.debian.org/pkg/libgravatar

Bug#1061511: heguangyu5's gedit-source-code-browser-plugin fork

[Kip Warner]

Hello Pietro,

I have some good news for you. It was brought to my attention today by
Ildar that heguangyu5 has created a successful upstream fix for gedit-
source-code-browser-plugin. I tested just now with Gedit 46.2 on Ubuntu
Noble and it works fine.

All I needed to do was take the current packaging, bump the package
version in d/changelog, and remove all of the old patches except 0001-
Retrieve-data-in-the-right-folder.patch from d/patches/series. The then
package built without any quilt errors and installed cleanly.

Yours truly,

-- 
Kip Warner
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#1061511: heguangyu5's gedit-source-code-browser-plugin fork

[Kip Warner]

On Thu, 2024-10-31 at 12:13 +0100, Pietro Battiston wrote:
> Wonderful news, thanks Kip!
> 
> What if I created a new Github (or gitlab.gnome.org?) project with
> heguangyu5's fork and the three of us as maintainers? This would
> likely reduce the chances that Debian's upstream dies again, and
> possibly push other people to contribute future fixes...
> 
> If we want to do this I would also:
> - propose heguangyu5 to join us
> - contact MicahCarrick and ask if he'd rather just transfer his
> project to us, to simplify the work also of other distributions

Yes, I think that's a good idea. I'm fine being a contributor, although
I imagine our first focus should be on just getting it repaired and
packaged first before adding new features.

I think it's also a good idea if you ask them to join too, as proposed,
so that we can consolidate everyone's efforts on a single fork, ideally
remove the other ones that are abandoned, and everything is in a single
canonical location.

-- 
Kip Warner
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#1061511: heguangyu5's gedit-source-code-browser-plugin fork

[Kip Warner]

On Wed, 2024-10-30 at 13:29 -0700, Kip Warner wrote:
> It was brought to my attention today by Ildar that heguangyu5 has
> created a successful upstream fix for
> gedit-
> source-code-browser-plugin.

It would probably help if I provided the upstream link!

   https://github.com/heguangyu5/gedit-source-code-browser/

-- 
Kip Warner
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#1094898: context: mtxrun running fails

[Kip Warner]

On Sat, 2025-02-01 at 23:54 +0100, Hilmar Preuße wrote:
> My one was just a a try too. The luametatex package (as it is) is now
> in the Debian archive for about 0,5 years and seems to be working. I
> see a timely correlation between the mimalloc upload and the
> luametatex crash. There could be a causal relationship
> 
> Let's wait for test results from the submitter.

Based on the strace(1) output, my guess is this is a problem with
mismatched symbols at runtime:

   Symbol `_UPT_accessors' has different size in shared object,
   consider re-linking

You may want to look at how soname versioning was being performed.
Usually GNU Libtool is pretty good in checking for ABI changes that
would break runtime, but I don't know if your build environment uses
it.

-- 
Kip Warner
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#1094898: context: mtxrun running fails

[Kip Warner]

On Sat, 2025-02-01 at 18:46 +0100, Hilmar Preuße wrote:
> I was afraid, that something like this could happen. On [1] I've put
> a luametatex package, which is linked statically with mimalloc. Could
> you try if it solves your issue?

Hilmar, just a shot in the dark here, but you might want to check to
see if certain CPU extensions were enabled at compile time, like AVX,
etc. SIGILL's are sometimes raised when the host machine hits an
instruction its CPU doesn't recognize but is found in the ISA of other
similar CPUs.

-- 
Kip Warner
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#1091241: pistache: FTBFS on armhf: dh_auto_test: error: cd obj-arm-linux-gnueabihf && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 meson test --no-suite=network returned exit c

[Kip Warner]

On Mon, 2024-12-23 at 18:42 +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, this package failed to build
> on armhf.

Hey Lucas,

Can you please pull the latest upstream? I'm a Pistache maintainer. We
released 0.4.26 this morning. Version 0.0.5 is pretty ancient.

-- 
Kip Warner
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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