date:20190627

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

Fedora Update System  changed:

   What|Removed |Added

   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 |perl-String-Compare-Constan
   |tTime-0.321-1.fc30  |tTime-0.321-1.fc30
   ||perl-String-Compare-Constan
   ||tTime-0.321-1.fc29



--- Comment #7 from Fedora Update System  ---
perl-String-Compare-ConstantTime-0.321-1.fc29 has been pushed to the Fedora 29
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

ghc alternatives and triggers

2019-06-27 Thread Jens-Ulrik Petersen

Hi,

Any objections to dropping the alternatives for runhaskell and hsc2hs in
Rawhide at this time?
https://bugzilla.redhat.com/show_bug.cgi?id=1640056

Also a heads-up that I am planning to move to rpm triggers in ghc-compiler
for updating the ghc-pkg cache instead of the current post/postun scripts
in all ghc-*-devel.

Jens
___
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

GCC / annobin changes in F30

2019-06-27 Thread Michael Cronenworth


Hi,

I was attempting to package the Kodi 18.3 update for RPMFusion but ran into a compiler 
error very early in the build. GCC outputs the following type of messages:


cc: error: .annobin-Wl,-wrap,_IO_getc.end: No such file or directory
cc: error: .annobin-Wl,-wrap,_IO_getc.start: No such file or directory
...snip...
cc: error: .text.-Wl,-wrap,_IO_getc.group: No such file or directory
cc: error: .text.-Wl,-wrap,_IO_getc_unlocked.group: No such file or directory
...snip...

I've isolated it to Fedora 30 as the 18.2 update, successfully compiled on May 11th[1], 
is also failing the same way today.


Fedora 29's build is successful. Fedora Rawhide is broken the same way and Rawhide 
successfully built Kodi on May 9th[2].


What's different this month?

Thanks,
Michael

[1] http://koji.rpmfusion.org/koji/buildinfo?buildID=11176
[2] http://koji.rpmfusion.org/koji/buildinfo?buildID=11160
___
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

On 28. 06. 19 0:51, Stephen John Smoogen wrote:

On Thu, 27 Jun 2019 at 18:49, Neal Gompa > wrote:

 > What about postponing this change to F32? I'd prefer python2 to be
 > retired and gone from the distro first, and the symlink and
 > %python_provide definition only switched then. I think that having
 > this middle state where python2 is available but python points to
 > python3 for exactly one release will be more confusing that switching
 > directly to the final state where python2 is gone and python simply
 > means python3.
 >

I think it makes sense to make the switch before we retire, because
then people's expectations are changed ahead of time and they can
adapt to The Future(TM).

Actually I think it makes more sense that F31 provides no /usr/bin/python. Then 
a lot of things which depend on it can be found and fixed since they have not 
adapted to the Future any other way.

We've been actively forbidding packagers doing that for more than a year.
Most packages that still require /usr/bin/python are either:

 * FTBFS since Fedora 28 (and I will make sure we follow the policy this time 
and finally kill those)

or

 * willingly workarounded by the packagers who tend to ignore all our 
recommendations (nothing we can really do here)

Totally that is 10 runtime dependent packages and 64 buildtime.

If we take away /usr/bin/python and "python" provide, those things won't 
resolve.

If we change it to Python 3, some of them might work, most of them probably 
won't. Some of them are broken already (like

$ (repoquery --repo=rawhide-source --whatrequires python; repoquery 
--repo=rawhide-source --whatrequires python-unversioned-command; repoquery 
--repo=rawhide-source --whatrequires /usr/bin/python) | pkgname | sort | uniq

audit
bibus
bitfrost
blitz
claws-mail
coan
crun
distro-info
distro-info-data
dracut-modules-olpc
dtrx
gcc
gnome-python2-desktop
graphite2
grass
gwebsockets
htop
hyperscan
cherrytree
chocolate-doom
json4s
kcov
libclc
libtaskotron
liquidwar
maxima
mchange-commons
mingw-qt5-qtdeclarative
mingw-wine-gecko
mongo-c-driver
mozc
offlineimap
olpc-contents
olpc-os-builder
perl-Plack
planner
python-rospkg
qtwebkit
qt5-qtdeclarative
sbt
seamonkey
sugar-base
sugar-castle
sugar-deducto
sugar-flip
sugar-jukebox
sugar-kuku
sugar-measure
sugar-pippy
sugar-srilanka
sugar-starchart
sugar-toolkit
sugar-yupana
swift-lang
tarantool
termy-qt
twitter-twemoji-fonts
uboot-tools
udis86
vdsm
vte
wesnoth
wine-mono
0ad

$ (repoquery --repo=rawhide --whatrequires python; repoquery --repo=rawhide 
--whatrequires python-unversioned-command; repoquery --repo=rawhide 
--whatrequires /usr/bin/python) | pkgname | sort | uniq

gwebsockets
icaro
pyqt-mail-checker
qct
redhat-lsb-languages
resiprocate-turn-server-psql
sugar
sugar-toolkit
vdsm
vdsm-yajsonrpc

Note that there are packages that actually need any /usr/bin/python to build, 
such as gcc. But I wouldn't bother with he buildtime deps much - either they 
build with py3 or they won't.

The runtime deps bother me, because they need to be fixed or retired either way. 
I'll happily retire them all (with big loud warnings before we do).

--
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 31 System-Wide Change proposal: Python means Python3


On 28. 06. 19 0:00, Neal Gompa wrote:

On Thu, Jun 27, 2019 at 5:59 PM Zbigniew Jędrzejewski-Szmek
 wrote:


On Wed, Jun 26, 2019 at 01:57:13PM -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. 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.


What about postponing this change to F32? I'd prefer python2 to be
retired and gone from the distro first, and the symlink and
%python_provide definition only switched then. I think that having
this middle state where python2 is available but python points to
python3 for exactly one release will be more confusing that switching
directly to the final state where python2 is gone and python simply
means python3.



I think it makes sense to make the switch before we retire, because
then people's expectations are changed ahead of time and they can
adapt to The Future(TM).


This is exactly the reason we want this in F31.

--
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 31 System-Wide Change proposal: Python means Python3

2019-06-27 Thread Gerald Henriksen

On Thu, 27 Jun 2019 16:09:58 -0400, you wrote:

>On Thu, Jun 27, 2019 at 2:52 PM Dan Book  wrote:
>>
>> As an outsider to the Python community, not having any binary or package 
>> that responds to the expected name "python" would be a disaster.
>>
>Can you expand on that? As I understand it, most things that are
>calling for "python" now are expecting that to be "python2". So when
>it becomes "python3", they'll break anyway. So why perpetuate a
>pattern that's not future-proof (for some values of "proof")?

Because it's not about what some python code expects, it about what
the human being using Fedora expects.

Nobody trying to compile a C program expects to have to use gcc9, they
just expect to type in gcc.

Similarly someone sitting down to use a tutorial to learn Python is
going to expect to type python and get something they can use,
particularly going forward when Python3 really just become Python as
Python2 fades from memory.
___
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

On Thu, Jun 27, 2019 at 7:41 PM Stephen John Smoogen  wrote:
>
>
>
> On Thu, 27 Jun 2019 at 18:49, Neal Gompa  wrote:
>>
>>
>> > What about postponing this change to F32? I'd prefer python2 to be
>> > retired and gone from the distro first, and the symlink and
>> > %python_provide definition only switched then. I think that having
>> > this middle state where python2 is available but python points to
>> > python3 for exactly one release will be more confusing that switching
>> > directly to the final state where python2 is gone and python simply
>> > means python3.
>> >
>>
>> I think it makes sense to make the switch before we retire, because
>> then people's expectations are changed ahead of time and they can
>> adapt to The Future(TM).
>>
>
> Actually I think it makes more sense that F31 provides no /usr/bin/python. 
> Then a lot of things which depend on it can be found and fixed since they 
> have not adapted to the Future any other way.
>

We've been throwing errors on using /usr/bin/python in packaged code
since Fedora 28, so I don't think it's necessary to wait like that.



-- 
真実はいつも一つ！/ 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: Fedora 31 System-Wide Change proposal: Python means Python3

2019-06-27 Thread Elliott Sales de Andrade

On Thu, 27 Jun 2019 at 18:59,  wrote:
>
> On Thu, Jun 27, 2019 at 4:34 PM, Neal Gompa  wrote:
> > This is because
> > in everything *except* Linux distributions, the unversioned name has
> > already switched over.
>
> Not in macOS.

System macOS is still Python 2, but new developers are not encouraged
to use it. Any reasonable Python macOS programmer uses conda or
virtualenv (or a wrapper like pyenv, pipenv, etc.), and a Python 3
environment will set python->python3.

-- 
Elliott
___
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

2019-06-27 Thread Stephen John Smoogen

On Thu, 27 Jun 2019 at 18:49, Neal Gompa  wrote:

>
> > What about postponing this change to F32? I'd prefer python2 to be
> > retired and gone from the distro first, and the symlink and
> > %python_provide definition only switched then. I think that having
> > this middle state where python2 is available but python points to
> > python3 for exactly one release will be more confusing that switching
> > directly to the final state where python2 is gone and python simply
> > means python3.
> >
>
> I think it makes sense to make the switch before we retire, because
> then people's expectations are changed ahead of time and they can
> adapt to The Future(TM).
>
>
Actually I think it makes more sense that F31 provides no /usr/bin/python.
Then a lot of things which depend on it can be found and fixed since they
have not adapted to the Future any other way.


-- 
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

[Bug 1646730] CVE-2018-18311 perl: Integer overflow leading to buffer overflow in Perl_my_setenv()

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

Laura Pardo  changed:

   What|Removed |Added

 Depends On||1724849



-- 
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

2019-06-27 Thread mcatanzaro


On Thu, Jun 27, 2019 at 4:34 PM, Neal Gompa  wrote:

This is because
in everything *except* Linux distributions, the unversioned name has
already switched over.


Not in macOS.

___
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

On Thu, Jun 27, 2019 at 5:59 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Wed, Jun 26, 2019 at 01:57:13PM -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. 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.
>
> What about postponing this change to F32? I'd prefer python2 to be
> retired and gone from the distro first, and the symlink and
> %python_provide definition only switched then. I think that having
> this middle state where python2 is available but python points to
> python3 for exactly one release will be more confusing that switching
> directly to the final state where python2 is gone and python simply
> means python3.
>

I think it makes sense to make the switch before we retire, because
then people's expectations are changed ahead of time and they can
adapt to The Future(TM).


-- 
真実はいつも一つ！/ 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: Fedora 31 Self-Contained Change proposal: DNF Make Best Mode the Default

2019-06-27 Thread Zbigniew Jędrzejewski-Szmek

On Thu, Jun 27, 2019 at 10:37:28AM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/DNF_Default_Best

I wanted to update today, and I got the following report:
$ sudo dnf upgrade --best
Last metadata expiration check: 0:00:18 ago on Thu 27 Jun 2019 10:45:00 PM CEST.
Error: 
 Problem: package InsightToolkit-4.9.1-9.fc29.x86_64 requires 
libnetlib.so.1.14()(64bit), but none of the providers can be installed
  - package InsightToolkit-4.9.1-9.fc29.x86_64 requires 
libv3p_netlib.so.1.14()(64bit), but none of the providers can be installed
  - package InsightToolkit-4.9.1-9.fc29.x86_64 requires 
libvcl.so.1.14()(64bit), but none of the providers can be installed
  - package InsightToolkit-4.9.1-9.fc29.x86_64 requires 
libvnl.so.1.14()(64bit), but none of the providers can be installed
  - package InsightToolkit-4.9.1-9.fc29.x86_64 requires 
libvnl_algo.so.1.14()(64bit), but none of the providers can be installed
  - cannot install both vxl-2.0.2-4.fc30.x86_64 and vxl-1.17.0-30.fc30.x86_64
  - cannot install both vxl-1.17.0-30.fc30.x86_64 and vxl-2.0.2-4.fc30.x86_64
  - cannot install the best update candidate for package 
vxl-1.17.0-30.fc30.x86_64
  - cannot install the best update candidate for package 
InsightToolkit-4.9.1-9.fc29.x86_64
(try to add '--allowerasing' to command line to replace conflicting packages or 
'--skip-broken' to skip uninstallable packages)

The problem with this is that it's not possible to figure out what who is too 
blame.
Specifically:
1. How am I to know that vxl is related to libnetlib.so.1.14()(64bit) and
   the other virtual provides?

2.
> - cannot install the best update candidate for package 
> vxl-1.17.0-30.fc30.x86_64
> - cannot install the best update candidate for package 
> InsightToolkit-4.9.1-9.fc29.x86_64
I see that vxl-1.17 and vxl-2.0.2 are mentioned. 1.17 is the older version.
So this message talks about old vxl version, so I assume it also talks about
old InsightToolkit version. But all logs above that only talk about one version
of InsightToolkit. Why would I care about requirements of the old version, when
about to upgrade to new version? What is even the new InsightToolkit version
dnf is trying to upgrade to?

3.
>  - cannot install both vxl-2.0.2-4.fc30.x86_64 and vxl-1.17.0-30.fc30.x86_64
>  - cannot install both vxl-1.17.0-30.fc30.x86_64 and vxl-2.0.2-4.fc30.x86_64
The second line is noise, already reported previously, but I can't find the bug
now.

So even in simple case with two packages, I'd need to do repoquery spelunking
to figure out what is going on. If dnf could tell me something like...

 Problem: package InsightToolkit-4.9.1-9.fc29.x86_64 requires
  libnetlib.so.1.14()(64bit), libv3p_netlib.so.1.14()(64bit),
  libvcl.so.1.14()(64bit), libvnl.so.1.14()(64bit),
  libvnl_algo.so.1.14()(64bit), currently provided by vxl-1.17.0.
  - There is no upgrade candidate for InsightToolkit.
  - Best upgrade candidate vxl-2.0.2-4.fc30.x86_64 does have those Provides.
→ cannot install both vxl-2.0.2-4.fc30.x86_64 and vxl-1.17.0-30.fc30.x86_64 
because vxl is not an installonly package.
   → cannot install the best update candidate for package vxl

i.e. group relevant Provides that "connect" two package into one list instead
of repeating the whole set of messages every time,
don't talk about upgrade candidates that don't actually exist,
mention the connection between Provides and package names,
omit evra when not required,
provide more explanations in general,

then I'd see this change in a more positive light. I think the output
right now is just noise for most users.

The premise that bug reports from users will help us catch such cases
— I don't see this as true. We *already know* that InsightToolkit has a problem,
there's a FTBFS bug for it somewhere.

The idea of "fault tolerant systems" is that the system mostly
continues to work in face of small failures in components. The distro
is a big system with thousands of interacting components, and *some*
simply must fail occasionally. The proposal is to make the system
fault-intolerant to notice errors earlier. That just seems wrong.
Returning to the example, why can't dnf print in red letters
at the end of the transaction log:

  Upgrade of vxl-1.17.0-30.fc30.x86_64 to vxl-2.0.2-4.fc30.x86_64 was held back 
because of dependency issues.

Users would see that too.

Zbyszek
___
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

On Thu, Jun 27, 2019 at 4:58 PM Ben Cotton  wrote:
>
> On Thu, Jun 27, 2019 at 2:52 PM Dan Book  wrote:
> >
> > As an outsider to the Python community, not having any binary or package 
> > that responds to the expected name "python" would be a disaster.
> >
> Can you expand on that? As I understand it, most things that are
> calling for "python" now are expecting that to be "python2". So when
> it becomes "python3", they'll break anyway. So why perpetuate a
> pattern that's not future-proof (for some values of "proof")?
>

The majority of the Python community writes Python 3 code pointing to
an unversioned shebang, even when it's Python 3 only. This is because
in everything *except* Linux distributions, the unversioned name has
already switched over. And OpenMandriva made the switch before us, and
that was not a terribly painful change like it was for Arch many years
earlier.

In fact, I would argue that the only mistake was in RHEL, where RHEL 8
did not ship with the default unversioned names that would point to
the Python 3 variants.

-- 
真実はいつも一つ！/ 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: Fedora 31 System-Wide Change proposal: Python means Python3

2019-06-27 Thread Charalampos Stratakis



- Original Message -
> From: "Ben Cotton" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Thursday, June 27, 2019 10:09:58 PM
> Subject: Re: Fedora 31 System-Wide Change proposal: Python means Python3
> 
> On Thu, Jun 27, 2019 at 2:52 PM Dan Book  wrote:
> >
> > As an outsider to the Python community, not having any binary or package
> > that responds to the expected name "python" would be a disaster.
> >
> Can you expand on that? As I understand it, most things that are
> calling for "python" now are expecting that to be "python2". So when
> it becomes "python3", they'll break anyway. So why perpetuate a
> pattern that's not future-proof (for some values of "proof")?

Depends on what you mean by calling "python". The biggest portion of python 
code floating around would be compatible with either both python2 and 3, or 
only with python3, with a few exceptions.

> 
> --
> 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
> 

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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

2019-06-27 Thread Zbigniew Jędrzejewski-Szmek

On Wed, Jun 26, 2019 at 01:57:13PM -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. 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.

What about postponing this change to F32? I'd prefer python2 to be
retired and gone from the distro first, and the symlink and
%python_provide definition only switched then. I think that having
this middle state where python2 is available but python points to
python3 for exactly one release will be more confusing that switching
directly to the final state where python2 is gone and python simply
means python3.

Zbyszek
___
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

2019-06-27 Thread Zbigniew Jędrzejewski-Szmek

On Thu, Jun 27, 2019 at 04:09:58PM -0400, Ben Cotton wrote:
> On Thu, Jun 27, 2019 at 2:52 PM Dan Book  wrote:
> >
> > As an outsider to the Python community, not having any binary or package 
> > that responds to the expected name "python" would be a disaster.
> >
> Can you expand on that? As I understand it, most things that are
> calling for "python" now are expecting that to be "python2". So when
> it becomes "python3", they'll break anyway. So why perpetuate a
> pattern that's not future-proof (for some values of "proof")?

While I'm wary of the proposed change, I think that this particular
avenue of criticism is misguided and we don't need to worry about
"future proofing".

Iiiif there's ever python4 (which isn't even on the horizon right
now), I think/hope that the way it is introduced will not repeat the
disastrous way that python3 was introduced, and the transition will be
more like the normal python 2.x→2.y and 3.x→3.y transitions, just with
a bigger set of changes. Python has the __future__ mechanism and
deprecation warnings, which can and should be used to phase in
changes. So I think we can safely assume that if python4.0 comes
around, we'll point the python symlink at it when we want it to be the
default, and we'll expect all packages in the distro to support
it. I.e. the python3.z→4.0 switch will not be substantially different
then the current 3.7→3.8 upgrade.

Zbyszek
___
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

On Thu, Jun 27, 2019 at 2:52 PM Dan Book  wrote:
>
> As an outsider to the Python community, not having any binary or package that 
> responds to the expected name "python" would be a disaster.
>
Can you expand on that? As I understand it, most things that are
calling for "python" now are expecting that to be "python2". So when
it becomes "python3", they'll break anyway. So why perpetuate a
pattern that's not future-proof (for some values of "proof")?

-- 
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

ODP: adding speech installation to fedora network installation image

2019-06-27 Thread Mmobilea

OK. If you can, open a new bug.
___
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 1724783] New: perl-IO-Async-0.74 is available

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

Bug ID: 1724783
   Summary: perl-IO-Async-0.74 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-IO-Async
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, kwiz...@gmail.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.74
Current version/release in rawhide: 0.73-1.fc31
URL: http://search.cpan.org/dist/IO-Async

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/7999/

-- 
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

2019-06-27 Thread Dan Book

On Thu, Jun 27, 2019 at 2:48 PM Miro Hrončok  wrote:

> On 27. 06. 19 18:49, Ben Cotton wrote:
> > On Thu, Jun 27, 2019 at 12:06 PM Miro Hrončok 
> wrote:
> >>
> >> So I might ask: What's the benefit of not having an unversioned python
> at all?
> >>
> > Avoiding ambiguity. Admittedly, it's avoiding large future pain at the
> > cost of small-and-frequent current pain. I'm not sure it's Fedora's
> > place to drive that mindset shift, particularly if upstream is taking
> > the opposite approach.
>
> To be fair, upstream allows us to choose. If we decide that we want
> "python"
> command not to exists, it's a valid choice.
>
> As Python maintainers, we want to make it python3. If Fedora decides that
> removing it is a better way, we have the ability to do that.
>
> I'd argue that it brings more problems. Such as: Should there also be no
> "pip",
> no "pytest", no "pylint"... command? Or should we switch those to Python
> 3, but
> just have no "python" command? What happens if users do "dnf install
> python"?
> Should they get Python 3 or nothing? etc.
>
> Either way, we really **need** "python" to no longer be Python 2. There
> are
> still people "out there" who call Python 2 the "default Python" because
> that's
> what you get when you type "python".
>

As an outsider to the Python community, not having any binary or package
that responds to the expected name "python" would be a disaster.

-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

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


On 27. 06. 19 20:13, Adam Williamson wrote:

On Thu, 2019-06-27 at 17:33 +0200, Miro Hrončok wrote:

There, you are correct. However, would we want "python" to mean Python 2
forever?


I don't honestly see the *harm* in this. That is what it has always
meant up until now, after all. That is probably what people expect it
to mean by this point. I always read "python" as "Python 2".

What is the benefit of this change, exactly?


The benefit is that people will eventually stop thinking this.

"python" (Python 2) will be unmaintained and dead couple weeks after Fedora 31 
is released. As the Python maintainers, we think that "python" being Python 2 
brings unfortunate expectations - that it is "the default Python".


We spent years and years trying to mark Python 2 as the "legacy" thing, but as 
long as we invoke Python 2 when users run "python" we cannot really expect that 
to happen. I believe that we should not run unsupported Python interpreter when 
users run "python".


--
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: always update the bootloader during major upgrades

2019-06-27 Thread Chris Murphy

On Thu, Jun 27, 2019 at 9:06 AM Bruno Wolff III  wrote:
>
> On Wed, Jun 26, 2019 at 14:19:26 -0600,
>   Chris Murphy  wrote:
> >
> >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.
>
> How do you envision this working for rawhide?
> I had a problem where grub1 configs were no longer updated with kernel
> updates, where I finally needed to upgrade to grub2.

Yep, small problem. And I'm not even sure how a 'grub2-install' on
BIOS systems would be initiated only at major upgrade time. But even
Fedora Rawhide does change versions when fcXX becomes fcXX+1, but is
that a sane trigger? I'm not sure what the alternatives are.

And could there be a policy setting in /etc/default/grub for this,
where the user can opt out? And should such an opt out exist? There is
no such opt out for UEFI. Anyway, the how to do this is a different
question than whether to do it, and whether the policy is the same
across all Fedora editions, spins, images, etc.

I think it's uncontroversial to say on IoT the bootloader must be
updated, I imagine no reasonable justification for making this user
domain on this class of device. That is probably also true for
cloud/virtual, and baremetal servers. It's really desktops that
there's an open question of what/who owns the bootloader. And there
I'd say the default really ought to be, maybe even must be, update the
bootloader with some regularity. And if that's true and agreed upon,
then fill in the gaps with some needed details: how often, how to do
it, should there be an opt out, and how to implement that, etc.

-- 
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

2019-06-27 Thread Adam Williamson

On Thu, 2019-06-27 at 17:33 +0200, Miro Hrončok wrote:
> There, you are correct. However, would we want "python" to mean Python 2 
> forever?

I don't honestly see the *harm* in this. That is what it has always
meant up until now, after all. That is probably what people expect it
to mean by this point. I always read "python" as "Python 2".

What is the benefit of this change, exactly?
-- 
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: Fedora 31 Self-Contained Change proposal: DNF Make Best Mode the Default

On Thu, Jun 27, 2019 at 11:25 AM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/DNF_Default_Best
>
> == Summary ==
> Currently, DNF prefers clean dependency resolution over package updates;
> a package (almost) silently won't get updated to a newer version if the new
> version has dependency problems. DNF will be changed to prefer updates and 
> fail
> if they have dependency resolution issues, while the failure has a
> temporal or permanent workaround
> hint for users who want to use the older behavior.
>
> == Owner ==
> * Name: [[User:jmracek| Jaroslav Mracek]]
> * Email: jmra...@redhat.com
>
>
> == Detailed Description ==
> Change the built-in default value of the `best` configuration option
> from `0` (false) to `1` (true).
>
> As a result, unless `best` is overridden in the `/etc/dnf/dnf.conf`
> file or using `--setopt`, it will default to `1`. As a convenience, we
> will also put the explicit `best=1` assignment in the shipped
> `/etc/dnf/dnf.conf` file for better transparency, and introduce the
> new `--nobest` command-line switch.
>
> The purpose of the `--nobest` switch (as a shorthand for
> `--setopt=best=0`) is to make it easy for the user to override the
> default setting when needed, and it will also be
> [https://github.com/rpm-software-management/dnf/pull/1311/commits/9a3e8fd0da49291d30fd1fef527cffb0bf3f047d#diff-6c823931c6d150295e5011fac6529ab9R144
> suggested] in the DNF output when a dependency error occurs.
>
> Relevant excerpt from the updated `dnf.conf(5)`:
> 
> best  boolean
> When upgrading a package, always try to install its highest version
> available, even only to find out some of its deps are not satisfiable.
> Enable this if you want to experience broken dependencies in the
> repositories firsthand. The default is True.
> 
>
> Relevant excerpt from the updated `dnf(8)`:
> 
> --nobest
> Set best option as false, therefore transactions are not limited to
> only best candidates.
> 
>
> '''Change in DNF output - missing vim-enhanced-2:8.1.1561-1.fc30'''
>
> Original output. DNF succeed with return code 0:
> 
> sudo dnf upgrade
> Last metadata expiration check: 2:16:40 ago on Mon 24 Jun 2019 04:27:16 PM 
> CEST.
> Dependencies resolved.
>
>  Problem: package vim-enhanced-2:8.1.1471-1.fc30.x86_64 requires
> vim-common = 2:8.1.1471-1.fc30, but none of the providers can be
> installed
>   - cannot install both vim-common-2:8.1.1561-1.fc30.x86_64 and
> vim-common-2:8.1.1471-1.fc30.x86_64
>   - problem with installed package vim-enhanced-2:8.1.1471-1.fc30.x86_64
>   - cannot install the best update candidate for package
> vim-common-2:8.1.1471-1.fc30.x86_64
>   - package vim-enhanced-2:8.1.1561-1.fc30.x86_64 is excluded
> ===
>  PackageArchitecture   Version
>Repository   Size
> ===
> Skipping packages with conflicts:
> (add '--best --allowerasing' to command line to force their upgrade):
>  vim-common x86_64
> 2:8.1.1561-1.fc30  updates 6.7
> M
>
> Transaction Summary
> ===
> Skip  1 Package
>
> Nothing to do.
> Complete!
> 
>
> Output after the change. DNF fails with return code 1, but proposing
> `--nobest` option as an option to resolve the issue:
> 
> sudo dnf upgrade
> Last metadata expiration check: 2:16:36 ago on Mon 24 Jun 2019 04:27:16 PM 
> CEST.
> Error:
>  Problem: package vim-enhanced-2:8.1.1471-1.fc30.x86_64 requires
> vim-common = 2:8.1.1471-1.fc30, but none of the providers can be
> installed
>   - cannot install both vim-common-2:8.1.1561-1.fc30.x86_64 and
> vim-common-2:8.1.1471-1.fc30.x86_64
>   - problem with installed package vim-enhanced-2:8.1.1471-1.fc30.x86_64
>   - cannot install the best update candidate for package
> vim-common-2:8.1.1471-1.fc30.x86_64
>   - package vim-enhanced-2:8.1.1561-1.fc30.x86_64 is excluded
> (try to add '--allowerasing' to command line to replace conflicting
> packages or '--skip-broken' to skip uninstallable packages or
> '--nobest' to use not only best candidate packages)
> 
>
> '''Q'''
>
> Can be a default of the best configuration option overwritten easily
> and permanently by user?
> Yes, just add `best=false` to `/etc/dnf/dnf.conf`
> 
> [main]
> best=False
> 
>
> Can be a default of the best configuration option overwritten easily
> from commandline?
> Yes, just add `--nobest` to command
> 
> dnf upgrade --nobest
> 
>
> What about PackageKit and Gnome Software?
> 
> PackageKit and Gnome Software will be not affected by the change. In
> case that the same behavior will be desired for PackageKit, It

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


On 27. 06. 19 18:49, Ben Cotton wrote:

On Thu, Jun 27, 2019 at 12:06 PM Miro Hrončok  wrote:


So I might ask: What's the benefit of not having an unversioned python at all?


Avoiding ambiguity. Admittedly, it's avoiding large future pain at the
cost of small-and-frequent current pain. I'm not sure it's Fedora's
place to drive that mindset shift, particularly if upstream is taking
the opposite approach.


To be fair, upstream allows us to choose. If we decide that we want "python" 
command not to exists, it's a valid choice.


As Python maintainers, we want to make it python3. If Fedora decides that 
removing it is a better way, we have the ability to do that.


I'd argue that it brings more problems. Such as: Should there also be no "pip", 
no "pytest", no "pylint"... command? Or should we switch those to Python 3, but 
just have no "python" command? What happens if users do "dnf install python"? 
Should they get Python 3 or nothing? etc.


Either way, we really **need** "python" to no longer be Python 2. There are 
still people "out there" who call Python 2 the "default Python" because that's 
what you get when you type "python".


--
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 31 Self-Contained Change proposal: DNF Make Best Mode the Default

2019-06-27 Thread Florian Weimer

* Björn Persson:

> If I understand this change correctly, then:
>
> · Before: If one package update is uninstallable, then that package
> won't be updated, but other packages can still be updated.
>
> · After: If one package update is uninstallable, then *nothing* will be
> updated.
>
> And you call that an improvement?

It is.  People have missed glibc updates because of the broken composes
without realizing it for quite some time, for example.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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

On Thu, Jun 27, 2019 at 12:06 PM Miro Hrončok  wrote:
>
> So I might ask: What's the benefit of not having an unversioned python at all?
>
Avoiding ambiguity. Admittedly, it's avoiding large future pain at the
cost of small-and-frequent current pain. I'm not sure it's Fedora's
place to drive that mindset shift, particularly if upstream is taking
the opposite approach.


-- 
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: Fedora 31 Self-Contained Change proposal: DNF Make Best Mode the Default

2019-06-27 Thread Dan Book

On Thu, Jun 27, 2019 at 12:30 PM Björn Persson  wrote:

>
> If there is a significant risk that the warning will be overlooked,
> then how about just making the warning more visible?
>
>
Based on experience with people installing things from CPAN for Perl, there
is no "more visible" that has any appreciable impact unless it causes the
process to fail.

-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

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


On 27. 06. 19 17:57, Ben Cotton wrote:

On Thu, Jun 27, 2019 at 10:10 AM Miro Hrončok  wrote:


No, we keep everything called python3, we just provide the "python" name.
With python2 -> python3, one of the problems was that everything was just called
"python" before. We are not proposing to start doing that again. All packages
still need to eb called python3-foo, ale package still need to use python3-foo
dependencies and all packages still need to invoke "python3" explicitly.


But if everything should refer to python3 explicitly, what's the
benefit of having the unversioned Python? I understand why it's better
to have python mean python3 instead of python2, but I don't understand
why it's better than not having it.


It's easier for the users, especially beginner Python developers or data 
scientists.

$ python
bash: python: command not found

Oh right!

$ sudo dnf install python
No match for argument: python
Error: Unable to find a match

Oh well?

Fedora is equipped with fully operational, ready to use and develop on Python 
interpreter, why not let people find it?


So I might ask: What's the benefit of not having an unversioned python at all?

--
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 31 System-Wide Change proposal: Python means Python3

On Thu, Jun 27, 2019 at 10:10 AM Miro Hrončok  wrote:
>
> No, we keep everything called python3, we just provide the "python" name.
> With python2 -> python3, one of the problems was that everything was just 
> called
> "python" before. We are not proposing to start doing that again. All packages
> still need to eb called python3-foo, ale package still need to use python3-foo
> dependencies and all packages still need to invoke "python3" explicitly.
>
But if everything should refer to python3 explicitly, what's the
benefit of having the unversioned Python? I understand why it's better
to have python mean python3 instead of python2, but I don't understand
why it's better than not having it.

-- 
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: Fedora 31 Self-Contained Change proposal: DNF Make Best Mode the Default

2019-06-27 Thread Björn Persson

If I understand this change correctly, then:

· Before: If one package update is uninstallable, then that package
won't be updated, but other packages can still be updated.

· After: If one package update is uninstallable, then *nothing* will be
updated.

And you call that an improvement?

>Relevant excerpt from the updated `dnf.conf(5)`:
>
>best  boolean
>When upgrading a package, always try to install its highest version
>available, even only to find out some of its deps are not satisfiable.
>Enable this if you want to experience broken dependencies in the
>repositories firsthand. The default is True.
>

"Best" is an absolutely terrible name for this option. By what
definition is an unusable package "better" than a lower-numbered
package that can actually be installed?

>Right now, when DNF runs in `best=0` mode, if a package cannot be
>upgraded due to dependency problems, it is skipped and a warning is
>printed in the transaction summary table. However, this poses a risk
>of important security fixes being overlooked by the user in case they
>are broken for some reason, such as due to a repository
>misconfiguration or inconsistency within the metadata itself.

If there is a significant risk that the warning will be overlooked,
then how about just making the warning more visible?

>Moreover, since DNF always exits with the return code `0` (success)
>when in `best=0` mode, this mode is especially risky in automated
>scripts

Would it not be possible to program DNF to update what can be updated
and then return a nonzero exit code?

Björn Persson


pgpbPyyK8eYL_.pgp
Description: OpenPGP digital signatur
___
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

2019-06-27 Thread stan via devel

On Thu, 27 Jun 2019 16:09:07 +0200
Miro Hrončok  wrote:

> No, we keep everything called python3, we just provide the "python"
> name. With python2 -> python3, one of the problems was that
> everything was just called "python" before. We are not proposing to
> start doing that again. All packages still need to eb called
> python3-foo, ale package still need to use python3-foo dependencies
> and all packages still need to invoke "python3" explicitly.
> 
> If Python 4 ever happens, it's going to be a problem one way or
> another, this doesn't make it nay more complicated.

Thanks for the explanation.
 
___
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


On 27. 06. 19 17:15, Adam Williamson wrote:

On Thu, 2019-06-27 at 12:32 +0200, Miro Hrončok wrote:

On 26. 06. 19 20:07, Adam Williamson wrote:

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?


We did. Circumstances changed.


Out of interest, what circumstances?


Mostly date.

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

"The name 'Python' will not refer to software that will be unmaintained upstream 
for most of Fedora 31's lifetime and retired from Fedora 32."


Also, before, we have decided to not do this, as it was against the upstream 
recommendation. That recommendation is changing now as Python 2 approaches EOL.


See https://github.com/python/peps/pull/989


I'm worried
about the cost/benefit ratio on such a change.


What worries you do most about "the cost"?


I mean, generalized existential dread? :)

The most obvious is scripts with #!/usr/bin/python . OK, we can try and
find every single one in the distro and patch them (though I'm sure
some will get missed somehow)


Yes, we've already done that.
https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate_package
https://fedoraproject.org/wiki/Changes/Make_ambiguous_python_shebangs_error


but there will certainly be ones that
*aren't part of the distro* that get bitten by this.


There, you are correct. However, would we want "python" to mean Python 2 
forever? Or do we want to phase things out slowly and make a designated point in 
the future, where this is changed?


Note that users and sysadmins can change the meaning of "python", see:

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


But yeah, I don't have an itemized list of things that are going to
break or anything. I wish I did!


That would be nice.

--
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 31 System-Wide Change proposal: Python means Python3

2019-06-27 Thread Adam Williamson

On Thu, 2019-06-27 at 12:32 +0200, Miro Hrončok wrote:
> On 26. 06. 19 20:07, Adam Williamson wrote:
> > 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?
> 
> We did. Circumstances changed.

Out of interest, what circumstances?

> > I'm worried
> > about the cost/benefit ratio on such a change.
> 
> What worries you do most about "the cost"?

I mean, generalized existential dread? :)

The most obvious is scripts with #!/usr/bin/python . OK, we can try and
find every single one in the distro and patch them (though I'm sure
some will get missed somehow) but there will certainly be ones that
*aren't part of the distro* that get bitten by this.

But yeah, I don't have an itemized list of things that are going to
break or anything. I wish I did!
-- 
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: always update the bootloader during major upgrades

2019-06-27 Thread Bruno Wolff III


On Wed, Jun 26, 2019 at 14:19:26 -0600,
 Chris Murphy  wrote:


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.


How do you envision this working for rawhide?
I had a problem where grub1 configs were no longer updated with kernel 
updates, where I finally needed to upgrade to grub2.

___
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: Source files for generic-release

2019-06-27 Thread Kalpa Welivitigoda

On Thu, Jun 27, 2019 at 7:34 PM Jakub Jelen  wrote:
>
> On Thu, 2019-06-27 at 18:29 +0800, Kalpa Welivitigoda wrote:
> > Hi all,
> >
> > I am trying to build generic-release [1] with rpmbuild and I am not
> > sure where the source files (Source0, Source1 in spec) come from.
> >
> > Is there a source tar for generic-release?
>
> Hello,
> these are stored in the dist-git of the package:
>
> https://src.fedoraproject.org/rpms/generic-release/tree/master
>
> You can click there from your link through "generic-release in other
> apps" -> SCM.
>

Got it, thanks Jakub.

> Regards,
> --
> Jakub Jelen
> Senior Software Engineer
> Security Technologies
> Red Hat, Inc.
> ___
> 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



-- 
Best Regards,

Kalpa Welivitigoda
http://about.me/callkalpa
___
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: gawk 5.0.1

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

** Note that this has already landed in Rawhide:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/IEZZK7WHGF3FWFZNSCG7Z5ZZVUHVFZAF/#IEZZK7WHGF3FWFZNSCG7Z5ZZVUHVFZAF

== Summary ==
New upstream major version of gawk has been released (4.2.1 -> 5.0.X).
Among many changes, the version 5 introduced a namespaces, which may
possible break some of the existing scripts.

== Owner ==
* Name: [[User:jamartis| Jakub Martisko]]
* Email: jamar...@redhat.com


== Detailed Description ==
The new version of gawk has been released. The new version fixes a
number of bugs, some of which were quite significant. Other notable
changes include:
* The regex routines have been replaced with those from GNULIB
* Comment handling in the pretty-printer has been reworked almost
completely from scratch. As a result, comments in many corner cases
that were previously lost are now included in the formatted output.
* Namespaces have been added.
* Gawk now uses the locale settings for ignoring case in single byte
locales, instead of hardwiring in Latin-1.

The introduction of namespaces may break some scripts written for
gawk 4.2.1 due to different variable names. (This is considered to
be a bug by the upstream and there is a patch fixing this)

== Benefit to Fedora ==
See above, the main benefit are several bug fixes.

== Scope ==
* Proposal owners: Update the source archive of the gawk, drop no
longer needed patches.

* Other developers: Some modifications to existing gawk scripts may be
needed. Especially those, using the inplace gawk extension, where
some of the variables have been renamed. (This is considered to be
a bug by the upstream and there is a patch fixing this)
* Release engineering: [https://pagure.io/releng/issue/8489 #8489]
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
see above

== How To Test ==
(not provided)

== User Experience ==
(not provided)

== Dependencies ==
 dnf repoquery -q  --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'gawk'

 Judy
 Macaulay2
 acl
 apt
 autoconf213
 avr-binutils
 avr-gcc
 clucene
 cone
 crack
 dictd
 eterm
 geomview
 git
 glibc
 gnome-libs
 gnome-menus
 gpgme
 gpm
 gscan2pdf
 gyachi
 japanese-bitmap-fonts
 kde-filesystem
 kdelibs3
 kernel
 kernel-tools
 krb5
 lapack
 libAfterImage
 libassuan
 libecpg
 libgcrypt
 libgpg-error
 libguestfs
 libksba
 libpaper
 libphidget
 libpq
 libsvm
 libtpms
 libvirt
 linuxdoc-tools
 lm_sensors
 lxcfs
 maildrop
 mingw-clucene
 nco
 netcdf
 nss
 ocaml
 ocaml-calendar
 ocaml-csv
 ocaml-curl
 ocaml-curses
 ocaml-expat
 ocaml-extlib
 ocaml-findlib
 ocaml-libvirt
 ocaml-pcre
 ocaml-ssl
 ocaml-xml-light
 paperkey
 pcb
 postgresql
 powermanga
 quilt
 rbldnsd
 rpm
 rss-glx
 samba
 selinux-policy
 stow
 surfraw
 swig
 systemd
 topgit
 tzdata
 virt-top
 xblast
 xdg-utils
 xfsdump
 xschem
 xscreensaver
 yara
 zsh

 dnf repoquery -q  --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora --enablerepo=updates
--enablerepo=updates-testing --whatrequires 'gawk'

 R-core
 akmods
 am-utils
 authselect-libs
 autoconf213
 autofs
 backupninja
 calamares
 centerim
 ceph-selinux
 check-checkmk
 checksec
 cloud-utils
 cloud-utils-growpart
 condor-vm-gahp
 copr-backend
 coreos-installer
 ctdb
 dhcp-client
 dkms
 docbook-utils
 dracut-kiwi-oem-dump
 e2fsprogs-devel
 esh
 execstack
 flamegraph-stackcollapse
 flamegraph-stackcollapse-perf
 gawk-abort
 gawk-devel
 gawk-doc
 gawk-errno
 gawk-json
 gawk-lmdb
 gawk-nl_langinfo
 gawk-pgsql
 gawk-redis
 gawk-select
 gawk-xml
 gawkextlib
 geeqie
 git-secret
 glimmer
 groff
 gt5
 gtkpod
 guilt
 hylafax+
 initscripts
 krb5-libs
 latex2rtf
 lbdb
 lde
 libguestfs
 libsmi
 linuxconsoletools
 linuxdoc-tools
 lorax
 ltunify
 m17n-db
 neofetch
 netconsole-service
 netdump-server
 network-scripts
 nfs-utils
 ocaml
 opari2
 pal
 pcp
 phpPgAdmin
 pkgdiff
 policycoreutils
 prettyping
 quilt
 rarian
 readonly-root
 rear
 redhat-lsb-core
 redis
 resource-agents
 rf
 rpm-build
 rpmdevtools
 rust-packaging
 screenie
 selinux-policy
 seqan
 seqan2-apps
 sofia-sip-devel
 spectre-meltdown-checker
 surfraw
 syslog-ng
 systemtap-testsuite
 testssl
 topgit
 translate-shell
 tuned
 tw
 twa
 txt2man
 unity-gtk-module-common
 virt-p2v-maker
 virt-v2v
 vzctl-core
 xfce4-dev-tools
 xschem
 ypserv
 zram

== Contingency Plan ==
* Contingency mechanism: Reverting to gawk 4.2.1 if significant issues
are discovered
* Contingency deadline: Beta freeze (?)
* Blocks release? No
* Blocks product? no

== Documentation ==
* http://git.savannah.gnu.org/cgit/gawk.git/tree/NEWS?h=gawk-5.0-stable
* https://www.gnu.org/software/gawk/manual/
* https://www.gnu.org/software/gawk/manual/gawk.html#Namespaces

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat

Fedora 31 Self-Contained Change proposal: DNF Make Best Mode the Default

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

== Summary ==
Currently, DNF prefers clean dependency resolution over package updates;
a package (almost) silently won't get updated to a newer version if the new
version has dependency problems. DNF will be changed to prefer updates and fail
if they have dependency resolution issues, while the failure has a
temporal or permanent workaround
hint for users who want to use the older behavior.

== Owner ==
* Name: [[User:jmracek| Jaroslav Mracek]]
* Email: jmra...@redhat.com


== Detailed Description ==
Change the built-in default value of the `best` configuration option
from `0` (false) to `1` (true).

As a result, unless `best` is overridden in the `/etc/dnf/dnf.conf`
file or using `--setopt`, it will default to `1`. As a convenience, we
will also put the explicit `best=1` assignment in the shipped
`/etc/dnf/dnf.conf` file for better transparency, and introduce the
new `--nobest` command-line switch.

The purpose of the `--nobest` switch (as a shorthand for
`--setopt=best=0`) is to make it easy for the user to override the
default setting when needed, and it will also be
[https://github.com/rpm-software-management/dnf/pull/1311/commits/9a3e8fd0da49291d30fd1fef527cffb0bf3f047d#diff-6c823931c6d150295e5011fac6529ab9R144
suggested] in the DNF output when a dependency error occurs.

Relevant excerpt from the updated `dnf.conf(5)`:

best  boolean
When upgrading a package, always try to install its highest version
available, even only to find out some of its deps are not satisfiable.
Enable this if you want to experience broken dependencies in the
repositories firsthand. The default is True.


Relevant excerpt from the updated `dnf(8)`:

--nobest
Set best option as false, therefore transactions are not limited to
only best candidates.


'''Change in DNF output - missing vim-enhanced-2:8.1.1561-1.fc30'''

Original output. DNF succeed with return code 0:

sudo dnf upgrade
Last metadata expiration check: 2:16:40 ago on Mon 24 Jun 2019 04:27:16 PM CEST.
Dependencies resolved.

 Problem: package vim-enhanced-2:8.1.1471-1.fc30.x86_64 requires
vim-common = 2:8.1.1471-1.fc30, but none of the providers can be
installed
  - cannot install both vim-common-2:8.1.1561-1.fc30.x86_64 and
vim-common-2:8.1.1471-1.fc30.x86_64
  - problem with installed package vim-enhanced-2:8.1.1471-1.fc30.x86_64
  - cannot install the best update candidate for package
vim-common-2:8.1.1471-1.fc30.x86_64
  - package vim-enhanced-2:8.1.1561-1.fc30.x86_64 is excluded
===
 PackageArchitecture   Version
   Repository   Size
===
Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
 vim-common x86_64
2:8.1.1561-1.fc30  updates 6.7
M

Transaction Summary
===
Skip  1 Package

Nothing to do.
Complete!


Output after the change. DNF fails with return code 1, but proposing
`--nobest` option as an option to resolve the issue:

sudo dnf upgrade
Last metadata expiration check: 2:16:36 ago on Mon 24 Jun 2019 04:27:16 PM CEST.
Error:
 Problem: package vim-enhanced-2:8.1.1471-1.fc30.x86_64 requires
vim-common = 2:8.1.1471-1.fc30, but none of the providers can be
installed
  - cannot install both vim-common-2:8.1.1561-1.fc30.x86_64 and
vim-common-2:8.1.1471-1.fc30.x86_64
  - problem with installed package vim-enhanced-2:8.1.1471-1.fc30.x86_64
  - cannot install the best update candidate for package
vim-common-2:8.1.1471-1.fc30.x86_64
  - package vim-enhanced-2:8.1.1561-1.fc30.x86_64 is excluded
(try to add '--allowerasing' to command line to replace conflicting
packages or '--skip-broken' to skip uninstallable packages or
'--nobest' to use not only best candidate packages)


'''Q'''

Can be a default of the best configuration option overwritten easily
and permanently by user?
Yes, just add `best=false` to `/etc/dnf/dnf.conf`

[main]
best=False


Can be a default of the best configuration option overwritten easily
from commandline?
Yes, just add `--nobest` to command

dnf upgrade --nobest


What about PackageKit and Gnome Software?

PackageKit and Gnome Software will be not affected by the change. In
case that the same behavior will be desired for PackageKit, It will
require changes in PackageKit code.


What about Microdnf?

Microdnf will be not affected by the change. There is a plan to unify
functional parity and behavior DNF with Microdnf but not before Fedora
33.



== Benefit to Fedora ==

This change allows the users to be properly notified

Fedora 31 System-Wide Change proposal: gawk 5.0.1

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

** Note that this has already landed in Rawhide:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IEZZK7WHGF3FWFZNSCG7Z5ZZVUHVFZAF/#IEZZK7WHGF3FWFZNSCG7Z5ZZVUHVFZAF

== Summary ==
New upstream major version of gawk has been released (4.2.1 -> 5.0.X).
Among many changes, the version 5 introduced a namespaces, which may
possible break some of the existing scripts.

== Owner ==
* Name: [[User:jamartis| Jakub Martisko]]
* Email: jamar...@redhat.com


== Detailed Description ==
The new version of gawk has been released. The new version fixes a
number of bugs, some of which were quite significant. Other notable
changes include:
* The regex routines have been replaced with those from GNULIB
* Comment handling in the pretty-printer has been reworked almost
completely from scratch. As a result, comments in many corner cases
that were previously lost are now included in the formatted output.
* Namespaces have been added.
* Gawk now uses the locale settings for ignoring case in single byte
locales, instead of hardwiring in Latin-1.

The introduction of namespaces may break some scripts written for
gawk 4.2.1 due to different variable names. (This is considered to
be a bug by the upstream and there is a patch fixing this)

== Benefit to Fedora ==
See above, the main benefit are several bug fixes.

== Scope ==
* Proposal owners: Update the source archive of the gawk, drop no
longer needed patches.

* Other developers: Some modifications to existing gawk scripts may be
needed. Especially those, using the inplace gawk extension, where
some of the variables have been renamed. (This is considered to be
a bug by the upstream and there is a patch fixing this)
* Release engineering: [https://pagure.io/releng/issue/8489 #8489]
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
see above

== How To Test ==
(not provided)

== User Experience ==
(not provided)

== Dependencies ==
 dnf repoquery -q  --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'gawk'

 Judy
 Macaulay2
 acl
 apt
 autoconf213
 avr-binutils
 avr-gcc
 clucene
 cone
 crack
 dictd
 eterm
 geomview
 git
 glibc
 gnome-libs
 gnome-menus
 gpgme
 gpm
 gscan2pdf
 gyachi
 japanese-bitmap-fonts
 kde-filesystem
 kdelibs3
 kernel
 kernel-tools
 krb5
 lapack
 libAfterImage
 libassuan
 libecpg
 libgcrypt
 libgpg-error
 libguestfs
 libksba
 libpaper
 libphidget
 libpq
 libsvm
 libtpms
 libvirt
 linuxdoc-tools
 lm_sensors
 lxcfs
 maildrop
 mingw-clucene
 nco
 netcdf
 nss
 ocaml
 ocaml-calendar
 ocaml-csv
 ocaml-curl
 ocaml-curses
 ocaml-expat
 ocaml-extlib
 ocaml-findlib
 ocaml-libvirt
 ocaml-pcre
 ocaml-ssl
 ocaml-xml-light
 paperkey
 pcb
 postgresql
 powermanga
 quilt
 rbldnsd
 rpm
 rss-glx
 samba
 selinux-policy
 stow
 surfraw
 swig
 systemd
 topgit
 tzdata
 virt-top
 xblast
 xdg-utils
 xfsdump
 xschem
 xscreensaver
 yara
 zsh

 dnf repoquery -q  --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora --enablerepo=updates
--enablerepo=updates-testing --whatrequires 'gawk'

 R-core
 akmods
 am-utils
 authselect-libs
 autoconf213
 autofs
 backupninja
 calamares
 centerim
 ceph-selinux
 check-checkmk
 checksec
 cloud-utils
 cloud-utils-growpart
 condor-vm-gahp
 copr-backend
 coreos-installer
 ctdb
 dhcp-client
 dkms
 docbook-utils
 dracut-kiwi-oem-dump
 e2fsprogs-devel
 esh
 execstack
 flamegraph-stackcollapse
 flamegraph-stackcollapse-perf
 gawk-abort
 gawk-devel
 gawk-doc
 gawk-errno
 gawk-json
 gawk-lmdb
 gawk-nl_langinfo
 gawk-pgsql
 gawk-redis
 gawk-select
 gawk-xml
 gawkextlib
 geeqie
 git-secret
 glimmer
 groff
 gt5
 gtkpod
 guilt
 hylafax+
 initscripts
 krb5-libs
 latex2rtf
 lbdb
 lde
 libguestfs
 libsmi
 linuxconsoletools
 linuxdoc-tools
 lorax
 ltunify
 m17n-db
 neofetch
 netconsole-service
 netdump-server
 network-scripts
 nfs-utils
 ocaml
 opari2
 pal
 pcp
 phpPgAdmin
 pkgdiff
 policycoreutils
 prettyping
 quilt
 rarian
 readonly-root
 rear
 redhat-lsb-core
 redis
 resource-agents
 rf
 rpm-build
 rpmdevtools
 rust-packaging
 screenie
 selinux-policy
 seqan
 seqan2-apps
 sofia-sip-devel
 spectre-meltdown-checker
 surfraw
 syslog-ng
 systemtap-testsuite
 testssl
 topgit
 translate-shell
 tuned
 tw
 twa
 txt2man
 unity-gtk-module-common
 virt-p2v-maker
 virt-v2v
 vzctl-core
 xfce4-dev-tools
 xschem
 ypserv
 zram

== Contingency Plan ==
* Contingency mechanism: Reverting to gawk 4.2.1 if significant issues
are discovered
* Contingency deadline: Beta freeze (?)
* Blocks release? No
* Blocks product? no

== Documentation ==
* http://git.savannah.gnu.org/cgit/gawk.git/tree/NEWS?h=gawk-5.0-stable
* https://www.gnu.org/software/gawk/manual/
* https://www.gnu.org/software/gawk/manual/gawk.html#Namespaces

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat

Fedora 31 Self-Contained Change proposal: DNF Make Best Mode the Default

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

== Summary ==
Currently, DNF prefers clean dependency resolution over package updates;
a package (almost) silently won't get updated to a newer version if the new
version has dependency problems. DNF will be changed to prefer updates and fail
if they have dependency resolution issues, while the failure has a
temporal or permanent workaround
hint for users who want to use the older behavior.

== Owner ==
* Name: [[User:jmracek| Jaroslav Mracek]]
* Email: jmra...@redhat.com


== Detailed Description ==
Change the built-in default value of the `best` configuration option
from `0` (false) to `1` (true).

As a result, unless `best` is overridden in the `/etc/dnf/dnf.conf`
file or using `--setopt`, it will default to `1`. As a convenience, we
will also put the explicit `best=1` assignment in the shipped
`/etc/dnf/dnf.conf` file for better transparency, and introduce the
new `--nobest` command-line switch.

The purpose of the `--nobest` switch (as a shorthand for
`--setopt=best=0`) is to make it easy for the user to override the
default setting when needed, and it will also be
[https://github.com/rpm-software-management/dnf/pull/1311/commits/9a3e8fd0da49291d30fd1fef527cffb0bf3f047d#diff-6c823931c6d150295e5011fac6529ab9R144
suggested] in the DNF output when a dependency error occurs.

Relevant excerpt from the updated `dnf.conf(5)`:

best  boolean
When upgrading a package, always try to install its highest version
available, even only to find out some of its deps are not satisfiable.
Enable this if you want to experience broken dependencies in the
repositories firsthand. The default is True.


Relevant excerpt from the updated `dnf(8)`:

--nobest
Set best option as false, therefore transactions are not limited to
only best candidates.


'''Change in DNF output - missing vim-enhanced-2:8.1.1561-1.fc30'''

Original output. DNF succeed with return code 0:

sudo dnf upgrade
Last metadata expiration check: 2:16:40 ago on Mon 24 Jun 2019 04:27:16 PM CEST.
Dependencies resolved.

 Problem: package vim-enhanced-2:8.1.1471-1.fc30.x86_64 requires
vim-common = 2:8.1.1471-1.fc30, but none of the providers can be
installed
  - cannot install both vim-common-2:8.1.1561-1.fc30.x86_64 and
vim-common-2:8.1.1471-1.fc30.x86_64
  - problem with installed package vim-enhanced-2:8.1.1471-1.fc30.x86_64
  - cannot install the best update candidate for package
vim-common-2:8.1.1471-1.fc30.x86_64
  - package vim-enhanced-2:8.1.1561-1.fc30.x86_64 is excluded
===
 PackageArchitecture   Version
   Repository   Size
===
Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
 vim-common x86_64
2:8.1.1561-1.fc30  updates 6.7
M

Transaction Summary
===
Skip  1 Package

Nothing to do.
Complete!


Output after the change. DNF fails with return code 1, but proposing
`--nobest` option as an option to resolve the issue:

sudo dnf upgrade
Last metadata expiration check: 2:16:36 ago on Mon 24 Jun 2019 04:27:16 PM CEST.
Error:
 Problem: package vim-enhanced-2:8.1.1471-1.fc30.x86_64 requires
vim-common = 2:8.1.1471-1.fc30, but none of the providers can be
installed
  - cannot install both vim-common-2:8.1.1561-1.fc30.x86_64 and
vim-common-2:8.1.1471-1.fc30.x86_64
  - problem with installed package vim-enhanced-2:8.1.1471-1.fc30.x86_64
  - cannot install the best update candidate for package
vim-common-2:8.1.1471-1.fc30.x86_64
  - package vim-enhanced-2:8.1.1561-1.fc30.x86_64 is excluded
(try to add '--allowerasing' to command line to replace conflicting
packages or '--skip-broken' to skip uninstallable packages or
'--nobest' to use not only best candidate packages)


'''Q'''

Can be a default of the best configuration option overwritten easily
and permanently by user?
Yes, just add `best=false` to `/etc/dnf/dnf.conf`

[main]
best=False


Can be a default of the best configuration option overwritten easily
from commandline?
Yes, just add `--nobest` to command

dnf upgrade --nobest


What about PackageKit and Gnome Software?

PackageKit and Gnome Software will be not affected by the change. In
case that the same behavior will be desired for PackageKit, It will
require changes in PackageKit code.


What about Microdnf?

Microdnf will be not affected by the change. There is a plan to unify
functional parity and behavior DNF with Microdnf but not before Fedora
33.



== Benefit to Fedora ==

This change allows the users to be properly notified

Re: [HEADS UP] SOURCE_DATE_EPOCH environment variable set in rpmbuild

2019-06-27 Thread Charalampos Stratakis



- Original Message -
> From: "Vít Ondruch" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Thursday, June 27, 2019 12:18:13 PM
> Subject: [HEADS UP] SOURCE_DATE_EPOCH environment variable set in rpmbuild
> 
> 
> 
> I just want to give heads up that today, my PR [1] allowing to set
> SOURCE_DATE_EPOCH environment variable during build of RPM was merged into
> redhat-rpm-config. This means that some packages might have a bit more
> reproducible builds.

Awesome! Thanks for that!

> 
> This was triggered by this ticket [2] and subsequent discussion on Ruby-SIG
> ML [3]. Please keep in mind that while your packages might benefit from this
> if it respects the environment variable, this is *not* part of any broader
> reproducible builds effort.
> 
> 
> 
> 
> 
> Vít
> 
> 
> 
> 
> 
> 
> 
> 
> [1] https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/57
> 
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1719647
> 
> [3]
> https://lists.fedoraproject.org/archives/list/ruby-...@lists.fedoraproject.org/message/FFGZUV5HJTZPJ7JR2K7TAORXBR7TJ4KZ/
> 
> ___
> 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
> 

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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


On 27. 06. 19 16:02, stan via devel wrote:

On Thu, 27 Jun 2019 12:32:26 +0200
Miro Hrončok  wrote:


On 26. 06. 19 20:07, Adam Williamson wrote:

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?


We did. Circumstances changed.


I'm worried
about the cost/benefit ratio on such a change.


What worries you do most about "the cost"?


Wouldn't this mean that when python4 is released, there is a replay of
the python2 -> python3 transition experience?


No, we keep everything called python3, we just provide the "python" name.
With python2 -> python3, one of the problems was that everything was just called 
"python" before. We are not proposing to start doing that again. All packages 
still need to eb called python3-foo, ale package still need to use python3-foo 
dependencies and all packages still need to invoke "python3" explicitly.


If Python 4 ever happens, it's going to be a problem one way or another, this 
doesn't make it nay more complicated.


--
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 31 System-Wide Change proposal: Python means Python3

2019-06-27 Thread stan via devel

On Thu, 27 Jun 2019 12:32:26 +0200
Miro Hrončok  wrote:

> On 26. 06. 19 20:07, Adam Williamson wrote:
> > 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?  
> 
> We did. Circumstances changed.
> 
> > I'm worried
> > about the cost/benefit ratio on such a change.  
> 
> What worries you do most about "the cost"?

Wouldn't this mean that when python4 is released, there is a replay of
the python2 -> python3 transition experience?
___
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: adding speech installation to fedora network installation image

2019-06-27 Thread mcatanzaro

On Thu, Jun 27, 2019 at 8:31 AM, stan via devel 
 wrote:

I'm not familiar enough with orca and gnome to say if this is a bug or
not.  When I looked for bugs, I found a bug from February that stated


Only the live image runs in a GNOME session where GNOME session 
services like orca are expected to be working. The netinstall image 
only runs anaconda, it doesn't run GNOME at all. I don't know whether 
the anaconda developers except orca to be supported in netinstall mode.


Michael

___
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: adding speech installation to fedora network installation image

2019-06-27 Thread stan via devel

On Thu, 27 Jun 2019 10:26:23 +0200
Mmobilea  wrote:

> But I have tried fedora workstation net inst image, not server image.
> I pressed alt+super+s, and orca doesn’t run on net installer. Next, I
> thought, that I must to have wired internet connection. I created a
> USB hodspot with my mobile phone, and it wasn’t any speech.

I'm not familiar enough with orca and gnome to say if this is a bug or
not.  When I looked for bugs, I found a bug from February that stated 

WARNING: Could not parse desktop file orca-autostart.desktop or it
references a not found TryExec binary

I don't know if that would cause the behavior you are seeing.  It might
be that there is not enough space on the netinstall image to support
orca, and that it is only supported on the full image.  If you like, I
can open a bugzilla about this for you, to see if your experience is
expected behavior because of space limitations, or a bug.
___
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

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

Paul Howarth  changed:

   What|Removed |Added

   Fixed In Version|perl-IO-Socket-SSL-2.066-4. |perl-IO-Socket-SSL-2.066-5.
   |fc31|fc31



--- Comment #3 from Paul Howarth  ---
(In reply to Petr Pisar from comment #2)
> > -# 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?

Yes, it should. That dependency dates back to before the openssl/openssl-libs
split in Fedora 18.

-- 
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 1724585] perl-Test-Compile-2.1.0 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Test-Compile-2.1.0-1.f
   ||c31
 Resolution|--- |RAWHIDE
Last Closed||2019-06-27 11:53:27



-- 
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 1724585] New: perl-Test-Compile-2.1.0 is available

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

Bug ID: 1724585
   Summary: perl-Test-Compile-2.1.0 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Test-Compile
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 2.1.0
Current version/release in rawhide: 2.0.1-1.fc31
URL: http://search.cpan.org/dist/Test-Compile/

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/3388/

-- 
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

Orphaned rubygem-jquery-datatables-rails

2019-06-27 Thread Pavel Valena

as I have no use for it and nothing depends on it.

I have also updated it prior to orphaning.

Regards,
-- 
Pavel Valena
Software Engineer, Red Hat
Brno, Czech Republic
___
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: Source files for generic-release

2019-06-27 Thread Jakub Jelen

On Thu, 2019-06-27 at 18:29 +0800, Kalpa Welivitigoda wrote:
> Hi all,
> 
> I am trying to build generic-release [1] with rpmbuild and I am not
> sure where the source files (Source0, Source1 in spec) come from.
> 
> Is there a source tar for generic-release?

Hello,
these are stored in the dist-git of the package:

https://src.fedoraproject.org/rpms/generic-release/tree/master

You can click there from your link through "generic-release in other
apps" -> SCM.

Regards,
-- 
Jakub Jelen
Senior Software Engineer
Security Technologies
Red Hat, Inc.
___
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: [Python-Dev] Re: [RELEASE] Python 3.7.4rc1 and 3.6.9rc1 are now available

On 27. 06. 19 11:54, Miro Hrončok wrote:

On 26. 06. 19 23:59, Ned Deily wrote:

On Jun 25, 2019, at 18:10, Miro Hrončok wrote:
I'm working on getting 3.7.4rc1 to Fedora rawhide (the "master branch" of
Fedora). If nothing goes wrong with the build, it should land within a day.
There are checks in Fedora that should uncover any suspicious test failures
of our Python packages, if that happens, we'll report back hopefully before
2019-06-28 AOE.

Thanks for the heads-up, Miro! I'm hoping to be able to start the manufacture
of 3.7.4 final a bit early so we can release on 06-28, it would be very
helpful if you could pass along any potential showstopper problems as soon as
you can and before approximately 06-28 1600Z.

There are couple Fedora packages that started to fail around the time when we
updated:

https://apps.fedoraproject.org/koschei/affected-by/python3?epoch1=0=3.7.3=3.fc31=0=3.7.4~rc1=1.fc31=f31

(However, they can be, and mostly are, unrelated to Python 3.4.7 update.)

Fox example pipenv is a false positive, pyqt5 fails on Python 2 for unrelated
reason etc.

One package that seems weird is python-dask, where there are some memory errors
and threading errors:

https://kojipkgs.fedoraproject.org/work/tasks/8942/35858942/build.log

Not sure if this is random or related to 3.7.4, running a couple more builds
now.

dask failures appear random.

--
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

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


On 26. 06. 19 20:07, Adam Williamson wrote:

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?


We did. Circumstances changed.


I'm worried
about the cost/benefit ratio on such a change.


What worries you do most about "the cost"?

--
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

Source files for generic-release

2019-06-27 Thread Kalpa Welivitigoda

Hi all,

I am trying to build generic-release [1] with rpmbuild and I am not
sure where the source files (Source0, Source1 in spec) come from.

Is there a source tar for generic-release?

[1] https://apps.fedoraproject.org/packages/generic-release/sources/spec/

Kalpa Welivitigoda
___
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

[HEADS UP] SOURCE_DATE_EPOCH environment variable set in rpmbuild

2019-06-27 Thread Vít Ondruch

I just want to give heads up that today, my PR [1] allowing to set
SOURCE_DATE_EPOCH environment variable during build of RPM was merged
into redhat-rpm-config. This means that some packages might have a bit
more reproducible builds.

This was triggered by this ticket [2] and subsequent discussion on
Ruby-SIG ML [3]. Please keep in mind that while your packages might
benefit from this if it respects the environment variable, this is *not*
part of any broader reproducible builds effort.


Vít



[1] https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/57

[2] https://bugzilla.redhat.com/show_bug.cgi?id=1719647

[3]
https://lists.fedoraproject.org/archives/list/ruby-...@lists.fedoraproject.org/message/FFGZUV5HJTZPJ7JR2K7TAORXBR7TJ4KZ/

___
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: [Python-Dev] Re: [RELEASE] Python 3.7.4rc1 and 3.6.9rc1 are now available

On 26. 06. 19 23:59, Ned Deily wrote:

On Jun 25, 2019, at 18:10, Miro Hrončok wrote:

I'm working on getting 3.7.4rc1 to Fedora rawhide (the "master branch" of
Fedora). If nothing goes wrong with the build, it should land within a day. There are
checks in Fedora that should uncover any suspicious test failures of our Python packages,
if that happens, we'll report back hopefully before 2019-06-28 AOE.

Thanks for the heads-up, Miro! I'm hoping to be able to start the manufacture
of 3.7.4 final a bit early so we can release on 06-28, it would be very helpful
if you could pass along any potential showstopper problems as soon as you can
and before approximately 06-28 1600Z.

There are couple Fedora packages that started to fail around the time when we
updated:

https://apps.fedoraproject.org/koschei/affected-by/python3?epoch1=0=3.7.3=3.fc31=0=3.7.4~rc1=1.fc31=f31

(However, they can be, and mostly are, unrelated to Python 3.4.7 update.)

Fox example pipenv is a false positive, pyqt5 fails on Python 2 for unrelated
reason etc.

One package that seems weird is python-dask, where there are some memory errors
and threading errors:

https://kojipkgs.fedoraproject.org/work/tasks/8942/35858942/build.log

Not sure if this is random or related to 3.7.4, running a couple more builds
now.

Spec/macro comments (was: Any new restriction in Koji added recently in Rawhide?)

2019-06-27 Thread Panu Matilainen


On 6/18/19 2:05 PM, Panu Matilainen wrote:

On 6/18/19 10:15 AM, Florian Weimer wrote:

* Panu Matilainen:

Are # lines stripped always, even in scriptlets?



No, because whatever is in scriptlets body belongs to the scriptlet 
interpreter which certainly is not rpm. Oh, I know...


To that cause, I just submitted 
https://github.com/rpm-software-management/rpm/pull/753. Doesn't help 
with comments after %endif though.


Just FWIW, %dnl support is now in rawhide.

What it means in practise is that for the first time there's now a way 
to escape macro expansion for the rest of the line (so eg multiline 
macros such as %configure can be commented out with it), it's possible 
to add comments to macros themselves and comments can appear anywhere in 
the spec.


The classical example of this is comments intended for the scriptlet 
below ending up in the previous scriptlet body.

---
%post -p /sbin/ldconfig

%dnl postun is needed to handle foo
%postun
%dnl always do bar first
%{_bindir}/do_bar
%{_bindir}/do_foo
---

...results in:

$ rpm -qp --scripts scriptintr-1.0-1.fc30.noarch.rpm
postinstall program: /sbin/ldconfig
postuninstall scriptlet (using /bin/sh):
/usr/bin/do_bar
/usr/bin/do_foo

...wheras #-comments would end up in the package and in case of "postun 
is needed to handle foo", in the body of the wrong scriptlet that will 
cause ldconfig to complain.


- 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: Please update form pep8 to pycodestyle

2019-06-27 Thread Dridi Boukelmoune

On Wed, Jun 26, 2019 at 3:06 PM José Abílio Matos  wrote:
>
> 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. :-)

Well, if the linter brings actual value (shellcheck for example does)
and maintainers use that to locally patch whatever fails linting and
sends the patches upstream bragging that this was First discovered in
Rawhide because we have the latest release of the linter, I see no
problem with that :p

Cheers
___
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 1723600] perl-EV-4.27 is available