date:20230627

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



--- Comment #5 from Fedora Update System  ---
FEDORA-2023-45536c77fa has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2023-45536c77fa`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-45536c77fa

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2215893

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202215893%23c5
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2215893] perl-RDF-NS-20230619 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
FEDORA-2023-db4da4d358 has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2023-db4da4d358`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-db4da4d358

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2215893

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202215893%23c4
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2215815] perl-re-engine-RE2-0.18 is available

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



--- Comment #5 from Fedora Update System  ---
FEDORA-2023-6dd1799c92 has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2023-6dd1799c92`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-6dd1799c92

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2215815

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202215815%23c5
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

2023-06-27 Thread John Reiser

On 6/27/23 02:00, Miro Hrončok wrote:

On 26. 06. 23 20:24, Fabio Valentini wrote:

On Mon, Jun 26, 2023 at 8:10 PM Miro Hrončok  wrote:

(snip)

---

The current problem with Python without tzdata is:

===
  >>> from zoneinfo import ZoneInfo
  >>> ZoneInfo("Europe/Prague")
Traceback (most recent call last):
    ...
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key 
Europe/Prague'
===

Not that ZoneInfo("UTC") also fails:

===
  >>> ZoneInfo("UTC")
Traceback (most recent call last):
...
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key UTC'
===

So we would need to patch Python to detect missing tzdata and report something
like:

   ZoneInfoNotInstalledError: 'No time zone information installed on the system,
you can only use UTC'

We would also need to ensure UTC work even without tzdata installed.

I would be reluctant to carry this as a downstream-only patch. And the upstream
window for changes like this has already closed for Python 3.12.

Does this mean that tzdata needs to be present for doing datetime /
timezone calculations at runtime with the zoneinfo module?

Yes. That's why it is Required and not Recommended.

Would this Change require that all Python programs that use this
module add "Requires: tzdata"? I don't think that would be a
reasonable change.

Either that or adapt their code to fail in a reasonable way. Both sound quite 
unreasonable to me.

The case with LANG seems analogous.  If LANG is unset, then any software
should use the default LANG=C, and should work acceptably well.
If TZ is unset (or there is no other indication
of which timezone to use, or if the timezone data is unavailable)
then any software should use UTC, and should work acceptably well.
(In formal scientific work then UTC *is* the default timezone.)
For either unset LANG or missing timezone info, it is optional
for an application to emit a polite informative message *once* on stderr.
In particular, the zoneinfo module should handle all the details
so that individual applications need not bother.
.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a chance to phase out `/lib64` directory?

2023-06-27 Thread Kevin Kofler via devel

Kalev Lember wrote:
> I would like to have a layout similar to what Debian is doing, so that
> shared libraries would go in /usr/lib/x86_64-redhat-linux/ and /usr/lib64
> would be a legacy symlink pointing to it.

That layout is NOT compliant with the FHS.

Which is particularly hilarious as Debian has long refused to use 
/usr/libexec (despite GNU having had it for ages, and Debian's refusal has 
in turn lead several upstreams to not or poorly support it and abuse 
/usr/lib or other directories for its purpose instead) because it was 
purportedly against the FHS (it seems they have never noticed that the 
clause that allows lib64 and lib32 does not actually require the suffix to 
be a number, "exec" is a perfectly fine suffix, so libexec is just another 
lib64/lib32-type directory), but was very fast to add an exception for this 
new entirely non-standard layout. (The FHS requires the arch-specific libdir 
variants to be suffixed sibling directories of lib, NOT subdirectories.)

> That kind of layout would make it much easier to do cross compilation
> because you could just take the whole /usr/lib/another-host-triplet/
> directory from another architecture without it interfering with the host
> libraries and use it for cross compilation purposes.

Practical cross-compilation to a completely different architecture needs 
sysroots anyway. That way, one can also easily target a different 
distribution on a different (or even the same) architecture, not just Fedora 
on a different architecture.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)

2023-06-27 Thread Jonathan Steffan

On Mon, Jun 26, 2023 at 8:34 AM Aoife Moloney  wrote:

> [...]
> Pungi and Koji already support Image Builder, so no additional work is
> required there (refer to the
> [
> https://docs.pagure.org/pungi/configuration.html#osbuild-composer-for-building-images
> pungi] and [https://github.com/osbuild/koji-osbuild/ koji]
> documentation). The only missing part in terms of infrastructure is
> provisioning ppc64le worker machines for Image Builder, see the
> relevant [https://pagure.io/fedora-infrastructure/issue/11243
> fedora-infra ticket].
>
> Note that Image Builder is already used for
> [https://fedoraproject.org/wiki/Changes/IoTArtifactsWithOSBuild
> building ISOs and raw disks of Fedora IoT]. Therefore, this proposal
> does not introduce a new tool to the Fedora build pipeline.
>

The Koji integration leaves many things to be desired. I've had to dig far
more than needed for osbuildimage stuff.

For example,
https://koji.fedoraproject.org/koji/tasks?state=all=tree=osbuildImage=-id
is nearly useless to know what is going on. You have to go into each task
to find what you are looking for and you end up with some json logs
https://koji.fedoraproject.org/koji/taskinfo?taskID=102669680 and
ultimately finding a link to the build
https://koji.fedoraproject.org/koji/buildinfo?buildID=653 to get to the
image. Maybe I'm just using it wrong, but I've not found a different way.

Compare that confusion to something as useful as the image builds at
https://koji.fedoraproject.org/koji/builds?type=image=-build_id where
you know exactly what everythign is and a single click on a build
https://koji.fedoraproject.org/koji/buildinfo?buildID=698 gives me
logs, isos, and all artifacts I'm interested in looking at.

Please include improving the Koji integration before making this change.
Those of use that spelunk around the automatic image creation would be
greatly appreciative.

-- 
Jonathan Steffan
jonathanstef...@gmail.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

2023-06-27 Thread Jonathan Steffan

On Mon, Jun 26, 2023 at 10:01 AM Aoife Moloney  wrote:

> == Summary ==
> The new PatternFly-based UI has been developed by the Anaconda team
> for some time now and we would like to make it available for users of
> Fedora to enhance and modernize installation experience. As the first
> step in this user adoption process, we are targeting Fedora
> Workstation only.

I was pleasantly surprised with the progress here based on the test image I
randomly stumbled upon this year. It's a big change from the familiar and
should be treated as such.

Does it make more sense to focus efforts on releasing an official
alternative Workstation install ISO? Generally, when you make people feel
like they are forced to change it's more likely to cause frustration. We
could make this more a celebration, a special access/preview to what is
next, and attract testers on https://fedoraproject.org/workstation/ with
some simple messaging. Completely understood that this would add yet
another QA target and that might be more burdensome than it's worth.

If changing the default install experience is the main goal, we should
start producing install media as soon as possible and promote it through
the F38 cycle. Maybe as part of the respin process in F38. The more
comfortable everyone is with this change, before the F39 release day, the
more likely this change will be well received.

-- 
Jonathan Steffan
jonathanstef...@gmail.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Unretire python-diskcache

2023-06-27 Thread Benson Muite

Would like to unretire Python-diskcache
https://bugzilla.redhat.com/show_bug.cgi?id=2215710
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

2023-06-27 Thread Miro Hrončok


On 27. 06. 23 21:37, Maxwell G wrote:



If your package is failing with ModuleNotFoundError: No module named
'imp', this is happening because Python 3.12 removed the long deprecated
imp module. As a stopgap measure, you can BuildRequire
python3-zombie-imp package, which allows you to import the imp module
even on Python 3.12. We strongly recommend talking to upstream and
encouraging them to migrate to importlib instead.


The package has `Provides: deprecated()` so that cannot be done without
violating policy.


The idea is that packages that already use (deprecated) imp can migrate to this 
as a stop gap measure. But no new packages should depend on this.


We could *not deprecate* it instead and submit a change proposal to deprecate 
it later, but that seems rather useless.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

2023-06-27 Thread Miro Hrončok


On 27. 06. 23 21:37, Maxwell G wrote:



If your package is failing with ModuleNotFoundError: No module named
'imp', this is happening because Python 3.12 removed the long deprecated
imp module. As a stopgap measure, you can BuildRequire
python3-zombie-imp package, which allows you to import the imp module
even on Python 3.12. We strongly recommend talking to upstream and
encouraging them to migrate to importlib instead.


The package has `Provides: deprecated()` so that cannot be done without
violating policy.


The idea is that packages that already use (deprecated) imp can migrate to this 
as a stop gap measure. But no new packages should depend on this.


We could *not deprecate* it instead and submit a change proposal to deprecate 
it later, but that seems rather useless.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

2023-06-27 Thread Patsy Griffin

Hi Miro,

Very much appreciate the feedback. Please see my responses below.

Thank you,
Patsy

On Mon, Jun 26, 2023 at 2:09 PM Miro Hrončok  wrote:

> Hello Patsy,
>
> On 26. 06. 23 17:54, Aoife Moloney wrote:
> > https://fedoraproject.org/wiki/Changes/AllowRemovalOfTzdata
> >
> > == Summary ==
> > Allow the removal of tzdata especially on containers in order to
> minimize size.
> > ...
> >
> > In order for this to work, we need packages that use tzdata at run
> > time to switch from Require'ing tzdata to Recommend'ing tzdata.  These
> > packages should also gracefully handle instances where tzdata has been
> > removed.  For example, this would require recognizing that tzdata is
> > not present and providing an appropriate error, such as recommending
> > that the user install tzdata.
> > ...
> > * python3.XX (3.9, 3.10, 3.11, 3.12)
>
> Who is expected to work on this? Python maintainers or this Change
> proposal owners?
>


This does not change the default.  It allows users to remove tzdata if they
want to minimize their container.  (Note: currently we are seeing cases
where just the data is removed leaving tzdata in an inconsistent state.)

We will work with maintainers as needed.  The respective package owners are
more knowledgeable in the changes needed to check for the availability of
tzdata and respond appropriately, such as informing the user that tzdata
needs to be installed.


> *PEP 615 – Support for the IANA Time Zone Database in the Standard
> Library* says:
>
>
> """
> Python distributors are encouraged to ensure that time zone data is
> installed
> alongside Python whenever possible (e.g. by declaring tzdata as a
> dependency
> for the python package).
> """
>
> from https://peps.python.org/pep-0615/#system-time-zone-information
>
>
> By changing the Requires to Recommends, we would diverge from upstream
> recommendation.
>
> ---
>
> The current problem with Python without tzdata is:
>
> ===
>  >>> from zoneinfo import ZoneInfo
>  >>> ZoneInfo("Europe/Prague")
> Traceback (most recent call last):
>File "/usr/lib64/python3.11/zoneinfo/_common.py", line 12, in
> load_tzdata
>  return
> resources.files(package_name).joinpath(resource_name).open("rb")
> ^
>File "/usr/lib64/python3.11/importlib/resources/_common.py", line 22,
> in files
>  return from_package(get_package(package))
>  
>File "/usr/lib64/python3.11/importlib/resources/_common.py", line 53,
> in
> get_package
>  resolved = resolve(package)
> 
>File "/usr/lib64/python3.11/importlib/resources/_common.py", line 44,
> in resolve
>  return cand if isinstance(cand, types.ModuleType) else
> importlib.import_module(cand)
>
> ^
>File "/usr/lib64/python3.11/importlib/__init__.py", line 126, in
> import_module
>  return _bootstrap._gcd_import(name[level:], package, level)
> 
>File "", line 1204, in _gcd_import
>File "", line 1176, in _find_and_load
>File "", line 1126, in
> _find_and_load_unlocked
>File "", line 241, in
> _call_with_frames_removed
>File "", line 1204, in _gcd_import
>File "", line 1176, in _find_and_load
>File "", line 1126, in
> _find_and_load_unlocked
>File "", line 241, in
> _call_with_frames_removed
>File "", line 1204, in _gcd_import
>File "", line 1176, in _find_and_load
>File "", line 1140, in
> _find_and_load_unlocked
> ModuleNotFoundError: No module named 'tzdata'
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>File "", line 1, in 
>File "/usr/lib64/python3.11/zoneinfo/_common.py", line 24, in
> load_tzdata
>  raise ZoneInfoNotFoundError(f"No time zone found with key {key}")
> zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key
> Europe/Prague'
> ===
>
> Not that ZoneInfo("UTC") also fails:
>
> ===
>  >>> ZoneInfo("UTC")
> Traceback (most recent call last):
> ...
> zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key UTC'
> ===
>
> So we would need to patch Python to detect missing tzdata and report
> something
> like:
>
>   ZoneInfoNotInstalledError: 'No time zone information installed on the
> system,
> you can only use UTC'
>

 Yes, or possibly recommend installing tzdata if additional timezone info
is needed.


> We would also need to ensure UTC work even without tzdata installed.
>
> I would be reluctant to carry this as a downstream-only patch. And the
> upstream
> window for changes like this has already closed for Python 3.12.
>

Understood.


>
> --

Re: cups-2.4.2-11.fc39.src.rpm depends on autoconf-2.71 or newer, not mentioned in .spec file, fails build

2023-06-27 Thread Jan Pazdziora

On Sun, Mar 26, 2023 at 02:44:34PM +0300, ijaaskelai...@outlook.com wrote:
> Kind regards, The Improvement Skeleton.

Please show the exact steps you use to build the cups package and the
exact error message you get.

Technically you are correct because configure.ac has AC_PREREQ([2.71]).
But autoconf is pulled in by the automake which is listed as BuildRequires
in cups.spec file, and since Fedora rawhide only has
autoconf-2.71-5.fc38.noarch, there really is not an older autoconf around
to ruin your day.

-- 
Jan Pazdziora | Sr. Principal Software Engineer | Red Hat 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: orphaned packages


On 6/27/23 17:46, Simon de Vlieger wrote:

Hi,

I've orphaned some packages that I am too unfamiliar with to maintain, 
especially
now that these are mostly FTBS/FTI and have unmaintained upstreams:

- preproc: https://src.fedoraproject.org/rpms/preproc
- preproc-rpmspec: https://src.fedoraproject.org/rpms/preproc-rpmspec
- rpkg-macros: https://src.fedoraproject.org/rpms/rpkg-macros
- rpkg-util: https://src.fedoraproject.org/rpms/rpkg-util
- rpm-git-tag-sort: https://src.fedoraproject.org/rpms/rpm-git-tag-sort


I've added two more packages to the list I'm orphaning, these have 
unmaintained upstreams and don't fit with my current knowledge or interests.


- python-django-contact-form: 
https://src.fedoraproject.org/rpms/python-django-contact-form
- python-django-robots: 
https://src.fedoraproject.org/rpms/python-django-robots

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

2023-06-27 Thread Kevin Fenzi

On Tue, Jun 27, 2023 at 07:37:13PM +, Maxwell G wrote:
> 
> > If your package is failing with ModuleNotFoundError: No module named
> > 'imp', this is happening because Python 3.12 removed the long deprecated
> > imp module. As a stopgap measure, you can BuildRequire
> > python3-zombie-imp package, which allows you to import the imp module
> > even on Python 3.12. We strongly recommend talking to upstream and
> > encouraging them to migrate to importlib instead.
> 
> The package has `Provides: deprecated()` so that cannot be done without
> violating policy.
> 
> > python-IPy   kevin
> 
> https://src.fedoraproject.org/rpms/python-IPy/pull-request/1

Merged, built in f39-python and python-packager-sig added
> 
> 
> > python-chai  kevin pingou
> 
> https://src.fedoraproject.org/rpms/python-chai/pull-request/3

Merged, built in f39-python and python-packager-sig added

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

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

2023-06-27 Thread Tomáš Hrnčiar


Hello,

I'd like to provide an update on Python 3.12 mass rebuild.

The mass rebuild is still in progress. So far 2666 packages were rebuilt 
in side tag which is about 65,8% out of 4049 python packages. We are now 
working on fixing important packages blocking others.


As mentioned in previous email - if you see a "Rebuilt for Python 3.12" 
(or similar) commit in your package, please don't rebuild it in regular 
rawhide or another rawhide side tag. If you need to, please let us know, 
so we can coordinate.


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


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

Note that it will take a while before all the essential packages are 
rebuilt, so don't expect all your dependencies to be available right 
away. Please, don't attempt to build your package in the side tag before 
we do.
When in trouble, ask here or on IRC (#fedora-python on Libera.Chat). 
Ping me (thrnciar) or Miro (mhroncok) if you need to talk to us.


Builds: 
https://koji.fedoraproject.org/koji/builds?latest=0=f39-python=-build_id=0


Please avoid any potentially disturbing or major changes in Python 
packages until the rebuild is over.


Thanks. Let us know if you have any questions.

Here is the list of packages that failed to build but their dependencies 
are available. If you'd like to help us, any fixes are welcome. Please 
build the package with --target=f39-python if you fix it.


If your package is failing with ModuleNotFoundError: No module named 
'imp', this is happening because Python 3.12 removed the long deprecated 
imp module. As a stopgap measure, you can BuildRequire 
python3-zombie-imp package, which allows you to import the imp module 
even on Python 3.12. We strongly recommend talking to upstream and 
encouraging them to migrate to importlib instead.


Maintainers by package:
NFStest  ajmitchell steved
Zim  cheeselee ohaessler
andriller    fab
appliance-tools  ngompa
aubio    nphilipp tartina
awake    fab
awscli2  davdunc nforro
b43-tools    pwalter
beaker   martstyk
binwalk  ajax swt2c
borgbackup   fschwarz
botan2   bkircher thm
brd  jsbackus
btest    fab
cdist    fnux
classification-banner rga
condor   bcotton matyas ttheisen valtri
criu adrian rstoyanov
cxxtest  mgieseki
dionaea  rebus
distgen  hhorak phracek pkubat praiskup zmiklank
dnf-plugin-diff  praiskup
dnf-plugins-extras   dmach jmracek mblaha pkratoch
dtc  arnd bonzini jwboyer pbrobinson
electron-cash    jonny
elements aalvarez
emacs-jedi   melmorabity
eric rdieter
fail2ban atkac hobbes1069 orion tmz
fedora-gather-easyfix pingou
flann    rmattes
flatpak-module-tools kalev otaylor
fonts-tweak-tool tagoh
future   sagitter
gaupol   music
gfal2-python jonathanspw mipatras
gnome-doc-utils  alexl caolanm limb rhughes rstrode
h5py orion stevetraylen terjeros
i2c-tools    ajax jorton jzerdik olysonek
kernel-tools acaringi jforbes jwboyer lgoncalv patrickt pbrobinson
kicad    avigne lkundrak stevenfalco
kitty    atim jonathanspw salimma solopasha zawertun
lammps   cz4rs ellio167 junghans rberger
lensfun  germano grahamwhiteuk nphilipp ohaessler rdieter trix
libffado nphilipp
libfreenect  jkastner kathenas kwizart rmattes
libnl3   dcbw jirka thaller
libssh2-python   clalance
lilv nphilipp tartina
livecd-tools bcl bruno ngompa
lvm2 agk bmarzins bmr cfeist kzak lvm-team mauelsha 
mbroz mcsontos pjones prajnoha zkabelac

m2crypto mitr ngompa
manafirewall ngompa thunderbirdtr
mercurial    kiilerix nbecker pstodulk
mrchem   jussilehtola
oct2spec orion
offlineimap  cicku dodji sergesanspaille teuf
onboard  yanqiyu
pam_wrapper  asn jhrozek
pdc-client   kevin lholecek lsedlar nphilipp
pdf-stapler  aarem raphgro
photoqt  eischmann
py-radix kevin
pyflowtools  stingray
pyftpdlib    aekoroglu
pygsl    jamatos
pyke spot
pyodbc   fjanus hhorak osloup
pyosmium tomh
python-GridDataFormats rathann
python-IPy   kevin
python-PyPDF2    aarem
python-acora fab
python-aiofiles  ankursinha
python-aiosmtpd  abompard
python-aiozeroconf   fab
python-alarmdecoder  fab
python-annexremote   ankursinha
python-ansi  sdyroff
python-ansible-pygments chedi
python-ansiwrap  fab
python-apsw  cicku dfateyev maci

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

2023-06-27 Thread Maxwell G




If your package is failing with ModuleNotFoundError: No module named
'imp', this is happening because Python 3.12 removed the long 
deprecated

imp module. As a stopgap measure, you can BuildRequire
python3-zombie-imp package, which allows you to import the imp module
even on Python 3.12. We strongly recommend talking to upstream and
encouraging them to migrate to importlib instead.


The package has `Provides: deprecated()` so that cannot be done without
violating policy.


python-IPy   kevin


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



python-chai  kevin pingou


https://src.fedoraproject.org/rpms/python-chai/pull-request/3

--
Maxwell G (@gotmax23)
Pronouns: He/They
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

2023-06-27 Thread Maxwell G




If your package is failing with ModuleNotFoundError: No module named
'imp', this is happening because Python 3.12 removed the long 
deprecated

imp module. As a stopgap measure, you can BuildRequire
python3-zombie-imp package, which allows you to import the imp module
even on Python 3.12. We strongly recommend talking to upstream and
encouraging them to migrate to importlib instead.


The package has `Provides: deprecated()` so that cannot be done without
violating policy.


python-IPy   kevin


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



python-chai  kevin pingou


https://src.fedoraproject.org/rpms/python-chai/pull-request/3

--
Maxwell G (@gotmax23)
Pronouns: He/They
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

2023-06-27 Thread Tomáš Hrnčiar


Hello,

I'd like to provide an update on Python 3.12 mass rebuild.

The mass rebuild is still in progress. So far 2666 packages were rebuilt 
in side tag which is about 65,8% out of 4049 python packages. We are now 
working on fixing important packages blocking others.


As mentioned in previous email - if you see a "Rebuilt for Python 3.12" 
(or similar) commit in your package, please don't rebuild it in regular 
rawhide or another rawhide side tag. If you need to, please let us know, 
so we can coordinate.


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


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

Note that it will take a while before all the essential packages are 
rebuilt, so don't expect all your dependencies to be available right 
away. Please, don't attempt to build your package in the side tag before 
we do.
When in trouble, ask here or on IRC (#fedora-python on Libera.Chat). 
Ping me (thrnciar) or Miro (mhroncok) if you need to talk to us.


Builds: 
https://koji.fedoraproject.org/koji/builds?latest=0=f39-python=-build_id=0


Please avoid any potentially disturbing or major changes in Python 
packages until the rebuild is over.


Thanks. Let us know if you have any questions.

Here is the list of packages that failed to build but their dependencies 
are available. If you'd like to help us, any fixes are welcome. Please 
build the package with --target=f39-python if you fix it.


If your package is failing with ModuleNotFoundError: No module named 
'imp', this is happening because Python 3.12 removed the long deprecated 
imp module. As a stopgap measure, you can BuildRequire 
python3-zombie-imp package, which allows you to import the imp module 
even on Python 3.12. We strongly recommend talking to upstream and 
encouraging them to migrate to importlib instead.


Maintainers by package:
NFStest  ajmitchell steved
Zim  cheeselee ohaessler
andriller    fab
appliance-tools  ngompa
aubio    nphilipp tartina
awake    fab
awscli2  davdunc nforro
b43-tools    pwalter
beaker   martstyk
binwalk  ajax swt2c
borgbackup   fschwarz
botan2   bkircher thm
brd  jsbackus
btest    fab
cdist    fnux
classification-banner rga
condor   bcotton matyas ttheisen valtri
criu adrian rstoyanov
cxxtest  mgieseki
dionaea  rebus
distgen  hhorak phracek pkubat praiskup zmiklank
dnf-plugin-diff  praiskup
dnf-plugins-extras   dmach jmracek mblaha pkratoch
dtc  arnd bonzini jwboyer pbrobinson
electron-cash    jonny
elements aalvarez
emacs-jedi   melmorabity
eric rdieter
fail2ban atkac hobbes1069 orion tmz
fedora-gather-easyfix pingou
flann    rmattes
flatpak-module-tools kalev otaylor
fonts-tweak-tool tagoh
future   sagitter
gaupol   music
gfal2-python jonathanspw mipatras
gnome-doc-utils  alexl caolanm limb rhughes rstrode
h5py orion stevetraylen terjeros
i2c-tools    ajax jorton jzerdik olysonek
kernel-tools acaringi jforbes jwboyer lgoncalv patrickt pbrobinson
kicad    avigne lkundrak stevenfalco
kitty    atim jonathanspw salimma solopasha zawertun
lammps   cz4rs ellio167 junghans rberger
lensfun  germano grahamwhiteuk nphilipp ohaessler rdieter trix
libffado nphilipp
libfreenect  jkastner kathenas kwizart rmattes
libnl3   dcbw jirka thaller
libssh2-python   clalance
lilv nphilipp tartina
livecd-tools bcl bruno ngompa
lvm2 agk bmarzins bmr cfeist kzak lvm-team mauelsha 
mbroz mcsontos pjones prajnoha zkabelac

m2crypto mitr ngompa
manafirewall ngompa thunderbirdtr
mercurial    kiilerix nbecker pstodulk
mrchem   jussilehtola
oct2spec orion
offlineimap  cicku dodji sergesanspaille teuf
onboard  yanqiyu
pam_wrapper  asn jhrozek
pdc-client   kevin lholecek lsedlar nphilipp
pdf-stapler  aarem raphgro
photoqt  eischmann
py-radix kevin
pyflowtools  stingray
pyftpdlib    aekoroglu
pygsl    jamatos
pyke spot
pyodbc   fjanus hhorak osloup
pyosmium tomh
python-GridDataFormats rathann
python-IPy   kevin
python-PyPDF2    aarem
python-acora fab
python-aiofiles  ankursinha
python-aiosmtpd  abompard
python-aiozeroconf   fab
python-alarmdecoder  fab
python-annexremote   ankursinha
python-ansi  sdyroff
python-ansible-pygments chedi
python-ansiwrap  fab
python-apsw  cicku dfateyev maci

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

2023-06-27 Thread Tomáš Hrnčiar


Hello,

I'd like to provide an update on Python 3.12 mass rebuild.

The mass rebuild is still in progress. So far 2666 packages were rebuilt 
in side tag which is about 65,8% out of 4049 python packages. We are now 
working on fixing important packages blocking others.


As mentioned in previous email - if you see a "Rebuilt for Python 3.12" 
(or similar) commit in your package, please don't rebuild it in regular 
rawhide or another rawhide side tag. If you need to, please let us know, 
so we can coordinate.


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


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

Note that it will take a while before all the essential packages are 
rebuilt, so don't expect all your dependencies to be available right 
away. Please, don't attempt to build your package in the side tag before 
we do.
When in trouble, ask here or on IRC (#fedora-python on Libera.Chat). 
Ping me (thrnciar) or Miro (mhroncok) if you need to talk to us.


Builds: 
https://koji.fedoraproject.org/koji/builds?latest=0=f39-python=-build_id=0


Please avoid any potentially disturbing or major changes in Python 
packages until the rebuild is over.


Thanks. Let us know if you have any questions.

Here is the list of packages that failed to build but their dependencies 
are available. If you'd like to help us, any fixes are welcome. Please 
build the package with --target=f39-python if you fix it.


If your package is failing with ModuleNotFoundError: No module named 
'imp', this is happening because Python 3.12 removed the long deprecated 
imp module. As a stopgap measure, you can BuildRequire 
python3-zombie-imp package, which allows you to import the imp module 
even on Python 3.12. We strongly recommend talking to upstream and 
encouraging them to migrate to importlib instead.


Maintainers by package:
NFStest  ajmitchell steved
Zim  cheeselee ohaessler
andriller    fab
appliance-tools  ngompa
aubio    nphilipp tartina
awake    fab
awscli2  davdunc nforro
b43-tools    pwalter
beaker   martstyk
binwalk  ajax swt2c
borgbackup   fschwarz
botan2   bkircher thm
brd  jsbackus
btest    fab
cdist    fnux
classification-banner rga
condor   bcotton matyas ttheisen valtri
criu adrian rstoyanov
cxxtest  mgieseki
dionaea  rebus
distgen  hhorak phracek pkubat praiskup zmiklank
dnf-plugin-diff  praiskup
dnf-plugins-extras   dmach jmracek mblaha pkratoch
dtc  arnd bonzini jwboyer pbrobinson
electron-cash    jonny
elements aalvarez
emacs-jedi   melmorabity
eric rdieter
fail2ban atkac hobbes1069 orion tmz
fedora-gather-easyfix pingou
flann    rmattes
flatpak-module-tools kalev otaylor
fonts-tweak-tool tagoh
future   sagitter
gaupol   music
gfal2-python jonathanspw mipatras
gnome-doc-utils  alexl caolanm limb rhughes rstrode
h5py orion stevetraylen terjeros
i2c-tools    ajax jorton jzerdik olysonek
kernel-tools acaringi jforbes jwboyer lgoncalv patrickt pbrobinson
kicad    avigne lkundrak stevenfalco
kitty    atim jonathanspw salimma solopasha zawertun
lammps   cz4rs ellio167 junghans rberger
lensfun  germano grahamwhiteuk nphilipp ohaessler rdieter trix
libffado nphilipp
libfreenect  jkastner kathenas kwizart rmattes
libnl3   dcbw jirka thaller
libssh2-python   clalance
lilv nphilipp tartina
livecd-tools bcl bruno ngompa
lvm2 agk bmarzins bmr cfeist kzak lvm-team mauelsha 
mbroz mcsontos pjones prajnoha zkabelac

m2crypto mitr ngompa
manafirewall ngompa thunderbirdtr
mercurial    kiilerix nbecker pstodulk
mrchem   jussilehtola
oct2spec orion
offlineimap  cicku dodji sergesanspaille teuf
onboard  yanqiyu
pam_wrapper  asn jhrozek
pdc-client   kevin lholecek lsedlar nphilipp
pdf-stapler  aarem raphgro
photoqt  eischmann
py-radix kevin
pyflowtools  stingray
pyftpdlib    aekoroglu
pygsl    jamatos
pyke spot
pyodbc   fjanus hhorak osloup
pyosmium tomh
python-GridDataFormats rathann
python-IPy   kevin
python-PyPDF2    aarem
python-acora fab
python-aiofiles  ankursinha
python-aiosmtpd  abompard
python-aiozeroconf   fab
python-alarmdecoder  fab
python-annexremote   ankursinha
python-ansi  sdyroff
python-ansible-pygments chedi
python-ansiwrap  fab
python-apsw  cicku dfateyev maci

Re: orphaned packages

2023-06-27 Thread Kevin Fenzi

On Tue, Jun 27, 2023 at 05:48:06PM +0200, Simon de Vlieger wrote:
> Side-question: am I supposed to do anything with Bugzilla's currently related
> to these packages that are assigned to me? (unassign/assign to orphan?).

You shouldn't have to. Automation should come along and reassign them.

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

Re: F39 Change Proposal: LLVM 17 (System-Wide)

2023-06-27 Thread Tom Stellard


On 6/27/23 04:06, Vitaly Zaitsev via devel wrote:

On 27/06/2023 03:21, Tom Stellard wrote:

For this update, we're going to let package maintainers be responsible for
rebuilding their own packages if they are unable to use the compat libraries
for some reason.  We can try to send an announcement when the side-tag is ready.


Some package maintainers are too lazy. They won't do anything even if you 
inform them in the ML.

Check my last year's fmt 9.0 update:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/FOESCVXNAHV2OATO36UIACIE3BQGMMR5/

I think it will be better to rebuild all dependent packages in a side tag.



Most packages don't need rebuilds and are just fine using the compat packages,
so there isn't a need to rebuild everything, but if packagers want to rebuild
along with the LLVM update they are welcome to do it in the side-tag.

There are a few packages that we know can't use the compat builds, and in those
cases, we'll try to do scratch builds early on and report issues to the 
maintainer,
and build them into the side-tag once they are working.

-Tom
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2217660] perl-Log-Any-1.716 is available

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

Xavier Bachelot  changed:

   What|Removed |Added

 Depends On||2217967
   Doc Type|--- |If docs needed, set a value





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2217967
[Bug 2217967] Review Request: perl-Devel-StackTrace-Extract - Extract a stack
trace from an exception object
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2217660
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: SIG proposal: libreoffice-sig

2023-06-27 Thread Mattia Verga via devel

Greetings folks,
the libreoffice-sig is now live.
Anyone interested can join the `#libreoffice-sig:fedoraproject.org` matrix room 
for discussion. If you're a packager and like to help maintain LO and related 
packages, you can ask to join the 
https://accounts.fedoraproject.org/group/libreoffice-sig/ FAS group.

If you maintain a LO package or any dependency, you're invited to add commit 
(or admin) access for libreoffice-sig group to your package and change the 
default bugzilla assignee to libreoffice-sig group. This will make BZ emails be 
sent to the libreoffice-...@lists.fedoraproject.org mailing list which you're 
also encouraged to join (this list is set as private as the only purpose is for 
BZ related activity; for active discussions please use the matrix room).

That should be all, let me know if I have forgot something important.
Thanks to all for your work in supporting Libreoffice RPM packaging in Fedora!

Mattia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Red Hat & Fedora -- largely stepping out of this ecosystem

2023-06-27 Thread Frank Ch. Eigler


Jeff Law  writes:

> [...]
> First a bit of background.  I came to Red Hat via the Cygnus
> acquisition.  [...]
>
> One could see signs of where this was going with the adjustments that
> were made to the exposed RHEL kernel sources some time ago.  Then the
> dissolution of CentOS a couple years back and most recently with the
> lockdown of the RHEL sources.
>
> What Red Hat has done may be technically legal and perhaps good for
> its business.  However, to me it's ethically unconscionable.   [...]

Could you elaborate how you see RH's new policy w.r.t. RHEL sources
being different from Cygnus's policy w.r.t. GnuPro sources?


- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Red Hat & Fedora -- largely stepping out of this ecosystem

2023-06-27 Thread Carlos Rodriguez-Fernandez

The distros that provide commercial support beside RedHat have been sort
of doing something similar. Canonical provides Ubuntu LTS, a distro with
5 years of development, and then additional 5 years of maintenance for
those with subscription. SUSE, also, 5 years major release support for
OpenSUSE where there is continuous development, and then if you want the
full 10 years (with the additional 5 years of maintenance), you would
choose SUSE Enterprise and paid the subscription fee.

Debian provides only 5 years cycle, and no support after that at all.

Red Hat is stopping the free 10 years cycle support provided by clones,
and going the same route other distros are already in. The difference
with RedHat is the fact that their free 5 years cycle distro (centos
stream) is a tiny bit ahead of their subscription 10 years one (rhel). I
personally don't see it as a deal breaker difference.

Am I missing something about the other distros?

I'm using CentOS Stream 9 hardened in production-level servers, and also
in personal servers. The tooling, the community maturity, and the
SELinux support of Enterprise Linux is much better than the alternative
in my opinion.

I use Fedora for my personal workstation and my kid's computer, and what
I love the most about Fedora is how it has become the vanguard in
innovation among Linux distros.

RedHat is just being a for-profit company, aligning itself with the rest
of Linux distros supported by a company. The only main difference is
that their "free tier" is slightly ahead of their Enterprise
subscription one. It depends how big of a deal that really becomes going
forward, but so far I don't see indications that it will be a big deal.
They have broken both in the past, the free and the paid.

Their contributions to opensource won't stop. The innovation in Fedora
won't stop either. Jeff, I hope you reconsider your decision.

Regards,
Carlos R.F.

On 6/27/23 07:40, Peter Boy wrote:

Thanks for your writing. A well-balanced and very thoughtful and considered
opinion. But your final decision seems to me rather a short-coming.

Am 27.06.2023 um 00:47 schrieb Jeff Law :

...

What Red Hat has done recently is depressing, but not a huge surprise to me. Red Hat struggled
repeatedly with how to deal with "the clones". The core idea I always came back to in
those discussions was that the value isn't in the bits, but in the stability, services and
ecosystem Red Hat enables around the bits. Arguments for protecting the bits were met with
something like "if that's what we need to do to be successful, then we're failing to provide
real value".

At some point in the last 20 years (I forget exactly when) Red Hat was looking
to codify its values. Naturally the topic of open source came up during those
discussions. When open source didn't make the cut, one could say the writing
was on the wall -- open source was a means to an end. In my mind that opened
the door for numerous changes we've seen in subsequent years.

One could see signs of where this was going with the adjustments that were made
to the exposed RHEL kernel sources some time ago. Then the dissolution of
CentOS a couple years back and most recently with the lockdown of the RHEL
sources.

What Red Hat has done may be technically legal and perhaps good for its
business. However, to me it's ethically unconscionable. Those who know me
know I'm not an zealot, but I do have a baseline set of ethical values and Red
Hat crossed that line.

I think there is a difference regarding the clones.

When Red Hat cancelled the academic licenses I switched all the servers I was responsible
for to Scientific Linux, one of the clones. As a public funded University we simply
couldn’t afford the new prices. And there was no such thing as "customers" for
us to pass on higher costs to. The results of our work are available to the company free
of charge.

But cases like OracleLinux, where a commercial company takes another company's
work and uses it to throw a competing commercial product on the market, are
something else, entirely. And they are to be evaluated differently beyond legal
licensing issues.

And as much as I disapprove of Red Hat's decisions that led to the end of
ScientificLinux, at the same time I can kind of understand it. But more
differentiation of such circumstances would have been better.

Perhaps it is a quandary, unsolvable without compromise.

...

I've been a Fedora user since before FC1. I run Fedora on my laptop. When I
need a docker image for something, I start with a Fedora image. When I need to
spin up a server (say to run the GCC CI/CD system) I load it with Fedora.
It's an ecosystem I'm technically comfortable in and easiest for me to utilize.

That will change across the board this summer. That's a bit hard for me to
swallow, but I can't get past that association we built between Red Hat and
Fedora and Red Hat's recent actions.

I'll still have to

[EPEL-devel] Re: Orphaning packages

2023-06-27 Thread Jonathan Wright via epel-devel

Lance,

I can sponsor/mentor you.  I'll reach out to ya via Mattermost.

On Tue, Jun 27, 2023 at 10:51 AM Lance Albertson  wrote:

>
>
> On Thu, Jun 22, 2023 at 9:50 AM Othman Madjoudj 
> wrote:
>
>> Hello,
>>
>> Please note that I've orphaned by packages, list in the end of the
>> message.
>>
>> Best regards
>> -Othman
>>
>>  rpms/mod_limitipconn
>>
>
> I'm interested in maintaining this but I am not a packager yet and would
> need to be onboarded if someone is willing to be a mentor.
>
> Thanks-
>
> --
> Lance Albertson
> Director
> Oregon State University | Open Source Lab
> ___
> 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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


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

Re: [EPEL-devel] Re: Orphaning packages

2023-06-27 Thread Jonathan Wright via devel

Lance,

I can sponsor/mentor you.  I'll reach out to ya via Mattermost.

On Tue, Jun 27, 2023 at 10:51 AM Lance Albertson  wrote:

>
>
> On Thu, Jun 22, 2023 at 9:50 AM Othman Madjoudj 
> wrote:
>
>> Hello,
>>
>> Please note that I've orphaned by packages, list in the end of the
>> message.
>>
>> Best regards
>> -Othman
>>
>>  rpms/mod_limitipconn
>>
>
> I'm interested in maintaining this but I am not a packager yet and would
> need to be onboarded if someone is willing to be a mentor.
>
> Thanks-
>
> --
> Lance Albertson
> Director
> Oregon State University | Open Source Lab
> ___
> epel-devel mailing list -- epel-de...@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-de...@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee

2023-06-27 Thread tdawson

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2023-06-28 from 16:00:00 to 17:00:00 US/Eastern
   At fedora-meet...@irc.libera.chat

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting.

A general agenda is the following:

#topic aloha

#topic EPEL Issues https://pagure.io/epel/issues
* https://pagure.io/epel/issues?tags=meeting=Open

#topic Old Business (if needed)

#topic General Issues / Open Floor




Source: https://calendar.fedoraproject.org//meeting/9854/

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

Re: F39 Change Proposal: LLVM 17 (System-Wide)

2023-06-27 Thread Tom Stellard


On 6/27/23 04:00, Vitaly Zaitsev via devel wrote:

On 27/06/2023 03:19, Tom Stellard wrote:


We're trying to be more consistent with gcc and also upstream clang.
gcc installs some of these same libraries and some equivalent ones
into /usr/lib as well (/usr/lib/gcc/$TRIPLE/$MAJOR_VERSON).


What about FindLLVM.cmake and its ${LLVM_LIBDIR_SUFFIX}? Many projects use it 
now.



We set LLVM_LIBDIR_SUFFIX, but I don't think upstream ever meant for this 
variable
to affect the Resource Directory path, because the search code in clang assumes
that both 32-bit and 64-bit libraries would have set the same value for 
LLVM_LIBDIR_SUFFIX,
which is not correct.

For libraries like libLLVM.so and libclang.so which aren't internal compiler 
libraries
and are meant to be linked by applications extending LLVM and clang, we still 
install
these to /usr/lib64/ on 64-bit and /usr/lib on 32-bit.

-Tom
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: Orphaning packages

2023-06-27 Thread Lance Albertson

On Thu, Jun 22, 2023 at 9:50 AM Othman Madjoudj  wrote:

> Hello,
>
> Please note that I've orphaned by packages, list in the end of the message.
>
> Best regards
> -Othman
>
>  rpms/mod_limitipconn
>

I'm interested in maintaining this but I am not a packager yet and would
need to be onboarded if someone is willing to be a mentor.

Thanks-

-- 
Lance Albertson
Director
Oregon State University | Open Source Lab
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: orphaned packages

Side-question: am I supposed to do anything with Bugzilla's currently related
to these packages that are assigned to me? (unassign/assign to orphan?).

Regards,

Simon
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

orphaned packages

Hi,

I've orphaned some packages that I am too unfamiliar with to maintain, 
especially
now that these are mostly FTBS/FTI and have unmaintained upstreams:

- preproc: https://src.fedoraproject.org/rpms/preproc
- preproc-rpmspec: https://src.fedoraproject.org/rpms/preproc-rpmspec
- rpkg-macros: https://src.fedoraproject.org/rpms/rpkg-macros
- rpkg-util: https://src.fedoraproject.org/rpms/rpkg-util
- rpm-git-tag-sort: https://src.fedoraproject.org/rpms/rpm-git-tag-sort

Regards,

Simon
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: LLVM 17 (System-Wide)

2023-06-27 Thread Jerry James

On Tue, Jun 27, 2023 at 5:06 AM Vitaly Zaitsev via devel
 wrote:
> Some package maintainers are too lazy. They won't do anything even if
> you inform them in the ML.

That's harsh.  Package maintainers are mostly volunteers, who spend
their free time on the project.  If something happens to reduce that
free time, their participation also decreases.  I myself periodically
get so much stuff to do piled on me that I temporarily drop out of
Fedora activities, then play catch up when my free time bounces back.
Don't assume laziness is the cause.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: more distinct default bash prompt?

2023-06-27 Thread Jens-Ulrik Petersen

So I made a copr repo PoC:

https://copr.fedorainfracloud.org/coprs/petersen/bash-color-prompt/

which you can test: the bash-color-prompt package there drops a
conditionalized PS1 into /etc/profile.d/ for now.

$ sudo dnf-3 copr enable petersen/bash-color-prompt
$ sudo dnf install bash-color-prompt

This shouldn't really be the final solution though - I would like it to be
available by default (even if turned off), but at least this allows more
user-testing now in different scenarios.

The prompt is similar to the one from my original post and can still be
"user-themed" with PROMPT_COLOR: it now defaults to normal green and adds the
red error code from Stephan (maybe this part could still be improved?) -
both now non-bright/bold.

https://copr-dist-git.fedorainfracloud.org/cgit/petersen/bash-color-prompt/bash-color-prompt.git/tree/

I can create a proper github or even pagure repo later if needed, but right
now I feel it would be helpful to have more user-feedback first.
I am happy to adapt this into a F39 Change (it could be monochrome by
default if pre-installed) if people want that: I feel it is only really
compelling if integrated into default desktop installations in some form.

Jens
ps It would be nice to support toolbox/containers too (like $debian_chroot) and
have opt-in for git branch too, but those could be added later I think.
Also a root color perhaps, as discussed.

pps I did test dim reverse-video but it looks quite stark in a light
terminal.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

2023-06-27 Thread Chris Murphy



On Mon, Jun 26, 2023, at 7:09 PM, Jiri Konecny wrote:
> Dne 26. 06. 23 v 20:39 Hans de Goede napsal(a):

>> Says 2G is the supported minimum. It would be good to see if
>> that can actually be made to / kept working.
>>
>> Has anyone already tested the new installer on a system with its
>> RAM limited to 2G ?

> If you need low memory footprint you probably don't want to use Live 
> image for installation. It's the biggest one because it needs to have 
> whole Gnome environment in memory. For that, I would suggest you to use 
> Fedora Server network installation ISO.

I recommend Everything netinstaller for the desktop use case. It's also a 
netinstaller, but the partitioning defaults are the same as Workstation edition.

It's not that easy to find with the new web site design. It's in alternative 
downloads. I had to web search to find it. But it is the first option on that 
page.

https://alt.fedoraproject.org/


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Red Hat & Fedora -- largely stepping out of this ecosystem

2023-06-27 Thread Peter Boy

Thanks for your writing. A well-balanced and very thoughtful and considered 
opinion. But your final decision seems to me rather a short-coming. 


> Am 27.06.2023 um 00:47 schrieb Jeff Law :
> 
> ...
> 
> 
> 
> What Red Hat has done recently is depressing, but not a huge surprise to me.  
> Red Hat struggled repeatedly with how to deal with "the clones". The core 
> idea I always came back to in those discussions was that the value isn't in 
> the bits, but in the stability, services and ecosystem Red Hat enables around 
> the bits.  Arguments for protecting the bits were met with something like "if 
> that's what we need to do to be successful, then we're failing to provide 
> real value".
> 
> At some point in the last 20 years (I forget exactly when) Red Hat was 
> looking to codify its values.  Naturally the topic of open source came up 
> during those discussions.   When open source didn't make the cut, one could 
> say the writing was on the wall -- open source was a means to an end.  In my 
> mind that opened the door for numerous changes we've seen in subsequent years.
> 
> One could see signs of where this was going with the adjustments that were 
> made to the exposed RHEL kernel sources some time ago.  Then the dissolution 
> of CentOS a couple years back and most recently with the lockdown of the RHEL 
> sources.
> 
> What Red Hat has done may be technically legal and perhaps good for its 
> business.  However, to me it's ethically unconscionable.   Those who know me 
> know I'm not an zealot, but I do have a baseline set of ethical values and 
> Red Hat crossed that line.
> 

I think there is a difference regarding the clones.

When Red Hat cancelled the academic licenses I switched all the servers I was 
responsible for to Scientific Linux, one of the clones. As a public funded 
University we simply couldn’t afford the new prices. And there was no such 
thing as "customers" for us to pass on higher costs to. The results of our work 
are available to the company free of charge.

But cases like OracleLinux, where a commercial company takes another company's 
work and uses it to throw a competing commercial product on the market, are 
something else, entirely. And they are to be evaluated differently beyond legal 
licensing issues.

And as much as I disapprove of Red Hat's decisions that led to the end of 
ScientificLinux, at the same time I can kind of understand it. But more 
differentiation of such circumstances would have been better.

Perhaps it is a quandary, unsolvable without compromise.


> ...
> 
> I've been a Fedora user since before FC1.  I run Fedora on my laptop. When I 
> need a docker image for something, I start with a Fedora image. When I need 
> to spin up a server (say to run the GCC CI/CD system) I load it with Fedora.  
>  It's an ecosystem I'm technically comfortable in and easiest for me to 
> utilize.
> 
> That will change across the board this summer.  That's a bit hard for me to 
> swallow, but I can't get past that association we built between Red Hat and 
> Fedora and Red Hat's recent actions.
> 
> I'll still have to deal with the RHEL/CentOS/Fedora ecosystem on a 
> professional level.  Obviously, I'll do what I need to do to help make my 
> employer successful -- but when a choice exists, Fedora/CentOS/RHEL won't be 
> where I land going forward.

I See, that outside of a professional level, you no longer want to deal with 
RHEL / CentOS. But why Fedora? It’s „sponsored by Red Hat“, yes, but is not 
subject to the same commercial and interest-based decisions (at least as far as 
I know). What's wrong with continuing to contribute to and shape the future of 
Fedora, especially with your independence of Red Hat?


—-
Peter Boy



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a chance to phase out `/lib64` directory?

2023-06-27 Thread Florian Weimer

* Kalev Lember:

> I would like to have a layout similar to what Debian is doing, so that
> shared libraries would go in /usr/lib/x86_64-redhat-linux/ and
> /usr/lib64 would be a legacy symlink pointing to it.

The Debian layout is a bit misdesigned in that it's not possible to
discover the multi-arch subdirectories under /usr/lib without
maintaining an explicit list.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: EPEL working group: updating rocksdb to newer version

2023-06-27 Thread Stephen Smoogen

On Tue, 27 Jun 2023 at 09:11, Kaleb Keithley  wrote:

> Hi,
>
> I don't see a specific epel working group list on lists.fpo.
>
>
The 'working group' is the EPEL Steering Committee which have meetings on
Wednesday at #fedora-meeting at 20:00 UTC (I think). Changes like what you
are looking at would be to open a ticket https://pagure.io/epel/issues so
it can be discussed at the next meeting. Things to cover:

1. WHat versions of EPEL are you updating? (epel-8, epel-9, epel-8-next,
epel-9-next)
2. What version is there already
3. What version are you updating to
4. What might break for someone when they do this update and how do they
fix it? (aka recompile app, change config, etc).
5. Do you have a version in a COPR which can be tested to see that it works?
6. When do you plan to do the update after any approval



> I'd like to update rocksdb to a newer version for consumption by ceph.
> (Ceph currently bundles rocksdb-7.9.2 IIRC for when the distribution's
> version is too old.)
>
> AFAIK, AFAICT, ceph is the only consumer of rocksdb in EPEL (or in Fedora
> for that matter.)
>
> I asked the maintainer of the epel rpms, and he referred me to the working
> group.
>
> Thoughts?
>
> Thanks
>
> --
>
> Kaleb
> ___
> 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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] EPEL working group: updating rocksdb to newer version

2023-06-27 Thread Kaleb Keithley

Hi,

I don't see a specific epel working group list on lists.fpo.

I'd like to update rocksdb to a newer version for consumption by ceph.
(Ceph currently bundles rocksdb-7.9.2 IIRC for when the distribution's
version is too old.)

AFAIK, AFAICT, ceph is the only consumer of rocksdb in EPEL (or in Fedora
for that matter.)

I asked the maintainer of the epel rpms, and he referred me to the working
group.

Thoughts?

Thanks

-- 

Kaleb
___
epel-devel mailing list -- epel-de...@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-de...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Unretiring ant-contrib

2023-06-27 Thread Zdeněk Žamberský


Hello,
I would like to unretire ant-contrib.

Package review:
https://bugzilla.redhat.com/show_bug.cgi?id=2217892

ticket:
https://pagure.io/releng/issue/11501

--
Zdeněk Žamberský
OpenJDK QE
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

2023-06-27 Thread Jiri Konecny


Hi Vit,

Dne 27. 06. 23 v 12:43 Vít Ondruch napsal(a):


Dne 26. 06. 23 v 18:00 Aoife Moloney napsal(a):

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

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== Summary ==
The new PatternFly-based UI has been developed by the Anaconda team
for some time now and we would like to make it available for users of
Fedora to enhance and modernize installation experience. As the first
step in this user adoption process, we are targeting Fedora
Workstation only.

== Owner ==

* Name: Anaconda team ([[User:jkonecny| Jiří Konečný]])

* Email: jkone...@redhat.com
* Name: Fedora Workstation SIG
* Email: desk...@lists.fedoraproject.org


== Detailed Description ==
The Anaconda team has been working on a new web-based UI for the OS
installer for some time. We would like to give users the fruits of our
work and get feedback so that we know what we need to improve or where
we should focus.
To make the adoption as painless as possible, the Fedora Workstation
was chosen as the first target so we have better control over the
environment and can have a focus. Also, Fedora Workstation has a
smaller featureset than other installation media. The adoption for the
other media later is planned too, but the exact date will be based on
feedback and our capacity allowance.


=== What will '''not''' change with the new Web UI? ===
The new UI will mostly use already existing functional code (some
modifications are necessary), so the stability should be similar. The
Anaconda specific kernel boot parameters are also staying almost
unchanged. The Anaconda team aims to reduce functionality that is not
used but still put a maintenance burden on the team. This should
result in much easier future extensions and stability of the
installer. The current approach is to start from what is known to be
required and used, then add future features based on the feedback.


=== What is going to change with the new Web UI? ===
The new web UI is not just a change of the UI technology, which is
based on the React and Cockpit framework, but also a complete overhaul
of the user experience. The new UI is trying to be easier to use by
removing most of the complexities but still leaving possibilities to
do everything you might need to do. We are trying to achieve a state
where even users who don’t have previous experience with the Linux
operating system will be able to do the installation smoothly.

List of what is part of the new UI:
* Wizard solution instead of hub and spoke



I am sad to see the "hub and spoke" to go away :(
I understand your point and honestly I felt the same way. However, I see 
it as

improvement after working with that a few times. Our ultimate goal
(not target right now) is to enable users to skip unnecessary steps so we
would get to similar level of what we had but easily understandable.

Jirka



Vít



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a chance to phase out `/lib64` directory?

2023-06-27 Thread Panu Matilainen


On 6/27/23 15:04, Neal Gompa wrote:

On Tue, Jun 27, 2023 at 6:37 AM Panu Matilainen  wrote:


On 6/27/23 13:30, Kalev Lember wrote:

On Tue, Jun 27, 2023 at 11:02 AM Vít Ondruch mailto:vondr...@redhat.com>> wrote:

 I don't think that GCC is always the best example to follow.

 Nevertheless, wouldn't it be worth of phasing out the /lib64? I don't
 know what is the history behind, but I don't think this layout is
 conceptual.


I would like to have a layout similar to what Debian is doing, so that
shared libraries would go in /usr/lib/x86_64-redhat-linux/ and
/usr/lib64 would be a legacy symlink pointing to it.


Likewise.


That kind of layout would make it much easier to do cross compilation
because you could just take the whole /usr/lib/another-host-triplet/
directory from another architecture without it interfering with the host
libraries and use it for cross compilation purposes.


Yes, that /lib/ arrangement allows for all manner of things that
just aren't possible with /lib64.

https://wiki.debian.org/Multiarch/TheCaseForMultiarch is a good read.


It would be a lot of work transitioning to a new layout though.


That it is.



I'd rather move toward sysroot multiarch instead, which would expand
that benefit beyond libraries to basically everything.

But to do anything, RPM's handling of architectures needs to change.
Years ago, I had attempted to fix some of this upstream, but it didn't
make it in.

https://github.com/rpm-software-management/rpm/pull/1038


It didn't go in, but not because we disagreed with the concept as such.

Note that support for multi-arch in rpm is now on the roadmap for 4.20 
(https://rpm.org/roadmap)


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

Re: ELN: Mass-rebuild has started

2023-06-27 Thread Stephen Gallagher

On Mon, Jun 26, 2023 at 8:51 PM Maxwell G  wrote:
>
> On Mon Jun 26, 2023 at 17:19 -0400, Stephen Gallagher wrote:
> > On Mon, Jun 26, 2023 at 5:08 PM Maxwell G  wrote:
> > >
> > > 2023-06-26T20:21:06Z Stephen Gallagher :
> > >
> > > > Just a heads-up that we've begun the targeted mass-rebuild for Fedora
> > > > ELN. It's running in Koji's "background" priority, so it should
> > > > hopefully not significantly impact other builds. My estimate is that
> > > > it will be running for about the next two days, followed up by manual
> > > > rebuilds for flaky tests/network hiccoughs, etc.
> > >
> > > Is that going to conflict with the ongoing Python 3.12 rebuild?
> >
> > It should not. I triggered the builds from the git hash of whatever
> > was current in the `eln` tag.
>
> Ah, do you just bump the eln disttag and not touch packages' Release
> fields and changelogs at all?

Yes, exactly this.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

2023-06-27 Thread Jiri Konecny


Hi Adam,

Dne 26. 06. 23 v 22:25 Adam Williamson napsal(a):

On Mon, 2023-06-26 at 17:00 +0100, Aoife Moloney wrote:

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

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== Summary ==
The new PatternFly-based UI has been developed by the Anaconda team
for some time now and we would like to make it available for users of
Fedora to enhance and modernize installation experience. As the first
step in this user adoption process, we are targeting Fedora
Workstation only.

I am in favor of giving the web UI a shot, but I do think this is a
pretty aggressive timeline given the amount of fairly large issues that
remain to be resolved, especially exactly how the 'choose-your-own-
partitioning' workflow is going to run (considering the stuff we
discussed about constraints around partition size and boot partition
requirements and disk label type requirements and so on). I think we
need to be really ready, in advance, to pull the contingency lever for
this one if it seems necessary. It should be fairly safe to do, since
we'll still be testing the existing UI on other images, including the
KDE live.

First, thanks you and your team for all the help.

I won't lie, we are on tight deadline, however, we decided that we
would like to try to get the web UI in, so we have more feedback
from the real users, thus we know what to focus on. Also, the benefit is
that the fallback is pretty simple (just use the current GTK UI), so if
we found any blocker, we can easily just post-pone this change to next
Fedora.

Another fallback is to also to add the current UI to the image next
to the web UI. If we release the ISO and users will miss something
it won't be blocking issue to anyone.

We are trying to embrace quick releases and fast development cycle,
by getting valuable feedback on real usage from our community,
while ensuring that we provide a safe fallback solutions at any point.

Best Regards,
Jirka


Naming nitpicks: I'm pretty sure the existing non-custom partitioning
flow is formally called "guided partitioning", so calling a new
slightly-more-customizable-one "guided partitioning" and retroactively
renaming the existing one "automatic partitioning" might be a bit
confusing, at least to old-timers. Also, I still think of the existing
UI as 'newUI', so I'm gonna keep calling this one 'webUI'. :D

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a chance to phase out `/lib64` directory?

2023-06-27 Thread Neal Gompa

On Tue, Jun 27, 2023 at 6:37 AM Panu Matilainen  wrote:
>
> On 6/27/23 13:30, Kalev Lember wrote:
> > On Tue, Jun 27, 2023 at 11:02 AM Vít Ondruch  > > wrote:
> >
> > I don't think that GCC is always the best example to follow.
> >
> > Nevertheless, wouldn't it be worth of phasing out the /lib64? I don't
> > know what is the history behind, but I don't think this layout is
> > conceptual.
> >
> >
> > I would like to have a layout similar to what Debian is doing, so that
> > shared libraries would go in /usr/lib/x86_64-redhat-linux/ and
> > /usr/lib64 would be a legacy symlink pointing to it.
>
> Likewise.
>
> > That kind of layout would make it much easier to do cross compilation
> > because you could just take the whole /usr/lib/another-host-triplet/
> > directory from another architecture without it interfering with the host
> > libraries and use it for cross compilation purposes.
>
> Yes, that /lib/ arrangement allows for all manner of things that
> just aren't possible with /lib64.
>
> https://wiki.debian.org/Multiarch/TheCaseForMultiarch is a good read.
>
> > It would be a lot of work transitioning to a new layout though.
>
> That it is.
>

I'd rather move toward sysroot multiarch instead, which would expand
that benefit beyond libraries to basically everything.

But to do anything, RPM's handling of architectures needs to change.
Years ago, I had attempted to fix some of this upstream, but it didn't
make it in.

https://github.com/rpm-software-management/rpm/pull/1038



-- 
真実はいつも一つ！/ 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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: PR #47: binutils: drop gold

2023-06-27 Thread Sérgio Basto


Thank you for the notice I started build nodejs-electron with lld on my
copr project 


https://copr.fedorainfracloud.org/coprs/sergiomb/electrons/build/6102774/


On Wed, 2023-06-21 at 17:07 +0200, Amit Shah wrote:
> (I realized I hadn't subscribed to f-devel with this email ID, and
> this
> message didn't make it to devel.  Resending.)
> 
> On Thu, 2023-06-15 at 13:59 +0200, Amit Shah wrote:
> > Hey Nick,
> > 
> > I submitted
> > 
> > https://src.fedoraproject.org/rpms/binutils/pull-request/47
> > 
> > yesterday to not build gold by default.
> > 
> > Creating this thread here to ensure you see this, and also a chance
> > to
> > discuss the change via email rather than on the PR.
> > 
> > Cheers,
> > 
> > Amit
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)


On 6/27/23 13:04, Hans de Goede wrote:

Hi,

On 6/27/23 12:36, Adam Williamson wrote:


To be fair, you're writing as if it's certain that a webUI-based
Workstation live cannot install to a 2G system, but AFAIK that has not
yet been demonstrated. It would seem reasonable to test it before
deciding we have a huge blocker issue here.


Right, first we need to test if this is a problem at all.
That is why I wrote "*may also* be on the hook".


What I read from this is that test ISOs should be provided ASAP so 
people can test them out in their usecases. I'm currently working on 
getting those somewhere together with the Anaconda team and will update 
this thread once available.


Regards,

Simon

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Announcing fmt library soversion bump


On 23/05/2023 12:22, Vitaly Zaitsev wrote:
I will use my proven-packager rights to rebuild all dependent packages 
in a separate side tag next week.


Many packages are not yet ready for fmt 10. Spdlog for example:

- https://github.com/gabime/spdlog/issues/2614
- https://github.com/gabime/spdlog/issues/2767
- https://github.com/gabime/spdlog/issues/2782

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: LLVM 17 (System-Wide)


On 27/06/2023 03:21, Tom Stellard wrote:

For this update, we're going to let package maintainers be responsible for
rebuilding their own packages if they are unable to use the compat 
libraries
for some reason.  We can try to send an announcement when the side-tag 
is ready.


Some package maintainers are too lazy. They won't do anything even if 
you inform them in the ML.


Check my last year's fmt 9.0 update:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/FOESCVXNAHV2OATO36UIACIE3BQGMMR5/

I think it will be better to rebuild all dependent packages in a side tag.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

2023-06-27 Thread Hans de Goede

Hi,

On 6/27/23 12:36, Adam Williamson wrote:
> On Tue, 2023-06-27 at 10:40 +0200, Hans de Goede wrote:
>> So although I realize this is not entirely fair IMHO if you want to push 
>> forward with this feature then you may also be on the hook to look into 
>> reducing the memory footprint elsewhere so that the end result still fits in 
>> 2G RAM. I have some experience with tweaking the livecd to work with less 
>> RAM and I'm happy to share my experience in this, but I do not have time to 
>> actually implement needed changes for this.
> 
> To be fair, you're writing as if it's certain that a webUI-based
> Workstation live cannot install to a 2G system, but AFAIK that has not
> yet been demonstrated. It would seem reasonable to test it before
> deciding we have a huge blocker issue here.

Right, first we need to test if this is a problem at all.
That is why I wrote "*may also* be on the hook".

Regards,

Hans


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: LLVM 17 (System-Wide)


On 27/06/2023 03:19, Tom Stellard wrote:


We're trying to be more consistent with gcc and also upstream clang.
gcc installs some of these same libraries and some equivalent ones
into /usr/lib as well (/usr/lib/gcc/$TRIPLE/$MAJOR_VERSON).


What about FindLLVM.cmake and its ${LLVM_LIBDIR_SUFFIX}? Many projects 
use it now.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a chance to phase out `/lib64` directory?


On 27/06/2023 12:30, Kalev Lember wrote:
I would like to have a layout similar to what Debian is doing, so that 
shared libraries would go in /usr/lib/x86_64-redhat-linux/ and 
/usr/lib64 would be a legacy symlink pointing to it.


Debian isn't a good example here. I've fixed over a hundred projects by 
switching from hard-coded lib/ to GNUInstallDirs.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2217108] perl-CPAN-Perl-Releases-5.20230623 is available

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



--- Comment #4 from Fedora Update System  ---
FEDORA-2023-7a7e4d7532 has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2023-7a7e4d7532`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-7a7e4d7532

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2217108

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202217108%23c4
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2216784] perl-HTTP-Tiny-0.086 is available

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



--- Comment #4 from Fedora Update System  ---
FEDORA-2023-388a61ea6f has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2023-388a61ea6f`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-388a61ea6f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2216784

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202216784%23c4
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2217200] Finance quotes stopped working

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #6 from Fedora Update System  ---
FEDORA-2023-e884cc3f99 has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2023-e884cc3f99`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-e884cc3f99

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2217200

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202217200%23c6
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2215501] perl-CPAN-Perl-Releases-5.20230616 is available

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



--- Comment #4 from Fedora Update System  ---
FEDORA-2023-7a7e4d7532 has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2023-7a7e4d7532`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-7a7e4d7532

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2215501

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202215501%23c4
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaned packages looking for new maintainers



Dne 27. 06. 23 v 8:43 Jeffrey Stewart napsal(a):


Would like to take**golang-github-lithammer-dedent and aqemu but I 
believe I still need a sponsor. Anyone willing to sponsor?




I think you can follow this guideline:

https://docs.fedoraproject.org/en-US/fesco/Packager_sponsor_policy/#adopting

Vít




On 6/9/23 07:24, Omair Majid wrote:

Hi,

Jens-Ulrik Petersen  writes:


What would be really helpful is to know how it compares with other Naskh fonts
like Paktype (current default) and Nafees, and even Noto Nastaliq Urdu
(they are all in Fedora 38).

I lack the tools/skills/knowledge/jargon to describe the differences I
see. Is there a guide for n00bs where they can read up on what sort of
things to compare and how to describe those differences?

Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List 
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report 
it:https://pagure.io/fedora-infrastructure/new_issue


___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List 
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report 
it:https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2215501] perl-CPAN-Perl-Releases-5.20230616 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-2023-0de79a3711 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2023-0de79a3711`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-0de79a3711

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2215501

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202215501%23c3
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2217108] perl-CPAN-Perl-Releases-5.20230623 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-2023-0de79a3711 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2023-0de79a3711`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-0de79a3711

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2217108

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202217108%23c3
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2216784] perl-HTTP-Tiny-0.086 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-2023-1be6532d43 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2023-1be6532d43`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-1be6532d43

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2216784

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202216784%23c3
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)



Dne 26. 06. 23 v 18:00 Aoife Moloney napsal(a):

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

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== Summary ==
The new PatternFly-based UI has been developed by the Anaconda team
for some time now and we would like to make it available for users of
Fedora to enhance and modernize installation experience. As the first
step in this user adoption process, we are targeting Fedora
Workstation only.

== Owner ==

* Name: Anaconda team ([[User:jkonecny| Jiří Konečný]])

* Email: jkone...@redhat.com
* Name: Fedora Workstation SIG
* Email: desk...@lists.fedoraproject.org


== Detailed Description ==
The Anaconda team has been working on a new web-based UI for the OS
installer for some time. We would like to give users the fruits of our
work and get feedback so that we know what we need to improve or where
we should focus.
To make the adoption as painless as possible, the Fedora Workstation
was chosen as the first target so we have better control over the
environment and can have a focus. Also, Fedora Workstation has a
smaller featureset than other installation media. The adoption for the
other media later is planned too, but the exact date will be based on
feedback and our capacity allowance.


=== What will '''not''' change with the new Web UI? ===
The new UI will mostly use already existing functional code (some
modifications are necessary), so the stability should be similar. The
Anaconda specific kernel boot parameters are also staying almost
unchanged. The Anaconda team aims to reduce functionality that is not
used but still put a maintenance burden on the team. This should
result in much easier future extensions and stability of the
installer. The current approach is to start from what is known to be
required and used, then add future features based on the feedback.


=== What is going to change with the new Web UI? ===
The new web UI is not just a change of the UI technology, which is
based on the React and Cockpit framework, but also a complete overhaul
of the user experience. The new UI is trying to be easier to use by
removing most of the complexities but still leaving possibilities to
do everything you might need to do. We are trying to achieve a state
where even users who don’t have previous experience with the Linux
operating system will be able to do the installation smoothly.

List of what is part of the new UI:
* Wizard solution instead of hub and spoke



I am sad to see the "hub and spoke" to go away :(


Vít




OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a chance to phase out `/lib64` directory?

2023-06-27 Thread Panu Matilainen


On 6/27/23 13:30, Kalev Lember wrote:
On Tue, Jun 27, 2023 at 11:02 AM Vít Ondruch > wrote:


I don't think that GCC is always the best example to follow.

Nevertheless, wouldn't it be worth of phasing out the /lib64? I don't
know what is the history behind, but I don't think this layout is
conceptual.


I would like to have a layout similar to what Debian is doing, so that 
shared libraries would go in /usr/lib/x86_64-redhat-linux/ and 
/usr/lib64 would be a legacy symlink pointing to it.


Likewise.

That kind of layout would make it much easier to do cross compilation 
because you could just take the whole /usr/lib/another-host-triplet/ 
directory from another architecture without it interfering with the host 
libraries and use it for cross compilation purposes.


Yes, that /lib/ arrangement allows for all manner of things that 
just aren't possible with /lib64.


https://wiki.debian.org/Multiarch/TheCaseForMultiarch is a good read.


It would be a lot of work transitioning to a new layout though.


That it is.

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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

2023-06-27 Thread Adam Williamson

On Tue, 2023-06-27 at 10:40 +0200, Hans de Goede wrote:
> So although I realize this is not entirely fair IMHO if you want to push 
> forward with this feature then you may also be on the hook to look into 
> reducing the memory footprint elsewhere so that the end result still fits in 
> 2G RAM. I have some experience with tweaking the livecd to work with less RAM 
> and I'm happy to share my experience in this, but I do not have time to 
> actually implement needed changes for this.

To be fair, you're writing as if it's certain that a webUI-based
Workstation live cannot install to a 2G system, but AFAIK that has not
yet been demonstrated. It would seem reasonable to test it before
deciding we have a huge blocker issue here.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a chance to phase out `/lib64` directory?



Dne 27. 06. 23 v 11:59 Nico Kadel-Garcia napsal(a):

On Tue, Jun 27, 2023 at 5:02 AM Vít Ondruch  wrote:

I don't think that GCC is always the best example to follow.

Nevertheless, wouldn't it be worth of phasing out the /lib64? I don't
know what is the history behind, but I don't think this layout is
conceptual.


Vít

Until, and unless, 32-bit compatibility on 64-bit hosts gets discarded



I don't think this really is precondition



and the File System Hierarchy rewritten, probably not.



We can drive the change instead waiting for it.


Vít



OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a chance to phase out `/lib64` directory?



Dne 27. 06. 23 v 12:30 Kalev Lember napsal(a):

On Tue, Jun 27, 2023 at 11:02 AM Vít Ondruch  wrote:

I don't think that GCC is always the best example to follow.

Nevertheless, wouldn't it be worth of phasing out the /lib64? I don't
know what is the history behind, but I don't think this layout is
conceptual.


I would like to have a layout similar to what Debian is doing, so that 
shared libraries would go in /usr/lib/x86_64-redhat-linux/ and 
/usr/lib64 would be a legacy symlink pointing to it.



Yep, something like this was on my mind. It would probably not directly 
solve the original issue which triggered the question, but afterall, it 
would be closer to what upstreams do.





That kind of layout would make it much easier to do cross compilation 
because you could just take the whole /usr/lib/another-host-triplet/ 
directory from another architecture without it interfering with the 
host libraries and use it for cross compilation purposes.


It would be a lot of work transitioning to a new layout though.



Indeed.


Vít




OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a chance to phase out `/lib64` directory?

2023-06-27 Thread Kalev Lember

On Tue, Jun 27, 2023 at 11:02 AM Vít Ondruch  wrote:

> I don't think that GCC is always the best example to follow.
>
> Nevertheless, wouldn't it be worth of phasing out the /lib64? I don't
> know what is the history behind, but I don't think this layout is
> conceptual.
>

I would like to have a layout similar to what Debian is doing, so that
shared libraries would go in /usr/lib/x86_64-redhat-linux/ and /usr/lib64
would be a legacy symlink pointing to it.

That kind of layout would make it much easier to do cross compilation
because you could just take the whole /usr/lib/another-host-triplet/
directory from another architecture without it interfering with the host
libraries and use it for cross compilation purposes.

It would be a lot of work transitioning to a new layout though.

-- 
Kalev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a chance to phase out `/lib64` directory?

2023-06-27 Thread Nico Kadel-Garcia

On Tue, Jun 27, 2023 at 5:02 AM Vít Ondruch  wrote:
>
> I don't think that GCC is always the best example to follow.
>
> Nevertheless, wouldn't it be worth of phasing out the /lib64? I don't
> know what is the history behind, but I don't think this layout is
> conceptual.
>
>
> Vít

Until, and unless, 32-bit compatibility on 64-bit hosts gets discarded
and the File System Hierarchy rewritten, probably not.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

2023-06-27 Thread Hans de Goede

Hi Simon,

On 6/27/23 11:00, Simon de Vlieger wrote:
> On 6/27/23 10:40, Hans de Goede wrote:
> 
>> Ok, so can you provide some instructions for how to make this work ? I guess 
>> it would be something like add the cmdline option + then start some systemd 
>> unit ?  Can you please put some instructions for this in the testing section 
>> of: https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation 
>>  (with a note that this is currently not supported / recommended).
>>
>>> About the improvements on the Live ISO, that should be a question on Fedora 
>>> Workstation SIG. Anaconda team is not in charge of the environment on the 
>>> Live ISO.
>>
>> Well you are suggesting a change that is likely going to significantly 
>> increase the amount of memory needed to do a livecd workstation install and 
>> as mentioned above pushing the requirements above 2G would basically block 
>> this change since 2G RAM is currently the advertised minimum RAM requirement 
>> for Fedora workstation installs.
>>
>> So although I realize this is not entirely fair IMHO if you want to push 
>> forward with this feature then you may also be on the hook to look into 
>> reducing the memory footprint elsewhere so that the end result still fits in 
>> 2G RAM. I have some experience with tweaking the livecd to work with less 
>> RAM and I'm happy to share my experience in this, but I do not have time to 
>> actually implement needed changes for this.
> Hi Hans,
> 
> it would indeed involve adding the `inst.webui` and `inst.webui.remote` 
> kernel command line options and a systemd unit to start the relevant services 
> (I *think* that'd only be `cockpit.service`).
> 
> You likely also want to truncate the `/etc/cockpit/allowed-users` file so you 
> can use your empty password root login during installation.
> 
> This is normally taken care of when anaconda starts the webservice [1].
> 
> I've been working on landing live-installer generation in the image builder 
> projects (there's a separate change request for this). You can follow 
> progress on that here [2].
> 
> When the image builder PR lands the first follow ups will involve 
> customization of the live-installer. Including kernel options, packages, and 
> systemd service files. This would allow you to build a lighter version of the 
> live-installer locally to use on the devices you work with.
> 
> I am interested to know which tweaks you perform to have the livecd use less 
> RAM to see if I can codify those. Could you share your experience?

At the end of this email is a copy & paste of my own notes
of the set of hacks which I use to do a livecd install on
1G RAM x86 tablets.

Low hanging fruit would be evolution and gnome-software + packagekit.

There are 3 ways (IIRC) how the whole set of evolution-daya-server
processes gets started on a GNOME session:

1. Through /etc/xdg/autostart/org.gnome.Evolution-alarm-notify.desktop
for this we would need some way to annotate .desktop files to not
start on a livecd. This could be e.g. a X-GNOME-no-livecd-autostart=yes
on the .desktop + code in GNOME's code to generate systemd user
unit files to honor this.

2. Through a calendar search provider. This can easily be disabled in
the livecd sessions with a drop-in gconf settings file disabling the
search provider. In general many of the gnome-shell search providers
can be quite heavy for low spec machines. I think there might even
already be some code to disable some of them.

3. Stop gnome-shell starting /usr/libexec/gnome-shell-calendar-server,
which does the calendar integration in the clock widget in the top bar.
The main gnome-shell talks to this over a dbus proxy and if it cannot
be started it logs one warning and everything is fine.

Making it possible to run gnome-shell with calendar integration 
disabled has been on my wishlist for quite a while now. This may also
be useful for the efforts to make gnome-shell work better on mobile
devices. Since the evolution data server processes might be a bit
too heavy for some mobile platforms too.

As for gnome-software + packagekit getting started (and taking
up quite a lot of RAM). I think these might already be disabled
on the livecd case, since auto downloading updates to have them
ready for installation on shutdown / reboot makes little sense
there. So the first thing to do there would be to check if
these are running at all.

If they are running there are 2 places where gnome-software
gets started:

1. /etc/xdg/autostart/org.gnome.Software.desktop
2. From a gnome-shell search provider

As for packagekit (will that still be there in F39?) this
gets triggered by both gnome-software as well as by some
code in gnome-shell talking to it to see if offline-updates
should be offered on shutdown/reboot.

One last thing to consider is to slightly increase the zram
factor on low RAM systems. Currently the zram real ram
relation is 1:1 which assuming a worst case compression
of 1:2 means that at full zram we end up with 1/2

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

2023-06-27 Thread Jiri Vanek

JDK will behave similarly. We ave (small) advantage that we have also
in-jdk-bundled tzdata.  However fallback in case of removed system
tzdata is not automatic, and requires human touch. Long ago we have a
patch in jdk which looked to system tzdata - if they were present,
they were used.  If not, the bundled copy was used.  Also user could
set up on startup which to use. But it had not prooved itself, as it
was casue of weird missonfigurations.

If this proposal will come live, we may introduce this patch again, or
leave it as it is now - on human touch.

TY!

 J.

On Tue, 27 Jun 2023 at 11:00, Miro Hrončok  wrote:
>
> On 26. 06. 23 20:24, Fabio Valentini wrote:
> > On Mon, Jun 26, 2023 at 8:10 PM Miro Hrončok  wrote:
> >>
> >
> > (snip)
> >
> >> ---
> >>
> >> The current problem with Python without tzdata is:
> >>
> >> ===
> >>   >>> from zoneinfo import ZoneInfo
> >>   >>> ZoneInfo("Europe/Prague")
> >> Traceback (most recent call last):
> >> ...
> >> zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key 
> >> Europe/Prague'
> >> ===
> >>
> >> Not that ZoneInfo("UTC") also fails:
> >>
> >> ===
> >>   >>> ZoneInfo("UTC")
> >> Traceback (most recent call last):
> >> ...
> >> zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key UTC'
> >> ===
> >>
> >> So we would need to patch Python to detect missing tzdata and report 
> >> something
> >> like:
> >>
> >>ZoneInfoNotInstalledError: 'No time zone information installed on the 
> >> system,
> >> you can only use UTC'
> >>
> >> We would also need to ensure UTC work even without tzdata installed.
> >>
> >> I would be reluctant to carry this as a downstream-only patch. And the 
> >> upstream
> >> window for changes like this has already closed for Python 3.12.
> >
> > Does this mean that tzdata needs to be present for doing datetime /
> > timezone calculations at runtime with the zoneinfo module?
>
> Yes. That's why it is Required and not Recommended.
>
> > Would this Change require that all Python programs that use this
> > module add "Requires: tzdata"? I don't think that would be a
> > reasonable change.
>
> Either that or adapt their code to fail in a reasonable way. Both sound quite
> unreasonable to me.
>
> > There's a similar issue with some Rust libraries (and probably other
> > language-specific timezone handling libraries), where they explicitly
> > assume that the timezone database is available, and will either fail
> > (bad case) or fall back to UTC (less bad case). Similar to the Python
> > case, I don't think adding "Requires: tzdata" to all packages like
> > these (either to the library in the case of dynamically linked /
> > scripting languages, or to all affected *applications* in the case of
> > statically linked languages) would be reasonable.
>
> Thanks for sharing a similar concern.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Towards enabling rpm sysusers integration

2023-06-27 Thread Panu Matilainen

On 6/22/23 19:55, Steve Grubb wrote:

https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format

I would caution against this whole proposal. Not that I'm against it, but
just saying be careful doing it. People often forget about our security
concerns. Currently, shadow-utils has about 400 places which generate audit
events during the managing of system and user accounts. libuser (I saw the
deprecation email) has 55 places where it sends audit events managing
accounts.

There is a 10 year old (or more) standard published here:
https://github.com/linux-audit/audit-documentation/wiki/SPEC-User-Account-Lifecycle-Events

If %pre getent, useradd, and groupadd are being replaced by something, that
something needs to conform to the expected security safeguards that currently
exist. It needs to match the kind of events and the format that currently
exists.

Looking at the systemd-sysusers source [1], it seems to do exactly zero
audit logging. So there's a bit of work to do on that front...

- Panu -

[1] https://github.com/systemd/systemd/blob/main/src/sysusers/sysusers.c
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

On 6/27/23 10:40, Hans de Goede wrote:

> Ok, so can you provide some instructions for how to make this work ? 
I guess it would be something like add the cmdline option + then start 
some systemd unit ?  Can you please put some instructions for this in 
the testing section of: 
https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation 
 (with a note that this is currently not supported / recommended).

>
>> About the improvements on the Live ISO, that should be a question on 
Fedora Workstation SIG. Anaconda team is not in charge of the 
environment on the Live ISO.

>
> Well you are suggesting a change that is likely going to 
significantly increase the amount of memory needed to do a livecd 
workstation install and as mentioned above pushing the requirements 
above 2G would basically block this change since 2G RAM is currently the 
advertised minimum RAM requirement for Fedora workstation installs.

>
> So although I realize this is not entirely fair IMHO if you want to 
push forward with this feature then you may also be on the hook to look 
into reducing the memory footprint elsewhere so that the end result 
still fits in 2G RAM. I have some experience with tweaking the livecd to 
work with less RAM and I'm happy to share my experience in this, but I 
do not have time to actually implement needed changes for this.

Hi Hans,

it would indeed involve adding the `inst.webui` and `inst.webui.remote` 
kernel command line options and a systemd unit to start the relevant 
services (I *think* that'd only be `cockpit.service`).

You likely also want to truncate the `/etc/cockpit/allowed-users` file 
so you can use your empty password root login during installation.

This is normally taken care of when anaconda starts the webservice [1].

I've been working on landing live-installer generation in the image 
builder projects (there's a separate change request for this). You can 
follow progress on that here [2].

When the image builder PR lands the first follow ups will involve 
customization of the live-installer. Including kernel options, packages, 
and systemd service files. This would allow you to build a lighter 
version of the live-installer locally to use on the devices you work with.

I am interested to know which tweaks you perform to have the livecd use 
less RAM to see if I can codify those. Could you share your experience?

Regards, Simon

[1]: 
https://github.com/rhinstaller/anaconda/blob/413007214f8f7f0dfbdff98431eee5789866e081/pyanaconda/ui/webui/__init__.py#L98

[2]: https://github.com/osbuild/osbuild-composer/pull/3440
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Is there a chance to phase out `/lib64` directory?


I don't think that GCC is always the best example to follow.

Nevertheless, wouldn't it be worth of phasing out the /lib64? I don't 
know what is the history behind, but I don't think this layout is 
conceptual.



Vít


Dne 27. 06. 23 v 3:19 Tom Stellard napsal(a):

On 6/26/23 10:02, Fabio Valentini wrote:
On Mon, Jun 26, 2023 at 6:13 PM Aoife Moloney  
wrote:


https://fedoraproject.org/wiki/Changes/LLVM-17

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
Update all llvm sub-projects in Fedora Linux to version 17.

== Owner ==
* Name: [[User:tstellar| Tom Stellard]]

* Email: 


== Detailed Description ==
All llvm sub-projects in Fedora will be updated to version 17, and
there will be a soname version change for the llvm libraries.
Compatibility packages clang16, llvm16, and lld16 will be added to
ensure that packages that currently depend on clang and llvm version
16 libraries will continue to work.

Other notable changes:

* The Clang Resource Directory will be moved from /usr/lib64/clang/17/
to /usr/lib/clang/17/ this is the location of clang's internal headers
and runtime libraries like libomp and compiler-rt.  Package owners of
packages that read or write this directory will need to update their
packages when rebuilding against/with LLVM 17.  The
%clang_resource_dir helper macro can be used to make this transition
smoother, and packages are encouraged to update to use this macro even
before the LLVM 17 update.

* Along with the Clang Resource Directory change, compiler-rt will now
install its libraries into /usr/lib/clang/17/lib/$TRIPLE/ instead of
/usr/lib64/clang/17/lib/


Isn't installing architecture-specific binaries into /usr/lib a bit
broken (and against Packaging Guidelines)?
If this is intended to make it possible to have parallel installable
toolchains for different $TRIPLEs, it might be a better idea to
install files for the "host triple" in the current location, and only
add symlinks for thise in the "new" location.



We're trying to be more consistent with gcc and also upstream clang.
gcc installs some of these same libraries and some equivalent ones
into /usr/lib as well (/usr/lib/gcc/$TRIPLE/$MAJOR_VERSON).

This also fixes problems we have with clang being unable to find 32-bit
libraries.  clang expects 32-bit and 64-bit libraries to be within the
same Clang Resource Directory, so it searches for the 32-bit libraries
in /usr/lib64/clang/17/lib, and they are installed in 
/usr/lib/clang/17/lib.


We do currently have symlinks for the 32-bit libraries installed in 
/usr/lib64/clang/17/lib,

but this is not very robust and still has some bugs.  Moving the Resource
Directory to match upstream is the most simple solution for us and it 
should

help prevent issues in the future too.

-Tom





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

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

2023-06-27 Thread Miro Hrončok

On 26. 06. 23 20:24, Fabio Valentini wrote:

On Mon, Jun 26, 2023 at 8:10 PM Miro Hrončok  wrote:

(snip)

---

The current problem with Python without tzdata is:

===
  >>> from zoneinfo import ZoneInfo
  >>> ZoneInfo("Europe/Prague")
Traceback (most recent call last):
...
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key 
Europe/Prague'
===

Not that ZoneInfo("UTC") also fails:

===
  >>> ZoneInfo("UTC")
Traceback (most recent call last):
...
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key UTC'
===

So we would need to patch Python to detect missing tzdata and report something
like:

   ZoneInfoNotInstalledError: 'No time zone information installed on the system,
you can only use UTC'

We would also need to ensure UTC work even without tzdata installed.

I would be reluctant to carry this as a downstream-only patch. And the upstream
window for changes like this has already closed for Python 3.12.

Does this mean that tzdata needs to be present for doing datetime /
timezone calculations at runtime with the zoneinfo module?

Yes. That's why it is Required and not Recommended.

Would this Change require that all Python programs that use this
module add "Requires: tzdata"? I don't think that would be a
reasonable change.

Either that or adapt their code to fail in a reasonable way. Both sound quite 
unreasonable to me.

There's a similar issue with some Rust libraries (and probably other
language-specific timezone handling libraries), where they explicitly
assume that the timezone database is available, and will either fail
(bad case) or fall back to UTC (less bad case). Similar to the Python
case, I don't think adding "Requires: tzdata" to all packages like
these (either to the library in the case of dynamically linked /
scripting languages, or to all affected *applications* in the case of
statically linked languages) would be reasonable.

Thanks for sharing a similar concern.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

2023-06-27 Thread Hans de Goede

Hi Jirka,

On 6/27/23 01:09, Jiri Konecny wrote:
> 
> 
> Dne 26. 06. 23 v 20:39 Hans de Goede napsal(a):
>> Hi,
>>
>> On 6/26/23 18:00, Aoife Moloney wrote:
>>> https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation
>>>
>>> This document represents a proposed Change. As part of the Changes
>>> process, proposals are publicly announced in order to receive
>>> community feedback. This proposal will only be implemented if approved
>>> by the Fedora Engineering Steering Committee.
>>>
>>>
>>> == Summary ==
>>> The new PatternFly-based UI has been developed by the Anaconda team
>>> for some time now and we would like to make it available for users of
>>> Fedora to enhance and modernize installation experience. As the first
>>> step in this user adoption process, we are targeting Fedora
>>> Workstation only.
>> 
>>
>> This all sounds great, thank you for working on this.
>>
>>> === Additional information ===
>>> * We are not planning to add support for spins with this change, they
>>> will use the existing GTK UI.
>>> * We don’t support remote connections to the WebUI yet.
>> Hmm, this really is going to be a problem for low memory machines.
>>
>> I regularly install Fedora Workstation on 2G (not an issue atm)
>> and 1G (requires some trickery) RAM systems. I know this is not
>> a lot of RAM but generally speaking these systems work fine
>> for non demanding work after the install.
>>
>> I'm pretty sure that not only the 1G but also the 2G RAM installs,
>> which currently barely fit in RAM will become a problem with
>> the new web installers. I was actually hoping the web-installer
>> would help here since one can then just setup networking in
>> the live environment and then have the browser showing the UI
>> run somewhere else, hopefully reducing memory consumption
>> compared to the gtk installer.
>>
>> Is there any chance this (remote installs) can at least be
>> enabled with a commandline option for advanced users?
>>
>> I realize that making something for remote installs which works
>> well for average users (and is also somehow using an authenticated
>> connection) is quite a bit of work.
>>
>> But in the interim a cmdline option to start listening on
>> other interfaces then the loopback device (and to not start
>> the local browser) would be nice to have for power users.
>>
>> Note related to this ATM:
>>
>> https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/welcome/Hardware_Overview/
>>
>> "Minimum System Configuration"
>>
>> Says 2G is the supported minimum. It would be good to see if
>> that can actually be made to / kept working.
>>
>> Has anyone already tested the new installer on a system with its
>> RAM limited to 2G ?
>>
>> As said I have some tricks to help with this which currently
>> allow me to go down to 1G. We should probably look into making
>> some of those the default on the livecd.
>>
>> E.g. changing a few things to not run evolution-data-services
>> on the livecd (no calendering will be configured anyways)
>> is an easy win of at least 50 MB of RAM.
>>
>> Regards,
>>
>> Hans
> If you need low memory footprint you probably don't want to use Live image 
> for installation. It's the biggest one because it needs to have whole Gnome 
> environment in memory. For that, I would suggest you to use Fedora Server 
> network installation ISO. It has much smaller memory footprint for 
> installation and still can install workstation system in the Software 
> Selection. The Fedora Server ISO is not part of this change so still GTK UI.
> If you want even smaller memory footprint then you can run the Server ISO in 
> the text mode by setting 'inst.text' kernel boot parameter in the grub menu.
> 
> We did some testing for the memory footprint of the web UI but it was some 
> time ago and I don't remember the results. We can definitely verify it.

The Workstation livecd is *the* default download on https://getfedora.org/ all 
the other Workstation options are hidden behind a "other Downloads" button.

Currently that default Workstation Download can be installed on machines with 
2G of RAM matching the advertised minimum system requirements.

Telling people with systems with 2G of RAM that they now need to use the server 
iso and then manually select the right package set is IMHO an unacceptable 
regressions and I consider this a blocker for moving forward with making the 
web based installer for Fedora Workstation.

Also you cannot assume that everyone will have enough bandwidth to do network 
installs...

> To answer your question, remote installations work (probably not great on 
> Live environment). We have 'inst.webui.remote' kernel boot parameter to 
> enable that, however, we decided to not officially support it from a few 
> reasons:
> - we don't have support for HTTPS connections yet (we are looking on the 
> security aspects of this)
> - it will not work on Live out of the box because Anaconda is not autostarted 
> there (something needs to start the Anaconda

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

Dne 26. 06. 23 v 22:12 Fabio Valentini napsal(a):

On Mon, Jun 26, 2023 at 8:40 PM Vít Ondruch  wrote:

Dne 26. 06. 23 v 20:24 Fabio Valentini napsal(a):

On Mon, Jun 26, 2023 at 8:10 PM Miro Hrončok  wrote:
(snip)

---

The current problem with Python without tzdata is:

===
   >>> from zoneinfo import ZoneInfo
   >>> ZoneInfo("Europe/Prague")
Traceback (most recent call last):
 File "/usr/lib64/python3.11/zoneinfo/_common.py", line 12, in load_tzdata
   return resources.files(package_name).joinpath(resource_name).open("rb")
  ^
 File "/usr/lib64/python3.11/importlib/resources/_common.py", line 22, in 
files
   return from_package(get_package(package))

 File "/usr/lib64/python3.11/importlib/resources/_common.py", line 53, in
get_package
   resolved = resolve(package)

 File "/usr/lib64/python3.11/importlib/resources/_common.py", line 44, in 
resolve
   return cand if isinstance(cand, types.ModuleType) else
importlib.import_module(cand)

^
 File "/usr/lib64/python3.11/importlib/__init__.py", line 126, in 
import_module
   return _bootstrap._gcd_import(name[level:], package, level)

 File "", line 1204, in _gcd_import
 File "", line 1176, in _find_and_load
 File "", line 1126, in _find_and_load_unlocked
 File "", line 241, in 
_call_with_frames_removed
 File "", line 1204, in _gcd_import
 File "", line 1176, in _find_and_load
 File "", line 1126, in _find_and_load_unlocked
 File "", line 241, in 
_call_with_frames_removed
 File "", line 1204, in _gcd_import
 File "", line 1176, in _find_and_load
 File "", line 1140, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'tzdata'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
 File "", line 1, in 
 File "/usr/lib64/python3.11/zoneinfo/_common.py", line 24, in load_tzdata
   raise ZoneInfoNotFoundError(f"No time zone found with key {key}")
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key 
Europe/Prague'
===

Not that ZoneInfo("UTC") also fails:

===
   >>> ZoneInfo("UTC")
Traceback (most recent call last):
...
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key UTC'
===

So we would need to patch Python to detect missing tzdata and report something
like:

ZoneInfoNotInstalledError: 'No time zone information installed on the 
system,
you can only use UTC'

We would also need to ensure UTC work even without tzdata installed.

I would be reluctant to carry this as a downstream-only patch. And the upstream
window for changes like this has already closed for Python 3.12.

Does this mean that tzdata needs to be present for doing datetime /
timezone calculations at runtime with the zoneinfo module?
Would this Change require that all Python programs that use this
module add "Requires: tzdata"? I don't think that would be a
reasonable change.

There's a similar issue with some Rust libraries (and probably other
language-specific timezone handling libraries),

Yep, this is the case for rubygem-tzinfo. It would deserve recommends at
minimum, because in theory, the tzdata can be suplied by tzinfo-data gem
instead.

That might work with something like

Requires: (tzdata or rubygem(tzinfo-data))

We don't have rubygem-tzinfo-data in Fedora. But it can be installed via 
`gem install` or Bundler. So that is the reason for soft dependency.

Vít

Suggests: tzdata

(similarly for python, since there's a tzdata package on pypi as well)

But this comes at the cost of still pulling in tzdata, potentially in
different flavors and formats, in different stages of being outdated,
further bloating install size ... which is what this change is trying
to avoid?

So all this considered, I'm not sure whether this change is actually
worth it, if tzdata databases of some form will likely be pulled into
installs anyway.
I'd rather have *one* tzdata that's up-to-date and used by everything
(for example, so Python and Ruby programs can actually agree what time
it is).

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

Re: F39 Change Proposal: LLVM 17 (System-Wide)


On 27/06/2023 08:41, Tom Stellard wrote:

I mentioned this in a previous reply, but this is how other compilers like
gcc install their internal libraries and it's also where clang expects its
libraries to be installed.


Got it. Thanks.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: How to correctly use Upstream release monitoring functionality?

V Tue, Jun 27, 2023 at 08:34:50AM +0200, Petr Pisar napsal(a):
> You can also check an archive of the notification
> .
> 
There is
:

org.fedoraproject.prod.hotness.update.drop the-new-hotness saw an update
for 'cpr', but release-monitoring.org doesn't know what that project is
called in Fedora land JSON

It looks like a mapping from an upstream project to a Fedora package was not
defined at the time when Anitya detected a new version in the upstream.

Though, I don't fully understand the message. I thought that Anitya notifies
distributions only having set the mapping. Either the message is wrongly
worded, or my idea how it works is wrong.

-- Petr


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

Re: Orphaned packages looking for new maintainers

2023-06-27 Thread Jeffrey Stewart

Would like to take**golang-github-lithammer-dedent and aqemu but I 
believe I still need a sponsor. Anyone willing to sponsor?


On 6/9/23 07:24, Omair Majid wrote:

Hi,

Jens-Ulrik Petersen  writes:


What would be really helpful is to know how it compares with other Naskh fonts
like Paktype (current default) and Nafees, and even Noto Nastaliq Urdu
(they are all in Fedora 38).

I lack the tools/skills/knowledge/jargon to describe the differences I
see. Is there a guide for n00bs where they can read up on what sort of
things to compare and how to describe those differences?

Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List 
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report 
it:https://pagure.io/fedora-infrastructure/new_issue___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: LLVM 17 (System-Wide)

2023-06-27 Thread Tom Stellard


On 6/26/23 22:44, Vitaly Zaitsev via devel wrote:

On 26/06/2023 18:12, Aoife Moloney wrote:

* The Clang Resource Directory will be moved from /usr/lib64/clang/17/
to /usr/lib/clang/17/ this is the location of clang's internal headers
and runtime libraries like libomp and compiler-rt.


Why? /usr/lib is a directory for 32-bit and architecture agnostic libraries. 
64-bit must use /usr/lib64.



I mentioned this in a previous reply, but this is how other compilers like
gcc install their internal libraries and it's also where clang expects its
libraries to be installed.

-Tom
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: How to correctly use Upstream release monitoring functionality?

V Tue, Jun 27, 2023 at 02:03:36AM -, Felix Wang napsal(a):
> I see the Fedora documentation about Upstream release monitoring. First, add 
> the project to Anitya and map it to the corresponding Fedora package, and 
> secondly, enable the monitoring in its fedora-src repository. I have set 
> these for cpr package, but I didn't receive the related message about its 
> updating status. Could anyone can help me to explain and use this?
> 
> Ref:
> https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring/
> https://release-monitoring.org/project/66765/
> https://src.fedoraproject.org/rpms/cpr
> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=Fedora=Fedora%20EPEL=cpr

Did you enable the notifications first in Fedora
 and then in Anitya
? I guess if you do it in the
other way, a notification from Anitya is discarded by Fedora because
creating bug reports in Fedora's Bugzilla is disabled at the time of arrival
of the notification.

Otherwise, it's some kind of bug in the notification chain. You can file
i ticket to  or to
 to start an
investigation. You can also check an archive of the notification
.

-- Petr


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

[rpms/perl-WWW-Mechanize] PR #1: Updated Source0 to the URL that works


ppisar closed without merging a pull-request against the project: 
`perl-WWW-Mechanize` that you
are following.

Closed pull-request:

``
Updated Source0 to the URL that works
``

https://src.fedoraproject.org/rpms/perl-WWW-Mechanize/pull-request/1
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-WWW-Mechanize] PR #1: Updated Source0 to the URL that works