[Bug 1724169] Missing MPLv2.0 in License

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Blocks|1632600 |



-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1724169] Missing MPLv2.0 in License

[bugzilla]

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



--- Comment #2 from Petr Pisar  ---
> -# openssl for Test-client-performs-Post-Handshake-Authentication.patch
> -BuildRequires: openssl

This was there because of /usr/bin/openssl tool. I can see you already have had
"openssl >= 0.9.8". Should that be openssl-libs?

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: wpa supplicant using /dev/random

[Chris Murphy]

On Thu, Jun 6, 2019 at 4:03 AM Tomas Mraz  wrote:
>
> On Wed, 2019-06-05 at 16:38 -0600, Chris Murphy wrote:
> > Jun 05 15:53:25 fmac.local kernel: random: crng init done
> > Jun 05 15:53:25 fmac.local kernel: random: 7 urandom warning(s)
> > missed
> > due to ratelimiting
> > Jun 05 15:53:25 fmac.local wpa_supplicant[1000]: random: Cannot read
> > from /dev/random: Resource temporarily unavailable
> > Jun 05 15:53:25 fmac.local wpa_supplicant[1000]: random: Got 20/20
> > bytes from /dev/random
> >
> >
> > Is this a bug? Should it be using /dev/urandom instead?
>
> That's clearly a bug. It should just use OpenSSL which it links to
> anyway to get random numbers. OpenSSL uses getrandom() to get entropy
> from the kernel to seed its RNG.

Upstream list hasn't been available the two times I've checked, it
just dead ends. So I filed a bug here:

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

-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1723904] perl-FFI-CheckLib-0.25 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-FFI-CheckLib-0.25-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-2019-441dc1a4d8

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[389-devel] 389 DS nightly 2019-06-27 - 96% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2019/06/27/report-389-ds-base-1.4.1.4-20190626git71138c0.fc30.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[Bug 1723904] perl-FFI-CheckLib-0.25 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-FFI-CheckLib-0.25-1.fc30 has been pushed to the Fedora 30 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-2019-622d40ab09

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/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
 316  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d   
condor-8.6.11-1.el7
  91  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-d2c1368294   
cinnamon-3.6.7-5.el7
  84  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-50a6a1ddfd   
afflib-3.7.18-2.el7
  57  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80   
python-gnupg-0.4.4-1.el7
  55  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b   
bubblewrap-0.3.3-2.el7
  27  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-fc63c75ab1   
hostapd-2.8-1.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-24edff97c6   
php-brumann-polyfill-unserialize-1.0.3-1.el7 
php-typo3-phar-stream-wrapper2-2.1.2-1.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f428efb17c   
drupal7-uuid-1.3-1.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-193cafec2e   
GraphicsMagick-1.3.32-1.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-7a3942050d   
nodejs-6.17.1-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-a7d80aae2a   
pdns-4.1.10-1.el7


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

cekit-3.2.0-1.el7
lammps-20190605-4.el7

Details about builds:



 cekit-3.2.0-1.el7 (FEDORA-EPEL-2019-4e5de37821)
 Container image creation tool

Update Information:

Release 3.2.0

ChangeLog:

* Wed Jun 26 2019 Marek Goldmann  - 3.2.0-1
- Release 3.2.0




 lammps-20190605-4.el7 (FEDORA-EPEL-2019-5bceeae18a)
 Molecular Dynamics Simulator

Update Information:

Fix MPI build

ChangeLog:

* Wed Jun 26 2019 Christoph Junghans  - 20190605-4
- Missing MPI build

References:

  [ 1 ] Bug #1724170 - "MPI" versions are actually serial
https://bugzilla.redhat.com/show_bug.cgi?id=1724170


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

[Bug 1721217] perl-String-Compare-ConstantTime-0.321 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-String-Compare-Constan |perl-String-Compare-Constan
   |tTime-0.321-1.fc31  |tTime-0.321-1.fc31
   ||perl-String-Compare-Constan
   ||tTime-0.321-1.fc30
 Resolution|--- |ERRATA
Last Closed||2019-06-27 00:54:49



--- Comment #6 from Fedora Update System  ---
perl-String-Compare-ConstantTime-0.321-1.fc30 has been pushed to the Fedora 30
stable repository. If problems still persist, please make note of it in this
bug report.

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Python means Python3

[Adam Williamson]

On Wed, 2019-06-26 at 21:13 +0100, José Abílio Matos wrote:
> On Wednesday, 26 June 2019 19.07.27 WEST Adam Williamson wrote:
> > Oh, man. I thought we'd decided against this in the past? I'm worried
> > about the cost/benefit ratio on such a change.
> 
> If this were only related with python I would agree with you.
> 
> Yet this also applies to lots of other tools like ipython and probably it 
> could be excluded from this but programs (a development IDE in this case) 
> like 
> spyder also have the * suffix (I am not used to curse but I think that I 
> could use an exception for this).
> 
> It is really, really, annoying to have to type/remember an extra suffix when 
> there are no other options available.
> 
> So even although you have a point all those cases, to me, look a lot like the 
> paper cuts they are very but they really hurt. :-)

That doesn't seem relevant; there's no reason renaming them has to go
together.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS UP] Unannounced soname bump of qrencode

[Rex Dieter]

mcatanz...@gnome.org wrote:

> 
> Let's ensure this at least doesn't happen for the same library again
> and again.
> 
> In [1], change SHOULD NOT -> MUST NOT.
> 
> Require maintainers (or provenpackagers) to fix violations like [2]
> when unannounced soname bumps occur.

Then may be worth mentioning this is intended for libraries providing a 
public api, ie, private libraries are generally exempted.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

always update the bootloader during major upgrades

[Chris Murphy]

Hi,

This is not a formal proposal, this is for discussion and identifying
liabilities. This email has an x86 GRUB bias only because that's the
bootloader regime I'm most familiar with. I think it should apply to
other archs as well, i.e. their bootloaders shouldn't be permitted to
become stale.

Short version: Fedora should take responsibility for the bootloader
being up to date, by updating it during major version upgrades. This
is already the case on UEFI with conventional installations. I'd like
to make sure it always happens on major version upgrades for BIOS
installations. What's the problem? This would step on any custom
bootloader configuration a user has for multiboot. There is no
reasonable mechanism on BIOS systems to determine if the bootloader is
a Fedora bootloader, and somehow only update a Fedora bootloader and
not touch any other bootloader.

Fedora should be responsible for keeping the bootloader it installs in
~80% of the use cases up-to-date; and ignore the fallout from the ~20%
who have a custom setup that would be stepped on by a forced
bootloader update. The former is a feature and security risk, by
allowing the bootloader to go stale over time. The latter is an
inconvenience.

Longer version:

terms:

bootloader  - this is the pre-boot bootloader binaries; on BIOS it's
embedded in the MBR, and the MBR gap or BIOS Boot partition, and
modules found in /boot/grub2 on Fedora. On UEFI, this is the
/EFI/fedora/shimx64.efi and /EFI/fedora/grubx64.efi which in the
typical installation are built and signed by the Fedora build system.
Other bootloaders have different names but generally follow a similar
convention, the point here is to distinguish between the "bootloader"
which runs in the pre-boot environment, and the installed package
containing user space tools that are used to install (or contain) the
bootloader.

Fedora bootloader - this is a bootloader that is derived from Fedora
packages and effort; as contrasted to merely upstream GRUB, or
Ubuntu's GRUB, etc. as these derivatives can actually be substantially
different from each other.

Discussion:

Both gnome-software (pk-offline-update), and dnf system-upgrade, on
BIOS firmware x86 computers, do not update the bootloader. That is, we
do not run 'grub2-install' either before starting an upgrade, or as a
post install operation following an upgrade. Therefore the bootloader
will become stale if the user does not manually run 'grub2-install'
periodically.

On conventional Fedora installations on UEFI computers, the bootloader
is included in the shim and grub2 packages as a file, and is therefore
updated. This happens sporadically within a Fedora release, not only
at major upgrade time. This updating of the bootloader files doesn't
happen on Silverblue on UEFI, so it ends up being subject to the same
problem under discussion.

In the most recent release, Fedora 30, we saw quite a lot of people
run into a problem we knew about before release, directly related to
the bootloader becoming stale. And it only affected BIOS systems (and
Silverblue on both firmware types).
https://fedoraproject.org/wiki/Common_F30_bugs#blscfg-fail
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1652806

In the bug, you can find some dups as well but also quite a bit of
user aggravation. I'd like to avoid this going forward.

Windows and macOS never involved users in this stuff. They always
asserted complete and total domain over the bootloader, there wasn't
even an option to avoid updating it. And I think Fedora needs to do
the same. Just update it. That benefits most users. It's the
responsible thing to do. And those who need custom setups, can still
do that. It would only get stepped on at major upgrade time. And it's
decently likely we can warn them in advance.

There are some gotchas I'm already thinking of: MBR gap is too small,
there are multiple drives and it's ambiguous which one should get the
bootloader, and so on. I think it's sane to have a test for reasonable
certainty we can and should update the bootloader, and warn and not
update it in the cases that fail that test.

Thoughts?


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Python means Python3

[José Abílio Matos]

On Wednesday, 26 June 2019 19.07.27 WEST Adam Williamson wrote:
> Oh, man. I thought we'd decided against this in the past? I'm worried
> about the cost/benefit ratio on such a change.

If this were only related with python I would agree with you.

Yet this also applies to lots of other tools like ipython and probably it 
could be excluded from this but programs (a development IDE in this case) like 
spyder also have the * suffix (I am not used to curse but I think that I 
could use an exception for this).

It is really, really, annoying to have to type/remember an extra suffix when 
there are no other options available.

So even although you have a point all those cases, to me, look a lot like the 
paper cuts they are very but they really hurt. :-)

Regards,
-- 
José Abílio

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

Re: Fedora 31 System-Wide Change proposal: Python means Python3

[Adam Williamson]

On Wed, 2019-06-26 at 13:57 -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Python_means_Python3
> 
> == Summary ==
> In package and command names, "Python" will mean "Python 3".
> 
> Users installing and running Python or Python packages without
> specifying a version will get Python 3.
> 
> Running python will run python3.

Oh, man. I thought we'd decided against this in the past? I'm worried
about the cost/benefit ratio on such a change.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 31 System-Wide Change proposal: Python means Python3

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Python_means_Python3

== Summary ==
In package and command names, "Python" will mean "Python 3".

Users installing and running Python or Python packages without
specifying a version will get Python 3.

Running python will run python3. Running
pytest will run the Python 3 version of pytest, and
similarly for pydoc, pylint, etc.

dnf install python will install {{package|python3}}, and
similarly for other python-* provides, e.g. dnf
install python-requests will install
{{package|python3-requests}}.

This is the final preparation for
[https://fedoraproject.org/wiki/Changes/RetirePython2 the retirement
of Python 2 in Fedora 32] done in line with the
[https://github.com/python/peps/pull/989 soon to be finalized]
upstream recommendations.

== Owner ==
* Name: [[User:Churchyard| Miro Hrončok]]
* Name: [[User:Pviktori| Petr Viktorin]]
* Email: 


== Detailed Description ==

=== Motivation ===

The final upstream release of Python 2 is planned for January 2020. No
further fixes will be made upstream. Most of Fedora 31's lifetime is
after that date. Python 2 will be maintained only by its Fedora
maintainers.

In preparation for removing Python 2 from Fedora entirely, we will
make the unqualified name "Python" refer to the fully supported
version.

This is in line with upstream changes to
[https://www.python.org/dev/peps/pep-0394/ PEP 394] recommendations.
(At the time of this writing, these changes are still
[https://github.com/python/peps/pull/989 being finalized], but
recommendations for Linux distributions are accepted.)

This completes the work started with Fedora 23's
[https://fedoraproject.org/wiki/Changes/Python_3_as_Default "Python 3
as Default"] change, with only
[https://fedoraproject.org/wiki/Changes/RetirePython2 removing Python
2] left to do.

=== What is being changed ===

The following changes will be made both in the
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/
Python packaging guidelines] and the actual packages.

 Package provides 

'''Before:''' Packages with Python 2 modules used to provide the
unversioned python- name. Users could do dnf
install python-requests and the {{package|python2-requests}}
package would be installed.

'''After:''' Packages with Python 3 modules will provide the
unversioned python- name. Users can do dnf install
python-requests and the {{package|python3-requests}} package
will be installed.

This applies to the {{package|python3}}/{{package|python2}} package as
well as packages with Python modules. dnf install python
will install {{package|python3}}.

The vast majority of packages will be updated by changing
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_the_python_provide_macro
the %python-provide macro], with no changes in the individual spec
files. The change owners will change the macro before the mass
rebuild.

 Python command 

'''Before:''' The /usr/bin/python command was a symbolic
link to /usr/bin/python2 living in the
{{package|python-unversioned-command}} subpackage of
{{package|python2}}. {{package|python2}} recommended
{{package|python-unversioned-command}}, so most users got the command
by default when {{package|python2}} was installed.

'''After:''' The /usr/bin/python command will be a
symbolic link to /usr/bin/python3 living in the
{{package|python-unversioned-command}} subpackage of
{{package|python3}}. {{package|python3}} will recommend
{{package|python-unversioned-command}}, so most users will get the
command by default when {{package|python3}} is installed (and it is
installed by default).


 Other commands 

Similarly, the Python-specific commands will switch from Python 2 to
Python 3. This includes at least the following commands:

* pip
* python-config
* wheel
* idle
* pydoc
* pytest
* nosetest
* pycodestyle
* pylint
* epylint
* pyreverse
* symilar
* unit2
* msgfmt.py
* pygettext.py
* flask
* ipython
* f2py
* ipdb
* easy_install
* ...

This list is incomplete, automation is yet to be created to discover
all such commands.

Note that applications like pygmentize or
cython, whose behavior doesn't depend on the Python
version, are not affected. (By current guidelines, they should be
already using Python 3 if possible.)

=== Changes needed by Python package maintainers ===

This section of the change covers action needed from Python package
maintainers. Most of the packages need no change, but there are
several exceptions.


 Packages with ambiguous names 

Tracked at: https://fedora.portingdb.xyz/namingpolicy/

If your package with a Python 2 module or plugin is named with
unversioned python (such as for example
claws-mail-plugins-python or PyQt4), it
needs to be removed or renamed to have python2 in the
name (such as, for example, claws-mail-plugins-python2 or
python2-PyQt4).

If your package is an application that happens to be written in Python
2 (such as {{package|calibre}}), no renaming is needed (applications
don't need the python-, 

Fedora 31 System-Wide Change proposal: Python means Python3

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Python_means_Python3

== Summary ==
In package and command names, "Python" will mean "Python 3".

Users installing and running Python or Python packages without
specifying a version will get Python 3.

Running python will run python3. Running
pytest will run the Python 3 version of pytest, and
similarly for pydoc, pylint, etc.

dnf install python will install {{package|python3}}, and
similarly for other python-* provides, e.g. dnf
install python-requests will install
{{package|python3-requests}}.

This is the final preparation for
[https://fedoraproject.org/wiki/Changes/RetirePython2 the retirement
of Python 2 in Fedora 32] done in line with the
[https://github.com/python/peps/pull/989 soon to be finalized]
upstream recommendations.

== Owner ==
* Name: [[User:Churchyard| Miro Hrončok]]
* Name: [[User:Pviktori| Petr Viktorin]]
* Email: 


== Detailed Description ==

=== Motivation ===

The final upstream release of Python 2 is planned for January 2020. No
further fixes will be made upstream. Most of Fedora 31's lifetime is
after that date. Python 2 will be maintained only by its Fedora
maintainers.

In preparation for removing Python 2 from Fedora entirely, we will
make the unqualified name "Python" refer to the fully supported
version.

This is in line with upstream changes to
[https://www.python.org/dev/peps/pep-0394/ PEP 394] recommendations.
(At the time of this writing, these changes are still
[https://github.com/python/peps/pull/989 being finalized], but
recommendations for Linux distributions are accepted.)

This completes the work started with Fedora 23's
[https://fedoraproject.org/wiki/Changes/Python_3_as_Default "Python 3
as Default"] change, with only
[https://fedoraproject.org/wiki/Changes/RetirePython2 removing Python
2] left to do.

=== What is being changed ===

The following changes will be made both in the
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/
Python packaging guidelines] and the actual packages.

 Package provides 

'''Before:''' Packages with Python 2 modules used to provide the
unversioned python- name. Users could do dnf
install python-requests and the {{package|python2-requests}}
package would be installed.

'''After:''' Packages with Python 3 modules will provide the
unversioned python- name. Users can do dnf install
python-requests and the {{package|python3-requests}} package
will be installed.

This applies to the {{package|python3}}/{{package|python2}} package as
well as packages with Python modules. dnf install python
will install {{package|python3}}.

The vast majority of packages will be updated by changing
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_the_python_provide_macro
the %python-provide macro], with no changes in the individual spec
files. The change owners will change the macro before the mass
rebuild.

 Python command 

'''Before:''' The /usr/bin/python command was a symbolic
link to /usr/bin/python2 living in the
{{package|python-unversioned-command}} subpackage of
{{package|python2}}. {{package|python2}} recommended
{{package|python-unversioned-command}}, so most users got the command
by default when {{package|python2}} was installed.

'''After:''' The /usr/bin/python command will be a
symbolic link to /usr/bin/python3 living in the
{{package|python-unversioned-command}} subpackage of
{{package|python3}}. {{package|python3}} will recommend
{{package|python-unversioned-command}}, so most users will get the
command by default when {{package|python3}} is installed (and it is
installed by default).


 Other commands 

Similarly, the Python-specific commands will switch from Python 2 to
Python 3. This includes at least the following commands:

* pip
* python-config
* wheel
* idle
* pydoc
* pytest
* nosetest
* pycodestyle
* pylint
* epylint
* pyreverse
* symilar
* unit2
* msgfmt.py
* pygettext.py
* flask
* ipython
* f2py
* ipdb
* easy_install
* ...

This list is incomplete, automation is yet to be created to discover
all such commands.

Note that applications like pygmentize or
cython, whose behavior doesn't depend on the Python
version, are not affected. (By current guidelines, they should be
already using Python 3 if possible.)

=== Changes needed by Python package maintainers ===

This section of the change covers action needed from Python package
maintainers. Most of the packages need no change, but there are
several exceptions.


 Packages with ambiguous names 

Tracked at: https://fedora.portingdb.xyz/namingpolicy/

If your package with a Python 2 module or plugin is named with
unversioned python (such as for example
claws-mail-plugins-python or PyQt4), it
needs to be removed or renamed to have python2 in the
name (such as, for example, claws-mail-plugins-python2 or
python2-PyQt4).

If your package is an application that happens to be written in Python
2 (such as {{package|calibre}}), no renaming is needed (applications
don't need the python-, 

Planned Outage - fedoraproject.org/wiki - 2019-06-27 21:00 UTC

[Kevin Fenzi]

Planned Outage - fedoraproject.org/wiki - 2019-06-27 21:00 UTC

There will be an outage starting at 2019-06-27 21:00 UTC ,
which will last approximately 2 hours.

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

date -d '2019-06-27 21:00UTC'

Reason for outage:

We will be updating the nodes running mediawiki to Fedora 30 and thus
also upgrading mediawiki to a newer version. The last scheduled upgrade
was aborted due to some issues found in staging. These issues have been
fixed and we are ready to finally upgrade.

Affected Services:

https://fedoraproject.org/wiki

Ticket Link:

https://pagure.io/fedora-infrastructure/issue/7942

Please join #fedora-admin or #fedora-noc on irc.freenode.net
or add comments to the ticket for this outage above.



signature.asc
Description: OpenPGP digital signature
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

Planned Outage - fedoraproject.org/wiki - 2019-06-27 21:00 UTC

[Kevin Fenzi]

Planned Outage - fedoraproject.org/wiki - 2019-06-27 21:00 UTC

There will be an outage starting at 2019-06-27 21:00 UTC ,
which will last approximately 2 hours.

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

date -d '2019-06-27 21:00UTC'

Reason for outage:

We will be updating the nodes running mediawiki to Fedora 30 and thus
also upgrading mediawiki to a newer version. The last scheduled upgrade
was aborted due to some issues found in staging. These issues have been
fixed and we are ready to finally upgrade.

Affected Services:

https://fedoraproject.org/wiki

Ticket Link:

https://pagure.io/fedora-infrastructure/issue/7942

Please join #fedora-admin or #fedora-noc on irc.freenode.net
or add comments to the ticket for this outage above.



signature.asc
Description: OpenPGP digital signature
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 Self-Contained Change proposal: Include several modules in the EFI build of Grub2 for security use-cases

[Benjamin Doron]

Hi all,
I've written some scripts to help with the signature verification aspect of 
this change. I've attempted to have them seamlessly handle different 
environments, but please let me know if you observe any misbehaviour. I'd 
particularly like to get input on the second script. The first can setup a 
system for signature verification only if the relevant modules are made 
available separately. Also, compare the steps the script takes with the wiki 
page. The script assumes that the modules are loaded by default (they are once 
they're included in the build) too. Check steps 2 and 3 in the "verify" portion 
of the How To Test section for what is missing (So, this is definitely useful 
after F31's release, but can be convenient now too).

Thanks.



grub2-switch-to-verify:
#!/bin/bash

## This, for now, is a holistic script. It assumes that we've either configured 
signature verification, or not.
## This will need to be changed. Individual scripts should check for their 
files, and call on a central script (or
## function therein) to configure things otherwise.

if [[ $(id -u) != 0 ]]; then
echo "You must run this script as root"
exit 1
fi

sata_or_nvme=$(if [[ $(mount | grep "/boot/efi" | cut -d " " -f 1) =~ 
(/dev/nvme*|/dev/mmcblk*) ]]; then echo 3; else echo 2; fi)
drive_num=$(lsblk | grep /boot/efi | cut -d " " -f 1 | cut -c 3- | rev | cut -c 
$sata_or_nvme- | rev)
part_type=$(fdisk /dev/$drive_num -l | grep "Disklabel type" | cut -d " " -f 3)
ESP_partnum=$(lsblk | grep /boot/efi | cut -c 6)
#export GPG_TTY=$(tty)

function firstrun {
touch /var/tmp/grub_verify-pgp_pass
chmod 600 /var/tmp/grub_verify-pgp_pass
gpg --gen-random --armor 0 24 > /var/tmp/grub_verify-pgp_pass
gpg --pinentry-mode loopback --batch --quick-generate-key --passphrase-file 
/var/tmp/grub_verify-pgp_pass "Grub_verify testing key" rsa sign never
gpg --export "Grub_verify testing key" > /boot/efi/EFI/fedora/pubkey
echo "
trust (hd0,$part_type$ESP_partnum)/efi/fedora/pubkey --skip-sig
set check_signatures=enforce" >> /etc/grub.d/40_custom
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
resign
}

function resign {
for x in $(find /boot -name "*.cfg.sig" -or -name "*.lst.sig" -or -name 
"*.mod.sig" -or -name "vmlinuz*.sig" -or -name "initramfs*.sig" -or -name 
"grubenv.sig"); do rm -f "$x"; done
for x in $(find /boot -name "*.cfg" -or -name "*.lst" -or -name "*.mod" -or 
-name "vmlinuz*" -or -name "initramfs*" -or -name "grubenv"); do gpg --batch 
--detach-sign -u "Grub_verify testing key" --pinentry-mode loopback 
--passphrase-fd 0 "$x" < /var/tmp/grub_verify-pgp_pass; done
}

if [ ! -f /boot/efi/EFI/fedora/grub.cfg.sig ]; then
firstrun
exit 0
else
resign
exit 0
fi


grub_verify-kern-postinst:
#!/bin/bash

## This is only going to address the kernel and initramfs (we're tacking on 
grubenv, as it is edited concurrently with
## kernel upgrades. However, "savedentry" might only change after a reboot. 
This requires further testing). While these
## are the most frequently modified, those with certain configurations will 
need to keep an eye on things.
##
## Thankfully, the new BootLoaderSpec format ensures that grub.cfg is rarely 
modified. The large majority of users don't
## use custom.cfg and user.cfg is generally on written once. An initial round 
of signing should cover all of this.
## grubenv will be resigned by this version of the script, but requires further 
testing.
## The default configuration doesn't allow for inserting modules, so we don't 
need to resign any of them. While this can
## hopefully be changed with Grub's 2.04 release, by that time additional 
module loading can be automated
## per-environment with patches to grub2-mkconfig.
##
## Once/if we turn on signature verification by default, all of the above will 
be handled with patches to the relevant
## scripts.

## It's unlikely that we'll hit this, but we need to be sure in case we're run 
directly.
if [[ $(id -u) != 0 ]]; then
echo "You must run this script as root"
exit 1
fi

old_sigs=$(for x in $(find /boot -name "vmlinuz*.sig" -or -name 
"initramfs*.sig" | grep -v rescue | sed 's/.sig//'); do if [[ "$x" != "$(rpm 
-ql kernel-core | grep -e /boot/vmlinuz -e /boot/initramfs | grep "$x")" ]]; 
then echo "$x"; fi; done)
new_uname_r=$(rpm -qa --last kernel | head -n 1 | cut -d " " -f 1 | sed 
's/kernel-//')

for x in $old_sigs; do rm -f "$x.sig"; done
for x in $(find /boot -name "grubenv.sig"); do rm -f "$x"; done
for x in $(find /boot -name "vmlinuz-$new_uname_r" -or -name 
"initramfs-$new_uname_r.img" -or -name "grubenv"); do gpg --batch --detach-sign 
-u "Grub_verify testing key" --pinentry-mode loopback --passphrase-fd 0 "$x" < 
/var/tmp/grub_verify-pgp_pass; done
exit 0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 

Re: adding speech installation to fedora network installation image

[stan via devel]

On Wed, 26 Jun 2019 14:26:14 +0200
Mmobilea  wrote:

> Hello,
> I’m new blind user of fedora 30. I couldn’t find where to post this
> request. I have small pendrive, and I must use network installer.
> Howewer orca or speakup doesn’t run on it. Could you add speech to
> the installer? Sorry for my English, i’m from Poland
 
Nothing wrong with your English.  Orca requires a desktop (graphical
user interface) to run, and the server netinstall image does not have a
desktop. And, from what I can find on the web, the Fedora kernels do
not include speakup because it is not considered part of the stable
kernel tree, so it would be difficult to add speech support.

I suggest you try the network installer for fedora workstation.  It
uses gnome, which has the best linux accessibility interfaces, and is
the same size as the server netinstall image.  Because of the size
restriction, the accessibility interfaces might be limited, though.

https://download.fedoraproject.org/pub/fedora/linux/releases/30/Workstation/x86_64/iso/Fedora-Workstation-netinst-x86_64-30-1.2.iso
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Final reminder: F31 Change proposals that require infra changes due today

[Ben Cotton]

If you have a Change proposal that requires changes to Infrastructure,
those proposals must be submitted (i.e. in ChangeReadyForWrangler
category) today, 26 June.

Other deadlines approaching:
* 2019-07-02 — Changes requiring mass rebuild
* 2019-07-02 — System-Wide changes
* 2019-07-23 — Self-contained changes

For more development milestones in the F31 schedule, see:
https://fedorapeople.org/groups/schedule/f-31/f-31-devel-tasks.html

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

Final reminder: F31 Change proposals that require infra changes due today

[Ben Cotton]

If you have a Change proposal that requires changes to Infrastructure,
those proposals must be submitted (i.e. in ChangeReadyForWrangler
category) today, 26 June.

Other deadlines approaching:
* 2019-07-02 — Changes requiring mass rebuild
* 2019-07-02 — System-Wide changes
* 2019-07-23 — Self-contained changes

For more development milestones in the F31 schedule, see:
https://fedorapeople.org/groups/schedule/f-31/f-31-devel-tasks.html

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Bootstrapped Packages

[Brian (bex) Exelbierd]

Thank you all for your offers of help.  I got pinged on IRC and got
help from besser82 which when combined with what I've heard from
churchyard in the past and the commits that Vit cited made it make
sense.

I've submitted a PR
https://pagure.io/packaging-committee/pull-request/910 to the
Packaging Guide to try and help anyone who follows me.  Edits and
Reviews are greatly appreciated.

regards,

bex

On Wed, Jun 26, 2019 at 2:04 PM Vít Ondruch  wrote:
>
>
> Dne 26. 06. 19 v 13:11 Miroslav Suchý napsal(a):
> > Dne 26. 06. 19 v 12:53 Brian (bex) Exelbierd napsal(a):
> >> Can someone point me at step by step instructions for how to handle
> >> new packages that require bootstrapping because of a circular
> >> depedency?
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping
> >
> >
>
> I did recently bootstrap build of rubygem-cucumber [1] in three steps.
>
>
> 1) Update of the Cucumber.
>
> https://src.fedoraproject.org/rpms/rubygem-cucumber/c/dd56251feac749f1729c9ad6b663cc779ea3fa2a?branch=master
>
>
> 2) Bootstrap build enabled.
>
> https://src.fedoraproject.org/rpms/rubygem-cucumber/c/fcf13af7b086c4bd06091ee63e025f57c02f1576?branch=master
>
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1217092
>
>
> 3) Bootstrap disabled for official build
>
> https://src.fedoraproject.org/rpms/rubygem-cucumber/c/6b5855729723d0578a25577a9a70b7e77ac52a41?branch=master
>
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1217098
>
>
> Of course the 2nd commit was there just to make the revert commit easier.
>
>
> Vít
>
>
>
> [1]:
> https://src.fedoraproject.org/rpms/rubygem-cucumber/blob/master/f/rubygem-cucumber.spec
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Brian "bex" Exelbierd (he/him/his)
Fedora Community Action & Impact Coordinator
@bexelbie | http://www.winglemeyer.org
bexel...@redhat.com | b...@pobox.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1724169] Missing MPLv2.0 in License

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-IO-Socket-SSL-2.066-4.
   ||fc31
 Resolution|--- |RAWHIDE
Last Closed||2019-06-26 15:16:44



--- Comment #1 from Paul Howarth  ---
Fixed in perl-IO-Socket-SSL-2.066-4.fc31

https://src.fedoraproject.org/rpms/perl-IO-Socket-SSL/c/030559c4b0c18576c7089bf3e4efa1ee9f689aa2
https://koji.fedoraproject.org/koji/taskinfo?taskID=35844506

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: [HEADS UP] Unannounced soname bump of qrencode

[Stephen John Smoogen]

On Wed, 26 Jun 2019 at 11:02, Jerry James  wrote:

> On Wed, Jun 26, 2019 at 4:01 AM Miro Hrončok  wrote:
> > $ rg -lF '.so*' rpm-specs/ | env LANG=en_US.utf8 sort
>
> [snip]
>
> > rpm-specs/coin-or-Ipopt.spec
>
> I am planning to fix this one soon as part of a general revamping of
> all of the coin-or-* packages.  But I'm curious.  Why is this the only
> one to show up on your list?  The coin-or-Alps and coin-or-Osi
> packages, for example, should have appeared here, but didn't.
>


I am expecting it was a quick and easy "let me see how much is in a small
amount of what I have on my system from a snapshot I took months ago". I
mean it wasn't meant to be a 'this is broke fix it' it was a 'here is how
many times .so shows up.'



> --
> Jerry James
> http://www.jamezone.org/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS UP] Unannounced soname bump of qrencode

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jun 26, 2019 at 04:34:00PM +0200, Miro Hrončok wrote:
> On 26. 06. 19 16:16, Jerry James wrote:
> >On Wed, Jun 26, 2019 at 4:01 AM Miro Hrončok  wrote:
> >>$ rg -lF '.so*' rpm-specs/ | env LANG=en_US.utf8 sort
> >
> >[snip]
> >
> >>rpm-specs/coin-or-Ipopt.spec
> >
> >I am planning to fix this one soon as part of a general revamping of
> >all of the coin-or-* packages.  But I'm curious.  Why is this the only
> >one to show up on your list?  The coin-or-Alps and coin-or-Osi
> >packages, for example, should have appeared here, but didn't.
> 
> 
> Becasue they don't have .so* but .so.*:
> 
> $ rg -lF '.so.*' rpm-specs/ | env LANG=en_US.utf8 sort | wc -l
> 2121
> 
> $ rg -lF '.so.*' rpm-specs/ | env LANG=en_US.utf8 sort

That's both not enough, because some specs have no leading dot,
e.g. '*so.*', and too much, because it matches comments and such.

I think this is better:
$ rg -l '^%\{?_libdir\}?/[^/]*\.?so\.?\*' rpm-specs/ | wc -l
1908
$ rg -l '^%\{?_libdir\}?/[^/]*\.?so\.?\*' rpm-specs/ | LANG=en_US.utf8 sort
389-admin.spec
389-adminutil.spec
389-ds-base.spec
a2ps.spec
a52dec.spec
aalib.spec
abc.spec
abrt.spec
accountsservice.spec
aces_container.spec
acl.spec
activemq-cpp.spec
adevs.spec
admesh.spec
adplug.spec
afflib.spec
afpfs-ng.spec
ahven.spec
aiksaurus.spec
airinv.spec
airrac.spec
airspyone_host.spec
airtsp.spec
alembic.spec
alfont.spec
AllegroOGG.spec
alltray.spec
alure.spec
amanith.spec
amftools.spec
ampache_browser.spec
am-utils.spec
anaconda.spec
anet.spec
angelscript.spec
anjuta.spec
ann.spec
anthy.spec
AntTweakBar.spec
apbs.spec
apiextractor.spec
apron.spec
apr.spec
apr-util.spec
apt.spec
aqbanking.spec
aqsis.spec
argtable.spec
argyllcms.spec
arpack.spec
arprec.spec
arts.spec
aspell.spec
assimp.spec
astrometry.spec
atkmm.spec
atk.spec
atlascpp.spec
atril.spec
at-spi2-atk.spec
at-spi2-core.spec
attr.spec
aubio.spec
audacious.spec
augeas.spec
authselect.spec
autotrace.spec
avahi.spec
avogadro2-libs.spec
babeltrace.spec
babl.spec
bamf.spec
barry.spec
bcc.spec
bcg729.spec
beecrypt.spec
bes.spec
bibutils.spec
bio2jack.spec
blackbox.spec
bliss.spec
blitz.spec
bluez.spec
bogl.spec
boinc-client.spec
bookkeeper.spec
botan2.spec
botan.spec
Box2D.spec
brasero.spec
brial.spec
bristol.spec
brltty.spec
bro.spec
bullet.spec
cairomm.spec
cairo.spec
caja.spec
calamares.spec
calc.spec
calligra.spec
cantor.spec
capnproto.spec
capstone.spec
c-ares.spec
CCfits.spec
ccnet.spec
ccrtp.spec
cddlib.spec
cdk.spec
cdparanoia.spec
cdrkit.spec
cegui.spec
ceph.spec
ceres-solver.spec
CGSI-gSOAP.spec
CharLS.spec
check.spec
cheese.spec
CheMPS2.spec
cherokee.spec
chicken.spec
chipmunk.spec
chmlib.spec
chromaprint.spec
cinnamon-desktop.spec
cinnamon-menus.spec
cinnamon-screensaver.spec
cjose.spec
cjs.spec
ck.spec
clalsadrv.spec
clang.spec
ClanLib06.spec
ClanLib1.spec
ClanLib.spec
cld2.spec
clipper.spec
clipsmm.spec
clips.spec
cliquer.spec
cln.spec
cloog.spec
clthreads.spec
clutter-gst3.spec
clutter-gtk.spec
cluttermm.spec
clxclient.spec
cmigemo.spec
cminpack.spec
cmocka.spec
cmockery2.spec
cmrt.spec
cocoalib.spec
codeblocks.spec
codec2.spec
Coin2.spec
Coin3.spec
coin-or-Alps.spec
coin-or-Bcp.spec
coin-or-Bcps.spec
coin-or-Blis.spec
coin-or-Bonmin.spec
coin-or-Cbc.spec
coin-or-Cgl.spec
coin-or-Clp.spec
coin-or-CoinMP.spec
coin-or-CoinUtils.spec
coin-or-Couenne.spec
coin-or-Dip.spec
coin-or-DyLP.spec
coin-or-FlopC++.spec
coin-or-Ipopt.spec
coin-or-lemon.spec
coin-or-Osi.spec
coin-or-OS.spec
coin-or-SYMPHONY.spec
coin-or-Vol.spec
collada-dom.spec
colord-gtk.spec
ColPack.spec
comedilib.spec
commoncpp2.spec
compat-guichan05.spec
compat-guile18.spec
compat-libicu62.spec
compat-libvpx5.spec
compat-readline5.spec
compat-SFML16.spec
compface.spec
compiz.spec
concordance.spec
condor.spec
console-bridge.spec
corosync.spec
cpl.spec
cpp-hocon.spec
cppmyth.spec
cpptest.spec
CQRlib.spec
cracklib.spec
createrepo_c.spec
criu.spec
crlibm.spec
crossguid2.spec
crossguid.spec
cryptominisat.spec
cryptsetup.spec
csdp.spec
ctemplate.spec
ctk.spec
CTL.spec
ctpl.spec
cudd.spec
cuetools.spec
cuneiform.spec
CUnit.spec
curlpp.spec
cutter.spec
CVector.spec
cxxtools.spec
cyrus-imapd.spec
cyrus-sasl.spec
daala.spec
dahdi-tools.spec
dapl.spec
dar.spec
datalog.spec
dataquay.spec
dateshift.spec
davix.spec
dbh.spec
dbus-glib.spec
dbus-qt3.spec
dbus.spec
dcap.spec
dcmtk.spec
ddccontrol.spec
deepin-file-manager.spec
deepin-metacity.spec
deepin-mutter.spec
deepin-qt-dbus-factory.spec
deepin-wm.spec
dee.spec
device-mapper-multipath.spec
DevIL.spec
dieharder.spec
diet.spec
diffmark.spec
ding-libs.spec
discount.spec
dislocker.spec
djvulibre.spec
dleyna-core.spec
dlib.spec
dlm.spec
dmlite.spec
dmraid.spec
dnssec-tools.spec
dolphin-connector.spec
dontpanic.spec
doodle.spec
dotconf.spec
dpdk.spec
dpm-dsi.spec
drawtk.spec
drpm.spec
drumkv1.spec
drumstick0.spec
drumstick.spec
DSDP.spec
dSFMT.spec
dspam.spec
dtc.spec
dtkwidget.spec
duktape.spec
dvblinkremote.spec
dwarves.spec
dx.spec
dynafed.spec
dynamite.spec
dynaplugz.spec
e16-epplets.spec
e2fsprogs.spec
eb.spec

Re: [HEADS UP] Unannounced soname bump of qrencode

[Miro Hrončok]

On 26. 06. 19 16:16, Jerry James wrote:

On Wed, Jun 26, 2019 at 4:01 AM Miro Hrončok  wrote:

$ rg -lF '.so*' rpm-specs/ | env LANG=en_US.utf8 sort


[snip]


rpm-specs/coin-or-Ipopt.spec


I am planning to fix this one soon as part of a general revamping of
all of the coin-or-* packages.  But I'm curious.  Why is this the only
one to show up on your list?  The coin-or-Alps and coin-or-Osi
packages, for example, should have appeared here, but didn't.



Becasue they don't have .so* but .so.*:

$ rg -lF '.so.*' rpm-specs/ | env LANG=en_US.utf8 sort | wc -l
2121

$ rg -lF '.so.*' rpm-specs/ | env LANG=en_US.utf8 sort
rpm-specs/389-admin.spec
rpm-specs/389-adminutil.spec
rpm-specs/389-ds-base.spec
rpm-specs/a52dec.spec
rpm-specs/aalib.spec
rpm-specs/abc.spec
rpm-specs/abrt.spec
rpm-specs/accountsservice.spec
rpm-specs/aces_container.spec
rpm-specs/acl.spec
rpm-specs/activemq-cpp.spec
rpm-specs/adevs.spec
rpm-specs/admesh.spec
rpm-specs/adns.spec
rpm-specs/adplug.spec
rpm-specs/afflib.spec
rpm-specs/afpfs-ng.spec
rpm-specs/ahven.spec
rpm-specs/aiksaurus.spec
rpm-specs/airinv.spec
rpm-specs/airrac.spec
rpm-specs/airspyone_host.spec
rpm-specs/airtsp.spec
rpm-specs/akonadiconsole.spec
rpm-specs/akregator.spec
rpm-specs/alembic.spec
rpm-specs/alfont.spec
rpm-specs/AllegroOGG.spec
rpm-specs/allegro.spec
rpm-specs/alliance.spec
rpm-specs/alsa-lib.spec
rpm-specs/alure.spec
rpm-specs/amanda.spec
rpm-specs/amanith.spec
rpm-specs/amftools.spec
rpm-specs/ampache_browser.spec
rpm-specs/anaconda.spec
rpm-specs/anet.spec
rpm-specs/angelscript.spec
rpm-specs/anjuta.spec
rpm-specs/ann.spec
rpm-specs/anthy.spec
rpm-specs/AntTweakBar.spec
rpm-specs/apbs.spec
rpm-specs/apiextractor.spec
rpm-specs/apron.spec
rpm-specs/apr.spec
rpm-specs/apr-util.spec
rpm-specs/apt.spec
rpm-specs/aqbanking.spec
rpm-specs/aqsis.spec
rpm-specs/arb.spec
rpm-specs/ardour5.spec
rpm-specs/argtable.spec
rpm-specs/argyllcms.spec
rpm-specs/ark.spec
rpm-specs/arpack.spec
rpm-specs/arprec.spec
rpm-specs/arts.spec
rpm-specs/aspell.spec
rpm-specs/assimp.spec
rpm-specs/astrometry.spec
rpm-specs/atkmm.spec
rpm-specs/atk.spec
rpm-specs/atlascpp.spec
rpm-specs/atlas.spec
rpm-specs/atril.spec
rpm-specs/at-spi2-atk.spec
rpm-specs/at-spi2-core.spec
rpm-specs/attr.spec
rpm-specs/aubio.spec
rpm-specs/audacious.spec
rpm-specs/augeas.spec
rpm-specs/authselect.spec
rpm-specs/autogen.spec
rpm-specs/autotrace.spec
rpm-specs/avahi.spec
rpm-specs/avogadro2-libs.spec
rpm-specs/babeltrace.spec
rpm-specs/babl.spec
rpm-specs/baloo-widgets.spec
rpm-specs/bamf.spec
rpm-specs/barry.spec
rpm-specs/bcc.spec
rpm-specs/bcg729.spec
rpm-specs/beecrypt.spec
rpm-specs/bes.spec
rpm-specs/bibutils.spec
rpm-specs/bicon.spec
rpm-specs/bio2jack.spec
rpm-specs/blackbox.spec
rpm-specs/blis.spec
rpm-specs/bliss.spec
rpm-specs/blogilo.spec
rpm-specs/bluez.spec
rpm-specs/bogl.spec
rpm-specs/boinc-client.spec
rpm-specs/bookkeeper.spec
rpm-specs/boost.spec
rpm-specs/botan2.spec
rpm-specs/botan.spec
rpm-specs/Box2D.spec
rpm-specs/brasero.spec
rpm-specs/brial.spec
rpm-specs/bristol.spec
rpm-specs/brltty.spec
rpm-specs/bro.spec
rpm-specs/bullet.spec
rpm-specs/bzip2.spec
rpm-specs/cairo-dock.spec
rpm-specs/cairomm.spec
rpm-specs/cairo.spec
rpm-specs/caja.spec
rpm-specs/calamares.spec
rpm-specs/calc.spec
rpm-specs/calligraplan.spec
rpm-specs/cantor.spec
rpm-specs/capnproto.spec
rpm-specs/capstone.spec
rpm-specs/c-ares.spec
rpm-specs/ccnet.spec
rpm-specs/ccrtp.spec
rpm-specs/cddlib.spec
rpm-specs/cdk.spec
rpm-specs/cdparanoia.spec
rpm-specs/cdrkit.spec
rpm-specs/cegui.spec
rpm-specs/ceph.spec
rpm-specs/ceres-solver.spec
rpm-specs/cfitsio.spec
rpm-specs/CGSI-gSOAP.spec
rpm-specs/CharLS.spec
rpm-specs/check.spec
rpm-specs/cheese.spec
rpm-specs/CheMPS2.spec
rpm-specs/cherokee.spec
rpm-specs/chipmunk.spec
rpm-specs/chmlib.spec
rpm-specs/choqok.spec
rpm-specs/chromaprint.spec
rpm-specs/chromium.spec
rpm-specs/cinnamon-desktop.spec
rpm-specs/cinnamon-menus.spec
rpm-specs/cinnamon-screensaver.spec
rpm-specs/cjose.spec
rpm-specs/cjs.spec
rpm-specs/ck.spec
rpm-specs/clalsadrv.spec
rpm-specs/clang.spec
rpm-specs/ClanLib06.spec
rpm-specs/ClanLib1.spec
rpm-specs/ClanLib.spec
rpm-specs/cld2.spec
rpm-specs/clipper.spec
rpm-specs/clipsmm.spec
rpm-specs/clips.spec
rpm-specs/cliquer.spec
rpm-specs/cln.spec
rpm-specs/cloog.spec
rpm-specs/clthreads.spec
rpm-specs/clutter-gst3.spec
rpm-specs/clutter-gtk.spec
rpm-specs/cluttermm.spec
rpm-specs/clxclient.spec
rpm-specs/cmigemo.spec
rpm-specs/cminpack.spec
rpm-specs/cmocka.spec
rpm-specs/cmockery2.spec
rpm-specs/cmrt.spec
rpm-specs/cocoalib.spec
rpm-specs/codeblocks.spec
rpm-specs/codec2.spec
rpm-specs/code-editor.spec
rpm-specs/Coin2.spec
rpm-specs/Coin3.spec
rpm-specs/coin-or-Alps.spec
rpm-specs/coin-or-Bcp.spec
rpm-specs/coin-or-Bcps.spec
rpm-specs/coin-or-Blis.spec
rpm-specs/coin-or-Bonmin.spec
rpm-specs/coin-or-Cbc.spec
rpm-specs/coin-or-Cgl.spec
rpm-specs/coin-or-Clp.spec
rpm-specs/coin-or-CoinMP.spec
rpm-specs/coin-or-CoinUtils.spec
rpm-specs/coin-or-Couenne.spec

Re: Fedora 31 System-Wide Change proposal: No More i686 Kernels

[Nicolas Mailhot via devel]

Le 2019-06-26 16:07, Josh Boyer a écrit :
On Wed, Jun 26, 2019 at 9:24 AM Roberto Ragusa  
wrote:


On 6/26/19 2:34 AM, Michal Schorm wrote:
> I - and a people around me - have plenty of 32-bit hardware.

Just for the record, I've got a couple of AMD XP2400+, AMD XP2000+ 
machines,

updated to recent Fedora versions and still usable.


So we should be clear here.  The question is not "are people still
using 32-bit hardware?"  The question at hand is whether or not we
believe it to be in Fedora's best interest to sustain that usecase,
with all the effort required to do so.


No just in the best interest. Lots of things would be in Fedora's best 
interest.


Useful enough to motivate someones to donate the time and energy to keep 
it in a good shape. All year round. Doing a good enough job the project 
as a whole feels their use of shared resources (builders, releng, QA 
time, etc) is not a waste.


--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Please update form pep8 to pycodestyle

[José Abílio Matos]

On Wednesday, 26 June 2019 13.03.44 WEST Vít Ondruch wrote:
> I agree with the "# Stop linting code in %%check and measuring coverage,
> this is upstream's business" reasoning. Shouldn't we mention that
> somewhere in guidelines?
> 
> 
> Vít

The funny part is that this consideration applies to more than just python. In 
this case I am thinking as an example in R packages that suffer from the same 
malady. :-)

-- 
José Abílio

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

Re: [HEADS UP] Unannounced soname bump of qrencode

[Jerry James]

On Wed, Jun 26, 2019 at 4:01 AM Miro Hrončok  wrote:
> $ rg -lF '.so*' rpm-specs/ | env LANG=en_US.utf8 sort

[snip]

> rpm-specs/coin-or-Ipopt.spec

I am planning to fix this one soon as part of a general revamping of
all of the coin-or-* packages.  But I'm curious.  Why is this the only
one to show up on your list?  The coin-or-Alps and coin-or-Osi
packages, for example, should have appeared here, but didn't.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: No More i686 Kernels

[Josh Boyer]

On Wed, Jun 26, 2019 at 9:24 AM Roberto Ragusa  wrote:
>
> On 6/26/19 2:34 AM, Michal Schorm wrote:
> > I - and a people around me - have plenty of 32-bit hardware.
>
> Just for the record, I've got a couple of AMD XP2400+, AMD XP2000+ machines,
> updated to recent Fedora versions and still usable.

So we should be clear here.  The question is not "are people still
using 32-bit hardware?"  The question at hand is whether or not we
believe it to be in Fedora's best interest to sustain that usecase,
with all the effort required to do so.  Of course there will always be
people using it if it is done.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: HEADS UP: DynamicBuildRequires are available

[Nicolas Mailhot via devel]

Le 2019-06-26 15:39, Richard W.M. Jones a écrit :

On Tue, Jun 18, 2019 at 03:27:41AM +0200, Igor Gnatenko wrote:



as of today, builders have been updated (thanks to Kevin) and
DynamicBuildRequires finally work in Rawhide.

Change Page: 
https://fedoraproject.org/wiki/Changes/DynamicBuildRequires


I'm curious why the config-for-MM- filename needs to contain the
month and year?  Both why it needs to have a date at all, and why --
if it needs a date -- that doesn't include the day.


It's just an example. It could have used fruit(cake)

I suppose the date call is here to show up the dynamic aspect of the 
feature, though it's a bad example

I'm pretty sure one could do things like

BuildRequires: %(echo config-for-$(date '+%m-%Y'))

on previous rpm versions and it would work.

What would not work before dynamic BuildRequires, is something akin to

%generate_buildrequires
cat deps.txt

with deps.txt included in the upstream source archive with a content 
that changes over time. Without dynamic buildrequires you have no way to 
act on this file because it is not available for processing before %prep 
is done.


Of course this is also an over-simplified example, because there is 
little chance that deps.txt exists in an rpm-compatible format upstream. 
Usually you have some form of json, yaml or xml file that needs a custom 
helper to be converted in rpm build deps. So in the real world you have


%generate_buildrequires
generate-foo-deps

with generate-foo-deps reading the default filename containing deps for 
foo language, and converting it to rpm syntax.


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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Disappearing pagure key

[Pierre-Yves Chibon]

On Wed, Jun 26, 2019 at 07:03:52AM -0600, Jerry James wrote:
> I generated a new API key on June 16, and used it.  Just now, I tried
> to do a fedpkg operation that resulted in the error:
> 
> Could not execute request_repo: The following error occurred while
> creating a new issue in Pagure: Invalid or expired token. Please visit
> https://pagure.io/settings#api-keys to get or renew your API token.
> For invalid or expired token refer to "fedpkg request-repo -h" to set
> a token in your user configuration.
> 
> (That URL is not correct, by the way.  Visiting it shows the main
> settings tab, NOT the API keys tab.)
> 
> Sure enough, the June 16 key is not listed, just all the expired ones
> from before that.  Sometime in the past 10 days, pagure lost track of
> my new API key.  I will generate a new one, but I thought somebody
> should know.

Note that we have two pagure instances, one running at pagure.io the other one
at src.fedoraproject.org. Are you sure the API token you generated on June 16th
wasn't for src.fp.o?


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: HEADS UP: DynamicBuildRequires are available

[Miroslav Suchý]

Dne 26. 06. 19 v 15:39 Richard W.M. Jones napsal(a):
> On Tue, Jun 18, 2019 at 03:27:41AM +0200, Igor Gnatenko wrote:
>> Hi folks,
>>
>> as of today, builders have been updated (thanks to Kevin) and
>> DynamicBuildRequires finally work in Rawhide.
>>
>> Change Page: https://fedoraproject.org/wiki/Changes/DynamicBuildRequires
> 
> I'm curious why the config-for-MM- filename needs to contain the
> month and year?  Both why it needs to have a date at all, and why --
> if it needs a date -- that doesn't include the day.

I just wanted to generate something dynamically. Such package does not even 
exists.
It can be even as simple as:

%generate_buildrequires
# this will build requires package:
#   zsh
echo "zsh"



-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: HEADS UP: DynamicBuildRequires are available

[Richard W.M. Jones]

On Tue, Jun 18, 2019 at 03:27:41AM +0200, Igor Gnatenko wrote:
> Hi folks,
> 
> as of today, builders have been updated (thanks to Kevin) and
> DynamicBuildRequires finally work in Rawhide.
> 
> Change Page: https://fedoraproject.org/wiki/Changes/DynamicBuildRequires

I'm curious why the config-for-MM- filename needs to contain the
month and year?  Both why it needs to have a date at all, and why --
if it needs a date -- that doesn't include the day.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Please update form pep8 to pycodestyle

[Miro Hrončok]

On 26. 06. 19 14:03, Vít Ondruch wrote:


Dne 26. 06. 19 v 13:23 Miro Hrončok napsal(a):

On 26. 06. 19 13:12, Miro Hrončok wrote:

This is a not that python-pep8 is dead upstream and changed to
python-pycodestyle.

We want to get rid of python-pep8:
https://bugzilla.redhat.com/show_bug.cgi?id=1667200

Please migrate your package away from python-pep8 /
python-pytest-pep8 to python-pycodestyle / python-pytest-pycodestyle
(*).

(*) python-pytest-pycodestyle needs to be packaged, I can do that if
there is a demand


Here's an example commit that simply drops all linting:

https://src.fedoraproject.org/rpms/python-utils/c/dc469f6e34136327c2f23c7643c4dfad21f05f68?branch=master




I agree with the "# Stop linting code in %%check and measuring coverage,
this is upstream's business" reasoning. Shouldn't we mention that
somewhere in guidelines?


Arguably, we should. https://pagure.io/packaging-committee/issue/909

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Rawhide-20190625.n.0 compose check report

[Dusty Mabe]

On 6/25/19 6:32 PM, Adam Williamson wrote:
> On Tue, 2019-06-25 at 17:45 +, Fedora compose checker wrote:
>> Missing expected images:
>>
>> Atomichost raw-xz x86_64
>> Atomichost qcow2 x86_64
>>
>> Compose FAILS proposed Rawhide gating check!
>> 3 of 47 required tests failed, 4 results missing
>> openQA tests matching unsatisfied gating requirements shown with **GATING** 
>> below
> 
> So, quite a few of these failures were down to some appearance changes
> in GNOME; I've updated the needles and am re-running those tests in
> prod now.
> 
> Dusty, Colin, and atomic@ : you got this mail because fedfind / check-
> compose considered the Atomic Host images to be "missing", and I just
> implemented a thing in check-compose yesterday to send you reports when
> there is an Atomic-related failure (like we used to do with the
> separate Fedora-Atomic composes):
> 
> https://pagure.io/fedora-qa/check-compose/issue/2
> 
> there is of course a bug there - fedfind shouldn't consider Atomic Host
> to be expected for Rawhide any more. I noticed that problem for F30+
> updates composes and fixed it prior to rolling out the new check-
> compose, but didn't notice it also needed fixing for Rawhide and
> Branched. I will fix that now and send a new fedfind out.
> 

Thanks Adam
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Disappearing pagure key

[Jerry James]

I generated a new API key on June 16, and used it.  Just now, I tried
to do a fedpkg operation that resulted in the error:

Could not execute request_repo: The following error occurred while
creating a new issue in Pagure: Invalid or expired token. Please visit
https://pagure.io/settings#api-keys to get or renew your API token.
For invalid or expired token refer to "fedpkg request-repo -h" to set
a token in your user configuration.

(That URL is not correct, by the way.  Visiting it shows the main
settings tab, NOT the API keys tab.)

Sure enough, the June 16 key is not listed, just all the expired ones
from before that.  Sometime in the past 10 days, pagure lost track of
my new API key.  I will generate a new one, but I thought somebody
should know.

Regards,
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1723300] Upgrade perl-Promises to 1.02

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Promises-1.02-1.fc31
 Resolution|--- |RAWHIDE
   Assignee|dd...@cpan.org  |jples...@redhat.com
Last Closed||2019-06-26 12:50:47



-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: No More i686 Kernels

[Roberto Ragusa]

On 6/26/19 2:34 AM, Michal Schorm wrote:

I - and a people around me - have plenty of 32-bit hardware.


Just for the record, I've got a couple of AMD XP2400+, AMD XP2000+ machines,
updated to recent Fedora versions and still usable.

Regards.
--
   Roberto Ragusamail at robertoragusa.it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

adding speech installation to fedora network installation image

[Mmobilea]

Hello,
I’m new blind user of fedora 30. I couldn’t find where to post this request. I 
have small pendrive, and I must use network installer. Howewer orca or speakup 
doesn’t run on it. Could you add speech to the installer?
Sorry for my English, i’m from Poland


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

Re: Please update form pep8 to pycodestyle

[Vít Ondruch]

Dne 26. 06. 19 v 13:23 Miro Hrončok napsal(a):
> On 26. 06. 19 13:12, Miro Hrončok wrote:
>> This is a not that python-pep8 is dead upstream and changed to
>> python-pycodestyle.
>>
>> We want to get rid of python-pep8:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1667200
>>
>> Please migrate your package away from python-pep8 /
>> python-pytest-pep8 to python-pycodestyle / python-pytest-pycodestyle
>> (*).
>>
>> (*) python-pytest-pycodestyle needs to be packaged, I can do that if
>> there is a demand
>
> Here's an example commit that simply drops all linting:
>
> https://src.fedoraproject.org/rpms/python-utils/c/dc469f6e34136327c2f23c7643c4dfad21f05f68?branch=master
>
>

I agree with the "# Stop linting code in %%check and measuring coverage,
this is upstream's business" reasoning. Shouldn't we mention that
somewhere in guidelines?


Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Bootstrapped Packages

[Vít Ondruch]

Dne 26. 06. 19 v 13:11 Miroslav Suchý napsal(a):
> Dne 26. 06. 19 v 12:53 Brian (bex) Exelbierd napsal(a):
>> Can someone point me at step by step instructions for how to handle
>> new packages that require bootstrapping because of a circular
>> depedency?
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping
>
>

I did recently bootstrap build of rubygem-cucumber [1] in three steps.


1) Update of the Cucumber.

https://src.fedoraproject.org/rpms/rubygem-cucumber/c/dd56251feac749f1729c9ad6b663cc779ea3fa2a?branch=master


2) Bootstrap build enabled.

https://src.fedoraproject.org/rpms/rubygem-cucumber/c/fcf13af7b086c4bd06091ee63e025f57c02f1576?branch=master

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


3) Bootstrap disabled for official build

https://src.fedoraproject.org/rpms/rubygem-cucumber/c/6b5855729723d0578a25577a9a70b7e77ac52a41?branch=master

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


Of course the 2nd commit was there just to make the revert commit easier.


Vít



[1]:
https://src.fedoraproject.org/rpms/rubygem-cucumber/blob/master/f/rubygem-cucumber.spec

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

[Bug 1724169] Missing MPLv2.0 in License

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Blocks||1632600



-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1724169] New: Missing MPLv2.0 in License

[bugzilla]

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

Bug ID: 1724169
   Summary: Missing MPLv2.0 in License
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-IO-Socket-SSL
  Assignee: p...@city-fan.org
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: caillon+fedoraproj...@gmail.com,
jose.p.oliveira@gmail.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org,
rhug...@redhat.com, rstr...@redhat.com,
sandm...@redhat.com
  Target Milestone: ---
Classification: Fedora



I noticed IO-Socket-SSL-2.066 sources distribute Public Suffix list from
 in lib/IO/Socket/SSL/PublicSuffix.pm file. The
data carry it's own license declaration:

// This Source Code Form is subject to the terms of the Mozilla Public
// License, v. 2.0. If a copy of the MPL was not distributed with this
// file, You can obtain one at https://mozilla.org/MPL/2.0/.

I believe perl-IO-Socket-SSL should add MPLv2.0 to the License tag.

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Bootstrapped Packages

[Björn 'besser82' Esser]

Am Mittwoch, den 26.06.2019, 12:53 +0200 schrieb Brian (bex) Exelbierd:
> Hi,
> 
> Can someone point me at step by step instructions for how to handle
> new packages that require bootstrapping because of a circular
> depedency?
> 
> I am about to request the first of the repos and want to make sure I
> follow the process correctly.  My goal is to wind up with both
> packages built fully in rawhide, and later other versions.
> 
> The package that requires a boot strap received it's ack today.  I
> suspect the other review is waiting on the bootstrap to "appear."
> 
> thank you for the guidance.
> 
> regards,
> 
> bex


Sure, I can help out with that.  It would be good, if you can point me
to the reviews in question, so I can get familiar with the packages and
what actually needs bootstrapping and in which ways.

Cheers
Björn


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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS UP] Unannounced soname bump of qrencode

[Miro Hrončok]

On 26. 06. 19 13:34, Martin Kolman wrote:

On Tue, 2019-06-25 at 16:30 -0500, mcatanz...@gnome.org wrote:

Let's ensure this at least doesn't happen for the same library again
and again.

In [1], change SHOULD NOT -> MUST NOT.

Require maintainers (or provenpackagers) to fix violations like [2]
when unannounced soname bumps occur.

(If anyone wants to write a script to detect such problems proactively,
even better.)

Couldn't some of the upcoming gating initiatives catch incidental soname bumps ?

I can imagine a test running on all builds, that checks for soname bump and
gates the package if the soname bump is not appropriately marked up somewhere
(say via some identifier in the package change log).

Alternatively I guess reverse dependency tests could catch this,
if systemd gating tests run & failed with the updated qrencode package,
keeping the qrencode package gated.



https://pagure.io/fedora-ci/general/issue/45
https://pagure.io/fedora-ci/general/issue/46

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS UP] Unannounced soname bump of qrencode

[Martin Kolman]

On Tue, 2019-06-25 at 16:30 -0500, mcatanz...@gnome.org wrote:
> Let's ensure this at least doesn't happen for the same library again 
> and again.
> 
> In [1], change SHOULD NOT -> MUST NOT.
> 
> Require maintainers (or provenpackagers) to fix violations like [2] 
> when unannounced soname bumps occur.
> 
> (If anyone wants to write a script to detect such problems proactively, 
> even better.)
Couldn't some of the upcoming gating initiatives catch incidental soname bumps ?

I can imagine a test running on all builds, that checks for soname bump and
gates the package if the soname bump is not appropriately marked up somewhere
(say via some identifier in the package change log).

Alternatively I guess reverse dependency tests could catch this,
if systemd gating tests run & failed with the updated qrencode package,
keeping the qrencode package gated.


> 
> If we don't fix [2] the problem will just occur again.
> 
> [1] 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_listing_shared_library_files
> [2] 
> https://src.fedoraproject.org/rpms/qrencode/blob/f48205000af5397008dbd645abb941e0dbb49636/f/qrencode.spec#_63
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Please update form pep8 to pycodestyle

[Miro Hrončok]

On 26. 06. 19 13:12, Miro Hrončok wrote:

This is a not that python-pep8 is dead upstream and changed to 
python-pycodestyle.

We want to get rid of python-pep8:
https://bugzilla.redhat.com/show_bug.cgi?id=1667200

Please migrate your package away from python-pep8 / python-pytest-pep8 to 
python-pycodestyle / python-pytest-pycodestyle (*).


(*) python-pytest-pycodestyle needs to be packaged, I can do that if there is a 
demand


Here's an example commit that simply drops all linting:

https://src.fedoraproject.org/rpms/python-utils/c/dc469f6e34136327c2f23c7643c4dfad21f05f68?branch=master

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1723962] perl-Test-Refcount-0.10 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Test-Refcount-0.09 is  |perl-Test-Refcount-0.10 is
   |available   |available



--- Comment #1 from Upstream Release Monitoring 
 ---
Latest upstream release: 0.10
Current version/release in rawhide: 0.08-15.fc31
URL: http://search.cpan.org/dist/Test-Refcount/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/11914/

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Please update form pep8 to pycodestyle

[Miro Hrončok]

This is a not that python-pep8 is dead upstream and changed to 
python-pycodestyle.

We want to get rid of python-pep8:
https://bugzilla.redhat.com/show_bug.cgi?id=1667200

Please migrate your package away from python-pep8 / python-pytest-pep8 to 
python-pycodestyle / python-pytest-pycodestyle (*).


(*) python-pytest-pycodestyle needs to be packaged, I can do that if there is a 
demand


Thanks.

Maintainers by package:
buildstream  bochecha
imgbased dougsland fabiand sbonazzo yuvalturg
pylast   peter
python-autobahn  jujens
python-cliappsalimma
python-dictdifferjkim jmontleon
python-f5-icontrol-rest xavierb
python-flake8-polyfill cottsay
python-keystoneauth1 alphacc apevec pabelanger
python-mwclient  adamwill rdieter tuxbrewr
python-natsort   immanetize jamatos
python-pydocstyletadej
python-pytest-pep8   cstratak orion
python-ryu   abregman apevec
python-shortuuid pbrobinson
python-stem  jorti
python-terminaltables terjeros
python-txaio jujens
python-utils churchyard
spyder   nonamedotc thozza

Packages by maintainer:
abregman   python-ryu
adamwill   python-mwclient
alphaccpython-keystoneauth1
apevec python-keystoneauth1 python-ryu
bochecha   buildstream
churchyard python-utils
cottsaypython-flake8-polyfill
cstratak   python-pytest-pep8
dougsland  imgbased
fabiandimgbased
immanetize python-natsort
jamatospython-natsort
jkim   python-dictdiffer
jmontleon  python-dictdiffer
jorti  python-stem
jujens python-autobahn python-txaio
nonamedotc spyder
orion  python-pytest-pep8
pabelanger python-keystoneauth1
pbrobinson python-shortuuid
peter  pylast
rdieterpython-mwclient
salimmapython-cliapp
sbonazzo   imgbased
tadej  python-pydocstyle
terjeros   python-terminaltables
thozza spyder
tuxbrewr   python-mwclient
xavierbpython-f5-icontrol-rest
yuvalturg  imgbased

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Bootstrapped Packages

[Miroslav Suchý]

Dne 26. 06. 19 v 12:53 Brian (bex) Exelbierd napsal(a):
> Can someone point me at step by step instructions for how to handle
> new packages that require bootstrapping because of a circular
> depedency?

https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping


-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Bootstrapped Packages

[Miro Hrončok]

On 26. 06. 19 12:53, Brian (bex) Exelbierd wrote:

Hi,

Can someone point me at step by step instructions for how to handle
new packages that require bootstrapping because of a circular
depedency?


I don't know about any, but if you'd like, I can talk to you over audio chat or 
IRC/Telegram and later maybe you can write something down?


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Bootstrapped Packages

[Brian (bex) Exelbierd]

Hi,

Can someone point me at step by step instructions for how to handle
new packages that require bootstrapping because of a circular
depedency?

I am about to request the first of the repos and want to make sure I
follow the process correctly.  My goal is to wind up with both
packages built fully in rawhide, and later other versions.

The package that requires a boot strap received it's ack today.  I
suspect the other review is waiting on the bootstrap to "appear."

thank you for the guidance.

regards,

bex
-- 
Brian "bex" Exelbierd (he/him/his)
Fedora Community Action & Impact Coordinator
@bexelbie | http://www.winglemeyer.org
bexel...@redhat.com | b...@pobox.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: gcc/g++ compiler memory exhaustion on build vms

[Panu Matilainen]

On 6/26/19 3:25 AM, Philip Kovacs via devel wrote:
I am finding that one of my c++ packages has compilation units that 
generate very large assembly (.s)
files -- so large that any attempt to build them in memory (e.g. with 
-pipe) causes memory exhaustion.
The only way I have found to reliably get the build to run to completion 
is by using -save-temps to force
g++ to save the .s assembly files to disk.  I also have to remove any 
(make) parallelism in the builds.


I am doing this:

%configure \
     CXXFLAGS="${CXXFLAGS} -save-temps" \
     ...

and using make (-j1 implied) instead of make_build. >
Just curious if anyone has a better suggestion here.



You don't need to abandon %make_build and friends for that. You can 
either set RPM_BUILD_NCPUS=1 environent variable or define 
%_smp_ncpus_max macro to 1 in the build environment, whichever is more 
convenient.


- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS UP] Unannounced soname bump of qrencode

[Miro Hrončok]

On 26. 06. 19 12:25, Neal Gompa wrote:

On Wed, Jun 26, 2019 at 6:01 AM Miro Hrončok  wrote:


On 26. 06. 19 10:59, Bob Mauchin wrote:


At least this is enforced for any new package, I make sure of it. But for
existing ones, we can maybe grep .so* to fix them.


$ rg -lF '.so*' rpm-specs/ | env LANG=en_US.utf8 sort
[...]
rpm-specs/snapd.spec
[...]


This spec doesn't have any shared objects, it just happens to match
because the string exists in the changelog. There may be other false
positives like that, so be careful...


No allegations about the listed specs at all, except that they match the 
pattern. In no way I have said: those packages are bad and should be fixed.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS UP] Unannounced soname bump of qrencode

[Neal Gompa]

On Wed, Jun 26, 2019 at 6:01 AM Miro Hrončok  wrote:
>
> On 26. 06. 19 10:59, Bob Mauchin wrote:
> >
> > At least this is enforced for any new package, I make sure of it. But for
> > existing ones, we can maybe grep .so* to fix them.
>
> $ rg -lF '.so*' rpm-specs/ | env LANG=en_US.utf8 sort
> [...]
> rpm-specs/snapd.spec
> [...]

This spec doesn't have any shared objects, it just happens to match
because the string exists in the changelog. There may be other false
positives like that, so be careful...


-- 
真実はいつも一つ！/ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS UP] Unannounced soname bump of qrencode

[Milan Crha]

Hi,

On Wed, 2019-06-26 at 11:11 +0200, Miro Hrončok wrote:
> $ rg -lF '.so*' rpm-specs/ | env LANG=en_US.utf8 sort
> 
> rpm-specs/evolution.spec

that's a false positive, the only occurrence of ".so*" in that file is
in the %changelog section, namely:

   * Tue May 17 2011 x  - 3.1.1-3
   - Keep libevolution-mail-settings.so* from the previous change,
 it is still used by other parts of evolution.

Just saying.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS UP] Unannounced soname bump of qrencode

[Miro Hrončok]

On 26. 06. 19 10:59, Bob Mauchin wrote:



On Wed, Jun 26, 2019, 00:21 Fabio Valentini > wrote:


On Tue, Jun 25, 2019 at 11:21 PM Miro Hrončok mailto:mhron...@redhat.com>> wrote:
 >
 > qrencode was bumped from 3.4.4 to 4.0.2.
 >
 > It has a bumped soname from libqrencode.so.3 to libqrencode.so.4.

This might be a good time to remind people that globbing out shared
libraries like this:
https://src.fedoraproject.org/rpms/qrencode/blob/master/f/qrencode.spec#_63

is even strongly discouraged by the current Packaging Guidelines:

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_listing_shared_library_files

- to help prevent packagers from accidentally bumping SONAMEs without
noticing it.

Fabio

At least this is enforced for any new package, I make sure of it. But for 
existing ones, we can maybe grep .so* to fix them.


$ rg -lF '.so*' rpm-specs/ | env LANG=en_US.utf8 sort
rpm-specs/389-ds-base.spec
rpm-specs/a2ps.spec
rpm-specs/alltray.spec
rpm-specs/amanith.spec
rpm-specs/am-utils.spec
rpm-specs/ast.spec
rpm-specs/atlas.spec
rpm-specs/binutils.spec
rpm-specs/calc.spec
rpm-specs/calligra.spec
rpm-specs/CBFlib.spec
rpm-specs/ceph.spec
rpm-specs/cgnslib.spec
rpm-specs/chicken.spec
rpm-specs/chromium.spec
rpm-specs/cliquer.spec
rpm-specs/cloog.spec
rpm-specs/coin-or-Ipopt.spec
rpm-specs/criu.spec
rpm-specs/cube.spec
rpm-specs/cyrus-sasl.spec
rpm-specs/djvulibre.spec
rpm-specs/dmraid.spec
rpm-specs/dpm-dsi.spec
rpm-specs/drat-trim.spec
rpm-specs/drumkv1.spec
rpm-specs/dspam.spec
rpm-specs/ebtables.spec
rpm-specs/ElectricFence.spec
rpm-specs/electron-cash.spec
rpm-specs/elfutils.spec
rpm-specs/enchant2.spec
rpm-specs/enchant.spec
rpm-specs/eruby.spec
rpm-specs/espeak-ng.spec
rpm-specs/ettercap.spec
rpm-specs/evince.spec
rpm-specs/evolution.spec
rpm-specs/fawkes.spec
rpm-specs/festival.spec
rpm-specs/fmt-ptrn.spec
rpm-specs/freemedforms.spec
rpm-specs/freeradius.spec
rpm-specs/fts.spec
rpm-specs/gambas3.spec
rpm-specs/ganglia.spec
rpm-specs/gcc.spec
rpm-specs/gdal.spec
rpm-specs/gdm.spec
rpm-specs/geany-plugins.spec
rpm-specs/geany.spec
rpm-specs/gegl04.spec
rpm-specs/gela-asis.spec
rpm-specs/gfal2.spec
rpm-specs/glew.spec
rpm-specs/glib.spec
rpm-specs/gnome-shell-extension-pomodoro.spec
rpm-specs/gnutls.spec
rpm-specs/google-compute-engine-oslogin.spec
rpm-specs/gpgme.spec
rpm-specs/grilo-plugins.spec
rpm-specs/gsequencer.spec
rpm-specs/gstreamer1-rtsp-server.spec
rpm-specs/gstreamer-rtsp.spec
rpm-specs/gstreamer.spec
rpm-specs/gtk-sharp3.spec
rpm-specs/hadoop.spec
rpm-specs/heimdal.spec
rpm-specs/HepMC3.spec
rpm-specs/hidviz.spec
rpm-specs/hplip.spec
rpm-specs/hpx.spec
rpm-specs/hugin.spec
rpm-specs/hwloc.spec
rpm-specs/hyperestraier.spec
rpm-specs/inih.spec
rpm-specs/ipmiutil.spec
rpm-specs/ircd-ratbox.spec
rpm-specs/julia.spec
rpm-specs/kakasi.spec
rpm-specs/kbibtex.spec
rpm-specs/kdepim4.spec
rpm-specs/kdepim-addons.spec
rpm-specs/kdeplasma-addons.spec
rpm-specs/kdevelop.spec
rpm-specs/kde-workspace.spec
rpm-specs/kernel-tools.spec
rpm-specs/kf5-kipi-plugins.spec
rpm-specs/kicad.spec
rpm-specs/klt.spec
rpm-specs/LabPlot.spec
rpm-specs/ladish.spec
rpm-specs/lcgdm-dav.spec
rpm-specs/libannodex.spec
rpm-specs/libbonobo.spec
rpm-specs/libcouchbase.spec
rpm-specs/libdb4.spec
rpm-specs/libdb.spec
rpm-specs/libdkimpp.spec
rpm-specs/libdxflib.spec
rpm-specs/libextractor.spec
rpm-specs/libgcrypt.spec
rpm-specs/libglvnd.spec
rpm-specs/libhugetlbfs.spec
rpm-specs/libiodbc.spec
rpm-specs/libkgapi.spec
rpm-specs/libomxil-bellagio.spec
rpm-specs/libssh.spec
rpm-specs/libtranslit.spec
rpm-specs/libunwind.spec
rpm-specs/libvdpau.spec
rpm-specs/libvirt-cim.spec
rpm-specs/lld.spec
rpm-specs/llvm5.0.spec
rpm-specs/llvm6.0.spec
rpm-specs/llvm.spec
rpm-specs/lrslib.spec
rpm-specs/lua-ldap.spec
rpm-specs/lua-rex.spec
rpm-specs/luxcorerender.spec
rpm-specs/lvm2.spec
rpm-specs/Macaulay2.spec
rpm-specs/malaga.spec
rpm-specs/mapserver.spec
rpm-specs/meataxe.spec
rpm-specs/modem-manager-gui.spec
rpm-specs/ModemManager.spec
rpm-specs/mod_mono.spec
rpm-specs/mono-debugger.spec
rpm-specs/mono.spec
rpm-specs/mp.spec
rpm-specs/mygui.spec
rpm-specs/nacl-arm-binutils.spec
rpm-specs/nacl-binutils.spec
rpm-specs/NetworkManager-fortisslvpn.spec
rpm-specs/NetworkManager-iodine.spec
rpm-specs/NetworkManager-ssh.spec
rpm-specs/NetworkManager-sstp.spec
rpm-specs/nfs-ganesha.spec
rpm-specs/NLopt.spec
rpm-specs/notmuch.spec
rpm-specs/nss-pam-ldapd.spec
rpm-specs/nss_wrapper.spec
rpm-specs/nx-libs.spec
rpm-specs/ocaml-bitstring.spec
rpm-specs/ocaml-cryptokit.spec
rpm-specs/ocaml-lablgtk.spec
rpm-specs/ocaml-SDL.spec
rpm-specs/omniORBpy.spec
rpm-specs/openh264.spec
rpm-specs/openldap.spec
rpm-specs/ORBit2.spec
rpm-specs/owfs.spec
rpm-specs/owncloud-client.spec
rpm-specs/pam_wrapper.spec
rpm-specs/papi.spec
rpm-specs/passwdqc.spec
rpm-specs/pcsc-lite.spec
rpm-specs/perl.spec
rpm-specs/pgmodeler.spec
rpm-specs/plib.spec
rpm-specs/pmix.spec

[HEADS UP] Sphinx updated to 2.1

[Miro Hrončok]

I've just pushed and built python-sphinx-2.1.2-1.fc31 for rawhide.

I don't anticipate any breakage. In case unexpected breakage happens, let me 
know.

https://src.fedoraproject.org/rpms/python-sphinx/pull-request/12
https://bugzilla.redhat.com/show_bug.cgi?id=1716158

Thanks,
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org

[HEADS UP] Sphinx updated to 2.1

[Miro Hrončok]

I've just pushed and built python-sphinx-2.1.2-1.fc31 for rawhide.

I don't anticipate any breakage. In case unexpected breakage happens, let me 
know.

https://src.fedoraproject.org/rpms/python-sphinx/pull-request/12
https://bugzilla.redhat.com/show_bug.cgi?id=1716158

Thanks,
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS UP] Unannounced soname bump of qrencode

[Bob Mauchin]

On Wed, Jun 26, 2019, 00:21 Fabio Valentini  wrote:

> On Tue, Jun 25, 2019 at 11:21 PM Miro Hrončok  wrote:
> >
> > qrencode was bumped from 3.4.4 to 4.0.2.
> >
> > It has a bumped soname from libqrencode.so.3 to libqrencode.so.4.
>
> This might be a good time to remind people that globbing out shared
> libraries like this:
> https://src.fedoraproject.org/rpms/qrencode/blob/master/f/qrencode.spec#_63
>
> is even strongly discouraged by the current Packaging Guidelines:
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_listing_shared_library_files
>
> - to help prevent packagers from accidentally bumping SONAMEs without
> noticing it.
>
> Fabio
>

At least this is enforced for any new package, I make sure of it. But for
existing ones, we can maybe grep .so* to fix them.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Modularity vs. libgit

[Petr Pisar]

On 2019-06-25, Adam Williamson  wrote:
> So I'm still not confident about the story here. Let's take something
> that does follow semver: it's not going to change API compatibility as
> *often* as libgit2, but ultimately it's gonna happen. And in Rawhide,
> presumably, when a new major version comes out, we want installs to
> move to that new major version; that's how we've always done things in
> the past, that's what Rawhide is for.
>
> So what's the story there? How is that supposed to work?

We had had "master" streams that were deprecated. They lived in "master"
dist-git branch and were supposed to contain the latest available
version regardless of ABI changes. Mainly for integration and
distribution-development purposes. It was meant in the same meaning as
what "Rawhide" means for Fedora releases.

The issue with master streams was that there was no platform:master and
thus they leaked into released distribution. Either when branching
a new a distribution from Rawhide or when using a stream expansion.

But I believe we need something like that. Otherwise how are we supposed
to develop modules in Rawhide? A developer story:

I created perl:5.30 stream that is the latest Perl version now. It
consists of many RPM packages. Some of them will get a new upstream
release between creating perl:5.30 stream and branching F31 from
Rawhide. And some of them will break API. What are we going to do with
these new package releases? Should we ignor them, not integrating them,
until a new perl:5.32 is created next year? Or should we add them into
perl:5.30 and risking the ABI change?

Don't forget I want to provide the stream to other Fedoras. One feasible
way is submit perl:5.30 to testing for released Fedoras, but postpone
pushing to stable until F31 is branched off. That effectively makes
perl:5.30 in-developement until the branching. Is that an accaptable way
of developing modules? The drawback is we align stream life cycle to
Fedora releases.

Another approach would be to build perl:5.30 only for Rawhide
(platform:f31 now) and forbid relengs to tag it into F31 composes on
branching. But this manual process would be error-prone would not scale.
We would need some way of marking a stream as a Rawhide only. And not
only for relengs. There is the issue of modular dependencies. It's not
feasible for packagers to update the modular dependency every time a new
dependency stream emerges. Or is it? Do we need a "master" streams for
building modules?

I hope I missed somthing and there is an obvious and easy way of solving
this issue. Otherwise the modularity is not sustainable for developers.

-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] knot / knot-resolver package rebase

[Tomas Krizek]

Hi,

I'd like to rebase knot and knot-resolver packages to their latest
upstream versions (Knot DNS 2.8.2, Knot Resolver 4.0.0) in EPEL 7.

Reasons
---
- upstream of Knot DNS supports only 2.7 and 2.8; the knot version in
EPEL 7 (2.6.9) is unsupported and will not receive any more security or
other bugfixes
- upstream of Knot Resolver supports only the latest version which is
binary-compatible only with Knot DNS 2.8+; the version of knot-resolver
in EPEL7 will not receive any more security or other bugfixes

Potential Issues

- in case the user has made changes to default configuration of Knot
Resolver, manual update of the config file may be required [1]
- in case the user has written custom module for Knot Resolver, a manual
update may be required [1]

Additional info
---
- upstream has documented the update process [1], [2] and it should be
seamless for Knot DNS (and default configurations of Knot Resolver)

[1] - https://knot-resolver.readthedocs.io/en/stable/upgrading.html
[2] -
https://www.knot-dns.cz/docs/2.8/html/migration.html#upgrade-2-7-x-to-2-8-x

-- 
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495  C509 A1FB A5F7 EF8C 4869



signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: gcc/g++ compiler memory exhaustion on build vms

[Philip Kovacs via devel]

 

   > On Wednesday, June 26, 2019, 02:42:29 AM EDT, Dan Horák  
wrote:>
> what package is it?

fastbit.   This evening I retired it in master since no upstream updates have 
been issued since 02/2016.
 https://src.fedoraproject.org/rpms/fastbit

The build problems are completely recent, nothing "real" has changed with this 
package in years.   I just startedgetting intermittent failures.   f30 and f29 
are still in the git tree if you want to look at it.    
  ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: gcc/g++ compiler memory exhaustion on build vms

[Dan Horák]

On Wed, 26 Jun 2019 05:33:24 + (UTC)
Philip Kovacs via devel  wrote:

>  > On Wednesday, June 26, 2019, 01:05:13 AM EDT, John Reiser
>  >  wrote:
>  
> > Please quantify: What is the byte size of the .s file?
> 
> > First hint: give the virtual machine enough resources!
> > Either RAM, or "swap" (paging) space.
> 
> The .s got up to about 375M before that particular g++ compile
> process died.   The jobs are submitted with the usual suspects: koji
> or fedpkg.   I don't think we have any control over the resources
> allocatedto the vm's or containers the jobs land on (and we
> shouldn't).  

what package is it?


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org