[arch-general] Kernel source URL change
Hi, Recently the way kernel sources are retrieved was changed in the linux package [1]. Now the sources are fetched from https://github.com/archlinux/linux. I see a few problems with this: - Previously the list of applied patches was very transparent. You could immediately see that the kernel and kernel patch tarballs come from kernel.org, and view individual extra patches. Now the code comes from a non-kernel source, and cannot be verified as easily. - Previously, if a new kernel version is released and is not yet in the repos, you could more or less take the official linux PKGBUILD, change one number and build it yourself. With the new layout it is not clear how to achieve this. - An often cited Arch policy is to use software as released by upstream with minimal patching. What becomes of this policy if one of the core packages builds from a technical fork instead of upstream? If the patches from kernel.org will no longer be signed, as announced in [2], then an alternative would be git tags from [3] and [4]. It's understandable if it may make development harder, nonetheless it would allow for better transparency and follow upstream closer — just one user's opinion. [1] https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/linux&id=d0c4ab0716e0ae1fc058a83ccb02bde92885ced6 [2] https://www.kernel.org/minor-changes-to-tarball-release-format.html [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ [4] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git -- Regards, Andrey
On 08/01, Andrey Vihrov via arch-general wrote:
- Previously the list of applied patches was very transparent. You could immediately see that the kernel and kernel patch tarballs come from kernel.org, and view individual extra patches. Now the code comes from a non-kernel source, and cannot be verified as easily.
Just run `git log v$_srcver`. That will show you all the patches that have been applied to the upstream release. That the sources do no longer come from kernel.org is irrelevant, you should _always_ verify the gpg signature for auditing purposes.
- Previously, if a new kernel version is released and is not yet in the repos, you could more or less take the official linux PKGBUILD, change one number and build it yourself. With the new layout it is not clear how to achieve this.
git-rebase(1) will accomplish that.
- An often cited Arch policy is to use software as released by upstream with minimal patching. What becomes of this policy if one of the core packages builds from a technical fork instead of upstream?
Nobody forked the linux kernel, and no new patches have been added. The resulting package is exactly the same, so nothing changed in that regard. Regards, Tharre -- PGP fingerprint: 42CE 7698 D6A0 6129 AA16 EF5C 5431 BDE2 C8F0 B2F4
On 01/08/18, Andrey Vihrov via arch-general wrote:
Hi,
Recently the way kernel sources are retrieved was changed in the linux package [1]. Now the sources are fetched from https://github.com/archlinux/linux.
I see a few problems with this:
- Previously the list of applied patches was very transparent. You could immediately see that the kernel and kernel patch tarballs come from kernel.org, and view individual extra patches. Now the code comes from a non-kernel source, and cannot be verified as easily.
- Previously, if a new kernel version is released and is not yet in the repos, you could more or less take the official linux PKGBUILD, change one number and build it yourself. With the new layout it is not clear how to achieve this.
- An often cited Arch policy is to use software as released by upstream with minimal patching. What becomes of this policy if one of the core packages builds from a technical fork instead of upstream?
If the patches from kernel.org will no longer be signed, as announced in [2], then an alternative would be git tags from [3] and [4]. It's understandable if it may make development harder, nonetheless it would allow for better transparency and follow upstream closer — just one user's opinion.
[1] https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/linux&id=d0c4ab0716e0ae1fc058a83ccb02bde92885ced6 [2] https://www.kernel.org/minor-changes-to-tarball-release-format.html [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ [4] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
-- Regards, Andrey
Also now to build the package locally you download the whole repository (~2 Gb compared to the ~110 Mb previously). What's the reasoning behind this change? Regards, -- Leonidas Spyropoulos A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
The size problem can be solved using hollow clone. Regards. On Thu, 2 Aug 2018, 07:28 Leonidas Spyropoulos via arch-general, < arch-general@archlinux.org> wrote:
On 01/08/18, Andrey Vihrov via arch-general wrote:
Hi,
Recently the way kernel sources are retrieved was changed in the linux package [1]. Now the sources are fetched from https://github.com/archlinux/linux.
I see a few problems with this:
- Previously the list of applied patches was very transparent. You could immediately see that the kernel and kernel patch tarballs come from kernel.org, and view individual extra patches. Now the code comes from a non-kernel source, and cannot be verified as easily.
- Previously, if a new kernel version is released and is not yet in the repos, you could more or less take the official linux PKGBUILD, change one number and build it yourself. With the new layout it is not clear how to achieve this.
- An often cited Arch policy is to use software as released by upstream with minimal patching. What becomes of this policy if one of the core packages builds from a technical fork instead of upstream?
If the patches from kernel.org will no longer be signed, as announced in [2], then an alternative would be git tags from [3] and [4]. It's understandable if it may make development harder, nonetheless it would allow for better transparency and follow upstream closer — just one user's opinion.
[1]
[2] https://www.kernel.org/minor-changes-to-tarball-release-format.html [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ [4] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
-- Regards, Andrey
Also now to build the package locally you download the whole repository (~2 Gb compared to the ~110 Mb previously).
What's the reasoning behind this change?
Regards,
-- Leonidas Spyropoulos
A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
On Thu, 2 Aug 2018, at 09:11, Joan Aymà via arch-general wrote:
The size problem can be solved using hollow clone.
Not in a well-formed PKGBUILD. There's ample discussion on this topic available. Of course you're welcome to hack together whatever you want.
Also now to build the package locally you download the whole repository (~2 Gb compared to the ~110 Mb previously).
Oh... Cloning into bare repository '/tmp/4.17-arch/archlinux-linux'... remote: Counting objects: 6135977, done. remote: Compressing objects: 100% (1099/1099), done. remote: Total 6135977 (delta 984), reused 385 (delta 385), pack-reused 6134493 Receiving objects: 100% (6135977/6135977), 2.07 GiB | 1.03 MiB/s, done. Resolving deltas: 100% (5111928/5111928), done. 33 minutes to fetch kernel. If this changeset is good for arch infrastructure builds, may be tar.xz will be also provided, via github releases for example. k
Now we know that the change is a solution in search of a problem.
The fact that they won't sign the patch tarballs anymore isn't a problem.
All that heftig must do, is to make it download the complete tarball and its signature.
Here you go:
https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.17.13.tar.xz
https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.17.13.tar.sign
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On August 7, 2018 8:31 AM, Konstantin Shalygin via arch-general
Also now to build the package locally you download the whole repository (~2 Gb compared to the ~110 Mb previously).
Oh...
Cloning into bare repository '/tmp/4.17-arch/archlinux-linux'... remote: Counting objects: 6135977, done. remote: Compressing objects: 100% (1099/1099), done. remote: Total 6135977 (delta 984), reused 385 (delta 385), pack-reused 6134493 Receiving objects: 100% (6135977/6135977), 2.07 GiB | 1.03 MiB/s, done. Resolving deltas: 100% (5111928/5111928), done.
33 minutes to fetch kernel.
If this changeset is good for arch infrastructure builds, may be tar.xz will be also provided, via github releases for example.
k
On 08/07/2018 07:31 PM, W B via arch-general wrote:
Now we know that the change is a solution in search of a problem.
The fact that they won't sign the patch tarballs anymore isn't a problem.
All that heftig must do, is to make it download the complete tarball and its signature.
Here you go: https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.17.13.tar.xz https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.17.13.tar.sign
We do not listen to your orders. -- Eli Schwartz Bug Wrangler and Trusted User
It isn't an order.
Can you tell us why this change was required, please?
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On August 8, 2018 3:11 AM, Eli Schwartz via arch-general
On 08/07/2018 07:31 PM, W B via arch-general wrote:
Now we know that the change is a solution in search of a problem. The fact that they won't sign the patch tarballs anymore isn't a problem. All that heftig must do, is to make it download the complete tarball and its signature. Here you go: https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.17.13.tar.xz https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.17.13.tar.sign
We do not listen to your orders.
-----------------------------------
Eli Schwartz Bug Wrangler and Trusted User
On 08/07/2018 10:31 PM, W B via arch-general wrote:
It isn't an order.
Can you tell us why this change was required, please?
Because heftig decided it was easier *for him* to do it this way. Because downloading 100 MB for every single patchlevel release quickly builds up to just as much as a full git clone. Can you tell us why you believe the move to git was "a solution in search of a problem"? Can you tell us why you replied to this list with the message that there are full tarballs, as though you think heftig did not know this and reject this already? Who are you trying to convince here? -- Eli Schwartz Bug Wrangler and Trusted User
On Tue, 7 Aug 2018 22:55:55 -0400
Eli Schwartz via arch-general
Because heftig decided it was easier *for him* to do it this way.
Because downloading 100 MB for every single patchlevel release quickly builds up to just as much as a full git clone.
Can you tell us why you believe the move to git was "a solution in search of a problem"?
I wonder if this isn't going to complicate my life maintaining the linux-rt kernel on AUR. So far I've tried to track the linux package closely, but I wonder what repercussions it will have. Many times it's also out of sync with the main distro kernel, but I always used to pick up the patches etc used by the main kernel. Oh well, nor really a complaint, let's see how it works out in practice. -- Joakim
participants (9)
-
Andrey Vihrov
-
Eli Schwartz
-
Jens John
-
Joakim Hernberg
-
Joan Aymà
-
Konstantin Shalygin
-
Leonidas Spyropoulos
-
Tharre
-
W B