Re: Please, minimize your build chroots

[Johannes Schauer Marin Rodrigues]

Quoting Santiago Vila (2022-12-16 02:15:13)
> I've just filed 21 bugs with subject "Missing build-depends on tzdata"
> in bookworm (as tzdata is not build-essential).

thank you for that!

> I can think of two solutions for this:
> 
> A) Either debootstrap, when using buildd profile, installs only
> essential and build-essential packages.
> 
> or
> 
> B) debootstrap keeps installing all required packages in the buildd profile,
> no matter if they are really build-essential or not, but those who
> are not build-essential should have their priority downgraded to "important"
> by ftpmaster.
> 
> This problem was already reported here:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837060

Thank you for finding my bug from back then. :)

> and apparently we have not decided yet if we are going to do A or B,
> or maybe some other thing. I don't really care how it's fixed, but I
> believe it's about time that we sync practice with policy, because
> currently we are doing this in a quite suboptimal way.

I think truly fixing this problem is a bit more tricky because most build tools
like the sbuild schroot backend require apt being installed in the chroot. As
of today, the sbuild schroot backend is unable to function with a chroot that
doesn't contain apt. I don't think it's conceptually possible to fix the
schroot backend to work with chroots without apt because schroot (for good
reason) doesn't give you root anywhere but inside the chroot.

To be able to install build dependencies in chroots without apt, the sbuild
unshare backend could be used. Also helmut's mdbp can easily be changed to
build packages in chroots without apt when using its mmdebstrap backend.

But of course changing debootstrap to only install essential, build-essential
and apt (but not prio:required) would already fix a large part of the problem.

> In the meantime: If you want to help QA and have any kind of chroot used
> for any kind of QA (say, ci.debian.org or reproducible-builds, or even
> your personal chroots), please try to minimize the packages there,
> do not merely accept debootstrap default behaviour.

You can use mmdebstrap to create such a chroot:

$ mmdebstrap --variant=apt --include=build-essential unstable chroot.tar

This will also install apt because most build tools need it. The mmdebstrap
package mimics debootstrap behaviour. As soon as debootstrap --variant=buildd
is fixed, I'll let mmdebstrap do the same thing.

Thanks!

cheers, josch

Please, minimize your build chroots

[Santiago Vila]

Greetings.

I'm doing archive-wide rebuilds again.

I've just filed 21 bugs with subject "Missing build-depends on tzdata"
in bookworm (as tzdata is not build-essential).


This is of course not fun for the maintainers, but it's also not fun
for people doing QA, because those bugs could be caught earlier in the
chain, but they are not. This is extra work for everybody.

(Similar bugs are even sliding into stable releases, I plan to report
a few of them against bullseye after 11.6 this Saturday, as bullseye
is the currently supported stable release).

Because people accept the default by debootrap "as is", chroots used
to build packages include packages which are neither essential nor
build-essential, like tzdata, mount or e2fsprogs.

I can think of two solutions for this:

A) Either debootstrap, when using buildd profile, installs only
essential and build-essential packages.

or

B) debootstrap keeps installing all required packages in the buildd profile,
no matter if they are really build-essential or not, but those who
are not build-essential should have their priority downgraded to "important"
by ftpmaster.

This problem was already reported here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837060

and apparently we have not decided yet if we are going to do A or B,
or maybe some other thing. I don't really care how it's fixed, but I
believe it's about time that we sync practice with policy, because
currently we are doing this in a quite suboptimal way.


In the meantime: If you want to help QA and have any kind of chroot used
for any kind of QA (say, ci.debian.org or reproducible-builds, or even
your personal chroots), please try to minimize the packages there,
do not merely accept debootstrap default behaviour.


Thanks.

Work-needing packages report for Dec 16, 2022

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 1254 (new: 1)
Total number of packages offered up for adoption: 162 (new: 0)
Total number of packages requested help for: 63 (new: 0)

Please refer to https://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   cdbs (#1026085), orphaned yesterday
 Description: common build system for Debian packages
 Reverse Depends: haskell-devscripts-minimal lua5.1-policy-dev
 Installations reported by Popcon: 3630
 Bug Report URL: https://bugs.debian.org/1026085

1253 older packages have been omitted from this listing, see
https://www.debian.org/devel/wnpp/orphaned for a complete list.



No new packages have been given up for adoption, but a total of 162 packages
are awaiting adoption.  See https://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   apache2 (#910917), requested 1524 days ago
 Description: Apache HTTP Server
 Reverse Depends: apache2 apache2-ssl-dev apache2-suexec-custom
   apache2-suexec-pristine backuppc bfh-container-server
   courier-webadmin cvsweb debbugs-web doc-central (129 more omitted)
 Installations reported by Popcon: 96656
 Bug Report URL: https://bugs.debian.org/910917

   apparmor (#1006872), requested 283 days ago
 Description: user-space parser utility for AppArmor
 Reverse Depends: apparmor-notify apparmor-profiles
   apparmor-profiles-extra apparmor-utils content-hub-testability
   dbus-broker dbus-daemon dbus-tests debian-cloud-images-packages
   dovecot-core (18 more omitted)
 Installations reported by Popcon: 188323
 Bug Report URL: https://bugs.debian.org/1006872

   aufs (#963191), requested 908 days ago
 Description: driver for a union mount for Linux filesystems
 Reverse Depends: fsprotect
 Installations reported by Popcon: 7025
 Bug Report URL: https://bugs.debian.org/963191

   autopkgtest (#846328), requested 2206 days ago
 Description: automatic as-installed testing for Debian packages
 Reverse Depends: debci-worker sbuild-qemu
 Installations reported by Popcon: 1163
 Bug Report URL: https://bugs.debian.org/846328

   balsa (#642906), requested 4099 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa
 Installations reported by Popcon: 593
 Bug Report URL: https://bugs.debian.org/642906

   cargo (#860116), requested 2074 days ago
 Description: Rust package manager
 Reverse Depends: dh-cargo python3-setuptools-rust rust-all
 Installations reported by Popcon: 2769
 Bug Report URL: https://bugs.debian.org/860116

   chromium (#1016047), requested 142 days ago
 Description: web browser
 Reverse Depends: chromium chromium-driver chromium-l10n
   chromium-shell icingaweb2-module-pdfexport node-puppeteer
   qunit-selenium x2gothinclient-minidesktop
 Installations reported by Popcon: 24734
 Bug Report URL: https://bugs.debian.org/1016047

   courier (#978755), requested 714 days ago
 Description: Courier mail server
 Reverse Depends: courier-faxmail courier-filter-perl courier-imap
   courier-ldap courier-mlm courier-mta courier-pcp courier-pop
   courier-webadmin couriergrey (3 more omitted)
 Installations reported by Popcon: 782
 Bug Report URL: https://bugs.debian.org/978755

   cron (#984736), requested 648 days ago
 Description: new maintainer need
 Reverse Depends: apticron autolog backintime-common bcron
   btrfsmaintenance buildd checksecurity clamtk cricket cron (24 more
   omitted)
 Installations reported by Popcon: 206123
 Bug Report URL: https://bugs.debian.org/984736

   crun (#1016183), requested 140 days ago
 Description: lightweight OCI runtime for running containers
 Reverse Depends: podman
 Installations reported by Popcon: 1607
 Bug Report URL: https://bugs.debian.org/1016183

   cyrus-imapd (#921717), requested 1406 days ago
 Description: Cyrus mail system - IMAP support
 Reverse Depends: cyrus-admin cyrus-caldav cyrus-clients cyrus-dev
   cyrus-imapd cyrus-murder cyrus-nntpd cyrus-pop3d cyrus-replication
 Installations reported by Popcon: 406
 Bug Report URL: https://bugs.debian.org/921717

   debtags (#962579), requested 918 days ago
 Description: Debian Package Tags support tools
 Reverse Depends: packagesearch
 Installations reported by Popcon: 1372
 Bug Report URL: https://bugs.debian.org/962579

   dee (#831388), requested 2344 days ago
 Description: model to synchronize mu

Re: Bug#1026087: ITP: distribution-gpg-keys -- GPG keys by various Linux distributions

[debian]

Hi!

On Thu, Dec 15, 2022 at 03:12:21PM +0100, Guillem Jover wrote:
> The project name talks about gpg keys, but those are really OpenPGP
> keys (or even better, certificates). I've asked upstream to rename the
> project to avoid this common confusion. So you might want to wait until
> that's settled to avoid multiple trips over NEW.
> 
>   
Thank you very much! I liked this issue on github and waiting for
upstream reply.
> 
> (If this project is also intended to only cover RPM-based distributions,
> as Adam brought up, you might want to further ask them to make that clear
> from the project name, say rpm-distribution-openpgp-keys or similar. But
> in any case regardless of the intended target use, it still seems like a
> very generic name which can be easily confused for a package that would
> be needed for Debian, or derivatives.)
Mainly for mock we just need keys for rpm-based
distributions/repositories. On the other way we have
extrepo-offline-data package where are repository keys for 3rd party debian 
repositories. Also maybe it's better to have extern PGP keys on one place.
What do you think about it?

Best Regards,
Juri Grabowski

Re: Bug#1026087: ITP: distribution-gpg-keys -- GPG keys by various Linux distributions

[Juri Grabowski]

Hello,

On Thu, Dec 15, 2022 at 08:15:37AM +0100, Adam Borowski wrote:
> These are all RPM distributions, which is definitely not what one would
> expect in our context.  At the very least the short desc would need to
> mention that, and I'd recommend having that in the name as well.
Thank you for your reply!
Mainly I agree with you.
Quebes is not really RPM distribution as long I know.
There is some keys for zoom, skype and others which are more self-contained.
Your suggestion for package descriptions?

Best Regards,
Juri Grabowski

Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

[Ian Jackson]

Helmut Grohne writes ("Re: Proposed `cargo-upstream` dpkg-buildpackage etc. 
build profile"):
> Thank you very much for immediately taking this to the list.

You're welcome.

Thanks for the review and the penetrating questions.

> I think that you imply here that all of the rust libraries would be
> annotated . Do you confirm?

Yes.

> Yes:
> 
> I caution that we increase our (uncompressed) sources by 200KB for
> adding this. This assumes changing every package, but the scope
> isn't entirely clear, see below. Do you confirm that this is the
> intention and that you think this increase is fine?

No, this is not my intention.  And IMO that increase would be
undesirable.

This facility is certainly cxompletely useless for a Rust library
package - those whose .debs are the Rust text and metadata, for
building other programs against.  Those things don't even have "real"
Rust build-dependencies - the Rust build deps are just there for
testing etc.  And there is no use to anyone building such a package if
they are using upstream crates.io packages.

So at the very least we're limiting this to leaf packages containing
binaries.  And, probably even then, this will only be useful when the
Debian or upstream maintainers want this hybrid or stepping stone
workflow.

I was imagining that this would be done ad-hoc by a maintainer when
they had a reason to do it, not that it would be supported by even
every leaf package.  In some cases it might be a transitional state.

I do think it would be useful for the central tooling to offer this
build profile for every package, but I don't think it is appropriate
to annotate all the Rust build depends for every package this way.
Tools like debcargo ought *not* to add this build profile to the Rust
deps.

If this profile turns out to be widely desired for "leaf packages at
random", filtering (or dummy-satisfying) the build dependencies should
be done some other way.

> Which packages should support this profile? I see the value for
> applications. Do you also intend it for libraries? If yes, how do they
> benefit?

They don't.

> How do you intend to transition packages to support this profile?
> Should that happen on an as-needed basis? Should it happen as a mass
> commit? Do you want it mass uploaded?

As needed.  No mass commit, no mass upload, no automated change.

> Given all of the mails in the thread thus far, you've convinced me:
>  * That the requested feature is useful.
>  * That it should be ecosystem-specific.
>  * That it needs to be easy to use (and that build profiles satisfy this
>requirement).
> 
> On the bike coloring front, I do prefer putting the package ecosystem
> last (i.e. upstream-cargo > cargo-upstream) for the consistency reasons
> that you gave in a reply.

I think I'm sold on that name question.

> I would also question the "upstream" part as it wasn't obvious to me
> initially. Good alternatives that aren't too long are not easy to come
> by, but maybe you have a reason to reject "external"? I think "external"
> would more strongly highlight that a build is no longer self-contained.

I don't have strong feelings about this.  I chose "upstream" because
that seems to be the term of art that people working in this space
use, to distinguish the general public package repo, from the Debian
one.

> > However, this could be a generally useful feature for Debian's cargo
> > tooling to support, and I think it could do so in a general way so
> > that this profile would be available in most Debian packages
> > containing Rust code, without package-specific work.  Whether to
> > implement such a feature is a matter for the maintainers of dh_cargo
> > et al.; IMO the build profile registration is useful even ad-hoc,
> > without any general feature.
> 
> Yeah, having this supported generically seems very useful. It would be
> nice to have a supportive reply from one of the dh-cargo maintainers
> here. (I do not see this as a requirement.)
> 
> I note that "without package-specific work" implies that you wouldn't
> attach build profiles to Build-Depends, which was my initial question.
> I'll stop second guessing here and wait for your answer.

I'm not sure precisely how this feature could (or should) be made
available to *all* application packages in a central way.  Having
tools like debcargo automatically add the profile to the build deps
produces a lot of bloat.  I'm hoping there is a better way.

But even without modifying the build dependencies, it is a lot easier
to cause a build to run without the stated build deps being satisfied,
than it is to do violence to the package build system.

This could be made easier.  Maybe tools like sbuild could have a
sepaarate option to disregard build deps matching a wildcard pattern,
or something.

I am hoping to leave these considerations for the future.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private addres

Bug#1026176: ITP: nim-httpbeast -- Fast multi-threaded HTTP server library for Nim

[Federico Ceratto]

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

* Package name: nim-httpbeast
  Version : 0.4.1
  Upstream Contact: Dominik Picheta
* URL : https://github.com/dom96/httpbeast
* License : Expat
  Programming Lang: Nim
  Description : Fast multi-threaded HTTP server library for Nim

Built on the Nim selectors module which makes efficient use of epoll on Linux
Automatic parallelization when compiling with --threads:on.
Support for HTTP pipelining.
On-demand parser so that only the requested data is parsed.
Integration with Nim's asyncdispatch allowing async/await to be used in.
the request callback whenever necessary.

Maintained by the Debian Nim Team at
https://salsa.debian.org/nim-team/nim-httpbeast

Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

[Helmut Grohne]

Hi Ian,

Thank you very much for immediately taking this to the list. The
discussion I've seen thus far seems very constructive and useful to me.
Thanks to the other participants as well.

On Thu, Dec 15, 2022 at 10:41:13AM +, Ian Jackson wrote:
> I would like to add the following entry to the table of build
> profiles in BuildProfileSpec:
> 
>  Profile anme: `cargo-upstream`
>  Can cause changes to built binaries, including functional chnges. (Y)
>  Should not cause changes to set of build debs. (N)
>  Description:
>Obtain Rust dependencies from crates.io, not from Debian; use a
>`Cargo.lock` from the source package if there is one.  Will usually
>cause cargo to make network accesses.  Ideally, behaviour of the
>resulting programs will be the same, but this is not guaranteed.


I think that you imply here that all of the rust libraries would be
annotated . Do you confirm?

Yes:

I caution that we increase our (uncompressed) sources by 200KB for
adding this. This assumes changing every package, but the scope
isn't entirely clear, see below. Do you confirm that this is the
intention and that you think this increase is fine?

No:

Would this profile show up in debian/control in any way? If not, why
use a build profile rather than an option?

(Please do skip questions that do not apply.)

Which packages should support this profile? I see the value for
applications. Do you also intend it for libraries? If yes, how do they
benefit?

How do you intend to transition packages to support this profile?
Should that happen on an as-needed basis? Should it happen as a mass
commit? Do you want it mass uploaded?

> This is useful when developing packages which are to be uploaded to
> Debian, but whose build dependencies are not yet available in the
> targeted suite.

Given all of the mails in the thread thus far, you've convinced me:
 * That the requested feature is useful.
 * That it should be ecosystem-specific.
 * That it needs to be easy to use (and that build profiles satisfy this
   requirement).

On the bike coloring front, I do prefer putting the package ecosystem
last (i.e. upstream-cargo > cargo-upstream) for the consistency reasons
that you gave in a reply.

I would also question the "upstream" part as it wasn't obvious to me
initially. Good alternatives that aren't too long are not easy to come
by, but maybe you have a reason to reject "external"? I think "external"
would more strongly highlight that a build is no longer self-contained.

In any case, I think the naming questions are solvable one way or
another, so please focus on the non-naming aspects first. I don't feel
too strongly about naming.

> However, this could be a generally useful feature for Debian's cargo
> tooling to support, and I think it could do so in a general way so
> that this profile would be available in most Debian packages
> containing Rust code, without package-specific work.  Whether to
> implement such a feature is a matter for the maintainers of dh_cargo
> et al.; IMO the build profile registration is useful even ad-hoc,
> without any general feature.

Yeah, having this supported generically seems very useful. It would be
nice to have a supportive reply from one of the dh-cargo maintainers
here. (I do not see this as a requirement.)

I note that "without package-specific work" implies that you wouldn't
attach build profiles to Build-Depends, which was my initial question.
I'll stop second guessing here and wait for your answer.

Helmut

Re: Bug#1026087: ITP: distribution-gpg-keys -- GPG keys by various Linux distributions

[Adam Borowski]

On Thu, Dec 15, 2022 at 03:12:21PM +0100, Guillem Jover wrote:
> On Wed, 2022-12-14 at 15:27:18 +0100, Juri Grabowski wrote:
> > * Package name: distribution-gpg-keys
> >   Upstream Author : Miroslav Suchý 
> > * URL : https://github.com/xsuchy/distribution-gpg-keys/
> >   Description : GPG keys by various Linux distributions
> > 
> > used by various Linux distributions to sign packages.
> > 
> > needed by mock/3.5 and I need a sponsor for this package. See current 
> > packaging in
> > https://salsa.debian.org/pkg-rpm-team/distribution-gpg-keys
> > After I know ITP bug number I upload this source package to
> > https://mentors.debian.net/package/distribution-gpg-keys/

> (If this project is also intended to only cover RPM-based distributions,
> as Adam brought up, you might want to further ask them to make that clear
> from the project name, say rpm-distribution-openpgp-keys or similar.

When in that project's native environment, ie a RPM distribution, the name
_is_ adequate.  It's only in Debian (/Alpine/Arch/Gentoo/...) where the
name can be confusing.  But then, there's no requirement for the package
name to match upstream.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

[Russ Allbery]

Ian Jackson  writes:

> I would like to add the following entry to the table of build
> profiles in BuildProfileSpec:

>  Profile anme: `cargo-upstream`
>  Can cause changes to built binaries, including functional chnges. (Y)
>  Should not cause changes to set of build debs. (N)
>  Description:
>Obtain Rust dependencies from crates.io, not from Debian; use a
>`Cargo.lock` from the source package if there is one.  Will usually
>cause cargo to make network accesses.  Ideally, behaviour of the
>resulting programs will be the same, but this is not guaranteed.

> This is useful when developing packages which are to be uploaded to
> Debian, but whose build dependencies are not yet available in the
> targeted suite.

I think this is a great idea.

In addition to the benefits you list (and less importantly, because
there's less direct affect on Debian), having this feature available would
make it easier to create a first pass of a package of a Rust tool intended
for local use.  I often build semi-broken short-cut packages locally of
things I need on some system but haven't yet found the time to make them
properly ready for Debian, and then gradually finish the work to get them
into Debian.  It would be very useful to have this support to get over the
initial barrier to making a Debian package.

I think it would increase the likelihood that I'd eventually do the work
to get all the way to an uploadable Debian package, whereas if it's
difficult to bootstrap from Cargo, I'm much more likely to let laziness
win, just build a static binary, and copy it around.

This is why I don't agree with Jonas: yes, there *are* other ways to
achieve the same goal, but they're more complicated and harder to explain.
The user experience of this build profile looks a lot simpler and cleaner.

-- 
Russ Allbery (r...@debian.org)  

Re: looking for debian friendly web app technology

[Timothy M Butterworth]

On Thu, Dec 15, 2022 at 8:51 AM Alastair McKinstry <
alastair.mckins...@sceal.ie> wrote:

> Hi,
>
> Is Qt6-base  not in testing, for bookworm? I've an app (metview) that I
> switched over Qt5->Qt6, should I move it back?
>
>
Bookworm currently has Qt 6.3.1 and 6.4.0 packaged.


> regards
>
> Alastair
>
> On 13/12/2022 20:27, Andreas Josef Heil wrote:
> > Well qt5 is fine too. I don't need fancy features. I will make a kde app.
> >
> > On 13.12.22 05:22, Imre Nagy wrote:
> >> The downside of these things, that current Debian does not seem to
> >> include Qt6 at all and I have no idea when it can go into the
> >> mainstream Debian, while there are a lot of project could be waiting
> >> for it. (Even my one is still pending for Debian). Qt6 for Debian is
> >> still in unstable/experimental state, which drives the developers
> >> like me to find other alternatives instead of Debian or for Debian.
> >>
> >> Best regards,
> >> Imre
> >>
> >> 2022. 12. 13. 1:48 keltezéssel, Sam Hartman írta:
>  I wrote too early sry. A desktop app is also possible. I will use qt.
> >
> --
> Alastair McKinstry,
> GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
> ph: +353 87 6847928 e: alast...@sceal.ie, im: @sceal.ie:mckinstry
>
>

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

[Jonas Smedegaard]

Quoting Ian Jackson (2022-12-15 14:05:32)
> Jonas Smedegaard writes ("Re: Proposed `cargo-upstream` dpkg-buildpackage 
> etc. build profile"):
> > What is the benefit of introducing a standardized flag for this
> > relatively narrow scope, compared to doing non-standardized fetching of
> > crates _before_ package build and building with those embedded?
> > Example of doing that is here: https://salsa.debian.org/debian/helvum
> > (essentially doing `cargo vendor --versioned-dirs debian/vendorlibs`).
> 
> IDK what precisely you mean there, and you've liked to the repo as a
> whole so I'm not sure what to look for.  Maybe you mean "what's wrong
> with pretending to vendor the dependencies" ?
> 
> Whatever approach is taken, it has to be controlled somehow.  For
> example, the paths to dependencies need to be adjusted, or the use of
> the Debian cargo wrapper enabled/disabled.
> 
> That control can be done by: (i) modifying the package source code
> (which is much more a pain, even if it's a toggle in a single place),
> (ii) ad-hoc environment variables or something (which don't survive
> sbuild) or (iii) a build profile.
> 
> ISTM that this kind of "build this package in s funky way" situation
> is precisely what build profiles are good for.

I disagree that it "has to be controlled somehow" *during build*, which
build profiles is about.

Looking at current list of profile names at
https://wiki.debian.org/BuildProfileSpec#Registered_profile_names it
seems to me that none of them involve violating the principle of source
package providing source for the build.

Essentially, you are proposing to formalize a way for injecting source
during build.

Debian currently has tooling for helping fetch source _before_ build,
most notably uscan, which does not involve defining a build profile
because what is built is static.

What I question is the sense of introducing dynamic-source builds, as
opposed to mangle-source-before-build which as a proof of concept is
possible to do with Rust creates through calling `cargo vendor ...`
_outside_ of regular dpkg-source mandated build targets.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: Bug#1026087: ITP: distribution-gpg-keys -- GPG keys by various Linux distributions

[Guillem Jover]

Hi!

On Wed, 2022-12-14 at 15:27:18 +0100, Juri Grabowski wrote:
> Package: wnpp
> Version: 1.79
> Severity: wishlist
> Owner: Juri Grabowski 
> X-Debbugs-Cc: debian-devel@lists.debian.org, deb...@jugra.de

> * Package name: distribution-gpg-keys
>   Version : 1.7.9
>   Upstream Author : Miroslav Suchý 
> * URL : https://github.com/xsuchy/distribution-gpg-keys/
> * License : CC0-1.0
>   Programming Lang: data
>   Description : GPG keys by various Linux distributions
> 
> used by various Linux distributions to sign packages.
> 
> needed by mock/3.5 and I need a sponsor for this package. See current 
> packaging in
> https://salsa.debian.org/pkg-rpm-team/distribution-gpg-keys
> After I know ITP bug number I upload this source package to
> https://mentors.debian.net/package/distribution-gpg-keys/

The project name talks about gpg keys, but those are really OpenPGP
keys (or even better, certificates). I've asked upstream to rename the
project to avoid this common confusion. So you might want to wait until
that's settled to avoid multiple trips over NEW.

  

(If this project is also intended to only cover RPM-based distributions,
as Adam brought up, you might want to further ask them to make that clear
from the project name, say rpm-distribution-openpgp-keys or similar. But
in any case regardless of the intended target use, it still seems like a
very generic name which can be easily confused for a package that would
be needed for Debian, or derivatives.)

Thanks,
Guillem

Re: looking for debian friendly web app technology

[Alastair McKinstry]

Hi,

Is Qt6-base  not in testing, for bookworm? I've an app (metview) that I 
switched over Qt5->Qt6, should I move it back?


regards

Alastair

On 13/12/2022 20:27, Andreas Josef Heil wrote:

Well qt5 is fine too. I don't need fancy features. I will make a kde app.

On 13.12.22 05:22, Imre Nagy wrote:
The downside of these things, that current Debian does not seem to 
include Qt6 at all and I have no idea when it can go into the 
mainstream Debian, while there are a lot of project could be waiting 
for it. (Even my one is still pending for Debian). Qt6 for Debian is 
still in unstable/experimental state, which drives the developers 
like me to find other alternatives instead of Debian or for Debian.


Best regards,
Imre

2022. 12. 13. 1:48 keltezéssel, Sam Hartman írta:

I wrote too early sry. A desktop app is also possible. I will use qt.



--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
ph: +353 87 6847928 e: alast...@sceal.ie, im: @sceal.ie:mckinstry

Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

[Ian Jackson]

Wouter Verhelst writes ("Re: Proposed `cargo-upstream` dpkg-buildpackage etc. 
build profile"):
> I have just one question: why make this rust-specific? I think a similar
> thing might be useful for golang packages (who also don't support shared
> libraries), or, heck, even Perl (if I'm willing to test that the package
> works while I have the not-yet-packaged dependencies in my ~/perl5/lib)

You are absolutely right that many other upstream (language-specifc)
package managers will have analogous situations.

I think *each* of these should have their *own* build-profile, rather
than one portmanteau one.  If a package has both Rust and NPM
build-dependencies, say, a user may very well want to use Rust
dependencies from Debian and NPM dependencies from upstream, or vice
versa.

The profile name should be named after the upstream package manager
being influenced, not after the programming language, since some
languages have several.

So I think that we will probably want
   cargo-upstream
   npm-upstream
   golang-upstream (is this the right name?)
etc.

Maybe this means that the name ought to be the other way arond, so
they all group together in the table, like the `no*` options.
   upstream-cargo
   upstream-npm
   upstream-golang (is this the right name?)

I don't want to speak for those working with these other package
managers, so I don't propose to add all of those right away.  But
establishing the precedent will hopefulloy be helpful for them

So for now I'm proposing to add just the cargo one.  If someone
working with Node packages (say) tells me "we want this for npm too"
then great and we should do that right away.  Otherwise we should
wait until ti's wanted.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

[Ian Jackson]

Jonas Smedegaard writes ("Re: Proposed `cargo-upstream` dpkg-buildpackage etc. 
build profile"):
> Similar pain for other upstream ecosystems as well - I know about npm
> for NodeJS modules, but imagine it is similar for Java and others as
> well.

Yes.

> What is the benefit of introducing a standardized flag for this
> relatively narrow scope, compared to doing non-standardized fetching of
> crates _before_ package build and building with those embedded?
> Example of doing that is here: https://salsa.debian.org/debian/helvum
> (essentially doing `cargo vendor --versioned-dirs debian/vendorlibs`).

IDK what precisely you mean there, and you've liked to the repo as a
whole so I'm not sure what to look for.  Maybe you mean "what's wrong
with pretending to vendor the dependencies" ?

Whatever approach is taken, it has to be controlled somehow.  For
example, the paths to dependencies need to be adjusted, or the use of
the Debian cargo wrapper enabled/disabled.

That control can be done by: (i) modifying the package source code
(which is much more a pain, even if it's a toggle in a single place),
(ii) ad-hoc environment variables or something (which don't survive
sbuild) or (iii) a build profile.

ISTM that this kind of "build this package in s funky way" situation
is precisely what build profiles are good for.

> If there is really a need for a standardized flag, then what is the
> benefit of a narrow one specific to cargo, compared to a more general
> "fetches-source-during-build" that would be suitable also for e.g.
> NodeJS fetching npm modules?

Wouter made the same point - I will reply there, to both the CC lists.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Re: dh_auto_test fails and I do not understand why

[Andrius Merkys]

Hi Niels,

Thanks for the explanation (snipped here).

On 2022-12-15 11:59, Niels Thykier wrote:

Your options include:

  * Migrate to "Rules-Requires-Root: no" if you can


Great, this indeed gets around the issue.

Best wishes,
Andrius

Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

[Wouter Verhelst]

Hi Ian,

On Thu, Dec 15, 2022 at 10:41:13AM +, Ian Jackson wrote:
> I would like to add the following entry to the table of build
> profiles in BuildProfileSpec:
> 
>  Profile anme: `cargo-upstream`
>  Can cause changes to built binaries, including functional chnges. (Y)
>  Should not cause changes to set of build debs. (N)
>  Description:
>Obtain Rust dependencies from crates.io, not from Debian; use a
>`Cargo.lock` from the source package if there is one.  Will usually
>cause cargo to make network accesses.  Ideally, behaviour of the
>resulting programs will be the same, but this is not guaranteed.
[...]

I have just one question: why make this rust-specific? I think a similar
thing might be useful for golang packages (who also don't support shared
libraries), or, heck, even Perl (if I'm willing to test that the package
works while I have the not-yet-packaged dependencies in my ~/perl5/lib)

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

[Jonas Smedegaard]

[ reply to d-devel only, as more suitable for Debian-wide issue ]

Quoting Ian Jackson (2022-12-15 11:41:13)
> I would like to add the following entry to the table of build
> profiles in BuildProfileSpec:
> 
>  Profile anme: `cargo-upstream`
>  Can cause changes to built binaries, including functional chnges. (Y)
>  Should not cause changes to set of build debs. (N)
>  Description:
>Obtain Rust dependencies from crates.io, not from Debian; use a
>`Cargo.lock` from the source package if there is one.  Will usually
>cause cargo to make network accesses.  Ideally, behaviour of the
>resulting programs will be the same, but this is not guaranteed.
> 
> This is useful when developing packages which are to be uploaded to
> Debian, but whose build dependencies are not yet available in the
> targeted suite.

Similar pain for other upstream ecosystems as well - I know about npm
for NodeJS modules, but imagine it is similar for Java and others as
well.

What is the benefit of introducing a standardized flag for this
relatively narrow scope, compared to doing non-standardized fetching of
crates _before_ package build and building with those embedded?
Example of doing that is here: https://salsa.debian.org/debian/helvum
(essentially doing `cargo vendor --versioned-dirs debian/vendorlibs`).

If there is really a need for a standardized flag, then what is the
benefit of a narrow one specific to cargo, compared to a more general
"fetches-source-during-build" that would be suitable also for e.g.
NodeJS fetching npm modules?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Proposed `cargo-upstream` dpkg-buildpackage etc. build profile

[Ian Jackson]

I would like to add the following entry to the table of build
profiles in BuildProfileSpec:

 Profile anme: `cargo-upstream`
 Can cause changes to built binaries, including functional chnges. (Y)
 Should not cause changes to set of build debs. (N)
 Description:
   Obtain Rust dependencies from crates.io, not from Debian; use a
   `Cargo.lock` from the source package if there is one.  Will usually
   cause cargo to make network accesses.  Ideally, behaviour of the
   resulting programs will be the same, but this is not guaranteed.

This is useful when developing packages which are to be uploaded to
Debian, but whose build dependencies are not yet available in the
targeted suite.

It allows a Debian maintainer or user to more easily rebuild the
package in a different suite to the one targeted, and can allow
unification of upstream (crates.io-based) and Debian development
without needing to carry a build system patch.

Particularly, it will sometimes ease the task of getting (leaf)
packages in Debian, as other aspects of the packaging can more easily
be tested separately from working on getting the dependencies in.

This build profile ought only to be used in packages that are intended
to appear in Debian (or a derivative) with .debs built from in-distro
dependencies (ie the dh_cargo-style local cargo replacement
repository, containing).  In such packages, obtaining dependencies
locally from within-distro is the default behaviour without
-Pcargo-upstream.

Invocation of this build profile will generally only be appropriate in
the context of manual development, or package-specific near-upstream
release workflows.  Certainly this profile ought not to be activated
for uploads to Debian, as it makes the package build depend on
out-of-distro inputs (and relies on external network access at build
time).

For now, I expect to use this only in an ad hoc fashion in affected
packages.  (I have a number of candidates.)

However, this could be a generally useful feature for Debian's cargo
tooling to support, and I think it could do so in a general way so
that this profile would be available in most Debian packages
containing Rust code, without package-specific work.  Whether to
implement such a feature is a matter for the maintainers of dh_cargo
et al.; IMO the build profile registration is useful even ad-hoc,
without any general feature.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Re: dh_auto_test fails and I do not understand why

[Johannes Schauer Marin Rodrigues]

Quoting Niels Thykier (2022-12-15 10:59:10)
> Long story short:
> 
>   * Bug in fakeroot (#1023286 + #1024544)
>   * Me thinking it was a bug in debhelper so I tried to fix it
> (which did not work and broke on the way in)
>   * Me realizing it was a bug in fakeroot and my change did not
> even function as a work around, so I undid it (it broke on
> the way out as well).
> 
> And the winners are: All the people that have (and are) able to use 
> "Rules-Requires-Root: no" as packages with that flag would have been
> completely unaffected by this entire ordeal!
> 
> Your options include:
> 
>   * Migrate to "Rules-Requires-Root: no" if you can
>   * Ensure you have debhelper (>= 13.11.3~) ("just uploaded") or
> debhelper/13.11.1 (or debhelper << 13.11)
> 
> I will now go back to looking more at my prototype for getting even more 
> packages buildable with "Rules-Requires-Root: no".

the original cause of all of this is the fakeroot bug since glibc 2.34,
specifically since coreutils was rebuilt with glibc 2.34.

This is a call for help. Please have a look at #1023286 and #1024544.

Back in August, glib 2.34 reached unstable. In October, coreutils 9.1 was
uploaded and used the new glibc functionality. Since then, calls to chown and
other utilities use some new glibc functions on armel, armhf and i386, namely
__stat64_time64, __fstatat64_time64 and __lstat64_time64.

Clint quickly fixed the problem and I submitted a test case so that this kind
of issue does not fly under the radar again in the future. The test case seems
to be working because now we get a build failure on mipsel because the test is
not passing.

So something else is missing. It's likely another glibc function that is
mipsel-specific. I tried to run ltrace on a mipsel porterbox to figure out what
library calls are done by coreutils chown on mipsel but that failed with
"unexpected breakpoint" errors, see #1023436.

Maybe somebody can find out what is wrong with fakeroot on mipsel? Since
fakeroot is a central part of Debian package builds, it would be a shame to
have this bug open for much longer...

Thanks!

cheers, josch

signature.asc
Description: signature

Re: dh_auto_test fails and I do not understand why

[Filippo Rusconi]

Greetings, Niels,

On Thu, Dec 15, 2022 at 10:59:10AM +0100, Niels Thykier wrote:

Andrius Merkys:

Hello,

On 2022-12-15 11:20, Filippo Rusconi wrote:
I have uploaded a package yesterday. That package does not have 
any dh_auto_test

target in d/rules.

The builds all fail, as described here:
https://buildd.debian.org/status/package.php?p=minexpert2
and I do not understand why.
Any soul to help me with this question?


I have just stumbled on the same while building a new package with 
javahelper:


install: cannot change owner and permissions of 
‘debian/_jh_build.lucene9-9.4.2’: Operation not permitted
jh_build: error: install -m0755 -o 0 -g 0 -d 
debian/_jh_build.lucene9-9.4.2 returned exit code 1


However, I have no idea why '-o 0 -g 0' options are used. They do 
not seem to be used before.


Andrius



Long story short:

* Bug in fakeroot (#1023286 + #1024544)
* Me thinking it was a bug in debhelper so I tried to fix it
  (which did not work and broke on the way in)
* Me realizing it was a bug in fakeroot and my change did not
  even function as a work around, so I undid it (it broke on
  the way out as well).

And the winners are: All the people that have (and are) able to use 
"Rules-Requires-Root: no" as packages with that flag would have been

completely unaffected by this entire ordeal!

Your options include:

* Migrate to "Rules-Requires-Root: no" if you can
* Ensure you have debhelper (>= 13.11.3~) ("just uploaded") or
  debhelper/13.11.1 (or debhelper << 13.11)

I will now go back to looking more at my prototype for getting even 
more packages buildable with "Rules-Requires-Root: no".


Thank you so much for the explanation. I'll go the Rules-Requires-Root: no
route!

Sincerely,
Filippo

--

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Research scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄  http://msxpertsuite.org
  http://www.debian.org



signature.asc
Description: PGP signature

Re: dh_auto_test fails and I do not understand why

[Niels Thykier]

Andrius Merkys:

Hello,

On 2022-12-15 11:20, Filippo Rusconi wrote:
I have uploaded a package yesterday. That package does not have any 
dh_auto_test

target in d/rules.

The builds all fail, as described here:
https://buildd.debian.org/status/package.php?p=minexpert2
and I do not understand why.
Any soul to help me with this question?


I have just stumbled on the same while building a new package with 
javahelper:


install: cannot change owner and permissions of 
‘debian/_jh_build.lucene9-9.4.2’: Operation not permitted
jh_build: error: install -m0755 -o 0 -g 0 -d 
debian/_jh_build.lucene9-9.4.2 returned exit code 1


However, I have no idea why '-o 0 -g 0' options are used. They do not 
seem to be used before.


Andrius



Long story short:

 * Bug in fakeroot (#1023286 + #1024544)
 * Me thinking it was a bug in debhelper so I tried to fix it
   (which did not work and broke on the way in)
 * Me realizing it was a bug in fakeroot and my change did not
   even function as a work around, so I undid it (it broke on
   the way out as well).

And the winners are: All the people that have (and are) able to use 
"Rules-Requires-Root: no" as packages with that flag would have been

completely unaffected by this entire ordeal!

Your options include:

 * Migrate to "Rules-Requires-Root: no" if you can
 * Ensure you have debhelper (>= 13.11.3~) ("just uploaded") or
   debhelper/13.11.1 (or debhelper << 13.11)

I will now go back to looking more at my prototype for getting even more 
packages buildable with "Rules-Requires-Root: no".


Thanks,
~Niels

Re: dh_auto_test fails and I do not understand why

[Andrius Merkys]

On 2022-12-15 11:44, Sebastiaan Couwenberg wrote:

On 12/15/22 10:34, Andrius Merkys wrote:
However, I have no idea why '-o 0 -g 0' options are used. They do not 
seem to be used before.


Recent changes in debhelper, see:

https://salsa.debian.org/debian/debhelper/-/commit/ca66cf4bc74fe31b3d5c8131788e7fdd8731

https://salsa.debian.org/debian/debhelper/-/commit/e41b7d15c4b005def732cb9f82ed14171499689d


Thanks for prompt response. Thus the issue is resolved in debhelper 13.11.3.

Best,
Andrius

Re: dh_auto_test fails and I do not understand why

[Sebastiaan Couwenberg]

On 12/15/22 10:34, Andrius Merkys wrote:
However, I have no idea why '-o 0 -g 0' options are used. They do not 
seem to be used before.


Recent changes in debhelper, see:


https://salsa.debian.org/debian/debhelper/-/commit/ca66cf4bc74fe31b3d5c8131788e7fdd8731

https://salsa.debian.org/debian/debhelper/-/commit/e41b7d15c4b005def732cb9f82ed14171499689d

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: dh_auto_test fails and I do not understand why

[Andrius Merkys]

Hello,

On 2022-12-15 11:20, Filippo Rusconi wrote:
I have uploaded a package yesterday. That package does not have any 
dh_auto_test

target in d/rules.

The builds all fail, as described here:
https://buildd.debian.org/status/package.php?p=minexpert2
and I do not understand why.
Any soul to help me with this question?


I have just stumbled on the same while building a new package with 
javahelper:


install: cannot change owner and permissions of 
‘debian/_jh_build.lucene9-9.4.2’: Operation not permitted
jh_build: error: install -m0755 -o 0 -g 0 -d 
debian/_jh_build.lucene9-9.4.2 returned exit code 1


However, I have no idea why '-o 0 -g 0' options are used. They do not 
seem to be used before.


Andrius

dh_auto_test fails and I do not understand why

[Filippo Rusconi]

Greetings, fellow Debianites,

I have uploaded a package yesterday. That package does not have any dh_auto_test
target in d/rules.

The builds all fail, as described here:
https://buildd.debian.org/status/package.php?p=minexpert2
and I do not understand why. 


Any soul to help me with this question?

Sincerely,
Filippo

--

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Research scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄  http://msxpertsuite.org
  http://www.debian.org

Bug#1026127: ITP: python-comm -- Register a comm implementation in the Jupyter kernel

[Jochen Sprickerhof]

Package: wnpp
Severity: wishlist
Owner: Jochen Sprickerhof 
X-Debbugs-Cc: debian-devel@lists.debian.org, jpu...@debian.org

* Package name: python-comm
  Version : 0.1.2
* URL : https://github.com/ipython/comm
* License : BSD-3-clause
  Programming Lang: Python
  Description : Register a comm implementation in the Jupyter kernel

It provides a way to register a Kernel Comm implementation, as per the Jupyter
kernel protocol. It also provides a base Comm implementation and a default
CommManager that can be used.

This is a new dependency of the ipykernel package and will be maintained
as part of the Python Team.

Bug#1026126: crosvm -- The Chrome OS Virtual Machine Monitor

[Junichi Uekawa]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-r...@lists.debian.org
X-Debbugs-CC: debian-devel@lists.debian.org


  Package name: crosvm
  Version : 0.0.1?
  Upstream Contact: crosvm-...@chromium.org
  URL : https://chromium.googlesource.com/crosvm/crosvm/
  License : BSD 3-clause
  Programming Lang: Rust
  Description : The Chrome OS Virtual Machine Monitor

  crosvm is a Virtual Machine Monitor for full system emulation using
  KVM, useful for running Linux guest OS inside a virtual machine of
  the same architecture as the host, similar to qemu.
  
  crosvm is designed with a multi-process architecture where each
  emulated device is running inside a sandbox.