Re: Please give a test to cron package, in experimental

[Alex]

Thank you for bringing this up @Georges !

I would like to add, that generally it is a bit confusing that you don't 
restrict merge requests against master on https://salsa.debian.org/ to 
maintainers, since the preferred way for contributors seems to be a 
patch/diff on top of a already patched repository.


Having a discussion about a patch/diff can be much more cumbersome than 
having a discussion in a MR, directly on the related code lines.


So I wonder why you don't just provide an additional branch 
"master-patched" against which merge requests can be opened without the 
risk of causing conflicts with existing patches.


IMO that could ease the life of contributors and maintainers (You don't 
need to press "merge" when done ..  gitlab always provides 
*/merge_requests/408.patch, so you still could rely on patches)


(And ofc it would be great to use gitlab issues, instead of 
bugs.debian.org ... though that's a different story)


Sorry, it might be a bit off-topic, just wanted to throw in my 2cent, 
from a contributors POV.


Cheers, Alexander Schwinn

Am 08.10.23 um 13:54 schrieb Georges Khaznadar:

Hello,

I began to maintain cron (https://tracker.debian.org/pkg/cron) a few
months ago, and lowered the bug report count by a few dozens, began also
to write a few autopkgtests for it, and made it easier to test cron, by
providing a possibility to run cron tasks immediately (not after a one
minute wait)

While discussing about bug report #830821
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830821), it appeared
that Alexabner Schwinn wanted to contribute, but was not at ease with
the packaging scheme which exists currently with cron package, in our
distributions stable, testing and unstable : we are maintaing a big heap
of patches to apply to Vixie's cron source version 3.0 (this latter is no
longer available from Internet).

The difference of difficulty is between:
-8<---
... hack something
$ git commit -m "my awesome contribution"
$ git diff HEAD^
 and -
$ export QUILT_PATCHES=debian/patches # if you're no debian maintainer
$ quilt push -a
$ quilt new my_awesome_contribution.patch
$ quilt add , ...
... hack someting
$ quilt refresh
$ quilt pop -a
$ git commit -m "my awesome contribution"
$ git diff HEAD^
$
-8<---

Everyone can see that the second sequence is rather tricky for a
volunteer contributor, and results probably from the history of cron's
maintenance, which began far before our usage of version control
systems (Vcs).

So, I am trying to create a new upstream cron package, which is made
from Vixie's cron version 3.0, with all of the debian patches applied,
and packaging it; which results in a debian release 4.0-1, now uploaded
to experimental. All of the comments which came with the headers of
every patch are now included in Git's log, which preserves authorship
information.

If you have some free time, please can you give a try, or just share
your thoughts about this change ? I intend to push version 4.0 to
debian/sid shortly if we can agree.

Best regards,   Georges.





OpenPGP_signature
Description: OpenPGP digital signature

MR against patched package (Was: Please give a test to cron package, in experimental)

[Gioele Barabucci]

On 10/10/23 10:15, Alex wrote:
So I wonder why you don't just provide an additional branch 
"master-patched" against which merge requests can be opened without the 
risk of causing conflicts with existing patches.


This can be easily done with git-buildpackage's `pq` (patch queue) 
subcommand. And it could be automated on salsa.d.o with a post-receive hook.


```
$ # turn debian/patches* into a branch
$ gbp pq import
$ # force push the generated branch to the repo on salsa
$ git push -f salsa patch-queue/master:master-patched
```

MRs against master-patched will then be possible, but they will require 
one extra step from the maintainer (i.e. `gbp pq export`) to turn these 
MRs into normal standalone patch files stored in debian/patches.


Regards,

PS: `gbp pq import/export` is a much better interface to debian/patches 
compared to plain `quilt`.


--
Gioele Barabucci

Re: apt-listchanges: appropriate heuristic for ignoring sub-packages with symlinked /usr/share/doc directories

[Jonathan Kamens]

On 10/10/23 02:18, Simon Richter wrote:

On 10/10/23 06:24, Jonathan Kamens wrote:


  * binary package name different from source name
  * deb contains no changelog or NEWS files in /usr/share/doc
  * creates a symlink in /usr/share/doc with the binary package name as
    its name, pointing at another directory in /usr/share/doc


I'd go an easier way: if the changelog is a symlink, its target is the 
changelog to use, so the same changelog (with the same file name) will 
be used by multiple packages, and all that's left is to deduplicate 
this list.


The new version of apt-listchanges already deduplicates. The main point 
of the logic revamp I did was to add such deduplication instead of 
relying on version numbers to determine what to show the user.


Having said that, it doesn't make sense to do what you're proposing. If 
a package doesn't have any changelog files in it, but rather just a 
symlink to another package's changelog files, then those changelog files 
will have already been parsed by apt-listchanges and displayed to the 
user when the package that owns them was installed. As far as I can see 
the only thing that would be accomplished by doing what you suggest 
would be to make apt-listchanges slower, since it would have to locate 
and reparse all those changelog files, only to discover that their 
contents have already been displayed to the user.


  jik

Re: Please test apt-listchanges 4.0 in experimental

[Jonathan Kamens]

N.B. apt-listchanges has been upgraded to 4.1 in experimental with some 
significant fixes, so if you're testing 4.0, please upgrade to 4.1, and 
if you're not testing yet, what are you waiting for? ;-)


Thanks to everyone who has tested and helped identify the issues fixed 
in 4.1!


Thanks,

jik

On 10/8/23 11:27, Jonathan Kamens wrote:


Hello friends,

I've adopted apt-listchanges and pushed a new version, 4.0, to 
experimental, with a bunch of fixes in it. Given how extensive the 
changes are, I'd appreciate some testing from folks here before it 
gets promoted to unstable. This package is widely used so it's kind of 
important for us to get this right. ;-)


You can view the changelog.Debian.gz in the deb itself or here 
.


One thing you may notice is that because the method of tracking which 
changelogs the user has already seen (see here 
 
or /usr/share/doc/apt-listchanges/what_to_display.html in the deb for 
details), the database needs to be populated with data for existing 
packages during upgrades, so the first time a package is upgraded 
after the switch to the new method, it will be slightly slower. I have 
a plan for addressing that but it hasn't been implemented yet (and 
indeed, requires advice from folks here for me to get it right, so 
I'll be sending another message after this one to ask for that advice).


Also, I'm still waiting on some translations, so you may notice some 
English strings in foreign locales. There is no need to report this to 
me, I'm aware.


Please file bugs, reply in this thread, or email me privately with any 
feedback as you deem appropriate. If you try it out and everything's 
fine and you can take a moment to email me and let me know that as 
well, I'd appreciate it, since that'll give me confirmation that it's 
gone through some testing by people other than me.


Thank you,

Jonathan Kamens

Bug#1053758: ITP: libspelling -- Spellcheck library for GTK4

[Nathan Pratta Teodosio]

Package: wnpp
Severity: wishlist
Owner: Nathan Pratta Teodosio 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org

* Package name: libspelling
  Version : 0.2.0
  Upstream Contact: Christian Hergert 
* URL : https://gitlab.gnome.org/chergert/libspelling/
* License : LGPL-2.1+
  Programming Lang: C
  Description : libspelling: Spellcheck library for GTK4

The package is a dependency for Gtranslator 45 and is expected to be for Gnome
Text Editor 46.

This package will be maintained by the Debian GNOME team. Packaging is at
https://salsa.debian.org/gnome-team/libspelling

Best regards,
Nathan

[RFC] locking down rsyslog.service

[Michael Biebl]

Hi,


I intend to lock down rsyslog.service in Debian in one of the next
uploads using the following systemd directives

PrivateTmp=yes
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#PrivateTmp=

PrivateDevices=yes
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#PrivateDevices=

ProtectHome=yes
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectHome=

ProtectSystem=full
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectSystem=

ProtectKernelTunables=yes
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectKernelTunables=

ProtectKernelModules=yes
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectKernelModules=

ProtectClock=yes
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectClock=

SystemCallFilter=@system-service
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#SystemCallFilter=

CapabilityBoundingSet=CAP_BLOCK_SUSPEND CAP_CHOWN CAP_LEASE
CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_SYS_ADMIN CAP_SYS_RESOURCE
CAP_SYSLOG
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#CapabilityBoundingSet=

The full rsyslog.service looks like this, in case you want to test it:
```
[Unit]
Description=System Logging Service
Requires=syslog.socket
Documentation=man:rsyslogd(8)
Documentation=man:rsyslog.conf(5)
Documentation=https://www.rsyslog.com/doc/

[Service]
Type=notify
ExecStart=/usr/sbin/rsyslogd -n -iNONE
StandardOutput=null
Restart=on-failure

# Increase the default a bit in order to allow many simultaneous
# files to be monitored, we might need a lot of fds.
LimitNOFILE=16384

PrivateTmp=yes
PrivateDevices=yes
ProtectHome=yes
ProtectSystem=full
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectClock=yes
SystemCallFilter=@system-service
CapabilityBoundingSet=CAP_BLOCK_SUSPEND CAP_CHOWN CAP_LEASE
CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_SYS_ADMIN CAP_SYS_RESOURCE
CAP_SYSLOG

[Install]
WantedBy=multi-user.target
Alias=syslog.service
```

While the attempt is to secure the default configuration of rsyslog, I
do not want to restrict it so much that it becomes unusable.
If you think, that one of those directives could cause issues with
commonly used setups, please let me know, so I can adjust the
configuration.

Looking forward to your feedback.

Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [RFC] locking down rsyslog.service

[Simon Richter]

Hi,

On 10/11/23 03:22, Michael Biebl wrote:


I intend to lock down rsyslog.service in Debian in one of the next
uploads using the following systemd directives



CapabilityBoundingSet=CAP_BLOCK_SUSPEND CAP_CHOWN CAP_LEASE
CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_SYS_ADMIN CAP_SYS_RESOURCE
CAP_SYSLOG


Does it actually need CAP_NET_ADMIN and CAP_SYS_ADMIN?

Everything else looks good to me.

   Simon

Bug#1053782: RFP: node-vite -- Next Generation Frontend Tooling

[Andrius Merkys]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-devel@lists.debian.org
Control: block 1042095 by -1

* Package name: node-vite
  Version : 4.4.11
  Upstream Author : Evan You
* URL : https://github.com/vitejs/vite
* License : Expat
  Programming Lang: JavaScript
  Description : Next Generation Frontend Tooling

Vite is a frontend build tool, including development server and build 
command bundling code with Rollup, pre-configured to output optimized 
static assets for production.


Vite is needed to produce CSS and JS files for sphinx-press-theme.

An estimate of work needed to package Vite:

$ npm2deb depends vite
Dependencies:
NPM   Debian
vite (4.4.11) None
├─ esbuild (^0.18.10) None
├─ fsevents (~2.3.2)  None
├─ postcss (^8.4.27)  node-postcss 
(8.4.20+~cs8.0.23-1)

└─ rollup (^3.27.1)   node-rollup (3.28.0-2)

Build dependencies:
NPM   Debian
@ampproject/remapping (^2.2.1) node-ampproject-remapping 
(2.2.0+~cs5.15.37-1)

@babel/parser (^7.22.7)   None
@babel/types (^7.22.5)node-babel 
(6.26.0+repack-3~bpo10+1)

@jridgewell/trace-mapping (^0.3.18)   None
@rollup/plugin-alias (^4.0.4) node-rollup-plugin-alias (5.0.0~ds-1)
@rollup/plugin-commonjs (^25.0.3) node-rollup-plugin-commonjs (25.0.4+ds1-1)
@rollup/plugin-dynamic-import-vars (^2.0.4)   None
@rollup/plugin-json (^6.0.0) node-rollup-plugin-json (6.0.0+ds1-2)
@rollup/plugin-node-resolve (15.1.0) node-rollup-plugin-node-resolve 
(15.1.0+ds-1)
@rollup/plugin-typescript (^11.1.2) node-rollup-plugin-typescript 
(11.1.2~ds+~1.0.1-1)

@rollup/pluginutils (^5.0.2) node-rollup-pluginutils (5.0.2~ds+~2.8.2-1)
@types/escape-html (^1.0.2)   None
@types/pnpapi (^0.0.2)None
acorn (^8.10.0)   acorn 
(8.8.1+ds+~cs25.17.7-2)

acorn-walk (^8.2.0)   None
cac (^6.7.14) None
chokidar (^3.5.3) node-chokidar (3.5.3-2)
connect (^3.7.0)  node-connect 
(3.7.0+~3.4.35-1)

connect-history-api-fallback (^2.0.0) None
convert-source-map (^2.0.0) node-convert-source-map (1.9.0+~1.5.2-1)
cors (^2.8.5) node-cors (2.8.5-1)
cross-spawn (^7.0.3)  node-cross-spawn (5.1.0-2)
debug (^4.3.4)node-debug 
(4.3.4+~cs4.1.7-1)

dep-types (link:./src/types)  None
dotenv (^16.3.1)  None
dotenv-expand (^9.0.0)None
es-module-lexer (^1.3.0)  node-es-module-lexer 
(1.1.0+dfsg-2)
escape-html (^1.0.3)  node-escape-html 
(1.0.3+~1.0.2-2)
estree-walker (^3.0.3)node-estree-walker 
(2.0.2-5)

etag (^1.8.1) node-etag (1.8.1-3)
fast-glob (^3.3.1)None
http-proxy (^1.18.1)  node-http-proxy (1.18.1-8)
json-stable-stringify (^1.0.2) node-json-stable-stringify 
(1.0.2+repack1+~cs1.0.34-2)

launch-editor-middleware (^2.6.0) None
lightningcss (^1.21.5)None
magic-string (^0.30.2)node-magic-string 
(0.30.1-1)
micromatch (^4.0.5)   node-micromatch 
(4.0.5+~4.0.2-1)

mlly (^1.4.0) None
mrmime (^1.0.1)   None
okie (^1.0.1) None
open (^8.4.2) node-open (8.4.0-6)
parse5 (^7.1.2)   node-parse5 (7.1.2+dfsg-2)
periscopic (^3.1.0)   None
picocolors (^1.0.0)   node-picocolors (1.0.0-4)
picomatch (^2.3.1)node-anymatch 
(3.1.3+~cs4.6.1-2)

postcss-import (^15.1.0)  None
postcss-load-config (^4.0.1) node-postcss-load-config (2.1.2+~cs6.0.0-1)
postcss-modules (^6.0.0)  node-postcss-modules 
(6.0.0+~cs5.1.3-2)

resolve.exports (^2.0.2)  None
rollup-plugin-license (^3.0.1)None
sirv (^2.0.3) None
source-map-support (^0.5.21) node-source-map-support (0.5.21+ds+~0.5.4-1)
strip-ansi (^7.1.0)   node-strip-ansi (6.0.1-2)
strip-literal (^1.3.0)None
tsconfck (^2.1.2) None
tslib (^2.6.1)node-tslib (2.4.1-1)
types (link:./types) 

Re: Bug#1053782: RFP: node-vite -- Next Generation Frontend Tooling

[Simon Richter]

Hi,

On 10/11/23 15:30, Andrius Merkys wrote:


   Description : Next Generation Frontend Tooling


Yes, but what does it do? Why would I pick this out of a package list if 
I didn't know the name of the package already?


   Simon