Re: Schedule for Thursday's FPC Meeting (2020-01-16 17:00 UTC)

[Zbigniew Jędrzejewski-Szmek]

What about the caret versioning guidelines
[https://pagure.io/packaging-committee/pull-request/908].
Fedora could really use this.

Zbyszek


On Wed, Jan 15, 2020 at 10:44:28PM -0500, James Antill wrote:
>  Following is the list of topics that will be discussed in the FPC
> meeting Thursday at 2020-01-16 17:00 UTC in #fedora-meeting-1 on 
> irc.freenode.net.
> 
>  Local time information (via. uitime):
> 
> = Day: Thursday ==
> 2020-01-16 09:00 PST  US/Pacific
> 2020-01-16 12:00 EST  --> US/Eastern <--
> 2020-01-16 17:00 GMT  Europe/London 
> 2020-01-16 17:00 UTC  UTC   
> 2020-01-16 18:00 CET  Europe/Berlin 
> 2020-01-16 18:00 CET  Europe/Paris  
> 2020-01-16 22:30 IST  Asia/Calcutta 
>  New Day: Friday -
> 2020-01-17 01:00 HKT  Asia/Hong_Kong
> 2020-01-17 01:00 +08  Asia/Singapore
> 2020-01-17 02:00 JST  Asia/Tokyo
> 2020-01-17 03:00 AEST Australia/Brisbane
> 
> 
>  Links to all tickets below can be found at: 
> 
> https://pagure.io/packaging-committee/issues?status=Open=meeting
> 
> = Followups =
> 
> #topic #907 Which %__foo macros for executables are acceptable? 
> .fpc 907
> https://pagure.io/packaging-committee/issue/907
> 
> #topic #909 Suggest that linting/measuring-coverage is not for %check
> .fpc 909
> https://pagure.io/packaging-committee/issue/909
> 
> #topic #935 Fonts packaging policy rewrite  
> .fpc 935
> https://pagure.io/packaging-committee/issue/935
> https://pagure.io/packaging-committee/pull-request/934
> 
> = Pull Requests =
> 
> #topic #pr-814 Add SELinux Independent Policy Guidelines 
> https://pagure.io/packaging-committee/pull-request/814
> 
> = Open Floor = 
> 
>  For more complete details, please visit each individual ticket.  The
> report of the agenda items can be found at:
> 
> https://pagure.io/packaging-committee/issues?status=Open=meeting
> 
>  If you would like to add something to this agenda, you can:
>   * Reply to this e-mail
>   * File a new ticket at: https://pagure.io/packaging-committee
>   * E-mail me directly
>   * Bring it up at the end of the meeting, during the open floor topic. Note
> that added topics may be deferred until the following meeting.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Cloud-30-20200116.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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: Mock build Fedora package on CentOS 7

[Nico Kadel-Garcia]

On Wed, Jan 15, 2020 at 12:08 PM Ian Pilcher  wrote:
>
> Is $SUBJECT possible these days?
>
> I've tried with both --bootstrap-chroot and --use-bootstrap-image, but
> the build is failing with:
>
>ERROR: builddep command missing.
>Please install package dnf-plugins-core.
>
> This happens even when the dnf-plugins-core package is installed (from
> EPEL) on the CentOS 7 host, probably because the Fedora 31 container
> image doesn't include that package.

There are notes in the "mock" buglists
at:https://github.com/rpm-software-management/mock/issues/390 . The
short answer is "not very well".  The dnf tools in RHEL 7 and 8 are
not sufficient to actually run dnf for "mock". There are options to
bootstrap Fedora 31 from a container using "podman" to install the
zstd compressed binary RPM, but it's slow and painful and unreliable
unless you build your entire toolchain from a collection of SRPM's.

My notes and patches aare available
at:https://github.com/nkadel/mockrep, especially the editing of
fedora-31.tmpl in the mock-core-configs.spec./

> Is there a secret incantation to make this work?
>
> --
> 
>   In Soviet Russia, Google searches 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
___
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: Let's talk about Fedora in the '20s!

[Benson Muite]

On 1/15/20 8:33 PM, Przemek Klosowski via devel wrote:

On 1/7/20 11:14 AM, Iñaki Ucar wrote:

I'm far from having a satisfactory response to that, but I see two
fronts here. First, marketing. How does Ubuntu managed to be so
popular among less-experienced Linux users? I'm not sure, but I
suspect that good marketing has something to do with it.
One of their primary aims has been user friendliness. Their forums are 
helpful and it is easier to find information on Ubuntu with a quick 
internet search. A number of other linux distributions now aim to be 
friendly to those who just want things to work.


I can think of several reasons that are important to me; some of them 
were addressed by Fedora and are no longer relevant, but they gave 
Ubuntu enough momentum to last


- Ubuntu provides LTS releases, so people can chose to install and 
forget. Yes, it is a tradeoff with new/shiny, but it's nice to have 
this option for something that is intended to last.
Fedora is positioned somewhere in between Debian and Ubuntu. Debian does 
not have as many users as Ubuntu. Cent OS is available for 10 years, but 
is mostly considered a server distro, though is also very capable 
desktop as many of the things in Fedora can be used in Cent OS or easily 
ported to it.


- as the result of the momentum, Ubuntu became the default in various 
special circumstances: Jupyter notebooks, WSL, etc.; furthermore, this 
popularity attracted packagers  so that some Ubuntu packages lead 
Fedora (see also next point).
Having software packages is helpful. However, things like Flatpak, Snap 
and Appimages may make this less of a concern. Some distributions allow 
using package repositories from other distributions, for example Puppy 
dog linux can use Ubuntu repositories, so with a small number of core 
developers can offer many applications.


- Ubuntu was pragmatic and compromising on non-free software such as 
codecs and video drivers; as a result, it has sometimes better support 
for things like CUDA software, video/multimedia, etc., even though 
nowadays Fedora has practically out-of-box support for these.
It is helpful to know when non-free software is used.  Perhaps better 
communication with hardware vendors is required. Alternatively, a number 
of distributions do have online stores where you can get a pre-installed 
system that should be hassle free. Part of the attraction of linux is 
the freedom to configure things yourself which  requires an investment 
of time.


Regarding the first point, the Fedora/Redhat/CentOS environment 
requires an early decision and commitment to one of the three 
alternatives. If it is production, one would deploy paid-support 
RedHat; less critical but still long-term roles call for CentOS, and 
of course Fedora is best for personal systems, especially for 
development and testing new software stacks.
This mostly needs a good partitioning of the file system and/or multiple 
hard drives, separate, data from the operating system and the 
applications. It is then possible to easily change the operating system. 
It is also possible to have workstations with multiple operating system 
boot options.


It turns out, however, that the initial intent often changes: an 
important production system becomes a less-critical legacy, or a 
cutting-edge development system proves itself and becomes production. 
In these cases it would be nice to transition smoothly between the 
choices: a RHEL system that comes off its entitlement should not just 
sit there unpatched but should smoothly transition to CentOS, and 
maybe there could be a way to transition a no-longer supported Fedora 
to a roughly-equivalent RedHat/CentOS. I realize that this is a big 
ask, but I wished for it often enough that I thought I'd put it out 
here for consideration, especially in the context of competing with 
Ubuntu.
This can work by separating data from operating system. Main problem 
might be that some software package may need to be built again since it 
may not be available in the repository - this would likely need some 
developer/packager time. Transitioning may be challenging to fully 
automate due to application software availability and compatibility, 
though many linux installers now give a choice of where to put the 
operating system and what disks/partitions to leave untouched.

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

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 

[389-devel] 389 DS nightly 2020-01-16 - 96% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/01/16/report-389-ds-base-1.4.3.1-20200116gitfa1f69a.fc31.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

Schedule for Thursday's FPC Meeting (2020-01-16 17:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2020-01-16 17:00 UTC in #fedora-meeting-1 on 
irc.freenode.net.

 Local time information (via. uitime):

= Day: Thursday ==
2020-01-16 09:00 PST  US/Pacific
2020-01-16 12:00 EST  --> US/Eastern <--
2020-01-16 17:00 GMT  Europe/London 
2020-01-16 17:00 UTC  UTC   
2020-01-16 18:00 CET  Europe/Berlin 
2020-01-16 18:00 CET  Europe/Paris  
2020-01-16 22:30 IST  Asia/Calcutta 
 New Day: Friday -
2020-01-17 01:00 HKT  Asia/Hong_Kong
2020-01-17 01:00 +08  Asia/Singapore
2020-01-17 02:00 JST  Asia/Tokyo
2020-01-17 03:00 AEST Australia/Brisbane


 Links to all tickets below can be found at: 

https://pagure.io/packaging-committee/issues?status=Open=meeting

= Followups =

#topic #907 Which %__foo macros for executables are acceptable? 
.fpc 907
https://pagure.io/packaging-committee/issue/907

#topic #909 Suggest that linting/measuring-coverage is not for %check
.fpc 909
https://pagure.io/packaging-committee/issue/909

#topic #935 Fonts packaging policy rewrite  
.fpc 935
https://pagure.io/packaging-committee/issue/935
https://pagure.io/packaging-committee/pull-request/934

= Pull Requests =

#topic #pr-814 Add SELinux Independent Policy Guidelines 
https://pagure.io/packaging-committee/pull-request/814

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open=meeting

 If you would like to add something to this agenda, you can:
  * Reply to this e-mail
  * File a new ticket at: https://pagure.io/packaging-committee
  * E-mail me directly
  * Bring it up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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 32 System-Wide Change proposal (late): Enable EarlyOOM

[Neal Gompa]

On Wed, Jan 15, 2020 at 6:40 PM John M. Harris Jr  wrote:
>
> On Wednesday, January 8, 2020 12:24:23 PM MST Chris Murphy wrote:
> > Looks like PSI based oom killing doesn't work without swap. Therefore
> > oomd can't be considered a universal solution. Quite a lot of
> > developers have workstations with quite a decent amount of RAM,
> > ~64GiB, and do not use swap at all. Server baremetal are likewise
> > mixed, depending on workloads, and in cloud it's rare for swap to
> > exist.
>
> While it's true some systems without swap are possible, it's not common,
> except in the case of virtual machines, in which case it depends heavily on
> the vendor.
>

Nearly all of our servers don't have swap in $DAYJOB's server fleet
(thousands of servers). In my experience, it's an increasingly common
thing.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[John M. Harris Jr]

On Wednesday, January 8, 2020 12:24:23 PM MST Chris Murphy wrote:
> Looks like PSI based oom killing doesn't work without swap. Therefore
> oomd can't be considered a universal solution. Quite a lot of
> developers have workstations with quite a decent amount of RAM,
> ~64GiB, and do not use swap at all. Server baremetal are likewise
> mixed, depending on workloads, and in cloud it's rare for swap to
> exist.

While it's true some systems without swap are possible, it's not common, 
except in the case of virtual machines, in which case it depends heavily on 
the vendor.

-- 
John M. Harris, Jr.
Splentity

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

[Bug 1791320] perl-XML-LibXML-Simple-1.01 is available

[bugzilla]

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



--- Comment #5 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-XML-LibXML-Simple-1.01-1.fc29.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=40587210

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1791320] perl-XML-LibXML-Simple-1.01 is available

[bugzilla]

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



--- Comment #4 from Upstream Release Monitoring 
 ---
Created attachment 1652584
  --> https://bugzilla.redhat.com/attachment.cgi?id=1652584=edit
[patch] Update to 1.01 (#1791320)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1791320] perl-XML-LibXML-Simple-1.01 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-XML-LibXML-Simple-1.00 |perl-XML-LibXML-Simple-1.01
   |is available|is available



--- Comment #3 from Upstream Release Monitoring 
 ---
Latest upstream release: 1.01
Current version/release in rawhide: 0.99-7.fc31
URL: http://search.cpan.org/dist/XML-LibXML-Simple

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


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


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


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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1789918] please build perl-Font-TTF-1.06 for EPEL 8

[bugzilla]

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



--- Comment #4 from Sergio Monteiro Basto  ---

The branches epel8 and epel8-playground  are created [1] please add me  as
maintainer,  my fas is sergiomb .

Thanks.


[1]
https://src.fedoraproject.org/rpms/perl-Font-TTF/tree/epel8
https://src.fedoraproject.org/rpms/perl-Font-TTF/tree/epel8-playground

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: RFC: Python minimization in Fedora

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jan 15, 2020 at 06:05:42PM +0100, Miro Hrončok wrote:
> ### File types (and bytecode caches)
> 
> The orthogonal dimension is the file type. Python standard library
> contains directories with both "extension modules" (written in C
> (usually) and compiled to `*.cpython-38-x86_64-linux-gnu.so` shared
> object file) and "pure Python" modules (written in Python and saved
> as `*.py` source file).
> 
> Each pure Python module comes in 4 files:
> 
> - `module.py` -- the source
> - `__pycache__/module.cpython-38.pyc` -- regular (not optimized) bytecode 
> cache
> - `__pycache__/module.cpython-38.opt-1.pyc` -- optimized bytecode cache 
> (level 1)
> - `__pycache__/module.cpython-38.opt-2.pyc` -- optimized bytecode cache 
> (level 2)

I suspect that the difference in speed between loading various .pyc
files is negligible. Do you have actual benchmarks for this?

> ### Solution 5: Stop shipping mandatory bytecode cache
> 
> This solution sounds simple: We do no longer ship the bytecode cache
> mandatorily. Technically, we move the `.pyc` files to a subpackage
> of `python3-libs` (or three different subpackages, that is not
> important here). And we only *Recommend* them from `python3-libs` --
> by default, the users get them, but for space critical Fedora
> flavors (such as container images) the maintainers can opt-out and
> so can the powerusers.
> 
> This would **save 18.6 MiB / 50%** -- quite a lot.
> 
> However, as said earlier, if the bytecode cache files are not there,
> Python attempts to create them upon first import. That can result in
> several problems, here we will try to propose how to workaround
> them.

Below using a flag file in each __pycache__ directory is suggested.
What about a different route: having a flag file for all descendants
of a directory?

For example, /usr/lib/python3.8/.dont_write_bytecode
would cover all modules under /usr/lib/python3.8/.
If a .pyc file is present, python could still make use of it.

This would be a nicer solution because it wouldn't require modifying
individual packages, but would still avoid the selinux issues and
slowdowns from failed attempts to write the optimized files.
The __pycache__ files wouldn't need to exist at all.

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

Re: RFC: Python minimization in Fedora

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jan 15, 2020 at 06:05:42PM +0100, Miro Hrončok wrote:
> ### File types (and bytecode caches)
> 
> The orthogonal dimension is the file type. Python standard library
> contains directories with both "extension modules" (written in C
> (usually) and compiled to `*.cpython-38-x86_64-linux-gnu.so` shared
> object file) and "pure Python" modules (written in Python and saved
> as `*.py` source file).
> 
> Each pure Python module comes in 4 files:
> 
> - `module.py` -- the source
> - `__pycache__/module.cpython-38.pyc` -- regular (not optimized) bytecode 
> cache
> - `__pycache__/module.cpython-38.opt-1.pyc` -- optimized bytecode cache 
> (level 1)
> - `__pycache__/module.cpython-38.opt-2.pyc` -- optimized bytecode cache 
> (level 2)

I suspect that the difference in speed between loading various .pyc
files is negligible. Do you have actual benchmarks for this?

> ### Solution 5: Stop shipping mandatory bytecode cache
> 
> This solution sounds simple: We do no longer ship the bytecode cache
> mandatorily. Technically, we move the `.pyc` files to a subpackage
> of `python3-libs` (or three different subpackages, that is not
> important here). And we only *Recommend* them from `python3-libs` --
> by default, the users get them, but for space critical Fedora
> flavors (such as container images) the maintainers can opt-out and
> so can the powerusers.
> 
> This would **save 18.6 MiB / 50%** -- quite a lot.
> 
> However, as said earlier, if the bytecode cache files are not there,
> Python attempts to create them upon first import. That can result in
> several problems, here we will try to propose how to workaround
> them.

Below using a flag file in each __pycache__ directory is suggested.
What about a different route: having a flag file for all descendants
of a directory?

For example, /usr/lib/python3.8/.dont_write_bytecode
would cover all modules under /usr/lib/python3.8/.
If a .pyc file is present, python could still make use of it.

This would be a nicer solution because it wouldn't require modifying
individual packages, but would still avoid the selinux issues and
slowdowns from failed attempts to write the optimized files.
The __pycache__ files wouldn't need to exist at all.

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

Re: RFC: Python minimization in Fedora

[Victor Stinner]

> Solution 4: ZIP the entire standard library
> (...)
> Nevertheless, this might (in theory) **save 17.8 MiB / 47 %**.

It's my favorite option. Almost 50% smaller is quite good! It would be
very efficient to have such disk space gain!

Using a ZIP file for the stdlib is commonly suggested solution when
the slow Python startup time is discussed. Python does tons of system
calls to load stdlib modules at startup: many stat() and open() calls.
Having a single large ZIP file allows to do more work in pure
userland.

This solution is well supported by unmodified Python: it's part of the
default sys.path search path:

$ python3
Python 3.7.6 (default, Dec 19 2019, 22:52:49)
>>> import sys; sys.path
['', '/usr/lib64/python37.zip', ...]

It's the second item of sys.path ;-)

I'm ok to discourage users to override *system files* by modifying
them as root. It's too easy to mess up your system this way.

It is easy to extract the ZIP file in your home directory, hack some
files and use PYTHONPATH environment variable to force loading your
modified stdlib.

* faster startup
* less disk space
* harder to mess up your system

Where are drawbacks by the way? ;-)

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

Re: RFC: Python minimization in Fedora

[Victor Stinner]

> Solution 4: ZIP the entire standard library
> (...)
> Nevertheless, this might (in theory) **save 17.8 MiB / 47 %**.

It's my favorite option. Almost 50% smaller is quite good! It would be
very efficient to have such disk space gain!

Using a ZIP file for the stdlib is commonly suggested solution when
the slow Python startup time is discussed. Python does tons of system
calls to load stdlib modules at startup: many stat() and open() calls.
Having a single large ZIP file allows to do more work in pure
userland.

This solution is well supported by unmodified Python: it's part of the
default sys.path search path:

$ python3
Python 3.7.6 (default, Dec 19 2019, 22:52:49)
>>> import sys; sys.path
['', '/usr/lib64/python37.zip', ...]

It's the second item of sys.path ;-)

I'm ok to discourage users to override *system files* by modifying
them as root. It's too easy to mess up your system this way.

It is easy to extract the ZIP file in your home directory, hack some
files and use PYTHONPATH environment variable to force loading your
modified stdlib.

* faster startup
* less disk space
* harder to mess up your system

Where are drawbacks by the way? ;-)

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

[Bug 1789918] please build perl-Font-TTF-1.06 for EPEL 8

[bugzilla]

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

Sergio Monteiro Basto  changed:

   What|Removed |Added

 Status|CLOSED  |ASSIGNED
 Resolution|WORKSFORME  |---
   Keywords||Reopened



--- Comment #3 from Sergio Monteiro Basto  ---
I just requested the branches [1] but it won't add me as maintainer ! , can you
add me as maintainer of this package please, my fas is sergiomb .

Thanks

[1]
https://pagure.io/releng/fedora-scm-requests/issue/21426
https://pagure.io/releng/fedora-scm-requests/issue/21427

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1789918] please build perl-Font-TTF-1.06 for EPEL 8

[bugzilla]

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

Nicolas Mailhot  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |WORKSFORME
Last Closed||2020-01-15 21:33:03



--- Comment #2 from Nicolas Mailhot  ---
Hi,

I’m not doing EPEL, I have my hands full Fedora-side. I have no objections to
others doing the EPEL maintenance.

Now I’ve stated that

https://lists.fedoraproject.org/archives/list/epel-annou...@lists.fedoraproject.org/thread/KXMMLYSAXAVHDKFFBVEFYYZHPJBWXOQQ/

implies you can request an epel 8 branch via fedpkg

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: List of long term FTBFS packages to be retired in February

[Simo Sorce]

On Wed, 2020-01-15 at 20:59 +0100, Tomasz Torcz wrote:
> On Mon, Jan 06, 2020 at 11:44:31AM +, Peter Robinson wrote:
> > > Also said in the e-mail, if you think those packages need to be exempted 
> > > from
> > > the process, we can deal with that to, however there must be a valid 
> > > reason. I
> > > don't think "the maintainer didn't actually maintain their Fedora 
> > > packages for
> > > almost 2 years because they have real stuff to do" is a valid reason, yet 
> > > other
> > > FESCo members might disagree with that statement.
> > 
> > Well the FTB from people pushing builds would be directly due to the
> > fact they're not on the ACL for the secure-boot, there is a handful of
> > packages like that.
> > 
> > Well FESCo might agree that they want booting x86 images with
> > secure-boot so ¯\_(ツ)_/¯
> 
>   We (Fedora) may want to have secure boot, yet we don't have maintainer
> with enough spare time for it.  Let's be adults and forgo secure boot.

You are not being very excellent here ... (and also ignoring the actual
thread you are responding to, where the maintainer already commented).

> -- 
> Tomasz Torcz   There exists no separation between gods and men:
> to...@pipebreaker.pl   one blends softly casual into the other.  — Frank 
> Herbert
> ___
> 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

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



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

Re: Mock build Fedora package on CentOS 7

[Ian Pilcher]

On 1/15/20 1:26 PM, Stephen John Smoogen wrote:

On Wed, 15 Jan 2020 at 12:08, Ian Pilcher  wrote:


Is $SUBJECT possible these days?

I've tried with both --bootstrap-chroot and --use-bootstrap-image, but
the build is failing with:

ERROR: builddep command missing.
Please install package dnf-plugins-core.

This happens even when the dnf-plugins-core package is installed (from
EPEL) on the CentOS 7 host, probably because the Fedora 31 container
image doesn't include that package.

Is there a secret incantation to make this work?



I do not see a dnf-plugins-core in EPEL. I see a dnf-langpacks-conf
and so I am not sure what is going on here.



I messed up.  dnf-plugins-core is actually in Extras.

--

 In Soviet Russia, Google searches 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

Re: List of long term FTBFS packages to be retired in February

[Tomasz Torcz]

On Mon, Jan 06, 2020 at 11:44:31AM +, Peter Robinson wrote:
> 
> > Also said in the e-mail, if you think those packages need to be exempted 
> > from
> > the process, we can deal with that to, however there must be a valid 
> > reason. I
> > don't think "the maintainer didn't actually maintain their Fedora packages 
> > for
> > almost 2 years because they have real stuff to do" is a valid reason, yet 
> > other
> > FESCo members might disagree with that statement.
> 
> Well the FTB from people pushing builds would be directly due to the
> fact they're not on the ACL for the secure-boot, there is a handful of
> packages like that.
> 
> Well FESCo might agree that they want booting x86 images with
> secure-boot so ¯\_(ツ)_/¯

  We (Fedora) may want to have secure boot, yet we don't have maintainer
with enough spare time for it.  Let's be adults and forgo secure boot.

-- 
Tomasz Torcz   There exists no separation between gods and men:
to...@pipebreaker.pl   one blends softly casual into the other.  — Frank 
Herbert
___
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: Mock build Fedora package on CentOS 7

[Stephen John Smoogen]

On Wed, 15 Jan 2020 at 12:08, Ian Pilcher  wrote:
>
> Is $SUBJECT possible these days?
>
> I've tried with both --bootstrap-chroot and --use-bootstrap-image, but
> the build is failing with:
>
>ERROR: builddep command missing.
>Please install package dnf-plugins-core.
>
> This happens even when the dnf-plugins-core package is installed (from
> EPEL) on the CentOS 7 host, probably because the Fedora 31 container
> image doesn't include that package.
>
> Is there a secret incantation to make this work?
>

I do not see a dnf-plugins-core in EPEL. I see a dnf-langpacks-conf
and so I am not sure what is going on here.


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

Re: RFC: Python minimization in Fedora

[Łukasz Posadowski]

Wed, 15 Jan 2020 18:05:42 +0100
Miro Hrončok :

> Hello Fedora!
> 
> In Python Maint, we sat down and we came up with several ideas how to
> minimize the filesystem footprint of Python. Unfortunately, the
> result is horribly long, sorry about that.

It was delightfull to read. I have some better understanding of
what Python setup.  Maybe even Python core may adopt some ideas in
the future. It that not what Fedora does? :) 

I used Micropython in Mirobit boards and that Python *is* tiny.
Standard Fedora Python is not really that big, but more code on disk
(even unused) is always a potential security problem. I sometimes build
my own Python without extras like tkinter, curses, or xml. It's super
easy and I always get the version I want.

I was suprised to see a proposal to remove pyc files. I know they're
big and, unless something is constantly using particular module, mostly
useless. Python is creating that files during "make install" and every
other module does that, during install. Python is faster with them.

Compressing data in modules is also nice. While zip is not the best,
it's what we have in Python. I'm suprised that this is largest part of
Python installation.

> Optimization level 2 is already broken.

That is a good point. Almost no one uses pure Python. 

> ### Solution 10: Stop shipping mandatory Python, rewrite dnf to Rust

No I just started to work really well. I didn't know about
libdnf, sounds interesting.

-- 
Łukasz Posadowski
___
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: What would it take to drop release and changelog from our spec files? (and do we want to?)

[Randy Barlow]

On Tue, 2020-01-14 at 00:30 +0100, David Kaufmann wrote:
> The field for bodhi I usually copy from the changelog - but to be
> honest I only fill it, because it's there - I don't even really know
> what it is used for, except being shown on the update page.

Users can read the update text with the updateinfo dnf subcommand. For
example:

$ dnf updateinfo --info FEDORA-2019-ed226e6112
Last metadata expiration check: 0:02:22 ago on Wed 15 Jan 2020 01:45:20 PM EST.
===
  xorg-x11-server-1.20.6-1.fc30
===
  Update ID: FEDORA-2019-ed226e6112
   Type: bugfix
Updated: 2020-01-14 19:37:24
   Bugs: 1752211 - crash of /usr/libexec/Xorg
   : 1761241 - [abrt] xorg-x11-server-Xwayland: 
present_wnmd_abort_vblank(): Xwayland killed by SIGABRT
Description: xserver 1.20.6
   Severity: None


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RFC: Python minimization in Fedora

[Przemek Klosowski via devel]

On 1/15/20 12:56 PM, Chris wrote:

That's an amazing amount of work! My only criticism would be:
- the quest for reducing disk space is getting a bit over the top.  I 
mean to make comparisons to 3.5" floppy disks which haven't been 
around for 20 years? Why is ~100MB so much? If you scale up from 
floppy disks and even reference a 8GB USB stick (which you can barely 
find any more), you'll fit just fine.  Most Raspberry Pi's (out of the 
box solutions) even ship with Python, so the size has never been their 
concern either (where otherwise space would be).


I am bias, because I absolutely adore Python and it's added bloat to 
basically be the swiss army knife that can solve any problem isn't 
worth the few MB you're trying to cut out of it.


Me too---but it's useful to have Python in super-small environments. For 
comparison, people squeezed Python onto ARM Arduino Nano-class 
platforms, using Cortex M0 chips on a 1"x2" board costing 5$. The total 
memory is on the order of 256kB; of course it doesn't run Linux, but you 
do get a Python REPL over a serial/USB link.


https://makezine.com/2017/08/11/circuitpython-snakes-way-adafruit-hardware/
___
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: RFC: Python minimization in Fedora

[Chris]

That's an amazing amount of work! My only criticism would be:
- the quest for reducing disk space is getting a bit over the top.  I mean
to make comparisons to 3.5" floppy disks which haven't been around for 20
years? Why is ~100MB so much? If you scale up from floppy disks and even
reference a 8GB USB stick (which you can barely find any more), you'll fit
just fine.  Most Raspberry Pi's (out of the box solutions) even ship with
Python, so the size has never been their concern either (where otherwise
space would be).

I am bias, because I absolutely adore Python and it's added bloat to
basically be the swiss army knife that can solve any problem isn't worth
the few MB you're trying to cut out of it.

That all said: as a dev, I've got no problems with the solution that just
involves removing dev-related packages from the main core build of Python
unless you pull in python-devel. Solution 5 seems also seems good (stop
shipping .pyc files)... Just pick one (.pyc, or .pyo) file to ship with the
distribution; I'm not sure if both are really required. Just my two cents;
I don't comment to much here, i enjoy seeing you all debate though! :)

Chris

On Wed, Jan 15, 2020 at 12:15 PM Miro Hrončok  wrote:

> Hello Fedora!
>
> In Python Maint, we sat down and we came up with several ideas how to
> minimize
> the filesystem footprint of Python. Unfortunately, the result is horribly
> long,
> sorry about that.
>
> Please, share your feedback, additional solutions, comments etc.
>
> Version with formatting and pictures is available at:
>
> https://github.com/hroncok/python-minimization/blob/master/document.md
>
>
> Enclosing here for better in-line responses:
>
>
>
> # Python minimization in Fedora
>
>  > While Fedora is well suited for traditional physical/virtual
> workstations and
> servers, it is often overlooked for use cases beyond traditional installs.
>  >
>  > Some modern types of deployments — such as IoT and containers — are
> quite
> sensitive to size. For IoT that's usually slow data connections (for
> updates/management) and for cloud and containers it’s the massive scale.
>
> -- the preamble of the [Fedora Minimization
> Objective](https://docs.fedoraproject.org/en-US/minimization/)
>
> One of the biggest things in Fedora is Python. Because [Fedora loves
> Python](https://fedoralovespython.org/) and because the package manager
> for
> Fedora packages -- dnf -- happens to be written in Python, the Python
> interpreter and its standard library comes pre-installed on many (if not
> all)
> Fedora systems and is often not possible to remove it without destroying
> the
> system completely or making it unmanageable.
>
> Python comes with [Batteries
> Included](https://en.wikipedia.org/wiki/Batteries_Included) -- the
> standard
> library is quite big. While pleasant for the programmers, this comes with
> a
> large filesystem footprint not entirely desired in Fedora. In this
> document, we
> will analyze the footprint and offer several minimization solutions/ideas
> with
> their challenges, pros (MiB saved) and cons. It is a list of ideas;
> **we're not
> promising to do any of this**.
>
>
> **Goal:**
>
>   1. Significantly lower the filesystem footprint of the mandatory Python
> installation in Fedora.
>
> **Non-goals:**
>
>   1. We don't aim to lower the filesystem footprint of all Python
> installations
> in Fedora -- the default may remain big, if there is an opt-out mechanism.
>   2. We don't aim to lower the filesystem footprint of all Fedora Python
> RPM
> packages, just the `python3` package and its subpackages -- the
> interpreter and
> the standard library.
>
> However, if any non-goal becomes a side effect of the solution of our
> goal, good.
>
> **Constraints:**
>
>   1. Do not break Python users' expectations. As an example, we don't
> strip
> Python standard library to the bare minimum and still call it Python.
>   2. Do not break Fedora users' expectations. As an example, we don't
> break the
> ability to hot patch Python files on a live system by default.
>   3. Do not break Fedora packagers' expectations. As an example, we don't
> [require "system tools" to use a custom Python
> entrypoint](https://fedoraproject.org/wiki/Changes/System_Python), such
> as
> `/usr/libexec/platform-python` or `/usr/libexec/system-python`.
>   4. Do not significantly increase the filesystem footprint of the default
> Python installation. As an example, we don't package [two separate
> versions (and
> stacks) of Python](
> https://fedoraproject.org/wiki/Changes/Platform_Python_Stack)
> -- one minimal for dnf (or Ansible) and another "normal" for the users.
>   5. Do not diverge from upstream significantly (but we can drive upstream
> change). As an example, we don't reinvent the import machinery of Python
> downstream only, but we might do it in upstream and even [use Fedora to
> pioneer
> the change](https://fedoraproject.org/wiki/Changes/python3_c.utf-8_locale
> ).
>
> The listed constraints are not absolute. We will 

Re: Let's talk about Fedora in the '20s!

[Przemek Klosowski via devel]

On 1/7/20 11:14 AM, Iñaki Ucar wrote:

I'm far from having a satisfactory response to that, but I see two
fronts here. First, marketing. How does Ubuntu managed to be so
popular among less-experienced Linux users? I'm not sure, but I
suspect that good marketing has something to do with it.


I can think of several reasons that are important to me; some of them 
were addressed by Fedora and are no longer relevant, but they gave 
Ubuntu enough momentum to last


- Ubuntu provides LTS releases, so people can chose to install and 
forget. Yes, it is a tradeoff with new/shiny, but it's nice to have this 
option for something that is intended to last.


- as the result of the momentum, Ubuntu became the default in various 
special circumstances: Jupyter notebooks, WSL, etc.; furthermore, this 
popularity attracted packagers  so that some Ubuntu packages lead Fedora 
(see also next point).


- Ubuntu was pragmatic and compromising on non-free software such as 
codecs and video drivers; as a result, it has sometimes better support 
for things like CUDA software, video/multimedia, etc., even though 
nowadays Fedora has practically out-of-box support for these.


Regarding the first point, the Fedora/Redhat/CentOS environment requires 
an early decision and commitment to one of the three alternatives. If it 
is production, one would deploy paid-support RedHat; less critical but 
still long-term roles call for CentOS, and of course Fedora is best for 
personal systems, especially for development and testing new software 
stacks.


It turns out, however, that the initial intent often changes: an 
important production system becomes a less-critical legacy, or a 
cutting-edge development system proves itself and becomes production. In 
these cases it would be nice to transition smoothly between the choices: 
a RHEL system that comes off its entitlement should not just sit there 
unpatched but should smoothly transition to CentOS, and maybe there 
could be a way to transition a no-longer supported Fedora to a 
roughly-equivalent RedHat/CentOS. I realize that this is a big ask, but 
I wished for it often enough that I thought I'd put it out here for 
consideration, especially in the context of competing with Ubuntu.

___
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

[POC-change] Fedora packages point of contact updates

[nobody]

Change in package status over the last 168 hours


0 packages were orphaned


0 packages were retired


0 packages unorphaned
-

0 packages were unretired


0 packages were given


0 packages had new branches



Sources: https://github.com/pypingou/fedora-owner-change
___
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

RFC: Python minimization in Fedora

[Miro Hrončok]

Hello Fedora!

In Python Maint, we sat down and we came up with several ideas how to minimize 
the filesystem footprint of Python. Unfortunately, the result is horribly long, 
sorry about that.


Please, share your feedback, additional solutions, comments etc.

Version with formatting and pictures is available at:

https://github.com/hroncok/python-minimization/blob/master/document.md


Enclosing here for better in-line responses:



# Python minimization in Fedora

> While Fedora is well suited for traditional physical/virtual workstations and 
servers, it is often overlooked for use cases beyond traditional installs.

>
> Some modern types of deployments — such as IoT and containers — are quite 
sensitive to size. For IoT that's usually slow data connections (for 
updates/management) and for cloud and containers it’s the massive scale.


-- the preamble of the [Fedora Minimization 
Objective](https://docs.fedoraproject.org/en-US/minimization/)


One of the biggest things in Fedora is Python. Because [Fedora loves 
Python](https://fedoralovespython.org/) and because the package manager for 
Fedora packages -- dnf -- happens to be written in Python, the Python 
interpreter and its standard library comes pre-installed on many (if not all) 
Fedora systems and is often not possible to remove it without destroying the 
system completely or making it unmanageable.


Python comes with [Batteries 
Included](https://en.wikipedia.org/wiki/Batteries_Included) -- the standard 
library is quite big. While pleasant for the programmers, this comes with a 
large filesystem footprint not entirely desired in Fedora. In this document, we 
will analyze the footprint and offer several minimization solutions/ideas with 
their challenges, pros (MiB saved) and cons. It is a list of ideas; **we're not 
promising to do any of this**.



**Goal:**

 1. Significantly lower the filesystem footprint of the mandatory Python 
installation in Fedora.


**Non-goals:**

 1. We don't aim to lower the filesystem footprint of all Python installations 
in Fedora -- the default may remain big, if there is an opt-out mechanism.
 2. We don't aim to lower the filesystem footprint of all Fedora Python RPM 
packages, just the `python3` package and its subpackages -- the interpreter and 
the standard library.


However, if any non-goal becomes a side effect of the solution of our goal, 
good.

**Constraints:**

 1. Do not break Python users' expectations. As an example, we don't strip 
Python standard library to the bare minimum and still call it Python.
 2. Do not break Fedora users' expectations. As an example, we don't break the 
ability to hot patch Python files on a live system by default.
 3. Do not break Fedora packagers' expectations. As an example, we don't 
[require "system tools" to use a custom Python 
entrypoint](https://fedoraproject.org/wiki/Changes/System_Python), such as 
`/usr/libexec/platform-python` or `/usr/libexec/system-python`.
 4. Do not significantly increase the filesystem footprint of the default 
Python installation. As an example, we don't package [two separate versions (and 
stacks) of Python](https://fedoraproject.org/wiki/Changes/Platform_Python_Stack) 
-- one minimal for dnf (or Ansible) and another "normal" for the users.
 5. Do not diverge from upstream significantly (but we can drive upstream 
change). As an example, we don't reinvent the import machinery of Python 
downstream only, but we might do it in upstream and even [use Fedora to pioneer 
the change](https://fedoraproject.org/wiki/Changes/python3_c.utf-8_locale).


The listed constraints are not absolute. We will mention in each solution, 
whether we feel that some constraints are violated, but that doesn't mean we 
shall outright discard the solution.



## How large is Python, actually

tl;dr Python 3.8.1 in Fedora has 111 MiB (approximately 77 3.5" floppy disks), 
but we only **install 37.5 MiB by default** (26 floppy disks).


![77 3.5" floppy 
disks](https://github.com/hroncok/python-minimization/raw/master/77-floppy-disks-gray.jpg)

*77 3.5" floppy disks, courtesy of Dana Walker. Imagine one of them is faulty.*

(All numbers are real installed disk sizes based on the `python38` package 
installed on Fedora 31, x86_64. The split into subpackages is based on the 
`python3` package from Fedora 32. Slight differences between Fedora 31 and 32 or 
between various architectures are irrelevant here, we aim for a long term 
minimization. See the [source of the numbers][source].)


In Fedora we split the Python interpreter into various RPM subpackages, some of 
them are optional. This is what you get all the time:


 - `python3` contains `/usr/bin/python3` and friends; has 21 KiB.
 - `python3-libs` contains `/usr/lib64/libpython3.8.so.1.0` and the majority of 
the standard library, is required by `python3`; has 37.5 MiB.


And this is what you get optionally:

 - `python3-devel` contains the "development files" and makes it possible to 
compile extension 

RFC: Python minimization in Fedora

[Miro Hrončok]

Hello Fedora!

In Python Maint, we sat down and we came up with several ideas how to minimize 
the filesystem footprint of Python. Unfortunately, the result is horribly long, 
sorry about that.


Please, share your feedback, additional solutions, comments etc.

Version with formatting and pictures is available at:

https://github.com/hroncok/python-minimization/blob/master/document.md


Enclosing here for better in-line responses:



# Python minimization in Fedora

> While Fedora is well suited for traditional physical/virtual workstations and 
servers, it is often overlooked for use cases beyond traditional installs.

>
> Some modern types of deployments — such as IoT and containers — are quite 
sensitive to size. For IoT that's usually slow data connections (for 
updates/management) and for cloud and containers it’s the massive scale.


-- the preamble of the [Fedora Minimization 
Objective](https://docs.fedoraproject.org/en-US/minimization/)


One of the biggest things in Fedora is Python. Because [Fedora loves 
Python](https://fedoralovespython.org/) and because the package manager for 
Fedora packages -- dnf -- happens to be written in Python, the Python 
interpreter and its standard library comes pre-installed on many (if not all) 
Fedora systems and is often not possible to remove it without destroying the 
system completely or making it unmanageable.


Python comes with [Batteries 
Included](https://en.wikipedia.org/wiki/Batteries_Included) -- the standard 
library is quite big. While pleasant for the programmers, this comes with a 
large filesystem footprint not entirely desired in Fedora. In this document, we 
will analyze the footprint and offer several minimization solutions/ideas with 
their challenges, pros (MiB saved) and cons. It is a list of ideas; **we're not 
promising to do any of this**.



**Goal:**

 1. Significantly lower the filesystem footprint of the mandatory Python 
installation in Fedora.


**Non-goals:**

 1. We don't aim to lower the filesystem footprint of all Python installations 
in Fedora -- the default may remain big, if there is an opt-out mechanism.
 2. We don't aim to lower the filesystem footprint of all Fedora Python RPM 
packages, just the `python3` package and its subpackages -- the interpreter and 
the standard library.


However, if any non-goal becomes a side effect of the solution of our goal, 
good.

**Constraints:**

 1. Do not break Python users' expectations. As an example, we don't strip 
Python standard library to the bare minimum and still call it Python.
 2. Do not break Fedora users' expectations. As an example, we don't break the 
ability to hot patch Python files on a live system by default.
 3. Do not break Fedora packagers' expectations. As an example, we don't 
[require "system tools" to use a custom Python 
entrypoint](https://fedoraproject.org/wiki/Changes/System_Python), such as 
`/usr/libexec/platform-python` or `/usr/libexec/system-python`.
 4. Do not significantly increase the filesystem footprint of the default 
Python installation. As an example, we don't package [two separate versions (and 
stacks) of Python](https://fedoraproject.org/wiki/Changes/Platform_Python_Stack) 
-- one minimal for dnf (or Ansible) and another "normal" for the users.
 5. Do not diverge from upstream significantly (but we can drive upstream 
change). As an example, we don't reinvent the import machinery of Python 
downstream only, but we might do it in upstream and even [use Fedora to pioneer 
the change](https://fedoraproject.org/wiki/Changes/python3_c.utf-8_locale).


The listed constraints are not absolute. We will mention in each solution, 
whether we feel that some constraints are violated, but that doesn't mean we 
shall outright discard the solution.



## How large is Python, actually

tl;dr Python 3.8.1 in Fedora has 111 MiB (approximately 77 3.5" floppy disks), 
but we only **install 37.5 MiB by default** (26 floppy disks).


![77 3.5" floppy 
disks](https://github.com/hroncok/python-minimization/raw/master/77-floppy-disks-gray.jpg)

*77 3.5" floppy disks, courtesy of Dana Walker. Imagine one of them is faulty.*

(All numbers are real installed disk sizes based on the `python38` package 
installed on Fedora 31, x86_64. The split into subpackages is based on the 
`python3` package from Fedora 32. Slight differences between Fedora 31 and 32 or 
between various architectures are irrelevant here, we aim for a long term 
minimization. See the [source of the numbers][source].)


In Fedora we split the Python interpreter into various RPM subpackages, some of 
them are optional. This is what you get all the time:


 - `python3` contains `/usr/bin/python3` and friends; has 21 KiB.
 - `python3-libs` contains `/usr/lib64/libpython3.8.so.1.0` and the majority of 
the standard library, is required by `python3`; has 37.5 MiB.


And this is what you get optionally:

 - `python3-devel` contains the "development files" and makes it possible to 
compile extension 

Mock build Fedora package on CentOS 7

[Ian Pilcher]

Is $SUBJECT possible these days?

I've tried with both --bootstrap-chroot and --use-bootstrap-image, but
the build is failing with:

  ERROR: builddep command missing.
  Please install package dnf-plugins-core.

This happens even when the dnf-plugins-core package is installed (from
EPEL) on the CentOS 7 host, probably because the Fedora 31 container
image doesn't include that package.

Is there a secret incantation to make this work?

--

 In Soviet Russia, Google searches 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

Re: Alternative buildroot as a development tool

[Kevin Fenzi]

On Mon, Jan 13, 2020 at 05:43:26PM +0100, Aleksandra Fedorova wrote:
...snip...

> --
> Note: The naming is hard here, and while I tend to call it
> “buildroot”, it actually needs to be called “alternative everything,
> except the srpms”.
> 
> I think we shouldn’t use the word “variant”, “spin”, “flavour” or
> something like that to describe it, as it is strictly the shared
> development playground linked to the latest Fedora Rawhide state and
> focused on the build and compose process. It is definitely not the
> alternative Fedora. It shouldn’t have releases on its own, it has no
> branches in the source code and it doesn’t target end-users.
> --

petri dish? too hard to say...fields (like planting a test crop in
another field)? Naming is hard. :) 
> 
> The good thing is that, with the distributed CI approach we have
> implemented, we are ready to consume the feedback from such
> alternative setups in a non-blocking but informative way. I think we
> can extend our use of CI machinery so that it simplifies the
> development process for everyone, removing redundant heads-ups but
> increasing the targeted collaboration in places where it is actually
> needed.
> 
> ### Use cases ###
> 
> The first example of such a buildroot is provided by the CPU baseline
> testing [1].
> 
> There will be more, since we may want to work on comps files for
> Minimization Objective.

Yeah, but comps files are used in composes, so we would have to do
composes to see changes there. I guess the CI part would do the
composing in that case? But we would also need a different comps (so we
didn't change the default one). 

> There is also one particularly important case of the RHEL bootstrap:
> RHEL tries hard to inherit as much as possible from Fedora, but since
> both Fedora and RHEL have historically different build and compose
> configurations, it is often problematic to deal with dependency and
> build issues which arise from it. To the point that RHEL sometimes
> just can’t use Fedora as an origin, and needs to find its way around.
> 
> The alternative buildroot targeting CentOS and RHEL would provide an
> open shared development environment. There we can work on converging
> the RHEL process to Fedora, and also on improving Fedora process with
> things, which RHEL and CentOS have discovered.

+1 !
 
> ### Proposal ###
> 
> This idea doesn’t quite fit into the Fedora Changes framework, as
> there is no actual change to Fedora. And we don't even have a concept
> of an Infrastructure Change at this point.

Well, infrastructure has a Request for resources process. 
However, it's a bit dated these days, not taking into account OpenShift
or the like. The CPE team has been wanting to move to a higher level
process for this kind of thing... but yeah, nothing is really clear, I'd
say just get buyin from stakeholders/fesco.
> 
> But there are several items one can think about:
> 
> 1) Though as I said above the “buildroot” term is slightly misleading
> but it is a start. And the change [2] is a first step, the prototype,
> which goes into that direction. Its main focus is the compiler
> parameters rather than anything else.

Yep.

> 2) The second part of the proposal is to setup a CentOS/RHEL-targeting
> buildroot and compose, with a focus on comps, dependency chains and
> compose differences. Which I think overlaps in a certain way with the
> Minimization Objective.

So, this would have composes? Or they would be test composes in CI/ODCS?

> 3) And the third part is to generally develop the alternative
> buildroot as a concept. It should be our toolbox item, something
> similar to the alternative architectures approach. So that it can be
> requested by anyone based on the existence of a SIG or working group,
> which would own and maintain it.

Yeah, although I think we should still examine if a thing is ready for
testing this way. I don't think we should just add anything that anyone
can think of. It does use resources. That said, I think if the concept
for testing is reasonable we could add it. 

Thanks for working on this and I'm eager to see how well we can get it
working! :) 

kevin


signature.asc
Description: PGP signature
___
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: HELP: FreeCAD is still very broken on Fedora 30/31

[Richard Shaw]

On Wed, Jan 15, 2020 at 9:04 AM Nicolas Chauvet  wrote:

> Le mer. 15 janv. 2020 à 15:52, Richard Shaw  a
> écrit :
> >
> > On Wed, Jan 15, 2020 at 8:50 AM Nicolas Chauvet 
> wrote:
> >>
> >> Le mer. 15 janv. 2020 à 15:36, Richard Shaw  a
> écrit :
> >> >
> >> >
> >> > There is a mess between Coin3 and Coin4 (and their dependencies)
> which I believe is causing most of the problems.
> >> >
> >> > Some background here:
> >> >
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RMWY7KZIPWNOYPZE7ZOHEZGCN334T2BW/#RMWY7KZIPWNOYPZE7ZOHEZGCN334T2BW
> >> >
> >> > The main Coin3D stack (Coin, soqt, SIMVoleon, privy) are still Coin3
> based for Fedora 30/31 but FreeCAD needs Coin4. FreeCAD doesn't actually
> use SoQt (but Quarter instead) but also requires Pivy at runtime which
> pulls in the rest of the Coin3 stack.
> >> >
> >> > I have avoided modules, but would that be a solution to the
> dependency problem? At least on Fedora 31? I don't need them for Rawhide so
> I would want to make sure they were obsoleted once f32 is released.
> >> >
> >> > Is there anything I can do or just leave it broken until f32 is
> released?
> >> >
> >> > I'm getting pretty worn out with bugzilla tickets related to FreeCAD
> and don't know how to "fix" it at this point, other than t
> >> You can downgrade freecad to the appropriate version that still uses
> >> Coin3, then keep the Coin4 version for f32.
> >
> >
> > Well the bug is actually in Coin3. SVG imports/exports cause a segfault,
> not really FreeCAD version specific I'm afraid, but I may have to live with
> a "lesser problem" as this point.
>
> Well, at this step the error is located in your FreeCAD compilation
> since, as I understand, you cannot have a process to load two
> differents versions of the same library (unless using symbol version
> which Coin3/4 doesn't use).
>

Well, that's where things get muddy. The current version only loads Coin4
(libCoin.so.80), Pivy loads Coin3 (libCoin.so.60) but Pivy is a Python
library so I was hoping I could get away with it. Initial testing seemed to
indicate it would but several bugzilla tickets later maybe not.



> So there is no bug analysis beyond that. (side note, your older
> FreeCAD RPM has Coin.so.60 as DTNEEDED, so you actually directly links
> to Coin3. not via a 3rd part dependency).
>

Yes, my initial testing with Coin4 was in my COPR.



>
> Is this Coin3 issue a regression or has the problem always existed in
> the f30/f31 livetime ?
>

Always as far as I know, just wasn't a problem until someone tried a SVG
import.

Thanks,
Richard
___
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: HELP: FreeCAD is still very broken on Fedora 30/31

[Nicolas Chauvet]

Le mer. 15 janv. 2020 à 15:52, Richard Shaw  a écrit :
>
> On Wed, Jan 15, 2020 at 8:50 AM Nicolas Chauvet  wrote:
>>
>> Le mer. 15 janv. 2020 à 15:36, Richard Shaw  a écrit :
>> >
>> >
>> > There is a mess between Coin3 and Coin4 (and their dependencies) which I 
>> > believe is causing most of the problems.
>> >
>> > Some background here:
>> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RMWY7KZIPWNOYPZE7ZOHEZGCN334T2BW/#RMWY7KZIPWNOYPZE7ZOHEZGCN334T2BW
>> >
>> > The main Coin3D stack (Coin, soqt, SIMVoleon, privy) are still Coin3 based 
>> > for Fedora 30/31 but FreeCAD needs Coin4. FreeCAD doesn't actually use 
>> > SoQt (but Quarter instead) but also requires Pivy at runtime which pulls 
>> > in the rest of the Coin3 stack.
>> >
>> > I have avoided modules, but would that be a solution to the dependency 
>> > problem? At least on Fedora 31? I don't need them for Rawhide so I would 
>> > want to make sure they were obsoleted once f32 is released.
>> >
>> > Is there anything I can do or just leave it broken until f32 is released?
>> >
>> > I'm getting pretty worn out with bugzilla tickets related to FreeCAD and 
>> > don't know how to "fix" it at this point, other than t
>> You can downgrade freecad to the appropriate version that still uses
>> Coin3, then keep the Coin4 version for f32.
>
>
> Well the bug is actually in Coin3. SVG imports/exports cause a segfault, not 
> really FreeCAD version specific I'm afraid, but I may have to live with a 
> "lesser problem" as this point.

Well, at this step the error is located in your FreeCAD compilation
since, as I understand, you cannot have a process to load two
differents versions of the same library (unless using symbol version
which Coin3/4 doesn't use).
So there is no bug analysis beyond that. (side note, your older
FreeCAD RPM has Coin.so.60 as DTNEEDED, so you actually directly links
to Coin3. not via a 3rd part dependency).

Is this Coin3 issue a regression or has the problem always existed in
the f30/f31 livetime ?


-- 
-

Nicolas (kwizart)
___
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: HELP: FreeCAD is still very broken on Fedora 30/31

[Richard Shaw]

On Wed, Jan 15, 2020 at 8:50 AM Nicolas Chauvet  wrote:

> Le mer. 15 janv. 2020 à 15:36, Richard Shaw  a
> écrit :
> >
> >
> > There is a mess between Coin3 and Coin4 (and their dependencies) which I
> believe is causing most of the problems.
> >
> > Some background here:
> >
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RMWY7KZIPWNOYPZE7ZOHEZGCN334T2BW/#RMWY7KZIPWNOYPZE7ZOHEZGCN334T2BW
> >
> > The main Coin3D stack (Coin, soqt, SIMVoleon, privy) are still Coin3
> based for Fedora 30/31 but FreeCAD needs Coin4. FreeCAD doesn't actually
> use SoQt (but Quarter instead) but also requires Pivy at runtime which
> pulls in the rest of the Coin3 stack.
> >
> > I have avoided modules, but would that be a solution to the dependency
> problem? At least on Fedora 31? I don't need them for Rawhide so I would
> want to make sure they were obsoleted once f32 is released.
> >
> > Is there anything I can do or just leave it broken until f32 is released?
> >
> > I'm getting pretty worn out with bugzilla tickets related to FreeCAD and
> don't know how to "fix" it at this point, other than t
> You can downgrade freecad to the appropriate version that still uses
> Coin3, then keep the Coin4 version for f32.
>

Well the bug is actually in Coin3. SVG imports/exports cause a segfault,
not really FreeCAD version specific I'm afraid, but I may have to live with
a "lesser problem" as this point.

Thanks,
Richard
___
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: HELP: FreeCAD is still very broken on Fedora 30/31

[Nicolas Chauvet]

Le mer. 15 janv. 2020 à 15:36, Richard Shaw  a écrit :
>
>
> There is a mess between Coin3 and Coin4 (and their dependencies) which I 
> believe is causing most of the problems.
>
> Some background here:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RMWY7KZIPWNOYPZE7ZOHEZGCN334T2BW/#RMWY7KZIPWNOYPZE7ZOHEZGCN334T2BW
>
> The main Coin3D stack (Coin, soqt, SIMVoleon, privy) are still Coin3 based 
> for Fedora 30/31 but FreeCAD needs Coin4. FreeCAD doesn't actually use SoQt 
> (but Quarter instead) but also requires Pivy at runtime which pulls in the 
> rest of the Coin3 stack.
>
> I have avoided modules, but would that be a solution to the dependency 
> problem? At least on Fedora 31? I don't need them for Rawhide so I would want 
> to make sure they were obsoleted once f32 is released.
>
> Is there anything I can do or just leave it broken until f32 is released?
>
> I'm getting pretty worn out with bugzilla tickets related to FreeCAD and 
> don't know how to "fix" it at this point, other than t
You can downgrade freecad to the appropriate version that still uses
Coin3, then keep the Coin4 version for f32.

Thx
-- 
-

Nicolas (kwizart)
___
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

HELP: FreeCAD is still very broken on Fedora 30/31

[Richard Shaw]

There is a mess between Coin3 and Coin4 (and their dependencies) which I
believe is causing most of the problems.

Some background here:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RMWY7KZIPWNOYPZE7ZOHEZGCN334T2BW/#RMWY7KZIPWNOYPZE7ZOHEZGCN334T2BW

The main Coin3D stack (Coin, soqt, SIMVoleon, privy) are still Coin3 based
for Fedora 30/31 but FreeCAD needs Coin4. FreeCAD doesn't actually use SoQt
(but Quarter instead) but also requires Pivy at runtime which pulls in the
rest of the Coin3 stack.

I have avoided modules, but would that be a solution to the dependency
problem? At least on Fedora 31? I don't need them for Rawhide so I would
want to make sure they were obsoleted once f32 is released.

Is there anything I can do or just leave it broken until f32 is released?

I'm getting pretty worn out with bugzilla tickets related to FreeCAD and
don't know how to "fix" it at this point, other than to tell them to use he
flatpack.

Thanks,
Richard
___
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: What would it take to drop release and changelog from our spec files? (and do we want to?)

[Panu Matilainen]

On 1/15/20 3:33 PM, Vít Ondruch wrote:


Dne 15. 01. 20 v 13:33 Panu Matilainen napsal(a):

On 1/15/20 2:13 PM, Miroslav Suchý wrote:

Dne 13. 01. 20 v 14:05 Vít Ondruch napsal(a):

%changelog

%include changelog


+1



As I pointed out in
https://pagure.io/packaging-committee/pull-request/942, %include is
nasty because it breaks the stand-alone attribute of specs. There are
umphteen dupes and variants of bugs about systemd.spec's use of
%include breaking this and that use pattern that aren't systemd's
fault, it's just that %include isn't as useful as it initially seems.



Would it be helpful to open RPM upstream ticket to discuss when the
missing included file is problematic and whether there should be other
graceful variant of include? May be the %include should always behave
gracefully, because (S)RPM build is going to always fail due to missing
files specified by Source directive.

This was actually discussed upstream not too long ago, just can't find 
the reference offhand.


Basically an %include can never be allowed to fail as it can contain 
anything at all, including mandatory parts of the spec. In theory you 
can have a spec consisting of nothing but one or more %include directives.


(S)RPM builds are not an issue, it's spec queries, in particular for 
build-dependencies but also for other data. Rpm has special logic to 
allow missing sources and patches for query purposes, because they're 
only needed for building. Something changelog-specific could also safely 
ignore the missing file as %changelog is always an optional part of the 
spec.


- Panu -

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

[Bug 1791320] perl-XML-LibXML-Simple-1.00 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-XML-LibXML-Simple-1.00-1.fc29.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=40567887

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1791320] perl-XML-LibXML-Simple-1.00 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1652449
  --> https://bugzilla.redhat.com/attachment.cgi?id=1652449=edit
[patch] Update to 1.00 (#1791320)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1791320] New: perl-XML-LibXML-Simple-1.00 is available

[bugzilla]

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

Bug ID: 1791320
   Summary: perl-XML-LibXML-Simple-1.00 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-XML-LibXML-Simple
  Keywords: FutureFeature, Triaged
  Assignee: c...@m.fsf.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: c...@m.fsf.org, mefos...@gmail.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.00
Current version/release in rawhide: 0.99-7.fc31
URL: http://search.cpan.org/dist/XML-LibXML-Simple

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


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


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


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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: What would it take to drop release and changelog from our spec files? (and do we want to?)

[Neal Gompa]

On Wed, Jan 15, 2020 at 7:10 AM Miroslav Suchý  wrote:
>
> Dne 11. 01. 20 v 3:54 Neal Gompa napsal(a):
> > * %{dist}..
>
> -1
> Packages with commitish in release version are usually developers snapshot.
> We already have few packages with such release in Fedora, but I would dislike 
> to make this standard.

That is not putting the hash in there. That is a counter. It's poorly labeled.

Basically, an NEVRA would look like this:

foo-0:1.0.0-fc32.1.1.noarch

"commit-at-version" is a counter, starting from 1 that indicates the
number of commits in the build system of the version of a package. So
version 1.1 would start at 1 initially, and every subsequent commit
where you _don't_ change the version, this number goes up.

"build-at-version" is a counter, starting from 1 that indicates the
number of builds in the build system of the commit at that version of
a package. So at version 1.1 with commit-at-version 1 would initially
have build-at-version 1 for the first build, but on the fourth
rebuild, it would be 5.

Given that, here's what the options I presented would look like the
following Release fields:

* %{dist}.: 1.fc32.5
* .%{?dist}: 1.5.fc32
* %{dist}..: fc32.1.5


--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: How do I request EPEL packages

[Petr Pisar]

On Tue, Jan 14, 2020 at 08:49:48PM +, Nick Howitt wrote:
> Hi,
> There are a number of fc31 packages I'd like to see in EPEL so I can use
> them for Centos7 for wok-3.0 and kimchi-3.0. Two that I need are:
> python3-libguestfs
> python3-pyparted
> 
> I also possibly need:
> python3-pyparted as the pip module throws a error.
> 
> The ones I'd also like so I can avoid pip are:
> python3-configobj
> python3-magic
> python3-cherrypy
> python3-websockify
> python3-cheetah
> 
> I've found a references for creating the request
> - 
> https://fedoraproject.org/wiki/Getting_a_Fedora_package_in_EPEL#The_procedure_for_getting_a_package_in_EPEL
> - and I've created an account on bugzilla. If I try to search for any of the
> packages with Classification=Fedora, Product=Fedora EPEL and
> Classification=name_of_package, none of the packages are listed.

python3-configobj is a name of the binary package. Bugzilla enumarates
packages (components in Bugzilla classification) by source package name. You
can get source package name with this commands:

# dnf --quiet repoquery --source python3-configobj
python-configobj-5.0.6-19.fc32.src.rpm

Now if I search for python-configobj in Bugzilla, I get

listing one bug report about adding the package to EPEL 6 (#1288811). 

If you want python-configobj for EPEL 7, file a bug there. There is "File
a new bug in the "python-configobj" component of the "Fedora EPEL" product"

link on search results. You should set the version fields of the bug report to
epel7 if possible. Otherwise use any version available.

If there is no component in "Fedora EPEL" product, report the bug in "Fedora"
component.

In all cases please make the subject of the bug clear that you want to add
a new package into EPEL 8.

-- Petr


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

Re: What would it take to drop release and changelog from our spec files? (and do we want to?)

[Vít Ondruch]

Dne 15. 01. 20 v 13:33 Panu Matilainen napsal(a):
> On 1/15/20 2:13 PM, Miroslav Suchý wrote:
>> Dne 13. 01. 20 v 14:05 Vít Ondruch napsal(a):
>>> %changelog
>>>
>>> %include changelog
>>
>> +1
>>
>
> As I pointed out in
> https://pagure.io/packaging-committee/pull-request/942, %include is
> nasty because it breaks the stand-alone attribute of specs. There are
> umphteen dupes and variants of bugs about systemd.spec's use of
> %include breaking this and that use pattern that aren't systemd's
> fault, it's just that %include isn't as useful as it initially seems.


Would it be helpful to open RPM upstream ticket to discuss when the
missing included file is problematic and whether there should be other
graceful variant of include? May be the %include should always behave
gracefully, because (S)RPM build is going to always fail due to missing
files specified by Source directive.


Vít


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

[Bug 1791036] perl-ExtUtils-MakeMaker-7.44 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-ExtUtils-MakeMaker-7.4
   ||4-1.fc32



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for Fedora ≥ 31.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[389-devel] Reminder: please review - PR 50819 - dsconf - Error: 'PwPolicyManager' object has no attribute 'get_attr_list'

[Mark Reynolds]

On 1/13/20 7:24 PM, Mark Reynolds wrote:

https://pagure.io/389-ds-base/pull-request/50819


--

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

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

[Sandro Bonazzola]

>  * something else - is something blocking you from using Copr? Please share 
> it with us.

Right now, getting https://bugzilla.redhat.com/show_bug.cgi?id=1572596 fixed 
will unblock building java packages on CentOS Stream / EPEL 8.
___
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: Let's talk about Fedora in the '20s!

[Nico Kadel-Garcia]

On Tue, Jan 14, 2020 at 3:04 AM Benson Muite  wrote:

> Maybe am wrong about faces/fingerprints as passwords:
>
> https://www.openwall.com/lists/oss-security/2019/05/08/5

There was also the infamous "gummy fingerprint" article from 2002:

https://cryptome.org/gummy.htm

And the mythbusters test of faking fingerprints. There, printing a
copy of a fingerprint, putting it on your fingertip, and moistening it
by licking it defeated even the best fingerprint scanners.

https://www.youtube.com/watch?v=3Hji3kp_i9k

While playing with the hardware can be fun, I'd not consider them
worth delaying a Fedora release for.
___
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: What would it take to drop release and changelog from our spec files? (and do we want to?)

[Panu Matilainen]

On 1/15/20 2:13 PM, Miroslav Suchý wrote:

Dne 13. 01. 20 v 14:05 Vít Ondruch napsal(a):

%changelog

%include changelog


+1



As I pointed out in 
https://pagure.io/packaging-committee/pull-request/942, %include is 
nasty because it breaks the stand-alone attribute of specs. There are 
umphteen dupes and variants of bugs about systemd.spec's use of %include 
breaking this and that use pattern that aren't systemd's fault, it's 
just that %include isn't as useful as it initially seems.


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

Re: What would it take to drop release and changelog from our spec files? (and do we want to?)

[Miroslav Suchý]

Dne 13. 01. 20 v 14:05 Vít Ondruch napsal(a):
> %changelog
> 
> %include changelog

+1

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

Re: What would it take to drop release and changelog from our spec files? (and do we want to?)

[Miroslav Suchý]

Dne 11. 01. 20 v 3:54 Neal Gompa napsal(a):
> * %{dist}..

-1
Packages with commitish in release version are usually developers snapshot.
We already have few packages with such release in Fedora, but I would dislike 
to make this standard.

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

Re: Fedora 32 Self-Contained Change proposal: Provide OpenType Bitmap Fonts

[Akira TAGOH]

On Fri, Jan 10, 2020 at 3:34 AM Nicolas Mailhot via devel
 wrote:
> Just to be clear: the Fonts packaging guidelines that FPC has been
> reviewing since last year mandates the conversion and forbids the
> packaging of deprecated formats.

Yes. we need to take some steps to move forward on it. as we've
already seen some issues on Pango, there might be similar on others
that can still use with the legacy formats. we should have a chance to
test on it but don't want to break as far as possible. so making both
formats available would be a good idea.
I personally think that we should have done it in a release though,
there seems to be some human resource issue to work on all the font
packages converting. so trying to experiment it for limited packages
this time.

>
> And, user feedback since then has shown making the deprecated formats
> available in addition to OpenType, not only creates the usual rendering
> mess when apps choose different glyphs sources in slightly different
> conditions, but also triggers app bugs. The old files are not
> "harmless".

Good point.  actually that happens when mixing up both formats in the
same place or where renderer can look over. replacement would be
harmless for Pango since it has already been broken. but it isn't true
for non-Pango. thus, providing them as a sub-package and both
sub-packages for legacy and OpenType may need to have Conflicts line
each other to avoid such a situation.

>
> > As it stands, having more than *.otb causes the weird hex number
> > rectangle glyph "Terminus Italic",
>
>
> Regards,
>
> --
> Nicolas Mailhot
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



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

[Bug 1791036] perl-ExtUtils-MakeMaker-7.44 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|ppi...@redhat.com   |
   Doc Type|--- |If docs needed, set a value



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Let's talk about Fedora in the '20s!

[Daniel Rusek]

> I think, and this is my personal opinion, that Ubuntu is so popular, 
> because it is easy to use for everyone. You don't need to have much 
> technical knowledge to use Ubuntu for most thinks that non technical 
> user needs and it looks good.
> 
> Every time I'm trying to use Fedora the same way, I always end up in 
> terminal for various reasons, either because of bugs in some software or 
> debugging something that simply doesn't work.
> 
> I tried a experiment on my desktop computer and tried to play with it 
> like regular user (using GUI for everything and doing things like 
> installing new things, watching movies, playing games etc.). It worked 
> for some time, but I always encounter something that just broke things 
> and if you google it, there is in most cases no way to fix this without 
> using terminal and have some technical knowledge.
> 
> The same is for the guides. There are plenty of guides for Ubuntu with 
> screenshots, so it's easy for users to just follow these guides. For 
> Fedora we have plenty of guides that just have only commands you need to 
> run and I know plenty of users that just don't know what command means 
> or where they should write it.
> 
> Michal

Well said!

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

[389-devel] Re: Example for a password storage scheme plug-in (SLAPI_PLUGIN_PWD_STORAGE_SCHEME) - bcrypt?

[Ludwig Krispenz]

Hi William,

I think Harald was asking how to extend an existing deployment with a 
plugin, not to build a new plugin into the core. Just use it with a 
standard build.


Unfortunately our plugin guide is a bit old and the example plugins are 
no longer installed with the server. The best you could get is checking 
out the code and then look into the folder test-plugins, there are 
examples and Makefiles - but not up to date.


Regards,
Ludwig

On 01/15/2020 07:20 AM, William Brown wrote:

Hi Harald,

The most recently developed scheme was pbkdf2_pwd.c, so it likely has the 
"best" example of how to make a module. I've attached the original PBKDF2 diff 
so you can see the other files that may need to be altered, but the list is:

+++ Makefile.am
+++ dirsrvtests/tests/tickets/ticket397_test.py
+++ ldap/ldif/template-dse.ldif.in
+++ ldap/servers/plugins/pwdstorage/pbkdf2_pwd.c
+++ ldap/servers/plugins/pwdstorage/pwd_init.c
+++ ldap/servers/plugins/pwdstorage/pwdstorage.h
+++ ldap/servers/slapd/pw.c
+++ ldap/servers/slapd/pw.h

There have also been a number of changes to the pbkdf2 module since, so it's best to look 
at the "latest" version of pbkdf2_pwd.c of course.

I'd like to ask what scheme you were planning to add, as if it's relevant we 
could consider upstreaming it into the server. It's also good as we can provide 
code review and advice to help as well.

Hope this helps!

PS: I'm at a conference so I may be slow to respond this week





On 15 Jan 2020, at 03:52, Harald Strack  wrote:

Hi,

we need to implement a  password storage scheme plug-in for the 389 directory 
server. Especially we need to implement bcrypt support.  We checked the source 
code and documentation and found out that we need to write a 
SLAPI_PLUGIN_PWD_STORAGE_SCHEME plugin.

Some plugins of this type are in the source of 389-base are in 
389-ds-base/ldap/servers/plugins/pwdstorage, a good starting point seems to be 
one of these

clear_pwd.c
crypt_pwd.c
md5c.c
md5.h
md5_pwd.c
ns-mta-md5_pwd.bu
ns-mta-md5_pwd.c
pbkdf2_pwd.c
pwd_init.c
pwdstorage.h
pwd_util.c
sha_pwd.c
smd5_pwd.c
ssha_pwd.c

But these are core plugins. How do we implement a plugin as extension? An 
example project with autoconf / makefile(s) etc. would be great. Any help would 
be greatly appreciated!

br

Harald






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

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs



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


--
Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn,
Handelsregister: Amtsgericht München, HRB 153243,
Geschäftsführer: Charles Cachera, Laurie Krebs, Michael O'Neill, Thomas Savage

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

Re: Alternative buildroot as a development tool

[Adam Samalik]

I really like this proposal. I feel like it's something we needed for a
long time.
More comments inline!

On Mon, Jan 13, 2020 at 5:45 PM Aleksandra Fedorova 
wrote:

> Hi, all,
>
> This topic goes along the lines of Matthew’s Operating System Factory
> discussion[1], but with a slightly different angle. It also is the
> generalization of the Change we have proposed recently [2]
>
> So let me start with the problem:
>
> In Fedora now we have a well known and established process of how to
> deal with updates that bring new content through packages. There are
> ways to package new content side by side with the old one, to perform
> a non-disruptive testing, iterate and upgrade.
>
> What I think is missing is the way to safely iterate on the process,
> which happens after the content is packaged. Examples are: changes to
> buildroot configuration as in [2], changes in comps files, for example
> required for Minimization Objective [3], changes in compose building
> process, changes in Mass Rebuild and so on.
>

Yes! I felt that a few times in the past.

We know how to make our output evolve, how to introduce new RPM
versions and make other output-related changes. We test all updates
thanks to Bodhi, try and test bigger changes in side tags, etc. But we don't
really have a way to safely experiment with what makes it all
happen — the Fedora build system. And by "build system", I mean it in
the broadest sense, including Koji, compose, configurations, and
many other parts).

And that's exactly where things like improving packager experience in
an actual significant way (that requires some testing and iterations), or
performance tuning that affects compatibility — requiring all those
technical changes you've listed — happen. Or would happen!


> For such changes we have to use an all-or-nothing approach, which
> means we either implement the change too early or postpone it for too
> long.
>

... or don't have space to experiment with bigger changes, potentially
limiting
our ability to innovate. And when we try to, there is a high risk of
negatively
impacting our contributors, because, well, production is where the testing
happens.


> To add flexibility to the Fedora process, I’d like to propose the
> concept of alternative buildroots.
>

Alternative buildroots are a good start.

>
> --
> Note: The naming is hard here, and while I tend to call it
> “buildroot”, it actually needs to be called “alternative everything,
> except the srpms”.
>

Oh! Ok, that's exactly what I was hoping for and that's even a better start!
(Or, you know, all we need :D)


>
> I think we shouldn’t use the word “variant”, “spin”, “flavour” or
> something like that to describe it, as it is strictly the shared
> development playground linked to the latest Fedora Rawhide state and
> focused on the build and compose process. It is definitely not the
> alternative Fedora. It shouldn’t have releases on its own, it has no
> branches in the source code and it doesn’t target end-users.
> --
>
> The good thing is that, with the distributed CI approach we have
> implemented, we are ready to consume the feedback from such
> alternative setups in a non-blocking but informative way. I think we
> can extend our use of CI machinery so that it simplifies the
> development process for everyone, removing redundant heads-ups but
> increasing the targeted collaboration in places where it is actually
> needed.
>
> ### Use cases ###
>
> The first example of such a buildroot is provided by the CPU baseline
> testing [1].
>
> There will be more, since we may want to work on comps files for
> Minimization Objective.
>

As part of the objective, we avoided such changes as they're quite
disruptive.
I was actually thinking about trying those "somewhere" on the side, but
this proposal sounds like enabling this, done properly as part of our infra,
for everyone. Cool!


>
> There is also one particularly important case of the RHEL bootstrap:
> RHEL tries hard to inherit as much as possible from Fedora, but since
> both Fedora and RHEL have historically different build and compose
> configurations, it is often problematic to deal with dependency and
> build issues which arise from it. To the point that RHEL sometimes
> just can’t use Fedora as an origin, and needs to find its way around.
>
> The alternative buildroot targeting CentOS and RHEL would provide an
> open shared development environment. There we can work on converging
> the RHEL process to Fedora, and also on improving Fedora process with
> things, which RHEL and CentOS have discovered.
>
> ### Proposal ###
>
> This idea doesn’t quite fit into the Fedora Changes framework, as
> there is no actual change to Fedora. And we don't even have a concept
> of an Infrastructure Change at this point.


Infra Changes are an interesting concept for this.

One thing that struck my mind was... Testing alternative approaches
on the side without affecting people is not really a change. That said,
Changes we do for 

Fedora-Cloud-30-20200115.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1787288] perl-Text-Bidi-2.15-5.fc32 FTBFS: /builddir/build/BUILD/Text-Bidi-2.15/blib/arch/auto/Text/Bidi/private/private.so: undefined symbol: fribidi_log2vis_get_embedding_levels

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Text-Bidi-2.15-5.fc32
 Resolution|--- |RAWHIDE
Last Closed||2020-01-15 08:57:03



--- Comment #2 from Petr Pisar  ---
fribidi is fixed. I added an overlooked dependency.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Fedora-Cloud-31-20200115.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

[John M. Harris Jr]

On Friday, January 10, 2020 6:37:11 AM MST Chris Adams wrote:
> AVX2 is not a reasonable requirement as a replacement for the current
> Fedora x86_64, as there are CPUs still being made today that don't
> support that.

Relevant lines from /proc/cpuinfo

flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts nopl cpuid aperfmperf pni dtes64 monitor 
ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm pti tpr_shadow vnmi 
flexpriority dtherm ida

If we want to go by what's actually in use as well, instead of just new 
machines, I can get an even more restrictive list. Further, something not 
being made anymore is not reason to drop it. That makes no sense. Fedora users 
aren't going to toss their current, working, good machine just to find one 
with a processor you think is new enough. That's absurd.

-- 
John M. Harris, Jr.
Splentity

___
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 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

[John M. Harris Jr]

On Friday, January 10, 2020 8:09:18 AM MST Aleksandra Fedorova wrote:
> We are not proposing the new architecture. We are proposing a "staging
> environment" for the current architecture. Which can be used for
> experiments which currently can not be performed without disrupting
> the release and user experience.

Clearly, this is not about the current architecture, it is about a newer, 
Intel-specific, micro architecture.

[snip]

> Based on the impact described above, I wouldn't consider the change
> system-wide.
 
> But I think we touch an interesting topic here: It seems our
> definition of Change is quite limited and focused on packaged changes.
> And the work we propose doesn't really fit in this framework. I'm
> going to start a separate thread on it.

This will have affects across the entire distro, and would potentially require 
changes to a number of Packages to fix either compile-time or run-time issues.

-- 
John M. Harris, Jr.
Splentity

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

[Bug 1787288] perl-Text-Bidi-2.15-5.fc32 FTBFS: /builddir/build/BUILD/Text-Bidi-2.15/blib/arch/auto/Text/Bidi/private/private.so: undefined symbol: fribidi_log2vis_get_embedding_levels

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1787288
Bug 1787288 depends on bug 1787293, which changed state.

Bug 1787293 Summary: fribidi-1.0.8 removed 
fribidi_log2vis_get_embedding_levels() without bumping a soname
https://bugzilla.redhat.com/show_bug.cgi?id=1787293

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org