Bug#1085466: src:libopaque: fails to migrate to testing for too long

[Joost van Baal-Ilić]

On Sat, Oct 19, 2024 at 08:55:21PM +0200, Joost van Baal-Ilić wrote:
> On Sat, Oct 19, 2024 at 08:01:01PM +0200, Paul Gevers wrote:
> > Migration status for libopaque (0.99.3-1 to 0.99.7-2): BLOCKED
[...]
> > Issues preventing migration:
> > ∙ ∙ missing build on ppc64el

> 
> суб 19 20:17 <@joostvb> @ #klutshnik:
> >> stf: opaque_CreateRegistrationResponseSegmentation fault
> >> @ 
> >> https://buildd.debian.org/status/fetch.php?pkg=libopaque&arch=ppc64el&ver=0.99.7-2&stamp=1726766202&raw=0
> >> it's that weird ppc64el arch
> >> bugs.debian.org/1085466
> >> could be that the fix is not ours to make, but some problem elsewhere...
> 
> Stef: any thoughts?

суб 19 20:57 <@stf> @ #klutshnik IRCnet:
>> huh, it crashes on both ppc64 and ppc64el so it's not an endiannness problem
>> https://buildd.debian.org/status/package.php?p=libopaque

Both Stefan and me are on it.  It might take some time.

Thanks again, Bye,

Joost




> On Sat, Oct 19, 2024 at 08:01:01PM +0200, Paul Gevers wrote:
> > Source: libopaque
> > Version: 0.99.3-1
> > Severity: serious
> > Control: close -1 0.99.7-2
> > Tags: sid trixie
> > User: release.debian@packages.debian.org
> > Usertags: out-of-sync
> > 
> > Dear maintainer(s),
> > 
> > The Release Team considers packages that are out-of-sync between testing and
> > unstable for more than 30 days as having a Release Critical bug in testing
> > [1]. Your package src:libopaque has been trying to migrate for 31 days [2],
> > hence this bug report. The current output of the migration software for this
> > package is copied to the bottom of this report and should list the reason
> > why the package is blocked.
> > 
> > If a package is out of sync between unstable and testing for a longer
> > period, this usually means that bugs in the package in testing cannot be
> > fixed via unstable. Additionally, blocked packages can have impact on other
> > packages, which makes preparing for the release more difficult. Finally, it
> > often exposes issues with the package and/or its (reverse-)dependencies. We
> > expect maintainers to fix issues that hamper the migration of their package
> > in a timely manner.
> > 
> > This bug will trigger auto-removal when appropriate. As with all new bugs,
> > there will be at least 30 days before the package is auto-removed.
> > 
> > This bug submission immediately closes the bug with the version in unstable,
> > so if that version or a later version migrates, this bug will no longer
> > affect testing. This bug is also tagged to only affect sid and trixie, so it
> > doesn't affect (old-)stable.
> > 
> > If you believe your package is unable to migrate to testing due to issues
> > beyond your control, don't hesitate to contact the Release Team.
> > 
> > This bug report has been automatically generated and has only been sent
> > manually. If you have any comments with regards to the content or the
> > process, please reach out to me.
> > 
> > Paul
> > 
> > [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
> > [2] https://qa.debian.org/excuses.php?package=libopaque
> > 
> > Current text from [2]:
> > Migration status for libopaque (0.99.3-1 to 0.99.7-2): BLOCKED: Maybe
> > temporary, maybe blocked but Britney is missing information (check below)
> > Issues preventing migration:
> > ∙ ∙ missing build on ppc64el
> > ∙ ∙ arch:ppc64el not built yet, autopkgtest delayed there
> > Additional info:
> > ∙ ∙ Piuparts tested OK -
> > https://piuparts.debian.org/sid/source/libo/libopaque.html
> > ∙ ∙ Reproducible on amd64 - info ♻ ∙ ∙ Reproducible on arm64 - info ♻ ∙ ∙
> > Reproducible on armhf - info ♻ ∙ ∙ Reproducible on i386 - info ♻ ∙ ∙ 29 days
> > old (needed 10 days)
> > 

Bug#1085466: src:libopaque: fails to migrate to testing for too long

[Joost van Baal-Ilić]

Hi Paul,

Thanks, I'm in contact with upstream about this.

Hi Stef,

суб 19 20:17 <@joostvb> @ #klutshnik:
>> stf: opaque_CreateRegistrationResponseSegmentation fault
>> @ 
>> https://buildd.debian.org/status/fetch.php?pkg=libopaque&arch=ppc64el&ver=0.99.7-2&stamp=1726766202&raw=0
>> it's that weird ppc64el arch
>> bugs.debian.org/1085466
>> could be that the fix is not ours to make, but some problem elsewhere...

Stef: any thoughts?

Bye,

Joost

On Sat, Oct 19, 2024 at 08:01:01PM +0200, Paul Gevers wrote:
> Source: libopaque
> Version: 0.99.3-1
> Severity: serious
> Control: close -1 0.99.7-2
> Tags: sid trixie
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
> 
> Dear maintainer(s),
> 
> The Release Team considers packages that are out-of-sync between testing and
> unstable for more than 30 days as having a Release Critical bug in testing
> [1]. Your package src:libopaque has been trying to migrate for 31 days [2],
> hence this bug report. The current output of the migration software for this
> package is copied to the bottom of this report and should list the reason
> why the package is blocked.
> 
> If a package is out of sync between unstable and testing for a longer
> period, this usually means that bugs in the package in testing cannot be
> fixed via unstable. Additionally, blocked packages can have impact on other
> packages, which makes preparing for the release more difficult. Finally, it
> often exposes issues with the package and/or its (reverse-)dependencies. We
> expect maintainers to fix issues that hamper the migration of their package
> in a timely manner.
> 
> This bug will trigger auto-removal when appropriate. As with all new bugs,
> there will be at least 30 days before the package is auto-removed.
> 
> This bug submission immediately closes the bug with the version in unstable,
> so if that version or a later version migrates, this bug will no longer
> affect testing. This bug is also tagged to only affect sid and trixie, so it
> doesn't affect (old-)stable.
> 
> If you believe your package is unable to migrate to testing due to issues
> beyond your control, don't hesitate to contact the Release Team.
> 
> This bug report has been automatically generated and has only been sent
> manually. If you have any comments with regards to the content or the
> process, please reach out to me.
> 
> Paul
> 
> [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
> [2] https://qa.debian.org/excuses.php?package=libopaque
> 
> Current text from [2]:
> Migration status for libopaque (0.99.3-1 to 0.99.7-2): BLOCKED: Maybe
> temporary, maybe blocked but Britney is missing information (check below)
> Issues preventing migration:
> ∙ ∙ missing build on ppc64el
> ∙ ∙ arch:ppc64el not built yet, autopkgtest delayed there
> Additional info:
> ∙ ∙ Piuparts tested OK -
> https://piuparts.debian.org/sid/source/libo/libopaque.html
> ∙ ∙ Reproducible on amd64 - info ♻ ∙ ∙ Reproducible on arm64 - info ♻ ∙ ∙
> Reproducible on armhf - info ♻ ∙ ∙ Reproducible on i386 - info ♻ ∙ ∙ 29 days
> old (needed 10 days)
> 

Bug#1076648: aephea: causes groff warning "cannot select font 'C'" when using \verbatim{ } or \tt{ }

[Joost van Baal-Ilić]

Hi again Stijn,

*ping* ?

BTW, if you prepare a patch, or a .tar.gz, I am happy to do some testing.

C U!

Bye,

Joost


On Mon, Jul 22, 2024 at 07:41:54AM +0200, Joost van Baal-Ilić wrote:
> Hi Stijn,
> 
> Excellent, thanks a lot!
> 
> BTW, I am not quite sure if, from \tt{stuff} one should generate .EX ; we
> currently generate "\fC stuff \fP" which is wrong.  I haven't found a good
> solution for this one yet.  (Generating .EX / .EE from verbatim{stuff} indeed
> sounds good to me.)
> 
> (To have your response appear at https://bugs.debian.org/1076648 , you can 
> mail
> to 1076...@bugs.debian.org ; I just resent your response below to that
> address.)
> 
> Bye,
> 
> Joost
> 
> 
> On Sun, Jul 21, 2024 at 09:09:02PM +0100, Stijn van Dongen wrote:
> > Thanks, this is interesting (and comprehensive). From the above it seems
> > that
> > .EX
> > stuff
> > .EE
> > dropped in the place mentioned will be sufficient to fix this, which of
> > course I'm happy to do. I'll first follow the link and test the proposed
> > fix, this may take between one and a few weeks. If this is inconveniently
> > slow for some reason let me know, then I can be quicker.
> > 
> > Best wishes,
> > Stijn
> > 
> > 
> > On Sat, Jul 20, 2024 at 7:11 PM Joost van Baal-Ilić 
> > wrote:
> > 
> > > Package: aephea
> > > Version: 12-248-3
> > > Severity: normal
> > >
> > > Hi *,
> > >
> > > When using \verbatim{stuff} or \tt{stuff} in an .azm file, the roff output
> > > features
> > >
> > > .nf \fC
> > > stuff
> > > .fi \fR
> > >
> > > or
> > >
> > > \fC stuff \fP
> > >
> > > .  It seems that's not valid roff; lots of details are available from
> > > https://savannah.gnu.org/bugs/index.php?64594 'bug #64594: [troff]
> > > "warning:
> > > cannot select font 'C'"' .  Trying to select the 'C' font in roff source
> > > causes
> > >
> > >  LC_ALL=C.UTF-8 \
> > >   MANROFFSEQ='' MANWIDTH=80 man --warnings -E UTF-8 -l -Tutf8 \
> > >   -Z man/uruk.8 >/dev/null
> > >
> > > (or just
> > >
> > >  groff -t -e -mandoc -Tutf8 man/uruk.8
> > >
> > > ) to emit
> > >
> > >  troff::37: warning: cannot select font 'C'
> > >
> > > ; I've read (also in https://savannah.gnu.org/bugs/index.php?64594 ) it's
> > > better to use
> > >
> > > .EX
> > > stuff
> > > .EE
> > >
> > > I believe changing the code around aephea/mac/aephea/base.zmm , line 118
> > >
> > >116  {vq#1}  {'\v{\1}'}
> > >117  {m#1}   {\@{\\fC}\1\@{\\fP}}
> > >118  {tt#1}  {\@{\\fC}\1\@{\\fP}}
> > >119
> > >120  {ftinc#2}   {\@{\\s+\1}\2\@{\\s-\1}}
> > >
> > > would be one way to fix it.
> > >
> > > I've seen the warning emitted with man-db 2.12.1-2 and groff 1.23.0-5
> > > (man-db 2.11.2 and groff 1.22.4 do _not_ emit the warning).
> > >
> > > I didn't do all possible testing myself yet.  Might get to it, one day.
> > >
> > > Stijn/upstream (Bcc-d): what do you think?
> > >
> > > Bye,
> > >
> > > Joost
> > >
> > >

Bug#1084920: RFS: caspar/20240818-1 -- Makefile snippets for centralized configuration management and typesetting

[Joost van Baal-Ilić]

Hi Phil e.a.,

On Fri, Oct 11, 2024 at 03:57:10PM +0100, Phil Wyett wrote:
> On Fri, 2024-10-11 at 16:30 +0200, Joost van Baal-Ilić wrote:
> > 
> > Now
> > 
> >   dget -x http://mdcc.cx/tmp/caspar/caspar_20240818-2.dsc
> > 
> > should get you a fixed caspar source package.  The file
> > caspar_20240818-2_source.changes refers to both -2 and the upstream
> > .orig.tar.xz sources: i ran "debuild -S -sa".
> > 
> > Could you please have a look at this?
> > 
> > Thanks again, Bye,
> > 
> > Joost
> > 
> > > > 
> 
> Hi,
> 
> Fails to download using 'dget'.
> 
> philwyett@ks-tarkin:~/Development/builder/debian/mentoring$ dget -x
> http://mdcc.cx/tmp/caspar/caspar_20240818-2.dsc
> dget: retrieving http://mdcc.cx/tmp/caspar/caspar_20240818-2.dsc
>   % Total% Received % Xferd  Average Speed   TimeTime Time 
> Current
>  Dload  Upload   Total   SpentLeft  Speed
>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:--
> 0
> curl: (22) The requested URL returned error: 404
> dget: curl caspar_20240818-2.dsc
> http://mdcc.cx/tmp/caspar/caspar_20240818-2.dsc failed
> philwyett@ks-tarkin:~/Development/builder/debian/mentoring$
> 
> Also note that new version uploads need to be '-1'.

Created a new caspar_20240818-1 :

dget -x http://mdcc.cx/tmp/caspar/caspar_20240818-1.dsc

Thanks again!

Bye,

Joost

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
  --Samuel Beckett in "Worstward Ho" (1983)

Bug#1084920: RFS: caspar/20240818-1 -- Makefile snippets for centralized configuration management and typesetting

[Joost van Baal-Ilić]

Hi again,

Now

  dget -x http://mdcc.cx/tmp/caspar/caspar_20240818-2.dsc

should get you a fixed caspar source package.  The file
caspar_20240818-2_source.changes refers to both -2 and the upstream
.orig.tar.xz sources: i ran "debuild -S -sa".

Could you please have a look at this?

Thanks again, Bye,

Joost



On Fri, Oct 11, 2024 at 03:39:51PM +0200, Joost van Baal-Ilić wrote:
> Hi Phil,
> 
> Thanks a lot for this review.  I know how to fix the problem, will do another
> release soonish.
> 
> Bye,
> 
> Joost
> 
> 
> On Fri, Oct 11, 2024 at 11:48:00AM +0100, Phil Wyett wrote:
> > Control: tags -1 +moreinfo
> > 
> > Hi Joost,
> > 
> > MAny thanks for your contribution to Debian.
> > 
> > I will not perform  full review at this time, the package fails to build, 
> > see
> > output below.
> > 
> >  dpkg-source -b .
> > dpkg-source: info: using source format '3.0 (quilt)'
> > dpkg-source: info: verifying ./caspar_20240818.orig.tar.xz.asc
> > gpgv: no valid OpenPGP data found.
> > gpgv: verify signatures failed: Unexpected error
> > dpkg-source: warning: cannot verify upstream tarball signature for
> > ./caspar_20240818.orig.tar.xz: no acceptable signature found
> > dpkg-source: info: building caspar using existing
> > ./caspar_20240818.orig.tar.xz
> > dpkg-source: info: building caspar using existing
> > ./caspar_20240818.orig.tar.xz.asc
> > dpkg-source: info: building caspar in caspar_20240818-1.debian.tar.xz
> > dpkg-source: info: building caspar in caspar_20240818-1.dsc
> >  debian/rules build
> > dh_testdir
> > ./configure --host=x86_64-linux-gnu --build=x86_64-linux-gnu --prefix=/usr 
> > --
> > mandir=\${prefix}/share/man --infodir=\${prefix}/share/info
> > checking for a BSD-compatible install... /usr/bin/install -c
> > checking whether build environment is sane... yes
> > checking for a race-free mkdir -p... /usr/bin/mkdir -p
> > checking for gawk... no
> > checking for mawk... mawk
> > checking whether make sets $(MAKE)... yes
> > checking whether make supports nested variables... yes
> > checking for zoem... yes
> > checking whether ln -s works... yes
> > checking that generated files are newer than configure... done
> > configure: creating ./config.status
> > config.status: creating Makefile
> > config.status: creating doc/Makefile
> > config.status: creating mk/Makefile
> > config.status: creating sgml/Makefile
> > config.status: creating script/Makefile
> > dh_testdir
> > /usr/bin/make
> > make[1]: Entering directory '/<>'
> > Making all in doc
> > make[2]: Entering directory '/<>/doc'
> > zoem -d roff -i casparize.azm -o casparize.1 || true
> > ___ [\dofile#2] failed to open file 
> > ___ [zoem] unwound on error/exception
> > zoem -d roff -i casparize.azm -o casparize.1
> > ___ [\dofile#2] failed to open file 
> > ___ [zoem] unwound on error/exception
> > make[2]: *** [Makefile:568: casparize.1] Error 9
> > make[2]: Leaving directory '/<>/doc'
> > make[1]: *** [Makefile:385: all-recursive] Error 1
> > make[1]: Leaving directory '/<>'
> > make: *** [debian/rules:33: build-stamp] Error 2
> > dpkg-buildpackage: error: debian/rules build subprocess returned exit status
> > 2
> > -
> > ---
> > Build finished at 2024-10-11T10:43:13Z
> > 
> > Finished
> > 
> > 
> > 
> > +
> > --+
> > | Cleanup   
> > |
> > +
> > --+
> > 
> > Not cleaning session: cloned chroot in use
> > Keeping session: unstable-amd64-sbuild-5554676f-8ab1-4f29-a54b-019414fd153d
> > E: Build failure (dpkg-buildpackage died)
> > 
> > Summary...
> > 
> > I believe casper is not yet ready for sponsorship at this time. Could the
> > contributor rectify one of more of the raised issues.
> > 
> > Once updated to your satisfaction and a new upload done, please remove the
> > 'moreinfo' tag on the Request For Sponsorship (RFS) bug report.
> > 
> > Regards
> > 
> > Phil
> > 
> > -- 
> > 
> > "I play the game for the game’s own sake"
> > 
> > Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans
> > 
> > --
> > 
> > Buy Me A Coffee: https://buymeacoffee.com/kathenasorg
> > 
> > Internet Relay Chat (IRC): kathenas
> > 
> > Matrix: #kathenas:matrix.org
> > 
> > Website: https://kathenas.org
> > 
> > Instagram: https://instagram.com/kathenasorg/
> > 
> > Threads: https://www.threads.net/@kathenasorg
> > 

Bug#1084920: RFS: caspar/20240818-1 -- Makefile snippets for centralized configuration management and typesetting

[Joost van Baal-Ilić]

Hi Phil,

Thanks a lot for this review.  I know how to fix the problem, will do another
release soonish.

Bye,

Joost


On Fri, Oct 11, 2024 at 11:48:00AM +0100, Phil Wyett wrote:
> Control: tags -1 +moreinfo
> 
> Hi Joost,
> 
> MAny thanks for your contribution to Debian.
> 
> I will not perform  full review at this time, the package fails to build, see
> output below.
> 
>  dpkg-source -b .
> dpkg-source: info: using source format '3.0 (quilt)'
> dpkg-source: info: verifying ./caspar_20240818.orig.tar.xz.asc
> gpgv: no valid OpenPGP data found.
> gpgv: verify signatures failed: Unexpected error
> dpkg-source: warning: cannot verify upstream tarball signature for
> ./caspar_20240818.orig.tar.xz: no acceptable signature found
> dpkg-source: info: building caspar using existing
> ./caspar_20240818.orig.tar.xz
> dpkg-source: info: building caspar using existing
> ./caspar_20240818.orig.tar.xz.asc
> dpkg-source: info: building caspar in caspar_20240818-1.debian.tar.xz
> dpkg-source: info: building caspar in caspar_20240818-1.dsc
>  debian/rules build
> dh_testdir
> ./configure --host=x86_64-linux-gnu --build=x86_64-linux-gnu --prefix=/usr --
> mandir=\${prefix}/share/man --infodir=\${prefix}/share/info
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for a race-free mkdir -p... /usr/bin/mkdir -p
> checking for gawk... no
> checking for mawk... mawk
> checking whether make sets $(MAKE)... yes
> checking whether make supports nested variables... yes
> checking for zoem... yes
> checking whether ln -s works... yes
> checking that generated files are newer than configure... done
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: creating doc/Makefile
> config.status: creating mk/Makefile
> config.status: creating sgml/Makefile
> config.status: creating script/Makefile
> dh_testdir
> /usr/bin/make
> make[1]: Entering directory '/<>'
> Making all in doc
> make[2]: Entering directory '/<>/doc'
> zoem -d roff -i casparize.azm -o casparize.1 || true
> ___ [\dofile#2] failed to open file 
> ___ [zoem] unwound on error/exception
> zoem -d roff -i casparize.azm -o casparize.1
> ___ [\dofile#2] failed to open file 
> ___ [zoem] unwound on error/exception
> make[2]: *** [Makefile:568: casparize.1] Error 9
> make[2]: Leaving directory '/<>/doc'
> make[1]: *** [Makefile:385: all-recursive] Error 1
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:33: build-stamp] Error 2
> dpkg-buildpackage: error: debian/rules build subprocess returned exit status
> 2
> -
> ---
> Build finished at 2024-10-11T10:43:13Z
> 
> Finished
> 
> 
> 
> +
> --+
> | Cleanup   
> |
> +
> --+
> 
> Not cleaning session: cloned chroot in use
> Keeping session: unstable-amd64-sbuild-5554676f-8ab1-4f29-a54b-019414fd153d
> E: Build failure (dpkg-buildpackage died)
> 
> Summary...
> 
> I believe casper is not yet ready for sponsorship at this time. Could the
> contributor rectify one of more of the raised issues.
> 
> Once updated to your satisfaction and a new upload done, please remove the
> 'moreinfo' tag on the Request For Sponsorship (RFS) bug report.
> 
> Regards
> 
> Phil
> 
> -- 
> 
> "I play the game for the game’s own sake"
> 
> Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans
> 
> --
> 
> Buy Me A Coffee: https://buymeacoffee.com/kathenasorg
> 
> Internet Relay Chat (IRC): kathenas
> 
> Matrix: #kathenas:matrix.org
> 
> Website: https://kathenas.org
> 
> Instagram: https://instagram.com/kathenasorg/
> 
> Threads: https://www.threads.net/@kathenasorg
> 

Bug#1084920: RFS: caspar/20240818-1 -- Makefile snippets for centralized configuration management and typesetting

[Joost van Baal-Ilić]

Package: sponsorship-requests
Severity: normal

Hi,

My PGP key expired, I've extended it and uploaded the extended key to
hkp://keyring.debian.org .  However, it seems this change did not yet trickle
down to our incoming machinery.  I would be grateful if anybody could sponsor
my latest work on my caspar package.

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

 * Package name : caspar
   Version  : 20240818-1
   Upstream contact : Joost van Baal-Ilić 
 * URL  : http://mdcc.cx/caspar/
 * License  : GPL-3+
 * Vcs  : http://git.mdcc.cx/caspar.git/
   Section  : devel

The source builds the following binary packages:

  caspar - Makefile snippets for centralized configuration management and 
typesetting
  caspar-doc - documentation for caspar

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

  https://tracker.debian.org/pkg/caspar

You can download the package with 'dget' using this command:

  dget -x http://mdcc.cx/tmp/caspar/caspar_20240818-1.dsc

You can verify the integrity using my key 57930DAB0B86B067 from e.g.
hkp://the.earth.li , hkp://pgp.surf.nl , hkp://keyserver.ubuntu.com or
hkp://keyring.debian.org .

Changes since the last upload:

caspar (20240818-1) unstable; urgency=medium

  * New upstream release - The Meždo Release
+ Upstream no longer ships typesetted (zoem) documentation in tarball
  release, but build-depends upon zoem.  This closes "Fails to build
  binary packages again after successful build". Thanks Lucas Nussbaum.
  (However, under some circumstances, dpkg-source detects local changes in
  aclocal.m4 and configure.  This might indicate a related bug.)
  (closes: #1049637)
+ d/control: add zoem, tidy and w3m to Build-Depends.
+ d/control: s/markdown/cmark/ in Suggests.
+ d/{rules,caspar-doc.install,caspar-doc.doc-base.{caspar,
  caspar-typesetting,csp_helper}}: do not try to install PostScript files:
  upstream no longer generates those.  BTW, one can easily generate .ps or
  PDF from manpages; e.g. "man -t caspar | ps2pdf" generates Portable
  Document Format on stdout.

  * d/{rules,lintian-overrides}: added lintian-overrides, call dh_lintian. see
Bug#1076648: 'aephea: causes groff warning "cannot select font 'C'" [...]'
    and see also https://savannah.gnu.org/bugs/index.php?64594 .

 -- Joost van Baal-Ilić   Thu, 10 Oct 2024 12:37:38 +0200


Greetings from 
https://wiki.debian.org/DebianEvents/gb/2024/MiniDebConfCambridge .

Bye,

Joost

Bug#1039195: Is fair a candidate for removal?

[Joost van Baal-Ilić]

Hi Andreas,

On Sat, Oct 05, 2024 at 10:53:29AM +0200, Andreas Tille wrote:
> 
> this bug came up as some candidate for the Bug of the Day[1] today.
> Usually the package salvage team is creating a Git repository (which I
> did[2] for your comfort in case you might want to keep the package
> either in Salvage team or debian/ or whereever it might make sense) and
> file an ITS bug to salvage the package.  However, the package does not
> really fulfill the ITS criteria[3] so I'm hesitating to do so.
> 
> The package is simply orphaned upstream and has no real users (since
> 2018 the vote number in popcon is maximum 1[4]).  Thus I woncer whether
> the package should rather be removed from unstable.  In case you
> consider the package worth keeping in Debian please let us know what
> team you might consider sensible as the maintainer of this package.
> I would volunteer to upgrade the packaging to latest standards and
> do some team upload if you want me to do so.
> 
> Kind regards
> Andreas.
> 
> [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks
> [2] https://salsa.debian.org/salvage-team/fair
> [3] 
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
> [4] 
> https://qa.debian.org/popcon-graph.php?packages=fair&show_installed=on&show_vote=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
> 

Thanks your work on improving Debian.  In https://bugs.debian.org/1039195 I
read "transitional sysv-init-to-unit generator [...] is in the process of being
deprecated and will be removed by the time Trixie ships, so the remaining
packages that ship init scripts without systemd units will stop working."  Has
this decision about the Trixie release been taken?  (I missed that.)  Or is
there still some chance of the compatibility surviving the release?  Do you
happen to have any pointers on this?

I'm curious on what Guus feels about this.  I myself am doubting about the
usefulness of removing packages which do not have any RC bug.  But happy to
follow Guus's opinion on what's best in this specific case.

Bye,

Joost

Bug#1082983: [L10N,DE] debian-history: updated german translation

[Joost van Baal-Ilić]

Hi Holger,

fixed in git in ea279c0..659f9d9 , thanks!

Bye,

Joost

On Sun, Sep 29, 2024 at 04:43:02PM +0200, Holger Wansing wrote:
> Package: debian-history
> Severity: wishlist
> Tags: patch,l10n
> 
> 
> Hi,
> 
> attached is an updated german translation for debian-history.
> 
> Please include it in your package.
> 
> 
> Many Thanks
> 
> So long
> Holger
> 
> 
> -- 
> Holger Wansing 
> PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1081819: lowering severity, adjusting title (was: Re: Bug#1081819: liboprf:FTBFS:build failure (‘-fcf-protection=full’ is not supported))

[Joost van Baal-Ilić]

severity 1081819 normal
retitle 1081819 liboprf: test tp-dpg-corrupt segfaults on riscv
thanks

Lower severity from serious to normal: liboprf 0.3.2-3 builds fine on all
release architectures (including riscv64), see
https://buildd.debian.org/status/package.php?p=liboprf .

Adjusting this in order to facilitate migration to trixie/testing.

Thanks, Bye,

Joost

Bug#655664: debian-timeline bug hygiene

[Joost van Baal-Ilić]

Hi Helmut,

Thanks for taking care of the debian-timeline bug list.

On Thu, Sep 19, 2024 at 08:17:26AM +0200, Helmut Grohne wrote:
> Control: severity 655664 serious
> 
> Hi Ana and others,
> 
> I looked into #1032166 as it is an rc bug without activity for prolonged
> time. It asks for debian-timeline not to be included in bookworm and
> since bookworm has been released, I consider it done thus closing.
> 
> On the flip side, it actually states that debian-timeline is not useful
> in any current browser due to #655664. So that's the underlying
> technical problem. I am thus raising that bug to rc severity even though
> it was originally filed at normal severity: The most common way to use
> the package shows an empty timeline. Please let me know if you disagree
> with this.

FWIW: I feel this is exactly the right thing to do.

Bye,

Joost

Bug#1082166: libopaque:FTBFS:build failure (‘-fcf-protection=full’ is not supported)

[Joost van Baal-Ilić]

Thanks again Yue Gui!  It's the same problem as for liboprf.  I'll get to it in
a few days.

Bye,

Joost

On Thu, Sep 19, 2024 at 10:52:21AM +0800, Yue Gui wrote:
> Source: libopaque
> Version: 0.99.7-1
> Severity: serious
> Tags: FTBFS, patch
> User: debian-ri...@lists.debian.org
> Usertags: riscv64
> X-Debbugs-Cc: debian-ri...@lists.debian.org
> 
> Dear libopaque Maintainer,
> The package libopaque build failed on architectures other than x86 and
> i386.The crucial buildd log below:
> ```
> 
> make[1]: Entering directory '/<>/src'
> cc -g -O2 -Werror=implicit-function-declaration
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -Wall -pedantic -Wl,-z,defs -Wl,-z,relro
> -Wl,-z,noexecstack -Wl,-z,now -fsanitize=signed-integer-overflow
> -fsanitize-undefined-trap-on-error -fcf-protection=full  -Iaux_ -o
> common.o -c common.c
> cc -g -O2 -Werror=implicit-function-declaration
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -Wall -pedantic -Wl,-z,defs -Wl,-z,relro
> -Wl,-z,noexecstack -Wl,-z,now -fsanitize=signed-integer-overflow
> -fsanitize-undefined-trap-on-error -fcf-protection=full  -Iaux_
> -I/usr/include/oprf -o opaque.o -c opaque.c
> cc -g -O2 -Werror=implicit-function-declaration
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -Wall -pedantic -Wl,-z,defs -Wl,-z,relro
> -Wl,-z,noexecstack -Wl,-z,now -fsanitize=signed-integer-overflow
> -fsanitize-undefined-trap-on-error -fcf-protection=full  -Iaux_ -o
> aux_/kdf_hkdf_sha512.o -c aux_/kdf_hkdf_sha512.c
> make -C utils/man
> make[2]: Entering directory '/<>/src'
> make[2]: warning: jobserver unavailable: using -j1.  Add '+' to parent
> make rule.
> pandoc -s  -o opaque.1 opaque.md
> cc1: error: ‘-fcf-protection=full’ is not supported for this target
> cc1: error: ‘-fcf-protection=full’ is not supported for this target
> cc1: error: ‘-fcf-protection=full’ is not supported for this target
> make[1]: *** [makefile:145: opaque.o] Error 1
> make[1]: *** Waiting for unfinished jobs
> make[1]: *** [makefile:148: common.o] Error 1
> make[1]: *** [makefile:148: aux_/kdf_hkdf_sha512.o] Error 1
> make[2]: Leaving directory '/<>/src/utils/man'
> make[1]: Leaving directory '/<>/src'
> dh_auto_build: error: cd src && make -j4 "INSTALL=install
> --strip-program=true" returned exit code 2
> make: *** [debian/rules:11: binary-arch] Error 25
> dpkg-buildpackage: error: debian/rules binary-arch subprocess returned
> exit status 2
> 
> ```
> The full buildd log is here:
> https://buildd.debian.org/status/fetch.php?pkg=libopaque&arch=riscv64&ver=0.99.7-1&stamp=1726708574&raw=0
> 
> My solution to this issue:
>  This error is caused by the fact that architectures other than x86 do not
> support -fcf-protection=full. We can add a condition to check if the host
> architecture is x86. If it is not x86, this CFLAG should be disabled.I have
> finished above work ,and i have tested that on local, it works well.The
> debpatch is in the attachment. Please let me know wheather this solution
> can be accepted.
> 
> Gui-Yue
> Best Regards

Bug#1082063: pyparallel: no homepage field

[Joost van Baal-Ilić]

Hoi,

Op Wed, Sep 18, 2024 at 03:11:15AM + schreef benatt...@gezapig.nl:
> X-Debbugs-Cc: team+pyt...@tracker.debian.org, debian-pyt...@lists.debian.org,
> python-modules-t...@lists.alioth.debian.org,
> python-modules-t...@alioth-lists.debian.net

Please do not do that.  Your bug report will be seen and acted upon in due time 
by
sending it to just the documented address.

Groetjes,

Joost

Bug#1082019: RFP: email-oauth2-proxy -- transparently add OAuth 2.0 support to IMAP/POP/SMTP client applications

[Joost van Baal-Ilić]

Package: wnpp
Severity: wishlist

* Package name: email-oauth2-proxy
  Version : 2024-09-12
  Upstream Author : Simon Robinson https://simon.robinson.ac e.a.
* URL : https://github.com/simonrob/email-oauth2-proxy
* License : Apache-2.0
  Programming Lang: Python
  Description : transparently add OAuth 2.0 support to IMAP/POP/SMTP client 
applications

Email services that support IMAP, POP and/or SMTP access are increasingly
requiring the use of OAuth 2.0 to authenticate connections, but not all clients
support this method. This tool creates a simple local proxy that intercepts the
traditional IMAP/POP/SMTP authentication commands and transparently replaces
them with the appropriate SASL (X)OAuth 2.0 commands and credentials. Your
email client can continue to use the login or auth/authenticate options, with
no need to make it aware of OAuth's existence. The proxy works in the
background with a menu bar/taskbar helper or as a headless system service.
One can use email-oauth2-proxy to access e.g. an Office 365 email account
without using Outlook's build in authentication, or use Gmail without using the
App Password.


I plan to use this software myself @ $dayjob.  Happy to contribute to any
packaging effort, e.g. @ salsa in the debian namespace.

Bye,

Joost

Bug#1081730: debian-faq: section 2.1 still documents Debian 11 bullseye as stable

[Joost van Baal-Ilić]

Hi Étienne,

Thanks for reporting!  Just fixed in 4d485c1..c4a6308 @ salsa , will end up in
next FAQ release.

Bye,

Joost

On Sat, Sep 14, 2024 at 11:18:02AM +0200, Étienne Mollier wrote:
> Package: debian-faq
> Version: 11.1
> Severity: normal
> 
> Dear Maintainer,
> 
> I had a quick lookup at the faq when hunting for newcomers
> documentation, and noticed section 2.1 "What is the latest
> version of Debian?" still shows:
> 
> > release 11, a.k.a. the `stable' distribution or bullseye
> 
> Debian 11 bullseye has left oldstable community maintenance and
> entered lts cycle last month, so it is probably a good time to
> read the following instead:
> 
> > release 12, a.k.a. the `stable' distribution or bookworm
> 
> Note I haven't reported other occurrences of bullseye in the
> document, but a quick grep suggests there are several more left
> at a number of locations.
> 
> Have a nice day,  :)
> Étienne.
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.10.9-amd64 (SMP w/12 CPU threads; PREEMPT)
> 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
> 
> debian-faq depends on no packages.
> 
> debian-faq recommends no packages.
> 
> Versions of packages debian-faq suggests:
> ii  firefox-esr [www-browser] 115.15.0esr-1
> ii  zathura-pdf-poppler [pdf-viewer]  0.3.3-1
> 
> -- no debconf information
> 
> -- 
>   .''`.  Étienne Mollier 
>  : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
>  `. `'   sent from /dev/pts/4, please excuse my verbosity
>`-

Bug#1081819: liboprf:FTBFS:build failure (‘-fcf-protection=full’ is not supported)

[Joost van Baal-Ilić]

Hi Gui-Yue,

On Mon, Sep 16, 2024 at 09:04:28AM +0800, Yue Gui wrote:
> Dear maintainer,
> I'll test that again.By the way, I noticed that this package has upgraded
> to 0.3.2-2,however the modifications i suggested seem not applied.Could you
> give me more information about this upgrade?

I only saw your very nice patch (thanks a lot for that!) after I noticed the
build failures after uploading 0.3.2-1 and acted upon those, together with
stef.

Working on an upload of 0.3.2-3 now, using your and stef's valuable input.

Thanks again!

Bye,

Joost

Bug#723138: Taking over metar into Debian Science team

[Joost van Baal-Ilić]

Hi Andreas,

Your assumption is correct, you are very welcome to move metar git/maintenance
to the debian science umbrella.

Thanks!

Bye,

Joost


On Sun, Sep 15, 2024 at 07:54:02AM +0200, Andreas Tille wrote:
> Hi,
> 
> metar showed up as Bug of the Day[1] and I'd like to work on the bugs of
> the package.  I think its a nice fit to Debian Science team.  Usually I
> would file some ITS bug following the Package Salvage procedure[2] but
> given that you asked for sponsoring (RFS) I assume you would like to
> join a team where its easy to find sponsors which fits for the Debian
> Science team.
> 
> So I simply assume that this is fine for you.
> 
> Kind regards
> Andreas.
> 
> [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks
> [2] 
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
> 
> -- 
> https://fam-tille.de
> 

Bug#1080048: mlucas - program to perform Lucas-Lehmer test on a Mersenne number

[Joost van Baal-Ilić]

Hi,

FYI: The mclucas package ( program to perform Lucas-Lehmer test on a Mersenne
number) will likely get removed from Debian sid soonish (and won't be released
with upcoming trixie) unless someone spends some time on it soonish.

See https://tracker.debian.org/pkg/mlucas and
https://bugs.debian.org/1080048 .

On first sight, to me it looks like shipping this with upcoming stable would
serve our users.

This is part of the massive sid cleanup effort being conducted these days:
https://udd.debian.org/bugs/?release=any&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=sidremove&fusertaguser=helmutg%40debian.org&allbugs=1&ctags=1&sortby=id&sorto=asc&format=html#results

Bye,

Joost - who won't have time to deal with this these days...

Bug#1050473: I can help

[Joost van Baal-Ilić]

Op Date: Thu, 11 Jan 2024 17:27:26 -0800, schreef Kevin Madrid:
> I can adopt this package if still needed.

Yes, please do.  I like leave.

Thanks, Bye,

Joost

Bug#939464: #939464 RFP: python-oletools -- Python tools to analyze MS OLE2 files

[Joost van Baal-Ilić]

Hi,

FYI: I've built 11/bullseye and 12/bookworm-binaries of python3-oletools.  I've
used the git repo at https://salsa.debian.org/pkg-security-team/python-oletools
.  For 11/bullseye I had to apply a trivial patch; 12/bookworm builds out of
the box.  Binaries and source packages are available from

 deb-src https://non-gnu.uvt.nl/debian bullseye python-oletools
 deb https://non-gnu.uvt.nl/debian bullseye python-oletools

 deb-src https://non-gnu.uvt.nl/debian bookworm python-oletools
 deb https://non-gnu.uvt.nl/debian bookworm python-oletools

.  See https://non-gnu.uvt.nl/ .

Enjoy,

Joost

Bug#1078946: blends-doc: fix for "3.5. Debian Pure Blends from philosophical point of view": name of Trotsky

[Joost van Baal-Ilić]

Package: blends-doc
Tags: patch
Severity: minor

Hi,

here's a small patch:

"use English, not German spelling for nom de guerre of Lev Davidovich Bronstein"

Relevant for https://blends.debian.org/blends/ch03.html#philosophy .

Thanks, Bye,

Joost

commit 68b18435b67ee54c36385bbd330d39c61dd05fb5
Author: Joost van Baal-Ilić 
Date:   Sun Aug 18 09:24:17 2024 +0200

use English, not German spelling for nome de guerre  of Lev Davidovich Bronstein

diff --git a/doc/en/03_general_ideas.xml b/doc/en/03_general_ideas.xml
index 19607f1..c74bb00 100644
--- a/doc/en/03_general_ideas.xml
+++ b/doc/en/03_general_ideas.xml
@@ -249,7 +249,7 @@ time (or over a certain time span) its quality.
 
 "To determine at the right moment the critical point where
  quantity changes into quality is one of the most important and
- difficult tasks in all the spheres of knowledge." (Trotzki) This
+ difficult tasks in all the spheres of knowledge." (Leon Trotsky) This
  might mean that we just passed the point in time when Debian changed
  its quality.  At one point we even observed a change once the package
  pool system was implemented to cope with the increased number of

Bug#1077405: debian/upstream/signing-key.asc (was: Re: Bug #1077405: pysodium-0.7.18.tar.gz.asc missing?)

[Joost van Baal-Ilić]

Hi again stef,

On Thu, Aug 08, 2024 at 12:21:10PM +0200, Joost van Baal-Ilić wrote:
> On Thu, Aug 08, 2024 at 12:06:44PM +0200, stef wrote:
> > On Thu, Aug 08, 2024 at 07:08:13AM +0200, Joost van Baal-Ilić wrote:
> > > 
> > > I just found out https://pypi.org/project/pysodium/#files lacks a
> > > pysodium-0.7.18.tar.gz.asc .   (It's not published on
> > > https://github.com/stef/pysodium/releases either.)  (You did sign your 
> > > pysodium
> > > releases in the past, didn't you?)   Could you please pgp sign your 
> > > release,
> > > and upload the signature?  Thanks! Bye,
> > 
> > i just added the signatures to github: 
> > 
> > https://github.com/stef/pysodium/releases/tag/v0.7.18
> 

OK, it's always something: after some fiddling I've found out our copy of your
key we have in our git (in
https://salsa.debian.org/python-team/packages/pysodium/-/blob/master/debian/upstream/signing-key.asc?ref_type=heads
) is expired:

 4096/970DEB6694D50988
 créé : 2014-08-23  expirée : 2018-09-03  utilisation : SC
 confiance : inconnu   validité : expirée
 [ expirée ] (1). stefan marsiske (temp online key) 

Where can we/Debian find an updated copy of that key?

Thanks again!

Bye,

Joost

Bug#1077405: Bug #1077405: pysodium-0.7.18.tar.gz.asc missing?

[Joost van Baal-Ilić]

On Thu, Aug 08, 2024 at 12:06:44PM +0200, stef wrote:
> On Thu, Aug 08, 2024 at 07:08:13AM +0200, Joost van Baal-Ilić wrote:
> > Hi stef,
> > 
> > I just found out https://pypi.org/project/pysodium/#files lacks a
> > pysodium-0.7.18.tar.gz.asc .   (It's not published on
> > https://github.com/stef/pysodium/releases either.)  (You did sign your 
> > pysodium
> > releases in the past, didn't you?)   Could you please pgp sign your release,
> > and upload the signature?  Thanks! Bye,
> 
> i just added the signatures to github: 
> 
> https://github.com/stef/pysodium/releases/tag/v0.7.18

Awesome, thanks!

Bye,

Joost

Bug#1077405: Bug #1077405: pysodium-0.7.18.tar.gz.asc missing?

[Joost van Baal-Ilić]

Hi stef,

I just found out https://pypi.org/project/pysodium/#files lacks a
pysodium-0.7.18.tar.gz.asc .   (It's not published on
https://github.com/stef/pysodium/releases either.)  (You did sign your pysodium
releases in the past, didn't you?)   Could you please pgp sign your release,
and upload the signature?  Thanks! Bye,

Joost


PS/note to self: debian/upstream/signing-key.asc in
https://salsa.debian.org/python-team/packages/pysodium/-/blob/master/debian/upstream/signing-key.asc

Bug#926369: www.debian.org: gettextize the Social Contract

[Joost van Baal-Ilić]

Hi Laura e.a.,

Op Thu, 4 Apr 2019 08:28:53 +0200 schreef Laura Arjona Reina:
>
> It would be nice to gettextize the Debian Social contract.
> The web page of the Debian Social Contract is considered upstream
> version for the package debian-doc, and the Debian flyers also produce a
> LaTeX-based version of it.
>
> We already have several translations in the wml format; if we gettextize
> the document, the same .po file/strings could be used for the 1.0 and
> the current version of the file, for the debian-doc-* packages, and for
> the debian-flyers project.
>
> I didn't look too much on how to do it but probably po4a-gettextize and
> po4a can help on this.

~$ po4a-gettextize --help-format

just taught me it supports both wml and DocBook XML.  It looks doable.

> If this works, we could use the same procedure to gettextize other
> foundation documents as the Debian Constitution, Diversity Statement,
> CoC, or other that shouldn't change much in time, and we'd like to show
> in different formats and languages in an easy way.

Excellent plan.  The Debian FAQ is another document which has translations, but
never got gettextize'd.  Otoh: I am not really sure about what would be best to
do with it; it very much shows its age and lack of maintenance :(

Anyway, yes, gettextizing the Social Contract would be a very useful thing to
do.

Bye,

Joost (biting his tongue and not committing himself to anything)

Bug#1076648: aephea: causes groff warning "cannot select font 'C'" when using \verbatim{ } or \tt{ }

[Joost van Baal-Ilić]

Hi Stijn,

Excellent, thanks a lot!

BTW, I am not quite sure if, from \tt{stuff} one should generate .EX ; we
currently generate "\fC stuff \fP" which is wrong.  I haven't found a good
solution for this one yet.  (Generating .EX / .EE from verbatim{stuff} indeed
sounds good to me.)

(To have your response appear at https://bugs.debian.org/1076648 , you can mail
to 1076...@bugs.debian.org ; I just resent your response below to that
address.)

Bye,

Joost


On Sun, Jul 21, 2024 at 09:09:02PM +0100, Stijn van Dongen wrote:
> Thanks, this is interesting (and comprehensive). From the above it seems
> that
> .EX
> stuff
> .EE
> dropped in the place mentioned will be sufficient to fix this, which of
> course I'm happy to do. I'll first follow the link and test the proposed
> fix, this may take between one and a few weeks. If this is inconveniently
> slow for some reason let me know, then I can be quicker.
> 
> Best wishes,
> Stijn
> 
> 
> On Sat, Jul 20, 2024 at 7:11 PM Joost van Baal-Ilić 
> wrote:
> 
> > Package: aephea
> > Version: 12-248-3
> > Severity: normal
> >
> > Hi *,
> >
> > When using \verbatim{stuff} or \tt{stuff} in an .azm file, the roff output
> > features
> >
> > .nf \fC
> > stuff
> > .fi \fR
> >
> > or
> >
> > \fC stuff \fP
> >
> > .  It seems that's not valid roff; lots of details are available from
> > https://savannah.gnu.org/bugs/index.php?64594 'bug #64594: [troff]
> > "warning:
> > cannot select font 'C'"' .  Trying to select the 'C' font in roff source
> > causes
> >
> >  LC_ALL=C.UTF-8 \
> >   MANROFFSEQ='' MANWIDTH=80 man --warnings -E UTF-8 -l -Tutf8 \
> >   -Z man/uruk.8 >/dev/null
> >
> > (or just
> >
> >  groff -t -e -mandoc -Tutf8 man/uruk.8
> >
> > ) to emit
> >
> >  troff::37: warning: cannot select font 'C'
> >
> > ; I've read (also in https://savannah.gnu.org/bugs/index.php?64594 ) it's
> > better to use
> >
> > .EX
> > stuff
> > .EE
> >
> > I believe changing the code around aephea/mac/aephea/base.zmm , line 118
> >
> >116  {vq#1}  {'\v{\1}'}
> >117  {m#1}   {\@{\\fC}\1\@{\\fP}}
> >118  {tt#1}  {\@{\\fC}\1\@{\\fP}}
> >119
> >120  {ftinc#2}   {\@{\\s+\1}\2\@{\\s-\1}}
> >
> > would be one way to fix it.
> >
> > I've seen the warning emitted with man-db 2.12.1-2 and groff 1.23.0-5
> > (man-db 2.11.2 and groff 1.22.4 do _not_ emit the warning).
> >
> > I didn't do all possible testing myself yet.  Might get to it, one day.
> >
> > Stijn/upstream (Bcc-d): what do you think?
> >
> > Bye,
> >
> > Joost
> >
> >

Bug#1076648: aephea: causes groff warning "cannot select font 'C'" when using \verbatim{ } or \tt{ }

[Joost van Baal-Ilić]

Package: aephea
Version: 12-248-3
Severity: normal

Hi *,

When using \verbatim{stuff} or \tt{stuff} in an .azm file, the roff output
features

.nf \fC
stuff
.fi \fR

or

\fC stuff \fP

.  It seems that's not valid roff; lots of details are available from
https://savannah.gnu.org/bugs/index.php?64594 'bug #64594: [troff] "warning:
cannot select font 'C'"' .  Trying to select the 'C' font in roff source causes

 LC_ALL=C.UTF-8 \
  MANROFFSEQ='' MANWIDTH=80 man --warnings -E UTF-8 -l -Tutf8 \
  -Z man/uruk.8 >/dev/null

(or just

 groff -t -e -mandoc -Tutf8 man/uruk.8

) to emit

 troff::37: warning: cannot select font 'C'

; I've read (also in https://savannah.gnu.org/bugs/index.php?64594 ) it's
better to use

.EX
stuff
.EE

I believe changing the code around aephea/mac/aephea/base.zmm , line 118

   116  {vq#1}  {'\v{\1}'}
   117  {m#1}   {\@{\\fC}\1\@{\\fP}}
   118  {tt#1}  {\@{\\fC}\1\@{\\fP}}
   119
   120  {ftinc#2}   {\@{\\s+\1}\2\@{\\s-\1}}

would be one way to fix it.

I've seen the warning emitted with man-db 2.12.1-2 and groff 1.23.0-5
(man-db 2.11.2 and groff 1.22.4 do _not_ emit the warning).

I didn't do all possible testing myself yet.  Might get to it, one day.

Stijn/upstream (Bcc-d): what do you think?

Bye,

Joost

Bug#1076635: publicfile-installer: Re: publicfile distribution license

[Joost van Baal-Ilić]

Package: publicfile-installer
Version: N/A
Severity: normal

On Sat, Jul 20, 2024 at 03:18:42PM +0200, D. J. Bernstein wrote in Message-ID:
<20240720131842.85956.qm...@cr.yp.to> To: publicf...@list.cr.yp.to:
> Bastian Germann writes:
> > https://cr.yp.to/distributors.html does not list publicfile.
> 
> Updated now.

Indeed https://cr.yp.to/distributors.html now says:

 What are the distribution terms for publicfile?

 2024.07.20: I hereby place the publicfile package (in particular,
 publicfile-0.52.tar.gz, with SHA-256 checksum
 3f9fcf737bfe48910812cc357a31bf1f2e3da2490dbd175ce535830f251c08ef) into the
 public domain. The package is no longer copyrighted. 

.  Debian should no longer ship publicfile-installer, but a new publicfile
package.  (and a bug to ftp.debian.org should get reported).

I _might_ get to that, one day...

Bye,

Joost

Bug#1076613: pyreadstat: diff for NMU version 1.2.7-1

[Joost van Baal-Ilić]

Hi Boyuan Yang,

On Fri, Jul 19, 2024 at 12:45:49PM -0400, Boyuan Yang wrote:
> Package: pyreadstat
> Version: 1.2.6-1
> Severity: normal
> Tags: patch  pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for pyreadstat (versioned as 1.2.7-1)

Great, thanks a lot!

> and
> uploaded it to DELAYED/7. Please feel free to tell me if I
> should delay it longer.

O no, no need for more delay at all.

Thanks again, Bye,

Joost

Bug#1068975: #1068975: src:python-zxcvbn: pwdsphinx 1.0.19-1 entered testing

[Joost van Baal-Ilić]

Hi,

FYI: pwdsphinx 1.0.19-1 just migrated to testing.  This should partly fix
#1068975 "src:python-zxcvbn: Abandoned upstream and unmaintained": pwdsphinx no
longer has a hard zxcvbn dependency.

HTH, Bye,

Joost

Bug#1071355: In how far are several packages affected by bug #1071355 of maptools

[Joost van Baal-Ilić]

Hi Andreas,

On Thu, Jul 04, 2024 at 07:56:40AM +0200, Andreas Tille wrote:
> 
> there was a series of testing removals due to bug #1071355 of
> r-cran-maptools.  Since maptools was removed from CRAN[1] we intend to
> remove this package.  However, before doing so I would like to
> understand why packages like r-cran-factominer, r-cran-ggpubr,
> r-cran-vim, r-cran-systemfit, r-cran-survminer and others where I can't
> see any connection to r-cran-maptools were removed from testing.

I _think_ it's something like this:

r-cran-ggpubr depends r-cran-rstatix depends r-cran-car depends r-cran-maptools 
.
Therefore a #1071355 in r-cran-maptools which is serious and tagged ftbfs
causes r-cran-ggpubr to get removed.

Bye,

Joost

PS: tnx "apt-rdepends r-cran-ggpubr"

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 +0000
> +++ 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 +
> +++ liboprf-0.1+git

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&arch=amd64&ver=1.0.4-1&stamp=1672405470&raw=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&arch=arm64&ver=1.0.2-3&stamp=1668331092&raw=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