Re: Self-Introduction: Peter Pentchev

[Peter Pentchev]

On Tue, May 28, 2024 at 09:35:52AM +0200, Dominik 'Rathann' Mierzejewski wrote:
> Hello, Peter!
> 
> On Tuesday, 28 May 2024 at 08:23, Peter Pentchev wrote:
> [...]
> > If my packager group application is accepted,
> 
> Have you gone through the other steps outlined in 
> https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/
> ?

Yes, and I already have a reviewed package - spiped,
https://bugzilla.redhat.com/show_bug.cgi?id=2265862 - and AFAIU the next
step should be creating a dist-git repository, hence the packager group
application :)

> > I will try to
> > help several packaging teams within Fedora (Python, Perl, Rust, maybe
> > some other topic-based ones) and probably separately package some tools
> > that I use on a daily basis, some written by me, some by others.
> 
> Sounds good. Welcome to Fedora!

Thank you! From what I've seen in the mailing lists in the past several
years when I've been mostly lurking, it is mostly a nice place :)

> > PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
> 
> You might want to update this URL to use https.

Right... good catch. Of course, the FreeBSD webserver had an automatic
redirect, but it was kind of high time I moved that over to my own
website. Thanks!

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org pe...@morpheusly.com
PGP key:https://www.ringlet.net/roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


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

Self-Introduction: Peter Pentchev

[Peter Pentchev]

Hi,

My name is Peter Pentchev. I am a software developer who has been
wrangling computers since 1986 and free/libre-software OS's and
distributions since 1997 (Slackware and RedHat (way before RHEL) at
first, then a decade or two of FreeBSD, then a decade or two of Debian).
I have maintained packages for FreeBSD since the year 2000, for Debian
since 2004-2005, and (unofficially, in personal and vendor repositories)
for CentOS and RHEL since 2013.

My main interests lie in system and network programming, but I have
dabbled in almost all areas of software development over the years with
varying degrees of success. My longest programming experience is in C
and Perl, but lately I prefer a mixture of Rust, type-checked Python,
and, when absolutely necessary, very carefully written POSIX shell and
Bash. If my packager group application is accepted, I will try to
help several packaging teams within Fedora (Python, Perl, Rust, maybe
some other topic-based ones) and probably separately package some tools
that I use on a daily basis, some written by me, some by others.

Thanks for reading this, and thanks for working on Fedora - it takes so
many different kinds of people doing so many different kinds of tasks to
create and maintain a working software distrubition!

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org pe...@morpheusly.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


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

Re: small logic issue with system upgrades

[Peter Boy]

> Am 23.05.2024 um 00:29 schrieb Marius Schwarz :
> 
> Am 22.05.24 um 17:48 schrieb Alexander Sosedkin:
>> On Wed, May 22, 2024 at 4:34 PM Marius Schwarz  
>> wrote:
>> 
>>> Were you following the steps outlined in
>>> https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline ?
>>> 
>>> 
> 
> I'm under the impression, there is a small misunderstanding here: The upgrade 
> worked as it should for the 23th time in a row :D

So, your server is running with F39 now? 


> It's just, that > while < the upgrade process was running, there was the 
> risk, that it or the connection fails, and in that case, there would not have 
> been a way to fix it remotely because of the mismatch of openssl and openssh 
> versions. (yes of course, an IPMI would be a way ).

Unfortunately, I don’t understand, what exactly the problem is. If you follow 
the procedure as described in the Quick Docs document mentioned above, there is 
no network connection while the actual update process is running. And even if 
there was one, you have no way of intervening in the process.  


Probably I overlook something in your mail. But I would really like to 
understand your issue. We are always looking to improve Fedora Server. And I’m 
running a bunch of servers in a remote data center, too, w/o access to the 
console (but a temporary KVM in case of emergency). So I have the update 
adventure every 6 months as well. 



> Yes, this is only relevant for remote-upgrades, but Fedora is a very good 
> server distribution and widely spread ;)

Wholehearted Agreement   :-)




--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast



--
___
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: Intention to unretire and rename pyftpdlib

[Peter Robinson]

On Tue, 21 May 2024 at 23:51, Sandro  wrote:
>
> Hi,
>
> I intend to unretire pyftpdlib [1] and rename the base package to
> python-pyftpdlib in line with current Python Packaging Guidelines. The

Why unretire? Why not just do a new package given the new name?

> package has been retired for more than eight weeks. So it will require a
> re-review.
>
> Since only the base package (SRPM) will be renamed, I'm wondering if it
> needs any Obsoletes and/or Provides. The name of the sub package will
> remain unchanged: python3-pyftpdlib.
> I don't think it's needed. But I'd like to hear from more experienced folks.
>
> I need pyftpdlib as a dependency for another package I've already
> prepared. It appears to be still maintained, but was retired due to an
> FTI bug [2] not being attended to.
>
> [1] https://src.fedoraproject.org/rpms/pyftpdlib
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=2220082
>
> Cheers,
>
> --
> Sandro
> FAS:   gui1ty
> Matrix:Penguinpee
> Elsewhere: [Pp]enguinpee
> --
> ___
> 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: Intent to start ARC investigation git-forge replacement

[Peter Robinson]

On Thu, 16 May 2024 at 13:29, Sérgio Basto  wrote:
>
> On Tue, 2024-04-23 at 12:06 +0200, Tomas Hrcka wrote:
> >  1. Suitability for dist-git and src.fedoraproject.org replacement
>
> Can someone explain me what is the problem of pagure ?

There's been a lot of discussions about it. I believe some of the main
problems are is it's basically unmaintained, it's not adding useful
features and as a result is an overall burden for those running it.

> please join to
> https://discussion.fedoraproject.org/t/2024-git-forge-evaluation/111795/20
>
> Thanks
> --
> Sérgio M. B.
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
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: The GRUB2 Bootloader – Installation and Configuration

[Peter Boy]

> Am 04.05.2024 um 05:41 schrieb Sérgio Basto :
> 
> Hi, 
> About this documentation [0], finally talks about rescue a bootloader
> with live images ... (but I will wrote about that in another time)

That doc is quite old, last review 2012-05-11! As a member of the docs board it 
tried to get it updated by an expert Fedorian, unfortunately without success. 
Grub changes only slowly and carefully. Basically, the text is still OK in my 
opinion, but some things are missing. 


> I run in trouble on cloning a disk from an old computer and starting
> booting on a new computer , security get the thing more complicated, I
> had to disable secure boot and selinux not sure , but I advice boot
> with kernel parameter selinux=0

To set selinux=0 is a bad idea. All the issues you describe have nothing to do 
with selinux.

> my old computer was bios legacy and the new have UEFI and here starts
> the challenge .

That’s really a challenge. You don’t describe what you did in detail. But the 
first think is that you can’t clone the disk. Your old BIOS boot system 
probably uses an MBR partition scheme. Your new computer with UEFI, on the 
other hand, requires a GPT partitioning scheme. 

You will have to make a lot of manual adjustments to transfer the system. 
You can convert your disk to GPT [a]. I never did this and I’m wondering how 
successful it works. 


I never did this, but I guess the best option is to keep your new computer on 
UEFI, do a complete new installation, but use ANACONDA from the live image to 
replace btrfs by a LVM system reproducing your old LVM partitions as close as 
possible and use grub2 (maybe you have to use the everything net install 
medium). When the system boots, clone your LVM partitions (each partition 
separately, not the complete disk). Most importantly you should preserver the 
respective partition numbers. And find out what else to adjust (e.g. the 
uuids). That will we a lot of work, I guess. 





[a] 
https://serverfault.com/questions/963178/how-do-i-convert-my-linux-disk-from-mbr-to-gpt-with-uefi/963179#963179
--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast



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

Re: Is there a policy for branches being merged or not

[Peter Robinson]

On Sun, 28 Apr 2024, 09:28 Julian Sikorski,  wrote:

> Hello,
>
> is there a general recommendation regarding keeping git release branches
> separate vs merged? I have been keeping mine separate. Originally to
> avoid release and changelog conflicts when cherry-picking, but I got
> used to it and kept doing it after converting to %autorelase and
> %autochangelog.
> Recently one of my packages got it branches merged by a provenpackager
> doing a deps rebuild. If there is no policy to merge, this is
> disappointing as force-pushes as not allowed and branches once merged
> cannot be unmerged. I know this is just a cosmetic issue, but choices
> made by the primary maintainers should be respected IMO.
>

It's up to the maintainers, but it's also hard to determine what the
maintainer's intentions are for those sorts of things, especially if you're
scripting a rebuild across 100s of packages for a bump.

As both a maintainer and a proven packagers I tend to just assume the
person has the best intentions of the project in mind.

Best regards,
> Julian
> --
> ___
> 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: F41 Change Proposal: Fedora Miracle Spin (self-contained)

[Peter Robinson]

On Thu, 25 Apr 2024 at 12:32, Neal Gompa  wrote:
>
> On Wed, Apr 24, 2024 at 10:49 PM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Wed, Apr 24, 2024 at 10:33:51PM -0500, Neal Gompa wrote:
> > > On Wed, Apr 24, 2024 at 3:26 PM Zbigniew Jędrzejewski-Szmek
> > >  wrote:
> > > >
> > > > On Wed, Apr 24, 2024 at 04:57:40PM +0100, Aoife Moloney wrote:
> > > > > Wiki - https://fedoraproject.org/wiki/Changes/FedoraMiracle
> > > >
> > > > > {{package|miracle-wm}} is available in Fedora Linux 40, so it can be
> > > > > installed on top of something like the existing Sway spin and
> > > > > configured to reuse much of the tools used there.
> > > > >
> > > > > For Fedora Linux 41, once the spin is produced, people can download
> > > > > and try the experience intended to be released.
> > > >
> > > > I applaud people trying out new window managers and doing stuff with
> > > > Fedora. But the overhead of creating and distributing a spin is quite
> > > > high… It seems that the contents of this spin would overlap very
> > > > strongly with Sway Spin. Would it make sense to combine them and
> > > > allow users to easily select one or the other? Even during boot, there
> > > > could be two boot menu entries and we could provide simple instructions
> > > > to switch between the desktops on an installed system.
> > > >
> > >
> > > Aside from actually being unintuitive and confusing to people to smush
> > > two spins together like that, the experience will eventually differ
> > > because different tools will be used.
> >
> > What tools?
> >
>
> Well, since it's based on Mir instead of wlroots, some Mir specific
> tooling may be developed. One of the goals is to have Fedora Miracle
> as a reference platform for showcasing and developing a community and
> ecosystem around the Mir compositor library.
>
> Two things being discussed upstream are how to support server-side
> decorations and how to support portals. Both of these are going to be
> Mir specific and at least the portal stuff will likely conflict with
> another spin's configuration.
>
> Miracle has only very slight compatibility with the Sway/i3 IPC, just
> barely enough for waybar to function. Most of the Sway tooling isn't
> going to work on Miracle because they rely on that IPC.
>
> > > Also, you overestimate the burden of creating a spin. Aside from
> > > comps, kickstart definitions, and pungi config being done initially
> > > (which isn't too high to begin with either), the effort required to
> > > maintain a spin image is extremely low.
> >
> > There's also the effort of distribuiting and archiving a few
> > additional gigabytes, putting up the links on the website and browsing
> > through them, some additional time and and additional step that can
> > fail during builds…
> >
> > > A large chunk of our spins are essentially semi-automatic these days,
> > > and people don't really notice because at the end of the day, it's a
> > > bundle of things configured together.
> >
> > Yes. And my point is that we can come up with a hundred or a thousands
> > of such bundle definitions, and my question is whether we should
> > create a separate deliverable for each possible definition.
> >
>
> If a SIG is willing to do it and support it, I don't see why not.

There's also QE efforts required to test it, and how many users will
it even get, is it worth it if there's a dozen users?
--
___
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: Interest in taking ownership of unison package

[Peter Boy]

> Am 25.04.2024 um 04:19 schrieb Matthew Krupcale :
> 
> Hello all,
> 
> I am interested in taking ownership of the unison package [1]. The most 
> recent discussion on this topic of which I'm aware is from 2018-05 [2], which 
> was attempting to bring all of the various unison versions [3-5] packaged in 
> Fedora into a single spec file. That never happened, and those packages were 
> retired in 2020-09.
> 
> . . .
> 
> Thoughts?
> 
> Matthew
> 

Hi Matthew,

Fedora Server WG would really appreciate your efforts very very much! Although 
we haven't been able to discuss this yet, of course, I'm very sure. Unison is 
currently a sadly missing building block when using Fedora Server as a file 
server. 

I had mentally registered that the Unison project, originally started as a 
research project, had been abandoned to facilitate permanent use and that the 
Unison project had been discontinued. This is obviously wrong, fortunately. 
Even if the developer group is obviously very small. 

I hope you are successful with this project. I would like to make Unison one of 
the  essential features of Fedora Server. 


Peter




--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast



--
___
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: Rust Stack Spring Cleaning - 2024 Edition

[Peter Robinson]

linxen 
>  |
> | rust-serde_plain | 2024-01-27 |75 | blinxen 
>  |
> | rust-cached_proc_macro   | 2024-01-30 |72 | dmellado
>  |
> | rust-cached_proc_macro_types | 2024-01-30 |72 | dmellado
>  |
> | rust-aom-sys | 2024-02-04 |67 | decathorpe  
>  |
> | rust-dav1d-sys   | 2024-02-04 |67 | decathorpe  
>  |
> | rust-sanitize-filename   | 2024-02-04 |67 | blinxen 
>  |
> | rust-readwrite   | 2024-02-05 |66 | jlebon  
>  |
> | rust-passwd  | 2024-02-15 |56 | pbrobinson  
>  |
> | rust-app_dirs| 2024-02-18 |53 | atim
>  |
> | rust-names   | 2024-02-20 |51 | dcavalca
>  |
> | rust-jwt | 2024-02-29 |42 | dmellado
>  |
> | rust-unscanny| 2024-02-29 |42 | decathorpe  
>  |
> | rust-qstring | 2024-03-02 |40 | ctron   
>  |
> | rust-backoff | 2024-03-07 |35 | alciregi
>  |
> | rust-olpc-cjson  | 2024-03-07 |35 | dmellado
>  |
> | rust-rsa | 2024-03-12 |30 | pbrobinson  
>  |
> | rust-version | 2024-03-12 |30 | pbrobinson  
>  |
> | rust-escape8259  | 2024-03-18 |24 | principis   
>  |
> | rust-strum   | 2024-03-18 |24 | decathorpe  
>  |
> | rust-derive_builder  | 2024-03-22 |20 | decathorpe  
>  |
> | rust-docker_credential   | 2024-03-22 |20 | dmellado
>  |
> | rust-tracing-futures | 2024-03-22 |20 | jistone 
>  |
> | rust-stratisd_proc_macros| 2024-03-30 |12 | jbaublitz   
>  |
> | rust-jxl-oxide   | 2024-04-03 | 8 | kalev   
>  |
> | rust-lopdf   | 2024-04-03 | 8 | kalev   
>  |
> | rust-rustls-pki-types| 2024-04-03 | 8 | pbrobinson  
>  |
> | rust-zbus_xml| 2024-04-03 | 8 | decathorpe  
>  |
> | rust-circular-buffer | 2024-04-06 | 5 | music   
>  |
> | rust-btoi| 2024-04-07 | 4 | blinxen 
>  |
> | rust-rust-embed  | 2024-04-08 | 3 | decathorpe  
>  |
> | rust-bytes-cast  | 2024-04-10 | 1 | alebastr
>  |
> | rust-format-bytes| 2024-04-10 | 1 | alebastr
>  |
> | rust-logging_timer   | 2024-04-10 | 1 | kiilerix
>  |
> | rust-vcsgraph| 2024-04-10 | 1 | alebastr
>  |
> | rust-whoami  | 2024-04-10 | 1 | kiilerix
>  |
> | rust-envy| 2024-04-11 | 0 | ctron   
>  |
> | rust-http-body   | 2024-04-11 | 0 | decathorpe  
>  |
> +--++---+--+

I see a couple of packages above listing me as the maintainer, but for
some reasons I don't appear below.

I am aware of a few of the above I'm listed against that my deps no
longer requre (eg passwd) but I hadn't got around to working out what
else depended on them to retire without possibly breaking something
else, overall happy for them to be retired as part of the mass
retirement if there's no other deps.

There's also some that are deps on things still in progress like
rust-rustls-pki-types (rhbz 2272351 has dep details), not sure how to
tag those so I don't have to do more work to repackage them.

Peter

> Packages by maintainer:
>
> - albertlarsan68 (3): rust-cedarwood, rust-fend-core, rust-topological-sort
>
> - alciregi (1): rust-backoff
>
> - alebastr (4): rust-bytes-cast, rust-format-bytes, rust-micro-timer,
> rust-vcsgraph
>
> - atim (12): rust-app_dirs, rust-array-init, rust-askama_shared,
> rust-gstreamer-editing-services, rust-gstreamer-player, rust-i3ipc,
> rust-libpulse-binding, rust-maildir, rust-nparse,
> rust-process_control, rust-treeline, rust-twoway
>
> - blinxen (8): rust-btoi, rust-fallible_collections, rust-noisy_float,
> rust-parse-size, rust-ptyprocess, rust-sanitize-filename,
> rust-serde_plain, rust-symlink
>
> - ctron (2): rust-envy, rust-qstring
>
> - dcavalca (33): rust-base-x, rust-benfred-read-process-memory,
> rust-cap, rust-combine, rust-concol

Re: network service removed in Fedora 40 without a Change proposal(?)

[Peter Robinson]

> > > Just for record, the removal of network-scripts was done because
> > > https://fedoraproject.org/wiki/Changes/dhclient_deprecation
> >
> > That page has Category:ChangePageIncomplete.
> > dhcp-client is present in F40, even though it has Provides:deprecated().
> >
> > > Network-scripts heavily depend on dhclient and there is no plan to rework
> > > them to use a different dhcp implementation.
> >
> > Ack. So it sounds like we could keep using both in F40
> > and prepare for removal in F41.
>
> There are various uses of the service that do not need a DHCP client,
> like the one I referred to in the bug report and FESCo ticket. Heck,
> you can kinda *assume* anyone still using the service at this point is
> doing something weird with it, not just a 'normal' "bring up this
> interface for me with DHCP" kinda thing.
>
> The removal of the network service should still be treated as its own
> significant operation, not a natural consequence of the removal of
> dhclient.

The System-V scripts are also deprecated since systemd v254 so
eventually they'll be going away too:

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

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Peter Boy]

> Am 05.04.2024 um 14:16 schrieb Kevin Kofler via devel 
> :
> 
> Peter Boy wrote:
>>> 
>>> . . .
>> 
>> This is an absolute no-go! It would break everyone’s usage of Fedora
>> Workstation
> 
> It would be a major change, yes. Though not really different from the 
> aforementioned upgrade to GNOME 3 with its completely redesigned user 
> experience, which was also done.
> 
> If Workstation were never allowed to change its user experience, it would be 
> shipping MATE nowadays, not GNOME.

Well, a switch from Gnome to KDE would require a lot of changes in everyday 
applications, e.g. Mail. That is not required when you update from Gnome 2 to 
Gnome 3.


>> and is in irreconcilable contradiction to the characteristics of an
>> „Edition" as defined with Fedora.next.
> 
> How so?

Provide a reliable solution which includes a non breaking evolvement of the 
Edition.


But not to give the wrong impression: I think it would be beneficial for Fedora 
to develop an alternative to the current Gnome Workstation, which has evolved 
over the years into a rather fat, bloated and opaque entity. But I think this 
change proposal is the wrong way to go.


>> For the desktop area I don’t see a non-overlapping use case between Gnome
>> and KDE. It’s just a different tool for the same use case.
> 
> This exact argument was already used 10 years ago to reject our (that was 
> before I left the KDE SIG, though this issue was one of the triggers for me 
> leaving the SIG) request for a Plasma Edition. 10 years later, we still have 
> no way out of this dilemma. The definition of an Edition needs to be refined 
> or completely replaced to get out of this catch-22.
> 
> As part of the process to look for a non-overlapping use case, there was an 
> attempt to focus specifically on scientific applications, which eventually 
> lead to the Scientific Lab, but that did not make it to an Edition either, 
> just to a Lab.
> 
> The overlap issue is also going to hinder other deliverables' efforts to 
> become Editions. E.g., Silverblue mostly overlaps with Workstation and 
> CoreOS: Workstation for the general use cases (workstation/desktop usage), 
> CoreOS for the atomic and container-oriented use cases.

Too bad, an explicit scientific desktop edition might have helped me propagate 
a Linux desktop in our University research cluster of excellence a good decade 
ago.  Scientific Linux for Servers was a great success. 


But it could still be a non-overlapping use case in its own right (even if I am 
contradicting myself): 

Integration / integrability in professional work environments thanks to the 
similarity of the KDE interface to Windows / MacOS and thanks to the 
cross-operating system capabilities of KDE (many KDE apps are already available 
for Windows, at least I’m happily using Kate on MacOS). And additionally, a way 
aiming to specifically attract new users who are currently on Windows/MacOS.

Scientific Desktop would be a special sub-case of this.


(Hm, would be really attractive to develop something like that)




>> That may change and can change, of course. But that’s nothing for F42,
>> rather for F52.
> 
> It just requires creating a new working group. That can be done instantly.


I'm afraid it's not that simple. It requires not only a new foundation or 
restructuring of a SIG, but also a mindset change among participants.  And the 
latter takes much longer. 







--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast



--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Peter Boy]

>  The editions should be listed prominently, and the other things can
>  lower in the page or require a click to show.

From a UX perspective, this is too cumbersome and involves too many clicks.

>  c) at all subpages there should be a toggle button to show
>  pre-release

If I see it correctly, this is already available on all pages. But a unified 
design would probably be better, an automatic hint during a beta phase.


> Am 03.04.2024 um 23:03 schrieb Kevin Kofler via devel 
> :
> 
> I would really like to see what the proportion of users downloading the 
> Server, IoT, Cloud, and CoreOS Editions is compared to Workstation or the 
> Spins. I would not expect it to be very high. Most Fedora users are desktop 
> users.  . . .  just completely niche. 
> So why do you expect those Editions to be more relevant to users downloading 
> Fedora from fedoraproject.org than the Spins?

If you have a look on the statistics Matthew reported on Flock last year, you 
would know that the numbers for Workstation were declining, whereas the numbers 
for Server raised steeply and for CoreOS and IoT steadily up. 


To put it in your (Kevin Kofler’s) words (it’s NOT my wording!): 
Why should we see any relevance in a declining Workstation instead of all the 
steadily growing server variants? Where is to be seen the future of Fedora?


But in fact, the phrasing itself of that paragraph is 'un-fedorian‘.



--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast



--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Peter Boy]

> Am 03.04.2024 um 03:51 schrieb Kevin Kofler via devel 
> :
> 
> Fedora 21 has introduced the Editions vs. Spins distinction, Fedora 2*21=42 
> would be a good time to retire it.


We would be pretty silly if we did that. This differentiation and the 
associated quality and safeguarding criteria are a model for success and one of 
our differentiation criteria.




--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast



--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Peter Boy]

> Am 03.04.2024 um 03:18 schrieb Adam Williamson :
> 
> 
> I mean, we really don't need to speculate about this much. We did an
> entire overhaul of the project - Fedora.next - which was explicitly
> based around making it much more focused and less of a choose-your-own-
> adventure, …


And let's not forget that we set special requirements for an edition and an 
edition working group behind it, which should (and does) ensure ongoing 
maintenance and user orientation in the long term (even if the latter 
unfortunately too often takes a back seat). 




--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast



--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Peter Boy]

> Am 02.04.2024 um 22:06 schrieb Steve Cossette :
> 
> ... The overall spirit of the CP is that we think KDE, and to some extent the 
> other spins too, need a bit more visibility on the website. …
> ...
> We've been discussing it in Matrix, and we can't seem to reach a consensus as 
> to what is the best way to initiate the discussion procedure. Figured a 
> change proposal was probably a decent way to "kick the hornet's nest", so to 
> speak. 
> 
> We essentially just want more visibility on the website, if that makes sense.

That sounds pretty much like an April Fool's joke (and an abuse of the change 
proposal process).  A pity in a way, but perhaps better this way, given the 
miserable debate about Wayland / X11 recently. 



--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast



--
___
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: Three steps we could take to make supply chain attacks a bit harder

[Peter Jones]

> (3) We should have a "security path", like "critical path".
> 
> sshd is linked to a lot of libraries:
> 
> /lib64/libaudit.so.1audit-libs
> /lib64/libc.so.6glibc
> /lib64/libcap-ng.so.0   libcap-ng
> /lib64/libcap.so.2  libcap
> /lib64/libcom_err.so.2  libcom_err
> /lib64/libcrypt.so.2libxcrypt
> /lib64/libcrypto.so.3   openssl-libs
> /lib64/libeconf.so.0libeconf
> /lib64/libgcc_s.so.1libgcc
> /lib64/libgssapi_krb5.so.2  krb5-libs
> /lib64/libk5crypto.so.3 krb5-libs
> /lib64/libkeyutils.so.1 keyutils-libs
> /lib64/libkrb5.so.3 krb5-libs
> /lib64/libkrb5support.so.0  krb5-libs
> /lib64/liblz4.so.1  lz4-libs
> /lib64/liblzma.so.5 xz-libs
> /lib64/libm.so.6glibc
> /lib64/libpam.so.0  pam-libs
> /lib64/libpcre2-8.so.0  pcre2
> /lib64/libresolv.so.2   glibc
> /lib64/libselinux.so.1  libselinux
> /lib64/libsystemd.so.0  systemd-libs
> /lib64/libz.so.1zlib / zlib-ng
> /lib64/libzstd.so.1 zstd
> 
> Should we have a higher level of attention to these packages?  We
> already have "critical path", but that's a broad category now.  These
> seem like they are "security path" packages, an intentionally small
> subset associated with very secure services which are enabled by
> default.

I agree, but that brings us to the question of what to do about them
that's special.

Unrelated to the idea that some packages are special in this way, it's
probably worth writing some static analysis tools we could put into
rpm-inspect to detect when (a) a binary grows new public keys it didn't
have before, and (b) a shared object grows a new ifunc.  The latter is
dramatically easier, of course, but both of those should be pretty rare
events, so they're worth further inspection.

Even if it's just RSA keys that we search for, that would add some
benefit, and that's pretty easy if nobody has tried to cover their
tracks: scan a binary for a big power of two sized odd number followed
by a small prime number, and then filtering that with a more rigorous
prime test on the first number will detect RSA keys and probably very
little else.  Might be worth grepping for "- BEGIN" as well.

Just some thoughts, I'm sure we'll all have many more where these come
from.

-- 
Peter
--
___
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: xz backdoor

[Peter Robinson]

> >>> I don't know how the assumption came up that F40 is only affected if
> >>> users opted in for testing, but that interpretation already ended up
> >>> in the Fedora Magazine and in the official linkedin post of Fedora (I
> >>> already asked to correct it).
> >>
> >> I believe that statement is correct, since none of the xz-5.6.x
> >> packages ever made it to F40 stable. The furthest they've got was
> >> updates-testing, which is not enabled in the official Beta releases.

The updates-testing repo isn't used in the Beta compose but it is
enabled by default so if someone took the beta and then applied
updates they would have automatically got the compromised package,
there's nuance there.

> >> However, if you installed F40 before Beta was released, then
> >> updates-testing is enabled and users may have installed the vulnerable
> >> package with a simple `sudo dnf upgrade`.

The same would be the case if they installed Beta.
--
___
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: F41 Change Proposal: Disable openSSL Engine Support (system-wide)

[Peter Robinson]

On Wed, 20 Mar 2024 at 09:05, Dmitry Belyavskiy  wrote:
>
> Hi!
>
> On Wed, Mar 20, 2024 at 9:50 AM Zbigniew Jędrzejewski-Szmek 
>  wrote:
>>
>> On Fri, Mar 08, 2024 at 08:37:19PM +, Aoife Moloney wrote:
>> > Wiki - https://fedoraproject.org/wiki/Changes/OpensslNoEngine
>> >
>> > 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 ==
>> > We disable support of engines in OpenSSL
>> >
>> > == Owner ==
>> > * Name: [[User:Dbelyavs| Dmitry Belyavskiy]]
>> > * Email: dbely...@redhat.com
>> >
>> > == Detailed Description ==
>> > We are going to build OpenSSL without engine support. Engines are not
>> > FIPS compatible and corresponding API is deprecated since OpenSSL 3.0.
>> > The engine functionality we are aware of (PKCS#11, TPM) is either
>> > covered by providers or will be covered soon.
>> >
>> > == Feedback ==
>> >
>> >
>> > == Benefit to Fedora ==
>> > We get rid of deprecated functionality and enforce using up-to-date
>> > API. Engine support is deprecated in OpenSSL upstream, and after
>> > provider migration caused some deficiencies with engine support. No
>> > new features will be added to the engine. So we reduce the maintenance
>> > burden and potentially attack surface.
>>
>> Hi,
>>
>> In systemd, we recently added support for engines in various tools:
>> - systemd-{repart,measure} have --private-key-source=file|engine|provider
>>   (this is C code).
>
>
> As `provider` is a possible source, you will have to replace `engine` with a 
> particular provider.
> tpm2 provider is on the way to rawhide, and pkcs11 provider has already 
> landed, so TPMs and Yubikeys
>
>
>>
>> - ukify has --signing-engine.
>>   This is Python code that calls sbsign or pesign to do parts of the
>>   heavy lifting, and those binaries do not support providers. (At least
>>   the docs are silent on this, please correct it they do.)
>
>
> Have no idea but it means we have to change this code
>>
>>
>> So it seems we'd lose support for signing with keys stored on yubikeys
>> and tpms and other fancy approaches if the proposed change goes through.
>
>
> We don't lose this support but we still have to adjust configurations.
>
>>
>> --
>>
>> Also, what is the impact on:
>> - kernel module signing in the build system
>> - signing of shim, grub2, fwupd, and the kernel in the build system
>> - mokutil
>
>
> Does any kernel module rely on OpenSSL?

No but they use openssl for signing kernel modules, you can see
details in the spec [1], search openssl.

[1] https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/kernel.spec
--
___
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: GStreamer 1.24 Released With Vulkan H.264/H.265 Decode & Many Enhancements

[Peter Robinson]

> https://www.phoronix.com/news/GStreamer-1.24-Released

The Fedora gstreamer maintainers regularly and actively update and
maintain the GST stack, I'm not sure what a message with just a link
provides, did you have a particular query you wanted answered about
the release in the context of Fedora?

Peter
--
___
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: dmesg restricted to root in Rawhide

[Peter Robinson]

On Wed, 28 Feb 2024 at 13:38, Barry Scott  wrote:
>
>
>
> On 28 Feb 2024, at 10:24, Karel Zak  wrote:
>
> You can restore the original behavior by using:
>
># sysctl kernel.dmesg_restrict=0
>
> However, be aware of the security consequences ;-)
>
>
> Given I can get the same information from journalctl -k what is the 
> improvement?

I believe you need to be in the wheel group to get that info from journalctl
--
___
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: Podman v5 breaking changes

[Peter Robinson]

On Mon, 26 Feb 2024 at 20:59, Gursewak Singh  wrote:
>
> In Fedora 40, Podman has undergone a major version upgrade to v5 [1], 
> introducing some breaking changes. Notably, CNI networking support has been 
> discontinued in favor of Netavark, and cgroups v1 support has been deprecated 
> in favor of cgroups v2.
>
> To know whether your nodes are affected, you can use podman info and look for 
> the cgroupVersion and networkBackend keys.
>
> If you're using cgroups v1, migrating to cgroups v2 is strongly recommended, 
> as a future Podman version will no longer support cgroups v1. Kernel 
> arguments can be adjusted to use cgroups v2 with rpm-ostree kargs [2].
>
> If you're using CNI networking, transitioning to Netavark requires running 
> podman system reset --force, leading to the deletion of images, containers, 
> and custom networks. Depending on your setup, it may be preferable to 
> reprovision the entire machine from the latest images to allow for Ignition 
> to bring up containerized applications from scratch.
>
> If you have any feedback or encounter issues related to the aforementioned 
> changes, please don't hesitate to participate in the upstream issue 
> discussion [3].

Sounds like a change of this size should have been a System Wide change.

> The Fedora CoreOS Team
>
> [1] https://fedoraproject.org/wiki/Changes/Podman5
> [2] 
> https://docs.fedoraproject.org/en-US/fedora-coreos/kernel-args/#_removing_existing_kernel_arguments
> [3] https://github.com/coreos/fedora-coreos-tracker/issues/1629
>
> --
> ___
> 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: A note about riscv64 changes

[Peter Robinson]

On Wed, 14 Feb 2024 at 12:07, David Abdurachmanov
 wrote:
>
> On Wed, Feb 14, 2024 at 12:49 PM Dan Horák  wrote:
> >
> > On Wed, 14 Feb 2024 10:42:52 +
> > "Richard W.M. Jones"  wrote:
> >
> > > On Wed, Feb 14, 2024 at 10:27:53AM +, Peter Robinson wrote:
> > > > Hi Richard,
> > > >
> > > > > A quick note that you may be seeing pull requests for riscv64 changes
> > > > > against your packages, like these examples:
> > > > >
> > > > > https://src.fedoraproject.org/rpms/ghc/pull-request/7
> > > > > https://src.fedoraproject.org/rpms/zlib-ng/pull-request/11
> > > > > https://src.fedoraproject.org/rpms/gdal/pull-request/21
> > > > >
> > > > > For many years we have been building Fedora for the RISC-V
> > > > > architecture on a separate build system at
> > > > > http://fedora.riscv.rocks/koji/ , and maintaining downstream patches
> > > > > against dist-git in http://fedora.riscv.rocks:3000/rpms/
> > > > > (Most of this work was done by David Abdurachmanov, not me.)
> > > >
> > > > I'm very happy to see these start to land, let me know if you need any
> > > > assistance.
> > > >
> > > > > I'm trying to get as much of this stuff back into Fedora dist-git,
> > > > > although only (hopefully!) where it doesn't break ordinary builds and
> > > > > isn't intrusive.  Obviously I may get this wrong sometimes so feel
> > > > > free to make comments if you disagree with changes.
> > > > >
> > > > > Some time, with any luck soon, we will be creating a new Koji instance
> > > > > with FAS authentication which will allow anyone to optionally build
> > > > > their packages on RISC-V builders.  And then later in the year we may
> > > > > be in a position with the availability of new hardware to discuss
> > > > > adding RISC-V as a regular architecture.  (We're not there yet as
> > > > > current hardware is far too slow to force it on Fedora developers.)
> > > >
> > > > Will this instance run with koji-shadow to properly mirror the builds
> > > > with all the appropriate NVR dependencies to properly mirror Fedora
> > > > primary builds?
> > >
> > > TBD.
> > >
> > > Koji-shadow specifically is unmaintained.  Maybe we'll try to hack
> > > something together with scripts, or get koji-shadow working.
> >
> > on the other hand, it's still tags, targets, buildroots in koji ...
> >
> > I should be able dig out some koji-shadow know-how out of my memory if
> > needed. Those were wonderful years :-)
>
> Many years ago I tried using koji-shadow, but I didn't like what it
> was doing. Cooking something custom seemed easier at that point. These

Yes, it was never a particularly nice process, but the advantage it
has was it made sure that a package build used the exact same packages
as on the mainline build so you could end up with identical builds and
that was very useful for bugs and build process problems.

> days we also have side tags, and thus some bootstrap operations happen
> there. Sadly those get removed relatively soonish after the tag gets
> merged. Sometimes before I get a chance to grab it. Otherwise I have a
> good picture of Fedora package land over so many years.
>
> Our "dist-git overlay" is relatively small these days. Should be <300
> packages, and majority of it was used to bump NVR for rebuilds.
>
> Cheers,
> david
>
> >
> > Dan
> > --
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > 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
--
___
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: A note about riscv64 changes

[Peter Robinson]

Hi Richard,

> A quick note that you may be seeing pull requests for riscv64 changes
> against your packages, like these examples:
>
> https://src.fedoraproject.org/rpms/ghc/pull-request/7
> https://src.fedoraproject.org/rpms/zlib-ng/pull-request/11
> https://src.fedoraproject.org/rpms/gdal/pull-request/21
>
> For many years we have been building Fedora for the RISC-V
> architecture on a separate build system at
> http://fedora.riscv.rocks/koji/ , and maintaining downstream patches
> against dist-git in http://fedora.riscv.rocks:3000/rpms/
> (Most of this work was done by David Abdurachmanov, not me.)

I'm very happy to see these start to land, let me know if you need any
assistance.

> I'm trying to get as much of this stuff back into Fedora dist-git,
> although only (hopefully!) where it doesn't break ordinary builds and
> isn't intrusive.  Obviously I may get this wrong sometimes so feel
> free to make comments if you disagree with changes.
>
> Some time, with any luck soon, we will be creating a new Koji instance
> with FAS authentication which will allow anyone to optionally build
> their packages on RISC-V builders.  And then later in the year we may
> be in a position with the availability of new hardware to discuss
> adding RISC-V as a regular architecture.  (We're not there yet as
> current hardware is far too slow to force it on Fedora developers.)

Will this instance run with koji-shadow to properly mirror the builds
with all the appropriate NVR dependencies to properly mirror Fedora
primary builds?

Peter
--
___
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: do we need CONFIG_UPROBES=y in our kernels?

[Peter Robinson]

> > In a german developer blog article was the topic raised, that with
> > uprobes enabled, userland apps can i.e. circumvent tls security(and
> > other protections),
> > by telling the kernel to probe the function calls with the uprobes api.
> > As this enables i.e. the hosting system of a vm or container, to track
> > activity inside the container, trust is lost i.e. from customer to
> > hoster. To be fair, you need to be root on the host to do this, but as
> > it "wasn't possible before", and it is "now" ( out in a greater public
> > ), it tends to create trust issues, just for being there*.
> >
> > As this only works with uprobes enabled and has no use case besides a
> > developer debugging apps, the question is:
> >
> > Do we need this for all others out there enabled by default?
>
> Both systemtap and bpftrace can use uprobes.  Those capabilities have
> been important from time to time in my job.  That does not mean that
> my ability to do my job should outweigh security concerns, of course,
> but I think some effort should be made to find out if use of uprobes
> via systemtap and bpftrace is common amongst Fedora users.

And unfortunately it's not buildable as a module, I suspect there's
some form of capabilities around it, I'm not sure if that can be
tightened.
--
___
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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Peter Boy]

> Am 07.02.2024 um 14:40 schrieb Solomon Peachy via devel 
> :
> 
> you just conflated volunteer Free Software package 
> maintainers with literal genocidal rapists and murders.

I am not arguing about the characteristics of maintainers or people and 
actions, but about the fundamental characteristics of *strategies*. Please read 
more carefully.

And by the way, rape and genocide was not part of the "fire and sword" strategy 
to bring about a change in beliefs, values and behaviour (Christianization), 
but an effect of separate, additional parallel processes (economic resource 
takeover) - just for historical completion and correctness. More precisely, 
processes and strategies of the adoption of economic domination 
instrumentalized processes and strategies of value domination 
(Christianization). Your reference here to rape and genocide lacks any factual 
(historical and political science) basis.

But this is way off-topic, sorry. 


On-topic is how these discussions and decisions affect Fedora distribution as a 
whole. And that worries me. 



--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast



--
___
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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Peter Boy]

I don't really want to get involved in this discussion. I don't use KDE, I 
don't even use Fedora Desktop anymore. But there is one argument resp. strategy 
that triggers me:

> Am 07.02.2024 um 10:44 schrieb Michel Lind :
> 
> 
> - KDE SIG likely also want people to test Wayland, so defaulting to the
>  X11 packages being removed makes sense here

If KDE Sig wants to attract users to Wayland, then the only good strategy is to 
make Wayland better than the previous way (i.e. Xorg) and promote that fact 
actively. Then people will be motivated to switch by themselves. Simply banning 
or deleting something will only alienate people and they will switch in 
frustration to another alternative, i.e. distribution in our case. This is a 
simple fact that can be found in all behavioral and political sciences.

Unfortunately, some Fedora maintainers seem to take their cue from the 
missionaries and conquistadors of the 16th and 17th centuries and try fire and 
sword and coercion. A bad strategy in a free world.

If I remember Matthew's Fedora status report on Flock last year correctly, the 
download and user numbers of Fedora Desktop are/were declining. Perhaps this is 
another reason to think about appropriate strategies. 




--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast



--
___
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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Peter Hutterer]

On Mon, Feb 05, 2024 at 10:33:52AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Feb 05, 2024 at 10:34:13AM +1000, Peter Hutterer wrote:
> > > And even before that, things were already only limping along. That was
> > > happening for over a decade and in that timeframe *nobody* has wanted
> > > to step up and work on it. Wayland is the future because otherwise we
> > > have no graphics future, as things currently stand.
> > 
> > It also doesn't help that the "it's the same people working on X and
> > Wayland" argument means that, absent significant breakthroughs in
> > space-time research, we can work on one or the other, not both.
> > Something's got to give.
> 
> We could also switch to a 4-day week, with 20h shifts ;)

"if 24h in a day isn't enough, work at night"

Uncredited because I'm not sure the person I got this from (in jest)
really wants the credit ;)

Cheers,
  Peter
--
___
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: [Test-Announce] 2024-02-05 @ 16:00 UTC - Fedora QA Meeting

[Peter Boy]

I would like to discuss about 

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

In connection with

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

and how to proceed with this.

As far as we know now, there is a config parameter to turn on/off whether a 
vgscan/vgchange/etc should inspect new or all connected devices of just devices 
in the/etc/lvm/devices/system.devices file.

It is a feature that upstream introduced some time ago. Upstream turn the 
parameter off, so that LVM inspected all devices after introducing  the feature 
and behaved as previously. LVM maintainer turn the parameter on, instead. Until 
now we have no information why they did it. We have no feedback in the bug nor 
on a direct email so far.

We have to consider if it is preferable to return to the previous state of the 
device file parameter.





> Am 05.02.2024 um 02:50 schrieb Adam Williamson :
> 
> # Fedora Quality Assurance Meeting
> # Date: 2024-02-05
> # Time: 16:00 UTC
> (https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
> # Location:
> https://matrix.to/#/#meeting:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org
> 
> Greetings testers! It's meeting time again, and once again we'll
> be on Matrix.
> 
> If anyone has any other items for the agenda, please reply to this
> email and suggest them! Thanks.
> 
> == Proposed Agenda Topics ==
> 
> 1. Previous meeting follow-up
> 2. Fedora 40 check-in
> 3. Test Day / community event status
> 4. Open floor
> -- 
> Adam Williamson (he/him/his)
> Fedora QA
> Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
> https://www.happyassassin.net
> 
> 
> 
> 
> 
> -- 
> Adam Williamson (he/him/his)
> Fedora QA
> Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
> https://www.happyassassin.net
> --
> ___
> 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

--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast






--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast



--
___
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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Peter Hutterer]

On Fri, Feb 02, 2024 at 11:08:15AM +, Neal Gompa wrote:
> On Fri, Feb 2, 2024 at 10:47 AM Peter Hutterer  
> wrote:
> >
> > On Thu, Feb 01, 2024 at 03:40:24PM +, Sérgio Basto wrote:
> > > On Thu, 2024-02-01 at 15:31 +0100, Leon Fauster via devel wrote:
> > > > Am 01.02.24 um 14:18 schrieb Sérgio Basto:
> > > > 
> > > >
> > > > > The problem is not KDE SIG not support X11, the problem is KDE SIG
> > > > > want
> > > > > drop X11 and force user to use wayland .
> > > >
> > > >
> > > > Looking from the side I wonder If its the SIG or more the
> > > > circumstances
> > > > that everything is in a forward flow and the SIG is facing it. So, if
> > > > the best time was not two or one year ago, and obviously also not
> > > > now.
> > > > When then? The fact is that there must be a point in time when the
> > > > display server takes an evolution step forward.
> > > >
> > > > Pressure in such transition helps to get forward, so I understand the
> > > > SIGs POV. Albeit, from the practical POV there are some issue and
> > > > therefore X11 is still the place to be.
> > > >
> > > > Maybe some elaboration should be done about the current state of X11
> > > > vs
> > > > Wayland (is it just nvidia?) and a timeframe calculation to have a
> > > > resolution. Maybe it won't look so bad then and a interim solution is
> > > > then more acceptable.
> > >
> > >
> > > I have an obvious answer is when the authors decide, in this case Xorg,
> > > when Xorg decides that it will stop supporting X11, like happened to
> > > Python2 or PHP5 and 7 or Gnome
> >
> > X.org (the ppl doing X development) doesn't work that way, there won't
> > be an official "we're no longer supporting this". More likely
> > development will languish (except for Xwayland) and actual Xorg releases
> > will be few and far in between, at unpredictable cadence and subject to
> > someone wanting to do it.
> >
> > The last Xorg release (21.0) from the master branch was in Oct 2021. The
> > only reason that one happened was because Povilas (who wanted a new
> > feature in X) stepped up and did the work of collecting the MRs and
> > doing the release maintainership. Every 21.x release since has been
> > backports and, especially more recently, a huge percentage are CVE fixes.
> >
> > Fedora still ships the previous release, server 1.20.x, which was
> > originally released from git master in 2018, the 1.20.14 version we're
> > on (excluding fixes and CVEs) is from Dec 2021.
> >
> > Xwayland on the other hand (which lives in the same git repo) continues
> > on its merry way with the 23.2 series branched as recently as last
> > August. But an Xwayland release does not include Xorg because, well,
> > there is little motivation to do more Xorg releases.
> >
> > When it comes down to it it "just" needs someone (trustworthy enough) to
> > step up and do them. Whether the releases get picked up immediately like in
> > the olden days is a different matter. But I doubt there'll be an X.org
> > statement of "we no longer support Xorg" anytime soon, even though that
> > is, to some extent functionally already true.
> >
> 
> And even before that, things were already only limping along. That was
> happening for over a decade and in that timeframe *nobody* has wanted
> to step up and work on it. Wayland is the future because otherwise we
> have no graphics future, as things currently stand.

It also doesn't help that the "it's the same people working on X and
Wayland" argument means that, absent significant breakthroughs in
space-time research, we can work on one or the other, not both.
Something's got to give.

Cheers,
  Peter


> 
> This is why *every* graphical environment is *finally* working on
> their Wayland environments if they have any development resources at
> all. Last year, we had Cinnamon release its own experimental Wayland
> session with v6.0. Budgie is working on replacing X11 with Wayland
> this year. LXQt will be on Wayland with v2. Xfce is working on the
> same for v4.20. MATE is looking at Wayfire after previously looking at
> Mirco for Wayland. Pantheon has been working on it for over a year now
> and has an experimental session.
> 
> Everyone is making a path to Wayland a priority because finally enough
> is done so that they can.
--
___
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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Peter Hutterer]

On Thu, Feb 01, 2024 at 03:40:24PM +, Sérgio Basto wrote:
> On Thu, 2024-02-01 at 15:31 +0100, Leon Fauster via devel wrote:
> > Am 01.02.24 um 14:18 schrieb Sérgio Basto:
> > 
> > 
> > > The problem is not KDE SIG not support X11, the problem is KDE SIG
> > > want
> > > drop X11 and force user to use wayland .
> > 
> > 
> > Looking from the side I wonder If its the SIG or more the
> > circumstances
> > that everything is in a forward flow and the SIG is facing it. So, if
> > the best time was not two or one year ago, and obviously also not
> > now.
> > When then? The fact is that there must be a point in time when the 
> > display server takes an evolution step forward.
> > 
> > Pressure in such transition helps to get forward, so I understand the
> > SIGs POV. Albeit, from the practical POV there are some issue and 
> > therefore X11 is still the place to be.
> > 
> > Maybe some elaboration should be done about the current state of X11
> > vs
> > Wayland (is it just nvidia?) and a timeframe calculation to have a 
> > resolution. Maybe it won't look so bad then and a interim solution is
> > then more acceptable.
> 
> 
> I have an obvious answer is when the authors decide, in this case Xorg,
> when Xorg decides that it will stop supporting X11, like happened to
> Python2 or PHP5 and 7 or Gnome 

X.org (the ppl doing X development) doesn't work that way, there won't
be an official "we're no longer supporting this". More likely
development will languish (except for Xwayland) and actual Xorg releases
will be few and far in between, at unpredictable cadence and subject to
someone wanting to do it.

The last Xorg release (21.0) from the master branch was in Oct 2021. The
only reason that one happened was because Povilas (who wanted a new
feature in X) stepped up and did the work of collecting the MRs and
doing the release maintainership. Every 21.x release since has been
backports and, especially more recently, a huge percentage are CVE fixes.

Fedora still ships the previous release, server 1.20.x, which was
originally released from git master in 2018, the 1.20.14 version we're
on (excluding fixes and CVEs) is from Dec 2021.

Xwayland on the other hand (which lives in the same git repo) continues
on its merry way with the 23.2 series branched as recently as last
August. But an Xwayland release does not include Xorg because, well,
there is little motivation to do more Xorg releases. 

When it comes down to it it "just" needs someone (trustworthy enough) to
step up and do them. Whether the releases get picked up immediately like in
the olden days is a different matter. But I doubt there'll be an X.org
statement of "we no longer support Xorg" anytime soon, even though that
is, to some extent functionally already true.

Cheers,
  Peter


> 
> In fact, it is something I've been thinking about, IMHO, downstream
> shouldn't decide when software is deprecated or not like KDE and Red
> HAt did , it's weird to me [1], although in RHEL we could have the
> packages via EPEL, I think, and RHEL 10 is only in a year and a half 
> 
> 
> [1]
> https://www.reddit.com/r/linux/comments/13c7hfk/red_hat_considers_xorg_deprecated_and_will_remove/
> 
> 
> > --
> > Leon
> > 
> > 
> > 
> > 
> > 
> > 
> > --
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
> 
> -- 
> Sérgio M. B.
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Peter Boy]

> Am 01.02.2024 um 16:47 schrieb Steve Cossette :
> 
> On 2024-02-01 10:27 a.m., Peter Boy wrote:
>> 
>> Sorry, a bit off-topic here, but nevertheless:
>> 
>>> Am 01.02.2024 um 15:14 schrieb Steve Cossette :
>>> 

>> 
>> 
> Will do!

Thanks, see you there


--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast



--
___
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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Peter Boy]

Sorry, a bit off-topic here, but nevertheless:

> Am 01.02.2024 um 15:14 schrieb Steve Cossette :
> 
> Hello Pgnd,
> 
> I honestly do appreciate your point of view. Especially from a business owner 
> standpoint. I do manage small business servers, and I feel you in that regard.
> 
> I do have to also applaud your nerves of steel though, using Fedora as a 
> server in a business environment, to me anyway, always felt ill-advised as 
> things tend to take rough 90 degree turns in Fedora which can often cause 
> breakages in some server scenarios and stuff (The F40 mysql change comes to 
> mind).


Hello Steve and hello Pgnd,

I would like to ask you (and invite you) to discuss your "take rough 90 degree 
turns“ assessment for Fedora Server on Fedora Server list (and hopefully 
diminish your need for nerves of steel). I rather hear sometimes a kind of 
disappointment (or rebuke) about Fedora Server, that it is boring and it 
changes too little, no excitement, no surprise, too little new, everything just 
works as it has always worked, ... That kind of thing, just boring.

We aim to avoid „90 degree turns“ and disruption and proof to be able to 
provide the latest functionality of software services in a stable and reliable 
environment without much delay and, above all, without disruption. And if I 
look at our download statistics, an increasing number of admins seem to like it.

Your example about the mysql change does not seem to me to be in any way as 
significant as the decision about KDE and Xorg. And does not represent a 
disruption, but rather an evolution. 


Would really like to discuss with you about recent 90 degree turns (I’m not 
aware of any in the last 2-3 years) and how to avoid it.



--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org <mailto:p...@fedoraproject.org>

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast





--
___
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: Looking for new maintainer for widelands

[Peter Hanecak]

Hello,

I'll take the widelands package.

Sincerely

Peter


On 1/30/24 11:17, Hans de Goede wrote:

Hi All,

I used to do a lot of gaming related Fedora packaging and I still maintain
over 200 pkgs, but I really don't have much time for Fedora package
maintainership anymore.

The last few years I have been limiting my package maintainership
to fixing FTBFS, which for many game packages is fine since they
are not seeing any new upstream releases.

Widelands however still has an active upstream and 6 months ago
a new version was released. I have been unable to find the time
to upgrade to this new release and I don't expect I will find
the time to do so in the near future.

So I hope someone else is willing to takeover as maintainer ?

Regards,

Hans

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


--
___
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: List of long term FTBFS packages to be retired in February

[Peter Robinson]

On Wed, 24 Jan 2024 at 16:39, Miro Hrončok  wrote:
>
> Dear maintainers.
>
> Based on the current fail to build from source policy, the following packages
> should be retired from Fedora 40 approximately one week before branching.
>
> 5 weekly reminders are required, hence the retirement will happen
> approximately in 5 weeks, i.e. around 2024-02-28.
> Since this is unfortunately after the branching,
> packages will be retired on rawhide and f40.
>
> I apologize for starting this process a bit later than required again.
> Unfortunately, I had other work obligations.
> Volunteers to take over this are always welcome.
>
> Policy:
> https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
>
> The packages in rawhide were not successfully built at least since Fedora 37.
>
> This report is based on dist tags.
>
> Packages collected via:
> https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb
>
> If you see a package that was built, please let me know.
> If you see a package that should be exempted from the process,
> please let me know and we can work together to get a FESCo approval for that.
>
> If you see a package that can be rebuilt, please do so.
>
>  Package  (co)maintainers
> 
> cl-asdf green
> erlang-jose bowlofeggs, erlang-maint-sig, jcline, 
> peter
> fwtsbenzea

I worked around the build failure for ftbfs and updated this package,
it doesn't like parallel builds, there's upstream reports but it
appears not to be getting attention from the maintainers even though
they're doing newer releases.

> ghdlsailer
> git-secrets  keesdejong
> golang-github-acme-lego  eclipseo, go-sig
> golang-github-eclesh-welford abulimov, dcavalca, go-sig
> golang-github-gatherstars-com-jwzeclipseo, go-sig
> golang-github-genuinetools-pkg   eclipseo, go-sig
> golang-github-gobs-prettyeclipseo, go-sig
> golang-github-google-gopacketgo-sig, salimma
> golang-github-jhillyerd-enmime   eclipseo, go-sig
> golang-github-pierrre-compareeclipseo, go-sig
> golang-github-smartystreets-goconvey alexsaezm, go-sig, jchaloup
> golang-gopkg-square-jose-2   alexsaezm, go-sig
> golang-gvisoreclipseo, elmarco, go-sig
> golang-opentelemetry-otel-0.20   alexsaezm, go-sig
> golang-sigs-k8s-kustomizedcavalca, go-sig
> golang-vitesseclipseo, go-sig
> infinipath-psm   honli
> j4-dmenu-desktop ibotty
> jackson-dataformats-binary   mbooth
> jackson-dataformats-text mbooth
> java-1.8.0-openjdk-aarch32   akasko, jvanek
> jreenrdieter
> kdevelop-pg-qt   jgrulich, kde-sig, rdieter, than
> libdeltacloudclalance
> libva-v4l2-request   kwizart, rathann
> lmms thm
> lxc  hguemar, sagarun, thm
> mingw-clucenegreghellings
> mingw-cppunitkwizart
> mingw-dirac  kwizart
> mingw-speexdsp   janisozaur
> nbd-runner   xiubli
> nodejs-generic-pool  patches, piotrp
> ofononjha, thunderbirdtr
> openni-primesensecottsay, jkastner, rmattes
> pcmciautils  harald
> pesign-test-app  javierm, nfrayer, pjones, rwood
> pthsem   ixs
> rust-drg jbtrystram, rust-sig
> telepathy-gabble aperezbios
> yaksazbyszek
>
> The following packages require above mentioned packages:
> Depending on: cl-asdf (5)
> common-lisp-controller (maintained by: green)
> common-lisp-controller-7.4-26.fc39.noarch requires cl-asdf
>
> emacs-slime (maintained by: bkreuter, salimma)
> emacs-slime-2:2.28-2.fc39.noarch requires 
> common-lisp-controller
> emacs-slime-2:2.28-2.fc39.src requires common-lisp-controller
>
> sbcl (maintained by: green, rdieter)
> sbcl-2.3.11-1.fc40.src requires common-lisp-controller
> sbcl-2.3.11-1.fc40.x86_64 requires common-lisp-controller
>
> maxima (maintained by: jamatos, rdieter)
>  

Re: rawhide aarch64 Thunderbird FTBFS "internal compiler error: Segmentation fault"

[Peter Robinson]

Hi,

> Tried twice, same error, aarch64 build bails out with

There's at least one known ICE on aarch64 for gcc-14 so I suggest
checking if it looks related.

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

> | 34:29.97 *** WARNING *** there are active plugins, do not report this as a 
> bug unless you can reproduce it without enabling any plugins.
> | 34:29.97 Event| Plugins
> | 34:29.97 PLUGIN_FINISH_UNIT   | annobin: Generate final 
> annotations
> | 34:29.97 PLUGIN_START_UNIT| annobin: Generate global 
> annotations
> | 34:29.97 PLUGIN_ALL_PASSES_START  | annobin: Generate per-function 
> annotations
> | 34:29.97 PLUGIN_ALL_PASSES_END| annobin: Register per-function 
> end symbols
> | 34:29.97 during RTL pass: split1
> | 34:29.97 In file included from 
> /builddir/build/BUILD/thunderbird-115.7.0/gfx/skia/skia/src/core/SkOpts.cpp:43:
> | 34:29.97 
> /builddir/build/BUILD/thunderbird-115.7.0/gfx/skia/skia/src/opts/SkBlitMask_opts.h:
>  In function ‘void neon::blit_mask_d32_a8(SkPMColor*, size_t, const SkAlpha*, 
> size_t, SkColor, int, int)’:
> | 34:29.97 
> /builddir/build/BUILD/thunderbird-115.7.0/gfx/skia/skia/src/opts/SkBlitMask_opts.h:234:1:
>  internal compiler error: Segmentation fault
> | 34:29.97   234 | }
> | 34:29.97   | ^
> | 34:30.04 Please submit a full bug report, with preprocessed source (by 
> using -freport-bug).
> | 34:30.04 See  for instructions.
>
> I'm not going to jump through hoops there.
> All other platforms finished the build fine, f39 and f38 builds
> completed also for aarch64.
>
> See https://kojipkgs.fedoraproject.org//work/tasks/9052/112279052/build.log of
> https://koji.fedoraproject.org/koji/taskinfo?taskID=112279052 of
> https://koji.fedoraproject.org/koji/taskinfo?taskID=112278913
>
>   Eike
>
> --
> GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 
> 2D3A
> --
> ___
> 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: Can't update from fedora 39 to rawhide

[Peter Robinson]

On Wed, 24 Jan 2024 at 13:04, Guinevere Larsen  wrote:
>
> Hi Fedora list!
>
> I'm trying to upgrade a VM from fedora 39 to rawhide but running dnf
> system-upgrade download --releasever=rawhide fails. the offending
> package seems to be "grubby-8.40-73.fc39", which conflicts with
> sdubby-1.0-5.fc40. Is this a known issue? Does anyone know a workaround?
> If not, where do I properly report this?

You could probably explicitly exclude sdubby.
--
___
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: Arm Minimal Image OS-Build (Self-Contained)

[Peter Robinson]

On Thu, 18 Jan 2024 at 14:39, Neal Gompa  wrote:
>
> On Thu, Jan 18, 2024 at 9:30 AM Aoife Moloney  wrote:
> >
> > Wiki -> https://fedoraproject.org/wiki/Changes/ArmMinimalImageOSBuild
> >
> > 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 ==
> > Build the Arm minimal image to be built using osbuild.
> >
> > == Owner ==
> > * Name: [[User:pbrobinson| Peter Robinson]]
> >
> > * Email: 
> >
> >
> > == Detailed Description ==
> > The Fedora Arm Minimal image is widely used as a base for various
> > usecases from low level board bring up right through to the basis of
> > other images. Over time the existing ImageFactory build process has
> > stagnated limiting our ability to enhance this image. The osbuild team
> > have worked with the Arm SIG to enable a number of enhancements around
> > things like Arm SystemReady and other such functionality to improve
> > this image creation process and to make it easier to use these images
> > with a much wider range of Arm devices making it easier to bring up
> > new types of Arm device in Fedora. In the future we are planning
> > further enhancements to ensure it's easy for developers and users to
> > make use of the Fedora within the Arm ecosystem.
> >
> > == Feedback ==
> > 
> >
> > == Benefit to Fedora ==
> > The Fedora arm Minimal Image currently requires a number of changes
> > and hacks to be used on specific devices or SoCs, the move to osbuild
> > will reduce or entirely eliminate these hacks right away with further
> > enhancements coming in the future.
> >
> > == Scope ==
> > * Proposal owners:
> > The proposal owners will:
> > ** Enable the creation of Minimal image using osbuild in pungi
> > ** Test the available artifacts
> >
> > * Other developers:
> >
> > * Release engineering: [https://pagure.io/releng/issues #Releng issue
> > number] 
> > Changes to the pungi config to use osbuild for minimal image will be
> > submitted as a PR by feature owners.
> >
> > * 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 upgrade impact. Only for new users.
> >
> > == How To Test ==
> > There will be a new Minimal Image, it will be testable in the same way
> > as the old image. Test various SoCs with arm-image-installer to ensure
> > devices boot and run as expected.
> >
> > == User Experience ==
> > There should be no change to the user experience for existing users.
> > We will enable the wider use of
> >
> > == Dependencies ==
> > All changes are already in osbuild but we will work with the osbuild
> > team if any issues arise.
> >
> > == Contingency Plan ==
> > The contingency plan is to build the Arm minimal image in the same way
> > we currently do.
> >
> > == Documentation ==
> > There should be no changes required to documentation for existing
> > users, docs will be updated for specific devices where enhancements
> > have been made.
> >
> > == Release Notes ==
> > TBD.
>
>
> Is there a repository where the blueprint for the minimal image will
> be stored? Otherwise there’s not exactly anything Fedora side that
> anyone can actually observe, extend, or maintain.

At the moment no, because the minimal image hasn’t changed in years,
but we will be introducing that for the other images in a future
release. This is currently focused on Minimal just to get the full
process in place and issues ironed out.

It's available in osbuild so people can do their own blueprints and
extend and maintain if they want their own custom version.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Where to add new ssh key to my FAS account?

[Peter Robinson]

On Wed, 10 Jan 2024 at 11:55, Barry Scott  wrote:
>
> I have been changing from SSH RSA key to using ed25519 based keys.
> I cannot recall, or track down docs on where to upload my new ssh key to
> for my FAS account.
>
> Can you point me in the right direction please?

Login to https://accounts.fedoraproject.org/ and it should be on the
right side of your profile page under the avatar roughly.
--
___
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: Turning a XImage * into a Drawable for use with XRenderCreatePicture

[Peter Hutterer]

On Thu, Jan 04, 2024 at 06:27:01PM +0100, Florian Weimer wrote:
> The pcb-rnd package contains a call:
> 
> XRenderCreatePicture(display, lpm->img_scaled, 
> XRenderFindVisualFormat(display, DefaultVisual(display, screen)), 0, 0);
> 
> The issue here is that lpm->img_scaled is an XImage *, but
> XRenderCreatePicture expected a Drawable as its second argument.
> 
> Any idea how to turn an XImage into a Drawable?

After digging through the Xlib sources a bit: an XImage is a
Xlib-specific struct that abstracts some manipulation functions. Unlike
a Drawable which exists on the protocol. You don't do anything with an
XImage except eventually rendering it to a Drawable.

So in this case - I guess look for where the lpm->img_scale is used on a
drawable and assume that's the drawable you want to use for the XRender
call. Which may or may not be lpm->pm_scaled in this case, I don't know
what the code does but it looks like that's the drawable the image
renders to.

> Not sure how this currently works, but GCC 14 refuse to compile this, as
> a C type error (using a pointer as an integer).

It cannot currently work. From XRenderCreatePicture() [1]:
  req->drawable = (CARD32) drawable;

which means that (parts of) the pointer value is sent to the server as
XID and the server should return BadDrawable unless you're really
(un)lucky with your pointer value.

Cheers,
  Peter

[1] 
https://gitlab.freedesktop.org/xorg/lib/libxrender/-/blob/master/src/Picture.c?ref_type=heads#L91
--
___
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: ARM PAC on koji vs COPR

[Peter Robinson]

On Wed, Jan 3, 2024 at 9:08 PM Stephen Smoogen  wrote:
>
>
>
> On Wed, 3 Jan 2024 at 15:01, Miroslav Suchý  wrote:
>>
>> Dne 03. 01. 24 v 14:46 Jarek Prokop napsal(a):
>>
>> 4. Why do koji and copr have CPU flag set that differs so much? Is our koji 
>> infra OK?
>>
>> For convenience of readers:
>>
>> Koji:
>> Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid 
>> asimdrdm lrcpc dcpop asimddp ssbs
>>
>> Copr:
>> Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid 
>> asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm dit 
>> uscat ilrcpc flagm ssbs paca pacg dcpodp svei8mm svebf16 i8mm bf16 dgh rng
>>
>> In Copr we use c7g.xlarge type from AWS as ARM builders. So if you spawn 
>> this machine in AWS you should be able to reproduce.
>
>
> My information may be old, but I believe the Fedora systems will be mostly 
> virtual machines running on Ampere systems from 2-3 years ago. I think there 
> are a couple of other systems which may be in usage also. The AWS systems are 
> a newer generation and different chipset. Another issue is that ARM like 
> Intel systems may be of the same generation but have different flags.
>

Ultimately builds should be using distro specified flags, not flags
based on detected build system features because that will lead to
builds that can't run on all supported platforms of a particular
architecture.
--
___
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

Error updating libvirt-dbus in F38

[Peter Boy]

Just started to update one of our Fedora Servers (F38)

I got the message: 

>   Executed scriptlet: libvirt-dbus-1.4.1-1.fc38.x86_64   124/132 
>   Cleaning up   : libvirt-dbus-1.4.1-1.fc38.x86_64   124/132 
>   Executed scriptlet: libvirt-dbus-1.4.1-1.fc38.x86_64   124/132 
> /var/tmp/rpm-tmp.BXEIBt: Zeile 1: fg: No Job control in this shell.
> Warning: %postun(libvirt-dbus-1.4.1-1.fc38.x86_64) Scriptlet failed, 
> Exit-status 1
> 
> Error in POSTUN scriptlet in rpm package libvirt-dbus
>  Cleaning up: libacl-2.3.1-6.fc38.x86_64  125/132 



Warning or error, what is it? 

Can I be sure that a reboot will be successful? 

My experiences with reports of this kind are quite mixed. From problem-free 
reboots to total failure, everything is possible. Unfortunately, reports of 
this kind do not exactly boost confidence in the reliability and usability of 
our Fedora. 

We should improve this and make reports of problems clearer.


--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast



--
___
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: RISC-V ABI issue with ULEB128

[Peter Robinson]

On Tue, Jan 2, 2024 at 5:15 PM David Abdurachmanov
 wrote:
>
> On Tue, Jan 2, 2024 at 6:26 PM Peter Robinson  wrote:
> >
> > On Tue, Jan 2, 2024 at 2:05 PM David Abdurachmanov
> >  wrote:
> > >
> > > On Tue, Jan 2, 2024 at 3:54 PM Florian Weimer  wrote:
> > > >
> > > > * David Abdurachmanov:
> > > >
> > > > > On Tue, Jan 2, 2024 at 1:09 PM Richard W.M. Jones  
> > > > > wrote:
> > > > >>
> > > > >>
> > > > >> I'm not sure exactly the effect on RISC-V binaries, but I wanted to
> > > > >> raise it here to get the attention of the Fedora toolchain team ...
> > > > >>
> > > > >> Here's the bug:
> > > > >>
> > > > >> https://sourceware.org/bugzilla/show_bug.cgi?id=31179
> > > > >> RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 
> > > > >> objects
> > > > >>
> > > > >> It refers to this change in binutils 2.41:
> > > > >>
> > > > >> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc
> > > > >>
> > > > >> As far as I understand the issue (which is not too far) this mainly
> > > > >> affects shipped *.o and *.a files (ie. static libraries and similar)
> > > > >> which were compiled with binutils < 2.41, which either won't link
> > > > >> correctly or will give a linker error when using GNU ld from 
> > > > >> binutils 2.41.
> > > > >
> > > > > Correction. This is broken in <= 2.41 (incl. the current stable
> > > > > binutils release).
> > > > >
> > > > >>
> > > > >> Unclear if it also affects *.so files (which would be a much more
> > > > >> serious ABI break), and also if it affects most binaries or just a
> > > > >> few.  I initially thought this only affected programs using 128 bit
> > > > >> ints, so didn't think it was too important, but after reading the
> > > > >> commit I'm not sure that is really true.
> > > > >
> > > > > Nelson Chu committed (5 days ago) a change:
> > > > >
> > > > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc
> > > > >
> > > > > This will accept whatever is produced by <= 2.41 and the final binary
> > > > > will be correct. There is also a new ld flag (--check-uleb128) which
> > > > > can produce a warning if it detects an issue.
> > > > >
> > > > > I plan/hope to use binutils 2.42 in Fedora/RISCV 40. That would happen
> > > > > before I start mass rebuilding, and that should fix this.
> > > >
> > > > Cc:ing Nick and Siddhesh for awareness.
> > > >
> > > > The current plan is to use binutils 2.41 for the mass rebuild.
> > >
> > > In Fedora/RISCV we typically end up using the latest available
> > > binutils. We are slightly different from upstream/normal Fedora.
> >
> > Which is fine when you're an out of mainline architecture but these
> > sorts of things need to be resolved well and truly before any
> > incorporation can happen.
>
> 100% true. We have plenty of stuff that isn't yet submitted to the
> official dist-git.

Is that delta easily viewable somewhere?

> I have been considering not going for 2.42 for Fedora 40, but we will
> do this again one more time (hopefully it's the last time, but you
> never know).
>
> > --
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam, 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
--
___
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: RISC-V ABI issue with ULEB128

[Peter Robinson]

On Tue, Jan 2, 2024 at 2:05 PM David Abdurachmanov
 wrote:
>
> On Tue, Jan 2, 2024 at 3:54 PM Florian Weimer  wrote:
> >
> > * David Abdurachmanov:
> >
> > > On Tue, Jan 2, 2024 at 1:09 PM Richard W.M. Jones  
> > > wrote:
> > >>
> > >>
> > >> I'm not sure exactly the effect on RISC-V binaries, but I wanted to
> > >> raise it here to get the attention of the Fedora toolchain team ...
> > >>
> > >> Here's the bug:
> > >>
> > >> https://sourceware.org/bugzilla/show_bug.cgi?id=31179
> > >> RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects
> > >>
> > >> It refers to this change in binutils 2.41:
> > >>
> > >> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc
> > >>
> > >> As far as I understand the issue (which is not too far) this mainly
> > >> affects shipped *.o and *.a files (ie. static libraries and similar)
> > >> which were compiled with binutils < 2.41, which either won't link
> > >> correctly or will give a linker error when using GNU ld from binutils 
> > >> 2.41.
> > >
> > > Correction. This is broken in <= 2.41 (incl. the current stable
> > > binutils release).
> > >
> > >>
> > >> Unclear if it also affects *.so files (which would be a much more
> > >> serious ABI break), and also if it affects most binaries or just a
> > >> few.  I initially thought this only affected programs using 128 bit
> > >> ints, so didn't think it was too important, but after reading the
> > >> commit I'm not sure that is really true.
> > >
> > > Nelson Chu committed (5 days ago) a change:
> > >
> > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc
> > >
> > > This will accept whatever is produced by <= 2.41 and the final binary
> > > will be correct. There is also a new ld flag (--check-uleb128) which
> > > can produce a warning if it detects an issue.
> > >
> > > I plan/hope to use binutils 2.42 in Fedora/RISCV 40. That would happen
> > > before I start mass rebuilding, and that should fix this.
> >
> > Cc:ing Nick and Siddhesh for awareness.
> >
> > The current plan is to use binutils 2.41 for the mass rebuild.
>
> In Fedora/RISCV we typically end up using the latest available
> binutils. We are slightly different from upstream/normal Fedora.

Which is fine when you're an out of mainline architecture but these
sorts of things need to be resolved well and truly before any
incorporation can happen.
--
___
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: goal: booting with an empty /etc

[Peter Boy]

> Am 11.12.2023 um 15:09 schrieb David Both :
> 
> What is the objective of achieving this "boot with empty /etc"? What
> does it accomplish? What problem does it solve?

For me, from a sysadmin POV, the great advantage is the clear separation of 
sysadmin made configuration and distribution provided (default) configuration. 
It makes the life of a sysadmin much easier, easier backup and selective 
restore, easier hunting for the cause of issues in a local app configuration, 
easier recovery and easier rebuild of a system that has become completely 
unusable. And all this for an RPM-based system and has nothing to do with 
containers. 

However, I would consider a simple and unmistakable structure, i.e. 2 separate 
directories with XFS or BTRFS file system, to be reasonable and not an overlay 
file system. This only makes the recovery in emergency mode and limited tool 
availability prone to errors.

I would like to go even further and also separate distribution default code and 
locally installed code in the /usr tree. OpenSuse has developed a good proposal 
for this some time ago.  


--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast



--
___
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: Building the boot.iso with dnf5

[Peter Robinson]

On Fri, Dec 8, 2023 at 7:35 PM Brian C. Lane  wrote:
>
> With the approval of
> https://fedoraproject.org/wiki/Changes/BuildWithDNF5 it seems like a
> good time to move Lorax over to using dnf5 to create the boot.iso. My
> current plan is to merge my dnf5 branch do a new build on Monday
> (12/11). You can preview this here:
> https://github.com/weldr/lorax/pull/1319
>
> (the test is currently failing due to an issue with the rawhide
> container image, I've testing it locally and via a temporary switch to
> using fedora:39 container).
>
> The resulting image is the same content and size as the current rawhide
> boot.iso, so that's good :)
>
> To be clear, this change uses libdnf5 to *build* the boot.iso but it
> does not have dnf5 on the iso or the systems installed using it.

It was my understanding the switch to dnf5 was delayed until F-41 so I
don't think we should be using it for this either until it's the
default in Fedora as well.

Peter
--
___
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: dracut problems quick docs page requires help

[Peter Boy]

> Am 30.11.2023 um 09:23 schrieb David Tardon :
> 
> Hi,
> 
> On Tue, 2023-11-21 at 06:39 +, Ankur Sinha wrote:
>> Hi folks,
>> 
>> We have this issue open on the quick-docs repo:
>> https://pagure.io/fedora-docs/quick-docs/issue/641
>> 
>> TLDR; the "debug-dracut-problems" quick doc seems to be out of date
>> and
>> needs review/updating.
>> 
>> https://docs.fedoraproject.org/en-US/quick-docs/debug-dracut-problems/
> 
> "It hasn't been changed in a while" does not equal "it's out of date".
> The kernel command line arguments for dracut that the page mentions
> still work the same way they worked 10 years ago. (With the exception
> of rd.udev.debug, which is ignored by systemd-based initrds; I've
> submitted a PR to fix that. And rd.udev.info is kinda pointless, as
> "info" is the default log level of systemd-udevd.)
> 
>> nfortunately, I don't know enough about dracut to do this myself.
>> Would
>> someone that knows this stuff please consider reviewing (even
>> updating?)
>> the page so we know what to do with it next?
> 
> Are there _actual_ problems there, i.e., something that doesn't work
> anymore?


Can I take that as „I had a look over the text and found no incorrect or 
outdated information about dracut“?

In that case I would want to change the "last review“ date.

(FYI: This is part of our strategy to increase the validity and trustworthiness 
of Fedora documentation, so your effort would really help a lot.) 

--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org <mailto:p...@fedoraproject.org>

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast






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

[Peter Robinson]

On Thu, Nov 23, 2023 at 12:51 PM 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.

There's other pieces that initial-setup takes care of as well, it
gives the option when creating a user to add them as an "admin" AKA
added to the wheel group and I also believe if only a root password is
set and no user created it may (it's been a while since I've tested)
add the ability for root to ssh in to the host as without a user you
can't access the machine remotely.

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

[Peter Robinson]

On Sat, Nov 25, 2023 at 12:21 AM Leslie Satenstein via devel
 wrote:
>
>
>
> I am a devout anaconda bigot, and  I exclusively use the Everything.iso with 
> it.
> Of course, I use it via terminal mode.
>
> A feature I relish in anaconda, is the ability to manage disks and 
> partitions.(using the right most radio button)
> My system has 2 SSD and 6 disks, and with anaconda, I select all of them and 
> then
> use the mentioned disk management to build the target system along with a 
> completed /etc/fstab.

This is run during install and is a different usecase to initial-setup
which doesn't offer disk configuration options.

> If I was looking to improve anaconda, I would add a one or two line 
> description against each group.
> the right most application selection column.
>
> As well, an option to offer a way to respond to what "Gerd Hoffmann" was 
> posting,
>
> Please do not add another tool, just embellish anaconda to include the extra 
> functionality.
>
>
>
>
> Leslie Satenstein
>
>
>
> On Friday, November 24, 2023 at 06:18:47 p.m. EST, Adam Williamson 
>  wrote:
>
>
> On Fri, 2023-11-24 at 13:38 +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?
>
> No, I think you're right there. initial-setup is not part of the
> anaconda-deployed Server package set. anaconda - as it does for all
> other spins/editions except Workstation - requires you to create a root
> password or admin user, so you can always log in.
>
> I think if initial-setup was included in the package set, it would run
> on boot if you didn't *both* set the root password *and* create a user
> (as it does on spins where it is installed, e.g. KDE), but it isn't.
>
> I tested this with a Server DVD image I had lying around; doing an
> install with only root password (no user created) didn't run initial-
> setup on boot, and rpm shows initial-setup not installed.
>
> However, as dgilmore noted, the Server ARM disk images certainly do
> rely on initial-setup.
>
> >
> > Best Regards,
> > Jirka
> >
> > Dne 22. 11. 23 v 13:53 Gerd Hoffmann napsal(a):
> > > 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 ...
> > >
> > > 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
> > --
> > ___
> > 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
>
> --
> 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 

Re: Possible deprecation/removal of Initial Setup from Fedora

[Peter Robinson]

On Fri, Nov 24, 2023 at 12:39 PM 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?

For example there's cases where a vendor ships the OS pre-installed on
the device and they won't know what the user will want here, often you
also need to set the language/keyboard as well before creating
users/setting passwords.

I believe also in the RHEL case it has the ability for the user to
accept an agreement before they can create users/set passwords etc and
I'm not sure how that would integrate into the systemd variant.

> Best Regards,
> Jirka
>
> Dne 22. 11. 23 v 13:53 Gerd Hoffmann napsal(a):
> > 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 ...
> >
> > 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
> --
> ___
> 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: Swift on aarch64 and 39 and Rawhide...suggestions?

[Peter Robinson]

On Mon, Nov 6, 2023 at 2:31 AM Ron Olson  wrote:
>
> Hey all-
>
> I’m still having a difficult time trying to figure out what to do about this 
> issue I’m having. Swift 5.9 was released awhile ago and I’ve been able to 
> build it for x864_64 on all versions of Fedora (Rawhide, 39, 38, 37) just 
> fine. On aarch64 (the only other architecture supported), it fails to build 
> for 39 and Rawhide, where the Swift compiler crashes with an LLVM stacktrace 
> while in the process of building the rest of the toolchain (in other words, 
> it’s not that Swift builds and packages correctly and then doesn’t work when 
> installed, it crashes during one of the compilation phases it uses to build 
> the entire toolchain).
>
> I’ve been trying to troubleshoot this problem and have it seems that the 
> issue may lay with ld-linux-aarch.so.1:
>
> [root@6ba0f8c47e54 swift-source]# lldb 
> ./build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend
> (lldb) target create 
> "./build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend"
> Current executable set to 
> '/root/rpmbuild/BUILD/swift-source/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend'
>  (aarch64).
> (lldb) ru
> Process 142 launched: 
> '/root/rpmbuild/BUILD/swift-source/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend'
>  (aarch64)
> Process 142 stopped
>
> thread #1, name = 'swift-frontend', stop reason = exec
> frame #0: 0xf7fd84c0 ld-linux-aarch64.so.1`_start at dl-start.S:22
>
> That’s as far as I’ve gotten. I not sure what the next move should be; 
> troubleshooting core libraries is not something I’ve done before and have no 
> idea where to start.
>
> Any help or suggestions would be greatly appreciated. I’ve been extremely 
> busy on non-packaging things and honestly don’t really have the time to dig 
> into this.

Maybe start with a bug against glibc with the information you
currently have and a means to reproduce it and the toolchains team may
have some pointers to where the problem lies.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 candidate composes coming - here's the plan

[Peter Boy]

> Am 26.10.2023 um 03:44 schrieb Adam Williamson :
> 
> On Wed, 2023-10-25 at 11:23 -0700, Adam Williamson wrote:
>> Hey folks! Just to keep everyone in the loop regarding F39 plans.
>> 
>> As you may have noticed, we've slipped once or twice already (depending
>> on whether you count the "early target date") and are in danger of
>> slipping again. The go/no-go meeting is scheduled for tomorrow (2023-
>> 10-26). The outstanding blockers are all Raspberry Pi-related, aside
>> from the shim one we've been waiving for several releases and intend to
>> waive again.
>> 
>> Matthew Miller, Kevin Fenzi and I came up with this plan: we're going
>> to run a compose right now without fixes for the two outstanding Pi
>> blockers (2241252 and 2244305). If QA can get sufficient testing on
>> this done by the go/no-go meeting, we can discuss the possibility of
>> shipping it and noting that there are known issues with Raspberry Pi
>> that are taking time to resolve, and Pi users should not install or
>> upgrade to F39 until they're resolved (or something like that).
>> 
>> If at any point a fix for 2241252 shows up, we'll run another compose
>> with the fix included. If that gets sufficient testing by the time of
>> the meeting, we can also consider that as a candidate to ship. If ARM
>> team decide to attempt a fix for 2244305 we'd also pull that in, but if
>> not, we think it's reasonable to consider revoting or waiving that bug,
>> as it seems not to happen very commonly or consistently and the
>> proposed "fix" apparently comes with tradeoffs of some kind.
>> 
>> So, QA folks, please stand ready to test one or two candidate composes
>> soon. If we wind up with two, we will consider most test results to
>> apply to both, as the only difference should be uboot-tools; we would
>> want to run ARM hardware tests, at least, on both composes if possible.
>> The usual announcement mails will be sent for the completed composes.
>> 
>> Thanks folks!
> 
> Update on this: the first candidate without Pi fixes is done and
> currently available for testing - see
> https://fedoraproject.org/wiki/Test_Results:Fedora_39_RC_1.1_Summary .
> The second candidate is running, when it is done,
> https://fedoraproject.org/wiki/Test_Results:Fedora_39_RC_1.2_Summary
> will be live.
> 
> Most tests of either candidate will be valid for both, but we
> especially would like testing of the second candidate (when it's done)
> on ARM hardware - obviously on Raspberry Pi, but also on any other ARM
> hardware folks have lying around. We ended up having to revert uboot-
> tools to an older version to try and address the Pi issues, so we need
> to check that hasn't broken anything else important. If you run into
> problems, please file a bug, propose it as a release blocker, and maybe
> reply here just to be sure :)

During the morning (in Europe) I tested F39 RC 1.2. The arm-installer has a 
serious bug  which makes installation for all my SBCs impossible. I posted 
details on the ARM list. In my opinion we should either not release now or 
release without the ARM raw SBC images (and w/o arm-installer). We can then 
release those at a later date in the follow-up.

I found a new issue in the Server full installer. 

After the message:
Starting installer, one moment ….

There are 10 lines showing the same message:
** (process:2431): Warning **: 13:01:21-525: expected enumeration type void, 
bit got PyBlockDevPlugin instead 

The Installation works, but showing error messages before the user, 
specifically new ones, hadn’t done anything, is a were bad show and is likely 
to undermine confidence in our (Fedora's) seriousness about quality assurance.



--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast



___
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: FEDORA-2023-ed0c57b4ba — unspecified update for libtirpc — Fedora Updates System

[Peter Robinson]

On Wed, Oct 25, 2023 at 5:04 PM Steve Dickson  wrote:
>
> Hello,
>
> This update failed [1] due to a system timeout [2]
> not a test failure... Is there some way to override
> or wave the failure.

There should be a waive option on the right panel for the update in
bodhi, and you can also retest from there too.
___
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: status openssl1.1

[Peter Robinson]

On Mon, Oct 16, 2023 at 10:05 AM Dmitry Belyavskiy  wrote:
>
> On Mon, Oct 16, 2023 at 10:21 AM Petr Pisar  wrote:
> >
> > V Mon, Oct 16, 2023 at 08:55:12AM +0200, josef radinger via devel napsal(a):
> > > Hi
> > >
> > > openssl1.1 reached EOS on recently (11th September 2023 I assume)
> > > https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/
> > >
> > > according to
> > > https://www.openssl.org/source/:
> > > ...
> > > The previous LTS version (the 1.1.1 series) is also available but has
> > > recently gone out of support.
> > > ...
> > >
> > > paid extended support for 1.1.1 would be available, but is maybe not the 
> > > way
> > > to go for fedora.
> > >
> > > we have
> > > https://fedoraproject.org/wiki/Changes/DeprecateOpensslCompat#Upgrade/compatibility_impact
> > > with no changes since 2022
> > > and a closed tracker bug at
> > > https://bugzilla.redhat.com/show_bug.cgi?id=2108694
> > >
> > > maybe we should start deprecating that package?
> > >
> > The package is already deprecated:
> >
> > # dnf5 repoquery --provides openssl1.1 | grep deprecated
> > deprecated()
> >
> > Maybe you wanted to say start removing? I rough estimation of an impact of 
> > the
> > removal are these 3 components:
> >
> > gloo-0.5.0^git20230824.01a0c81-6.fc40.src.rpm
> > opensmtpd-6.8.0p2-12.fc39.src.rpm
> > python3.6-3.6.15-20.fc39.src.rpm
>
> I'm afraid it's too late for removing the compat package in F40. If
> not, I can raise the change proposal, otherwise it will be delayed
> until F41 starts

Why is it too late for F-40? Do you mean F-39?
___
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: Orphaning all my packages

[Peter Boy]

Sorry for top posting. But my question doesn’t fit to a specific post. And I 
don’t like to contribute to getting off-topic. But ...

I followed the thread and various similar discussions closely. My question is: 
Who is really suffering from the famous „June decision“ of Red Hat? I don’t get 
it.


No one has denied that every fix or improvement of a software or a 
configuration finds its way into CentOS (stream) and its source repository (and 
hopefully into Fedora, too - much more important here). So as a member of the 
OSS community, I can take full advantage of any enhancement to OSS software 
developed by Red Hat and have access to the source code.


As a Red Hat customer, I obviously have access to the source code for the 
specific RHEL x.y.z version I am using, either - just in case I’m interested 
instead of the phone number in my support contract.


And as a student, programmer or even curious citizen who would like to know and 
learn how everything works, with a developer license I can look at everything 
and study and learn. 



So, who _exactly_ is suffering? 

I don’t get it and would really like to know. I put a considerable amount of 
time into Fedora. Maybe, I’m suffering without knowing?  :-)





> Am 03.10.2023 um 23:30 schrieb Simo Sorce :
> 
> On Tue, 2023-10-03 at 23:13 +0200, Leon Fauster via devel wrote:
>> Am 03.10.23 um 21:29 schrieb Simo Sorce:
>>> On Tue, 2023-10-03 at 20:55 +0200, Leon Fauster via devel wrote:
>>>> Am 03.10.23 um 20:46 schrieb Sérgio Basto:
>>>>> On Tue, 2023-10-03 at 13:13 -0500, Michael Catanzaro wrote:
>>>>>> On Tue, Oct 3 2023 at 01:19:20 PM -0400, Simo Sorce 
>>>>>> wrote:
>>>>>>> Additionally *all* of the code is fully available in git form on
>>>>>>> gitlab
>>>>>>> as part of CentOS Stream.
>>>>>> 
>>>>>> We all know or should know that this is false. It's easy enough to
>>>>>> disprove with a counterexample:
>>>>>> 
>>>>>> https://access.redhat.com/errata/RHSA-2023:1918
>>>>>> 
>>>>>> Try to find the code for that webkit2gtk3-2.36.7-1.el9_1.3.src.rpm in
>>>>>> CentOS Stream. It isn't there, and never will be.
>>>>>> 
>>>>> 
>>>>> it is here :
>>>>> https://git.centos.org/rpms/webkit2gtk3/c/2d1b790baa97d14849e56ed21d3f0145268283c2?branch=c9
>>>>> 
>>>> 
>>>> 
>>>> Since June 21 the strategy changed. Such commits do not get pushed
>>>> anymore. But you are right, to prove it a different example is necessary 
>>>> ...
>>> 
>>> You are wrong and have been mislead.
>>> Nothing has changed in how we develop and publish code in gitlab.
>> 
>> 
>> Nope, I do not argue about processes at all. Its about resulting code
>> fragments. Speak, having in gitlab version 8 of a package and in the
>> current/latest RHEL release (9.2) version 7 with backports of 8 doesn't
>> mean that the code is in gitlab. The code differs and its not
>> accessible. Thats all about.
> 
> The code is still in gitlab, in most cases in directly accessible in
> individual commits. In some cases, like the one Michael mentioned,
> where a rebase landed early in the CentOS branch the code may land
> together with other changes, but it is not like it is not there.
> There are is a no regression policy in RHEL, so if CentOS is ahead it
> means it already has all of the code in question.
> 
> And if there is an actual reason to need to know what exact change
> landed in RHEL there are several avenues to find out (just grab a
> developer subscription for example).
> 
> I just find that this is generally just a mental exercise, but not
> something people do or need to do on a regular basis, and does not
> prevent any use, study, sharing or enjoyment of the code.
> 
> Claiming the code is inaccessible sounds odd to me.
> But perhaps I am just old and remember when all you got from upstream
> was a tarball and you had to figure out what actual changes went in
> manually with diff ... no commits or commit messages and often not even
> a reasonable changelog ... 
> 
> Simo.
> 
> -- 
> Simo Sorce,
> DE @ RHEL Crypto Team,
> Red Hat, Inc


--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast



___
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: Intention to tighten RPM crypto-policy back

[Peter Robinson]

On Wed, Sep 27, 2023 at 11:04 AM Alexander Sosedkin
 wrote:
>
> On Tue, Sep 26, 2023 at 7:47 PM Peter Robinson  wrote:
> >
> > On Tue, Sep 19, 2023 at 10:20 AM Alexander Sosedkin
> >  wrote:
> > >
> > > Hello,
> > >
> > > 6 months ago, there's been a F38 blocker: 
> > > https://pagure.io/fesco/issue/2960
> > > Long story short:
> > > RPM has moved to sequoia,
> > > sequoia has started respecting crypto-policies,
> > > Google repos have been signed with a 1024-bit DSA key,
> > > Google Chrome was not installable => F38 blocker.
> > > Back at the time, it's been hastily "resolved"
> > > by relaxing RPM security through crypto-policies
> > > just enough to tolerate that Google signature:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=2170878
> > > https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/merge_requests/129
> > >
> > > Since then it has been brought to my attention that
> > > Google has now added a 4096 bit RSA key
> > > https://www.google.com/linuxrepositories/
> > > (EB4C 1BFD 4F04 2F6D DDCC EC91 7721 F63B D38B 4796)
> > >
> > > Because of that, I'd like to revert that RPM policy relaxation
> > > https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/commit/a12f7b20638be8f872ad1995c7d2edce41c227b5
> > > in (f39) rawhide and align RPM security with the rest of the policy.
> > >
> > > Thoughts / feedback?
> >
> > I think it should be done as a system wide change so it can have the
> > appropriate review but it seems we're better off than we were.
>
> System-wide or self-contained?

System wide as it potentially affects ability to install 3rd party software.

> I'm not altering the system-wide default,
> I'm removing the exception that was limited to rpm/dnf in scope
> to bring them in line with system-wide default;
> but rpm/dnf are kinda important.
> ___
> 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: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Peter Robinson]

On Wed, Sep 27, 2023 at 6:24 AM Remi Collet  wrote:
>
> Le 26/09/2023 à 19:32, Carlos O'Donell a écrit :
>
> >> In version 8.3 (F40) we'll includes the UTC definition
> >> in our patch to use system tzdata, UTC being use
> >> as the fallback value.
> >
> > I'm curious; what does this patch look like?
>
> (trivial) patch to our system tzdata patch attached
>
> In short, if file is missing use bundled content
>
> Full patch for PHP 8.3:
> https://git.remirepo.net/cgit/rpms/scl-php83/php.git/plain/php-8.3.0-systzdata-v24.patch
>
> Remi
>
>
> P.S. IMHO, allowing removal of tzdata for PHP doesn't make any sense
> as most app will fail badly (runtime exception) because of missing
> TZ when upstream use a bundle copy of the full database, so this can
> never happen, so this will create another RPM specific problem

Can't you just explicitly require tzdata?
___
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: Intention to tighten RPM crypto-policy back

[Peter Robinson]

On Tue, Sep 19, 2023 at 10:20 AM Alexander Sosedkin
 wrote:
>
> Hello,
>
> 6 months ago, there's been a F38 blocker: https://pagure.io/fesco/issue/2960
> Long story short:
> RPM has moved to sequoia,
> sequoia has started respecting crypto-policies,
> Google repos have been signed with a 1024-bit DSA key,
> Google Chrome was not installable => F38 blocker.
> Back at the time, it's been hastily "resolved"
> by relaxing RPM security through crypto-policies
> just enough to tolerate that Google signature:
> https://bugzilla.redhat.com/show_bug.cgi?id=2170878
> https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/merge_requests/129
>
> Since then it has been brought to my attention that
> Google has now added a 4096 bit RSA key
> https://www.google.com/linuxrepositories/
> (EB4C 1BFD 4F04 2F6D DDCC EC91 7721 F63B D38B 4796)
>
> Because of that, I'd like to revert that RPM policy relaxation
> https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/commit/a12f7b20638be8f872ad1995c7d2edce41c227b5
> in (f39) rawhide and align RPM security with the rest of the policy.
>
> Thoughts / feedback?

I think it should be done as a system wide change so it can have the
appropriate review but it seems we're better off than we were.
___
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: Intention to tighten RPM crypto-policy back

[Peter Robinson]

On Tue, Sep 26, 2023 at 6:23 PM Alexander Sosedkin  wrote:
>
> On Tue, Sep 19, 2023 at 7:47 PM Kevin Fenzi  wrote:
> >
> > On Tue, Sep 19, 2023 at 11:19:18AM +0200, Alexander Sosedkin wrote:
> > > Hello,
> > >
> > > 6 months ago, there's been a F38 blocker: 
> > > https://pagure.io/fesco/issue/2960
> > > Long story short:
> > > RPM has moved to sequoia,
> > > sequoia has started respecting crypto-policies,
> > > Google repos have been signed with a 1024-bit DSA key,
> > > Google Chrome was not installable => F38 blocker.
> > > Back at the time, it's been hastily "resolved"
> > > by relaxing RPM security through crypto-policies
> > > just enough to tolerate that Google signature:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=2170878
> > > https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/merge_requests/129
> > >
> > > Since then it has been brought to my attention that
> > > Google has now added a 4096 bit RSA key
> > > https://www.google.com/linuxrepositories/
> > > (EB4C 1BFD 4F04 2F6D DDCC EC91 7721 F63B D38B 4796)
> > >
> > > Because of that, I'd like to revert that RPM policy relaxation
> > > https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/commit/a12f7b20638be8f872ad1995c7d2edce41c227b5
> > > in (f39) rawhide and align RPM security with the rest of the policy.
> > >
> > > Thoughts / feedback?
> >
> > It might be good to go through all the ones that were hit by this (it
> > wasn't just chrome) and indicate if they are now fixed.
> > You can see a partial list in the common bug:
> >
> > https://discussion.fedoraproject.org/t/popular-third-party-rpms-fail-to-install-update-remove-due-to-security-policies-verification/70498
> >
> > and in the discussion off it.
>
> Whoa, that's too many, I suspect misreporting.
> I seriously doubt they were all really using DSA-1024 and switched over.
> But if that really was the case --- great job to all of them.
>
> > The list from there:
> > Google Chrome (RPM signature rejected, repo key rejected)
> Repo has added RSA-4096, RPM is signed with SHA-512, installs
>
> > Microsoft Edge (repo key rejected)
> RSA-2048, RPM is signed with SHA-256, installs
>
> > Dropbox (repo key rejected)
> RSA-2048, RPM is signed with SHA-512
>
> > Skype (repo key rejected)
> RSA-2048 / SHA-512
>
> > Visual Studio Code (repo key rejected)
> RSA-2048 / SHA-256 (let's name a package `code`. outstanding move)
>
> > Sublime Text (repo key rejected)
> RSA-4096 / SHA-256
>
> > Microsoft Teams (repo key rejected)
> RSA-2048, but https://packages.microsoft.com/yumrepos/ms-teams/repodata
> looks barren

I believe MS has end of life the dedicated Linux Teams app and
possibly viewer and only support the web app now.

> > TeamViewer (repo key rejected)
> RSA-4096 / SHA-256
> ___
> 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: Package fails to build for aarch64, works for x86_64

[Peter Robinson]

On Thu, Sep 21, 2023 at 3:25 PM Ron Olson  wrote:
>
> Hey all-
>
> I was trying to submit the released version of Swift 5.9 to Fedora but I get 
> a build failure only for the aarch64 platform for Rawhide and F39:
>
> https://koji.fedoraproject.org/koji/buildinfo?buildID=2291751 (F39)
> https://koji.fedoraproject.org/koji/buildinfo?buildID=2291750 (Rawhide/F40)
>
> While it compiled for both fine on F38:
>
> https://koji.fedoraproject.org/koji/buildinfo?buildID=2291752
>
> What is the rule/advice around a situation like this insofar as should I 
> release it for the current platforms (F38,F37,EPEL9) and try to figure out 
> what’s going on with the aarch64 build, or should it be an all-or-nothing, 
> release to every platform or none at all? I’d personally lean towards trying 
> to provide the new shiny where possible, but I can see making a case for 
> holding off due to F39 coming down the road. Complicating all this is trying 
> to gauge interest in there being an aarch64 version of Swift for Fedora.
>
> Could I, possibly, temporarily drop support for aarch64 in the spec file for 
> 5.9 so all versions of x86_64 can get it, and then re-enable it for if/when I 
> figure out what’s going on with the aarch64 version?
>
> The funny thing is that Apple has already started providing development 
> versions of Swift 5.10 and it does, in fact, build on both x86_64 and aarch64.

Well a quick google of one of the errors and it doesn't look like the
error is actually new to 5.9, this bug looks to have been reported in
May against F-38 / 5.8:
https://bugzilla.redhat.com/show_bug.cgi?id=2203541
___
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

Non-responsive maintainer Daiki Ueno

[Peter Oliver]

As per the non-responsive package maintainer process 
(https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/),
 does anyone know how to contact Daiki Ueno?  fedora-active-user isn’t working 
for me at the moment, so I haven’t been able to check his activity within 
Fedora, but he is active elsewhere (e.g., https://gitlab.com/dueno).

There is a backlog of pull requests for the Fedora Emacs package 
(https://src.fedoraproject.org/rpms/emacs/pull-requests).  Marc-André Lureau 
and I have volunteered to become co-maintainers to help merge
them, but we have not had a response.

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

--
Peter Oliver___
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: An update on RHEL moving to issues.redhat.com

[Peter Boy]

> Am 14.09.2023 um 14:50 schrieb Fabio Valentini :
> 
> Personally, I find the Pagure UI (and GitHub) to be much cleaner and
> easier to navigate than the UX mess that is GitLab …

+++1





--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST /UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast


___
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: An update on RHEL moving to issues.redhat.com

[Peter Boy]

> Am 11.09.2023 um 18:14 schrieb Neal Gompa :
> 
> What it did do was make my life harder trying to build up and sustain
> the pagure contributor community.
> 
> Thankfully, pagure development *isn't* dead and after the mailman
> stack stuff is sorted out, I can go back to working on Pagure 6.0.


Maybe a bit OT: I like that and  I am very glad to hear that (the continuous 
development of pagure, not the harder life). Pagure is very efficient and 
straightforward to use. And at least for what I do for Fedora, it is (almost) 
perfect and Gitlab a pain the … 

I’m not a python developer, but maybe I can help otherwise (testing, 
documentation,…)



--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST /UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast


___
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: TSS maintainer volunteer - IBM TSS

[Peter Robinson]

Hi Kenneth,

> I'm not 100% clear on the process.  I have a .spec file that passes fedpkg
> mockbuild.
>
> I submitted the request to
> https://bugzilla.redhat.com/show_bug.cgi?id=2238052.
>
> Is that all?  What else should I do?

Well the package is already in Fedora with a maintainer [1] so you
don't need to do a review but you should reach out to that maintainer
if you wish to assist them in co-maintaining the package. It seems you
already know them any way as you cc:ed them on the email.

I suggest a read through of the packaging guidelines [2] would also
assist you greatly as they're pretty decent :)

[1] https://src.fedoraproject.org/rpms/tss2
[2] https://docs.fedoraproject.org/en-US/packaging-guidelines/
___
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: Adding Passim as a Fedora 40 feature?

[Peter Robinson]

On Wed, Sep 6, 2023 at 12:58 PM Stephen Smoogen  wrote:
>
>
>
> On Fri, 25 Aug 2023 at 13:31, Richard Hughes  wrote:
>>
>> On Fri, 25 Aug 2023 at 16:27, Stephen Smoogen  wrote:
>> > It depends on the scanning from ports open to unknown shared files to 'why 
>> > did our network costs go up so much?'
>>
>> Surely if you're on a local network with bandwidth costs you'd turn
>> off avahi or lock down the firewall? Lots of stuff blasts out mDNS
>> traffic these days.
>
>
> In the Windows world, you have a one-click which says 'I am on a metered 
> line' which is supposed to do things like that. I don't see anything like 
> that on the Mac but I am only 'learning' it now.
>
> I just realized.. is avahi even on in a default install or would this be an 
> extra service needed to be turned on and 'configured' (not that avahi needs 
> much configuring). It isn't on my F38 box, but I have been living in it for a 
> long time so it could be something I did in the past or something I inherited 
> from a long ago release.

It is default on Workstation and I believe most desktops
___
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: firefox builds seem stuck on the farm - pls check

[Peter Robinson]

On Wed, Aug 30, 2023 at 9:55 AM Martin Stransky  wrote:
>
> On 8/30/23 10:51, Peter Robinson wrote:
> > On Wed, Aug 30, 2023 at 9:48 AM Martin Stransky  wrote:
> >>
> >> On 8/30/23 10:43, Peter Robinson wrote:
> >>> On Wed, Aug 30, 2023 at 9:42 AM Marius Schwarz  
> >>> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> as mozilla released the updates notes for ff 117, there are a lot of
> >>>> high impact security fixes for ff 117.
> >>>>
> >>>> unfortunatly, the ff 117 builds on the farm seem stuck for 40+h ,
> >>>> according to koji.
> >>>>
> >>>> I informed  Martin, but can someone else take a look too, in case hes
> >>>> not available?
> >>>
> >>> Which build in particular, can you provide a link to the root koji task?
> >>
> >> The builds are here:
> >>
> >> https://koji.fedoraproject.org/koji/packageinfo?packageID=37
> >
> > So you mean all 3?
>
> Yes.

Well I've freed the 3 x86 builds, I presume you didn't want the whole
lot just cancelled, please be more specific next time.
___
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: firefox builds seem stuck on the farm - pls check

[Peter Robinson]

On Wed, Aug 30, 2023 at 9:48 AM Martin Stransky  wrote:
>
> On 8/30/23 10:43, Peter Robinson wrote:
> > On Wed, Aug 30, 2023 at 9:42 AM Marius Schwarz  
> > wrote:
> >>
> >> Hi,
> >>
> >> as mozilla released the updates notes for ff 117, there are a lot of
> >> high impact security fixes for ff 117.
> >>
> >> unfortunatly, the ff 117 builds on the farm seem stuck for 40+h ,
> >> according to koji.
> >>
> >> I informed  Martin, but can someone else take a look too, in case hes
> >> not available?
> >
> > Which build in particular, can you provide a link to the root koji task?
>
> The builds are here:
>
> https://koji.fedoraproject.org/koji/packageinfo?packageID=37

So you mean all 3?

> Thanks.
>
> > ___
> > 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
>
> --
> Martin Stransky
> Software Engineer / Red Hat, Inc
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 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: firefox builds seem stuck on the farm - pls check

[Peter Robinson]

On Wed, Aug 30, 2023 at 9:42 AM Marius Schwarz  wrote:
>
> Hi,
>
> as mozilla released the updates notes for ff 117, there are a lot of
> high impact security fixes for ff 117.
>
> unfortunatly, the ff 117 builds on the farm seem stuck for 40+h ,
> according to koji.
>
> I informed  Martin, but can someone else take a look too, in case hes
> not available?

Which build in particular, can you provide a link to the root koji task?
___
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: Adding Passim as a Fedora 40 feature?

[Peter Robinson]

On Mon, Aug 28, 2023 at 9:50 PM Simo Sorce  wrote:
>
> On Mon, 2023-08-28 at 15:14 -0500, Chris Adams wrote:
> > Once upon a time, Richard Hughes  said:
> > > On Mon, 28 Aug 2023 at 16:27, Leon Fauster via devel
> > >  wrote:
> > > > whats the benefit of this "self-signed TLS certificate" (as it does
> > > > not provide any "security")? Is this stub for something later ... ?
> > >
> > > It's a good question. It provides encryption (so client A can provide
> > > the file to client B without client C being aware what's being sent)
> >
> > Without identification though, it doesn't do that, because there's no
> > way for client B to know it is really talking to client A - it could be
> > talking to client C with a man-in-the-middle attack and a different
> > self-signed cert pretending to be client A.
>
> It helps dealing with passive attacks, but not with active attacks.
>
> It could be improved by using TOFU, so that the window of impersonation
> is small, but requires clients to cache an association and then has
> weird failure modes to be dealt with if one of the actors get re-imaged
> or changes the cert for any reason.
>
>
> Richard,
> given your files are all independently integrity checked, you should
> probably not use a TLS connection, because it will be flagged up pretty
> rapidly if it is using a self-singed cert anyway.
>
> This thing works only within the same LAN, therefore already "within" a
> firewall so it does not need to cross any boundary for which encryption
> matters enough.
>
> Finally if an enterprise says TLS is a must you could give an option to
> use TLS if said enterprise provides the certs (they will probably
> disable the service anyway otherwise).

What about integration with Let's Encypt as an option, the cert
registration/renewal process is then pretty automated.
___
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: Adding Passim as a Fedora 40 feature?

[Peter Robinson]

On Fri, Aug 25, 2023 at 7:35 PM Richard Hughes  wrote:
>
> On Fri, 25 Aug 2023 at 19:26, Marcus Müller  wrote:
> > I fully agree with that assessment. "Here's a knob you turn that has the 
> > potential to make
> > your firmware update 2s faster and is generally good for the ecosystem, but 
> > you will have
> > set it on every machine you set up" will not lead to significant deployment.
>
> Agree.
>
> > Question: I presume you only want to share the metadata, and never 
> > downloaded fw images,
> > right?
>
> I think for phase 1 that's completely correct.
>
> > If that's the case, it'd alleviate a lot of the privacy concerns I'd have 
> > with my
> > laptop sharing with a campus network all of the devices for which I've 
> > lately downloaded
> > firmware.
>
> There are concerns with sharing firmware, I totally agree. It's
> non-free software (which you have permission to redistribute, but
> still unpalatable for many) -- the compromise I've done for people
> changing the default to "metadata,firmware" is that you need to reboot
> into the new firmware before the published firmware gets shared; on
> the logic that you don't want to advertise to the world that you're
> currently running insecure firmware.

In a lot of corporate datacentre networks the "users" on the network
would know what the network is comprised of, and often on these
networks they will have 10s, 100s of even 1000s of identical devices
where being able to do sharing of the same firmware is useful. Maybe
make that configurable so the network/system admin can make the
decision for what's best for their usecase?

> > Can I suggest we make this at most a "Recommends:" dependence for fwupd in 
> > any case, so
> > that one might uninstall passim without disabling fwupd?
>
> Yes, that's what I have right now. I do need to split out a
> passim-libs so that you can remove the daemon and just leave the tiny
> client library.
>
> > I'd actually love if I knew of a way my fedora containers could 
> > automagically find
> > local package and metadata sources. Knowing that "change dnf to pull data 
> > from
> > mDNS-announced sources *by default*" is a big change, flying the fwupd 
> > balloon first seems
> > very attractive to me.
>
> Yup, totally agree. I think it's a nice self contained test that if
> successful we could extend out to DNF metadata and other container-y
> stuff.
>
> Richard.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 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: Adding Passim as a Fedora 40 feature?

[Peter Robinson]

On Fri, Aug 25, 2023 at 12:43 PM Richard Hughes  wrote:
>
> Hi all,
>
> I was thinking of adding Passim as a default-installed and
> default-enabled dep of fwupd in the Fedora 40 release. Before I create
> lots of unnecessary drama, is there any early feedback on what's
> described in https://github.com/hughsie/passim/blob/main/README.md
> please.
>
> The tl;dr: is I want to add a mDNS server that reshares the public
> firmware update metadata from the LVFS on your LAN. The idea is that
> rather than 25 users in an office downloading the same ~2MB file from
> the CDN every day, the first downloads from the CDN and the other 24
> download from the first machine. All machines still download the
> [tiny] jcat file from the CDN still so we know the SHA256 to search
> for and verify.
>
> The backstory is that as the fwupd grows and grows (to ChromeOS,
> FreeBSD, Windows and macOS) we need to scale things up a couple of
> orders of magnitude. This isn't specific to firmware stuff, although I
> think it makes a great testcase which we could add dnf or ostree
> content to in the future. Comments and questions are most welcome.
> Thanks,

Is this something where you could enable it on one specific device and
have a systemd time to pull the metadata and it advertises it to the
network so you can designate a single device to run the service?
___
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: Broken Discrete/Dedicated GPU support

[Peter Robinson]

On Fri, Aug 18, 2023 at 10:16 AM Leigh Scott  wrote:
>
> > On Mon, Aug 14 2023 at 07:19:05 PM +0200, Jan Drögehoff
> >  >
> > Unfortunately yes. There is more info here:
> >
> > https://www.hadess.net/2023/08/new-responsibilities.html
> >
> > Red Hat has instructed us to stop work on several core desktop
> > components. All of these components need new maintainers now. The
> > switcheroo-control repo has now been archived, and a future new
> > maintainer will need to recreate the repo in a new location. It's
> > certainly not good news. :(
> >
> > Michael
>
> So it's ok if Linuxmint  takes over maintenance for?

Don't see why not, as long as there's communication with the other
users/consumers of it.

>  - switcheroo-control
> - iio-sensor-proxy
> ___
> 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: Replacing DNF with DNF5: changes reverted and helping steps

[Peter Robinson]

On Tue, Aug 15, 2023 at 11:41 AM Petr Pisar  wrote:
>
> V Tue, Aug 15, 2023 at 12:09:34PM +0200, Vít Ondruch napsal(a):
> > Dne 14. 08. 23 v 19:30 Adam Williamson napsal(a):
> > > On Mon, 2023-08-14 at 16:59 +0200, Vít Ondruch wrote:
> > > > $ sudo dnf update -x dnf
> > > > Updating and loading repositories:
> > > > Repositories loaded.
> > > > Failed to resolve the transaction:
> > > > Problem 1: package mass-prebuild-1.1.0-1.fc39.noarch requires dnf, but
> > > > none of the providers can be installed
> [...]
> > > I think only the mass-prebuild maintainer can help you there. dnf5
> > > cannot be set to provide dnf, because it...doesn't.
> >
> > I know and yet again, I have not find any issues using mass-prebuild with
> > DNF5 and until now, it worked just fine. I probably won't ever understand
> > this game with names.
> >
> Since DNF5 is planned as a replacement for Fedora 40 and because Fedora 39 has
> already branched, I'd like to see making dnf5 replacing dnf package in Fedora
> 40 as soon as possible. To have a testing, integration, and stablization 
> period
> as long as possible.

Quoting Samantha [1]:

"We've gone ahead and decided not to replace DNF with DNF05 in Fedora
39 and, perhaps notably, Fedora 40 as well. Fedora 41 is the safest
option at the moment."

So I thought it wasn't coming until Fedora 41?

[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EYE2JY537OM7GFW46EK7YIBLHJ52USAZ/
___
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: Disabling rawhide builds during branching - happening in 2hrs

[Peter Robinson]

On Fri, Aug 11, 2023 at 9:13 AM Luna Jernberg  wrote:
>
> I think so as there is Branched composes here atleast:
> https://kojipkgs.fedoraproject.org/compose/branched/

Builds of packages and composed are completely disconnnected. A
compose will just consume what ever packages are available in a
particular tag whether or not builds are allowed on that tag.

But there are currently f40 builds running just fine so it does look
like they've been re-enabled, if they weren't they would error out
very early on in the "fedpkg build" process.

> Den fre 11 aug. 2023 kl 09:45 skrev Florian Weimer :
> >
> > * Tomas Hrcka:
> >
> > > Once Fedora Linux 39 is branched we will reenable builds in koji with
> > > notification to this list.
> >
> > Has branching completed?  I didn't see an all-clear message.
> >
> > Thanks,
> > Florian
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam, report it: 
> > https://pagure.io/fedora-infrastructure/new_issue
> ___
> 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: zlib-ng as a compat replacement for zlib

[Peter Robinson]

On Sun, Aug 6, 2023 at 5:35 AM Daniel Alley  wrote:
>
> >In my test zlib-ng is about 40% faster.
>
> I did some testing with zlib-ng and createrepo-c a few months ago [0], and I 
> also found that the compression portion of the workload was about 40% faster. 
>  So this matches my experience, too.
>
> (BTW, if that github comment [0] sounds negative, it isn't meant to, it's 
> just that zlib ended up not being the primary culprit of the performance 
> issue I was investigating at the time, so I was not as immediately interested 
> in replacing it.)
>
> I support this proposal.  A tricky detail is that one of the big upsides of 
> zlib-ng is that it has a lot of optimized codepaths for ARM, POWER, Z, 
> RISC-V, AVX-256, AVX-512 and so forth which madler/zlib does not have.  And 
> that's fantastic, but I expect it could make the testing process a bit more 
> painful.

We tried to pull some of the optimisations in some time ago to the
Fedora package and they caused some issues with compatibility.

> Since each of the arch-specific acceleration codepaths is behind a separate 
> build flag [1] though, (I assume) we could easily do a more conservative 
> rollout with most arch-specific optimizations disabled at first, and then 
> enabled gradually over time.
>
> [0] 
> https://github.com/rpm-software-management/createrepo_c/pull/335#issuecomment-1381362220
> [1] https://github.com/zlib-ng/zlib-ng#advanced-build-options
> ___
> 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: Fedora 39 Mass Rebuild

[Peter Robinson]

On Thu, Aug 3, 2023 at 4:11 PM Artur Frenszek-Iwicki
 wrote:
>
> > I just discovered that the fontawesome-fonts package had no commit or
> > build either.  I wonder if it has something to do with this error I
> > just encountered while preparing an update for the package:
> >
> > $ git push
> > Source file '60-%{fontpkgname1}.conf' was neither listed in the
> > 'sources' file nor tracked in git. Push operation was cancelled
> > Hint: this check (.git/hooks/pre-push script) can be bypassed by
> > adding the argument '--no-verify' argument to the push command.
> > error: failed to push some refs to
> > 'ssh://pkgs.fedoraproject.org/rpms/fontawesome-fonts'
> >
> > The error is bogus.  Something failed to expand the %{fontpkgname1}
> > macro.  I wonder if the mass rebuilder actually made a commit, but the
> > push failed.
>
> Interesting. One of my fonts packages was also skipped during
> the Mass Rebuild, though in my case, pushing a manual rebuild
> later worked fine.
> https://src.fedoraproject.org/rpms/daniel-wikholm-segment16-fonts

Sometimes if a builder has issues during the "make srpm" phase it
fails in a weird way and isn't picked up I found during my days in
rel-eng.
___
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: Update on DNF05 in Fedora

[Peter Robinson]

On Fri, Jul 28, 2023 at 9:47 AM Vít Ondruch  wrote:
>
>
> Dne 27. 07. 23 v 22:23 Kevin Fenzi napsal(a):
> > On Thu, Jul 27, 2023 at 02:54:13PM -0400, DJ Delorie wrote:
> >> Samantha Bueno  writes:
> >>> We've gone ahead and decided not to replace DNF with DNF05 in Fedora
> >>> 39 and, perhaps notably, Fedora 40 as well.
> >> For those of us who upgraded to DNF05 in rawhide to test it, is there a
> >> quick reference for our paths forward?  Er, backward?  I upgraded at the
> >> wrong time and spent half a day recovering my system, I'd rather avoid
> >> that if I have to go back to DNF04...
> > I would expect a revert back to where /usr/bin/dnf is dnf4 (but
> > hopefully dnf5 is still available/seperate).
>
>
> Please note that this is not just about changing where /usr/bin/dnf
> points to. I was unpleasantly surprised that DNF5 is using different
> locations for data cache and there is no migration path back and forth,
> which leaves some unattended directories behind. I am very grumpy about
> this, because the cache is invaluable on Rawhide being sometimes the
> only (or at minimum the easiest) way to revert to older package in case
> of troubles.

In that sort of usecase it's a once off change when you move back to
dnf4, you can always grab rpms manually either from the remaining dnf5
local cache or worst case from koji.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Enable fwupd-refresh.timer by default on IoT, CoreOS & Server Editions (Self-Contained)

[Peter Robinson]

On Wed, Jul 26, 2023 at 3:37 PM Ralf Corsépius  wrote:
>
>
>
> Am 26.07.23 um 15:55 schrieb Solomon Peachy via devel:
> > On Wed, Jul 26, 2023 at 09:45:13AM +0200, Ralf Corsépius wrote:
> >> It could be "my bubble", but for me, in all these fwupd is around, it has
> >> never, ever worked on any piece of HW for me.
> >
> > Most of the stuff I have that is updated through fwupd are peripherals
> > [1] that are independent of the system vendor.
> >
> > That said, my two primary systems are a Lenovo laptop and an HP
> > workstation that are fully supported by fwupd/lvfs,
>
> My (older) lenovo laptop and my HPE Micro-Server are obviously not.
>
> > and the UEFI dbx
> > stuff works on all of the remaining physical systems (including servers)
> To my big surprise, for the first time ever, today fwupd installed a dbx
> update on one of my machine - Now, I am still wondering why it didn't do
> so on another, similar machine ;)
>
> > [1] Off the top of my head: Logitech wireless stuff, Jabra conference
> >  speaker, synaptics fingerprint sensor, (Samsung?) NVME storage, and
> This is the second time, somebody mentions Samsung NVMEs were supported.
> Well, what shall I say.
>
> I have several of them (and Samsung SATA SSDs), but so far, I always had
> to resort to other means of updating their firmware (Windows+Magician or
> iso-images), because fwupd would not want to update.

Ultimately being supported and the vendor actually bothering to
publish the firmware updates is two different things, I see this in
linux-firmware too WRT to in particular the various wireless driver
firmware.

From the NVME PoV the firmware update process is standardised as part
of the NVME spec, in most cases I have found, and I've tried a few
different vendors, you can use fwupdmgr to apply the updates from the
vendor's update zip file.

I blogged about it here:
https://nullr0ute.com/2022/06/using-fwupdmgr-to-update-nvme-firmware/
___
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: List of long term FTBFS packages to be retired in August

[Peter Robinson]

On Tue, Jul 25, 2023 at 4:44 PM Florian Weimer  wrote:
>
> * Josh Boyer:
>
> > On Tue, Jul 25, 2023 at 10:53 AM Miro Hrončok  wrote:
> >>
> >> On 25. 07. 23 16:42, Florian Weimer wrote:
> >> > * Miro Hrončok:
> >> >
> >> >> glibc32   codonell, fweimer, jakub, 
> >> >> mcermak
> >> >
> >> > Is this about FTBFS issues?  There isn't any recent build failure in
> >> > Koji, so I don't get why it's on this list?
> >>
> >> The build currently in Rawhide was done on Fedora 36 which is end of life.
> >>
> >> Apparently the release engineering team has not rebuilt this package in a 
> >> mass
> >> rebuild at least since Fedora 35.
> >>
> >> To remove it from the list, build the package on Rawhide please.
> >
> > Or we could not, and drop i686 completely.
>
> If we drop glibc32, we can't build any 32-bit code at all because GCC
> will no longer support -m32.  In this regardm x86-64 is different than
> the other Fedora architectures which can target bare metal 32-bit even
> from 64-bit-only compilers.
>
> Are bootloaders fully treated as firmware and no longer built by Fedora?
> At least the shim package does not come with corresponding source code
> AFAICS.  But I expect that there are other 32-bit pre-boot packages that
> we still rebuild.

There's shim-unsigned* which is built in Fedora, the output of those
are sent off to be signed and then the signed binaries are put into
the final shim packages which don't have source code but they are
still built on Fedora with the source, just in a two step process due
to the out of band signing.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Color Bash Prompt (System Wide)

[Peter Boy]

> Am 15.07.2023 um 21:03 schrieb Matthew Miller :
> 
> On Sat, Jul 15, 2023 at 05:22:15PM +0200, Dan Čermák wrote:
>>> For a long time the Fedora default shell prompt has been monochrome,
>>> which makes it difficult to find shell prompt commands between long
>>> command outputs when scrolling through terminal shell output.
>>> This Change introduces a simple default colored shell prompt, which
>>> users can also easily theme themselves.
>>> 
>>> [https://petersen.fedorapeople.org/color-bash-prompt.png screenshot of
>>> color bash prompt in gnome-terminal]
>> 
>> I am overall in favor of this change, thanks for working on this Jens
>> and for keeping it simple!
> 
> Me too!

And me too. :-)

And it would be nice to get some color issues fixed in one step, e.g. light 
yellow warning and error messages a white background. Really ‚fun' for your 
eyesight



--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST /UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast


___
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

Java-devel list?

[Peter Boy]

Is there something wrong with the Java-Devel list? 

I can send a message to the list and get no reject or error, but is never shows 
up, at least it looks like that.

Or did I miss something? 





--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST /UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast


___
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: DNF5-5.0.1 has a stable API

[Peter Robinson]

On Thu, Jul 20, 2023 at 10:46 AM Miroslav Suchý  wrote:
>
> Dne 20. 07. 23 v 10:08 Peter Robinson napsal(a):
> > The dnf5 API has similar primitives (Base, Goal, Package, etc.), but it's
> >> not at all compatible.
>
> It may be worth to add the link to the API:
>
> https://dnf5.readthedocs.io/en/latest/api/index.html
>
> > So everything has to be rewritten across the entire ecosystem to work
> > with it? Wow, who thinks that's a good idea? It took the ecosystem
> > long enough to migrate from the yum "API" to dnf and now they have to
> > do that all over again?
>
> "Only dead projects has stable API"

You can evolve APIs with versioning to ensure backwards compatibility
while also evolving the usecases.
___
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: DNF5-5.0.1 has a stable API

[Peter Robinson]

On Wed, Jul 19, 2023 at 11:35 PM Maxwell G  wrote:
>
>
> 2023-07-19T13:39:57Z Peter Robinson :
>
> > On Wed, Jul 19, 2023 at 2:20 PM Nicola Sella  wrote:
> >>
> >> Hi all,
> >> Yesterday, DNF5 5.1.0 was released upstream[1] and in rawhide[2]. This
> >> update makes DNF5's API stable. This means that changes to the API
> >> won't happen in stable Fedora releases.
> >
> > How compatible is this API with the old dnf4 API?
> The dnf5 API has similar primitives (Base, Goal, Package, etc.), but it's
> not at all compatible.

So everything has to be rewritten across the entire ecosystem to work
with it? Wow, who thinks that's a good idea? It took the ecosystem
long enough to migrate from the yum "API" to dnf and now they have to
do that all over again?
___
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 Zim

[Peter Boy]

> Am 19.07.2023 um 23:11 schrieb Otto Liljalaakso :
> 
> Robin Lee kirjoitti 14.7.2023 klo 17.53:
>> I've orphaned the Zim package. It fails to build with Python 3.12 in Rawhide.
>> 
>> Users can move to the flatpak on Flathub, which is also packaged by me.
>> 
> Thank you for maintaining the Zim package until now. I took it. The build 
> failure was easy to fix by BuildRequiring setuptools. I also updated to the 
> latest version, and am in the process of looking at open bugs and switching 
> to SPDX license identifiers.

And thanks for keeping it as a ROM. That is much more trustworthy for me.



--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST /UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast


___
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: DNF5-5.0.1 has a stable API

[Peter Robinson]

On Wed, Jul 19, 2023 at 2:20 PM Nicola Sella  wrote:
>
> Hi all,
> Yesterday, DNF5 5.1.0 was released upstream[1] and in rawhide[2]. This update 
> makes DNF5's API stable. This means that changes to the API won't happen in 
> stable Fedora releases.

How compatible is this API with the old dnf4 API?
___
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: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Peter Robinson]

On Wed, Jul 19, 2023 at 12:38 PM Neal Gompa  wrote:
>
> On Wed, Jul 19, 2023 at 6:11 AM Peter Robinson  wrote:
> >
> > On Wed, Jul 19, 2023 at 10:21 AM Jaroslav Mracek  wrote:
> > >
> > > > On Wed, Jul 19, 2023 at 6:23 AM Jaroslav Mracek 
> > > >  > > >
> > > > Does that mean the issues with dnf [2] we able to be solved all the
> > > > time but just weren't investigated?
> > >
> > > The issue was investigated also with DNF, but the issue was well hidden, 
> > > because the code uses hard coded set for downloaded elements. For most 
> > > investigation we used the biggest repository (Fedora) that showed a high 
> > > memory usage and we tried to mitigate what can we do to improve the 
> > > situation. The real issue was with update repository that surprisingly 
> > > uses slightly more RAM then fedora repository.
> > >
> > > With DNF5 we reinvest it as a completely different issue. DNF5 has a 
> > > better option for investigation that allow us to discover the real source 
> > > of the issue. We knew that DNF5 fixed RAM usage for `fedora` repository 
> > > therefore we continued to search in other directions. Basically we were 
> > > surprised why we got the report with DNF5 because we know that RAM usage 
> > > was  improved with DNF5 and default setting. It means that there where 
> > > two issues that overlaps with symptoms but has a different reproducers. 
> > > Solving the first one (too big metadata to process) uncover the second 
> > > issue with processing updateinfo metadata.
> > >
> > > The status of the issue - We have to wait until our patch is reviewed and 
> > > merged in libsolv and we have to wait until libsolv creates the upstream 
> > > release, because downstream of libsolv in Fedora is not under DNF team 
> > > control and the main admin doesn't like any downstream patches.
> >
> > Looking at upstream releases it seems they don't release often, in the
> > last 18 months there's been 4 releases anywhere between a month and 9
> > months apart.
> >
> > I don't see how it's feasible to sit around and tell users "I'm sorry,
> > you have to wait until upstream bothers to release before you can have
> > a fix to enable you to update your system" when there is a fix
> > available. Can you please explain that to me? It is entirely
> > reasonable to pull in a fix that is headed upstream to fix a key
> > problem in a key distro component so that it doesn't remain broken for
> > MONTHS!
>
> I agree. But the reason releases don't get made is that libsolv
> doesn't have a set schedule, and I can just ask upstream to make a
> release and they probably will.
>
> If the fix is already merged upstream, it's reasonable enough to
> backport. What we want to avoid is non-upstream patches, because this
> component is critical enough that we don't want that burden.

I agree with not having long term non upstream patches but at the same
time patches that are upstream or headed upstream to make things work
I think is a reasonable compromise.
___
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: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Peter Robinson]

On Wed, Jul 19, 2023 at 10:21 AM Jaroslav Mracek  wrote:
>
> > On Wed, Jul 19, 2023 at 6:23 AM Jaroslav Mracek  > wrote:
> >
> > Does that mean the issues with dnf [2] we able to be solved all the
> > time but just weren't investigated?
>
> The issue was investigated also with DNF, but the issue was well hidden, 
> because the code uses hard coded set for downloaded elements. For most 
> investigation we used the biggest repository (Fedora) that showed a high 
> memory usage and we tried to mitigate what can we do to improve the 
> situation. The real issue was with update repository that surprisingly uses 
> slightly more RAM then fedora repository.
>
> With DNF5 we reinvest it as a completely different issue. DNF5 has a better 
> option for investigation that allow us to discover the real source of the 
> issue. We knew that DNF5 fixed RAM usage for `fedora` repository therefore we 
> continued to search in other directions. Basically we were surprised why we 
> got the report with DNF5 because we know that RAM usage was  improved with 
> DNF5 and default setting. It means that there where two issues that overlaps 
> with symptoms but has a different reproducers. Solving the first one (too big 
> metadata to process) uncover the second issue with processing updateinfo 
> metadata.
>
> The status of the issue - We have to wait until our patch is reviewed and 
> merged in libsolv and we have to wait until libsolv creates the upstream 
> release, because downstream of libsolv in Fedora is not under DNF team 
> control and the main admin doesn't like any downstream patches.

Looking at upstream releases it seems they don't release often, in the
last 18 months there's been 4 releases anywhere between a month and 9
months apart.

I don't see how it's feasible to sit around and tell users "I'm sorry,
you have to wait until upstream bothers to release before you can have
a fix to enable you to update your system" when there is a fix
available. Can you please explain that to me? It is entirely
reasonable to pull in a fix that is headed upstream to fix a key
problem in a key distro component so that it doesn't remain broken for
MONTHS!
___
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: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Peter Robinson]

On Wed, Jul 19, 2023 at 6:23 AM Jaroslav Mracek  wrote:
>
> > On Mon, Jul 17, 2023 at 6:40 AM Jaroslav Mracek  > wrote:
> >
> > Except dnf5 broke a number of microdnf usecases with low memory where
> > microdnf worked [1].
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2214520
>
> Correct but as you can see the issue was not in DNF5 but in libsolv (solver 
> for DNF, DNF5, zypper, PackageKit). Ales Matej from DNF team prepared two 
> patches - one to resolve the issue in libsolv and second to enable workaround 
> for DNF5. Thanks to better DNF5 structure we were able to discover the real 
> cause of the issue.

Does that mean the issues with dnf [2] we able to be solved all the
time but just weren't investigated?

> Therefore I am curios why the issue is mentioned here?

Because the issues, while quite probably now known, still aren't
resolved in F-38 where it was meant to be stable for those usecases
from the release of F-38. This in turn gives me little confidence in
the rest of dnf5 being ready to replace the much larger set of
usecases as implemented by dnf4 by the Change Completion [3] deadline
in less than 3 weeks time.

[2] https://bugzilla.redhat.com/show_bug.cgi?id=1907030
[3] https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Peter Robinson]

On Mon, Jul 17, 2023 at 6:40 AM Jaroslav Mracek  wrote:
>
> Hello Pavel,
>
> May I ask you to be more specific what is the problem with including 
> references for issues? I am not sure whether your issues are related to 
> issues referenced by Fabio or whether you have in mind something else. It 
> will help us to prioritize the work.
>
> On Fri, Jul 14, 2023 at 10:50 AM Pavel Březina  wrote:
>>
>> On 7/13/23 23:59, Fabio Valentini wrote:
>> > Hi all,
>> >
>> > I'm opening this thread to trigger discussion of the roadmap for DNF5
>> > in Fedora 39 - whether the switch still looks doable for this release,
>> > or whether it should be reverted for F39 and postponed to F40.
>>
>> +1 for postponing. We have hit issues preparing CI environment via
>> ansible and applying workarounds to make dnf5 work is imho not the way
>> to go with such core tool. It should be there as opt-in so it can get
>> tested but not default.
>
>
> DNF5 was released in Fedora 38 where it replaced microdnf, therefore it was 
> possible to test it in Fedora 38

Except dnf5 broke a number of microdnf usecases with low memory where
microdnf worked [1].

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2214520

> Best regards
>
> Jaroslav
>
>>
>>
>> > This is also being tracked in a FESCo ticket:
>> > https://pagure.io/fesco/issue/3039
>> >
>> > The DNF5 Change was approved with the condition that bits that are
>> > important to the distribution *MUST* work, but this does not seem to
>> > be the case yet, six months after this was initially approved -
>> > there's at least a few things that are still using dnf-3 or have been
>> > broken since the switch to dnf5:
>> >
>> > - rawhide mock / koji builds still default to dnf-3 (DNF 4)
>> > - Fedora CI has been partially broken since the switch to DNF5 (c.f.
>> > [fedora-ci/general#416](https://pagure.io/fedora-ci/general/issue/416)),
>> > making CI results for bodhi updates at least partially useless
>> > - fedora-review has been broken since the switch to DNF5 (c.f.
>> > [FedoraReview#482](FedoraReview/issue/482)), which is really hurting
>> > the rate at which new packages are getting reviewed and added to
>> > Fedora
>> > - (not an exhaustive list, feel free to mention other things, I will
>> > update the list to include them)
>> >
>> > We are now mere days before the Fedora 39 mass rebuild is scheduled to
>> > start, so I think it's time to start talking about the roadmap for
>> > getting missing pieces into place for Fedora 39, or if that is not
>> > possible within this timeframe, whether the contingency mechanism
>> > should be enacted.
>> >
>> > Fabio
>> > ___
>> > devel mailing list -- devel@lists.fedoraproject.org
>> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> > Fedora Code of Conduct: 
>> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> > List Archives: 
>> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> > Do not reply to spam, report it: 
>> > https://pagure.io/fedora-infrastructure/new_issue
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it: 
>> https://pagure.io/fedora-infrastructure/new_issue
>
> ___
> 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: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)

[Peter Hanecak]

Hello,

On 7/7/23 04:16, Michael Catanzaro wrote:
On Thu, Jul 6 2023 at 09:40:59 PM -0400, Demi Marie Obenour 
 wrote:

It needs to be off by default.  See KDE’s telemetry policy


Again, if it's off by default then the data will be garbage. There is no 
point in doing opt-in telemetry. I would withdraw the proposal entirely 
if we cannot do it opt-out.


Since you're repeating that argument, I'll join those who repeat "off by 
default" + "opt-in only" + "able to uninstall that component completely".


Argument:

1) IANAL, but GDPR; with addition "not a big believer in anonymization 
being 100% effective"


2) "dark pattern", e.g. you know (guess, estimate, whatever) that many 
will not opt-in, hence you're trying to trick them (e.g. twisting their 
will and choices)



Sincerely

Peter

--
Peter Hanecak
  http://hany.sk/~hany/
  GnuPG: http://hany.sk/~hany/gpg/475DFC4C.txt
___
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

Orphaning piper

[Peter Hutterer]

I've orphaned the piper package. This is the GTK GUI to interface with
the libratbag daemon to configure programmable mice. It's up for grabs
now if you want it, first come, first serve and so on.

My personal take is that this should be flatpak only but who am I to
stand in the way of a motivated packager :)

Cheers,
  Peter

PS: if you *are* motivated, Piper desparately needs upstream maintainers
___
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: Orphaning packages (was LibreOffice packages)

[Peter Robinson]

On Sun, Jul 2, 2023 at 10:27 PM Kevin Kofler via devel
 wrote:
>
> Peter Robinson wrote:
> > Assuming those "binary compatible distributions" choose to add
> > LibreOffice back in and support it, given what they actually do in
> > terms of actual development it's actually pretty unlikely they're
> > going to do all the extra work to add back an office suite and all the
> > dependencies it requires.
>
> If LibreOffice remains maintained in Fedora (and I sure hope so, because
> otherwise that would definitely make Fedora useless for me), there is a good
> chance that somebody will request and maintain EPEL branches for it, as has
> already been done for the KDE Plasma and KDE Gear applications stack.

Someone doing work in EPEL is quite a bit different to my point of a
corporate organisation downstream of RHEL adding value and
differentiation that Red Hat doesn't provide as part of RHEL.
___
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: Orphaning packages (was LibreOffice packages)

[Peter Robinson]

On Sun, Jul 2, 2023 at 11:01 AM Vitaly Zaitsev via devel
 wrote:
>
> On 02/07/2023 10:51, Simon de Vlieger wrote:
> > The suppliers for these enterprise distributions and the support they
> > offer also abide by political lines.
>
> Indeed. That's why having RHEL repacks (Alma, Rocky, Oracle Linux) is good.
>
> > While your data won't be gone in an instant you still end up in the same 
> > situation with using an unsupported office suite.
>
> You can simply switch to one of these RHEL binary compatible distributions.

Assuming those "binary compatible distributions" choose to add
LibreOffice back in and support it, given what they actually do in
terms of actual development it's actually pretty unlikely they're
going to do all the extra work to add back an office suite and all the
dependencies it requires.
___
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: Orphaning packages (was LibreOffice packages)

[Peter Robinson]

On Sat, Jul 1, 2023 at 12:50 PM Vitaly Zaitsev via devel
 wrote:
>
> On 01/07/2023 13:36, Chris Adams wrote:
> > A lot of the corporate world has gone to the "cloud"
>
> > don't have to worry about local backups of important documents and
> > spreadsheets, they get sharing with minimal effort, they can access
> > things from their mobile devices, etc.
>
> And voluntarily hand over all the corporate secrets to Google and
> Microsoft. Brilliant idea.

This sort of comment is off topic, various companies are free to do
with their data as they wish, just as you are free to do with it as
you please. Frankly it's often more secure with cloud providers than
on corporate networks. Either way that comment doesn't provide useful
discourse in this discussion.
___
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: Orphaning packages (was LibreOffice packages)

[Peter Robinson]

On Sat, Jul 1, 2023 at 12:30 PM Peter Robinson  wrote:
>
> On Sat, Jul 1, 2023 at 12:00 AM Kevin Kofler via devel
>  wrote:
> >
> > Peter Robinson wrote:
> > > I would hardly say Libreoffice, bluetooth on the desktop and certain
> > > iDevice pieces is "killing all work on the desktop" it's more focusing
> > > on things that are important to their customers in those contexts.
> >
> > What corporate desktop customers do not use LibreOffice? If RH considers
> > LibreOffice unimportant to their customers, it is obvious that they only
> > care about server customers.
>
> Well if the customer gets it via Flatpak they still have it, it also
> means it doesn't need to be upgraded in lockstep with the OS so they
> can go to newer versions while keeping the same rev of the desktop or
> vica versa.
>
> But then there's also "desktop usecases like retail point of sale and
> a whole lot of other single use UX graphical like display boards,
> ticket machines, places where they're technical workstations and the
> user has a separate windows device for email/office etc. There's a
> vast array.

Also a lot use online docs like Office365 or Google docs. I personally
used to use Libreoffice a lot but now I mostly use gDocs.
___
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: Orphaning packages (was LibreOffice packages)

[Peter Robinson]

On Sat, Jul 1, 2023 at 12:00 AM Kevin Kofler via devel
 wrote:
>
> Peter Robinson wrote:
> > I would hardly say Libreoffice, bluetooth on the desktop and certain
> > iDevice pieces is "killing all work on the desktop" it's more focusing
> > on things that are important to their customers in those contexts.
>
> What corporate desktop customers do not use LibreOffice? If RH considers
> LibreOffice unimportant to their customers, it is obvious that they only
> care about server customers.

Well if the customer gets it via Flatpak they still have it, it also
means it doesn't need to be upgraded in lockstep with the OS so they
can go to newer versions while keeping the same rev of the desktop or
vica versa.

But then there's also "desktop usecases like retail point of sale and
a whole lot of other single use UX graphical like display boards,
ticket machines, places where they're technical workstations and the
user has a separate windows device for email/office etc. There's a
vast array.
___
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: Orphaning packages (was LibreOffice packages)

[Peter Robinson]

On Fri, Jun 30, 2023 at 4:41 AM Kevin Kofler via devel
 wrote:
>
> Bastien Nocera wrote:
> > As part of the same process outlined in Matthias Clasen's "LibreOffice
> > packages" email, my upstream and downstream work on desktop Bluetooth,
> > multimedia applications (namely totem, rhythmbox and sound-juicer) and
> > libfprint/fprintd is being stopped, and all the rest of my upstream and
> > downstream work will be reassigned depending on Red Hat's own priorities,
> > as I am transferred to another team.
>
> So Red Hat is essentially killing all work on desktop packages, not just on
> LibreOffice? Also considering that several of those packages are libraries
> that cannot just be put on Flathub as LibreOffice can (which was their
> excuse for terminating all work on LibreOffice packaging).

I would hardly say Libreoffice, bluetooth on the desktop and certain
iDevice pieces is "killing all work on the desktop" it's more focusing
on things that are important to their customers in those contexts.
___
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: UW-IMAP

[Peter Boy]

> Am 29.06.2023 um 18:15 schrieb David Both :
> 
> @Peter Boy:
> 
> I would truly appreciate your step-by-step guide. That would be
> incredibly helpful. I'm sure I can figure out connecting it with
> SendMail. There is lots of information out there but - as I said - it
> needs some work.
> 
> If you make it CC-by-SA it should be unencumbered and I will be sure to
> attribute that section to you. With your guide I would gladly use
> Dovecot.
> 
> I do have a deadline. Do you have an estimate of when you might finish
> the translation?
> 
> I know a little German from uni but not nearly enough to do a
> translation.
> 
> Danke und guten Tag.
> 
> -- 

Das klingt schon mal gut.


Well, I’m quite flexible at the moment. Maybe I have to prepare some 
contribution to FLOCK, just in case a proposal would get accepted. It’s quite 
comfortable for me to do it in the next 14 days. If that’s OK for your 
deadline. Otherwise I would reorganize my planning a bit more. Generally it’s 
not so much work using DeepL and some fine-tuning. But I would like to update 
the text slightly and do a final test - just to be sure (and I have to do that 
anyway for the planned tutorial). And CC-by-SA is OK for me (I just don’t 
remember what we sign with FAS account).


Peter




--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST /UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast


___
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: UW-IMAP

[Peter Boy]

Hi,

> Am 29.06.2023 um 16:27 schrieb David Both :
> 
> ...
> I also spent about 4 days trying to get Dovecot to work with SendMail in
> a test VM setup. I'm either missing one or more important bits or its
> just too complex for me. None of the docs I have found anywhere has a
> complete start-to-finish picture. I find no accurate list of here's
> exactly what needs to be in place and configured in this way to make it
> work. The docs I find are incomplete because they assume much about my
> knowledge or just skip parts that are needed. Others are just plain
> wrong after trying them.

Just in case you decide for dovecot (which would be preferable, IMHO), I could 
contribute a step-by-step guide to create a workable configuration of dovecot 
(it is Part of a solution for a rather full-fledged mail service). However, the 
instructions use Postfix, not Sendmail. But because the connection runs via 
milter, the replacement with Sendmail should not be a difficult.

At the moment everything is (still) in German. But I have to translate it 
anyway, because I want to create a tutorial for Fedora Server from it. 


> 
> [1] http://www.both.org/?page_id=1183

What a coincidence, actually found this in my ePub library (though still 
unread, sorry :-) ).



--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST /UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast


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

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

[Peter Boy]

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


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

I think there is a difference regarding the clones.

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

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

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

Perhaps it is a quandary, unsolvable without compromise.


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

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


—-
Peter Boy



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