Re: Enabling -fstack-clash-protection for trixie

[Lucas Nussbaum]

Hi Emanuele,

On 10/08/23 at 16:57 +0200, Emanuele Rocca wrote:
> Hi,
> 
> On 2023-08-10 02:43, Lucas Nussbaum wrote:
> > What I would need is a script that customizes a chroot.
>   
> This is what I'm passing to sbuild --chroot-setup-commands for my
> builds:
> 
> sbuild --chroot-setup-commands='printf "APPEND CFLAGS 
> -fstack-clash-protection\nAPPEND CXXFLAGS -fstack-clash-protection\n" > 
> /etc/dpkg/buildflags.conf'
> 
> Would a script with just that printf command work for collab-qa-tools?

Apparently yes.

Results:
http://qa-logs.debian.net/2023/08/11.stackclash-arm/

I only included logs for builds that succeeded in a vanilla build,
but failed with the custom build.

Lucas

guile-gnutls not picked up by sid autobuilders

[Andreas Metzler]

Good morning,

guile-gnutls was uploaded almost a week ago to sid, but the unstable
autobuilders seem to ignore it.
https://buildd.debian.org/status/package.php?p=guile-gnutls

Is there anything I can do? The experimental uploads were picked up
seamlessly.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Request for review of debootstrap change [was: Re: Second take at DEP17 - consensus call on /usr-merge matters]

[Helmut Grohne]

Hi Holger,

On Fri, Aug 11, 2023 at 09:28:51AM +, Holger Levsen wrote:
> On Fri, Aug 11, 2023 at 09:38:02AM +0100, Luca Boccassi wrote:
> > > This is implemented in
> > > https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/96
>  
> what about cdebootstrap?

cdebootstrap (and mmdebstrap) never implemented a merging step[1] and to
this date rely on the usrmerge package doing it at postinst time. Once
base-files ships the aliasing symlinks, both will produce /usr-merged
trees without any modifications. The reason that we need a change to
debootstrap is that its current merging implementation breaks when
base-files ships aliasing symlinks.

So the main reason for doing this change to debootstrap is that it
enables us to continue supporting cdebootstrap and mmdebstrap without
any changes there.

Helmut

[1] For mmdebstrap there is a merged-usr hook that can do it. Johannes
will migrate it to the same post-merging approach I am proposing for
debootstrap here.

Bug#1043464: ITP: libpeas2 -- application plugin library

[Jeremy Bícha]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org
Owner: jeremy.bi...@canonical.com

Package Name: libpeas2
Version: 1.99.0
Upstream Author: Garret Regier, et al.
License: LGPL-2.1+
Programming Lang: C (also Python3, JavaScript, Lua)

Description: Application plugin library
 libpeas-2 is a library that allows applications to support plugins.

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

This is a new API for libpeas. It drops the GTK3 dependency and
support so I don't think it's very practical for most reverse
dependencies to switch to the new libpeas until they are ready to
upgrade away from GTK3. Therefore, we will need to keep both versions
of libpeas in Debian.

Currently, the only thing I know of that uses libpeas2 is GNOME Builder 45.

Thanks,
Jeremy Bícha

nvidia-graphics-drivers-legacy-390xx uploaded 8 days ago but not yet installed

[Vincent Lefevre]

Hi,

Bug 1042892 in nvidia-legacy-390xx-kernel-dkms was fixed on 2 August,
and the packages for amd64 and i386 were built 8 days ago, but they
are still in the "Uploaded" state (contrary to armhf):

https://buildd.debian.org/status/package.php?p=nvidia-graphics-drivers-legacy-390xx

What happens?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Request for review of debootstrap change [was: Re: Second take at DEP17 - consensus call on /usr-merge matters]

[Holger Levsen]

On Fri, Aug 11, 2023 at 09:38:02AM +0100, Luca Boccassi wrote:
> > This is implemented in
> > https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/96
 
what about cdebootstrap?


-- 
cheers,
Holger

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

"In just 6 decades, roughly the life span of a blue whale, humans took blue 
whale
population down from 360,000 to just 1,000. In one century, whalers killed two
million baleen whales, which together weighed twice as much as all wild mammals
on Earth today."
https://www.theatlantic.com/science/archive/2021/11/whaling-whales-food-krill-iron/620604/


signature.asc
Description: PGP signature

Re: Request for review of debootstrap change [was: Re: Second take at DEP17 - consensus call on /usr-merge matters]

[Luca Boccassi]

On Fri, 11 Aug 2023 at 05:52, Helmut Grohne  wrote:
>
> Hi,
>
> This is picking up on the debootstrap matter and is kinda crucial.
>
> On Thu, Jul 13, 2023 at 01:31:04AM +0100, Luca Boccassi wrote:
> > > After having sorted this out, what part of your safety concerns with 3C
> > > do remain?
> >
> > Nothing, as that stemmed from a misunderstanding of what the
> > implementation would have required, and that's cleared now.
>
> So we finally removed the misunderstanding with Luca and I imply that
> this also removes Sam's concern (as he was inheriting the
> misunderstanding from Luca).
>
> Let me briefly recap the most important pieces. The proposal at hand is
> changing debootstrap in unstable, testing, stable and oldstable. Rather
> than merging /usr before the initial unpack, it will merge after the
> initial unpack but before running maintainer scripts. Therefore
> base-files can ship aliasing symlinks without triggering tar errors from
> debootstrap and once it does, the merging step in debootstrap
> automatically becomes a noop. With this change in place, we can move
> forward without changing cdebootstrap nor mmdebstrap.
>
> This is implemented in
> https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/96
> and reviewed by Luca Boccassi and Simon McVittie. Thank you two. I have
> tested this change for bootstrapping buster, bullseye, bookworm and
> trixie on amd64 without hitting regressions.
>
> Do we have any more disagreement with this approach or implementation?
> If you review the MR, don't hesitate to leave a positive or negative
> comment on it. We want to make sure that this doesn't break stuff as its
> exposure is high.
>
> I intend to merge and NMU this change before too long and Simon McVittie
> intends to prepare stable and oldstable uploads with this change and the
> change to make --variant=buildd /usr-merged for trixie and beyond.
> Having these changes in oldstable (and thus affecting buildds) is a
> precondition for lifting the moratorium, so we'd like to move forward
> soon.

Ship it!

If you need help with NMUs to unstable or *stable let me know.

Kind regards,
Luca Boccassi

Re: snapshot.d.o has been in a bad state for several months

[Christian Kastner]

On 2023-08-02 13:33, Johannes Schauer Marin Rodrigues wrote:
> snapshot.debian.org is getting worse again. There is not a single snapshot for
> August yet and the last days of July are spotty:
[...]
> I'd argue that snapshot.d.o is part of the central services Debian provides 
> and
> it should work better than it does right now.

I second this, snapshot.d.o pas proven to be an invaluable tool for
reproducing issues.

Is there any way we can help resolve the open issues?

Best,
Christian