* 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 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
* 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
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