rt-tests release tarball location
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
Signature · 3 lines
Thomas Petazzoni, co-owner and CEO, Bootlin Embedded Linux and Kernel engineering and training https://bootlin.com
Quoted 11 lines · Thomas Petazzoni
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/.
Quoted 8 lines
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
+John, +Clark
Quoted 12 lines · Kurt Kanzenbach
Quoted 11 lines · Thomas Petazzoni
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/.
Quoted 8 lines
Quoted 8 lines
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?
Quoted 8 lines
+1
For Gentoo I had to add both URLs to
SRC_URIin the ebuilds. It first tries rt-tests/ and then rt-tests/older/ location, which is also not ideal.Thanks,
Kurt
Sebastian
Quoted 18 lines · Sebastian Andrzej Siewior
+John, +Clark
Quoted 16 lines · Kurt Kanzenbach
Quoted 15 lines · Thomas Petazzoni
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.
Quoted 7 lines
Quoted 4 lines
Quoted 4 lines
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
Quoted 26 lines · John Kacur
Quoted 23 lines · Sebastian Andrzej Siewior
+John, +Clark
Quoted 20 lines · Kurt Kanzenbach
Quoted 19 lines · Thomas Petazzoni
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?
Quoted 6 lines
Quoted 2 lines
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?
Quoted 4 lines
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
Quoted 3 lines · John Kacur
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.
Quoted 3 lines
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/
Quoted 1 line
John
Sebastian
čt 9. 1. 2025 v 9:06 odesílatel Sebastian Andrzej Siewior <[email protected]> napsal:
Quoted 6 lines
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.
Quoted 11 lines
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/
Quoted 4 lines
Quoted 1 line
John
Sebastian
Tomas
Quoted 6 lines · Tomas Glozar
čt 9. 1. 2025 v 9:06 odesílatel Sebastian Andrzej Siewior <[email protected]> napsal:
Quoted 4 lines
What I am asking is to either please keep all rt-tests releases in
https://www.kernel.org/pub/linux/utils/rt-tests/
Quoted 8 lines
Quoted 2 lines
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.
Quoted 1 line
Tomas
Sebastian
Sebastian Andrzej Siewior schrieb am Do 09. Jan, 09:05 (+0100):
Quoted 9 lines · John Kacur
Quoted 3 lines
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
Signature · 10 lines
“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 501480Quoted 17 lines · Sebastian Andrzej Siewior
Quoted 3 lines · John Kacur
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.
Quoted 3 lines
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/
Quoted 8 lines
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
Quoted 10 lines
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/Quoted 1 line
John
Sebastian
Hello John,
Quoted 3 lines · On Fri, 10 Jan 2025 11:46:01 -0500 (EST) John Kacur <[email protected]> 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
Signature · 3 lines
Thomas Petazzoni, co-owner and CEO, Bootlin Embedded Linux and Kernel engineering and training https://bootlin.com
Quoted 12 lines · Thomas Petazzoni
Hello John,
Quoted 3 lines · On Fri, 10 Jan 2025 11:46:01 -0500 (EST) John Kacur <[email protected]> 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.
Quoted 7 lines
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
Quoted 1 line · On Mon, 18 Aug 2025 15:18:26 -0400 (EDT) John Kacur <[email protected]> wrote:
Done. Updating my scripts too.
Thanks a lot, much appreciated!
Thomas
Signature · 3 lines
Thomas Petazzoni, co-owner and CEO, Bootlin Embedded Linux and Kernel engineering and training https://bootlin.com
Quoted 21 lines · Kurt Kanzenbach
Quoted 11 lines · Thomas Petazzoni
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/.Quoted 8 lines
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?
Quoted 5 lines
+1
For Gentoo I had to add both URLs to
SRC_URIin 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