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

2024-03-06 Thread Joachim Zobel
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.

Sincerely,
Joachim



Bug#1065397: RFS: libunistring/1.2-1 -- Unicode string library for C

2024-03-06 Thread Boyuan Yang
Control: tags -1 +moreinfo
X-Debbugs-CC: debian@jff.email

Hi,

On Sun, 03 Mar 2024 21:24:43 +0100 =?ISO-8859-1?Q?J=F6rg_Frings-F=FCrst?= 
 wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "libunistring":
> 
>  * Package name : libunistring
>    Version  : 1.2-1
>    Upstream contact : Bruno Haible 
>  * URL  : https://www.gnu.org/software/libunistring/
>  * License  : GPL-2+ with distribution exception, Expat and GPL-2+, 
>   LGPL-3+ or GPL-2+, FreeSoftware, GPL-3+, GPL-3+ or 
>   GFDL-NIV-1.2+, X11, GPL-2+ with distribution exception, 
>   GPL-2+
>  * Vcs  : https://git.jff.email/cgit/libunistring.git
>    Section  : libs
> 
> The source builds the following binary packages:
> 
>   libunistring-dev - Unicode string library for C - development files
>   libunistring5 - Unicode string library for C
> 
> To access further information about this package, please visit the following
> URL:
> 
>   https://mentors.debian.net/package/libunistring/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>  dget -x 
>https://mentors.debian.net/debian/pool/main/libu/libunistring/libunistring_1.2-1.dsc
> 
> or from 
> 
>  git https://git.jff.email/cgit/libunistring.git/?h=release%2Fdebian%2F1.2-1
> 
> 
> Changes since the last upload:
> 
>  libunistring (1.2-1) unstable; urgency=medium
>  .
>    * New upstrem release.
>  - Refresh / Rebuild symbols file.
>    * debian/copyright:
>  - Add 2024 to myself.
>  - Refresh uploader copyright years.
>    * Remove unused patches:
>  - debian/patches/0100-float-endian-detection.patch.

Having #MISSING# in .symbols file is a red flag. It is a strong indication that
the library is breaking API explicitly.

Please check again and work with upstream to persue bumping SONAME together
with API/ABI breakage. This is especially important given large number
of reverse dependencies.

Thanks,
Boyuan Yang


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


Bug#1064077: RFS: qt5ct/1.8-1 -- Qt5 Configuration Utility

2024-03-06 Thread Soren Stoutner
Mateusz,

Did you have any questions about what I was asking here?

Soren

On Tuesday, February 20, 2024 2:40:04 PM MST Soren Stoutner wrote:
> Mateusz,
> 
> When compiling locally on my system, the current version of lintian 
(2.117.0)
> found the following problems.  These are not displayed on 
mentors.debian.net,
> leading me to believe they were recently added checks.
> 
> W: qt5ct: link-to-shared-library-in-wrong-package usr/lib/x86_64-linux-gnu/
> libqt5ct-common.so.1.8 [usr/lib/x86_64-linux-gnu/libqt5ct-common.so]
> N:
> N:   Although this package is not a "-dev" package, it installs a
> N:   "libsomething.so" symbolic link referencing the corresponding shared
> N:   library. When the link doesn't include the version number, it is used 
by
> N:   the linker when other programs are built against this shared library.
> N:
> N:   Shared libraries are supposed to place such symbolic links in their
> N:   respective "-dev" packages, so it is a bug to include it with the main
> N:   library package.
> N:
> N:   However, if this is a small package which includes the runtime and the
> N:   development libraries, this is not a bug. In the latter case, please
> N:   override this warning.
> N:
> N:   Please refer to Development files (Section 8.4) in the Debian Policy
> N:   Manual for details.
> N:
> N:   Visibility: warning
> N:   Show-Always: no
> N:   Check: libraries/shared/links
> N:   Renamed from: non-dev-pkg-with-shlib-symlink
> N:
> N:
> W: qt5ct: package-name-doesnt-match-sonames libqt5ct-common1.8
> N:
> N:   The package name of a library package should usually reflect the soname
> of N:   the included library. The package name can determined from the
> library N:   file name with the following code snippet:
> N:
> N:$ objdump -p /path/to/libfoo-bar.so.1.2.3 | sed -n -e's/
> ^[[:space:]]*SONAME[[:space:]]*//p' | \
> N:sed -r -e's/([0-9])\.so\./\1-/; s/\.so(\.|$)//; y/_/-/; s/(.*)/
\L&/'
> N:
> N:   Visibility: warning
> N:   Show-Always: no
> N:   Check: libraries/shared/soname
> N:
> N:
> I: qt5ct: no-symbols-control-file usr/lib/x86_64-linux-gnu/libqt5ct-
common.so.
> 1.8
> N:
> N:   Although the package includes a shared library, the package does not 
have
> N:   a symbols control file.
> N:
> N:   dpkg can use symbols files in order to generate more accurate library
> N:   dependencies for applications, based on the symbols from the library 
that
> N:   are actually used by the application.
> N:
> N:   Please refer to the dpkg-gensymbols(1) manual page and
> N:   https://wiki.debian.org/UsingSymbolsFiles for details.
> N:
> N:   Visibility: info
> N:   Show-Always: no
> N:   Check: debian/shlibs
> 
> As noted in the text of the checks, there are scenarios where these do not
> apply (like small packages that include the runtime and the development
> files), which appears to be the case with qt5ct.  Can you please help me to
> understand why qt5ct is including this shared library, if there are any 
other
> packages in Debian that are building against this library, and if you feel
> that any of the lintian checks above apply?  If you feel they don’t apply I
> would recommend you add lintian overrides and I will be happy to upload your
> package.
> 
> Soren


-- 
Soren Stoutner
so...@debian.org

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


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

2024-03-06 Thread Daniel Gröber
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.

--Daniel


signature.asc
Description: PGP signature


Bug#1065535: RFS: libjs-jush/2.0.2+git20210206+1-1 [ITP] -- JavaScript Syntax Highlighter

2024-03-06 Thread Alexandre Rossi
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "libjs-jush":

 * Package name : libjs-jush
   Version  : 2.0.2+git20210206+1-1
   Upstream contact : Jakub Vrana 
 * URL  : https://jush.sourceforge.io/
 * License  : Apache-2.0
 * Vcs  : https://salsa.debian.org/js-team/libjs-jush
   Section  : web

The source builds the following binary packages:

  libjs-jush - JavaScript Syntax Highlighter

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

  https://mentors.debian.net/package/libjs-jush/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libj/libjs-jush/libjs-jush_2.0.2+git20210206+1-1.dsc

This is a dependency of adminerevo which I request to maintain as a DM.
An older and partial version is already in src:javascript-goodies, and I'll
fill a bug to avoid duplication if this package ever reaches unstable.

Regards,
--
  Alexandre Rossi



Bug#1065534: RFS: adminerevo/4.8.3-1 [ITP] -- Web-based database administration tool

2024-03-06 Thread Alexandre Rossi
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : adminerevo
   Version  : 4.8.3-1
   Upstream contact : Lionel Laffineur 
 * URL  : https://docs.adminerevo.org/
 * License  : MIT, Apache-2.0
 * Vcs  : https://salsa.debian.org/debian/adminerevo
   Section  : web

The source builds the following binary packages:

  adminerevo - Web-based database administration tool

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

  https://mentors.debian.net/package/adminerevo/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/a/adminerevo/adminerevo_4.8.3-1.dsc

This is a fork of adminer which is already in Debian and seems unmaintained
upstream. Iv'e been maintaining adminer for some time as a DM and would like to
continue with adminerevo.

Regards,
--
  Alexandre Rossi