Re: packaging of nix

[Pratham Patel]

Hi!

At the moment, it's not possible to build a NixOS image that adheres to FHS. 
Therefore, we can either

1. Add the FHS support to NixOS, which makes the whole thing about using NixOS 
moot. BUT, maybe we can hack our way around it like so? ([snippet 
source](https://github.com/balsoft/nixos-fhs-compat/blob/7a94f4c372e209d6db6bc92dc1c3559a2b27c20e/modules/fhs.nix#L21-L34))
```nix
config = lib.mkIf config.environment.fhs.enable {
  systemd.tmpfiles.rules = lib.optionals config.environment.fhs.linkExes [
"L+ /bin - - - - /run/current-system/sw/bin"
"L+ /sbin- - - - /run/current-system/sw/bin"
"L+ /usr/bin - - - - /run/current-system/sw/bin"
  ] ++ lib.optionals config.environment.fhs.linkLibs ([
"L+ /lib - - - - /etc/lsb/lib"
"L+ /lib64   - - - - /etc/lsb/lib"
"L+ /usr/lib - - - - /etc/lsb/lib"
  ]);
  environment.sessionVariables.LD_LIBRARY_PATH = lib.mkIf 
config.environment.fhs.linkLibs (lib.mkForce "/lib");
  system.activationScripts.binsh = lib.mkIf config.environment.fhs.linkExes 
(lib.mkForce "");
  system.activationScripts.usrbinenv = lib.mkIf config.environment.fhs.linkExes 
(lib.mkForce "");
};
```

2. Add non-FHS support to mkosi, which--if done correctly--might help with Guix 
too. This is just a thought, since I'm not sure how to approach this.

About Nix (the package manager), I would love to help with that, since most of 
the folks that want to try Nix might do a `sudo dnf install nix`. I looked at 
your COPR and noticed the dist-git repo. Since I'm very new to the dist-git 
workflow, can you point me to the actual git repo for it? I'm looking for 
_unresolved_ issues that you (and other testers) have documented so far in the 
issue tracker.

I'm dogfooding myself with Fedora on the Orange Pi 5 (custom image I built for 
myself) to improve the AArch64 experience and would love to report back with 
generic/arm-specific issues!
--
___
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 2251844] perl-IO-Tty-1.18 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-IO-Tty-1.18-1.fc38.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=109641925


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202251844%23c2
--
___
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 2251844] perl-IO-Tty-1.18 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 2001778
  --> https://bugzilla.redhat.com/attachment.cgi?id=2001778=edit
Update to 1.18 (#2251844)


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202251844%23c1
--
___
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 2251844] New: perl-IO-Tty-1.18 is available

[bugzilla]

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

Bug ID: 2251844
   Summary: perl-IO-Tty-1.18 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-IO-Tty
  Keywords: FutureFeature, Triaged
  Assignee: spo...@gmail.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mspa...@redhat.com,
p...@city-fan.org, perl-devel@lists.fedoraproject.org,
ppi...@redhat.com, spo...@gmail.com, st...@silug.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 1.18
Upstream release that is considered latest: 1.18
Current version/release in rawhide: 1.17-4.fc39
URL: http://search.cpan.org/dist/IO-Tty/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


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


Based on the information from Anitya:
https://release-monitoring.org/project/7281/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-IO-Tty


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202251844%23c0
--
___
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

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-1c906d04ee   
golang-1.20.10-3.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-a371f42add   
openssl11-1.1.1k-6.el7


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

anope-2.1.0-2.el7

Details about builds:



 anope-2.1.0-2.el7 (FEDORA-EPEL-2023-1a96479505)
 IRC services designed for flexibility and ease of use

Update Information:

# Anope 2.1.0- Added `nickserv:minpasslen` for configuring the minimum
password length   - Added support for access list entry descriptions.   - Added
support for linking over a UNIX socket.   - Added support for server-initiated
logins and logouts on UnrealIRCd   - Added support for server-initiated logouts
on InspIRCd   - Added support for the `ANONYMOUS SASL` mechanism   - Allowed
users to opt-out of being added to channel access lists   - Cleaned up the
codebase to use Modern C++17   - Modernized the build system to use a modern
version of CMake   - Removed `nickserv:strictpasswords` as it is obsolete now
`nickserv:minpasslen` exists   - Removed support for using insecure encryption
methods as the primary method   - Removed the Windows-only `anopesmtp` tool   -
Removed the `inspircd12` and `inspircd20` modules (use `inspircd` instead)   -
Removed the `ns_getpass` module (no supported encryption modules)   - Removed
the `os_oline` module (no supported IRCds)   - Removed the two day X-line cap
- Removed the `unreal` module (use `unrealircd` instead)   - Renamed
`nickserv:passlen` to `nickserv:maxpasslen`   - Renamed the `charybdis` module
to `solanum`   - Renamed the `inspircd3` module to `inspircd`   - Renamed the
`unreal4` module to `unrealircd`   - Replaced `uplink:ipv6` with
`uplink:protocol`   - Updated all references to IRCServices to refer to Anope
instead

ChangeLog:

* Mon Nov 27 2023 Robert Scheck  2.1.0-2
- Reflect upstream configuration file changes and renamings
* Sun Nov 26 2023 Robert Scheck  2.1.0-1
- Upgrade to 2.1.0 (#2251530)

References:

  [ 1 ] Bug #2251530 - anope-2.1.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2251530


--
___
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] Fedora EPEL 8 updates-testing report

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-330054b0a8   
dbus-broker-28-4.el8


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

anope-2.1.0-2.el8
bitcoin-core-selinux-0-11.20231127git4505616.el8

Details about builds:



 anope-2.1.0-2.el8 (FEDORA-EPEL-2023-f67d8ae3e9)
 IRC services designed for flexibility and ease of use

Update Information:

# Anope 2.1.0- Added `nickserv:minpasslen` for configuring the minimum
password length   - Added support for access list entry descriptions.   - Added
support for linking over a UNIX socket.   - Added support for server-initiated
logins and logouts on UnrealIRCd   - Added support for server-initiated logouts
on InspIRCd   - Added support for the `ANONYMOUS SASL` mechanism   - Allowed
users to opt-out of being added to channel access lists   - Cleaned up the
codebase to use Modern C++17   - Modernized the build system to use a modern
version of CMake   - Removed `nickserv:strictpasswords` as it is obsolete now
`nickserv:minpasslen` exists   - Removed support for using insecure encryption
methods as the primary method   - Removed the Windows-only `anopesmtp` tool   -
Removed the `inspircd12` and `inspircd20` modules (use `inspircd` instead)   -
Removed the `ns_getpass` module (no supported encryption modules)   - Removed
the `os_oline` module (no supported IRCds)   - Removed the two day X-line cap
- Removed the `unreal` module (use `unrealircd` instead)   - Renamed
`nickserv:passlen` to `nickserv:maxpasslen`   - Renamed the `charybdis` module
to `solanum`   - Renamed the `inspircd3` module to `inspircd`   - Renamed the
`unreal4` module to `unrealircd`   - Replaced `uplink:ipv6` with
`uplink:protocol`   - Updated all references to IRCServices to refer to Anope
instead

ChangeLog:

* Mon Nov 27 2023 Robert Scheck  2.1.0-2
- Reflect upstream configuration file changes and renamings
* Sun Nov 26 2023 Robert Scheck  2.1.0-1
- Upgrade to 2.1.0 (#2251530)

References:

  [ 1 ] Bug #2251530 - anope-2.1.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2251530




 bitcoin-core-selinux-0-11.20231127git4505616.el8 (FEDORA-EPEL-2023-c3a0dc1d80)
 Bitcoin Core SELinux policy

Update Information:

Fix policies for daemon case.

ChangeLog:

* Mon Nov 27 2023 Simone Caronni  - 
0-11.20231127git4505616
- Update policies (#2246255).
* Wed Jul 19 2023 Fedora Release Engineering  - 
0-10.20210312giteaa9a04
- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
* Wed Jan 18 2023 Fedora Release Engineering  - 
0-9.20210312giteaa9a04
- Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
* Wed Jul 20 2022 Fedora Release Engineering  - 
0-8.20210312giteaa9a04
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild

References:

  [ 1 ] Bug #2246255 - SELinux denial of bitcoind reading 
/etc/bitcoin/bitcoin.conf
https://bugzilla.redhat.com/show_bug.cgi?id=2246255


--
___
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: [HEADS UP] Jasper update with .so name update

[Orion Poplawski]

On 11/27/23 13:31, Adam Williamson wrote:

On Tue, 2023-11-21 at 10:55 +0100, Josef Řídký wrote:

Hi,

there is a new jasper version (4.1.0) that will be available in Fedora 40+.
As this version is bumping it's .so name, the rebuild of the dependent
package will be necessary.

There is a side tag created for safe rebuild of those packages
(f40-build-side-77302) with a new jasper version available.

I would like to ask maintainers of affected packages to rebuild their
packages using this tag, so I will be able to push the update to f40 once
all is done.

List of affected packages is:
- eccodes-devel
- g2clib-devel
- grib_api-devel


Somehow your list is far too short:

[adamw@xps13a tmp]$ sudo dnf repoquery --whatrequires
"libjasper.so.6()(64bit)"
DevIL-0:1.7.8-42.fc39.x86_64
DevIL-ILUT-0:1.7.8-42.fc39.x86_64
GraphicsMagick-0:1.3.40-3.fc39.x86_64
LibRaw-0:0.21.1-6.fc40.x86_64
OpenSceneGraph-libs-0:3.6.5-19.fc40.x86_64
dcraw-0:9.28.0-20.fc39.x86_64
digikam-libs-0:8.1.0-3.fc39.x86_64
eccodes-0:2.32.1-1.fc40.x86_64
gegl04-0:0.4.46-1.fc40.x86_64
grib_api-0:1.27.0-19.fc39.x86_64
jasper-0:3.0.6-4.fc39.x86_64
jasper-devel-0:3.0.6-4.fc39.x86_64
jasper-utils-0:3.0.6-4.fc39.x86_64
kdelibs-6:4.14.38-40.fc40.x86_64
kdelibs3-0:3.5.10-123.fc40.x86_64
libicns-0:0.8.1-27.fc39.x86_64
ncl-0:6.6.2-38.fc40.x86_64
netpbm-progs-0:11.02.00-2.fc39.x86_64
qt5-qtimageformats-0:5.15.11-1.fc40.x86_64
qt6-qtimageformats-0:6.6.0-1.fc40.x86_64
wgrib2-0:3.1.3-1.fc40.x86_64

the update failed gating because of qt5-qtimageformats, but all the
others also ought to be rebuilt onto the side tag before this is
pushed.


I've built most of these and working on the rest - but I think we're 
bumping into a qt6 update at the same time.  Pinging maintainers here.


Other issues:

kdelibs/kdelibs3 are FTBFS


--
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic 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: Possible deprecation/removal of Initial Setup from Fedora

[Dennis Gilmore via devel]

On Thu, Nov 23, 2023 at 6:51 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Wed, Nov 22, 2023 at 01:53:14PM +0100, Gerd Hoffmann wrote:
> > On Tue, Nov 21, 2023 at 08:07:06AM -0800, Davide Cavalca wrote:
> > > On 2023-11-21 04:34, Jiri Konecny wrote:
> > > > Is Anaconda Initial Setup important for your project or workflow? What
> > > > functionality is absolutely necessary for you? Do you use the text
> > > > mode or the graphical mode? Are you aware of any alternatives? Is
> > > > there anything that would prevent you from migrating to one of the
> > > > proposed alternatives? Also please feel free to share this mail to any
> > > > relevant groups.
> > >
> > > The Fedora Asahi Remix uses initial-setup (in text mode) for our Server 
> > > and
> > > Minimal variants.
> >
> > I think this is used by *all* server images.  It offers to set the root
> > password and add users, so without that you simply can't login ...
>
> systemd-firstboot can set the root user password, but it cannot create
> other users. But maybe we should extend it allow that. We recently had
> a discussion about adding support for creating "normal" users from
> systemd-sysusers, and the conclusion was that we can add a basic mode
> where /etc/skel is copied and the user is written to file databases.
> If people think this would be useful, I could that this idea upstream.

Does it allow for setting the network, language, hostname, and timezone?

Dennis
--
___
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] Jasper update with .so name update

[Adam Williamson]

On Tue, 2023-11-21 at 10:55 +0100, Josef Řídký wrote:
> Hi,
> 
> there is a new jasper version (4.1.0) that will be available in Fedora 40+.
> As this version is bumping it's .so name, the rebuild of the dependent
> package will be necessary.
> 
> There is a side tag created for safe rebuild of those packages
> (f40-build-side-77302) with a new jasper version available.
> 
> I would like to ask maintainers of affected packages to rebuild their
> packages using this tag, so I will be able to push the update to f40 once
> all is done.
> 
> List of affected packages is:
> - eccodes-devel
> - g2clib-devel
> - grib_api-devel

Somehow your list is far too short:

[adamw@xps13a tmp]$ sudo dnf repoquery --whatrequires
"libjasper.so.6()(64bit)"
DevIL-0:1.7.8-42.fc39.x86_64
DevIL-ILUT-0:1.7.8-42.fc39.x86_64
GraphicsMagick-0:1.3.40-3.fc39.x86_64
LibRaw-0:0.21.1-6.fc40.x86_64
OpenSceneGraph-libs-0:3.6.5-19.fc40.x86_64
dcraw-0:9.28.0-20.fc39.x86_64
digikam-libs-0:8.1.0-3.fc39.x86_64
eccodes-0:2.32.1-1.fc40.x86_64
gegl04-0:0.4.46-1.fc40.x86_64
grib_api-0:1.27.0-19.fc39.x86_64
jasper-0:3.0.6-4.fc39.x86_64
jasper-devel-0:3.0.6-4.fc39.x86_64
jasper-utils-0:3.0.6-4.fc39.x86_64
kdelibs-6:4.14.38-40.fc40.x86_64
kdelibs3-0:3.5.10-123.fc40.x86_64
libicns-0:0.8.1-27.fc39.x86_64
ncl-0:6.6.2-38.fc40.x86_64
netpbm-progs-0:11.02.00-2.fc39.x86_64
qt5-qtimageformats-0:5.15.11-1.fc40.x86_64
qt6-qtimageformats-0:6.6.0-1.fc40.x86_64
wgrib2-0:3.1.3-1.fc40.x86_64

the update failed gating because of qt5-qtimageformats, but all the
others also ought to be rebuilt onto the side tag before this is
pushed.
-- 
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: Possible deprecation/removal of Initial Setup from Fedora

[Leslie Satenstein via devel]

I am not sure of the difference between text mode and graphical mode, except 
that I am an end-user of anaconda,and I use it via the Everything.iso.  
Therein, anaconda is a mixed mode, with text / graphical for partition 
management(creating, mounting,deleting)
and graphical mode for application and application-group selection/subselection.
FWIW, I like the existing functionality, with one suggest enhancement -- put a 
2 line text description for each of the subgroups that are part of a main 
group. 



Leslie Satenstein
 

On Monday, November 27, 2023 at 11:22:17 a.m. EST, Adam Williamson 
 wrote:  
 
 On Mon, 2023-11-27 at 14:12 +0100, mkol...@redhat.com wrote:
> On Fri, 2023-11-24 at 15:15 -0800, Adam Williamson wrote:
> > On Tue, 2023-11-21 at 13:34 +0100, Jiri Konecny wrote:
> > > Hello everyone,
> > > 
> > > Is Anaconda Initial Setup important for your project or workflow?
> > > What 
> > > functionality is absolutely necessary for you? Do you use the text
> > > mode 
> > > or the graphical mode? Are you aware of any alternatives? Is there 
> > > anything that would prevent you from migrating to one of the
> > > proposed 
> > > alternatives? Also please feel free to share this mail to any
> > > relevant 
> > > groups.
> > 
> > In addition to the other uses identified: if you do a KDE install and
> > set the root password but do not create a user account, i-s will run
> > on
> > first boot and allow (not sure if it requires) user creation. This is
> > probably the case for other non-GNOME desktops too (GNOME uses its
> > own
> > gnome-initial-setup).
> Sure, but is this really necessary on those images ? If it only
> triggers if no user account is present only only provides user
> creation, what about enforcing user creation at installation time
> instead ? 
> 
> That would simplify the whole thing, as there would be less scenarios
> to test/debug/go wrong.

The problem, as always, is different use cases. We want to very
strongly encourage people to create a user before logging in on KDE
installs, as we really don't want people using KDE as root. But for a
small headless install, someone might want to operate as root without a
user account.

Workstation has sorted this out by disabling user/root spokes in the
installer entirely and having its own g-i-s which requires creation of
an admin user, but we don't have anything like that in place for KDE
currently. So we have to try and manage both KDE and e.g. a minimal or
Server install as best we can, using essentially the same workflows.

If someone wants to do some customization for KDE, of course, that
could help.
-- 
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
  --
___
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: libxml2 2.12.0 (and 2.12.1) in rawhide, with some API breaks

[Tomasz Kłoczko]

On Mon, 27 Nov 2023 at 17:17, Frederic Berat  wrote:

> ERROR: Error in gtkdoc helper script:
>
> ERROR: ['/usr/bin/gtkdoc-mkhtml', 
> '--path=/builddir/build/BUILD/cinnamon-5.8.4/docs/reference/cinnamon:/builddir/build/BUILD/cinnamon-5.8.4/redhat-linux-build/docs/reference/cinnamon',
>  'cinnamon', '../cinnamon-docs.sgml'] failed with status 6
> warning: failed to load external entity "../xml/cinnamon-recorder.xml"
> ../recorder.xml:10: element include: XInclude error : could not load 
> ../xml/cinnamon-recorder.xml, and no fallback was found
>
> BTW repositories management: createrepo-c needs libxml 2.12.x adjustment as
well.
It is already integrated in createrepo-c git repo.

API has changed slightly not only because  has been
removed but in the same cases it needs some minor adjustments because of
some const declarations (look on libvirt-glib today commited changes by
maintainer).

Nevertheless, just FTR: ABI has not changed.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
--
___
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: libxml2 2.12.0 (and 2.12.1) in rawhide, with some API breaks

[Frederic Berat]

Le lun. 27 nov. 2023, 16:45, Leigh Scott  a écrit :

> > On Fri, Nov 24, 2023 at 12:07 PM David King  wrote:
>
> > - Out of the 13 packages that seem correlated but don't show obvious
> errors
> > directly related to libxml2, there are still some quite suspicious ones,
> > like cinnamon which fails due to a missing xml file.
>
> > [1] https://copr.fedorainfracloud.org/coprs/fberat/mass-prebuild/
> > [2] https://gitlab.com/fedora/packager-tools/mass-prebuild
>
> Do you have the error message for the cinnamon issue?
>

ERROR: Error in gtkdoc helper script:

ERROR: ['/usr/bin/gtkdoc-mkhtml',
'--path=/builddir/build/BUILD/cinnamon-5.8.4/docs/reference/cinnamon:/builddir/build/BUILD/cinnamon-5.8.4/redhat-linux-build/docs/reference/cinnamon',
'cinnamon', '../cinnamon-docs.sgml'] failed with status 6
warning: failed to load external entity "../xml/cinnamon-recorder.xml"
../recorder.xml:10: element include: XInclude error : could not load
../xml/cinnamon-recorder.xml, and no fallback was found


You have the full log here:

https://download.copr.fedorainfracloud.org/results/fberat/mpb.221/fedora-39-x86_64/06691050-cinnamon/builder-live.log.gz


--

___
> 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: [Anaconda-devel] Re: Possible deprecation/removal of Initial Setup from Fedora

[Dennis Gilmore via devel]

On Mon, Nov 27, 2023 at 7:53 AM Neal Gompa  wrote:
>
> On Mon, Nov 27, 2023 at 8:13 AM  wrote:
> >
> > On Fri, 2023-11-24 at 15:15 -0800, Adam Williamson wrote:
> > > On Tue, 2023-11-21 at 13:34 +0100, Jiri Konecny wrote:
> > > > Hello everyone,
> > > >
> > > > Is Anaconda Initial Setup important for your project or workflow?
> > > > What
> > > > functionality is absolutely necessary for you? Do you use the text
> > > > mode
> > > > or the graphical mode? Are you aware of any alternatives? Is there
> > > > anything that would prevent you from migrating to one of the
> > > > proposed
> > > > alternatives? Also please feel free to share this mail to any
> > > > relevant
> > > > groups.
> > >
> > > In addition to the other uses identified: if you do a KDE install and
> > > set the root password but do not create a user account, i-s will run
> > > on
> > > first boot and allow (not sure if it requires) user creation. This is
> > > probably the case for other non-GNOME desktops too (GNOME uses its
> > > own
> > > gnome-initial-setup).
> > Sure, but is this really necessary on those images ? If it only
> > triggers if no user account is present only only provides user
> > creation, what about enforcing user creation at installation time
> > instead ?
> >
>
> That is not possible in all cases. Two cases offhand that it is not possible 
> on:
>
> * ARM images
> * OEM preload images
>
> These two cases require us to not pre-configure a user but also allow
> the user to be created on first boot.


These use cases do more than just creating a user account, the user
can also choose to set a root password, set the system timezone, set
the system language, configure the network and hostname. I have pasted
below the first screen you get on initial setup on the Minimal Arm
image

1) [ ] Language settings 2) [x] Time settings
   (Language is not set.)   (America/New_York timezone)
3) [x] Network configuration 4) [!] Root password
   (Connected: enp1s0)  (Root account is disabled)
5) [!] User creation
   (No user will be created)

Dennis

>
>
> --
> 真実はいつも一つ！/ 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
--
___
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: Possible deprecation/removal of Initial Setup from Fedora

[Adam Williamson]

On Mon, 2023-11-27 at 14:12 +0100, mkol...@redhat.com wrote:
> On Fri, 2023-11-24 at 15:15 -0800, Adam Williamson wrote:
> > On Tue, 2023-11-21 at 13:34 +0100, Jiri Konecny wrote:
> > > Hello everyone,
> > > 
> > > Is Anaconda Initial Setup important for your project or workflow?
> > > What 
> > > functionality is absolutely necessary for you? Do you use the text
> > > mode 
> > > or the graphical mode? Are you aware of any alternatives? Is there 
> > > anything that would prevent you from migrating to one of the
> > > proposed 
> > > alternatives? Also please feel free to share this mail to any
> > > relevant 
> > > groups.
> > 
> > In addition to the other uses identified: if you do a KDE install and
> > set the root password but do not create a user account, i-s will run
> > on
> > first boot and allow (not sure if it requires) user creation. This is
> > probably the case for other non-GNOME desktops too (GNOME uses its
> > own
> > gnome-initial-setup).
> Sure, but is this really necessary on those images ? If it only
> triggers if no user account is present only only provides user
> creation, what about enforcing user creation at installation time
> instead ? 
> 
> That would simplify the whole thing, as there would be less scenarios
> to test/debug/go wrong.

The problem, as always, is different use cases. We want to very
strongly encourage people to create a user before logging in on KDE
installs, as we really don't want people using KDE as root. But for a
small headless install, someone might want to operate as root without a
user account.

Workstation has sorted this out by disabling user/root spokes in the
installer entirely and having its own g-i-s which requires creation of
an admin user, but we don't have anything like that in place for KDE
currently. So we have to try and manage both KDE and e.g. a minimal or
Server install as best we can, using essentially the same workflows.

If someone wants to do some customization for KDE, of course, that
could help.
-- 
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

[python-SIG] Introduction new member

[seddik alaoui ismaili]

Hi Folks,

I'm seddik, I have joined Fedora Infrastructure Community in July 2020 as a
contributor. So I'm helping with automation and monitoring tasks.
I have a little experience on python programming, and would be happy to get
involved as much as ever.

Please feel free to help me with any documentation, or process related to
fedora python contribution. I would love to help/ maintain a python
application.

I found these links :

https://fedoraproject.org/wiki/SIGs/Python#Areas_of_contribution
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED_status=MODIFIED_status=ON_DEV_status=ON_QA_status=VERIFIED_status=RELEASE_PENDING_status=POST=Package%20Review_id=13374947=Fedora_format=advanced_desc=python_desc_type=allwordssubstr
https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/


Regards,

*Seddik *
Nickname (irc / matrix ): *saibug*
--
___
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

[Bug 2251788] perl-Net-DNS-1.41 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Net-DNS-1.41-1.fc38.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=109620540


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202251788%23c2
--
___
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: libxml2 2.12.0 (and 2.12.1) in rawhide, with some API breaks

[Daniel P . Berrangé]

On Mon, Nov 27, 2023 at 04:20:16PM +0100, Fabio Valentini wrote:
> On Fri, Nov 24, 2023 at 12:08 PM David King  wrote:
> >
> > The latest released versions of libxml2 have a couple of important
> > changes in header files that have unintentionally caused some packages
> > to fail to build without modification, including:
> >
> > * several functions now accept or return a const xmlError struct
> > * cyclic dependencies in header files were fixed (by dropping some
> >includes)
> 
> Sorry if the answer to this question is obvious - but shouldn't
> breaking changes like these cause an soname bump?
> I realize the whole "unintentional" part - but if these changes also
> affect ABI (the first sounds like it might do that), dependent
> packages would need to be rebuilt either way, wouldn't they?

IIUC, the changes in libxml2 are API breaks, but not ABI breaks.

ie the 'xmlError' parameter should have been const all along,
and apps would have been using it as if it were const. The
API was changed to correct this mistake and should be backcompat
with an pre-existing compiled app, but cause warnings on new
builds. Annoying, but an acceptable change without soname bump.


With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
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: libxml2 2.12.0 (and 2.12.1) in rawhide, with some API breaks

[Leigh Scott]

> On Fri, Nov 24, 2023 at 12:07 PM David King  wrote:

> - Out of the 13 packages that seem correlated but don't show obvious errors
> directly related to libxml2, there are still some quite suspicious ones,
> like cinnamon which fails due to a missing xml file.

> [1] https://copr.fedorainfracloud.org/coprs/fberat/mass-prebuild/
> [2] https://gitlab.com/fedora/packager-tools/mass-prebuild

Do you have the error message for the cinnamon 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: Unannounced soname bump in F39 updates-testing kernel-tools-libs

[Justin Forbes]

On Sun, Nov 26, 2023 at 11:48 AM Chris Adams  wrote:
>
> kernel-tools-libs changed libcpupower.so.0 to libcpupower.so.1 in
> 6.6.2-200.fc39, which breaks mate-applets and gnome-applets.

This was backed out for the stable Fedora updates.  The soname bump
stands in F40.  Note, there is no functional change at all to
libcpupower.   Upstream decided to bump the soname due to API breaking
changes made back in 4.7 (2016).  Better late than never I suppose.

Justin

> --
> Chris Adams 
> --
> ___
> 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

[Bug 2251788] New: perl-Net-DNS-1.41 is available

[bugzilla]

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

Bug ID: 2251788
   Summary: perl-Net-DNS-1.41 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Net-DNS
  Keywords: FutureFeature, Triaged
  Assignee: paul.wout...@aiven.io
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: ka...@ucw.cz, mspa...@redhat.com,
paul.wout...@aiven.io,
perl-devel@lists.fedoraproject.org, rstr...@redhat.com
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 1.41
Upstream release that is considered latest: 1.41
Current version/release in rawhide: 1.40-1.fc40
URL: https://metacpan.org/dist/Net-DNS/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


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


Based on the information from Anitya:
https://release-monitoring.org/project/3147/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-Net-DNS


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202251788%23c0
--
___
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 2251788] perl-Net-DNS-1.41 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 2001731
  --> https://bugzilla.redhat.com/attachment.cgi?id=2001731=edit
Update to 1.41 (#2251788)


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202251788%23c1
--
___
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: libxml2 2.12.0 (and 2.12.1) in rawhide, with some API breaks

[Fabio Valentini]

On Fri, Nov 24, 2023 at 12:08 PM David King  wrote:
>
> The latest released versions of libxml2 have a couple of important
> changes in header files that have unintentionally caused some packages
> to fail to build without modification, including:
>
> * several functions now accept or return a const xmlError struct
> * cyclic dependencies in header files were fixed (by dropping some
>includes)

Sorry if the answer to this question is obvious - but shouldn't
breaking changes like these cause an soname bump?
I realize the whole "unintentional" part - but if these changes also
affect ABI (the first sounds like it might do that), dependent
packages would need to be rebuilt either way, wouldn't they?

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

Re: libxml2 2.12.0 (and 2.12.1) in rawhide, with some API breaks

[Remi Collet]

Le 27/11/2023 à 14:23, Frederic Berat a écrit :

I made a mass rebuild of the packages that directly depend on libxml2, 
and found 115 packages (out of 621) with build failure correlated to the 
libxml2 update.


I see PHP in the failure report

The issue is fixed upstream
https://github.com/php/php-src/commit/8a95e616b91ac0eeedba90a61e36e652919763f2


The patch is in 8.3.0 in rawhide
(and will be in 8.2.14 in F39 in 3 weeks)


Remi
--
___
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: libxml2 2.12.0 (and 2.12.1) in rawhide, with some API breaks

[Mamoru TASAKA]

Frederic Berat wrote on 2023/11/27 22:23:

On Fri, Nov 24, 2023 at 12:07 PM David King  wrote:


The latest released versions of libxml2 have a couple of important
changes in header files that have unintentionally caused some packages
to fail to build without modification, including:

* several functions now accept or return a const xmlError struct
* cyclic dependencies in header files were fixed (by dropping some
includes)

Most failures that have been witnessed so far by davidlt while
rebuilding RISCV packages, and have been related to the xmlError const
change, but xmlsec1 was hit by the include changes:

https://github.com/lsh123/xmlsec/pull/729
https://src.fedoraproject.org/rpms/xmlsec1/pull-request/4

As libxml2 is used rather widely, I expect more changes to come up over
time, so please feel free to ask me for help (amigadave on IRC, or Cc
  on bugs) and I will be happy to submit patches
upstream and do builds; I am a provenpackager, so happy to help.

Thanks to davidlt for spotting the breakages!


Hello,

I made a mass rebuild of the packages that directly depend on libxml2, and
found 115 packages (out of 621) with build failure correlated to the
libxml2 update.
Out of these 115 packages, 102 so far are highly related (i.e. they show
xml related errors in the build logs).

Few notes:
- Since the new version of libxml2 is already in rawhide I made the mass
rebuild on F39 with it instead of a rawhide build. That implies that some
of the packages may already have been fixed but that still gives a rough
idea on potential problems. I threfore started a mass-rebuild on rawhide to
cross-check, but I don't have a report to give yet.
- Out of the 13 packages that seem correlated but don't show obvious errors
directly related to libxml2, there are still some quite suspicious ones,
like cinnamon which fails due to a missing xml file.

When you plan to do such an update, I can only recommend you to do a mass
prebuild [1][2].

Full report can be found attached. I also added a log file listing the
obvious failures.

I hope that helps a bit.

Fred.

[1]https://copr.fedorainfracloud.org/coprs/fberat/mass-prebuild/
[2]https://gitlab.com/fedora/packager-tools/mass-prebuild


 lxappearance-obconf:
 Source: (distgit) fedora
 NVR: lxappearance-obconf-0.2.3^20230918git63c5dc1b-1.fc39
 Commit/branch: 7219a560762102a88b77331424ef536d7183581a



 rubygem-nokogiri:
 Source: (distgit) fedora
 NVR: rubygem-nokogiri-1.15.4-1.fc39
 Commit/branch: 8820fad4b3e368c60c5cd255ce92b244133446ba



 yaz:
 Source: (distgit) fedora
 NVR: yaz-5.34.0-4.fc39
 Commit/branch: cff7180eae835591dc5d64930e75082a593243a1


I've fixed these 3 packages. (koschei was complaining.)

Note that we are planning to do mass rebuild for upcoming ruby3.3:

https://fedoraproject.org/wiki/Changes/Ruby_3.3 ,

but some packages which need rebuilding for ruby3.3 are listed in
this "fails to build with libxml2 2.12.0" list (i.e. rebuild of some
packages will fail due to the reason unrelated to ruby).
So when we do mass rebuild for ruby3.3 on side-tag and that side-tag
gets merged, some dependency breakage is perhaps going to happen.

I appreciated it if libxml2 2.12.0 related build failure will be addressed
by the corresponding maintainers.

Regards,
Mamoru
--
___
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: libxml2 2.12.0 (and 2.12.1) in rawhide, with some API breaks

[Daniel P . Berrangé]

On Mon, Nov 27, 2023 at 02:23:51PM +0100, Frederic Berat wrote:
> On Fri, Nov 24, 2023 at 12:07 PM David King  wrote:
> 
> > The latest released versions of libxml2 have a couple of important
> > changes in header files that have unintentionally caused some packages
> > to fail to build without modification, including:
> >
> > * several functions now accept or return a const xmlError struct
> > * cyclic dependencies in header files were fixed (by dropping some
> >includes)
> >
> > Most failures that have been witnessed so far by davidlt while
> > rebuilding RISCV packages, and have been related to the xmlError const
> > change, but xmlsec1 was hit by the include changes:
> >
> > https://github.com/lsh123/xmlsec/pull/729
> > https://src.fedoraproject.org/rpms/xmlsec1/pull-request/4
> >
> > As libxml2 is used rather widely, I expect more changes to come up over
> > time, so please feel free to ask me for help (amigadave on IRC, or Cc
> >  on bugs) and I will be happy to submit patches
> > upstream and do builds; I am a provenpackager, so happy to help.
> >
> > Thanks to davidlt for spotting the breakages!
> >
> 
> Hello,
> 
> I made a mass rebuild of the packages that directly depend on libxml2, and
> found 115 packages (out of 621) with build failure correlated to the
> libxml2 update.
> Out of these 115 packages, 102 so far are highly related (i.e. they show
> xml related errors in the build logs).
> 
> Few notes:
> - Since the new version of libxml2 is already in rawhide I made the mass
> rebuild on F39 with it instead of a rawhide build. That implies that some
> of the packages may already have been fixed but that still gives a rough
> idea on potential problems. I threfore started a mass-rebuild on rawhide to
> cross-check, but I don't have a report to give yet.
> - Out of the 13 packages that seem correlated but don't show obvious errors
> directly related to libxml2, there are still some quite suspicious ones,
> like cinnamon which fails due to a missing xml file.
> 
> When you plan to do such an update, I can only recommend you to do a mass
> prebuild [1][2].
> 
> Full report can be found attached. I also added a log file listing the
> obvious failures.
> 
> I hope that helps a bit.
> 
> Fred.
> 
> [1] https://copr.fedorainfracloud.org/coprs/fberat/mass-prebuild/
> [2] https://gitlab.com/fedora/packager-tools/mass-prebuild
> 

> libosinfo: 
> Source: (distgit) fedora
> NVR: libosinfo-1.11.0-1.fc39
> Commit/branch: 74d2faa889b6199ce7a6b1dfb584d36793796ffb

Not yet fixed upstream, but will get it addressed.

> libvirt: 
> Source: (distgit) fedora
> NVR: libvirt-9.7.0-1.fc39
> Commit/branch: 5828ec5da6d0d2496a964e09f492672b254870c0
> libvirt-glib: 
> Source: (distgit) fedora
> NVR: libvirt-glib-4.0.0-9.fc39
> Commit/branch: 3a288ed6f451fd2719432a9351df72577ae8dc8f

Fixed upstream, pending rawhide update

> virt-viewer: 
> Source: (distgit) fedora
> NVR: virt-viewer-11.0-7.fc39
> Commit/branch: 477761744846305911fd27650219906f7713fac3

Not yet fixed upstream, but will get it addressed.


With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
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: libxml2 2.12.0 (and 2.12.1) in rawhide, with some API breaks

[Richard W.M. Jones]

On Mon, Nov 27, 2023 at 02:23:51PM +0100, Frederic Berat wrote:
> guestfs-tools: 
> Source: (distgit) fedora
> NVR: guestfs-tools-1.51.5-1.fc39
> Commit/branch: 68563e35e7b92050a7c47eb01871e2caa166bf38

> libguestfs: 
> Source: (distgit) fedora
> NVR: libguestfs-1.51.7-1.fc39
> Commit/branch: 7f1b9ab59922175926d102ecb5d38a01ddc9b1e4

> virt-top: 
> Source: (distgit) fedora
> NVR: virt-top-1.1.1-13.fc39
> Commit/branch: b3038178961c557347ba9956ee395e20617772c6

> virt-v2v: 
> Source: (distgit) fedora
> NVR: virt-v2v-2.3.6-1.fc39
> Commit/branch: 06731df1314cced9968cee060a9164b86b23b0f1

I've fixed all of these upstream and I'll push the changes to Fedora
shortly.

Rich.

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

Re: [Anaconda-devel] Re: Possible deprecation/removal of Initial Setup from Fedora

[Neal Gompa]

On Mon, Nov 27, 2023 at 8:13 AM  wrote:
>
> On Fri, 2023-11-24 at 15:15 -0800, Adam Williamson wrote:
> > On Tue, 2023-11-21 at 13:34 +0100, Jiri Konecny wrote:
> > > Hello everyone,
> > >
> > > Is Anaconda Initial Setup important for your project or workflow?
> > > What
> > > functionality is absolutely necessary for you? Do you use the text
> > > mode
> > > or the graphical mode? Are you aware of any alternatives? Is there
> > > anything that would prevent you from migrating to one of the
> > > proposed
> > > alternatives? Also please feel free to share this mail to any
> > > relevant
> > > groups.
> >
> > In addition to the other uses identified: if you do a KDE install and
> > set the root password but do not create a user account, i-s will run
> > on
> > first boot and allow (not sure if it requires) user creation. This is
> > probably the case for other non-GNOME desktops too (GNOME uses its
> > own
> > gnome-initial-setup).
> Sure, but is this really necessary on those images ? If it only
> triggers if no user account is present only only provides user
> creation, what about enforcing user creation at installation time
> instead ?
>

That is not possible in all cases. Two cases offhand that it is not possible on:

* ARM images
* OEM preload images

These two cases require us to not pre-configure a user but also allow
the user to be created on first boot.



-- 
真実はいつも一つ！/ 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: libxml2 2.12.0 (and 2.12.1) in rawhide, with some API breaks

[Frederic Berat]

On Fri, Nov 24, 2023 at 12:07 PM David King  wrote:

> The latest released versions of libxml2 have a couple of important
> changes in header files that have unintentionally caused some packages
> to fail to build without modification, including:
>
> * several functions now accept or return a const xmlError struct
> * cyclic dependencies in header files were fixed (by dropping some
>includes)
>
> Most failures that have been witnessed so far by davidlt while
> rebuilding RISCV packages, and have been related to the xmlError const
> change, but xmlsec1 was hit by the include changes:
>
> https://github.com/lsh123/xmlsec/pull/729
> https://src.fedoraproject.org/rpms/xmlsec1/pull-request/4
>
> As libxml2 is used rather widely, I expect more changes to come up over
> time, so please feel free to ask me for help (amigadave on IRC, or Cc
>  on bugs) and I will be happy to submit patches
> upstream and do builds; I am a provenpackager, so happy to help.
>
> Thanks to davidlt for spotting the breakages!
>

Hello,

I made a mass rebuild of the packages that directly depend on libxml2, and
found 115 packages (out of 621) with build failure correlated to the
libxml2 update.
Out of these 115 packages, 102 so far are highly related (i.e. they show
xml related errors in the build logs).

Few notes:
- Since the new version of libxml2 is already in rawhide I made the mass
rebuild on F39 with it instead of a rawhide build. That implies that some
of the packages may already have been fixed but that still gives a rough
idea on potential problems. I threfore started a mass-rebuild on rawhide to
cross-check, but I don't have a report to give yet.
- Out of the 13 packages that seem correlated but don't show obvious errors
directly related to libxml2, there are still some quite suspicious ones,
like cinnamon which fails due to a missing xml file.

When you plan to do such an update, I can only recommend you to do a mass
prebuild [1][2].

Full report can be found attached. I also added a log file listing the
obvious failures.

I hope that helps a bit.

Fred.

[1] https://copr.fedorainfracloud.org/coprs/fberat/mass-prebuild/
[2] https://gitlab.com/fedora/packager-tools/mass-prebuild



> --
> https://amigadave.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
>

# Mass-prebuild mpb.221 (ID:221)

This report was generated using mpb-report 1.2.1.dev0+gd74b038.d20231127

## General information

Build location: https://copr.fedorainfracloud.org/coprs/fberat/mpb.221
Chroot: fedora-rawhide
Tested architectures: x86_64

Main packages tested:

libxml2: 
Source: (file) /home/fberat/work/mpb/libxml2/libxml2-2.12.1-1.fc40.src.rpm
NVR: libxml2-2.10.4-3.fc39
Commit/branch: f39

## Overall status

618 out of 621 builds are done.
Running: 1 
Success: 487   
Under check: 2 
Manual confirmation needed: 16
Failed: 115   

## List of failed packages

0ad: 
Source: (distgit) fedora
NVR: 0ad-0.0.26-14.fc39
Commit/branch: f832f129b1a0cc5508223846fac14ae3fac9f41a
PDAL: 
Source: (distgit) fedora
NVR: PDAL-2.5.6-1.fc39
Commit/branch: 3bdb75f20016fc6eeb05d72171318c41f9e2280d
R-XML: 
Source: (distgit) fedora
NVR: R-XML-3.99.0.10-4.fc39
Commit/branch: 2377247efc63c629503710fc2d0116a9d824730c
R-xml2: 
Source: (distgit) fedora
NVR: R-xml2-1.3.4-2.fc39
Commit/branch: 5a2d2cf844f2e52fe9ed46597439dea50168e4fb
abiword: 
Source: (distgit) fedora
NVR: abiword-3.0.5-9.fc39
Commit/branch: 57149a875dec5c87fe20f25ee1d4394eeafbddbd
ardour6: 
Source: (distgit) fedora
NVR: ardour6-6.9.0-13.fc38
Commit/branch: 1f9ebf39fd9c78f34c9a5118c5cc4278ff9ad3ac
ardour7: 
Source: (distgit) fedora
NVR: ardour7-7.5.0-1.fc39
Commit/branch: 2048db73d6759e84debfa2d329d0ac00c0f84d7a
ardour8: 
Source: (distgit) fedora
NVR: ardour8-8.1.0-1.fc39
Commit/branch: 90bb3ebe1690c7d68d65d43a588d90e03c83c4b3
atril: 
Source: (distgit) fedora
NVR: atril-1.26.1-3.fc39
Commit/branch: 7f9290e6c1dc7ad99e7bf30ac13d74ce22bc0b20
audacious-plugins: 
Source: (distgit) fedora
NVR: audacious-plugins-4.3.1-3.fc39
Commit/branch: d280a3185a862aa392db56de1daf04fc874f1ad9
badwolf: 
Source: (distgit) fedora
NVR: badwolf-1.2.2-6.fc39
Commit/branch: 

unresponsive maintainer for python-installer

[Kaleb Keithley]

Is someone in contact with cstratak?

I started the non-responsive maintainer process [1], because I asked that
python-installer be branched and built for epel, or to add the EPEL
packagers SIG to the maintainers [2] on 14 Nov 2023 and added a NEEDINFO on
16 Nov.

Even after allowing for holidays, PTOs, and etc., there is still no
response.

Thanks

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2251761
[2] https://bugzilla.redhat.com/show_bug.cgi?id=2249631


-- 

Kaleb
--
___
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: Possible deprecation/removal of Initial Setup from Fedora

[mkolman]

On Fri, 2023-11-24 at 15:15 -0800, Adam Williamson wrote:
> On Tue, 2023-11-21 at 13:34 +0100, Jiri Konecny wrote:
> > Hello everyone,
> > 
> > Is Anaconda Initial Setup important for your project or workflow?
> > What 
> > functionality is absolutely necessary for you? Do you use the text
> > mode 
> > or the graphical mode? Are you aware of any alternatives? Is there 
> > anything that would prevent you from migrating to one of the
> > proposed 
> > alternatives? Also please feel free to share this mail to any
> > relevant 
> > groups.
> 
> In addition to the other uses identified: if you do a KDE install and
> set the root password but do not create a user account, i-s will run
> on
> first boot and allow (not sure if it requires) user creation. This is
> probably the case for other non-GNOME desktops too (GNOME uses its
> own
> gnome-initial-setup).
Sure, but is this really necessary on those images ? If it only
triggers if no user account is present only only provides user
creation, what about enforcing user creation at installation time
instead ? 

That would simplify the whole thing, as there would be less scenarios
to test/debug/go wrong.

> 
> openQA tests this:
> https://openqa.fedoraproject.org/tests/2280185#step/_graphical_wait_login/1
> -- 
> 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
--
___
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: F40 Change Proposal: 389_Directory_Server_3.0.0 (System-Wide)

[Alexander Bokovoy]

On Пан, 27 ліс 2023, Aoife Moloney wrote:

Wiki: https://fedoraproject.org/wiki/Changes/389_Directory_Server_3.0.0

This is a proposed Change for Fedora Linux.
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 ==

389-ds-base upgrade from version 2.4.4 to the latest upstream version
3.0.0 in Fedora.
Newly created instances now are using LDMB database by default instead
of BerkeleyDB.


From FreeIPA side, we do support this proposal. The only caveat is that
once libdb is not available in Fedora, a direct in-place upgrade of
FreeIPA servers will not be possible and a process to upgrade through a
separate replica instance will need to be implemented.

The upgrade through a separate replica is already tested and supported
by FreeIPA. The scenario of upgrading an IPA instance in the case an
underlying library's (libdb) availability preventing an in-place
upgrade, is mostly a documentation and upgrade planning issue.

The very same upgrade process is already used by RHEL IdM when upgrading
from RHEL 7 to RHEL 8 and when upgrading from RHEL 8 to RHEL 9 where an
in-place upgrade is not supported for RHEL IdM servers. In RHEL it is
unrelated to the database change but rather to the way how IPA packages
get delivered (as a modular stream in RHEL 8 and again as plain RPMs in
RHEL 9) but conceptually it is the same situation.

For libdb removal, I'd suggest we aim to get it removed not earlier than
two Fedora releases after all libdb users were removed.






== Owner ==

* Name: 389 Directory Server Development Team

* Email: 389-devel (at) lists (dot) fedoraproject (dot) org
Primary contact:
* Name: [[User:progier| Pierre Rogier]]
* Email: progier (at) redhat (dot) com


== Detailed Description ==

Since Fedora 36 (389-ds-base 2.1.0), the 389 Directory Server supports
two kinds of underlying database:

* Berkeley Database (BDB)
* Lightning Memory-Mapped Database Manager (LMDB)

Newly created instances are still created with BDB by default while
libdb is flagged as [[Changes/Libdb deprecated - Fedora Project
Wiki|deprecated since Fedora 33]], this change is about to create
instances with LMDB by default.


== Feedback ==

No feedback yet.


== Benefit to Fedora ==
A step on the way to remove a deprecated piece of software no longer
supported by the upstream community.
(See https://fedoraproject.org/wiki/Changes/Libdb_deprecated)

== Scope ==

The change is quite limited in terms of development and interface
impact, but it impacts a critical component: FreeIPA.

[1] Impact on software that uses generic LDAP interface without any
specific 389DS features (like configuration tools and monitoring
entries):
No interface impact, but there may be some impact in terms of dynamic
(i.e: response time, maximum throughput). Especially if browsing (i.e
VLV) indexes are used on big lists.

[2] Impact on software that explicitly creates 389DS instances (like
FreeIPA) may also have to change the way the database is tuned.
(Especially the database maximum size: `nsslapd-mdb-max-size`)

[3] Impact on software that explicitly uses backend monitoring LDAP
entries: new attributes about LMDB specific data are present.

There are no packages in [3] case and FreeIPA is the only one in [2]
case but there is likely an unknown number of software in [1] case
that use the LDAP interface without needing a specific LDAP server.

So, in summary, the main risk is to see some regression in tests.

* Proposal owners:

Development impact:

- Change of a default value of one parameter of the instance creation
utility (`dscreate`)
- Provide a better visibility of that parameter in configuration tools
(`dscreate` and `dsconf`)

The above changes have already been done to be able to build the test
packages, so the remaining work is to merge the commit in the upstream
branch and rebase it to rawhide.

The larger impact is to determine if there are any regressions while
running 389DS and FreeIPA tests and fix them (with the help of the
FreeIPA team).

* Other developers:
The FreeIPA team is involved to help us diagnose any potential FreeIPA
test regressions.

Other QA teams may also be involved to test that there are no regressions.

* Release engineering: N/A (not needed for this Change): No strong
coordination is needed as only a single group of package is directly
impacted.

* Policies and guidelines: N/A (not needed for this Change)

* Trademark approval: N/A (not needed for this Change)


* Alignment with Community Initiatives:


== Upgrade/compatibility impact ==

No impact on upgrade because existing instances still use the
previously installed backend interface.

There should not be any compatibility issues (bugs excepted) with the
LDAP requests, but performance may be impacted.

There may be issues with applications that explicitly:

* 

F40 Change Proposal: 389_Directory_Server_3.0.0 (System-Wide)

[Aoife Moloney]

Wiki: https://fedoraproject.org/wiki/Changes/389_Directory_Server_3.0.0

This is a proposed Change for Fedora Linux.
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 ==

389-ds-base upgrade from version 2.4.4 to the latest upstream version
3.0.0 in Fedora.
Newly created instances now are using LDMB database by default instead
of BerkeleyDB.



== Owner ==

* Name: 389 Directory Server Development Team

* Email: 389-devel (at) lists (dot) fedoraproject (dot) org
Primary contact:
* Name: [[User:progier| Pierre Rogier]]
* Email: progier (at) redhat (dot) com


== Detailed Description ==

Since Fedora 36 (389-ds-base 2.1.0), the 389 Directory Server supports
two kinds of underlying database:

* Berkeley Database (BDB)
* Lightning Memory-Mapped Database Manager (LMDB)

Newly created instances are still created with BDB by default while
libdb is flagged as [[Changes/Libdb deprecated - Fedora Project
Wiki|deprecated since Fedora 33]], this change is about to create
instances with LMDB by default.


== Feedback ==

No feedback yet.


== Benefit to Fedora ==
A step on the way to remove a deprecated piece of software no longer
supported by the upstream community.
(See https://fedoraproject.org/wiki/Changes/Libdb_deprecated)

== Scope ==

The change is quite limited in terms of development and interface
impact, but it impacts a critical component: FreeIPA.

[1] Impact on software that uses generic LDAP interface without any
specific 389DS features (like configuration tools and monitoring
entries):
No interface impact, but there may be some impact in terms of dynamic
(i.e: response time, maximum throughput). Especially if browsing (i.e
VLV) indexes are used on big lists.

[2] Impact on software that explicitly creates 389DS instances (like
FreeIPA) may also have to change the way the database is tuned.
(Especially the database maximum size: `nsslapd-mdb-max-size`)

[3] Impact on software that explicitly uses backend monitoring LDAP
entries: new attributes about LMDB specific data are present.

There are no packages in [3] case and FreeIPA is the only one in [2]
case but there is likely an unknown number of software in [1] case
that use the LDAP interface without needing a specific LDAP server.

So, in summary, the main risk is to see some regression in tests.

* Proposal owners:

Development impact:

- Change of a default value of one parameter of the instance creation
utility (`dscreate`)
- Provide a better visibility of that parameter in configuration tools
(`dscreate` and `dsconf`)

The above changes have already been done to be able to build the test
packages, so the remaining work is to merge the commit in the upstream
branch and rebase it to rawhide.

The larger impact is to determine if there are any regressions while
running 389DS and FreeIPA tests and fix them (with the help of the
FreeIPA team).

* Other developers:
The FreeIPA team is involved to help us diagnose any potential FreeIPA
test regressions.

Other QA teams may also be involved to test that there are no regressions.

* Release engineering: N/A (not needed for this Change): No strong
coordination is needed as only a single group of package is directly
impacted.

* Policies and guidelines: N/A (not needed for this Change)

* Trademark approval: N/A (not needed for this Change)


* Alignment with Community Initiatives:


== Upgrade/compatibility impact ==

No impact on upgrade because existing instances still use the
previously installed backend interface.

There should not be any compatibility issues (bugs excepted) with the
LDAP requests, but performance may be impacted.

There may be issues with applications that explicitly:

* Configure 389 Directory Server instances (like FreeIPA) because the
set of configuration attributes for the backend depends on the
underlying database implementation.
The unused parameters are ignored, so it should not impact the compatibility.
But there is a risk with the new parameters: the "20 GB" default value
for the LMDB database maximum size may not be large enough for the
application's needs.

* Monitor 389 Directory Server backends because the set of attributes
in the monitoring entries also depends on the underlying database
implementation.

More details about these points are described in
[https://www.port389.org/docs/389ds/FAQ/Berkeley-DB-deprecation.html
389 Directory Server FAQ - BerkeleyDB backend deprecation]

== How To Test ==

[https://copr.fedorainfracloud.org/coprs/g/389ds/389-ds-base-freeipa-tests/
COPR project] contains builds that can be tested (F37, F38, F39,
rawhide on x86_64 and s390x).

So you can install them by using:


sudo dnf copr enable -y @389ds/389-ds-base-freeipa-tests
sudo dnf install 389-ds-base-3.0.0


Then you can create new directory server instances and use them.


== User 

F40 Change Proposal: 389_Directory_Server_3.0.0 (System-Wide)

[Aoife Moloney]

Wiki: https://fedoraproject.org/wiki/Changes/389_Directory_Server_3.0.0

This is a proposed Change for Fedora Linux.
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 ==

389-ds-base upgrade from version 2.4.4 to the latest upstream version
3.0.0 in Fedora.
Newly created instances now are using LDMB database by default instead
of BerkeleyDB.



== Owner ==

* Name: 389 Directory Server Development Team

* Email: 389-devel (at) lists (dot) fedoraproject (dot) org
Primary contact:
* Name: [[User:progier| Pierre Rogier]]
* Email: progier (at) redhat (dot) com


== Detailed Description ==

Since Fedora 36 (389-ds-base 2.1.0), the 389 Directory Server supports
two kinds of underlying database:

* Berkeley Database (BDB)
* Lightning Memory-Mapped Database Manager (LMDB)

Newly created instances are still created with BDB by default while
libdb is flagged as [[Changes/Libdb deprecated - Fedora Project
Wiki|deprecated since Fedora 33]], this change is about to create
instances with LMDB by default.


== Feedback ==

No feedback yet.


== Benefit to Fedora ==
A step on the way to remove a deprecated piece of software no longer
supported by the upstream community.
(See https://fedoraproject.org/wiki/Changes/Libdb_deprecated)

== Scope ==

The change is quite limited in terms of development and interface
impact, but it impacts a critical component: FreeIPA.

[1] Impact on software that uses generic LDAP interface without any
specific 389DS features (like configuration tools and monitoring
entries):
No interface impact, but there may be some impact in terms of dynamic
(i.e: response time, maximum throughput). Especially if browsing (i.e
VLV) indexes are used on big lists.

[2] Impact on software that explicitly creates 389DS instances (like
FreeIPA) may also have to change the way the database is tuned.
(Especially the database maximum size: `nsslapd-mdb-max-size`)

[3] Impact on software that explicitly uses backend monitoring LDAP
entries: new attributes about LMDB specific data are present.

There are no packages in [3] case and FreeIPA is the only one in [2]
case but there is likely an unknown number of software in [1] case
that use the LDAP interface without needing a specific LDAP server.

So, in summary, the main risk is to see some regression in tests.

* Proposal owners:

Development impact:

- Change of a default value of one parameter of the instance creation
utility (`dscreate`)
- Provide a better visibility of that parameter in configuration tools
(`dscreate` and `dsconf`)

The above changes have already been done to be able to build the test
packages, so the remaining work is to merge the commit in the upstream
branch and rebase it to rawhide.

The larger impact is to determine if there are any regressions while
running 389DS and FreeIPA tests and fix them (with the help of the
FreeIPA team).

* Other developers:
The FreeIPA team is involved to help us diagnose any potential FreeIPA
test regressions.

Other QA teams may also be involved to test that there are no regressions.

* Release engineering: N/A (not needed for this Change): No strong
coordination is needed as only a single group of package is directly
impacted.

* Policies and guidelines: N/A (not needed for this Change)

* Trademark approval: N/A (not needed for this Change)


* Alignment with Community Initiatives:


== Upgrade/compatibility impact ==

No impact on upgrade because existing instances still use the
previously installed backend interface.

There should not be any compatibility issues (bugs excepted) with the
LDAP requests, but performance may be impacted.

There may be issues with applications that explicitly:

* Configure 389 Directory Server instances (like FreeIPA) because the
set of configuration attributes for the backend depends on the
underlying database implementation.
The unused parameters are ignored, so it should not impact the compatibility.
But there is a risk with the new parameters: the "20 GB" default value
for the LMDB database maximum size may not be large enough for the
application's needs.

* Monitor 389 Directory Server backends because the set of attributes
in the monitoring entries also depends on the underlying database
implementation.

More details about these points are described in
[https://www.port389.org/docs/389ds/FAQ/Berkeley-DB-deprecation.html
389 Directory Server FAQ - BerkeleyDB backend deprecation]

== How To Test ==

[https://copr.fedorainfracloud.org/coprs/g/389ds/389-ds-base-freeipa-tests/
COPR project] contains builds that can be tested (F37, F38, F39,
rawhide on x86_64 and s390x).

So you can install them by using:


sudo dnf copr enable -y @389ds/389-ds-base-freeipa-tests
sudo dnf install 389-ds-base-3.0.0


Then you can create new directory server instances and use them.


== User 

Fedora rawhide compose report: 20231127.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20231126.n.0
NEW: Fedora-Rawhide-20231127.n.0

= SUMMARY =
Added images:2
Dropped images:  4
Added packages:  15
Dropped packages:0
Upgraded packages:   131
Downgraded packages: 0

Size of added packages:  35.28 MiB
Size of dropped packages:0 B
Size of upgraded packages:   12.98 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -174.80 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Silverblue dvd-ostree aarch64
Path: 
Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20231127.n.0.iso
Image: Sericea dvd-ostree x86_64
Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-Rawhide-20231127.n.0.iso

= DROPPED IMAGES =
Image: KDE live aarch64
Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-Rawhide-20231126.n.0.iso
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20231126.n.0.iso
Image: Workstation live aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20231126.n.0.iso
Image: Kinoite dvd-ostree aarch64
Path: Kinoite/aarch64/iso/Fedora-Kinoite-ostree-aarch64-Rawhide-20231126.n.0.iso

= ADDED PACKAGES =
Package: golang-github-task-slim-sprig3-3.0.0-1.fc40
Summary: Useful template functions for Go templates
RPMs:golang-github-task-slim-sprig3-devel
Size:58.69 KiB

Package: kdsoap-ws-discovery-client-0.3.0-1.fc40
Summary: Library for finding WS-Discovery devices in the network using Qt6 and 
KDSoap
RPMs:kdsoap-ws-discovery-client kdsoap-ws-discovery-client-devel
Size:474.71 KiB

Package: kio-extras-kf5-23.08.2-5.fc40
Summary: Additional components to increase the functionality of KIO Framework
RPMs:kio-extras-kf5 kio-extras-kf5-info
Size:9.28 MiB

Package: kwayland-5.27.80-1.fc40
Summary: Qt-style API to interact with the wayland-client API
RPMs:kwayland kwayland-devel
Size:1.65 MiB

Package: libahp-xc-1.3.8-1.fc40
Summary: Driver library for the AHP XC Correlators
RPMs:libahp-xc libahp-xc-devel libahp-xc-doc
Size:419.18 KiB

Package: libkexiv2-24.01.75-1.fc40
Summary: A wrapper around Exiv2 library
RPMs:libkexiv2-qt5 libkexiv2-qt5-devel libkexiv2-qt6 libkexiv2-qt6-devel
Size:1.66 MiB

Package: libkscreen-5.27.80-1.fc40
Summary: KDE display configuration library
RPMs:libkscreen libkscreen-devel
Size:1.94 MiB

Package: libplasma-5.27.80-1.fc40
Summary: Plasma is the foundation of the KDE user interface (v6)
RPMs:libplasma libplasma-devel
Size:13.81 MiB

Package: plasma-activities-5.27.80-1.fc40
Summary: Core components for the KDE Activity concept
RPMs:plasma-activities plasma-activities-devel
Size:937.08 KiB

Package: plasma-activities-stats-5.27.80-1.fc40
Summary: Library to access the usage statistics data collected by the KDE 
activity manager
RPMs:plasma-activities-stats plasma-activities-stats-devel
Size:750.93 KiB

Package: plasma-print-manager-5.27.80-1.fc40
Summary: Printer management for KDE
RPMs:plasma-print-manager plasma-print-manager-libs
Size:3.26 MiB

Package: plasma5support-5.27.80-2.fc40
Summary: Support components for porting from KF5/Qt5 to KF6/Qt6
RPMs:plasma5support plasma5support-devel
Size:957.24 KiB

Package: rust-fs_at-0.1.10-2.fc40
Summary: Implementation of 'at' functions for various platforms
RPMs:rust-fs_at+default-devel rust-fs_at+log-devel 
rust-fs_at+workaround-procmon-devel rust-fs_at-devel
Size:63.07 KiB

Package: rust-remove_dir_all0.7-0.7.0-1.fc40
Summary: Safe, reliable implementation of remove_dir_all
RPMs:rust-remove_dir_all0.7+default-devel rust-remove_dir_all0.7-devel
Size:24.20 KiB

Package: rust-triomphe-0.1.9-1.fc40
Summary: Fork of std::sync::Arc with some extra functionality and without weak 
references
RPMs:rust-triomphe+arc-swap-devel rust-triomphe+default-devel 
rust-triomphe+serde-devel rust-triomphe+stable_deref_trait-devel 
rust-triomphe+std-devel rust-triomphe-devel
Size:68.88 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  HepMC3-3.2.7-3.fc40
Old package:  HepMC3-3.2.7-2.fc40
Summary:  C++ Event Record for Monte Carlo Generators
RPMs: HepMC3 HepMC3-devel HepMC3-doc HepMC3-interfaces-devel 
HepMC3-protobufIO HepMC3-protobufIO-devel HepMC3-rootIO HepMC3-rootIO-devel 
HepMC3-search HepMC3-search-devel python3-HepMC3 python3-HepMC3-protobufIO 
python3-HepMC3-rootIO python3-HepMC3-search
Size: 8.13 MiB
Size change:  4.34 KiB
Changelog:
  * Sun Nov 26 2023 Mattias Ellert  - 3.2.7-3
  - Rebuild for root 6.30


Package:  R-qtl-1.62-1.fc40
Old package:  R-qtl-1.60-3.fc39
Summary:  Tools for analyzing QTL experiments
RPMs: R-qtl
Size: 21.69 MiB
Size change:  -20.93 KiB
Changelog:
  * Sun Nov 26 2023 Mattias Ellert  - 1.62-1
  - Update to 1.62


Package:  aesfix-1.0.1-3.fc40
Old package:  aesfix-1.0.1-3.fc39
Summary:  Correct bit errors in AES-128 key schedule

Re: Possible deprecation/removal of Initial Setup from Fedora

[Jiri Konecny]

Hi,

Good point, I forget about these deliverables are present.

Best Regards,
Jirka

Dne 27. 11. 23 v 10:32 Gerd Hoffmann napsal(a):

On Fri, Nov 24, 2023 at 01:38:27PM +0100, Jiri Konecny wrote:

Hi,

I wonder, I thought that the server images are usually using Anaconda to
create a user during installation. Am I missing something?

Well, if you boot the install.iso and go through an anaconda install,
then yes, users are created as part of that.

But that is not the only way to deploy servers, there are also
ready-to-use qcow2 + raw images which you can just boot without going
through the anaconda install process.

take care,
   Gerd


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

[Jens-Ulrik Petersen]

I took ghc-X11-xft and vala-language-server for now (would welcome
comaintainers).

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

Re: Possible deprecation/removal of Initial Setup from Fedora

[Gerd Hoffmann]

On Fri, Nov 24, 2023 at 01:38:27PM +0100, Jiri Konecny wrote:
> Hi,
> 
> I wonder, I thought that the server images are usually using Anaconda to
> create a user during installation. Am I missing something?

Well, if you boot the install.iso and go through an anaconda install,
then yes, users are created as part of that.

But that is not the only way to deploy servers, there are also
ready-to-use qcow2 + raw images which you can just boot without going
through the anaconda install process.

take care,
  Gerd
--
___
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 2251701] New: perl-Time-Out-0.24 is available

[bugzilla]

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

Bug ID: 2251701
   Summary: perl-Time-Out-0.24 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Time-Out
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 0.24
Upstream release that is considered latest: 0.24
Current version/release in rawhide: 0.23-1.fc40
URL: http://search.cpan.org/dist/Time-Out/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


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


Based on the information from Anitya:
https://release-monitoring.org/project/3468/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-Time-Out


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202251701%23c0
--
___
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-local-lib] PR #2: Ensure csh syntax is used for C shell even if SHELL env var is unset.

[Petr Pisar]

ppisar commented on the pull-request: `Ensure csh syntax is used for C shell 
even if SHELL env var is unset.` that you are following:
``
The AVC failure is tracked at . 
It won't block perl-local-lib because it does not enforce 
fedora-ci.koji-build.installability.functional test 
.

This change will get info Fedora when a maintainer of this package builds it. A 
Fedora version after another. If this package is distributed in EPEL, then 
likewise. If it is distributed in RHEL, you need to go to Red Hat support and 
ask them to include this change.
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-local-lib/pull-request/2
--
___
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

[Test-Announce] Fedora 40 Rawhide 20231127.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 40 Rawhide 20231127.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/40

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_40_Rawhide_20231127.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_40_Rawhide_20231127.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_40_Rawhide_20231127.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_40_Rawhide_20231127.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_40_Rawhide_20231127.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_40_Rawhide_20231127.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_40_Rawhide_20231127.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
--
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@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