Are we building against CentOS 5.2 or 5.1

[Martin Sourada]

Hi,

I've just got a bug on gxine about missing dependency on gecko-libs =
1.8.0.12 and after some exploration I've found that Firefox was upgraded
to 3.0 in CentOS 5.2 and that CentOS 5.2 was released about three weeks
ago, but I didn't noticed any message, or warning, here on the
epel-devel-list. So the question is, are the builders set to build
against 5.1 or against 5.2?

Thanks,
Martin

[Michael Stahnke]

2008/7/16 Martin Sourada :
> Hi,
>
> I've just got a bug on gxine about missing dependency on gecko-libs =
> 1.8.0.12 and after some exploration I've found that Firefox was upgraded
> to 3.0 in CentOS 5.2 and that CentOS 5.2 was released about three weeks
> ago, but I didn't noticed any message, or warning, here on the
> epel-devel-list. So the question is, are the builders set to build
> against 5.1 or against 5.2?
>
> Thanks,
> Martin
>
> epel-devel-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/epel-devel-list

We actually build against RHEL.  I think the builders are still at
5.1, if I am recalling correctly.

Anybody else ?

stahnma

[Dennis Gilmore]

On Wednesday 16 July 2008, Michael Stahnke wrote:
> 2008/7/16 Martin Sourada :
> > Hi,
> >
> > I've just got a bug on gxine about missing dependency on gecko-libs =
> > 1.8.0.12 and after some exploration I've found that Firefox was upgraded
> > to 3.0 in CentOS 5.2 and that CentOS 5.2 was released about three weeks
> > ago, but I didn't noticed any message, or warning, here on the
> > epel-devel-list. So the question is, are the builders set to build
> > against 5.1 or against 5.2?
> We actually build against RHEL.  I think the builders are still at
> 5.1, if I am recalling correctly.
>
> Anybody else ?

The should be using RHEL-5.2  now if not file a bug and we will get it fixed

[Michael Schwendt]

On Wed, 16 Jul 2008 17:27:08 -0500, Dennis Gilmore wrote:
> On Wednesday 16 July 2008, Michael Stahnke wrote:
> > 2008/7/16 Martin Sourada :
> > > Hi,
> > >
> > > I've just got a bug on gxine about missing dependency on gecko-libs =
> > > 1.8.0.12 and after some exploration I've found that Firefox was upgraded
> > > to 3.0 in CentOS 5.2 and that CentOS 5.2 was released about three weeks
> > > ago, but I didn't noticed any message, or warning, here on the
> > > epel-devel-list. So the question is, are the builders set to build
> > > against 5.1 or against 5.2?
> > We actually build against RHEL.  I think the builders are still at
> > 5.1, if I am recalling correctly.
> >
> > Anybody else ?
>
> The should be using RHEL-5.2  now if not file a bug and we will get it fixed

This broken dep is in the repoclosure report since early July.
And unless the private reports have been disabled, this broken dep
has been reported weekly to:

martin.sourada AT gmail.com
        gxine - 0.5.11-14.el5.i386

The script is still misconfigured to run for i386 instead of i686, but
that doesn't affect gxine+firefox.

[Martin Sourada]

On Thu, 2008-07-17 at 00:45 +0200, Michael Schwendt wrote:
> This broken dep is in the repoclosure report since early July.
> And unless the private reports have been disabled, this broken dep
> has been reported weekly to:
> martin.sourada AT gmail.com
>     gxine - 0.5.11-14.el5.i386    
>
> The script is still misconfigured to run for i386 instead of i686, but
> that doesn't affect gxine+firefox.

Yeah, I got that mail a few times, and every time I checked the rest of
the broken deps in that batch, there were obvious false positives like
missing dependency: kernel-devel, and given that in 5.1 there is still
firefox 2.0.0.12, I thought it was result of the broken skript. My bad.

Going to rebuild now against xulrunner. What is the fastest way to get
it to repos?

Thanks,
Martin

[Michael Schwendt]

On Thu, 17 Jul 2008 00:51:15 +0200, Martin Sourada wrote:
> > The script is still misconfigured to run for i386 instead of i686, but
> > that doesn't affect gxine+firefox.
>
> Yeah, I got that mail a few times, and every time I checked the rest of
> the broken deps in that batch, there were obvious false positives like
> missing dependency: kernel-devel,

That's because kernel and kernel-devel (and a few other packages) are NOT
available for i386. They are i686-only for RHEL afaik, not even i586. For
the parameters passed to repoclosure this means "-a i686" and NOT "-a i386".

That's an EasyFix for whoever has write-access where the script is
stored. [Restoring the single-mail-per-report feature is unrelated. That
was okay around May this year.]
> Going to rebuild now against xulrunner. What is the fastest way to get
> it to repos?

Mail epel signers according to the epel faq.

[Mike McGrath]

On Thu, 17 Jul 2008, Michael Schwendt wrote:
> On Thu, 17 Jul 2008 00:51:15 +0200, Martin Sourada wrote:
> > > The script is still misconfigured to run for i386 instead of i686, but
> > > that doesn't affect gxine+firefox.
> >
> > Yeah, I got that mail a few times, and every time I checked the rest of
> > the broken deps in that batch, there were obvious false positives like
> > missing dependency: kernel-devel,
>
> That's because kernel and kernel-devel (and a few other packages) are NOT
> available for i386. They are i686-only for RHEL afaik, not even i586. For
> the parameters passed to repoclosure this means "-a i686" and NOT "-a i386".

Just so I don't mailbomb everyone again.  Changing:

process_deps 5 i386 testing yes

to

process_deps 5 i686 testing yes

?

-Mike

[Michael Schwendt]

On Thu, 17 Jul 2008 13:59:09 -0500 (CDT), Mike McGrath wrote:
> On Thu, 17 Jul 2008, Michael Schwendt wrote:
> > On Thu, 17 Jul 2008 00:51:15 +0200, Martin Sourada wrote:
> > > > The script is still misconfigured to run for i386 instead of i686, but
> > > > that doesn't affect gxine+firefox.
> > >
> > > Yeah, I got that mail a few times, and every time I checked the rest of
> > > the broken deps in that batch, there were obvious false positives like
> > > missing dependency: kernel-devel,
> >
> > That's because kernel and kernel-devel (and a few other packages) are NOT
> > available for i386. They are i686-only for RHEL afaik, not even i586. For
> > the parameters passed to repoclosure this means "-a i686" and NOT "-a i386".
>
> Just so I don't mailbomb everyone again.  Changing:
>
> process_deps 5 i386 testing yes
>
> to
>
> process_deps 5 i686 testing yes
>
> ?

Ah, no, I forgot that somebody added that stuff. In the context of
process_deps this additional line near the top, where a similar thing
is done for ppc, would be needed (I only see a diff of a script called
checkEpel.sh):

[ $arch == "i386" ] && arch_label=i686 || arch_label=$arch

$arch is used in the repo ids, $arch_label passed to Yum.

Dunno where that process_deps() function comes from. It's broken as
I've told stahnma (who might be its author). It ought to run rc-report
on all report-files at once as was done around May.

[Michael Schwendt]

On Fri, 18 Jul 2008 11:44:00 +0200, Michael Schwendt wrote:
> > Just so I don't mailbomb everyone again.  Changing:
> >
> > process_deps 5 i386 testing yes
> >
> > to
> >
> > process_deps 5 i686 testing yes
> >
> > ?
>
> Ah, no, I forgot that somebody added that stuff. In the context of
> process_deps this additional line near the top, where a similar thing
> is done for ppc, would be needed (I only see a diff of a script called
> checkEpel.sh):
> [ $arch == "i386" ] && arch_label=i686 || arch_label=$arch

As the 'OR' is troublesome, it ought to be dropped in favour of giving
$arch_label a default value earlier. Top of function should look like this:

process_deps()
{
    release=$1
    arch=$2
    testing=$3
    mail=$4
    [ -z $4 ] && mail="no" || mail="yes"
-    [ $arch = "ppc" ] && arch_label=ppc64 || arch_label=$arch
+    arch_label=$arch
+    [ $arch == "i386" ] && arch_label=i686
+    [ $arch == "ppc" ] && arch_label=ppc64
    command="/usr/local/bin/rc-modified -d mdcache -n -c $YUM_CONF_LOC -a

RHEL firefox 1.5 -> 3.0

[Orion Poplawski]

> Hi,
>
> I've just got a bug on gxine about missing dependency on gecko-libs =
> 1.8.0.12 and after some exploration I've found that Firefox was upgraded
> to 3.0 in CentOS 5.2

Is anyone else surprised about this move?  It appears to have broken IDL
on 5.2.

- Orion

RHEL firefox 1.5 -> 3.0

[Stephen John Smoogen]

On Wed, Jul 16, 2008 at 8:57 PM,   wrote:
> > Hi,
> >
> > I've just got a bug on gxine about missing dependency on gecko-libs =
> > 1.8.0.12 and after some exploration I've found that Firefox was upgraded
> > to 3.0 in CentOS 5.2
>
> Is anyone else surprised about this move?  It appears to have broken IDL
> on 5.2.

Not really. Red Hat (CentOS's upstream) announced early on in the 5.x
series that they would move to firefox 3.0 when it was ready. The Red
Hat 5.2 beta had firefox-3.0 in it, and it had been discussed on this
list before.

RHEL firefox 1.5 -> 3.0

[Orion Poplawski]

Stephen John Smoogen wrote:
> On Wed, Jul 16, 2008 at 8:57 PM,   wrote:
> > Is anyone else surprised about this move?  It appears to have broken IDL
> > on 5.2.
>
> Not really. Red Hat (CentOS's upstream) announced early on in the 5.x
> series that they would move to firefox 3.0 when it was ready. The Red
> Hat 5.2 beta had firefox-3.0 in it, and it had been discussed on this
> list before.

Well, not so much surprised by the appearance as surprised by the 
decision to make a change that was likely to cause incompatibilities 
with software built against 1.5.  I moved to EL versions to try to avoid 
such things...

RHEL firefox 1.5 -> 3.0

[Stephen John Smoogen]

On Thu, Jul 17, 2008 at 10:04 AM, Orion Poplawski  wrote:
> Stephen John Smoogen wrote:
> > On Wed, Jul 16, 2008 at 8:57 PM,   wrote:
> > > Is anyone else surprised about this move?  It appears to have broken IDL
> > > on 5.2.
> >
> > Not really. Red Hat (CentOS's upstream) announced early on in the 5.x
> > series that they would move to firefox 3.0 when it was ready. The Red
> > Hat 5.2 beta had firefox-3.0 in it, and it had been discussed on this
> > list before.
>
> Well, not so much surprised by the appearance as surprised by the decision
> to make a change that was likely to cause incompatibilities with software
> built against 1.5.  I moved to EL versions to try to avoid such things...

I think this was the reason for the Red Hat 5.x.y releases. There were
paying customers who wanted a new desktop and others who wanted an old
one. Red Hat 5.1.x will be locked with firefox-1.5 etc, but the
various users that want 3.0 with 5 will get it with 5.2,5.3 series.