On Sun, 24 Mar 2024 at 18:20:30 +0100, Samuel Thibault wrote:
> - it's indeed better to avoid loading porters with this, notably because
> it'll be most often the same for a set of architectures. The buildd
> infrastructure could have an additional build-profile parameter that
> can be set
Quoting Samuel Thibault (2024-03-24 18:20:30)
> - making sure that the Debian release eventually only contains non-profile
> builds should be relatively easy thanks to the buildinfo files (they
> currently only contain them in the DEB_BUILD_PROFILES environment variable,
> they could be added as
Simon McVittie, le dim. 24 mars 2024 16:45:02 +, a ecrit:
> On Sun, 24 Mar 2024 at 13:09:02 +0100, Samuel Thibault wrote:
> > Simon McVittie, le dim. 24 mars 2024 11:59:50 +, a ecrit:
> > > For the specific example of pipewire, I've suggested temporarily
> > > dropping that feature from
On Sun, 24 Mar 2024 at 13:09:02 +0100, Samuel Thibault wrote:
> Simon McVittie, le dim. 24 mars 2024 11:59:50 +, a ecrit:
> > For the specific example of pipewire, I've suggested temporarily
> > dropping that feature from pipewire on the affected architectures
> >
Simon McVittie, le dim. 24 mars 2024 11:59:50 +, a ecrit:
> On Sun, 24 Mar 2024 at 12:56:52 +0500, Andrey Rakhmatullin wrote:
> > 2. FTBFSing packages (those that block further work, anyway)
> ...
> > An example of a currently existing obstacle of this kind is snapd-glib
> > (mainly because it
On Sun, 24 Mar 2024 at 12:56:52 +0500, Andrey Rakhmatullin wrote:
> 2. FTBFSing packages (those that block further work, anyway)
...
> An example of a currently existing obstacle of this kind is snapd-glib
> (mainly because it blocks pipewire).
For the specific example of pipewire, I've suggested
On Sat, Mar 23, 2024 at 04:50:48PM -0500, Steven Robbins wrote:
> Wondering about the current state of this transition.
It's still in the stage of re-bootstrapping armel and armhf.
https://buildd.debian.org/stats/armel.png
https://buildd.debian.org/stats/armhf.png
Wondering about the current state of this transition. Is there a tracker of
any kind for this? Or would someone be willing to post an email here
periodically? Weekly maybe?
I looked at the release goals wiki and at the "brain dump" page but failed to
find anything dated more precisely than
On Thu, Mar 14, 2024 at 08:42:14PM -0700, Steve Langasek wrote:
> On Thu, Mar 14, 2024 at 10:47:02PM +0100, Micha Lenk wrote:
> > The time_t transition seems to be stalled due to issues on armel/armhf
> > architecture. My understanding is, as long as this transition isn't over,
> > uploaders of
Hi,
On Thu, Mar 14, 2024 at 10:47:02PM +0100, Micha Lenk wrote:
> The time_t transition seems to be stalled due to issues on armel/armhf
> architecture. My understanding is, as long as this transition isn't over,
> uploaders of affected packages are discouraged to upload anything
> unrelated to
Hi all,
The time_t transition seems to be stalled due to issues on armel/armhf
architecture. My understanding is, as long as this transition isn't over,
uploaders of affected packages are discouraged to upload anything unrelated to
this transition (to avoid any delays to get it through).
Do
Hi Simon,
On Mon, Feb 26, 2024 at 11:40:56AM +, Simon McVittie wrote:
> > glib2.0 # already in experimental
> The upstream version in experimental is unsuitable for unstable, but it's
> "the same shape" as the version in unstable in all the places that matter,
> and we
On Sun, 25 Feb 2024 at 23:56:58 -0800, Steve Langasek wrote:
> I have attached the full list of current packages missing correct builds in
> experimental here for review. I am also attaching dd-list output for the
> same. Please check whether you have packages on this list that need
> attention.
On Fri, Feb 23, 2024 at 04:36:43PM +0100, Guillem Jover wrote:
> Hi!
> On Mon, 2024-02-19 at 19:48:38 -0800, Steve Langasek wrote:
> > I have coordinated with the gcc maintainer so that we can have the default
> > flags in gcc-13 changed this week.
> > We are therefore targeting Friday for the
Hi!
On Mon, 2024-02-19 at 19:48:38 -0800, Steve Langasek wrote:
> I have coordinated with the gcc maintainer so that we can have the default
> flags in gcc-13 changed this week.
>
> We are therefore targeting Friday for the mass NMUs to unstable though there
> is a possibility this won't start
15 matches
Mail list logo
