Bug#1072745: ITP: gophian -- tools to help with Debianzing Go software

[Maytham Alsudany]

Package: wnpp
Severity: wishlist
Owner: Maytham Alsudany 
X-Debbugs-CC: debian...@lists.debian.org, debian-devel@lists.debian.org

* Package name: gophian
  Version : 0.1.0
  Upstream Contact: Maytham Alsudany 
* URL : https://codeberg.org/Maytha8/gophian
* License : GPL-3+
  Programming Lang: Python
  Description : tools to help with Debianzing Go software

 Gophian is a featureful and intelligent tool to assist developers in packaging
 Go software for the Debian distribution.
 .
 The currently recommended dh-make-golang tool is known to be unreliable and
 relies on various outdated and deprecated libraries to function. gophian seeks
 to change that, by replicating the functionality of "go get" in Python, and
 providing something that works out of the box, as well as adding on more
 features and more intelligence to improve the Go packaging experience.

Will need a sponsor to upload to NEW.

--
Kind regards,
Maytham Alsudany


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

Accepted how-can-i-help 19 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 12 May 2024 21:10:39 +0200
Source: how-can-i-help
Architecture: source
Version: 19
Distribution: unstable
Urgency: medium
Maintainer: Tomasz Nitecki 
Changed-By: Lucas Nussbaum 
Closes: 1070713
Changes:
 how-can-i-help (19) unstable; urgency=medium
 .
   [ Nicolas Noirbent ]
   * Fix autorm variable initialisation. Closes: #1070713
Checksums-Sha1:
 a378ed5021ec8b4c17ab84b620298e278cb7da1c 1704 how-can-i-help_19.dsc
 1e921395c591b8052352819ea5c6468724dd8acf 11232 how-can-i-help_19.tar.xz
 1be0a02b7ea9fca05e0af2a694a5a9548cfcefbb 13190 
how-can-i-help_19_source.buildinfo
Checksums-Sha256:
 72a56f8eebf349260c5ba9a8e83bb7780f27fd44aaa8422c52d558b445edcfea 1704 
how-can-i-help_19.dsc
 9ac26d2619615605f5317e2a8e782fdef537b0824f24069ca0859dd8e53ae765 11232 
how-can-i-help_19.tar.xz
 28a6cbbc164f4046af7171fb5d00e1bd10596770e4a67810cae420380a0d8fce 13190 
how-can-i-help_19_source.buildinfo
Files:
 fdeaf255e269bd47966e4aaf9d5400ad 1704 devel optional how-can-i-help_19.dsc
 459d262c3a788d8aa263fd5452403a8b 11232 devel optional how-can-i-help_19.tar.xz
 a146c521cc3f2cbaac04a0aba9788bdd 13190 devel optional 
how-can-i-help_19_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE/t7ByzN7z1CfQ8IkORS1MvTfvpkFAmZBFEgACgkQORS1MvTf
vpndIg//fsMcHCqLWOwn6DhKk8j6nJYPn64c1PBYfucxonleW0ZJrJmeyvLcgQnP
0V9ZBIxDoE1Fc15ptKgEHqCh44BLKnLZ3+J9yQwBPvU+ToSHFITr6aiv4VrKKWKC
7rbPSvjT4Zpq2Yc6Zcds87lPUszmD7hpGZf80f/oTc8p/4cxpUVueneTPDKpryb1
26oBRxu9wIPVQmBqdqs9hbyjyueGfyShOE3vHzkQIfugwGF806VcVYafY2OzG4Ja
m+DKB25knae4g/pBZym1QEyo0csMhNSEIBefIYQETz3htHSZwcCn8FzRjFPCzDI3
inW2C7minmEFHQS3ImZl5JGd+zxZEiiW9ellLPw02hLRwjWdDdXw35wVXxeGLxQt
g3eL/Yz2ZAGT5mc2OjQlZFD1WvIVJm7ZVEqXZrB+f2hLO2XgCniHdvifWq5V4LXj
wKySzKNyfUe0gBvTtAxTM1hmT/iTDJfwGiLLojqJDoM6V8aAkEDRpQS1lxrmEHkI
GxqPhVw0bMHiGddGWksxQ54BjZPcroNdi3LAeZJrIGstpbByNo5nNcn3T5/yLytb
Io0InlNRkeHW4vELmTaqmxLhID7mj/JvA1Rbs6zYfjnjorjM2H7XVj+y2a40OdNJ
G/aSlfAqTQMJZM+Sex0Tb54qwlEmpeMxBqFuaI2iicZmW7LmXWg=
=qHl/
-END PGP SIGNATURE-



pgpFDu92ALtcH.pgp
Description: PGP signature

Accepted how-can-i-help 18 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 07 May 2024 10:15:00 +0200
Source: how-can-i-help
Architecture: source
Version: 18
Distribution: unstable
Urgency: medium
Maintainer: Tomasz Nitecki 
Changed-By: Lucas Nussbaum 
Closes: 1069108 1070652
Changes:
 how-can-i-help (18) unstable; urgency=medium
 .
   [ Paul Wise ]
   * Always build the manual page from source
   * Do not print the autorm header when all autorm items are hidden
   * Bump debhelper from old 12 to 13.
   * Update standards version to 4.6.1, no changes needed.
   * Use debhelper execute_after_* instead of override_
   * Update standards version to 4.6.2, no changes needed.
 .
   [ Athos Ribeiro ]
   * {Dir,File}.exists? were removed from Ruby 3.2. Use .exist? instead.
 Closes: #1069108
 .
   [ Lucas Nussbaum ]
   * Explicitly require ostruct. Closes: #1070652
 + Thanks Vincent Lefevre for the report, and Cédric Boutillier
   for the fix.
   * Add missing build-dep on docbook-xml
Checksums-Sha1:
 eef5c3adb8ed4b8fac9ddc8539884e3a2008c94f 1704 how-can-i-help_18.dsc
 66c33b2687bad5f0eacf8183255727603ca09cbf 11184 how-can-i-help_18.tar.xz
 84327c1b03de20c370b60fb1dc558cd7726b9801 13158 
how-can-i-help_18_source.buildinfo
Checksums-Sha256:
 8f88d7bd11e9814a7b35f5bf0d2976d885d3e969cc00b2893b6fdbfa859c3a93 1704 
how-can-i-help_18.dsc
 66c07fcc7f1a3d6b57a4bdfb7e7ff9854de653d9236c63726feb6d9ee7b5fdc4 11184 
how-can-i-help_18.tar.xz
 bf3638b48ad3a6b02c79950eec92484053e08819d24e0f7a9181c37d68236171 13158 
how-can-i-help_18_source.buildinfo
Files:
 a81cf09fda303e3dbd3ee4ddc3491e17 1704 devel optional how-can-i-help_18.dsc
 96034af8276b797c12fbe9c205b4d4d1 11184 devel optional how-can-i-help_18.tar.xz
 792ee81dacdf07489f9e91c9668dc9f6 13158 devel optional 
how-can-i-help_18_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE/t7ByzN7z1CfQ8IkORS1MvTfvpkFAmY54ysACgkQORS1MvTf
vplaUQ//fn3jiQwDQm+ASPeA+hlQ0Hk6ayQMdDFp73nxkvss4YdFTNcqZka6BUjw
z2Dcu0xgfzOUsS6/SaJVsU0hWJDm2Qw7FxSNCQX/supRI7jkZqXTNw+Gxmfc47Mi
NxgNWdlOK5/xcBa52dKNZiHBr4ljRY0NpXclSYPxPAJQFzVhPuUKG5b5Fw6HYAcB
ygJzb88Bo8sHoft5fa22R3Ru5xvU65hYQn9GqaNXAqlJms7f+aIQl50NIUj8A51c
fdE+0KCAMMTljn01iN/S+2AYUoVCAfkMpt9wY/cDhZxOgq77FQqHTirKLxJeio/9
akiZzRlTnvRIIS9V3MwdJzCcnnwDS5q5n9LXUGgEZMFdQoEd/2CEcfVGztCk6JuG
Gy2PilvOhkjtcJT5ybZnyy8es6CLk4txBCTL0lBnh4wJNN8aB2S86MB72hBoivAG
7dwP1KVAuX4w5BYdtVwCBk0J3uZKqi1nqU1IiM7uTybUX74f3hyw/V8zOG4qDucP
TpiyOU7UmS3igjRGGMBWjtP7ge7BSfS1kO94PS2o183wk1Mx+tiI693BB+B2Dw68
9t9OJXCbKdZLtgkOAJ/BBUQRGs781WixX2xYOUjesnG4N1ov4fmxfmvWIuSVmiwM
JNZN0aBq30c1jhZcmgpcdbzDjgqkpG9S9KU+Cn9zYUSpgVqz/gE=
=KRRg
-END PGP SIGNATURE-



pgpSYey7DALcF.pgp
Description: PGP signature

Accepted doublecmd-help 1.1.10-1 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 09 Mar 2024 13:46:43 +
Source: doublecmd-help
Built-For-Profiles: noudeb
Architecture: source
Version: 1.1.10-1
Distribution: unstable
Urgency: medium
Maintainer: Pascal Packaging Team 
Changed-By: Graham Inggs 
Changes:
 doublecmd-help (1.1.10-1) unstable; urgency=medium
 .
   * New upstream release
   * Update debian/copyright
   * Install READ_ME.txt files, as these are now
 referenced by the HTML documentation
Checksums-Sha1:
 378677f1933219d803232c5e741290547fbbbd7f 2133 doublecmd-help_1.1.10-1.dsc
 d39e0dd0a9fac1880446b1ed4ab7d96478f43860 7947552 
doublecmd-help_1.1.10.orig.tar.gz
 01c9b44d1e48e22ec9cec103725f2d9eca0bacb7 3124 
doublecmd-help_1.1.10-1.debian.tar.xz
Checksums-Sha256:
 9fb6aec253e269abef8407e414cdf100e2510796ec342d7ea9a8d32c4209ded1 2133 
doublecmd-help_1.1.10-1.dsc
 8175d082712beb757aa48136e6443f3532e950d437292f3e3de50f1baeef1ab1 7947552 
doublecmd-help_1.1.10.orig.tar.gz
 8ebf03f6c652ad7f0f5c493d31fdf85f6612e261aa15e7c9975e6d6023b338ff 3124 
doublecmd-help_1.1.10-1.debian.tar.xz
Files:
 d10cd128aee38a3138ec7ab47c1881f1 2133 doc optional doublecmd-help_1.1.10-1.dsc
 2558aab80a44373746767f5430f66a08 7947552 doc optional 
doublecmd-help_1.1.10.orig.tar.gz
 2145ecd6a0182d46af4cf76010cad52a 3124 doc optional 
doublecmd-help_1.1.10-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEJeP/LX9Gnb59DU5Qr8/sjmac4cIFAmXsapcACgkQr8/sjmac
4cLwFw/7B2DuRdI4ct0Dh5iFHqbm6aC+TGpCab9AWoow3+6dAxIVoCAuhEOvmTog
bdYcvrbNVuve1aa+3b8Bj+hCCqaCujAKx8HWIJ9x/VxccVjD/XxcS8SsyWSt5S1S
73sJu1C/SmdDAKDrxCX7A0TW91SXen3bDDrhGYj5T4Dvms1U+1dHWqJ1YJsxClaR
zm1x4jnzBM4LAryvmfvvxgv6pIZwMyyBcKbR9IxqwXRvCgIXU9tE4+sp5i4AO99c
6JM6pakOYQIWgStfEh8qOHlmAstEs/1YAxRb13NQzmU4QR+qnI/I9asVuFhuGqYh
zNobQcaJKrsb5vDVVBItHW4S43baJgnAVaVIkWLur6xceF2GaK62m7XN8nldvraX
2mREJG+fsYgWM79DK9Wkas+wp1Q6D1TOkfqsIuFbxTVUMM3TU5ZACez/xPWor1xQ
7+aCCt+xzqXMwgGCnoFGuTqY9y2RCwouZ2NwjTnDn+Ao7A2SR7AJnz1bTbx3WfCh
3ZP7Yx1JAzRZ2ytUxPPFfAPlT7aQOsZERnVtioHhwaP+wi0GJwG6f7AaYOlkwrux
w4slgijjTa8+Z1L5bc1+YyUowHGn2euQCkd9OlNB9LcRYeqDF48rQzagE4vvnroA
EaF4H89tZYq8cVYwygQNP4wgbnVHPiXf6zVRHOVaUGOvWRJ4D3M=
=0f+s
-END PGP SIGNATURE-



pgpCIbIBd9X_R.pgp
Description: PGP signature

Re: Requesting help with the t64 transition

[Steve Langasek]

On Fri, Mar 08, 2024 at 01:58:22PM +0100, John Paul Adrian Glaubitz wrote:
> debbootstrap first downloads perl-modules-5.38_5.38.2-3_all.deb, then later 
> tries
> to install perl_5.38.2-3.2_powerpc.deb which causes dpkg to bail out. It can 
> be
> reproduced with:

> # debootstrap --no-check-gpg --arch=powerpc --variant=buildd \
>   --include=debian-ports-archive-keyring unstable sid-powerpc-sbuild \
>   http://ftp.ports.debian.org/debian-ports

> Thus, we need to get rid of perl-modules-5.38_5.38.2-3_all.deb from the
> repositories in order to be able to create fresh chroots with debbootstrap
> again.  Since packages in Debian Ports are directly synced from the main
> repos for arch:all, this needs to be done by the FTP masters.

Why is debootstrap picking perl-modules-5.38_5.38.2-3_all.deb when
perl-modules-5.38_5.38.2-3.2_all.deb is present in unstable for 2 days?

I'm also not sure why it hasn't expired out of unstable given that it is
superseded.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: Requesting help with the t64 transition

[John Paul Adrian Glaubitz]

Hi,

On Tue, 2024-03-05 at 09:56 +0100, John Paul Adrian Glaubitz wrote:
> I would like to ask for help with the t64 transition for m68k, powerpc and
> sh4 because it's getting too much for me alone and I'm really exhausted.
> 
> I have build many packages for powerpc already and some for m68k and sh4,
> but I'm not there yet. The progress with powerpc is the furthest, but perl
> is still uninstallable and I don't really understand why because cudf does
> not produce any useful output.

Some update. I have managed to get powerpc back to the state where the 
devscripts
and build-essential packages can be installed. However, I had to update the 
chroots
on the buildds manually as debbootstrap currently fails due to left-over 
perl-modules
package.

debbootstrap first downloads perl-modules-5.38_5.38.2-3_all.deb, then later 
tries
to install perl_5.38.2-3.2_powerpc.deb which causes dpkg to bail out. It can be
reproduced with:

# debootstrap --no-check-gpg --arch=powerpc --variant=buildd \
  --include=debian-ports-archive-keyring unstable sid-powerpc-sbuild \
  http://ftp.ports.debian.org/debian-ports

Thus, we need to get rid of perl-modules-5.38_5.38.2-3_all.deb from the 
repositories
in order to be able to create fresh chroots with debbootstrap again. Since 
packages
in Debian Ports are directly synced from the main repos for arch:all, this 
needs to
be done by the FTP masters.

For m68k and sh4, I managed to build perl and pam so that all Perl packages are 
rebuilding
for now. Thorsten Glaser is kindly helping me with the transition on m68k.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Requesting help with the t64 transition

[John Paul Adrian Glaubitz]

On Tue, 2024-03-05 at 09:56 +0100, John Paul Adrian Glaubitz wrote:
> For m68k, there is mitchy.debian.net and for powerpc, there is 
> perotto.debian.net.
> 
> For sh4, qemu-user can be used.
> 
> Chroots here: https://people.debian.org/~glaubitz/chroots/

I'm collecting packages for bootstrap here: 
https://people.debian.org/~glaubitz/bootstrap/

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Requesting help with the t64 transition

[Simon Richter]

Hi,

On 3/5/24 17:56, John Paul Adrian Glaubitz wrote:


For m68k, there is mitchy.debian.net and for powerpc, there is 
perotto.debian.net.


As soon as the container with my stuff arrives, I have another A1200 
with 68060 and 603e+. Alas, Linux does not support asymmetric 
multiprocessing so I cannot run both at the same time.


   Simon

Requesting help with the t64 transition

[John Paul Adrian Glaubitz]

Hello,

I would like to ask for help with the t64 transition for m68k, powerpc and
sh4 because it's getting too much for me alone and I'm really exhausted.

I have build many packages for powerpc already and some for m68k and sh4,
but I'm not there yet. The progress with powerpc is the furthest, but perl
is still uninstallable and I don't really understand why because cudf does
not produce any useful output.

See: 
https://buildd.debian.org/status/fetch.php?pkg=bfs=powerpc=3.1.2-1=1709623862=0

I am not subscribed to debian-devel, so please CC.

For m68k, there is mitchy.debian.net and for powerpc, there is 
perotto.debian.net.

For sh4, qemu-user can be used.

Chroots here: https://people.debian.org/~glaubitz/chroots/

Thank you,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Editor extensions to help editing debian/* files?

[Dominique Dumont]

On Sunday, 21 January 2024 08:43:05 CET Otto Kekäläinen wrote:
> What editors and extensions are you using to augment your productivity
> and minimize mistakes when editing debian/* files?

That's not exactly an editor extension, but I use 'cme edit dpkg' to modify 
debian files.
This tool provide a GUI with integrated help to edit most debian/* files.

See 
https://github.com/dod38fr/config-model/wiki/Managing-Debian-packages-with-cme

HTH

Re: Editor extensions to help editing debian/* files?

[Johannes Schauer Marin Rodrigues]

Hi Otto,

Quoting Otto Kekäläinen (2024-01-29 07:06:51)
> > > It would be nice though if the version in Debian was newer :)
> >
> > I probably won't update it until it is suitable for inclusion in a
> > stable release. This means at minimum being relatively safe to run in
> > an untrusted source tree, probably by using debvm to generate a VM
> > containing the relevant tools and running the tools in the VM.
> 
> As it happens, I have been writing this tool[1] that runs all builds
> and tests inside a container, and check-all-the-things would be a
> perfect match to be wrapped by the command 'debcraft validate' that
> mounts sources inside a throwaway container.. ;)
> 
> https://salsa.debian.org/otto/debcraft

could you add an entry for your tool as docker solution number twelve to this
table:

https://wiki.debian.org/SystemBuildTools#Package_build_tools

Thanks!

cheers, josch

signature.asc
Description: signature

Re: Editor extensions to help editing debian/* files?

[Otto Kekäläinen]

Hi!

> > It would be nice though if the version in Debian was newer :)
>
> I probably won't update it until it is suitable for inclusion in a
> stable release. This means at minimum being relatively safe to run in
> an untrusted source tree, probably by using debvm to generate a VM
> containing the relevant tools and running the tools in the VM.

As it happens, I have been writing this tool[1] that runs all builds
and tests inside a container, and check-all-the-things would be a
perfect match to be wrapped by the command 'debcraft validate' that
mounts sources inside a throwaway container.. ;)

https://salsa.debian.org/otto/debcraft

Re: Editor extensions to help editing debian/* files?

[Paul Wise]

On Thu, 2024-01-25 at 22:22 -0800, Otto Kekäläinen wrote:

> Yeah, I remember looking into cats some years back as a place to learn
> what commands exist. Similarly I also occasionally browse
> https://pre-commit.com/hooks.html.

Yeah, there are lots of other tools similar to cats, many of them are
linked from the doc/TODO file but there are more I need to add there
and probably many more that I don't know about.

> The challenge with having all possible checkers is that they create a
> lot of noise and managing the false positives end up being a lot of
> work. Not suitable for daily use, but I will probably use cats for
> "annual checkups" on stuff I maintain.

One of the newer features added to cats in 2019 helps there, for some
commands it only enables the highest severity level, then if there is
no output it moves on to the next level, and so on. You can also
disable individual checks or groups of checks as desired. Probably
there are some other things we could add to improve the situation.

> It would be nice though if the version in Debian was newer :)

I probably won't update it until it is suitable for inclusion in a
stable release. This means at minimum being relatively safe to run in
an untrusted source tree, probably by using debvm to generate a VM
containing the relevant tools and running the tools in the VM.

> By the way, I submitted some small fixes at
> https://github.com/collab-qa/check-all-the-things/pulls.

Thanks, I will review them when I get time.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: Editor extensions to help editing debian/* files?

[Otto Kekäläinen]

Hi!

> Thats beginning to look like the history of check-all-the-things.

Yeah, I remember looking into cats some years back as a place to learn
what commands exist. Similarly I also occasionally browse
https://pre-commit.com/hooks.html.
The challenge with having all possible checkers is that they create a
lot of noise and managing the false positives end up being a lot of
work. Not suitable for daily use, but I will probably use cats for
"annual checkups" on stuff I maintain.

It would be nice though if the version in Debian was newer :)

Since https://tracker.debian.org/pkg/check-all-the-things lacks a
working git and homepage link, you guys should probably do a new
upload to Debian.
By the way, I submitted some small fixes at
https://github.com/collab-qa/check-all-the-things/pulls.

Re: Editor extensions to help editing debian/* files?

[Paul Wise]

On Sat, 2024-01-20 at 23:43 -0800, Otto Kekäläinen wrote:

> PS. Related, these are commands I frequently run manually but don't
> have any editor integration for:

Thats beginning to look like the history of check-all-the-things.

Initially I maintained such a list of commands on the wiki:

   https://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package

Then later I worked on a tool to replace that to ease maintenance.

Jakub Wilk was in parallel working on a second implementation.

Eventually I found out and since his tool had a better design but mine
had a better name ;) then we joined forces to work on his together:

https://github.com/collab-qa/check-all-the-things

I haven't had the motivation to work on it for some years though, but I
keep adding TODO items/ideas to a local tree just in case that changes.

There are of course a ton of other tools with the same aim out there,
but almost all of them are aimed at web output or editor output etc,
while check-all-the-things is currently aimed at command-line users,
and most other tools have a more complex process to add new checkers.

I cannot recommend running it on a source tree you don't trust, because
it currently has no sandboxing mechanisms so the source tree could
contain exploits for the QA tools that it may run. Now that debvm and
bwrap etc exist, there is the potential for this to be fixed nicely.

If SARIF support were ever to be implemented, there is the potential
for it to produce machine-readable output and thus be useful for
editors and to become the basis of Debian-wide static/dynamic analysis,
perhaps as an integral part of Debusine when that happens.

https://github.com/collab-qa/check-all-the-things/issues/4

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: Editor extensions to help editing debian/* files?

[Otto Kekäläinen]

> I looked into better tooling/editor support in general for Debian
> languages in general. I think the industry answer is that "someone"
> ought to build a "language (LSP) server" for the Debian languages, which
> would enable editors with LSP support[1] to get the same basic features.

True - LSPs is the common API into linters (and more) nowadays, but I
was ready to settle with something simpler, as building a LSP for
Debian I imagine is a lot of work..

..
> I might have a stab at writing a prototype for a LSP for Debian formats.

..however, if you start doing a minimal prototype it would be a great!

Who knows if the LSP some day in the future would forward snippets to
a Debian-specific LLM that would give hints on what needs to be
changed to conform to the Debian policy :)

Re: Editor extensions to help editing debian/* files?

[Niels Thykier]

Otto Kekäläinen:

Hi!

Thanks for the tip, Niels!

It would be cool if dh_assistant had some kind of generic command like
"dh_assistant validate" which would attempt to introspect all
information silently and emit output only if it fails to parse
something.


That might be an option. The question is what more would you expect here 
that is actually feasible to implement. :)


Feel free to propose concrete ideas and I will have a look at them. 
Sadly, debhelper was never designed to be introspect-able, but depending 
on the ask it might be doable or doable with some limitations.



Additionally it could emit a non-zero exit code on errors.
I tested your latest command and it works as you expected, though it
does not use exit code.
> # dh_assistant detect-unknown-hook-targets
The hook target override_dh_car_configure in debian/rules does not
seem to match any known commands.
# echo $?
0



Adding an exit 2 as a "linter" exit code in the next version with a 
"--no-linter-exit-code" (open for better names) to have it always return 
0 (which I suspect will be easier for some users).



Also if the JSON included the filename and line number of the finding
it would be handy:

{
"unknown-hook-targets": [
   {
  "candidates": [],
  "filename": "debian/rules",
  "target-name": "override_dh_car_configure"
   }
]
}



I would be happy to include that. Unfortunately, I only have the 
information available from:


  LC_ALL=C make -Rrnpsf debian/rules debhelper-fail-me 2>/dev/null

Which seems to have the following limitations:

 * filename/line is *not* included for "empty" targets

 * When a line number is present, it is for the first line of the recipe
   and not the target definition itself. One might be tempted to do
   (lineno - 1) but it is not accurate[0].

I am open to suggestions for this that does not involve parsing the 
makefile itself. I will leave ad-hoc parsing of Turing complete 
languages to other programs.




I don't know how much ambition you have for expanding the scope of
dh_assistant.


The dh_assistant tool is growing organically based on requests, or 
things I need, or when I notice people needing to introspect something 
and I can easily provide it via dh_assistant. :)


I did not aim for it to be a full-fledged linter, though I do not mind 
adding debhelper related linting where possible.




We already have Lintian which has a massive amount of
checks, including ones related to debian/rules. It is just a pity
Lintian does not support checking a single file or the debian/
directory contents without building the package.. [1]

[1] https://bugs.debian.org/262783


The infrastructure and design choices of lintian is working against 
lintian here. I doubt #262783 will ever be solved as there is a major 
difference between a 'clean assembled packages' and the '"mess" you call 
a git checkout".
  Even if we get #262783, a lot of lintian checks are written to check 
.deb packages because that is the final result and you avoid a lot of 
"what if d/rules decided to do X - what if it does *not* do X" 
ambiguity. Which the person who does #262783 would probably also spend a 
lot of effort porting binary checks in to the ("dirty") source context 
where you have less context.




I looked into better tooling/editor support in general for Debian 
languages in general. I think the industry answer is that "someone" 
ought to build a "language (LSP) server" for the Debian languages, which 
would enable editors with LSP support[1] to get the same basic features.


Among features that LSP servers can provide are:

 * Configurable on save actions (such as wrap-and-sort)
 * Format file on user request (wrap-and-sort, again)
 * Diagnostics (linting)
 * Text highlighting / inline documentation / inlay hints
 * Auto-completion

The first half is basically what you are looking for and the latter half 
is what I have been focusing on in my plugin, so it does seem to cover 
our interests.


I might have a stab at writing a prototype for a LSP for Debian formats. 
But it will not be in `dh_assistant`.


Best regards,
Niels

--

[0]: Sample makefile

"""
my-target:
# Some makefile level comment (not indented)
first line of the target definition
"""

Here the line number reported by make would be 3, but the target 
definition is actually line 1 (so doing a -1 would be "off by one per 
line of comment")


[1]: Which allegedly includes:
 * emacs via eglot (?), which comes built-in these days
 * neovim
 * atom/pulsar via plugin (?)
 * IDEA via open source plugin or builtin via their paid subscription

Re: Editor extensions to help editing debian/* files?

[Otto Kekäläinen]

Hi!

Thanks for the tip, Niels!

It would be cool if dh_assistant had some kind of generic command like
"dh_assistant validate" which would attempt to introspect all
information silently and emit output only if it fails to parse
something. Additionally it could emit a non-zero exit code on errors.
I tested your latest command and it works as you expected, though it
does not use exit code.

# dh_assistant detect-unknown-hook-targets
The hook target override_dh_car_configure in debian/rules does not
seem to match any known commands.
# echo $?
0

Also if the JSON included the filename and line number of the finding
it would be handy:

{
   "unknown-hook-targets": [
  {
 "candidates": [],
 "filename": "debian/rules",
 "target-name": "override_dh_car_configure"
  }
   ]
}


I don't know how much ambition you have for expanding the scope of
dh_assistant. We already have Lintian which has a massive amount of
checks, including ones related to debian/rules. It is just a pity
Lintian does not support checking a single file or the debian/
directory contents without building the package.. [1]

[1] https://bugs.debian.org/262783

Re: Editor extensions to help editing debian/* files?

[Niels Thykier]

Niels Thykier:

[...]

Btw, `debhelper` has a `dh_assistant` command that can do some very 
basic analysis as well. Not sure any of it is useful for editor 
integration (especially because some of the features requires that it 
receives the same arguments as `dh` or/and `dh_auto_configure`).
   Personally, I have used `dh_assistant detect-hook-targets` to detect 
which overrides that `dh` would pick up (relies heavily on 
"Build-Depends: dh-sequence-foo" style add ons though). Admittedly, not 
in an editor context but if you can combine it with something that reads 
known make file targets, you could get a "override_typo looks like an 
override target but `dh` does not recognize it"-style warning out of it.


Maybe I should just add that feature directly to `dh_assistant`. Then 
you can have one more command for your checklist! :D


Best regards,
Niels




Ok, added this to debhelper/13.11.10:

$ apt satisfy 'debhelper (>= 13.11.10), libtext-levenshtein-perl'
$ dh_assistant detect-unknown-hook-targets [--output-format=json]

The code can have false positives - especially if you use `dh ... --with 
...`.  In that case, you have to pass the same `--with ...` to 
`dh_assistant` to avoid the false positive. All the more reason to use 
declarative `Build-Depends: dh-sequence-foo`.


For machine output use the JSON format (lintian/lintian-brush, etc.). 
The text output is subject to change. MRs for improvements welcome at 
https://salsa.debian.org/debian/debhelper/


End sidebar/thread hijack.

Best regards,
Niels

Re: Editor extensions to help editing debian/* files?

[Niels Thykier]

Otto Kekäläinen:

Hi!

What editors and extensions are you using to augment your productivity
and minimize mistakes when editing debian/* files?

I am aware of dpkg-dev-el for Emacs mentioned in the DD reference[1].
I am a big fan of Pulsar[2] and recently found a 'language-debian'
plugin for Pulsar[3], but didn't get it to emit any errors/messages.

I would be interested to learn what editors and integrations others
use specifically for debian/* files. I've witnessed several old DDs
stop their Debian work, and many aspiring ones give up on becoming a
DD, because the Debian packaging work is so laboursome. One small
thing that could ease the burden could be better editor integrations
that help people write and maintain the debian/* files with less
effort.

- Otto

[...]


Hi Otto

Personally, I use PyCharm/IDEA with the IDEA-debpkg plugin (the latter I 
wrote because there was no existing plugin) or emacs with dpkg-dev-el 
depending on the context.


I think my use of PyCharm/IDEA started for similar reasons that you are 
praising Pulsar - if I need to work on another file, it would have an 
integration for that (like the preview pane with markdown, support for 
shellcheck, etc.).
  In most cases, PyCharm (and I presume Pulsar as well) has basic 
support out of the box or can hint you to a plugin based on the filename 
(extension based) - I do not have to hunt it down. Sadly, except for my 
own Debian plugin because d/control and d/changelog does not have 
extensions... oh well.


Thanks for the command list. I have added a few of them to my todo list 
for my plugin. Like `wrap-and-sort` is due now that it supports comments 
and has better defaults out of the box.


Btw, `debhelper` has a `dh_assistant` command that can do some very 
basic analysis as well. Not sure any of it is useful for editor 
integration (especially because some of the features requires that it 
receives the same arguments as `dh` or/and `dh_auto_configure`).
  Personally, I have used `dh_assistant detect-hook-targets` to detect 
which overrides that `dh` would pick up (relies heavily on 
"Build-Depends: dh-sequence-foo" style add ons though). Admittedly, not 
in an editor context but if you can combine it with something that reads 
known make file targets, you could get a "override_typo looks like an 
override target but `dh` does not recognize it"-style warning out of it.


Maybe I should just add that feature directly to `dh_assistant`. Then 
you can have one more command for your checklist! :D


Best regards,
Niels

Editor extensions to help editing debian/* files?

[Otto Kekäläinen]

Hi!

What editors and extensions are you using to augment your productivity
and minimize mistakes when editing debian/* files?

I am aware of dpkg-dev-el for Emacs mentioned in the DD reference[1].
I am a big fan of Pulsar[2] and recently found a 'language-debian'
plugin for Pulsar[3], but didn't get it to emit any errors/messages.

I would be interested to learn what editors and integrations others
use specifically for debian/* files. I've witnessed several old DDs
stop their Debian work, and many aspiring ones give up on becoming a
DD, because the Debian packaging work is so laboursome. One small
thing that could ease the burden could be better editor integrations
that help people write and maintain the debian/* files with less
effort.

- Otto

[1] 
https://www.debian.org/doc/manuals/developers-reference/developers-reference.en.html
[2] https://optimizedbyotto.com/post/pulsar-best-text-file-and-code-editor/
[3] https://web.pulsar-edit.dev/packages/language-debian


PS. Related, these are commands I frequently run manually but don't
have any editor integration for:

wrap-and-sort --wrap-always --verbose

make --dry-run --makefile=debian/rules

codespell --write --check-filenames --check-hidden debian/

find debian/ -type f | xargs spellintian --picky

aspell --mode=debctrl -c debian/control

duck -v --color=always

find -name *.pot -exec i18nspector "{}" +; find -name *.po -exec
i18nspector "{}" +;

shellcheck -x --shell=bash $(shell grep -Irnw -e '^#!.*/bash' | sort
-u |cut -d ':' -f 1 | xargs)
shellcheck -x --shell=sh $(shell grep -Irnw -e '^#!.*/sh' | sort -u
|cut -d ':' -f 1 | xargs)

if [ "$(find debian/patches/ -type f -not -name series | wc -l)" !=
"$(wc -l < debian/patches/series)" ]
then
  echo "Contents of debian/patches/series does not match number of
patches in debian/patches"
fi

Re: Please help test the PAM in experimental

[Svante Signell]

Hi,

you don't seem to address:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029097
why?

On Fri, 2024-01-19 at 11:40 -0700, Sam Hartman wrote:
> 
> There are a number of changes, and I'd just like a bit more
> confidence
> that it works as expected before uploading to unstable in about a
> week.
> 
> Changes include:
> 
> * Running pam_umask with usergroups support by default.
> 
> * libpam-modules now depends on libsystemd0 because utmp is not
>   y2038-clean and upstream has decided to depend on elogind for that.
> 
> * New PAM upstream and thus newly rebased patches.
> 
> So, it would be helpful especially if you would install libpam-
> modules
> and libpam0g from experimental.

Re: Please help test the PAM in experimental

[Luca Boccassi]

On Fri, 19 Jan 2024 at 18:41, Sam Hartman  wrote:
>
>
> There are a number of changes, and I'd just like a bit more confidence
> that it works as expected before uploading to unstable in about a week.
>
> Changes include:
>
> * Running pam_umask with usergroups support by default.
>
> * libpam-modules now depends on libsystemd0 because utmp is not
>   y2038-clean and upstream has decided to depend on elogind for that.
>
> * New PAM upstream and thus newly rebased patches.
>
> So, it would be helpful especially if you would install libpam-modules
> and libpam0g from experimental.

Thanks for the update, looks good in my testing VM, will check on my
testing desktop later.

I see one warning due to pam_lastlog being deprecated but still in the
default config:

[495799.050948] login[55]: PAM unable to dlopen(pam_lastlog.so):
/usr/lib/security/pam_lastlog.so: cannot open shared object file: No
such file or directory
[495799.051113] login[55]: PAM adding faulty module: pam_lastlog.so

I guess this needs to be filed against the login package, as that's
shipping the rule enabling it?

Please help test the PAM in experimental

[Sam Hartman]

There are a number of changes, and I'd just like a bit more confidence
that it works as expected before uploading to unstable in about a week.

Changes include:

* Running pam_umask with usergroups support by default.

* libpam-modules now depends on libsystemd0 because utmp is not
  y2038-clean and upstream has decided to depend on elogind for that.

* New PAM upstream and thus newly rebased patches.

So, it would be helpful especially if you would install libpam-modules
and libpam0g from experimental.


signature.asc
Description: PGP signature

Re: DebGPT: how LLM can help debian development? demo available.

[Otto Kekäläinen]

Hi!

I've noticed that the most recent LLMs are actually very good at
finding information, summarizing and giving code examples about Debian
already without extra training. One just needs to double check that
the answer was correct to not fall for when they are simply making up
plausible sounding stuff. However, checking if an answer is correct is
much faster than figuring it out something from scratch.

Anyone can test it for themselves at https://chat.lmsys.org/ - no
registration required, just participate in the research by reading the
replies from two LLMs and telling the leaderboard which reply you
think was better.

Knowing there is so much repetitive petty work involved in Debian
package maintenance that drains a of energy both from current and
aspiring maintainers I have been skimming the README at
https://salsa.debian.org/deeplearning-team/debgpt with high hopes for
DebGPT to evolve over time. It would be great if there was a LLM with
enough logic and context that it could do things like Lintian-brush
(or even go all the way like Janitor and start filing MRs on Salsa for
humans to review/finalize).

Re: DebGPT: how LLM can help debian development? demo available.

[Andreas Tille]

Am Wed, Jan 03, 2024 at 01:06:25PM +0100 schrieb Andrey Rakhmatullin:
> On Wed, Jan 03, 2024 at 11:33:06AM +0200, Andrius Merkys wrote:
> > On 2024-01-03 11:12, Andrey Rakhmatullin wrote:
> > > On Wed, Jan 03, 2024 at 09:58:33AM +0200, Andrius Merkys wrote:
> > > > To me the most time consuming task in Debian recently is the Python
> > > > transitions. I wonder whether DebGPT could help with them. Maybe there 
> > > > are
> > > > other, non-Debian-specific GPTs for this task, but I would prefer a 
> > > > Debian
> > > > one.
> > > As "transitions" is too broad, can you list actual problems you spend time
> > > on for them?
> > 
> > Mostly failing tests, and mostly due to API changes between subsequent
> > Python 3.x versions.
> So the solution is either find a patch in the upstream repo (committed or
> proposed in issues/PRs) or write one yourself. Not sure what can AI help
> here with.

Well, may be people replacing 'assertEquals' by the new name
'assertEqual'[1] could talk with some GPT first how much work all their
downstreams might have due to this kind of estetic changes to find
patches?  In the last year I've seen quite some changes which do not
obviously serve any better purpose than fitting some esthetics pattern
breaking some API.  (The s/assertEquals/assertEqual/ one is not the
only example.)

Kind regards
Andreas.

[1] 
https://salsa.debian.org/python-team/packages/pypandoc/-/blob/debian/master/debian/patches/0005-Python3.12.patch?ref_type=heads

-- 
http://fam-tille.de

Re: DebGPT: how LLM can help debian development? demo available.

[Mo Zhou]

debgpt v0.4.90 has been uploaded to NEW, targeting at unstable.
This tool is still under development, new features will be added later.
Usage examples can be found in debgpt(1) or README.md .
They are the same file.

During my (limited number) of experiments when developing this tool,
LLMs are good at:

1. $ debgpt git commit
    (many recent git commits in debgpt repo are generated using LLM)
    This is the one I like most so far. This will likely become a part of
    my git workflow.
2. summarizing arbitrary texts in pretty format
3. explaining arbitrary code files
4. fortune, e.g. $ debgpt fortune :joke
5. writing boring boiler plate code (such as matplotlib)

LLMs are bad at:

1. logic and deduction
    for example, it does not always tell the relation between
    "SyntaxError: print 'hello world'" and an upstream PR named "initial
    python3 support.
    (Maybe chain of thoguht can improve this but I postponed it)
2. generating unix-format patches
   Let it give you the edited files directly, instead of the diff.

This tool is not specific to Debian distribution. Adding additional text
sources like Arch Wiki, Gentoo Policy/Wiki is very easy and planned
as future feature. Or you can load these web pages through
`debgpt --cmd 'curl '`.

Support for dealing very long documents will be further investigated
in future releases.

On 1/3/24 20:07, Mo Zhou wrote:

I have implemented the OpenAI API frontend, with streaming to terminal
enabled.
On 1/2/24 17:07, M. Zhou wrote:

Following what has been discussed in d-project in an offtopic
subthread, I prepared some demo on imagined use cases to
leverage LLMs to help debian development.
https://salsa.debian.org/deeplearning-team/debgpt

Accepted node-help-me 5.0.0-1 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 05 Jan 2024 20:32:59 +0800
Source: node-help-me
Architecture: source
Version: 5.0.0-1
Distribution: unstable
Urgency: low
Maintainer: Debian Javascript Maintainers 

Changed-By: Ying-Chun Liu (PaulLiu) 
Changes:
 node-help-me (5.0.0-1) unstable; urgency=low
 .
   * New upstream version 5.0.0
Checksums-Sha1:
 49aef0570447bd127e568b8e4fbb44402409c8a9 2274 node-help-me_5.0.0-1.dsc
 b1ebe63b967b74060027c2ac61f9be12d354a6f6 4698 node-help-me_5.0.0.orig.tar.gz
 cb31903df275699446cafacd922d42f621271fd5 3108 
node-help-me_5.0.0-1.debian.tar.xz
 3ed3ba8ee0dc84ebc97a136d5dc75b07f81575d8 19737 
node-help-me_5.0.0-1_source.buildinfo
Checksums-Sha256:
 ab3fa5e30b23d2ff60bb088012871387f0f421bfee06dde5b3a41f9ac1c88507 2274 
node-help-me_5.0.0-1.dsc
 5c4df5422b6e17a0e37dc48eb2342b081dd12e6935aa19bdf2d5e8f3e79d97df 4698 
node-help-me_5.0.0.orig.tar.gz
 869a5ba81cb3e7bd07c8e5cbda6e8585031dec124c2a5dd756878bd8b9c96573 3108 
node-help-me_5.0.0-1.debian.tar.xz
 772af468358130b4b04c8ecea25a9ede22dc2363992f6a34d7be8fe4493c6cc2 19737 
node-help-me_5.0.0-1_source.buildinfo
Files:
 d4084e281531572d092cfbdedcba18d5 2274 javascript optional 
node-help-me_5.0.0-1.dsc
 289d859ef2bf9e2a075c6a62b2fbafb5 4698 javascript optional 
node-help-me_5.0.0.orig.tar.gz
 744cc015fd2aa026d6585f53ed90e25a 3108 javascript optional 
node-help-me_5.0.0-1.debian.tar.xz
 e935ce307ce39b771e7a31876804d32e 19737 javascript optional 
node-help-me_5.0.0-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEEo2h49GQQhoFgDLZIRBc/oT0FiIgFAmWX/HsTHHBhdWxsaXVA
ZGViaWFuLm9yZwAKCRBEFz+hPQWIiH5oEACaLYgQnnEUTksx9gRUpSX9cIsHJItj
IJqYPsO4VnnvNaxduqGFJMvyT5062z7Ci3S9PQ/P+mcOYiabYOMKt81aQTmoW0vt
GBH6eL0NsWpZuiEnDul/RS3zywLmNk3eg4REYStu+9mRSJ0RjIivG/+vB36bFyfb
1yOv0ncNxobg4MVOZZtYph4eqQwrzKQbsJfRpxeNeQg9PKlY4Dq32IxNvI7B/oGh
hJ39GomHFiYGPa+d/fHlGzbibBF2T3v6FEUvcrJeXD4Lks/x+//WTAayLBdoxY6l
pQvyiCVk5lZvlqW95FFmLERE1AgvGcgmPQTvjHDWH9VXX1IhK/Qw95zh+EsNZY8T
gvXGgrTYSt/HSiXOl/Xaisvey+10J0KYpzO7uSHsg83FfVQbaP66YS2xI/4sjKIL
4Xz46RQQoaizSliLuoyt73xnFc1wMrnig9SDb/FVHlNEGYA305Mrs5+204sFhTr9
lfEJm9vyPLLXxlthXoOnaCIa6wx6QMXsihK4C75DIj6w2abPX9eAKpCFmfW9mdXO
kwB6oVvzJdK50i0c4jCTBRtzDe4DESYeZ/0COUv1+JI5PeB9YgsvEsIhNtxNFVUM
hW4G3jjGpmgWo1kapY6IiNBpB/JdXp1yvbB3lJd0I0jgllkHpZTyQ1Em4hTF3Me8
4Q3Mi/rvIcuKsg==
=mj/D
-END PGP SIGNATURE-

Re: DebGPT: how LLM can help debian development? demo available.

[Mo Zhou]

I have implemented the OpenAI API frontend, with streaming to terminal
enabled. Just export your OPENAI_API_KEY to environment if you have one,
and specify `-F openai` in the debgpt command line. It work work without
the self-hosted LLM inference backend.

That means the command `debgpt none -i -F openai` falls back to a general
terminal client to ChatGPT. I believe adding this frontend allows more
people to try LLMs with debian-specific tasks conveniently.

Since the openai frontend allows people to use this tool without pytorch
and a bunch of deep learning frameworks, I plan to upload debgpt to
experimental/non-free, following python-openai (unstable/non-free).
Packages in debian archive should be enough to run the openai frontend,
but not for the self-hosted LLM backend.

The following are my replies to previous comments:



On 1/2/24 17:49, Jeremy Stanley wrote:

but one of the most
useful ways I've seen LLM leveraged is large open source projects
feeding in their corpus of complex documentation, and then providing
users with a human language interaction prompt where they can ask
questions and get conversational responses based on that
documentation. A continuously trained LLM backing a sort of "search"
function for all of www.d.o/doc (and maybe also wiki.d.o) could be
cool.

Yes. So the `debgpt policy ...` and `debgpt devref` are two examples on
letting LLM read long documents and answer questions. The problem is that
the full document is too long, while the supported context length is
just 4k ~ 16k tokens for openai api, or 8k tokens for self-hosted mistral7b.

Through merely prompt engineering, of course we cannot feed the whole policy
document to the context. Because solely section 4.9.1 is already overlength
against the typical chatgpt model gpt-3.5-turbo.

That's why the interface is designed to feed a specific section of long
document. That said, with more works, I think it should be possible to
feed the LLM the table of contents first, and let it choose a section it
wants to refer based on your question.



On 1/3/24 02:58, Andrius Merkys wrote:

I find this pretty impressive. Thanks a lot for working on it.

Thanks. I had fun experimenting with this.


To me the most time consuming task in Debian recently is the Python 
transitions. I wonder whether DebGPT could help with them. Maybe there 
are other, non-Debian-specific GPTs for this task, but I would prefer 
a Debian one.

This is in fact not Debian specific. Essentially the current status of this
project is almost a prompt generator, automatically gathering information
about the task you specified in the command line, and send all the 
information
to LLM. It is not different from using the web-based ChatGPT, by copy 
and pasting

the same information before asking the question to LLM.

But if the requirement is relatively loose -- it can be seen as Debian 
specific.
Particularly for ChatGPT, there is a debian-specific system prompt in 
debgpt/frontend.py,

which asks ChatGPT to play the role of a Debian developer when responding.



On 1/3/24 04:33, Andrius Merkys wrote:
Mostly failing tests, and mostly due to API changes between subsequent 
Python 3.x versions.
My idea is to extract the failure from the BTS, and append the "breaking 
changes"
section of the cpython changelog, and see what suggestion the LLM can 
provide.
I do not expect perfect bug fixing suggestions but it should be able to 
conclude

something. The corresponding cli may look like this:

$ debgpt bts --id BUG_NUMBER --pychange 3.11-3.12 free -i   # to be 
implemented


Or possily pull the list of recent github upstream issues list, and let LLM
figure out which upstream bug or pull request is most relevant.

$ debgpt bts --id BUG_NUMBER --upstream_issues free -i  # to be implemented

The upstream issues webpage can be found in the Control/metadata file, 
and the source package
name can be typically found in the bugs page. This automatic process 
should be able to

save people some time.



On 1/3/24 07:06, Andrey Rakhmatullin wrote:

So the solution is either find a patch in the upstream repo (committed or
proposed in issues/PRs) or write one yourself. Not sure what can AI help
here with.
We can ask LLMs to suggest a fix to the bug. Or let LLM to check whether 
the recent upstream
issues list contains a title which might be relevant to the content of 
the debian bug report.


For instance, the LLM can tell `Syntax error: ,   print "hello 
world"` is most relevant
to an upstream pull request named, e.g. `[pull-request] initial python3 
support`, and directly
give you the pull request link. (you may have to retry a couple of times 
to make it think

correctly though).

I made up a test sample about this at:
  examples/e4d7fc9f-7469-4cad-959d-373b89498663-initmsg.txt

Complicated inference tasks are what we hope LLMs can do very well 
eventually.
Grasping the semantics of natural language is something traditional 
software can

never

Re: DebGPT: how LLM can help debian development? demo available.

[Andrey Rakhmatullin]

On Wed, Jan 03, 2024 at 11:33:06AM +0200, Andrius Merkys wrote:
> On 2024-01-03 11:12, Andrey Rakhmatullin wrote:
> > On Wed, Jan 03, 2024 at 09:58:33AM +0200, Andrius Merkys wrote:
> > > To me the most time consuming task in Debian recently is the Python
> > > transitions. I wonder whether DebGPT could help with them. Maybe there are
> > > other, non-Debian-specific GPTs for this task, but I would prefer a Debian
> > > one.
> > As "transitions" is too broad, can you list actual problems you spend time
> > on for them?
> 
> Mostly failing tests, and mostly due to API changes between subsequent
> Python 3.x versions.
So the solution is either find a patch in the upstream repo (committed or
proposed in issues/PRs) or write one yourself. Not sure what can AI help
here with.

Re: DebGPT: how LLM can help debian development? demo available.

[Andrius Merkys]

On 2024-01-03 11:12, Andrey Rakhmatullin wrote:

On Wed, Jan 03, 2024 at 09:58:33AM +0200, Andrius Merkys wrote:

To me the most time consuming task in Debian recently is the Python
transitions. I wonder whether DebGPT could help with them. Maybe there are
other, non-Debian-specific GPTs for this task, but I would prefer a Debian
one.

As "transitions" is too broad, can you list actual problems you spend time
on for them?


Mostly failing tests, and mostly due to API changes between subsequent 
Python 3.x versions.


Best,
Andrius

Re: DebGPT: how LLM can help debian development? demo available.

[Andrey Rakhmatullin]

On Wed, Jan 03, 2024 at 09:58:33AM +0200, Andrius Merkys wrote:
> To me the most time consuming task in Debian recently is the Python
> transitions. I wonder whether DebGPT could help with them. Maybe there are
> other, non-Debian-specific GPTs for this task, but I would prefer a Debian
> one.
As "transitions" is too broad, can you list actual problems you spend time
on for them?

Re: DebGPT: how LLM can help debian development? demo available.

[PICCA Frederic-Emmanuel]

> Installation and setup guide can be found in docs/.

Is it planed to package transformers in Debian instead of using conda/mamba 
venv for this installation ?

* It would be great to help with the Debian patch workflow. 
  - upstream status
  - find upstream bug equivalent to a Debian bug report.
  - prepare bug report for upstream.
  - propose improved patch description.

* doing request on codesearch.net

Cheers

Frederic

Re: DebGPT: how LLM can help debian development? demo available.

[Andrius Merkys]

Hi,

On 2024-01-03 00:07, M. Zhou wrote:

Following what has been discussed in d-project in an offtopic
subthread, I prepared some demo on imagined use cases to
leverage LLMs to help debian development.
https://salsa.debian.org/deeplearning-team/debgpt


I find this pretty impressive. Thanks a lot for working on it.

[...]


You can also tell me more ideas on how we can interact with LLM
for debian-specific tasks. It is generally not difficult to
implement. The difficulty stems from the hardware capacity, and
hence the context length. Thus, the client program has to fetch
the most-relevant information regarding the task.


To me the most time consuming task in Debian recently is the Python 
transitions. I wonder whether DebGPT could help with them. Maybe there 
are other, non-Debian-specific GPTs for this task, but I would prefer a 
Debian one.


Andrius

Re: DebGPT: how LLM can help debian development? demo available.

[Jeremy Stanley]

On 2024-01-02 17:07:57 -0500 (-0500), M. Zhou wrote:
[...]
> You can also tell me more ideas on how we can interact with LLM
> for debian-specific tasks. It is generally not difficult to
> implement. The difficulty stems from the hardware capacity, and
> hence the context length. Thus, the client program has to fetch
> the most-relevant information regarding the task.
[...]

I consider myself an "AI skeptic" (probably due to watching the
Terminator films at an impressionable age), but one of the most
useful ways I've seen LLM leveraged is large open source projects
feeding in their corpus of complex documentation, and then providing
users with a human language interaction prompt where they can ask
questions and get conversational responses based on that
documentation. A continuously trained LLM backing a sort of "search"
function for all of www.d.o/doc (and maybe also wiki.d.o) could be
cool.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

DebGPT: how LLM can help debian development? demo available.

[M. Zhou]

Hi folks,

Following what has been discussed in d-project in an offtopic
subthread, I prepared some demo on imagined use cases to
leverage LLMs to help debian development.
https://salsa.debian.org/deeplearning-team/debgpt

To run the demo, the least requirement is a CUDA GPU with
> 6GB memory. You can run it on CPU of course, but that
will require > 64GB RAM, and it may take > 20 minutes to
give you a reply (I tested this using Xeon Gold 6140).
A longer context will require more memory.

If you cannot run the demo, I also provided a couple of example
sessions. You can use `reply.py` to replay my llm session
to figure out how it works.

Installation and setup guide can be found in docs/.

First start the LLM inference backend:
$ debgpt backend --device cuda --precision 4bit

Then you can launch the frontend to interact with it.
The complete list of potential use cases are listed
in demo.sh . I have recorded my session as an example for
every single command inside.

The following are some selected examples use cases:
(the results are not always perfect. You can ask LLM to retry though)

1. let LLM read policy section 4.9.1 and implement "nocheck"
   support in pytorch/debian/rules

   command: debgpt x -f examples/pytorch/debian/rules --policy 4.9.1 free -i
   replay: python3 replay.py examples/84d5a49c-8436-4970-9955-d14592ef1de1.json

2. let LLM add armhf, and delete kfreebsd-amd64 from archlist
   in pytorch/debian/control

   command: debgpt x -f examples/pytorch/debian/control free -i
   replay: python3 replay.py examples/e98f8167-be4d-4c27-bc49-ac4b5411258f.json

3. I always forget which distribution should I target when
   uploading to stable. Is it bookworm? bookworm-pu? bookworm-updates?
   bookworm-proposed-updates? We let llm read devref section 5.1 and
   let it answer the question

   command: debgpt devref -s 5.5 free -i
   replay: python3 replay.py examples/6bc35248-ffe7-4bc3-93a2-0298cf45dbae.json

4. Let LLM explain the difference among proposals in
   vote/2023/vote_002 .

   command: debgpt vote -s 2023/vote_002 diff
   replay: python3 replay.py examples/bab71c6f-1102-41ed-831b-897c80e3acfb.json

   Note, this might be sensitive. I added a big red warning in the program
   if you ask LLM about vote questions. Do not let LLM affect your vote.

5. Mimic licensecheck. The licensecheck perl implementation is based on regex.
   It has a small knowledge base, and does not work when the text is very noisy.

   command: debgpt file -f debgpt/llm.py licensecheck -i
   replay: python3 replay.py examples/c7e40063-003e-4b04-b481-27943d1ad93f.json

6. My email is too long and you dont want to read it. LLM can summarize it.

   command: debgpt ml -u 
'https://lists.debian.org/debian-project/2023/12/msg00029.html' summary -i
   replay: python3 replay.py examples/95e9759b-1b67-49d4-854a-2dedfff07640.json


7. General chat with llm without any additional information.

   command: debgpt none -i
   replay: python3 replay.py examples/da737d4c-2e93-4962-a685-2a0396d7affb.json

The core idea of all those sub functionalities are the same.
Just gather some task-specific information. And send them
together to the LLM.

I felt the state-of-the-art LLMs are much better than
that in a few months ago. I'll leave it to the community to
evaluate how LLM can help debian development, as well as how
useful it is, and how reliable it is.

You can also tell me more ideas on how we can interact with LLM
for debian-specific tasks. It is generally not difficult to
implement. The difficulty stems from the hardware capacity, and
hence the context length. Thus, the client program has to fetch
the most-relevant information regarding the task.

How do you think?

Re: DEP17 - /usr-merge - what has happened - what will happen - what you can do to help

[Cyril Brulebois]

Simon McVittie  (2023-11-16):
> On Thu, 16 Nov 2023 at 11:27:36 +0100, Helmut Grohne wrote:
> > usr-is-merged now enforces a merged layout in trixie and unstable.
> > If you are faced with failures from debootstrap consider updating
> > your debootstrap from bullseye-updates or bookworm-updates.
> 
> The updated versions were ready before the 12.2/11.8 point releases,
> but unfortunately couldn't be reviewed in time to be included;
> instead, they will be included in Debian 12.3 (2023-12-09) and 11.9
> (early 2024).

You're absolutely correct that packages were ready, and weren't
“reviewed in time”. I think I've already stated a few times I'm more
than aware of my part of responsibility for that.

That being said, being expected to review critical changes for stable
suites, in a component that's also used for every single installation,
within a few days (or be bypassed entirely), after years of being stuck
in place, isn't something that felt even remotely reasonable.


A few weeks ago, the switch was flipped all of a sudden in unstable,
breaking various parts of the Debian infrastructure (e.g. piuparts,
jenkins, etc.), without having debootstrap packages readily available.
Of course, one can add options here and there, but that cost energy,
time, and motivation, to a number of people.


I must point out that while I'm very happy to see progress finally being
made, especially a number of changes that Helmut stages and coordinates
(e.g. https://lists.debian.org/debian-boot/2023/11/msg00056.html).

But I'm not quite so thrilled with the way some other changes are being
pushed in an uncoordinated fashion, even less so when it feels like I
have to spend extra time on mea culpas.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: DEP17 - /usr-merge - what has happened - what will happen - what you can do to help

[Holger Levsen]

hi Helmut,

On Thu, Nov 16, 2023 at 04:35:18PM +0100, Helmut Grohne wrote:
> What I actually meant was the set of packages used by debootstrap, but I
> wrote essential. 

ah!

> In essence, this is "Priority: required". I'm not sure
> about "Priority: important" yet. debootstrap seems to reliably configure
> all required packages before unpacking important packages and that may
> be sufficient to be safe. Rule of thumb: If your package is in the
> "Priority: required" set and has an aliased file, do expect me to send a
> patch.

:)

fwiw, required is also only 27 source packages. and important adds another
27 as well.

btw, this made me aware that we (r-b.o) didn't track that, so thanks
to this thread there's 
https://tests.reproducible-builds.org/debian/unstable/amd64/pkg_set_important.html
now and in future! 

> > a mail or a bug? is there a user tag?
> A d-devel thread Cced to all relevant maintainers.
> https://lists.debian.org/20230912181509.ga2588...@subdivi.de

thanks!

> We're talking about:
>  * base-files
>  * bash
>  * coreutils maybe
>  * dash
>  * libc6
>  * util-linux
 
ok, those are kinda important. ;)

> > many thanks for all your work on this!
> You are welcome.

& many thanks to everyone else involved too!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

20230709: Today was the warmest day on earth in 125,000 years. Today was also
the day with the most planes in the air at one time ever in history. By the time
you read this both of these records have probably been broken.


signature.asc
Description: PGP signature

Re: DEP17 - /usr-merge - what has happened - what will happen - what you can do to help

[Helmut Grohne]

Hi Holger,

On Thu, Nov 16, 2023 at 01:22:05PM +, Holger Levsen wrote:
> feel free to reply in public (incl. quoting me). or reply in private. :)
> (well, or don't reply though that would make me a bit sad. :)

I think your question is relevant to others.

> On Thu, Nov 16, 2023 at 11:27:36AM +0100, Helmut Grohne wrote:
> > I now change focus away from systemd units towards the essential set.
> > This is a tricky affair as it risks breaking bootstrap and the
> > debian-installer. As such, I intend to send patches for affected
> > packages and have started doing so already. There are quite a few more
> > patches to come. 
> 
> I don't understand, the essential set involves 23 source packages,
> why do you expect "quite a few" patches and not a certain amount?
> the next paragraph also seems to suggest you're talking about
> a "bigger essential set" than what I have in mind.

What I actually meant was the set of packages used by debootstrap, but I
wrote essential. In essence, this is "Priority: required". I'm not sure
about "Priority: important" yet. debootstrap seems to reliably configure
all required packages before unpacking important packages and that may
be sufficient to be safe. Rule of thumb: If your package is in the
"Priority: required" set and has an aliased file, do expect me to send a
patch.

> > Within three months we need to reach the point where
> > essential is fully converted with the exception of those packages that
> > cannot be converted without breakage. At that point, I'll coordinate a
> > synchronized NMU of the remaining packages. Affected maintainers have
> > received a mail while ago.
> 
> a mail or a bug? is there a user tag?

A d-devel thread Cced to all relevant maintainers.
https://lists.debian.org/20230912181509.ga2588...@subdivi.de
We're talking about:
 * base-files
 * bash
 * coreutils maybe
 * dash
 * libc6
 * util-linux

> many thanks for all your work on this!

You are welcome.

Helmut

Re: DEP17 - /usr-merge - what has happened - what will happen - what you can do to help

[Simon McVittie]

On Thu, 16 Nov 2023 at 11:27:36 +0100, Helmut Grohne wrote:
> usr-is-merged now enforces a merged layout in trixie and unstable. If
> you are faced with failures from debootstrap consider updating your
> debootstrap from bullseye-updates or bookworm-updates.

I think that should say bookworm-proposed-updates or
bullseye-proposed-updates. The updated versions were ready before the
12.2/11.8 point releases, but unfortunately couldn't be reviewed in time
to be included; instead, they will be included in Debian 12.3 (2023-12-09)
and 11.9 (early 2024).

bookworm-backports also has a suitable version.

(Packages that have been accepted by the release team for the next point
release only go into -proposed-updates. The corresponding -updates suites
are only used if the release team specifically allows a package to be
added to them to fast-track it onto end-user systems, which has not been
done in this case.)

> Please upload restructuring changes to experimental.
...
> This advice is valid for the entire trixie cycle.

This is good advice regardless of the /usr merge or not, and I think
we should generally be testing restructuring in experimental before
uploading it to unstable, even after trixie.

This is doubly true if NEW packages are involved, because uploading those
to unstable means the maintainer no longer has control over whether/when
they start a transition (the ftp team might approve them at any time,
whether it's a convenient time or not), and after they're accepted they
will need a source-only re-upload before migration can happen.

smcv

DEP17 - /usr-merge - what has happened - what will happen - what you can do to help

[Helmut Grohne]

Hello developers,

yeah, I know, this is annoying to many. Still I hope that we can close
this chapter by trixie with your help.

# What has happened?

Since the unstable buildds have been updated to be merged-/usr, the file
move moratorium has been officially delegated to
https://wiki.debian.org/UsrMerge and in that course has been reduced.

The debootstrap uploads to bullseye p-u and bookworm p-u have been
reviewed accepted and will be part of the next stable point release.

usr-is-merged now enforces a merged layout in trixie and unstable. If
you are faced with failures from debootstrap consider updating your
debootstrap from bullseye-updates or bookworm-updates.

dh_movetousr and dh-sequence-movetousr is a thing and can be used to
convert packages.

dh_installsystemd and dh_instalinit now install units to /usr. This
renders 11 packages rc-buggy and patches for all instances have been
filed. On the flip side, more than 500 source packages will complete the
transition in their next upload or binNMU.

While systemd.pc still points the unit directory below /lib, the change
is prepared and patches have been filed for all resulting bugs. The
change is still being deferred, because it would cause 19 rc bugs as of
this writing.

systemd (255) has removed support for the split layout in unstable.

I have sent patches moving shared libraries in essential from /lib to
/usr/lib.

# What will happen next?

I have spent quite some effort on ensuring that most of systemd units
would move with little impact. As a result, I hope that we can resolve
more than half of them using no-change uploads or binNMUs. These will
not be scheduled now, because there is little urgency yet and your
regular uploads will make such binNMUs unnecessary in many cases.

I now change focus away from systemd units towards the essential set.
This is a tricky affair as it risks breaking bootstrap and the
debian-installer. As such, I intend to send patches for affected
packages and have started doing so already. There are quite a few more
patches to come. Within three months we need to reach the point where
essential is fully converted with the exception of those packages that
cannot be converted without breakage. At that point, I'll coordinate a
synchronized NMU of the remaining packages. Affected maintainers have
received a mail while ago. And then we hopefully return to the simpler
pre-/usr-merge bootstrap protocol where packages describe what makes up
Debian. I hope to have this completed by the end of March 2024.

My next focus will be difficult cases. There are two problem categories
that I already know will require non-trivial patches. One is udev rules
in Multi-Arch: same packages and the other is diversions. These probably
all need patches and extensive testing.

What remains is converting the remaining packages and we ideally get
that done by trixie. This is the point where we consider binNMUs for
systemd units. As we progress, we'll also encounter more and more
problems caused by concurrent file move and restructuring (DEP17 P1) and
will get a better understanding of how the approach using Conflicts
impacts upgrades from bookworm to trixie. Possibly, we'll have to
convert some of those Conflicts (DEP17 M7) into protective diversions
(DEP17 M8) in order to unbreak upgrades.

As much as I'd like to say we're done then, there will still be a number
of tasks remaining. The release-notes will likely need an update.
External repositories need help adapting to Debian's changes.
Derivatives will need help setting up their own monitoring. We'll also
notice some broken pieces. For most of us though, problems should fade
away.

# What you can do to help?

Please do apply /usr-merge related patches in a timely manner. I try to
give you time by sending them in a useful order and leaving at least
two weeks before they become urgent.

Please move files from / to /usr yourself.
https://wiki.debian.org/UsrMerge has instructions on whether your
package is eligible and what to do. I will not be able to send patches
for each and every package. Neither from a funding pov nor does my day
have sufficient hours. Getting this done must be a collective effort.

Please upload restructuring changes to experimental. If you rename
binary packages (e.g. adding a "t64" suffix for the 2038 transition) or
move a file from one package to another, please upload to experimental.
This advice is valid for the entire trixie cycle. In doing so, dumat is
enabled to spot /usr-merge related problems in your package and report
them to you rather than you having to check for them. Alternatively,
run[1] dumat locally before upload.

If you want to support this effort beyond your own packages, help is
appreciated with writing patches. Especially the ones for udev rules are
relatively mechanical and just need someone doing them. I'm happy to get
you started and reviewing them. Consider stopping by in
OFTC#debian-usrmerge.


I hope that this all makes sense to you. In ca

Re: What would help the most?

[Jonathan Kamens]

Hello Lucas,

I think the reason why people are puzzled and hesitant to reply is that 
your inquiry seemingly came out of nowhere and you've offered no context 
for it. Why is this question being asked? Why are you the person asking 
it? What are you going to do with the responses?


People are understandably suspicious when someone asks somewhat weird 
questions out of the blue with no explanation for why.


If you want people to answer, I suggest you explain better what's going 
on here.


  jik

On 10/30/23 16:10, Lukasz Szybalski wrote:





Paul, Marc, Andrey
Thanks for replying.


To narrow it down:


This is a serious question and I would like a serious response.

Look back on the last 3 months of work you did @ debian or in salsa or 
bts or lists, and ask yourself.
What would be the minimal thing that would help you accomplish or make 
an even bigger impact at Debian but for you? (the Debian Developer)

What would it be?


Thank you
Lucas Szybalski
from Chicago IL
https://www.linkedin.com/in/lucas-szybalski/


*Vision of Debian:*
Create a free operating system, freely available for everyone.

*Goal:*
Coding and Maintaining Packages <https://www.debian.org/intro/help>
Testing and Bug Squashing <https://www.debian.org/intro/help>

/In these 2 goals:/
What is the minimum most valuable thing that would help YOU
accomplish your goals for Debian ?


Thanks
Lucas

Re: What would help the most?

[Lukasz Szybalski]

Paul, Marc, Andrey
> Thanks for replying.
>
>
> To narrow it down:
>
>
This is a serious question and I would like a serious response.

Look back on the last 3 months of work you did @ debian or in salsa or bts
or lists, and ask yourself.
What would be the minimal thing that would help you accomplish or make an
even bigger impact at Debian but for you? (the Debian Developer)
What would it be?


Thank you
Lucas Szybalski
from Chicago IL
https://www.linkedin.com/in/lucas-szybalski/




> *Vision of Debian:*
> Create a free operating system, freely available for everyone.
>
> *Goal:*
> Coding and Maintaining Packages <https://www.debian.org/intro/help>
> Testing and Bug Squashing <https://www.debian.org/intro/help>
>
> *In these 2 goals:*
> What is the minimum most valuable thing that would help YOU accomplish
> your goals for Debian ?
>
>
> Thanks
> Lucas
>
>
>

Re: What would help the most?

[Andrey Rakhmatullin]

On Mon, Oct 30, 2023 at 02:48:24PM -0500, Lukasz Szybalski wrote:
> It's not an AI guy.
> 
> This is a question of, as a debian developer @debian.org...what do you need
> right now? What would help you?
> 
> Example without giving direction..or inserting things... more cs grads
> working bugs or more debian developers or more automation or ...?
Which of these can you provide?

Re: What would help the most?

[Lukasz Szybalski]

It's not an AI guy.

This is a question of, as a debian developer @debian.org...what do you need
right now? What would help you?

Example without giving direction..or inserting things... more cs grads
working bugs or more debian developers or more automation or ...?

Thanks
Lucas


On Mon, Oct 30, 2023 at 5:20 AM Imre Nagy  wrote:

> Hmm ...
>
> I did not go deep into this situation, but if you would like to traing an
> agent and/or whatever, most likely you need a valid email address to post
> to a list.
> If this is an agent, it is trained to (by the emails before)
> - use/mimic older members address to show credentibility
> - collect and parse repliers name so the email can be personalized.
>
> These lower your guards.
>
> I think all information can be gathered from the mailing-list public
> archive. So if Syzbalski does not pop up and say, "hey guys, I was drunk
> and texted to my ex and debian lists", I am still considering this being a
> AI training.
>
> Best regars,
> Imre
>
> 2023. 10. 30. 8:52 keltezéssel, Tino Didriksen írta:
>
> That was also my initial reaction - so much so that I discarded the
> original email as Spam, because it hit all the factors in my head. But
> given other people took it seriously, I looked into whether
> szybal...@gmail.com has been active before, and sure enough there are
> mails going back more than a decade.
>
> So evidence would say it's not spam, but still a bizarre set of mails.
>
> -- Tino Didriksen
>
>
> On Mon, 30 Oct 2023 at 07:03,  wrote:
>
>> Hi,
>>
>> I have the feeling, that this is some kind of semi-AI generated chat.
>> I think we should stop it now.
>>
>> Imre, Nagy
>> 2023. 10. 30. 2:29 keltezéssel, Lukasz Szybalski írta:
>>
>>
>> On Sat, Oct 28, 2023 at 3:41 AM Paul Wise  wrote:
>>
>>> On Fri, 2023-10-27 at 14:00 -0500, Lukasz Szybalski wrote:
>>>
>>> > What is the minimum most value thing that would
>>> > help YOU accomplish your goals for Debian ?
>>>
>>> Check out this page if no-one gives anything more specific:
>>>
>>> https://www.debian.org/intro/help
>>>
>>>
>> Paul, Marc, Andrey
>> Thanks for replying.
>>
>>
>> To narrow it down:
>>
>> *Vision of Debian:*
>> Create a free operating system, freely available for everyone.
>>
>> *Goal:*
>> Coding and Maintaining Packages <https://www.debian.org/intro/help>
>> Testing and Bug Squashing <https://www.debian.org/intro/help>
>>
>> *In these 2 goals:*
>> What is the minimum most valuable thing that would help YOU accomplish
>> your goals for Debian ?
>>
>>
>> Thanks
>> Lucas
>>
>>

-- 
http://wwwhww.news/u/cwSNkeLNXf <http://lucasmanual.com/blog/>

Re: What would help the most?

[Imre Nagy]

Hmm ...

I did not go deep into this situation, but if you would like to traing 
an agent and/or whatever, most likely you need a valid email address to 
post to a list.

If this is an agent, it is trained to (by the emails before)
- use/mimic older members address to show credentibility
- collect and parse repliers name so the email can be personalized.

These lower your guards.

I think all information can be gathered from the mailing-list public 
archive. So if Syzbalski does not pop up and say, "hey guys, I was drunk 
and texted to my ex and debian lists", I am still considering this being 
a AI training.


Best regars,
Imre

2023. 10. 30. 8:52 keltezéssel, Tino Didriksen írta:
That was also my initial reaction - so much so that I discarded the 
original email as Spam, because it hit all the factors in my head. But 
given other people took it seriously, I looked into whether 
szybal...@gmail.com has been active before, and sure enough there are 
mails going back more than a decade.


So evidence would say it's not spam, but still a bizarre set of mails.

-- Tino Didriksen


On Mon, 30 Oct 2023 at 07:03,  wrote:

Hi,

I have the feeling, that this is some kind of semi-AI generated chat.
I think we should stop it now.

Imre, Nagy

2023. 10. 30. 2:29 keltezéssel, Lukasz Szybalski írta:


On Sat, Oct 28, 2023 at 3:41 AM Paul Wise  wrote:

On Fri, 2023-10-27 at 14:00 -0500, Lukasz Szybalski wrote:

> What is the minimum most value thing that would
    > help YOU accomplish your goals for Debian ?

Check out this page if no-one gives anything more specific:

https://www.debian.org/intro/help


Paul, Marc, Andrey
Thanks for replying.


To narrow it down:

*Vision of Debian:*
Create a free operating system, freely available for everyone.

*Goal:*
Coding and Maintaining Packages <https://www.debian.org/intro/help>
Testing and Bug Squashing <https://www.debian.org/intro/help>

/In these 2 goals:/
What is the minimum most valuable thing that would help YOU
accomplish your goals for Debian ?


Thanks
Lucas

Re: What would help the most?

[Tino Didriksen]

That was also my initial reaction - so much so that I discarded the
original email as Spam, because it hit all the factors in my head. But
given other people took it seriously, I looked into whether
szybal...@gmail.com has been active before, and sure enough there are mails
going back more than a decade.

So evidence would say it's not spam, but still a bizarre set of mails.

-- Tino Didriksen


On Mon, 30 Oct 2023 at 07:03,  wrote:

> Hi,
>
> I have the feeling, that this is some kind of semi-AI generated chat.
> I think we should stop it now.
>
> Imre, Nagy
> 2023. 10. 30. 2:29 keltezéssel, Lukasz Szybalski írta:
>
>
> On Sat, Oct 28, 2023 at 3:41 AM Paul Wise  wrote:
>
>> On Fri, 2023-10-27 at 14:00 -0500, Lukasz Szybalski wrote:
>>
>> > What is the minimum most value thing that would
>> > help YOU accomplish your goals for Debian ?
>>
>> Check out this page if no-one gives anything more specific:
>>
>> https://www.debian.org/intro/help
>>
>>
> Paul, Marc, Andrey
> Thanks for replying.
>
>
> To narrow it down:
>
> *Vision of Debian:*
> Create a free operating system, freely available for everyone.
>
> *Goal:*
> Coding and Maintaining Packages <https://www.debian.org/intro/help>
> Testing and Bug Squashing <https://www.debian.org/intro/help>
>
> *In these 2 goals:*
> What is the minimum most valuable thing that would help YOU accomplish
> your goals for Debian ?
>
>
> Thanks
> Lucas
>
>

Re: What would help the most?

[Andrey Rakhmatullin]

On Mon, Oct 30, 2023 at 07:03:38AM +0100, deb...@hyperborg.com wrote:
> Hi,
> 
> I have the feeling, that this is some kind of semi-AI generated chat.
> I think we should stop it now.
Makes sense.

Re: What would help the most?

[debian]

Hi,

I have the feeling, that this is some kind of semi-AI generated chat.
I think we should stop it now.

Imre, Nagy

2023. 10. 30. 2:29 keltezéssel, Lukasz Szybalski írta:


On Sat, Oct 28, 2023 at 3:41 AM Paul Wise  wrote:

On Fri, 2023-10-27 at 14:00 -0500, Lukasz Szybalski wrote:

> What is the minimum most value thing that would
    > help YOU accomplish your goals for Debian ?

Check out this page if no-one gives anything more specific:

https://www.debian.org/intro/help


Paul, Marc, Andrey
Thanks for replying.


To narrow it down:

*Vision of Debian:*
Create a free operating system, freely available for everyone.

*Goal:*
Coding and Maintaining Packages <https://www.debian.org/intro/help>
Testing and Bug Squashing <https://www.debian.org/intro/help>

/In these 2 goals:/
What is the minimum most valuable thing that would help YOU accomplish 
your goals for Debian ?



Thanks
Lucas

Re: What would help the most?

[Lukasz Szybalski]

On Sat, Oct 28, 2023 at 3:41 AM Paul Wise  wrote:

> On Fri, 2023-10-27 at 14:00 -0500, Lukasz Szybalski wrote:
>
> > What is the minimum most value thing that would
> > help YOU accomplish your goals for Debian ?
>
> Check out this page if no-one gives anything more specific:
>
> https://www.debian.org/intro/help
>
>
Paul, Marc, Andrey
Thanks for replying.


To narrow it down:

*Vision of Debian:*
Create a free operating system, freely available for everyone.

*Goal:*
Coding and Maintaining Packages <https://www.debian.org/intro/help>
Testing and Bug Squashing <https://www.debian.org/intro/help>

*In these 2 goals:*
What is the minimum most valuable thing that would help YOU accomplish your
goals for Debian ?


Thanks
Lucas

Re: What would help the most?

[Marc Haber]

On Fri, 27 Oct 2023 14:00:45 -0500, Lukasz Szybalski
 wrote:
>What is the minimum most value thing that would help YOU accomplish your
>goals for Debian ?

I do not quite understand the question, so my answer might be a bit
off.

I'd like to have conffile management improved. Debian is already
better than other distributions in this regard, but I'd still have a
few additional features. For example having some kind of interactive
merge function that could be invoked during package installation
instead of the "do you want their conffile, your conffile, an editor
or a shell" prompt.

I'd like to have better tooling for conffile handling in maintainer
scripts, some convergence of dpkg and ucf, possibly a more declarative
approach or more boilerplate code that is easier to debug.

And I'd like Debian packages to make consequent use of this mechanism
which is one that makes Debian special.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: What would help the most?

[Paul Wise]

On Fri, 2023-10-27 at 14:00 -0500, Lukasz Szybalski wrote:

> What is the minimum most value thing that would
> help YOU accomplish your goals for Debian ?

Check out this page if no-one gives anything more specific:

https://www.debian.org/intro/help

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: What would help the most?

[Andrey Rakhmatullin]

On Fri, Oct 27, 2023 at 02:00:45PM -0500, Lukasz Szybalski wrote:
> Hello
> I wanted to understand better from people with y...@debian.org email address
> on:
> 
> Vision of Debian:
> Create a free operating system, freely available for everyone.
> 
> Goal:
> Helping customers achieve outcome.
Sorry, I don't get this part.

> What is the minimum most value thing that would help YOU accomplish your
> goals for Debian ?
What's the context for your survey?

What would help the most?

[Lukasz Szybalski]

Hello
I wanted to understand better from people with y...@debian.org email address
on:

Vision of Debian:
Create a free operating system, freely available for everyone.

Goal:
Helping customers achieve outcome.

What is the minimum most value thing that would help YOU accomplish your
goals for Debian ?

Thanks
Lucas Szybalski

Re: /usr-merge and DEP17 update: what happens next and how you can help

[Simon Richter]

Hi,

On 10/10/23 03:16, Helmut Grohne wrote:


For one thing, dh_installsystemd generates maintainer scripts for
restarting services. Before version 13.11.6, it did not recognize the
/usr location. If you were to backport such a package, bookworm's
debhelper would not generate the relevant maintainer scripts. You can
mitigate this by issuing "Build-Depends: debhelper (>= 13.11.6~)". Thus,
you'll be using a backported debhelper (unless the backporter carelessly
deletes this dependency).


If that would be the only reason to require a backported debhelper, then 
it would probably be better to make the file move conditional on the 
target distribution (from "dpkg-parsechangelog -S distribution") -- the 
intention of that is immediately readable, while a versioned build 
dependency needs to be explained or a backporter might want to 
carelessly delete it.


gcc does something similar, although that uses "lsb_release -cs", which 
is technically not entirely correct since it looks at the build system, 
not the current package, but for the purpose of backports is good enough 
and avoids corner cases like "stable-proposed-updates" not matching 
"bookworm" or "bookworm-backports".


   Simon

Re: /usr-merge and DEP17 update: what happens next and how you can help

[Andrea Bolognani]

On Mon, Oct 09, 2023 at 08:16:32PM +0200, Helmut Grohne wrote:
> On Mon, Oct 09, 2023 at 02:10:27PM +0200, Andrea Bolognani wrote:
> > Am I missing something?
> 
> Yes, you are and what you are missing really is not obvious, so thanks
> for asking!
> 
> For one thing, dh_installsystemd generates maintainer scripts for
> restarting services. Before version 13.11.6, it did not recognize the
> /usr location. If you were to backport such a package, bookworm's
> debhelper would not generate the relevant maintainer scripts. You can
> mitigate this by issuing "Build-Depends: debhelper (>= 13.11.6~)". Thus,
> you'll be using a backported debhelper (unless the backporter carelessly
> deletes this dependency).

You mentioned this constraint in your original email, so while I
didn't mention it explicitly I was planning on adding the necessary
Build-Depends. I was also assuming that a good enough version of
debhelper would be backported to bookworm.

> For another, we have this generic file loss problem (DEP17 P1). If - in
> addition to moving units to /usr - you also restructure your package
> between bookworm and trixie (move units between binary packages), then
> an upgrade scenario may delete those files even in the presence of
> correct Breaks+Replaces. As long as you are sure that you do not rename
> any binary packages nor move any units between packages from bookworm to
> trixie, this won't apply. Such renames or moves are hard to predict
> though.

I'm actually hoping that I will be able to get around to a pretty big
refactoring of the libvirt package before trixie, so this is kind of
a deal breaker for me :)

> So if you understand these limitations and are prepared to handle them
> for backports, cleaning things up now is fine. If you are not, deferring
> that cleanup until after trixie and using dh_movetousr in the interim,
> may be the simpler option.

Yup, given the situation dh_movetousr definitely feels like the way
to go.

Thank you for taking the time to explain the situation and, once
again, for all your tireless work in this area :)

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Re: /usr-merge and DEP17 update: what happens next and how you can help

[Helmut Grohne]

Hi Andrea,

On Mon, Oct 09, 2023 at 02:10:27PM +0200, Andrea Bolognani wrote:
> For libvirt, the upstream build system actually installs systemd
> units under /usr/lib, and we move things around in debian/rules so
> that they end up under /lib in the Debian package:
> 
>   SRV_MONOLITHIC = libvirt-guests virtlogd virtlockd \
>libvirtd libvirtd-tcp libvirtd-tls virt-guest-shutdown
> 
>   set -e; for f in $(SRV_MONOLITHIC); do \
>   dh_install -p libvirt-daemon-system \
>  usr/lib/systemd/system/$${f}* \
>  lib/systemd/system/; \
>   done
> 
> I wouldn't be surprised if other packages did something similar.

This definitely is more common, yes.

> In this case, instead of throwing dh_movetousr into the mix, wouldn't
> it be more sensible to drop the rename part and just follow the
> upstream build system?

In the long run, I definitely agree. In the short term, there are
downsides.

> I guess this could theoretically be problematic for backports, as the
> dh_movetousr approach would guarantee that units still end up in /lib
> on bookworm and older but this wouldn't. On the other hand, hasn't
> systemd been able to load units both from /lib and /usr/lib for
> several releases now? So I would expect that to work somewhat
> transparently.

This is correct. systemd handles both locations since very long. 

> Am I missing something? I have to admit that, while I've tried to
> keep tabs on the discussion and all the great work you and other have
> been doing to push things forward, I never quite managed to fully
> absorb the problem space.

Yes, you are and what you are missing really is not obvious, so thanks
for asking!

For one thing, dh_installsystemd generates maintainer scripts for
restarting services. Before version 13.11.6, it did not recognize the
/usr location. If you were to backport such a package, bookworm's
debhelper would not generate the relevant maintainer scripts. You can
mitigate this by issuing "Build-Depends: debhelper (>= 13.11.6~)". Thus,
you'll be using a backported debhelper (unless the backporter carelessly
deletes this dependency).

For another, we have this generic file loss problem (DEP17 P1). If - in
addition to moving units to /usr - you also restructure your package
between bookworm and trixie (move units between binary packages), then
an upgrade scenario may delete those files even in the presence of
correct Breaks+Replaces. As long as you are sure that you do not rename
any binary packages nor move any units between packages from bookworm to
trixie, this won't apply. Such renames or moves are hard to predict
though.

So if you understand these limitations and are prepared to handle them
for backports, cleaning things up now is fine. If you are not, deferring
that cleanup until after trixie and using dh_movetousr in the interim,
may be the simpler option.

Helmut

Re: /usr-merge and DEP17 update: what happens next and how you can help

[Sven Joachim]

On 2023-10-09 14:10 +0200, Andrea Bolognani wrote:

> For libvirt, the upstream build system actually installs systemd
> units under /usr/lib, and we move things around in debian/rules so
> that they end up under /lib in the Debian package:
>
>   SRV_MONOLITHIC = libvirt-guests virtlogd virtlockd \
>libvirtd libvirtd-tcp libvirtd-tls virt-guest-shutdown
>
>   set -e; for f in $(SRV_MONOLITHIC); do \
>   dh_install -p libvirt-daemon-system \
>  usr/lib/systemd/system/$${f}* \
>  lib/systemd/system/; \
>   done
>
> I wouldn't be surprised if other packages did something similar.
>
> In this case, instead of throwing dh_movetousr into the mix, wouldn't
> it be more sensible to drop the rename part and just follow the
> upstream build system?

Makes sense to me, but there is one caveat.

> I guess this could theoretically be problematic for backports, as the
> dh_movetousr approach would guarantee that units still end up in /lib
> on bookworm and older but this wouldn't. On the other hand, hasn't
> systemd been able to load units both from /lib and /usr/lib for
> several releases now? So I would expect that to work somewhat
> transparently.

While systemd has supported units both under /lib/systemd/system and
/usr/lib/systemd/system for years, dh_installsystemd has only gained
support for the latter in the latest debhelper upload.

So if you install systemd units there, adding a build-dependency on
debhelper (>= 13.11.6~) is probably advisable, lest backports run into
#1041159[1].

Cheers,
   Sven


1. https://bugs.debian.org/1041159

Re: /usr-merge and DEP17 update: what happens next and how you can help

[Andrea Bolognani]

On Sun, Oct 08, 2023 at 10:25:44PM +0200, Helmut Grohne wrote:
>  * For many other cases, I propose leaving the upstream install layout
>as is and performing the conversion using a new debhelper component
>that will be called dh_movetousr
> 
[...]
> 
>  * movetousr.ddlist lists packages that probably need to run
>dh_movetousr for some reason:
> + There are other files than systemd units shipped in aliased
>   locations.
> + debian/*.install places units to /lib. In this case, consider
>   installing units by placing them to debian/*.service if possible
>   to benefit from the automatic conversion.
> + An upstream build system hard codes the systemd unit location to
>   /lib.
> + ...
> 
[...]
> 
> Debian Libvirt Maintainers 
>libvirt

For libvirt, the upstream build system actually installs systemd
units under /usr/lib, and we move things around in debian/rules so
that they end up under /lib in the Debian package:

  SRV_MONOLITHIC = libvirt-guests virtlogd virtlockd \
   libvirtd libvirtd-tcp libvirtd-tls virt-guest-shutdown

  set -e; for f in $(SRV_MONOLITHIC); do \
  dh_install -p libvirt-daemon-system \
 usr/lib/systemd/system/$${f}* \
 lib/systemd/system/; \
  done

I wouldn't be surprised if other packages did something similar.

In this case, instead of throwing dh_movetousr into the mix, wouldn't
it be more sensible to drop the rename part and just follow the
upstream build system?

I guess this could theoretically be problematic for backports, as the
dh_movetousr approach would guarantee that units still end up in /lib
on bookworm and older but this wouldn't. On the other hand, hasn't
systemd been able to load units both from /lib and /usr/lib for
several releases now? So I would expect that to work somewhat
transparently.

Am I missing something? I have to admit that, while I've tried to
keep tabs on the discussion and all the great work you and other have
been doing to push things forward, I never quite managed to fully
absorb the problem space.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

/usr-merge and DEP17 update: what happens next and how you can help

[Helmut Grohne]

 in the
essential set that we can move without breaking unmerged debootstrap.
Then I'll proceed with the remaining bootstrap mass upload as detailed
in https://lists.debian.org/20230912181509.ga2588...@subdivi.de. The
rest hopefully is adding dh_movetousr/dh-sequence-movetousr to lots of
packages with your help and monitoring/mitigating the fallout until we
release trixie with no aliasing. That's the theory at least.

I hope this all makes sense. In case it does not, please speak up. In
terms of more detailed reviews, I'd be very happy to have more eyeballs
on this and those debhelper MRs in particular.

Helmut
Adam Cecile 
   librtsp-server-perl (U)

Adam Conrad 
   cyrus-sasl2 (U)

Adam Majer 
   isc-kea (U)

Adrian Vondendriesch 
   pacemaker (U)
   pgbackrest (U)
   pgpool2 (U)
   tmate-ssh-server

Agathe Porte 
   opentracker

Aide Maintainers 
   aide

Aigars Mahinovs 
   dlt-daemon

Alberto Bertogli 
   kxd (U)

Alberto Leiva Popper 
   jool (U)

Alejandro Garrido Mota 
   direvent

Alex David 
   nebula (U)

Alexander GQ Gerasiov 
   minidlna

Alexander Sosna 
   csync2 (U)

Alexander Wirt 
   amavisd-new (U)
   conntrack-tools (U)
   ferm
   icinga2 (U)
   nsca (U)
   nsca-ng (U)

Alexandre Detiste 
   game-data-packager (U)

Alexandre Mestiashvili 
   hd-idle

Alexandre Rossi 
   davmail

Alexandre Viau 
   influxdb (U)

Alexandru Mihail 
   mini-httpd

Amin Bandali 
   opendht

Ana Custura 
   ampr-ripd (U)
   vanguards (U)

Andreas B. Mundt 
   atftp (U)

Andreas Bombe 
   soapyremote (U)

Andreas Henriksson 
   garagemq (U)
   mender-client (U)
   mender-connect (U)

Andreas Hoenen 
   apt-show-versions (U)

Andreas Metzler 
   exim4 (U)

Andreas Tille 
   orthanc (U)

Andrej Shadura 
   borgmatic (U)
   matrix-synapse (U)
   twms

Andrew Lee (李健秋) 
   lxdm (U)

Andrew Ruthven 
   request-tracker5 (U)

Andrii Senkovych 
   webdis

Andrius Merkys 
   epics-base (U)

Andriy Grytsenko 
   lxdm (U)

Andy Grover 
   python-rtslib-fb (U)

Anthony Fok 
   etcd (U)

Anthony Prades 
   cyrus-imapd (U)

Anton Gladky 
   h2o (U)

Antonin Kral 
   pimd

Antonio Radici 
   postgrey (U)

Apollon Oikonomopoulos 
   beanstalkd (U)
   h2o
   pimd (U)
   puppetdb (U)
   redsocks
   tgt

Arnaud Ferraris 
   calamares-settings-mobian (U)
   make-dynpart-mappings (U)

Arnaud Ferraris 
   umtp-responder (U)

Arnaud Rebillout 
   docker-registry (U)

Arno Töll 
   apache2 (U)

Aron Xu 
   trafficserver (U)

Arturo Borrero Gonzalez 
   conntrack-tools (U)
   nftables (U)
   nftlb

Artyom A Anikeev 
   clsync

Aurélien COUDERC 
   sddm (U)

Axel Beckert 
   gpm
   wdm

Baptiste Beauplat 
   chkboot
   monitorix

Barak A. Pearlmutter 
   clsync (U)
   ddccontrol

Bas Couwenberg 
   nagios-nrpe (U)

Bastian Germann 
   cyrus-sasl2 (U)
   swupdate

Benjamin Hof 
   postfix-mta-sts-resolver

Benjamin Schlüter 
   e2guardian (U)

Bernd Schumacher 
   bootcd

Bernd Zeimetz 
   collectd (U)

Bernhard Schmidt 
   bind9 (U)
   conserver (U)
   freeradius (U)
   isatapd

Bill Allombert 
   consolation

Bill MacAllister 
   kafs-client

Birger Schacht 
   errbot (U)
   usbguard

Bjorn Dolk 
   sia (U)

Bo YU 
   pyro5 (U)

Brian May 
   amavisd-new

Brian T. Smith 
   opa-fm (U)

Bruno Kleinert 
   syncplay

Calogero Lo Leggio 
   burp

ChangZhuo Chen (陳昌倬) 
   lxdm (U)

Chow Loong Jin 
   logiops

Chris Boot 
   shairport-sync
   ulogd2 (U)

Chris Lamb 
   zoneminder (U)

Christian Ehrhardt 
   openvswitch (U)

Christian Göttsche 
   vnstat

Christian Marillat 
   qbittorrent

Christoph Berg 
   omnidb (U)
   pgbouncer (U)
   pgpool2 (U)
   powa-collector (U)
   prometheus-sql-exporter (U)
   snmptt
   tmate-ssh-server (U)

Christoph Biedl 
   ngircd
   pptpd
   schroot

Christoph Martin 
   apt-show-versions
   burp (U)

ClamAV Team 
   clamsmtp

Clément Hermann 
   onedrive (U)

Colin Watson 
   man-db

Collectd Packaging Team 
   collectd

Conserver Maintainers 
   conserver

Craig Small 
   net-snmp

Damyan Ivanov 
   kgb-bot (U)

Daniel Baumann 
   gnunet
   netdata
   ttyd

Daniel Echeverri 
   glances

Daniel Kahn Gillmor 
   getdns (U)
   knot (U)
   nsd (U)
   wireguard

Daniel Salzman 
   knot (U)

Daniel Swarbrick 
   prometheus-alertmanager (U)
   prometheus-node-exporter-collectors (U)

dann frazier 
   flamethrower

David Banks 
   game-data-packager (U)

David Kunz 
   icingaweb2-module-director

David Steele 
   comitup

Debian Accessibility Team 
   espeakup

Debian Apache Maintainers 
   apache2

Debian Astronomy Team 
   gavodachs

Debian Borg Collective 
   borgmatic

Debian CommunityWLAN Team 
   batmand
   fastd

Debian Cyrus Team 
   cyrus-imapd
   cyrus-sasl2

Debian DNS Team 
   bind9

Debian Edu Developers 
   debian-edu-config
   sitesummary

Debian Edu Packaging Team 
   autofs (U)
   e2guardian

Debian Erlang Packagers 
   erlang
   yaws

Debian freedesktop.org maintainers 

   power-profiles-daemon

Debian FreeIPA Team 
   custodia

Debian FreeIPA Team 
   freeipa-healthcheck

Debian FreeRADIUS Packaging

how-can-i-help by default [Re: lpr/lpd]

[Simon Richter]

Hi,

On 9/25/23 14:08, Paul Wise wrote:


The problem with that approach is that the help needed information
changes independently to packages, so the information will get very out
of date in between point releases, which is why how-can-i-help does
online checks. If desired, it would be easy to have an apt update hook
that would download the data from UDD so that how-can-i-help can work
offline when the network is available.


Yes, that's why I thought of using indices/ -- there are already 
Maintainers and Uploaders files in there that I'd expect are also meant 
to change independently from Packages. The indices/ directory seems to 
be available on most if not all mirrors as well, so putting it there 
would not put unnecessary strain on UDD.


My proposal is to display the list of RFA/O packages installed on the 
system by default as part of the after-installation summary, because we 
currently have no way of reaching users of at-risk packages before the 
package is removed, and I would like to change that.


   Simon

Bug#1052202: ITP: tree-sitter-vimdoc -- Vim help file parser for tree-sitter

[James McCoy]

Package: wnpp
Severity: wishlist
Owner: James McCoy 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: tree-sitter-vimdoc
  Version : 2.0.0
  Upstream Contact: Thomas Vigouroux 
* URL : https://github.com/neovim/tree-sitter-vimdoc/
* License : Apache 2.0
  Programming Lang: JavaScript, C, Rust
  Description : Vim help file parser for tree-sitter

This package provides a tree-sitter parser for Vim's help files.

This is needed for Neovim's tests and is one of the tree-sitter parsers
expected to be available.  It will be maintained in the tree-sitter
team.

Accepted click-help-colors 0.9.2-1 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 08 Sep 2023 19:30:58 +0200
Source: click-help-colors
Architecture: source
Version: 0.9.2-1
Distribution: sid
Urgency: medium
Maintainer: Sakirnth Nagarasa 
Changed-By: Sakirnth Nagarasa 
Changes:
 click-help-colors (0.9.2-1) sid; urgency=medium
 .
   * Uploading to sid.
   * Merging upstream version 0.9.2.
Checksums-Sha1:
 6f03440d319ace369d40c230418c530a6782970f 1386 click-help-colors_0.9.2-1.dsc
 b3d40cb5fdb8c4ec0f3d210555c8eb9f0062165e 128132 
click-help-colors_0.9.2.orig.tar.xz
 b4f1c4141244c4a0f4513e5a26d6d0425eca7538 1768 
click-help-colors_0.9.2-1.debian.tar.xz
 3157d67478f971a6bcfb6a14c78f5527d7fc8103 5952 
click-help-colors_0.9.2-1_amd64.buildinfo
Checksums-Sha256:
 bdbb916c9f31b206efb2ccff209ee0e8ec1b8d6204268ab79ce11a92aac8d680 1386 
click-help-colors_0.9.2-1.dsc
 41de0803c474cbd32e54cc3df1698e9d0565a703a4b081935de34ac75f9d3364 128132 
click-help-colors_0.9.2.orig.tar.xz
 5be595d84a11bb52411d043fbc8e4ccda9007ed40934551a8a1ebd472b6bada6 1768 
click-help-colors_0.9.2-1.debian.tar.xz
 214afe27abd0aaf65bca191cd4d1bf9989eb36046672701edcc261d4fa548c32 5952 
click-help-colors_0.9.2-1_amd64.buildinfo
Files:
 04a2a76551e46e26f6b4cd6ba51c0fc5 1386 python optional 
click-help-colors_0.9.2-1.dsc
 2beed1bd648e90ca8638b0a3ced57b4d 128132 python optional 
click-help-colors_0.9.2.orig.tar.xz
 7f4b3774e74892ac5ceb5c83e6204e97 1768 python optional 
click-help-colors_0.9.2-1.debian.tar.xz
 84fa57c636ff5d05cc03306f8e45f0ac 5952 python optional 
click-help-colors_0.9.2-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQSQD23K0grRgZ+eimrWSi+uCV73mQUCZP2qSwAKCRDWSi+uCV73
maDAAQCggHO80E84Q4PvV522YkDPl8anoJZfQK4kY/TbU7885QD8DGOdTi5kTZks
lnotCH8AC8+ysCS7QrO44cZDbuW9ggo=
=vttI
-END PGP SIGNATURE-

Re: Help with the nftables package: the embedded python module

[Arturo Borrero Gonzalez]

On Sun, Jul 30, 2023, 21:39 Jeremy Sowden  wrote:

> On 2023-07-28, at 18:59:45 +0200, Timo Röhling wrote:
> > * Arturo Borrero Gonzalez  [2023-07-28 18:38]:
> > > I would appreciate additional suggestions and hints. Patches welcome.
> >
> > If you have bad interactions between the Python and non-Python parts
> > of your package, you can try and build them independently, i.e.,
> >
> > override_dh_auto_build:
> > dh_auto_build --package=python3-nftables --sourcedirectory=py
> --buildsystem=pybuild
> >   dh_auto_build --remaining-packages
> >
> > and similar for the other dh_auto_* commands. I did something like
> > that for tinyobjloader and it worked quite nicely.
>
> Thanks for the pointer, Timo.  This does seem to do the trick.
>
> Arturo, I'll push the changes to Salsa.
>
> J.
>

Thanks, Timo and Jeremy.

>

Re: Help with the nftables package: the embedded python module

[Jeremy Sowden]

On 2023-07-28, at 18:59:45 +0200, Timo Röhling wrote:
> * Arturo Borrero Gonzalez  [2023-07-28 18:38]:
> > I would appreciate additional suggestions and hints. Patches welcome.
>
> If you have bad interactions between the Python and non-Python parts
> of your package, you can try and build them independently, i.e.,
> 
> override_dh_auto_build:
> dh_auto_build --package=python3-nftables --sourcedirectory=py 
> --buildsystem=pybuild
>   dh_auto_build --remaining-packages
> 
> and similar for the other dh_auto_* commands. I did something like
> that for tinyobjloader and it worked quite nicely.

Thanks for the pointer, Timo.  This does seem to do the trick.

Arturo, I'll push the changes to Salsa.

J.


signature.asc
Description: PGP signature

Re: Help with the nftables package: the embedded python module

[Timo Röhling]

Hi,

* Arturo Borrero Gonzalez  [2023-07-28 18:38]:

I would appreciate additional suggestions and hints. Patches welcome.

If you have bad interactions between the Python and non-Python parts
of your package, you can try and build them independently, i.e.,

override_dh_auto_build:
dh_auto_build --package=python3-nftables --sourcedirectory=py 
--buildsystem=pybuild
dh_auto_build --remaining-packages

and similar for the other dh_auto_* commands. I did something like
that for tinyobjloader and it worked quite nicely.


Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Help with the nftables package: the embedded python module

[Arturo Borrero Gonzalez]

Hi there,

the nftables source package contains a python module (the python binding for 
libnftables).


Source code: https://salsa.debian.org/pkg-netfilter-team/pkg-nftables

Recently, and because python & setuptools deprecation issues, the python side of 
package that has been working for ages, is now broken.


nftables upstream  has removed integration with autotools [1] (suggested by me), 
so we distro developers (me) should find the best way to install the package 
(autotools wont do it anymore), which apparently is the python way [0] WTH.


I have tested a number of approaches to replace the old simple method, while 
producing the exact same content in the resulting debian binary package:


/usr/lib/python3/dist-packages/nftables/__init__.py
/usr/lib/python3/dist-packages/nftables/nftables.py
/usr/lib/python3/dist-packages/nftables/schema.json
/usr/lib/python3/dist-packages/nftables-0.1-py3.11.egg-info

The approaches I tried include:
 * using pybuild, which is regarded pretty much everywhere as a magic thing, 
but gets confused with the --with options passed to the autotools ./configure.sh 
script via dh_auto_configure in d/rules


 * running `python3 -m build` in d/rules to generate the PKG-INFO file to later 
move it via dh_install to nftables-0.1-py3.11.egg-info. This is not elegant 
because the embedded version in the file path.


* pip install: one of the referenced methods to handle python's setuptools 
deprecation  [0]is to use pip. But I'm reluctant to run pip (also, couldn't get 
it to produce the same content for the deb file)


I would appreciate additional suggestions and hints. Patches welcome.

regards.

PS: I'm on vacations, so I may be slow to respond to this email.


[0] See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html

 << move away from a model where there is one, single authoritative way to do 
things and towards fostering an environment that allows people to develop 
different tools that work for their workflow. Thanks to all the standards work 
that's gone on, there has been a profusion of new packaging projects arising, 
and you should look to see which ones fit your needs.>>


[1] 
https://salsa.debian.org/pkg-netfilter-team/pkg-nftables/-/blob/master/debian/patches/0001-py.patch

Accepted gimp-help 2.10.34-2 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 03 May 2023 11:00:29 +0200
Source: gimp-help
Architecture: source
Version: 2.10.34-2
Distribution: unstable
Urgency: medium
Maintainer: Debian GNOME Maintainers 

Changed-By: Jordi Mallach 
Changes:
 gimp-help (2.10.34-2) unstable; urgency=medium
 .
   * Upload to unstable, targetting transition to bookworm.
Checksums-Sha1:
 2862e10b725955334b24aa0039587ac57a758465 3621 gimp-help_2.10.34-2.dsc
 e0649a3bb71e73db4feaee8643f8e2bc9194bed1 11556 
gimp-help_2.10.34-2.debian.tar.xz
 9a0419131bb23c4dda9714145828d1bf701f8ad2 14451 
gimp-help_2.10.34-2_amd64.buildinfo
Checksums-Sha256:
 1f691edcce7922e55d72a1c16337b0d624725855c42db3aae9596ab55818bf7e 3621 
gimp-help_2.10.34-2.dsc
 5c5a0c3e77ed2c443e428dc6a9f5601a10e92b401301dc16296de97062d06932 11556 
gimp-help_2.10.34-2.debian.tar.xz
 e76ff89f07a19ad5f28badd35c4f4ea45c427c22b57e41692e397c738de9d976 14451 
gimp-help_2.10.34-2_amd64.buildinfo
Files:
 c93a0280c8148cb26a42dda5f526c76d 3621 doc optional gimp-help_2.10.34-2.dsc
 3de6ac00b6aab30305ea93bcb5683c53 11556 doc optional 
gimp-help_2.10.34-2.debian.tar.xz
 04affe71db2538790bbd5ae86dac7cd9 14451 doc optional 
gimp-help_2.10.34-2_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE6BdUhsApKYN8KGoWJVAvb8vjywQFAmRZcPsACgkQJVAvb8vj
ywT0NxAApukMtFAeCu8tm1hf2GnRH8YaQX74cJqXGAri77UslvXzKcNDgfWsPYUI
YUNXxaWQXboyaZYQqEON9+WSL4FiY+1elohDU4kfDsXfueyS4zuFVR5bRMXjLVor
Pw1GMsW4x6KwdVhKPchL7ownI9wRa47aGNPfSwgxUrnCCit8/fNsKUJZDqMXow8t
xmOSf6eSsN2XPDyBx3wIo3AZPxv/cGZMaQjzzrgRiIN8xFphBV20xBi/VK8qBG6b
JIJHSz1Nb7kOfDlRY935VDTWjIExxXPZK7UKU2B3XUfaJObnlN/H4bMI+05H1S2h
qPALQI29jDIZHmMGW2eVi7PxHa6T93ZTBCOcS5EGo7C3xhsPN/7ckPiXXFNNF37c
m322f141cVk8utQwsEvmxd52f7UGtBu8hFxCvhLeV2YBPJN1BwAyYpPLF5wVV1xc
UQqXJvZvPk+JjVi0mL6LngU/jWqrLVQb5Xj1X06gdUKmDgzfCtzTgcdWu2ZRz8Dw
MpvcRHbmxGBSOmHKXy/6ua+Q4fayGONxt4nDgEn+YhdlNabl1vTKOIuExABVdk57
11ZS4GlfXYH8XKNysrRLGxG3epmi1C1j82vIaP6mUgbfX1srcok8+3CMD6Vn8HV7
3Ks2qRJiBOJb9xtI13SPPT8htqxCe1znQu5Kl1tZ1zx+DJcyLBU=
=/Ova
-END PGP SIGNATURE-

Accepted gimp-help 2.10.34-1 (source all) into experimental

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 01 May 2023 01:53:14 +0200
Source: gimp-help
Binary: gimp-help-ca gimp-help-common gimp-help-cs gimp-help-da gimp-help-de 
gimp-help-el gimp-help-en gimp-help-en-gb gimp-help-es gimp-help-fa 
gimp-help-fi gimp-help-fr gimp-help-hr gimp-help-hu gimp-help-it gimp-help-ja 
gimp-help-ko gimp-help-lt gimp-help-nl gimp-help-nn gimp-help-pt 
gimp-help-pt-br gimp-help-ro gimp-help-ru gimp-help-sl gimp-help-sv 
gimp-help-uk gimp-help-zh-cn
Architecture: source all
Version: 2.10.34-1
Distribution: experimental
Urgency: medium
Maintainer: Debian GNOME Maintainers 

Changed-By: Jordi Mallach 
Description:
 gimp-help-ca - Documentation for the GIMP (Catalan)
 gimp-help-common - Data files for the GIMP documentation
 gimp-help-cs - Documentation for the GIMP (Czech)
 gimp-help-da - Documentation for the GIMP (Danish)
 gimp-help-de - Documentation for the GIMP (German)
 gimp-help-el - Documentation for the GIMP (Greek)
 gimp-help-en - Documentation for the GIMP (English)
 gimp-help-en-gb - Documentation for the GIMP (British English)
 gimp-help-es - Documentation for the GIMP (Spanish)
 gimp-help-fa - Documentation for the GIMP (Farsi)
 gimp-help-fi - Documentation for the GIMP (Finnish)
 gimp-help-fr - Documentation for the GIMP (French)
 gimp-help-hr - Documentation for the GIMP (Croatian)
 gimp-help-hu - Documentation for the GIMP (Hungarian)
 gimp-help-it - Documentation for the GIMP (Italian)
 gimp-help-ja - Documentation for the GIMP (Japanese)
 gimp-help-ko - Documentation for the GIMP (Korean)
 gimp-help-lt - Documentation for the GIMP (Lithuanian)
 gimp-help-nl - Documentation for the GIMP (Dutch)
 gimp-help-nn - Documentation for the GIMP (Norwegian)
 gimp-help-pt - Documentation for the GIMP (Portuguese)
 gimp-help-pt-br - Documentation for the GIMP (Brazilian Portuguese)
 gimp-help-ro - Documentation for the GIMP (Romanian)
 gimp-help-ru - Documentation for the GIMP (Russian)
 gimp-help-sl - Documentation for the GIMP (Slovenian)
 gimp-help-sv - Documentation for the GIMP (Swedish)
 gimp-help-uk - Documentation for the GIMP (Ukrainian)
 gimp-help-zh-cn - Documentation for the GIMP (Simplified Chinese)
Changes:
 gimp-help (2.10.34-1) experimental; urgency=medium
 .
   * New upstream release
   * Add new binary packages for cs, da, en_GB, fa, fi, hr, hu, lt, pt,
 ro, uk and zh_CN.
   * Drop obsolete override for dh_clean.
Checksums-Sha1:
 590b1eba051fc3eb06f64ccf62be53a4bdd544bf 3621 gimp-help_2.10.34-1.dsc
 d07a971bfb2178bdbf4cc8f63789a027e211fd80 165540436 
gimp-help_2.10.34.orig.tar.bz2
 7ac91236ccd5c6774e2f30212b9f17741c60e2e3 11612 
gimp-help_2.10.34-1.debian.tar.xz
 96382b9cf44e508564acb72865982c3ad90e8349 50332916 
gimp-help-ca_2.10.34-1_all.deb
 64f8f5d747fc7cf079d35f01731fea7e2e8fd3c4 191060 
gimp-help-common_2.10.34-1_all.deb
 50b6f39ce44fa8089c55cce95f5c289bf4d55331 49488836 
gimp-help-cs_2.10.34-1_all.deb
 70829f1826219d7877db60674fa9c8176548c600 49620052 
gimp-help-da_2.10.34-1_all.deb
 baca167e2696cd087e66965e1bab9119d2a5276f 51882032 
gimp-help-de_2.10.34-1_all.deb
 d43140c9478aa98fde209a2c8251992ddf90deb5 46903996 
gimp-help-el_2.10.34-1_all.deb
 a8cbcb29d075aabfbc2ecd4d19b61596d5728f82 49593388 
gimp-help-en-gb_2.10.34-1_all.deb
 f4fcd825d9c56c3ad4ae778c4916e4911f881174 49612680 
gimp-help-en_2.10.34-1_all.deb
 1843584f648b9378f6a86bde3b2d5963587a7c97 50009268 
gimp-help-es_2.10.34-1_all.deb
 b653010fa5228c7355fd5cc1c34386f777c63c6d 49614940 
gimp-help-fa_2.10.34-1_all.deb
 03d3eebca44c612eca0de4da232045088fc83a9b 49637188 
gimp-help-fi_2.10.34-1_all.deb
 bd7c0c64b782e9c35c6edbd530110428bdee380b 51880876 
gimp-help-fr_2.10.34-1_all.deb
 baf6adc8f001cc6346412b4aa01ec3a09f82c645 49615448 
gimp-help-hr_2.10.34-1_all.deb
 7ffce1dbdb8b93b2a26192c7ffb7d24b873e8aab 49605208 
gimp-help-hu_2.10.34-1_all.deb
 7723c86397c7ae9c8dbfbdb8f52e5b35cdeeccbb 54448404 
gimp-help-it_2.10.34-1_all.deb
 306840664cf934add58881353499349147d83e81 48498592 
gimp-help-ja_2.10.34-1_all.deb
 cdcafd67a6cb5e2dc69e4fddfdb5b3a58e63d9c5 50083900 
gimp-help-ko_2.10.34-1_all.deb
 dc145e585e0d20e842a475273b93f6d8f7badbb6 50630916 
gimp-help-lt_2.10.34-1_all.deb
 fb1d583d483cb20e3d0f785e71f31eb31e0f68a5 49696460 
gimp-help-nl_2.10.34-1_all.deb
 4639aee2da9c22e824668fcdd2348f4d92c36d36 45073696 
gimp-help-nn_2.10.34-1_all.deb
 241af4a7c74fee8b8a12c71f7f1e9dbe3fd9fa7e 51709028 
gimp-help-pt-br_2.10.34-1_all.deb
 c864f9e424bcee7d8945bbec3f09210566d18b85 49606360 
gimp-help-pt_2.10.34-1_all.deb
 eddca5949030746e9edaa6c84b9ee916cd1c4e6f 49642312 
gimp-help-ro_2.10.34-1_all.deb
 41e23f1fbc3b58efb7d63763349f2456c7db7473 49821936 
gimp-help-ru_2.10.34-1_all.deb
 188c4215de7938a8eafb379364bb8978cffe3d7d 49624352 
gimp-help-sl_2.10.34-1_all.deb
 e765cb650db691e80e6e12f50aee5703bc93eec9 49649048 
gimp-help-sv_2.10.34-1_all.deb
 6349e880c5dc0be605a364585722e4619ba825aa 49621816 
gimp-help-uk_2.10.34-1_all.deb
 a7a8bdb4d9a335582879d770787b070a5d98e312 49618656 
gimp

Bug#1034575: ITP: cve-bin-tool -- The CVE Binary Tool is a free, open source tool to help you find known vulnerabilities in software, using data from the National Vulnerability Database (NVD) list of

[jarebear6expepjozn6rakjq5iczi3irqwphcvbswgkahd6b6twnxxid]

Package: wnpp
Severity: wishlist
Owner: jarebear6expepjozn6rakjq5iczi3irqwphcvbswgkahd6b6twnxxid 

X-Debbugs-Cc: debian-devel@lists.debian.org, 
jarebear6expepjozn6rakjq5iczi3irqwphcvbswgkahd6b6twnx...@4xvk.com

* Package name: cve-bin-tool
  Version : 3.2.0 
  Upstream Author : Teri Oda 
* URL : https://github.com/intel/cve-bin-tool
* License : GPL
  Programming Lang: Python
  Description : The CVE Binary Tool is a free, open source tool to help you 
find known vulnerabilities in software, using data from the National 
Vulnerability Database (NVD) list of Common Vulnerabilities and Exposures 
(CVEs).

The tool has two main modes of operation:

A binary scanner which helps you determine which packages may have been 
included as part of a piece of software. There are 288 checkers which focus on 
common, vulnerable open source components such as openssl, libpng, libxml2 and 
expat.
Tools for scanning known component lists in various formats, including 
.csv, several linux distribution package lists, language specific package 
scanners and several Software Bill of Materials (SBOM) formats.

It is intended to be used as part of your continuous integration system to 
enable regular vulnerability scanning and give you early warning of known 
issues in your supply chain.

Re: Help with a libzstd sparc64 FTBFS on the buildd

[Peter Pentchev]

On Thu, Apr 06, 2023 at 05:01:07PM +0200, Paul Gevers wrote:
> Hi Peter,
> 
> On 06-04-2023 15:37, Peter Pentchev wrote:
> > I feel like I cannot ask for an unblock from the release
> > managers since the sparc64 buildd started failing on this package
> > at some point in February:
> 
> sparc64 is not a release architecture. sparc64 will not be better or worse
> if something migrates. I suggest to consider those problem separately.

TBH, that was my own understanding, and I was about to send an unblock
request earlier today, but then I decided to take another look at
the freeze policy and the phrase "migration for packages only allowed if
all their binary packages have been built on buildds" threw me a bit.
But yeah, I should have realized that should only apply to release
architectures... thanks for correcting my thinking!

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Re: Help with a libzstd sparc64 FTBFS on the buildd

[Paul Gevers]

Hi Peter,

On 06-04-2023 15:37, Peter Pentchev wrote:

I feel like I cannot ask for an unblock from the release
managers since the sparc64 buildd started failing on this package
at some point in February:


sparc64 is not a release architecture. sparc64 will not be better or 
worse if something migrates. I suggest to consider those problem separately.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Re: Help with a libzstd sparc64 FTBFS on the buildd

[Peter Pentchev]

On Thu, Apr 06, 2023 at 04:37:16PM +0300, Peter Pentchev wrote:
> Hi,
> 
> The libzstd package in testing is currently missing a couple of
> build-time tests and a fix for a very rare data corruption bug.
> Both of these have been fixed in libstd-1.5.4+dfsg2-5 in unstable;

...of course this should have been libzstd-1.5.4+dfsg2-5

> however, I feel like I cannot ask for an unblock from the release
> managers since the sparc64 buildd started failing on this package
> at some point in February:
> 
>   https://buildd.debian.org/status/logs.php?pkg=libzstd=sparc64
> 
> Now, the -1, -2, and -4 failures I can explain: there were some
> problems in the upstream test suite that were fixed in -3 and -5.
> However, -3 and -5 should really not have failed: they built
> successfully on all other architectures where the build dependencies
> were installable, and they also passed autopkgtest runs:
> 
>   https://ci.debian.net/packages/libz/libzstd/
> 
> I set up a qemu-based sbuild environment on my laptop, and
> I built the libzstd package successfully. Is it possible that
> something is wrong with the sparc64 buildd? Could somebody with
> an actual sparc64 box try to build libstd-1.5.4+dfsg2-5 and
> let me know if it works for them?

...and of course this should also have been libzstd-1.5.4+dfsg2-5

> Thanks in advance!

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Help with a libzstd sparc64 FTBFS on the buildd

[Peter Pentchev]

Hi,

The libzstd package in testing is currently missing a couple of
build-time tests and a fix for a very rare data corruption bug.
Both of these have been fixed in libstd-1.5.4+dfsg2-5 in unstable;
however, I feel like I cannot ask for an unblock from the release
managers since the sparc64 buildd started failing on this package
at some point in February:

  https://buildd.debian.org/status/logs.php?pkg=libzstd=sparc64

Now, the -1, -2, and -4 failures I can explain: there were some
problems in the upstream test suite that were fixed in -3 and -5.
However, -3 and -5 should really not have failed: they built
successfully on all other architectures where the build dependencies
were installable, and they also passed autopkgtest runs:

  https://ci.debian.net/packages/libz/libzstd/

I set up a qemu-based sbuild environment on my laptop, and
I built the libzstd package successfully. Is it possible that
something is wrong with the sparc64 buildd? Could somebody with
an actual sparc64 box try to build libstd-1.5.4+dfsg2-5 and
let me know if it works for them?

Thanks in advance!

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#1032663: ITP: eludris -- A simple CLI to help you with setting up and managing your Eludris instance

[Oliver Wilkes]

Package: wnpp
Severity: wishlist
Owner: Oliver Wilkes 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name : eludris
Version : 0.3.2
Upstream Author : Oliver Wilkes 
* URL : https://github.com/eludris/eludris/tree/main/cli/
* License : MIT
Programming Lang: Rust
Description : A simple CLI to help you with setting up and managing your 
Eludris instance


Located at https://github.com/eludris/eludris/tree/main/cli, this is a 
package for creating an Eludris instance with ease. It is officially 
supported and maintained by Eludris and reduces the barrier to entry for 
new instance owners.


### Why is this package useful/relevant?

This CLI provides an easy way for users to create their own Eludris 
instance from scratch. There are currently no alternatives as Eludris is 
relatively new and this is an 'official' CLI.


### How do you plan to maintain it?

I am not all too sure how this works as this is my first time packaging 
for Debian. I plan to maintain it solo for now, unless if anyone has any 
better suggestions as to what team to maintain it under.

Re: Bug#1011666: need help with groff 1.23.0 (1.23.0~rc3-1 package prepared)

[Alejandro Colomar]

Hi Colin,

On 3/3/23 19:12, Colin Watson wrote:
> This isn't really analogous to your situation, though.  git-dpm is more
> like a workflow tool (such as stgit) than it is like a program you use
> to generate one-off scripted patches.  I don't think it would be
> appropriate or reasonable to try to embed this sort of thing in every
> commit generated by git-dpm, which is quite a lot of the commits that
> end up in my packaging branches.

If it's recurrent, maybe doing it only once would be nice.

> 
> I'd be happy to write a debian/README.source file, which would be a
> better place for this sort of thing.  I'm not sure exactly when I'll get
> round to it, but I've added it to my to-do list.

Sure, that would also help!

Cheers,

Alex

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Re: Bug#1011666: need help with groff 1.23.0 (1.23.0~rc3-1 package prepared)

[Colin Watson]

On Mon, Feb 27, 2023 at 03:26:52PM +0100, Alejandro Colomar wrote:
> On 2/27/23 13:56, G. Branden Robinson wrote:
> > At 2023-02-26T13:30:58+, Colin Watson wrote:
> >> First, move your current branch somewhere for reference, then make a new
> >> one.  Then, my routine for pulling in new upstreams looks roughly like
> >> this:
> >>
> >>   git-dpm import-new-upstream -p $UPSTREAMTAG^{} --rebase-patched 
> >> ../foo.orig.tar.gz
> >>   # this imports the unpacked upstream tarball onto an upstream branch
> >>   # based on $UPSTREAMTAG, then drops you into a rebase session
> >>
> >>   ... continue with rebase as needed, then once you're finished ...
> >>
> >>   git-dpm update-patches --amend
> >>   # the --amend is just because the import-new-upstream step will
> >>   # already have recorded the new upstream on the branch you started
> >>   # from, but the history looks clearer if you bundle the rebase with
> >>   # that in a single merge commit, which this does
> 
> May I ask something from you, Colin?  Could you please embed that
> info in the commit messages in salsa?  That would help those who
> want to learn Debian packaging from actual practice rather than
> tutorials (I've read and watched many of those, and my confusion
> only grows; I mean, just look at
> <https://www.youtube.com/watch?v=O83rIRRJysA> :p).
> 
> In the Linux man pages I write the scripts or commands run to produce
> a scripted or semi-scripted patch, or when some important information
> needed to write a patch was gotten from some script.  See for example:

This isn't really analogous to your situation, though.  git-dpm is more
like a workflow tool (such as stgit) than it is like a program you use
to generate one-off scripted patches.  I don't think it would be
appropriate or reasonable to try to embed this sort of thing in every
commit generated by git-dpm, which is quite a lot of the commits that
end up in my packaging branches.

I'd be happy to write a debian/README.source file, which would be a
better place for this sort of thing.  I'm not sure exactly when I'll get
round to it, but I've added it to my to-do list.

> > Please find attached my much more modest proposal.  Let's make sure the
> > groff in Debian bookworm will not throw confusing undefined register
> > warnings or drop text from man pages that begin to embrace groff 1.23's
> > new features.

I'm fine with this, modulo sorting out minor commit formatting details.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Re: Bug#1011666: need help with groff 1.23.0 (1.23.0~rc3-1 package prepared)

[Alejandro Colomar]

Hi Branden and Colin!

On 2/27/23 13:56, G. Branden Robinson wrote:
> [added Alex Colomar to CC]
> 
> At 2023-02-26T13:30:58+, Colin Watson wrote:
>>> I am not a proficient gbp user, but I think I have done what is
>>> necessary.
>>
>> groff doesn't use gbp - it uses git-dpm.
> 
> Right.  You told me that before and the information trickled out of my
> sieve-like brain.  TLA overload, so I was SOL.  FML.

$ wtf is SOL
SOL: SOL (6)  - a collection of card games which are easy to play 
with...
$ wtf is FML
Gee...  I don't know what FML means...


Please send a patch to bsdgames :D

At least dict(1) could help with SOL.  No luck with FML though,
I had to search it on the web.  No good.  Fuck my life! :D

$ dict -d foldoc SOL
1 definition found

From The Free On-line Dictionary of Computing (30 December 2018) [foldoc]:

  SOL
  
 1.  {Simulation Oriented Language}.
  
 2. {Second-Order lambda-calculus}.
  
 3. Semantic Operating Language.  Language for manipulating
 semantic networks for building cognitive models, particularly
 for natural language understanding.  "Explorations in
 Cognition", D.A. Norman et al, W.H.  Freeman 1974.
  
 4. Shit Outta Luck.

$ dict FML
No definitions found for "FML", perhaps you mean:
gcide:  ml  Fm  Fil  -ful
wn:  ml  fl  fm  ful
vera:  ml  fl  fm  cfml  aml  bml  dml  eml  gml  iml  kml  mml
  nml  qml  sml  uml  vml  wml  xml  fal  fbl  fcl  fdl  frl  ftl
  fma  fmb  fmm  fmo  fms
jargon:  fm
foldoc:  ml  fl  fm


> 
>> If you try to use gbp for it then you will probably get quite confused
>> and so will I, so please don't.
> 
> Yes, indeed, thanks.
> 
>> First, move your current branch somewhere for reference, then make a new
>> one.  Then, my routine for pulling in new upstreams looks roughly like
>> this:
>>
>>   git-dpm import-new-upstream -p $UPSTREAMTAG^{} --rebase-patched 
>> ../foo.orig.tar.gz
>>   # this imports the unpacked upstream tarball onto an upstream branch
>>   # based on $UPSTREAMTAG, then drops you into a rebase session
>>
>>   ... continue with rebase as needed, then once you're finished ...
>>
>>   git-dpm update-patches --amend
>>   # the --amend is just because the import-new-upstream step will
>>   # already have recorded the new upstream on the branch you started
>>   # from, but the history looks clearer if you bundle the rebase with
>>   # that in a single merge commit, which this does

May I ask something from you, Colin?  Could you please embed that
info in the commit messages in salsa?  That would help those who
want to learn Debian packaging from actual practice rather than
tutorials (I've read and watched many of those, and my confusion
only grows; I mean, just look at
<https://www.youtube.com/watch?v=O83rIRRJysA> :p).

In the Linux man pages I write the scripts or commands run to produce
a scripted or semi-scripted patch, or when some important information
needed to write a patch was gotten from some script.  See for example:


commit a1eaacb1a569cd492b09c04982cd40b4b733ba3c
Author: Alejandro Colomar 
Date:   Wed Nov 9 16:36:36 2022 +0100

Many pages: Add '\" t' comment where necessary

Scripted change:

$ grep -l -x '^[.]TS$' man*/* | sort -u | xargs sed -i -e "1i'\" t"

Link: 
<https://lore.kernel.org/linux-man/07a7d4e7-79a6-b2c3-6892-1e39a0679...@gmail.com/T/#mcf36c8a387fd5ff4f800dc220e3dbdd229b556bd>
Reported-by: Jakub Wilk 
Cc: Mike Frysinger 
Cc: "G. Branden Robinson" 
Cc: Michael Kerrisk 
Cc: Stefan Puiu 
Signed-off-by: Alejandro Colomar 

commit b324e17d3208c940622ab192609b836928d5aa8d
Author: Alejandro Colomar 
Date:   Sun Dec 4 20:38:06 2022 +0100

Many pages: wfix

Refer consistently to software versions.  In most cases, it is done as
 .  In the case of Linux and glibc, use the project
name, instead of other terms such as 'kernel' or 'library'.

I found the uses of inconsistent language with the following:

$ find man* -type f \
| xargs grep -i 
'\(since\|before\|after\|until\|to\|from\|in\|between\|version\|with\) 
\(kernel\|version\|2\.\|3\.\|4\.\|5\.\)' \
| sort

However, I might have missed some cases.  Anyway, 99% consistency is
pretty good consistency.  We'll fix the remaining cases as we see them.

Signed-off-by: Alejandro Colomar 


>>
>> Then you can cherry-pick your packaging changes on top of this, as well
>> as telling pristine-tar about the new upstream tarball based on the
>> appropriate imported branch.
>>
>> If you push the results to a temporary branch on salsa then I can look
>> over them, which is probably a good idea since you're unfamiliar with
>> git-dpm.
> 
> Thanks f

Re: need GBP help with groff 1.23.0 (1.23.0~rc3-1 package prepared)

[G. Branden Robinson]

At 2023-02-26T11:52:39+0100, Andrey Rakhmatullin wrote:
> Just import them? Do you have any specific questions or problems with
> this?
[...]
> Again, which advice? You said that it works for you.

Hi Andrey,

I think at least some of my confusion arose from trying to use gbp with
a git-dpm-based repository.  I was working in a big hurry, trying to
make the Bullseye release but that is now looking hopeless.

Thanks for responding so swiftly to my plea for help.

Regards,
Branden


signature.asc
Description: PGP signature

Re: Bug#1011666: need help with groff 1.23.0 (1.23.0~rc3-1 package prepared)

[G. Branden Robinson]

[added Alex Colomar to CC]

At 2023-02-26T13:30:58+, Colin Watson wrote:
> Sorry about that!  Feel free to grab me on IRC if I'm not replying to
> email.

Ah!  I'm never on IRC anymore.  I shifted to machines with power
management for everyday use; the loss of a nailed-up Internet connection
destroyed my IRC continuity.  (I hear there are ways around this...)

> > I am not a proficient gbp user, but I think I have done what is
> > necessary.
> 
> groff doesn't use gbp - it uses git-dpm.

Right.  You told me that before and the information trickled out of my
sieve-like brain.  TLA overload, so I was SOL.  FML.

> If you try to use gbp for it then you will probably get quite confused
> and so will I, so please don't.

Yes, indeed, thanks.

> First, move your current branch somewhere for reference, then make a new
> one.  Then, my routine for pulling in new upstreams looks roughly like
> this:
> 
>   git-dpm import-new-upstream -p $UPSTREAMTAG^{} --rebase-patched 
> ../foo.orig.tar.gz
>   # this imports the unpacked upstream tarball onto an upstream branch
>   # based on $UPSTREAMTAG, then drops you into a rebase session
> 
>   ... continue with rebase as needed, then once you're finished ...
> 
>   git-dpm update-patches --amend
>   # the --amend is just because the import-new-upstream step will
>   # already have recorded the new upstream on the branch you started
>   # from, but the history looks clearer if you bundle the rebase with
>   # that in a single merge commit, which this does
> 
> Then you can cherry-pick your packaging changes on top of this, as well
> as telling pristine-tar about the new upstream tarball based on the
> appropriate imported branch.
> 
> If you push the results to a temporary branch on salsa then I can look
> over them, which is probably a good idea since you're unfamiliar with
> git-dpm.

Thanks for this.  I also found
https://wiki.debian.org/PackagingWithGit/GitDpm which is helpful for my
fallback plan described below.

> > How do we move forward with this?  I am anxious about the closing of the
> > soft freeze window.
> 
> There is no way that this giant new upstream release will be suitable
> at this stage in the freeze; it's too late.  This should be targeted
> at experimental.

Oh, man.  That really sucks the wind out of my sails.  :(

(Good thing I did the packaging update work already!)

The freeze policy says, "Starting 2023-02-12, only small, targeted fixes
are appropriate for bookworm. We want maintainers to focus on small,
targeted fixes. This is mainly at the maintainers discretion, there will
be no hard rule that will be enforced."[1]

I was kind of hoping for an exercise of that discretion in favor of
getting the groff release in.  I hope you feel I have been attentive to
issues of implementation quality.  Nevertheless I admit I have a
conflict of interest as an active upstream (for the moment, still
unoffical) co-maintainer who wants to see his 4,000 commits including
400 bug fixes get into the next Debian release.[2]

But, also, Bertrand Garrigues (GNU maintainer, who has had to step back
quite a bit for personal reasons) is going to be unavailable to tag
1.23.0 final until _next_ weekend so I think groff and Debian release
timing may simply have a curse on them.

Please find attached my much more modest proposal.  Let's make sure the
groff in Debian bookworm will not throw confusing undefined register
warnings or drop text from man pages that begin to embrace groff 1.23's
new features.

Alex Colomar, the Linux man-pages maintainer, is eager to adopt the new
man(7) MR macro ASAP, so that's 2,500 man pages, many commonly used,
that will be undergoing a transition in the next few months, I expect.

Meanwhile I reckon I'll start praying to the gods of backports and point
releases.

Regards,
Branden

[1] https://release.debian.org/testing/freeze_policy.html#soft
[2] 
https://git.savannah.gnu.org/cgit/groff.git/tree/ANNOUNCE?id=99e5b4ae55a7c222f6bf57b355289a88d862478d

https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS?id=99e5b4ae55a7c222f6bf57b355289a88d862478d
commit 69e844df84929b8a6a440cbbafe55dcd134107b6
Author: G. Branden Robinson 
Date:   Mon Feb 27 06:27:17 2023 -0600

Rename and document patch

diff --git a/debian/changelog b/debian/changelog
index ca8a27d5..4f867aeb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,14 @@
-groff (1.22.4-10) UNRELEASED; urgency=medium
+groff (1.22.4-10) unstable; urgency=medium
 
+  [ Colin Watson ]
   * Set upstream metadata fields: Repository-Browse.
 
- -- Colin Watson   Mon, 02 Jan 2023 13:38:52 -
+  [ G. Branden Robinson ]
+  * debian/patches/add-groff-1.23-forward-compatibility.patch: Prevent
+formatter warnings and dropped man(7) document text when encountering
+documents written using new features of groff 1.23.
+
+ -- G. Branden Robinson   Mon, 27 Feb 2023 06:30:24 -0600
 
 groff (1.22.4-9) unstable; urgency=medium
 
diff --git 

Re: Bug#1011666: need help with groff 1.23.0 (1.23.0~rc3-1 package prepared)

[Colin Watson]

On Sat, Feb 25, 2023 at 11:13:29PM -0600, G. Branden Robinson wrote:
> I've sent you a couple of mails over the past few months, but I don't
> recall seeing a reply.

Sorry about that!  Feel free to grab me on IRC if I'm not replying to
email.

> I am not a proficient gbp user, but I think I have done what is
> necessary.

groff doesn't use gbp - it uses git-dpm.  If you try to use gbp for it
then you will probably get quite confused and so will I, so please
don't.

First, move your current branch somewhere for reference, then make a new
one.  Then, my routine for pulling in new upstreams looks roughly like
this:

  git-dpm import-new-upstream -p $UPSTREAMTAG^{} --rebase-patched 
../foo.orig.tar.gz
  # this imports the unpacked upstream tarball onto an upstream branch
  # based on $UPSTREAMTAG, then drops you into a rebase session

  ... continue with rebase as needed, then once you're finished ...

  git-dpm update-patches --amend
  # the --amend is just because the import-new-upstream step will
  # already have recorded the new upstream on the branch you started
  # from, but the history looks clearer if you bundle the rebase with
  # that in a single merge commit, which this does

Then you can cherry-pick your packaging changes on top of this, as well
as telling pristine-tar about the new upstream tarball based on the
appropriate imported branch.

If you push the results to a temporary branch on salsa then I can look
over them, which is probably a good idea since you're unfamiliar with
git-dpm.

> How do we move forward with this?  I am anxious about the closing of the
> soft freeze window.

There is no way that this giant new upstream release will be suitable at
this stage in the freeze; it's too late.  This should be targeted at
experimental.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Re: need GBP help with groff 1.23.0 (1.23.0~rc3-1 package prepared)

[Andrey Rakhmatullin]

On Sun, Feb 26, 2023 at 12:06:18AM -0600, G. Branden Robinson wrote:
> Background: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011666
> 
> Can someone advise me as to the correct procedure for merging upstream
> release candidate archives into https://salsa.debian.org/debian/groff ?
Just import them? Do you have any specific questions or problems with
this?

> ...except that I don't think I did the upstream merge/tagging right.
You shouldn't do merging or taging manually, gbp import-orig does that for
you.

> I suspect this because if I do a "git rebase -i origin", git goes crazy
> and tells me I have merge conflicts. 
Why are you running this command and what do expect to get after running
it? And if it's in a pushed branch then you shouldn't ever do that.

> None of the release candidates were already staged even as reference
> points, so I had to wade into the gbp documentation myself, and I
> probably screwed it up.
Not sure what do you mean by this but importing upstream tarballs is a
very basic gbp action that's hard to screw assuming the repo was already n
a good shape. And it doesn't matter that tarballs are "release candidates"
unless that implies something else.

> [1] Here are my clumsy attempts to get those release candidate archives
> in.  (I expanded some git aliases that I have set up.)
> 
>   587  git branch upstream
But the repo already has the upstream branch.

>   592  git commit -v debian/watch
The upstream branch doesn't have a debian/watch file. Have you confused
master and upstream by running the previous command? Or are some commands
missing?

>   598  gbp import-orig --upstream-branch=upstream 
> https://alpha.gnu.org/gnu/groff/groff-1.23.0.rc1.tar.gz
>   599  gbp import-orig --upstream-branch=upstream 
> https://alpha.gnu.org/gnu/groff/groff-1.23.0.rc2.tar.gz
>   600  gbp import-orig --upstream-branch=upstream 
> https://alpha.gnu.org/gnu/groff/groff-1.23.0.rc3.tar.gz
(--upstream-branch=upstream should be the default)

>   643  git tag upstream/1.23.0_rc1 bc599bf23fcb428295d769c7944bdfd97d8a203d
>   644  git tag upstream/1.23.0_rc2 ff6560eb9b39d2c45a0f8a0c1cc12527edaf270d
>   645  git tag upstream/1.23.0_rc3 ff12aaae2c82beece4d9ff6bb90f019ab142ed06
>   647  git tag -d upstream/1.23.0.rc1
>   648  git tag -d upstream/1.23.0.rc2
>   649  git tag -d upstream/1.23.0.rc3
None of this should be needed if you tell import-orig that the versions
are 1.23.0~rcN instead of the default 1.23.0.rc1.

>   At that point I was able to get "gbp buildpackage" to run, and it was
>   just a matter of doing ordinary packaging work, as illustrated in the
>   commit messages above.
> 
>   Advice is appreciated!
Again, which advice? You said that it works for you.

need GBP help with groff 1.23.0 (1.23.0~rc3-1 package prepared)

[G. Branden Robinson]

Background: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011666

Can someone advise me as to the correct procedure for merging upstream
release candidate archives into https://salsa.debian.org/debian/groff ?

I am not a proficient gbp user, but I think I have done what is
necessary.

...except that I don't think I did the upstream merge/tagging right.

I suspect this because if I do a "git rebase -i origin", git goes crazy
and tells me I have merge conflicts.  None of the release candidates
were already staged even as reference points, so I had to wade into the
gbp documentation myself, and I probably screwed it up.

*** I have not PUSHED anything. ***

Some relevant shell history is at the end of this message.[1]

But after the point where I merged the upstream tarballs, things are
clean and I can rebase at will.

The upstream diffs are too gigantic to enclose (4,500+ commits since
groff 1.22.4), and not very interesting as they can be seen at groff's
own Git repo.

I'm attaching a git diff -p of my changes after that, meaning the actual
packaging work.

For the benefit of people reading this message, here are the commit
messages themselves (git log -r HEAD~21..HEAD).

commit 3cff7c6967e89d187efb160ce7d2a09af5ea82aa (HEAD -> master)
Author: G. Branden Robinson 
Date:   Sat Feb 25 22:53:06 2023 -0600

debian/changelog: Add upstream bug closers.

commit 1fd80f4151713e9f1d3cb52a4b749fa643776908
Author: G. Branden Robinson 
Date:   Sat Feb 25 22:29:27 2023 -0600

debian/groff{,-base}.install: Add new files

...provided upstream (en.tmac, hyphen.it, it.tmac, groff_font.5,
groff_out.5, groff_tmac.5, groff_man_style.7, groff_rfc1345.7,
FontMap-X11, ptx.tmac, rfc1345.tmac, sanitize.tmac, sboxes.tmac; see
upstream NEWS).

commit 56bf101afd21b9516775f58511e51d85dde06ef1
Author: G. Branden Robinson 
Date:   Sat Feb 25 22:09:23 2023 -0600

debian/groff{,-base}.install: Drop files

...that are no longer produced upstream (see upstream NEWS).

commit 9e99a662a4512e1f6656da2b9408f0f411abd311
Author: G. Branden Robinson 
Date:   Sat Feb 25 21:53:50 2023 -0600

debian/rules (confflags): Migrate option name.

...to "--with-appdefdir" from "--with-appresdir" per upstream NEWS.

commit 21ca0ea6c2162a95faf850b7f9c208b4d6d05374
Author: G. Branden Robinson 
Date:   Sat Feb 25 21:47:03 2023 -0600

Drop {meintro,meref,pic}.txt.

commit 58720f040d16da8bc868eca5466c91ee1a343889
Author: G. Branden Robinson 
Date:   Sat Feb 25 21:17:45 2023 -0600

debian/patches/clamp-negative-tab-stop*: Drop

Applied upstream in commit 6692653f7cae4116d4e70318f71b3d0808f2261f,
2021-09-11.

commit 01d76131b10c44f05ba7378a6193a5ce74f10fb9
Author: G. Branden Robinson 
Date:   Sat Feb 25 21:14:29 2023 -0600

debian/patches/destructor-segv.patch: Drop

Applied upstream in commit c788cf8c6bbe939fa11f7ec032e525a7e33f41b6,
2020-09-29.

commit 0323958c2ea85b86d24e07907e5718584fe5e746
Author: G. Branden Robinson 
Date:   Sat Feb 25 21:11:54 2023 -0600

debian/patches/document-sgr.patch: Resync

...with upstream.

commit 34942d9ebdb365be2765d1cf05850f7a8a6b78ad
Author: G. Branden Robinson 
Date:   Sat Feb 25 21:07:36 2023 -0600

debian/patches/bsd-updates.patch: Drop

Applied upstream in commit 5a8af7104f1c581bcfbad12b56033ad403b0afe1,
2019-12-21.

commit 915e5df22c31ce935de36322f1fa4db933c923e5
Author: G. Branden Robinson 
Date:   Sat Feb 25 21:04:51 2023 -0600

debian/patches/mdoc-Lk-arguments.patch: Drop

Applied upstream in commit 76e4db6e839904d2e2a28b29b483678214598f3b,
2019-01-12.

commit 34fe473ff1c2853d823d5acd3362aeef3e634c7b
Author: G. Branden Robinson 
Date:   Sat Feb 25 21:00:23 2023 -0600

debian/patches/avoid-perl-diamond.patch: Drop

Applied upstream in commit 27472b5ae548d3dbe933713d488d676708996253,
2019-01-24.

commit 4266e24f1d65d5e7c06ac3c2ae2a202c3d0629ce
Author: G. Branden Robinson 
Date:   Sat Feb 25 20:57:25 2023 -0600

debian/patches/sort-perl-hash-keys.patch: Drop

Applied upstream in commit fcf3dc68839d83bfba206d1febffd9514a71ee82,
2015-11-06.

commit cb1cbb55e73e877c73a45d070eed89179699f316
Author: G. Branden Robinson 
Date:   Sat Feb 25 20:52:43 2023 -0600

debian/patches/series: Drop display-utc-times.*

commit 2ec0236804bf60e18282526d343068e9c26d6df2
Author: G. Branden Robinson 
Date:   Sat Feb 25 20:49:14 2023 -0600

debian/patches/mmse-note.patch: Resync w/ upstream

commit e8e7c6ce1e8267bbf6c65ce5910140ccc5a8993a
Author: G. Branden Robinson 
Date:   Sat Feb 25 20:45:39 2023 -0600

debian/patches/load-desc-failure.patch: Resync

...with upstream.

commit b7dc5d92ac984184ab30aef76e5d21752a044fe9
Author: G. Branden Robinson 
Date:   Sat Feb 25 20:40:55 2023 -0600

debian/patches/papersize-config.patch: Resync

...with upstream.

commit bb6d8e31ae4f60afd1ede232618dbff17e64ac87
Author: G. Branden Robinson 
Date:   Sat Feb 25 20:35:20 2023 -0600

Accepted doublecmd-help 1.0.10-1 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 12 Feb 2023 09:34:06 +
Source: doublecmd-help
Built-For-Profiles: noudeb
Architecture: source
Version: 1.0.10-1
Distribution: unstable
Urgency: medium
Maintainer: Pascal Packaging Team 
Changed-By: Graham Inggs 
Changes:
 doublecmd-help (1.0.10-1) unstable; urgency=medium
 .
   * New upstream release
   * Update debian/copyright
   * Bump Standards-Version to 4.6.2, no changes
Checksums-Sha1:
 49f5443b820e61ed63833f9ad92636f87898b385 2133 doublecmd-help_1.0.10-1.dsc
 89f4c72b0a16e5695ce8cdcc470300309df34754 7605382 
doublecmd-help_1.0.10.orig.tar.gz
 df41a0939fe37f90f22f4678cb2917d3f54ec09f 3104 
doublecmd-help_1.0.10-1.debian.tar.xz
Checksums-Sha256:
 daeceddfc1f0832795ee7fff19c4222bf85777034c4da2db02f22787b9c421bb 2133 
doublecmd-help_1.0.10-1.dsc
 f13935373728d654e1b3e39be6156e5e3d878569dd9d64992f1684fc17f28eff 7605382 
doublecmd-help_1.0.10.orig.tar.gz
 7706b4b8c434d4fde0c71f9adce7f08a572298ef04b1d509068fd54952dd3739 3104 
doublecmd-help_1.0.10-1.debian.tar.xz
Files:
 868387ba097ee0e7424fa11769703158 2133 doc optional doublecmd-help_1.0.10-1.dsc
 11ae41f101eee400dd378dd9705bca10 7605382 doc optional 
doublecmd-help_1.0.10.orig.tar.gz
 bfbb6f8d562bdf6d8c040e01a7ce3f08 3104 doc optional 
doublecmd-help_1.0.10-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEJeP/LX9Gnb59DU5Qr8/sjmac4cIFAmPosvwACgkQr8/sjmac
4cKJNxAAgHgd/k7E/VFxbE0FErTHA9sfLf/pc/2su5zzxaMZizlAQb4Jqa/LZ94G
9s6tJ9IshmISrV+7/NQF6Z+0Zmo28OrratztJjHyVTp/zBPDAWZJsiRbYWEyfhWi
U+yQC1AVGUuTZNC6Lxx2ffedzQik032SLlkb9foOfW3X0T6jS/mcui1MqtU/zI5T
L1uq78EUCl6KUzq5urDu6euDMnEziRasatigKpszL0IhS8WjPvpMIgVYiabewzLZ
M+NO/fFBoVCz76VUY/7fIGOAUdPhC5s5w4U4+OzkzJH3/3jKktC3Cbd41PnRHhbL
Pbn3pK/f84Z5vV4cu6QcQOZLAas7AYx0xW77Bcck6RCOuwH125pcO2bj4+NPrBTK
XnjPe7iFpfAZlfAhPJbrdAJ5pTrN0cf1J369CZYaSgjjk/21MlISldjVsrKy5Yej
p/q+oHjpd0lCbrBNramF6lbrVUov9IHXMu6TAQntX+lMIuVhY/yeuFNR40034WH+
3l9/OAnxoXy0SztSfhPX9z1fUQZqM2EzrJGOcuRgxm3Uw+hgdxuC0LHemdgfUDTh
mpSHR7Fp+XL9ILBiG3wU9g7mo+xy5da6Tb0TnOAmKnAD4qkUStKlMLk62avMQXmq
wAp1POcXQjDzuxJ7TZ3mcWDpotm1Gpl630uyvlwgfkd8wTULuSk=
=RdP9
-END PGP SIGNATURE-

Bug#1030841: ITP: frp -- A fast reverse proxy to help you expose a local server behind a NAT or firewall to the internet

[Bo YU]

Package: wnpp
Severity: wishlist
Owner: Bo YU 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: frp
  Version : 0.36.1-1
  Upstream Author :
* URL : https://github.com/fatedier/frp
* License : Apache-2.0
  Programming Lang: Go
  Description : A fast reverse proxy to help you expose a local server 
behind a NAT or firewall to the internet.

 .
 frp is a fast reverse proxy to help you expose a local server behind a
 NAT or firewall to the Internet. As of now, it supports **TCP** and
 **UDP**, as well as **HTTP** and **HTTPS** protocols, where requests can
 be forwarded to internal services by domain name.
 .

 This package will be maintained under Debian go team.



signature.asc
Description: PGP signature

Re: Help patching files in dependency package

[Dominic Hargreaves]

On Tue, Jan 17, 2023 at 08:52:50AM +0800, Paul Wise wrote:
> On Tue, 2023-01-17 at 00:55 +0100, Tobias Wackenhut wrote:
> 
> > What would be the cleanest way to package the new version with the 
> > mentioned patch?
> 
> Ask the extension author to get the patch included into the upstream
> rt5 core, get a release of that, then get request-tracker-5 updated.
> 
> Alternatively, drop the patch from the extension upstream and work
> around the issue within the extension upstream codebase instead.
> 
> If neither of these are viable, discuss with the request-tracker-5
> maintainers in Debian about including the patch in that package.

Hi, (somewhat dormant) RT maintainer here.

Thanks Paul, that's spot on. We have in the distant past applied
those sort of patches before they hit RT upstream, but it's definitely
not ideal, and it really depends on the patch. 

However, Tobias, I don't see any patch that needs to be applied in

- Debian already has RT 5.0.3 (>= 5.0.2)?

Let's continue the discussion on
pkg-request-tracker-maintain...@alioth-lists.debian.net (CCed).

Cheers
Dominic

Re: Help patching files in dependency package

[Paul Wise]

On Tue, 2023-01-17 at 00:55 +0100, Tobias Wackenhut wrote:

> What would be the cleanest way to package the new version with the 
> mentioned patch?

Ask the extension author to get the patch included into the upstream
rt5 core, get a release of that, then get request-tracker-5 updated.

Alternatively, drop the patch from the extension upstream and work
around the issue within the extension upstream codebase instead.

If neither of these are viable, discuss with the request-tracker-5
maintainers in Debian about including the patch in that package.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Help patching files in dependency package

[Tobias Wackenhut]

Hi,

I so far only have basic packaging experience and would be really happy 
for any pointers in the right direction.




Problem (concrete example for simplicity, general topic):

- This is about perl software, i.e. interpreted script files.
- I want to update rt5-extension-resetpassword
- Upstream introduces a patch to rt5 core packaged in request-tracker-5
- Base package is dependency of extension package

What would be the cleanest way to package the new version with the 
mentioned patch? I think I only need pointers on what direction to take 
and maybe a pointer to the docs. I am more interested in the general 
approach to this kind of problem, but the example is the issue at hand.




Ideas so far:

- Package scripts for patch and patch -R
- Including the affected files in the extension package and overriding 
the ones in the dependency
- Somehow integrate the functionality into the base package, that is 
only used by this extension.



Thanks in advance for any hint

Tobias

Accepted click-help-colors 0.9.1-4 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 04 Jan 2023 08:13:18 +0100
Source: click-help-colors
Architecture: source
Version: 0.9.1-4
Distribution: sid
Urgency: medium
Maintainer: Sakirnth Nagarasa 
Changed-By: Sakirnth Nagarasa 
Changes:
 click-help-colors (0.9.1-4) sid; urgency=medium
 .
   * d/control: Updating Standards-Version.
Checksums-Sha1:
 4a08348a975c30bd33408f2c94ae37dca8def7c1 1386 click-help-colors_0.9.1-4.dsc
 f19909267163c79167010efc4a5448b85d5f3aa9 1732 
click-help-colors_0.9.1-4.debian.tar.xz
 fa5ac447a4740c584c66d1e256de310294ca0fca 6380 
click-help-colors_0.9.1-4_amd64.buildinfo
Checksums-Sha256:
 ed4097e61fe74cde426d811b44f03bc94452540421142506555dff8493324ee2 1386 
click-help-colors_0.9.1-4.dsc
 33f7b5543f83f7fa3d5c16a7e560f2bf0a0d2f4f73bd32a27df3687705db5050 1732 
click-help-colors_0.9.1-4.debian.tar.xz
 deb5d423bc4e1d10a9b39f7c8b149c9d52bcfc5f06a2d94fb7105151bfabbfe2 6380 
click-help-colors_0.9.1-4_amd64.buildinfo
Files:
 eb74acdbe60ddac2d5d86b7b59e5047f 1386 python optional 
click-help-colors_0.9.1-4.dsc
 ef8b107d40eea52a02541c9ee24d9920 1732 python optional 
click-help-colors_0.9.1-4.debian.tar.xz
 a0b0d3fb2fea14b47c2d7839fc907225 6380 python optional 
click-help-colors_0.9.1-4_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSQD23K0grRgZ+eimrWSi+uCV73mQUCY7Uo7wAKCRDWSi+uCV73
mVMhAQCb+qWRGZ0rAcncIkMyA02QhKe7y4bJNc5jbUoruRaY0QEA9sSANuisxLuJ
XeHgXAc6PnUI1+sJr99b2WExH/aT1QU=
=qRnS
-END PGP SIGNATURE-

Re: Help setting dbconfig-common for MariaDB, not MySQL

[Marc Haber]

On Mon, 2 Jan 2023 17:08:25 +0100, Paul Gevers 
wrote:
>Hi Marc,
>
>On 02-01-2023 16:58, Marc Haber wrote:
>> On Mon, 2 Jan 2023 16:31:17 +0100, Paul Gevers 
>> wrote:
>>> On 02-01-2023 14:21, Alessandro Vesely wrote:
 A user complained that MySQL doesn't work, because it misses the INET6
 type that the example settings use.
>>>
>>> And is this an absolute must? (It's an example after all?)
>> 
>> It is. We need to stop having "disable IPv6" as measure 1 if something
>> doesn't work right. It's the default IP protocol for a decade.
>
>Are you saying that MySQL doesn't support IPv6? Or just that the "INET6 
>type" in the context of MariaDB is a MariaDB specific implementation of 
>something? (Sorry, I didn't investigate and assumed the latter).

I didn't investigate and assumed some kind of the former.

Anyway, since we have a diversion between MySQL and MariaDB here that
causes dbconfig-common to trip over an IPv6 issue, I see the usual
solution coming over the horizon and wanted to object against that
one.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Help setting dbconfig-common for MariaDB, not MySQL

[Alessandro Vesely]

On Mon 02/Jan/2023 16:31:17 +0100 Paul Gevers wrote:

Hi Alessandro,



Hi, thanks for replying.



On 02-01-2023 14:21, Alessandro Vesely wrote:
please pardon my ignorance about Debian install.  I'm distributing a software 
which could use various DBMS'es by setting a number of parameters.  Example 
parameters are only given for MariaDB.  I distribute a debian/ directory that 
Debian users can use to prepare a package instead of configure, make, make 
install.  However, the debian/postinst supports MariaDB only.


Do I understand you correctly that you don't want to support MySQL?



Yes, it'd be too much work to create, test, and debug the settings for an 
alternative DBMS.



A user complained that MySQL doesn't work, because it misses the INET6 type 
that the example settings use.


And is this an absolute must? (It's an example after all?)



Well the reference example started using INET6 a few years ago, to store both 
IPv4 and IPv6 addresses.  It simplified settings somewhat.  Reverting to the 
previous state is too bad.


A user needing to work with MySQL can replace INET6 with a suitable BLOB, and 
change all the related queries and configs accordingly.  The existing 
debian/postinst won't work in that case.  It could be easily adapted, IF the 
relevant queries and configs were given...



Now I've added "mariadb-client | mariadb-server | dbconfig-no-thanks" to the 
Debian clause in debian/control.


I think that's wrong. At least it would fail to install dbconfig-common in case 
there is a mariadb-client installed. Also, I wonder about the mariadb-server 
part. mariadb-server depends on the versioned mariadb-server-* package which 
depends on the versioned mariadb-client-* package. So in case mariadb-client 
wouldn't be able to be fulfilled, mariadb-server as the second alternative 
isn't going to help. And in my opinion you should not depend on the server 
part. As with most databases, the server part can live on a different host and 
package should really not force the server to be on the same host.



Would "mariadb-client | dbconfig-no-thanks" work?  But see below.


I'm not clear how I could add an (optional) Conflicts mysql-something, also 
because I see no mysql-server in the package cache.


mysql-server is available in unstable, but we don't want to support both MySQL 
and MariaDB in Debian stable at the same time, so currently MySQL is blocked 
from migration. However, derivatives choose differently (Ubuntu supports MySQL 
in their releases).



Indeed, the user who complained was on Ubuntu 22.04 and MySQL version 8.0.23. 
He asked me to add MariaDB to the list of requirements.  Perhaps he can install 
requirements according to what I write in debian/control Depend.  If I only 
require mariadb-client and then the server is MySQL, it won't run.



Is there a way to fail if a user chooses to install the DB but MariaDB is 
missing?  Or is the above enough?


I don't think you can do it with dependencies. If you really want to go this 
route, you have to detect it during run time.



Yeah, not very nice, but still better to discover it at runtime.  The database 
creation with INET6 types will fail on Ubuntu.



Than

Re: Help setting dbconfig-common for MariaDB, not MySQL

[Paul Gevers]

Hi Marc,

On 02-01-2023 16:58, Marc Haber wrote:

On Mon, 2 Jan 2023 16:31:17 +0100, Paul Gevers 
wrote:

On 02-01-2023 14:21, Alessandro Vesely wrote:

A user complained that MySQL doesn't work, because it misses the INET6
type that the example settings use.


And is this an absolute must? (It's an example after all?)


It is. We need to stop having "disable IPv6" as measure 1 if something
doesn't work right. It's the default IP protocol for a decade.


Are you saying that MySQL doesn't support IPv6? Or just that the "INET6 
type" in the context of MariaDB is a MariaDB specific implementation of 
something? (Sorry, I didn't investigate and assumed the latter).


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Re: Help setting dbconfig-common for MariaDB, not MySQL

[Marc Haber]

On Mon, 2 Jan 2023 16:31:17 +0100, Paul Gevers 
wrote:
>On 02-01-2023 14:21, Alessandro Vesely wrote:
>> A user complained that MySQL doesn't work, because it misses the INET6 
>> type that the example settings use.
>
>And is this an absolute must? (It's an example after all?)

It is. We need to stop having "disable IPv6" as measure 1 if something
doesn't work right. It's the default IP protocol for a decade.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Help setting dbconfig-common for MariaDB, not MySQL

[Paul Gevers]

Hi Alessandro,

On 02-01-2023 14:21, Alessandro Vesely wrote:
please pardon my ignorance about Debian install.  I'm distributing a 
software which could use various DBMS'es by setting a number of 
parameters.  Example parameters are only given for MariaDB.  I 
distribute a debian/ directory that Debian users can use to prepare a 
package instead of configure, make, make install.  However, the 
debian/postinst supports MariaDB only.


Do I understand you correctly that you don't want to support MySQL? Or 
that you don't know how to support both at the same time? Most packages 
in Debian that are using MariaDB or MySQL can easily support both (hence 
we have the default-mysql-client and virtual-mysql-client packages), and 
indeed dbconfig-common treats them as equal.


A user complained that MySQL doesn't work, because it misses the INET6 
type that the example settings use.


And is this an absolute must? (It's an example after all?)

Now I've added "mariadb-client | 
mariadb-server | dbconfig-no-thanks" to the Debian clause in 
debian/control.


I think that's wrong. At least it would fail to install dbconfig-common 
in case there is a mariadb-client installed. Also, I wonder about the 
mariadb-server part. mariadb-server depends on the versioned 
mariadb-server-* package which depends on the versioned mariadb-client-* 
package. So in case mariadb-client wouldn't be able to be fulfilled, 
mariadb-server as the second alternative isn't going to help. And in my 
opinion you should not depend on the server part. As with most 
databases, the server part can live on a different host and package 
should really not force the server to be on the same host.


I'm not clear how I could add an (optional) Conflicts 
mysql-something, also because I see no mysql-server in the package cache.


mysql-server is available in unstable, but we don't want to support both 
MySQL and MariaDB in Debian stable at the same time, so currently MySQL 
is blocked from migration. However, derivatives choose differently 
(Ubuntu supports MySQL in their releases). As mentioned above, the 
server part can be on a different host, but ependencies are not able to 
describe incompatibility with what runs on the other host.


Is there a way to fail if a user chooses to install the DB but MariaDB 
is missing?  Or is the above enough?


I don't think you can do it with dependencies. If you really want to go 
this route, you have to detect it during run time.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Help setting dbconfig-common for MariaDB, not MySQL

[Alessandro Vesely]

Hi,

please pardon my ignorance about Debian install.  I'm distributing a software 
which could use various DBMS'es by setting a number of parameters.  Example 
parameters are only given for MariaDB.  I distribute a debian/ directory that 
Debian users can use to prepare a package instead of configure, make, make 
install.  However, the debian/postinst supports MariaDB only.


A user complained that MySQL doesn't work, because it misses the INET6 type 
that the example settings use.  Now I've added "mariadb-client | mariadb-server 
| dbconfig-no-thanks" to the Debian clause in debian/control.  I'm not clear 
how I could add an (optional) Conflicts mysql-something, also because I see no 
mysql-server in the package cache.


Is there a way to fail if a user chooses to install the DB but MariaDB is 
missing?  Or is the above enough?



Thanks in advance for any hint
Ale
--

Re: Help trying to debug an sbuild failure?

[Theodore Ts'o]

On Wed, Dec 28, 2022 at 12:10:51AM +0100, Johannes Schauer Marin Rodrigues 
wrote:
> Note, that if you keep upgrading a Debian unstable chroot across multiple
> releases, it will end up looking slightly different than a freshly
> debootstrapped Debian unstable chroot. So I think there is value in
> semi-regularly re-creating the build chroot from scratch. Maybe write a script
> that does what you need?

That's true, but the number of user/group id's that sbuild would
actually care about is probably quite small and might very well just
be sbuild:sbuild I would think, no?

> Finally, I think this is something that could be solved in sbuild. Ultimately,
> schroot is able to do things as the root user, so it should have sufficient
> permissions to fix up a chroot that carries incorrect permissions. Could you
> quickly note in a bug against sbuild on the Debian BTS which steps exactly you
> carried out so that I am able to reproduce your problem?

Sure, no problem.

> I'm making no promises that I'll find the time to improve the schroot backend
> of sbuild to survive the kind of chroot-rsync that you have performed but if
> this is important to you, then maybe we can make a trade and I implement this
> sbuild functionality and you have a look at pull requests
> https://github.com/tytso/e2fsprogs/pull/118 or #107 and leave some comments in
> return? :)

Thanks for the reminder, I'll take a look.  Most of the patch
proposals for e2fsprogs end up going to linux-e...@vger.kernel.org (so
that other ext4 developers can review them), and I sometimes forgot to
look over the github pull requests.

I'm also about to go on a Panama Canal cruise, where my internet
access may be limited (which is why I was trying to get sbuild setup
on my laptop in the first place :-), and e-mail has the advantage of
being much easily cacheable using offlineimap...

- Ted

Re: Help trying to debug an sbuild failure?

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Theodore Ts'o (2022-12-27 05:19:45)
> On Mon, Dec 26, 2022 at 08:45:53PM +0100, Santiago Vila wrote:
> > El 26/12/22 a las 20:29, Theodore Ts'o escribió:
> > > I: The directory does not exist inside the chroot.
> > 
> > This is really a problem with schroot. I guess that this will not work 
> > either:
> > 
> > schroot -c the-chroot-name
> > 
> > This usually works when you are in your $HOME because this file:
> > 
> > /etc/schroot/default/fstab
> 
> Nope, that's not the issue; yes, /tmp and /home are missing form
> /etc/schroot/sbuild/fstab, but that was true on the *working* setup as
> well, and from what I can tell; that's deliberate.  It looks like the
> goal is to keep things hermetic when building with sbuild, so it's a
> feature that there aren't random directories leaking through from the
> host to the sbuild enviroment.

that is correct. :)

> I think I've figured out the issue.  The problem is that the user and group
> id's for sbuild are different on my desktop and my laptop, and I did an rsync
> to copy the /chroot directories from my desktop to my laptop --- and it
> appears that sbuild is very sensisitve about the user id's being the same
> across the host and chroot environments.
> 
> Apparently sbuild copies the files for the package it is building over
> a directory in /var/lib/sbuild/build, with the permissions being mode
> 770, and that is what sbuild bind mounts into the chroot.  If my
> theory is correct, if the user/group id's are different from between
> the base /etc/passwd and chroot, then things go bad in a hurry.

I think your analysis makes sense.

> >From my working system (while gbp buildpackage was running sbuild):
> 
> % ls -al /var/lib/sbuild/build/
> total 12
> 4 drwxrws--- 3 sbuild sbuild 4096 Dec 26 23:05 ./
> 4 drwxrws--- 4 sbuild sbuild 4096 Dec 19  2020 ../
> 4 drwxrwx--- 3 tytso  sbuild 4096 Dec 26 23:05 f2fs-tools-oT4KHz/
> 
> Amd on the broken (laptop) system:
> 
> # ls -al /var/lib/sbuild/build/
> total 32
> 4 drwxrws--- 8 fwupd-refresh Debian-exim 4096 Dec 26 22:48 ./
> 4 drwxrws--- 4 sbuildsbuild  4096 Dec 25 14:45 ../
> 4 drwxrwx--- 2 tytso Debian-exim 4096 Dec 26 14:01 f2fs-tools-9QfprK/
> 4 drwxrwx--- 2 tytso Debian-exim 4096 Dec 26 16:01 f2fs-tools-btkVPv/
> 4 drwxrwx--- 2 tytso Debian-exim 4096 Dec 26 14:20 f2fs-tools-cVTRAh/
> 4 drwxrwx--- 2 tytso Debian-exim 4096 Dec 26 22:48 f2fs-tools-Myld8j/
> ...
> 
> Each of were created from a failed sbuild invocation...  And
> "Debian-exim" on my laptop has the same group id as "sbuild" on my
> desktop (and which is the group id in my chroots).
> 
> This also explains the error message:
> 
> E: Failed to change to directory ‘/<>’: Permission denied
> 
> Oops.
> 
> So I guess I need to either manually juggle group id's in the chroots
> (and/or my laptop's root directory --- but it's probably easier to do
> it in the chroots, since there are fewer filees to chgrp in the
> chroots), or I could recreate the sbuild chroots from scratch using
> sbuild-createchroot (but then I would need to recreate all of the
> custom hacks so that ccache,eatmydata, apt-auto-proxy, etc. are working
> correctly in the chroot).
> 
> What fun

Note, that if you keep upgrading a Debian unstable chroot across multiple
releases, it will end up looking slightly different than a freshly
debootstrapped Debian unstable chroot. So I think there is value in
semi-regularly re-creating the build chroot from scratch. Maybe write a script
that does what you need?

That being said, I think the biggest problem is, that the main sbuild
contributors these days (me and Jochen) do not use the schroot backend anymore
but the unshare backend instead which doesn't suffer from this kind of problem
(but of course has different quirks that one needs to be aware of). So I must
admit that in the past few years, the schroot backend hasn't gotten the love
that it deserves considering that it's the default backend used on the buildd
machinery.

Finally, I think this is something that could be solved in sbuild. Ultimately,
schroot is able to do things as the root user, so it should have sufficient
permissions to fix up a chroot that carries incorrect permissions. Could you
quickly note in a bug against sbuild on the Debian BTS which steps exactly you
carried out so that I am able to reproduce your problem?

I'm making no promises that I'll find the time to improve the schroot backend
of sbuild to survive the kind of chroot-rsync that you have performed but if
this is important to you, then maybe we can make a trade and I implement this
sbuild functionality and you have a look at pull requests
https://github.com/tytso/e2fsprogs/pull/118 or #107 and leave some comments in
return? :)

Thanks!

cheers, josch

signature.asc
Description: signature

Re: Help trying to debug an sbuild failure?

[Theodore Ts'o]

On Mon, Dec 26, 2022 at 08:45:53PM +0100, Santiago Vila wrote:
> El 26/12/22 a las 20:29, Theodore Ts'o escribió:
> > I: The directory does not exist inside the chroot.
> 
> This is really a problem with schroot. I guess that this will not work either:
> 
> schroot -c the-chroot-name
> 
> This usually works when you are in your $HOME because this file:
> 
> /etc/schroot/default/fstab

Nope, that's not the issue; yes, /tmp and /home are missing form
/etc/schroot/sbuild/fstab, but that was true on the *working* setup as
well, and from what I can tell; that's deliberate.  It looks like the
goal is to keep things hermetic when building with sbuild, so it's a
feature that there aren't random directories leaking through from the
host to the sbuild enviroment.

I think I've figured out the issue.  The problem is that the user and
group id's for sbuild are different on my desktop and my laptop, and I
did an rsync to copy the /chroot directories from my desktop to my
laptop --- and it appears that sbuild is very sensisitve about the
user id's being the same across the host and chroot environments.

Apparently sbuild copies the files for the package it is building over
a directory in /var/lib/sbuild/build, with the permissions being mode
770, and that is what sbuild bind mounts into the chroot.  If my
theory is correct, if the user/group id's are different from between
the base /etc/passwd and chroot, then things go bad in a hurry.

>From my working system (while gbp buildpackage was running sbuild):

% ls -al /var/lib/sbuild/build/
total 12
4 drwxrws--- 3 sbuild sbuild 4096 Dec 26 23:05 ./
4 drwxrws--- 4 sbuild sbuild 4096 Dec 19  2020 ../
4 drwxrwx--- 3 tytso  sbuild 4096 Dec 26 23:05 f2fs-tools-oT4KHz/

Amd on the broken (laptop) system:

# ls -al /var/lib/sbuild/build/
total 32
4 drwxrws--- 8 fwupd-refresh Debian-exim 4096 Dec 26 22:48 ./
4 drwxrws--- 4 sbuildsbuild  4096 Dec 25 14:45 ../
4 drwxrwx--- 2 tytso Debian-exim 4096 Dec 26 14:01 f2fs-tools-9QfprK/
4 drwxrwx--- 2 tytso Debian-exim 4096 Dec 26 16:01 f2fs-tools-btkVPv/
4 drwxrwx--- 2 tytso Debian-exim 4096 Dec 26 14:20 f2fs-tools-cVTRAh/
4 drwxrwx--- 2 tytso Debian-exim 4096 Dec 26 22:48 f2fs-tools-Myld8j/
...

Each of were created from a failed sbuild invocation...  And
"Debian-exim" on my laptop has the same group id as "sbuild" on my
desktop (and which is the group id in my chroots).

This also explains the error message:

E: Failed to change to directory ‘/<>’: Permission denied

Oops.

So I guess I need to either manually juggle group id's in the chroots
(and/or my laptop's root directory --- but it's probably easier to do
it in the chroots, since there are fewer filees to chgrp in the
chroots), or I could recreate the sbuild chroots from scratch using
sbuild-createchroot (but then I would need to recreate all of the
custom hacks so that ccache,eatmydata, apt-auto-proxy, etc. are working
correctly in the chroot).

What fun

- Ted

p.s.  I guess if I had been planning ahead I would have made sure that
various system users and groups which are auto-created by packages at
install-time (and which are therefore different depending on install
order) were pre-created on my laptop with the same numerical id's as
on my desktop, since that would have avoided all *sorts* of random
problems, especially if I was going to play games with copying chroots
around --- or trying to use NFS --- and not getting taken by surprise
by this sort of thing.  Live and learn

Re: Help trying to debug an sbuild failure?

[Santiago Vila]

El 26/12/22 a las 20:29, Theodore Ts'o escribió:

I: The directory does not exist inside the chroot.


This is really a problem with schroot. I guess that this will not work either:

schroot -c the-chroot-name

This usually works when you are in your $HOME because this file:

/etc/schroot/default/fstab

has a line like this:

/home   /home   nonerw,bind 0   0

which makes a bind mount and makes /home to "exist" inside the chroot.

So the solution is to either try sbuild from a directory which is
bind-mounted like that, like $HOME, or add a new entry to fstab
with the directory you need.

Hope this helps.

Help trying to debug an sbuild failure?

[Theodore Ts'o]

Hi, I'm trying to figure out an sbuild failure on my laptop.  The
sbuild environment from replicated from my desktop where things work
perfectly well.  But in my laptop, things are failing at the 
"Setup apt archive" step with

   E: Failed to change to directory ‘/<>’: Permission denied

And I'm completely at a loss trying to figure out what might be going
wrong.  Can anyone give me some hints about what to look for?

Thanks,

- Ted



sbuild (Debian sbuild) 0.84.2 (08 December 2022) on letrec.thunk.org

+==+
| f2fs-tools 1.15.0-1 (amd64)  Mon, 26 Dec 2022 19:20:17 + |
+==+

Package: f2fs-tools
Version: 1.15.0-1
Source Version: 1.15.0-1
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: full

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-a67a3165-6688-4368-a376-66e094e41dfa'
 with '<>'
I: NOTICE: Log filtering will replace 'build/f2fs-tools-cVTRAh/resolver-CwG6Va' 
with '<>'

+--+
| Update chroot|
+--+

Get:1 http://httpredir.debian.org/debian unstable InRelease [161 kB]
Get:2 http://httpredir.debian.org/debian unstable/main Sources.diff/Index [63.6 
kB]
Get:3 http://httpredir.debian.org/debian unstable/main amd64 
Packages.diff/Index [63.6 kB]
Get:4 http://httpredir.debian.org/debian unstable/main Sources 
T-2022-12-26-1404.34-F-2022-12-26-0804.45.pdiff [15.0 kB]
Get:4 http://httpredir.debian.org/debian unstable/main Sources 
T-2022-12-26-1404.34-F-2022-12-26-0804.45.pdiff [15.0 kB]
Get:5 http://httpredir.debian.org/debian unstable/main amd64 Packages 
T-2022-12-26-1404.34-F-2022-12-26-0804.45.pdiff [33.2 kB]
Get:5 http://httpredir.debian.org/debian unstable/main amd64 Packages 
T-2022-12-26-1404.34-F-2022-12-26-0804.45.pdiff [33.2 kB]
Fetched 337 kB in 1s (238 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Local sources
-

/tmp/gbp/f2fs-tools_1.15.0-1.dsc exists in /tmp/gbp; copying to chroot
I: NOTICE: Log filtering will replace 
'build/f2fs-tools-cVTRAh/f2fs-tools-1.15.0' with '<>'
I: NOTICE: Log filtering will replace 'build/f2fs-tools-cVTRAh' with 
'<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper-compat (= 13), libblkid-dev, libselinux1-dev, 
pkg-config, uuid-dev, build-essential, fakeroot
Filtered Build-Depends: debhelper-compat (= 13), libblkid-dev, libselinux1-dev, 
pkg-config, uuid-dev, build-essential, fakeroot
E: Failed to change to directory ‘/<>’: Permission denied
I: The directory does not exist inside the chroot.  Use the --directory option 
to run the command in a different directory.
Dummy package creation failed
E: Setting up apt archive failed

Setup apt archive
-

Merged Build-Depends: dose-distcheck
Filtered Build-Depends: dose-distcheck
E: Failed to change to directory ‘/<>’: Permission denied
I: The directory does not exist inside the chroot.  Use the --directory option 
to run the command in a different directory.
Dummy package creation failed
E: Setting up apt archive failed
E: Failed to explain bd-uninstallable

+--+
| Summary  |
+--+

Build Architecture: amd64
Build Type: full
Build-Space: n/a
Build-Time: 0
Distribution: unstable
Fail-Stage: explain-bd-uninstallable
Host Architecture: amd64
Install-Time: 0
Job: /tmp/gbp/f2fs-tools_1.15.0-1.dsc
Machine Architecture: amd64
Package: f2fs-tools
Package-Time: 0
Source-Version: 1.15.0-1
Space: n/a
Status: given-back
Version: 1.15.0-1

Finished at 2022-12-26T19:20:17Z
Build needed 00:00:00, no disk space