Bug#1056044: ITP: python-jsonschema-specifications -- JSON Schema meta-schemas and vocabularies, exposed as a Registry

[Thomas Goirand]

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

* Package name: python-jsonschema-specifications
  Version : 2023.11.1
  Upstream Contact: Julian Berman 
* URL : 
https://github.com/python-jsonschema/jsonschema-specifications
* License : Expat
  Programming Lang: Python
  Description : JSON Schema meta-schemas and vocabularies, exposed as a 
Registry

 This package contains JSON support files from the JSON Schema Specifications
 (metaschemas, vocabularies, etc.), packaged for runtime access from Python as
 a referencing-based Schema Registry.

Note: This package is needed to update python-jsonschema to the latest
upsteram release.

Re: RFC: advise against using Proton Mail for Debian work?

[Jonathan McDowell]

On Wed, Nov 15, 2023 at 11:21:06PM +0100, Norwid Behrnd wrote:
> I would like to add an observation tangential to your points A), explanation
> to new contributors, and B) potentially advise against the use of Proton Mail
> for Debian work to yield a «no, Proton Mail can be useful for some Debian
> work».

I'll chip in, without wearing any hats, to comment that:

a) I completely agree with all the sentiments raised about not storing
the private portion of OpenPGP keys on other people's systems; this
extends to systems run by DSA (in the distant past we had to do a clean
up of DD keys that had been stored on master).

but

b) Proton Mail are active members of the OpenPGP ecosystem and are doing
good work in trying to improve it's usefulness and usability. I have no
reason to object to their use within Debian, as long as upload keys are
not stored there.

J.

-- 
/-\ |   "Do I scare you?" "No." "Do you
|@/  Debian GNU/Linux Developer |   want me to?" -- Wayne's World.
\-  |


signature.asc
Description: PGP signature

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

[Helmut Grohne]

Hello developers,

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

# What has happened?

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

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

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

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

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

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

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

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

# What will happen next?

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

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

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

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

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

# What you can do to help?

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

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

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

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


I hope that this all makes sense to you. In case it does no

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

[Simon McVittie]

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

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

bookworm-backports also has a suitable version.

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

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

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

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

smcv

Bug#1056052: Subject: ITP: wasix-libc -- wasix libc implementation for WebAssembly

[daichi1.fukui]

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

* Package name: wasix-libc
  Version : 0.0~git20230922.d0362cb
  Upstream Author : Johnathan Sharratt 
* URL : https://github.com/wasix-org/wasix-libc
* License : Apache-2.0 and Apache-2.0-with-LLVM-Exceptions and Expat
  Programming Lang: C
  Description : wasix libc implementation for WebAssembly

Reason for ITP:
wasix-libc is the libc implementation for WebAssembly (WASM) with POSIX 
conformance.
WASIX is a superset on top of WASI, so wasix-libc incorporates POSIX-compliant 
extentions
such as support for sockets, which are not available in wasi-libc.
With this package, we will be able to build a C source code with POSIX 
interfaces into a WASM module.

A git repository will be created on salsa:
https://salsa.debian.org/dfukui/wasix-libc

Maintenance plan:
Because I have less experience in debian packaging, I would like to
ask Debian developers to review my upload. I need a sponsor too.
Report will be sent to Debian Bug Tracking System 

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

[Helmut Grohne]

Hi Holger,

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

I think your question is relevant to others.

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

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

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

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

> many thanks for all your work on this!

You are welcome.

Helmut

Bug#1056067: ITP: node-sass-loader -- css loader module for webpack

[Alexandre Rossi]

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

* Package name: node-sass-loader
  Version : 13.3.2
  Upstream Contact: J. Tangelder
* URL : https://github.com/webpack-contrib/sass-loader
* License : MIT
  Programming Lang: Javascript
  Description : css loader module for webpack

Webpack takes code targeted at node.js and makes it run in the browser.
Node.js comes with API of its own that is not available in the browsers.
Webpack exposes this code to programs that are unaware they are running
in a browser.

Sass is a CSS preprocessor to include features that don’t exist in CSS yet
like nesting, mixins, inheritance, and other nifty goodies that help
write robust, maintainable CSS.

This package is enables webpack to include and compile Sass files
into a web application bundle.

Node.js is an event-based server-side JavaScript engine.

This is required to build some webapps.

I'll be seeking a sponsor for this.

Thanks,

Alex

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

[Holger Levsen]

hi Helmut,

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

ah!

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

:)

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

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

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

thanks!

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

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

& many thanks to everyone else involved too!


-- 
cheers,
Holger

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

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


signature.asc
Description: PGP signature

Bug#1056068: RFH: resvg -- SVG rendering library (command-line utility)

[Andrej Shadura]

Package: wnpp
Severity: normal
X-Debbugs-Cc: re...@packages.debian.org, debian-devel@lists.debian.org, Rust 
Maintainers 
Control: affects -1 + src:resvg

Hi all,

resvg is a command-line SVG renderer which I introduced to Debian back
in 2019. Unfortunately, very soon after the initial upload the upstream
has rewritten substantial parts of resvg, which resulted in it requiring
build dependencies that were missing from Debian at that point. I tried
to update resvg and upload the missing dependencies, but ultimately
never completed that work, and resvg was removed from bookworm.

Unfortunately, I cannot invest any more time into resvg at the moment,
so I have to officially request assistance with maintaining the resvg package.

To the Debian Rust team: if you can, please adopt this package.

Thank you.

The package description is:
 resvg is a command-line utility to render SVG files based on a static
 SVG Full 1.1 subset. It is a fast, small, portable, multiple
 backend SVG library designed for edge-cases.
 .
 resvg supports Cairo and Qt backends.

Bug#1056091: ITP: golang-github-prometheus-community-pgbouncer-exporter -- Prometheus exporter for PgBouncer

[Lena Voytek]

Package: wnpp
Severity: wishlist
Owner: Lena Voytek 
X-Debbugs-Cc: debian-devel@lists.debian.org, l...@voytek.dev

* Package name: golang-github-prometheus-community-pgbouncer-exporter
  Version : 0.7.0
  Upstream Author : Prometheus Monitoring Community
* URL : https://github.com/prometheus-community/pgbouncer_exporter
* License : MIT
  Programming Lang: Go
  Description : Prometheus exporter for PgBouncer

PgBouncer Exporter extracts data and metrics from pgbouncer for
monitoring using Prometheus tools. It provides a useful
connection between PostgreSQL databases and the Prometheus
ecosystem. For more information on Prometheus exporters see
https://prometheus.io/docs/instrumenting/exporters/

I intend to actively maintain this package within the Debian Go
Packaging team.

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

[Cyril Brulebois]

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

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

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


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


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

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


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


signature.asc
Description: PGP signature

Re: lintian.debian.org off ?

[Otto Kekäläinen]

Hi!

On Wed, 27 Sept 2023 at 13:27, Lucas Nussbaum  wrote:
>
> Hi,
>
> #1042428 is the bug for "no explanation for lintian tags on UDD"
>
> On 26/09/23 at 21:35 -0700, Otto Kekäläinen wrote:
> > I know Lintian tag info is available via command line, but I
> > frequently need to educate upstreams about Lintian rules, and thus
> > really also need a URL to share to them. Perhaps I could implement
> > that later in the year.
>
> That's indeed a good rationale for adding a web interface to lintian
> tags explanations. Thanks.
>
> I still plan to work on adding that eventually.

This issue still exists. I would now have the need to send the url
https://lintian.debian.org/tags/service-file-is-not-a-file to upstream
developers to learn about this Lintian issue, but the URL does not
serve any contents nor does it redirect to a new location.

I am still willing to contribute the Apache/Nginx rewrite rules if
somebody can point me to a code repository where I can read/contribute
at like I announced on September 27th in this thread.

- Otto