humm..
<issue> https://rhn.redhat.com/errata/RHSA-2007-1020.html release tags indicate it was built against 5.1, something we have not seen as yet.... </issue>
Options: 1) We build it with what we have at the moment, 5.0 + Updates
2) We wait for 5.1 before building it ( Note: it _is_ a security issue... so keep this in mind )
3) We build it now against 5.0 and Tag it accordingly, and then rebuild it when 5.1 is out and then change Tag to 5_1. It will be a different RPM and would involve most uses doing two updates.
Opinions ?
I'd prefer the third option. This would allow us to have the update as soon as possible and to be as close as possible to the original vendor.
Am Mittwoch, den 31.10.2007, 22:34 +0000 schrieb Karanbir Singh:
humm..
<issue> https://rhn.redhat.com/errata/RHSA-2007-1020.html release tags indicate it was built against 5.1, something we have not seen as yet.... </issue>
Options:
We build it with what we have at the moment, 5.0 + Updates
We wait for 5.1 before building it ( Note: it _is_ a security
issue... so keep this in mind )
- We build it now against 5.0 and Tag it accordingly, and then rebuild
it when 5.1 is out and then change Tag to 5_1. It will be a different RPM and would involve most uses doing two updates.
Opinions ?
Karanbir Singh wrote:
- We build it now against 5.0 and Tag it accordingly, and then rebuild it
when 5.1 is out and then change Tag to 5_1. It will be a different RPM and would involve most uses doing two updates.
Opinions ?
As ugly as it is - this should be what to do. Yes, it sucks. Hard. But security updates aren't updates to wait upon.
Sucks. Sucks. Sucks. But let us do it.
Ralph
On 10/31/07, Ralph Angenendt ra+centos@br-online.de wrote:
Karanbir Singh wrote:
- We build it now against 5.0 and Tag it accordingly, and then rebuild it
when 5.1 is out and then change Tag to 5_1. It will be a different RPM and would involve most uses doing two updates.
Opinions ?
As ugly as it is - this should be what to do. Yes, it sucks. Hard. But security updates aren't updates to wait upon.
Sucks. Sucks. Sucks. But let us do it.
Ralph
The security issue seems more serious than it looks in the RHSA announcement. The description "the default CUPS configuration does not allow remote hosts to connect to the IPP TCP port" may be misleading. Virtually all machines running cups have port 631/tcp open. The details of this bug were publicly made available today. So, I suppose there is no choice, The hole must be plugged as soon as possible.
Akemi
Hi,
Ralph Angenendt wrote:
Karanbir Singh wrote:
- We build it now against 5.0 and Tag it accordingly, and then rebuild it
when 5.1 is out and then change Tag to 5_1. It will be a different RPM and would involve most uses doing two updates.
As ugly as it is - this should be what to do. Yes, it sucks. Hard. But security updates aren't updates to wait upon.
Yes, thats what I thought as well. The only major issue is that we have extra rpms for cups-*-el5_0*.rpm knocking about for i386/x86_64 that wont exist upstream at all.
Karanbir Singh wrote:
humm..
<issue> https://rhn.redhat.com/errata/RHSA-2007-1020.html release tags indicate it was built against 5.1, something we have not seen as yet.... </issue>
Options:
We build it with what we have at the moment, 5.0 + Updates
We wait for 5.1 before building it ( Note: it _is_ a security
issue... so keep this in mind )
- We build it now against 5.0 and Tag it accordingly, and then
rebuild it when 5.1 is out and then change Tag to 5_1. It will be a different RPM and would involve most uses doing two updates.
Opinions ?
I guess I would go with the lesser of the evils.... #3
Nikolay Ulyanitsky wrote:
May be to rebuild the package with current %dist and put it to 5.1 release without rebuilding?
On Wed, 2007-10-31 at 22:34 +0000, Karanbir Singh wrote:
Options:
- We build it with what we have at the moment, 5.0 + Updates
The point is that upstream are now using the %dist tag ( rightly or not, its there now - so we cant really question that anymore. I suppose, like other things, we live with it ) to indicate what tree[1] the package was built against. This could be used by clients and users to verify and track the origin within the Z release's.
If we do what you are saying - that is build with el5_0 and just move it as is into the 5.1.x tree's - we end up with a package set that cant be tracked back to origin by name, and is not even declared as centos modified.
For the time being, we released with el5_0, but I would really vote for rebuild with 5.1 ( so we get the linking and stuff right, and can actually rpmverify for an exact match ) and release that rebuilt package when we can.
On Thu, Nov 01, 2007 at 12:55:12PM +0000, Karanbir Singh wrote:
For the time being, we released with el5_0, but I would really vote for rebuild with 5.1 ( so we get the linking and stuff right, and can actually rpmverify for an exact match ) and release that rebuilt package when we can.
+1
I think for the future the packaged should be releases el5_0.centos built against 5.0 tree, and then when 5.1 is available, rebuilt as el5_1 against the 5.1 tree.
On 11/1/07, Matthew Miller mattdm@mattdm.org wrote:
On Thu, Nov 01, 2007 at 12:55:12PM +0000, Karanbir Singh wrote:
For the time being, we released with el5_0, but I would really vote for rebuild with 5.1 ( so we get the linking and stuff right, and can actually rpmverify for an exact match ) and release that rebuilt package when we can.
+1
-- Matthew Miller mattdm@mattdm.org http://mattdm.org/ Boston University Linux ------> http://linux.bu.edu/ _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Maciej Żenczykowski wrote:
I think for the future the packaged should be releases el5_0.centos built against 5.0 tree, and then when 5.1 is available, rebuilt as el5_1 against the 5.1 tree.
That is what upstream is doing ... the problem is, they are releasing el5_1 stuff, built against the el5_1 tree _BUT_ as of now, there _IS_NO_ el5_1 tree.
That is what leaves CentOS without the ability to build these things as they are currently being built upstream.
I meant the extra centos tag added to the 5.0 built versio of the package. I do understand the problem posed by the 5.1 version of the package being out before 5.1 ;-)
On 11/1/07, Johnny Hughes johnny@centos.org wrote:
Maciej Żenczykowski wrote:
I think for the future the packaged should be releases el5_0.centos built against 5.0 tree, and then when 5.1 is available, rebuilt as el5_1 against the 5.1 tree.
That is what upstream is doing ... the problem is, they are releasing el5_1 stuff, built against the el5_1 tree _BUT_ as of now, there _IS_NO_ el5_1 tree.
That is what leaves CentOS without the ability to build these things as they are currently being built upstream.
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Thu, Nov 01, 2007 at 04:43:13PM -0500, Johnny Hughes wrote:
That is what upstream is doing ... the problem is, they are releasing el5_1 stuff, built against the el5_1 tree _BUT_ as of now, there _IS_NO_ el5_1 tree.
So, do we have a current educated guess as to how long it will be until there is one? "Late October" was last I'd heard.
Matthew Miller wrote:
So, do we have a current educated guess as to how long it will be until there is one? "Late October" was last I'd heard.
rumour on irc the other day was '1st Nov'. not that I believe in such stuff anyway :D
Maciej Żenczykowski wrote:
I think for the future the packaged should be releases el5_0.centos built against 5.0 tree, and then when 5.1 is available, rebuilt as el5_1 against the 5.1 tree.
We thought about this at the time, however that would cause more confusion we felt. the '.centos' bit is added only when there is a change in the sources from upstream. I suppose we can revisit the policy should this kind of a thing become more common in the future.
Feels to me like even if the package has no changes it's 'different' than upstream and should have the label + appropriate coment somewhere in the README.
On 11/2/07, Karanbir Singh mail-lists@karan.org wrote:
Maciej Żenczykowski wrote:
I think for the future the packaged should be releases el5_0.centos built against 5.0 tree, and then when 5.1 is available, rebuilt as el5_1 against the 5.1 tree.
We thought about this at the time, however that would cause more confusion we felt. the '.centos' bit is added only when there is a change in the sources from upstream. I suppose we can revisit the policy should this kind of a thing become more common in the future.
-- Karanbir Singh : http://www.karan.org/ : 2522219@icq _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-
Akemi Yagi -
Heiko Adams -
Johnny Hughes -
Karanbir Singh -
Linux Rockz -
Maciej Żenczykowski -
Matthew Miller -
Nikolay Ulyanitsky -
Ralph Angenendt