Bug#1067112: fangfrisch: missing dependency on clamdscan

[Joost van Baal-Ilić]

severity 1067112 wishlist
retitle 1067112 fangfrisch: mention clamdscan in Suggests or Recommends and/or 
Enhances
thanks


Op Mon, Mar 18, 2024 at 10:09:34PM -0400 schreef Scott Kitterman:
> On Monday, March 18, 2024 11:39:04 AM EDT Joost van Baal-Ilić wrote:
> > Package: fangfrisch
> > Version: 1.9.0-1
> > Severity: normal
> > 
> > Hi,
> > 
> > Thanks for maintaining fangfrisch!
> > 
> > When running
> > 
> >  clamav@donmel:~$ fangfrisch --conf /etc/fangfrisch.conf initdb
> > 
> > , in order to get fangfrisch properly setup, the fangfrisch software fails
> > with:
> > 
> >  Mar 18 16:01:29 donmel fangfrisch[143542]: ERROR: /bin/sh: 1: clamdscan:
> > not found
> > 
> > .  Please add clamdscan to fangfrisch's debian/control "Depends: ": that
> > should fix this.
> 
> That's not a configuration file provided by Debian, so I don't think this is 
> a 
> valid bug in Debian (it's not the upstream default either).  It's quite 
> possible to use fangfrisch to just download data on one machine for further 
> distribution on an internal network.
> 
> It should at least be Suggests and probably Recommends though.  It could also 
> probably stand to have Enahnces: clamdscan.

Indeed, I failed to mention I have specified

 [DEFAULT]
 db_url = sqlite:var/lib/fangfrisch/db.sqlite
 local_directory = /var/lib/clamav
 max_size = 10MB
 on_update_exec = clamdscan --reload
 on_update_timeout = 42

 [...]

in my /etc/fangfrisch.conf .  Suggests / Recommends sounds perfectly fine, as
does Enhances: clamdscan.

Thanks, Bye,

Joost

Bug#983870: Picking up webdriver-manager packaging

[Joost van Baal-Ilić]

Hi Ananthu!

On Thu, Mar 21, 2024 at 11:38:36PM +0530, Ananthu C V wrote:
> 
> It seems that you are no longer intending to work on this.
> I, on the other hand, require webdriver manager for packaging 
> lightnovel-crawler.
> So if you don't mind, can I pick this up?

Sure, be my guest.  I hope my comments in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983870#12 help you get
started.

Happy hacking!

Bye,

Joost

Bug#1067112: fangfrisch: missing dependency on clamdscan

[Joost van Baal-Ilić]

Package: fangfrisch
Version: 1.9.0-1
Severity: normal

Hi,

Thanks for maintaining fangfrisch!

When running

 clamav@donmel:~$ fangfrisch --conf /etc/fangfrisch.conf initdb

, in order to get fangfrisch properly setup, the fangfrisch software fails with:

 Mar 18 16:01:29 donmel fangfrisch[143542]: ERROR: /bin/sh: 1: clamdscan: not 
found

.  Please add clamdscan to fangfrisch's debian/control "Depends: ": that should
fix this.

Thanks, Bye,

Joost

Bug#1066857: doc-debian: /usr/share/doc/debian/bug-reporting.txt should not be compressed

[Joost van Baal-Ilić]

Hi Vincent,

Thanks for this nice bugreport, will get to it.

Bye,

Joost

On Thu, Mar 14, 2024 at 02:31:11PM +0100, Vincent Lefevre wrote:
> Package: doc-debian
> Version: 11.3+nmu1
> Severity: wishlist
> 
> The bug-reporting.txt file is rather small, thus it does not need to
> be compressed. Having it compressed like currently breaks references,
> such as in the apt-get(8) man page, which says
> 
>   APT bug page[1]. If you wish to report a bug in APT, please see
>   /usr/share/doc/debian/bug-reporting.txt or the reportbug(1) command.
> 
> and in /usr/share/doc/debian/FAQ/support.en.html too, while only
> /usr/share/doc/debian/bug-reporting.txt.gz exists.
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
> 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
> (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> doc-debian depends on no packages.
> 
> Versions of packages doc-debian recommends:
> ii  debian-faq  11.1
> 
> Versions of packages doc-debian suggests:
> ii  atril [postscript-viewer]   1.26.2-1.1+b1
> ii  elinks [www-browser]0.16.1.1-4.1+b2
> ii  firefox [www-browser]   123.0.1-1
> hi  firefox-esr [www-browser]   92.0-local
> ii  ghostscript [postscript-viewer] 10.02.1~dfsg-3+b1
> ii  gv [postscript-viewer]  1:3.7.4-2+local1
> ii  links [www-browser] 2.29-1+b3
> ii  links2 [www-browser]2.29-1+b3
> ii  lynx [www-browser]  2.9.0rel.0-2+b1
> ii  qpdfview-ps-plugin [postscript-viewer]  0.5.0+ds-4
> ii  w3m [www-browser]   0.5.3+git20230121-2+b3
> ii  zathura-ps [postscript-viewer]  0.2.7-2+b2
> 
> -- no debconf information
> 
> -- 
> Vincent Lefèvre  - Web: 
> 100% accessible validated (X)HTML - Blog: 
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
> 

Bug#1062555: liboprf: NMU diff for 64-bit time_t transition

[Joost van Baal-Ilić]

Hi Benjamin,

Excellent, thank you!

Bye,

Joost

On Wed, Feb 28, 2024 at 04:06:10PM +, Benjamin Drung wrote:
> Source: liboprf
> Dear maintainer,
> 
> Please find attached a final version of this patch for the time_t
> transition.  This patch is being uploaded to unstable.
> 
> Note that this adds a versioned build-dependency on dpkg-dev, to guard
> against accidental backports with a wrong ABI.
> 
> Thanks!
> 
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.5.0-21-generic (SMP w/16 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: unable to detect

> diff -Nru liboprf-0.1+git20231001.0da3e2b/debian/changelog 
> liboprf-0.1+git20231001.0da3e2b/debian/changelog
> --- liboprf-0.1+git20231001.0da3e2b/debian/changelog  2023-10-04 
> 14:07:26.0 +
> +++ liboprf-0.1+git20231001.0da3e2b/debian/changelog  2024-02-28 
> 16:06:06.0 +
> @@ -1,3 +1,10 @@
> +liboprf (0.1+git20231001.0da3e2b-1.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Rename libraries for 64-bit time_t transition.  Closes: #1062555
> +
> + -- Benjamin Drung   Wed, 28 Feb 2024 16:06:06 +
> +
>  liboprf (0.1+git20231001.0da3e2b-1) unstable; urgency=low
>  
>* New upstream git snapshot (thanks again Thorsten Alteholz for
> diff -Nru liboprf-0.1+git20231001.0da3e2b/debian/control 
> liboprf-0.1+git20231001.0da3e2b/debian/control
> --- liboprf-0.1+git20231001.0da3e2b/debian/control2023-10-04 
> 14:07:26.0 +
> +++ liboprf-0.1+git20231001.0da3e2b/debian/control2024-02-28 
> 16:06:06.0 +
> @@ -3,14 +3,17 @@
>  Priority: optional
>  Maintainer: Joost van Baal-Ilić 
>  Uploaders: Stefan Marsiske 
> -Build-Depends: debhelper-compat (= 13), dh-exec (>=0.3), pkgconf, 
> libequihash-dev, libsodium-dev
> +Build-Depends: dpkg-dev (>= 1.22.5), debhelper-compat (= 13), dh-exec 
> (>=0.3), pkgconf, libequihash-dev, libsodium-dev
>  Standards-Version: 4.5.1
>  Homepage: https://github.com/stef/liboprf
>  Rules-Requires-Root: no
>  Vcs-Browser: https://salsa.debian.org/debian/liboprf
>  Vcs-Git: https://salsa.debian.org/debian/liboprf.git
>  
> -Package: liboprf0
> +Package: liboprf0t64
> +Provides: ${t64:Provides}
> +Replaces: liboprf0
> +Breaks: liboprf0 (<< ${source:Version})
>  Section: libs
>  Architecture: any
>  Multi-Arch: same
> diff -Nru liboprf-0.1+git20231001.0da3e2b/debian/liboprf0.install 
> liboprf-0.1+git20231001.0da3e2b/debian/liboprf0.install
> --- liboprf-0.1+git20231001.0da3e2b/debian/liboprf0.install   2023-10-04 
> 14:07:26.0 +
> +++ liboprf-0.1+git20231001.0da3e2b/debian/liboprf0.install   1970-01-01 
> 00:00:00.0 +
> @@ -1,2 +0,0 @@
> -#!/usr/bin/dh-exec
> -usr/lib/liboprf.so.0 => usr/lib/${DEB_HOST_MULTIARCH}/liboprf.so.0
> diff -Nru liboprf-0.1+git20231001.0da3e2b/debian/liboprf0t64.install 
> liboprf-0.1+git20231001.0da3e2b/debian/liboprf0t64.install
> --- liboprf-0.1+git20231001.0da3e2b/debian/liboprf0t64.install
> 1970-01-01 00:00:00.0 +
> +++ liboprf-0.1+git20231001.0da3e2b/debian/liboprf0t64.install
> 2023-10-04 14:07:26.0 +
> @@ -0,0 +1,2 @@
> +#!/usr/bin/dh-exec
> +usr/lib/liboprf.so.0 => usr/lib/${DEB_HOST_MULTIARCH}/liboprf.so.0
> diff -Nru 
> liboprf-0.1+git20231001.0da3e2b/debian/liboprf0t64.lintian-overrides 
> liboprf-0.1+git20231001.0da3e2b/debian/liboprf0t64.lintian-overrides
> --- liboprf-0.1+git20231001.0da3e2b/debian/liboprf0t64.lintian-overrides  
> 1970-01-01 00:00:00.0 +
> +++ liboprf-0.1+git20231001.0da3e2b/debian/liboprf0t64.lintian-overrides  
> 2024-02-28 16:05:00.0 +
> @@ -0,0 +1 @@
> +liboprf0t64: package-name-doesnt-match-sonames liboprf0
> diff -Nru liboprf-0.1+git20231001.0da3e2b/debian/rules 
> liboprf-0.1+git20231001.0da3e2b/debian/rules
> --- liboprf-0.1+git20231001.0da3e2b/debian/rules  2023-10-04 
> 14:07:26.0 +
> +++ liboprf-0.1+git20231001.0da3e2b/debian/rules  2024-02-28 
> 16:06:05.0 +
> @@ -7,7 +7,7 @@
>  export DEB_LDFLAGS_MAINT_APPEND = -lsodium
>  
>  %:
> - dh $@ -p liboprf-dev -p liboprf0
> + dh $@
>  
>  override_dh_auto_install:
>   dh_auto_install -- PREFIX=/usr

Bug#1064204: RM: freedict-swa-eng/experimental -- ROM; NPOASR, unmaintained

[Joost van Baal-Ilić]

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
Severity: normal

Please remove the freedict-swa-eng source and dict-freedict-swa-eng binary
packages.  All other currently maintained dict-* packages are build from one
source package.  The freedict-swa-eng package was part of a stalled attempt of
splitting the source.  It has been sitting in experimental since about 2007,
never made it to unstable/testing/stable.

Thanks, Bye,

Joost

Bug#1063692: uruk: move files to /usr (DEP17)

[Joost van Baal-Ilić]

tags 1063692 +pending
thanks

Hi Helmut,

On Sun, Feb 11, 2024 at 02:17:47PM +0100, Helmut Grohne wrote:
> On Sun, Feb 11, 2024 at 10:19:50AM +0100, Joost van Baal-Ilić wrote:
> > Thanks a lot for this beautiful patch.  Do you intend to take care of 
> > uploading
> > it to unstable too?  If not, I'm happy to do that of course.
> 
> Thanks for the quick reply. I prefer you uploading it as you know your
> git workflow best. Let me know if you want me to NMU it. Realistically,
> we need this done by September 2024 to finish the transition in time.

Cool; just committed your patch; I'll take care of the upload.

Bye,

Joost

Bug#1063692: uruk: move files to /usr (DEP17)

[Joost van Baal-Ilić]

Hi Helmut,

Thanks a lot for this beautiful patch.  Do you intend to take care of uploading
it to unstable too?  If not, I'm happy to do that of course.

Bye,

Joost

On Sun, Feb 11, 2024 at 07:47:03AM +0100, Helmut Grohne wrote:
> Package: uruk
> Version: 20231009-1
> Tags: patch trixie sid
> User: helm...@debian.org
> Usertags: dep17m2
> 
> Hi,
> 
> we want to finalize the /usr-merge transition by moving all aliased
> files from / to /usr via DEP17 to avoid negative effects arising from
> aliasing. uruk is involved, because it uses --prefix=/ and thus causes
> aliasing. I'm sending a patch, because it cannot automatically be
> converted using dh-sequence-movetousr. Note that this patch must not be
> uploaded to bookworm-backports or earlier as it would violate the file
> move moratorium there.
> 
> Helmut

> diff --minimal -Nru uruk-20231009/debian/changelog 
> uruk-20231009/debian/changelog
> --- uruk-20231009/debian/changelog2023-10-09 14:30:23.0 +0200
> +++ uruk-20231009/debian/changelog2024-02-11 07:37:17.0 +0100
> @@ -1,3 +1,10 @@
> +uruk (20231009-1.1) UNRELEASED; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Move files to /usr for DEP17. (Closes: #-1)
> +
> + -- Helmut Grohne   Sun, 11 Feb 2024 07:37:17 +0100
> +
>  uruk (20231009-1) unstable; urgency=medium
>  
>* New upstream release: The Vyttila - Kakkanad Release.
> diff --minimal -Nru uruk-20231009/debian/rules uruk-20231009/debian/rules
> --- uruk-20231009/debian/rules2023-10-09 14:30:23.0 +0200
> +++ uruk-20231009/debian/rules2024-02-11 07:37:17.0 +0100
> @@ -33,8 +33,8 @@
>  
>  build-indep:
>   $(checkdir)
> - ./configure --prefix=/ --datarootdir=/usr/share \
> -  --sysconfdir=/etc --localstatedir=/var --libexecdir=/lib
> + ./configure --prefix=/usr --exec-prefix=/usr --datarootdir=/usr/share \
> +  --sysconfdir=/etc --localstatedir=/var 
> '--libexecdir=$${prefix}/lib'
>   $(MAKE)
>   touch build
>  
> @@ -51,17 +51,13 @@
>   install -d debian/$(package)
>  #   # /libexec/uruk/init/{autodetect-ips,enable-ipv6}
>  #   # should end up in /lib/uruk/init/
> - $(MAKE) install prefix=$(CURDIR)/debian/$(package) \
> -  datarootdir=$(CURDIR)/debian/$(package)/usr/share \
> -  sysconfdir=$(CURDIR)/debian/$(package)/etc \
> -  localstatedir=$(CURDIR)/debian/$(package)/var \
> -  libexecdir=$(CURDIR)/debian/$(package)/lib
> + $(MAKE) install DESTDIR=$(CURDIR)/debian/$(package)
>   mkdir -p debian/$(package)/etc/uruk
>   mkdir -p debian/$(package)/etc/default
>   mkdir -p debian/$(package)/usr/share/lintian/overrides
>   cp -a debian/rc debian/$(package)/etc/uruk
>  #   # /libexec will contain uruk/lsb/*, not needed on Debian
> - rm -r debian/$(package)/lib/uruk/lsb
> + rm -r debian/$(package)/usr/lib/uruk/lsb
>   cp -a debian/lintian-overrides 
> debian/$(package)/usr/share/lintian/overrides/$(package)
>   mv 
> $(CURDIR)/debian/$(package)/usr/share/doc/$(package)/examples/default 
> debian/$(package)/etc/default/uruk
>   rm $(CURDIR)/debian/$(package)/usr/share/doc/$(package)/COPYING

Bug#1063021: O: ruby-ami -- Ruby client library for the Asterisk Management Interface

[Joost van Baal-Ilić]

Hi Reiner,

Thanks for your interest.

On Sun, Feb 04, 2024 at 09:19:16PM +0100, Reiner Herrmann wrote:
> Joost schreef:
> > A not yet packaged new upstream is available, since 2016.  Upstream has not
> > commited any code after 2016.
> > 
> > ruby-ami has no reverse-depends in our archives, no package build-depends
> > upon ruby-ami.
> 
> This sounds like it can also be removed instead of being orphaned?

Indeed.  I am not quite sure RM-ing is the right thing to do as long
as there are no annoying bugs are found.

If you feel otherwise, feel free to post an RM.

Thanks, Bye,

Joost

Bug#1063021: O: ruby-ami -- Ruby client library for the Asterisk Management Interface

[Joost van Baal-Ilić]

Package: wnpp
Control: affects -1 + src:ruby-ami
Severity: normal

Hi,

I intend to orphan the ruby-ami package.

A not yet packaged new upstream is available, since 2016.  Upstream has not
commited any code after 2016.

ruby-ami has no reverse-depends in our archives, no package build-depends upon
ruby-ami.

The package description is:
 RubyAMI is an Asterisk Management Interface client library in Ruby built on
 Celluloid IO and based on EventMachine providing a connection to the Asterisk
 Manager Interface. RubyAMI is a low level library; it does not provide any
 features beyond connection management and protocol parsing. Actions are sent
 over the wire, and responses are returned. Events are passed to a callback you
 define. It's up to you to match these up into something useful. In this regard,
 RubyAMI is very similar to Blather for XMPP or Punchblock, the Ruby 3PCC
 library.

Bug#1061954: frog: NMU diff for 64-bit time_t transition

[Joost van Baal-Ilić]

Hi,

[sorry for yet another one, i clicked sent too early...]

On Fri, Feb 02, 2024 at 03:01:04PM +0100, Joost van Baal-Ilić wrote:
> On Fri, Feb 02, 2024 at 02:22:20PM +0100, Maarten van Gompel wrote:
> > 
> > On second thought, I read https://wiki.debian.org/ReleaseGoals/64bit-time 
> > and
> > checked the updated Frog sources, there is no time_t exposed at all anymore
> > in the new version I'm packaging.
> 
> That's nice.
> 
> > So if I understand things correctly, the new
> > libfrog3 library does not need the t64 transition and I can revert
> > https://salsa.debian.org/science-team/frog/-/commit/2bbda8d92d40b96a216e8d8db972a9589f8df02f
> >  ?
> 
> 
> > > Afaik the plan is to keep the binary packages named libt64 (reading
> > > https://wiki.debian.org/ReleaseGoals/64bit-time ); this helps executing 
> > > the
> > > transition.
> > 
> > I'll rebase so the libfrog2t64 patch is included, but it'll be
> > immediately superseded by libfrog3.
> 
> Upcoming stable release could likely ship both frog2 and frog3.  E.g. if
> testing around release-time ships binaries build-depending upon frog2, this
> will happen.

Wow, having just read Message-Id:  to
debian-science, we might indeed succeed in shipping upcoming Debian stable
without frog2.

Bye,

Joost

Bug#1061954: frog: NMU diff for 64-bit time_t transition

[Joost van Baal-Ilić]

Hi,

On Fri, Feb 02, 2024 at 02:22:20PM +0100, Maarten van Gompel wrote:
> 
> On second thought, I read https://wiki.debian.org/ReleaseGoals/64bit-time and
> checked the updated Frog sources, there is no time_t exposed at all anymore
> in the new version I'm packaging.

That's nice.

> So if I understand things correctly, the new
> libfrog3 library does not need the t64 transition and I can revert
> https://salsa.debian.org/science-team/frog/-/commit/2bbda8d92d40b96a216e8d8db972a9589f8df02f
>  ?


> > Afaik the plan is to keep the binary packages named libt64 (reading
> > https://wiki.debian.org/ReleaseGoals/64bit-time ); this helps executing the
> > transition.
> 
> I'll rebase so the libfrog2t64 patch is included, but it'll be
> immediately superseded by libfrog3.

Upcoming stable release could likely ship both frog2 and frog3.  E.g. if
testing around release-time ships binaries build-depending upon frog2, this
will happen.

Bye,

Joost

Bug#1061954: frog: NMU diff for 64-bit time_t transition

[Joost van Baal-Ilić]

Hi Maarten e.a.,

On Thu, Feb 01, 2024 at 06:29:20PM +0100, Maarten van Gompel wrote:
> On Tue Jan 30, 2024 at 2:31 PM CET, Lukas Märdian wrote:
> > As part of the 64-bit time_t transition required to support 32-bit
> > architectures in 2038 and beyond
> > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified

> 
> Thanks for your patch. I am currently in the progress of upgrading these
> packages to the new upstream sources after a long hiatus. This would
> involve a library transition anyway (libfrog2 -> libfrog3). Is it
> sufficient if I include  'Provides: ${t64:Provides}' for the new
> libfrog3 package to accomodate this transition? I just did this in
> commit 2bbda8d92d40b96a216e8d8db972a9589f8df02f:
>   
>   
> https://salsa.debian.org/science-team/frog/-/commit/2bbda8d92d40b96a216e8d8db972a9589f8df02f
> 
> Perhaps that also removes the need for the oddly named frog2t64 package?
> If not, I'll apply your patch and rebase my changes on top of it.

Afaik the plan is to keep the binary packages named libt64 (reading
https://wiki.debian.org/ReleaseGoals/64bit-time ); this helps executing the
transition.

HTH, Bye,

Joost

Bug#1062555: liboprf: NMU diff for 64-bit time_t transition

[Joost van Baal-Ilić]

Hi,

I've had a look at the diff, lgtm.  I'd appreciate the upload to unstable in
due time.  Thanks a lot for your work, much appreciated!

Bye,

Joost


On Thu, Feb 01, 2024 at 10:57:49PM +, Steve Langasek wrote:
> Source: liboprf
> Version: 0.1+git20231001.0da3e2b-1
> Severity: serious
> Tags: patch pending
> Justification: library ABI skew on upgrade
> User: debian-...@lists.debian.org
> Usertags: time-t
> 
> NOTICE: these changes must not be uploaded to unstable yet!
> 
> Dear maintainer,
> 
> As part of the 64-bit time_t transition required to support 32-bit
> architectures in 2038 and beyond
> (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> liboprf as a source package shipping runtime libraries whose ABI
> either is affected by the change in size of time_t, or could not be
> analyzed via abi-compliance-checker (and therefore to be on the safe
> side we assume is affected).
> 
> To ensure that inconsistent combinations of libraries with their
> reverse-dependencies are never installed together, it is necessary to
> have a library transition, which is most easily done by renaming the
> runtime library package.
> 
> Since turning on 64-bit time_t is being handled centrally through a change
> to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
> important that libraries affected by this ABI change all be uploaded close
> together in time.  Therefore I have prepared a 0-day NMU for liboprf
> which will initially be uploaded to experimental if possible, then to
> unstable after packages have cleared binary NEW.
> 
> Please find the patch for this NMU attached.
> 
> If you have any concerns about this patch, please reach out ASAP.  Although
> this package will be uploaded to experimental immediately, there will be a
> period of several days before we begin uploads to unstable; so if information
> becomes available that your package should not be included in the transition,
> there is time for us to amend the planned uploads.
> 
> 
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)

> diff -Nru liboprf-0.1+git20231001.0da3e2b/debian/changelog 
> liboprf-0.1+git20231001.0da3e2b/debian/changelog
> --- liboprf-0.1+git20231001.0da3e2b/debian/changelog  2023-10-04 
> 14:07:26.0 +
> +++ liboprf-0.1+git20231001.0da3e2b/debian/changelog  2024-02-01 
> 17:51:25.0 +
> @@ -1,3 +1,10 @@
> +liboprf (0.1+git20231001.0da3e2b-1.1) experimental; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Rename libraries for 64-bit time_t transition.
> +
> + -- Steve Langasek   Thu, 01 Feb 2024 17:51:25 +
> +
>  liboprf (0.1+git20231001.0da3e2b-1) unstable; urgency=low
>  
>* New upstream git snapshot (thanks again Thorsten Alteholz for
> diff -Nru liboprf-0.1+git20231001.0da3e2b/debian/control 
> liboprf-0.1+git20231001.0da3e2b/debian/control
> --- liboprf-0.1+git20231001.0da3e2b/debian/control2023-10-04 
> 14:07:26.0 +
> +++ liboprf-0.1+git20231001.0da3e2b/debian/control2024-02-01 
> 17:51:25.0 +
> @@ -10,7 +10,10 @@
>  Vcs-Browser: https://salsa.debian.org/debian/liboprf
>  Vcs-Git: https://salsa.debian.org/debian/liboprf.git
>  
> -Package: liboprf0
> +Package: liboprf0t64
> +Provides: ${t64:Provides}
> +Replaces: liboprf0
> +Breaks: liboprf0 (<< ${source:Version})
>  Section: libs
>  Architecture: any
>  Multi-Arch: same
> diff -Nru liboprf-0.1+git20231001.0da3e2b/debian/liboprf0.install 
> liboprf-0.1+git20231001.0da3e2b/debian/liboprf0.install
> --- liboprf-0.1+git20231001.0da3e2b/debian/liboprf0.install   2023-10-04 
> 14:07:26.0 +
> +++ liboprf-0.1+git20231001.0da3e2b/debian/liboprf0.install   1970-01-01 
> 00:00:00.0 +
> @@ -1,2 +0,0 @@
> -#!/usr/bin/dh-exec
> -usr/lib/liboprf.so.0 => usr/lib/${DEB_HOST_MULTIARCH}/liboprf.so.0
> diff -Nru liboprf-0.1+git20231001.0da3e2b/debian/liboprf0t64.install 
> liboprf-0.1+git20231001.0da3e2b/debian/liboprf0t64.install
> --- liboprf-0.1+git20231001.0da3e2b/debian/liboprf0t64.install
> 1970-01-01 00:00:00.0 +
> +++ liboprf-0.1+git20231001.0da3e2b/debian/liboprf0t64.install
> 2023-10-04 14:07:26.0 +
> @@ -0,0 +1,2 @@
> +#!/usr/bin/dh-exec
> +usr/lib/liboprf.so.0 => usr/lib/${DEB_HOST_MULTIARCH}/liboprf.so.0
> diff -Nru 
> liboprf-0.1+git20231001.0da3e2b/debian/liboprf0t64.lintian-overrides 
> liboprf-0.1+git20231001.0da3e2b/debian/liboprf0t64.lintian-overrides
> --- liboprf-0.1+git20231001.0da3e2b/debian/liboprf0t64.lintian-overrides  
> 1970-01-01 00:00:00.0 +
> +++ 

Bug#1049742: reopening / Re: Bug#1049742: marked as done (uruk: Fails to build binary packages again after successful build)

[Joost van Baal-Ilić]

reopen 1049742
thanks


on second thought i'm not quite sure wether this bug is actually fixed now;
reopening.


On Mon, Oct 09, 2023 at 02:45:03PM +, Debian Bug Tracking System wrote:
> Your message dated Mon, 09 Oct 2023 14:42:24 +
> with message-id 
> and subject line Bug#1049742: fixed in uruk 20231009-1
> has caused the Debian Bug report #1049742,
> regarding uruk: Fails to build binary packages again after successful build
> to be marked as done.

Bug#1053504: build target not in manual page

[Joost van Baal-Ilić]

Hi Geert,

On Thu, Oct 05, 2023 at 11:32:07AM +0200, Geert Stappers wrote:
> 
> The manual page of caspar is unaware of the build target.
> 
> 
> $ grep --context 4 build /usr/include/caspar/mk/caspar.mk | head -n 9
> _csp_DIRS := $(shell for d in *; do test -d "$$d" && echo "$$d"; done)
> _csp_DIRS := $(filter-out $(csp_TABOODIRS),$(_csp_DIRS))
> 
> all:
>   $(MAKE) build
>   $(MAKE) install
>   $(MAKE) load
> 
> define _csp_filetargets
> $
> 
> 
> 
> I noticed the build target in
> 
> $ make
> make build
> make[1]: Entering directory 'path/redacted'
> make[1]: Nothing to be done for 'build'.
> make[1]: Leaving directory 'path/redacted'
> make install
> make[1]: Entering directory 'path/redacted'
> redacted command redacted parameters
> ... more "make output" ...
> 
> and would like to use it. ( I have an use case for "build",
> but don't know how to use it.)
> 
> 
> Please document how to use the build target.

At http://mdcc.cx/pub/caspar/caspar-latest/doc/caspar.html as shipped with
caspar 20220907, which is shipped with Debian bookworm (stable), it says:

"Note: csp_BUILD is deprecated. You should not use it."

Therefore closing this bug.

Thanks anyway, and excuse me for not catching this in our earlier discussion.

Bye,

Joost

Bug#1052413: pyequihash: should maintainer/uploader be turned?

[Joost van Baal-Ilić]

Hallo Ben,


On Thu, Sep 21, 2023 at 06:26:13PM +0200, Ben Tris wrote:
> Source: pyequihash
> Version: 0.2-2
> Severity: minor
> X-Debbugs-Cc: benatt...@gezapig.nl
> 
> Dear Maintainer,
> 
> Normally the Debian Python Team would be maintainer.
> Then Joost van Baal-Ilić would be under uploaders.
> 
> Now it's opposite.

Lets see:

(sid)joostvb@banach:/var/lib/apt/lists% egrep Package\|Maintain\|Upload 
deb.debian.org_debian_dists_sid_main_source_Sources
| less

 Package: libequihash
 Maintainer: Joost van Baal-Ilić 
 Uploaders: Stefan Marsiske 

while e.g.

 Package: py-lmdb
 Maintainer: Debian Python Team 
 Uploaders: Robert Edmonds , Andrej Shadura 


and

 Package: py-postgresql
 Maintainer: Debian Python Team 
 Uploaders: Daniel Kahn Gillmor , William Grzybowski 


So I think you're right: we are maintaining libequihash using
https://salsa.debian.org/python-team/packages/pyequihash.git , so indeed we
should likely change it to:

Package: libequihash
Maintainer: Debian Python Team 
Uploaders: Joost van Baal-Ilić , Stefan Marsiske 


I'll get to that soonish.

Thanks for your bugreport!

Groeten,

Joost

Bug#1049864: ITP: libopaque - Language bindings for establishing a shared secret using the OPAQUE protocol

[Joost van Baal-Ilić]

Package: wnpp
Severity: wishlist
Owner: Joost van Baal-Ilić 

* Package name: libopaque
  Version : 0.99
  Upstream Author : Stefan Marsiske and Chris Topher
* URL : https://github.com/stef/libopaque
* License : GPLv3, LGPLv3
  Programming Lang: C, JavaScript, Python, Go, PHP
  Description : Language bindings for establishing a shared secret using 
the OPAQUE protocol

 This library implements the OPAQUE protocol as proposed in the IRTF Crypto
 Forum Research Group draft (https://github.com/cfrg/draft-irtf-cfrg-opaque).
 The OPAQUE protocol combines a Oblivious Pseudo-Random Function (OPRF) and an
 Authenticated Key-Exchange (AKE) into a protocol where a user holding nothing
 but a password and a server holding some information protected by the password
 can establish a shared secret.  The library comes with bindings for js, php7,
 ruby, java, erlang, lua, python, go and SASL.


libopaque depends on liboprf, ITP Bug #1049347 .

The (yet to be packaged) Klutshnik software (https://klutshnik.info/) will
depend upon libopaque.  I will be working on this package at (yet to be created)
https://salsa.debian.org/debian/libopaque .

The libopaque project was funded through the NGI0 PET Fund, a fund established
by NLnet with financial support from the European Commission's Next Generation
Internet programme, under the aegis of DG Communications Networks, Content and
Technology under grant agreement No 825310.

Bye,

Joost

Bug#1049347: ITP: liboprf - Oblivious Pseudo-Random Generator and Threshold OPRF library

[Joost van Baal-Ilić]

Package: wnpp
Severity: wishlist
Owner: Joost van Baal-Ilić 

* Package name: liboprf
  Version : 0.1
  Upstream Author : Stefan Marsiske
* URL : https://github.com/stef/liboprf
* License : GPLv3, LGPLv3
  Programming Lang: C
  Description : Oblivious Pseudo-Random Functions and Threshold OPRF library

 This library implements the basic OPRF (ristretto255, SHA-512) variant from the
 "Oblivious Pseudorandom Functions using Prime-Order Groups" Draft from the IRTF
 Crypto Forum Research Group (https://github.com/cfrg/draft-irtf-cfrg-voprf/).
 Additionally it implements a threshold OPRF based on "TOPPSS: Cost-minimal
 Password-Protected Secret Sharing based on Threshold OPRF" by Krawczyk et al
 (https://ia.cr/2017/363).
 .
 This library depends on libsodium.

The (yet to be packaged) Klutshnik software (https://klutshnik.info/) will
depend upon liboprf.  I will be working on this package at (yet to be created)
https://salsa.debian.org/debian/liboprf .

Bye,

Joost



signature.asc
Description: PGP signature

Bug#1041816: pyequihash: Uses obsolete Debian Python Modules Team as uploader/Vcs field

[Joost van Baal-Ilić]

On Sun, Jul 23, 2023 at 04:44:48PM -0400, Boyuan Yang wrote:
> Source: pyequihash
> Version: 0.2-2
> Severity: normal
> X-Debbugs-CC: joos...@debian.org
> Tags: sid
> 
> Dear Debian pyequihash package maintainer,
> 
> Your package is one of the few packages left that still uses Debian
> Python Modules Team ( 
> https://qa.debian.org/developer.php?email=python-modules-team%40lists.alioth.debian.org
>  )
> in package maintainer or uploader field. This has been long been obsolete
> according to past discussion on debian-python mailing list. Besides, your
> package has Vcs-* fields that are 404 not found. Please fix these issues
> in the next package upload.

Thanks for reporting this, will get to it.

(And thanks for your pyreadstat upload!)

Bye,

Joost

Bug#1034348: at: autopkgtest regression on arm64

[Joost van Baal-Ilić]

Hi,

Another happy at user here.

Jose M Calhariz  wrote:
> Hi, I believe my last update fixed the problem can someone double check?

That was at 3.2.5-2, right?  Closing this bug: afaik nobody has been able to
reproduce the issue.  Therefore better to close and see what happens next.

Please reopen if you feel this is not appropriate.

Thanks!  Bye,

Joost

Bug#1035710: unblock: doc-debian/11.3

[Joost van Baal-Ilić]

Hi Luca,

On Wed, May 24, 2023 at 12:04:57AM +0100, Luca Boccassi wrote:
> Control: retitle -1 unblock: doc-debian/11.3+nmu1
> Control: tags -1 -moreinfo
> 
> On Tue, 23 May 2023 23:37:23 +0100 Luca Boccassi 
> wrote:
> > On Tue, 23 May 2023 06:46:19 +0200 Joost van =?utf-8?Q?Baal-
> Ili=C4=87?=
> >  wrote:
> > > On Sat, May 20, 2023 at 04:21:47PM +0200, Sebastian Ramacher wrote:
> > >  
> > > > On 2023-05-14 06:47:18 +0200, Joost van Baal-Ilić wrote:
> > > > > reopen 1035710
> > > > > retitle 1035710 unblock: doc-debian/11.3
> > > > > thanks
> > > > > 
> > > > > Please unblock package doc-debian
> > > > > 
> > > > 
> > > > Please go ahead with the upload to unstable. Remove the moreinfo
> > > > tag once the package is available.
> > > 
> > > Thank you.  Unfortunately I don't think I'll make it before the deadline
> > > / in the next couple of hours, real life currently doesn't allow me that.
> > > 
> > > If anybody else has time to take a shot at it: here's the current
> > > issue's: I made a mistake in the upload to experimental: it says
> > > 'experimental' in the top of debian/changelog; should probably be
> > > 'unstable'.  And the last commit on salsa is misguided.
> > > 
> > > If nobody steps up I can probably prepare an upload for the first
> > > bookworm point release.
> > 
> > I can take care of this, I'll do a changelog-only upload of the current
> > version that's in experimental to unstable.
> 
> Done, you can find the changelog-only commit to pull from at:
> 
> https://salsa.debian.org/bluca/doc-debian/-/commits/master?ref_type=heads

Excellent, thanks a lot, you made my day \o/

Bye,

Joost

Bug#1035710: unblock: doc-debian/11.3

[Joost van Baal-Ilić]

On Sat, May 20, 2023 at 04:21:47PM +0200, Sebastian Ramacher wrote:
 
> On 2023-05-14 06:47:18 +0200, Joost van Baal-Ilić wrote:
> > reopen 1035710
> > retitle 1035710 unblock: doc-debian/11.3
> > thanks
> > 
> > Please unblock package doc-debian
> > 
> > [ Reason ]
> > The doc-debian package claims to ship the Constitution for the Debian 
> > Project,
> > the Debian Social Contract and other Debian documents.  The versions of 
> > those
> > documents are obsolete [obsolete], which makes the package as now in testing
> > very buggy.

> > 
> > unblock doc-debian/11.3
> 
> Please go ahead with the upload to unstable. Remove the moreinfo tag
> once the package is available.

Thank you.  Unfortunately I don't think I'll make it before the deadline / in
the next couple of hours, real life currently doesn't allow me that.

If anybody else has time to take a shot at it: here's the current issue's: I
made a mistake in the upload to experimental: it says 'experimental' in the top
of debian/changelog; should probably be 'unstable'.  And the last commit on
salsa is misguided.

If nobody steps up I can probably prepare an upload for the first bookworm
point release.

Bye,

Joost

-- 
irc: joostvb @ OFTC / libera.chat / ...

Bug#1035913: fixed in doc-debian 11.2

[Joost van Baal-Ilić]

Hi josch,

On Fri, May 12, 2023 at 08:12:46PM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> Quoting Joost van Baal-Ilić (2023-05-12 09:12:23)
> > TL;DR: I believe I can upload a fix to experimental & ask for unblock in the
> > coming weekend.
> 
> cool!


> > I am very sorry it took me so long to find some time to work on these long
> > standing issues.  (In my defense: I've explicitly asked for more hands:
> > https://lists.debian.org/msgid-search/20230201193812.gb28...@beskar.mdcc.cx 
> > .
> > And: I'm am not the doc-debian maintainer; I'm merely an uploader.)
> 
> Sorry, I didn't want to come across as rude. I'm also just doing all this as a
> volunteer in my limited free time just like you. Though it seems in practice
> you have become the de-facto doc-debian maintainer now -- congratulations. :)

Hehe :)

> > Anyway, I'll likely have time to work on this during the coming weekend; I
> > believe I can do a fixed upload then, thanks to your very helpful hints.
> > (And, risking stating the obvious here: NMU's very welcome.)
> 
> If you want me to do something, just mail me what you need and I'll see 
> whether
> I can find some time to take care of it.

Thanks for this kind message.

I've just uploaded doc-debian/11.3 to experimental and reopened the unblock
request in #1035710 (unblock: doc-debian/11.3).

Thanks!

Bye

Joost

Bug#1035913: fixed in doc-debian 11.2

[Joost van Baal-Ilić]

Hi again!

TL;DR: I believe I can upload a fix to experimental & ask for unblock in the
coming weekend.

On Fri, May 12, 2023 at 07:17:53AM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> Quoting Joost van Baal-Ilić (2023-05-12 07:01:45)
> > A!  That explains!  Thanks a lot.  I now have a plan again; will get to it
> > within a week.
> 
> can we finish this a bit quicker than that? The full freeze is at 2023-05-24
> and my package is also broken by dash in experimental, so the upload of my
> package has to be coordinated with dash and doc-debian. The earlier you are
> ready, the earlier not only my package but also dash can be unblocked.
> 
> Sorry, this would've been much more relaxed if the doc-debian upload did not
> happen during hard freeze...

OK, I understand it's not doc-debian in unstable, but only doc-debian as it is
scheduled to end up in bookworm which is causing trouble in your package (and 
dash
(!)).

And I understand you want to be sure doc-debian in bookworm will ship the
new-style /usr/share/doc-base/doc-debian.debian-constitution-text e.a. , not
the old-style /usr/share/doc-base/debian-constitution-text .

I am very sorry it took me so long to find some time to work on these long
standing issues.  (In my defense: I've explicitly asked for more hands:
https://lists.debian.org/msgid-search/20230201193812.gb28...@beskar.mdcc.cx .
And: I'm am not the doc-debian maintainer; I'm merely an uploader.)

Anyway, I'll likely have time to work on this during the coming weekend; I
believe I can do a fixed upload then, thanks to your very helpful hints.  (And,
risking stating the obvious here: NMU's very welcome.)

Thanks, Bye,

Joost

Bug#1035913: fixed in doc-debian 11.2

[Joost van Baal-Ilić]

Hi,

On Fri, May 12, 2023 at 06:50:55AM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> Quoting Joost van Baal-Ilić (2023-05-11 15:35:24)
> > On Thu, May 11, 2023 at 01:55:48PM +0200, Joost van Baal-Ilić wrote:
> > > On Thu, May 11, 2023 at 12:38:17PM +0200, Johannes Schauer Marin 
> > > Rodrigues wrote:
> > > > On Thu, 11 May 2023 09:49:47 + Debian FTP Masters 
> > > >  wrote:
> > > > > Changes:
> > > > >  doc-debian (11.2) experimental; urgency=high
> > > > >  .
> > > > >* This release is targeted for Debian 12 bookworm: changes with 
> > > > > what is
> > > > >  in testing now are minimal and suitable for an upload late in the
> > > > >  release cycle.
> > > > >* debian/TODO: added
> > > > >* Revert changes which are too intrusive for an upload during 
> > > > > freeze.
> > > > >  (Closes: #1035913) Thanks Johannes Schauer Marin Rodrigues: 
> > > > > "changed
> > > > >  /usr/share/doc-base/ paths".
> > > > 
> > > > I do not understand that last changelog entry. Reverting "changes which 
> > > > are too
> > > > intrusive for an upload during freeze" sounds like you are going back 
> > > > to this:
> > > > 
> > > > /usr/share/doc-base/debian-constitution-text
> > > > /usr/share/doc-base/debian-mailing-lists
> > > > /usr/share/doc-base/debian-manifesto
> > > > /usr/share/doc-base/debian-reporting-bugs
> > > > /usr/share/doc-base/debian-social-contract
> > > > 
> > > > But the package in experimental is shipping this:
> > > > 
> > > > $ curl --silent 
> > > > https://incoming.debian.org/debian-buildd/pool/main/d/doc-debian/doc-debian_11.2_all.deb
> > > >  | dpkg-deb -c - | grep doc-base
> > > > drwxr-xr-x root/root 0 2023-05-11 09:08 ./usr/share/doc-base/
> > > > -rw-r--r-- root/root   578 2020-12-31 08:50 
> > > > ./usr/share/doc-base/doc-debian.debian-constitution-text
> > > > -rw-r--r-- root/root   238 2020-12-31 08:50 
> > > > ./usr/share/doc-base/doc-debian.debian-mailing-lists
> > > > -rw-r--r-- root/root   502 2020-12-31 08:50 
> > > > ./usr/share/doc-base/doc-debian.debian-manifesto
> > > > -rw-r--r-- root/root   278 2020-12-31 08:50 
> > > > ./usr/share/doc-base/doc-debian.debian-reporting-bugs
> > > > -rw-r--r-- root/root   550 2020-12-31 08:50 
> > > > ./usr/share/doc-base/doc-debian.debian-social-contract
> > > > 
> > > > So the paths actually did *not* get reverted to how they were before 
> > > > 11.0?
> > > 
> > > Thanks for this.  Apparently the buildengine used gives different results 
> > > than
> > > the one I used locally to check before uploading.  This bug should get
> > > reopened.  I'll investigate.
> > 
> > ok this is not trivial.  even in a sid chroot it installs
> > usr/share/doc-base/doc-debian.debian-constitution-text , and does not 
> > install
> > usr/share/doc-base/debian-constitution-text .  changing dh compat level to 
> > the
> > current one does not fix it.  dh_installdocs(1) does not help me.  i'll
> > investigate more...
> 
> you cannot go back to the old doc-base paths. The package name is part of the
> path since this debhelper commit from 2021:
> 
> https://salsa.debian.org/debian/debhelper/-/commit/8eac421c260e62bcecd571af225438e107b33157

( fixing bug https://bugs.debian.org/980903 . )

A!  That explains!  Thanks a lot.  I now have a plan again; will get to it
within a week.

Bye,

Joost

Bug#1035913: reopen / Re: Bug#1035913: fixed in doc-debian 11.2

[Joost van Baal-Ilić]

reopen 1035913
thanks

On Thu, May 11, 2023 at 01:55:48PM +0200, Joost van Baal-Ilić wrote:

> 
> This bug should get reopened.

Doing so.

Bye,

Joost

Bug#1035710: closing / Re: unblock: doc-debian/11.1

[Joost van Baal-Ilić]

Closing this request.  11.2 which is in experimental [11.2] is better suited
for bookworm: it has a smaller diff with what's in stable now.  However, since
11.2 has some other problems ( #1035913 ), I'll do more work in the coming days
and hope to come up with an ever better candidate for bookworm.  Sorry for the
noise.

Bye,

Joost


[11.2] 
https://tracker.debian.org/news/1430982/accepted-doc-debian-112-source-into-experimental/

Bug#1035289: merecat: diff for NMU version 2.31+git20220513+ds-4.1

[Joost van Baal-Ilić]

Hi gregor,

Awesome, thanks a lot!  (And no need to delay longer.)

Bye,

Joost


On Thu, May 11, 2023 at 08:54:27PM +0200, gregor herrmann wrote:
> Control: tags 1035289 + patch
> Control: tags 1035289 + pending
> 
> 
> Dear maintainer,
> 
> I've prepared an NMU for merecat (versioned as 2.31+git20220513+ds-4.1) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.
> 
> Regards.
> 
> 
> -- 
>  .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
>  : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
>  `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
>`-   

> diff -Nru merecat-2.31+git20220513+ds/debian/changelog 
> merecat-2.31+git20220513+ds/debian/changelog
> --- merecat-2.31+git20220513+ds/debian/changelog  2023-02-23 
> 07:09:58.0 +0100
> +++ merecat-2.31+git20220513+ds/debian/changelog  2023-05-11 
> 20:47:24.0 +0200
> @@ -1,3 +1,13 @@
> +merecat (2.31+git20220513+ds-4.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Fix "postinst uses /usr/share/doc content (Policy 12.3):
> +/usr/share/doc/merecat/examples/merecat.conf":
> +Install example config files to /usr/share/merecat and symlink them from
> +/usr/share/doc/merecat/examples. (Closes: #1035289)
> +
> + -- gregor herrmann   Thu, 11 May 2023 20:47:24 +0200
> +
>  merecat (2.31+git20220513+ds-4) unstable; urgency=medium
>  
>* Upload to unstable.
> diff -Nru merecat-2.31+git20220513+ds/debian/install 
> merecat-2.31+git20220513+ds/debian/install
> --- merecat-2.31+git20220513+ds/debian/install2023-02-17 
> 09:47:41.0 +0100
> +++ merecat-2.31+git20220513+ds/debian/install2023-05-11 
> 20:47:24.0 +0200
> @@ -1 +1,3 @@
>  merecat.service lib/systemd/system
> +throttle.conf   usr/share/merecat
> +merecat.confusr/share/merecat
> diff -Nru merecat-2.31+git20220513+ds/debian/merecat.examples 
> merecat-2.31+git20220513+ds/debian/merecat.examples
> --- merecat-2.31+git20220513+ds/debian/merecat.examples   2022-05-05 
> 09:52:36.0 +0200
> +++ merecat-2.31+git20220513+ds/debian/merecat.examples   1970-01-01 
> 01:00:00.0 +0100
> @@ -1,2 +0,0 @@
> -throttle.conf
> -merecat.conf
> diff -Nru merecat-2.31+git20220513+ds/debian/merecat.links 
> merecat-2.31+git20220513+ds/debian/merecat.links
> --- merecat-2.31+git20220513+ds/debian/merecat.links  1970-01-01 
> 01:00:00.0 +0100
> +++ merecat-2.31+git20220513+ds/debian/merecat.links  2023-05-11 
> 19:58:06.0 +0200
> @@ -0,0 +1,2 @@
> +usr/share/merecat/throttle.conf usr/share/doc/merecat/examples/throttle.conf
> +usr/share/merecat/merecat.conf  usr/share/doc/merecat/examples/merecat.conf

Bug#1035913: fixed in doc-debian 11.2

[Joost van Baal-Ilić]

Hi again,

On Thu, May 11, 2023 at 01:55:48PM +0200, Joost van Baal-Ilić wrote:
> On Thu, May 11, 2023 at 12:38:17PM +0200, Johannes Schauer Marin Rodrigues 
> wrote:
> > On Thu, 11 May 2023 09:49:47 + Debian FTP Masters 
> >  wrote:
> > > Changes:
> > >  doc-debian (11.2) experimental; urgency=high
> > >  .
> > >* This release is targeted for Debian 12 bookworm: changes with what is
> > >  in testing now are minimal and suitable for an upload late in the
> > >  release cycle.
> > >* debian/TODO: added
> > >* Revert changes which are too intrusive for an upload during freeze.
> > >  (Closes: #1035913) Thanks Johannes Schauer Marin Rodrigues: "changed
> > >  /usr/share/doc-base/ paths".
> > 
> > I do not understand that last changelog entry. Reverting "changes which are 
> > too
> > intrusive for an upload during freeze" sounds like you are going back to 
> > this:
> > 
> > /usr/share/doc-base/debian-constitution-text
> > /usr/share/doc-base/debian-mailing-lists
> > /usr/share/doc-base/debian-manifesto
> > /usr/share/doc-base/debian-reporting-bugs
> > /usr/share/doc-base/debian-social-contract
> > 
> > But the package in experimental is shipping this:
> > 
> > $ curl --silent 
> > https://incoming.debian.org/debian-buildd/pool/main/d/doc-debian/doc-debian_11.2_all.deb
> >  | dpkg-deb -c - | grep doc-base
> > drwxr-xr-x root/root 0 2023-05-11 09:08 ./usr/share/doc-base/
> > -rw-r--r-- root/root   578 2020-12-31 08:50 
> > ./usr/share/doc-base/doc-debian.debian-constitution-text
> > -rw-r--r-- root/root   238 2020-12-31 08:50 
> > ./usr/share/doc-base/doc-debian.debian-mailing-lists
> > -rw-r--r-- root/root   502 2020-12-31 08:50 
> > ./usr/share/doc-base/doc-debian.debian-manifesto
> > -rw-r--r-- root/root   278 2020-12-31 08:50 
> > ./usr/share/doc-base/doc-debian.debian-reporting-bugs
> > -rw-r--r-- root/root   550 2020-12-31 08:50 
> > ./usr/share/doc-base/doc-debian.debian-social-contract
> > 
> > So the paths actually did *not* get reverted to how they were before 11.0?
> 
> Thanks for this.  Apparently the buildengine used gives different results than
> the one I used locally to check before uploading.  This bug should get
> reopened.  I'll investigate.

ok this is not trivial.  even in a sid chroot it installs
usr/share/doc-base/doc-debian.debian-constitution-text , and does not install
usr/share/doc-base/debian-constitution-text .  changing dh compat level to the
current one does not fix it.  dh_installdocs(1) does not help me.  i'll
investigate more...

Thanks again, Bye,

Joost

Bug#1035913: fixed in doc-debian 11.2

[Joost van Baal-Ilić]

On Thu, May 11, 2023 at 12:38:17PM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> Hi,
> 
> On Thu, 11 May 2023 09:49:47 + Debian FTP Masters 
>  wrote:
> > Changes:
> >  doc-debian (11.2) experimental; urgency=high
> >  .
> >* This release is targeted for Debian 12 bookworm: changes with what is
> >  in testing now are minimal and suitable for an upload late in the
> >  release cycle.
> >* debian/TODO: added
> >* Revert changes which are too intrusive for an upload during freeze.
> >  (Closes: #1035913) Thanks Johannes Schauer Marin Rodrigues: "changed
> >  /usr/share/doc-base/ paths".
> 
> I do not understand that last changelog entry. Reverting "changes which are 
> too
> intrusive for an upload during freeze" sounds like you are going back to this:
> 
> /usr/share/doc-base/debian-constitution-text
> /usr/share/doc-base/debian-mailing-lists
> /usr/share/doc-base/debian-manifesto
> /usr/share/doc-base/debian-reporting-bugs
> /usr/share/doc-base/debian-social-contract
> 
> But the package in experimental is shipping this:
> 
> $ curl --silent 
> https://incoming.debian.org/debian-buildd/pool/main/d/doc-debian/doc-debian_11.2_all.deb
>  | dpkg-deb -c - | grep doc-base
> drwxr-xr-x root/root 0 2023-05-11 09:08 ./usr/share/doc-base/
> -rw-r--r-- root/root   578 2020-12-31 08:50 
> ./usr/share/doc-base/doc-debian.debian-constitution-text
> -rw-r--r-- root/root   238 2020-12-31 08:50 
> ./usr/share/doc-base/doc-debian.debian-mailing-lists
> -rw-r--r-- root/root   502 2020-12-31 08:50 
> ./usr/share/doc-base/doc-debian.debian-manifesto
> -rw-r--r-- root/root   278 2020-12-31 08:50 
> ./usr/share/doc-base/doc-debian.debian-reporting-bugs
> -rw-r--r-- root/root   550 2020-12-31 08:50 
> ./usr/share/doc-base/doc-debian.debian-social-contract
> 
> So the paths actually did *not* get reverted to how they were before 11.0?

Thanks for this.  Apparently the buildengine used gives different results than
the one I used locally to check before uploading.  This bug should get
reopened.  I'll investigate.

Bye,

Joost

Bug#1035710: Bug#1035913: doc-debian 11.0 changed /usr/share/doc-base/ paths

[Joost van Baal-Ilić]

tnx, i'm now preparing a new doc-debian targetted for bookworm with only
minimal changes.  will have a closer look at this issue soonish (likely today).

sorry for this hassle.

Bye,

Joost

On Thu, May 11, 2023 at 08:23:17AM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> Package: doc-debian
> Version: 11.0
> Severity: normal
> 
> Hi,
> 
> On Mon, 8 May 2023 07:46:09 +0200 Joost van =?utf-8?Q?Baal-Ili=C4=87?= 
>  wrote:
> > [ Risks ] None.  The doc-debian package is a key package due to Priority:
> > standard.  It acts as a leaf package: Its only true reverse depends is the
> > live-task-standard package.[reverse-depends]
> 
> you are forgetting packages using doc-debian in their autopkgtests.
> 
> > [ Other info ] I made a mistake uploading doc-debian 11.0 to unstable; that
> > got accepted.  The version 11.1 is now available from
> > http://mdcc.cx/tmp/doc-debian/ .  I've incorporated some small cosmetic
> > changes next to the much needed document updates.  Attached is a 161 kB
> > doc-debian_6.5-11.1.dsc-debdiff , as well as a summarizing 13kB
> > doc-debian_6.5-11.1.dsc-debdiff-tldr .
> 
> Before your upload of 11.0, doc-debian contained:
> 
> /usr/share/doc-base/debian-constitution-text
> /usr/share/doc-base/debian-mailing-lists
> /usr/share/doc-base/debian-manifesto
> /usr/share/doc-base/debian-reporting-bugs
> /usr/share/doc-base/debian-social-contract
> 
> Then with 11.0 this became:
> 
> /usr/share/doc-base/doc-debian.debian-constitution-text
> /usr/share/doc-base/doc-debian.debian-mailing-lists
> /usr/share/doc-base/doc-debian.debian-manifesto
> /usr/share/doc-base/doc-debian.debian-reporting-bugs
> /usr/share/doc-base/doc-debian.debian-social-contract
> 
> This broke the autopkgtest of mmdebstrap which you can also see on the excuses
> page for doc-debian: https://qa.debian.org/excuses.php?package=doc-debian
> 
> Since I noticed this breakage, I uploaded a new version of mmdebstrap that
> works around this problem, assuming that this change was intentional. In
> hindsight, I probably should've contacted you instead because when
> investigating http://mdcc.cx/tmp/doc-debian/doc-debian_11.1_all.deb and
> comparing it to the version from unstable I see:
> 
> diff -u <(curl --silent 
> http://ftp.de.debian.org/debian/pool/main/d/doc-debian/doc-debian_11.0_all.deb
>  | dpkg-deb -c - | awk '{print $6}' | sort) <(curl --silent 
> http://mdcc.cx/tmp/doc-debian/doc-debian_11.1_all.deb | dpkg-deb -c - | awk 
> '{print $6}' | sort)
> --- /dev/fd/632023-05-11 08:18:34.782823397 +0200
> +++ /dev/fd/622023-05-11 08:18:34.782823397 +0200
> @@ -3,11 +3,11 @@
>  ./usr/share/
>  ./usr/share/doc/
>  ./usr/share/doc-base/
> -./usr/share/doc-base/doc-debian.debian-constitution-text
> -./usr/share/doc-base/doc-debian.debian-mailing-lists
> -./usr/share/doc-base/doc-debian.debian-manifesto
> -./usr/share/doc-base/doc-debian.debian-reporting-bugs
> -./usr/share/doc-base/doc-debian.debian-social-contract
> +./usr/share/doc-base/debian-constitution-text
> +./usr/share/doc-base/debian-mailing-lists
> +./usr/share/doc-base/debian-manifesto
> +./usr/share/doc-base/debian-reporting-bugs
> +./usr/share/doc-base/debian-social-contract
>  ./usr/share/doc/debian/
>  ./usr/share/doc/debian/bug-log-access.txt
>  ./usr/share/doc/debian/bug-log-mailserver.txt.gz
> 
> What are the intended paths. Should I revert my changes to mmdebstrap or not?
> 
> Also, these changes of paths in /usr/share/doc-base/ forth and back are not
> recorded in debian/changelog. If the change was intended, please document it.
> 
> Thanks!
> 
> cheers, josch

Bug#1031294: doc-debian: misspelled "Control: forwarded"

[Joost van Baal-Ilić]

tags 1031294 +pending
thanks

On Tue, Feb 14, 2023 at 07:09:24PM +0100, Jakub Wilk wrote:
> Package: doc-debian
> Version: 6.5
> 
> bug-reporting.txt gives the following example:
> 
> Control: forward -1 https://bugs.debian.org/nnn
> 
> This should be "forwarded", not "forward".
> 
> It's been already fixed on the website: #863069

Fixed in git, thanks.

Bye,

Joost

Bug#1020509: doc-debian: Constitution text is outdated

[Joost van Baal-Ilić]

tags 1020509 +pending
thanks


On Thu, Sep 22, 2022 at 03:24:18PM +0200, Joost van Baal-Ilić wrote:
> On Thu, Sep 22, 2022 at 09:58:15AM -0300, Raúl Benencia wrote:
> > Package: doc-debian
> > Version: 6.5
> > Severity: normal
> > X-Debbugs-Cc: none, Raúl Benencia 
> > 
> > Dear Maintainer,
> > 
> > The current version of the Constitution for the Debian Project is
> > 1.8. The package contains v1.7. Please, consider updating the text.
> 
> I'm aware of this issue and it has been on my radar.  Anyway, thanks
> for reporting it here.
> 
> I'll get to it soonishlish.  (As always, patches/NMU's welcome.)

Fixed in git now.

Bye,

Joost

Bug#798012: #798012 doc-debian: unmarked rationale

[Joost van Baal-Ilić]

Hi Jakub,

Sorry for taking 8 years to reply on this useful suggestion... And thanks
for it!

On Fri, 4 Sep 2015 14:39:17 +0200 Jakub Wilk  wrote:
>
> /usr/share/doc/debian/constitution.txt.gz reads:
> "Text marked as a citation, such as this, is rationale and does not form
> part of the constitution."
>
> But in this text document, rationale is not marked in any way. It's
> therefore impossible to tell which parts are rationale and which are
> proper parts of the constitution without looking at the WML source.

It would be best / pragmatic to ship not just .txt copies, but also .html
typesetted stuff in the package; .html is created during build time, see
doc/Makefile.  As we say: patches welcome.

Bye,

Joost

Bug#1034467: debian-faq: difficulties understanding the concept of stable-updates from the docs

[Joost van Baal-Ilić]

Package: debian-history
Version: 11.1
Severity: normal

Hi kalle,

Thanks for your interest & reporting this issue!

On Sat, Apr 15, 2023 at 04:10:43PM +0200, kalle wrote:
> hello,
> Consulting (today) the Debian FAQ and the wiki i find it confusing and
> time-consuming to grasp, how packages are updated in the stable
> release.
> From the FAQ I understand that:
> -2.1:"it changes if major security or usability fixes are incorporated"
> -2.2:"only get security updates"
> 
> From the Wiki, Article "DebianSoftware", section "Updates to […]" I
> take, that the tracking of "buster-updates" brings the latest versions
> or backports for the important parts. 
> Buster-updates is recommended too in the article "DebianBullseye",
> section FAQ.
> 
> At least 2.1 and 2.2 contradict. The term "usability fixes" in 2.1.
> then could be explained a bit more, like it is done in the wiki article
> "DebianSoftware".

I'm filing this as a bug in the debian-faq package, so that it won't get lost.
Indeed it's not completely obvious to everybody which entries to use in
sources.list under which circumstances; I've heard more people asking about
this.  However, I don't know all details myself either, and unfortunately don't
have the time to do this research now.  Do you maybe have the time to come up
with a suggested text to put in e.g. the FAQ?

Thanks anyway!

Bye,

Joost

Bug#1033971: ITP: pyreadstat - read/write data sets from SAS, Stata, and SPSS from/to Python pandas.DataFrame

[Joost van Baal-Ilić]

Hi,

Op Wed, Apr 05, 2023 at 10:41:59AM +0200 schreef Joost van Baal-Ilić:

> * Package name: pyreadstat
>   Upstream Author : Evan Miller, Otto Fajardo e.a.
> * URL : https://pypi.org/project/pyreadstat 
> https://github.com/Roche/pyreadstat
> * License : Apache-2.0, MIT
>   Programming Lang: Python, C
>   Description : read/write data sets from SAS, Stata, and SPSS from/to 
> Python pandas.DataFrame
> 

> https://salsa.debian.org/python-team/packages/pyreadstat .

FWIW: This is in NEW now, at
https://ftp-master.debian.org/new/pyreadstat_1.2.1-1.html .  Futhermore,
there's a build for Debian 11/bullseye available from

 deb http://non-gnu.uvt.nl/debian bullseye uvt

, see http://non-gnu.uvt.nl/ for instructions.

Bye,

Joost

-- 
Joost van Baal-Ilić  https://abramowitz.uvt.nl/
 Tilburg University
mailto:joostvb.uvt.nl   The Netherlands

Bug#1033971: ITP: pyreadstat - read/write data sets from SAS, Stata, and SPSS from/to Python pandas.DataFrame

[Joost van Baal-Ilić]

Package: wnpp
Severity: wishlist

* Package name: pyreadstat
  Upstream Author : Evan Miller, Otto Fajardo e.a.
* URL : https://pypi.org/project/pyreadstat 
https://github.com/Roche/pyreadstat
* License : Apache-2.0, MIT
  Programming Lang: Python, C
  Description : read/write data sets from SAS, Stata, and SPSS from/to 
Python pandas.DataFrame

Binary package names: python3-pyreadstat

 A Python package to read and write popular stats packages files (like SAS
 (sas7bdat, sas7bcat, xport/xpt), SPSS (sav, zsav, por) and Stata (dta)) from
 and to Python pandas.DataFrame data structures.  This module is a wrapper
 around the Readstat C library by Evan Miller.

I'm planning to work on the pyreadstat packaging using
python-team's git at Salsa, at
https://salsa.debian.org/python-team/packages/pyreadstat .

Bye,

Joost

-- 
Joost van Baal-Ilić  https://abramowitz.uvt.nl/
 Tilburg University
mailto:joostvb.uvt.nl   The Netherlands


signature.asc
Description: PGP signature

Bug#1031513: clamav: new upstream security release, CVE-2023-20032

[Joost van Baal-Ilić]

Package: clamav
Severity: grave

Hi,

As you'll likely know there is
https://security-tracker.debian.org/tracker/CVE-2023-20032 and
https://blog.clamav.net/2023/02/clamav-01038-01052-and-101-patch.html

"CVE-2023-20032: Fixed a possible remote code execution vulnerability in the
HFS+ file parser. The issue affects versions 1.0.0 and earlier, 0.105.1 and
earlier, and 0.103.7 and earlier. Thank you to Simon Scannell for reporting
this issue."

Upstream released fixed tarballs for all their supported branches.  I've
managed to build 0.103.8+dfsg-0+deb10u1~uvt0 for Debian 10/buster from that,
it's available from https://non-gnu.uvt.nl/debian/buster/clamav/ (including
sources).

We are now running this build on the Tilburg University mail infrastructure,
it might work for others too.

Anybody working on a proper Debian supplied fix: feel free to contact me (via
IRC, e.g.)

HTH, Bye,

Joost

-- 
Joost van Baal-Ilić   http://abramowitz.uvt.nl/
 Tilburg University
mailto:joostvb.uvt.nl   The Netherlands


signature.asc
Description: PGP signature

Bug#1031214: eekboek-gui wordt een probleem

[Joost van Baal-Ilić]

Package: eekbook-gui


Hi,

On Mon, Feb 13, 2023 at 10:02:25AM +0100, somebody wrote:
> 
> He, ik zie net dat eekboek-gui van mijn laptop gegooid werd. Da's ook jammer!
> 
> apt install eekboek-gui
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  libalien-wxwidgets-perl : Depends: libwxgtk3.2-dev (< 3.2.2~) but 
> 3.2.2+dfsg-1 is to be installed
>Depends: libwxgtk-media3.2-dev (< 3.2.2~) but 
> 3.2.2+dfsg-1 is to be installed
> E: Unable to correct problems, you have held broken packages.
> 
> 

Seems there's something going on with eekbook-gui on some of our
releases.

Hope to be able to assign some time to this soonish.

Bye,

Joost

Bug#1030530: pyenv / Re: Python 3.10 in bookworm

[Joost van Baal-Ilić]

Hi karthek e.a.,

Op Tue, Feb 07, 2023 at 10:50:07PM +0530 schreef karthek:
> Sorry for spamming…
> Resending the same message, I just remembered debian.org ignores mails
> from mail@* addresses.
> 
> On Tue, Feb 07, 2023 at 02:24:08PM +, Stefano Rivera wrote:
> > > See "ITP pyenv" @ http://bugs.debian.org/978149 .
> > 
> > I think the Python development community would be very happy to see
> > this. Debian's selected Python releases don't meet all the needs of
> > Python developers, who typically want access to all supported Python 3
> > versions (and possibly the next alpha), at all times.
> > 
> 
> Indeed.
> 
> > I'd be happy to review and sponsor uploads.
> > 
> 
> Thanks Stefano, I packaged it almost 2 years ago while working on
> Android Open-source project (AOSP). While I got response from upstream,
> I Haven't got any response from debian community back then apart from
> interest in it from Julian a year ago.
> 
> Since then I also didn't find any DD nearyby my city to sign my key.
> 
> I'm happy to work on the packaging…
> 

I've just found some work of you @ https://salsa.debian.org/karthek/pyenv .
Nice!

I see you've published just one branch ("master") and did not copy upstream
sources to salsa.  You might want to consider converting it to make use of the
gbp style packaging, as used by https://salsa.debian.org/python-team .

BTW: unfortunately I don't have any more time to invest in this... :(

Happy Hacking!

Bye,

Joost

-- 
“For if I am mistaken, I am. For one who does not exist cannot be mistaken
either.”– St. Augustine of Hippo, De Civitate Dei,
book XI, 26, early 5th century AD.

Bug#1030776: ITP: quickjs -- small and embeddable Javascript engine

[Joost van Baal-Ilić]

Package: wnpp
Severity: wishlist
Owner: Sebastian Humenda 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
pkg-a11y-de...@alioth-lists.debian.net, shume...@gmx.de

* Package name: quickjs
  Version : 2021.03.27
  Upstream Contact: Fabrice Bellard, Charlie Gordon
* URL : https://bellard.org/quickjs/
* License : MIT
  Programming Lang: C
  Description : small and embeddable Javascript engine

 QuickJS is a small and embeddable Javascript engine. It supports the
 ES2020 specification, including modules, asynchronous generators, proxies and
 BigInt.
 .
 It supports mathematical extensions such as big decimal float float
 numbers (BigDecimal), big binary floating point numbers (BigFloat),
 and operator overloading.

This package is required as a dependency of Edbrowse. It has no further
dependencies.

Bye,

Joost - on behalf of Sebastian Humenda

Bug#1030530: Python 3.10 in bookworm

[Joost van Baal-Ilić]

Op Tue, Feb 07, 2023 at 05:52:21AM + schreef Danial Behzadi دانیال بهزادی:
> Does it worth trying to package pyenv for Debian? Ain't it against any rules?

See "ITP pyenv" @ http://bugs.debian.org/978149 .

Bye,

Joost

-- 
Joost van Baal-Ilić   http://abramowitz.uvt.nl/
 Tilburg University
mailto:joostvb.uvt.nl   The Netherlands

Bug#981496: svtools: ship with bullseye?

[Joost van Baal-Ilić]

Priority 981496 normal
Thanks

Hi Adrian,

Thanks for this notification, and sorry for not responding ealier.  Chris filed
the original bug, but didn't indicate any actual breakage of the package.  Age
alone would, afaik, not be a reason to stop shipping a package; nor would lack
of a formal maintainer be.  These indeed _could_ indicate trouble with the
package (so thanks Chris for creating awareness), but are not sufficient for
blocking it from entering testing.  No record of actual breakage is filed
upstream.  Therefore I feel the priority of this bug should get lowered, and
svtools should get shipped with bullseye as-is.

Adjusting; and hoping I'm not too late here.

Bye,

Joost

On Sat, Feb 04, 2023 at 10:36:12PM +0200, Adrian Bunk wrote:
> Hi Joost,
> 
> if you as maintainer of daemontools think this package would be useful 
> in bookworm, please close the bug (and consider adopting the package).
> 
> Thanks
> Adrian
> 
> 
> On Wed, Sep 08, 2021 at 02:25:01PM +0300, Adrian Bunk wrote:
> > On Sun, Jan 31, 2021 at 10:35:45PM +0100, Chris Hofstaedtler wrote:
> > > Package: svtools
> > > Version: 0.6-4
> > > Severity: important
> > > 
> > > Hi,
> > > 
> > > the package "svtools" has been orphaned by its original maintainer
> > > over 7 years ago. The Debian maintainer was also the upstream
> > > maintainer. Upstream has archived the project, and the last change
> > > was over 9 years ago.
> > > 
> > > Is this still useful software? Should we continue to ship it?
> > > 
> > > If you are interested, please speak up now.
> > >...
> > 
> > Jan, you intend to addopt daemontools.
> > 
> > Can you check whether svtools is still useful for Debian
> > (and if yes, ideally also adopt it)?

Bug#1029431: ITP: pyequihash -- python bindings for libequihash: memory-hard Proof-of-Work with fast verification

[Joost van Baal-Ilić]

Package: wnpp
Severity: wishlist
Owner: Joost van Baal-Ilić 

* Package name: pyequihash
  Version : 0.2
  Upstream Author : Stefan Marsiske 
* URL : https://github.com/stef/equihash/python
* License : GPLv3
  Programming Lang: Python
  Description : python bindings for libequihash: memory-hard Proof-of-Work 
with fast verification

Binary package name: python3-equihash

 Equihash implements the algorith as described in "Equihash: Asymmetric 
Proof-of-Work
 Based on the Generalized Birthday Problem" by Alex Biryukov and Dmitry
 Khovratovich, 2016, DOI:10.14722/ndss.2016.23108.  This code, by Stefan 
Marsiske, is
 a fork of an ealier implementation by Khovratovich at
 https://github.com/khovratovich/equihash/ ; it provides a library, a C API and
 Python bindings.  The cryptographic password storage SPHINX (pwdsphinx and 
libsphinx)
 depend upon equihash.
 .
 This package offers a Python wrapper for the C library and comes with functions
 equihash.solve(n, k, seed) and equihash.verify (n,k,seed,sol).

See https://www.ctrlc.hu/~stef/blog/posts/sphinx.html and
https://nlnet.nl/project/OpaqueSphinxServer/ for more background information.

See e.g. https://core.ac.uk/download/pdf/31227294.pdf for a copy of the original
article.

The SPHINX project was funded through the NGI0 PET Fund, a fund established by
NLnet with financial support from the European Commission's Next Generation
Internet programme, under the aegis of DG Communications Networks, Content and
Technology under grant agreement No 825310.

I intend to carry out this work within the Debian Python Team, at the yet to be
created https://salsa.debian.org/python-team/packages/pyequihash .

The libequihash package which is now in unstable ( see
https://tracker.debian.org/pkg/libequihash ) currently holds the same python
code.  I'll upload a new version of this original libequihash package without
the python wrapper code; it will no longer build python3-equihash.  Packaging
pyequihash from this pypi upstream sources is done in order to simplify the
Debian packaging work (and by doing so fix some RC bugs).

Bye,

Joost

Bug#1028518: Bug is fixed upstream..

[Joost van Baal-Ilić]

Hi,

On Fri, Jan 13, 2023 at 10:54:51AM +1100, Peter Chubb wrote:
> The current mailman3 upstream source is fixed.
> 
> https://gitlab.com/mailman/mailman/-/commit/1954815f32fea4d9d920cdc74f63bcc24d3b6c49
> 
> fixed python3.11 compatibility.

And fwiw I believe this fixed made it in upstream Mailman 3.3.8 which was 
shipped
04-Jan-2023.

HTH, Bye,

Joost

Bug#1028129: #1028129: securestring FTBFS: fatal error: Python.h: No such file or directory

[Joost van Baal-Ilić]

On Tue, Jan 10, 2023 at 06:26:54PM +0800, Bo YU wrote:
> On Mon, Jan 9, 2023 at 10:35 PM Joost van Baal-Ilić
>  wrote:
> >
> > Bo YU: thanks a lot for your recent work on securestring!  Do you plan
> > to upload it, or would you prefer me to handle that?  (I have time
> > to take care of it this week.)
> 
> Yeah, I need your help to upload it as usual(I do not have permission
> to upload package now).
> But before I reply to you, bage has helped to upload it already.
> 
> Anyway, thanks to all here.:)

Excellent, thanks!

Bye,

Joost

Bug#1028129: #1028129: securestring FTBFS: fatal error: Python.h: No such file or directory

[Joost van Baal-Ilić]

Hi,

Bo YU: thanks a lot for your recent work on securestring!  Do you plan
to upload it, or would you prefer me to handle that?  (I have time
to take care of it this week.)

Bye,

Joost

Bug#1024239: libequihash: baseline violation on i386 and FTBFS on !x86

[Joost van Baal-Ilić]

reopen 1024239
thanks

Hi Adrian,

On Mon, Jan 09, 2023 at 02:16:28AM +0200, Adrian Bunk wrote:
> 
> sorry for the late reply.
> 
> On Thu, Dec 29, 2022 at 03:43:18PM +0100, Joost van Baal-Ilić wrote:
> > 
> > 
> > Thanks, after consulting with upstream this should be fixed in new upstream
> > https://github.com/stef/equihash/archive/refs/tags/v1.0.3.tar.gz which has
> > https://github.com/stef/equihash/commit/0806afadf99837519469449c55dc425763e8eef7
> > .  I'll upload a new package soonishlish.
> 
> a second baseline violation I missed in my original bug report is
> -march=native, which FTBFS on some architectures and where it builds
> the package would only run on hardware compatible with whatever buildd
> did build the package (on amd64 this also means either on AMD or on 
> Intel hardware).
> 
> Regarding the binary-any FTBFS, this can be reproduced in a chroot
> with "dpkg-buildpackage -B".
> 
> sbuild has a --no-arch-all option that might do the same (untested).
> 
> python3-equihash is the binary-all package, what seems to fail is 
> debian/rules trying to build it in binary-any-only builds.

Thanks for detailed explanation.  I saw my latest upload FTBFS again, indeed.
Upstream helpfully released yet another version, I'll investigate later this
week.

Bye,

Joost

Bug#891417: #891417: systraq: error message during package installation 'ls: cannot access '/home/*/.ssh/a*': ...'

[Joost van Baal-Ilić]

Hi again,

On Sun, Jan 03, 2021 at 01:47:46PM +0100, Joost van Baal-Ilić wrote:
> 
> Thank you for your interest in systraq and reporting the issue.  It's indeed
> an annoying message.
> 
> From: Peter Wiersig , Date: Sun, 25 Feb 2018 13:06:42 
> +0100:
> >
> > during package installation the line
> > 
> > ls: cannot access '/home/*/.ssh/a*': No such file or directory
> > 
> > gets printed after package installation and my systems etckeeper
> > run. My examination showed it initially from
> > /etc/systraq/Makefile, after installing the version from buster
> > the line comes from /usr/include/systraq/filetraq.mk
> > 
> > I'm guessing the debian-systraq user isn't allowed to peek into my
> > users home dirs due to filesystem permissions, but even if I
> > change the one or two users directories now, future users adding
> > the authorized_keys file in the future might get missed.
> 
> The culprit is indeed in usr/include/systraq/filetraq.mk , in
> 
> filetraq.main.conf:
>   echo '# $@: automatically generated' > $@
>   find /etc -not -readable -and -prune -or \( -perm -a+r -and -type f 
> -and -print \) | sort >> $@
>   ls -1 /home/*/.ssh/a* | sort >> $@
> 
> which is executed as user debian-systraq, e.g. during package upgrade via
> /etc/apt/apt.conf.d/20systraq .
> 
> I'd like this code to give an error message if permissions are lacking, but
> ideally _not_ when no files /home/*/.ssh/a* are present on the system.  I
> haven't managed to produce not too complicated code which does just that.
> I'll spend some more brain cycles on it.
> 
> Anyway, as is commonly said: patches are welcome...

For the record: this _almost_ does what I want:

 find /home -maxdepth 3 -not -readable -and -prune -or \( -name 
"authorized_keys*" -and -path "*/.ssh*" \)

.

I want both ~/.ssh/ and ~/.ssh2/ .  I want both authorized_keys and 
authorized_keys2 .

TL:DR; WiP...

Bye,

Joost

Bug#1000594: #1000594 / Re: Bug#1027404: RFS: sfeed/1.6-1 [ITP] -- simple RSS and Atom parser

[Joost van Baal-Ilić]

Hi,

FYI: Just uploaded Hiltjo's new sfeed_1.6-1.

Bye,

Joost

Bug#983804: ITA ucspi-tcp and ucspi-unix

[Joost van Baal-Ilić]

*ping*

Any news?

Bye,

Joost

Bug#1027404: RFS: sfeed/1.6-1 [ITP] -- simple RSS and Atom parser

[Joost van Baal-Ilić]

Hi,

Paul: Thanks for the Cc.

On Fri, Dec 30, 2022 at 11:46:29PM +0100, Hiltjo Posthuma wrote:
> On Fri, Dec 30, 2022 at 04:45:53PM -0500, Paul Tagliamonte wrote:
> > On Fri, Dec 30, 2022 at 10:38:52PM +0100, Matteo Bini wrote:
> > > Package: sponsorship-requests
> > > Severity: wishlist
> > > 
> > > Dear mentors,
> > > 
> > > I am looking for a sponsor for my package "sfeed":
> > 
> > sfeed_1.6-1_amd64 was uploaded to NEW, and rejected due to a very
> > fixable copyright oversight. I don't see it in NEW or the archive,
> > so I'm going to CC the last folks to package this, perhaps you can
> > deduplicate your work.

> 
> I've sent a new version to Joost a while ago (12 november), it should fix all
> the issues. There was some delay in the reply from Joost. I don't know the
> current status of my submitted changes.
> 
> The new files are available via the following URL:
> https://codemadness.org/downloads/ports/debian/sfeed/

That would be

 dget https://codemadness.org/downloads/ports/debian/sfeed/sfeed_1.6-1.dsc

.

> In the debian/copyright file is added:
> 
> Files: strlcat.c
> Files: strlcpy.c
> Copyright: 1998, 2015 Todd C. Miller 
> License: ISC
> 
> strlcat.c en strlcpy.c are copied from OpenBSD and are used for compatibility
> with the C functions strlcat() and strlcpy(). They are also ISC licensed.

I didn't have the time yet to have a look at Hiltjo's latest work.  Paul and
Matteo: Feel free to sponsor an upload of Hiltjo's code.

If not, I might get to it later.

Bye,

Joost

Bug#1024239: reopen / Re: Bug#1024239: marked as done (libequihash: baseline violation on i386 and FTBFS on !x86)

[Joost van Baal-Ilić]

reopen 1024239
thanks

https://buildd.debian.org/status/fetch.php?pkg=libequihash=amd64=1.0.4-1=1672405470=0

shows build on amd64 still fails.



On Fri, Dec 30, 2022 at 12:51:19PM +, Debian Bug Tracking System wrote:
> Your message dated Fri, 30 Dec 2022 12:49:19 +
> with message-id 
> and subject line Bug#1024239: fixed in libequihash 1.0.4-1
> has caused the Debian Bug report #1024239,
> regarding libequihash: baseline violation on i386 and FTBFS on !x86
> to be marked as done.

Bug#1024239: libequihash: baseline violation on i386 and FTBFS on !x86

[Joost van Baal-Ilić]

Thanks, after consulting with upstream this should be fixed in new upstream
https://github.com/stef/equihash/archive/refs/tags/v1.0.3.tar.gz which has
https://github.com/stef/equihash/commit/0806afadf99837519469449c55dc425763e8eef7
.  I'll upload a new package soonishlish.

Bye,

Joost


On Wed, Nov 16, 2022 at 11:37:01AM +0200, Adrian Bunk wrote:
> Source: libequihash
> Version: 1.0.2-3
> Severity: serious
> Tags: ftbfs
> 
> https://buildd.debian.org/status/fetch.php?pkg=libequihash=arm64=1.0.2-3=1668331092=0
> 
> ...
> make[1]: Entering directory '/<>'
> g++ -c -Wall -g -O3 -std=c++17 -fstack-protector-strong -D_FORTIFY_SOURCE=2 
> -fasynchronous-unwind-tables -fpic -Werror=format-security -Wl,-z,defs 
> -Wl,-z,relro -ftrapv -Wl,-z,noexecstack -march=native 
> -fstack-clash-protection -fcf-protection=full -o equihash.o equihash.cc
> cc1plus: error: ‘-fcf-protection=full’ is not supported for this target
> make[1]: *** [Makefile:16: equihash.o] Error 1
> 
> 
> -fcf-protection=full is an x86-only option not supported on
> other architectures.
> 
> -fcf-protection=full violates the i386 baseline,
> please use it only on amd64.

Bug#1023113: ITP: pwdsphinx -- SPHINX password storage protocol

[Joost van Baal-Ilić]

Package: wnpp
Severity: wishlist
Owner: Joost van Baal-Ilić 

* Package name: pwdsphinx
  Version : 1.0.6
  Upstream Author : Stefan Marsiske
* URL : https://github.com/stef/pwdsphinx ,
 https://www.ctrlc.hu/~stef/blog/posts/sphinx.html
* License : GPL-3+, CC-BY-SA-4.0
  Programming Lang: Python
  Description : SPHINX password storage protocol

 SPHINX -- password Store that Perfectly Hides from Itself (No Xaggeration) --
 is an information-theoretically secure cryptographic password storage
 protocol with strong security guarantees, as described in the 2015 paper
 "Device-Enhanced Password Protocols with Optimal Online-Offline Protection" by
 Jarecki, Krawczyk, Shirvanian, and Saxena (https://ia.cr/2015/1099).
 .
 This package [pwdsphinx] contains a CLI frontend ("sphinx"), a reference
 server implementation ("oracle") and a python wrapper for the SPHINX protocol.
 .
 This package [pwdsphinx-tools] contains 4 simple scripts which
   - wrap the client to query the master password securely using
 pinentry: "getpwd",
   - a tool "exec-on-click" which executes a command on mouse-click,
   - a tool "type-pwd" that combines the two previous tools to insert a
 password without using the clipboard,
   - and a dmenu wrapper "dmenu-sphinx" that uses all of the above to retrieve
 usernames and passwords for given hosts.
 Some of these tools can also be used for other password managers,
 that are using the clipboard to deliver passwords to the UI.

I am working on this package at https://salsa.debian.org/debian/pwdsphinx .

The package pwdsphinx depends upon python3-securestring, libsphinx0 and
libequihash0; these (securestring, libsphinx, libequihash) are in NEW now; ITPs
#1023014, #1022862, #1021433.

The SPHINX project was funded through the NGI0 PET Fund, a fund established by
NLnet with financial support from the European Commission's Next Generation
Internet programme, under the aegis of DG Communications Networks, Content and
Technology under grant agreement No 825310.

Bye,

Joost

Bug#1023014: ITP: securestring -- Clearing the contents of strings containing cryptographic material

[Joost van Baal-Ilić]

Package: wnpp
Severity: wishlist
Owner: Joost van Baal-Ilić 

* Package name: securestring
  Version : 0.2
  Upstream Author : András Veres-Szentkirályi, Lawrence Fan
* URL : https://pypi.org/project/SecureString/,
 https://github.com/aznashwan/py-securestring
* License : MIT
  Programming Lang: Python
  Description : Clearing the contents of strings containing cryptographic 
material

  Python wrapper around OPENSSL_cleanse() which fills a pointer with a string
  of 0's, typically used to clear the contents of strings containing
  cryptographic material.

I am maintaining this package as part of the Python team, I am working
in https://salsa.debian.org/python-team/packages/securestring .

I plan to package "pwdsphinx" too ( https://salsa.debian.org/debian/pwdsphinx ,
https://github.com/stef/pwdsphinx , ITP will follow); pwdsphinx will depend
upon python3-securestring.  See also Bug#1022862: ITP: libsphinx and
Bug#1021433: ITP: libequihash.

The SPHINX project was funded through the NGI0 PET Fund, a fund established by
NLnet with financial support from the European Commission's Next Generation
Internet programme, under the aegis of DG Communications Networks, Content and
Technology under grant agreement No 825310.

Bye,

Joost

Bug#1022862: ITP: libsphinx -- SPHINX password storage library

[Joost van Baal-Ilić]

Package: wnpp
Owner: Joost van Baal-Ilić 
Severity: wishlist

* Package name: libsphinx
  Upstream Author : Stefan Marsiske
* URL : https://github.com/stef/libsphinx
* License : LGPL-3+
  Programming Lang: C
  Description : SPHINX password storage library

 SPHINX -- password Store that Perfectly Hides from Itself (No Xaggeration) --
 is an information-theoretically secure cryptographic password storage
 protocol with strong security guarantees, as described in the 2015 paper
 "Device-Enhanced Password Protocols with Optimal Online-Offline Protection" by
 Jarecki, Krawczyk, Shirvanian, and Saxena (https://ia.cr/2015/1099).

 libsphinx is a low-level library implementing SPHINX.

I plan to package "pwdsphinx" too ( https://salsa.debian.org/debian/pwdsphinx ,
https://github.com/stef/pwdsphinx , ITP will follow); pwdsphinx will depend
upon libequihash (ITP #1021433, https://salsa.debian.org/debian/libequihash)
and libsphinx.

I'm using https://salsa.debian.org/debian/libsphinx for the packaging work.

See https://www.ctrlc.hu/~stef/blog/posts/sphinx.html and
https://nlnet.nl/project/OpaqueSphinxServer/ for more background information.

The SPHINX project was funded through the NGI0 PET Fund, a fund established by
NLnet with financial support from the European Commission's Next Generation
Internet programme, under the aegis of DG Communications Networks, Content and
Technology under grant agreement No 825310.

Bye,

Joost

Bug#1021709: manpages.debian.org: FAQ is full of deadlinks, incl. to the static assets repo

[Joost van Baal-Ilić]

Hi наб,

On Thu, Oct 13, 2022 at 02:15:56PM +0200, наб wrote:
> On Thu, Oct 13, 2022 at 01:55:42PM +0200, Joost van Baal-Ilić wrote:
> > https://dyn.manpages.debian.org/faq.html redirects here to
> > https://manpages.debian.org/bullseye/avr-libc/FAQ.3avr.en.html which I 
> > asssume
> > is build from  avr-libc 1:2.0.0+Atmel3.6.2-1.1 .  I guess you'd have to 
> > report
> > a bug to avr-libc.  *But* I can't find any of the problems you've found in 
> > the
> > webpage @ https://manpages.debian.org/bullseye/avr-libc/FAQ.3avr.en.html 
> > 
> 
> Of course it does. I even got this once while testing.
> This is a caching issue ‒ for me it shows the Manpages FAQ,
> and if I Ctrl-Shift-R it shows the avr-libc FAQ(3) like it does for you.
> 
> So this is another bug, I guess, since the top bar links to
> dyn.m.d.o/faq.html instead of the correct dyn.-free page on the error
> pages for example (i got there from the nonexistent m.d.o/unrar, which
> redirected me to dyn.m.d.o/unrar to show me the 404).
> 
> My report concerns the Debian Manpages FAQ with canonical URL
>   https://manpages.debian.org/faq.html
> (at least I hope that's the canonical URL!)

Aha!  It seems debiman is where this should get reported.  Either

 reportbug debiman

(it's shipped with unstable and oldstable) or @ 
https://github.com/Debian/debiman/ .

HTH, Bye,

Joost

Bug#1021709: manpages.debian.org: FAQ is full of deadlinks, incl. to the static assets repo

[Joost van Baal-Ilić]

Hi наб,

Thanks for your report!

On Thu, Oct 13, 2022 at 01:26:24PM +0200, наб wrote:
> Package: manpages.debian.org
> Severity: normal
> 
> Dear Maintainer,
> 
> https://dyn.manpages.debian.org/faq.html:
>   source code: 
> https://anonscm.debian.org/git/collab-maint/debian-goodies.git/plain/dman?id=19924c907a8b907eaea3c0d942c5ae780ef6111e
>   static assets repository: 
> https://anonscm.debian.org/git/srv-manpages/debian-assets.git/
>   hosted on Alioth: 
> https://anonscm.debian.org/git/srv-manpages/debian-assets.git/
>404, AIUI anonscm/alioth has been dead for years
> 
>   Alioth project: https://alioth.debian.org/projects/srv-manpages/
>   doesn't even resolve
> 
>   mdocml: http://mdocml.bsd.lv/
>   Report at mdocml: http://mdocml.bsd.lv/contact.html
>   it's been mandoc for close to a decade, and should be
>   mandoc: https://mandoc.bsd.lv/
>   Report at mandoc: http://mandoc.bsd.lv/contact.html
> 
> I'd post a patch, but, well. No clue what against, given the givens.

https://dyn.manpages.debian.org/faq.html redirects here to
https://manpages.debian.org/bullseye/avr-libc/FAQ.3avr.en.html which I asssume
is build from  avr-libc 1:2.0.0+Atmel3.6.2-1.1 .  I guess you'd have to report
a bug to avr-libc.  *But* I can't find any of the problems you've found in the
webpage @ https://manpages.debian.org/bullseye/avr-libc/FAQ.3avr.en.html 

Bye,

Joost

Bug#1021433: ITP: libequihash -- memory-hard Proof-of-Work with fast verification

[Joost van Baal-Ilić]

Package: wnpp
Owner: Joost van Baal-Ilić 
Severity: wishlist

* Package name: libequihash
  Upstream Author : Dmitry Khovratovich and Stefan Marsiske
* URL : https://github.com/stef/equihash
* License : CC0-1.0
  Programming Lang: C++
  Description : memory-hard Proof-of-Work with fast verification

 Equihash implements the algorith as described in "Equihash: Asymmetric
 Proof-of-Work Based on the Generalized Birthday Problem" by Alex Biryukov and
 Dmitry Khovratovich, 2016, DOI:10.14722/ndss.2016.23108.  This code, by Stefan
 Marsiske, is a fork of an earlier implementation by Khovratovich at
 https://github.com/khovratovich/equihash/ ; it provides a library, a C API and
 Python bindings.  The cryptographic password storage SPHINX (pwdsphinx and
 libsphinx) depend upon equihash.


Upstream started packaging work at
https://github.com/stef/equihash/tree/master/debian .  I'll work from that
first packaging code, probably using a repository at salsa.debian.org .

See https://www.ctrlc.hu/~stef/blog/posts/sphinx.html and
https://nlnet.nl/project/OpaqueSphinxServer/ for more background information.

See e.g. https://core.ac.uk/download/pdf/31227294.pdf for a copy of the original
article.

The SPHINX project was funded through the NGI0 PET Fund, a fund established by
NLnet with financial support from the European Commission's Next Generation
Internet programme, under the aegis of DG Communications Networks, Content and
Technology under grant agreement No 825310.

Bye,

Joost

Bug#1020509: doc-debian: Constitution text is outdated

[Joost van Baal-Ilić]

Hi Raúl,

On Thu, Sep 22, 2022 at 09:58:15AM -0300, Raúl Benencia wrote:
> Package: doc-debian
> Version: 6.5
> Severity: normal
> X-Debbugs-Cc: none, Raúl Benencia 
> 
> Dear Maintainer,
> 
> The current version of the Constitution for the Debian Project is
> 1.8. The package contains v1.7. Please, consider updating the text.

I'm aware of this issue and it has been on my radar.  Anyway, thanks
for reporting it here.

I'll get to it soonishlish.  (As always, patches/NMU's welcome.)

Bye,

Joost

Bug#1000594: ITP: sfeed -- Collection of command-line tools for processing RSS and Atom feeds

[Joost van Baal-Ilić]

Hi,

For the record, I plan to sponsor this upload; I'm in conversation with Hiltjo
about this.

Hiltjo: thanks for your work.

Bye,

Joost

Bug#1019537: brightnessctl is likely better / Re: Bug#1019537: RFP: backlightctl -- Lightweight monitor backlight control utility

[Joost van Baal-Ilić]

On Sun, Sep 11, 2022 at 02:30:22PM +0200, Joost van Baal-Ilić wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: backlightctl
>   Upstream Author : P "hellerbarde" Stark
> * URL : https://github.com/hellerbarde/backlightctl

> 
> Upstream ships no formal release yet; it's been sitting in a github git repo
> since 2012.  There's a cmake buildsystem supplied.  No upstream manpage yet.
> 
> I like it since it's pretty small and does _just_ what's needed; nothing more.

But maybe it's usefulness is debatable since we're shipping the more actively
maintained brightnessctl since at least buster/oldstable...

Bye,

Joost

Bug#1019537: RFP: backlightctl -- Lightweight monitor backlight control utility

[Joost van Baal-Ilić]

Package: wnpp
Severity: wishlist

* Package name: backlightctl
  Upstream Author : P "hellerbarde" Stark
* URL : https://github.com/hellerbarde/backlightctl
* License : MIT/X
  Programming Lang: C
  Description : Lightweight monitor backlight control utility

 Really lightweight (<100 SLOC) monitor backlight control utility written in C
 that directly writes to the /sys/ filesystem.  The config file is read from
 /etc/backlightctl.conf. It must contain exactly 2 lines. The first one points
 to the file controlling the brightness. The second line points to the file
 containing the maximal brightness.

Upstream ships no formal release yet; it's been sitting in a github git repo
since 2012.  There's a cmake buildsystem supplied.  No upstream manpage yet.

I like it since it's pretty small and does _just_ what's needed; nothing more.

Bye,

Joost

Bug#1014511: sysvinit: debian/copyright reports incorrect licenses

[Joost van Baal-Ilić]

Hi,

On Mon, Aug 22, 2022 at 02:49:59AM +, binh1.tran...@toshiba.co.jp wrote:
> 
> I sent an e-mail "sysvinit: License of debian/po/vi.po file" to Clytie 
> Siddall from 2022/07/11
> But maybe Clytie Siddall is busy in his/her work.
> And I haven't received  any feedback from him/her.

Clytie Siddall (she/her) passed away in February 2015.
https://www.debian.org/doc/manuals/project-history/detailed.en.html#2015-02
She is truely missed.

Bye,

Joost

Bug#1009728: gnome-shell 42.0-3 depends instead of recommends power-profiles-daemon, conflicts with tlp

[Joost van Baal-Ilić]

Hi Gijs,

Could you please share the output of

 dpkg --get-selections | egrep -v install\|purge

?  Maybe you've set another package on hold which causes
this problem on your system.

HTH, Bye,

Joost

Bug#1002249: debian-faq: FTBFS: grep: nullfont.log: No such file or directory

[Joost van Baal-Ilić]

On Tue, Dec 21, 2021 at 05:32:16PM +0100, Lucas Nussbaum wrote:
> Source: debian-faq
> Version: 10.1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20211220 ftbfs-bookworm
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.


> > This is METAFONT, Version 2.71828182 (TeX Live 2022/dev/Debian) (preloaded 
> > base=mf)
> > 
> > kpathsea: Running mktexmf nullfont
> > 
> > ! I can't find file `nullfont'.
> > <*> ...four; mag:=1; ; nonstopmode; input nullfont
> >   
> > Please type another input file name
> > ! Emergency stop.
> > <*> ...four; mag:=1; ; nonstopmode; input nullfont
> >   
> > Transcript written on mfput.log.
> > grep: nullfont.log: No such file or directory
> > mktextfm: `mf-nowin -progname=mf \mode:=ljfour; mag:=1; ; nonstopmode; 
> > input nullfont' failed to make nullfont.tfm.
> > kpathsea: Appending font creation commands to missfont.log.
> > xelatex failed
> > stdin.tex:24: Package fontspec Error: The font "CharisSIL-R" cannot be 
> > found.

> > stdin.tex:538: Font TU/CharisSIL-R.ttf(0)/b/n/12=[CharisSIL-B.ttf]/OT at 
> > 12.0pt not loadable: Metric (TFM) file or installed font not found.
> > stdin.tex:538: leading text:  T
> > .:1787: Font TU/CharisSIL-R.ttf(0)/b/n/8=[CharisSIL-B.ttf]/OT at 8.0pt not 
> > loadable: Metric (TFM) file or installed font not found.
> > .:1787: leading text: }
> > Unexpected error occured
> > Error: list index out of range
> > make[2]: *** [Makefile:169: en/debian-faq.en.pdf] Error 1
> 
> 
> The full build log is available from:
> http://qa-logs.debian.net/2021/12/20/debian-faq_10.1_unstable.log
> 
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> 
> If you reassign this bug to another package, please marking it as 
> 'affects'-ing
> this package. See https://www.debian.org/Bugs/server-control#affects
> 
> If you fail to reproduce this, please provide a build log and diff it with 
> mine
> so that we can identify if something relevant changed in the meantime.

Thank you for reporting this, and thank you for your massive rebuild efforts:
much appreciated.  I'll look into this issue soonishlish.

Bye,

Joost

Bug#1000155: sorry for the noise / Re: #1006908 ITA: daemontools -- collection of tools for managing UNIX services

[Joost van Baal-Ilić]

Oops, this message belonged somewhere else, sorry for the noise!

Joost

On Tue, Mar 08, 2022 at 06:13:52AM +0100, Joost van Baal-Ilić wrote:
> retitle 1006908 ITA: daemontools -- collection of tools for managing UNIX 
> services

Bug#1000155: #1006908 ITA: daemontools -- collection of tools for managing UNIX services

[Joost van Baal-Ilić]

retitle 1006908 ITA: daemontools -- collection of tools for managing UNIX 
services
owner 1006908 !
thanks

I intend to adopt the daemontools package, and upload it with myself as Mainter
in debian/control.

On Date: Tue, 8 Mar 2022 05:50:26 +0100, Jan Mojzis  
wrote:
> I planned to manage the daemontools package (new repo is here
> https://salsa.debian.org/debian/daemontools), but I didn't get a sponsor.  I
> leave the packaging to someone else.  The package is orphaned.

Jan: Would you like to be recorded as co-maintainer?  (Listed in Uploaders: in
debian/control .)

Anyway, thanks a lot for setting up the salsa repo, that's very helpful.  And
thanks a lot for your work on the packaging, of course!  At a first glance, it
looks ready for uploading: very nice work.

Bye,

Joost



signature.asc
Description: PGP signature

Bug#1003247: workaround / Re: Bug#1003247: mailman3-web: Mailman3 not working following distribution upgrade from Debian 10 to 11.

[Joost van Baal-Ilić]

On Thu, Jan 06, 2022 at 06:14:26PM -0500, Gordon Dickens wrote:
> Package: mailman3-web
> Version: 0+20200530-2
> Severity: important
> 
> Dear Maintainer,
> 
> I performed a distribution upgrade from Debian 10 Buster (which runs mailman
> 3.2.1) to Debian 11 Bullseye (which runs mailman 3.3.1) with the command
> "apt-get full-upgrade -y" and everything apparently worked properly except at
> the end of the upgrade when the following error dialog was generated by the
> mailman3-web and mailman3-full post-installation scripts:
> 
> Setting up mailman3-web (0+20200530-2) ...
> Determining localhost credentials from /etc/mysql/debian.cnf: succeeded.
> dbconfig-common: writing config to /etc/dbconfig-common/mailman3-web.conf
> dbconfig-common: flushing administrative password
> sed: -e expression #2, char 77: unterminated `s' command
> dpkg: error processing package mailman3-web (--configure):
>  installed mailman3-web package post-installation script subprocess returned
>  error exit status 1
> dpkg: dependency problems prevent configuration of mailman3-full:
>  mailman3-full depends on mailman3-web; however:
>   Package mailman3-web is not configured yet.
> 
> dpkg: error processing package mailman3-full (--configure):
>  dependency problems - leaving unconfigured
> Errors were encountered while processing:
>  mailman3-web
>  mailman3-full
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 

> 
> So, I am now stuck

> 
> Does anybody have any idea how to fix this?  I would very much appreciate 
> some suggestions.
> 

Not a fix, but a _very_ _dirty_ workaround:

 sudo mv /var/lib/dpkg/info/mailman3-web.postinst 
/var/lib/dpkg/info/mailman3-web.postinst.disabled

(Only do this if everything else failed.) After that, try the install again by
running

 sudo apt-get -f install

.  Your can now do dpkg/apt stuff again.  However, you'll have to manually
execute all the needed things /var/lib/dpkg/info/mailman3-web.postinst was
trying to achieve: have a look at that script.

HTH, Bye,

Joost

Bug#993009: RFP: cimfomfa -- tingea library for mcl

[Joost van Baal-Ilić]

Hi,

Minor update.

On Mon, Nov 01, 2021 at 08:01:16PM +0100, Joost van Baal-Ilić wrote:
> On Mon, Sep 06, 2021 at 02:05:33PM +0200, Joost van Baal-Ilić wrote:
> > On Thu, Aug 26, 2021 at 11:26:55AM +0200, Joost van Baal-Ilić wrote:
> > >
> > > * Package name: cimfomfa
> > >   Upstream Author : Stijn van Dongen 
>
> URL : https://github.com/micans/cimfomfa
>
> > > * License : GPL-3+
> > >   Programming Lang: C
>
> Description : C utility library libtingea for MCL and zoem
>
> Long description:
>
> cimfomfa is used by both MCL, a cluster algorithm for graphs, and zoem,
> a macro/DSL language. It supplies abstractions for memory management, I/O,
> associative arrays, strings, heaps, and a few other things.
> The tingea library comes with some testing programs.


https://github.com/micans/cimfomfa/archive/refs/tags/21-341.tar.gz was released
dec 10, 2021.


> > > The upcoming mcl tarball will need cimfomfa to build, a git snapshot
> > > prerelease of upcoming mcl is available from
> > > http://micans.org/phloobaz/mcl-21-100.tar.gz .  (We ship the mcl
> > > package.)
> 
> BTW, the mcl code is maintained at public repository
> https://github.com/micans/mcl .


> > > It would be cool if the Debian Med Packaging Team at
> > > https://salsa.debian.org/med-team could take up maintainership of this
> > > library.
> 

> Or maybe zoem (debian-science), mcl (debian-med) and cimfomfa could all be
> maintained by https://salsa.debian.org/math-team .  Since these packages will
> now share dependencies, maybe that would work best.  Or would it be better to
> move zoem from debian-science to debian-med?  Andreas Tille, Shayan Doust:
> any opinions?

I'll very likely maintain cimfomfa at https://salsa.debian.org/science-team .

cimfomfa 21-341.tar.gz lacks a configure.ac, and therefore is not trivial to
build; I've just reported that upstream.

A preliminary http://mdcc.cx/tmp/cimfomfa/cimfomfa_21-341-1.dsc is available.

Bye,

Joost

Bug#1002596: zoem: new upstream

[Joost van Baal-Ilić]

Package: zoem
Severity: normal


https://github.com/micans/zoem/releases/tag/21-341

released dec 10, 2021.

See also #993009
ITP: cimfomfa -- tingea library for mcl and zoem

Bug#999837: ITP: merecat -- simple web server with only basic features

[Joost van Baal-Ilić]

Hi Thaddeus,

On Wed, Nov 17, 2021 at 09:31:25PM +, Thaddeus H. Black wrote:
> On Wed, Nov 17, 2021 at 01:54:20PM +0100, Joost van Baal-Ilić wrote:
> > Package: wnpp
> > Owner: Joost van Baal-Ilić 
> > Severity: wishlist
> > 
> > * Package name: merecat
> >   Upstream Author : Joachim Wiberg 
> > * URL : https://troglobit.com/projects/merecat/
> > * License : BSD 2-clause
> >   Programming Lang: C
> >   Description : simple web server with only basic features
> > 
> >  Merecat is a simple web server based on Jef Poskanzer's thttpd.
> >  It supports all basic features required for most use-cases. The
> >  most prominent features are probably HTTPS, using OpenSSL, PHP,
> >  multiple servers with HTTP redirect support, redirect from HTTP
> >  to HTTPS, virtual hosts, and the URL-traffic-based throttling.
> >  .
> >  Its small footprint makes it is suitable for small and embedded
> >  systems.
> > 
> > I plan to migrate my personal web servers to merecat, and maintain
> > the software using git at https://salsa.debian.org/debian .  Upstream
> > also publishes a debian/ directory btw, at their git repo
> > at https://github.com/troglobit/merecat ; and I published a first
> > shot at packaging at http://mdcc.cx/tmp/merecat/ .
> 
> If I ask you how merecat improves upon simple web servers already in
> Debian, I do not mean to challenge you, nor to discourage you.  I am
> merely curious.
> 
> If you don't mind telling me, how *does* merecat improve upon simple
> web servers already in Debian?

I've found 5 + 2 + 1 of them:

 averell : written in erlang
 droopy  : with upload functionality
 filetea : filesharing functionality
 gatling : has more features
 thin: written in Ruby

Maybe webfs and civetweb are comparable to merecat, I'll look closer.

And then there's publicfile-installer which I plan to Orphan soonish.

I believe it boils down to: merecat is written in the widely spoken C
language, is based upon the widely tested thttpd code, and has a very minimal
feature set (and therefore possibly fewer bugs).  Anyway, I'll try to improve
the merecat description with these and more findings, thanks for your
interest!

Bye,

Joost

Bug#999837: ITP: merecat -- simple web server with only basic features

[Joost van Baal-Ilić]

Package: wnpp
Owner: Joost van Baal-Ilić 
Severity: wishlist

* Package name: merecat
  Upstream Author : Joachim Wiberg 
* URL : https://troglobit.com/projects/merecat/
* License : BSD 2-clause
  Programming Lang: C
  Description : simple web server with only basic features

 Merecat is a simple web server based on Jef Poskanzer's thttpd.
 It supports all basic features required for most use-cases. The
 most prominent features are probably HTTPS, using OpenSSL, PHP,
 multiple servers with HTTP redirect support, redirect from HTTP
 to HTTPS, virtual hosts, and the URL-traffic-based throttling.
 .
 Its small footprint makes it is suitable for small and embedded
 systems.

I plan to migrate my personal web servers to merecat, and maintain
the software using git at https://salsa.debian.org/debian .  Upstream
also publishes a debian/ directory btw, at their git repo
at https://github.com/troglobit/merecat ; and I published a first
shot at packaging at http://mdcc.cx/tmp/merecat/ .

Bye,

Joost

Bug#993009: RFP: cimfomfa -- tingea library for mcl

[Joost van Baal-Ilić]

retitle 993009 ITP: cimfomfa -- tingea library for mcl and zoem
thanks


 * Package name: cimfomfa
   Upstream Author : Stijn van Dongen 
   URL : https://github.com/micans/cimfomfa
 * License : GPL-3+
   Programming Lang: C
   Description : C utility library libtingea for MCL and zoem

Long description:

cimfomfa is used by both MCL, a cluster algorithm for graphs, and zoem,
a macro/DSL language. It supplies abstractions for memory management, I/O,
associative arrays, strings, heaps, and a few other things.
The tingea library comes with some testing programs.

On Mon, Nov 01, 2021 at 08:01:16PM +0100, Joost van Baal-Ilić wrote:
> On Mon, Sep 06, 2021 at 02:05:33PM +0200, Joost van Baal-Ilić wrote:
> > On Thu, Aug 26, 2021 at 11:26:55AM +0200, Joost van Baal-Ilić wrote:
> > > Upstream published a git snapshot prerelease of cimfomfa, at
> > > http://micans.org/phloobaz/cimfomfa-21-101.tar.gz .  The upcoming mcl
> > > tarball will need cimfomfa to build, a git snapshot prerelease of
> > > upcoming mcl is available from
> > > http://micans.org/phloobaz/mcl-21-100.tar.gz .  (We ship the mcl
> > > package.)
> 
> BTW, the mcl code is maintained at public repository
> https://github.com/micans/mcl .

And btw, the zoem code is maintained at the not yet public repository
at https://github.com/micans/zoem/ .

> > > It would be cool if the Debian Med Packaging Team at
> > > https://salsa.debian.org/med-team could take up maintainership of this
> > > library.
> 
> 
> Or maybe zoem (debian-science), mcl (debian-med) and cimfomfa could all be
> maintained by https://salsa.debian.org/math-team .  Since these packages will
> now share dependencies, maybe that would work best.  Or would it be better to
> move zoem from debian-science to debian-med?  Andreas Tille, Shayan Doust: any
> opinions?

Bye,

Joost

Bug#998160: adjusting webmaster-team/cron / was: Re: Bug#998160: Stop using /usr/share/doc/debian

[Joost van Baal-Ilić]

Hi Osamu e.a.,

On Wed, Nov 03, 2021 at 05:02:21PM +0900, Osamu Aoki wrote:
> On Mon, 2021-11-01 at 14:31 +0100, Joost van Baal-Ilić wrote:
> > 
> > I was brave enough to again have a look at cron/parts/7doc ...  :-/
> > 
> > Note to self: once debian-faq ships new translations (pt and ko) we
> > might have to adjust 7doc again.
> > 
> > Osamu: or is there another script in webmaster-team/cron I should
> > have a look at?
> > 
> > Osamu: stop using FTP service: you mean the script parts/1ftpfiles which 
> > seems
> > to try to access ftp://ftp.de.debian.org/debian/pool/main ?  (I just found 
> > out
> > we still offer ftp access... Wow...) But uhm, is that script still being run
> > from cron?  If so I might be able to fix that, one of these days.
> 
> I have written code to use http instead of ftp locally.  It needs to be 
> tested.

Excellent, thanks!

> Give me some time to test to avoid regressions.

Sure!

I found around line 475 of cron/parts/7doc, there is

 ln -sf debian-faq.zh-cn.pdf $webdocdir/manuals/debian-faq/debian-faq.zh_CN.pdf
 ln -sf debian-faq.zh-cn.txt $webdocdir/manuals/debian-faq/debian-faq.zh_CN.txt

.  I didn't see any other special casing of specific languages in debian-faq,
so I think we don't need to do any adjustments for new translations (pt and
ko).

I'll try to set up a test-instance myself here.  (I have only 19 GB free disk
space available here now; hope that'll be enough...)

Bye,

Joost

PS/note to self: https://www.debian.org/doc/manuals/debian-faq/ honors browser
language settings.  Page https://www.debian.org/doc/user-manuals#faq has an
explicit listing of available languages, might need adjustment.  Translated
content available directly via e.g.
https://www.debian.org/doc/manuals/debian-faq/index.de.html and
https://www.debian.org/doc/manuals/debian-faq/debian-faq.fr.pdf .

Bug#798013: #798013: doc-debian: useless "Suggests: postscript-viewer, www-browser"

[Joost van Baal-Ilić]

tags #798013 +pending
thanks

Fixed in git at [master 8419b97].  Thanks Jakub Wilk!

Bug#843449: #843449: doc-debian: Mistake in doc-base control file for debian-social-contract

[Joost van Baal-Ilić]

tags #843449 +pending
thanks

Fixed in git at [master 1a4d1e3].  Thanks Legimet!

Bug#273323: doc-debian: please ship typesettable version of social contract and dfsg documents

[Joost van Baal-Ilić]

Hi,

Thanks for participating in this discussion.  I guess the way forward is to
ship a /usr/share/doc/doc-debian/README file with instructions on the various
ways as posted here on how to get typesettable versions.  (Or anybody has
better ideas?)

Anyway, I'll try to get to that.  (As always: patches welcome :)

Bye,

Joost

PS: and on my todo list is shipping the Debian flyers as a Debian package, in
order to improve discoverability of
https://debian.pages.debian.net/debian-flyers/ and
https://salsa.debian.org/debian/debian-flyers .

Bug#993009: RFP: cimfomfa -- tingea library for mcl

[Joost van Baal-Ilić]

Hi,

Some updates.

On Mon, Sep 06, 2021 at 02:05:33PM +0200, Joost van Baal-Ilić wrote:
> On Thu, Aug 26, 2021 at 11:26:55AM +0200, Joost van Baal-Ilić wrote:
> > Package: wnpp
> > Severity: wishlist
> > 
> > * Package name: cimfomfa
> >   Upstream Author : Stijn van Dongen 

URL : https://github.com/micans/cimfomfa

> > * License : GPL-3+
> >   Programming Lang: C

Description : C utility library libtingea for MCL and zoem

Long description:

cimfomfa is used by both MCL, a cluster algorithm for graphs, and zoem,
a macro/DSL language. It supplies abstractions for memory management, I/O,
associative arrays, strings, heaps, and a few other things.
The tingea library comes with some testing programs.

> > Upstream published a git snapshot prerelease of cimfomfa, at
> > http://micans.org/phloobaz/cimfomfa-21-101.tar.gz .  The upcoming mcl 
> > tarball
> > will need cimfomfa to build, a git snapshot prerelease of upcoming mcl is
> > available from http://micans.org/phloobaz/mcl-21-100.tar.gz .  (We ship the
> > mcl package.)

BTW, the mcl code is maintained at public repository
https://github.com/micans/mcl .

> > It would be cool if the Debian Med Packaging Team at
> > https://salsa.debian.org/med-team could take up maintainership of this
> > library.


Or maybe zoem (debian-science), mcl (debian-med) and cimfomfa could all be
maintained by https://salsa.debian.org/math-team .  Since these packages will
now share dependencies, maybe that would work best.  Or would it be better to
move zoem from debian-science to debian-med?  Andreas Tille, Shayan Doust: any
opinions?

Bye,

Joost

Bug#998244: lists.debian.org: request for debian-math mailing list (was: Re: Debian Math Team)

[Joost van Baal-Ilić]

Hi,

I am interested in the creation of this list.  The Debian Math Team is being
created now; https://salsa.debian.org/math-team was created last week, it
currently has 11 members.  The need for this group (and list) has been
discussed in the thread starting at
https://lists.debian.org/msgid-search/87wnlvn3fg@piedmont.edu ; people
expressed interest there.

Thanks, Bye,

Joost

Bug#998160: adjusting webmaster-team/cron / was: Re: Bug#998160: Stop using /usr/share/doc/debian

[Joost van Baal-Ilić]

Hi again,

[Dropping debian-doc; I believe the list gets a copy via 998160@bugs.d.o
anyway.]

On Mon, Nov 01, 2021 at 07:48:23PM +0900, Osamu Aoki wrote:
> On Sun, 2021-10-31 at 11:03 +0100, Joost van Baal-Ilić wrote:
> > On Sun, Oct 31, 2021 at 03:08:42PM +0900, Osamu Aoki wrote:
> > > Source: debian-faq
> > > Version: 10.1
> > > Severity: minor
> > > 
> > > When DDP was started, those people had big plan.  But in reality, scope
> > > has been scaled back.
> > > 
> > > Since there is no big pile of Debian document and most (Policy,
> > > DevRef,...) now uses their own doc directory, I think it's about time
> > > for FAQ to be in line with others.
> > > 
> > > This should help people to find this document easily since doc-base
> > > support is scant and rarely used by newbies.
> > 
> > I agree.
> > 
> > But how about the doc-debian package? That one now installs :
> > 
> > /usr/share/doc/debian/bug-log-access.txt
> > /usr/share/doc/debian/bug-*.txt.gz
> > /usr/share/doc/debian/bug-reporting.txt.gz
> > /usr/share/doc/debian/constitution.*txt.gz
> > /usr/share/doc/debian/debian-manifesto.gz
> > /usr/share/doc/debian/mailing-lists.txt.gz
> > /usr/share/doc/debian/social-contract.*txt.gz
> > /usr/share/doc/debian/source-unpack.txt
> > 
> > If those documents get moved, we can get rid of /usr/share/doc/debian/ .
> > 
> > However, I myself am not quite sure if moving these documents is the right
> > thing to do.  Opinions?
> 
> Good catch.  True.
> 
> I think it is good idea but its worth thinking.
> 
> If we do this, we need to update debwww cron script.
> 
> Before then, we should stop using FTP servive in cron script.
> 
> >  url = g...@salsa.debian.org:webmaster-team/cron.git

larjona just granted me access, thanks for that!

I was brave enough to again have a look at cron/parts/7doc ...  :-/

Note to self: once debian-faq ships new translations (pt and ko) we
might have to adjust 7doc again.

Osamu: or is there another script in webmaster-team/cron I should
have a look at?

Osamu: stop using FTP service: you mean the script parts/1ftpfiles which seems
to try to access ftp://ftp.de.debian.org/debian/pool/main ?  (I just found out
we still offer ftp access... Wow...) But uhm, is that script still being run
from cron?  If so I might be able to fix that, one of these days.

Thanks, Bye,

Joost

Bug#998160: Stop using /usr/share/doc/debian

[Joost van Baal-Ilić]

On Sun, Oct 31, 2021 at 03:08:42PM +0900, Osamu Aoki wrote:
> Source: debian-faq
> Version: 10.1
> Severity: minor
> 
> When DDP was started, those people had big plan.  But in reality, scope
> has been scaled back.
> 
> Since there is no big pile of Debian document and most (Policy,
> DevRef,...) now uses their own doc directory, I think it's about time
> for FAQ to be in line with others.
> 
> This should help people to find this document easily since doc-base
> support is scant and rarely used by newbies.

I agree.

But how about the doc-debian package? That one now installs :

/usr/share/doc/debian/bug-log-access.txt
/usr/share/doc/debian/bug-*.txt.gz
/usr/share/doc/debian/bug-reporting.txt.gz
/usr/share/doc/debian/constitution.*txt.gz
/usr/share/doc/debian/debian-manifesto.gz
/usr/share/doc/debian/mailing-lists.txt.gz
/usr/share/doc/debian/social-contract.*txt.gz
/usr/share/doc/debian/source-unpack.txt

If those documents get moved, we can get rid of /usr/share/doc/debian/ .

However, I myself am not quite sure if moving these documents is the right
thing to do.  Opinions?

Bye,

Joost

Bug#754740: unnecessarily gender-specific language

[Joost van Baal-Ilić]

Hi Osamu,

On Sun, Oct 31, 2021 at 02:57:26PM +0900, Osamu Aoki wrote:
> 
> In my recent merge request, I addressed issues raised here.
> 
>   https://salsa.debian.org/ddp-team/debian-faq/-/merge_requests/6
> 
> Please merge and close this bug report.
> 
> (If no objection or no comment from the current maintainer, I will merge... I 
> think I
> have write access.)


https://salsa.debian.org/ddp-team/debian-faq/-/merge_requests/6/diffs?commit_id=8a9c82f23b5c10c85c88b5e161a0cc82c77fd232
looks good to me.

However,
https://salsa.debian.org/ddp-team/debian-faq/-/merge_requests/6/diffs?commit_id=23bfbd07838c6d7ac1f5ea70165b719a3b04da34
, could better use the patch as listed at Bug#995435 : we _do_ have a
(unofficial) forum.

Thanks, Bye,

Joost

Bug#998145: carmetal: new upstream, new homepage (was: Re: unmaintained potential important CaRMetal (GeoGebra alike))

[Joost van Baal-Ilić]

Package: carmetal

Hi,

On Sat, Oct 30, 2021 at 04:40:14PM +0200, Mattia Rizzolo wrote:
> On Wed, Oct 27, 2021 at 10:15:15AM +0200, Ben Tris wrote:
> > This package can probably be updated to version 4.3 from 2019.

Indeed, version 4.3 was released sept 11, 2020 it says at
https://carmetal.en.uptodown.com/windows .  And the links in debian/copyright
are no longer valid; upstream moved to another site.

HTH, Bye,

Joost

Bug#924131: #924131: debian-history: host the scanned printout of the Debian creation announcement in Debian server

[Joost van Baal-Ilić]

tags 924131 +patch
thanks


Hi,

On Thu, Oct 28, 2021 at 07:38:10AM +0200, Joost van Baal-Ilić wrote:
> 
> This bug is now partially fixed:
> 
> I've just uploaded a copy of the 1993 announcement news posting to
> https://wiki.debian.org/DebianHistory?action=AttachFile=get=Debian-announcement-1993.txt
> ; it's linked to from https://wiki.debian.org/DebianHistory .


And uploaded the picture of the printout to
https://wiki.debian.org/DebianHistory?action=AttachFile=get=Debian-announcement-1993-pic-by-Ian_Murdock.png
.  Now maybe



The Debian Project was officially founded by Ian Murdock on https://groups.google.com/forum/message/raw?msg=comp.os.linux.development/Md3Modzg5TU/xty88y5OLaMJ;>August
16th, 1993.  (There is also a https://www.flickr.com/photos/iamurdock/20006308374/;>scanned
printout of that announcement.) At that time, the whole concept of a


could get changed to



The Debian Project was officially founded by Ian Murdock on https://wiki.debian.org/DebianHistory?action=AttachFile=get=Debian-announcement-1993.txt;>August
16th, 1993.  (There is also a https://wiki.debian.org/DebianHistory?action=AttachFile=get=Debian-announcement-1993-pic-by-Ian_Murdock.png;>scanned
printout of that announcement.) At that time, the whole concept of a


.

(And that would also fix the broken groups.google.com link; it gives 'The page 
isn’t
redirecting properly' here now.)

Bye,

Joost

Bug#924131: #924131: debian-history: host the scanned printout of the Debian creation announcement in Debian server

[Joost van Baal-Ilić]

Hi,

This bug is now partially fixed:

I've just uploaded a copy of the 1993 announcement news posting to
https://wiki.debian.org/DebianHistory?action=AttachFile=get=Debian-announcement-1993.txt
; it's linked to from https://wiki.debian.org/DebianHistory .  I have not yet
tried to get a real picture download from flickr.com.  And btw: the picture
does not show to complete posting.

I've used https://debiananwenderhandbuch.de/wasistdebiangnu.html,
https://groups.google.com/g/comp.os.linux.development/c/Md3Modzg5TU/m/xty88y5OLaMJ
and https://www.flickr.com/photos/iamurdock/20006308374/in/photostream/ for the
text .

HTH, Bye,

Joost

Bug#996015: debian-faq: remove obsolete usenet links / Re: Debian FAQ Usenet newsgroup

[Joost van Baal-Ilić]

Package: debian-faq
Severity: normal

Hi Sebul,

On Sun, Oct 10, 2021 at 05:07:34AM +0900, sebul / https://sebuls.blogspot.kr
wrote:
> Hello.
> https://www.debian.org/doc/manuals/debian-faq/support.en.html#s12.2.5
> 12.2.5. Usenet newsgroups
> say Linux Online and LinuxJournal
> But these links say page not found.
> 
> Where is usenet for debian?

These links are obsolete and should be removed.  I don't think there's
a specific usenet group dedicated to Debian; and I'm not quite sure
we should refer to one if such a group would exist.

Thanks for bringing this up.

(Now reporting this in our Bugtracking System; Patches welcome! :-)

Bye,

Joost

Bug#995435: debian-faq: remove links to obsolete user help forums (was: Re: Is debianHELP correct ?)

[Joost van Baal-Ilić]

Package: debian-faq
Severity: normal
Tags: +patch

Reporting this as a bug so it won't get lost.  Sebul and Justin B Rye: thanks a
lot!

Bye,

Joost



On Fri, Oct 01, 2021 at 09:38:41AM +0100, Justin B Rye wrote:
> Sebul wrote:
> > Please see
> > https://www.debian.org/doc/manuals/debian-faq/support.en.html#s12.2.2
> > At 12.2.2. Webforms
> > link to debianHELP is strange.
> 
> Apparently its decay has reached the stage of expired SSL
> certificates, so it's about time debian-faq/support.dbk was trimmed
> back to only point at forums.debian.net.
> 
>Web forum
>
> http://forums.debian.net/;>Debian User Forums 
> provides web forums on which you can submit questions about Debian
> and have them answered by other users.  (It is not officially part
> of the Debian project.)
>
>   
> 
> That would be a minimal fix, but I'd also want to reorganise it now.
> DebianHELP was entirely "third-party", but forums.debian.net is not
> ("https://bits.debian.org/2021/08/debianuserforums.html;) - the
> debian-user mailinglist isn't "official" in that it guarantees an
> authoritative answer from the DPL, or supersedes the NO WARRANTY
> warnings, it's just that it's the "preferred" support channel.
> Perhaps it needs to say something like:
> 
>Web forum
>
> Besides the official mailing lists, there are also web forums at
> http://forums.debian.net/;>Debian User Forums
> on which you can submit questions about Debian and have them
> answered by other users.
>
>   
> -- 
> JBR   with qualifications in linguistics, experience as a Debian
>   sysadmin, and probably no clue about this particular package
> 

Bug#424620: reopen / Re: Bug#424620: marked as done (mailman: error.log not re-opened on log rotation)

[Joost van Baal-Ilić]

reopen 424620
thanks

was closed by spammer

Bug#993009: RFP: cimfomfa -- tingea library for mcl

[Joost van Baal-Ilić]

On Thu, Aug 26, 2021 at 11:26:55AM +0200, Joost van Baal-Ilić wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: cimfomfa
>   Upstream Author : Stijn van Dongen 
> * URL : none yet
> * License : GPL-3+
>   Programming Lang: C
>   Description : tingea library for mcl
> 
> Upstream published a git snapshot prerelease of cimfomfa, at
> http://micans.org/phloobaz/cimfomfa-21-101.tar.gz .  The upcoming mcl tarball
> will need cimfomfa to build, a git snapshot prerelease of upcoming mcl is
> available from http://micans.org/phloobaz/mcl-21-100.tar.gz .  (We ship the
> mcl package.)
> 
> cimfomfa builds libtingea.a ; the code is not yet documented.
> 
> (The code is maintained using (for now private (!)) repositories at
> https://github.com/micans/mcl and https://github.com/micans/cimfomfa .)
> 
> It would be cool if the Debian Med Packaging Team at
> https://salsa.debian.org/med-team could take up maintainership of this
> library.

News from upstream: upcoming zoem release will build-depend upon
libtingea-dev.

The zoem package is maintained by Debian Science Team; therefore CC-ing.

Bye,

Joost

Bug#993009: RFP: cimfomfa -- tingea library for mcl

[Joost van Baal-Ilić]

Package: wnpp
Severity: wishlist

* Package name: cimfomfa
  Upstream Author : Stijn van Dongen 
* URL : none yet
* License : GPL-3+
  Programming Lang: C
  Description : tingea library for mcl

Upstream published a git snapshot prerelease of cimfomfa, at
http://micans.org/phloobaz/cimfomfa-21-101.tar.gz .  The upcoming mcl tarball
will need cimfomfa to build, a git snapshot prerelease of upcoming mcl is
available from http://micans.org/phloobaz/mcl-21-100.tar.gz .  (We ship the
mcl package.)

cimfomfa builds libtingea.a ; the code is not yet documented.

(The code is maintained using (for now private (!)) repositories at
https://github.com/micans/mcl and https://github.com/micans/cimfomfa .)

It would be cool if the Debian Med Packaging Team at
https://salsa.debian.org/med-team could take up maintainership of this
library.

HTH, Bye,

Joost



signature.asc
Description: PGP signature

Bug#978907: #978907: timbl: ftbfs with autoconf 2.70

[Joost van Baal-Ilić]

tag 978907 +pending
thanks

thanks to Ko van der Sloot: fixed upstream in
https://github.com/LanguageMachines/timbl/commit/63740b

Bye,

Joost

Bug#965169: #965169 ITA: jigl

[Joost van Baal-Ilić]

retitle 965169 ITA: jigl -- Generates a static html photo gallery from one or 
more directories of images
owner 965169 joos...@debian.org
thanks

I intend to adopt jigl.  I use it myself, and plan to keep on using it.  I
created a git repo @ g...@salsa.debian.org:debian/jigl.git , plan to start
filling it with some old .dsc's and work on a new upload from there.

Bye,

Joost

Bug#991781: RFR: fail2ban can't send e-mail using mail from bsd-mailx

[Joost van Baal-Ilić]

Hi,

I've fixed a typo in the patch: s/provide/provider/ , patch below
adjusted.

Also, it's not clear to me wether one should do e.g.

 sudo update-alternatives --config mail

and select mail.mailutils, or would it be easier/better to edit files in
/etc/fail2ban/action.d/ ?  But indeed, otoh, maybe we should just leave it as
is.

HTH, Bye,

Joost


On Wed, Aug 04, 2021 at 09:55:54PM +0200, Paul Gevers wrote:
> Control: severity -1 normal
> Control: notforwarded -1
> Control: tags -1 - upstream
> Control: tags -1 patch pending
> 
> Hi,
> 
> I have the attached patch ready to push. I'm wondering if we need more
> detailed instructions.
> 
> Paul

> From 072744ceed8cac5cef19c92d9e506bebeb26b482 Mon Sep 17 00:00:00 2001
> From: Paul Gevers 
> Date: Wed, 4 Aug 2021 09:59:34 +0200
> Subject: [PATCH] issues.dbk: fail2ban and mail from bsd-mailx don't work
>  together
> 
> Closes: #991781
> ---
>  en/issues.dbk | 23 +++
>  1 file changed, 23 insertions(+)
> 

diff --git a/en/issues.dbk b/en/issues.dbk
index a01b2967..4eab01ef 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -493,6 +493,29 @@ data = 
${lookup{$local_part}lsearch{/some/path/$domain_data/aliases}}
 
   
 
+  
+fail2ban can't send e-mail using mail from bsd-mailx
+
+  The fail2ban package can
+  be configured to send out e-mail notifications. It does that
+  using mail, which is provided by multiple
+  packages in Debian. A security update (needed on systems that
+  use mail from mailutils) just before the release
+  of bullseye broke this functionality for systems that have
+  mail provided by bsd-mailx. Users of
+  fail2ban in combination with
+  bsd-mailx that wish
+  fail2ban to send out e-mail, should
+  either switch to a different provider for mail
+  or manually unapply https://github.com/fail2ban/fail2ban/commit/410a6ce5c80dd981c22752da034f2529b5eee844;>the
+  upstream commit (all files are in
+  /etc/fail2ban/action.d/).
+
+  
+
   
   Things to do post upgrade before rebooting
   

Bug#991688: mention improved/added man page translations

[Joost van Baal-Ilić]

Hi,

On Fri, Jul 30, 2021 at 09:59:00PM +0200, Paul Gevers wrote:
> On 30-07-2021 18:43, Helge Kreutzmann wrote:
> > If this is the rule now, fine.
> 
> It is not. We have multiple items mentioning backports.

Indeed, I was mistaken, excuse me.

So, Helge suggested:

 During the lifetime of bullseye backports of further improvements /
 translations will be provided within the backports archive, possibly also new
 languages.

I suggest:

 During the lifetime of the bullseye release, backports of further translation
 improvements will be provided via the backports archive.

Justin: is that proper English?

If so, the complete text to include in the introductory section for 2.2 "What's
new in the distribution?"...  would be (Justin B Rye, Helge Kreutzmann, Joost
van Baal-Ilić):

 The manual pages for several projects such as systemd, util-linux,
 OpenSSH, and Mutt in a number of languages, including French, Spanish,
 and Macedonian, have been substantially improved. To benefit from
 this, please install manpages-xx (where xx is the code for your
 preferred natural language).

 During the lifetime of the bullseye release, backports of further
 translation improvements will be provided via the backports archive.

.

Bye,

Joost

Bug#991688: mention improved/added man page translations

[Joost van Baal-Ilić]

Hi again Helge,

On Fri, Jul 30, 2021 at 02:39:02PM +0200, Helge Kreutzmann wrote:
> On Fri, Jul 30, 2021 at 12:27:25PM +0100, Justin B Rye wrote:
> > Helge Kreutzmann wrote:

> > 
> > > Please install manpages-nn (where nn is your language code) to 
> > > benefit from the improvements. During the lifetime of bullseye backports
> > > of further improvements / translations will be provided within the 
> > > backports archive, possibly also new languages.

> > Reapplying some of those suggested changes:
> > 
> >   The manual pages for several projects such as systemd, util-linux,
> >   OpenSSH, and Mutt in a number of languages, including French, Spanish,
> >   and Macedonian, have been substantially improved. To benefit from
> >   this, please install manpages-xx (where xx is the code for your
> >   preferred natural language).
> > 
> > (I'm avoiding calling openssh a package.)
> > 
> > This version's short enough that we might consider including it in the
> > introductory section for 2.2 "What's new in the distribution?"...
> 
> I'm fine with the update, even though it misses the fact that I did
> (for buster) and will be (for bullseye) provide updates as translators
> translate more pages and paragraphs.

You mean via backports?  Yes, I suggested dropping that: I'm not quite sure we
should suggest that in the release notes since it's not strictly part of the
release.  Or maybe something could get added somewhere else?

Bye,

Joost

Bug#991688: mention improved/added man page translations

[Joost van Baal-Ilić]

Hi,

Helge: thanks!

On Fri, Jul 30, 2021 at 12:17:15PM +0200, Helge Kreutzmann wrote:
> Package: release-notes
> Severity: normal
> Tags: patch
> 
> The man pages for nonenglish speaking users have been substantially
> improved and extended. Please add a text along the following lines:
> 
> The documentation (man pages) for several projects like systemd, util
> linux, Openssh and mutt and several languages (new or extendd), e.g. 
> french, spanish, makedonain have been substantially extended and/or 
> added. Please install manpages-nn (where nn is your language code) to 
> benefit from the improvements. During the lifetime of bullseye backports
> of further improvements / translations will be provided within the 
> backports archive, possibly also new languages.

I'd propose:

The manual pages for several packages like systemd, util-linux, openssh and
mutt in several languages like French, Spanish and Macedonian have been
substantially improved. Please install manpages-nn (where nn is your preferred
natural language code) to enjoy this.

HTH, Bye,

Joost

Bug#986656: ITP: runit-services -- a collection of services for runit

[Joost van Baal-Ilić]

Hi Lorenzo e.a.,

Maybe https://github.com/void-linux/void-runit can be of some help too,
making it easier to use runit on Debian.

HTH, Bye,

Joost