Bug#1064340: Re: Bug#1064340: RFS: kylin-nm/4.0.0.0-1 -- Gui Applet tool for display and edit network simply

[Tobias Frost]

On Tue, May 21, 2024 at 05:15:09PM +0800, handsome_feng wrote:
> Hi,
> 
> 
> > The NMU has not been incorporated.
> Sorry, I didn't quite understand this point. Did someone request an NMU?
I stand correctred, it was not a NMU, but the changelog entry for 3.0.3.1-1 was 
not in d/changelog.

Bug#1064340: RFS: kylin-nm/4.0.0.0-1 -- Gui Applet tool for display and edit network simply

[Tobias Frost]

Control: tags -1 moreinfo

Hi,

- The NMU has not been incorporated.
- There are undocumented changes. Some are very confusing.
  - Why the move from github to gitlab?
  - Why the uploaders change? Is this authorized?
  -  Upstream Contact Changed from a team email to your mail?

What's going on here? 

- There is neither a response for #1070113, nor has it been adressed.


(It seems also that all documents moved aways from English to Chinese?)

-- 
tobi

On Tue, Feb 20, 2024 at 03:53:24PM +0800, xibowen wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "kylin-nm":
> 
>  * Package name : kylin-nm
>Version  : 4.0.0.0-1
>Upstream contact : xibowen 
>  * URL  : https://gitee.com/openkylin/kylin-nm
>  * License  : GPL-2+, BSD-3-clause, GPL-3+
>  * Vcs  : https://gitee.com/openkylin/kylin-nm
>Section  : utils
> 
> The source builds the following binary packages:
> 
>   kylin-nm - Gui Applet tool for display and edit network simply
>   kylin-nm-plugin - Gui Applet plugin for display and edit network simply
>   kylin-nm-plugin-dev - Gui Applet development for display and edit network 
> simply
>   libkylin-nm-base - Gui lib for display and edit network simply
>   libkylin-nm-base-dev - Gui lib development for display and edit network 
> simply
> 
> To access further information about this package, please visit the following 
> URL:
> 
>   https://mentors.debian.net/package/kylin-nm/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/k/kylin-nm/kylin-nm_4.0.0.0-1.dsc
> 
> Changes since the last upload:
> 
>  kylin-nm (4.0.0.0-1) unstable; urgency=medium
>  .
>* New upstream release.
> 
> This package is depended on ukui-greeter and ukui-screensaver.
> 
> Regards,
> -- 
>   xibowen

Bug#1067595: RFS: psocksxx/1.1.1-5 -- psocksxx is a C++ wrapper for POSIX sockets

[Tobias Frost]

Control: tags -1 moreinfo

On Sun, Mar 24, 2024 at 10:23:53AM +0100, Jörg Frings-Fürst wrote:
>  psocksxx (1.1.1-5) unstable; urgency=medium
>  .
>    * debian/control:
>  - Fix git URL.

Hi Jörg,

can you provide a secure URL for VCS-Git, please?

Thanks!

--
tobi

Bug#1069942: RFS: imsprog/1.3.7-1 -- Linux chip programmer for CH341a devices

[Tobias Frost]

On Sat, May 18, 2024 at 09:42:56PM +0200, Fabio Fantoni wrote:
> On Thu, 16 May 2024 12:47:44 +0200 Tobias Frost  wrote:
> > >
> > >   * Don't fixed: P: imsprog source:
> > > package-uses-old-debhelper-compat-version 12 - I want to maintain
> > > compatibility for |Jammy| and |Focal| releases.
> >
> > If you package for different distributions, let me recommend me to utilize
> > dedicated branches for those, for example by following the DEP14 proposal;
> > this will allow to optimize for the different Debian derivates.
> >
> > For a Debian upload, please use a acutal compat level; >12 has a lots of
> > benefits.
> 
> Hi, I think compat 12 is not too old and can be keeped for now to make
> possible to do unofficial build and individual build (any people also
> without experience) on multiple Debian versions and derivatives still
> supported easier and faster using debian/latest.

I disagree.

Uploads to Debian are aimed for the next stable, not for old releases, therefore
they should follow the current best practices, and this is not compat 12.

DEP14 is designed to cater older (and other distributions), this would be a
compromise. Also, debhelper is very often backported to older released, so
many people will not even need to change back to an older compat level.
Even Jammie and Focal have debhelper 13 available.

IMHO There is no reason to stay at 12; while others might, I'll certainly will
not sponsor level 12.
 
> About creation of other packaging branches following DEP14 I think is good
> only for official build (for example possible official backports), but
> before I think is good update the package to 1.3.9-1 before consider doing
> official backports and don't backports of 1.3.2-1.

DEP14 is not only for backports, but also for other distributions, like Ubuntu, 

-- 
tobi

Bug#1069942: RFS: imsprog/1.3.7-1 -- Linux chip programmer for CH341a devices

[Tobias Frost]

Hi,

thanks for working on the package!

> Hello, Tobias!
> I've done some work on the bugs :)
> 
> In version v1.3.9:
> 
>   * Fixed: There is a spelling error "copyed" in in 99-CH341.rules.
>   * Fixed (metadata changed): W: imsprog:
> appstream-metadata-missing-modalias-provide
> usr/lib/udev/rules.d/99-CH341.rules
>   * Fixed: As you are upstream, you could wrap README.md at 80 chars
per
> line :)
>   * Fixed: src:imsprog: Does not rebuild qt language files
> 
>   * Don't fixed: P: imsprog source:
> package-uses-old-debhelper-compat-version 12 - I want to maintain
> compatibility for |Jammy| and |Focal| releases.

If you package for different distributions, let me recommend me to utilize
dedicated branches for those, for example by following the DEP14 proposal;
this will allow to optimize for the different Debian derivates.

For a Debian upload, please use a acutal compat level; >12 has a lots of
benefits.

-- 
tobi


 
> Please check this package and send me Lintian's warnings.
> Regards, Mikhail
 

Bug#1070991: RFS: libcdio-paranoia/10.2+2.0.2-1 -- audio CD reading utility which includes extra data verification features

[Tobias Frost]

Hi Phillippe,

a short review:

- package could use some modernization:
  - it is still using d/compat, at the very old level 11
  - d/copyright is not dep5 

Would be cool if you could update those parts.

-- 
tobi


On Sun, May 12, 2024 at 05:45:13PM +0200, Philippe SWARTVAGHER wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "libcdio-paranoia":
> 
>  * Package name : libcdio-paranoia
>Version  : 10.2+2.0.2-1
>Upstream contact : [fill in name and email of upstream]
>  * URL  : https://www.gnu.org/software/libcdio/
>  * License  : [fill in]
>  * Vcs  : https://salsa.debian.org/debian/libcdio-paranoia
>Section  : libs
> 
> The source builds the following binary packages:
> 
>   libcdio-cdda-dev - library to read and control digital audio CDs
> (development files)
>   libcdio-cdda2t64 - library to read and control digital audio CDs
>   libcdio-paranoia-dev - library to read digital audio CDs with error
> correction (development files)
>   libcdio-paranoia2t64 - library to read digital audio CDs with error
> correction
>   cd-paranoia - audio CD reading utility which includes extra data
> verification features
> 
> To access further information about this package, please visit the
> following URL:
> 
>   https://mentors.debian.net/package/libcdio-paranoia/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>   dget -x
> https://mentors.debian.net/debian/pool/main/libc/libcdio-paranoia/libcdio-paranoia_10.2+2.0.2-1.dsc
> 
> Changes since the last upload:
> 
>  libcdio-paranoia (10.2+2.0.2-1) unstable; urgency=medium
>  .
>[ Debian Janitor ]
>* Remove constraints unnecessary since buster (oldstable):
>  + Build-Depends: Drop versioned constraint on libcdio-dev.
>  + libcdio-cdda-dev: Drop versioned constraint on libcdio-dev in
> Depends.
>  + libcdio-paranoia-dev: Drop versioned constraint on libcdio-dev
> in Depends.
>  + cd-paranoia: Drop versioned constraint on libcdio-utils in Replaces.
>  + cd-paranoia: Drop versioned constraint on libcdio-utils in Breaks.
>  .
>[ Philippe SWARTVAGHER ]
>* d/control: update Build-Depends packages, as suggested by Lintian
>* New upstream release
>  - Drop all patches (applied upstream).
>  - Closes: #981017.
>* Bump Standards-Version to 4.7.0 (no change)
>* Add patches to fix typos
> 
> Regards,
> --
>   Philippe
> 

Bug#1069906: RFS: vzlogger/0.8.5-1 -- Fixes for the migration to testing

[Tobias Frost]

Control: tags -1 moreinfo

Hi Joachim,

On Sun, May 12, 2024 at 01:59:22PM +0200, Joachim Zobel wrote:
> 
> An updated 0.8.5-1 has been uploaded.

It's nice that you've picked up my suggestions regarding the README.md…
However, recycling upstream version numbers (as upstream) should be
avoided, as there are now two 0.8.5 in the world. Please avoid that.

The watch file is not working:
tobi@gondor:~/workspace/deb/mentors/JoachimZobel/vzlogger/debcheckout/vzlogger$ 
uscan --force-download
uscan warn: In directory ., downloading
  
https://github.com/volkszaehler/vzlogger/releases/download/v0.8.5/vzlogger-0.8.5.tar.gz
 failed: 404 Not Found
uscan warn: No upstream tarball downloaded. No further processing with 
mk_origtargz ...

(Tagging moreinfo because of the watchfile.)
 
> Sincerely,
> Joachim
> 

Bug#1069906: RFS: vzlogger/0.8.5-1 -- Fixes for the migration to testing

[Tobias Frost]

On Sun, May 12, 2024 at 01:59:22PM +0200, Joachim Zobel wrote:
> (forgotten cc)
> 
> Am Freitag, dem 03.05.2024 um 18:50 +0200 schrieb Tobias Frost:
> > reviewing your new package:
> > 
> > - d/changelog
> >   - generally documents only changes to the packaging, not "upstream"
> changes
> > (the entry "Fixed logrotate conf user name" is an upstream
> change.)
> > There are exceptions, like if it a very noteworthy change, but
> this
> > is one isn't in that category.
> >   - When packaging a new upstream version, you say so in the
> changelog.
> > (Like first changelog entry: 
> >  * New upstream version.
> > )
> >   - There are undocumented changes, for example the change to the
> > Standard-Version. 
> > 
> 
> Done.
> 
> > A nitpick on d/rules:
> >  I'm a fan of declarative syntax, so I'd replace the dh_clean
> override
> >  with specifing the file to be deleted in the file d/clean. (If you
> feel
> >  different about this, it is ok to ignore my nitpicking)
> 
> Done, thx.
> 
> > Remarks on Readme.md: 
> >   - It cointains only information not relevant when the user is
> > installing the binary package (like how to build, how to install
> and
> > where to find the packages), so it should not be installed into
> > the binary package.
> 
> Not exactly. There is the important line "Our packages are built with
> MQTT support, but without OMS support.". In addition it is a moving
> target. So I'd prefer to keep it as now.

This information would go into the long description of the package,
(README.md is not available pre-install, and this is something the
user wants to knowbeforehand; using README.md for this purpose is
very unusal in Debian.)

> >   - "Debian" is written with a captial "D".
> 
> Done.
> 
> >   - The sentence "Unfortunately Debian armhf packages do not 
> > run on Raspberry Pi 1 although the architecture on the RPi is
> named armhf.
> > Using Raspian armhf packages fixes that." is a bit hard to parse,
> a
> > bit off:
> > - Raspberry Pi 1 is supported by the Debian armel architecture,
> so people
> >   running (real) Debian on the Pi 1 need to use "armel" not
> "armhf".
> > - Paspian has been renamed to Raspberry Pi OS, so the naming
> should
> >   maybe be also updated.
> 
> Done. During the discussion more changes were added.
> 
> > Maybe this should be separated into a Debian and Raspberry Pi OS
> > section? (They are different distributions anyways…)
> 
> The handling is very similar from the users perspective.
> 
> >   
> > Some parts already mentioned for the previous upload, would be great
> if
> > you could start tackling them:
> > 
> > As you are involved with upstream:
> > The manpage, initfile, systemd service file should probably be
> included in the
> > upstream part, it is not only useful for Debian alone.
> > 
> 
> It is currently under discussion if other installation methods are
> still needed.

I'd still say README.md shouldn't end up in the binary package, as it
only covers installation topics, which are irrelevant to our users.

> > Linitian: (I've pre-filtered them a bit already on those that should
> be
> > investigaged. If harderning is working now, override the linitian I:
> tag.)
> > I: vzlogger source: debian-rules-parses-dpkg-parsechangelog
> [debian/rules:15]
> > I: vzlogger: hardening-no-bindnow [usr/bin/vzlogger]
> > I: vzlogger: systemd-service-file-missing-documentation-key
> [usr/lib/systemd/system/vzlogger.service]
> > P: vzlogger source: trailing-whitespace [debian/changelog:10]
> > P: vzlogger source: trailing-whitespace [debian/changelog:4]
> > P: vzlogger source: trailing-whitespace [debian/control:17]
> > P: vzlogger source: trailing-whitespace [debian/control:40]
> > P: vzlogger source: trailing-whitespace [debian/rules:45]
> > X: vzlogger: systemd-service-file-missing-hardening-features
> [usr/lib/systemd/system/vzlogger.service]
> > X: vzlogger source: upstream-metadata-file-is-missing
> 
> All done except for upstream-metadata-file-is-missing. I don't think
> this is of much use for a service.
> 
> An updated 0.8.5-1 has been uploaded.
> 
> Sincerely,
> Joachim
 

Bug#1070331: RFS: nq/0.5-0.1 [NMU] -- Lightweight queue system

[Tobias Frost]

On Sun, May 12, 2024 at 02:34:15PM +0200, Preuße, Hilmar wrote:
> On 11.05.2024 09:08, Tobias Frost wrote:
> 
> Hi,
> 
> > Please also announce the NMU / RFS to the package maintainer,
> > preferable as bug reported against it. Thanks!
> > 
> The package is flagged as LowNMU [1], which says:
> 
> "You don't need to contact the maintainers beforehand, and you don't need to
> use a delayed upload queue. If the package maintainer or maintainer group is
> active, it is polite to let them have a stab at fixing the problem first."
> 
> Given the fact that the last upload was 3.5 years ago I'd assume that the
> maintainers group is non-active. Hence I did not inform them.

LowNMU just says you can upload into DELAYED/0, or directly, but not
that communication is not needed beforehand. It explictly says [1]: "at any
time, as long as the NMU procedure in the Debian Developer's Reference
is otherwise followed" 
The Developers Reference [2] explictly says:
"Have you clearly expressed your intention to NMU, at least in the BTS?
If that didn't generate any feedback, it might also be a good idea to
try to contact the maintainer by other means (email to the maintainer
addresses or private email, IRC).

So, no, announcing the NMU is not optional, it is the bare minimum.


[1] https://wiki.debian.org/LowThresholdNmu
[2]

> Hilmar
> 
> [1] https://tracker.debian.org/pkg/nq
> -- 
> -- 
> sigfault
> 

--
tobi


signature.asc
Description: PGP signature

Bug#1069620: RFS: lua-mode/20231023~git-1 -- Emacs major-mode for editing Lua programs

[Tobias Frost]

Hi Xiyue,

when packaging a git snapshot, I feel this should be indicated in the
upstream version that it is based on the old one, something like
+

In your case I'd 20210802+git20231023 as upstream version.

Long time ago I did something like that for dhewm3, you 
can see the watch file here:
https://salsa.debian.org/games-team/dhewm3/-/blob/debian/1.5.0+git20181221+dfsg-1/debian/watch?ref_type=tags

(not marking moreinfo, as other people might see that differently.)

--
tobi

On Sun, Apr 21, 2024 at 10:02:48AM -0700, Xiyue Deng wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "lua-mode":
> 
>  * Package name : lua-mode
>Version  : 20231023~git-1
>Upstream contact : immerrr 
>  * URL  : https://github.com/immerrr/lua-mode
>  * License  : GPL-3+
>  * Vcs  : https://salsa.debian.org/emacsen-team/lua-mode
>Section  : lisp
> 
> The source builds the following binary packages:
> 
>   elpa-lua-mode - Emacs major-mode for editing Lua programs
> 
> To access further information about this package, please visit the following 
> URL:
> 
>   https://mentors.debian.net/package/lua-mode/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/l/lua-mode/lua-mode_20231023~git-1.dsc
> 
> Changes since the last upload:
> 
>  lua-mode (20231023~git-1) unstable; urgency=medium
>  .
>* Sync to latest upstream snapshot (d074e41)
>* Drop the patch applied upstream and reorder the remaining patch
>* Update upstream license to GPL-3+ following upstream change
>* Add a missing upstream copyright holder
> 
> Regards,
> -- 
> Xiyue Deng
> 

Bug#1068724: RFS: gensync/2.0.5-1 [ITP] -- a library for efficient synchronization of data over a network.

[Tobias Frost]

Control: reopen -1
Control: forcemerge 1069696 -1

Hi Chen,

In future, please do not file new RFS bugs, instead modify the existing
one until a package has been sponsored.

(forcemerge: FTR, the new one is #1069696, let that one be the leading one)

-- 
tobi


On Tue, Apr 09, 2024 at 06:53:58PM +, Chen, Xingyu wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "gensync":
> 
>  * Package name : gensync
>Version  : 2.0.5-1
>Upstream contact :  project>
>  * URL  : https://github.com/nislab/gensync
>  * License  : 
>  * Vcs  : [fill in URL of packaging vcs]
>Section  : libs
> 
> The source builds the following binary packages:
> 
>   gensync - a library for efficient synchronization of data over a network. 
> Gensync is a library that uses many different syncing algorithms to sync data 
> between two nodes in a network. These algorithms include IBLTs, CPISyncs, 
> HashSyncs, Cuckoo Syncs, and more.
> 
> To access further information about this package, please visit the following 
> URL:
> 
>   https://mentors.debian.net/package/gensync/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/g/gensync/gensync_2.0.5-1.dsc
> 
> Changes for the initial release:
> 
>  gensync (2.0.5-1) UNRELEASED; urgency=medium
>  .
>* Initial release (Closes: #)  
> 
> Regards,
> --
>   Kevin Chen
> 

Bug#1069083: RFS: runit-services/0.7.2 -- UNIX init scheme with service supervision (services)

[Tobias Frost]

On Tue, Apr 16, 2024 at 09:39:58AM +0200, Lorenzo wrote:
> Control: block -1 by 1067525
> 
> this fix need to go to unstable because elogind 255.4.1 is already
> there, but runit-services depends on runit > 2.1.2-56 (unstable is at
> 2.1.2-54) so 1067525 needs to be uploaded first or together with this
> one, otherwise runit-services is not installable

Ok, just saw that one.
Please note that this fact must be stated in d/changelog, something like
"Upload to unstable."

-- 
tobi

> On Tue, 16 Apr 2024 09:30:08 +0200 Lorenzo  wrote:
> > Package: sponsorship-requests
> > Severity: normal
> > 
> > Dear mentors,
> > 
> > I am looking for a sponsor for my package "runit-services":
> > 
> >  * Package name : runit-services
> >Version  : 0.7.2
> >Upstream contact : [fill in name and email of upstream]
> >  * URL  : [fill in URL of upstream's web site]
> >  * License  : BSD-3-Clause, GPL-2.0+, GPL-3+, CC0-1.0
> >  * Vcs  :
> >https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services Section
> >   : admin
> > 
> > The source builds the following binary packages:
> > 
> >   runit-services - UNIX init scheme with service supervision
> > (services)
> > 
> > To access further information about this package, please visit the
> > following URL:
> > 
> >   https://mentors.debian.net/package/runit-services/
> > 
> > Alternatively, you can download the package with 'dget' using this
> > command:
> > 
> >   dget -x
> >   
> > https://mentors.debian.net/debian/pool/main/r/runit-services/runit-services_0.7.2.dsc
> > 
> > Git repo:
> >   
> > https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/tree/next?ref_type=heads
> > 
> > Changes since the last upload:
> > 
> >  runit-services (0.7.2) unstable; urgency=medium
> >  .
> >* Fix elogind service (Closes: #1069075)
> > 
> > Regards,
> > Lorenzo
> > 
> > 
> 

Bug#1069083: RFS: runit-services/0.7.2 -- UNIX init scheme with service supervision (services)

[Tobias Frost]

Control: tags -1 moreinfo

Hi Lorenzo,

the last uploads where to experimental, this one targets unstable but
that is not mentioned in the changelog, so I guess this was accidential?

-- 
tobi

On Tue, Apr 16, 2024 at 09:30:08AM +0200, Lorenzo wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "runit-services":
> 
>  * Package name : runit-services
>Version  : 0.7.2
>Upstream contact : [fill in name and email of upstream]
>  * URL  : [fill in URL of upstream's web site]
>  * License  : BSD-3-Clause, GPL-2.0+, GPL-3+, CC0-1.0
>  * Vcs  :
>https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services Section
>   : admin
> 
> The source builds the following binary packages:
> 
>   runit-services - UNIX init scheme with service supervision (services)
> 
> To access further information about this package, please visit the
> following URL:
> 
>   https://mentors.debian.net/package/runit-services/
> 
> Alternatively, you can download the package with 'dget' using this
> command:
> 
>   dget -x
>   
> https://mentors.debian.net/debian/pool/main/r/runit-services/runit-services_0.7.2.dsc
> 
> Git repo:
>   
> https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/tree/next?ref_type=heads
> 
> Changes since the last upload:
> 
>  runit-services (0.7.2) unstable; urgency=medium
>  .
>* Fix elogind service (Closes: #1069075)
> 
> Regards,
> Lorenzo
> 

Bug#1069696: RFS: gensync/2.0.5-1 [ITP] -- a library for efficient synchronization of data over a network.

[Tobias Frost]

Control: tags -1 moreinfo

Hi Chen,

please take a look at [1] -- the page indicates a lots of problems
with your package, especially the lintian errors, warnings and
informational tags. That means your package is not yet ready to
be reviewed in depth.

Please fix those linitian erros, then remove the moreinfo tag.
 
As you seems to be upstream, please read https://wiki.debian.org/UpstreamGuide

Cheers,
-- 
tobi



[1] https://mentors.debian.net/package/gensync/


On Mon, Apr 22, 2024 at 09:43:03PM +, Chen, Xingyu wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "gensync":
> 
>  * Package name : gensync
>Version  : 2.0.5-1
>Upstream contact : Kevin Chen 
>  * URL  : https://github.com/nislab/gensync-lib
>  * License  : GPL
>  * Vcs  :
>Section  : libs
> 
> The source builds the following binary packages:
> 
>   gensync - a library for efficient synchronization of data over a network. 
> Gensync is a library that uses many different syncing algorithms to sync data 
> between two nodes in a network. These algorithms include IBLTs, CPISyncs, 
> HashSyncs, Cuckoo Syncs, and more.
> 
> To access further information about this package, please visit the following 
> URL:
> 
>   https://mentors.debian.net/package/gensync/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/g/gensync/gensync_2.0.5-1.dsc
> 
> Changes for the initial release:
> 
>  gensync (2.0.5-1) UNRELEASED; urgency=medium
>  .
>* Initial release (Closes: #1069684)  
> 
> Regards,
> --
>   Kevin Chen
> 
> 

Bug#1069942: RFS: imsprog/1.3.7-1 -- Linux chip programmer for CH341a devices

[Tobias Frost]

Control: tags -1 moreinfo

Hi Mikhail,

Thanks for the update. There is one thing I'd like to fixed:
The qm language files needs to be recreated at build time.

As you are upstream, you can incoorporate that change upstream
(and drop the binary files from your tarball)

There is a spelling error "copyed" in in 99-CH341.rules.

Linitian to be checked (verified and if not a false positive fixed
otherwise overriden)

W: imsprog: appstream-metadata-missing-modalias-provide 
usr/lib/udev/rules.d/99-CH341.rules
(likekly false positive)

I: imsprog: hardening-no-bindnow [usr/bin/IMSProg]
I: imsprog: hardening-no-bindnow [usr/bin/IMSProg_editor]

P: imsprog source: package-uses-old-debhelper-compat-version 12
P: imsprog source: trailing-whitespace [debian/changelog:12]


As you are upstream, please consider signing your tarballs:
X: imsprog source: debian-watch-does-not-check-openpgp-signature [debian/watch]


As you are upstream, you could wrap README.md at 80 chars per line :)
X: imsprog source: very-long-line-length-in-source-file 577 > 512 
[README.md:103]

--
tobi

On Sat, Apr 27, 2024 at 02:19:07PM +0300, Михаил Медведев wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "imsprog":
> 
>  * Package name : imsprog
>Version  : 1.3.7-1
>Upstream contact : Mikhail medvedeve-ink-rea...@yandex.ru
>  * URL  :https://github.com/bigbigmdm/IMSProg
>  * License  : GPL-2+, GPL-3+, LGPL-2.1
>  * Vcs  :https://github.com/bigbigmdm/IMSProg/
>Section  : devel
> 
> The source builds the following binary packages:
> 
>   imsprog - Linux chip programmer for CH341a devices
> 
> To access further information about this package, please visit the following 
> URL:
> 
>   https://mentors.debian.net/package/imsprog/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>   dget 
> -xhttps://mentors.debian.net/debian/pool/main/i/imsprog/imsprog_1.3.7-1.dsc
> 
> Changes since the last upload:
> 
>  imsprog (1.3.7-1) unstable; urgency=medium
>  .
>* New upstream release
> 
> Regards,
> -- 
>   Mikhail Medvedev

Bug#1070331: RFS: nq/0.5-0.1 [NMU] -- Lightweight queue system

[Tobias Frost]

Please also announce the NMU / RFS to the package maintainer, preferable
as bug reported against it. Thanks!

On Sat, May 04, 2024 at 02:19:00PM +0200, 
=?UTF-8?Q?Preu=C3=9...@buxtehude.debian.org wrote:
> Control: block -1 by 1005961
> 
> On 03.05.2024 23:45, Christoph Biedl wrote:
> 
> Hi,
> 
> > That would be necessary - although I don't know how to solve this in a
> > sensible way.
> > 
> > Sorry for disturbing your best intentions to bring nq back in shape -
> > but this problem will not disappear by ignoring it.
> > 
> Completely agree. Let's see if there are reactions for the re-opened bug.
> 
> Hilmar
> -- 
> sigfault
> 

Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool

[Tobias Frost]

On Mon, May 06, 2024 at 08:02:17PM +0200, Daniel Gröber wrote:
> On Mon, May 06, 2024 at 02:10:53PM -0300, Lucas Castro wrote:
> 
>  [DEFAULT]
>  debian-branch = gnuabordo/latest
>  debian-tag = gnuabordo/%(version)s

Please let me suggest to use DEP14 for branch naming:
https://dep-team.pages.debian.net/deps/dep14/

--
tobi

Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool

[Tobias Frost]

On Mon, May 06, 2024 at 04:31:26PM +0200, Daniel Gröber wrote:
> Hi Lucas,
> d/changelog:
> > lsm (1.0.21-1) unstable; urgency=medium
> > .
> >   * New upstream release (Closes: #1041221)
> >   * Usrmerge compliance (Closes: #1054086)
> 
> Could be more specific. "Use dh_installsystemd to install units" maybe?
> 
> >   * Package rename
> 
> Use imperative in changelogs and be more specific: "Rename package to
> 'foolsm' to stay consistent with upstream" or some such.
> 
> >  - Added transitional package for renaming process
> 
> More specific please. I'd go with straight prose and not bullet-points
> myself. Say: "The old 'lsm' package is now transitional and installs the
> new 'foolsm' package.
> 
> >  - Debian package was modified after upstream project rename.
> 
> I'm not sure what you're trying to tell me here?
> 
> >   * debian/watch updated
> >   * debian/patches/ cleaned out
> 
> IMO these are implied. Ofc. we're going to do that when we update a package
> in Debian so while these would make good git commits I don't think they
> should be in d/changelog since that's mostly user-facing.
> 
> Maybe that's just my git sensibilities showing and it's perfectly
> appropriate to note this in d/changelog for the old dsc focused workflow?
> Feel free to rebuttle this point.
> 
d/changelog should reflect all changes made to the packaging, so if
d/watch and d/patches are changed, it should be mentioned in d/changelog

However, the changelog should say "WHY" something has changed.
Do "d/watch updated" should be improved to "updated d/watch due to $x"
or like.
Same for d/parchs: Explain the why - for example "patch abc.patch has
been removed, applied upstream".

--
tobi

Bug#1069906: RFS: vzlogger/0.8.5-1 -- Fixes for the migration to testing

[Tobias Frost]

Control: tags -1 moreinfo

Hi Joachim,

reviewing your new package:

- d/changelog
  - generally documents only changes to the packaging, not "upstream" changes
(the entry "Fixed logrotate conf user name" is an upstream change.)
There are exceptions, like if it a very noteworthy change, but this
is one isn't in that category.
  - When packaging a new upstream version, you say so in the changelog.
(Like first changelog entry: 
 * New upstream version.
)
  - There are undocumented changes, for example the change to the
Standard-Version. 

A nitpick on d/rules:
 I'm a fan of declarative syntax, so I'd replace the dh_clean override
 with specifing the file to be deleted in the file d/clean. (If you feel
 different about this, it is ok to ignore my nitpicking)

Remarks on Readme.md: 
  - It cointains only information not relevant when the user is
installing the binary package (like how to build, how to install and
where to find the packages), so it should not be installed into
the binary package.
  - "Debian" is written with a captial "D".
  - The sentence "Unfortunately Debian armhf packages do not 
run on Raspberry Pi 1 although the architecture on the RPi is named armhf.
Using Raspian armhf packages fixes that." is a bit hard to parse, a
bit off:
- Raspberry Pi 1 is supported by the Debian armel architecture, so people
  running (real) Debian on the Pi 1 need to use "armel" not "armhf".
- Paspian has been renamed to Raspberry Pi OS, so the naming should
  maybe be also updated.

Maybe this should be separated into a Debian and Raspberry Pi OS
section? (They are different distributions anyways…)

  
Some parts already mentioned for the previous upload, would be great if
you could start tackling them:

As you are involved with upstream:
The manpage, initfile, systemd service file should probably be included in the
upstream part, it is not only useful for Debian alone.

Linitian: (I've pre-filtered them a bit already on those that should be
investigaged. If harderning is working now, override the linitian I: tag.)
I: vzlogger source: debian-rules-parses-dpkg-parsechangelog [debian/rules:15]
I: vzlogger: hardening-no-bindnow [usr/bin/vzlogger]
I: vzlogger: systemd-service-file-missing-documentation-key 
[usr/lib/systemd/system/vzlogger.service]
P: vzlogger source: trailing-whitespace [debian/changelog:10]
P: vzlogger source: trailing-whitespace [debian/changelog:4]
P: vzlogger source: trailing-whitespace [debian/control:17]
P: vzlogger source: trailing-whitespace [debian/control:40]
P: vzlogger source: trailing-whitespace [debian/rules:45]
X: vzlogger: systemd-service-file-missing-hardening-features 
[usr/lib/systemd/system/vzlogger.service]
X: vzlogger source: upstream-metadata-file-is-missing


-- 
Cheers,
tobi

On Fri, Apr 26, 2024 at 10:37:26PM +0200, Joachim Zobel wrote:
> Package: sponsorship-requests  
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "vzlogger":
> 
> * Package name : vzlogger  
> Version  : 0.8.5-1  
> Upstream contact : Joachim Zobel   
> * URL  : 
> http://wiki.volkszaehler.org/software/controller/vzlogger  
> * License  : GPL-3.0-or-later 
> * Vcs  : https://github.com/volkszaehler/vzlogger/tree/debian  
> Section  : net
> 
> The source builds the following binary packages:
> 
> vzlogger - program for logging measurements of smart meters
> 
> To access further information about this package, please visit the following 
> URL:
> 
> http://www.heute-morgen.de/debian/repo/unstable/main/source/net/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
> dget -x 
> http://www.heute-morgen.de/debian/repo/unstable/main/source/net/vzlogger_0.8.5-1.dsc
> 
> Changes since the last upload:
> 
>   * Fixed logrotate conf user name
>   * Fixed passing of hardening flags to cmake 
> 
> Regards,  
> --  
> Joachim Zobel
> 


signature.asc
Description: PGP signature

Bug#1068436: transmission RFS

[Tobias Frost]

On Sat, Apr 06, 2024 at 06:43:08PM +, Barak A. Pearlmutter wrote:
> Well, given that the main maintainer dropped themselves from the
> debian/control file, I think the package can be freely adopted,
> keeping Leo Antunes on of course in case he reappears. I'll drop the
> two of them a note asking for objections, and assuming there are none,
> I'd suggest we go ahead with that. What do you think? This would be:
> 
> Maintainer: Leo Antunes 
> Uploaders: Alexandre Rossi ,
>Barak A. Pearlmutter 
> 
> and would allow "proper" uploads, not just NMUs.

Note that the package is in the debian namespace on salsa. No need
to NMU, team-uploads can be done by everyone. [1]

[1] 
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group

-- 
tobi

Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool

[Tobias Frost]

Control: tags -1 moreinfo

The source package name is still being renamed, and the source package
rename is not explictly stated in the changelog.

(I think this renane shouldn't be done, to keep the history of the
package, not only the tracker but also the BTS and all the other
services working on source packages.)

(You should also bump the timestamp in the d/changelog, when uploading a
new package to mentors.)

The patch in package should be fowarded; as it only changes *comments*,
consider dropping it completly.

--
tobi

On Thu, 14 Mar 2024 22:25:04 -0300 Lucas Castro 
wrote:
> 
> Em 06/03/2024 05:49, Daniel Gröber escreveu:
> > Hi Lucas,
> >
> > On Tue, Mar 05, 2024 at 03:29:49PM -0300, Lucas Castro wrote:
> >>> Are you sure you want to change the source package name? Doing so
fractures
> >>> the history of the package on tracker.d.o and it's not really
necessary.
> >> The upstream has changed software name but it's a good point about
> >> tracker.d.o.
> > Right, so users will try to `apt install foolsm` in the future, but
the
> > source package name is largeley irellevant to them.
> >
> >>> Quick package review:
> >>>
> >>>    - d/postinst: I don't think it's useful to print the message
about editing
> >>>  the config. I've only seen packages do that in special
circumstances, do
> >>>  you have a justification for it being necessary here?
> >> Really, really not. I really would like improve that, I guess to
write good
> >> doc and manual pages is enough.
> > I would argue users (sysadmins in this case) are going to be
familiar with
> > the concept of having to configure a package before it becomes
useful and
> > while the daemon not being started at package installation is
> > unconventional in Debian automatic config reloading is by far not
universal
> > so any config change to make lsm useful is going to elicit a restart
> > anyway.
> >
> > So I just don't see why we'd want a conspicuous message telling
people what
> > they already know :)
> >
> >>>    - You declare Replaces+Conflicts on lsm but you don't seem to
take any
> >>>  care for the new binary package to actually be compatible
with the old
> >>>  one since the config location changed.
> >> I'm in doubt, when the old config exist, if set dpkg to copy the
old config
> >> from old location to the new one or if I just print/show up a
message to
> >> users notifying about path update requirement.
> > I think an automatic upgrade is the way to go in this case as long
as the
> > config format is still fully compatible to the old lsm-1.0.4, but
since
> > copying will leave cruft behind for the user to cleanup manually I
think we
> > should mv the config.
> >
> >> If it's good/allowed do the copy, it could be applied in postinst.
I think
> >> print/show up message is rightest way.
> > Consider that people upgrade Debian systems for many, many years
without
> > reinstalling. So every bit of cruft we leave behind due to
transitions such
> > as this accumulates. I don't see a technical need for not doing so
in this
> > case so I think we should clean up behind ourselves and move the
config to
> > the new location.
> >
> > You should then absoluteley print a message in the log to note this
fact,
> > but perhaps not as conspicuously as you're printing the "configure
me"
> > message. Something like "Moving $OLD_PATH to $NEW_PATH" should
suffice
> > since the package(s) involved should be obvious from the filenames.
> 
> Just uploaded to mentors again, now the update occur smoothly.
> 
> 
> >
> > --Daniel
> 
> Thanks for taking time on testing update.

Bug#1067127: marked as done (RFS: emacs-cmake-mode/3.28.3+ds-1 [Team] -- Emacs major mode for editing CMake sources)

[Tobias Frost]

Control: reopen -1
Control: retitle -1 RFS: emacs-cmake-mode/3.29.0+ds-1 [Team] -- Emacs major 
mode for editing CMake sources
Control: forcemerge -1 1067530

> Date: Sat, 23 Mar 2024 00:15:55 -0700
> From: Xiyue Deng 
> To: 1067127-d...@bugs.debian.org
> Subject: Re: Bug#1067127: Acknowledgement (RFS:
>  emacs-cmake-mode/3.28.3+ds-1 [Team] -- Emacs major mode for editing CMake
>  sources)
> User-Agent: Gnus/5.13 (Gnus v5.13)
> 
> 3.29.0 has just been released.  Will send a new RFS.

Please do not open new RFS when the old one has not been sponsored.
Instead, use the old one and update it accordingly.

Thanks!

> -- 
> Xiyue Deng

Bug#1067426: Package sponsorship request Qucs-S

[Tobias Frost]

Control: tags -1 moreinfo

Hi Vadim,

On Thu, Mar 21, 2024 at 04:56:43PM +0300, Vadim Kuznetsov wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> I am looking for a sponsor for my package "qucs-s":
> 
> * Package name : qucs-s
>    Version : 24.1.0-1
>    Upstream contact : Vadim Kuznetsov 
> * URL : https://github.com/ra3xdh/qucs_s
> * License : GPL-2.0
> * Vcs : https://github.com/ra3xdh/qucs_s.git
>    Section : electronics|

Some pointers to get started with packaging for Debian,
so that it can be included in Debian:
https://mentors.debian.net/intro-maintainers/

As you are upstream: 
https://wiki.debian.org/UpstreamGuide

I've had a brief view at the debian/ directory on your repository,
and there will be a bit work required to make your package suitable
for inclusion into Debian, for example you'll need a debian/copyright
file. I didn't look into further details, but I suggest to upload your
package to mentors.debian.net, as this has already some QA built in and
will help you to identify problems with your package, for example from
the linitian tool.

Then, when ready, remove the "moreinfo" tag from this bug report to get 
a proper review of the package.

You'll also need to file a ITP bug (use "reportbug wnpp" to get a
template). ITP stands for "Itent to Package" and declares that *you*
want to package and maintain your package. 

(RFP as mentioned by Peter stands for Request To Package, that means you
ask if someone else wants to package and maintain it, however, that
needs someone volunteering, so it might never happen.)apt

-- 
Cheers,
tobi

Bug#1064027: RFS: mercurial-evolve/11.1.1-1

[Tobias Frost]

can you upload your dsc to mentors?
TIA!


On Thu, 15 Feb 2024 22:46:21 +0100 Georges Racinet
 wrote:
> Package: sponsorship-requests
> Severity: normal
> X-Debbugs-Cc: andrew.shad...@collabora.co.uk, jcris...@debian.org
> 
> Dear uploaders,
> 
> I have pushed a new version 11.1.1-1 of the mercurial-evolve package
to
> https://salsa.debian.org/python-team/packages/mercurial-evolve
> 
> Note that the previous version, 10.5.3, does not work with
> the current Mercurial version (6.6) in unstable.
> 
> Is anyone available to upload it to the archive?
> 
> Thank you so much,
> 
> Cc Andrew, who did the previous uploads, and Julien, who is the
Mercurial
> package maintainer.
> 
> G. Racinet.
> 
> 

Bug#1065193: RFS: libhx/4.23-1 [RC] -- C library providing queue, tree, I/O and utility functions

[Tobias Frost]

Control: tags -1 moreinfo

On Sun, Mar 17, 2024 at 04:57:54PM +0100, Jörg Frings-Fürst wrote:
> tags 1065193 - moreinfo
> thanks
> 
> Hi Tobias,
> 
> 
> 
> Am Sonntag, dem 17.03.2024 um 14:39 +0100 schrieb Tobias Frost:
> > Hi Jörg,
> > 
> > "debcheckout libhx" still gives me 4.17-1 as head.
> > 
> > After looking at your repo, I think I should point you to DEP-14
> > as a recommended git layout for packaging. 
> > As the branch name indicates you are using per-package-revision
> > branches:
> > IMHO It makes little sense to have one branch per debian package
> > version/revision; (I had a similiar discussion on vzlogger lately,
> > so to avoid repetiions: #1064344#28)
> > 
> > Please clarify how you want to manage the package in git, as
> > this needs to be reflected in d/control's VCS-* fields correctly.
> > (this is now blocking the upload.)
> 
> I have been using Vincent Driessen's branching model and the corresponding git
> extension gitflow-avh for at least 7 years with Debian and for a long time at
> work.
> 
> The default branch is master and development takes place in the develop 
> branch.
> 
> The release candidates are managed in the branch release. The extension
> debian/debian-version is used as a tag during the transfer.
> 
> The master branch always contains the last published executable version to 
> which
> the git tag in debian/control points.
> 
a> The procedure is described in the README.debian.

ok, won't further argue about how to organize your git repo, but I can
only tell the Debian perspective: It is breaking expectations as a
debcheckout libhx does today NOT give me a state that represents the
package in unstable. VCS-Git specifies where the (package)
development is happening [1].

[1] Policy 5.6.26 

But as I am not using the git repo as base for the sponsoring, lets put
that topic to rest.

> > 
> > (The current fields say the package is maintained in the default branch
> > of your repo. I see a debian/ directory there, but that one is missing
> > released (it is at 4.17-1, while unstable is at 4.19-1.1)
> > 
> > The review is based on the .dsc, timestamped on mentors.d.n
> > 2024-03-17 12:00
> > 
> > d/changelog is *STILL* changing history for the 4.19-1 changelog
> > block. (This issue must be fixed before upload.)
> > 
> 
> I think these were artifacts because my changes to the NMU were not adopted. 
> Has
> been corrected.

No it has not. I expect old changelog entries to be *identical* to
the ones that have been uploaded, and they still are not, so I fear
we are talking past each other. Please let me know what you think that
you have fixed, so that we can spot the different expectations.

For my perspective:
This is the diff from debian/changelog from the current
version in the archives and the dsc uploaded to mentors at 2024-03-17 14:45
You are still rewriting history (second hunk of this diff), this hunk
should not exists.

diff -Naur archive/libhx-4.19/debian/changelog 
mentors/libhx-4.23/debian/changelog
--- archive/libhx-4.19/debian/changelog 2024-02-28 13:48:09.0 +0100
+++ mentors/libhx-4.23/debian/changelog 2024-03-17 15:23:31.0 +0100
@@ -1,3 +1,17 @@
+libhx (4.23-1) unstable; urgency=medium
+
+  * New upstream release (Closes: #1064734).
+  * Add debian/.gitignore
+  * Remove not longer needed debian/libhx-dev.lintian-overrides.
+  * Fix debian/libhx32t64.lintian-overrides.
+  * debian/copyright:
+- Add 2024 to myself.
+  * debian/control:
+- Readd BD dpkg-dev (>= 1.22.5).
+  Thanks to Tobias Frost 
+
+ -- Jörg Frings-Fürst   Sun, 17 Mar 2024 15:23:31 +0100
+
 libhx (4.19-1.1) unstable; urgency=medium

   * Non-maintainer upload.
@@ -9,11 +23,8 @@

   * New upstream release.
 - Refresh symbols files.
-  * Remove empty debian/libhx-dev.symbols.
-  * debian/rules:
-- Remove build of libhx-dev.symbols.

- -- Jörg Frings-Fürst   Sun, 17 Dec 2023 14:44:39 +0100
+ -- Jörg Frings-Fürst   Tue, 21 Nov 2023 10:41:07 +0100

 libhx (4.14-1) unstable; urgency=medium

Bug#1067037: RFS: batsignal/1.8.0-1 -- Lightweight battery daemon written in C

[Tobias Frost]

Control: tags -1 moreinfo

Hi itd,

(Policy requires that the "Maintainer" has "their correct name and a working 
email
address", see Policy §3.3. I know that there are exceptions, but I'm not
sure about the conditions they require (for DMs/DDs, at least DAM needs
to know your name, but I don't know the rules for Debian Contributors.
Due to that, I will not sponsor this package, but I can certainly review the
package.)

On Sun, Mar 17, 2024 at 12:17:52PM +0100, itd wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "batsignal":
> 
>  * Package name : batsignal
>Version  : 1.8.0-1
>Upstream contact : https://github.com/electrickite/batsignal
>  * URL  : https://github.com/electrickite/batsignal
>  * License  : ISC
>  * Vcs  : https://salsa.debian.org/itd/batsignal
>Section  : utils
> 
> The source builds the following binary packages:
> 
>   batsignal - Lightweight battery daemon written in C
> 
> To access further information about this package, please visit the following 
> URL:
> 
>   https://mentors.debian.net/package/batsignal/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/b/batsignal/batsignal_1.8.0-1.dsc
> 
> Changes for the initial release:
> 
>  batsignal (1.8.0-1) unstable; urgency=medium
>  .
>* Initial release.

Inital releases needs an ITP bug. Please file one and add the appropiate
Closes: # stanca.

> I would like to move the Vcs to /debian/batsignal, whenever that is
> convenient.

Let me know your salsa username and I'll make that happen.


A short, possibly incomplete review:
- d/copyright: I suggest to have the same license for debian/* as for
  upstream, as this eases forwarding patches etc. Though ISC is
  considered by the FSF to be compatible with the GPL, this is likely
  fine too to keep it at is is.

- d/watch / this dsc
  uscan download this:
c8c2a048f4aa105aae389d9d765b76057d4998dbfc29a7dfeaf66351eaa7cba1  
batsignal_1.8.0.orig.tar.gz
 
  your dsc contains:
d02e5c821d41e72c30d00bb88759287f9b74225e1217158e5e59f11ba03d5a5b  
batsignal_1.8.0.orig.tar.xz

  when constructing your dsc, please make sure to use the same file as
  uscan would produce. (I've verified that the content of both orig files is 
identical)

Package looks good, otherwise. Make sure to remove the moreinfo tag when
the above issues are fixed.

Cheers,
-- 
tobi


> Regards,
> --   itd
> 

Bug#1065193: RFS: libhx/4.23-1 [RC] -- C library providing queue, tree, I/O and utility functions

[Tobias Frost]

Hi Jörg,

"debcheckout libhx" still gives me 4.17-1 as head.

After looking at your repo, I think I should point you to DEP-14
as a recommended git layout for packaging. 
As the branch name indicates you are using per-package-revision
branches:
IMHO It makes little sense to have one branch per debian package
version/revision; (I had a similiar discussion on vzlogger lately,
so to avoid repetiions: #1064344#28)

Please clarify how you want to manage the package in git, as
this needs to be reflected in d/control's VCS-* fields correctly.
(this is now blocking the upload.)

(The current fields say the package is maintained in the default branch
of your repo. I see a debian/ directory there, but that one is missing
released (it is at 4.17-1, while unstable is at 4.19-1.1)

The review is based on the .dsc, timestamped on mentors.d.n
2024-03-17 12:00

d/changelog is *STILL* changing history for the 4.19-1 changelog
block. (This issue must be fixed before upload.)

Thanks for re-adding the B-D on dpkg-dev.


So, please elaborate on the git issue (so that the correct VCS-* can be
confirmed or specified) , and fix the rewriting history part, and I'll upload 

Remove the moreinfo tag when ready.

Cheers,
--
tobi

On Sun, Mar 17, 2024 at 01:48:57PM +0100, Jörg Frings-Fürst wrote:
> Hello Tobias,
> 
> thanks for your review.
> 
> 
> Am Donnerstag, dem 14.03.2024 um 17:53 +0100 schrieb Tobias Frost:
> > Control: tags -1 moreinfo
> > 
> > Hi Jörg,
> > 
> > d/copyright:
> > you are changing history:
> > 
> > diff -Naur archive/libhx-4.19/debian/changelog 
> > new/libhx-4.23/debian/changelog
> > (...)
> >    * debian/rules:
> >  - Remove build of libhx-dev.symbols.
> > 
> > - -- Jörg Frings-Fürst   Sun, 17 Dec 2023 14:44:39 +0100
> > + -- Jörg Frings-Fürst   Tue, 21 Nov 2023 10:41:07 +0100
> > 
> >  libhx (4.14-1) unstable; urgency=medium
> > 
> > - you git repository seems to missing commits. a debcheckout libhx
> >   gives me 4.17-1 in d/changelog.
> 
> Sorry, that's my mistake.
> 
> > 
> > - please don't drop the Build-Depends: dpkg-dev (>= 1.22.5), the
> >   time_t transition requires it, 
> > 
> 
> Ok. I have add it. 
> 
> > --
> > tobi
> > 
> 
> CU
> Jörg
> 
> -- 
> New:
> GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
> GPG key (long) : 09F89F3C8CA1D25D
> GPG Key: 8CA1D25D
> CAcert Key S/N : 0E:D4:56
> 
> 
> Jörg Frings-Fürst
> D-54470 Lieser
> 
> 
> git:  https://git.jff.email/cgit/
> 
> Skype:jff-skype@jff.email
> Jami: joergfringsfuerst
> Telegram: @joergfringsfuerst
> Matrix:   @joergff:matrix.snct-gmbh.de
> 
> My wish list: 
>  - Please send me a picture from the nature at your home.
> 
> 
> 
> 

Bug#1064605: [ftpmas...@ftp-master.debian.org: [Pkg-rust-maintainers] rustup_1.26.0-5_source.changes REJECTED]

[Tobias Frost]

On Sun, Mar 17, 2024 at 01:46:39PM +0100, Geert Stappers wrote:
> 
> Hi,
> 
> 
> In an attempt to express my appreciation for working rustup in Debian,
> this forwarded message.
> 
> - Forwarded message from Debian FTP Masters -
> 
> Date: Sun, 17 Mar 2024 11:32:47 +
> From: Debian FTP Masters 
> To: Debian Rust Maintainers , 
> t...@debian.org, Zixing Liu 
> Subject: [Pkg-rust-maintainers] rustup_1.26.0-5_source.changes REJECTED
> 
> 
> 
> rustup_1.26.0-5.dsc: Refers to non-existing file 'rustup_1.26.0.orig.tar.xz'
> Perhaps you need to include the file in your upload?
> 
> If the orig tarball is missing, the -sa flag for dpkg-buildpackage will be 
> your friend.

The problem was the the sponsoree's dsc included a different orig.tar,
(identical in content, but compressed with xz; If I'd had to guess maybe
gbp created that one.) 

I've reuploaded alrady with the one using the one in the archives, so
this should(tm) appear soon.

> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
> 
> 
> ___
> Pkg-rust-maintainers mailing list
> pkg-rust-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
> 
> 
> - End forwarded message -
> 
> 
> 
> 
> Regards
> Geert Stappers
> Should be working on making it possible to be ready
> for the next RFS for rustup
> -- 
> Silence is hard to parse
> 

Bug#1065197: RFS: cevomapgen/31-1 [ITP] -- External Map Generator for C-Evo

[Tobias Frost]

Control: tags -1 moreinfo

Hi Peter,

(There was also #1040494, which seems not to have been sponsored.
In this case, please reopen the old RFS bug and don't file new bugs.)

Here's a very short review, (including copyright review)

- lintian:
  - Comments should be directly over the overriden tag, otherwise the
override justification is not correctly picked up

  - O: cevomapgen: no-manual-page [usr/games/cevomapgen]
I disagree this should be overriden, and I disagree that gui
programs don't need a manpage.

- d/copyright
  I see that there are files with years from 1999-2023 and one 2024.
  Please review your d/copyright file and record the years correctly.

-- 
tobi

On Fri, Mar 01, 2024 at 07:53:12PM +, Peter Blackman wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "cevomapgen":
> 
>  * Package name : cevomapgen
>    Version  : 31-1
>    Upstream contact : Peter Blackman 
>  * URL  : https://sourceforge.net/projects/cevomapgen/
>  * License  : GPL-3+
>  * Vcs  : https://salsa.debian.org/PeterB/cevomapgen
>    Section  : games
> 
> The source builds the following binary packages:
> 
>   cevomapgen - External Map Generator for C-Evo
> 
> 
> cevomapgen is a tool for use with c-evo-dh
> https://tracker.debian.org/pkg/c-evo-dh
> a strategy game with some similarities to Freeciv
> 
> 
> To access further information about this package, please visit the following
> URL:
> 
>   https://mentors.debian.net/package/cevomapgen/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>   dget -x
> https://mentors.debian.net/debian/pool/main/c/cevomapgen/cevomapgen_31-1.dsc
> 
> Changes for the initial release:
> 
>  cevomapgen (31-1) unstable; urgency=medium
>  .
>    * Initial release (Closes: #1035747)
> 
> Regards,
> -- 
>   Peter Blackman
> 

Bug#1065197: RFS: cevomapgen/31-1 [ITP] -- External Map Generator for C-Evo

[Tobias Frost]

> The source builds the following binary packages:
> 
>    cevomapgen - External Map Generator for C-Evo


> 
> cevomapgen is a tool for use with c-evo-dh
> https://tracker.debian.org/pkg/c-evo-dh

Would it make sense to call it also c-evo-mapgen, to use the same scheme
as the game package?

Bug#1065682: RFS: c-evo-dh/1.11-1 -- Empire Building Game (data files), C-evo: Distant Horizon

[Tobias Frost]

Control: tags -1 moreinfo

Hi Peter,

Some review
- source packages do not have a Description: field, only binary
  packages.

- note that changing previous d/changelog entries should be only done in
  rare circumtances, for example annotating CVEs to earlier uploads,
  not known then.
  I don't see the necassity for that history rewriting here, so
  please don't do that. 
  Additional confusion can arise, if you change the timestamp
  of historical changelog entries. Don't do that either.
  Please revert those changes.

Cheers,
--
tobi


On Fri, Mar 08, 2024 at 08:58:59PM +, Peter B wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "c-evo-dh":
> 
>  * Package name : c-evo-dh
>    Version  : 1.11-1
>    Upstream contact : Peter 
>  * URL  : https://sourceforge.net/projects/c-evo-eh/
>  * License  : CC0-1.0, GPL-2+, CC-BY-SA-3.0-US, CC-BY-3.0
>  * Vcs  : https://salsa.debian.org/PeterB/c-evo-dh
>    Section  : games
> 
> The source builds the following binary packages:
> 
>   c-evo-dh-gtk2  - Empire Building Game (GTK2), C-evo: Distant Horizon
>   c-evo-dh-stdai - Empire Building Game (AI module), C-evo: Distant Horizon
>   c-evo-dh-data  - Empire Building Game (data files), C-evo: Distant Horizon
> 
> 
> To access further information about this package, please visit the following
> URL:
> 
>   https://mentors.debian.net/package/c-evo-dh/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>   dget -x
> https://mentors.debian.net/debian/pool/main/c/c-evo-dh/c-evo-dh_1.11-1.dsc
> 
> 
> Changes since the last upload:
> 
>  c-evo-dh (1.11-1) unstable; urgency=medium
>  .
>    * New Upstream Release
>    * Missing change in changlog for (1.10-1)
>    * Update d/copyright date
>    * Drop lintian override on missing man page for libexec binary
>    * Add source package description in d/control
>    * Strip trailing whitespace from d/c-evo-dh-gtk2.install
> 
> Regards,
> -- 
>   Peter Blackman
> 

Bug#1066079: RFS: ddclient/3.11.2-1 -- address updating utility for dynamic DNS services

[Tobias Frost]

Control: tags -1 moreinfo

Hi Richard,

On Tue, Mar 12, 2024 at 12:52:09AM -0700, Richard Hansen wrote:
>  * Package name : ddclient
>Version  : 3.11.2-1
>Upstream contact : https://github.com/ddclient/ddclient
>  * URL  : https://ddclient.net
>  * License  : GPL-2.0+, Artistic or GPL-1+, Apache-2.0
>  * Vcs  : https://salsa.debian.org/debian/ddclient
>Section  : net
> 
> 
>  ddclient (3.11.2-1) unstable; urgency=medium
>  .
>* Add curl build dependency to enable the -curl argument
>* Suggest curl

The package now "Depends" on curl, not "Suggests" it. As this
conflicts with the d/ch entry, can you clarify?

>* Bump Standards-Version to 4.6.2 (no changes needed)
>* gbp.conf: Rename branches and tags to match current convention
>* gbp.conf: Set upstream-vcs-tag (for import-orig)
>* New upstream version 3.11.2
>* Refresh patches
>* Update dependencies
>* Use dh_installchangelogs to install ChangeLog.md
>* debian/copyright: Set Upstream-Contact to project URL
>* debian/copyright: Update copyright year for debian/*

There are more changes, undocumented, like droping some B-Ds.

Please expand on the "why" a change is made over the "what",
as this helps reviewing.

> Regards,

-- 
Cheers,
tobi

Bug#1065442: RFS: shaderc/2023.8-1 [RC] -- Library API for accessing glslc functionality - shared libraries

[Tobias Frost]

Hi Philippe,

Seems so that upstream has released a new version last week, but as you
package looks fine, lets upload that one first ;)

d/copyright: 
 - upstream years needs to include at least 2023 (e.g for 
glslc/test/option_fpreserve_bindings.py)
 - kokoro needs also 2023 for Google.

Otherwise, it looks fine to me, and fixing the RC bugs has priority, so
uploaded. Please fix the copyright years for the next upload
nethertheless and take a look at the lintian stuff, for example
if usr/bin/glslc needs hardening and whether it makes sense to install
the examples into the -dev packagse, as well as there are two typos
mentioned by linitan.

Thanks for your contribution to Debian!

-- 
cheers,
tobi




On Mon, Mar 04, 2024 at 09:19:57PM +0100, Philippe SWARTVAGHER wrote:
> Package: sponsorship-requests
> Severity: important
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "shaderc":
> 
>  * Package name : shaderc
>Version  : 2023.8-1
>Upstream contact : David Neto 
>  * URL  : https://github.com/google/shaderc/
>  * License  : Apache-2.0, BSD-3-clause
>  * Vcs  : https://salsa.debian.org/debian/shaderc
>Section  : libs
> 
> The source builds the following binary packages:
> 
>   glslc - Command line compiler for GLSL/HLSL to SPIR-V
>   libshaderc-dev - Library API for accessing glslc functionality -
> static libraries and headers
>   libshaderc1 - Library API for accessing glslc functionality - shared
> libraries
> 
> To access further information about this package, please visit the
> following URL:
> 
>   https://mentors.debian.net/package/shaderc/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>   dget -x
> https://mentors.debian.net/debian/pool/main/s/shaderc/shaderc_2023.8-1.dsc
> 
> Changes since the last upload:
> 
>  shaderc (2023.8-1) unstable; urgency=medium
>  .
>* New upstream release
>  - Refresh patches
>  - Add patch to fix name of Python interpreter
>  - Fix FTBFS (Closes: #1058397)
>  - Refresh d/glslc.lintian-overrides
>* Fix linking of libshaderc.so, add autopkgtest (Closes: #1029939)
>* Add obj-x86_64-linux-gnu to d/clean
>* Use printf instead of echo to generate build-version.inc. Thanks to
>  Vagrant Cascadian! (Closes: #1035324)
>* Build-Depends on pkgconf instead of pkg-config
>* d/copyright: update copyright year
> 
> Regards,
> --
>   Philippe
> 

Bug#1065193: RFS: libhx/4.23-1 [RC] -- C library providing queue, tree, I/O and utility functions

[Tobias Frost]

Control: tags -1 moreinfo

Hi Jörg,

d/copyright:
you are changing history:

diff -Naur archive/libhx-4.19/debian/changelog new/libhx-4.23/debian/changelog
(...)
   * debian/rules:
 - Remove build of libhx-dev.symbols.

- -- Jörg Frings-Fürst   Sun, 17 Dec 2023 14:44:39 +0100
+ -- Jörg Frings-Fürst   Tue, 21 Nov 2023 10:41:07 +0100

 libhx (4.14-1) unstable; urgency=medium

- you git repository seems to missing commits. a debcheckout libhx
  gives me 4.17-1 in d/changelog.

- please don't drop the Build-Depends: dpkg-dev (>= 1.22.5), the
  time_t transition requires it, 

--
tobi

On Fri, Mar 01, 2024 at 06:50:24PM +0100, Jörg Frings-Fürst wrote:
> Package: sponsorship-requests
> Severity: important
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "libhx":
> 
>    Package name : libhx
>    Version  : 4.23-1
>    Upstream contact : Jan Engelhardt 
>    URL  : https://inai.de/projects/libhx/
>    License  : LGPL-2.1+, WTFPL-2+, GPL-2+
>    Vcs  : https://git.jff.email/cgit/libhx.git
>    Section  : libs
> 
> The source builds the following binary packages:
> 
>   libhx32t64 - C library providing queue, tree, I/O and utility functions
>   libhx-dev - Development files for libhx
>   libhx-doc - Documentation files for libhx
> 
> To access further information about this package, please visit the following
> URL:
> 
>  https://mentors.debian.net/package/libhx/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>  dget -x 
> https://mentors.debian.net/debian/pool/main/libh/libhx/libhx_4.23-1.dsc
> 
> or from 
> 
>  git https://git.jff.email/cgit/libhx.git?h=release%2Fdebian%2F4.23-1
> 
> 
> 
> Changes since the last upload:
> 
>  libhx (4.23-1)  experimental; urgency=medium
>  .
>    * New upstream release (Closes: #1064734).
>    * Add debian/.gitignore
>    * Remove not longer needed debian/libhx-dev.lintian-overrides.
>    * Fix debian/libhx32t64.lintian-overrides.
>    * debian/copyright:
>  - Add 2024 to myself.
> 
> 
> 
> CU
> 
> Jörg
> 
> 
> -- 
> New:
> GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
> GPG key (long) : 09F89F3C8CA1D25D
> GPG Key: 8CA1D25D
> CAcert Key S/N : 0E:D4:56
> 
> 
> Jörg Frings-Fürst
> D-54470 Lieser
> 
> 
> git:  https://git.jff.email/cgit/
> 
> Skype:jff-skype@jff.email
> Jami: joergfringsfuerst
> Telegram: @joergfringsfuerst
> Matrix:   @joergff:matrix.snct-gmbh.de
> 
> My wish list: 
>  - Please send me a picture from the nature at your home.
> 
> 
> 
> 

Bug#1065193: RFS: libhx/4.23-1 [RC] -- C library providing queue, tree, I/O and utility functions

[Tobias Frost]

On Fri, Mar 01, 2024 at 06:50:24PM +0100, Jörg Frings-Fürst wrote:
>  libhx (4.23-1)  experimental; urgency=medium

Note: the dsc file targets unstable, not experimental. The review was
using unstable as target.

-- 
tobi

Bug#1065374: RFS: sane-backends/1.3.0-1 -- API development library for scanners

[Tobias Frost]

Control: tags -1 moreinfo

Hi Jörg,

isfdtype(3) says the header you need to include is 
   #include 
   #include 

Any reason why you don't include the header but use a forward
declaration instead?

--
tobi

Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255

[Tobias Frost]

Hi Joachim

&& dpkg --compare-versions $2 le-nl 0.8.3 \
&& dpkg --compare-versions $2 ge 0.8.2; then

- $2 might be empty, you need to quote it: use "$2" otherwise dpkg will
  fail:

$ dpkg --compare-versions $empty le-nl 0.8.3
dpkg: error: --compare-versions takes three arguments:   


Type dpkg --help for help about installing and deinstalling packages [*];
Use 'apt' or 'aptitude' for user-friendly package management;
Type dpkg -Dhelp for a list of dpkg debug flag values;
Type dpkg --force-help for a list of forcing options;
Type dpkg-deb --help for help about manipulating *.deb files;

Options marked [*] produce a lot of output - pipe it through 'less' or 'more' !
 
-- 
tobi

Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255

[Tobias Frost]

Control: tags -1 moreinfo

Hi Joachim

approaching upload :)
beside the remark on postinst below, packaging is looking good already.

d/copyright:

 - minor thing, please write in d/copyright "GPL-3.0-or-later" as license
   indicator, as this makes it clearer.

 - the debian/ directory - change the year to 2023-2024

 -modules/GetGitRevisionDescription.cmake* is undocumented and
  licensed under modules/GetGitRevisionDescription.cmake

(copyright review done)

On Thu, Mar 07, 2024 at 06:02:56AM +0100, Joachim Zobel wrote:
> Control: tags -moreinfo
> 
> Hi Tobias.
> 
> Thanks for looking into the package.
> 
> Am Donnerstag, dem 22.02.2024 um 22:58 +0100 schrieb Tobias Frost:
> > d/source/lintian-overrides
> >  - delete the overrides, seems to be some remnant of earlier packaging.
> > 
> > d/DEBIAN_RELEASE.txt
> >  - delete this file; the information contained in this files would not
> >be a process how to create a package for Debian. (and if you need a
> >file describing certain unusal aspects of the Debian packaging, it
> >would be README.source (see Debian Policy §4.14)
> >I recommend checking out git-buildpackage:
> >https://honk.sigxcpu.org/piki/projects/git-buildpackage/ 
> >https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/
> >- remove Debian_release.patch -- this is not needed, you work with
> >your debian/ directory and evolve it, you do not patch it when you
> >create a new version. 
> > 
> > d/control
> >  - specify Rules-Require-Root
> >  - you manually depend on libsml1. Can you expand why this is needed?
> >  - Build-Depend: s/pkg-config/pkgconf
> >  - remove versions from the versioned build dependencies, if the
> >debpendency is already fulfilled in oldstable:
> >- libjson-c-dev, libcurl4-openssl-dev, 
> > 
> > 
> > d/postinst / postrm
> >  - When you create a user, it should start with "_" - see policy 9.2.1
> >- Another option might be using systemd's DynamicUser feature to 
> >  create the user at runtime. (bonus: some hardening for free.)
> >- there's systemd-sysuser (works also without systemd as init system)
> >  to use sysusers.d 
> >- do not delete users/groups on package removal. 
> 
> All changes have been done. In addition the repository has been moved
> to DEP-14 layout.

Thanks!

I see that you've decided to migrate the user.
However, you should do so only when the package is upgraded from an old
version, which had the old name, to avoid collisions down the road.
your postinst needs a conditional based on the old version, (which is
be passed to postinst.)

Those might be helpful:
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#
https://www.debian.org/doc/debian-policy/ap-flowcharts.html
deb-postinst(5) 

Example for how to check for the required version using dpkg
--compare-version:
https://codesearch.debian.net/show?file=pam-pgsql_0.7.3.2-1%2Fdebian%2Fpostinst=32

-- 
tobi



signature.asc
Description: PGP signature

Bug#1062001: RFS: trader/7.20-1 -- simple game of interstellar trading

[Tobias Frost]

On Sun, Mar 10, 2024 at 04:25:16PM +0100, Tobias Frost wrote:

Maybe this needs a bit more expansion:

> Having two sources of packages is bad too, I'd suggest to stop
> distribution your own packages, at least make sure not to use the same
> exact same version/revision, so that there will be clear from looking on
> the version only that this was from your archives. Otherwise, I'll
> envise chaos. Make sure that the version in your archives sort earlier
> than the one in Debian's as this sould be the canonical source of the
> Debian packages. Such a versioning scheme is also used for backports,
> you can look there how it is done.

If you ship packages yourself, you should ensure that if people
installing from Debian archives they will get the Debian package not
yours, at least if the version in the Debian archive is not of an older
version.

This is similar to the procedure when doing a backport, the backport
version is always "older" than then the version in testing, so that when
testing becomes stable the proper package from now-stable is installed,
updating the backports package.

An easy way is to append "~" to your upstream package's revision, as
this will always sort earlier, eg. "7.20-3~"

-- 
tobi

Bug#1062001: RFS: trader/7.20-1 -- simple game of interstellar trading

[Tobias Frost]

Control: tags -1 moreinfo

Hi John,

thanks for the fixes you've already applied, but the package needs more
work to be Debian compliant.

On Wed, Feb 28, 2024 at 11:10:58AM +1100, John Zaitseff wrote:
> Control: retitle -1 trader/7.20-2 -- simple game of interstellar trading
> Control: tags -1 - moreinfo
> 
> Dear Tobias,
> 
> Thank you very much for your feedback on my RFS for Star Traders,
> and apologies for not replying sooner -- it's been a bit of a crazy
> week around here...
> 
> You (or anyone else) can see my latest Git tree at the following
> URL; this tree reflects the changes I've made as a result of your
> email:
> 
>   https://www.zap.org.au/git-browser/trader.git/tree/?h=with-debian
>   git clone https://git.zap.org.au/git/trader.git -b with-debian
> 
> I do have a few questions and observations about your comments:
> 
> > d/control:
> > - Please remove all versions from the versioned build depends that
> >   are fulfiled already since oldstable, e.g gettext and automake.
> 
> Good catch!  This is what happens when one maintains a Debian
> package outside the distro since 2011...
> 
> Given that the Git tag for package version 7.20-1 already exists
> (and has been distributed!), I've released the new package as
> 7.20-2, with the entry for 7.20-1 removed as it has not been
> uploaded to Debian. 

Well, the first Debian revision should be -1, and I wonder why
you are repeating that mistake with -3? At least that one should have
been kept at -2. 

To avoid confusion, a "-1" with the suite "UNRELEASED" could been added
to the changelog, so that people know what's happening.

In future, don't bump the Debian revision unless it has been sponsored.

Having two sources of packages is bad too, I'd suggest to stop
distribution your own packages, at least make sure not to use the same
exact same version/revision, so that there will be clear from looking on
the version only that this was from your archives. Otherwise, I'll
envise chaos. Make sure that the version in your archives sort earlier
than the one in Debian's as this sould be the canonical source of the
Debian packages. Such a versioning scheme is also used for backports,
you can look there how it is done.

Regarding the revision -3: You write "New upstream relases", that is wrong,
or at least you are using the terminology wrong.
A new upstream release must have a new upstream version , and a new
orig.tar corresponding to the new upstream version. Yours are the same. 

To have a way out, and as you are upstream, how's about cutting
a new upstream release, e.g 7.21 and package it as 7.21-1 ?

> I'm retitling this bug report to suit.  If you
> prefer, I can close this RFS and open a new one.

You did it right, you don't file new RFS bugs if the previous one
hasn't been sponsored.

> You can now download the updated package by running:
> 
>   dget -x 
> https://ftp.zap.org.au/pub/debian/dists/zapgroup-sid/main/source/trader_7.20-2.dsc

(Please utilize mentors, mentors has some diagnositics that helps
analyzing/reviewing the package, e.g lintian output.)

> > - Your VCS-Git link git:// is not using an encrypted link, but the
> >   site supports https://. Please use https.
> 
> Done.
> 
> > d/copyright:
> > - the directory lib/ has files which are not documented in
> >   d/copyright; (They have a different license and copyright)
> > - same for the m4 macros
> 
> Hmm.  The files (in lib and m4) that are not my own are mostly from
> the Gnulib GNU Portability Library.  Rather tedious and quite a bit
> of work, but I've updated the debian/copyright file to suit.

> I find it interesting that you're the first Debian developer to pick
> up on this: previous sponsors of the package were okay with it the
> way it was.  Perhaps you're more thorough!  If it leads to a better
> Debian package, I don't mind.
> 
> However, I note from section 2.3 of the Debian policy manual:
> 
>   Thus, the copyright information for files in the source package
>   which are only part of its build process, such as autotools files,
>   need not be included in /usr/share/doc/PACKAGE/copyright, because
>   those files do not get installed into the binary package.
> 
> My reading of that suggests there is no need to include copyright
> stanzas for files in the m4 directory.  Is this understanding
> correct?

Well, I'm used to that that they should be also documented and probably
I'm more strict than other on this; Ok, then leave them alone...

> This is what I've added to debian/copyright -- is this okay?
> 
>   Files: lib/*
>   Copyright: 1987-2024, Free Software Foundation, Inc.
>   License: GPL-3+
>   Comment:
>Some files in this directory (from the Gnulib GNU Portability Library)
>are licensed by the Free Software Foundation under LGPL-2.1+; other
>files are under GPL-2+.  When combined with the remaining files from the
>same Gnulib library, these inherit the overall GPL-3+ licence.

no, that's not ok.
you need to document the copyright *verbatim*, that is

Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255

[Tobias Frost]

On Tue, Feb 27, 2024 at 06:50:56AM +0100, Joachim Zobel wrote:
> Hi.
> 
> Thanks for taking the time to review my package.
> 
> Am Donnerstag, dem 22.02.2024 um 22:58 +0100 schrieb Tobias Frost:
> > d/postinst / postrm
> >  - When you create a user, it should start with "_" - see policy
> > 9.2.1
> This has been implemented and is on its way, see 
> https://github.com/volkszaehler/vzlogger/pull/628
> 
> It was a bit complicated because I need to rename an existing user.
> There are installations of the existing native package. I am therefore
> unsure if it is good to do this. Going by the letter which is
> "When maintainers choose a new hardcoded or dynamically generated
> username" the username has already been choosen when the
> debian/vzlogger.init script was created.
> 
> Since it is a now or never situation and since the number of existing
> installations is still low I tend to rename the user. Any opinions are
> appreciated.

If you think the existing user base is large enough, you can also
migrate the username, if you detect in your postinst script that you
are upgrading from an version with the old username.
(This code could then be dropped in trixie+1, assuming the package will
be in trixie, of course)

> Sincerely,
> Joachim
> 

Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255

[Tobias Frost]

Hi Joachim,

On Sat, Feb 24, 2024 at 06:37:02PM +0100, Joachim Zobel wrote:
> Hi.
> 
> I'll reply to the DEP-14 issue while working on the others.
> 
> Am Donnerstag, dem 22.02.2024 um 22:58 +0100 schrieb Tobias Frost:
> > > https://github.com/volkszaehler/vzlogger.git 
> > > 
> > > on branch debian-0.8.3-1.
> > 
> > (There is no such branch on that repo, but a "debian" one.)
> 
> Sorry, forgot to merge that. 
> 
> > Please see dep14 (https://dep-team.pages.debian.net/deps/dep14/) for 
> > recommendation how to layout the repository used for packaging, I'd
> > even recommend to use an extra repository for the packaging.
> 
> I know about DEP-14 and actually tried it. I found it however very
> inconvenient to use and I think this is because it is inappropriate for
> the current situation. 

Sorry, I don't get what you mean. Why is it inappropiate?

Putting DEP14 (branch names[1]) aside, Debian packagaing is supposed to
be "linear", you work on a package, upload it, and the next iteration
you base your work on the already uploaded version.

It makes no sense to have a branch for every Debian package revision,
because once it has been uploaded it will become immuteable, you cannot
reupload the same revesion, the upload will be rejected.
We *tag* Debian package releases to mark them, and when the next one is
ready, it will be based on the old revision, so it is more natural to
continue on that branch.
Also, you are supposed to note the branch in VCS-Git where packaging is
happening, and this is _a_ branch (that's singular!), see the Debian
Policy for extra reasoning.

[1] which are only getting important if you need to manage different
Debian release suites or backports on top. the scheme /,
e.g debian/unstable is meant to aid here. note: you cannot have branches
"debian" _and_ "debian/$suite", because git won't allow that. If you use
"debian" as branch, this will make it harder to deploy DEP14 later.

> The package is maintained in the upstream repository as a native
> package (by me). This is necessary because Debian packages are built as
> part of the upstream releases. So all packaging changes happen upstream
> first. 

If you are in control of upstream packaging, well, frankly, than you
are in control to do things propoerly upstream.

The first thing is: stop building native packages. Native packages are
the wrong approach 99% of the time. [2]

This will also save you a lot of time, you won't need to maintain two
flavours. (As Debian packages need to follow Debian rules and not
upstream rules, a native package will not be acceptable for Debian.)

The upstream guide discourages to have a debian/ directory in the
upstream main branch [3], but if you do, and base your packaging on
it.

Having a debian directory in "main" and another branch, especially if
they are divereged, will only confuse people. (and they might to need
to work on your package, e.g if there is a need for an NMU.) 
So pick one.


[2] 
https://wiki.debian.org/DebianMentorsFaq#What_is_the_difference_between_a_native_Debian_package_and_a_non-native_package.3F
 You should only use a native Debian package when it is clear that the
 package would not be useful outside the context of a Debian system, and
 would never be distributed except packaged for Debian or its
 derivatives. Even if the software is currently only available in Debian,
 if someone could reasonably use the software on another distribution or
 on another operating system, then the package should be non-native

[3] https://wiki.debian.org/UpstreamGuide#Pristine_Upstream_Source, 
third paragraph.

> The changes that are later needed to turn an upstream native
> release into a Debian release are few and won't change much over time.
> So a patch makes sense IMHO. 

As said, native is wrong anyways, but the packaging directory should be
orthogonal to the upstream version, as the upstream version needs also
to work on non-Debian systems, don't they?

> This situation can change when vzlogger reaches stable (and as a result
> reaches Raspbian). At that point maintaining a package in the upstream
> repo is no longer necessary.

This sounds wrong. 
Either you package in an dedicated repository, or you don't. That is
orthogonal to whether the package is in Debian or not.

> For now I would prefer to use the suggested release workflow (which I
> am already using for libsml, where the situation is the same). 

tracker.d.o is unhappy:
"The VCS repository is not up to date, push the missing commits."

Your process breaks tooling in Debian. It is broken.

> I am
> aware that the DEP-14 layout works well if upstream is not doing
> package maintenance and I am not generally against it. 

It is not significant for DEP-14 whether upstream is doing package
maintaince or not. In your instance, 

Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255

[Tobias Frost]

Control: tags -1 moreinfo

Hi Joachim,

review based on the dsc containing:
Checksums-Sha256:
 75aa7ed495b21d360340c84a4def6e16e25ecc36dab91e2481631993b2624bde 5128639 
vzlogger_0.8.3.orig.tar.gz
 c6737877696173e8daa4c9e4d4a1b6663ae5256f669c87554360e665f154e292 6252 
vzlogger_0.8.3-1.debian.tar.xz

It is only a partial review, especially I did not do a d/copyright
review yet.

Please check my remarks and remove the moreinfo tag when ready.

On Tue, Feb 20, 2024 at 12:34:04PM +0100, Joachim Zobel wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "vzlogger":
> 
>  * Package name : vzlogger
>  Version : 3.1-4
>  Upstream contact : Joachim Zobel 
>  * URL : http://wiki.volkszaehler.org/software/controller/vzlogger
>  * License : GPL-3
>  * Vcs : https://github.com/volkszaehler/vzlogger
>  Section : net 
> 
> The source builds the following binary packages:
> 
>  vzlogger - program to read measurements from smart meters and log them
> to Influxdb or forward them via MQTT.
> 
> vzlogger is a tool to read and log measurements of a wide variety of
> smart meters and sensors. It supports various commonly used protocols
> such as s0, d0, sml, oms and others. It can write these data to an
> Influxdb, forward them via MQTT, make them available via HTTP or eport
> them to a volkszaehler.org middleware.
> 
> The package is maintained in the upstream repository. Upstream (which I
> am part of) currently builds native packages. These are patched (a
> switch from native to quilt, a different changelog and a version >= 3.0
> for the dependency on openssl) to make them more suitable for debian.
> The package is therefore availabe in the upstream repo 

Yeah, format 3.0 quilt is the way, it is not a native package.

> https://github.com/volkszaehler/vzlogger.git 
> 
> on branch debian-0.8.3-1.

(There is no such branch on that repo, but a "debian" one.)

Please see dep14 (https://dep-team.pages.debian.net/deps/dep14/) for 
recommendation how to layout the repository used for packaging, I'd
even recommend to use an extra repository for the packaging.

> Alternatively, you can download thepackage with 'dget' using this
> command:
> 
>  dget -x 
> http://www.heute-morgen.de/debian/repo/unstable/main/source/net/vzlogger_0.8.3-1.dsc
> 
> Regards,
> -- 
>  Joachim Zobel

As you are upstream:
https://wiki.debian.org/UpstreamGuide

d/source/lintian-overrides
 - delete the overrides, seems to be some remnant of earlier packaging.

d/DEBIAN_RELEASE.txt
 - delete this file; the information contained in this files would not
   be a process how to create a package for Debian. (and if you need a
   file describing certain unusal aspects of the Debian packaging, it
   would be README.source (see Debian Policy §4.14)
   I recommend checking out git-buildpackage:
   https://honk.sigxcpu.org/piki/projects/git-buildpackage/ 
   https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/
   - remove Debian_release.patch -- this is not needed, you work with
   your debian/ directory and evolve it, you do not patch it when you
   create a new version. 

d/control
 - specify Rules-Require-Root
 - you manually depend on libsml1. Can you expand why this is needed?
 - Build-Depend: s/pkg-config/pkgconf
 - remove versions from the versioned build dependencies, if the
   debpendency is already fulfilled in oldstable:
   - libjson-c-dev, libcurl4-openssl-dev, 


d/postinst / postrm
 - When you create a user, it should start with "_" - see policy 9.2.1
   - Another option might be using systemd's DynamicUser feature to 
 create the user at runtime. (bonus: some hardening for free.)
   - there's systemd-sysuser (works also without systemd as init system)
 to use sysusers.d 
   - do not delete users/groups on package removal. 

As you are involved with upstream:
The manpage, initfile, systemd service file should probably be included in the
upstream part, it is not only useful for Debian alone.

Linitian emits:
W: vzlogger source: build-depends-on-obsolete-package Build-Depends: pkg-config 
(>= 0.25) => pkgconf
W: vzlogger: groff-message troff::5: warning: cannot select 
font 'CB' [usr/share/man/man8/vzlogger.8.gz:1]
I: vzlogger source: debian-rules-parses-dpkg-parsechangelog [debian/rules:12]
I: vzlogger: file-references-package-build-path [usr/bin/vzlogger]
I: vzlogger: file-references-package-build-path [usr/lib/static/libvz.a]
I: vzlogger: hardening-no-bindnow [usr/bin/vzlogger]
I: vzlogger: hardening-no-fortify-functions [usr/bin/vzlogger]
I: vzlogger: systemd-service-file-missing-documentation-key 
[usr/lib/systemd/system/vzlogger.service]
I: vzlogger source: unused-override odd-historical-debian-changelog-version 
*0.3.4-rc1* [debian/source/lintian-overrides:2]
P: vzlogger source: capitalization-in-override-comment 
odd-historical-debian-changelog-version debian Debian 
[debian/source/lintian-overrides:1]
P: vzlogger source: silent-on-rules-requiring-root 

Bug#1062001: RFS: trader/7.20-1 -- simple game of interstellar trading

[Tobias Frost]

Control: tags -1 moreinfo

Hi,

some review:

d/control: 
- Please remove all versions from the versioned build depends
  that are fulfiled already since oldstable, e.g gettext and automake.
- Your VCS-Git link git:// is not using an encrypted link, but the site
  supports https://. Please use https.

d/copyright:
- the directory lib/ has files which are not documented in d/copyright;
  (They have a different license and copyright)
- same for the m4 macros

embedded code copies:
- gnulib is packaged for Debian, any reason why you don't use the packaged 
version?
- there are m4 macros from autoconf-archive. Please check if you can use
  the ones from the package autoconf-archive.

Please add some upstream metadata: https://wiki.debian.org/UpstreamMetadata

d/changelog
- d/changelog's purpose is to document changed to the packageing,
  generaly not to document upstream changes, so I'd cut that down
  to:

  trader (7.20-1) unstable; urgency=low
 
* New upstream release.
* Updated to Debian Policy 4.6.2 (no changes).

- lintian findings:
W: trader: groff-message troff::133: warning: macro 'mR' not 
defined [usr/share/man/man6/trader.6.gz:1]
I: trader source: public-upstream-key-not-minimal has 16 extra signature(s) for 
keyid 0D254111C4EE569B [debian/upstream/signing-key.asc]
I: trader source: vcs-field-uses-insecure-uri Git 
git://git.zap.org.au/data/git/trader.git -b with-debian
P: trader source: source-contains-autogenerated-gperf-data 
[lib/iconv_open-hpux.h]
P: trader source: source-contains-autogenerated-gperf-data 
[lib/iconv_open-irix.h]
P: trader source: source-contains-autogenerated-gperf-data 
[lib/iconv_open-osf.h]
P: trader source: source-contains-autogenerated-gperf-data 
[lib/iconv_open-solaris.h]
P: trader source: source-contains-autogenerated-gperf-data 
[lib/iconv_open-zos.h]

Cheers,
-- 
tobi




On Wed, Jan 31, 2024 at 10:59:26AM +1100, John Zaitseff wrote:
> Hi, Bastian et al.,
> 
> > > > 7.19-1 was never uploaded to Debian, so please remove it from
> > > > the changelog.
> > >
> > > Would this still be the case even though I _did_ release it on
> > > The ZAP Group Australia's repository?  If so, how would I
> > > preserve the changes listed for v7.19 -- should I just add them
> > > as part of the 7.20-1 changelog entry?
> >
> > Yes, you should do that. Alternatively, you can upload 7.19-1
> > before uploading 7.20-1.
> 
> I have removed the changelog entry for 7.19-1; the entry for 7.20-1
> now reads:
> 
>  trader (7.20-1) unstable; urgency=low
> 
>* New upstream release: changed documentation (history of the game),
>  updated Swedish, Norwegian Bokmål, French, German, Serbian, Esperanto,
>  Romanian, Polish and Ukrainian translations.
>* Incorporates changes made to previous upstream release (not uploaded
>  to Debian): new Polish, Romanian and Ukrainian translations, renamed
>  AppStream metainfo and desktop files.
>* Require at least Gettext 0.21 and Automake 1.16 for building.
>* Updated to Debian Policy 4.6.2 (no changes).
> 
> Could you (or someone) now sponsor the package?  The original link
> now points to the updated package:
> 
>   dget -x 
> https://ftp.zap.org.au/pub/debian/dists/zapgroup-sid/main/source/trader_7.20-1.dsc
> 
> Yours truly,
> 
> John Zaitseff
> 
> -- 
> John Zaitseff   ╭───╮   Email: j.zaits...@zap.org.au
> The ZAP Group   │ Z │   GnuPG: 0x0D254111C4EE569B
> Australia Inc.  ╰───╯   https://www.zap.org.au/~john/
> 

Bug#1061290: RFS: rgbds/0.7.0-3 [ITP] -- Game Boy ASM programming tools

[Tobias Frost]

Control: tags -1 moreinfo

Hi Julius,

a short review based on the dsc uploaded 2024-02-02 22:10

d/control:
- Initial packagin starts at Debian revision -1 (yours is -3)

d/patches;
- Remove, as empty.

d/control:
- its up to you to keep the comments, but then you need to maintain them
  and keep them up to date. However, as the information you write in the
  comment is already given by the Build-Depends: field, it would be
  redudant for me, I would remove them completly. 
- Some of your versioned Build-Depends are available since at least
  oldstable. In this case, remove the version constraint. (cmake and
  bison)
- VCS-* points to where the package is maintained, not upstream.
  Please update the link, preferable to a repository on salsa.
  I can create one for you either in the Debian namespace of games-team
  namespace and grant you all rights you need. Let me know.
  (Note: I do not sponsor uploads of new packages if the packaging is
  not maintained on salsa. This does not consitute a promise that I will
  sponsor if it on salsa, though.)
- As you've asked the games team for sponsoring, please put it under
  the umbrella of the games team.

d/gbp.conf:
- seems that there is some git repo ;) 
- you should also use pristine-tar and enable sign-tags

d/source/lintian-overrides:
- please limit the usage of wildcards to the minimum, so that new
  instances of the override will be caught in future versions of the

d/rules:
- it seems that you leave out some tests, due to it pulling stuff from
  the web. This is the right way during build, as you cant download.
  However, you can download stuff in autopkgtest, so you should
  implement autopkgtest.

d/changelog:
- update the timestamp. (dch -r "")

Tagging "moreinfo", remove the tag when you've got something ready for
review.

-- 
Cheers,
tobi

Bug#1063704: RFS: tiny-initramfs/0.1-5.1 [NMU] [RC] -- Minimalistic initramfs implementation (automation)

[Tobias Frost]

Hi Victor,

uploaded to DELAYED/5 and sent the nmudiff to the package.

Thanks for your contributions to Debian!

Cheers,
-- 
tobi

On Sun, Feb 11, 2024 at 12:10:48PM +0100, Victor Westerhuis wrote:
> Package: sponsorship-requests
> Severity: important
> X-Debbugs-Cc: christ...@iwakd.de
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Dear mentors,
> 
> I am looking for a sponsor for "tiny-initramfs". The current version of
> the package is unusable with kernel packages with version 6.6.3-1~exp1
> or greater, because it does not support compressed modules. This NMU
> contains a targeted fix to enable support for XZ compressed modules.
> 
> I opened bug #1063142 6 days ago, so far without response from Christian
> Seiler, the maintainer. According to
> https://contributors.debian.org/contributor/chris_se/ Christian has not
> been active in Debian since 2021. That's why I decided to propose this
> NMU.
> 
> The below VCS URL is no longer active. The packaging was already
> imported in Salsa at https://salsa.debian.org/debian/tiny-initramfs and
> I'm testing some bigger packaging changes in my fork at
> https://salsa.debian.org/viccie30/tiny-initramfs.
> 
>  * Package name : tiny-initramfs
>Version  : 0.1-5.1
>Upstream contact : Christian Seiler 
>  * URL  : https://github.com/chris-se/tiny-initramfs/
>  * License  : GPL-2+, GPL-3+
>  * Vcs  : 
> https://anonscm.debian.org/cgit/collab-maint/tiny-initramfs.git
>Section  : utils
> 
> The source builds the following binary packages:
> 
>   tiny-initramfs - Minimalistic initramfs implementation (automation)
>   tiny-initramfs-core - Minimalistic initramfs implementation (core tools)
> 
> To access further information about this package, please visit the following 
> URL:
> 
>   https://mentors.debian.net/package/tiny-initramfs/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/t/tiny-initramfs/tiny-initramfs_0.1-5.1.dsc
> 
> Changes since the last upload:
> 
>  tiny-initramfs (0.1-5.1) unstable; urgency=high
>  .
>* Non-maintainer upload.
>* Decompress kernel modules included in initramfs. (Closes: #1063142)
> 
> - --
> Vriendelijke groet, Kind regards,
> 
> Victor Westerhuis
> 
> -BEGIN PGP SIGNATURE-
> 
> iQJHBAEBCAAxFiEE6OxII3T+o0Ujs6ECQz2Rq5dHQPsFAmXIqzgTHHZpY3RvckB3
> ZXN0ZXJodS5pcwAKCRBDPZGrl0dA+3QGD/90vFeAtsjTVWxw/W88+KV9WWp5HS4S
> t380m73WMciSqK8tA94xiem+6kwVkgTr5VeKvNPKBiRhlhkXVAJiqoVmg9xTY7oh
> bmOb9vghXCQ81+KINiE9gkBzYHdeTF+OLalN0Vjwn1R1yvQFNgi7uB/bArfR4qv8
> ytFzoqwFYURfuyVV5H+l5xhOl0q1BsNeShGQQGIhtH6rDvNhBdHIN6CAXMHkwIV8
> E1SAxVTvK2oSW7tU6wCYlwG2pXmPsFxRwjDE1l4gL3mjm0yRbfjMP8h9e7AfKVSf
> 9GD88xrNGPxsKGFgEfCkm4ndzoF3JqypIjpI8Xw8Zm/OHnrVobxAI84zvJB1tCeX
> fOYmO3HHOPzNDecJ6idWGddjXdjuQDGepbT/ZJ3qzxIPaCCPBMkGLrkmfM+sb1eg
> voRhYA36Fen1sM75rBbEx6b+tWhnb8b/lVmVHI553FhQoo+Off0/vaQGzVKf+AEw
> O5hU6e8BpPaAB8XyLYpehm1+fhO4MMf6jDhK+a7kFeHugPNL92GbnKKcbR5yVcoU
> TqlXYyU1rULqALU8fozYIm/pfZm9iPrCxe23Cj3ziJ0cRBteOe8L9FV+pzr8F5Q2
> 72JIYsJ3Q24tLVuLVyFzYVyR2Yp778+bz6bcj+b0C1mY9HmbnkaVrc0/q/R/KVMb
> 01fIJEX7ZkkTAg==
> =cfoH
> -END PGP SIGNATURE-
> 

Bug#1062683: closing 1062683

[Tobias Frost]

close 1062683 
thanks

Uploaded.

Bug#1057098: RFS: runit/2.1.2-57 -- system-wide service supervision

[Tobias Frost]

Control: tags -1 moreinfo

(This time sending to the correct bug ;-)

Hi Lorenzo,

the warning of unmerged systems will stop booting soon MUST
be in Debian.NEWS, preinst is the wrong place and it will be
very likely missed.  NEWS is a well-known mechanism to convey
important information. 

On the other hand, is this warning acutally required?  Once this will
get a real issue, Depend: on usr-is-merged and you should
be set. If you cannot tell when that is, enforce it now, as non-merged
systems are no longer supported anyway. 

There is a lintian warning:
W debian-news-entry-has-unknown-version
2.1.2-14 [usr/share/doc/getty-run/NEWS.Debian.gz:1]

Possibly this NEWS file can go, the version is older than
old-old-stable.


Small additional information:
With https://lists.debian.org/debian-devel-announce/2022/09/msg1.html
usrmerge is enforced on all installations.

TL:DR: init-system-helpers is Essential: Yes, so you can already now
Depend: on usr-is-merged if you want to make sure.
(That will also cover where people held init-systems-helpers to an older


-- 
tobi

Bug#1062683: RFS: runit-services/0.7.1 -- UNIX init scheme with service supervision (services)

[Tobias Frost]

Control: tags -1 -moreinfo

(note: I replied to the wrong bug, the remarks should have gone to 
#1057098)

I'll bounce them to the right bug after correction this mail.


 

Bug#1062683: RFS: runit-services/0.7.1 -- UNIX init scheme with service supervision (services)

[Tobias Frost]

On Sun, Feb 11, 2024 at 11:16:02AM +0100, Tobias Frost wrote:
> Hi Lorenzo,
> 
> the warning of unmerged systems will stop booting soon MUST
> be in Debian.NEWS, preinst is the wrong place and it will be
> very likely missed.  NEWS is a well-known mechanism to convey
> important information. 
> 
> On the other hand, is this warning acutally required?  Once this will
> get a real issue, Depend: on usr-is-merged and you should
> be set. If you cannot tell when that is, enforce it now, as non-merged
> systems are no longer supported anyway. 

Small additional information:
With https://lists.debian.org/debian-devel-announce/2022/09/msg1.html
usrmerge is enforced on all installations. 

TL:DR: init-system-helpers is Essential: Yes, so you can already now
Depend: on usr-is-merged if you want to make sure.
(That will also cover where people held init-systems-helpers to an older
version)

--
tobi

Bug#1062683: RFS: runit-services/0.7.1 -- UNIX init scheme with service supervision (services)

[Tobias Frost]

Control: tags -1 moreinfo

Hi Lorenzo,

the warning of unmerged systems will stop booting soon MUST
be in Debian.NEWS, preinst is the wrong place and it will be
very likely missed.  NEWS is a well-known mechanism to convey
important information. 

On the other hand, is this warning acutally required?  Once this will
get a real issue, Depend: on usr-is-merged and you should
be set. If you cannot tell when that is, enforce it now, as non-merged
systems are no longer supported anyway. 

There is a lintian warning:
W debian-news-entry-has-unknown-version
2.1.2-14 [usr/share/doc/getty-run/NEWS.Debian.gz:1]

Possibly this NEWS file can go, the version is older than
old-old-stable.

-- 
tobi

On Fri, Feb 02, 2024 at 07:05:41PM +0100, Lorenzo wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "runit-services":
> 
>  * Package name : runit-services
>Version  : 0.7.1
>Upstream contact : [fill in name and email of upstream]
>  * URL  : [fill in URL of upstream's web site]
>  * License  : GPL-2.0+, BSD-3-Clause, CC0-1.0, GPL-3+
>  * Vcs  :
>https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services Section
>   : admin
> 
> The source builds the following binary packages:
> 
>   runit-services - UNIX init scheme with service supervision (services)
> 
> To access further information about this package, please visit the
> following URL:
> 
>   https://mentors.debian.net/package/runit-services/
> 
> Alternatively, you can download the package with 'dget' using this
> command:
> 
>   dget -x
>   
> https://mentors.debian.net/debian/pool/main/r/runit-services/runit-services_0.7.1.dsc
> 
> Git repo:
>   
> https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/tree/next?ref_type=heads
> 
> Changes since the last upload:
> 
>  runit-services (0.7.1) experimental; urgency=medium
>  .
>* Fix piuparts failure in package removal
>   (Closes: #1062682)
>* update years in copyright.in and
>   regenerate d/copyright
> Regards,
> Lorenzo
> 

Bug#1061559: RFS: fpart/1.6.0-1

[Tobias Frost]

On Fri, Jan 26, 2024 at 01:12:54PM +0100, Ganael Laplanche wrote:
> fpart (1.6.0-1) unstable; urgency=low
> 
>* New upstream release
>* debian/control
>  - Bump Standards-Version to 4.6.2 (no changes required)
>* debian/copyright
>  - Bump copyright dates
>* debian/rules
>  - Enable hardening
> 

(dsc checked with timestamp:2024-01-25 12:10)

Hi,

d/control says still 4.6.0, in contrast to the changelog entry.
However, this is easy to fix (and as the repo is in the Debian group)
I've made this change for you in the repository and uploaded the
version accordingly.  
I've also added the tag in the repo.

NOTE: The tags for the upstream versions are missing in the repo.
PLEASE push your tags!

--
Cheers,
tobi

Bug#1059568: RFS: swaykbdd/1.4-1 -- Per-window keyboard layout switching daemon for Sway

[Tobias Frost]

Control: tags -1 moreinfo

Hi Sepi,

Am Thu, Dec 28, 2023 at 04:48:34PM +0200 schrieb Sepi Gair:
> I am looking for a sponsor for my package "swaykbdd":
> 
>  * Package name : swaykbdd
>Version  : 1.4-1
>Upstream contact : Artem Senichev 
>  * URL  : https://github.com/artemsen/swaykbdd
>  * License  : Expat
>  * Vcs  : https://salsa.debian.org/spg/swaykbdd
>Section  : x11

d/changelog needs to document every change you make on the packaging,
there are several undoucmented changes.

Remove the moreinfo tag when this has been fixed, and I'll upload the
package.

-- 
Cheers,
tobi

Bug#1060913: Re: Bug#1060913: RFS: sdaps/1.9.11-0.1 [NMU] [RC] -- scripts for data acquisition with paper-based surveys

[Tobias Frost]

Control: tags -1 moreinfo

On Wed, 17 Jan 2024 10:13:00 +0800 Bo YU  wrote:

(...)

>I should obey Debian  NMU guidance here.

This. The Debian developers reference has some information about NMUs,
please honour them.

Taggins moreinfo, as until this is not solved, this RFS is not
actionable.
Please re-evaulate whether your new upstream version is in accordance
with the NMU guidelines, and if so, follow the procedure, remove the
morinfo tag, and provide all information what you have done, e.g
bug reports to the package in question where you announce the NMU.

-- 
tobi

Bug#1055951: RFS: multispeech/4.6.0-1 [ITP] -- Multilingual speech server for Emacspeak

[Tobias Frost]

Control: tags -1 moreinfo

On Sat, Dec 30, 2023 at 07:27:26AM +0300, Igor B. Poretsky wrote:
> Hello Tobias,
> 
> >>>>> "Tobias" == Tobias Frost  writes:
> 
> Tobias> - m4/* has undocumentd files.
> 
> Why should these files be mentioned especially? Isn't the "Files: *"
> stanza sufficient?

Those undocumented files have a different license, license holders
and/or copyright years. So they need to be mentioned extra.

As the license is different, they need to be in an extra Files:
section.)

For example:

$ head m4/libtool.m4
# libtool.m4 - Configure libtool for the host system. -*-Autoconf-*-
#
#   Copyright (C) 1996-2001, 2003-2015 Free Software Foundation, Inc.
#   Written by Gordon Matzigkeit, 1996
#
# This file is free software; the Free Software Foundation gives
# unlimited permission to copy and/or distribute it, with or without
# modifications, as long as this notice is preserved.

your d/copyright do not mention them, so this needs to be fixed.

> Tobias> - */Makefile.in are not documented
> 
> The Makefile.in files are autogenerated. How should be they documented
> apart from others? And, maybe, some other autogenerated files as well?
>
> Apparently there is something I don't understand clearly here.

You need to document the verbatim copyright infomation every file that
you ship in your orig.tar.  Those autogenerated Makefile.in are:

# Makefile.in generated by automake 1.15 from Makefile.am.
# @configure_input@

# Copyright (C) 1994-2014 Free Software Foundation, Inc.

# This Makefile.in is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.

So, as long as you ship them in your tarball, they must be documented.
(As for libtool.m4 and Makefile.in the license is the same, you might
be able to document in a single additional Files: * section.)

(I suggest that you verify each and every file and see if something else
is missing in d/copyright.)

> Best regards,
> Igor.
> 

-- 
tobi


signature.asc
Description: PGP signature

Bug#1059236: RFS: nanomsg/1.2+dfsg-1 [ITA] -- nanomsg utilities

[Tobias Frost]

Am Thu, Dec 28, 2023 at 09:49:05AM +0100 schrieb Gianfranco Costamagna:
> control: owner -1 !
> control: tags -1 moreinfo
> 
> Also, since the transition will likely involve a couple of packages, it might 
> be a good point to just
> follow what upstream named and let things go that way (and maybe open an 
> upstream bug asking to avoid
> changing soname if the API is stable)

This. Follow upstream's SONAME, otherwise this can become very tricky in the 
future.

> G.

Bug#981030: RFS: sctk/2.4.10-20151007-1312Z+dfsg2-4 -- speech recognition scoring toolkit

[Tobias Frost]

Am Mon, Nov 22, 2021 at 04:10:15PM +0100 schrieb Giulio Paci:
> The failing test case relies on the assumptions that, when a and b have the
> same double value:
> 2) "a - b" is 0.0.

(comment only based on this mail, did not check the code)

usually (C,C++) you cannot reliably say "if ( (a - b) == 0 )" or "if (a == b)"
as floating point cannot always represent the numbers exactly enough.

Usually comparing floats for almost-equality is done, something like

if (fabs(a - b) <= FLT_EPSILON)

(but FLT_EPSILION (or DBL_EPSILON) might not always be suitable, for example it
depends how much rounding you might have picked up on the way

--
tobi

Bug#934298: RFS: tsctp/0.7.11-1

[Tobias Frost]

Control: tag -1 moreinfo

Hi Thomas,

d/tests - is empty should be removed or autopkgtests added.

d/copyright: I recommend against using for debian/ a differnent
 license than upstream, as this complicates e.g forwarding of 
patches.

d/changelog: It is a bit terse ;-) usually its "Initial release (Closes: )"

d/rules: - you do not need the dh_auto_configure override, do you?
 - I wonder why you need to specify cmake, does debhelpr not pick it up 
automatically?

d/control: Having a git VCS for packaging is best practice in 2023, I strongly
   suggest to add one. You can use salsa.debian.org ; I can create one 
for you in
   the Debian namespace, if you want.  (this unlocks the perk 
collaborative
   maintainance ;-))

.. 
Cheer,
tobi

Bug#1057264: RFS: git-credential-oauth/0.11.0-1 -- Git credential helper for GitHub and other forges using OAuth

[Tobias Frost]

Control: tags -1 moreinfo
Control: tags -1 confirmed

Am Fri, Dec 15, 2023 at 08:00:00AM + schrieb M Hickford:
> X-Debbugs-CC: debian...@lists.debian.org
> 
> Hi. Can anyone help? I'm looking for a sponsor for my package.

Hi,

d/changelog is to document changes to the packageing.
I see there are some changes to the packaging, but they
are not mentioned.

Please update d/changelog accordingly and let me know, and
I will upload the package.

-- 
Cheers,
tobi

Bug#1055951: RFS: multispeech/4.6.0-1 [ITP] -- Multilingual speech server for Emacspeak

[Tobias Frost]

Found another few minutes for the d/copyright review:

- doc/Makefile.in is undocumented.
- po Translation authors should also be mentioned
- m4/* has undocumentd files.
- */Makefile.in are not documented

-- 
tobi

Bug#1055951: RFS: multispeech/4.6.0-1 [ITP] -- Multilingual speech server for Emacspeak

[Tobias Frost]

Control: tags -1 moreinfo

Hi Igor,

Thanks for improving the package!
had another few minutes to take a look at your package.

(Didn't find time for copyright review yet.)

Am Wed, Dec 20, 2023 at 03:58:15AM +0300 schrieb Igor B. Poretsky:
> Hello Tobias,
> 
> >>>>> "Tobias" == Tobias Frost  writes:
> 
> Tobias> Until the first upload is sponsored, you just keep a single
> Tobias> changelog entry.  In the case of a new upstream version, you
> Tobias> just change the version accordingly.
> 
> Very much thanks for your clarification. So, I've updated my uploads on
> mentors.debian.net.

I'm puzzled… The changelog is still having multiple entries.
Did the upload fail? Timestamp of the dsc I've checked:  2023-12-19 23:40

You changelog file must be -- as this is the initial upload to Debian exactly 
this:

multispeech (4.6.1-1) unstable; urgency=medium

  * Initial release. (Closes: #1055902)

 -- Igor B. Poretsky   Sun, 10 Dec 2023 16:01:03 +0300


Thats it. The file ends here.


d/control:
- the library package should not recommend multispeech | sd-multispeech.
  (Recommends on libary packages are not useful, the binary package pulls in the
   library anyways --  see also the recommends definiton in policy; the library 
does
  not "depend" on the application, but vice versa.

BTw, Samuel corrected me: SIGHUP seems to be appropiate. (See 1055951#42)


> Best regards,
> Igor.
> 

Bug#1056937: RFS: allegro5/2:5.2.9.0+dfsg-1 -- portable library for cross-platform game and multimedia development

[Tobias Frost]

Control: tags -1 moreinfo

Hi Andreas,

my lintian is quite unhappy:

there are many of those (and similar)

E: allegro5-doc: privacy-breach-uses-embedded-file You may use the 
node-html5shiv package (virtual package). 
(//cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv-printshiv.min.js) 
[usr/share/doc/allegro5-doc/refman/acodec.html]

W: allegro5-doc: groff-message troff::104: warning: cannot 
select font 'C' [usr/share/man/man3/al_set_target_bitmap.3alleg5.gz:4]

Can you please fix those and I'll upload the package.

Thanks!

-- 
tobi

Bug#1055951: RFS: multispeech/4.6.0-1 [ITP] -- Multilingual speech server for Emacspeak

[Tobias Frost]

Am Sat, Dec 09, 2023 at 12:15:29PM +0300 schrieb Igor B. Poretsky:
> Hello Tobias,
> 
> >>>>> "Tobias" == Tobias Frost  writes:
> 
> Tobias> The "-1" is the Debian revision; it is orthogonal to the
> Tobias> upstream version, (except the rules where it resets to
> Tobias> usually -1, of course)
> 
> So, what should I do if my package has not been yet sponsored, but a new
> upstream release actually has some sensible fixes? As I understand, I
> may update my upload on mentors.debian.net. But what should I do in
> debian/changelog? Should I add a new entry with a new upstream version
> or amend the one that closes the ITP bug? I think that the latter option
> is better. Am I right?

You amend it. To avoid ambigiouness:

Until the first upload is sponsored, you just keep a single changelog entry.
In the case of a new upstream version, you just change the version accordingly.

For example a fictional package foobar, updating from 1.0.0 to 1.0.1:

foobar (1.0.0-1) unstable; urgency=medium

 * Initial Package (Closes: #…)

would become:

foobar (1.0.1-1) unstable; urgency=medium

 * Initial Package (Closes: #…)

Version 1.0.0-1 will NOT be mentioned in d/changelog, as there are no changes
to the Debian package if there was no prior upload.


-- 
Cheers,
tobi

Bug#1052597: RFS: libkysdk-base/2.2.0.1-1 -- common files for kylin sdk base library

[Tobias Frost]

Control: tags -1 moreinfo

Hi xibowen,
On Mon, Oct 30, 2023 at 11:23:33AM +0800, xibowen wrote:
> Hi. thanks for reply.
> 
> >
> > I'm curious if libkysdk-base-common is really needed? This will also
> > require a NEW processing btw.
> >
> 
> I have removed the libkysdk-base-common and uploaded to mentors.
> 
> Lastest upload: https://mentors.debian.net/package/libkysdk-base/
> 
>  libkysdk-base (2.2.0.1-1) unstable; urgency=medium
>  .
>* Update libs soname version.
>* Fix compile error on armhf and ppc64el.
>* d/control:
>  - Add Multi-Arch.

(this is a partial review, as I ran out of time.)

- Updating the SONAME of a library requires this procedure to be followed:
https://wiki.debian.org/Teams/ReleaseTeam/Transitions
  Comparing the symbols file does not make it obvious why you are
  bumping SONAME, but I did not check with abi-complicance-checker...
  Can you fill me in why you bump the soname?

- the breaks/replaces version seems odd, as it is a binnmu version.
  You likely want (<< 2.2.0.1-1~), though I am not sure why you think
  you'll need the Break/Replace? Can you exand?

- you could use d/clean instead of overriding dh_clean

- for the install files, for multiarch, a cleaner way would be to write
  /usr/lib/${DEB_HOST_MULTIARCH}/… instead of /usr/lib/*/…

-- 
Cheers,
tobi


signature.asc
Description: PGP signature

Bug#1058066: RFS ping

[Tobias Frost]

On Mon, Dec 18, 2023 at 05:30:46PM +0200, Alexandru Mihail wrote:
> Gently pinging about the current RFS;
> This contains an important fix for a problem which also affects stable
> (#1057842)

Please upload your package to mentors. Thanks.

> Thanks,
> Alexandru Mihail
> mini-httpd maintainer
> 

Bug#1057954: RFS: nanomsg/1.2+dfsg-1 [ITA] -- nanomsg utilities

[Tobias Frost]

Control: tags -1 moreinfo

Hi Phil,

Thanks for planing to adopt nanomsg!

(I've granted you access rights to the salsa repository, you should be
able to commit your changes - a recommendation here is to ask for this
in the RFS, not only as a comment on mentors.d.n)

The package seems to be gone from mentors, so the bot auto-closed this RFS.
However, based on below changelog information, some feedback.

On Sun, Dec 10, 2023 at 10:11:29PM +, Phil Wyett wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "nanomsg":
> 
>  * Package name : nanomsg
>Version  : 1.2+dfsg-1
>Upstream contact : Martin Sústrik 
>  * URL  : https://nanomsg.org/
>  * License  : Expat
>  * Vcs  : https://salsa.debian.org/debian/nanomsg
>Section  : libs
> 
> The source builds the following binary packages:
> 
>   libnanomsg6 - high-performance implementation of scalability libraries
>   libnanomsg-dev - nanomsg development files
>   nanomsg-utils - nanomsg utilities
> 
> To access further information about this package, please visit the following 
> URL:
> 
>   https://mentors.debian.net/package/nanomsg/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/n/nanomsg/nanomsg_1.2+dfsg-1.dsc
> 
> Changes since the last upload:
> 
>  nanomsg (1.2+dfsg-1) unstable; urgency=medium
>  .
>* New upstream version 1.2.
>* Soname bump rename package to libnanomsg6.

Please note that there is a mandotory procedure to be followed when
there is a SO-NAME bump. You can find the details here:
https://wiki.debian.org/Teams/ReleaseTeam/Transitions (for example you
need to target experimental first, this was the glue for me that it
seems not to be followed.)

>* New maintainer (Closes: #871443).
>* d/control: Use debhelper-compat 13.
>  - Update paths for missing files.
>* d/control: Use HTTPS homepage URL.
>* d/control: Remove unneeded '${shlibs:Depends}'.
>* d/control: Update 'Standards-Version' to 4.6.2.0 - No Changes required

Cheers, 
--
tobi

Bug#1055951: RFS: multispeech/4.6.0-1 [ITP] -- Multilingual speech server for Emacspeak

[Tobias Frost]

Am Fri, Dec 01, 2023 at 08:38:55AM +0300 schrieb Igor B. Poretsky:
> Hello Tobias,
> 
> >>>>> "Tobias" == Tobias Frost  writes:
> 
> Tobias> You should be able to just re-upload to mentors. If it does
> Tobias> not allow that, remove the package manually from mentors,
> Tobias> then re-upload. In the case a bot auto-close this RFS bug,
> Tobias> just manually re-open it (do not file a new one)
> 
> Indeed, I've done it without a problem. Thus, I've re-uploaded all my
> packages, not only Multispeech. And, since the issues listed are actual
> for other my packages as well, I tried to address them their as well.
> 
> Tobias> On further iterations, you keep at -1 until this is
> Tobias> sponsored.

> But some things should be fixed on the upstream level. Of course, I can
> do it with Debian patches, but is it a point when I am an upstream
> developer myself? How should I act in this situation?

The "-1" is the Debian revision; it is orthogonal to the upstream
version, (except the rules where it resets to usually -1, of course)

If you have fixes that goes into the upstream part, as upsream you can
always cut a new release, that will increase its version; that would
reset the Debian revision generally to -1.
If you for whatever reason don't want to make a new upstream release,
you can as well work with patches, in this case, you would increment the
debian revision *if the previous revision have been uploaded previously.

(Note that the "keep at -1" from my previous mail is meant for this RFS,
it is meant "don't change it until sponsored", in other words, if you
have another upload (after this has been sponsored), lets say "-2", you
would keep "-2" until the RFS is sponsored. Sorry if that caused
confusion.)

BTW, not sure if I pointed you to this document alraeady, but when
you are upstream as well, you should read this:
https://wiki.debian.org/UpstreamGuide

Cheers,
-- 
tobi

 
> Best regards,
> Igor.

Bug#1056362: RFS: ruby-mdl/0.13.0-4 -- Markdown lint tool - transitional dummy package

[Tobias Frost]

Also uploaded ruby-mdl_0.13.0-4~bpo12+1.dsc:
Uploading to ftp-master [DELAYED/6-day] (via ftp to ftp.upload.debian.org):

DELAYED/6 so that -4 it will be in testing when it enters the backport NEW 
queue.
(as per backports policy the same version needs to be in testing first.)

--
tobi

Bug#1055889: RFS: urlview/1b-1 [ITA] -- Extracts URLs from text

[Tobias Frost]

Control: tags -1 moreinfo

Hi,

a short review:
- d/copyright misses a few files/has inaccuracies, e.g enter.h
  please review & update.

Otherwise it looks good, thanks for taking care of urlview and your
contributions to Debian!

Cheers,
--
tobi

Bug#1055951: RFS: multispeech/4.6.0-1 [ITP] -- Multilingual speech server for Emacspeak

[Tobias Frost]

Am Sun, Nov 26, 2023 at 03:30:18PM +0300 schrieb Igor B. Poretsky:
> Hello Tobias,
> 
> Great thanks for your review. I'll try to address all the issues listed,
> but several questions by the way below:
> 
> >>>>> "Tobias" == Tobias Frost  writes:
> 
> Tobias> d/changelog: - An initial upload to Debian only have one
> Tobias> single entry, like "Initial Upload (Closes:
> Tobias> #)" (There are by definition no changes to the
> Tobias> packaging on initial upload.)  - As an consequence, the
> Tobias> debian revision must stay at -1 until sponsored.
> 
> Ok, but how can I return to the -1 debian revision now in my upload on
> mentors.debian.net? And what should I do further if it will not be the
> last iteration?

You should be able to just re-upload to mentors. If it does not allow that,
remove the package manually from mentors, then re-upload. In the case a bot
auto-close this RFS bug, just manually re-open it (do not file a new one)

On further iterations, you keep at -1 until this is sponsored.

> Tobias> - A library package needs a development package too.
> 
> But this library is not intended for a third-party development. It just
> implements core functionality that is common for two different
> frontends.

Ok, it seems that this library package could be dropped, if it is solely
internal. This will also make the packaging easier, as libraries are always
a bit more advanced.

I'd either statically link this internal library, or just compile the
source files seperately for both flavours of your binary.

> Tobias> - the library package must only contain the library, not
> Tobias> configuration files nor manpages. (makes them breaking when
> Tobias> an SONAME bump is required - see above about your Conflicts)
> 
> But this configuration is common as well and it is parsed by the library
> functions. Can you give me some hint what should I do in this situation?

The usual approach is here to have a -data package for the library.
Is is a possible scenario that users want different configuration for the
different frontends? In this case, the frontends should ship (separate)
configurations.
 
> Tobias> d/libmultispeech.shlibs - Why do you need this file?
> 
> For the version restriction in dependencies.

The Debian build system should be able to calculate dependencies on libraries
automatically, so obviously I'm missing some detail why this is not working
here.

> 
> Tobias> d/libmultispeech.links - why do you need the link? Is
> Tobias> multispeech to be invoked by the user directly or is it only
> Tobias> to be invoked by emacs? (as the usr/share/emacs seems to
> Tobias> indicate) (Disclaimer: I do not know anything about emacs
> Tobias> extension.)
> 
> Generally, it is used just by Emacspeak. This symlink is inherited
> historically from the old versions. Now I see no valuable reason for it.
> 
> Tobias> postinst - speech-dispatcher is using a systemd service
> Tobias> file, if you really need to reload its configuration, you
> Tobias> should use service speech-dispatcher reload and not kill it
> Tobias> via kill. (you might overkill)
> 
> Actually, it is not mandatory. Speech Dispatcher can as well be
> automatically spawned by a client. The kill command in this case just
> sends the SIGHUP signal, that does not kill or restart Speech
> Dispatcher, but only notifies it about a configuration change. It is
> documented behaviour of Speech Dispatcher. And I should notify every
> running instance regardless of the way it was launched by.

Additional data point: Looking at speech-dispatcher-espeak-ng, they are not
sending SIGHUP. So it seems not to be nedded, also not the service reload
(it seems to be discouraged to run it as system service)
 
> Best regards,
> Igor.

cheers,
-- 
tobi

Bug#1056690: RFS: dhcpcd/1:10.0.5-4 -- DHCPv4 and DHCPv6 dual-stack client

[Tobias Frost]

Control: tags -1 moreinfo

As Daniel said, this should be done on a VM, or if the hardware is
important, on a porter box.

See https://dsa.debian.org/doc/guest-account/
and then go to https://nm.debian.org/wizard to request an account.

(Using the buildds for debugging is inappropiate; hurd is not a release
architecture.)

Remove the moreinfo tag when there is something that makes sense to be
sponsored.

--
tobi

Bug#1055951: RFS: multispeech/4.6.0-1 [ITP] -- Multilingual speech server for Emacspeak

[Tobias Frost]

Control: tags -1 moreinfo

Hi Igor,

a short, but incomplete review on  multispeech_4.6.0-4.dsc, Uploaded 2023-11-24 
12:24
(For example, I did not do a d/copyright review.)

d/changelog:
 - An initial upload to Debian only have one single entry, like
   "Initial Upload (Closes: #)"
(There are by definition no changes to the packaging on initial
upload.)
 - As an consequence, the debian revision must stay at -1 until
   sponsored.

d/compat 
 - is obosolete, switch to B-D on debhelper-compat mechanisxm
 - compat level 10 is ancient. Update to 13. See
   debhelper-compat-upgrade-checklist(7) for what has changed.

d/control:
  - Standard Version is too old, update to 4.6.2, check the policy-upgrade
checklist for changes.
  - It B-D on cbds. cbds should no longer be used for new packages.
Convert to the debhelper sequencer.
  - It Recommends/Suggests/Conflicts on packages not in Debian, please
clean up here. (Do not recommend/suggest those packages)
For the conflict:
- libmultispeech5 conflicts on packages libmultispeechX (with X=0
  and 3). Even if the packages are not in Debian, this indicates
  that either
  - libmultispeechX had packaging issues. 
  - you are not aware that libmultispeechX must be co-installable,
and if they aren't the package needs to be fixed.
(Update: it is packaing errors, see below)
  - (the conflicts might be useful to transition existing users to 
 the Debian packages, if the Debian package would fail to
 install, but this would then be removed after trixie becomes
 stable.)
   - A library package needs a development package too.

d/rules:
  - Use the debhelper sequencer ("dh_")

d/libmultispeech5.install
  - You are not using multiarch.
  - the library package must only contain the library, not configuration
files nor manpages. (makes them breaking when an SONAME bump is
required - see above about your Conflicts)

d/libmultispeech.shlibs
  - Why do you need this file?

d/libmultispeech.links
  - why do you need the link? Is multispeech to be invoked by the user
directly or is it only to be invoked by emacs? (as the
usr/share/emacs seems to indicate)
(Disclaimer: I do not know anything about emacs extension.)

(not required but for consistency:)
 - the files d/docs d/install etc. should be names .docs
   .install to make it more obvious where they go. Of course
   this is defined by d/control when not doing so, but it helps
   understanding whats going on and also protects from problems if
   the package order in d/control is changed for whatever reason.)

prerm
  - not sure what your plans are with prerm, (should it be postrm?) what
you want to archive, but note that debconf questions should only be
removed when the package is purged.
  - use dh_installdebconf, if possible, instead.

postinst
  - speech-dispatcher is using a systemd service file, if you really
need to reload its configuration, you should use service
speech-dispatcher reload  and not kill it via kill. (you might
overkill)

- build log has warnings, for exmple:
dpkg-gencontrol: warning: package multispeech: substitution variable 
${perl:Depends} unused, but is defined
dpkg-gencontrol: warning: package multispeech: substitution variable 
${perl:Depends} unused, but is defined

- lintian:
+++ lintian output +++
su: warning: cannot change directory to /nonexistent: No such file or directory
I: libmultispeech5: conflicts-with-version multispeech (<< 4.0.0)
I: multispeech source: debian-watch-file-is-missing
I: libmultispeech5: hardening-no-bindnow [usr/lib/libmultispeech.so.5.1.2]
I: multispeech: hardening-no-bindnow [usr/bin/multispeech]
I: sd-multispeech: hardening-no-bindnow 
[usr/lib/speech-dispatcher-modules/sd_multispeech]
I: libmultispeech5: hardening-no-fortify-functions 
[usr/lib/libmultispeech.so.5.1.2]
I: multispeech: hardening-no-fortify-functions [usr/bin/multispeech]
I: sd-multispeech: hardening-no-fortify-functions 
[usr/lib/speech-dispatcher-modules/sd_multispeech]
I: multispeech source: no-dh-sequencer [debian/rules]
I: libmultispeech5: no-symbols-control-file usr/lib/libmultispeech.so.5.1.2
I: multispeech source: out-of-date-standards-version 4.5.1 (released 
2020-11-17) (current is 4.6.2)
I: libmultispeech5: typo-in-manual-page "allows to" "allows one to" 
[usr/share/man/man5/multispeech.conf.5.gz:134]
I: libmultispeech5: typo-in-manual-page "allows to" "allows one to" 
[usr/share/man/man5/multispeech.conf.5.gz:157]
I: libmultispeech5: typo-in-manual-page "allows to" "allows one to" 
[usr/share/man/man5/multispeech.conf.5.gz:186]
I: multispeech: unused-debconf-template shared/emacspeak/groupies 
[templates:104]
I: multispeech: unused-debconf-template shared/emacspeak/invalidport 
[templates:92]
I: multispeech: unused-debconf-template shared/emacspeak/invaliduser 
[templates:166]
I: multispeech: unused-debconf-template shared/emacspeak/rootgroup 
[templates:188]
P: 

Bug#1056731: RFS: backintime/1.4.1-0.1 [NMU] -- simple backup/snapshot system (graphical interface)

[Tobias Frost]

Hi Fabio,

Am Sat, Nov 25, 2023 at 07:33:32PM +0100 schrieb Fabio Fantoni:
> Il 25/11/2023 18:10, Tobias Frost ha scritto:
> > This seems a bit ouf of scope for an NMU (new upstream releases are
> > NMUed only in exceptional cases) and #998105 is severity normal and
> > #973760 is severity minor. (Please see the developers reference about
> > NMUs.
> > 
> > Do you have additional information why this should be an NMU?
> > I'm seeing you are member of the repo, should your name be added as
> > Uploaders and this be a regular upload?
> > Did you reach out to the maintainers and get an ACK from them?
> > 
> Hi, thanks for reply. I recently did some help on this package because I use
> it, so when I see cases with issue and/or new upstream version (with useful
> things) where a lot of time passes I try to help if I have time.
> 
> even if #998105 is only set "normal" is "a regression" that make users that
> backup over ssh waste time to found the workaround, I tried also to be fixed
> for bookworm (before release) with a upload with only this fix 
> (https://salsa.debian.org/jmw/pkg-backintime/-/commit/0066cffd98aa09c5528cb94abedda5a1a5e59e3e)
> but was rejected by the maintainer, then he replied to me who just wanted to
> wait for the bookworm release and have additional things before making a new
> upload. so I gave up and waited until after the new upstream version came
> out (and I still waited another month before doing anything)

It seems that commit was done during or just before the hard-freeze, and thus 
not
acceptable as per release policy.

The problem's severiy "normal" seems to be appropiate, too.

> Although it is not such a long time or with such serious bugs from the
> general point of view of debian, some upstream developers and users have
> come to consider this package as abandoned, here is an example:
> https://bugs.launchpad.net/ubuntu/+source/backintime/+bug/2039271 (anyway
> In that case it would not have been possible to upload the new upstream
> version anyway as that Ubuntu version was in freeze)

(Ubuntu != Debian.)
And as you say on the launchpad bug, 4 uploads a year well means this package
is maintained.

> 
> I would prefer a normal upload (from the maintainer), already prepared and
> tested, it also saves time, but unfortunately as I wrote at the moment I
> have not received any response and I had only been given permission for the
> repository previously where I already started to prepare for new upload one
> month ago. I also write to upload with delay for give another possibility to
> the maintainer, if he will have time
> 
> regarding the maintainers list I think it would be good to have it in the
> debian python team but doing this or possibly adding me as co-maintainer is
> a choice of the current maintainer. however I can't guarantee that I would
> have enough time to follow it and make quick enough uploads when needed in
> the long term.
> 
> If the maintainer responds to me in the future I will ask if he wants do
> something.

thanks for your explanations. Unfortunatly, I fear that your NMU is outside of
the scope of NMUs, despite the good intentions you have.

NMUing a new upstream version is only appropiate under certain conditions. For
example it is preferred to have dedicated patches to fix problems (but not
during a freeze, of course)

So if you come up with dedicated fixes, this NMU can go forward, otherwise, I
fear, not, unless the maintainer actively acked. (There is also no bug that
expressed the intention that you are going to NMU on the package's BTS)

Other option would be to invoke the ITS process, but I'm not sure (as in I did
not check in depth),whether the package would be eligble. Of course, you will
have to commit to the maintainance of the package then.
(But a NMU does also, albeit not to the same extend.)

-- 
tobi

Bug#1056731: RFS: backintime/1.4.1-0.1 [NMU] -- simple backup/snapshot system (graphical interface)

[Tobias Frost]

Control: tags -1 moreinfo


On Sat, Nov 25, 2023 at 05:39:44PM +0100, Fabio Fantoni wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "backintime":
> 
>  * Package name : backintime
>    Version  : 1.4.1-0.1
>  * URL  : https://github.com/bit-team/backintime
>  * License  : GPL-2+
>  * Vcs  : https://salsa.debian.org/jmw/pkg-backintime
>    Section  : utils
> 
> The source builds the following binary packages:
> 
>   backintime-common - simple backup/snapshot system (common files)
>   backintime-qt - simple backup/snapshot system (graphical interface)
> 
> To access further information about this package, please visit the following
> URL:
> 
>   https://mentors.debian.net/package/backintime/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/b/backintime/backintime_1.4.1-0.1.dsc
> 
> After one month from new upstream version without no activity on debian
> packaging I prepared it on git https://salsa.debian.org/jmw/pkg-backintime
> 
> After some days, 21 day ago I also write a mail to maintainer without reply
> for now
> 
> So I prepared this NMU, can someone upload it with a delay of few days
> please? to give a further upload possibility to the maintainer, just as I
> have not uploaded the release commit to git (I will only do it if the nmu
> reaches the repository)
> 
> 
> Changes since the last upload:
> 
>  backintime (1.4.1-0.1) unstable; urgency=medium
>  .
>    * Non-maintainer upload
>    * New upstream version 1.4.1 (Closes: #998105, #973760)
>    * d/patches: remove one patch applied upstream
>    * Update d/copyright

This seems a bit ouf of scope for an NMU (new upstream releases are
NMUed only in exceptional cases) and #998105 is severity normal and
#973760 is severity minor. (Please see the developers reference about
NMUs.

Do you have additional information why this should be an NMU?
I'm seeing you are member of the repo, should your name be added as
Uploaders and this be a regular upload?
Did you reach out to the maintainers and get an ACK from them?

Cheers,
tobi

> Regards,
 -- 
>   Fabio Fantoni
> 

Bug#1056285: RFS: opendkim/2.11.0~beta2-9 -- DomainKeys Identified Mail (DKIM) signing and verifying milter

[Tobias Frost]

Control: owner -1 !
Control: tags -1 moreinfo

Hi David,

thanks for providing this update, especially for CVE-2022-48521.

A question to that: Can you elaborate a bit on the testing you have
done to verify that this patch indeed fixes the vulnerability?
(Asking, becasue unfortunatly there is not lot of information available
e.g from the upstream issue and upstream seems to be generally very
silent…

Said that, if we have a high confidence in this patch, this fix should
also propagate to stable (via stable-proposed-updates) and oldstable.
I'm happy to sponsor such uploads. 

Except the information request, this package is ready to be sponsored,
and I will do so once the me-being-paranoid-question has been answered
;-)

-- 
Cheers,
tobi


On Sun, Nov 19, 2023 at 09:30:22PM +0100, David Bürgin wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "opendkim":
> 
>  * Package name : opendkim
>Version  : 2.11.0~beta2-9
>Upstream contact : The Trusted Domain Project
>  * URL  : http://www.opendkim.org/
>  * License  : BSD-3-clause and SOSL, ISC, GPL-3+ with AutoConf 
> exception
>  * Vcs  : https://salsa.debian.org/debian/opendkim
>Section  : mail
> 
> The source builds the following binary packages:
> 
>   opendkim - DomainKeys Identified Mail (DKIM) signing and verifying milter
>   opendkim-tools - utilities for administering the OpenDKIM milter
>   libopendkim11 - DomainKeys Identified Mail (DKIM) library
>   libopendkim-dev - DomainKeys Identified Mail (DKIM) library (development 
> files)
>   libvbr2 - Vouch By Reference (VBR) library
>   libvbr-dev - Vouch By Reference (VBR) library (development files)
>   librbl1 - Real-time Blacklist (RBL) query library
>   librbl-dev - Real-time Blacklist (RBL) query library (development files)
>   miltertest - utility for testing milter applications
> 
> To access further information about this package, please visit the following 
> URL:
> 
>   https://mentors.debian.net/package/opendkim/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/o/opendkim/opendkim_2.11.0~beta2-9.dsc
> 
> Changes since the last upload:
> 
>  opendkim (2.11.0~beta2-9) unstable; urgency=medium
>  .
>[ David Bürgin ]
>* debian/patches: Add missing upstream bug metadata, add new patches:
>  - rev-ares-deletion.patch: Delete Authentication-Results headers in
>reverse, addresses CVE-2022-48521 (Closes: #1041107).
>  - ares-missing-space.patch: Add missing space in Auth-Results header.
>* Replace transitional libldap2-dev with libldap-dev in Build-Depends.
>* Remove obsolete lsb-base dependency in opendkim package.
>* Delete obsolete entries in debian/opendkim.NEWS.
>  .
>[ Samuel Thibault ]
>* d/rules: Generalize hurd-i386 into hurd.
> 
> Thank you.
> 
> 
> -- 
> David
> 


signature.asc
Description: PGP signature

Bug#1056273: RFS: c-evo-dh/1.10-1 -- Empire Building Game (data files), C-evo: Distant Horizon

[Tobias Frost]

Control: tags -1 moreinfo

Hi Peter,

On Sun, Nov 19, 2023 at 01:59:09PM +, Peter B wrote:
>  c-evo-dh (1.10-1) unstable; urgency=medium
>  .
>    * New Upstream Release, (Closes: #1055837)
>    * Add NEWS file

You NEWS file seems to be a duplication of the upstream changelog file. Please
install that (eg using an override for dh_installchangelogs) instead and drop 
NEWS again.

Please document *all* changes to the packaging in d/changelog, for
example putting it in team maintaince needs to be mentioned.
There is another undocumented change in d/rules.

After that is fixed, it will be ready for upload.

-- 
tobi

Bug#1055101: Remove moreinfo tag

[Tobias Frost]

Control: tags -1 moreinfo

Hi Daniel,

thanks for working on the package, appreciating the progress!

I've enabled CI for the package on salsa, in case you're wondering about
that.

Let me continue on the review, as said, the last one was only a short
review.

- lintian 
W: libapache2-mod-authn-otp source: timewarp-standards-version (2022-05-05 
< 2022-12-17)

(You need to touch the date on d/changelog… hint: dch -r "" )

I: libapache2-mod-authn-otp: hardening-no-bindnow [usr/bin/genotpurl]
I: libapache2-mod-authn-otp: hardening-no-bindnow [usr/bin/otptool]

This could be false positives, please review whether this is true or a
false positive, e.g some compiler flags are not passed appropiatly.
(There's a wiki page on wiki.d.o about hardening:
https://wiki.debian.org/Hardening)

Update: CI revealed that this are indeed missing compiler flags.
I also see that in configure.ac CFLAGS are replaced, not ammended.

- d/copyright is incomplete / inaccurate.
  d/copyright needs to reflect what the code says, and must be "verbatim".
  For example, You write "2009-", the "-" is incorrectly, a correct span
  needs to have a target. In the case of this source (but I did only
  grep on it), it seems that it should be 2009 only.
  - Please make sure every license is covered. For example, base32.c has a
  different license and copyright holder.

- upstream tarball differs in hash.
  
  probably a pristine-tar issue, if you re-generated the tarball from
  there. Please use the tarball retrived from upstream:

sha256 sums:
c2c41cd3404d1d9560e38a92d1afc70751d3d569978e8b4fe7e4a53b5e806033  
upstream/1.1.10.tar.gz
9151b4ee47680ef21ba89b66bb45a4b49c5d5a33cf12562507d6405e3d61f480  
mentors/libapache2-mod-authn-otp_1.1.10.orig.tar.gz

- (not required to be fixed for this upload)
The package does not cross-compile. It would be nice if that could be
fixed.

- There is a warning emitted by the compiler that indicates that there
  might be a buffer overflow. Please investigate and patch if required.
  (I did not investigate the context of the usage of snprintf e.g in
  motp.c, but this might well have security impact.)


-- 
Cheers,
tobi

On Fri, Nov 17, 2023 at 07:03:30PM +, Daniel Fancsali wrote:
> Control: tag - moreinfo
> 
> Thanks for the review Tobias.
> 
> Well, that happens if you put something on the back-burner for some time. ;)
> 
> I do apologise...
> 
> All should be fixed now.
> 
> Cheers,
> Daniel
> 


signature.asc
Description: PGP signature

Re: Salsa repositories requested

[Tobias Frost]

On Fri, Nov 17, 2023 at 05:19:50PM +, Peter B wrote:
> Hi,
> 
> I'm adopting ifstat https://tracker.debian.org/pkg/ifstat
> and would like to setup the packaging VCS under the debian group in Salsa.
> As a DM I don't have the access to do this myself.

Done.

> If its not too much extra work to set up two repositories,
> I would also like to have one for mp3guessenc
> https://tracker.debian.org/pkg/mp3guessenc

Done


Please import all previous uploads, e.g by gbp import-dscs --debsnap 

(Thanks for your contributions to Debian and maintaining those packages!)

--
tobi

Bug#1055448: RFS: libsilkit/4.0.37-1 [ITP] -- Simulation in the loop kit by Vector

[Tobias Frost]

On Tue, Nov 14, 2023 at 07:45:36AM +, Krämer, Jan wrote:

> Hi Tobias,
> 
> I still have some questions:
> 
> - Is it permitted to update the libsilkit version (to 4.0.39) within the 
> review process?
Yes, you can update to a later version.

(if you do so, just upload it to mentors.d.n and then retitle this RFS
bug to reflect the new version.)

> - The only remaining vendoring is GoogleTest, which is only used for
> the unit/integration tests which are not shipped by the package. Is
> this allowed or should we use the systems libraries here as well?

It's packaged, so the packaged version should be used.

> - Related, if this is allowed, do we need to include the License
> information, since we do not ship source files nor object files
> compiled with these source files in the binary package?

My understanding is that your d/copyright needs to reflect *everything* you 
ship in your orig.tar.

> Cheers and thanks again for the review,
> Jan

Cheers,
-- 
tobi

Bug#1055448: RFS: libsilkit/4.0.37-1 [ITP] -- Simulation in the loop kit by Vector

[Tobias Frost]

Control: tags -1 moreinfo

Hi Jan,

Thanks for your RFS!
as you are listed as upstream contact, let me, as I always do, point you to
https://wiki.debian.org/UpstreamGuide

As this is your first package your are maintaining, please also read
https://mentors.debian.net/intro-maintainers/

This part of the CONTRIBUTING.md concerns me:
  We are sorry, but at the moment, we do not accept external contributions until
  wehave established a contribution process. We're working behind the scenes to
  get this ready in the future. Until then, we would kindly ask you to not open 
pull
  requests.

This stanca is older than a year (Aug 2022), so when will this happen?

Sorry to be blunt, but putting a DFSG license on a piece of software and
then saying we do not accept contributions, is (IMHO) not within the
spirit of the Open Source Community, even if it might on paper fullfil
the DFSG.

This is also problematic for maintaining the package, as how should we,
as Debian, upstream patches, for example if you are go missing for
whatever reasons? Effectively, we would need to maintain a fork, and
that is certainly nothing Vector could want.

I'd say this brings the RFS very close to the "wontfix" territory,
certainly I will not sponsor this upload, but other sponsors might.
(The review below is partial, done until I saw the README.)

In Debian we do not package every software. So maybe I'll need a salse
pitch here:
- Why does Vector want it in the Debian archives?
- Why would Debian want it to be in the Debian archives?
- Are there other projects using the library that you intend to package
  for Debian?

On Mon, Nov 06, 2023 at 12:57:23PM +, 
=?UTF-8?Q?Kr=C3=a4...@buxtehude.debian.org wrote:
 
>  * Package name   : libsilkit 
>     Version    : 4.0.37-1 
>     Upstream contact : jan.krae...@vector.com 
>  * URL    : https://github.com/vectorgrp/sil-kit 
>  * License   : MIT 
>  * Vcs  : https://github.com/vectorgrp/sil-kit
>    Section    : libs 
> 
> The source builds the following binary packages: 
> 
>   libsilkit-dev - Development packages for libsilkit 
>   libsilkit4 - Simulation in the loop kit by Vector 
> 
> To access further information about this package, please visit the following 
> URL: 
> 
>   https://mentors.debian.net/package/libsilkit/ 
> 
> Alternatively, you can download the package with 'dget' using this command: 
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/libs/libsilkit/libsilkit_4.0.37-1.dsc
>  
> 
> Changes for the initial release: 
>  libsilkit (4.0.37-1) unstable; urgency=medium 
>  . 
>    * Reworked the documentation on Virtual Time Synchronization 
>    * The documentation of the demo section now refers to the pre built Vector 
>  SIL Kit packages and not to a source build. 
> 
> An ITP bug for the wnpp package can be found here:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055064

Here's a short review on your package: As the build fails, it is likely
to be incomplete.

- d/changelog: An initial upload has no changes, so it would just say
  "Initial upload. Closes: #your-itp-bug."
  
  (As there is a lots of history in d/changelog: This file is not the
  upstream changelog, is about recording changes to the packaging.)

  However, as said, your only entry for the initial upload is as I
  described above, delete the rest.

- d/control:
  - cmake >= 3.20 is aready fulfiled in stable, you can drop the
 versioned part.
  - you have a -dev package and a library package - good!
However, I see that you are installing a systemd service file, that
means you also need a non-library binary package so that multi-arch
will work. (something like a -tools package

- manpage: It says it is autogenerated, so you need to generate it
  during build. As you are upstream, include the manpages upstream, so
  other distributions will benefit too.

- src/ThirdPArty (most of the directories are empty, possibly this is
  the reason for the FTBFS)
  You cannot vendor libraries in Debian, you must use packaged versions.
  If it is not packaged, you have to package it.

- It FTBFS in a clean pbuilder enviornment. (asio not found) Likely
  missing dependencies Checkout sbuilder or pbuilder to make sure to
  build in a clean enviornment.

- d/copyright claims that *EVERY* file is Copyright: 2023 Vector Informatik GmbH
  despite ThirdParty/LICENSES.rst is contradicting it.
  The year is not correct either, I saw at least one file with the year
  2022. 
  Please review every file and record the copyright information
  appropiatly. 
  I did not do a complete copyright review.

- There is no watchfile

- d/control VCS-* needs to point where the *packaging* resides,
  not to the upstream repo. see Policy for details.
  (Due to CONTRIBUTING.md any other location than salsa.d.o is
  IMHO inacceptable.) 

- Stopping here after seeing CONTRIBUTING.md.

-- 
Cheers from Regensburg,

Bug#1054561: RFS: qnetload/1.3.6-1 [ITP] -- Graphically display network speed and usage

[Tobias Frost]

Control: tags -1 moreinfo

Hi,

On Thu, Oct 26, 2023 at 12:24:13AM +0100, Carles Pina i Estany wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
>  * Package name : qnetload
>Version  : 1.3.6-1

(Review of Upload #3 Uploaded:  2023-10-25 23:09)

- autopkgtests: thanks for having one, but this test should be marked
  superficicial.

  (optional: For a non superficial test, you could run your test suite in
  autopkgtest.)

- d/copyright should have the complete license boiler plate for GPL-3

Otherwise, package looks good. Please fix those two issues and I'll upload.

Remove the moreinfo tag when ready!

--
tobi


signature.asc
Description: PGP signature

Bug#1051397: About the RFS for ukui-greeter, ukui-biometric-auth and ukui-screensaver

[Tobias Frost]

Control: tags -1 moreinfo

Hi liudun,

the package tracker does not list you as uploader, so I wonder if this
upload has been discussed with the packaging team beforehand?

(please remove the moreinfo tag when that has been clarified)

-- 
tobi

Bug#1053565: RFS: openvpn3-client/20+dfsg-1 [ITP] -- virtual private network daemon (version 3)

[Tobias Frost]

Control: tags -1 moreinfo

Hi Marc,

On Fri, Oct 06, 2023 at 03:03:02PM +0200, Marc Leeman wrote:
> Package: sponsorship-requests
>  * Package name : openvpn3-client
>Version  : 20+dfsg-1
>Upstream contact : OpenVPN Solutions LLC 
>  * URL  : https://openvpn.net/
>  * License  : Gnu Affero General Public License 3
>  * Vcs  : https://salsa.debian.org/televic-team/openvpn3-client
>Section  : net
> 
(...)
> 
>  openvpn3-client (20+dfsg-1) unstable; urgency=medium
>  .
>* Initial release. (Closes: #904044)
>* d/control: do not depend on openvpn2 dev headers
>* d/postinst: create user before chown
>* d/README: add comment on lintian-warning unicode-impl.hpp
>* d/README: update dfsg motivation
>* remove sum files (see d/README.source)
> 
> Additional discussion on the packaging with upstream can be found here:
> https://github.com/OpenVPN/openvpn3-linux/issues/193

The issue and ITP talks about there being two packages, a library part
and the client part. Has this changed (I cannot find the library part.)

- changelog for an initial release should be only the first line, (as there
are no changes to the debian package on the initial upload)

- you are creating an user. [1]
  - As per Debian polic 9.3, the username shouldbe an invalid user and start 
with an "_" 
  - If I am not mistaken, you can use tmpfiles.d to specify the
directory /var/lib/openvpn to be owned by openvpn:openvpn, so that
snipped in postinst might not be needed. (please verify)

[1] https://wiki.debian.org/AccountHandlingInMaintainerScripts

- unicode-impl.hpp
I'm not convinced that this (license) issue is a non-issue. It might be
solved in later versions of the file, but the version in the tarball
does not allow modification.
As you are anyway dfsg repacking (at least the version indicates this,
see also below), hows' about removing the file and then reintroducing a
fine one with a patch?

- files installed in /usr/include 
  --> you want a -dev package.

- d/copyright 
  - is not DEP-5 format.
  - There is no indication why it is dfsg, and there id no
Files-Exluded section.. so are you repacking at all?
  - For praticality reasons, it is recommended to keep the license of
the debian the same as upstream. Otherwise, package upstreaming
might get more difficult than needed. (GPL2 is anyway incompatibel
with Affero GPL 3; your "or later" safes the day.)
  - There is license text for the Gnu Affero General Public License 3,
and it should be probably "AGPL-3" abbreviated.
  - Note: I did not do a license review of the source files. 


- lintian overrides
  - you need to comment the overrides WHY you overrode them.

- postinst 
  - remove the useless comment about utf-8, or let me know what you want
to say with it.

- the python part - I think this should be in a dedicated python module package?

- S-V could be updated.

- There is no watch file.

- The package is in a team namespace on salsa, but d/control does not
  indicate that it is team maintained.

As usual, remove moreinfo when you are done updating your package.

Cheers,
-- 
tobi

Bug#1053575: RFS: ruby-mdl/0.13.0-1 -- Markdown lint tool

[Tobias Frost]

Am Wed, Nov 01, 2023 at 11:55:29PM +0100 schrieb Norwid Behrnd:

Your transitional package needs to Depends: on the new package.

> The /debian/control file was edited to eventually yield an updated
> `markdownlint_0.13.0-1_all.deb` (for future use) and a transitional
> `ruby-mdl_0.13.0-1_all.deb`.  Does this meet the criteria better?
> 
> The additional lines replaces/provides/conflicts follow Andreas Fester's
> blog[1] and example.[2]  However, after reading current lintian's note and
> sections 7.3 and 7.6 of the Debian Policy Manual (v4.6.2.0) with
> 
> "[`Conflicts:`] can make it more difficult for the package manager to find a
> correct solution to an upgrade or installation problem." (see page 61).
> 
> I substituted `Conflicts:` for `Breaks:`.

> [1] https://www.labcorner.de/renaming-a-debian-package/
> [2] https://sources.debian.org/src/crossvc/1.5.0-1%2Betch1/debian/control/

I think you need also



> ``` file /debian/control
> Source: ruby-mdl
> Section: text
> Priority: optional
> Maintainer: Norwid Behrnd 
> Build-Depends: debhelper-compat (= 13),
>gem2deb (>= 1),
>ruby (>= 2.7),
>ruby-kramdown (>= 2.3),
>ruby-kramdown-parser-gfm (>= 1.1),
>ruby-mixlib-cli (<< 2.2),
>ruby-mixlib-cli (>= 2.1.1),
>ruby-mixlib-config (<< 4),
>ruby-mixlib-config (>= 2.2.1),
>ruby-mixlib-shellout
> Standards-Version: 4.6.2
> Vcs-Git: https://salsa.debian.org/nbehrnd/ruby-mdl.git
> Vcs-Browser: https://salsa.debian.org/nbehrnd/ruby-mdl
> Homepage: https://github.com/markdownlint/markdownlint
> Testsuite: autopkgtest-pkg-ruby
> Rules-Requires-Root: no
> 
> Package: markdownlint
> Architecture: all
> Depends: ${misc:Depends},
>  ${ruby:Depends},
>  ${shlibs:Depends}
> Replaces: ruby-mdl
> Provides: ruby-mdl
> Breaks: ruby-mdl (<< 0.13.0-1)
> Description: Markdown lint tool
>  markdownlint checks an individual markdown file, or a directory of markdown
>  files against a set of rules for syntax consistency.  In its report back
>  to the CLI, the Ruby based implementation reports the line(s) with an issue
>  identified and how to improve it.
> 
> Package: ruby-mdl
> Architecture: all
> Depends: ${misc:Depends}
> Section: oldlibs
> Description: Markdown lint tool - transitional dummy package
>  This is a transitional package for markdownlint. It can be safely removed.
> 
> ```
> 

Bug#1054422: RFS: pointback/0.2-5 [RC] [Team] -- restore window points when returning to buffers

[Tobias Frost]

Am Thu, Nov 02, 2023 at 08:34:03AM -0700 schrieb Xiyue Deng:
> Tobias Frost  writes:
> Will file an RM request.  Thanks for looking into this!

Just filed the bug. I've put you on Debbugs-CC, so you should get a copy.

--
tobi

Bug#1051498: RFS: strace/6.5-0.1 [NMU] -- System call tracer

[Tobias Frost]

Am Fri, Nov 03, 2023 at 09:11:46PM +0800 schrieb Bo YU:
> On Wed, Nov 1, 2023 at 8:45 PM Tobias Frost  wrote:
> >
> > Control: tags -1 moreinfo
> >
> > Hi Bo YU,
> >
> > can you expand on the background of the NMU?
> > A new upstream version are usually only acceptable in NMUs in rare
> > circumstances, so this needs extra explanation.
> 
> Thanks. In this time, the NMU for 6.5 is meaningless because upstream
> has released
> 6.6. I will close the RFS.

(If you are still working on the package, RFS should not be closed; they
should be kept and updated.)
 
> I want the NMU because I did the NMU at 6.4 and enable test to
> non-fatal for riscv64.
> But I think kernel has fixed the for 6.5, so I want to track the issue
> from my side.
> see #1043393.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043393

NMUs are regulated within Debian, see the developers reference for details,
but usually new upstream releases are out of scope for an NMU (as said already)


> >
> > Have you been in contact with Steve and told them about your intentions
> > to NMU it?
> 
> In fact, I am interesting to maintain the package and want to the fix
> RC[0] bug.
> I would to ask Steve will agree this or not.:)

You need to ask him ;-)
(For completeness, there is also the ITS procedure, but Steve is generally
active, so I guess asking him directly will be better)

> Thanks.
> Bo
> [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054998

This bug would be in scope for an NMU, however, not by a new upstream
release, but by providing a backported fix / patch for 6.4.0-1
(see developers reference, NMU should be minimal changes only and need
to fix actual bugs.)

-- 
Cheers,
tobi

 
> >
> > Cheers,
> > --
> > tobi
> >
> > On Sat, 9 Sep 2023 02:03:55 +0800 Bo YU  wrote:
> > > Package: sponsorship-requests
> > > Severity: normal
> > >
> > > Dear mentors,
> > >
> > > I am looking for a sponsor for my package "strace":
> > >
> > >  * Package name : strace
> > >Version  : 6.5-0.1
> > >Upstream contact : [fill in name and email of upstream]
> > >  * URL  : https://strace.io
> > >  * License  : [fill in]
> > >  * Vcs  : https://salsa.debian.org/debian/strace
> > >Section  : utils
> > >
> > > The source builds the following binary packages:
> > >
> > >   strace - System call tracer
> > >   strace64 - System call tracer for 64bit binaries
> > >   strace-udeb - System call tracer
> > >
> > > To access further information about this package, please visit the
> > following URL:
> > >
> > >   https://mentors.debian.net/package/strace/
> > >
> > > Alternatively, you can download the package with 'dget' using this
> > command:
> > >
> > >   dget -x
> > https://mentors.debian.net/debian/pool/main/s/strace/strace_6.5-0.1.dsc
> > >
> > > Changes since the last upload:
> > >
> > >  strace (6.5-0.1) unstable; urgency=medium
> > >  .
> > >* Non-maintainer upload.
> > >* New upstream version 6.5
> > >
> > > >-
> > >
> > > I'd be appreciated that if you import-dsc 6.4-0.1[0] to salsa[1] also
> > >
> > > [0]:
> > https://deb.debian.org/debian/pool/main/s/strace/strace_6.4-0.1.dsc
> > > [1]: https://salsa.debian.org/debian/strace
> > >
> > > --
> > > Regards,
> > > --
> > >   Bo YU
> > >
> >

Bug#1053662: RFS: qt5-ukui-platformtheme/4.1.0.1-1 -- Qt5 QPA platform theme of UKUI

[Tobias Frost]

Control: tags -1 moreinfo

Same as with the other packages, this first needs clarification.
This is a hidden NMU with xibowen adding themself as Uploaders, with
no information whether this was somehow discussed with the maintainers.

Same as #1053143:

> did you contact the maintainers prior to this RFS?
> 
> (pinging the team to make them aware of this RFS.)
> 
> The current state of sid/experimental does not say xibowen is an
> existing maintainer, so this is technically an NMU, and the changes
> are likely out of scope for an NMU -- see dev-ref)
> 
> This should be clarified if the current maintainers are aware.

--
tobi

Bug#1053575: RFS: ruby-mdl/0.13.0-1 -- Markdown lint tool

[Tobias Frost]

Control: tags -1 moreinfo
Control: forcemerge -1 1054258



On Wed, 1 Nov 2023 10:47:08 +0100 Norwid Behrnd 
wrote:
> The RFS ticket #1054258 /
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054258 
> aims to correct errors and substitute `ruby-mdl` by `mdl` for good. 
Thus, the
> uploaded to mentors.debian.net by 2023-10-29 finally uses only one
control file
> in common to assemble both `ruby-mdl` as the transition dummy package,
and
> `mdl` as the one where further curated in future.
> 

As Bastian said (and I did too, without knowing this bug report in
#1054258), this is not a good reason to rename a source package.
We explictly WANT to retrain the history of the package, for example.

I'm merging the bug reports, as we should be discussed on a single bug.

--
tobi

 

Bug#1053148: RFS: peony/4.1.1.1-1 -- file Manager for the UKUI desktop

[Tobias Frost]

Control: tags -1 moreinfo

Same as #1053143:

> did you contact the maintainers prior to this RFS?
> 
> (pinging the team to make them aware of this RFS.)
> 
> The current state of sid/experimental does not say xibowen is an
> existing maintainer, so this is technically an NMU, and the changes
> are likely out of scope for an NMU -- see dev-ref)
> 
> This should be clarified if the current maintainers are aware.

--
tobi

Bug#1053143: RFS: ukui-session-manager/4.0.0.0-1 -- Session manager of the UKUI desktop environment

[Tobias Frost]

Control: tags -1 moreinfo

Hi xibowen,

did you contact the maintainers prior to this RFS?

(pinging the team to make them aware of this RFS.) 

The current state of sid/experimental does not say xibowen is an
existing maintainer, so this is technically an NMU, and the changes
are likely out of scope for an NMU -- see dev-ref)

This should be clarified if the current maintainers are aware of this
NMU before this RFS goes forward.

On Thu, 28 Sep 2023 14:39:14 +0800 "=?utf-8?B?eGlib3dlbg==?=" > 
>  ukui-session-manager (4.0.0.0-1) unstable; urgency=medium
>  .
>    * New upstream release.
>    * Upload to unstable.

Not all changes seems documented, for example, that you'Ve added



> Regards,
> -- 
>   xibowen

 
Cheers,
tobi

Bug#1052015: RFS: blktrace/1.3.0-1 -- utilities for block layer IO tracing

[Tobias Frost]

Control: tags -1 moreinfo


Hi Daichi,

this seems to be a NMU, and for NMUs there is a set of rules [0], for
example it needs to fix (important) bugs.
 
Maybe I am missing something but I think this upload is outside of the
scope of an NMU. Please let me know if I missed something.


[0]
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#non-maintainer-uploads-nmus

-- 
tobi

Bug#1051498: RFS: strace/6.5-0.1 [NMU] -- System call tracer

[Tobias Frost]

Control: tags -1 moreinfo

Hi Bo YU,

can you expand on the background of the NMU?
A new upstream version are usually only acceptable in NMUs in rare
circumstances, so this needs extra explanation. 

Have you been in contact with Steve and told them about your intentions
to NMU it? 

Cheers,
-- 
tobi

On Sat, 9 Sep 2023 02:03:55 +0800 Bo YU  wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "strace":
> 
>  * Package name : strace
>    Version  : 6.5-0.1
>    Upstream contact : [fill in name and email of upstream]
>  * URL  : https://strace.io
>  * License  : [fill in]
>  * Vcs  : https://salsa.debian.org/debian/strace
>    Section  : utils
> 
> The source builds the following binary packages:
> 
>   strace - System call tracer
>   strace64 - System call tracer for 64bit binaries
>   strace-udeb - System call tracer
> 
> To access further information about this package, please visit the
following URL:
> 
>   https://mentors.debian.net/package/strace/
> 
> Alternatively, you can download the package with 'dget' using this
command:
> 
>   dget -x
https://mentors.debian.net/debian/pool/main/s/strace/strace_6.5-0.1.dsc
> 
> Changes since the last upload:
> 
>  strace (6.5-0.1) unstable; urgency=medium
>  .
>    * Non-maintainer upload.
>    * New upstream version 6.5
> 
> >-
> 
> I'd be appreciated that if you import-dsc 6.4-0.1[0] to salsa[1] also
> 
> [0]:
https://deb.debian.org/debian/pool/main/s/strace/strace_6.4-0.1.dsc
> [1]: https://salsa.debian.org/debian/strace
> 
> -- 
> Regards,
> --
>   Bo YU
> 

Bug#1050967: RFS: mesa/23.1.6-1~bpo12+1

[Tobias Frost]

Hi Jermey,

Have you coordinated this backports effort in any way with the mesa
maintainers? 

(mesa has in the meantime updated in testing to 23.2.x, so this version
is not suitable for backports anymore)

--
tobi

Bug#1054258: RFS: mdl/0.13.0-1 -- Markdown lint tool

[Tobias Frost]

>    * rename package (formerly `ruby-mdl`, now `mdl`) because it is an

Please keep the old (source) package name. 

Binary packages can be renamed independently.

(also, 3-letter package names litter the namespace, and should be
avoided.)

-- 
tobi

Bug#1054422: RFS: pointback/0.2-5 [RC] [Team] -- restore window points when returning to buffers

[Tobias Frost]

On Mon, Oct 23, 2023 at 10:12:50AM -0700, Xiyue Deng wrote:
> Package: sponsorship-requests
> Severity: important
> X-Debbugs-CC: debian-emac...@lists.debian.org
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "pointback":
> 
>  * Package name : pointback
>Version  : 0.2-5
>Upstream contact : Markus Triska 
>  * URL  : https://www.metalevel.at/pointback/
>  * License  : GPL-3+
>  * Vcs  : https://salsa.debian.org/emacsen-team/pointback
>Section  : lisp
> 
> The source builds the following binary packages:
> 
>   elpa-pointback - restore window points when returning to buffers
> 
> To access further information about this package, please visit the following 
> URL:
> 
>   https://mentors.debian.net/package/pointback/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/p/pointback/pointback_0.2-5.dsc
> 
> Changes since the last upload:
> 
>  pointback (0.2-5) unstable; urgency=medium
>  .
>* Team upload.
>  .
>[ Nicholas D Steeves ]
>* Drop emacs24 and emacs25 from Enhances (packages do not exist in
>  bullseye).
>  .
>[ Debian Janitor ]
>* Bump debhelper from old 10 to 13.
>* Set debhelper-compat version in Build-Depends.
>  .
>[ Xiyue Deng ]
>* Add patch migrate-from-removed-assoc-el.patch to migrate from
>  obsoleted functions in assoc.el which has been removed since Emacs
>  29.1 (Closes: #1042900).
>* Drop Built-Using which should not be used for an "arch: all" package.
>* Update Standards-Version to 4.6.2.  No change needed.
>* Drop emacs version in Recommends which is from oldoldstable.
>* Add d/watch with comments of no real upstream version control.
>* Update d/copyright year and add Upstream-Contact.
> 
> Regards,
> -- 
> Xiyue Deng

Looks good, but one question:
Upstream says: 

As of Emacs 26.1, switch-to-buffer-preserve-window-point defaults to t, which 
solves the problem that pointback.el addresses.

Is this pacakge (pointback) obsolete and should it be kept in Debian?

(As the package is fine, I'm uploadig it, but if it is obsolete, please
file a bug for removal.)


Please also investiate: 
 I: elpa-pointback: wrong-section-according-to-package-name lisp => editors

-- 
tobi

Bug#1055041: RFS: a2d/2.0.3-1 -- APRS to DAPNET portal

[Tobias Frost]

Control: tags -1 moreinfo

Hi Yogeswaran,



>   dget -x https://mentors.debian.net/debian/pool/main/a/a2d/a2d_2.0.3-1.dsc
> 
> Changes since the last upload:
> 
>  a2d (2.0.3-1) unstable; urgency=medium
>  .
>* New upstream version.
>* Fixed failed VCS repository. (Closes: #1055040)

I've took a look at your package:


- You do not replace the debian changelog, you append the new
  information. (hint: use "debchange" or "dch" for changelog manipulation)

- there are undocumented changes, for example it seems that dependencies
  has been changeed. that (and why it is) should be noted in
  d/changelog.


(You are also upstream)
- It seems you have renamed a2dapp to a2d. This change is not good,
  as it is too short / generic, and renaming is a breaking change
  for your users. I'd appreaciate if you could stay with the old name.

- Do you really need an hard dependency on nginx?
  (I've checked myself: I think you don't. you'll use nginx as a proxy,
  but people might want to setup e.g another http server for that or
  even directly connect to the 9333 port (can they?); I think nginx
  should be Recommends: not Depends: -- see policy about the definition
  of Depends.)

- You README.md suggests to do rm -rf 
  That is bad advice! Do not blindly say that they should nuke the nginx
  configuration; (If, then the user should run apt purge nginx, but this
  is also still dangerous a people might loose data); deluser is also
  a bad advice, (system) users should not be deleted after they have
  been created.

- postinst is wrong. Especially you do not remove those files on
  "remove" -- only purge should delete user configuration, for example.

Thinking about it I am not sure if you are handling conffiles correctly,
as your postrm will nuke also files not handled by your packge, by
blindly removing them. This is an RC bug. Probably your application
will create files there? Maybe than /etc/ is the wrong location, maybe
app-created files should be reside in /var/lib/a2d? I'm not sure here
if/how this is handled correctly, maybe someone else will chime in.
I'm just sure that "rm -r /etc/a2d" could make some admins unhappy.

(I'm running out of time here, the review might not be complete)

--
tobi


> Regards,
> -- 
>   Yogeswaran Umasankar
> 

Bug#1055101: RFS: libapache2-mod-authn-otp/1.1.10-1 -- Apache module for one-time password authentication

[Tobias Frost]

Control: tags -1 moreinfo

>   
> 
> Alternatively, you can download the package with 'dget' using this 
> command:
> 
>   dget -x 
> 
> 

I don't think your package is called hello ;-)

FTR: It is here:
https://mentors.debian.net/package/libapache2-mod-authn-otp/

A short review: 

- The mentors pages says there is not watchfile
- You need to claim the ITP, as it had become RFP due to inactivity.

- The package should be maintained on salsa; let me know your username
on salsa and I set up a repository in the debian/ namespace.

- Standard-Version is outdated.

- d/copyright 
  I recommend *against* having different licenses for upstream and  
debian/*, as it makes it more difficult to e.g send patches upstream,

- d/libapache2-mod-authn-otp-docs.docs list docs that do not exists.
  (you probably dont need this file at all) 


lintian:
X: libapache2-mod-authn-otp source: upstream-metadata-file-is-missing


Please fix above, and I will take another look; remove the "moreinfo"
tag when ready!

-- 
Cheers,
tobi

Bug#981030: RFS: sctk/2.4.10-20151007-1312Z+dfsg2-4 -- speech recognition scoring toolkit

[Tobias Frost]

Hi Guili,

If you are still interested in this RFS, please ping me and update your
package according to the informations given in this RFS (e.g the NMU).

When ready, put the package on mentors and ping me, and I will have a
look.

-- 
Cheers,
tobi

Bug#1054320: RFS: onefetch/2.18.1-1 [ITP] -- Command-line Git information tool

[Tobias Frost]

Control: tags -1 moreinfo

Hi Ossama,

On Sat, Oct 21, 2023 at 05:40:26PM +, Ossama Hjaji wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "onefetch":
> 
>  * Package name : onefetch
>Version  : 2.18.1-1
>Upstream contact : Ossama Hjaji 
>  * URL  : https://github.com/o2sh/onefetch
>  * License  : MIT
>  * Vcs  : https://salsa.debian.org/o2sh/onefetch
>Section  : utils
> 
> The source builds the following binary packages:
> 
>   onefetch - Command-line Git information tool
> 
> To access further information about this package, please visit the following 
> URL:
> 
>   https://mentors.debian.net/package/onefetch/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/o/onefetch/onefetch_2.18.1-1.dsc
> 
> Changes for the initial release:
> 
>  onefetch (2.18.1-1) unstable; urgency=medium
>  .
>* 2.18.1 release (Closes: #943720).
> 
> Regards,
> --
>   Ossama Hjaji

A small look at your package. Please note that I am not familiar with
Rust, so I won't sponsor the upload. You might want to reach out to the 
Rust packaging team. (https://wiki.debian.org/Teams/RustPackaging).
Check also their rust packaging policy, 

As you are upstream: https://wiki.debian.org/UpstreamGuide

- it build-depends on CMake, but I don't see any CMakeLists.txt 
- you cannot vendor dependencies. (file: debian/vendor.tar.gz)
  all external dependencies must be pulled in by Debian packages.
- d/onefetch-docs.docs mentions non-existing files.
- d/changelog: the only entry for the initial upload should just read "Initial 
release (Closes: #ITP-bug)"
  (That it is the 2.18 release is redundant.)

lintian:
   I spelling-error-in-binary
Afe Safe [usr/bin/onefetch]
extention extension [usr/bin/onefetch]

P package-uses-old-debhelper-compat-version
11
P silent-on-rules-requiring-root
[debian/control]
P trailing-whitespace
[debian/changelog:6]
[debian/rules:16]
P uses-debhelper-compat-file
[debian/compat]
 
-- 
tobi

Re: Package remains in status "Uploaded"

[Tobias Frost]

On Tue, Sep 26, 2023 at 11:56:56PM +0200, Preuße, Hilmar wrote:
> Hi all,
> 
> the package texinfo has been built successfully for architecture loong64 and
> is in status "Uploaded" for about a month now. I'm pretty sure there are a
> lot of packages in status "BD-Uninstallable" b/c it does not get installed.

Unfortunatly it is not possible to give-back the package:
 
 You are authenticated as tobi. ✓
 Working on package texinfo, suite sid and architecture loong64. ✓
 Package in state Uploaded, cannot give back. ✗

> What can be done here?
> 
> Hilmar
> -- 
> sigfault
> 





signature.asc
Description: PGP signature