All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: Fiona Klute <fiona.klute@gmx.de>
Cc: Julien Olivain <ju.o@free.fr>, buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH 1/1] package/squashfs: bump to version 4.7.4
Date: Tue, 6 Jan 2026 15:47:58 +0100	[thread overview]
Message-ID: <20260106154758.37b2117e@windsurf> (raw)
In-Reply-To: <08ad8b80-c5b6-4dfe-a3a9-e3030583af59@gmx.de>

Hello Fiona,

On Tue, 6 Jan 2026 14:52:07 +0100
Fiona Klute <fiona.klute@gmx.de> wrote:

> > I've created an upstream issue about the problem, citing your version 
> > details (thanks!): https://github.com/plougher/squashfs-tools/issues/338  
> 
> Update: The upstream maintainer has added a fallback similar to the 
> util-linux one [1]. However a new issue has been reported since about 
> corrupted images with all-zero files [2], so I think it's best to delay 
> the update until that's resolved.
> 
> > On the Buildroot side I wonder how old toolchains can reasonably be 
> > before we consider them *too old*. So far I thought the Bootlin stable 
> > toolchains were the expected baseline, because they're supposed to be 
> > used for tests unless there's a good reason not to. Personally, I 
> > wouldn't consider musl 1.2.3 "recent", uClibc-ng 1.0.50 maybe kind of, 
> > but toolchains from 2020 definitely outdated. I may be influenced by the 
> > ~2 year Debian stable cycle. ;-)  
> With the upstream fallback merged the question isn't critical any more, 
> but I think it'd be generally useful to have a documented answer.

On the gcc version, we do have a fairly clear policy, but it's true we
don't have such a policy on the C library. We try to reasonably support
older toolchains as we recognize people may be using somewhat old
toolchains to support specific HW, or just because they "fear"
switching to a newer toolchain. So in the case of squashfs, when there
is a relatively easy fallback solution, it's always good to have (and
good for upstream, as it makes their project more broadly "compatible").

I don't know if we want a policy that says "toolchains with components
older than X years are not supported. Can be a topic for the upcoming
Buildroot Developers Meeting though.

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

      reply	other threads:[~2026-01-06 14:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-03 11:40 [Buildroot] [PATCH 1/1] package/squashfs: bump to version 4.7.4 Fiona Klute via buildroot
2026-01-04 12:52 ` Julien Olivain via buildroot
2026-01-04 14:43   ` Fiona Klute via buildroot
2026-01-04 15:34     ` Fiona Klute via buildroot
2026-01-04 18:46       ` Julien Olivain via buildroot
2026-01-04 23:42         ` Fiona Klute via buildroot
2026-01-06 13:52           ` Fiona Klute via buildroot
2026-01-06 14:47             ` Thomas Petazzoni via buildroot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260106154758.37b2117e@windsurf \
    --to=buildroot@buildroot.org \
    --cc=fiona.klute@gmx.de \
    --cc=ju.o@free.fr \
    --cc=thomas.petazzoni@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.