Hi,
i just wonder not seeing all src rpms for c6?
http://mirror.centos.org/centos-6/6.0/os/SRPMS/Packages/
like for c4 & c5:
http://mirror.centos.org/centos-4/4.9/os/SRPMS/ http://mirror.centos.org/centos-5/5.6/os/SRPMS/
Do i miss something (i was in holidays)?
Thanks PM
On 08/09/2011 09:34 PM, Leon Fauster wrote:
Hi,
i just wonder not seeing all src rpms for c6?
It seems only the rebranded SRPMs are available, all SRPMs that are rebuilt unchanged from the upstream vendor are missing. I don't know if this is on purpose or not.
Regards, Xavier
Xavier Bachelot wrote:
On 08/09/2011 09:34 PM, Leon Fauster wrote:
Hi,
i just wonder not seeing all src rpms for c6?
It seems only the rebranded SRPMs are available, all SRPMs that are rebuilt unchanged from the upstream vendor are missing. I don't know if this is on purpose or not.
I think they were supposed to be uploaded once the ISO download and yum upgrade waves lessen the pressure on the mirrors, and then they were forgotten due to the 6.1 rebuild effort.
On Wed, 10 Aug 2011, Xavier Bachelot wrote:
On 08/09/2011 09:34 PM, Leon Fauster wrote:
Hi,
i just wonder not seeing all src rpms for c6?
It seems only the rebranded SRPMs are available, all SRPMs that are rebuilt unchanged from the upstream vendor are missing. I don't know if this is on purpose or not.
Relying on the upstream vendor's distribution of the unmodified SRPMS isn't sufficient to comply with the GPL. Probably wasn't deliberate, but if it was, it was a mis-judgement.
--- Charlie
On 08/10/2011 03:43 PM, Charlie Brady wrote:
Relying on the upstream vendor's distribution of the unmodified SRPMS isn't sufficient to comply with the GPL. Probably wasn't deliberate, but if it was, it was a mis-judgement.
That isnt the strategy!
srpms will start showing up in a few hours time, and should be complete in the next 48 hrs ( onto mirror.c.o - local mirrors might take a bit more time ). I'll also try and squeeze out the debuginfo's before we start seeding 6.1 and 5.7
- KB
Am 11.08.2011 um 12:58 schrieb Karanbir Singh:
On 08/10/2011 03:43 PM, Charlie Brady wrote:
Relying on the upstream vendor's distribution of the unmodified SRPMS isn't sufficient to comply with the GPL. Probably wasn't deliberate, but if it was, it was a mis-judgement.
That isnt the strategy!
srpms will start showing up in a few hours time, and should be complete in the next 48 hrs ( onto mirror.c.o - local mirrors might take a bit more time ).
thank you to clarify.
I'll also try and squeeze out the debuginfo's before we start seeding 6.1 and 5.7
aside - i am not sure anymore, where the place is to track the current 5.7 progress (if there is any place right now - i remember that they are plans to open it, right?)
i looked @
https://nazar.karan.org/cgit/ http://qaweb.dev.centos.org/qa/ http://planet.centos.org/
i appreciate any hints
LM
On 8/11/2011 6:58 AM, Karanbir Singh wrote:
On 08/10/2011 03:43 PM, Charlie Brady wrote:
Relying on the upstream vendor's distribution of the unmodified SRPMS isn't sufficient to comply with the GPL. Probably wasn't deliberate, but if it was, it was a mis-judgement.
That isnt the strategy!
srpms will start showing up in a few hours time, and should be complete in the next 48 hrs ( onto mirror.c.o - local mirrors might take a bit more time ). I'll also try and squeeze out the debuginfo's before we start seeding 6.1 and 5.7
- KB
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
I know your busy, but, any word on the debuginfo packages?
Fred Wittekind
Hi,
On 08/17/2011 06:14 PM, Fred Wittekind wrote:
I know your busy, but, any word on the debuginfo packages?
we are changing the entire debuginfo infra around on its head, the resources we have in place now are clearly not adequate for the amount of data that needs to be on there.
the plan is to convert one of our machines at OSUOSL into a debug and vault machine, and setup mirrors from there in the US and EU ( it might only be 1 machine in each location for now, not many of our machines have > 1TiB of disk space needed for this content now ).
Thats not much in terms of news, but you know what is going on at this time. ETA, give it another 4 - 5 days. the configs are all in, puppet knows what to do, its now just a case of sitting it out waiting for the data to relocate itself. And then flipping dns
- KB
Hello.
http://mirror.centos.org/centos-6/6.0/cr/i386/RPMS/ has packages but http://mirror.centos.org/centos-6/6.0/cr/SRPMS/Packages/ remains empty.
What is cr/SRPMS/ directory for?
http://mirror.centos.org/centos-6/6.0/cr/i386/RPMS/ has packages but http://mirror.centos.org/centos-6/6.0/cr/SRPMS/Packages/ remains empty.
/join :)
Please, put at least some SRPMS here :) Most interesting are net-base: kernel, iptables, tc, ifconfig, ppp, rp-pppoe and all such - people are updating their patches for 6.1 out there (I'm among them) and it may be nice to have sources to know what awaits us.
Thanks.
On 10/21/2011 05:38 PM, Alexey Asemov (Alex/AT) wrote:
http://mirror.centos.org/centos-6/6.0/cr/i386/RPMS/ has packages but http://mirror.centos.org/centos-6/6.0/cr/SRPMS/Packages/ remains empty.
/join :)
Please, put at least some SRPMS here :) Most interesting are net-base: kernel, iptables, tc, ifconfig, ppp, rp-pppoe and all such - people are updating their patches for 6.1 out there (I'm among them) and it may be nice to have sources to know what awaits us.
except for the packages which must be modified by CentOS (and therefore must be patched before building ), all sources are available on ftp.redhat.com.
Manuel Wolfshant wrote:
On 10/21/2011 05:38 PM, Alexey Asemov (Alex/AT) wrote:
http://mirror.centos.org/centos-6/6.0/cr/i386/RPMS/ has packages but http://mirror.centos.org/centos-6/6.0/cr/SRPMS/Packages/ remains empty.
/join :)
Please, put at least some SRPMS here :) Most interesting are net-base: kernel, iptables, tc, ifconfig, ppp, rp-pppoe and all such - people are updating their patches for 6.1 out there (I'm among them) and it may be nice to have sources to know what awaits us.
I'm waiting for kernel-2.6.32-131.17.1.el6.src.rpm .
except for the packages which must be modified by CentOS (and therefore must be patched before building ), all sources are available on ftp.redhat.com.
Was i386/RPMS/kernel-2.6.32-131.17.1.el6.i686.rpm made by simply doing
wget http://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/kernel... rpmbuild --rebuild kernel-2.6.32-131.17.1.el6.src.rpm
? Regarding kernel-2.6.32-71.29.1.el6.src.rpm , there was a small difference in the spec file and dynamically generated files.
--- kernel-rh.spec +++ kernel-centos.spec @@ -947,3 +947,3 @@ fi -gpg --homedir . --export --keyring ./kernel.pub Red > extract.pub +gpg --homedir . --export --keyring ./kernel.pub CentOS > extract.pub gcc -o scripts/bin2c scripts/bin2c.c @@ -1656,2 +1656,5 @@ %changelog +* Mon Jun 27 2011 Karanbir Singh kbsingh@centos.org [2.6.32-71.29.1.el6.centos] +- Roll in CentOS Branding + * Thu Apr 21 2011 Frantisek Hrbata fhrbata@redhat.com [2.6.32-71.29.1.el6]
linux-2.6.32-71.29.1.el6.i686/.config | 2 linux-2.6.32-71.29.1.el6.i686/configs/kernel-2.6.32-i686-debug.config | 2 linux-2.6.32-71.29.1.el6.i686/configs/kernel-2.6.32-i686.config | 2 linux-2.6.32-71.29.1.el6.i686/crypto/signature/key.h | 109 +++------- linux-2.6.32-71.29.1.el6.i686/extract.pub |binary linux-2.6.32-71.29.1.el6.i686/kernel.pub |binary linux-2.6.32-71.29.1.el6.i686/kernel.pub~ |binary linux-2.6.32-71.29.1.el6.i686/kernel.sec |binary linux-2.6.32-71.29.1.el6.i686/random_seed |binary vanilla-2.6.32-71.29.1.el6/crypto/signature/key.h | 109 +++------- vanilla-2.6.32-71.29.1.el6/extract.pub |binary vanilla-2.6.32-71.29.1.el6/kernel.pub |binary vanilla-2.6.32-71.29.1.el6/kernel.sec |binary vanilla-2.6.32-71.29.1.el6/random_seed |binary 14 files changed, 75 insertions(+), 149 deletions(-)
On Tue, Oct 25, 2011 at 1:53 AM, Tetsuo Handa from-centos@i-love.sakura.ne.jp wrote:
except for the packages which must be modified by CentOS (and therefore must be patched before building ), all sources are available on ftp.redhat.com.
Was i386/RPMS/kernel-2.6.32-131.17.1.el6.i686.rpm made by simply doing
wget http://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/kernel... rpmbuild --rebuild kernel-2.6.32-131.17.1.el6.src.rpm
You will get stock RHEL kernel by doing that. Anyways, why do you need exactly centos kernel? As you can see below -- it's just stock RHEL one but with some slight changes which doesn't affect functionality.
--- kernel-rh.spec +++ kernel-centos.spec +* Mon Jun 27 2011 Karanbir Singh kbsingh@centos.org [2.6.32-71.29.1.el6.centos] +- Roll in CentOS Branding
Ilya A. Otyutskiy wrote:
You will get stock RHEL kernel by doing that. Anyways, why do you need exactly centos kernel? As you can see below -- it's just stock RHEL one but with some slight changes which doesn't affect functionality.
Just wanted to rebuild with TOMOYO enabled. To do so, I wanted to know what modification is required for reusing upstream packages.
Akemi Yagi wrote:
In addition to the above, one line in the genkey file is modified by CentOS:
Name-Real: CentOS
Thanks Akemi. So, roughly speaking centos's kernel srpm is made with
sed -i -e 's@--keyring ./kernel.pub Red@--keyring ./kernel.pub CentOS@' -- SPECS/kernel.spec sed -i -e 's@Red Hat, Inc.@CentOS@' -- SOURCES/genkey
.
Karanbir Singh wrote:
We have enough ( but barely enough ) space on the mirrors for 6.0/cr/SRPMS; however that would then mean that we no longer have enough space to get 6.1 on there.
I see. The reason the directory remains empty is to save disk space.
So just to keep with the theme of things, what is the feeling if I were :
- to drop the CR/SRPMS into vault.c.o
- add a .repo stanza into the centos-release-cr rpm with a [sources]
pointing to the right place
I'm fine with that approach.
Thanks.
On 10/25/2011 01:18 PM, Tetsuo Handa wrote:
I see. The reason the directory remains empty is to save disk space.
The issue is a bit wider than that, but in effect its a case of keeping mirror size down.
So just to keep with the theme of things, what is the feeling if I were :
- to drop the CR/SRPMS into vault.c.o
- add a .repo stanza into the centos-release-cr rpm with a [sources]
pointing to the right place
I'm fine with that approach.
I'll work on getting this done for later today; it might be a while before the srpms show up ( give it a day or two ).
- KB
So just to keep with the theme of things, what is the
feeling if I were :
- to drop the CR/SRPMS into vault.c.o
- add a .repo stanza into the centos-release-cr rpm with a
[sources]
pointing to the right place
I'm fine with that approach.
I'll work on getting this done for later today; it might be a while before the srpms show up ( give it a day or two ).
Hi all, any news about this?
On 11/29/2011 09:24 AM, centos1@iotti.biz wrote:
So just to keep with the theme of things, what is the
feeling if I were :
- to drop the CR/SRPMS into vault.c.o
- add a .repo stanza into the centos-release-cr rpm with a
[sources]
pointing to the right place
I'm fine with that approach.
I'll work on getting this done for later today; it might be a while before the srpms show up ( give it a day or two ).
Hi all, any news about this?
There are some here:
http://vault.centos.org/6.0/cr/SRPMS/Packages/
The rest will have to wait until we release 6.1 ... we are trying to get this done.
On 10/25/2011 01:18 PM, Tetsuo Handa wrote:
Just wanted to rebuild with TOMOYO enabled. To do so, I wanted to know what modification is required for reusing upstream packages.
It would be great to have that in the CentOS Plus kernel
- KB
Karanbir Singh wrote:
On 10/25/2011 01:18 PM, Tetsuo Handa wrote:
Just wanted to rebuild with TOMOYO enabled. To do so, I wanted to know what modification is required for reusing upstream packages.
It would be great to have that in the CentOS Plus kernel
I'd like to. But enabling TOMOYO (i.e. changing to CONFIG_SECURITY_PATH=y) triggers changes in "struct security_operations" that results in kernel ABI changes. If I recall correctly, CentOS Plus kernel does not accept kernel config changes that changes kernel ABI.
On Tue, Oct 25, 2011 at 2:42 PM, Tetsuo Handa from-centos@i-love.sakura.ne.jp wrote:
Karanbir Singh wrote:
On 10/25/2011 01:18 PM, Tetsuo Handa wrote:
Just wanted to rebuild with TOMOYO enabled. To do so, I wanted to know what modification is required for reusing upstream packages.
It would be great to have that in the CentOS Plus kernel
I'd like to. But enabling TOMOYO (i.e. changing to CONFIG_SECURITY_PATH=y) triggers changes in "struct security_operations" that results in kernel ABI changes. If I recall correctly, CentOS Plus kernel does not accept kernel config changes that changes kernel ABI.
Yes, that is correct. Anything that causes kABI incompatibility cannot be implemented in the cplus kernel.
Akemi
On 10/25/2011 10:42 PM, Tetsuo Handa wrote:
It would be great to have that in the CentOS Plus kernel
I'd like to. But enabling TOMOYO (i.e. changing to CONFIG_SECURITY_PATH=y) triggers changes in "struct security_operations" that results in kernel ABI changes. If I recall correctly, CentOS Plus kernel does not accept kernel config changes that changes kernel ABI.
so, lets make room for a kernel-<ver>-<rel>.tomoyo perhaps. Is that config option the only real change needed ?
Over a period of time, how are RH patches likely to impact this ?
- KB
Karanbir Singh wrote:
so, lets make room for a kernel-<ver>-<rel>.tomoyo perhaps. Is that config option the only real change needed ?
Thanks. CONFIG_SECURITY_PATH=y and CONFIG_SECURITY_TOMOYO=y are needed.
Over a period of time, how are RH patches likely to impact this ?
Distributor's patches unlikely break CONFIG_SECURITY_TOMOYO because TOMOYO 2.x is in-tree. However, RH heavily backports features from later kernels to RHEL. I guess RH would backport RCU path walk patchset (which breaks TOMOYO 2.2) to RHEL 6. If such backport happens, kernel-<ver>-<rel>.tomoyo can no longer be provided without kernel patches.
TOMOYO 2.x is already enabled in Ubuntu, Debian, openSUSE etc. But RH would be the last distribution that enables TOMOYO because RH drives SELinux. I proposed TOMOYO 2.x for Fedora but was rejected.
I'm providing 2 alternatives. One is TOMOYO 1.x (out of tree patches that require recompilation of kernel source package but can keep kernel ABI) and the other is AKARI (subset of TOMOYO 1.x but is a loadable kernel module). http://akari.sourceforge.jp/comparison.html
Given above circumstances/risks, do we think we should make room for a kernel-<ver>-<rel>.tomoyo ?
On Wed, Oct 26, 2011 at 6:51 AM, Tetsuo Handa from-centos@i-love.sakura.ne.jp wrote:
I'm providing 2 alternatives. One is TOMOYO 1.x (out of tree patches that require recompilation of kernel source package but can keep kernel ABI) and the other is AKARI (subset of TOMOYO 1.x but is a loadable kernel module). http://akari.sourceforge.jp/comparison.html
I checked the config options required for AKARI. Of the 5 options listed, one is not set in the current EL6 kernel:
# CONFIG_SECURITY_PATH is not set
You mentioned CONFIG_SECURITY_PATH is the one that breaks the kABI. But TOMOYO 1.x would not?
Akemi
Akemi Yagi wrote:
I'm providing 2 alternatives. One is TOMOYO 1.x (out of tree patches that require recompilation of kernel source package but can keep kernel ABI) and the other is AKARI (subset of TOMOYO 1.x but is a loadable kernel module). http://akari.sourceforge.jp/comparison.html
I checked the config options required for AKARI. Of the 5 options listed, one is not set in the current EL6 kernel:
# CONFIG_SECURITY_PATH is not set
You mentioned CONFIG_SECURITY_PATH is the one that breaks the kABI.
CONFIG_SECURITY_PATH is the one that is mandatory for TOMOYO 2.x but breaks the kABI. But CONFIG_SECURITY_PATH is optional for AKARI. AKARI was designed to be usable on RHEL kernels without changing kernel config or patching to source.
But TOMOYO 1.x would not?
TOMOYO 1.x does not need CONFIG_SECURITY_PATH because TOMOYO 1.x adds a new set of hooks similar to CONFIG_SECURITY_PATH. Thus, the kABI is preserved but TOMOYO 1.x needs patching to source.
On Wed, Oct 26, 2011 at 2:49 PM, Tetsuo Handa from-centos@i-love.sakura.ne.jp wrote:
Akemi Yagi wrote:
I'm providing 2 alternatives. One is TOMOYO 1.x (out of tree patches that require recompilation of kernel source package but can keep kernel ABI) and the other is AKARI (subset of TOMOYO 1.x but is a loadable kernel module). http://akari.sourceforge.jp/comparison.html
I checked the config options required for AKARI. Of the 5 options listed, one is not set in the current EL6 kernel:
# CONFIG_SECURITY_PATH is not set
You mentioned CONFIG_SECURITY_PATH is the one that breaks the kABI.
CONFIG_SECURITY_PATH is the one that is mandatory for TOMOYO 2.x but breaks the kABI. But CONFIG_SECURITY_PATH is optional for AKARI. AKARI was designed to be usable on RHEL kernels without changing kernel config or patching to source.
I see. Then the AKARI kernel module will be a good (perfect?) candidate for ELRepo.
But TOMOYO 1.x would not?
TOMOYO 1.x does not need CONFIG_SECURITY_PATH because TOMOYO 1.x adds a new set of hooks similar to CONFIG_SECURITY_PATH. Thus, the kABI is preserved but TOMOYO 1.x needs patching to source.
In this case, the cplus kernel can accommodate TOMOYO 1.x. Can you think of any reason it cannot? Anything else to consider?
On a not so important subject, is TOMOYO written as 友代, and AKARI as 明 ? 灯り ?
Akemi
Tetsuo Handa wrote:
CONFIG_SECURITY_PATH is the one that is mandatory for TOMOYO 2.x but breaks the kABI.
My apologies. I was misunderstanding. I was assuming that making changes in "struct security_operations" breaks the kABI. But it seems it does not.
I've just rebuilt kernel-2.6.32-131.17.1.el6.i686.rpm with TOMOYO 1.x/2.x. rpmbuild with kabi checks enabled did not fail.
The only difference in symvers-2.6.32-131.12.1.el6.i686.gz between stock CentOS's kernel and CentOS + TOMOYO 1.8 kernel was
+ 0x0b6d773e ccsecurity_ops vmlinux EXPORT_SYMBOL
. The only difference in symvers-2.6.32-131.12.1.el6.i686.gz between stock CentOS's kernel and CentOS + TOMOYO 2.2 (CONFIG_SECURITY_PATH=y + CONFIG_SECURITY_TOMOYO=y) kernel was
+ 0xfc4d6f3e security_path_mknod vmlinux EXPORT_SYMBOL
. TOMOYO added one new symbol but didn't change existing symbols.
Akemi Yagi wrote:
In this case, the cplus kernel can accommodate TOMOYO 1.x. Can you think of any reason it cannot? Anything else to consider?
Does the cplus kernel accept source code not within RHEL's kernel SRPM? I thought the cplus kenrel does not. If it doesn't, TOMOYO 2.2 is OK for now but will require build fix patch when RCU path walk patchset is backported.
On a not so important subject, is TOMOYO written as 友代, and AKARI as 明 ? 灯り ?
TOMOYO is 知世 from Card Captor Sakura, AKARI is 灯里 from ARIA.
On 10/27/2011 04:57 AM, Tetsuo Handa wrote:
My apologies. I was misunderstanding. I was assuming that making changes in "struct security_operations" breaks the kABI. But it seems it does not.
excellent, lets do it then.
Does the cplus kernel accept source code not within RHEL's kernel SRPM?
yes, the patches and driver updates are from outside ( in some cases backports of potentially next-release stuff from upstream ).
so, is it just a case of getting a work-flow in place and trialling the process ?
- KB
Karanbir Singh wrote:
On 10/27/2011 04:57 AM, Tetsuo Handa wrote:
My apologies. I was misunderstanding. I was assuming that making changes in "struct security_operations" breaks the kABI. But it seems it does not.
excellent, lets do it then.
I see. Created http://bugs.centos.org/view.php?id=5219 for this topic. Thank you.
On Mon, Oct 24, 2011 at 2:53 PM, Tetsuo Handa from-centos@i-love.sakura.ne.jp wrote:
I'm waiting for kernel-2.6.32-131.17.1.el6.src.rpm .
? Regarding kernel-2.6.32-71.29.1.el6.src.rpm , there was a small difference in the spec file and dynamically generated files.
--- kernel-rh.spec +++ kernel-centos.spec @@ -947,3 +947,3 @@ fi -gpg --homedir . --export --keyring ./kernel.pub Red > extract.pub +gpg --homedir . --export --keyring ./kernel.pub CentOS > extract.pub gcc -o scripts/bin2c scripts/bin2c.c @@ -1656,2 +1656,5 @@ %changelog +* Mon Jun 27 2011 Karanbir Singh kbsingh@centos.org [2.6.32-71.29.1.el6.centos] +- Roll in CentOS Branding
* Thu Apr 21 2011 Frantisek Hrbata fhrbata@redhat.com [2.6.32-71.29.1.el6]
In addition to the above, one line in the genkey file is modified by CentOS:
Name-Real: CentOS
Akemi
On 10/24/2011 10:53 PM, Tetsuo Handa wrote:
Please, put at least some SRPMS here :) Most interesting are net-base: kernel, iptables, tc, ifconfig, ppp, rp-pppoe and all such - people are updating their patches for 6.1 out there (I'm among them) and it may be nice to have sources to know what awaits us.
I'm waiting for kernel-2.6.32-131.17.1.el6.src.rpm .
We have enough ( but barely enough ) space on the mirrors for 6.0/cr/SRPMS; however that would then mean that we no longer have enough space to get 6.1 on there.
So just to keep with the theme of things, what is the feeling if I were : - to drop the CR/SRPMS into vault.c.o - add a .repo stanza into the centos-release-cr rpm with a [sources] pointing to the right place
- KB
On Tue, 25 Oct 2011, Karanbir Singh wrote:
On 10/24/2011 10:53 PM, Tetsuo Handa wrote:
Please, put at least some SRPMS here :) Most interesting are net-base: kernel, iptables, tc, ifconfig, ppp, rp-pppoe and all such - people are updating their patches for 6.1 out there (I'm among them) and it may be nice to have sources to know what awaits us.
I'm waiting for kernel-2.6.32-131.17.1.el6.src.rpm .
We have enough ( but barely enough ) space on the mirrors for 6.0/cr/SRPMS; however that would then mean that we no longer have enough space to get 6.1 on there.
So just to keep with the theme of things, what is the feeling if I were :
- to drop the CR/SRPMS into vault.c.o
- add a .repo stanza into the centos-release-cr rpm with a [sources]
pointing to the right place
I think that is a good idea. It should not matter to anyone where the srpms are physically located as long as they are accessible.
In addition, given that the sprms used to build most of the distro are unmodified from the upstream versions, do you even need to distribute them? Since I am not a lawyer I do not know the answer but it would seem to me that if you made the srpms you modify available that would be good enough.
I am sure some lawyer wannabee will complain about this. People always seem to find something to whine about but if you could do that it would save a bunch of disk space. Which is a good thing IMO.
Just my $.02
Regards,
On 10/25/2011 02:14 PM, me@tdiehl.org wrote:
In addition, given that the sprms used to build most of the distro are unmodified from the upstream versions, do you even need to distribute them? Since I am not a lawyer I do not know the answer but it would seem to me that if you made the srpms you modify available that would be good enough.
I think lets avoid that conversation completely by just pushing out all the srpms / debugs to match what comes from our builds,
- KB
On 10/25/2011 08:14 AM, me@tdiehl.org wrote:
On Tue, 25 Oct 2011, Karanbir Singh wrote:
On 10/24/2011 10:53 PM, Tetsuo Handa wrote:
Please, put at least some SRPMS here :) Most interesting are net-base: kernel, iptables, tc, ifconfig, ppp, rp-pppoe and all such - people are updating their patches for 6.1 out there (I'm among them) and it may be nice to have sources to know what awaits us.
I'm waiting for kernel-2.6.32-131.17.1.el6.src.rpm .
We have enough ( but barely enough ) space on the mirrors for 6.0/cr/SRPMS; however that would then mean that we no longer have enough space to get 6.1 on there.
So just to keep with the theme of things, what is the feeling if I were :
- to drop the CR/SRPMS into vault.c.o
- add a .repo stanza into the centos-release-cr rpm with a [sources]
pointing to the right place
I think that is a good idea. It should not matter to anyone where the srpms are physically located as long as they are accessible.
In addition, given that the sprms used to build most of the distro are unmodified from the upstream versions, do you even need to distribute them? Since I am not a lawyer I do not know the answer but it would seem to me that if you made the srpms you modify available that would be good enough.
You have to provide your own copies and that is clearly called out in the GPL. The reason is that SOMEONE ELSE might go out of business, etc.
Also, the "someone else" only needs to provide the Source to their "customers/users" ... so in the case of Red Hat, they could, for example, put those SRPMS as only available via an RHN account. That would leave CentOS users in a bad place.
This is the reason that you are responsible to provide your own source code ... which we will. Now, if 2 companies have a relationship ... like Fedora and Red Hat, then one could provide the sources for both, etc.
I am sure some lawyer wannabee will complain about this. People always seem to find something to whine about but if you could do that it would save a bunch of disk space. Which is a good thing IMO.
Just my $.02
Regards,
-
Akemi Yagi -
Alexey Asemov (Alex/AT) -
centos1＠iotti.biz -
Charlie Brady -
Fred Wittekind -
Ilya A. Otyutskiy -
Johnny Hughes -
Karanbir Singh -
Leon Fauster -
Ljubomir Ljubojevic -
Manuel Wolfshant -
me＠tdiehl.org -
Tetsuo Handa -
Xavier Bachelot