[EPEL-devel] Fedora EPEL 7 updates-testing report

2022-01-28 Thread updates 
The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-6395a45cb3   
perl-Image-ExifTool-12.38-1.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

remmina-1.4.23-4.el7

Details about builds:



 remmina-1.4.23-4.el7 (FEDORA-EPEL-2022-efe09e7241)
 Remote Desktop Client

Update Information:

- Add missing xdg-utils BuildRequires for generation of icon and theme caches. -
Modify conditional to exclude el7 only from aarch64 builds. Will   now enable
building for el8 and above. - Add scriptlets for updating of icon cache on el7
as not automatic.    Add updating of icon cache for el7.    * Wed Jan 19
2022 Phil Wyett  - 1.4.23-2 - Remove unneeded
BuildRequires for gtk-vnc-2.0.   libvncserver is the preferred for VNC and
disables the gvnc plugin if found.   We have not in the recent past built the
gvnc plugin.  * Wed Jan 19 2022 Phil Wyett  -
1.4.23-1 - New upstream version 1.4.23. - Enable x2go plugin.

ChangeLog:

* Sun Jan 23 2022 Phil Wyett  - 1.4.23-4
- Add missing xdg-utils BuildRequires for generation of icon and theme caches.
- Modify conditional to exclude el7 only from aarch64 builds. Will
  now enable building for el8 and above.
- Add scriptlets for updating of icon cache on el7 as not automatic.
* Fri Jan 21 2022 Fedora Release Engineering  - 
1.4.23-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild
* Wed Jan 19 2022 Phil Wyett  - 1.4.23-2
- Remove unneeded BuildRequires for gtk-vnc-2.0.
  libvncserver is the preferred for VNC and disables the gvnc plugin if found.
  We have not in the recent past built the gvnc plugin.
* Wed Jan 19 2022 Phil Wyett  - 1.4.23-1
- New upstream version 1.4.23.
- Enable x2go plugin.
* Wed Nov 10 2021 Simone Caronni  - 1.4.21-1
- Update to 1.4.21.
* Tue Sep 14 2021 Sahana Prasad  - 1.4.20-3
- Rebuilt with OpenSSL 3.0.0
* Fri Jul 23 2021 Fedora Release Engineering  - 
1.4.20-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild


___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Fedora EPEL 8 updates-testing report

2022-01-28 Thread Larry Cao 
Please, do unsubscribe email larryca...@gmail.com

> On Jan 27, 2022, at 17:25, upda...@fedoraproject.org wrote:
> 
> The following Fedora EPEL 8 Security updates need testing:
> Age  URL
>   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-cf4fee5aa6   
> perl-Image-ExifTool-12.38-1.el8
>   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-1ba918cfc7   
> strongswan-5.9.5-2.el8
> 
> 
> The following builds have been pushed to Fedora EPEL 8 updates-testing
> 
>ipv6calc-4.0.1-63.el8
>testcloud-0.6.4-1.el8
>uglify-js3-3.15.0-1.el8
> 
> Details about builds:
> 
> 
> 
> ipv6calc-4.0.1-63.el8 (FEDORA-EPEL-2022-be8744420c)
> IPv6 address format change and calculation utility
> 
> Update Information:
> 
> Final release 4.0.1
> 
> ChangeLog:
> 
> * Thu Jan 27 2022 Peter Bieringer  - 4.0.1-63
> - Final release 4.0.1
> * Mon Nov  1 2021 Peter Bieringer  - 4.0.0-62
> - Update to latest fixed release
> 
> 
> 
> 
> testcloud-0.6.4-1.el8 (FEDORA-EPEL-2022-004cf14e22)
> Tool for running cloud images locally
> 
> Update Information:
> 
> - fix selinux detection for image context (olichtne) - Drop dependency on
> python-mock - Drop coverage testing in rpm build
> 
> ChangeLog:
> 
> * Thu Jan 27 2022 Frantisek Zatloukal  - 0.6.4-1
> - fix selinux detection for image context (olichtne)
> - Drop dependency on python-mock
> - Drop coverage testing in rpm build
> * Sat Jan 22 2022 Fedora Release Engineering  - 
> 0.6.3-2
> - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild
> 
> 
> 
> 
> uglify-js3-3.15.0-1.el8 (FEDORA-EPEL-2022-87c049b72e)
> JavaScript parser, mangler/compressor and beautifier toolkit
> 
> Update Information:
> 
> Uglify-JS 3.15.0
> 
> ChangeLog:
> 
> * Wed Jan 26 2022 Mattias Ellert  - 3.15.0-1
> - Update to 3.15.0
> 
> References:
> 
>  [ 1 ] Bug #2045909 - uglify-js-3.15.0 is available
>https://bugzilla.redhat.com/show_bug.cgi?id=2045909
> 
> 
> ___
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Removing playground from package.cfg files

2022-01-28 Thread Troy Dawson 
On Fri, Jan 28, 2022 at 7:28 AM Troy Dawson  wrote:

>
>
> On Fri, Jan 28, 2022 at 12:01 AM Miro Hrončok  wrote:
>
>> On 28. 01. 22 3:37, Troy Dawson wrote:
>> >
>> >
>> > On Wed, Jan 26, 2022 at 7:54 AM Troy Dawson > > > wrote:
>> >
>> >
>> >
>> > On Wed, Jan 26, 2022 at 7:37 AM Miro Hrončok > > > wrote:
>> >
>> > On 26. 01. 22 16:30, Troy Dawson wrote:
>> >  > EPEL 8 Playground is going away.
>> >  > One of the steps in that process [1] is to clean out
>> playground from
>> > all the
>> >  > various package.cfg files.
>> >  > I will not be removing the package.cfg files.  I will only
>> remove
>> >  > epel8-playground entry if it is there.  If you, as a package
>> > maintainer, want
>> >  > to remove the package.cfg file, you are free to do so.
>> >  > I have seen too many package.cfg files that have been
>> modified, and
>> > I do not
>> >  > feel safe globally removing them.
>> >  >
>> >  > Note: I will be checking the epel8, epel9, rawhide and f35
>> branches for
>> >  > package.cfg files.
>> >  >
>> >  > This will be happening later today.  Let me know if you have
>> any
>> > concerns
>> >  > and/or comments.
>> >
>> > Hey Troy. Could you please share the list for inspection before
>> actually
>> > changing anything?
>> >
>> >
>> > I can, and will.  Good idea.
>> > It will be a couple hours before I have that list.
>> > Troy
>> >
>> >
>> > That took longer than expected.  Sorry about that.
>> > I know I said that I was only going to take the epel8-playground out of
>> the
>> > files, but it turned out that there were so many that only have the
>> default
>> > package.cfg that we put in, that I feel we should take all those
>> default files out.
>> > There was three groups.
>> >
>> > ** A - Custom package.cfg
>> > * I will only remove epel8-playground
>> > argbash (custom) rawhide f35
>> > nss-mdns (custom) f35
>> > RBTools (custom) rawhide f35
>> >
>> > ** B - Default epel8 package.cfg - in Rawhide and F35
>> > * I am going to remove the package.cfg from rawhide and f35
>> > beanstalk-client (default) rawhide f35
>> > copr-selinux (default) rawhide f35
>> > czmq (default) rawhide f35
>> > fctxpd (default) rawhide f35
>> > gedit-plugin-editorconfig (default) f35
>> > glances (default) rawhide f35
>> > gnome-doc-utils (default) rawhide f35
>> > libwebsockets (default) rawhide f35
>> > MUMPS (default) f35
>> > netcdf4-python (default) rawhide f35
>> > opentrep (default) rawhide f35
>> > python-astroid (default) rawhide f35
>> > python-cftime (default) rawhide f35
>> > python-kubernetes (default) rawhide f35
>> > python-lazy-object-proxy (default) rawhide f35
>> > python-multidict (default) rawhide f35
>> > python-repoze-tm2 (default) rawhide f35
>> > python-repoze-who (default) rawhide f35
>> > python-transaction (default) rawhide f35
>> > R (default) f35
>> > sagator (default) f35
>> > TurboGears2 (default) rawhide f35
>> >
>> > ...
>> >
>> > Let me know if anyone disagrees with my plan.
>>
>> Thank You!
>>
>> Looking for example at python-astroid where your plan is to remove it
>> from f35
>> and rawhide but not from f34.
>>
>> The f35 and rawhide branches are not in sync but f35 is "reachable" from
>> rawhide history. Do we really need to diverge f35 just to remove a file
>> that we
>> are OK keeping on f34?
>>
>> Looking at python-astroid in Koji:
>> https://koji.fedoraproject.org/koji/packageinfo?packageID=16809
>>
>> It doesn't seem this was submitted regularly for many targets. The file
>> has:
>>
>>[koji]
>>targets = epel8 epel8-playground
>>
>> Yet when I run `fedpkg build` on rawhide, it only submits a build for
>> rawhide.
>> Similarly on f35, it only submits a build for f35.
>>
>> When I run `$ fedpkg --release=epel8 build` it submits 2 builds, so it
>> indeed
>> does at least something. The dangerousnes of this is... minimal?
>> Considering
>> the Koji target will be blocked.
>>
>> Hence I propose to only remove the file from f35 if the branch has the
>> same
>> HEAD as rawhide, but not to remove it otherwise to avoid git mess.
>>
>> Similarly, I would also remove it from f34 in such case.
>>
>
> Very good point, and I agree with it.
>
> For "B" packages I will do the following
> If Rawhide, f35 and f34 are all in sync
> - Remove package in rawhide, sync to f35 and f34
> Else If Rawhide and f35 are in sync
> - Remove package in rawhide, sync to f35
> Else If Rawhide and f35 are NOT in sync
> - Remove package in rawhide only
> Else If package.cfg in F35 only
> - Do nothing, because it is not in sync with rawhide.
>
> For "A" packages, I will follow the above logic,
> but instead of "remove package.cfg" I will
> "remove epel8-playground from package.cfg"
>
> For "C" packages, I will just "remove package.cfg"
> No If's or Else's for the "C"

[EPEL-devel] Re: Removing playground from package.cfg files

2022-01-28 Thread Troy Dawson 
On Fri, Jan 28, 2022 at 12:01 AM Miro Hrončok  wrote:

> On 28. 01. 22 3:37, Troy Dawson wrote:
> >
> >
> > On Wed, Jan 26, 2022 at 7:54 AM Troy Dawson  > > wrote:
> >
> >
> >
> > On Wed, Jan 26, 2022 at 7:37 AM Miro Hrončok  > > wrote:
> >
> > On 26. 01. 22 16:30, Troy Dawson wrote:
> >  > EPEL 8 Playground is going away.
> >  > One of the steps in that process [1] is to clean out
> playground from
> > all the
> >  > various package.cfg files.
> >  > I will not be removing the package.cfg files.  I will only
> remove
> >  > epel8-playground entry if it is there.  If you, as a package
> > maintainer, want
> >  > to remove the package.cfg file, you are free to do so.
> >  > I have seen too many package.cfg files that have been
> modified, and
> > I do not
> >  > feel safe globally removing them.
> >  >
> >  > Note: I will be checking the epel8, epel9, rawhide and f35
> branches for
> >  > package.cfg files.
> >  >
> >  > This will be happening later today.  Let me know if you have
> any
> > concerns
> >  > and/or comments.
> >
> > Hey Troy. Could you please share the list for inspection before
> actually
> > changing anything?
> >
> >
> > I can, and will.  Good idea.
> > It will be a couple hours before I have that list.
> > Troy
> >
> >
> > That took longer than expected.  Sorry about that.
> > I know I said that I was only going to take the epel8-playground out of
> the
> > files, but it turned out that there were so many that only have the
> default
> > package.cfg that we put in, that I feel we should take all those default
> files out.
> > There was three groups.
> >
> > ** A - Custom package.cfg
> > * I will only remove epel8-playground
> > argbash (custom) rawhide f35
> > nss-mdns (custom) f35
> > RBTools (custom) rawhide f35
> >
> > ** B - Default epel8 package.cfg - in Rawhide and F35
> > * I am going to remove the package.cfg from rawhide and f35
> > beanstalk-client (default) rawhide f35
> > copr-selinux (default) rawhide f35
> > czmq (default) rawhide f35
> > fctxpd (default) rawhide f35
> > gedit-plugin-editorconfig (default) f35
> > glances (default) rawhide f35
> > gnome-doc-utils (default) rawhide f35
> > libwebsockets (default) rawhide f35
> > MUMPS (default) f35
> > netcdf4-python (default) rawhide f35
> > opentrep (default) rawhide f35
> > python-astroid (default) rawhide f35
> > python-cftime (default) rawhide f35
> > python-kubernetes (default) rawhide f35
> > python-lazy-object-proxy (default) rawhide f35
> > python-multidict (default) rawhide f35
> > python-repoze-tm2 (default) rawhide f35
> > python-repoze-who (default) rawhide f35
> > python-transaction (default) rawhide f35
> > R (default) f35
> > sagator (default) f35
> > TurboGears2 (default) rawhide f35
> >
> > ...
> >
> > Let me know if anyone disagrees with my plan.
>
> Thank You!
>
> Looking for example at python-astroid where your plan is to remove it from
> f35
> and rawhide but not from f34.
>
> The f35 and rawhide branches are not in sync but f35 is "reachable" from
> rawhide history. Do we really need to diverge f35 just to remove a file
> that we
> are OK keeping on f34?
>
> Looking at python-astroid in Koji:
> https://koji.fedoraproject.org/koji/packageinfo?packageID=16809
>
> It doesn't seem this was submitted regularly for many targets. The file
> has:
>
>[koji]
>targets = epel8 epel8-playground
>
> Yet when I run `fedpkg build` on rawhide, it only submits a build for
> rawhide.
> Similarly on f35, it only submits a build for f35.
>
> When I run `$ fedpkg --release=epel8 build` it submits 2 builds, so it
> indeed
> does at least something. The dangerousnes of this is... minimal?
> Considering
> the Koji target will be blocked.
>
> Hence I propose to only remove the file from f35 if the branch has the
> same
> HEAD as rawhide, but not to remove it otherwise to avoid git mess.
>
> Similarly, I would also remove it from f34 in such case.
>

Very good point, and I agree with it.

For "B" packages I will do the following
If Rawhide, f35 and f34 are all in sync
- Remove package in rawhide, sync to f35 and f34
Else If Rawhide and f35 are in sync
- Remove package in rawhide, sync to f35
Else If Rawhide and f35 are NOT in sync
- Remove package in rawhide only
Else If package.cfg in F35 only
- Do nothing, because it is not in sync with rawhide.

For "A" packages, I will follow the above logic,
but instead of "remove package.cfg" I will
"remove epel8-playground from package.cfg"

For "C" packages, I will just "remove package.cfg"
No If's or Else's for the "C" packages.

Troy
___
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:

[EPEL-devel] Re: Removing playground from package.cfg files

2022-01-28 Thread Miro Hrončok 

On 28. 01. 22 3:37, Troy Dawson wrote:



On Wed, Jan 26, 2022 at 7:54 AM Troy Dawson > wrote:




On Wed, Jan 26, 2022 at 7:37 AM Miro Hrončok mailto:mhron...@redhat.com>> wrote:

On 26. 01. 22 16:30, Troy Dawson wrote:
 > EPEL 8 Playground is going away.
 > One of the steps in that process [1] is to clean out playground from
all the
 > various package.cfg files.
 > I will not be removing the package.cfg files.  I will only remove
 > epel8-playground entry if it is there.  If you, as a package
maintainer, want
 > to remove the package.cfg file, you are free to do so.
 > I have seen too many package.cfg files that have been modified, and
I do not
 > feel safe globally removing them.
 >
 > Note: I will be checking the epel8, epel9, rawhide and f35 branches 
for
 > package.cfg files.
 >
 > This will be happening later today.  Let me know if you have any
concerns
 > and/or comments.

Hey Troy. Could you please share the list for inspection before actually
changing anything?


I can, and will.  Good idea.
It will be a couple hours before I have that list.
Troy


That took longer than expected.  Sorry about that.
I know I said that I was only going to take the epel8-playground out of the 
files, but it turned out that there were so many that only have the default 
package.cfg that we put in, that I feel we should take all those default files out.

There was three groups.

** A - Custom package.cfg
* I will only remove epel8-playground
argbash (custom) rawhide f35
nss-mdns (custom) f35
RBTools (custom) rawhide f35

** B - Default epel8 package.cfg - in Rawhide and F35
* I am going to remove the package.cfg from rawhide and f35
beanstalk-client (default) rawhide f35
copr-selinux (default) rawhide f35
czmq (default) rawhide f35
fctxpd (default) rawhide f35
gedit-plugin-editorconfig (default) f35
glances (default) rawhide f35
gnome-doc-utils (default) rawhide f35
libwebsockets (default) rawhide f35
MUMPS (default) f35
netcdf4-python (default) rawhide f35
opentrep (default) rawhide f35
python-astroid (default) rawhide f35
python-cftime (default) rawhide f35
python-kubernetes (default) rawhide f35
python-lazy-object-proxy (default) rawhide f35
python-multidict (default) rawhide f35
python-repoze-tm2 (default) rawhide f35
python-repoze-who (default) rawhide f35
python-transaction (default) rawhide f35
R (default) f35
sagator (default) f35
TurboGears2 (default) rawhide f35

...

Let me know if anyone disagrees with my plan.


Thank You!

Looking for example at python-astroid where your plan is to remove it from f35 
and rawhide but not from f34.


The f35 and rawhide branches are not in sync but f35 is "reachable" from 
rawhide history. Do we really need to diverge f35 just to remove a file that we 
are OK keeping on f34?


Looking at python-astroid in Koji:
https://koji.fedoraproject.org/koji/packageinfo?packageID=16809

It doesn't seem this was submitted regularly for many targets. The file has:

  [koji]
  targets = epel8 epel8-playground

Yet when I run `fedpkg build` on rawhide, it only submits a build for rawhide.
Similarly on f35, it only submits a build for f35.

When I run `$ fedpkg --release=epel8 build` it submits 2 builds, so it indeed 
does at least something. The dangerousnes of this is... minimal? Considering 
the Koji target will be blocked.


Hence I propose to only remove the file from f35 if the branch has the same 
HEAD as rawhide, but not to remove it otherwise to avoid git mess.


Similarly, I would also remove it from f34 in such case.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure