Dear all,
I upgraded the Zabbix package to the upstream version 2.0.2. It seems to work fine, except I don't tested everything.
Thus I have the SRPM with the update for the spec file and some of the sources files. How can I provide it to EPEL ?
Sincerely yours,
-----------------------------------------------------------------------
Fabrice Salvaire, PhD
Research Scientist - Information Technology Division
Phone: +33 (0)1 49 08 07 62
GENOMIC VISION Bâtiment E 80-84 rue des Meuniers 92220 Bagneux France
-----------------------------------------------------------------------
On Tue, 25 Sep 2012 16:29:26 +0200 Fabrice Salvaire f.salvaire@genomicvision.com wrote:
Dear all,
I upgraded the Zabbix package to the upstream version 2.0.2. It seems to work fine, except I don't tested everything.
Thus I have the SRPM with the update for the spec file and some of the sources files. How can I provide it to EPEL ?
File a bug against the epel Zabbix package and the maintainer can review and apply your patches.
kevin
On Tue, Sep 25, 2012 at 11:37 AM, Kevin Fenzi kevin@scrye.com wrote:
On Tue, 25 Sep 2012 16:29:26 +0200 Fabrice Salvaire f.salvaire@genomicvision.com wrote:
Dear all,
I upgraded the Zabbix package to the upstream version 2.0.2. It seems to work fine, except I don't tested everything.
Thus I have the SRPM with the update for the spec file and some of the sources files. How can I provide it to EPEL ?
File a bug against the epel Zabbix package and the maintainer can review and apply your patches.
its actually a touch more complex to that unless things have changed. The EPEL guidelines [1] state that major version updates are to be avoided with a goal of 'yum update' just working. I'm not sure how big of a difference 1.8 -> 2.0, but 1.6 -> 1.8 was different enough. Currently EPEL5 has 1.6 release of zabbix and EPEL6 has 1.8 release. This has been talked about several times on list and I don't know that anyone came up with a good resolution.
One of the options was to change the package name and host both releases in EPEL. I'm not sure how often this actually happens, or what the path to get there would be.
I asked about this with 1.8 on rhel5 and got the above response, so I thought I'd share. That being said, take this as info not a reason to stop :) I'm all for someone figuring out a way forward.
-greg
[1] http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#A_major_version_upd...
On Tue, 2012-09-25 at 12:36 -0500, Greg Swift wrote:
On Tue, Sep 25, 2012 at 11:37 AM, Kevin Fenzi kevin@scrye.com wrote:
On Tue, 25 Sep 2012 16:29:26 +0200 Fabrice Salvaire f.salvaire@genomicvision.com wrote:
Dear all,
I upgraded the Zabbix package to the upstream version 2.0.2. It seems to work fine, except I don't tested everything.
Thus I have the SRPM with the update for the spec file and some of the sources files. How can I provide it to EPEL ?
File a bug against the epel Zabbix package and the maintainer can review and apply your patches.
its actually a touch more complex to that unless things have changed. The EPEL guidelines [1] state that major version updates are to be avoided with a goal of 'yum update' just working.
I recently joined Dan Horak (sharkcz) in the work towards a 2.0 package for Fedora and EPEL.
It's pretty complex indeed. We're switching to two users to keep agent and proxy/server isolated better. We also switched to Debian Alternatives to choose between database implementations and have no conflicting sub-packages. The draft is suitable for systemd and init scripts -- having all necessary conditionals in place and hopefully ending the existence of 4 different branches.
I published a draft. I hope Dan can take a look at it soon. Anybody's comment is highly appreciated.
http://www.geofrogger.net/review/z2/zabbix20-2.0.2-3.el6.src.rpm http://www.geofrogger.net/review/z2/zabbix.Fedora is a README, that will become part of the package.
I'm not sure how big of a difference 1.8 -> 2.0, but 1.6 -> 1.8 was different enough. Currently EPEL5 has 1.6 release of zabbix and EPEL6 has 1.8 release. This has been talked about several times on list and I don't know that anyone came up with a good resolution.
You definitely need to run a database upgrade. Since proxies and servers must run the same major version, it'd be a good idea to also have it in EPEL 5.
One of the options was to change the package name and host both releases in EPEL. I'm not sure how often this actually happens, or what the path to get there would be.
That's the approach we took. zabbix20 conflicts with zabbix. Zabbix has a good stable-policy, so relevant changes would only appear on major x.y releases. They're aiming for regular major releases every 9 months from now on.
Volker Fröhlich
I asked about this with 1.8 on rhel5 and got the above response, so I thought I'd share. That being said, take this as info not a reason to stop :) I'm all for someone figuring out a way forward.
-greg
[1] http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#A_major_version_upd...
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On Tue, Sep 25, 2012 at 1:28 PM, Volker Fröhlich volker27@gmx.at wrote:
On Tue, 2012-09-25 at 12:36 -0500, Greg Swift wrote:
On Tue, Sep 25, 2012 at 11:37 AM, Kevin Fenzi kevin@scrye.com wrote:
On Tue, 25 Sep 2012 16:29:26 +0200 Fabrice Salvaire f.salvaire@genomicvision.com wrote:
Dear all,
I upgraded the Zabbix package to the upstream version 2.0.2. It seems to work fine, except I don't tested everything.
Thus I have the SRPM with the update for the spec file and some of the sources files. How can I provide it to EPEL ?
File a bug against the epel Zabbix package and the maintainer can review and apply your patches.
its actually a touch more complex to that unless things have changed. The EPEL guidelines [1] state that major version updates are to be avoided with a goal of 'yum update' just working.
I recently joined Dan Horak (sharkcz) in the work towards a 2.0 package for Fedora and EPEL.
It's pretty complex indeed. We're switching to two users to keep agent and proxy/server isolated better. We also switched to Debian Alternatives to choose between database implementations and have no conflicting sub-packages. The draft is suitable for systemd and init scripts -- having all necessary conditionals in place and hopefully ending the existence of 4 different branches.
I published a draft. I hope Dan can take a look at it soon. Anybody's comment is highly appreciated.
http://www.geofrogger.net/review/z2/zabbix20-2.0.2-3.el6.src.rpm http://www.geofrogger.net/review/z2/zabbix.Fedora is a README, that will become part of the package.
I'm not sure how big of a difference 1.8 -> 2.0, but 1.6 -> 1.8 was different enough. Currently EPEL5 has 1.6 release of zabbix and EPEL6 has 1.8 release. This has been talked about several times on list and I don't know that anyone came up with a good resolution.
You definitely need to run a database upgrade. Since proxies and servers must run the same major version, it'd be a good idea to also have it in EPEL 5.
One of the options was to change the package name and host both releases in EPEL. I'm not sure how often this actually happens, or what the path to get there would be.
That's the approach we took. zabbix20 conflicts with zabbix. Zabbix has a good stable-policy, so relevant changes would only appear on major x.y releases. They're aiming for regular major releases every 9 months from now on.
awesomeness. Its great to see this.
Dear all,
On 25/09/12 18:37, Kevin Fenzi wrote:
On Tue, 25 Sep 2012 16:29:26 +0200 Fabrice Salvairef.salvaire@genomicvision.com wrote:
Dear all,
I upgraded the Zabbix package to the upstream version 2.0.2. It seems to work fine, except I don't tested everything.
Thus I have the SRPM with the update for the spec file and some of the sources files. How can I provide it to EPEL ?
File a bug against the epel Zabbix package and the maintainer can review and apply your patches.
If I am right the EPEL devel list archive is not searchable and there is no "public container" to put such works: a way to find experimental SRPM for a package, a kind of github infrastructure with a wiki and branches. The SRPM of Greg Swift is certainly much better than my quick upgrade of the 1.8 package, my own is just a RPM version of no more than a personal compilation in order to deploy the agent easily. But how to be aware of it?
Fabrice
kevin
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On Wed, Sep 26, 2012 at 3:45 AM, Fabrice Salvaire f.salvaire@genomicvision.com wrote:
Dear all,
On 25/09/12 18:37, Kevin Fenzi wrote:
On Tue, 25 Sep 2012 16:29:26 +0200 Fabrice Salvairef.salvaire@genomicvision.com wrote:
Dear all,
I upgraded the Zabbix package to the upstream version 2.0.2. It seems to work fine, except I don't tested everything.
Thus I have the SRPM with the update for the spec file and some of the sources files. How can I provide it to EPEL ?
File a bug against the epel Zabbix package and the maintainer can review and apply your patches.
If I am right the EPEL devel list archive is not searchable and there is no "public container" to put such works: a way to find experimental SRPM for a package, a kind of github infrastructure with a wiki and branches. The SRPM of Greg Swift is certainly much better than my quick upgrade of the 1.8 package, my own is just a RPM version of no more than a personal compilation in order to deploy the agent easily. But how to be aware of it?
To search the epel-devel list i usually use 'site:lists.fedoraproject.org epel-devel' in my google search string.
Historically the primary way I have looked into the state of moving an existing package forward is to contact the package owners. Sometimes if they can't push a newer package into stable they host it in their private space and can tell you about it.
https://admin.fedoraproject.org/pkgdb/acls/name/zabbix
I also tend to check out Fedora's Koji to see what is being built in Fedora, since typically it can be used with Fedora with a minimal amount of work.
http://koji.fedoraproject.org/koji/packageinfo?packageID=4278
And the work on the package was Volker not me, but thanks :)
epel-devel@lists.fedoraproject.org