[EPEL-devel] Re: Moving EPEL7 to python3.6

[Orion Poplawski]

On 10/19/2018 01:22 PM, Stephen John Smoogen wrote:

Hi,

EPEL is a set of packages which work for CentOS and RHEL versions 6
and 7. In the version 7, we are currently using python34 and would
like to move this to python36. In doing so, we need help in both our
packaging rules and in updating a lot of packages to work for
python36.

First problem: Packaging rules.
Because there could be updates of python versions from 3.4 to 3.6 or
3.8, we wanted to make clear what python was used for any particular
library. This would make it so someone needing python-bottle did not
end up with one packaged with python-3.6 installed on a python-3.4
system. So we wanted the names to be more specific than python3 and
went with naming all the sub packages python34 or python36.

However, this was decided a while ago and it may not be the best
convention to use or one that the current python sig would like us to
use. I would like to get a naming convention cleared up and documented
so when we do a mass rebuild that the packages come out with either a
python3- or python36-


If you are going to be having different versions of python3 over the 
life of a release, I think it's imperative that it be explicit what 
version of python 3 a package is for.  Otherwise lies madness.



Second problem: When to do this update
We had been looking to do this in October, but it may make more sense
to do this in November after Fedora29 has shipped so that people can
help focus on this versus anything F29 related. It also gives us some
lead time to write blogs/magazine items. How does 2018-11-14 sound?

Third problem: Updating and rebuilding packages to work with python36

Below are the list of packages I found which were making
python34- packages currently in EPEL-7. In updating to
python36, I would like to have a combined Virtual Fedora Activity Day
where we work together on IRC. First we would get any scripts ready
and then work with release engineering to change macros in epel-macros
to point to the correct versions of python and any name changes. We
would then do a mass release bump and rebuild all the packages against
python3.6. As problems are found during that day we would make
appropriate changes and fix.

This might take 2 gos.


The biggest issue I have run into with Python 3 packaging in EPEL is 
version lock.  Python modules (like most software) have atrocious 
backwards compatibility.  For example, we have python3-scipy at version 
0.18.1.  If we add a python3_other_pkgversion package to it for 
python36, we get python36-scipy-0.18.1 whereas we really want 
python36-scipy-1.15.2 (not just to get the latest and greatest - though 
that is important - the old version of the module just may not work with 
the latest python).  We can't update to that though in the python34 
stack or we'll break things.  This plays havock with the original vision 
of just flip a macro switch and rebuild everything, which means rolling 
out a new python version will take time and consideration of each package.


So I think we need another approach.  Some ideas:

- Can we make epel7-py36 branches, and somehow have %python3_version, 
et. al. be 3.6 for those builds?


- Can we just make it easier for people to create python3X- packages 
from existing python3- or python3(X-n)- packages?  And just drop the 
whole macro thing altogether, since sed -i -e s/pyton34-/python36-/ 
*.spec does 90% of the work?



Orion

--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
___
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

Re: [EPEL-devel] Moving EPEL7 to python3.6

[Orion Poplawski]

On 10/19/2018 01:22 PM, Stephen John Smoogen wrote:

Hi,

EPEL is a set of packages which work for CentOS and RHEL versions 6
and 7. In the version 7, we are currently using python34 and would
like to move this to python36. In doing so, we need help in both our
packaging rules and in updating a lot of packages to work for
python36.

First problem: Packaging rules.
Because there could be updates of python versions from 3.4 to 3.6 or
3.8, we wanted to make clear what python was used for any particular
library. This would make it so someone needing python-bottle did not
end up with one packaged with python-3.6 installed on a python-3.4
system. So we wanted the names to be more specific than python3 and
went with naming all the sub packages python34 or python36.

However, this was decided a while ago and it may not be the best
convention to use or one that the current python sig would like us to
use. I would like to get a naming convention cleared up and documented
so when we do a mass rebuild that the packages come out with either a
python3- or python36-


If you are going to be having different versions of python3 over the 
life of a release, I think it's imperative that it be explicit what 
version of python 3 a package is for.  Otherwise lies madness.



Second problem: When to do this update
We had been looking to do this in October, but it may make more sense
to do this in November after Fedora29 has shipped so that people can
help focus on this versus anything F29 related. It also gives us some
lead time to write blogs/magazine items. How does 2018-11-14 sound?

Third problem: Updating and rebuilding packages to work with python36

Below are the list of packages I found which were making
python34- packages currently in EPEL-7. In updating to
python36, I would like to have a combined Virtual Fedora Activity Day
where we work together on IRC. First we would get any scripts ready
and then work with release engineering to change macros in epel-macros
to point to the correct versions of python and any name changes. We
would then do a mass release bump and rebuild all the packages against
python3.6. As problems are found during that day we would make
appropriate changes and fix.

This might take 2 gos.


The biggest issue I have run into with Python 3 packaging in EPEL is 
version lock.  Python modules (like most software) have atrocious 
backwards compatibility.  For example, we have python3-scipy at version 
0.18.1.  If we add a python3_other_pkgversion package to it for 
python36, we get python36-scipy-0.18.1 whereas we really want 
python36-scipy-1.15.2 (not just to get the latest and greatest - though 
that is important - the old version of the module just may not work with 
the latest python).  We can't update to that though in the python34 
stack or we'll break things.  This plays havock with the original vision 
of just flip a macro switch and rebuild everything, which means rolling 
out a new python version will take time and consideration of each package.


So I think we need another approach.  Some ideas:

- Can we make epel7-py36 branches, and somehow have %python3_version, 
et. al. be 3.6 for those builds?


- Can we just make it easier for people to create python3X- packages 
from existing python3- or python3(X-n)- packages?  And just drop the 
whole macro thing altogether, since sed -i -e s/pyton34-/python36-/ 
*.spec does 90% of the work?



Orion

--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 135  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b6c663378c   
unrtf-0.21.9-8.el6
  25  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-6bc3a525a2   
libmad-0.15.1b-26.el6


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

R-Rcpp-0.12.19-1.el6
R-littler-0.3.5-1.el6

Details about builds:



 R-Rcpp-0.12.19-1.el6 (FEDORA-EPEL-2018-f99404a56d)
 Seamless R and C++ Integration

Update Information:

Update to version 0.12.19
https://cran.r-project.org/web/packages/Rcpp/ChangeLog

ChangeLog:

* Mon Oct 22 2018 Mattias Ellert  - 0.12.19-1
- Update to 0.12.19
* Tue Jul 31 2018 Florian Weimer  - 0.12.18-2
- Rebuild with fixed binutils

References:

  [ 1 ] Bug #1641428 - Please update it to 0.12.19
https://bugzilla.redhat.com/show_bug.cgi?id=1641428




 R-littler-0.3.5-1.el6 (FEDORA-EPEL-2018-df2a340e4b)
 littler: R at the Command-Line via 'r'

Update Information:

New version 0.3.5  https://cran.r-project.org/web/packages/littler/ChangeLog

ChangeLog:

* Mon Oct 22 2018 Mattias Ellert  - 0.3.5-1
- New upstream release 0.3.5

___
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

[Bug 1638230] Upgrade perl-File-Slurp to 9999.21

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1638230



--- Comment #12 from Fedora Update System  ---
perl-File-Slurp-.23-1.fc28 has been pushed to the Fedora 28 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-db7a7d3024

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 135  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3835d39d1a   
unrtf-0.21.9-8.el7
  85  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f9d6ff695a   
bibutils-6.6-1.el7 ghc-hs-bibutils-6.6.0.0-1.el7 pandoc-citeproc-0.3.0.1-4.el7
  69  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d   
condor-8.6.11-1.el7
  41  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3492a96896   
myrepos-1.20180726-1.el7
  32  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-bc87c43cdd   
libbson-1.3.5-6.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-a9ac6a18d2   
libgit2-0.26.7-1.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-aa66b877bb   
mosquitto-1.5.3-1.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-d46b0aab32   
lighttpd-1.4.51-1.el7


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

R-Rcpp-0.12.19-1.el7
R-littler-0.3.5-1.el7
Zim-0.68-4.el7
caddy-0.11.0-3.el7
julietaula-montserrat-fonts-7.200-4.el7
milter-greylist-4.6.2-2.el7
python-lark-parser-0.6.4-2.el7
teeworlds-0.6.5-1.el7

Details about builds:



 R-Rcpp-0.12.19-1.el7 (FEDORA-EPEL-2018-ecefe585e2)
 Seamless R and C++ Integration

Update Information:

Update to version 0.12.19
https://cran.r-project.org/web/packages/Rcpp/ChangeLog

ChangeLog:

* Mon Oct 22 2018 Mattias Ellert  - 0.12.19-1
- Update to 0.12.19
* Tue Jul 31 2018 Florian Weimer  - 0.12.18-2
- Rebuild with fixed binutils

References:

  [ 1 ] Bug #1641428 - Please update it to 0.12.19
https://bugzilla.redhat.com/show_bug.cgi?id=1641428




 R-littler-0.3.5-1.el7 (FEDORA-EPEL-2018-588b50e47f)
 littler: R at the Command-Line via 'r'

Update Information:

New version 0.3.5  https://cran.r-project.org/web/packages/littler/ChangeLog

ChangeLog:

* Mon Oct 22 2018 Mattias Ellert  - 0.3.5-1
- New upstream release 0.3.5




 Zim-0.68-4.el7 (FEDORA-EPEL-2018-ea7b66372f)
 Desktop wiki & notekeeper

Update Information:

Update to 0.68

ChangeLog:

* Mon Oct 22 2018 Robin Lee  - 0.68-4
- Fix for epel7
* Thu Jul 19 2018 Robin Lee  - 0.68-3
- Use python2_sitelib macro (BZ#1603334)
* Thu Jul 12 2018 Fedora Release Engineering  - 0.68-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
* Thu Apr 26 2018 Iryna Shcherbina  - 0.68-2
- Update Python 2 dependency declarations to new packaging standards
  (See https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3)
* Mon Apr  2 2018 Robin Lee  - 0.68-1
- Update to 0.68
* Wed Feb  7 2018 Fedora Release Engineering  - 0.67-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Tue Jan 30 2018 Igor Gnatenko  - 0.67-3
- Remove obsolete scriptlets
* Wed Jul 26 2017 Fedora Release Engineering  - 0.67-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild




 caddy-0.11.0-3.el7 (FEDORA-EPEL-2018-960cae316e)
 HTTP/2 web server with automatic HTTPS

Update Information:

- Enable httpd_can_network_connect selinux boolean to connect to ACME endpoint
rhbz#1641158 - Define UDP 80/443 as selinux http_port_t for QUIC rhbz#1608548 -
Define TCP 5033 as selinux http_port_t for HTTP challenge rhbz#1641160

ChangeLog:

* Fri Oct 19 2018 Carl George  - 0.11.0-3
- Enable httpd_can_network_connect selinux boolean to connect to ACME endpoint 
rhbz#1641158
- Define UDP 80/443 as selinux http_port_t for QUIC rhbz#1608548
- Define TCP 5033 as selinux http_port_t for HTTP challenge rhbz#1641160
* Thu Jul 12 2018 Fedora Release Engineering  - 
0.11.0-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild

Re: EPEL: Python 3.4 will be EOL in March 2019

[Stephen John Smoogen]

On Tue, 2 Oct 2018 at 11:54, Aurelien Bompard
 wrote:
>
>
> > most of the packages I've seen lack the python3_other bits (no
> > statistics, just my impression).
>
> That's my impression too.
>
> > Is this something we want? If so, are the packagers willing to adapt
> > their packages (as much as I'd like to do this, I lack the resources to
> > hack on 228 packages)?
>
> I've done quite a few but it's in the tens, not the hundreds. However, winter 
> is coming and it's a nice activity when you're down with the flu.
>
> I've noticed that the with_python3_other variable isn't defined in the file 
> shipped by python3-rpm-macros, it would help transition to set that variable 
> as in the original plan. The edits I've done use that variable as a 
> conditional. Or shouldn't they?
>
> I'm interesting in having more python3.6 packages in EPEL7 since newer 
> releases of Mailman3 requires Python >= 3.5, so I'm currently stuck by some 
> missing dependencies. So I'm willing to help move this forward.

So I would like to get this done in November after F29 is out the
door. I am guessing a set of changes will be needed to be tested
before hand.

-- 
Stephen J Smoogen.
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org

[Bug 1638230] Upgrade perl-File-Slurp to 9999.21

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1638230



--- Comment #11 from Fedora Update System  ---
perl-File-Slurp-.23-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-bb63aaa566

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Re: Intent to orphan / give to go-sig some unused leaf golang packages

[Fabio Valentini]

On Mon, Oct 15, 2018 at 1:21 PM Fabio Valentini  wrote:
>
> Hi everybody,
>
> I'm cleaning up my packages a bit, and I currently maintain some leaf
> packages which aren't used by anything (or anything I use) at this
> point in time.
>
> The packages all have the go-sig as co-admin already, but I intend to
> drop them from my radar completely. You know, cognitive burden and
> stuff.
>
> - golang-github-AudriusButkevicius-kcp-go
> - golang-github-AudriusButkevicius-pfilter
> - golang-github-calmh-luhn
> - golang-github-ccding-go-stun
> - golang-github-cznic-b
> - golang-github-cznic-fileutil
> - golang-github-cznic-golex
> - golang-github-cznic-internal
> - golang-github-cznic-lex
> - golang-github-cznic-lexer
> - golang-github-cznic-lldb
> - golang-github-cznic-mathutil
> - golang-github-cznic-ql
> - golang-github-cznic-sortutil
> - golang-github-cznic-strutil
> - golang-github-cznic-zappy
> - golang-github-edsrzf-mmap-go
> - golang-github-klauspost-reedsolomon
> - golang-github-remyoudompheng-bigfft
> - golang-github-templexxx-cpufeat
> - golang-github-templexxx-reedsolomon
> - golang-github-templexxx-xor
> - golang-github-tjfoc-gmsm
> - golang-github-xtaci-kcp-go
> - golang-github-xtaci-smux
> - golang-github-zillode-notify
>
> The length of this list of now unused leaf packages tells its own
> story about the go ecosystem.
>
> As far as I can tell, nothing in fedora depends on this set of
> packages anymore, except some inter-dependencies between the packages
> themselves.
>
> All the packages are up-to-date with either the latest stable release
> (where available) or the current git master branch, and all the
> packages use the new golang packaging macros ("spec 3.0"). Tests are
> run where available and pass (except where they don't).
>
> If somebody wants to take over a package personally instead of it
> being inherited by the go-sig group, I will give them the package
> instead. I'll give up the remaining packages on Mon, 22 Oct. 2018.
>
> Fabio

Done. I orphaned all of them, since nobody wanted to pick any of them up.

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org

[Fedocal] Reminder meeting : Modularity Office Hours

[nils]

Dear all,

You are kindly invited to the meeting:
   Modularity Office Hours on 2018-10-23 from 10:00:00 to 11:00:00 US/Eastern
   At fedora-modular...@chat.freenode.net

The meeting will be about:
This is where you ask the Fedora Modularity Team questions (and we try to 
answer them)!

Join us on [IRC](irc://chat.freenode.net/#fedora-modularity): 
#fedora-modularity on [FreeNode](https://freenode.net)


Source: https://apps.fedoraproject.org/calendar/meeting/5910/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org

Re: Unretiring rudeconfig

[Robert-André Mauchin]

On dimanche 21 octobre 2018 00:10:03 CEST Ankur Sinha wrote:
> 
> Please feel free to ping me when you are looking for a reviewer in the
> future :)

If I can take your offer, I have yet another simple Golang package that I had 
forgotten to do:
https://bugzilla.redhat.com/show_bug.cgi?id=1641822

It builds in Koji and follows standard Golang template.

Thanks,

Robert-André

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org

[Bug 1640571] Upgrade perl-Mojolicious to 8.03

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1640571

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Mojolicious-8.03-1.fc3
   ||0
 Resolution|--- |RAWHIDE
Last Closed||2018-10-22 17:06:44



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1154912

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[Bug 1640988] perl-Catalyst-Runtime-5.90120 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1640988

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Catalyst-Runtime-5.901
   ||20-1.fc30
 Resolution|--- |RAWHIDE
Last Closed||2018-10-22 17:08:01



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1154909

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[Bug 1640993] Upgrade perl-WWW-Mechanize to 1.89

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1640993

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-WWW-Mechanize-1.89-1.f
   ||c30
 Resolution|--- |RAWHIDE
Last Closed||2018-10-22 17:08:52



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1154902

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[Bug 1639152] Upgrade perl-Mail-DKIM to 0.54

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1639152

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Mail-DKIM-0.54-1.fc30
 Resolution|--- |RAWHIDE
Last Closed||2018-10-22 17:03:23



--- Comment #1 from Emmanuel Seyman  ---
Built in rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1154908

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Re: Self Introduction: Kefu Chai

[Benjamin Kircher]

> On 19. Oct 2018, at 13:17, Kefu Chai  wrote:
> 
> Hey, my name is Kefu Chai, and my nick name on IRC is kefu.
> 
> I am a software developer using C++ and Python. I found that fmt[0] is a very 
> good C++ library for C++ developers like me who whats to have python's 
> str.format() in C++. But its package[1] was recently orphaned. I've been 
> using fedora for couple years in my work. I think it's an opportunity for me 
> to contribute to this project by being a maintainer of this package.
> 
> The review request for fmt can be found at 
> https://bugzilla.redhat.com/show_bug.cgi?id=1638768 .
> 
> Cheers


Welcome Kefu!

I took a look at the package review. Good work.

Unfortunately I cannot sponsor you. It sometimes takes a while to find someone 
willing to sponsor but don’t give up :-) 

BK
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org

[Bug 1546092] amavisd-new ignores $final_spam_destiny directive

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1546092

Juan Orti  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |WORKSFORME
Last Closed||2018-10-22 16:28:50



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

test post

[Aaron Gray]

test post

-- 
Aaron Gray

Independent Open Source Software Engineer, Computer Language Researcher,
Information Theorist, and amateur computer scientist.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

[Lennart Poettering]

On Mo, 22.10.18 11:58, Florian Weimer (fwei...@redhat.com) wrote:

> Anyway, the problem suggests to me that the default soft limit should
> not be raised until the kernel gets better recovery, so that
> applications won't trigger the issue by accident.

During the whole discussions we always made clear that we can't and
won't change the default soft limit, because of the incompatibility
with select(), which cannot deal with fds > 1024. i.e. there always
needs to be the explicit "opt-in" step for apps to say "i am happy
with fds > 1024" (aka, "I promise not to use select()") by bumping the
soft limit to the high limit.

Lennart

-- 
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org

[Bug 1638230] Upgrade perl-File-Slurp to 9999.21

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1638230

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #10 from Fedora Update System  ---
perl-File-Slurp-.23-1.fc29 has been pushed to the Fedora 29 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-04cba6d768

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Re: Fedora should replace mailing lists with Discourse

[Stephen John Smoogen]

On Mon, 22 Oct 2018 at 15:05, Stephen J. Turnbull  wrote:
>

>  > I'm not able to parse this. This very thread is more information that
>  > may get us to move it up in priority. Can you rephrase?
>
> I don't know what "Fedora management" values, or what is needed by the
> people who are doing the work that devel is designed for (coordinating
> packages, troubleshooting dependencies, etc).  However, there are
> forums related to Fedora that people have put up (and IIUC fedoraforum
> is an experiment set up by the Fedora project itself).  That means

Fedora Forum is from a long time ago when Fedora was just starting up.
At that time things were being set up in a more confederated method
where teams would run the products they wanted. The discussions of
mailing lists vs web-something have gone on since 2004 at least. And
they branch out into 'you should use slack!', 'you should use irc',
'telegram!', 'USEnet!' 'you all are wrong. the Plato system had a
superior method', etc etc etc

> there is some dissatisfaction.  But turning that into requirements, or
> justifying using admin resources, etc to upgrade requires more
> knowledge about the community than I have.
>
> I haven't found this thread very informative, to be honest.  The email
> advocates say "it works, could be better" (which given the traffic
> levels I'd have to say is true) which isn't very specific about *what*

Which pretty sums up every one of these conversations over the last 15
years. I don't think either side really can formulate things any more
than a left handed person can say why they are left handed versus
right handed.. one method works better for their brain and the other
doesn't. Does it work perfectly? No but the other method is like using
a tool which always feels wrong. You might be able to learn to use it
but it always itches. Trying to explain it beyond that comes down to
things like 'well it must be superior because I work better on it!'
versus 'well my brain likes to categorize things in this visual method
and your brain uses that method.'

And then a bunch of people try to come up with a tool which works for
everyone but find out that the larger the net, the bigger the holes.
Roll around 2-3 years and we will see another version.


-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org

Re: Fedora should replace mailing lists with Discourse

[Kevin Fenzi]

On 10/22/18 11:14 AM, Stephen J. Turnbull wrote:
> Kevin Fenzi writes:
>  > On 10/21/18 6:12 PM, Stephen J. Turnbull wrote:
> 
>  > > years now.  abompard has a few commits, he and pingu still answer mail
>  > > but that's about it. 
>  > 
>  > Well, he has 980 commits, much more than anyone else.
> 
> Sure, but in the last couple of years there are only a couple of dozen
> commits from all committers.

True. ;(

>  > We intend to keep up with upstream, but we haven't dropped other
>  > items to do so urgently.
> 
> OK, you're right: it's not urgent; HyperKitty is at 1.2.0a1 in our
> repo, 1.1.5 is dated October 17 last year, but little has changed and
> no new features in the UI.  Fedora's Postorius is 1.1.2 (upstream
> 1.2.3), but I doubt that many of the issues I have with Fedora's
> Postorius are fixed upstream, they're more local installation stuff.
> There are many more upstream changes in Postorius vs. HyperKitty, but
> I didn't notice any missing Postorius functionality (except web form
> signups, and that's deliberate).
> 
> Máirín will probably have results in a couple months but we are
> unlikely to release again until PyCon (in May, I think).

Yeah, but staying closer to upstream is still valuable, so people who
commit fixes don't have to wait ages to see them in production.

Another thing I'd like to do at some point, and perhaps we should just
do this soon is move our instance to openshift. That would allow for a
lot faster deployment schedule and a lot more flexability about what
container(s) we use for things as well as scaling, etc. But again thats
some work we need to prioritize and get people working on.
> 
>  > > I don't know the reasons, but somebody at Fedora does: they're the
>  > > same reasons that fedoraforum.org exists.
>  > 
>  > I'm not able to parse this. This very thread is more information that
>  > may get us to move it up in priority. Can you rephrase?
> 
> I don't know what "Fedora management" values, or what is needed by the
> people who are doing the work that devel is designed for (coordinating
> packages, troubleshooting dependencies, etc).  However, there are
> forums related to Fedora that people have put up (and IIUC fedoraforum
> is an experiment set up by the Fedora project itself).  That means
> there is some dissatisfaction.  But turning that into requirements, or
> justifying using admin resources, etc to upgrade requires more
> knowledge about the community than I have.

Fedoraforum is not now, nor has it ever been run by the Fedora project.
It's always been a 3rd party site that runs how they like. I used to be
a moderator there, but I've not had time to even login there in ages.
(perhaps proving that polling sites always ends up slipping down your
list until you no longer remember to do it).

> I haven't found this thread very informative, to be honest.  The email
> advocates say "it works, could be better" (which given the traffic
> levels I'd have to say is true) which isn't very specific about *what*
> works and how it works to enhance productivity, while the forum
> advocates are not at all precise about how a forum is supposed to
> improve *productivity* of this list.  They're mostly focused on
> certain issues, such as ease of entry that I agree are important for a
> user support forum, but I don't think they really help the devel
> workers (that's my personal opinion, not anything I can claim
> expertise on).

Yep. Perhaps we could (re)direct people to file issues with upstreams so
their problems are at least tracked.

>  > Sure. I appreciate your input though!
> 
> Try and stop me! :-)
> 
> Seriously, as I said before, Fedora is currently one of our biggest
> publicly accessible Mailman 3 installations.  We want the best for you
> first, but if "the best for Fedora" can be Mailman 3, we want it to
> shine!

Thanks!

kevin





signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org

[EPEL-devel] Re: Moving EPEL7 to python3.6

[Tuomo Soini]

On Fri, 19 Oct 2018 15:22:01 -0400
Stephen John Smoogen  wrote:

> However, this was decided a while ago and it may not be the best
> convention to use or one that the current python sig would like us to
> use. I would like to get a naming convention cleared up and documented
> so when we do a mass rebuild that the packages come out with either a
> python3- or python36-

I'd very much prefer python3- naming just because it would make
python3 packaging much more consistent with fedora.

But I'd want to point out that add problem to all packages currently
named as python3- (packages where python2 counterpart is part of
rhel).

Because python3- can't have sub-package named python3-.

-- 
Tuomo Soini 
Foobar Linux services
+358 40 5240030
Foobar Oy 
___
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] [Fwd: [includepkgs=devtoolset*] Re: Cannot find -latomic when building for epel7 aarch64]

[Sérgio Basto]

Hello, 

Moving this subject to epel-devel ML 

Generically where I find devtoolset howto(s) ? and what should be mock-
core-configs ? 

And I'm confused what difference of rh-eclipse46 and devtoolset-4 [1] ?

Thanks 
[1]
https://www.softwarecollections.org/en/scls/rhscl/rh-eclipse46/
https://www.softwarecollections.org/en/scls/rhscl/devtoolset-4/



 Forwarded Message 
From: Sérgio Basto 
Reply-to: Development discussions related to Fedora

To: Development discussions related to Fedora 
Subject: [includepkgs=devtoolset*] Re: Cannot find -latomic when
building for epel7 aarch64
Date: Mon, 22 Oct 2018 16:48:45 +0100

On Sat, 2018-10-20 at 13:03 -0400, Todd Zullinger wrote:
> Sérgio Basto wrote:
> > I had checked mock-core-config [1] , which are in use in copr (I
> > guess)
> > and can't enable developer tools .
> > But on koji runs well , can you review this ? please .
> > 
> > I could build azureus [4] on koji [2] which need eclipse-swt , but
> > not
> > on copr `Error: No Package found for rh-eclipse46-eclipse-swt >=
> > 3.5` 
> > Unfortunately I didn't have much time to dig it ... 
> 
> Packages from the SCL repos in mock-core-configs are
> restricted via the following config entry¹:
> 
> includepkgs=devtoolset*
> 
> That limit was not included in the initial koji
> configuration, but my understanding was that was going to be
> corrected.
> 
> The only packages allowed to be used (or more specifically,
> BuildRequired) from the SCL repos in EPEL are devtoolset*.
> (Feel free to follow up on epel-devel on that, as that's
> where the folks who know best are.)
> 
> ¹ https://github.com/rpm-software-management/mock/blob/devel/mock-cor
> e-configs/etc/mock/epel-7-x86_64.cfg#L62


Thank you for the reply 

I improve my spec [1], I'm using devtoolset-4, I could build and run
azureus on el7 but unfortunately, this collection is EOL since Dec
2017; so I don't know if it is a good test, anyway with actual mock-
core-configs we can't install dependencies (rh-java-common-jpackage-
utils and rh-java-common-runtime).
if I add to [sclo-rh] includepkgs=devtoolset*,rh* it works .

In resume [2] fails with: [3]

Thanks 

[1]
https://github.com/sergiomb2/azureus/commits/master

[2]
mock -r epel-7-x86_64 --install devtoolset-4-eclipse-swt

[3]
Problem: cannot install the best candidate for the job
  - nothing provides rh-java-common-runtime needed by devtoolset-4-
eclipse-swt-1:4.5.2-5.4.el7.x86_64


-- 
Sérgio M. B.
___
devel mailing list -- de...@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@list
s.fedoraproject.org
-- 
Sérgio M. B.
___
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

Re: Fedora should replace mailing lists with Discourse

[Neal Gompa]

On Mon, Oct 22, 2018 at 2:22 PM Kevin Fenzi  wrote:
>
> On 10/22/18 9:49 AM, Neal Gompa wrote:
> > On Mon, Oct 22, 2018 at 12:40 PM Kevin Fenzi  wrote:
> >>
> >> On 10/22/18 7:35 AM, Aurelien Bompard wrote:
>  abompard has a few commits, he and pingu still answer mail
>  but that's about it.
> >>>
> >>> I agree that my activity on HyperKitty has slowed down a lot these last 
> >>> years, because I got involved with other projects too.
> >>>
>  No, it can't, can it.  Fedora is not keeping up with upstream, which
>  means that "anyone who wants to" isn't upgrading on the Fedora system.
> >>>
> >>> I'm planning to upgrade but I'm currently stuck with the fact that 
> >>> Mailman Core upped it's dependency on Python 3.5+, and only Python 3.4 is 
> >>> easily accessible in EPEL. So we need to come up with a plan to rebuild 
> >>> all the dependency packages for both Python 3.4 and 3.6, which was part 
> >>> of the initial python lib spec file template in EPEL, but never got 
> >>> really implemented by python lib packagers. (see 
> >>> https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/thread/WIDTOW7HUOJI3QO4WNCG2DTTF5B3CLBE/)
> >>
> >> EPEL folks are trying to plan a python3 work day with whoever we can get
> >> from the python sig soon, where we try and move as much of the stack as
> >> we can to python36. That should very much help this.
> >>
> >
> > Would it be too difficult to just move to Fedora for the Mailman +
> > HyperKitty + Postorius system?
>
> Well, it would still be some work, just different. I know mailman3 is
> under review, we would want that to finish up, then any other packages
> we need, then fixing up any config for fedora vs rhel, etc.
>
> Might be easier, not sure.
>

I'm doing the review for mailman3, I'm just waiting on Aurelien to
respond in it.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org

Re: Fedora should replace mailing lists with Discourse

[Stephen J. Turnbull]

Kevin Fenzi writes:
 > On 10/21/18 6:12 PM, Stephen J. Turnbull wrote:

 > > years now.  abompard has a few commits, he and pingu still answer mail
 > > but that's about it. 
 > 
 > Well, he has 980 commits, much more than anyone else.

Sure, but in the last couple of years there are only a couple of dozen
commits from all committers.

 > We intend to keep up with upstream, but we haven't dropped other
 > items to do so urgently.

OK, you're right: it's not urgent; HyperKitty is at 1.2.0a1 in our
repo, 1.1.5 is dated October 17 last year, but little has changed and
no new features in the UI.  Fedora's Postorius is 1.1.2 (upstream
1.2.3), but I doubt that many of the issues I have with Fedora's
Postorius are fixed upstream, they're more local installation stuff.
There are many more upstream changes in Postorius vs. HyperKitty, but
I didn't notice any missing Postorius functionality (except web form
signups, and that's deliberate).

Máirín will probably have results in a couple months but we are
unlikely to release again until PyCon (in May, I think).

 > > I don't know the reasons, but somebody at Fedora does: they're the
 > > same reasons that fedoraforum.org exists.
 > 
 > I'm not able to parse this. This very thread is more information that
 > may get us to move it up in priority. Can you rephrase?

I don't know what "Fedora management" values, or what is needed by the
people who are doing the work that devel is designed for (coordinating
packages, troubleshooting dependencies, etc).  However, there are
forums related to Fedora that people have put up (and IIUC fedoraforum
is an experiment set up by the Fedora project itself).  That means
there is some dissatisfaction.  But turning that into requirements, or
justifying using admin resources, etc to upgrade requires more
knowledge about the community than I have.

I haven't found this thread very informative, to be honest.  The email
advocates say "it works, could be better" (which given the traffic
levels I'd have to say is true) which isn't very specific about *what*
works and how it works to enhance productivity, while the forum
advocates are not at all precise about how a forum is supposed to
improve *productivity* of this list.  They're mostly focused on
certain issues, such as ease of entry that I agree are important for a
user support forum, but I don't think they really help the devel
workers (that's my personal opinion, not anything I can claim
expertise on).

 > Sure. I appreciate your input though!

Try and stop me! :-)

Seriously, as I said before, Fedora is currently one of our biggest
publicly accessible Mailman 3 installations.  We want the best for you
first, but if "the best for Fedora" can be Mailman 3, we want it to
shine!

Steve
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org

Re: Attention Gmail users, please turn off HTML mail

[Stephen J. Turnbull]

Brian (bex) Exelbierd writes:

 > The question was genuine.  Additionally, even at this site, the user
 > profile doesn't seem to be present.

I doubt there is a user profile chapter or page for HyperKitty at the
Mailman project.  If there is one, it would be in the HyperKitty docs
themselves.

 > Unrelated, if you have edit rights on that page, the GitHub link is
 > out of date and the page still refers to Fedora Hosted.

I hope you don't mean the Mailman wiki DEV/Home page?  Couldn't find
either reference there.

Steve
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org

Re: Fedora should replace mailing lists with Discourse

[Kevin Fenzi]

On 10/22/18 9:49 AM, Neal Gompa wrote:
> On Mon, Oct 22, 2018 at 12:40 PM Kevin Fenzi  wrote:
>>
>> On 10/22/18 7:35 AM, Aurelien Bompard wrote:
 abompard has a few commits, he and pingu still answer mail
 but that's about it.
>>>
>>> I agree that my activity on HyperKitty has slowed down a lot these last 
>>> years, because I got involved with other projects too.
>>>
 No, it can't, can it.  Fedora is not keeping up with upstream, which
 means that "anyone who wants to" isn't upgrading on the Fedora system.
>>>
>>> I'm planning to upgrade but I'm currently stuck with the fact that Mailman 
>>> Core upped it's dependency on Python 3.5+, and only Python 3.4 is easily 
>>> accessible in EPEL. So we need to come up with a plan to rebuild all the 
>>> dependency packages for both Python 3.4 and 3.6, which was part of the 
>>> initial python lib spec file template in EPEL, but never got really 
>>> implemented by python lib packagers. (see 
>>> https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/thread/WIDTOW7HUOJI3QO4WNCG2DTTF5B3CLBE/)
>>
>> EPEL folks are trying to plan a python3 work day with whoever we can get
>> from the python sig soon, where we try and move as much of the stack as
>> we can to python36. That should very much help this.
>>
> 
> Would it be too difficult to just move to Fedora for the Mailman +
> HyperKitty + Postorius system?

Well, it would still be some work, just different. I know mailman3 is
under review, we would want that to finish up, then any other packages
we need, then fixing up any config for fedora vs rhel, etc.

Might be easier, not sure.

kevin





signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org

Re: Fedora should replace mailing lists with Discourse

[Neal Gompa]

On Mon, Oct 22, 2018 at 12:40 PM Kevin Fenzi  wrote:
>
> On 10/22/18 7:35 AM, Aurelien Bompard wrote:
> >> abompard has a few commits, he and pingu still answer mail
> >> but that's about it.
> >
> > I agree that my activity on HyperKitty has slowed down a lot these last 
> > years, because I got involved with other projects too.
> >
> >> No, it can't, can it.  Fedora is not keeping up with upstream, which
> >> means that "anyone who wants to" isn't upgrading on the Fedora system.
> >
> > I'm planning to upgrade but I'm currently stuck with the fact that Mailman 
> > Core upped it's dependency on Python 3.5+, and only Python 3.4 is easily 
> > accessible in EPEL. So we need to come up with a plan to rebuild all the 
> > dependency packages for both Python 3.4 and 3.6, which was part of the 
> > initial python lib spec file template in EPEL, but never got really 
> > implemented by python lib packagers. (see 
> > https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/thread/WIDTOW7HUOJI3QO4WNCG2DTTF5B3CLBE/)
>
> EPEL folks are trying to plan a python3 work day with whoever we can get
> from the python sig soon, where we try and move as much of the stack as
> we can to python36. That should very much help this.
>

Would it be too difficult to just move to Fedora for the Mailman +
HyperKitty + Postorius system?



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org

Re: Fedora should replace mailing lists with Discourse

[Kevin Fenzi]

On 10/22/18 7:35 AM, Aurelien Bompard wrote:
>> abompard has a few commits, he and pingu still answer mail
>> but that's about it.
> 
> I agree that my activity on HyperKitty has slowed down a lot these last 
> years, because I got involved with other projects too.
> 
>> No, it can't, can it.  Fedora is not keeping up with upstream, which
>> means that "anyone who wants to" isn't upgrading on the Fedora system.
> 
> I'm planning to upgrade but I'm currently stuck with the fact that Mailman 
> Core upped it's dependency on Python 3.5+, and only Python 3.4 is easily 
> accessible in EPEL. So we need to come up with a plan to rebuild all the 
> dependency packages for both Python 3.4 and 3.6, which was part of the 
> initial python lib spec file template in EPEL, but never got really 
> implemented by python lib packagers. (see 
> https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/thread/WIDTOW7HUOJI3QO4WNCG2DTTF5B3CLBE/)

EPEL folks are trying to plan a python3 work day with whoever we can get
from the python sig soon, where we try and move as much of the stack as
we can to python36. That should very much help this.

> Or run the lists on Fedora instead of CentOS. Or install in a venv instead of 
> RPMs. All these solutions come with advandages and tradeoffs.
> 
> But the plan is definitely to upgrade, once we have a solution to this issue.

Yep.

kevin




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org

[includepkgs=devtoolset*] Re: Cannot find -latomic when building for epel7 aarch64

[Sérgio Basto]

On Sat, 2018-10-20 at 13:03 -0400, Todd Zullinger wrote:
> Sérgio Basto wrote:
> > I had checked mock-core-config [1] , which are in use in copr (I
> > guess)
> > and can't enable developer tools .
> > But on koji runs well , can you review this ? please .
> > 
> > I could build azureus [4] on koji [2] which need eclipse-swt , but
> > not
> > on copr `Error: No Package found for rh-eclipse46-eclipse-swt >=
> > 3.5` 
> > Unfortunately I didn't have much time to dig it ... 
> 
> Packages from the SCL repos in mock-core-configs are
> restricted via the following config entry¹:
> 
> includepkgs=devtoolset*
> 
> That limit was not included in the initial koji
> configuration, but my understanding was that was going to be
> corrected.
> 
> The only packages allowed to be used (or more specifically,
> BuildRequired) from the SCL repos in EPEL are devtoolset*.
> (Feel free to follow up on epel-devel on that, as that's
> where the folks who know best are.)
> 
> ¹ https://github.com/rpm-software-management/mock/blob/devel/mock-cor
> e-configs/etc/mock/epel-7-x86_64.cfg#L62

Thank you for the reply 

I improve my spec [1], I'm using devtoolset-4, I could build and run
azureus on el7 but unfortunately, this collection is EOL since Dec
2017; so I don't know if it is a good test, anyway with actual mock-
core-configs we can't install dependencies (rh-java-common-jpackage-
utils and rh-java-common-runtime).
if I add to [sclo-rh] includepkgs=devtoolset*,rh* it works .

In resume [2] fails with: [3]

Thanks 

[1]
https://github.com/sergiomb2/azureus/commits/master

[2]
mock -r epel-7-x86_64 --install devtoolset-4-eclipse-swt

[3]
Problem: cannot install the best candidate for the job
  - nothing provides rh-java-common-runtime needed by devtoolset-4-
eclipse-swt-1:4.5.2-5.4.el7.x86_64


-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org

Summary/Minutes from today's FESCo Meeting (2018-10-22)

[Justin Forbes]

=
#fedora-meeting-1: FESCO (2018-10-22)
=


Meeting started by jforbes at 15:00:05 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2018-10-22/fesco.2018-10-22-15.00.log.html
.



Meeting summary
---
* init process  (jforbes, 15:00:05)

* #2001  F29 Final: dnf rebase requested post-freeze  (jforbes,
  15:03:21)
  * LINK: https://pagure.io/fesco/issue/2001   (jforbes, 15:03:21)
  * LINK: https://pagure.io/fesco/issue/2001#comment-537283   (zbyszek,
15:05:22)
  * AGREED: F29 Final: dnf rebase requested post-freeze is approved
(+6,1,-0)  (jforbes, 15:14:44)

* Next week's chair  (jforbes, 15:14:57)
  * jforbes will chair next meeting  (jforbes, 15:16:50)

* Open Floor  (jforbes, 15:17:01)
  * LINK: https://pagure.io/releng/issue/7878 - make pm_request
available and working in koji.  (nirik, 15:18:55)
  * LINK: https://pagure.io/releng/issue/7840 - consider ursa major
(nirik, 15:18:55)
  * AGREED: FESCo confirms psabata as the New Council Engineering rep
(+8,1,0)  (jforbes, 15:33:26)

Meeting ended at 15:35:30 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* jforbes (33)
* nirik (28)
* zbyszek (23)
* zodbot (13)
* maxamillion (9)
* tyll (6)
* rindolf (4)
* jsmith (4)
* sgallagh (0)
* bowlofeggs (0)
* contyk (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org

Fedora Rawhide-20181021.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 11/133 (x86_64), 2/24 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20181019.n.0):

ID: 299250  Test: x86_64 universal install_blivet_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/299250
ID: 299299  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/299299

Old failures (same test failed in Rawhide-20181019.n.0):

ID: 299170  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/299170
ID: 299194  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/299194
ID: 299195  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/299195
ID: 299200  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/299200
ID: 299210  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/299210
ID: 299213  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/299213
ID: 299214  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/299214
ID: 299216  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/299216
ID: 299219  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/299219
ID: 299226  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/299226
ID: 299227  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/299227
ID: 299266  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/299266

Soft failed openQA tests: 2/133 (x86_64), 2/24 (i386)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Rawhide-20181019.n.0):

ID: 299189  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/299189
ID: 299190  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/299190
ID: 299259  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/299259
ID: 299286  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/299286

Passed openQA tests: 102/133 (x86_64), 20/24 (i386)

New passes (same test did not pass in Rawhide-20181019.n.0):

ID: 299253  Test: x86_64 universal install_blivet_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/299253
ID: 299267  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/299267
ID: 299285  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/299285
ID: 299287  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/299287

Skipped openQA tests: 19 of 159

Installed system changes in test x86_64 Server-boot-iso install_default@uefi: 
System load changed from 1.22 to 1.78
Previous test data: https://openqa.fedoraproject.org/tests/298334#downloads
Current test data: https://openqa.fedoraproject.org/tests/299163#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 
System load changed from 0.98 to 1.48
Previous test data: https://openqa.fedoraproject.org/tests/298338#downloads
Current test data: https://openqa.fedoraproject.org/tests/299167#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 
Filesystem for mount / changed from 
/dev/mapper/fedora_ibm--p8--kvm--03--guest--02-root to /dev/mapper/fedora-root
System load changed from 1.48 to 1.68
Previous test data: https://openqa.fedoraproject.org/tests/298339#downloads
Current test data: https://openqa.fedoraproject.org/tests/299168#downloads

Installed system changes in test x86_64 Workstation-boot-iso install_default: 
System load changed from 2.71 to 2.25
Average CPU usage changed from 36.24285714 to 15.64761905
Previous test data: https://openqa.fedoraproject.org/tests/298377#downloads
Current test data: https://openqa.fedoraproject.org/tests/299206#downloads

Installed system changes in test x86_64 Workstation-boot-iso 
install_default@uefi: 
System load changed from 2.15 to 1.55
Previous test data: https://openqa.fedoraproject.org/tests/298380#downloads
Current test data: https://openqa.fedoraproject.org/tests/299209#downloads

Installed system changes in test i386 Workstation-boot-iso install_default: 
System load changed from 0.65 to 0.54
Previous test data: https://openqa.fedoraproject.org/tests/298383#downloads
Current test data: https://openqa.fedoraproject.org/tests/299212#downloads

Installed system changes in test x86_64 AtomicHost-dvd_ostree-iso 

Re: Fedora should replace mailing lists with Discourse

[Aurelien Bompard]

> abompard has a few commits, he and pingu still answer mail
> but that's about it.

I agree that my activity on HyperKitty has slowed down a lot these last years, 
because I got involved with other projects too.

> No, it can't, can it.  Fedora is not keeping up with upstream, which
> means that "anyone who wants to" isn't upgrading on the Fedora system.

I'm planning to upgrade but I'm currently stuck with the fact that Mailman Core 
upped it's dependency on Python 3.5+, and only Python 3.4 is easily accessible 
in EPEL. So we need to come up with a plan to rebuild all the dependency 
packages for both Python 3.4 and 3.6, which was part of the initial python lib 
spec file template in EPEL, but never got really implemented by python lib 
packagers. (see 
https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/thread/WIDTOW7HUOJI3QO4WNCG2DTTF5B3CLBE/)
Or run the lists on Fedora instead of CentOS. Or install in a venv instead of 
RPMs. All these solutions come with advandages and tradeoffs.

But the plan is definitely to upgrade, once we have a solution to this issue.

Aurélien
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org

New major version of forge macros in redhat-rpm-config

[Nicolas Mailhot]

Hi,

As some of you have noticed a major rework of the forge macros has 
finally landed in rawhide:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1155046

(helpers to package projects hosted on Gitlab, Github, Googlecode, 
Bitbucket, etc)



It adds the ability to process multiple source archives in a single 
spec. That was the main missing feature, pointed out by reviewers during 
the initial integration last year.


If you do not need the feature there should be no intentional change in 
the way the macros behave.



If you do need it it's now possible via two switches:
1. -z : process the numberth block of definitions in the spec 
file
2. -a: process every blocks of source definitions in one go, without 
separate -z calls


A contrived spec example that pulls every kind of source the macro 
supports right now is given in:

https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/35


The last version of the macros was documented through
https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation

That proved not too successful. The wiki page was a lot of effort to 
write and maintain, packagers do not read it, FPC never figured how to 
integrate it in guidelines. And then there is the new docs project.


Therefore, I now intend to drop this wiki page. And just ship some 
example spec templates in a redhat-rpm-config subpackage or somewhere 
else¹. That should be easier to maintain, to audit, to keep up to date, 
and to use by Fedora packagers.



Calling the same block of macro code several times with different 
settings, and without side effects, in the same spec, required a huge 
amount of cleanups and refactoring. Including, bugfixes in rpm itself.


Thus, while there is no intentional behaviour change for packagers that 
only use a single source archive in their spec, the cleanups may change 
or remove some undocumented and unintended ways to use the macros that 
were possible in the previous version.


For those reasons, while a backport to stable or even epel-rpm-macros is 
planed, it won't occur immediately.



If you are the maintainer of complex packaging macros in Fedora, the 
whole content of

https://src.fedoraproject.org/rpms/redhat-rpm-config/c/c70110c677904a188d66ffd01a9ab024469ca62d

may be of interest. Implementing this feature required lots of macro 
infra work which is completely generic and not forge-specific.


If you are just a rpm macro user, you can ignore this plumbing.


Many thanks to the redhat-rpm-config maintainers that had the thankless 
task to help me do things that were never done or possible before. 
Evaluating new code, without a past reference to build upon, is always 
scary.


Best regards,


¹ That mostly depends on what FPC decides in 
https://pagure.io/packaging-committee/issue/813


--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org

Re: Moving on from Council Engineering role

[Dennis Gilmore]

El jue, 11-10-2018 a las 12:53 -0400, Josh Boyer escribió:
> Hello Fedora Friends,
> 
> I believe it's time for me to move on from my current role as the
> Council Engineering representative.  When I resigned from FESCo a bit
> ago, I thought I could still fulfill this role.  Unfortunately, that
> turns out to not be the case.  I cannot in good conscience hold a
> seat
> on the Council and be an absentee member.
> 
> As we look to the future for Fedora, we need someone with more active
> participation to be present.  Fortunately, we have a large set of
> very
> competent people that I believe can step into this role without
> issue.
> While it is only a suggestion, I would like to nominate Petr Šabata
> as
> the new Council Engineering rep.  He is more than capable of
> discussing the technical implications of Modularity and the newly
> proposed Objective from Paul.  The decision will ultimately be up to
> FESCo and the Council of course.
> 
> These are important times for Fedora and I'm excited for the future!
> I will continue to participate as I can and I'm looking forward to
> seeing the directions we take as a project and as a distribution.  It
> has been an honor to be part of the Fedora Council for the past few
> years.  Thank you to the community for trusting me with that role for
> so long.

Thank you Josh for all your work over the years, and for the self
awareness that you are not doing the job you want to be doing. I think
that Petr would be able to the job technically very well, however I
object to your reasoning for nominating him. It seems to me that the
nominations is done with a strong bias to a small subset of the
technical directions we are going in. As the Engineering representive I
think there needs to also be a strong focus on the other things like
Fedora CoreOS, emerging technologies (some are coverd with objectives
like IoT), as well as the other technical challenges fedora is facing.
I also know Petr has a lot on his plate already.  Are we perhaps asking
too much of him?

Dennis


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org

Re: Fedora should replace mailing lists with Discourse

[Gerald B. Cox]

On Sat, Oct 20, 2018 at 3:05 AM Stephen J. Turnbull 
wrote:

> Required disclosure: Mailman dev, and my sympathies are with the list
> advocates for this channel both for that reason, and for more
> objective ones.  I don't really argue against a move to Discourse
> here, but I do know a bit about the problem space, and I'd like to
> discuss *some* aspects here.  I expect it's clear which I prefer, but
> there are a lot of arguments "for" that I don't deal with.
>
> Dominik 'Rathann' Mierzejewski writes:
> > Gerald B. Cox writes:
>
>  > > Regardless, as I mentioned above, if they have a bug, then it
>  > > should be reported for them to address.
>  >
>  > I wouldn't call it a bug, just bad UX for a minority(?) target
>  > audience.
>
> I'm pretty sure the Discourse developers would concede that bad UX for
> email users is undesirable.  I'm *not* sure they would concede that
> it's bad UX.  We know how to render HTML to plain text, to RTF, and so
> on; Discourse deliberately chose not to do so, but rather chose a
> format of their own or perhaps some existing format (this is the first
> I've heard of BBcode, so I can't judge).
>
> Thus, I doubt that reporting an issue against Discourse's email
> functionality would get action any time soon from the developers, and
> might get a lot of pushback.
>

Thanks very much for your detailed reply.  You summed it up pretty well.
As far as
the mailing list issue for some email clients I did find this over on the
Discourse support forum:

https://meta.discourse.org/t/plaintext-and-or-raw-emails-for-mailing-list-mode/74267

Again, I'm far from being an email expert... I'm just a user of it - but
people who do have
the knowledge might want to take a look and see if this discussion reflects
some of their concerns
and possibly participate.  I don't know if the situation could or could not
be improved... but it doesn't
hurt to ask.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org

[Bug 1638230] Upgrade perl-File-Slurp to 9999.21

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1638230



--- Comment #9 from Fedora Update System  ---
perl-File-Slurp-.23-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-bb63aaa566

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[Bug 1638230] Upgrade perl-File-Slurp to 9999.21

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1638230

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |MODIFIED



--- Comment #7 from Fedora Update System  ---
perl-File-Slurp-.23-1.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-db7a7d3024

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[Bug 1638230] Upgrade perl-File-Slurp to 9999.21

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1638230



--- Comment #8 from Fedora Update System  ---
perl-File-Slurp-.23-1.fc29 has been submitted as an update to Fedora 29.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-04cba6d768

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Re: PSA: builds using forge macros with tags broken on rawhide

[Jakub Cajka]

- Original Message -
> From: "Nicolas Mailhot" 
> To: "Jakub Cajka" 
> Cc: "Development discussions related to Fedora" 
> 
> Sent: Monday, October 22, 2018 1:55:02 PM
> Subject: Re: PSA: builds using forge macros with tags broken on rawhide
> 
> Le 2018-10-22 13:09, Jakub Cajka a écrit :
> 
> > I think that it would be reasonable to test the changes against the
> > Fedora package base before even pushing the change in to the rawhide.
> > This kind of unnecessary breakage is easily avoidable if you would
> > spent sometime on testing this by scratch rebuilding the Fedora
> > packages locally, prior pushing this.
> 
> There's certainly many things that could be done better if someone took
> the time to do it. But, everyone's time is limited including mine. I
> already rebuild hundreds of Go packages regularly to QA the changes. It
> takes days. Those 40 packages were not part of the set.

In my experience this doesn't require that much time as this is fully 
scriptable from getting all the dependent(Go based packages) and rebuilding 
them locally(even using something dumb as mockchain, it takes under 1 day to 
complete for Go, without needing any babysitting(in VM on i7/ssd laptop)). One 
day(of computation power) seems like reasonable trade-off for not wasting time 
of significant number of (Go) packagers by breaking macros. Or AFAIK it should 
be possible to do such change in the koji side tag(ideally with formal change 
proposal) not affecting the main tag.

> 
> So, if we want more things to be done with the existing manpower, we
> need to fix all the thousands of little things that waste the available
> contributor time:
>   * rehost things cleanly on pagure
>   * clean up the maze of repurposed Go infra specs so any change or fix
> can be QAed and pushed quickly
>   * contribute the fixes we want or need to the Fedora packages that ship
> the corresponding code, instead of 'saving' time by doing messy
> ill-thought workarounds in a private spec file generator

I'm sure that we all want to advance Fedora, but could you be more specific? 
What needs to be done in your opinion? Would you mind opening issues in Go SIG 
for those specific changes(or better PRs in respective packages)?

JC

> 
> And then when things are clearly in one place this place can be used to
> sync the reviews, QA runs and Koji/copr mass rebuilds. Which is clearly
> not the case today.
> 
> Call that purism if you like
> 
> --
> Nicolas Mailhot
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org

Re: PSA: builds using forge macros with tags broken on rawhide

[Nicolas Mailhot]

Le 2018-10-22 13:09, Jakub Cajka a écrit :


I think that it would be reasonable to test the changes against the
Fedora package base before even pushing the change in to the rawhide.
This kind of unnecessary breakage is easily avoidable if you would
spent sometime on testing this by scratch rebuilding the Fedora
packages locally, prior pushing this.


There's certainly many things that could be done better if someone took 
the time to do it. But, everyone's time is limited including mine. I 
already rebuild hundreds of Go packages regularly to QA the changes. It 
takes days. Those 40 packages were not part of the set.


So, if we want more things to be done with the existing manpower, we 
need to fix all the thousands of little things that waste the available 
contributor time:

 * rehost things cleanly on pagure
 * clean up the maze of repurposed Go infra specs so any change or fix 
can be QAed and pushed quickly
 * contribute the fixes we want or need to the Fedora packages that ship 
the corresponding code, instead of 'saving' time by doing messy 
ill-thought workarounds in a private spec file generator


And then when things are clearly in one place this place can be used to 
sync the reviews, QA runs and Koji/copr mass rebuilds. Which is clearly 
not the case today.


Call that purism if you like

--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org

Schedule for Monday's FESCo Meeting (2018-10-22)

[Justin Forbes]

Following is the list of topics that will be discussed in the
FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2018-10-22 15:00 UTC'


Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda

= New business =

#topic #2001  F29 Final: dnf rebase requested post-freeze
.fesco 2001
https://pagure.io/fesco/issue/2001

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org

Re: PSA: builds using forge macros with tags broken on rawhide

[Jakub Cajka]

- Original Message -
> From: "Nicolas Mailhot" 
> To: "Robert-André Mauchin" , "Development 
> discussions related to Fedora"
> 
> Cc: "Nicolas Mailhot" 
> Sent: Monday, October 22, 2018 10:00:40 AM
> Subject: Re: PSA: builds using forge macros with tags broken on rawhide
> 
> Le lundi 22 octobre 2018 à 00:31 +0200, Robert-André Mauchin a écrit :
> > Yeah all "gosetup -q" (which is gofed default) are broken because of
> > your commit:
> 
> Well I know no such a thing, there was never any gosetup macro in the
> macro set, and I think I told you a year ago I would not define a
> gosetup macro just to avoid typing forgesetup, unless it actually added
> some processing over the forgesetup macro. That would obfuscate specs
> for no good reason and increase gratuituously the maintenance surface
> (as we see *now*).
> 
> And I doubt -q is your problem, since (*precisely for backwards
> compatible reasons) it is still accepted by forgesetup (even though it's
> ignored, because it’s the default behaviour now).
> 
> Oh, I see, I forgot to add a phantom -q to forgeautosetup as it already
> was already its default behaviour. So you're forcing somewhere a -q that
> I don't think was ever needed. I will add the -q to the macro definition
> if that makes you feel better.
> 
> So, no biggie. Easy to fix. That's why such changes hit -devel before
> anyone dreams of queuing them to stable.

I think that it would be reasonable to test the changes against the Fedora 
package base before even pushing the change in to the rawhide. This kind of 
unnecessary breakage is easily avoidable if you would spent sometime on testing 
this by scratch rebuilding the Fedora packages locally, prior pushing this.

Could we avoid any such kind of regressions in the future?

JC

> 
> What package exactly installs your gosetup macro in /usr/lib/rpm so I
> can see what other things it tries to do? I see no macro file in the
> Fedora gofed package manifests.
> 
> If you could PR your changes to the official Fedora packages that
> coordinate Fedora go macros (the go-macros repository on github, that
> will be rehosted in pagure as soon as the @rh contributors ok the move)
> instead of doing it in other places, that would be a tad easier to
> coordinate.
> 
> > Please revert this, we should be able to use whatever flag supported
> > by %setup and
> >  %autosetup, not a small subset.  How do you even pass the basic -n
> > flags now?
> 
> So basically, you have a macro, which sole purpose is to pass
> precomputed -n values to *setup, and you want to use it with manual -n
> flags. Why? Could you tell us what exactly is the point of
> 
> 1. wrapping a Fedora macro in another name just because you do not like
> the official macro name in Fedora
> 2. overriding the only thing this macro does over autosetup
> 3. and then complaining all the argument passing to autosetup does not
> work as you wish it does
> 
> So all this complexity, because what you really want is to use autosetup
> directly. Then just do. What's the problem exactly with typing autosetup
> in your spec? No one stops you from doing it.
> 
> One reason I removed the -n in forgeautosetup and forgesetup precisely
> to stop packagers confusing themselves the way you are confusing
> yourself.
> 
> The other being -n is incompatible with the processing of multiple
> archives that many people asked me to add to the macros. Which is
> finally implemented after months of work. And which just hit rawhide
> after more than a month of review.
> 
> So, do you have actual spec files in Fedora with this use of the redhat-
> rpm-config macros? If that is the case, I can put those flags in the
> macros so you can continue shooting yourself in the foot using undefined
> known-broken use patterns. If not, I'd rather remove the possibility
> altogether before someone harms himself.
> 
> > With you mods, we have to edit hundreds of specs to remove
> > the -q flags.
> 
> And that concretely, if why pre-generating specs instead of making the
> effort to include default processing in the macro code Fedora ships is
> wrong.
> 
> Regards,
> 
> --
> Nicolas Mailhot
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to 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/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org

Fedora rawhide compose report: 20181021.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20181019.n.0
NEW: Fedora-Rawhide-20181021.n.0

= SUMMARY =
Added images:1
Dropped images:  2
Added packages:  7
Dropped packages:2
Upgraded packages:   100
Downgraded packages: 0

Size of added packages:  23.94 MiB
Size of dropped packages:85.80 KiB
Size of upgraded packages:   9.49 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   117.35 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20181021.n.0.s390x.tar.xz

= DROPPED IMAGES =
Image: AtomicHost qcow2 ppc64le
Path: 
AtomicHost/ppc64le/images/Fedora-AtomicHost-Rawhide-20181019.n.0.ppc64le.qcow2
Image: AtomicHost raw-xz ppc64le
Path: 
AtomicHost/ppc64le/images/Fedora-AtomicHost-Rawhide-20181019.n.0.ppc64le.raw.xz

= ADDED PACKAGES =
Package: duperemove-0.11-3.fc30
Summary: Tools for deduping file systems
RPMs:duperemove
Size:506.36 KiB

Package: ghcid-0.7.1-1.fc30
Summary: GHCi based bare bones IDE
RPMs:ghc-ghcid ghc-ghcid-devel ghcid
Size:10.56 MiB

Package: lutris-0.4.21-1.fc30
Summary: Install and play any video game easily
RPMs:lutris
Size:1.33 MiB

Package: pcb-rnd-2.0.1-1.fc30
Summary: Modular Printed Circuit Board layout tool
RPMs:pcb-rnd pcb-rnd-auto pcb-rnd-cloud pcb-rnd-core pcb-rnd-debug 
pcb-rnd-doc pcb-rnd-export pcb-rnd-export-extra pcb-rnd-export-sim 
pcb-rnd-extra pcb-rnd-hid-gtk2-gdk pcb-rnd-hid-gtk2-gl pcb-rnd-hid-lesstif 
pcb-rnd-import-geo pcb-rnd-import-net pcb-rnd-io-alien pcb-rnd-io-standard 
pcb-rnd-lib-gl pcb-rnd-lib-gtk pcb-rnd-lib-gui pcb-rnd-lib-io
Size:11.47 MiB

Package: python-multio-0.2.4-1.fc30
Summary: Unified async library for curio and trio
RPMs:python3-multio
Size:21.27 KiB

Package: python-multipart-0.0.5-2.fc30
Summary: A streaming multipart parser for Python
RPMs:python3-multipart
Size:41.89 KiB

Package: rust-rustfix-0.4.2-1.fc30
Summary: Automatically apply the suggestions made by rustc
RPMs:rust-rustfix-devel
Size:20.86 KiB


= DROPPED PACKAGES =
Package: gettext-commons-0.9.6-14.fc24
Summary: Java internationalization (i18n) library
RPMs:gettext-commons gettext-commons-javadoc
Size:56.22 KiB

Package: python-hghooks-0.7.0-10.fc29
Summary: A set of useful hooks for Mercurial
RPMs:python2-hghooks
Size:29.58 KiB


= UPGRADED PACKAGES =
Package:  apache-commons-lang3-3.8.1-2.fc30
Old package:  apache-commons-lang3-3.8.1-1.fc30
Summary:  Provides a host of helper utilities for the java.lang API
RPMs: apache-commons-lang3 apache-commons-lang3-javadoc
Size: 1018.65 KiB
Size change:  -44 B
Changelog:
  * Fri Oct 12 2018 Marian Koncek  - 3.8.1-2
  - Fix incorrect OSGi metadata
  - Resolves: rhbz#1636556


Package:  apache-commons-parent-47-1.fc30
Old package:  apache-commons-parent-43-3.fc29
Summary:  Apache Commons Parent Pom
RPMs: apache-commons-parent
Size: 26.89 KiB
Size change:  2.12 KiB
Changelog:
  * Fri Oct 12 2018 Marian Koncek  - 47-1
  - Update to upstream version 47


Package:  biber-2.11-2.fc30
Old package:  biber-2.11-1.fc30
Summary:  Command-line bibliographic manager, BibTeX replacement
RPMs: biber
Size: 294.96 KiB
Size change:  -232 B
Changelog:
  * Thu Oct 18 2018 Colin B. Macdonald  - 2.11-2
  - Re-enable tests for e.g., #1512848


Package:  bindfs-1.13.10-1.fc30
Old package:  bindfs-1.13.9-3.fc30
Summary:  Fuse filesystem to mirror a directory
RPMs: bindfs
Size: 270.16 KiB
Size change:  1.35 KiB
Changelog:
  * Sat Oct 20 2018 Filipe Rosset  - 1.13.10-1
  - update to new version 1.13.10


Package:  binutils-2.31.1-15.fc30
Old package:  binutils-2.31.1-14.fc30
Summary:  A GNU collection of binary utilities
RPMs: binutils binutils-devel
Size: 39.90 MiB
Size change:  16.62 KiB
Changelog:
  * Fri Oct 12 2018 Nick Clifton   - 2.31.1-15
  - Allow OS specific sections in section groups.  (#1639485)


Package:  bzflag-2.4.18-1.fc30
Old package:  bzflag-2.4.16-1.fc30
Summary:  3D multi-player tank battle game
RPMs: bzflag bzflag-maps-sample
Size: 64.03 MiB
Size change:  -20.12 KiB
Changelog:
  * Fri Oct 19 2018 Gwyn Ciesla  - 2.4.18-1
  - 2.4.18


Package:  caddy-0.11.0-3.fc30
Old package:  caddy-0.11.0-2.fc29
Summary:  HTTP/2 web server with automatic HTTPS
RPMs: caddy
Size: 52.15 MiB
Size change:  3.34 MiB
Changelog:
  * Fri Oct 19 2018 Carl George  - 0.11.0-3
  - Enable httpd_can_network_connect selinux boolean to connect to ACME 
endpoint rhbz#1641158
  - Define UDP 80/443 as selinux http_port_t for QUIC rhbz#1608548
  - Define TCP 5033 as selinux http_port_t for HTTP challenge rhbz#1641160


Package:  carbon-c-relay-3.4-1.fc30
Old package:  carbon-c-relay-3.3-2.fc29
Summary:  Enhanced C implementation of Carbon relay, aggregator and 

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

[Florian Weimer]

* Lennart Poettering:

> On Fr, 19.10.18 09:12, Florian Weimer (fwei...@redhat.com) wrote:
>
>> >> (cross-posting to devel and desktop lists, ideally reply to both)
>> >
>> > Coincidentally, at All Systems Go! in Berlin last week I had some
>> > discussions with kernel people about RLIMIT_NOFILE defaults. They
>> > basically suggested that the memory and performance cost of large
>> > numbers of fds on current kernels is cheap, and that we should bump
>> > the hard limit in systemd for all userspace processes.
>> 
>> Which kernel version is that?  Is that a new patch?  Or some older
>> kernel?
>> 
>> It's definitely not true for kernel 4.18, see the script I posted.
>
> I inquired Tejun Heo about this all, this is what he replied:

> So, yeah, if we'd use cgroupv2 on Fedora, then everything would be
> great (unfortunately the container messiness blocks that for now). But
> as long as we don't, lifting the fd limit is not really making things
> worse, given that there are tons of other easily exploitable ways to
> acquire untracked memory...

How does cgroupv2 solve this if we do not configure hard limits for the
user session?  I don't want us to go back to static resource allocation
for applications, similar to what System 9 did.

Anyway, the problem suggests to me that the default soft limit should
not be raised until the kernel gets better recovery, so that
applications won't trigger the issue by accident.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org

Re: Building Steam Proton on Fedora

[Kamil Paral]

On Sat, Oct 20, 2018 at 2:06 PM Dridi Boukelmoune <
dridi.boukelmo...@gmail.com> wrote:

> On Fri, Oct 19, 2018 at 5:15 PM Kamil Paral  wrote:
> >
> > I don't know how to build Proton and the people who reported Proton
> works for them on Fedora are simply referring to the bundled Proton in
> Steam installation, I believe.
>
> Makes sense! And this is exactly what I'm trying to avoid... Non-free
> RPM downloading more code to run off the internet.
>
> > However, it should be possible to use Steam-bundled Proton to run
> arbitrary Windows executables, not just those provided by Steam, if you
> don't mind some tinkering:
> >
> >
> https://www.reddit.com/r/SteamPlay/comments/99z9o9/running_games_standalone_via_proton/e4rr7rv/
> >
> https://www.reddit.com/r/Steam/comments/99fjzw/steam_proton_for_non_steam_applications/
> >
> https://www.reddit.com/r/SteamPlay/comments/9bhvxh/how_do_i_run_a_non_steam_game_with_proton/
> >
> https://www.reddit.com/r/SteamPlay/comments/9anque/steamplayprotonlutris_cheat_sheet/
> >
> https://github.com/ValveSoftware/Proton/issues/260#issuecomment-427607859
> >
> https://forum.level1techs.com/t/windows-games-on-steam-for-linux-proton-client-testing-grounds/131219/71
> >
> > I haven't personally tried that.
>
> The new README and docker-based setup got me further but still
> nowhere. I'm surprised that after installing the docker package there
> is no group of the eponymous persuasion. That makes the whole
> privileges awkward and with no surprise (being Debian-based) the build
> system is not SELinux-friendly.
>
> I'll let a couple weeks pass and revisit this again, thanks for the links.
>

I should mention one thing - Proton is supposed to be basically Wine +
esync + dxvk. You can set up the same functionality using those upstream
projects yourself, without compiling Proton per se. It would be useful for
running arbitrary Windows games. For running Steam games, you might be
missing some Steam integration bits (SteamWorks) though.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org

Re: PSA: builds using forge macros with tags broken on rawhide

[Nicolas Mailhot]

Le lundi 22 octobre 2018 à 10:00 +0200, Nicolas Mailhot a écrit :
> Le lundi 22 octobre 2018 à 00:31 +0200, Robert-André Mauchin a écrit :
> > Yeah all "gosetup -q" (which is gofed default) are broken because of
> > your commit:
> 
> Well I know no such a thing, there was never any gosetup macro in the
> macro set, and I think I told you a year ago I would not define a
> gosetup macro just to avoid typing forgesetup, unless it actually
> added
> some processing over the forgesetup macro. That would obfuscate specs
> for no good reason and increase gratuituously the maintenance surface
> (as we see *now*).

However, you *can* PR your own definition of gosetup to the Fedora go
macros package if you absolutely want it to exist. I will be happy to
support the PR so this macro has a maintainer in Fedora.

I'm not the Fedora maintainer of this package (even though, at this
point, I wrote most of it in line numbers). But I will be happy to
support your request.

Regards,
-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org

Re: PSA: builds using forge macros with tags broken on rawhide

[Nicolas Mailhot]

Le lundi 22 octobre 2018 à 10:00 +0200, Nicolas Mailhot a écrit :
> Le lundi 22 octobre 2018 à 00:31 +0200, Robert-André Mauchin a écrit :
> > Yeah all "gosetup -q" (which is gofed default) are broken because of
> > your commit:
> 
> Well I know no such a thing, there was never any gosetup macro in the
> macro set, and I think I told you a year ago I would not define a
> gosetup macro just to avoid typing forgesetup, unless it actually
> added
> some processing over the forgesetup macro. That would obfuscate specs
> for no good reason and increase gratuituously the maintenance surface
> (as we see *now*).
> 
> And I doubt -q is your problem, since (*precisely for backwards
> compatible reasons) it is still accepted by forgesetup (even though
> it's
> ignored, because it’s the default behaviour now).
> 
> Oh, I see, I forgot to add a phantom -q to forgeautosetup as it
> already
> was already its default behaviour. So you're forcing somewhere a -q
> that
> I don't think was ever needed. I will add the -q to the macro
> definition
> if that makes you feel better.
>
> So, no biggie. Easy to fix. That's why such changes hit -devel before
> anyone dreams of queuing them to stable.

And it's here:

https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/45



-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org

Re: PSA: builds using forge macros with tags broken on rawhide

[Nicolas Mailhot]

Le lundi 22 octobre 2018 à 00:31 +0200, Robert-André Mauchin a écrit :
> Yeah all "gosetup -q" (which is gofed default) are broken because of
> your commit:

Well I know no such a thing, there was never any gosetup macro in the
macro set, and I think I told you a year ago I would not define a
gosetup macro just to avoid typing forgesetup, unless it actually added
some processing over the forgesetup macro. That would obfuscate specs
for no good reason and increase gratuituously the maintenance surface
(as we see *now*).

And I doubt -q is your problem, since (*precisely for backwards
compatible reasons) it is still accepted by forgesetup (even though it's
ignored, because it’s the default behaviour now).

Oh, I see, I forgot to add a phantom -q to forgeautosetup as it already
was already its default behaviour. So you're forcing somewhere a -q that
I don't think was ever needed. I will add the -q to the macro definition
if that makes you feel better.

So, no biggie. Easy to fix. That's why such changes hit -devel before
anyone dreams of queuing them to stable.

What package exactly installs your gosetup macro in /usr/lib/rpm so I
can see what other things it tries to do? I see no macro file in the
Fedora gofed package manifests.

If you could PR your changes to the official Fedora packages that
coordinate Fedora go macros (the go-macros repository on github, that
will be rehosted in pagure as soon as the @rh contributors ok the move)
instead of doing it in other places, that would be a tad easier to
coordinate.

> Please revert this, we should be able to use whatever flag supported
> by %setup and
>  %autosetup, not a small subset.  How do you even pass the basic -n
> flags now?

So basically, you have a macro, which sole purpose is to pass
precomputed -n values to *setup, and you want to use it with manual -n
flags. Why? Could you tell us what exactly is the point of

1. wrapping a Fedora macro in another name just because you do not like
the official macro name in Fedora
2. overriding the only thing this macro does over autosetup
3. and then complaining all the argument passing to autosetup does not
work as you wish it does

So all this complexity, because what you really want is to use autosetup
directly. Then just do. What's the problem exactly with typing autosetup
in your spec? No one stops you from doing it.

One reason I removed the -n in forgeautosetup and forgesetup precisely
to stop packagers confusing themselves the way you are confusing
yourself.

The other being -n is incompatible with the processing of multiple
archives that many people asked me to add to the macros. Which is
finally implemented after months of work. And which just hit rawhide
after more than a month of review.

So, do you have actual spec files in Fedora with this use of the redhat-
rpm-config macros? If that is the case, I can put those flags in the
macros so you can continue shooting yourself in the foot using undefined
known-broken use patterns. If not, I'd rather remove the possibility
altogether before someone harms himself.

> With you mods, we have to edit hundreds of specs to remove 
> the -q flags.

And that concretely, if why pre-generating specs instead of making the
effort to include default processing in the macro code Fedora ships is
wrong.

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org

[Test-Announce] Proposal to CANCEL: 2018-10-22 @ 15:00 UTC - Fedora QA Meeting

[Geoffrey Marr]

Hey everyone,

Having missed our first ship date, but still on track to potentially meet
our second, I am proposing we cancel the QA meeting tomorrow and simply
take the time to get ready for the Blocker Review meeting an hour later at
16:00UTC.

If anyone has any important information that must be shared at the meeting,
please respond to this email and we can run the meeting at the normal time.
Otherwise, I look forward to seeing you at the Blocker Review Meeting
tomorrow!

Geoff Marr
IRC: coremodule
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-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/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org