Bug#1061074: ITP: golang-github-hugelgupf-p9 -- p9 implementation written in golang

[Reinhard Tartler]

Package: wnpp
Owner: Reinhard Tartler 
Severity: wishlist

* Package name: golang-github-hugelgupf-p9
  Version : 0.3.0
  Upstream Author : gvisor authors
* URL or Web page : https://github.com/hugelgupf/p9
* License : Apache 2.0
  Description : p9 implementation written in golang

This package provides a p9 server and client implementation written in
 golang. It is part of the gvisor security platform.

Intend to maintain this under the pkg-golang umbrella. It is a new
dependency of podman (used by podman machine to transfer files to VMs it
manages).

Bug#1061078: ITP: oaknut -- Aarch64 (arm64) code emitter

[David James]

Package: wnpp
Severity: wishlist
Owner: David James 
X-Debbugs-Cc: debian-devel@lists.debian.org, davidjamescastor...@proton.me

* Package name: oaknut
  Version : 1.2.2
  Upstream Contact: MerryHime 
* URL : https://github.com/merryhime/oaknut
* License : MIT (Expat)
  Programming Lang: C++, CMake
  Description : Aarch64 (arm64) code emitter

Oaknut is a header-only C++20 assembler for arm64 systems. It is designed to 
process C++ code and emit it to memory at runtime.

I am in the process of packaging Citra, the Nintendo 3DS emulator. This is 
one of the dependencies required to package Citra on arm64. Without this, I 
would have to exclude the arm64 architecture entirely.

In addition to being a Citra dependency, this software would also be useful 
for anyone creating software to emulate an embedded ARM 8.0-8.2 system.

I would maintain this package myself, but would need a sponsor.

build profile proposal: nogir (second try)

[Simon McVittie]

Last year, Helmut Grohne proposed a nogir build profile to help with
cross-compiling the GLib ecosystem:
.
After some discussion on #1030223, I have a revised proposal, with the
same name but slightly different rules:

profile name:nogir
content changes: Y/N (ideally N)
package set changes: Y
description: Disable GObject-Introspection bindings (.gir, .typelib).
 See the GObject-Introspection mini-policy for details.

For background, GObject-Introspection provides machine-readable
information about C/C++ code that follows GLib's conventions. There are
two formats: GIR XML is a text format with full information for compiled
bindings (C++, Rust, Haskell), and typelibs are a more efficient binary
format with a subset of that information for dynamic bindings (Python,
JavaScript, Perl). There is a compiler to do the lossy conversion from
GIR XML into typelibs, but creating the GIR XML is the part that has
dependencies we sometimes want to avoid, so disabling the typelibs but
leaving the GIR XML in place is not useful.

Public typelibs (Foo-1.typelib) are already shipped in their own package,
gir1.2-foo-1, so they are easy to disable with a build profile.

Public GIR XML (Foo-1.gir) is normally in the -dev package alongside the
C headers, but recent versions of gobject-introspection define a canonical
virtual package name gir1.2-foo-1-dev which can either be a Provides on
the -dev package or an independent binary package.

Here is the draft text that I added to the GObject-Introspection
mini-policy in 1.78.1-11:


Source packages that build GIR XML and typelibs may implement the nogir
build profile. This will usually be desirable for libraries that can be
used directly from C/C++ code without needing to use GObject-Introspection.
It will usually not be useful to implement the nogir build profile in
packages where GObject-Introspection is a functional requirement for using
the package, such as gnome-shell.

Ideally, the nogir build profile should disable the build of gir1.2-* and
gir1.2-*-dev packages, and disable all build-dependencies on the
gobject-introspection toolchain and gir1.2-*-dev packages, without
affecting the contents of any other binary package, in particular lib*-dev.
When implemented like this, nogir is a "safe" or "reproducible" build-profile.

However, for many pre-existing source packages, separating GIR XML
from the lib*-dev package into a new gir1.2-*-dev package would be an
incompatible change that needs to be coordinated with dependent packages,
because previously-correct dependent packages would begin to fail to build
from source until they add gir1.2-*-dev to their Build-Depends (even if
the package was built without the nogir profile and the dependency is
a native build). It would also require manual processing by the Debian
archive administrators, to approve the new binary package name.

To mitigate those factors, if the GIR XML is included in a lib*-dev
binary package, the nogir build profile may remove the GIR XML from
that package. The resulting binary package must drop any Provides
matching gir1.2-*-dev that it would have had when built normally. This
will often be automatic: if dh_girepository is used, ${gir:Depends}
and ${gir:Provides} will automatically be emptied for packages that do
not contain any GIR XML or typelibs.

If this is done, dependent packages will continue to build successfully
against any dependency that was not built with nogir, but will require
changes (namely adding Build-Depends: gir1.2-*-dev ) in order to
be sucessfully buildable with dependencies that were built with nogir.


I did wonder whether this should be two separate build profiles, but
that seems like it's probably unnecessary complexity.

smcv

Re: build profile proposal: nogir (second try)

[Matthias Geiger]

Am 17.01.24 um 23:00 schrieb Simon McVittie:

Last year, Helmut Grohne proposed a nogir build profile to help with
cross-compiling the GLib ecosystem:
.
After some discussion on #1030223, I have a revised proposal, with the
same name but slightly different rules:

profile name:nogir
content changes: Y/N (ideally N)
package set changes: Y
description: Disable GObject-Introspection bindings (.gir, .typelib).
  See the GObject-Introspection mini-policy for details.

For background, GObject-Introspection provides machine-readable
information about C/C++ code that follows GLib's conventions. There are
two formats: GIR XML is a text format with full information for compiled
bindings (C++, Rust, Haskell), and typelibs are a more efficient binary
format with a subset of that information for dynamic bindings (Python,
JavaScript, Perl). There is a compiler to do the lossy conversion from
GIR XML into typelibs, but creating the GIR XML is the part that has
dependencies we sometimes want to avoid, so disabling the typelibs but
leaving the GIR XML in place is not useful.

Public typelibs (Foo-1.typelib) are already shipped in their own package,
gir1.2-foo-1, so they are easy to disable with a build profile.

Public GIR XML (Foo-1.gir) is normally in the -dev package alongside the
C headers, but recent versions of gobject-introspection define a canonical
virtual package name gir1.2-foo-1-dev which can either be a Provides on
the -dev package or an independent binary package.


Hi Simon,

thanks for this.

Does this mean we should should split out the .gir XML files from 
existing source packages into a separate gir1.2-foo-dev (in the long run) ?


[...]

best,

--
Matthias Geiger 
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: build profile proposal: nogir (second try)

[Simon McVittie]

On Wed, 17 Jan 2024 at 23:15:03 +0100, Matthias Geiger wrote:
> Am 17.01.24 um 23:00 schrieb Simon McVittie:
> > Public GIR XML (Foo-1.gir) is normally in the -dev package alongside the
> > C headers, but recent versions of gobject-introspection define a canonical
> > virtual package name gir1.2-foo-1-dev which can either be a Provides on
> > the -dev package or an independent binary package.
> 
> Does this mean we should should split out the .gir XML files from existing
> source packages into a separate gir1.2-foo-dev (in the long run) ?

That's a good question, and I don't have an easy answer for it. The
tradeoff is:

- having the GIR XML in libfoo-dev means fewer binary packages and
  therefore smaller Packages metadata;

- having a separate (non-virtual) gir1.2-foo-1-dev means we can "cleanly"
  turn off GIR/typelibs in cases when they're not needed, and means
  libfoo-dev is a bit smaller and with fewer dependencies

It's analogous to the choice between one big -dev package (libcairo2-dev,
libwayland-dev) or multiple smaller -dev packages (libportal*-dev) for a
source package with more than one shared library.

The larger, more widely-used and lower-level the library is, the more I
would be inclined to opt for the approach with extra binary packages
- for example splitting out gir1.2-gtk-4.0-dev from libgtk-4-dev
seems more desirable than splitting out gir1.2-shumate-1.0-dev from
libshumate-dev. Separating out the GIR XML is more interesting for
packages that are involved in bootstrapping, or for packages that someone
will frequently want to cross-compile, particularly the ones you'll want
to cross-compile early in the development of a new port when tools like
qemu-user might not be able to target it.

In the case where the GIR XML is in libfoo-dev, asking for it to have
Provides: gir1.2-foo-1-dev means that dependent packages can depend on the
systematic gir1.2-foo-1-dev name, and then will work correctly either way.

The only package where I'm sure that I intend to separate out the GIR
XML in the short term is src:glib2.0, where for historical reasons
gir1.2-glib-2.0 has been built by src:gobject-introspection until
now. I'm most of the way through preparing a version of glib2.0
2.79.x for experimental that takes over gir1.2-glib-2.0{,-dev}
from src:gobject-introspection, and I definitely don't want to fold
gir1.2-glib-2.0-dev into libglib2.0-dev, because GLib's position at the
bottom of the GNOME stack makes it particularly important that we can
still bootstrap and cross-compile it.

smcv

Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

[Steve Langasek]

Hi Colin,

On Tue, Jan 09, 2024 at 01:32:11PM +, Colin Watson wrote:
> On Mon, Jan 08, 2024 at 03:01:11PM -0800, Steve Langasek wrote:
> > On Fri, Jan 05, 2024 at 09:17:52PM +0100, Paul Gevers wrote:
> > > On 05-01-2024 17:36, Rene Engelhard wrote:
> > > > Also a problem is that experimental also might already contain totally
> > > > unrelated updates like new upstream versions...

> > > I share this worry. Have you thought about how to handle the cases where 
> > > you
> > > don't have experimental to upload to? How big is this problem?



> In the current situation, though, not having experimental available
> means that there's no opportunity for dumat to weigh in regarding
> usrmerge interactions, which seems problematic given Helmut's
> preliminary analysis.

I guess this is a reply to the bits of context I retained above rather than
directly a reply to my most immediate preceding message.  In a separate
subthread, I laid out what I thought the process should be for handling the
transition of packages in that situation; but you are raising a separate
point.

Which parallels what Helmut had to say:

> Whenever you face files in aliased locations (other than systemd units),
> please go via experimental to let dumat judge your upload.  Check the
> bookworm package for files in aliased locations, not the unstable one.

I have also had other out-of-band conversations with Helmut about the
overlapping issues between usrmerge and time_t, so this was generally
speaking on my radar although I didn't address it in my proposed transition
plan.

I think it is unrealistic to ask experimental to be otherwise quiesced of
transitions to ensure that we can stage all of the affected libraries in
experimental, and I also think that making false transitions for packages
that are ALREADY in experimental because of transitions would be
counterproductive. ("False" because if the library package has a different
soname between unstable and experimental, then renaming the runtime library
package in the *experimental* version is unnecessary because there's nothing
"in the wild" depending on that package name but with the old ABI for which
upgrade compatibility is of concern.)

My preferred path forward here would be, as Helmut suggests, to check which
libraries are in the intersection of (packages in experimental for which we
won't stage time_t uploads) and (packages that exist in bookworm and need
transitioning of aliased paths), and ensure that these packages are handled
carefully according to Helmut's own guidance.  My optimistic expectation is
that the intersection will be null, or nearly; but in any case I will bring
data.

And my proposal for checking that set, since we're only talking about
runtime library packages, is to check whether any of the contents of these
packages in bookworm match ^/lib - as a runtime library package NOT matching
this pattern, but matching a pattern for one of the other aliased
directories, would be something ...  special.

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


signature.asc
Description: PGP signature