* rt-tests release tarball location
@ 2024-12-28 10:43 Thomas Petazzoni
2025-01-07 9:41 ` Kurt Kanzenbach
0 siblings, 1 reply; 14+ messages in thread
From: Thomas Petazzoni @ 2024-12-28 10:43 UTC (permalink / raw)
To: linux-rt-users
Hello,
I am one of the co-maintainers of Buildroot, an embedded Linux build
system. Among many other packages, we obviously have rt-tests as one of
our packages. When rt-tests is built, we download it from kernel.org.
Unfortunately, the rt-tests tarballs are moved around: the latest
release is available at https://www.kernel.org/pub/linux/utils/rt-tests/,
but as soon as another newer release is available, the older release
tarballs get moved to
https://www.kernel.org/pub/linux/utils/rt-tests/older/.
This breaks the build for build systems such as Buildroot, that expect
a release tarball to stay at a given location, and not being moved
around.
Would it possible to keep the tarballs at the same location? Either by
not having the older/ folder entirely, or by populating it immediately
with the latest release, so that all releases are always available from
the older/ folder?
Thanks a lot for your support!
Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: rt-tests release tarball location
2024-12-28 10:43 rt-tests release tarball location Thomas Petazzoni
@ 2025-01-07 9:41 ` Kurt Kanzenbach
2025-01-07 14:14 ` Sebastian Andrzej Siewior
2025-01-08 18:17 ` John Kacur
0 siblings, 2 replies; 14+ messages in thread
From: Kurt Kanzenbach @ 2025-01-07 9:41 UTC (permalink / raw)
To: Thomas Petazzoni, linux-rt-users
[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]
On Sat Dec 28 2024, Thomas Petazzoni wrote:
> Hello,
>
> I am one of the co-maintainers of Buildroot, an embedded Linux build
> system. Among many other packages, we obviously have rt-tests as one of
> our packages. When rt-tests is built, we download it from kernel.org.
> Unfortunately, the rt-tests tarballs are moved around: the latest
> release is available at https://www.kernel.org/pub/linux/utils/rt-tests/,
> but as soon as another newer release is available, the older release
> tarballs get moved to
> https://www.kernel.org/pub/linux/utils/rt-tests/older/.
>
> This breaks the build for build systems such as Buildroot, that expect
> a release tarball to stay at a given location, and not being moved
> around.
>
> Would it possible to keep the tarballs at the same location? Either by
> not having the older/ folder entirely, or by populating it immediately
> with the latest release, so that all releases are always available from
> the older/ folder?
+1
For Gentoo I had to add both URLs to SRC_URI in the ebuilds. It first
tries rt-tests/ and then rt-tests/older/ location, which is also not
ideal.
Thanks,
Kurt
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: rt-tests release tarball location
2025-01-07 9:41 ` Kurt Kanzenbach
@ 2025-01-07 14:14 ` Sebastian Andrzej Siewior
2025-01-08 18:21 ` John Kacur
2025-01-08 18:17 ` John Kacur
1 sibling, 1 reply; 14+ messages in thread
From: Sebastian Andrzej Siewior @ 2025-01-07 14:14 UTC (permalink / raw)
To: Kurt Kanzenbach, John Kacur, Clark Williams
Cc: Thomas Petazzoni, linux-rt-users
+John, +Clark
On 2025-01-07 10:41:37 [+0100], Kurt Kanzenbach wrote:
> On Sat Dec 28 2024, Thomas Petazzoni wrote:
> > Hello,
> >
> > I am one of the co-maintainers of Buildroot, an embedded Linux build
> > system. Among many other packages, we obviously have rt-tests as one of
> > our packages. When rt-tests is built, we download it from kernel.org.
> > Unfortunately, the rt-tests tarballs are moved around: the latest
> > release is available at https://www.kernel.org/pub/linux/utils/rt-tests/,
> > but as soon as another newer release is available, the older release
> > tarballs get moved to
> > https://www.kernel.org/pub/linux/utils/rt-tests/older/.
> >
> > This breaks the build for build systems such as Buildroot, that expect
> > a release tarball to stay at a given location, and not being moved
> > around.
> >
> > Would it possible to keep the tarballs at the same location? Either by
> > not having the older/ folder entirely, or by populating it immediately
> > with the latest release, so that all releases are always available from
> > the older/ folder?
John, any favorites?
> +1
>
> For Gentoo I had to add both URLs to SRC_URI in the ebuilds. It first
> tries rt-tests/ and then rt-tests/older/ location, which is also not
> ideal.
>
> Thanks,
> Kurt
Sebastian
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: rt-tests release tarball location
2025-01-07 9:41 ` Kurt Kanzenbach
2025-01-07 14:14 ` Sebastian Andrzej Siewior
@ 2025-01-08 18:17 ` John Kacur
1 sibling, 0 replies; 14+ messages in thread
From: John Kacur @ 2025-01-08 18:17 UTC (permalink / raw)
To: Kurt Kanzenbach; +Cc: Thomas Petazzoni, linux-rt-users
On Tue, 7 Jan 2025, Kurt Kanzenbach wrote:
> On Sat Dec 28 2024, Thomas Petazzoni wrote:
> > Hello,
> >
> > I am one of the co-maintainers of Buildroot, an embedded Linux build
> > system. Among many other packages, we obviously have rt-tests as one of
> > our packages. When rt-tests is built, we download it from kernel.org.
> > Unfortunately, the rt-tests tarballs are moved around: the latest
> > release is available at https://www.kernel.org/pub/linux/utils/rt-tests/,
> > but as soon as another newer release is available, the older release
> > tarballs get moved to
> > https://www.kernel.org/pub/linux/utils/rt-tests/older/.
> >
> > This breaks the build for build systems such as Buildroot, that expect
> > a release tarball to stay at a given location, and not being moved
> > around.
> >
> > Would it possible to keep the tarballs at the same location? Either by
> > not having the older/ folder entirely, or by populating it immediately
> > with the latest release, so that all releases are always available from
> > the older/ folder?
>
> +1
>
> For Gentoo I had to add both URLs to SRC_URI in the ebuilds. It first
> tries rt-tests/ and then rt-tests/older/ location, which is also not
> ideal.
Why is it not ideal? This seems like a perfectly reasonable solution?
John
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: rt-tests release tarball location
2025-01-07 14:14 ` Sebastian Andrzej Siewior
@ 2025-01-08 18:21 ` John Kacur
2025-01-08 19:05 ` Crystal Wood
2025-01-09 8:05 ` Sebastian Andrzej Siewior
0 siblings, 2 replies; 14+ messages in thread
From: John Kacur @ 2025-01-08 18:21 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Kurt Kanzenbach, Clark Williams, Thomas Petazzoni, linux-rt-users
On Tue, 7 Jan 2025, Sebastian Andrzej Siewior wrote:
> +John, +Clark
> On 2025-01-07 10:41:37 [+0100], Kurt Kanzenbach wrote:
> > On Sat Dec 28 2024, Thomas Petazzoni wrote:
> > > Hello,
> > >
> > > I am one of the co-maintainers of Buildroot, an embedded Linux build
> > > system. Among many other packages, we obviously have rt-tests as one of
> > > our packages. When rt-tests is built, we download it from kernel.org.
> > > Unfortunately, the rt-tests tarballs are moved around: the latest
> > > release is available at https://www.kernel.org/pub/linux/utils/rt-tests/,
> > > but as soon as another newer release is available, the older release
> > > tarballs get moved to
> > > https://www.kernel.org/pub/linux/utils/rt-tests/older/.
> > >
> > > This breaks the build for build systems such as Buildroot, that expect
> > > a release tarball to stay at a given location, and not being moved
> > > around.
> > >
> > > Would it possible to keep the tarballs at the same location? Either by
> > > not having the older/ folder entirely, or by populating it immediately
> > > with the latest release, so that all releases are always available from
> > > the older/ folder?
>
> John, any favorites?
>
We've been doing this for 15+ years. Normally I would expect the package
creators to come-up with a work around and not expect the people offering
the packages to accomdate your packaging software.
How many kernels back to you need to keep? Could we come up with a
compromise where we keep the newest kernel, plus say the last 3 in the
rt-tests directory before they get moved to the older directory?
John
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: rt-tests release tarball location
2025-01-08 18:21 ` John Kacur
@ 2025-01-08 19:05 ` Crystal Wood
2025-01-09 8:05 ` Sebastian Andrzej Siewior
1 sibling, 0 replies; 14+ messages in thread
From: Crystal Wood @ 2025-01-08 19:05 UTC (permalink / raw)
To: John Kacur, Sebastian Andrzej Siewior
Cc: Kurt Kanzenbach, Clark Williams, Thomas Petazzoni, linux-rt-users
On Wed, 2025-01-08 at 13:21 -0500, John Kacur wrote:
>
> On Tue, 7 Jan 2025, Sebastian Andrzej Siewior wrote:
>
> > +John, +Clark
> > On 2025-01-07 10:41:37 [+0100], Kurt Kanzenbach wrote:
> > > On Sat Dec 28 2024, Thomas Petazzoni wrote:
> > > > Hello,
> > > >
> > > > I am one of the co-maintainers of Buildroot, an embedded Linux build
> > > > system. Among many other packages, we obviously have rt-tests as one of
> > > > our packages. When rt-tests is built, we download it from kernel.org.
> > > > Unfortunately, the rt-tests tarballs are moved around: the latest
> > > > release is available at https://www.kernel.org/pub/linux/utils/rt-tests/,
> > > > but as soon as another newer release is available, the older release
> > > > tarballs get moved to
> > > > https://www.kernel.org/pub/linux/utils/rt-tests/older/.
> > > >
> > > > This breaks the build for build systems such as Buildroot, that expect
> > > > a release tarball to stay at a given location, and not being moved
> > > > around.
> > > >
> > > > Would it possible to keep the tarballs at the same location? Either by
> > > > not having the older/ folder entirely, or by populating it immediately
> > > > with the latest release, so that all releases are always available from
> > > > the older/ folder?
> >
> > John, any favorites?
> >
>
> We've been doing this for 15+ years. Normally I would expect the package
> creators to come-up with a work around and not expect the people offering
> the packages to accomdate your packaging software.
Even when the status quo is both weird (unstable URLs are bad in
general) and has caused issues for multiple packagers, and there's a
simple fix?
>
> How many kernels back to you need to keep? Could we come up with a
> compromise where we keep the newest kernel, plus say the last 3 in the
> rt-tests directory before they get moved to the older directory?
Or just don't move anything, and keep everything in "older" including
the latest release, with the latest release also being in the current
spot (i.e. Thomas's second suggestion).
Or turn older/ into a symlink to the current directory, for
compatibility only, maybe with a "latest" symlink to the current
release.
-Crystal
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: rt-tests release tarball location
2025-01-08 18:21 ` John Kacur
2025-01-08 19:05 ` Crystal Wood
@ 2025-01-09 8:05 ` Sebastian Andrzej Siewior
2025-01-09 10:13 ` Tomas Glozar
` (2 more replies)
1 sibling, 3 replies; 14+ messages in thread
From: Sebastian Andrzej Siewior @ 2025-01-09 8:05 UTC (permalink / raw)
To: John Kacur
Cc: Kurt Kanzenbach, Clark Williams, Thomas Petazzoni, linux-rt-users
On 2025-01-08 13:21:19 [-0500], John Kacur wrote:
> We've been doing this for 15+ years. Normally I would expect the package
> creators to come-up with a work around and not expect the people offering
> the packages to accomdate your packaging software.
This does not mean it does not deserve to be fixed once people complain.
Debian and Fedora download the source package and host it themself so
they don't rely on upstream's copy of it. Other, such as buildroot or
Gentoo or even yocto download it on every request.
> How many kernels back to you need to keep? Could we come up with a
> compromise where we keep the newest kernel, plus say the last 3 in the
> rt-tests directory before they get moved to the older directory?
What I am asking is to either please keep all rt-tests releases in
https://www.kernel.org/pub/linux/utils/rt-tests/
but this would also mean that the older folder becomes removed and this
might upset more people.
Then there is the alternative especially if you prefer to have only the
latest release on top to please keep all releases in
https://www.kernel.org/pub/linux/utils/rt-tests/older/
even the current one. This does not sound annoying, does it? The latter
is what I do with RT patches while I release them after people
complained so I have the latest release in
https://www.kernel.org/pub/linux/kernel/projects/rt/$version/
and
https://www.kernel.org/pub/linux/kernel/projects/rt/$version/older/
> John
Sebastian
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: rt-tests release tarball location
2025-01-09 8:05 ` Sebastian Andrzej Siewior
@ 2025-01-09 10:13 ` Tomas Glozar
2025-01-09 10:49 ` Sebastian Andrzej Siewior
2025-01-09 12:04 ` Jörg Sommer
2025-01-10 16:46 ` John Kacur
2 siblings, 1 reply; 14+ messages in thread
From: Tomas Glozar @ 2025-01-09 10:13 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: John Kacur, Kurt Kanzenbach, Clark Williams, Thomas Petazzoni,
linux-rt-users
čt 9. 1. 2025 v 9:06 odesílatel Sebastian Andrzej Siewior
<bigeasy@linutronix.de> napsal:
>
> What I am asking is to either please keep all rt-tests releases in
> https://www.kernel.org/pub/linux/utils/rt-tests/
>
> but this would also mean that the older folder becomes removed and this
> might upset more people.
Can't we symlink the older directory to its parent, so that all
releases will be available under both
https://www.kernel.org/pub/linux/utils/rt-tests/ and
https://www.kernel.org/pub/linux/utils/rt-tests/older/? Yes, it's a
bit ugly, but it would ensure the downloads keep working for everyone.
> Then there is the alternative especially if you prefer to have only the
> latest release on top to please keep all releases in
> https://www.kernel.org/pub/linux/utils/rt-tests/older/
>
> even the current one. This does not sound annoying, does it? The latter
> is what I do with RT patches while I release them after people
> complained so I have the latest release in
> https://www.kernel.org/pub/linux/kernel/projects/rt/$version/
> and
> https://www.kernel.org/pub/linux/kernel/projects/rt/$version/older/
>
> > John
>
> Sebastian
>
Tomas
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: rt-tests release tarball location
2025-01-09 10:13 ` Tomas Glozar
@ 2025-01-09 10:49 ` Sebastian Andrzej Siewior
0 siblings, 0 replies; 14+ messages in thread
From: Sebastian Andrzej Siewior @ 2025-01-09 10:49 UTC (permalink / raw)
To: Tomas Glozar
Cc: John Kacur, Kurt Kanzenbach, Clark Williams, Thomas Petazzoni,
linux-rt-users
On 2025-01-09 11:13:50 [+0100], Tomas Glozar wrote:
> čt 9. 1. 2025 v 9:06 odesílatel Sebastian Andrzej Siewior
> <bigeasy@linutronix.de> napsal:
> >
> > What I am asking is to either please keep all rt-tests releases in
> > https://www.kernel.org/pub/linux/utils/rt-tests/
> >
> > but this would also mean that the older folder becomes removed and this
> > might upset more people.
>
> Can't we symlink the older directory to its parent, so that all
> releases will be available under both
> https://www.kernel.org/pub/linux/utils/rt-tests/ and
> https://www.kernel.org/pub/linux/utils/rt-tests/older/? Yes, it's a
> bit ugly, but it would ensure the downloads keep working for everyone.
kup supports a ln command so that would work, yes.
> Tomas
Sebastian
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: rt-tests release tarball location
2025-01-09 8:05 ` Sebastian Andrzej Siewior
2025-01-09 10:13 ` Tomas Glozar
@ 2025-01-09 12:04 ` Jörg Sommer
2025-01-10 16:46 ` John Kacur
2 siblings, 0 replies; 14+ messages in thread
From: Jörg Sommer @ 2025-01-09 12:04 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: John Kacur, Kurt Kanzenbach, Clark Williams, Thomas Petazzoni,
linux-rt-users
Sebastian Andrzej Siewior schrieb am Do 09. Jan, 09:05 (+0100):
> On 2025-01-08 13:21:19 [-0500], John Kacur wrote:
> > We've been doing this for 15+ years. Normally I would expect the package
> > creators to come-up with a work around and not expect the people offering
> > the packages to accomdate your packaging software.
>
> This does not mean it does not deserve to be fixed once people complain.
> Debian and Fedora download the source package and host it themself so
> they don't rely on upstream's copy of it. Other, such as buildroot or
> Gentoo or even yocto download it on every request.
For the record: Yocto uses the git repository (pinned by commit ID) to get
the source.
Regards, Jörg
--
“UNIX was not designed to stop people from doing stupid things, because
that would also stop them from doing clever things.”
(Doug Gwyn)
Navimatix GmbH T: 03641 - 327 99 0
Tatzendpromenade 2 F: 03641 - 526 306
07745 Jena www.navimatix.de
Geschäftsführer: Steffen Späthe, Jan Rommeley
Registergericht: Amtsgericht Jena, HRB 501480
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: rt-tests release tarball location
2025-01-09 8:05 ` Sebastian Andrzej Siewior
2025-01-09 10:13 ` Tomas Glozar
2025-01-09 12:04 ` Jörg Sommer
@ 2025-01-10 16:46 ` John Kacur
2025-08-13 21:06 ` Thomas Petazzoni
2 siblings, 1 reply; 14+ messages in thread
From: John Kacur @ 2025-01-10 16:46 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Kurt Kanzenbach, Clark Williams, Thomas Petazzoni, linux-rt-users
On Thu, 9 Jan 2025, Sebastian Andrzej Siewior wrote:
> On 2025-01-08 13:21:19 [-0500], John Kacur wrote:
> > We've been doing this for 15+ years. Normally I would expect the package
> > creators to come-up with a work around and not expect the people offering
> > the packages to accomdate your packaging software.
>
> This does not mean it does not deserve to be fixed once people complain.
> Debian and Fedora download the source package and host it themself so
> they don't rely on upstream's copy of it. Other, such as buildroot or
> Gentoo or even yocto download it on every request.
>
> > How many kernels back to you need to keep? Could we come up with a
> > compromise where we keep the newest kernel, plus say the last 3 in the
> > rt-tests directory before they get moved to the older directory?
>
> What I am asking is to either please keep all rt-tests releases in
> https://www.kernel.org/pub/linux/utils/rt-tests/
>
> but this would also mean that the older folder becomes removed and this
> might upset more people.
> Then there is the alternative especially if you prefer to have only the
> latest release on top to please keep all releases in
> https://www.kernel.org/pub/linux/utils/rt-tests/older/
>
> even the current one. This does not sound annoying, does it? The latter
> is what I do with RT patches while I release them after people
This option seems the least disruptive from my point of view.
I am now keeping all versions including the current version in
/pub/linux/utils/rt-tests/older
Thanks
John
> complained so I have the latest release in
> https://www.kernel.org/pub/linux/kernel/projects/rt/$version/
> and
> https://www.kernel.org/pub/linux/kernel/projects/rt/$version/older/
>
> > John
>
> Sebastian
>
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: rt-tests release tarball location
2025-01-10 16:46 ` John Kacur
@ 2025-08-13 21:06 ` Thomas Petazzoni
2025-08-18 19:18 ` John Kacur
0 siblings, 1 reply; 14+ messages in thread
From: Thomas Petazzoni @ 2025-08-13 21:06 UTC (permalink / raw)
To: John Kacur
Cc: Sebastian Andrzej Siewior, Kurt Kanzenbach, Clark Williams,
linux-rt-users
Hello John,
On Fri, 10 Jan 2025 11:46:01 -0500 (EST)
John Kacur <jkacur@redhat.com> wrote:
> This option seems the least disruptive from my point of view.
> I am now keeping all versions including the current version in
> /pub/linux/utils/rt-tests/older
I am getting back to you on this, because the latest version is not in
the /older/ subfolder, i.e the 2.9 version is not in the older/ folder.
Would it be possible to place it here, so that its URL is stable
over time?
Thanks a lot!
Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: rt-tests release tarball location
2025-08-13 21:06 ` Thomas Petazzoni
@ 2025-08-18 19:18 ` John Kacur
2025-08-18 19:24 ` Thomas Petazzoni
0 siblings, 1 reply; 14+ messages in thread
From: John Kacur @ 2025-08-18 19:18 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Sebastian Andrzej Siewior, Kurt Kanzenbach, Clark Williams,
linux-rt-users
On Wed, 13 Aug 2025, Thomas Petazzoni wrote:
> Hello John,
>
> On Fri, 10 Jan 2025 11:46:01 -0500 (EST)
> John Kacur <jkacur@redhat.com> wrote:
>
> > This option seems the least disruptive from my point of view.
> > I am now keeping all versions including the current version in
> > /pub/linux/utils/rt-tests/older
>
> I am getting back to you on this, because the latest version is not in
> the /older/ subfolder, i.e the 2.9 version is not in the older/ folder.
>
> Would it be possible to place it here, so that its URL is stable
> over time?
>
> Thanks a lot!
>
> Thomas
> --
Done. Updating my scripts too.
John Kacur
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: rt-tests release tarball location
2025-08-18 19:18 ` John Kacur
@ 2025-08-18 19:24 ` Thomas Petazzoni
0 siblings, 0 replies; 14+ messages in thread
From: Thomas Petazzoni @ 2025-08-18 19:24 UTC (permalink / raw)
To: John Kacur
Cc: Sebastian Andrzej Siewior, Kurt Kanzenbach, Clark Williams,
linux-rt-users
On Mon, 18 Aug 2025 15:18:26 -0400 (EDT)
John Kacur <jkacur@redhat.com> wrote:
> Done. Updating my scripts too.
Thanks a lot, much appreciated!
Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2025-08-18 19:35 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-12-28 10:43 rt-tests release tarball location Thomas Petazzoni
2025-01-07 9:41 ` Kurt Kanzenbach
2025-01-07 14:14 ` Sebastian Andrzej Siewior
2025-01-08 18:21 ` John Kacur
2025-01-08 19:05 ` Crystal Wood
2025-01-09 8:05 ` Sebastian Andrzej Siewior
2025-01-09 10:13 ` Tomas Glozar
2025-01-09 10:49 ` Sebastian Andrzej Siewior
2025-01-09 12:04 ` Jörg Sommer
2025-01-10 16:46 ` John Kacur
2025-08-13 21:06 ` Thomas Petazzoni
2025-08-18 19:18 ` John Kacur
2025-08-18 19:24 ` Thomas Petazzoni
2025-01-08 18:17 ` John Kacur
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox