Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week

[Petr Viktorin]

On 30. 06. 23 18:13, Jerry James wrote:

On Fri, Jun 30, 2023 at 9:02 AM Petr Viktorin  wrote:

The use_tracing was fixed for most code, but still remained in
profiling/tracing support.
I filed a PR for Cython:
https://src.fedoraproject.org/rpms/Cython/pull-request/46

(Hoping for a Cython 3 release soon -- things are getting fixed properly
for 3.0, but the stable branch is pretty much on life support now...)


Ah great, thank you.


Do you have an example of a package that fails on ob_digit?
Uses of that should be behind CYTHON_USE_PYLONG_INTERNALS which should
be off by default (and probably will stay off until Cython 3.0).


I was trying to fix a couple of Paulo's packages, python-cypari2 and
python-fpylll.  They directly access ob_digit.  My attempts to fix
them seemed to be stymied by the Cython definition I mentioned, but
maybe I just don't know what I'm doing. :-)  If you have suggestions
on how to approach the fixes for those two packages, I would be very
grateful.


Sadly these are too involved for me to fix today, but I filed upstream 
issues:


https://github.com/sagemath/cypari2/issues/137
https://github.com/fplll/fplll/issues/514
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week

[Petr Viktorin]

On 29. 06. 23 22:37, Jerry James wrote:

On Tue, Jun 13, 2023 at 6:03 AM Tomas Hrnciar  wrote:

If you'd like to build a package after we already rebuilt it, you should be 
able to build it in the side tag via:

on branch rawhide:
$ fedpkg build --target=f39-python
$ koji wait-repo f39-python --build 


I'm trying to help by fixing packages I maintain that failed to build
on the first attempt.  However, I'm having some issues with Cython
generating incorrect code.  The most recent example is the
python-pytest-cython package, which fails because Cython generates
code that accesses the use_tracing field of _PyCFrame.  That field was
removed in python 3.12.


Thanks for your help!

The use_tracing was fixed for most code, but still remained in 
profiling/tracing support.
I filed a PR for Cython: 
https://src.fedoraproject.org/rpms/Cython/pull-request/46


(Hoping for a Cython 3 release soon -- things are getting fixed properly 
for 3.0, but the stable branch is pretty much on life support now...)




There are a couple of other packages that have issues with the
representation of a long object.  In python 3.11 and before, we had:

struct _longobject {
 PyObject_VAR_HEAD
 digit ob_digit[1];
};

In python 3.12, we have:

typedef struct _PyLongValue {
 uintptr_t lv_tag; /* Number of digits, sign and flags */
 digit ob_digit[1];
} _PyLongValue;

struct _longobject {
 PyObject_HEAD
 _PyLongValue long_value;
};

The Cython package in the side tag has this in Includes/cpython/longintrepr.pxd:

 ctypedef class __builtin__.py_long [object PyLongObject]:
 cdef digit* ob_digit

which is incorrect for python 3.12.  I think I'm stuck until Cython
has been updated for python 3.12.


Do you have an example of a package that fails on ob_digit?
Uses of that should be behind CYTHON_USE_PYLONG_INTERNALS which should 
be off by default (and probably will stay off until Cython 3.0).

___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Python 3.11 final release might be delayed to December

[Petr Viktorin]

On 05. 07. 22 15:54, Richard Shaw wrote:
On Tue, Jul 5, 2022 at 8:07 AM Richard W.M. Jones > wrote:


On Tue, Jul 05, 2022 at 01:17:39PM +0200, Miro Hrončok wrote:
 > Hello,
 > forwarding this  message to Fedora.
 >
 > Will know more by the end of this week -- we might need to consider
 > reverting back to Python 3.10 if we don't want to ship Fedora 37 GA
 > with a beta version of Python :(

Is there a reason why shipping a beta version of Python would be bad?
I've been using it on my main development machine for a few weeks and
for the (fairly limited) Python stuff I do it seems to be fine.

It'd be a problem if it was causing bugs.


Would it not make sense then to review the blocker bugs  and then 
determine if they are blockers for us?


The issue is not bug(s but ABI compatibility. We can't update from a 
Beta to (say) 3.11.1 in stable Fedora, because all PYC files and 
extension modules would break if the C-ABI or PYC files would break.

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Help needed: liquidctl and python3.11

[Petr Viktorin]

On 30. 06. 22 15:13, Artur Frenszek-Iwicki wrote:

Some time ago we've had python3.11 land in Rawhide, with a rebuild of dependent 
packages.
One of my packages, liquidctl, fails to build with the new Python, and since my 
knowledge of the language
stops at "I used it to rewrite some bash scripts", I'd need some help.


Hello,
I replied on the bug: https://bugzilla.redhat.com/show_bug.cgi?id=2098741#c3
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Does anybody still use `starship'?

[Petr Viktorin]

On 10. 01. 22 18:41, Dan Čermák wrote:

Otto Urpelainen  writes:


Igor Raits kirjoitti 9.1.2022 klo 13.24:

Hello,

I'm interested to hear if there are any users of the `starship'
application here in Fedora that consume it from the repositories.
Please speak up if you do!


I use it, too.


Same here and very thankful for being able to do that!


Same here! And I'm happy with what the Fedora version can do.
Thank you!
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: tzdata-minimal (Self-Contained Change proposal)

[Petr Viktorin]

On 15. 07. 21 20:33, Carlos O'Donell wrote:

On 7/15/21 6:34 AM, Zbigniew Jędrzejewski-Szmek wrote:

On Tue, Jul 06, 2021 at 01:20:47PM -0400, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/tzdata-minimal

== Summary ==
Split the tzdata package into two parts - tzdata and tzdata-minimal.
tzdata will require tzdata-minimal.  tzdata-minimal provides the
minimal files needed to support UTC on containers.

== Owner ==
* Name: Patsy Griffin (Franklin)
* Email: pa...@redhat.com


== Detailed Description ==
This is the first step towards providing support for a minimal, UTC
only, version of tzdata for containers.  The tzdata-minimal package
will be a stand-alone, UTC only, subset of tzdata. The tzdata package
will require tzdata-minimal.

With this framework in place, other packages can develop code to
detect a minimal tzdata installation.  These packages will also need
to provide appropriate messages when users request timezone
information not available when only tzdata-minimal is installed.


In general, I like the idea of making it easier to not install tzdata.
For many machines it's completely unnecessary, and 5MB is enough to
make this worthwhile.


Thanks for supporting the idea.


I don't know enough about all the consumers to comment on the details.
FWIW, systemd-timedated already has a reasonable message that encompasses
both possible errors:

   $ timedatectl set-timezone Europe/Warsaw2
   Failed to set time zone: Invalid or not installed time zone 'Europe/Warsaw2'

But I think it'd be useful to use a different message if we can
distinguish the two cases. I'd be happy to take a patch...


Yes, you could say "invalid" (zone table files installed) if the zone is not
in one of the tables, and "invalid or not installed" if there are no files
(no tzdata installed).


Without the split (i.e. if either all or none of tzdata is installed), 
it would be similar:
If a zone1970.tab exists but doesn't list the zone (or, hopefully 
equivalently: a zone1970.tab exists but there's no file for the zone): 
it's "Invalid time zone".

If the table doesn't exist: it's "Invalid or not installed".


We are still in the process of checking with upstream tzdata if they are
comfortable with, and will support *not* installing some of the zones, and
document that upstream.

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: tzdata-minimal (Self-Contained Change proposal)

[Petr Viktorin]

On 14. 07. 21 12:43, Jonathan Wakely wrote:

On Tue, 13 Jul 2021 at 21:42, Carlos O'Donell wrote:

(1) Missing files vs. No /usr/share/zoneinfo.

All existing third-party software must handle zone name changes today,
so there must be some way to handle the error that a given zone is
missing (changed names).

Let me talk a bit about the new C++ time zone API I have been looking
at with Jonathan Wakely.

Errors based on this will be likely correct e.g. get_tz_dir() from the
currently proposed C++ API for this (see (2)):


N.B. The functions below are not part of the standardized API, they
are implementation details of a specific implementation of that API.



  353 CONSTDATA auto tz_dir_default = "/usr/share/zoneinfo";
  354 CONSTDATA auto tz_dir_buildroot = "/usr/share/zoneinfo/uclibc";
  355
  356 // Check special path which is valid for buildroot with uclibc builds
  357 if(stat(tz_dir_buildroot, &sb) == 0 && S_ISDIR(sb.st_mode))
  358 return tz_dir_buildroot;
  359 else if(stat(tz_dir_default, &sb) == 0 && S_ISDIR(sb.st_mode))
  360 return tz_dir_default;
  361 else
  362 throw runtime_error("discover_tz_dir failed to find zoneinfo\n");

Having tzdata uninstalled will throw the generic error as on line 362.

But having tzdata-minimal will instead throw a specific error from line 3624:

3624 throw std::runtime_error(std::string(tz_name) + " not found in timezone 
database");

This probably supports having tzdata removed entirely, since the latter
error makes it seems as-if the zone name is wrong (it's not, it's just
not installed).

Notes:
https://github.com/HowardHinnant/date

(2) Non-rpm packaging.

We have C++ users using Howard Hinnart's 'date' package that implements
 header and it can process complete IANA tzdb files.

Currently Howard's API is being proposed for inclusion
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0355r7.html


N.B. This is incorrect, it was proposed some years ago (the paper
above is from 2018) and is now part of ISO/IEC 14882:2020 i.e. the
C++20 standard.

I'm not yet sure what the C++ runtime will need to do if there are no
zoneinfo files at all, not even UTC. I suspect we will need a fallback
to UTC as well, and std::tzdb::current_zone() will return the info for
the UTC timezone. So I'm not sure that there's much practical
difference between no tzdata at all and tzdata-minimal as far as
libstdc++ will be concerned. This might change once I actually start
to implement it though. Maybe having tzdata-minimal would allow the
initial implementation to omit the fallback (assuming that all
sensible linux environments have at least UTC info), and add the
fallback later.

(It doesn't help that glibc has a fallback to UTC because the C++
runtime can't use glibc for timezone info, it will consume the tzdata
files directly.)


It doesn't help Python's zoneinfo either, for the same reason.
I assume anything that uses the glibc API shouldn't depend on tzdata 
directly.

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: tzdata-minimal (Self-Contained Change proposal)

[Petr Viktorin]

On 13. 07. 21 16:31, Carlos O'Donell wrote:

On 7/12/21 12:16 PM, Petr Viktorin wrote:

On 06. 07. 21 20:38, David Cantrell wrote:

On Tue, Jul 06, 2021 at 01:20:47PM -0400, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/tzdata-minimal

== Summary ==
Split the tzdata package into two parts - tzdata and tzdata-minimal.
tzdata will require tzdata-minimal.  tzdata-minimal provides the
minimal files needed to support UTC on containers.

[...]



Python should work well without *any* tzdata installed. But having
only a small subset of timezones would result in issues unique to
Fedora-based systems (assuming those are the only systems that split
tzdata).


It's possible to remove all tzdata.

However, without *some* data it is not easy to distinguish between these
two scenarios if you want to offer a different error message:

- Is this zone provided and correct but missing? e.g. exists but is not 
installed.
   - zone table exists, lists the zone, but the zone is missing.

- Is this zone not correct? e.g. doesn't exist in the current version.
   - zone table doesn't list the zone.


True. But I don't see a use case where this would be important enough: 
when is an error message like "tzdata is not installed, so the zone 
can't be used *or* checked" not enough?


The problem with making it possible to distinguish between these two 
scenarios is that *every* consumer of tzdata must now distinguish 
between them. If they assume tzdata is never split (as many do, AFAIK), 
their error messages will be wrong.
That's not every consumer we distribute in a RPM (we could handle that I 
guess), but also any third-party one people will build/install on their 
systems.



We could theoretically patch Python to give reasonable error
messages. But since the consumer of the tz data (the zoneinfo module)
was only added in Python 3.9 (last year), existing applications
mainly use third-party modules instead of the standard library. I
assume that like Python, these modules expect tzinfo to either be
missing entirely or be all there. And I expect this is the case for
more than just Python modules.
  
Over time some zones become deprecated and invalid names.


One must already handle zone name changes, so if the code can handle
name deprecation then it will report the same error for missing zoneinfo. >

Is it reasonable for glibc to hardcode the +0 fallback timezone,
rather than needing the zoneinfo file for it? If so, we could remove
tzdata from minimal containers entirely. Or is that too naive?


It is not naive.

glibc already falls back to UTC with no data present (and we need to cleanup
what we print).

The question is what kind of errors we want to be able to express to users.
  

== Benefit to Fedora ==
This change will reduce the size of base container installations.

== Scope ==
* Proposal owners: Implement the proposal.
* Other developers: Developers need to ensure that their packages
continue to build and install with the new split tzdata/tzdata-minimal
package changes.

* Release engineering: No coordination required with Release Engineering.
* Policies and guidelines: The policies and guidelines do not need to
be updated.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A

== Upgrade/compatibility impact ==
The only visible change will be a new package tzdata-minimal required by tzdata.


== How To Test ==
Run a dnf upgrade of tzdata and observe that tzdata-minimal is now
also installed as a dependency.


== User Experience ==
Users will see that new updates to tzdata include a new package
dependency on tzdata-minimal.


== Dependencies ==
This change does not require or depend on changes to other packages.
However, we hope that dependent packages will work towards
recommending tzdata for builds and installs rather than requiring it.


== Contingency Plan ==
* Contingency mechanism: If we are unable to complete this feature by
the final development freeze, we will revert to the shipped
configuration.
* Contingency deadline: 100% Code complete deadline
* Blocks release? No

== Documentation ==
No documentation changes are needed at this time.


== Release Notes ==
The tzdata package is now divided into a UTC only package,
tzdata-minimal, and tzdata.


What is supposed to be in tzdata-minimal?  Is it
/usr/share/zoneinfo/UTC or that and more?


Slightly more (based on experience).

* UTC
/usr/share/zoneinfo/UTC

* Zone tables (which can be used to determine what is valid).
/usr/share/zoneinfo/iso3166.tab
/usr/share/zoneinfo/zone.tab
/usr/share/zoneinfo/zone1970.tab

* License file
/usr/share/licenses/tzdata/LICENSE

It saves ~5MiB for base container image sizes in a supportable way
(as opposed to what is done today which is to delete the zoneinfo data).



Forcibly removing tzdata on a fresh Fedora VM that I just set up has
the system fall back to UTC, as expected.  On this incredibly small
install, tzdata is required glibc-

Re: F35 Change: tzdata-minimal (Self-Contained Change proposal)

[Petr Viktorin]

On 12. 07. 21 18:31, Carlos O'Donell wrote:

On 7/6/21 2:38 PM, David Cantrell wrote:

On Tue, Jul 06, 2021 at 01:20:47PM -0400, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/tzdata-minimal

== Summary ==
Split the tzdata package into two parts - tzdata and tzdata-minimal.
tzdata will require tzdata-minimal.  tzdata-minimal provides the
minimal files needed to support UTC on containers.

== Owner ==
* Name: Patsy Griffin (Franklin)
* Email: pa...@redhat.com


== Detailed Description ==
This is the first step towards providing support for a minimal, UTC
only, version of tzdata for containers.  The tzdata-minimal package
will be a stand-alone, UTC only, subset of tzdata. The tzdata package
will require tzdata-minimal.

With this framework in place, other packages can develop code to
detect a minimal tzdata installation.  These packages will also need
to provide appropriate messages when users request timezone
information not available when only tzdata-minimal is installed.

== Feedback ==
We have had requests for this functionality in order to support
minimal container installations.  Currently some container kickstart
installations already ad hoc remove most of the timezone information
provided by tzdata, leaving only UTC support available.  This change
provides a formal method of providing this support.

Both the glibc and python teams are aware of this proposed change.
This change does not currently require changes in their code.  The
goal is for those packages that currently require tzdata as part of
their build or install, move towards recommending tzdata instead.

== Benefit to Fedora ==
This change will reduce the size of base container installations.

== Scope ==
* Proposal owners: Implement the proposal.
* Other developers: Developers need to ensure that their packages
continue to build and install with the new split tzdata/tzdata-minimal
package changes.

* Release engineering: No coordination required with Release Engineering.
* Policies and guidelines: The policies and guidelines do not need to
be updated.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A

== Upgrade/compatibility impact ==
The only visible change will be a new package tzdata-minimal required by tzdata.


== How To Test ==
Run a dnf upgrade of tzdata and observe that tzdata-minimal is now
also installed as a dependency.


== User Experience ==
Users will see that new updates to tzdata include a new package
dependency on tzdata-minimal.


== Dependencies ==
This change does not require or depend on changes to other packages.
However, we hope that dependent packages will work towards
recommending tzdata for builds and installs rather than requiring it.


== Contingency Plan ==
* Contingency mechanism: If we are unable to complete this feature by
the final development freeze, we will revert to the shipped
configuration.
* Contingency deadline: 100% Code complete deadline
* Blocks release? No

== Documentation ==
No documentation changes are needed at this time.


== Release Notes ==
The tzdata package is now divided into a UTC only package,
tzdata-minimal, and tzdata.


What is supposed to be in tzdata-minimal?  Is it
/usr/share/zoneinfo/UTC or that and more?


A little more is provided.

You need some of the name tables for certain use cases.


What are the use cases (and why are they needed for minimal containers)?


This is based on Intel's clear linux work in splitting the data.
  

Forcibly removing tzdata on a fresh Fedora VM that I just set up has
the system fall back to UTC, as expected.  On this incredibly small
install, tzdata is required glibc-common, python3-libs, and
python3-dateutil.  The last one is reasonable, but for all of them I
ask if tzdata is actually a hard dependency or if it can become a weak
dependency and this change proposal could become "make tzdata
something easily removable" rather than creating more tzdata packages.


If you can minimally provide the tables of possible zones, and provide
an easy way to detect a zone is missing, then the APIs can determine:
"Yes you could do that, but your system is missing the data."
vs.
"That is an invalid zone."
Which is a useful distinction.


Sure, we can provide such an API, but that alone won't make consumers 
use it. Especially if it's specific to Fedora (and Clear Linux -- AFAIK, 
people expect missing bits and pieces are there.)


I think the best place to discuss and document this would be the tz. If 
their README (or just a mail thread) said the data can be split this 
way, and hinted at what should be done when it is, we wouldn't need this 
conversation.
Without that, I don't think it's OK to allow Fedora systems with only 
tzdata-minimal.


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

Re: F35 Change: tzdata-minimal (Self-Contained Change proposal)

[Petr Viktorin]

On 06. 07. 21 20:38, David Cantrell wrote:

On Tue, Jul 06, 2021 at 01:20:47PM -0400, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/tzdata-minimal

== Summary ==
Split the tzdata package into two parts - tzdata and tzdata-minimal.
tzdata will require tzdata-minimal.  tzdata-minimal provides the
minimal files needed to support UTC on containers.

== Owner ==
* Name: Patsy Griffin (Franklin)
* Email: pa...@redhat.com


== Detailed Description ==
This is the first step towards providing support for a minimal, UTC
only, version of tzdata for containers.  The tzdata-minimal package
will be a stand-alone, UTC only, subset of tzdata. The tzdata package
will require tzdata-minimal.

With this framework in place, other packages can develop code to
detect a minimal tzdata installation.  These packages will also need
to provide appropriate messages when users request timezone
information not available when only tzdata-minimal is installed.

== Feedback ==
We have had requests for this functionality in order to support
minimal container installations.  Currently some container kickstart
installations already ad hoc remove most of the timezone information
provided by tzdata, leaving only UTC support available.  This change
provides a formal method of providing this support.

Both the glibc and python teams are aware of this proposed change.
This change does not currently require changes in their code.  The
goal is for those packages that currently require tzdata as part of
their build or install, move towards recommending tzdata instead.


Python should work well without *any* tzdata installed.
But having only a small subset of timezones would result in issues 
unique to Fedora-based systems (assuming those are the only systems that 
split tzdata).


We could theoretically patch Python to give reasonable error messages. 
But since the consumer of the tz data (the zoneinfo module) was only 
added in Python 3.9 (last year), existing applications mainly use 
third-party modules instead of the standard library. I assume that like 
Python, these modules expect tzinfo to either be missing entirely or be 
all there.

And I expect this is the case for more than just Python modules.


Is it reasonable for glibc to hardcode the +0 fallback timezone, rather 
than needing the zoneinfo file for it? If so, we could remove tzdata 
from minimal containers entirely.

Or is that too naive?



== Benefit to Fedora ==
This change will reduce the size of base container installations.

== Scope ==
* Proposal owners: Implement the proposal.
* Other developers: Developers need to ensure that their packages
continue to build and install with the new split tzdata/tzdata-minimal
package changes.

* Release engineering: No coordination required with Release Engineering.
* Policies and guidelines: The policies and guidelines do not need to
be updated.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A

== Upgrade/compatibility impact ==
The only visible change will be a new package tzdata-minimal required 
by tzdata.



== How To Test ==
Run a dnf upgrade of tzdata and observe that tzdata-minimal is now
also installed as a dependency.


== User Experience ==
Users will see that new updates to tzdata include a new package
dependency on tzdata-minimal.


== Dependencies ==
This change does not require or depend on changes to other packages.
However, we hope that dependent packages will work towards
recommending tzdata for builds and installs rather than requiring it.


== Contingency Plan ==
* Contingency mechanism: If we are unable to complete this feature by
the final development freeze, we will revert to the shipped
configuration.
* Contingency deadline: 100% Code complete deadline
* Blocks release? No

== Documentation ==
No documentation changes are needed at this time.


== Release Notes ==
The tzdata package is now divided into a UTC only package,
tzdata-minimal, and tzdata.


What is supposed to be in tzdata-minimal?  Is it
/usr/share/zoneinfo/UTC or that and more?

Forcibly removing tzdata on a fresh Fedora VM that I just set up has
the system fall back to UTC, as expected.  On this incredibly small
install, tzdata is required glibc-common, python3-libs, and
python3-dateutil.  The last one is reasonable, but for all of them I
ask if tzdata is actually a hard dependency or if it can become a weak
dependency and this change proposal could become "make tzdata
something easily removable" rather than creating more tzdata packages.


For python3-libs, I would have no issue with tzdata a weak dependency.
For users of python3-dateutil, I'd suggest using the Python standard 
library instead, where possible.

___
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

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

[Petr Viktorin]

On 15. 06. 21 13:48, Neal Gompa wrote:

On Tue, Jun 15, 2021 at 6:50 AM Petr Viktorin  wrote:


Hi Neal,
We had this conversation in the past (and you can see it in the change).
I don't think I can convince you, but I'll reiterate since it's new for
devel@.

Unlike the "mandatory tests" issue elsewhere in this thread, using the
PyPI namespace is the main point of the change. I can't take it out.


On 15. 06. 21 2:11, Neal Gompa wrote:

On Mon, Jun 14, 2021 at 8:02 PM Gordon Messmer  wrote:


On 6/14/21 1:53 PM, Neal Gompa wrote:

This is completely unreasonable. The dist-info/egg-info data of a
Python module is for generating dependencies, not for forcing people
to deal with PyPI.



I don't think we can reasonably separate the two.

https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610

(I believe this is the "namespace" issue mentioned in the proposed change.)


You can. When it comes to distribution packages, we can maintain
consistency of the package names referenced within the distribution.
The point of this was to be able to use the names Python packages call
themselves for dependencies. PyPI is merely a distribution center for
such things. Fedora is another distribution center for such things.


You can only separate the namespaces if you sacrifice interoberability,
i.e. allowing pip-installable packages to depend on Fedora packages.
It turns out you can already do that (venv --system-site-packages), and
users expect that dist-info project names use the PyPI namespace. This
is a current problem that we need to solve.

There are other (harder) solutions for the issue than reusing the PyPI
namespace in Fedora, but why should we bother with them? There already
is an ecosystem-wide namespace; why should we add a Fedora-specific one?
(Or a Linux-distro-specific one, if we're interested in cross-distro
collaboration.)

You seem to assume that registering/blocking a name on PyPI is hard.
I say it is not and I am willing to do it for packagers who need it.
(And to mitigate the bus factor, I'll make it a responsibility of Red
Hat's python-maint team.)


It's not terribly different from how organizations may have private
Python package indexes that may use whatever names they want for
Python software they build and release.


I agree, in fact, I think Fedora's problems here are a subset of the
problems the private organizations have: if issues of proprietary corps
are solved, we can use the solution as well. (However, it'll need more
work than is necessary for Fedora/FOSS needs, so I don't want to drive
the effort.)
BUT, if the issues are solved, it'll likely be through namespacing: we'd
need to prefix our names with `fedora-` or `fedora:`. I still think it
is better for Fedora to reuse the public PyPI namespace rather than
start its own.


As long as you don't make packagers deal with it, I'm fine with it.
I'm okay with the PyPI contract as long as you don't make me or any
other Fedora packager specifically deal with it. And I strongly
suspect you're going to want automation in the future, but that choice
is up to you.


When packaging something that isn't on PyPI, you can let me know (on 
python-de...@lists.fedoraproject.org ) and I'll get the name blocked. I 
expect this to be rare enough to not need automation.


If the name *conflicts* with something on PyPI, then also let me know. 
Dealing with that issue might be more difficult, and it might involve 
you more. Still, this situation is confusing for users, so I think it's 
fair to want to solve it.

(And again, I'm not expecting existing packages to do this *right* now.)
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

[Petr Viktorin]

On 15. 06. 21 13:32, Alexander Bokovoy wrote:

On ti, 15 kesä 2021, Petr Viktorin wrote:

On 14. 06. 21 20:09, Alexander Bokovoy wrote:

On ma, 14 kesä 2021, Ben Cotton wrote:

[...]

 PyPI Parity 

Machine-readable metadata (''distribution'' names in
dist-info directories on disk and the corresponding
python3.Xdist(foo) RPM provides) will match the Python
Package Index (PyPI).

This solves a ''namespace'' issue. Python packaging tools use a flat 
namespace,
and PyPI is ''the'' place where open-source Python packages are 
generally
published, so users and tools assume a package called 
requests

is whatever requests means on PyPI.
While this is not ideal (especially for private packages), it makes 
sense

for Fedora to align with the PyPI namespace.

Note that Fedora package names are not affected – just the Python 
packaging

metadata on disk and virtual RPM Provides generated from it.

The new guidelines cover what to do for packages that cannot be 
registered

on PyPI. The Change owner is prepared to help with PyPI registration.

Note that names found in Fedora but not on PyPI
[https://github.com/pypa/pypi-support/issues/355 have been reserved 
on PyPI]

to avoid being taken by unrelated projects.


samba has extensive Python C bindings but does not use PyPI at all. We
don't want to, we don't need to, it is technically not possible without
building Samba from scratch and it would not make it usable for PIP
install without a stricter coordination of the non-Python dependencies
-- that's what Linux distributions do.

In addition, 'samba' name is taken by an unrelated package on PyPI which
was not updated since 2019. For us this namespacing enforcement would
only be a problem.


Then I'd recommend that the project name in dist-info metadata would 
be, for example "samba-bindings".


Samba Python bindings have no dist-info metadata. Does it need to? The
bindings are consumed by few projects around Samba but none of them has
anything related on PyPI. What exists on PyPI is either an outdated
stuff without upstream sources or a reference to a similar outdated
stuff, none of which is using Samba Python bindings.


It doesn't need to have dist-info metadata, but I believe it would be 
better if it did, so that it's *possible* to encode "requires Samba" in 
Python packaging metadata.
(*Should* the bindings be consumed by more than a few projects around 
Samba? If yes, it dist-info would make it easier.)


There should also be a good way to add dist-info metadata to projects 
*like* Samba, even if Samba packagers decide they don't want it.


This matters in cases like a pip-installable package declaring a 
dependency on Samba bindings: it now can't use `samba` because that 
means something else on PyPI.


There are already unrelated projects with Samba name on PyPI. This
change in Fedora guidelines cannot affect those. It cannot also affect
actual use of Samba Python bindings. It looks like there is no real use
of PyPI for our use case either, so why the fuss for this particular
package?

I suspect at best we'd submit a request for exception, if pressed.


No pressure; this is exactly why the old guidelines aren't going anywhere.


I fully agree about not installing Samba itself via pip.

(Also, this is one of the cases that might take a decade -- I'm not 
putting pressure on you to implement this, but pointing out a 
direction for the future.)


Frankly, I do not see a real use case for what you might see in other
projects. We had a similar issue with FreeIPA and what we provide on
PyPI is a crippled subset of FreeIPA Python modules that mostly does not
use real FreeIPA features. To date, I am not sure it is really bringing
any benefit to us (upstream).

This does not mean the whole effort is useless, not at all. It means, in
my opinion, that proposed guidelines are failing to address real world
use cases present in Fedora. Invalidating these use cases is as bad as
dropping the guidelines' changes in one go. ;)


Don't put Samba or FreeIPA up on PyPI. But provide a name in dist-info, 
so packages on PyPI can depend on Samba/FreeIPA (which need to be 
installed separately). And reserve that name, so  no one else can put it 
on PyPI either.


Again, no pressure, just a direction for the future.

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

[Petr Viktorin]

On 14. 06. 21 17:52, Vitaly Zaitsev via devel wrote:

On 14.06.2021 15:32, Ben Cotton wrote:

Running upstream tests is mandatory.


What about tests that require network access?



Thanks for this and all the other concerns about mandatory tests!
I updated the proposal to mane them not mandatory, but require a smoke 
test if they're not there.
I also removed the mention of Fedora CI: it was meant as an escape hatch 
for tests that need network, but that's now unnecessary.


Diff: 
https://pagure.io/fork/pviktori/packaging-committee/c/ec9643873c989e0ff264128891665f6ad78f3e4a?branch=new-py-guidelines
History including other minor changes: 
https://pagure.io/fork/pviktori/packaging-committee/commits/new-py-guidelines


New wording:

If a test suite exists upstream,
it *SHOULD* be run in the `+%check+` section.
If that is not possible with reasonable effort,
at least a basic smoke test (such as importing the packaged module)
*MUST* be run in `+%check+`.

You *MAY* exclude specific failing tests.
You *MUST NOT* disable the entire testsuite
or ignore its result to solve a build failure.

As an exception,
you *MAY* disable tests with an appropriate `+%if+` conditional
(e.g. http://rpm.org/user_doc/conditional_builds.html[bcond])
when xref:index.adoc#bootstrapping[bootstrapping].

Most errors in Python happen at run-time,
so tests are extremely important to root out issues,
especially when mass rebuilds are required.

Common reasons for skipping tests in `+%check+` include requiring
network access,
dependencies not packaged in Fedora,
and/or specialized hardware or resources.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

[Petr Viktorin]

I'll address the larger "mandatory tests" issue later; thanks for all 
your concerns!

This point deserves a reply on its own:

On 14. 06. 21 19:35, Benjamin Beasley wrote:
[...]

It’s also not clear to me why the Python guidelines should be so much stricter 
than the overall Fedora guidelines 
(https://docs.fedoraproject.org/en-US/packaging-guidelines/#_test_suites) in 
this area.


Two reasons:
- Python is a dynamic language; most errors only happen at runtime. In 
C, just compiling and linking might work as a reasonable smoke test.
- I'd like the Python guidelines to be a bit "ahead" of the Fedora-wide 
ones. The proposal contains a few ideas that might be better 
Fedora-wide, but I'd rather introduce and test them in the ecosystem I know.


___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

[Petr Viktorin]

On 14. 06. 21 20:09, Alexander Bokovoy wrote:

On ma, 14 kesä 2021, Ben Cotton wrote:

[...]

 PyPI Parity 

Machine-readable metadata (''distribution'' names in
dist-info directories on disk and the corresponding
python3.Xdist(foo) RPM provides) will match the Python
Package Index (PyPI).

This solves a ''namespace'' issue. Python packaging tools use a flat 
namespace,

and PyPI is ''the'' place where open-source Python packages are generally
published, so users and tools assume a package called 
requests

is whatever requests means on PyPI.
While this is not ideal (especially for private packages), it makes sense
for Fedora to align with the PyPI namespace.

Note that Fedora package names are not affected – just the Python 
packaging

metadata on disk and virtual RPM Provides generated from it.

The new guidelines cover what to do for packages that cannot be 
registered

on PyPI. The Change owner is prepared to help with PyPI registration.

Note that names found in Fedora but not on PyPI
[https://github.com/pypa/pypi-support/issues/355 have been reserved on 
PyPI]

to avoid being taken by unrelated projects.


samba has extensive Python C bindings but does not use PyPI at all. We
don't want to, we don't need to, it is technically not possible without
building Samba from scratch and it would not make it usable for PIP
install without a stricter coordination of the non-Python dependencies
-- that's what Linux distributions do.

In addition, 'samba' name is taken by an unrelated package on PyPI which
was not updated since 2019. For us this namespacing enforcement would
only be a problem.


Then I'd recommend that the project name in dist-info metadata would be, 
for example "samba-bindings".
This matters in cases like a pip-installable package declaring a 
dependency on Samba bindings: it now can't use `samba` because that 
means something else on PyPI.


I fully agree about not installing Samba itself via pip.

(Also, this is one of the cases that might take a decade -- I'm not 
putting pressure on you to implement this, but pointing out a direction 
for the future.)



=== Burdening packagers ===

[https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/message/IYBF5GX6HVQYPC5EJ6HVK7GJHAIKHVBK/ 


Neal]
does
“not necessarily disagree that PyPI and Fedora pythonXdist() names
should match, but [he disagrees] on burdening packagers with this.”

However, actually pushing a package to PyPI (and maintaining it there)
is not necessary.
The minimal-effort solution is to ''reserve'' the name on PyPI
so that a conflicting package can not be created there.

The author of this change is willing to do this work for all
Python packages whose upstream is not on PyPI;
packagers need to send a request to the Python SIG list.
If something happens to me, Red Hat's python-maint team is also ready
to do this, and in the event of catastrophic management change,
PyPI maintainers can be e-mailed directly.

This is all described in the new guidelines (see the ''PyPI parity'' 
section).


The new guidelines discourage the minimal-effort solution because it is
suboptimal ''for users'' (and for the wider Python ecosystem).


In case of Samba I would argue that going with anything but
minimal-effort is actually suboptimal to users.


I agree; Samba is a special case.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

[Petr Viktorin]

Hi Neal,
We had this conversation in the past (and you can see it in the change). 
I don't think I can convince you, but I'll reiterate since it's new for 
devel@.


Unlike the "mandatory tests" issue elsewhere in this thread, using the 
PyPI namespace is the main point of the change. I can't take it out.



On 15. 06. 21 2:11, Neal Gompa wrote:

On Mon, Jun 14, 2021 at 8:02 PM Gordon Messmer  wrote:


On 6/14/21 1:53 PM, Neal Gompa wrote:

This is completely unreasonable. The dist-info/egg-info data of a
Python module is for generating dependencies, not for forcing people
to deal with PyPI.



I don't think we can reasonably separate the two.

https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610

(I believe this is the "namespace" issue mentioned in the proposed change.)


You can. When it comes to distribution packages, we can maintain
consistency of the package names referenced within the distribution.
The point of this was to be able to use the names Python packages call
themselves for dependencies. PyPI is merely a distribution center for
such things. Fedora is another distribution center for such things.


You can only separate the namespaces if you sacrifice interoberability, 
i.e. allowing pip-installable packages to depend on Fedora packages.
It turns out you can already do that (venv --system-site-packages), and 
users expect that dist-info project names use the PyPI namespace. This 
is a current problem that we need to solve.


There are other (harder) solutions for the issue than reusing the PyPI 
namespace in Fedora, but why should we bother with them? There already 
is an ecosystem-wide namespace; why should we add a Fedora-specific one? 
(Or a Linux-distro-specific one, if we're interested in cross-distro 
collaboration.)


You seem to assume that registering/blocking a name on PyPI is hard.
I say it is not and I am willing to do it for packagers who need it. 
(And to mitigate the bus factor, I'll make it a responsibility of Red 
Hat's python-maint team.)



It's not terribly different from how organizations may have private
Python package indexes that may use whatever names they want for
Python software they build and release.


I agree, in fact, I think Fedora's problems here are a subset of the 
problems the private organizations have: if issues of proprietary corps 
are solved, we can use the solution as well. (However, it'll need more 
work than is necessary for Fedora/FOSS needs, so I don't want to drive 
the effort.)
BUT, if the issues are solved, it'll likely be through namespacing: we'd 
need to prefix our names with `fedora-` or `fedora:`. I still think it 
is better for Fedora to reuse the public PyPI namespace rather than 
start its own.



___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

[Petr Viktorin]

On 14. 06. 21 17:39, Richard W.M. Jones wrote:

Questions, questions ...

These new guidelines seem to be fine for pure Python packages, but I'm
maintaining a couple of packages where Python bindings are built as
subpackages of existing C libraries:

https://src.fedoraproject.org/rpms/libnbd
https://src.fedoraproject.org/rpms/libguestfs

[Yes there are good reasons for this.  No we are not going to decouple
them and package the Python stuff separately.]

Running %pyproject_install etc is not really an option for us.
However I guess some of these macros could make sense
(%pyproject_save_files?  %pyproject_files?).  Also I don't think these
projects generate the extra *.egg-info files or how to create them.


Note that the macros are helpers/implementation details. They're not 
necessary; you can use other tools to be compatible with the guidelines.

Some of those tools are still to be written.
That's the main reason why adopting the guidelines might take a decade. 
We do intend to add helpers for more use cases, but it's not a priority 
right now.


Like the change says, there's no rush; the old guidelines will be 
retired "some time after the vast majority of Python packages follow the 
new guidelines and there are no known blockers for the remaining ones".
I hope it's clear that I do not expect individual packagers to solve 
this problem. (Though if y'all want to help, I won't object.)



=== Not removing older guidelines ===
There's no rush; it might well take a decade.


I guess we've got a while ...

While I've got your attention, one other package is interesting:

https://src.fedoraproject.org/rpms/nbdkit

This has Python 3 bindings but they work in completely the opposite
way to normal bindings, namely a Python interpreter is embedded in a
C program.  As far as I know none of the Python guidelines in Fedora
address this scenario directly, and indeed we don't currently use any
of the special %python* macros.


Thanks for the examples!
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

License correction for pyparsing-doc: MIT -> MIT and GPLv2+ and GPLv3+ and BSD

[Petr Viktorin]

Hi!

The documentation package pyparsing-doc includes several examples that 
aren't under the project licence (MIT). The License field was corrected.

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Follow-up - Please BuildRequire python3-setuptools explicitly

[Petr Viktorin]

On 2020-10-05 13:53, Richard Shaw wrote:
I updated fail2ban and gmsh and committed to master. I assume that is 
sufficient?


Thank you!
As I understand it, it is sufficient.  But since repo queries look at 
"live" packages, you might get some spurious notifications about this in 
the future.

___
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: Many packages unnecessarily link to libpython

[Petr Viktorin]

On 2020-05-31 10:24, Honggang LI wrote:

On Fri, May 29, 2020 at 06:47:35PM +0200, Petr Viktorin wrote:



On 2020-05-18 03:53, Honggang LI wrote:

On Fri, May 15, 2020 at 02:12:00PM -0400, Charalampos Stratakis wrote:

rdma-coredledford honli jwilson


rdma-core pyverbs must be linked with libpython38. For example,

build]$ nm ./python/pyverbs/mem_alloc.cpython-38-x86_64-linux-gnu.so | grep -w 
U |  grep  PyInterpreterState_GetID
U PyInterpreterState_GetID

Python-3.8.3]$ nm -a ./build/debug/libpython3.8d.so | grep 
PyInterpreterState_GetID
000c6a82 T PyInterpreterState_GetID


This is exactly the case where the module should *not* be linked to
/usr/lib64/libpython3.8.so.
mem_alloc.cpython-38-x86_64-linux-gnu.so is a Python module, so it is loaded
from Python when imported. The import will link link it to the particular
Python interpreter it's imported into, which could be using a different
libpython3.8.so (such as the debug version).


OK, I see the problem now. But I don't know how to handle this.

Let's take ../python/pyverbs/srq.cpython-39-x86_64-linux-gnu.so as
example.

1) Link with debug version.
[honli@localhost pyverbs (master)]$ gcc  -fPIC  -Wall -Wextra -Wno-sign-compare 
-Wno-unused-parameter -Wmissing-prototypes -Wmissing-declarations 
-Wwrite-strings -Wformat=2 -Wcast-function-type -Wformat-nonliteral -Wdate-time 
-Wnested-externs -Wshadow -Wstrict-prototypes -Wold-style-definition 
-Wredundant-decls -O2 -g -DNDEBUG  -Wl,--as-needed -Wl,--no-undefined -shared 
-Wl,-soname,srq.cpython-39-x86_64-linux-gnu.so -o 
../python/pyverbs/srq.cpython-39-x86_64-linux-gnu.so 
CMakeFiles/srq.cpython-39-x86_64-linux-gnu.dir/srq.c.o  
-Wl,-rpath,/home/honli/upstream/rdma-core/build/lib:  
../lib/librdmacm.so.1.2.30.0 ../lib/libibverbs.so.1.9.30.0 -lpython3.9d

[honli@localhost pyverbs (master)]$ ldd 
../python/pyverbs/srq.cpython-39-x86_64-linux-gnu.so
linux-vdso.so.1 (0x7fff2fbe4000)
libibverbs.so.1 => 
/home/honli/upstream/rdma-core/build/lib/libibverbs.so.1 (0x7feed22c3000)
libpython3.9d.so.1.0 => /lib64/libpython3.9d.so.1.0 (0x7feed1e6e000)
libc.so.6 => /lib64/libc.so.6 (0x7feed1ca3000)
libnl-route-3.so.200 => /lib64/libnl-route-3.so.200 (0x7feed1c1b000)
libnl-3.so.200 => /lib64/libnl-3.so.200 (0x7feed1bf7000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7feed1bd5000)
libdl.so.2 => /lib64/libdl.so.2 (0x7feed1bcc000)
libutil.so.1 => /lib64/libutil.so.1 (0x7feed1bc7000)
libm.so.6 => /lib64/libm.so.6 (0x7feed1a81000)
/lib64/ld-linux-x86-64.so.2 (0x7feed22f7000)

[honli@localhost pyverbs (master)]$ ldd 
../python/pyverbs/srq.cpython-39-x86_64-linux-gnu.so | grep libpython3.9d.so.1.0
libpython3.9d.so.1.0 => /lib64/libpython3.9d.so.1.0 (0x7f32570ac000)

[honli@localhost pyverbs (master)]$ rpm -qf /lib64/libpython3.9d.so.1.0
python3-debug-3.9.0~b1-3.fc33.x86_64

2) link with normal version
[honli@localhost pyverbs (master)]$ gcc  -fPIC  -Wall -Wextra -Wno-sign-compare 
-Wno-unused-parameter -Wmissing-prototypes -Wmissing-declarations 
-Wwrite-strings -Wformat=2 -Wcast-function-type -Wformat-nonliteral -Wdate-time 
-Wnested-externs -Wshadow -Wstrict-prototypes -Wold-style-definition 
-Wredundant-decls -O2 -g -DNDEBUG  -Wl,--as-needed -Wl,--no-undefined -shared 
-Wl,-soname,srq.cpython-39-x86_64-linux-gnu.so -o 
../python/pyverbs/srq.cpython-39-x86_64-linux-gnu.so 
CMakeFiles/srq.cpython-39-x86_64-linux-gnu.dir/srq.c.o  
-Wl,-rpath,/home/honli/upstream/rdma-core/build/lib:  
../lib/librdmacm.so.1.2.30.0 ../lib/libibverbs.so.1.9.30.0 -lpython3.9

[honli@localhost pyverbs (master)]$ ldd 
../python/pyverbs/srq.cpython-39-x86_64-linux-gnu.so | grep libpython3.9
libpython3.9.so.1.0 => /lib64/libpython3.9.so.1.0 (0x7f7f8a7c7000)

[honli@localhost pyverbs (master)]$ rpm -qf /lib64/libpython3.9.so.1.0
python3-libs-3.9.0~b1-3.fc33.x86_64

As you see, "-lpython3.9" or "-lpython3.9d" library must be provided to
the linker. Otherwise, a lot of "undefined reference to xxx" error
messages show up.

/home/honli/upstream/rdma-core/build/pyverbs/srq.c:10425: undefined reference 
to `PyErr_GivenExceptionMatches'
/home/honli/upstream/rdma-core/build/pyverbs/srq.c:8987: undefined reference to 
`_PyObject_GenericGetAttrWithDict'
/home/honli/upstream/rdma-core/build/pyverbs/srq.c:7786: undefined reference to 
`PyModuleDef_Init'

[honli@localhost pyverbs (master)]$ grep undefined error.txt |wc -l
876

Any hits how to handle this?


Judging from the file name, mem_alloc.cpython-38-x86_64-linux-gnu.so is 
a Python module. If that's so, you shouldn't link it using gcc, but use 
a Python import statement to load it.

Is there some reason to link it using gcc?
___
devel mailing list -- devel@lists.fedoraproject

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

[Petr Viktorin]

On 2020-05-29 16:39, Miro Hrončok wrote:

On 29. 05. 20 16:25, Richard Shaw wrote:
On Fri, May 29, 2020 at 9:18 AM Miro Hrončok > wrote:



    The side tag has been merged. Thank you all for your patience.


Woohoo! So now Python can be rebuilt with the fix for PySide2? :)


Technically blocked by https://bugzilla.redhat.com/show_bug.cgi?id=1839826

But I am sure Petr is working on it.


It's progressing, though slower than I hoped due to other issues. I'll 
rebuild PySide and close the bug when done.

___
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: How to determine maintainer of a package en mass?

[Petr Viktorin]

On 2020-05-29 01:34, Fabio Valentini wrote:

On Fri, May 29, 2020 at 1:16 AM Richard Shaw  wrote:


Specifically, I would like a way to determine which packages I am the sole 
maintainer of or the main maintainer.

Long story short, I've been spending far too much time on packaging work and it's taking 
away from $LIFE, $DAYJOB, and other hobbies I used to enjoy. I need to offload the 
primary maintenance of some of them to "lighten the load" so to speak.

No worries, I'm not disappearing or anything and will continue to do what I can.


This shows all the packages for which you are "owner" / "main admin":
https://src.fedoraproject.org/dashboard/projects?acl=main+admin

This shows all packages for which you have "admin" access (whether
directly or via group membership):
https://src.fedoraproject.org/dashboard/projects?acl=admin

Do those two pages show the information you need?


There's also a JSON with all maintainers for all packages here: 
https://src.fedoraproject.org/extras/pagure_owner_alias.json

___
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: Many packages unnecessarily link to libpython

[Petr Viktorin]

On 2020-05-18 03:53, Honggang LI wrote:

On Fri, May 15, 2020 at 02:12:00PM -0400, Charalampos Stratakis wrote:

rdma-coredledford honli jwilson


rdma-core pyverbs must be linked with libpython38. For example,

build]$ nm ./python/pyverbs/mem_alloc.cpython-38-x86_64-linux-gnu.so | grep -w 
U |  grep  PyInterpreterState_GetID
U PyInterpreterState_GetID

Python-3.8.3]$ nm -a ./build/debug/libpython3.8d.so | grep 
PyInterpreterState_GetID
000c6a82 T PyInterpreterState_GetID


This is exactly the case where the module should *not* be linked to 
/usr/lib64/libpython3.8.so.
mem_alloc.cpython-38-x86_64-linux-gnu.so is a Python module, so it is 
loaded from Python when imported. The import will link link it to the 
particular Python interpreter it's imported into, which could be using a 
different libpython3.8.so (such as the debug version).

___
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: Location of executable code

[Petr Viktorin]

On 2020-05-22 17:31, Steve Grubb wrote:

On Friday, May 22, 2020 10:39:43 AM EDT Petr Viktorin wrote:

On 2020-05-22 16:30, Steve Grubb wrote:

Hello,

I am working on our application whitelisting daemon. It uses the rpmdb to
derive trust in what's on disk. If we use the whole rpmdb, then the
number of files is large. So, to prune the amount of entries in the
trust db down to a reasonable number, I thought we could jettison
anything in /usr/share.

According to the Filesystem Hierarchy Standard [1] it says this about
/usr/ share:

The /usr/share hierarchy is for all read-only architecture independent
data files.

But what I'm finding in practice is that cinnamon places its javascript
there, there are libexec dirs that contain executable code, there are
python and byte compiled python over there. In short, the system doesn't
work because critical executables are in /usr/share.

The question is what should be done about this? Do we care that things
are in /usr/share that are not following the Filesystem Hierarchy
Standard? If we do, what is the proper fix this this? Should bz be
opened against each component?


Does "read-only architecture independent data" mean the files must not
be programs?


I personally think of data and applications/modules/libraries as distinct
entities.


Javascript, Python scripts and Python bytecode are all read-only and
architecture independent.


But they are not data. What I'm trying to do is constrain the notion of what
can be executed.


Interesting. Where do you draw the line?

I guess /usr/lib*/python3.*/pydoc_data/topics.py is not data?
What about a YAML file? An Ansible playbook? A PostScript image?
A JavaScript file intended to be minified and sent to a browser?

Not that those are very practical questions. I'm just curious.


And everything on disk is data.
The document you linked explicitly gives troff macros and "perl" as
examples of what goes in /usr/share/.


Indeed it does. But it also suggests /usr/lib as another home for that. If
there was a /usr/share/code  or /usr/share/perl or some convention like that,
it would make the job easier because applications are discoverable. Instead
they are hidden and in unexpected places. And its hard to tell what are
example programs from something that the system depends on. There needs to be
clarity about the intentions of any system code that lives in /usr/share. At
least the libexec dirs are obvious. Is it possible to make this system code
discoverable?


Possible, but not easy. There's currently no clear distinction, and even 
if you come up with a clear spec, it won't be easy to move all the files.




-Steve


IMO, /usr/share/ would be a better place for *all* pure-Python modules
than /usr/lib/, where they are now. The main reason they weren't moved
is that the move would cause a lot of disruption.


1 - https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s11.html

___
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: Location of executable code

[Petr Viktorin]

On 2020-05-22 16:30, Steve Grubb wrote:

Hello,

I am working on our application whitelisting daemon. It uses the rpmdb to
derive trust in what's on disk. If we use the whole rpmdb, then the number of
files is large. So, to prune the amount of entries in the trust db down to a
reasonable number, I thought we could jettison anything in /usr/share.

According to the Filesystem Hierarchy Standard [1] it says this about /usr/
share:

The /usr/share hierarchy is for all read-only architecture independent data
files.

But what I'm finding in practice is that cinnamon places its javascript there,
there are libexec dirs that contain executable code, there are python and
byte compiled python over there. In short, the system doesn't work because
critical executables are in /usr/share.

The question is what should be done about this? Do we care that things are in
/usr/share that are not following the Filesystem Hierarchy Standard? If we
do, what is the proper fix this this? Should bz be opened against each
component?


Does "read-only architecture independent data" mean the files must not 
be programs?
Javascript, Python scripts and Python bytecode are all read-only and 
architecture independent. And everything on disk is data.
The document you linked explicitly gives troff macros and "perl" as 
examples of what goes in /usr/share/.


IMO, /usr/share/ would be a better place for *all* pure-Python modules 
than /usr/lib/, where they are now. The main reason they weren't moved 
is that the move would cause a lot of disruption.



1 - https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s11.html

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

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

[Petr Viktorin]

On 2020-05-22 13:59, Tomasz Kłoczko wrote:
On Fri, 22 May 2020 at 12:02, Miro Hrončok > wrote:


On 22. 05. 20 12:43, Tomasz Kłoczko wrote:
 > [mode=serious]
 > On making transition from 3.8.x to 3.9.x all what would be
necessary to do would
 > be just create compat-python3.8 package -> upgrade python.spec to
3.9 -> monitor
 > number of packages still dependent on compat-python3.8 to focus
what still needs
 > to be ported/rebuild. ...snip

This doesn't work. As long as you rebuild setuptools and other
essential
packages with 3.9, the entire 3.8 stack would be useless. You would
need compat
packages for hundreds of packages to make this work.


Is that not *the*target/goal?.. make whole old stack useless/obsolete ASAP?

And no you would not need that because as long as you will not remove 
from repository all python---.f22 
packages all dependencies will be fulfilled.
Remember that each package is not rebuild on entire system but on very 
limited one with (theoretically) necessary dependencies. With that it is 
possible to rebuild all packages one by one and move everything in one 
batch. To make that whole transition easier all what will be 
necessary to do is clone current repository to something like 
fedora-transition-python and add keep all rebuild packages in that repo 
and merge all that packages in one go when all will be finished. 
No stress or time pressure. such transition can take weeks if not months 
and decision about merge could be done instantly basing on only one 
metric which is number of packages still dependent on compat-python3.8. 


How is this "fedora-transition-python" different from a side tag?

The problem with "cloning" is that people build new versions in Fedora 
all the time, so the "clone" gets out of date (with some additional 
problems related to version/release numbers). Unless the "clone" is kept 
up to date, merging the repo would mean downgrading some packages.


That is the main reason for the time pressure: the longer the rebuild 
takes, the more the repos diverge.


Than if at the and will be still some remains hard quickly to port it 
should be made decision about create some limited number of packages 
like compat-python3.8- and/or to put some of those packages on 
obsoletes list. > With single metric decision about actual transition will be no longer in

hands of anyone (as single person or comity).
It will be strict technical decision based on quite well defined set of 
conditions hanging on that metric.


So, what conditions do you propose?

Why would a condition (decided by one person or commitee) be better than 
that person (or comittee) deciding on the fly -- based on not just the 
number, but the actual packages that still fail to build?


If we are talking about using that methodology not only for python in 
some simple enough cases such decision could be done .. automatically!
Basing on my already +25y exp on building rpm packages I can even bet 
that after some cleanups in all python related stuff it should be 
possible to make python major release upgrade *automatically.*


I'm afraid the clean-ups, and keeping the clean-ups up to date, would be 
more work than doing the work manually.


Whoever would want to help on that transition will be asked to add that 
fedora-transition-python repository to own build systems or own personal 
system. Initial set of rebuilds made automatically should provide enough 
set of new dependencies allowing fixing one by one each package which 
will need manual intervention in form of some patches.


That's very similar to what's been happening in COPR for months now.

Above and what I wrote in my prev email could be general methodology on 
making any future transition of bigger groups of packages from one major 
version to another one (not only python specific).


All this is just like git branching but on packages with packages 
repositories as well.


Branching is not hard; merging is. Both Git and CVS could branch; Git 
won because the *merging* (and thus the whole branch-based workflow) is 
easier.


It is yet another consequence of what I've sketched. With that it 
would be possible to remove all python packages bootstrap bconds:


[tkloczko@barrel SPECS.fedora]$ grep bootstrap python* | grep bcond
python3.spec:%bcond_with bootstrap
python-BTrees.spec:%bcond_with bootstrap
python-dask.spec:%bcond_without bootstrap
python-fsspec.spec:%bcond_without bootstrap
python-pbr.spec:%bcond_with bootstrap
python-setuptools.spec:%bcond_with bootstrap
python-setuptools.spec:# Warning, different bootstrap meaning here, has 
nothing to do with our bcond

python-sphinx_rtd_theme.spec:%bcond_with bootstrap
python-stestr.spec:%bcond_without bootstrap
python-wheel.spec:%bcond_with bootstrap
python-zbase32.spec:%bcond_with bootstrap


Sorry, I don't see how this would be possible.

Of course to that picture needs to be added yet another small bit which 
is 

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3

[Petr Viktorin]

On 2020-04-03 14:43, Aleksandra Fedorova wrote:

On Fri, Apr 3, 2020 at 11:59 AM Petr Viktorin  wrote:


On 2020-04-02 20:07, Stephen Gallagher wrote:

On Thu, Apr 2, 2020 at 12:56 PM Miro Hrončok  wrote:

The change proposal received overly negative feedback by the packager community
as represented both by RHEL¹ and non-RHEL maintainers. Despite being reworked
several times, none of this feedback was reflected in the proposal, only new
reasons why this is going to be done the original way were added. It seems that
feedback is collected not to find the best technical solution, but rather to
find ways to justify a solution that's already decided.



This is needlessly antagonistic, Miro. We've collected the feedback in
good faith, examined it and then identified shortcomings with it. For
the sake of clarity in the Change Proposal, I've recorded that
reasoning there.


Key questions in the *Detailed Description* remain "out of scope of ELN" or not
answered clearly.


If something is not clear, please constructively offer that
information. I've been doing my best to rephrase and clarify anything
that has come up. Anything remaining that is "out of scope of ELN" is
literally just that. ELN's scope is largely "Make Fedora Rawhide more
useful to downstream so that downstream developers will work there
instead of internally".


# What if packages don't build on ELN?

The question isn't actually answered. Instead, the proposal answers
*how* packages will fail to build in ELN.


These are linked topics.

ELN is a "build profile" applied to Fedora Rawhide sources. If we take
a working Fedora Rawhide content and apply build profile to it, and it
breaks, then there two reasons why it may break:
1) the content is different because of the conditional, and this
conditional is broken. So we fix it.
2) the build profile is different, then we fix the buildroot and build
flags, and pungi config.

As we have a working baseline, it means that eventually if we reduce
the number of differences we reach the working state. Once we have
that working state we can start _adding_ differences again while
keeping it in a working state.


# If a package fails to build on ELN, what will happen?

What will the time limit be?
What exactly happens is a maintainer rejects the pull request?

# What if there is a new upstream feature RHEL wants in a package, how
will that go in?

Why is this not in scope? We're bringing RHEL development closer to
Fedora development. Non-Red Hatters don't know how a feature gets into
RHEL, and I don't blame them if they think this will affect their
workflow. Will it? How?


It is not a new thing which ELN changes. Red Hat developers have
always been working with Fedora on changes. If feature makes sense to
Fedora, it is not a matter of the ELN build, it is a matter of
bringing it to Fedora Rawhide.
ELN is not involved in this process.


OK, so would the following answer be correct?
That is not in the scope of ELN. As in the past, the feature can be 
either added to Fedora (and ELN) on its own merits, or it can be added 
directly to RHEL without affecting Fedora (and ELN) at all.



# What if I do not want to have %if's in my spec files?

What happens if ELN SIG cannot find a solution the maintainer is
comfortable with?


Again, we use raw Fedora Rawhide packages which work.


And if they don't work in ELN, it's up to the ELN SIG to make Rawhide 
packages work there. Right?



# What if I do not want to have %if's in my spec files, but I want to
see how changes show up in RHEL?

Sorry, but the answer reminds me of Modularity promises that the missing
pieces will be ready in the future.
What will the maintainer actually be expected to do in this case?


In Fedora - nothing. ELN is not the answer to all the wishes. And we
don't promise that we will ever cover this case in ELN. I don't see
any similarities with Modularity here.


The proposal should address the impact on all major packaging
styles, and while one side of the spectrum (packagers preferring single-spec
with conditionals) is covered, there are very few concrete details on the other
(packagers interested in simple spec files or completely uninterested in RHEL).
The affected packagers are concerned that the current proposal does not in fact
benefit Fedora (to an extent that would justify the disruptions), but rather
addresses mainly a downstream RHEL concern using Fedora's resources.


This is a great example of the Nirvana Fallacy. Essentially, you are
arguing that improvements for one group is not acceptable unless it
improves things for every other group too.


It doesn't have to *improve* things for the other group, but if not, it
should clearly acknowledge that it makes things worse (or the same), and
say how. Otherwise that group will justifiably feel excluded.

Say a new package is added to RHEL, which was previously

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3

[Petr Viktorin]

On 2020-04-02 20:07, Stephen Gallagher wrote:

On Thu, Apr 2, 2020 at 12:56 PM Miro Hrončok  wrote:

The change proposal received overly negative feedback by the packager community
as represented both by RHEL¹ and non-RHEL maintainers. Despite being reworked
several times, none of this feedback was reflected in the proposal, only new
reasons why this is going to be done the original way were added. It seems that
feedback is collected not to find the best technical solution, but rather to
find ways to justify a solution that's already decided.



This is needlessly antagonistic, Miro. We've collected the feedback in
good faith, examined it and then identified shortcomings with it. For
the sake of clarity in the Change Proposal, I've recorded that
reasoning there.


Key questions in the *Detailed Description* remain "out of scope of ELN" or not
answered clearly.


If something is not clear, please constructively offer that
information. I've been doing my best to rephrase and clarify anything
that has come up. Anything remaining that is "out of scope of ELN" is
literally just that. ELN's scope is largely "Make Fedora Rawhide more
useful to downstream so that downstream developers will work there
instead of internally".


# What if packages don't build on ELN?

The question isn't actually answered. Instead, the proposal answers 
*how* packages will fail to build in ELN.


# If a package fails to build on ELN, what will happen?

What will the time limit be?
What exactly happens is a maintainer rejects the pull request?

# What if there is a new upstream feature RHEL wants in a package, how 
will that go in?


Why is this not in scope? We're bringing RHEL development closer to 
Fedora development. Non-Red Hatters don't know how a feature gets into 
RHEL, and I don't blame them if they think this will affect their 
workflow. Will it? How?


# What if I do not want to have %if's in my spec files?

What happens if ELN SIG cannot find a solution the maintainer is 
comfortable with?


# What if I do not want to have %if's in my spec files, but I want to 
see how changes show up in RHEL?


Sorry, but the answer reminds me of Modularity promises that the missing 
pieces will be ready in the future.

What will the maintainer actually be expected to do in this case?



The proposal should address the impact on all major packaging
styles, and while one side of the spectrum (packagers preferring single-spec
with conditionals) is covered, there are very few concrete details on the other
(packagers interested in simple spec files or completely uninterested in RHEL).
The affected packagers are concerned that the current proposal does not in fact
benefit Fedora (to an extent that would justify the disruptions), but rather
addresses mainly a downstream RHEL concern using Fedora's resources.


This is a great example of the Nirvana Fallacy. Essentially, you are
arguing that improvements for one group is not acceptable unless it
improves things for every other group too.


It doesn't have to *improve* things for the other group, but if not, it 
should clearly acknowledge that it makes things worse (or the same), and 
say how. Otherwise that group will justifiably feel excluded.



Say a new package is added to RHEL, which was previously only in Fedora. 
The packager doesn't want RHEL conditionals in the spec. The change 
doesn't make sense upstream or in Fedora (for example, the crypto 
backend needs to be replaced to comply with some regulation). Without 
the change, the package (and anything depending on it) cannot be built 
in ELN.
As I read the proposal, ELN will work with the packager and try to find 
a good solution. However, the discussion might be under pressure of RHEL 
guidelines.


What *actually* happens in this worst case? Will the macros be forced 
into the package?
(If yes, please say it explicitly, so we can discuss that! If not, 
hooray -- alse say that explicitly!)


Even if the worst case scenatio is very unlikely, it would help thinking 
about the not-ideal-but-not-worst cases as well.




Downstream RHEL concerns *are* Fedora concerns. I cannot stress this
enough: Fedora and Red Hat have a highly symbiotic relationship. The
more RHEL succeeds, the more support Fedora gets from Red Hat. The
more Fedora succeeds, the better the resulting RHEL product. It is
disingenuous to imply that something that "addresses mainly a
downstream RHEL concern using Fedora's resources" is a net-negative
for Fedora.


Yes, that is true! The question is, does the goal justify the means? And 
even before that, what exactly are the means (specifically, in terms of 
limiting packager autonomy)?



While benefiting the entire Fedora/RHEL/CentOS/EPEL ecosystem is certainly a
good goal, I believe that doing this in a way that alienates a significant part
of our packagers is a disservice to Fedora. The concerned packagers believe that
Fedora is (and should remain) the upstream for RHEL, not RHEL itself. This might
be shifting us to the u

Full history of linux kernel (Re: CPE Git Forge Decision)

[Petr Viktorin]

On 2020-03-31 21:39, Przemek Klosowski via devel wrote:
[...]> Still, the
official Linux git log ( 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?ofs=905000 
) lacks the development history preceding 2005-04-16, and starts with 
one heck of a commit:





FWIW, this is mainly because early Git was unable to cope with huge 
histories, converting old history to another format isn't 
straighforward, and the history is immutable.


Earlier history is out there and there are ways to `graft` it to a 
current repo to locally join the histories together. See e.g. 
https://stackoverflow.com/a/8130239/99057

___
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 33 System-Wide Change proposal: ELN Buildroot and Compose

[Petr Viktorin]

On 2020-03-25 17:33, Aleksandra Fedorova wrote:

[Branching] removes community maintainer from the conversation about what
downstream is doing. While we want to give community member a voice in
that conversation.


I fear that this proposal *forces* the community member to participate 
in the discussion. That is a very different thing than giving them a voice.



On 2020-03-25 17:10, Miro Hrončok wrote:

On 25. 03. 20 16:47, Stephen Gallagher wrote:

I think we managed to miss a few key points in the Change Proposal
which is directly resulting in a bit of the confusion here.


Reading the rest of you e-mail I must agree that this is what happened. 
Would you mind putting the change back to incomplete state and resend it 
once more for feedback once this is addressed?



The first and most important of these is that ELN will*not*  be
building the complete Fedora package set. We're going to be building a
selected subset of packages (derived from packages in RHEL 8 and
EPEL). Our current expectation is that we are going to be looking at
fewer than 2500 source packages. We are still working up the initial
list of these and we will update the Change Proposal with it (as well
as providing a fedora-devel post breaking down the known owners).


Glad to hear that.


Second, from this reduced subset, we expect that the overwhelming
majority of the maintainers are Red Hat employees that already work on
RHEL. With this in mind, we think that the level of concern about how
this will affect non-Red Hat contributors is premature. We will reach
out directly to those non-Red Hat contributors we identify.


This actually worries me very much.

The subset of packages will need to form a working system; it will 
include the most important packages. I hope this doesn't end up limiting 
maintainers of Fedora's most central packages to only Red Hatters or 
those that agree to play by RHEL rules that they have no say in.


I am pretty sure that most packages/packagers will be OK with the ELN 
change. But "most" is not enough. We do need to take the "worst cases" 
into account. Consider a package that:
- is needed in RHEL, but only as a dependency of something vital; the 
RHEL maintainer doesn't care too much about it outside their work duties
- has an enthusiastic packager in Fedora, who prefers to leave RHEL work 
to paid developers


(As member of a team that, some time ago, used to be catch-all RHEL 
maintainer for anything that happened to be written in Python, I can 
definitely imagine situations similar to this.)


For such a package, we need to avoid pushing ELN macros into the 
package, otherwise we lose an enthusiastic contributor who does amazing 
work in Fedora.


Such a package might even be hypothetical right now, but the case still 
needs to be adressed. A package can fall into this category at any time 
in the future. It's not enough to identifying packagers that are 
affected now, and work with them. There needs to be a process for cases 
like these, and it can't be "merge these ELN macros now, there's a 
deadline coming; maybe we'll come up with a better process in the 
future". (Especially if Red Hat is unlikely to drive setting up a better 
process.)


IMO, any changes needed in EL need to be opt-in, with the understanding 
that opting in will be (almost always) beneficial for everyone involved. 
They need to feel like a gift ("Hello fedora packager, please accept 
this PR with EL macros; it'll make it easier to work on this together!") 
rather than forced ("Red Hat needs this; merge it or else").


To borrow Neal Gompa's words, ELN needs to not feel "like it's written 
for Red Hat people to move their sandbox outside of Red Hat into Fedora 
without anyone else to be able to play in the sandbox."



For ELN changes to be to be opt-in, there essentially needs to be a 
place to diverge -- a place for ELN hotfixes to live while polishing 
them and debating their usefulness in Fedora and further upstreams.
Here by "hotfix" I need something required in RHEL that is not yet ready 
for upstream. It is healthy to have a place for such things: it removes 
time pressure from discussions (people from the community very often 
have good ideas but less time), but allows the fix to be used now (so 
the rest of ELN isn't blocked).
Forks are good if they're not permanent (but, making them not permanent 
needs effort).



As Miro Hrončok continues:
As a Red employee if I need to diverge a RHEL package from Fedora, I 
prefer to use branches as well. And I know for a fact I am not alone in 
this. Please don't forget to identify and reach out to Red Hat 
contributors as well, not just the non-Red Hat contributors.


[Stephen Gallagher]:

Finally, of the set of packages that we're going to be including, we
anticipate around 200-300 of them will have distro conditionals that
need investigation (with fewer needing actual modification). The ELN
SIG will be doing this initial investigation and will provide guidance
(and/or PRs) to aff

Re: Copr Build System - review of 2019 and vote for features in 2020

[Petr Viktorin]

On 2020-01-22 12:03, Kevin Kofler wrote:

Kevin Kofler wrote:

IMHO, this whole "delete by default" concept is inherently flawed and
dangerous and cannot be fixed. Notification e-mails can be lost in so many
ways (wrong Fedora notification settings, e-mail provider issues, spam
filter false positives, out-of-quota mailbox, etc.) or be missed due to
being offline for a prolonged period of time. It should never be allowed
to delete users' data without their explicit confirmation. Especially in
this case where it is not even possible to reupload the data because Copr
can no longer build for those EOL chroots (which is another quite annoying
limitation of Copr – allowing to build for EOL releases would also allow
people to try backporting select security fixes to those releases Fedora
no longer wants to support).


PS: I also think that at the very least, there ought to be a way to
permanently opt-out a Copr repository out of all future cleanups. Some Coprs
such as the Kannolo Copr should just always be preserved.

I also do not understand why 6 TB of disk space is such an issue in times
where one single HDD can carry up to 16 TB.


AFAIU, the problem is that if something should *always* be preserved, 
you're looking at very different hardware (and associated maintenance 
work) than a single HDD.

___
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

List of Python 2 packages to be removed mid-November (= in a week)

[Petr Viktorin]

Dear maintainers,
here is an updated list of packages that (transitively, at build or run 
time) require Python 2 and have not yet got a FESCo exception to do so.

If you were bcced on this e-mail, it affects one or more of your packages.

The default action will be to remove such packages starting November 15.

If this took you by surprise, don't panic. It's possible to change the 
default. Let us know and we'll work things out.
The mid-November deadline is not for removing *all* of Python 2, but for 
getting exceptions.


If you are already working to port to Python 3, sorry for the spam! But, 
time is running out. Consider getting an exception so the package isn't 
removed in November. Or remove the package (if nothing depends on it) 
and re-introduce it when it's ported. (We'll be happy to help, with 
reviews or otherwise.)
If you want to remove the Python 2 package, but you're waiting for 
something that depends on it, please make sure you know what the 
maintainer(s) of the dependent package are planning to do. (Hopefully 
you have fewer dependents than "python27" or "python2-setuptools", and 
your questions can be more targeted than this e-mail.)
If you want to continue using Python 2, please let us know ASAP. We can 
guide you through filing the FESCo exception.


If you talked to us (on e-mail or Bugzilla) and think your package is 
fine as it is, but you don't have a FESCo exception (or a request for 
one), then there was a misunderstanding. We're sorry for our side of it. 
Please get a FESCo exception for your package.


Note: Packages that BuildRequire python27, and have no other Python 2 
dependencies, have a blanket exception for Fedora 32:

https://pagure.io/fesco/issue/2250
They aren't listed below.
Also note: Orphaned Python 2 packages also aren't listed below, but will 
be removed unless someone adopts them and gets an exception.



## Why the FESCo exception?

It's a bit of process meant to ensure all the relevant people know that 
a package *and its dependencies* will stay in Fedora, despite using an 
(upstream-)unmaintained interpreter.
With hundreds of packages, all different, we unfortunately do need a bit 
of bureaucracy.
Due to the volume, the Python 2 removal will be *automated*, so if you 
have an "obvious exception", it's still important to let *humans* know, 
so they can adapt their automation.



## Why now?

The current maintainers of python27 don't want to maintain it forever, 
without upstream support. But we also don't want to just drop it and let 
everything burn, hence all this fuss.
The policy and messaging around deprecating and removing Python 2 has 
been getting stronger and stronger ever since the Python 3.0 release in 
2008.

If you still need more time, please let us know.


## What exactly is happening?

The formal change proposal is here:
https://fedoraproject.org/wiki/Changes/RetirePython2

Packages requiring Python 2 will be removed starting November 15 (unless 
they have an exception).

Components with all essential subpackages removed will be retired.
The removal will be (semi-)automated.

Source packages only BuildRequiring removed packages will fail to build, 
and will be removed according to the regular FTBFS policy.


https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/


## The list

Here is the package breakdown sorted by maintainers.
The list contains the shortest dependency path to Python 2. The arrow 
means "depends on".


The data is based on the latest rawhide compose, so it might be a bit 
out of date.


If you find a bogus dependency, such as a dependency that can be 
resolved in a non-Python 2 way, please let us know, so we can blacklist it.


aarem
  pdf-stapler
(→ PY2)
python2-staplelib (→ PY2)
  python-PyPDF2
python2-PyPDF2 (→ PY2)
  python2-more-itertools
(→ PY2)
abbot
  protobuf
python2-protobuf (→ PY2)
abompard
  python-coverage
python2-coverage (→ PY2)
  python-mako
python2-mako (→ PY2)
  python-pysocks
python2-pysocks (→ PY2)
  python-urllib3
python2-urllib3 (→ PY2)
ajmitchell
  NFStest
(→ PY2)
alexl
  dbus
(BuildRequires: python2-gobject → PY2)
  dbus-python
python2-dbus (→ PY2)
  gnome-python2
gnome-python2-canvas (→ PY2)
gnome-python2-devel (→ PY2)
gnome-python2-gconf (→ PY2)
gnome-python2-gnome (→ PY2)
gnome-python2-gnomevfs (→ PY2)
  gnome-python2-desktop
(→ gnome-python2-canvas → PY2)
gnome-python2-gnomekeyring (→ PY2)
gnome-python2-libwnck (→ PY2)
gnome-python2-rsvg (→ PY2)
alsadi
  dumb-init
(BuildRequires: python2-mock → PY2)
amigadave
  dbus
(BuildRequires: python2-gobject → PY2)
amluto
  python-musicbrainzngs
python2-musicbrainzngs (→ PY2)
anishpatil
  gnome-transliteration
(→ python2-gobject → PY2)
aperezbios
  sugar
(→ PY2)
sugar-cp-* (→ sugar → PY2)
  telepathy-salut
(BuildRequires: python2-dbus → PY2)
apevec
  pyparsing
python2-pyparsing (→ PY2)
  python-distutils-extra
  

Re: Next F31 push?

[Petr Viktorin]

On 2019-10-18 09:18, Leigh Scott wrote:

On Fri, 2019-10-18 at 07:50 +0200, Kevin Kofler wrote:

I mean, in the end it would be self-defeating, because the high chance
that it would introduce more problems would just mean we'd need to
freeze again for longer.



So you get a working ISO for release then break it by releasing untested 
updates  after GA :-(


Untested but fixable. The ISO needs to be usable on its own, but a 
0-day-after-GA update can be amended by 1-day-after-GA update. Or a 
7-day one.

___
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: Why retire Python 2 packages and games that still work to end user ?

[Petr Viktorin]

On 8/11/19 2:28 PM, Kevin Kofler wrote:

Miro Hrončok wrote:

We are still planning to maintain the interpreter. As is documented in the
change. So can we please stop arguing about maintaining the interpreter
over and over? It is staying and our team will maintain it at least until
RHEL 7 EOL, possibly longer.


Then why do you require all this FESCo exception bureaucracy, including a
Python 3 migration plan, for every single package requiring Python 2, even
if it is only the interpreter (and the shipped standard library)?


Python 2 will not get the attention, fixes, and security updates that 
people have been used to in the past decade. That's a big deal, and 
unfortunately we know no good way to properly communicate this to all 
the affected packagers.
We hope the bureaucracy works for the hundreds of packages with inactive 
maintainers; the flip side is that the active maintainers do have to do 
some more work, even if it's just filing a ticket and switching a 
BuildRequires. Sorry for that.


As for the Python 3 migration plan: we can agree to maintain Python 2 
for you to depend on, if there's a feasible plan of moving away from 
Python 2. If there's no plan, you'll just run into trouble in a few more 
years. If you consider your package important, we really want to know 
about the situation.


The Python 3 migration plan is not a requirement, but a very common and 
useful piece of information that we want to hear about. Every package is 
different; we can't know where each upstream does their planning. As a 
packager, you know best where to ask for this info, so we ask you to 
find it and paste the link in a Fedora place -- Bugzilla or a FESCo ticket.
If there's another plan instead of a "Python 3 porting plan" (like port 
to Rust instead, or to Tauthon, or maintain Python 2 forever), we'd also 
like to know about it.




Yes the concern is about maintaining the python2-* packages.

The difference between EL and Fedora is that package sin Fedora get recent
rebases / updates to newer version. You cannot just package them and call
it "done". And most of the upstreams are coming to a point where you
cannot update the Python 2 package because the new version doe snot
support Python 2.

That at the end means you need to go over nonobvious bumps to split the
Python 2 package out of the "common" package, in order to update the
"common" (now Python 3 only) package. And this problem spreads further
with dependencies (even transitive ones). I don't have the energy or time
to split hundreds of packages and maintain a separate stack of Python 2
packages. If somebody else has, go for it.


And that is a perfectly valid reason to orphan the Python 2 parts. My issue
with the policy you proposed and FESCo approved for F31 is that it does not
require this to be the case, but allows maintainers to drop the Python 2
subpackage just because they don't like Python 2 (or simply want to avoid
going through the bureaucracy you're requiring for F32), which is a quite
antisocial thing to do.

If the partial orphaning policy were limited to packages where upstream
dropped or is in the process of dropping Python 2 support, I would not
object.


The policy is for those *and their dependencies*.

See, I have a "package where upstream is in the process of dropping 
Python 2 support". It's called "python2".
I could just drop it and call it a day, but since people still want it, 
I'll maintain it. But only for those who care and who understand the 
situation; not for the hundreds of inactive maintainers.
(To be clear: making it possible and straightforward to build Fedora 
RPMs with python3 *is* more work than just maintaining the interpreter 
for users.)



That said, those are also the cases where the split out python2-* package
WOULD in fact be "done" and never require getting updated to a newer
version, unless upstream maintains some legacy/LTS branch. So the situation
for whomever ends up stuck maintaining the python2-* package would not be
that different from the RHEL situation.


Sure, but this "python2" one does need ongoing maintenance.


The set of python2-* packages to remain is determined by the FESCo
exceptions. It is fairly easy really: We don't have the necessary
information to understand what Python packages are "important" and what
are "cruft". Hence if your package is important, you just need to explain
that. Obviously, if you need to maintain the package as a dependency, for
another important package, the exception can be requested at once, you
don't need to request dozens of exception to keep e.g. chromium around.


But why does this have to go through FESCo and a formal approval process?
Why is it not sufficient that the maintainer says "yes, this is still
needed"? If a maintainer wants to keep the package, this clearly means it is
important to SOMEBODY, so why do we need an approval by committee to confirm
this (or worse, veto this against the wishes of the maintainer)?


The maintainer needs to say "yes, thi

Orphaned python2-django1.11

[Petr Viktorin]

Hello,
Back when [Django 2.0] was released in Fedora 28, I took over Django 
1.11 LTS as some important (to me) packages depended on it. I'm no 
longer interested in maintaining it, so I've orphaned it.
Let me know if you want to take it. If no one does, it may be removed 
from Rawhide in 6 weeks.


Depending packages and their maintainers are:
- fts-monitoring (andreamanzi, simonm)
- python-oauth2client (mbaldessari, ralph)
- cobbler-web (jimi, kwizart, orion, shenson)

Let me know if you need help with these packages.


[Django 2.0]: https://fedoraproject.org/wiki/Changes/Django20
___
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

Don't lint in %check (Was: python-flake8 package not available in F30)

[Petr Viktorin]

On 3/9/19 7:33 PM, Chris wrote:

Thank you both for your fast reply!

 >  Why do you need to BuildRequire a linting tool? What are you trying 
to achieve?


I just use python-flake8 as an OCD way of having my build fail if i fail 
pep8 :)  It's just used in conjunction of my unit tests.


Running a linter is fine upstream, but I'll argue that you'll be much 
better off disabling it for the distro build.


Newer versions of flake8 can cause your tests to suddenly fail. We've 
seen that happen relatively often -- style standards themselves evolve, 
and the way they're codified in automatic tools evolves.


Upstream, please do check code style or unused imports if that's your 
thing. But after you cut a release (on GitHub/PyPI), linting the code 
doesn't really bring any benefit. (Unlike running the test suite, of 
course.)


Even if you're currently maintaining this both upstream and in Fedora, 
and have the energy to watch for & fix any failures, after some years 
you might want to pass the package on to someone else. Be nice to your 
successor. And be nice your potential Debian (et al.) maintainers by 
making your specfile show how to package for a distro :)



(Note: AFAIK this is not official Fedora policy; please 
disagree/discuss/argue.)

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

Python BuildRequires Generators (Re: F31 System-Wide Change proposal)

[Petr Viktorin]

On 2/22/19 2:39 PM, Neal Gompa wrote:

On Fri, Feb 22, 2019 at 6:01 AM Petr Viktorin  wrote:


On 2/18/19 9:19 PM, Ben Cotton wrote:

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

= BuildRequires Generators =

== Summary ==
Add possibility to generate build-time dependencies within RPM spec
file and teach RPM and mock how to handle this.



I am very excited about this change. Count with me for Python. Is there
a (draft) API to start coding against?

In Python, there's an effort to enable things like this generator, e.g.
[PEP 517].

Here, gathering BuildRequires is a two-step process:

- the "build backend" is specified in declarative metadata;
- then the build backend can query backend-specific metadata for
additional BuildRequires.

Is that possible with the current plans?


BTW: New versions of Python's usual build system (setuptools/setup.py)
will be forward compatible with PEP 517. Please do not write generators
that use setup.py directly.


We currently have no BuildRequires generators written yet, so we can
Do It Right(TM) for this. :)

That said, I'm not sure how we will be broadly compatible for divining
setup_requires if they are specified...


No divining in the generator, please.
We should use only the (newly) standardized interfaces, PEP 518, 517, 
etc. Issues with those should be solved upstream (or patched 
temporarily, with a bug filed).
Nothing in the generator should be Setuptools-specific (except using 
Setuptools as the default build backend, for backwards compatibility 
reasons).
setup_requires (and all of setup.py) are Setuptools-specific, so 
Setuptools is responsible for all the divining and for making the info 
available through standardized interfaces.

And yes, this aligns with Setuptools upstream plans.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F31 System-Wide Change proposal: BuildRequires Generators

[Petr Viktorin]

On 2/22/19 12:01 PM, Petr Viktorin wrote:

On 2/18/19 9:19 PM, Ben Cotton wrote:

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

= BuildRequires Generators =

== Summary ==
Add possibility to generate build-time dependencies within RPM spec
file and teach RPM and mock how to handle this.



I am very excited about this change. Count with me for Python. Is there 
a (draft) API to start coding against?


In Python, there's an effort to enable things like this generator, e.g. 
[PEP 517].


Missing footnote:
[PEP 517]: https://www.python.org/dev/peps/pep-0517/
specifically: 
https://www.python.org/dev/peps/pep-0517/#get-requires-for-build-wheel




Here, gathering BuildRequires is a two-step process:

- the "build backend" is specified in declarative metadata;
- then the build backend can query backend-specific metadata for 
additional BuildRequires.


Is that possible with the current plans?


BTW: New versions of Python's usual build system (setuptools/setup.py) 
will be forward compatible with PEP 517. Please do not write generators 
that use setup.py directly.

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

Re: F31 System-Wide Change proposal: BuildRequires Generators

[Petr Viktorin]

On 2/18/19 9:19 PM, Ben Cotton wrote:

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

= BuildRequires Generators =

== Summary ==
Add possibility to generate build-time dependencies within RPM spec
file and teach RPM and mock how to handle this.



I am very excited about this change. Count with me for Python. Is there 
a (draft) API to start coding against?


In Python, there's an effort to enable things like this generator, e.g. 
[PEP 517].


Here, gathering BuildRequires is a two-step process:

- the "build backend" is specified in declarative metadata;
- then the build backend can query backend-specific metadata for 
additional BuildRequires.


Is that possible with the current plans?


BTW: New versions of Python's usual build system (setuptools/setup.py) 
will be forward compatible with PEP 517. Please do not write generators 
that use setup.py directly.

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

Re: F31 System-Wide Change proposal: BuildRequires Generators

[Petr Viktorin]

On 2/19/19 7:04 PM, Raphael Groner wrote:

Hi,

maybe you already noticed, there's a project called pipreqs that parses python 
code for import statements. We've already a review request:
https://bugzilla.redhat.com/show_bug.cgi?id=1665749

Although, I doubt in general that any automagic with dependency generators 
brings a huge benefit in the long run. In case of python projects, I see 
sometimes conditional dependencies that enable optional features by awareness 
of any existance of a library, e.g. SecretStorage that parses for alternative 
desktops and optional password storage. Further, mostly there are up to 5 
dependencies to note but sometimes 2 to ignore anyways.


Yes, automagic generators don't work in the long run. Requirements are 
always better listed explicitly.
However, for most Python projects they *are* listed explicitly -- in the 
Python package metadata. And there are efforts upstream to make this 
metadata more usable for automation.


Currently, that metadata needs to be copied, by hand, to RPM 
BuildRequires. That's what a generator can automate.

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

Re: Python packages with extras dependencies

[Petr Viktorin]

On 2/5/19 12:44 AM, Eli Young wrote:

Python packages can specify extras dependencies, which are sets of dependencies not 
required for core functionality, and which generally correspond to some feature. These 
can then be specified by downstream consumers of the package. For example, requests has 
an entry in extras called security[1], which currently adds requirements of python 
packages pyOpenSSL >= 0.14, cryptography >= 1.3.4, and idna >= 2.0.0. A 
downstream consumer that wants to use this would add a dependency on requests[security].

 From what I can tell, the current practice in Fedora packaging is to ignore 
these. This simplifies packaging Python modules that have extras specified, but 
ultimately pushes the specification of those dependencies down into every 
consumer of the package, whether users or other packages.

As an example of this, I currently maintain the python-dns-lexicon package, 
which provides a common CLI and API for various different DNS providers. Some 
of the providers have additional dependencies that are necessary to function, 
and which are specified as extras. The Plesk provider, for example, also 
requires python-xmltodict[2]. In line with what appears to standard practice, 
extra dependencies are not currently installed with the broader 
python-dns-lexicon package. If, however, a user or dependent package wants to 
utilize the Plesk functionality of python-dns-lexicon, they now need to know 
that python-xmltodict needs to be installed, and will need to check whenever 
the package updates as to whether or not that has changed.

How should we be handling this? Right now, it seems that most packages follow 
this behavior of punting on the responsibility to package consumers. Should 
this continue? If not, how should we handle things? Should we just include all 
extras dependencies in the parent package? Alternatively, should we have 
dummy/meta subpackages for extras that require the parent package as well as 
any extras dependencies (e.g. python-dns-lexicon-plesk would require 
python-dns-lexicon and python-xmltodict)?

[1]: https://github.com/requests/requests/blob/v2.21.0/setup.py#L105
[2]: https://github.com/AnalogJ/lexicon/blob/v3.0.6/setup.py#L101



Hello,

AFAIK, there are currently no official guidelines for Python extras, and 
there's some fame & glory waiting if you'd like to help draft them :)


That said, I believe subpackages are the answer here.
In addition you could use weak dependencies. I think the main package 
should have "Suggests:" for all the extras, and even "Recommends:" for 
ones that are almost always useful.
I believe the cost of extra dependencies is lower in Fedora than on 
PyPI. Some common reasons for punting deps to extras don't apply (like 
bootstrapping issues or requiring compiled modules from pure-Python 
ones), so sometimes it's good to just go for hard Requires.


Purely as a packager, I'd like to see "boolean Provides", something like:
Provides: (python3dist(dns-lexicon[plesk]) if python3dist(xmltodict))
... but at a chat with RPM devs on the last Flock, I learned that is not 
feasible.


The Python SIG (python-de...@lists.fedoraproject.org) would be a good 
place to discuss specific details.

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

Re: Python setuptools and files to be installed in the installation prefix

[Petr Viktorin]

On 10/2/18 10:06 PM, Miro Hrončok wrote:

On 2.10.2018 16:30, Federico Bruni wrote:

Hi folks

While trying to figure out a way to install some desktop specific 
files (such as APP.desktop or APP.appdata.xml) within the installation 
prefix (instead of python installation) using setuptools, I started 
wondering if it's actually a good idea.


AFAIK setuptools (PyPA) considers this a bad practice and doesn't (want 
to) support this. It's up to the Linux package maintainers to do this.


I don't remember where this information comes from, but I'm 90% sure 
it's accurate.


Peter and/or Nick might know more. Cced.


If you use Python's upstream packaging mechanisms, the expectation is 
that the result is installable into a self-contained environment like 
venv, Conda, or a user's home.

To install these files system-wide, put it in the RPM spec.

It's probably possible to do this correctly from setuptools, but that 
would put you in the business of figuring out how to do it correctly 
from setuptools. I don't think you want that :)

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

Re: Heads Up: python2 is marked as deprecated

[Petr Viktorin]

On 09/11/18 11:52, Tomasz Kłoczko wrote:
On Tue, 11 Sep 2018 at 16:48, Petr Viktorin <mailto:pvikt...@redhat.com>> wrote:

[..]

These numbers hide an important fact: many things currently come with
RPMs for both python2 and python3.

More detailed statistics (based on SRPMs, not binary RPMs):
http://fedora.portingdb.xyz/
Graph with historical data: http://fedora.portingdb.xyz/history/

 > In other words trying currently announcing python2 as depricated
is at
 > least a bit .. odd.

Do you know a better way to make the python2 numbers go down?

Would *you* be interested in maintaining python2 past 2020, with no
upstream support and 3415 dependent packages?


No and no .. of course :)
I've been only trying to say that with current numbers about balance 
between python 2 and 3 packages are making announcement about 
deprecation a bit to early. Only this and nothing more :P


When will it not be too early?


I fully understand effort to migrate ASAP to python 3.
IMO it should be announced only kind of call to migrate as much as 
possible with completing set of advises abut typical porting issues.


Python 3 is now almost 10 years old. The "Python 3 as Default" change 
was for Fedora 21. Python's documentation has a section on porting. 
There are printed books about porting. There's a comprehensive guide at 
portingguide.readthedocs.io. Fedora's Python packaging guidelines say 
"If it supports only python2 then [...] upstream SHOULD be contacted and 
encouraged to rectify this issue." -- have you done that?


We're honestly tired of making calls to migrate. What would another one 
of those accomplish?


Forming ad hoc team people which could help porting code to python 3 may 
IMO be useful.


Try the Python SIG!

I have in my set of packages one of those which will require migration 
to python 3 as well.


Why have you waited so long?


It is mc package which has amazon s3 vfs backend as and
I'm thinking about create mc-s3 (or mc-vfs-s3) subpackage to separate 
python2 dependent parts.
Theoretically as now aws-cli AFAIK is already ported to python 3 it 
should be easy however I haven't now access to AWS systems to test s3 
bucket access over mc.
Other possible option may be rewrite s3 vfs backent to use some other 
(non python based script .. and backend tool).


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

Re: Heads Up: python2 is marked as deprecated

[Petr Viktorin]

On 09/10/18 11:26, Tomasz Kłoczko wrote:

Just FTR current numbers about packages which requires python3 vs python2:

# dnf repoquery -C --whatrequires python3| grep -cv i686; dnf repoquery 
-C --whatrequires python2| grep -cv i686

Last metadata expiration check: 0:59:03 ago on Mon 10 Sep 2018 18:23:45 BST.
3034
Last metadata expiration check: 0:59:09 ago on Mon 10 Sep 2018 18:23:45 BST.
3415


These numbers hide an important fact: many things currently come with 
RPMs for both python2 and python3.


More detailed statistics (based on SRPMs, not binary RPMs): 
http://fedora.portingdb.xyz/

Graph with historical data: http://fedora.portingdb.xyz/history/

In other words trying currently announcing python2 as depricated is at 
least a bit .. odd.

kloczek


Do you know a better way to make the python2 numbers go down?

Would *you* be interested in maintaining python2 past 2020, with no 
upstream support and 3415 dependent packages?

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

Re: Why are we shipping debug builds of pythons?

[Petr Viktorin]

On 08/05/18 14:01, Jan Kratochvil wrote:

On Sun, 05 Aug 2018 13:39:58 +0200, Charalampos Stratakis wrote:

Here we are referring to the python2-debug or python3-debug builds, which
are just extra python builds that are compiled with the --with-pydebug flag


Not just --with-pydebug:

--
%if %{with debug_build}
BuildPython debug \
   "--without-ensurepip --with-pydebug" \
   "-O0"
%endif # with debug_build

BuildPython optimized \
   "--without-ensurepip %{optimizations_flag}" \
   ""
--

Many packages have their *-debug variants. And then some packages (like
kernel) switch even their standard builds to debug mode but only in Rawhide.
Despite all that the *-debug package one occasionally needs is then missing
and one still has to build it locally.

That is all together messy. This is why Microsoft has their debug build of
their whole OS - Windows - called Checked Build:

https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/checked-and-free-build-differences


The main issue with --with-pydebug is that it changes the ABI, i.e. all 
extensions need to be re-built specifically for it (and debug extensions 
outside the standard library aren't usually packaged in Fedora). That 
makes it much less useful than if it just used less optimizations.

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

Re: F29 System Wide Change: Move /usr/bin/python into a separate package

[Petr Viktorin]

On 05/24/18 18:53, Randy Barlow wrote:

On 05/24/2018 12:45 PM, Jason L Tibbitts III wrote:

Could you fill us in a bit?  The only thing I know about resultsdb is
that there is a thing called resultsdb.  I went to
https://taskotron.fedoraproject.org/resultsdb/results but I have no idea
how to find, say, all packages which call /usr/bin/python at build time.
A naïve search for /usr/bin/python didn't turn anything up.


Well I didn't say it was easy to do, but there is a test that tasktotron
runs on our packages called dist.python-versions.executables that I
*think* is the one responsible for failing packages that still use
/usr/bin/python. This URL can show results for that particular test:

https://taskotron.fedoraproject.org/resultsdb/results?testcases=dist.python-versions.executables

Another test seems to notice if the package uses /usr/bin/python during
build:

https://taskotron.fedoraproject.org/resultsdb/results?testcases=dist.python-versions.python_usage

So we could look through these to find packages that fail. Of course, a
downside to this approach is that there will only be data for packages
that have been built since these tests existed, so unmaintained packages
might not appear in these results even though they could have problems.
So maybe it's not actually a great way to know the answer to the
question now that I think about it more. Well, except that we did try to
build all packages during the mass rebuild, but then again, many of them
failed to build and still haven't been rebuilt...


That's actually our earlier attempt at solving this problem! :)
It's moderately useful, but it does have its shortcomings:
- It works by grepping the logs, so anything that hides stderr isn't 
detected
- It keeps /usr/bin/python available, so config tools that check whether 
/usr/bin/python *exists* get the wrong view of their environment.
- It's not easy to get a package list out of resultsdb (which is 
probably just a solvable UI problem)

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

Re: F29 System Wide Change: Move /usr/bin/python into a separate package

[Petr Viktorin]

On 05/24/18 01:01, Miro Hrončok wrote:

On 24.5.2018 00:56, Adam Williamson wrote:

The thing you're missing - which the Change doesn't explicitly state,
so it's understandable - is the effect of having the python2 package
Recommend the package with /usr/bin/python in it.

For *user* systems that will mean that package always gets installed
alongside python2, including that it should get installed on
update/upgrade. They could then manually remove it, but this is the
only way they could get into trouble - by default, both existing and
new installs should have /usr/bin/python. This is because dnf's default
behaviour is to install Recommends/Supplements.

However, for *package builds*, Recommends/Supplements are not
installed. So *package builds* which only BuildRequire python2 or
whatever would not get /usr/bin/python , and would thus fail. The
packager could always just add BuildRequires python-unversioned-command
to "fix" the problem, which is probably the fix we don't want them to
do, but at least then we have a handy way to identify recalcitrant
packages, and their maintainers can't pretend they weren't aware of the
problem and didn't actively decide to take the lazy way out.


I guess this needs to be added to the change proposal. I won't have time 
to do this now, so cc'ing Petr.


I'm not sure where to add this information. I see the Change as full of 
clear explanations of the above, but since I helped write it and know 
the technical details, it's hard for me to communicate this to people 
(especially those biased towards the view that we're breaking things 
without cause).


Could you help me out with a more concrete proposal on what to change in 
the text?




For reference:

# Abstract:

In Fedora's build system, only packages explicitly buildrequiring /usr/bin/python will get it. 


# Detailed description:

Packages that need /usr/bin/python to build will need to BuildRequire it. Packages that need /usr/bin/python to be used by users will need to Require it. In both cases, the packager should avoid the need and only fallback to (Build)Requiring /usr/bin/python as a temporary workaround. 


The new package will virtually provide python, ensuring that dnf install python will make the python command available. 


# Don't (Build)Require python-unversioned-command, but /usr/bin/python

If this change ever gets obsoleted, or for older Fedoras support, we ask the maintainers who fallback to (Build)Requiring /usr/bin/python, not to use the package name for the dependency, but the executable path instead. 


# Scope:


Maintainers of packages that use /usr/bin/python need to switch to using 
/usr/bin/python3 or /usr/bin/python2 explicitly (with help from Proposal owners 
if needed). [further instructions/recommendations follow]


# Upgrade/compatibility impact:


All packages that rely on /usr/bin/python need to change to /usr/bin/python2, 
or add explicit (Build)Requires.

Advanced users that don't install recommended packages by default will either have to install /usr/bin/python manually or live without it. Generally, the users should not be affected by this change. 


User Experience

Advanced users might uninstall the /usr/bin/python link if they want to. Others don't need to deal with this change. 



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

Re: F29 System Wide Change: Move /usr/bin/python into a separate package

[Petr Viktorin]

On 05/24/18 02:21, Orcan Ogetbil wrote:

On 23 May 2018 at 11:30, Brian C. Lane wrote:

as a user of python what do you expect
/usr/bin/pythong to do? You expect it to run the python2 interpreter.


Careful with the generalization. I expect /usr/bin/python to launch
python3 and I get surprised with each Fedora release why it still
keeps launching python2 after all these years.


Fedora follows [PEP 394], which is a result of much discussion across 
many distros and use cases.


[PEP 394]: https://www.python.org/dev/peps/pep-0394/

I don't blame you for expecting python3 instead, though :)


This change seems to be a move in the right direction (although I
would have preferred a more radical approach, like removing python2
from the distro altogether. It can be reintroduced in a later release
as a compat-python2 package)


I would also prefer what a more radical approach, and I did suggest it 
upstream. what ended up in the current PEP is a compromise.

The discussion/history is at https://github.com/python/peps/pull/630.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZOT7FZGKKM6U3LBQBV3I46UTBY6NMMDJ/

Re: Intent to orphan Python 2

[Petr Viktorin]

On 04/08/18 17:49, Kevin Kofler wrote:

Rex Dieter wrote:

And we've circled back to the original post starting this thread.

Note: intent to *orphan*, not intent to *retire*.


If it is not going to be retired, then why would we want to kill python2-*
subpackages throughout the distribution for no reason?


By orphaning, I mean:

1. Work with users and maintainers of dependent packages to either 
remove their dependencies or to share/take over maintainership

2. Drop the package if no one stepped up

This is the first step.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Petr Viktorin]

On 04/04/18 18:21, James Hogarth wrote:
[...]

Can we please get some consistency here?

I noted today that firewalld has dropped python2-firewall but of course 
ansible isn't switching to py3 for the controller (and therefore local) 
until F29 and not all python modules are py3 compatible yet... and of 
course we ship firewalld as our firewall in fedora.


This means that in F28 you can't just `yum  install ansible 
python-firewall` and do ansible localhost -m firewalld and have it work.


Worse is if you bump into a module not ported yet and then you have a 
split of python versions and playbooks required.


Is there some list of packages Ansible depends on?
I'd can to add the list to portingdb, so we could warn people about the 
implications of dropping subpackages. Currently we use RPM deps, so the 
needs of Ansible clients are invisible.


Naturally there's no technical reason to drop the library in F28 and 
there's no Change filed for it.


It's the maintainer's decision, as with any RPM.
Has anyone communicated to the firewalld maintainer that Ansible depends 
on the package? Again, a maintainer can't very well notice a "soft 
dependency", unless they use Ansible themselves.


We at least need a "common bugs" with all the python2-* libraries being 
dropped in F28 and really they shouldn't be going without a Change.

> For a "soft despondency" like firewalld I'd argue that it shouldn't drop
until F29 when ansible goes py3 by default (it has a Change filed to 
that effect).


To be clear I'm 100% comfortable with python2 being dropped in the 
proposed timescale... but let's do it sensibly and not have it surprise 
people.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Petr Viktorin]

On 03/24/18 15:28, Kevin Kofler wrote:

Petr Viktorin wrote:

As with any orphaning, that leaves two options:
- someone else agrees now to take over in 2020 (keeping in mind this is
a security-critical package and will be abandoned upstream), or


IMHO, this is clearly the right thing to do. I have been doing security
backports for qt3 and kdelibs3 for years, and now also qt 4 and kdelibs 4.
It is not an unreasonable amount of work, though to be very clear I will NOT
be the one to do this for Python 2, somebody experienced with and interested
in Python should do it.


And if you read the original mail to the end, you'll find that our 
position is not as black-and-white as it might look from the Subject line.
As Python SIG we maintain old Python versions like 2.6 or 3.3 *today* – 
but just for developers who need to test backwards compatibility of 
their upstream libraries; we don't want to see them used as a base for 
Fedora packages. Why? To make sure Fedora packages work with modern 
Python, and to have only one time-sensitive place to concentrate on when 
a critical security fix comes. We want to put Python 2.7 in the same 
situation.


Part of the reason to start dropping Python 2 packages now is to figure 
out which packages can do it now and which ones will need additional 
help or coordination in the next few years.


As I wrote in the beginning of the e-mail, we'd rather go out and change 
the packaging guidelines to say "please drop your unneeded python2 
subpackages, or let us drop them for you". (Note the word *unneeded*.) 
That would make a nice a simple message, and in effect it would give you 
the same options you have now.
But it turns out we can't say just that (for good reasons [0]), so we're 
explicitly mentioning your second option – "if you can manage the 
transition better, come and do it instead of us".
I doubt anyone can – Python SIG is, by definition, the people 
experienced with and interested in packaging Python in Fedora. And yes, 
we'll do our best to manage things, with cooperation with interested 
packagers.


There's of course a third option – if you don't want to take over 
*everything* but have ideas about how to do something better – 
respecting that if you're asking someone to do more work, they might (or 
might not) say no – then come over to Python SIG [1] and talk!


And let me mention this one explicitly: expecting us to maintain Python 
2 *is* implicitly asking us to do work. It's not necessarily bad per se, 
but don't complain if we ask you to do some work in return.

We'll be glad to help anyone who respects that.


[0] https://pagure.io/packaging-committee/issue/753
[1] https://fedoraproject.org/wiki/SIGs/Python



Especially for the first couple years, it will be possible to just borrow
fixes from other distros, in particular RHEL/CentOS. As was pointed out
elsewhere in this thread, EL7 ships Python 2.7 and should be supported until
2024. (That said, RHEL typically only fixes the really critical issues. My
experience with qt3 and kdelibs3 is that RHEL was not always proactive in
backporting security fixes and sometimes even ended up picking up my Fedora
fix, weeks later. But there are also other distros around.)

 Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Intent to orphan Python 2

[Petr Viktorin]

tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need 
to start dropping python2 packages now.



Python 2.7 will reach end of upstream support on 1st of January, 2020, 
after almost 10 years (!) of volunteer maintenance.


Fedora still has more than 3000 packages depending on python2 – many 
more than we can support without upstream help.
We (rightly) don't have the authority to say "please drop your unneeded 
python2 subpackages, or let us drop them for you" [0].
The next best thing we *can* say is: "if Fedora is to keep python2 
alive, we won't be the ones doing it – at least not at the current 
magnitude".

Here are the details.


The current maintainers of python2 would like to "orphan" the python2 
package in 2020 (~ Fedora 30):

- Charalampos Stratakis (cstratak)
- Tomáš Orsava (torsava)
- Miro Hrnočok (churchyard)
- Petr Viktorin (pviktori)
- Iryna Schcherbina (ishcherb)
- Michal Cyprian (mcyprian)
- Bohuslav Kabrda (bkabrda)
- David Malcolm (dmalcolm)
- Thomas Spura (tomspur)

As with any orphaning, that leaves two options:
- someone else agrees now to take over in 2020 (keeping in mind this is 
a security-critical package and will be abandoned upstream), or

- dependent packages drop support for Python 2.

Unlike most other orphanings, we have some thousands of dependent 
packages, so a lot of time and care is required.
In case no one steps up, we'd like to start dropping Python 2 support 
from dependent packages *now*, starting with ported libraries on whose 
python2 version nothing in Fedora depends. (We keep a list of those at [1].)
Of course, we're ready to make various compromises with interested 
packagers, as long as there's an understanding that we won't just 
support python2 forever.


If you are a maintainer of anything at [1] we ask you kindly to consider 
removing the python2 subpackages.
You can either do it now in Rawhide, or add a conditional for Fedora > 
29. (On the current schedule, Fedora 30 will be the first release still 
supported after 2020-01-01.)


If no one steps up to maintain python2 after 2020, we're prepared to 
package a "legacy" python27 package, similar to what we do for e.g. 
python33 [2], to:

- help developers that still need to test against this version
- support exceptionally important non–security critical applications, if 
their upstreams don't manage to port to Python 3 in time




[0] https://pagure.io/packaging-committee/issue/753
[1] http://fedora.portingdb.xyz/#legacy-leaf
[2] https://src.fedoraproject.org/rpms/python33/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Petr Viktorin]

On 02/15/2018 10:17 AM, Michal Novotny wrote:
I feel PRs are better for this sort of stuff. Mainly because people are 
informed why exactly this change is made,
they can read the guidelines and then merge the change when they are 
sure they understand it. It helps spreading knowledge
and keeping community involved. Python team did it very well in their 
"Fedora's Switch to Python 3 effort 
<https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3>", i think.


Yeah, well, I definitely agree that's how it should be done, but... did 
you see the script that handles the automatic pull requests? (If not, 
the first half is here: https://pagure.io/python-fixrequires, and the 
second half -- merging -- is not yet automated.)


Pagure's API around automatically creating and administering Pull 
Requests is, not yet useful enough. Selenium kinda works as a 
workaround. But I wouldn't recommend it, unless one of your goals is to 
find the issues, so this can eventually become the preferred workflow. 
(See e.g. https://pagure.io/pagure/issue/2803)


(Disclaimer: I'm not the one actually doing the work, I just heard the 
complaints...)



Maybe it would be nice if proven packagers had some tooling for doing 
those changes.


tl;dr: It's possible, people are slowly working on it, but it's not 
generally usable yet.



--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 strange rpmbuild failure

[Petr Viktorin]

On 02/04/2018 10:08 PM, Alec Leamas wrote:



On 04/02/18 21:36, Steve Grubb wrote:

On Sunday, February 4, 2018 2:29:26 PM EST Alec Leamas wrote:



Many questions here, and a large package. Still, searching the logs I
cannot see any python files - are there any such at all?


None at all. Its all java, javascript, R, and ELF files.


If not, perhaps  you could disable the byte compulation as described in
[1]?


Bingo! That fixed the build...which leads to the question of why is that
failing?


I think the basic answer is that the byte comoilation script is using
all sorts of strange heuristics. It seems that it determined a that a
non-python file was python.

Efforts are under way to redefine things and make the byte compilation
more explicit. Until this is done, this is probably not the last error
of this sort.

In other words, it's sort of a known bug with fixes under way, slowly...


I'd like to make sure any Python-related automation is limited to Python 
context (/usr/lib*/python*, files with python shebangs, etc.). I'm not 
sure why it's not this way now.


We're preparing a Change to fix this exact issue in Fedora 29. Started 
just last week, actually:

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

Up to this point I thought this was just a theoretical issue. Thank you 
for finding a concrete example -- and sorry it had to be you!



--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Ambiguous python version in waf

[Petr Viktorin]

On 02/05/2018 12:47 PM, Guido Aulisi wrote:

2018-02-05 12:00 GMT+01:00 Petr Viktorin :

On 02/05/2018 09:32 AM, Guido Aulisi wrote:


Hi,
according to latest python guides, we should avoid calling generic
unversioned python command

(https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build#Quick_Opt-Out)

But what should we do if it's called inside waf? waf is provided
upstream, should we patch it to call either python2 or python3, or use
PYTHON_DISALLOW_AMBIGUOUS_VERSION=0?

I got this problem in recent ardour5 rawhide builds
(https://apps.fedoraproject.org/koschei/package/ardour5?collection=f28).
Now I'm seeing that builds are back to normal and python2 has been
downgraded.

Thanks



Thanks for the question, and sorry for the inconvenience!

The python2 message is, so far, only a warning. I see the log contains a
different error: "--freedesktop requires itstool > 2.0.0 to translate
files.".
Could you check if that's not causing the failure?


I found that the check for itstool fails because it gets the
deprecation warning as input, there's a mistake in
output = subprocess.Popen("itstool --version", shell=True,
stderr=subprocess.STDOUT,
stdout=subprocess.PIPE).communicate()[0].splitlines()
stderr is redirected to stdout, so itstool gets DEPRECATION and
version [u'WARNING:']
I will report this upstream, it seems to me that the redirection of
stderr is a mistake.


Ah! I see the problem now: /usr/bin/itstool has a /usr/bin/python 
shebang. I've filed a pull request that should fix this:

https://src.fedoraproject.org/rpms/itstool/pull-request/1


[...]


It looks like waf will be one of the tougher things to figure out. After the
mass rebuild we'll see the effect on the whole distribution, and hopefully
come up with a better strategy for bundled waf.


I will file a bug for waf, if it's the correct thing to do.


If you can wait a bit until itstool maintainers merge the PR, that 
should sort the problem out.

Let me know if you need this soon, I can look for a provenpackager.


--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Ambiguous python version in waf

[Petr Viktorin]

On 02/05/2018 09:32 AM, Guido Aulisi wrote:

Hi,
according to latest python guides, we should avoid calling generic
unversioned python command
(https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build#Quick_Opt-Out)

But what should we do if it's called inside waf? waf is provided
upstream, should we patch it to call either python2 or python3, or use
PYTHON_DISALLOW_AMBIGUOUS_VERSION=0?

I got this problem in recent ardour5 rawhide builds
(https://apps.fedoraproject.org/koschei/package/ardour5?collection=f28).
Now I'm seeing that builds are back to normal and python2 has been downgraded.

Thanks


Thanks for the question, and sorry for the inconvenience!

The python2 message is, so far, only a warning. I see the log contains a 
different error: "--freedesktop requires itstool > 2.0.0 to translate 
files.".

Could you check if that's not causing the failure?

If the python2 message is breaking your build, then please file a bug 
and set an environment variable, as described in the Change. (Do file 
the bug, though – that ensures we'll contact you before we remove the 
workaround.)



Background:

We do want everyone to avoid calling /usr/bin/python, but we realize 
it's not always easy. That's why we added the warning -- it will allow 
us to grep the logs to figure out what is using it (and why). And of 
course, in simple cases it can be fixed right away.
Some tools do fail if there's extra output on stderr; that's the reason 
for the "Quick Opt-Out" workaround.


It looks like waf will be one of the tougher things to figure out. After 
the mass rebuild we'll see the effect on the whole distribution, and 
hopefully come up with a better strategy for bundled waf.



--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[OT] Octal number syntax (Was: Please stop re-adding gtk-update-icon-cache scriptlets)

[Petr Viktorin]

On 01/20/2018 06:08 AM, Chris Adams wrote:

Once upon a time, Nico Kadel-Garcia  said:

I don't see any modern scripting language where a leading 0 would lead
to interpreting a number as octal.


I suggest you check again; I don't see any where a leading 0 does NOT
lead to interpreting a number as octal  Here are a few common scripting
languages (just what I have installed):

$ python -c 'print(010 + 1)'
9


Fedora's /usr/bin/python is not a modern scripting language, but a 
7-years-old one with even older historical baggage. We're working on 
fixing that, but there are serious backwards compatibility issues :) 


Generally, the movement is away from leading 0 meaning octal.
Current Python does not allow this. It was removed exactly because it 
was "extremely easy to inadvertently [specify] the wrong value" [0], 
especially for people without a C/Unix background.
Instead, there's the explicit "0o" prefix, which also works in Python 2, 
Ruby, JavaScript (ES6), Perl 6, ... even Rust. An you're likely to see 
style guides and linters warning against leading 0 in languages that 
keep it.


You could say RPM is ahead of its time here!


[0]: https://www.python.org/dev/peps/pep-3127/#motivation


--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly

[Petr Viktorin]

On 01/17/2018 12:38 PM, Richard W.M. Jones wrote:

On Thu, Jan 11, 2018 at 01:02:32PM -0800, Troy Dawson wrote:

Hello,
Python3 will be in the next major RHEL release.  I don't mean RHEL
7.6, but with numbers higher than 7.
There are many, many packages with something like the following

   if 0%{?fedora}
%define with_python3 1
   %endif

If you have something like that, please change it to something like this.

   if 0%{?fedora} || 0%{?rhel} > 7
%define with_python3 1
   %endif


I'll say it once again, but why can't we just have
%{python2_available} and %{python3_available} macros defined in the
base system?


Mostly because we can't change RHEL.

So, how about %{python2_missing} and %{python3_available}? Is that too 
ugly and inconsistent?



--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 Self Contained Change: Avoid /usr/bin/python in RPM build

[Petr Viktorin]

On 01/10/2018 09:33 AM, Miro Hrončok wrote:

On 10.1.2018 03:16, Nick Coghlan wrote:
On 10 January 2018 at 11:30, Jason L Tibbitts III  
wrote:

In the end I just can't shake the notion that it's bad to have some
random non-python-related environment variable basically breaking
python.


Aye, I think you've hit on the main problem: if this is keyed off
RPM_BUILD_ROOT, then it will impact all RPM builds that use a Fedora
provided Python, even if those builds aren't otherwise required to
abide by Fedora's policy settings.

With a dedicated environment variable instead, that could look 
something like:


 PYTHON_DISALLOW_AMBIGUOUS_VERSION=0 # Status quo
 PYTHON_DISALLOW_AMBIGUOUS_VERSION=1 # Hard failure
 PYTHON_DISALLOW_AMBIGUOUS_VERSION=warn # Deprecation warning


This sounds good to me. It didn't occur to me that we can actually set a 
dedicated env vars for our builds (which is even better).


+1, let's do that!


This would potentially even make it possible to push this patch to 
upstream. >

Then either Koji can take care of setting that (and including it in
the mock configs it generates), or else it can be included in some of
the Fedora specific RPM setup.

Cheers,
Nick.

P.S. Using a dedicated environment variable would have the advantage
of allowing anyone else that *also* wanted to look for and remove
unqualified references to Python 2 to set it.






--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Django 2.0 released, and what it means to you

[Petr Viktorin]

On 12/05/2017 09:19 AM, Matthias Runge wrote:

Hello,

tl;dr if you're not maintaining/using a Django related package,
you can safely skip this message.


Django 2.0 was released quite recently. While it is mostly compatible with
earlier versions, the SIGNIFICANT change is, to drop support for Python 2.

I'm intending to update Django in Rawhide to 2.0 in 2 weeks. If you're
maintaining a package depending on Django, please make sure to disable
the python2 subpackage. Please keep in mind, you'll also need proper
obsoletes.

If there is any bug, blocker, whatever connected to this change,
please make also sure to report it in bugzilla and
make your bug a blocker for[1].


Hi,
Another option is to create a new "python2-django" package containing 
the latest Django 1.x code (which is still supported upstream as LTS). 
That would mean dependent packages would have until April 2020 to drop 
Python 2.

If that would help, let me know and I'll package it.


--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: ENOTIME

[Petr Viktorin]

On 07/20/2017 05:04 PM, Orion Poplawski wrote:

My workload at $dayjob$ has increased significantly so I'm afraid I have much
less time to devote to packaging work.  Now more than ever I could use help
maintaining my packages (listed below).  If you are interested, please add
yourself as co-maintainers in pkgdb.  Thanks!


Hello Orion!
Sorry for the late reply; I'm behind in my e-mails.

First of all, thank you very much for all your work! I knew you 
maintained a lot of Python packages, but seeing the whole list is very 
impressive.


Would you like to hand over (some of) your Python packages to the Python 
SIG?
Pagure doesn't allow groups as package owners, but I hope I can 
represent Python SIG here, at least for administrative tasks. (Among 
other things, I lead Red Hat's python-maint team, which includes many 
active Python SIGgers.)
If you add me as admin, I'll add Python SIG to the committers list, try 
to search for contributors, and handle any emergencies. (I can't promise 
we'll handle day-to-day packaging for all the packages, but some of them 
are interesting to me presonally.)


Unfortunately, in Pagure I can't request access for myself. But if you 
agree, I can file ticket with a Fedora infra for some kind of mass update.


Python packages where you're an admin seem to be:

netcdf4-python
oct2spec
pyhoca-cli
pyhoca-gui
pymongo
python-AppTools
python-Traits
python-backports_abc
python-clyent
python-cytoolz
python-ecdsa
python-envisage
python-gflags
python-google-apputils
python-iptools
python-ipython_genutils
python-jupyter_core
python-locket
python-nbformat
python-numpydoc
python-optcomplete
python-pamela
python-pkgconfig
python-process-tests
python-pycosat
python-pyface
python-pytest-cache
python-pytest-cov
python-pytest-flakes
python-pytest-pep8
python-rpm-macros
python-scp
python-setuptools_scm
python-sphinx-gallery
python-sphinxcontrib-issuetracker
python-spur
python-terminado
python-toolz
python-traitlets
python-traitsui
python-workerpool
python-x2go
python3-Cython
python3-PyYAML
python3-coverage
python3-dbus
python3-decorator
python3-docutils
python3-idna
python3-jinja2
python3-markupsafe
python3-netaddr
python3-netifaces
python3-nose
python3-numpy
python3-ply
python3-py
python3-pycparser
python3-pycurl
python3-pygments
python3-pytest
python3-pytz
python3-requests
python3-scipy
python3-setuptools
python3-six
python3-sqlalchemy
python3-suds
python3-tornado
python3-urllib3

--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass package change (python2- binary package renaming)

[Petr Viktorin]

On 08/10/2017 04:52 AM, Scott Talbert wrote:

On Tue, 8 Aug 2017, Zbigniew Jędrzejewski-Szmek wrote:


Hello Fedora Python package maintainers!

This is an announcement of a mass package renaming:
Python 2 binary packages will be renamed to python2-*.

This will happen soon after the F27 branching on August 15th.


Currently ~1330 source packages already generate a binary package with
the python2- prefix, and 835 remain to be updated. The spec files for
approximately 740 packages will be renamed, and 95 will be left for
fixing by maintainers or proven packagers.

[...]
Where did your list of 'all python packages' come from?  I fear that 
there are some missing because wxPython should be in there.


I'll plan on fixing wxPython myself, but you may want to look into why 
it wasn't on the list as there may be others.


Thanks for noticing!

Unfortunately, I don't know of a good way to automatically tell if a 
package contains a Python module, or if it's an application that just 
happens to use Python.
So, if a package doesn't have an unqalified "python-" prefix (or 
postfix), it doesn't end up on the autogenerated list, and needs to be 
added manually.

Ideas for better heuristics are welcome :)

--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposed Mass Bug Filing: Renaming "python-" binary packages to "python2-"

[Petr Viktorin]

On 06/29/2017 11:12 AM, Peter Robinson wrote:

On Thu, Jun 29, 2017 at 2:39 AM, Adam Williamson
 wrote:

On Wed, 2017-06-28 at 16:21 +0200, Iryna Shcherbina wrote:

2) Using `python-` instead of `python2-` in the dependencies for the
Python 2 binary RPM [2].


I'm not sure this list is terribly useful, because of the above. There
are thousands of packages that do this, because the 'python2-' provide
is not available on some older Fedora release, or on EPEL (and the
package is maintained for EPEL as well as Fedora). Sprinkling "if (some
release number condition) then Requires: python2-foo else Requires:
python-foo" all over your spec is a giant PITA and I for one am not
very interested in doing it.

IMHO, if there is going to be some kind of requirement that all Python
requires be explicitly versioned, there needs to be a co-ordinated
effort to make sure the versioned Provides are available across at
least EL6, EL7, and all supported Fedora releases *first*.


I completely agree with Adam's sentiment here and think this is a
giant waste of time for a little bit of vanity. It's prone to errors.
I've seen and fixed numerous issues where maintainers just blanket
change/build/push without doing proper provides/obsoletes and break
things on stable releases and EL.

Most packagers have enough problems with workload without piling on a
bunch of extra unnecessary vanity bollocks that provides absolutely
ZERO value.


Sorry that all this looks useless to you!

Let me try to explain the situation:
Python 2.7 has 10-year upstream support. That's as much as enterprise 
Linux distributions, but coming from a community of volunteers, who are 
getting tired and want to move on.
That support will end in 2020. That's when the current Fedora 
maintainers of Python 2.7 plan to orphan it.
Since lots of packages Fedora depend on Python, we want to make sure 
these packages have:

- fair warning that py2 is going away
- a chance to move over as gracefully as possible.

You're free to not act on these warnings and suggestions -- all that'll 
happen is your package will have a missing dependency in a few years.


If you have a better way to manage this, please let us know!


--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposed Mass Bug Filing: Renaming "python-" binary packages to "python2-"

[Petr Viktorin]

On 06/29/2017 04:20 AM, Adam Williamson wrote:

On Thu, 2017-06-29 at 12:11 +1000, Nick Coghlan wrote:

On 29 June 2017 at 11:39, Adam Williamson  wrote:

On Wed, 2017-06-28 at 16:21 +0200, Iryna Shcherbina wrote:

2) Using `python-` instead of `python2-` in the dependencies for the
Python 2 binary RPM [2].


I'm not sure this list is terribly useful, because of the above. There
are thousands of packages that do this, because the 'python2-' provide
is not available on some older Fedora release, or on EPEL (and the
package is maintained for EPEL as well as Fedora). Sprinkling "if (some
release number condition) then Requires: python2-foo else Requires:
python-foo" all over your spec is a giant PITA and I for one am not
very interested in doing it.

IMHO, if there is going to be some kind of requirement that all Python
requires be explicitly versioned, there needs to be a co-ordinated
effort to make sure the versioned Provides are available across at
least EL6, EL7, and all supported Fedora releases *first*.


This was the key concern I raised in response to the initial email,
and our conclusion at the time was:

1. This case does need to be addressed
2. Adding an opaque dependency on buildroot configuration settings
wouldn't be a particularly nice way to handle it, since it forces
every package to switch concurrently, rather than each maintainer
getting to decide when to move from the Python 2 stack to the Python 3
stack for themselves (and that unilateral shift is already going to
happen for unqualified dependency declarations when the virtual
%python_provides macro moves from the Python 2 stack to the Python 3
stack)
3. Ideally, the recommended approach would work for arbitrary RHEL &
CentOS based buildroots, not just those with the EPEL RPM macros
available

The most straightforward solution we came up with was for affected
packages to define their own "%py_prefix" macro that selects the stack
they want to use based on the Python version:

```
# The block below would become the conventional
# "Python stack compatibility" dance for
# EL6, EL7, and Fedora
# Each package can decide for itself which version of
# Fedora had a sufficiently complete Py3 stack for
# them to be able to switch over

# Current EL releases & older Fedora use "python-*"
%if 0%{?el6} || 0%{?el7} || 0%{?fedora} < 25
%define py_prefix python
%if 0%{?el6} || 0%{?el7}
BuildRequires: python-devel
%else
BuildRequires: python2-devel
%endif
%else
# Newer Fedora releases use "pythonX-*"
# A Py2-only project would use "python2" here
%define py_prefix python3
BuildRequires: python3-devel
%endif


# Dependency declarations use stack selected above
BuildRequires: %{py_prefix}-builddep1
BuildRequires: %{py_prefix}-builddep2
Requires: %{py_prefix}-runtimedep1
Requires: %{py_prefix}-runtimedep2
```


Erf, well, that seems kinda icky but manageable. Is it really better
than just coming up with some kind of script to at least add the
appropriate "Provides: python2-foo" to all packages (or at least a
large subset of the most commonly-used packages) in EL6/EL7/F24,
though? I mean, that doesn't seem beyond the bounds of possibility, to
just find everything that provides 'python-foo' and make it also
provide 'python2-foo'...


Adding python2-foo is the second half of this proposal.
We don't want to do that by *just* adding "Provides: python2-foo" to all 
packages, because if everyone did that, we'd need to ask them to change 
again in a few years.


Would it be reasonable to do this in phases: first ask everyone to add 
python2- provides, then ask everyone to use them? Yes, and in fact, we 
already did that: the python2- prefix has been recommended in the 
guidelines for a quite a long time. But many packagers won't do the 
change until it starts being necessary.


Rebuilding lots of packages in EL6 is practically impossible, actually.
However, some subset of commonly-used packages do have the python2- 
prefixed provides even in EL6. The very example above is misleading: 
EL6's packages do provide python2-devel.



--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposed Mass Bug Filing: Renaming "python-" binary packages to "python2-"

[Petr Viktorin]

On 06/20/2017 05:54 PM, Jason L Tibbitts III wrote:

"IS" == Iryna Shcherbina  writes:


IS> The packages that violate the above-mentioned policies are being
IS> tracked in portingdb [3] and we plan to start filling bugs soon.

Before doing that, please post a list of packages and their maintainers
to the devel list.  Preferably you would post two lists: one in the
form:

packageowner1 owner2 owner2

And another in the form

owner  package1 package2 package3

This makes it easy for packagers to trivially see if they have any work
to do without having to wrestle with what could potentially be a large
number of bugzilla tickets which are more annoying than useful.

The message with these lists should also include reasonably complete
information about what they need to do.  Not just a pile of links,
though you should of course include links in case someone wants to read
further.

IS> Since that's a lot of bugs to file (more than 1000) , we
IS> encourage all maintainers to fix the packages they maintain.

That will go faster if you don't waste people's time filing a load bugs
and instead give people at least a couple of weeks to see their name on
a list and get things fixed up.

A few extra minutes spent generating a useful and complete report can
save a lot of time for busy packagers and potentially save some ill will
as well.


Noted.
I think this advice should be added to the wiki [0], as it really 
applies to all mass bug filings.

Iryna, could you draft a change?

Another strategy we'll be using is not filing all the bugs at once: the 
plan is to file a few at first and learn from the reactions before doing 
the next wave.



[0] https://fedoraproject.org/wiki/Mass_bug_filing

--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Self-introduction

[Petr Viktorin]

On 03/01/2017 12:39 PM, Artem Goncharov wrote:

Hello everyone,

My name is Artem and I would like to join the python-devel group.

I am a Software/Solution architect with experience in Telecom and
databases. Due to the work I never had a change to participate actively
in OS development activities, but since FC4 I am with Fedora and always
do try to test Betas on all of my workstations. So in this or other way
I am a long running contributor to Fedora community. Now the time came,
when I would participate more actively to get a different experience.

Python is just another language on my skills list. But since I have
started with it relatively recently I would like to deepen my knowledge
while doing something useful for the community.

I have started supporting Python3 port activities (reviews are still
pending ;-), but that is definitely not the only thing I will be able to
bring. I would be glad if someone will be able to review my specs and
point on problems to start bringing use sooner.


Welcome!

Could you add a link to the specs here, if you've filed bugs already? 
There's quite a large backlog of Python packages that reviewers need to 
go through, but writing here could maybe make things faster :)


Packaging/reviews is probably the best way to get into Fedora 
contributions. If you watch this list, you should see what people are 
working on, and hopefully find other opportunities to get involved.


If you need any help, be sure to let us know!


--
Petr Viktorin
___
python-devel mailing list -- python-de...@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: F26 Self Contained Change: Making sudo pip Safe (Again)

[Petr Viktorin]

On 02/07/2017 01:22 PM, Mathieu Bridon wrote:

On Tue, 2017-02-07 at 13:08 +0100, Vít Ondruch wrote:

Dne 7.2.2017 v 11:32 Michal Cyprian napsal(a):

Ruby on Fedora uses /usr/local/share/gems/ for packages installed
as a root via gem tool for many years.


Since you refer to Ruby, I just want to highlight that
/usr/local/share/gems/ is for packages installed by *root* via gem
too (as you correctly said) [1]. We assume that root manages the
entire system and wants installed packages to be available system
wide. I don't expect this is widely used practice. Typical user
installed packages goes into $HOME/.gem. Is there any location
similar to this?


Yes, under ~/.local/lib/

It's what you get with `pip install --user $module`.


As far as I know, our users very appreciate the possibility to do
"gem install" without administrator privileges.


So do Python developers. It's very commonly used.

But even more common is to use virtual environments, one per
application.

---

I strongly feel this feature is a move in the wrong direction. I've
never met a Python developer (and I'm one myself) installing modules
system-wide with Pip. It seems to me the only people doing that are
people who follow bad documentations.


Well, I've met some that are writing the bad documentation. Their 
rationale was that pip's --user option doesn't work on Ubuntu, so they 
don't have many options. (This might have been fixed since, but old 
versions are still around.)


And, not just Python developers are installing software distributed over 
PyPI.



IMHO a much better (and simpler) way to fix the (very real) issue of
unsuspecting users damaging their systems would be for pip to refuse to
run with root permissions.


I wouldn't say it's simpler, unless you also want to disable `sudo pip 
--user`.


I believe that a proper fix, which includes making --user the default, 
is planned upstream.



--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: including EOL and vulnerable software in Fedora

[Petr Viktorin]

On 10/10/2016 06:18 PM, Kevin Kofler wrote:

Charalampos Stratakis wrote:

tox is THE main reason for multiple interpreters in Fedora.

So no the comments are not contradictory but it seems there is a lack of
(technical) understanding of the actual situation here, but I may be wrong
here, so please correct me if you think so.

tox is not just any package, so maybe it is not stressed out I guess from
the original descriptions.


If no package is allowed to require the old Pythons (and IMHO, "Recommends:"
is "require"),


This is the source of the apparent contradiction. For me, "Recommends" 
and "Requires" are two different things. "Requires" means that the 
dependency is required for proper operation. In this case, that would 
usually mean the library is built for a particular version of Python.
"Recommends" means that people usually want to install the packages 
together. Specifically, "tox" is a tool for testing Python code across 
multiple Python versions. Without a few different interpreters, it would 
be useless, but no single interpreter is required for it. And since many 
people use it to test across various versions, it makes sense to install 
those by default.




that also applies to tox. If tox is allowed to recommend the
old Pythons, that invalidates the claim that they will never be dragged in
as dependencies.


Sorry for the brevity in that claim. The old Pythons should not being 
dragged in as deps, *except* for development tools specifically meant 
for testing on alternate Pythons, where "alternate" almost always means 
"old".



In an earlier mail:
On 10/10/2016 04:14 PM, Kevin Kofler wrote:

Petr Viktorin wrote:

I would also like to point out that if you have these suffixed Python
versions installed, some build scripts may be accidentally picking up
those instead of the recommended default versions of Python.


Do you mean Fedora build scripts here?


I mean build scripts in upstream tarballs, which can also end up in our
packages (and cause problems when building outside of mock), but which can
also be used directly by people.



Okay, let's go back to the use case here: a developer wants to test on 
various versions of Python. If that's not the case, they wouldn't 
install tox, since tox is a tool that only tests code on various 
versions of Python.


The alternative to packaging those Pythons in Fedora is putting them in 
some COPR. I believe this would send a bad message. If we want to make 
Fedora friendly for Python developers, we should make cross-version 
testing officially supported, and as easy as possible. "Bring your own 
Python from somewhere" does not give Fedora any advantage over any other OS.
But either way, main repos or COPR, if a developer wants to test against 
multiple Pythons and follows the recommended steps, the old Pythons 
might get picked up by build scripts. I don't see an alternative that 
would prevent this.



The alternative to Recommending lots of Python versions from Tox is 
letting people install them manually. This, again, makes the experience 
worse – people just want to start testing, and we want them to be able 
to do that by just installing the testing tool and running it.




--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: including EOL and vulnerable software in Fedora

[Petr Viktorin]

I'd like to apologize for the wording "No security fixes will be 
applied". It was meant as a warning to users who might install the 
package without knowing what it is for, not as a declaration that we 
won't maintain the package properly.


The "python26" package is meant to provide just that -- Python 2.6, as 
it was released and as it is present in various old environments. People 
that develop backwards-compatible libraries need to test against this 
version, and to make Fedora compelling for those developers, we want to 
make it as easy as possible to test the backwards compatibility.


This version is no longer supported upstream, so there aren't many eyes 
on it. It shouldn't be held to the same standards as the current Python 
versions, but since it is still in use, bugs still sometimes get found 
and security fixes will get applied. We do intend to maintain the 
package according to Fedora standards -- as far as there are standards 
for packages with inactive upstreams.


This conversation builds on discussions all the way back to Flock, and 
some details were elided or worded inappropriately in the recent 
messages. I'd like to invite everyone to take a deep breath, try to 
understand the intent, and ask for clarifications rather than forming 
assumptions.




--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: including EOL and vulnerable software in Fedora

[Petr Viktorin]

On 10/09/2016 05:39 PM, Kevin Kofler wrote:

Nick Coghlan wrote:

They're not unnecessary for Python developers, as if you want to make
sure you're not accidentally using any features from later versions of
Python, the only way to reliably check that is to actually test your
code on those older versions. Tools like "tox" make that relatively
easy to do, but you still need a straightforward way to get hold of
the old runtimes for tox to use. The addition of these packages to
Fedora means that as soon as you do "dnf install tox", those runtimes
are all brought in automatically via Recommends, rather than having to
jump through multiple hoops to reconfigure your local package
management.


That contradicts churchyard's claim in the FESCo tracker:
| These packages are not intended to be used as dependencies for other
| packages (such as we have some "compat" packages when another package
| needs an older version of a library), hence we want to stop people from
| requiring them, see ​https://fedorahosted.org/fpc/ticket/650 - as a result
| no software in Fedora will ever run on those.


Indeed, there's a disconnect here. The old Pythons are intended for 
*upstream* development/testing.


If you're developing for Fedora, the old Pythons are not for you.
They're for people who are developing cross-platform libraries, which 
for some reason need backwards compatibility: usually for deployment 
elsewhere (old RHEL, old Debian – I've even seen people that need an old 
Python for Symbian phones, though that's older than we can support in 
Fedora).
And if you're developing a cross-platform library, you don't *want* your 
dependencies to come form RPMs. They need to be installable from PyPI 
(the Python-specific package repository) so you can use them on any distro.
So, the older Pythons should come with virtualenv & Pip, but a RPM 
ecosystem around them would be useless.


The people this is for want to develop compatible libraries for Python. 
They don't really care for the OS underneath. But having the old Pythons 
easily installable provides an incentive for them to choose Fedora.


The resulting upstream libraries can then be packaged as RPMs with 
Fedora's normal Python.




I would also like to point out that if you have these suffixed Python
versions installed, some build scripts may be accidentally picking up those
instead of the recommended default versions of Python.


Do you mean Fedora build scripts here?


--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F24 Self Contained Change: System Python

[Petr Viktorin]

On 02/10/2016 07:35 PM, Josh Boyer wrote:
> On Wed, Feb 10, 2016 at 1:26 PM, Bill Nottingham  wrote:
>> Miro Hrončok (mhron...@redhat.com) said:
>>> I had this in mind as well, but currently, this is not the part of the
>>> change. Once we need this and we have system-python, we can propose a
>>> system wide change that system-python is a different version.
>>
>> ... is the goal that the system-python is outside of $PATH and has a
>> non-standard $PYTHONPATH as well?  That would seem to be where this is
>> heading.

Having it outside $PATH is a good idea, I think. But $PYTHONPATH can be
shared (if the system-python version matches the /usr/bin/python3
version, which it should, at least most of the time).


-- 
Petr Viktorin
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 Self Contained Change: System Python

[Petr Viktorin]

On 02/09/2016 08:26 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Feb 08, 2016 at 08:27:53AM +0100, Jan Kurik wrote:
>> = Proposed Self Contained Change: System Python =
>> https://fedoraproject.org/wiki/Changes/System_Python
>>
>> Change owner(s):
>> * Miro Hrončok 
>> * Petr Viktorin
>> * Robert Kuska
>> * Charalampos Stratakis
>>
>> Separate several subpackages form the python3 packages - a
>> system-python(-libs) that can be required by various tools that
>> consider themselves "system tools".
> 
> The part of "Python" that can be usefully split is the standard
> library, and that's where most of the size and dependencies come in.
> In principle the python binary could be trimmed down, but it's small,
> and doesn't bring in any dependencies. The proposal doesn't state it
> clearly, so I assume you only want to split the stdlib
> (system-python-libs), and providing a separate system-python package
> with a separate binary is only a means to differentiate dependencies.

Indeed, the Python binary is very small, since it just calls python-libs.*
The binary needs to be separate to ensure /usr/bin/python? will always
refer to the full installation of Python**, and system-python is there
only for things that opt in.

> My first issue is that system-python{,-libs} is basically a
> subpackage, and should be called python-.

python- is also the naming scheme for Python libraries, which
this is not. So I don't think the naming is that clear-cut.

> And since debian
> calls it -minimal, so should we, to match existing
> expectations and increase cross-distro similarity.

That would also create the expectation that this is following Debian's
set of modules for python-minimal. While it's possible that we'll end up
with the same set, I don't want to lock us in.

> Second, why call it python-*, not python3-*? I think it'll
> be endlessly confusing to have both python*- (v3), python2-* (v2),
> and python3-* (v3) mixed in the same distro.

The assumption is that the basic system tools can agree on a single,
system-wide version of Python, and in case of a "Python 4" they can be
switched at once.
"python-*" is v2, by the way. This change adds "system-python" which is v3.

> My third issue is that packages will have a dependency on either
> system-python or normal python and this will a binary decision.
> Changing the list of things provided by system-python will be hard.
> If you add something to system-python, the only way to ensure that
> dependent packages can make use of it is to add a versioned dependencies
> on system-python. If you remove something from system-python, it will
> be necessary to go over all dependent packages and verify if they need
> the thing being removed or not. And if users' scripts start using
> system-python, it will impossible to remove anything, except maybe
> between Fedora releases.  This is very inflexible.

User scripts should not use system-python.
I now think the binary should be at /usr/libexec/system-python, to drive
that point home.

As for versioned dependencies, and removing things from a published
package -- that's how RPMs enerally work. I don't see a problem.

> As an alternative proposal, what about using an automatic dependency
> generator and having dependent packages require specific modules from
> the standard library. Those modules could then be moved between
> system-python-libs and python-libs, and things would just work™. I
> think that a separate system-python binary also wouldn't be needed.

That's a great idea, and I'm thinking along the same lines. But this
would have to be done upstream, with the wider Python community on board.
Especially with MicroPython gaining popularity, it would be great to
split the stdlib into individual chunks, record their interdependencies,
and say to library authors: "if you want to opt-in to be compatible with
minimal implementations of Python, specify which pieces of stdlib you
need, and make sure your dependencies do the same".

But, that's quite a long-term project. This Change is relatively small,
it should give us the immediate benefits, and if/when the full solution
is done it should be easy to switch to it.

> The scheme with automatic dependency generation could be implemented
> gradually, by introducing the automatic provides and dependencies
> generators, without removing current manual provides. Then when the
> generated dependencies seem to be right, removing manual dependencies.
> 
> Automatic dependency generation would benefit the whole ecosystem of
> Python packages in Fedora.

It would. It's also practically impossible to write such generators
correctly. (Please prove me wrong

Re: F24 Self Contained Change: System Python

[Petr Viktorin]

On 02/08/2016 02:13 PM, Jonathan Wakely wrote:
> On 08/02/16 08:27 +0100, Jan Kurik wrote:
>> python3 package to be split in several more subpackages:
>> * system-python-libs - a subset of standard Python library considered
>> essential to run "system tools" requiring Python
>> * system-python - /usr/bin/system-python binary (interpreter) for the
>> tools to be able to run, provides system-python(abi)
>> * python3-libs brings in the remaining subset of standard Python
>> library and will require system-python-libs, thus packages requiring
>> it (directly or indirectly) will get the entire standard Python
>> library
>> * python3 still requires python3-libs and provides python(abi)
>>
>> The term "system tool" in this context means any package where a
>> maintainer wishes to require system-python package instead of python3
>> package.
> 
> I'm not opposed to this change (I don't have an opinion) but this
> seems like an almost circular definition.
> 
> system-python-libs is defined as "whatever system tools want to use"
> and "system tools" are defined as "anything that uses system-python".
> 
> So I could create a package that uses system-python, but requires some
> large or obscure piece of the Python standard library, and then insist
> that it is added to system-python-libs. The definitions should prevent
> that.

Right, currently all we have is the circular definition.
The first step (listed under "Scope") is defining what
system-python-libs will contain. Once that's done, it'll be much harder
to add obscure libraries.


-- 
Petr Viktorin
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 Self Contained Change: System Python

[Petr Viktorin]

On 02/08/2016 09:21 AM, Neal Gompa wrote:
> On Mon, Feb 8, 2016 at 2:37 AM, Florian Weimer  wrote:
>> On 02/08/2016 08:27 AM, Jan Kurik wrote:
>>> = Proposed Self Contained Change: System Python =
>>> https://fedoraproject.org/wiki/Changes/System_Python
>>
>> Is this intended to mirror Debian's python-minimal?

Not necessarily, thought if the subset is similar we might re-use it.

>> What steps have been taken to accommodate Python upstream's wishes
>> against creating subsets of the standard distribution?  If I recall
>> correctly, this was a major point of discussion when Debian introduced
>> python-minimal.

The system-python is not a general-purpose Python interpreter. It should
only be called from programs that explicitly opt in to it.
Perhaps is should be /usr/libexec/system-python rather than
/usr/bin/system-python, to drive the idea home.

> This sounds like a really bad idea. How do we know what to expect is
> provided in a given Python package?

Part of the change is defining the exact subset. The idea is that it
should be small, to keep cloud images small for apps that don't use
Python themselves.

> We don't currently have anything
> that creates package-independent virtual Provides/Requires of Python
> modules that would cover the scope necessary to make this more
> effective.

Right. Every package using system-python would need to explicitly
disable the automatic Python requires, and add the system-python ones.

> Technically, there is one for independent Python module packages
> coming in RPM upstream that is currently disabled by default (in fact,
> I've got a pull request to improve it based on feedback from the
> Python SIG as well as Mageia[1]), but I don't think that is currently
> designed to handle the kind of complexity this is going to introduce.
> 
> How in the world would we handle such a dramatic departure from how we
> currently package Python?

It's a change designed for a few system tools that can accept the
limitations.  we can make Python-less containers and cloud images
smaller. Normal Python packages would be unaffected.
So I don't think it's a dramatic departure.


-- 
Petr Viktorin
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Proposed Mass Bug Filing: Python 3 Porting

[Petr Viktorin]

Hello!

According to the Python packaging guidelines [*], software must be
packaged for Python 3 if upstream supports it. I would like to start
filing some cookie-cutter bugs [**] where that's not the case, or where
there are some common problems with the Python 3 porting.

Some people have already started doing this, especially during the
Fedora Activity Day (FAD) [***], but some of the bugs filed could be
clearer. Hopefully, going through the mass bug filing procedure will
raise the quality of these bug reports, and provide a single place to
track them.
This also means I don't have a list of packages this mass filing applies
to: usually where the issue is known, a bug was already filed. But many
more are surely left to report. Rumor has it that the next FAD is
already being planned; it would be nice to be ready for mass filing at
least by then.

Several different issues related to this are appearing in the wild. I'd
like to put them all under this umbrella, and I'm including bug report
text for each one below.

[*] https://fedoraproject.org/wiki/Packaging:Python
[**] https://fedoraproject.org/wiki/Mass_bug_filing
[***] https://fedoraproject.org/wiki/FAD_Python_3_Porting_2015


Proposed "Python 3 Porting Tracking bug" description:

"""
Bugs related to the Python 3 porting effort are tracked here. These are:

* No py3 subpackage where upstream supports py3
* No python2-* or python-* Provides
* Requires on both py2 and py3 in one RPM

Mass bug filing was discussed in  and announced in 

Python packaging guidelines: https://fedoraproject.org/wiki/Packaging:Python
"""


Proposed child bug titles and texts:

1. : Provide a Python 3 subpackage

"""
Upstream, this software supports for Python 3. Please provide a Python 3
package for Fedora.


According to the Python packaging guidelines [0], software must be
packaged for Python 3 if upstream supports it.
The guidelines give detailed information on how to do this, and even
provide an example spec file [1].

The current best practice is to provide subpackages for the two Python
versions (called "Common SRPM" in the guidelines). Alternatively, if
nothing depends on your Python2 package, you can just switch to Python 3
entirely.

It's fine to do this in Rawhide only.


If anything is unclear, or if you need any kind of assistance with the
porting, you can ask on IRC (#fedora-python on Freenode), or reply here.
We'll be happy to help!


[0] https://fedoraproject.org/wiki/Packaging:Python
[1] https://fedoraproject.org/wiki/Packaging:Python#Example_common_spec_file
"""


2. : Missing "python2-" provide

"""
This package does not provide "python2-".

As per Python packaging guidelines [0], when there are two versions of
module "foo", the two packages must provide:
"python3-foo" for Python 3
"python2-foo" for Python 2
"python-foo" for the system default Python (currently 2, but this might
change in the future)

Please use the %python_provide macro [1] to specify the correct provides.

It's fine to do this in Rawhide only.


If anything is unclear, or if you need any kind of assistance with this
issue, you can ask on IRC (#fedora-python on Freenode), or reply here.
We'll be happy to help!


[0] https://fedoraproject.org/wiki/Packaging:Python
[1]
https://fedoraproject.org/wiki/Packaging:Python#The_.25python_provide_macro
"""


3. : Missing "python-" provide

(as for 2., s/python2-/python-/ where necessary)


4. :  requires both Python 2 and Python 3

"""
The  RPM requires both Python 2 and Python 3.

Except in very special circumstances, there is no need for one package
to drag in both Python stacks. Usually, this is a packaging error: for
example, a stray "/usr/bin/python" shebang in a Python 3 package can
introduce a Python 2 dependency.

Please split your package, or remove the stray dependencies.

It's fine to do this in Rawhide only.


If anything is unclear, or if you need any kind of assistance, you can
ask on IRC (#fedora-python on Freenode), or reply here. We'll be happy
to help investigating or fixing this issue!
"""


-- 
Petr Viktorin
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Filing Bugs for Python 3 Switch

[Petr Viktorin]

On 01/28/2015 06:08 PM, Dan Williams wrote:

On Wed, 2015-01-28 at 11:09 -0500, Bohuslav Kabrda wrote:

Hi,
I just filed 2 bugs [A], [B] for the Python 3 switch [C] and I realized that I 
should probably follow the mass bug filing policy.
As I've said previously, we've already had both Python 2 and Python 3 on LiveCDs for few 
releases, so it makes sense to move as much as possible to Python 3. My intention is to 
mass file bugs only for "applications" (see the second item in second list at 
[D]) - in short, these are packages for which it doesn't make sense to introduce python3- 
subpackage, but it only makes sense to rebuild them with Python 3.
The mass bug filing policy suggests providing text of the bug for review, so 
here it is:


Since your package requires Python and is considered an application as per [1], 
I'd like to ask you to rebuild it with Python 3. Please see recommendations and 
notes at [2]. Note: this switch should only be done assuming you need to do 
none or very little downstream patching of upstream source. If upstream source 
doesn't work with Python 3, it's ok to stay with Python 2.

Some general notes:
If your package depends on Python because of a Python script that has /usr/bin/python in hashbang, you need to change this to /usr/bin/python3. All "Requires" and 
"BuildRequires" on Python extension modules have to be changed from "python-foo" to "python3-foo" in order for this change to work. If your package 
is an "application" (let's call it "foo") and it also generates a subpackage with Python bindings (i.e. "python-foo" or "foo-python"), you 
should provide a python3 subpackage ("python3-foo" or "foo-python3") and use that as dependency of other subpackages.


How about "#!/usr/bin/env python"?  I don't recall who suggested this a
long time ago, but I'm 99% sure it was to better handle python3...


That does *not* handle Python 3 for you. In Fedora 22, /usr/bin/python 
will still point to Python 2 [0], so this would (normally) still call 
Python 2.


What /usr/bin/env does is take $PATH into account – for example if you 
have a virtualenv activated, it would use the python from that 
virtualenv. For applications that are installed as part of the system, 
this is almost never what you want.



[0] 
http://fedoraproject.org/wiki/Changes/Python_3_as_Default#User_Experience


--
Petr Viktorin

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Mozilla enabled ads in Firefox and they're active in Fedora

[Petr Viktorin]

On 11/20/2014 04:44 PM, Martin Stransky wrote:

On 11/20/2014 03:28 PM, Petr Viktorin wrote:

It's not about tracking per se – I'm fine with e.g. opt-in usage reports
that feed into research for making a better browser – that benefits me
(in a very indirect and miniscule way, but in the end the purpose is for
the *user's* benefit).
Ads are a feature that only benefits the upstream and the companies that
pay for the ads. From my (user's) perspective, there is no reason to
have them on my system. There is no benefit to me from this feature.
None at all. This is a major difference from Gnome search providers,
which I personally don't like either, but I can see how they might be
good for someone.


 From the user perspective Mozilla provides you a high-quality browser
for free (free as a beer). But they have to pay engineers for the work.


Every piece of Fedora is like that, and yet I don't see any other 
software doing useless-for-me opt-out tracking.
(Also, who am I paying? All authors of Firefox, or only the Mozilla 
employees?)



There are some other options there. To have free (basic) and paid
(extended) Firefox versions - Red Hat goes this way. Or direct donation
from users like Wikipedia. Mozilla chose the Ads way and you may or may
not accept it and you exactly know what's the (asked) price.


The question is, will *Fedora* accept it on my behalf?  Will Fedora no 
longer shield me from the ways of the Android developer?



That's still much better than Chrome where the price (user tracking) is
hidden and you can't disable it.


Well, you can – the Chromium source is out there. The only catch is that 
Chromium is not built primarily for users, but for the developers' benefit.



You can remove the Ads from Firefox by one click so no big deal here.
The same case is using Addblock to block Ads on Web. But you're giving
nothing back then.


Is there now an *obligation* to give back? Because there never has been 
such a thing.


I personally give quite a lot back, not to Mozilla specifically but to 
open-source community as a whole – but it's not because I have an 
obligation to do it nor because I'm forced to do it.
The recend trend of "open source" guiding me to become part of some 
monetization scheme saddens me.



Every user likes the best software for free (as a beer), but there isn't
any magic wand which makes it up for you.


The process which gave us Firefox so far seemed quite fine. I'm sure it 
was no easy wand-waving, but so far it has been for the user first.
Sure, Mozilla did not organize as many events or hire so many employees 
or get to dabble in the phone business. But the result is, so far, great.


I want my software to work for *me*; the free as in beer part is secondary.

--
Petr³

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Mozilla enabled ads in Firefox and they're active in Fedora

[Petr Viktorin]

On 11/20/2014 04:02 PM, Matthew Miller wrote:

On Thu, Nov 20, 2014 at 03:28:11PM +0100, Petr Viktorin wrote:

tl;dr: I think the line we should not cross is: including features
that don't benefit the user and may be considered harmful.


I don't think this is a very clear line. Should we drop all spreadsheet
applications?

http://www.velocityreviews.com/threads/spreadsheets-considered-harmful.717849/


Spreadsheet applications exist to benefit the user, so they don't cross 
this line.


(With a short-circuiting "and"¹, you won't even get to the "may be 
considered harmful" part in this case...)



--
Petr³

¹ http://en.wikipedia.org/wiki/Short-circuit_evaluation

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Mozilla enabled ads in Firefox and they're active in Fedora

[Petr Viktorin]

On 11/19/2014 09:11 AM, Benjamin Kerensa wrote:

Hello Free Software Friends,


I want to encourage the Fedora Community to think carefully about making
a switch
to another browser as the default in Fedora. I would not get hung up on
these tiles
(Ads) too much and remember they are necessary in order for Mozilla to
continue
building Firefox, Thunderbird, Seamonkey, Firefox OS and supporting the
very literally
hundreds of movements and thousands of events it does each year.

But that all aside I hope you will weigh whether the alternatives will
provider your users
any better of an experience in terms of Stability, Performance, Privacy
or Trust.

I think it will be difficult to find an alternative that offers what
Firefox does to your
users and frankly I think you will have a fair amount of users that will
be upset that
you switched the default on them. Sure they can still install Firefox
but the fact is
Fedora users come to expect Firefox to be the default much like they
expect Gnome
to be the default. (Also remember there are very likely thousands of
Mozilla Contributors that use Fedora)


In other words: you have achieved have vendor lock-in.
Congratulations! Good for you. Not so good for me.


Whatever your decision have a good release cycle and keep on building that
awesome free software!


Free software is, and always has been, about users. If something does 
not benefit the users should be able to switch away – where "something" 
is not whole applications, but individual *features* of applications.


Compare, for example, to the ad-ridden, spy-heavy, vendor-locked-in 
Android ecosystem, where users can't turn off unwanted features. Most 
software there is written to benefit the *developers*, not the *users*. 
Sure, it is more profitable for them that way, and the terms of some of 
those apps are even acceptable. But the fact that this model is finding 
its way into free software is worrying at best.


I think the line we should not cross is: including features that don't 
benefit the user and may be considered harmful. If I opt-in to ads – if 
you politely ask, and I, with mutual respect and understanding, agree to 
help your cause – then it's perfectly fine. (See vim's "Help kids in 
Uganda" message.) If you just quietly make money off me, or distract and 
annoy me until I have paid, then I can't and will not respect you.


It's not about tracking per se – I'm fine with e.g. opt-in usage reports 
that feed into research for making a better browser – that benefits me 
(in a very indirect and miniscule way, but in the end the purpose is for 
the *user's* benefit).
Ads are a feature that only benefits the upstream and the companies that 
pay for the ads. From my (user's) perspective, there is no reason to 
have them on my system. There is no benefit to me from this feature. 
None at all. This is a major difference from Gnome search providers, 
which I personally don't like either, but I can see how they might be 
good for someone.


If I wanted software that works and is adequately funded, I'd use 
Chrome. If Mozilla slides into forcing ads on people, the difference 
between Chrome and Firefox becomes quantitative, not qualitative – 
Google does the same bad stuff, but worse.


Personally, I sadly no longer trust Mozilla to do what's best for me. 
(Please don't become the next Google. Yes, I'm aware Google makes lots 
of money and can easily fund development and thousands of events each 
year. That does not make them an example I think Mozilla should follow.)


If Fedora starts including, as soldiers in a Trojan horse of default 
software, upstreams' features that don't benefit me and may be 
considered harmful, then Fedora will lose my trust as well.



tl;dr: I think the line we should not cross is: including features that 
don't benefit the user and may be considered harmful.


--
Petr³

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: DNF: why does it refresh metadata all the time

[Petr Viktorin]

On 06/19/2014 07:14 PM, Reindl Harald wrote:

why does DNF refresh metadata in background?


To quote Aleš Kozumplík from [a previous mail]:
| majority of people appreciates having the metadata handy and only a 
minority worries about the traffic.


[a previous mail] 
https://lists.fedoraproject.org/pipermail/devel/2013-March/180401.html




that has no benefit,


False.


increases network traffic


True (in some scenarios).


and finally leads to more likely outdated metadata in case
you type "dnf upgrade" *when* you want to apply updates


True.



the "failed to load plugin copr" is also just a bug


In that case please file it here: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora



--
Petr³

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Summary/Minutes from today's FESCo Meeting (2014-03-05)

[Petr Viktorin]

On 03/07/2014 10:59 AM, H. Guémar wrote:

Hi,

I don't think that worrying about perpetuating offensive stereotypes
is specifc to the US, we have similar controversies in Europe:
http://en.wikipedia.org/wiki/Banania#Controversy
http://en.wikipedia.org/wiki/Zwarte_Piet#Controversies


Well, read the second article. "92% of the Dutch public don't perceive 
Zwarte Piet as racist". I'm not saying it is or is not, or that it 
should or should not be fixed; I'm saying that there is a culture where 
this is not perceived as a big deal, as opposed to USA where political 
correctness is a big deal.



Anyway, the line between what is acceptable and unacceptable in Fedora
should be that no one should be offended by something that directly
refers to him or his origins in a negative or hurtful way.


My point is that the list "him/her and his/her origins" seems rather 
arbitrary. Why is e.g. "his/her religion" not on the list?
I'm not saying where the line should be drawn, that is obviously 
something a single person (or a single culture) shouldn't decide.


(By the way, excluding females by saying "he" when you mean anybody is 
seriously offensive to some. Again, from what I can tell, this is a big 
issue in the American culture.)



I have no opinion about the Cherokee logo, as an European citizen, it
looks to me very innocent (a little child playing) but if it offends
native americans, it should be fixed anyway.


I also don't see how anyone could be offended by it, but I understand 
that there is a culture that I don't understand :)


--
Petr³

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Summary/Minutes from today's FESCo Meeting (2014-03-05)

[Petr Viktorin]

On 03/06/2014 06:00 PM, Matthew Miller wrote:

On Thu, Mar 06, 2014 at 03:50:37PM +0100, drago01 wrote:

For instance we named a release "beefy miracle" and that might have
been offensive for some people (ex. in India)., but
apparently no one cared enough to "officially" complain.


Additionally, there is a fundamental difference here. The problem isn't that
someone might be offended -- people might be (and are) offended by anything.
The problem is that the logo refers to a marginalized race of people using
stereotyped imagery. While many people do not eat beef and hold cows sacred,
the beefy miracle logo does not make any reference to those people. If it
did, it too would have been a problem.


It seems this tabooization of stereotypes[0] is a North American concept 
(though, as I was surprised to learn, apparently there are entire fields 
of study around this area, which I admit I'm not familiar with).
I don't get how referring to a marginalized people using stereotyped 
imagery should be considered "offensive" in Fedora while sacrilege 
should not. I really don't see any fundamental difference. (Though -- or 
maybe because -- neither are offensive to me personally.)


Please, consider that there are cultures other than your own. What seems 
inherently right for you may seem confusing or even absurd to others, 
and on the other hand what seems trivial to you might be a huge issue 
for others.


--
Petr³


[0] Pardon me if this simplification is offensive. The whole concept is 
foreign to me.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: advertisement in packaged software (e.g. Firefox)

[Petr Viktorin]

On 02/12/2014 04:31 PM, Matthias Clasen wrote:


Are we allowed to ship software in Fedora that dynamically loads
advertisements from the web and shows them to users?


I think "allowed" is probably the wrong term to use here. Fedora
packaging rules on what is allowed to be included have pretty much
focused on legality of packages. ie licensing, trademarks, patents,
etc. The question of whether advertisements are "allowed" is starting
to venture into the grounds of philosophy. There's probably also a
privacy question to answer here too. To me though, those aren't
criteria for forbidding software from Fedora entirely, but are
relevant when choosing whether a piece of software is set as the
default option installed for users.


Yeah, I agree. This is not about being allowed to, but the question is
whether we want to. And for that, the question probably is: it depends.

I can't imagine having very obnoxious and prominents advertisements in
the flagship applications that we install by default. But an application
that is otherwise useful to our users should probably not be banned from
the package universe just because it downloads an ad.


If that ad enables tracking users, or is obnoxious in any way, the 
software should be modified to not include the ad.


I believe a major advantage of a free distribution like Fedora, over an 
app store like Android's, is that it tries to do what's best for the 
users, not developers and advertisers. Let's not change that, please.


--
Petr³

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: adam's grump of the day: icons in fonts (was Re: web-assets-httpd stuck in limbo?)

[Petr Viktorin]

On 01/17/2014 02:25 AM, Samuel Sieb wrote:

On 01/16/2014 01:38 PM, Chris Murphy wrote:


On Jan 16, 2014, at 1:41 PM, Matthew Miller 
wrote:



The other thing -- getting unicode to include standard symbols -- is
happening. That's why we have 💩 . Yay standards!


Oh man. Change that to 144pt. Is it chocolate soft serve with a smile?
Or is it Mr. Hanky's cousin?

Right-click on it> Show Font > Apple Color Emoji > Character

Character Name? PILE OF POO

Hahaha. Oh so many bad ideas made into a standard here…

👌 This does not mean OK in many countries!
👍 This can also be a crude gesture.
👃 This is just bad graphics.


Well, the graphics can be better in a different font.


Pine decoration, custard, bento box, and wind chime. Standards. Oh boy.



Assuming you're using Fedora to read your emails, what font do you have
installed that has those glyphs?  I can see them on my Android phone,
but not on my Fedora laptop.


You can use Symbola, yum install gdouros-symbola-fonts

--
Petr³

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf versus yum

[Petr Viktorin]

On 01/06/2014 03:32 PM, Lars E. Pettersson wrote:

On 01/06/2014 02:06 PM, Vít Ondruch wrote:

Dne 6.1.2014 13:31, Lars E. Pettersson napsal(a):

...

What would be the point in removing the running kernel? Is there
actually such a use case?

Lars


Why are you asking? May be you should let your imagination run riot.


Why? Isn't that obvious? If there is no use case for removing the
running kernel, well, then there's no reason to let a application do so,
isn't it?


AFAIU, inside a container you don't need a kernel installed.


Allowing something that has no, or a minuscules use case, while at the
same time might create huge problems for non technically oriented user,
is, in my opinion, really bad.


Also, I'd like to point out that "yum/dnf remove" by default shows what
it is going to do and you have to explicitly confirm the action, isn't
it enough? How much protection do you need?


Me? For me personally it dose not matter. The reason I debate this is to
help the unsuspecting ordinary non technical users from debunking their
systems. The user perspective is good to have sometimes, you know.

Lars



--
Petr³
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf versus yum

[Petr Viktorin]

On 01/02/2014 06:16 PM, Richard W.M. Jones wrote:

On Thu, Jan 02, 2014 at 05:54:00PM +0100, Reindl Harald wrote:

to prevent that the same as with GRUB2 and systemd way too early
made it in a stable release happening again - and after that get
again "why are you open your mouth now and not due testing" back


I'm sure that Ales will welcome patches from you.

But, have you ever contributed a patch to Fedora?  I'm having
difficulty finding any.  The first match for a Google search "reindl
harald fedora" is a discussion about banning you from sending mail to
this mailing list.  You don't even have a Fedora account.


I see no reason for ad hominem attacks. Personal history is irrelevant 
here. Let's please keep civil and focus on facts.


Aleš announced DNF ready for user testing, this thread is a legitimate 
reply to that (though this list may be the wrong channel for it).


--
Petr³

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: $HOME/.local/bin in $PATH

[Petr Viktorin]

On 11/01/2013 11:14 AM, Reindl Harald wrote:



Am 01.11.2013 11:08, schrieb Petr Viktorin:

On 11/01/2013 10:48 AM, Reindl Harald wrote:

Am 01.11.2013 10:38, schrieb drago01:

On Fri, Nov 1, 2013 at 10:26 AM, Andrew Haley  wrote:

On 10/30/2013 10:27 AM, Alec Leamas wrote:

On 2013-10-30 11:23, Reindl Harald wrote:

Am 30.10.2013 11:20, schrieb Alec Leamas:

On 2013-10-30 10:58, Reindl Harald wrote:

Am 30.10.2013 10:53, schrieb Alec Leamas:

Some kind of reference for the bad in having a well-known, hidden directory in 
the path?

the *writeable for the user* is the problem

Any reference for this problem?

what about consider the implications?
do you really need a written reference for any security relevant fact?
i can write one for you if you prefer links :-)


Well, the question is really if someone else out there share your
concerns about this.


Why does it matter?  A hidden directory in everyone's path is obviously
useful to an attacker, and (IMO) more useful to an attacker than to a user.


The attacker needs to be able to write to your home directory to take
advantage of it.
And if he can do that (you lost) he has numerous other ways of doing it


so the people decided not put the current directory in the
PATH on Unix *for security reasons* decades ago must be
fools and if you would have been born as this happened you
would have told them "forget it, in that case you are lost"


Was that even for security reasons?


yes, Google may help here


Anyway, how this is relevant to this discussion? How does a static, well-known 
(maybe not to you so far) bin
directory compare to the danger of . PATH and, say, a rootkit in /tmp/cp?


the rootkit in /tmp/cp is in your path?


If . would have been in $PATH and I happened to be in /tmp, then yes.
On the other hand if I install something in my home, it does not affect 
other users in any way.


(As an aside: the old Unix security decisions assumed the user trusts 
his or her software. This is of course increasingly less the case, but 
that neither makes anyone a fool, nor does it make . comparable to 
~/.local/bin.)



heroic attitude :-)

*yes* you have lost and in doubt in this situation the
interesting thing is how large the impact becomes


Users of a multi-user system get to customize their system without having to 
bother a sysadmin, and without seeing
technical details of that's accompished mixed with their ~/Photos and 
~/Documents.


on multi-user systems it is *intentional* that the user does *not* install
software at it's own and if this should be the case the admin *one time*
will add a directory to PATH and say "there you go"


As Alec said, not necessarily. If you want this policy for your systems, 
you have the power to do so.
The users (or software they install) can, of course, edit their 
.bash_profile to change it right back.



What impact did *you* have in mind?


the *security* impact after "you have lost" happened


In both cases, everything the user had access to is compromised, 
including .bash_profile itself. What other *security* impact did you 
have in mind?


--
Petr³

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: $HOME/.local/bin in $PATH

[Petr Viktorin]

On 11/01/2013 10:48 AM, Reindl Harald wrote:

Am 01.11.2013 10:38, schrieb drago01:

On Fri, Nov 1, 2013 at 10:26 AM, Andrew Haley  wrote:

On 10/30/2013 10:27 AM, Alec Leamas wrote:

On 2013-10-30 11:23, Reindl Harald wrote:

Am 30.10.2013 11:20, schrieb Alec Leamas:

On 2013-10-30 10:58, Reindl Harald wrote:

Am 30.10.2013 10:53, schrieb Alec Leamas:

Some kind of reference for the bad in having a well-known, hidden directory in 
the path?

the *writeable for the user* is the problem

Any reference for this problem?

what about consider the implications?
do you really need a written reference for any security relevant fact?
i can write one for you if you prefer links :-)


Well, the question is really if someone else out there share your
concerns about this.


Why does it matter?  A hidden directory in everyone's path is obviously
useful to an attacker, and (IMO) more useful to an attacker than to a user.


The attacker needs to be able to write to your home directory to take
advantage of it.
And if he can do that (you lost) he has numerous other ways of doing it


so the people decided not put the current directory in the
PATH on Unix *for security reasons* decades ago must be
fools and if you would have been born as this happened you
would have told them "forget it, in that case you are lost"


Was that even for security reasons?
Anyway, how this is relevant to this discussion? How does a static, 
well-known (maybe not to you so far) bin directory compare to the danger 
of . PATH and, say, a rootkit in /tmp/cp?



heroic attitude :-)

*yes* you have lost and in doubt in this situation the
interesting thing is how large the impact becomes


Users of a multi-user system get to customize their system without 
having to bother a sysadmin, and without seeing technical details of 
that's accompished mixed with their ~/Photos and ~/Documents.


What impact did *you* have in mind?

--
Petr³

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: $HOME/.local/bin in $PATH

[Petr Viktorin]

On 10/30/2013 01:08 PM, Reindl Harald wrote:



Am 30.10.2013 13:00, schrieb Alec Leamas:

On 2013-10-30 12:25, Reindl Harald wrote:

i gave you a starting point to learn about security and the reason
for sftp-chroot doing so is that someone could use race-conditions
to bypass the security

if you do not understand that allowing any random application running
with your normal user permissions place a binary inside PATH is a bad
idea i really can not help you

security is *always* a process and layered, there are a lot of things
to consider in different levels and while you can not gain 100%
security you can make it harder to bypass restrictions on several
places and doing things which are clearly against is not smart

you can decide that security is not that important for you
but a distribution as such should not make such wrong decisions for all users

No, it should not.  However,  the right decision is in many cases a trade-off 
between security and usabilty, not
always with a single answer. Allowing users to install sw (i. e., allowing 
random applications to put things in
$PATH) has of course security implications. Dis-allowing has usability aspects. 
 My personal view is that for the
distribution the defaults should allow and support user-installed sw.


the distribution should *not* train users doing this in their userhome

that is why /usr/local exists and software besides packages belongs
there and should be installed as root, 1 out of 1000 users need
to install software in the userhome,


Do you have any source for that assumption?
For example university students usually simply can't install as root.


if so they should learn
about the implications and have a small barrier


No, they should just install the software and be done with it.


it's not that hard to edit .bash_profile but you need to do it by hand
which means you have to spend a thought about it which is completly
different to "i did not know about the door i never opened by myself"


Why should I do that? I expect `pip install --user` to install my 
package without me having to fiddle with .bash_profile.



And, isn't  this still a little off-topic?


no it is not because the topic is in the subject


Current defaults already has ~/bin in $PATH, and user can certainly put
things there. Isn't the issue here if having a hidden, writeable directory
in $PATH is such a bad idea, given that users actually can install sw?


guess how many users are aware of the hidden directory compared with
"bin" in the userhome and how often someone may take a look


Also guess how many users don't care.
Do you have data to make anything else than a guess?


you can now argue that the user does not look in both of them
and i argue that extaly *this* is the problem
the defaults are dangerous for the majority of ordinary users


I personally like that ~/bin contains what I put there myself by hand, 
and ~/.local/bin has what was installed via pip.



but there are users sometimes take a look what is in their userhome
the chance doing also in hidden subdirectories is by zero


This is wild speculation.
You can just echo $PATH to see what directories are in $PATH.


Also, if you bother securing .bash_profile so that rogue programs can't 
write into it, you can easily check if $PATH is set the way you want it.
If you don't bother, it doesn't matter if malware installs to 
~/.local/bin/rootkit or ~/.rootkit


--
Petr³

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Source file audit - 2013-09-30

[Petr Viktorin]

On 10/04/2013 11:49 AM, Dridi Boukelmoune wrote:

Hi,

In my case, the makeself source tarball is hosted on github. I've seen
many people saying that github was down recently (even though it
worked fine for me).


It was down for about two hours: https://status.github.com/messages

--
Petr³

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Grepping through all Fedora specfiles?

[Petr Viktorin]

On 07/25/2013 01:45 AM, Toshio Kuratomi wrote:

On Thu, Jul 25, 2013 at 09:02:47AM +1000, Tony Breeds wrote:


As an aside, Any guesses as to how big the ~/fedora-git dir would be
after running the script above?


Upwards of 9GB.  I'm working on a git-seed script right now and that's the
size of a checkout seed in the testing environment (which has an older sync
of the git repos).

-Toshio


If you're worried about the size, shallow clones could work for you in 
this case: git clone --depth 1

Read the man page for the limitations.

It might not save too much space, though -- compressed history tends to 
be small.


(`git fetch --unshallow` will bring in the history if you change your 
mind later.)


--
Petr³

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel