[EPEL-devel] Re: Backporting fuse3 and fuse3-libs rpms to EPEL

2019-04-05 Thread David Dykstra
Thanks a lot for the helpful answer.  I will request the fuse3 repo or
get the current fuse maintainer to do it.

Dave

On Fri, Apr 05, 2019 at 12:33:37PM -0500, Jason L Tibbitts III wrote:
> >>>>> "DD" == David Dykstra  writes:
> 
> DD> Does this also imply a new fuse3 package in pagure & bodhi?  Or
> DD> could it still be part of the fuse package but have a separate
> DD> fuse3.spec?
> 
> It would have to be a separate package repository and receive separate
> updates.  It is not possible for a source package in EPEL to have the
> same name as a source package in RHEL, even if the build products
> (binary RPMs) have different names.
> 
> Note that a package review is not required to create a package
> repository named "fuse3" (or "fuse3.7" or whatever) when the "fuse"
> package repository already exists.  See
> https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process
> When running fedpkg request-repo, use the --exception flag.
> 
>  - J<
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: Backporting fuse3 and fuse3-libs rpms to EPEL

2019-04-05 Thread David Dykstra
On Fri, Apr 05, 2019 at 11:04:46AM -0400, Stephen John Smoogen wrote:
> On Fri, 5 Apr 2019 at 10:14, David Dykstra  wrote:
...
> > Since RHEL already includes fuse/fuse-libs rpms, my intention is to
> > update the .spec file so those will not build on el6 & 7, leaving only
> > fuse3/fuse3-libs.  On the other hand, I'm not sure rpmbuild will be
> > happy with having a fuse.spec that does not generate a fuse rpm, I will
> > try it.  I guess the alternative would be to split fuse3 out into a
> > separate pagure/bodhi/koji package but it would be good to avoid that.
> 
> I believe that you need to rename the src.rpm spec to being fuse3 for
> this to work with koji. Even though your package is not building fuse2
> items, koji uses the src.rpm and will see yours as being newer than
> the one that is provided by RHEL as fuse.

Does this also imply a new fuse3 package in pagure & bodhi?  Or could it
still be part of the fuse package but have a separate fuse3.spec?

Dave
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org


[EPEL-devel] Backporting fuse3 and fuse3-libs rpms to EPEL

2019-04-05 Thread David Dykstra
The Fedora fuse package currently builds rpms called fuse/fuse-libs and
fuse3/fuse3-libs, the former for fuse-2 versions and the latter for
fuse-3.  The community I support has a need for fuse3/fuse3-libs on
EPEL, so I would like to backport them from Fedora to EPEL.  Does anyone
have an objection to this?  I plan to make a pagure issue on it for
EPSCO review.

The need for this is to take advantage of a feature beginning in
libfuse-3.3.0 that enables pre-mounting fuse filesystems. 
https://github.com/libfuse/libfuse/releases/tag/fuse-3.3.0
We want to add an option to singularity to pre-mount fuse and then run
the fuse filesystem code inside of el6 & el7 containers, in particular
the CernVM FileSystem which is based on fuse.
https://github.com/cvmfs/cvmfs

The package maintainer is cooperating with me on this
https://bugzilla.redhat.com/show_bug.cgi?id=1696454
Since RHEL already includes fuse/fuse-libs rpms, my intention is to
update the .spec file so those will not build on el6 & 7, leaving only
fuse3/fuse3-libs.  On the other hand, I'm not sure rpmbuild will be
happy with having a fuse.spec that does not generate a fuse rpm, I will
try it.  I guess the alternative would be to split fuse3 out into a
separate pagure/bodhi/koji package but it would be good to avoid that.

Dave
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: Major upgrade for singularity in EPEL

2019-04-04 Thread David Dykstra
The pagure issue
https://pagure.io/epel/issue/53
was already approved so I will now do the builds and give them a 4 week
testing period.

Dave

On Wed, Apr 03, 2019 at 11:47:43AM -0500, Dave Dykstra wrote:
> Thanks very much for your reply, Stephen.
> 
> I have already done scratch builds for EPEL 6 & 7 so that's not a problem.
> 
> The primary reason for upgrading to singularity-3 is that development
> has stopped on singularity-2 and users have been asking me to upgrade
> because they want some of the newer features.  I will go ahead and
> create a pagure issue.
> 
> Dave
> 
> On Wed, Apr 03, 2019 at 06:04:42AM -0400, Stephen John Smoogen wrote:
> > On Tue, 2 Apr 2019 at 18:29, David Dykstra  wrote:
> > > singularity-3.1.1 was just released upstream, and I think it is at this
> > > point compatible enough with singularity-2 to upgrade it in EPEL6 and
> > > EPEL7.  I have had singularity-3 releases in Fedora for over 3 months,
> > > but have been holding off on EPEL upgrades because it is a complete
> > > rewrite in another language (golang instead of C) and initially had some
> > > incompatibilities.  There is no more development happening in
> > > singularity-2, although the startup company that supplies long term
> > > support for singularity-2 (Sylabs) has promised to release any security
> > > patches that it develops.
> > >
> > > Is there any objection, or any process that needs to be gone through, in
> > > order to do this type of major upgrade in EPEL?
> > 
> > I would start by doing scratch builds to see if there are versions of
> > go which will compile the code in EPEL-6 and EPEL-7. I am expecting
> > EPEL-6 might be too old and is only got a 18 months of life left so
> > keeping it at -2 and using the security updates will be the case.
> > EPEL-7 might be possible but not sure.
> > 
> > After that, the process for doing it in EPEL would be to email this
> > list with the reasons why an upgrade needs to be done, and then put in
> > a ticket https://pagure.io/epel/issues that we will discuss at the
> > next meeting. EPSCO would then probably give approval and you would
> > then send one more email announcing it is happening and bob's your
> > uncle.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: Major upgrade for singularity in EPEL

2019-04-03 Thread David Dykstra
Thanks very much for your reply, Stephen.

I have already done scratch builds for EPEL 6 & 7 so that's not a problem.

The primary reason for upgrading to singularity-3 is that development
has stopped on singularity-2 and users have been asking me to upgrade
because they want some of the newer features.  I will go ahead and
create a pagure issue.

Dave

On Wed, Apr 03, 2019 at 06:04:42AM -0400, Stephen John Smoogen wrote:
> On Tue, 2 Apr 2019 at 18:29, David Dykstra  wrote:
> > singularity-3.1.1 was just released upstream, and I think it is at this
> > point compatible enough with singularity-2 to upgrade it in EPEL6 and
> > EPEL7.  I have had singularity-3 releases in Fedora for over 3 months,
> > but have been holding off on EPEL upgrades because it is a complete
> > rewrite in another language (golang instead of C) and initially had some
> > incompatibilities.  There is no more development happening in
> > singularity-2, although the startup company that supplies long term
> > support for singularity-2 (Sylabs) has promised to release any security
> > patches that it develops.
> >
> > Is there any objection, or any process that needs to be gone through, in
> > order to do this type of major upgrade in EPEL?
> 
> I would start by doing scratch builds to see if there are versions of
> go which will compile the code in EPEL-6 and EPEL-7. I am expecting
> EPEL-6 might be too old and is only got a 18 months of life left so
> keeping it at -2 and using the security updates will be the case.
> EPEL-7 might be possible but not sure.
> 
> After that, the process for doing it in EPEL would be to email this
> list with the reasons why an upgrade needs to be done, and then put in
> a ticket https://pagure.io/epel/issues that we will discuss at the
> next meeting. EPSCO would then probably give approval and you would
> then send one more email announcing it is happening and bob's your
> uncle.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org


[EPEL-devel] Major upgrade for singularity in EPEL

2019-04-02 Thread David Dykstra
Hello,

singularity-3.1.1 was just released upstream, and I think it is at this
point compatible enough with singularity-2 to upgrade it in EPEL6 and
EPEL7.  I have had singularity-3 releases in Fedora for over 3 months,
but have been holding off on EPEL upgrades because it is a complete
rewrite in another language (golang instead of C) and initially had some
incompatibilities.  There is no more development happening in
singularity-2, although the startup company that supplies long term
support for singularity-2 (Sylabs) has promised to release any security
patches that it develops.

Is there any objection, or any process that needs to be gone through, in
order to do this type of major upgrade in EPEL?

Thanks,

Dave
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org