go apps / imports of stlib / does rpm as a mechanisms to provide such infos

[Leon Fauster via devel]

IIRC, go applications with vendored modules/go-packages, if rpm-packaged
carefully, do provide go-package dependency information via the
rpm-provides tag for vendored packages. I wonder about "imports" of
golang's stdlib go-packages.

Usecase: go.dev releases a new golang version because an included
package (e.g. net) has a critical flaw. A local app does not use that
package and therefore does not need to be recompiled. How could I
enumerate the rpm packages that need to be recompiled?

Would this info generally be desirable?
Maybe with help of go-rpm-macros?

  go list -json | jq .Imports

shows such imports, when executed in the source/building directory.


rpm-provides tag example:

stdlib: bundled(golang(net)) = go1.21.9

vs

module: bundled(golang(golang.org/x/net)) = 0.24.0


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

Re: Firefox 126.0 with DBus service

[Leon Fauster via devel]

Am 15.05.24 um 14:11 schrieb Tom Hughes via devel:

On 15/05/2024 13:06, Michael J Gruber wrote:


Is this used by Gnome search unconditionally? I might want to use Gnome
but not a background indexer/tracker/search engine. Threw me off back 
then

when KDE introcuced something like that.


Go to "Search" in the Gnome settings and you can control which
search providers are enabled.



Its also configurable via

dconf read /org/gnome/desktop/search-providers/disabled

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

Re: Spec file using github repo - not tarball

[Leon Fauster via devel]

Am 09.05.24 um 17:21 schrieb Nico Kadel-Garcia:

On Wed, May 8, 2024 at 4:36 PM Kenneth Goldman  wrote:


Is it possible for a .spec file to clone a github.com repo rather than
download a tarball?  Can someone link to a working example?


Git clones are bulky, with the entire history of a project rather than
merely the state of the repo at the moment of that tag or git commit.
The "Source:" line can point to a specific archibal tarball or zipfile
export of sourcecode at github.com, such as:

 https://github.com/aws/aws-cli/archive/refs/tags/2.15.46.zip



IIRC, such archives are created on the fly and for some reason not 
consistent. Some projects do provide additionally source packages for 
there releases because of that ...


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

Re: mdadm Update in Rawhide

[Leon Fauster via devel]

Am 08.05.24 um 22:44 schrieb Jonathan Wright via devel:
I was having trouble finding the public key(s).  I'll look more into 
this now.


They sign the tar archive before it is compressed, so I'll have to stray 
from the standard way of verifying the sigs in the docs a little.





Here is an example of including the validation

https://src.fedoraproject.org/rpms/webkit2gtk4.0/blob/main/f/webkit2gtk4.0.spec#_203


BTW, the source and url uris in the spec file could be switched to https?!

https://src.fedoraproject.org/rpms/mdadm/blob/rawhide/f/mdadm.spec#_8

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

Re: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN

[Leon Fauster via devel]

Am 08.05.24 um 00:22 schrieb Kevin Kofler via devel:

Neal Gompa wrote:


On Mon, May 6, 2024 at 8:17 AM Leon Fauster via devel
 wrote:


Am 06.05.24 um 13:56 schrieb Florian Festi:

Hi everyone,

RPM has deprecated the %patchN syntax in favor of %patch -PN where N is
the patch number for a year now. See the RPM documentation for more
information [1]. In current RPM versions, this syntax only emits a
deprecation warning, but support for this syntax has been removed
completely in the upcoming RPM 4.20 release. As it will be added in
Fedora soon [2] it is time to switch over to the new syntax now.

There are around 1800 packages that still use the old syntax. Later
this week/next week, we will run this script [3] over the affected
packages
[4][5] to update them to the modern patch syntax. For example, the
script will change:

%patch0 -p1 → %patch -P0 -p1
%patch0005 -p2 → %patch -P0005 -p2




Is this supported by rpm in RHEL8/9 (EPEL8/9 builds)?



Yes. It's been supported for a very long time.


%patch -P is already documented in the 1997 First Edition of Maximum RPM.
Here is the link in the 2000 online edition:
https://ftp.osuosl.org/pub/rpm/max-rpm/s1-rpm-inside-macros.html#S3-RPM-INSIDE-WHICH-PATCH-TAG



Ok. I got it :-)

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

Re: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN

[Leon Fauster via devel]

Am 06.05.24 um 13:56 schrieb Florian Festi:

Hi everyone,

RPM has deprecated the %patchN syntax in favor of %patch -PN where N is
the patch number for a year now. See the RPM documentation for more
information [1]. In current RPM versions, this syntax only emits a
deprecation warning, but support for this syntax has been removed
completely in the upcoming RPM 4.20 release. As it will be added in
Fedora soon [2] it is time to switch over to the new syntax now.

There are around 1800 packages that still use the old syntax. Later this
week/next week, we will run this script [3] over the affected packages
[4][5] to update them to the modern patch syntax. For example, the
script will change:

%patch0 -p1 → %patch -P0 -p1
%patch0005 -p2 → %patch -P0005 -p2




Is this supported by rpm in RHEL8/9 (EPEL8/9 builds)?




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

Re: Multiple account problem

[Leon Fauster via devel]

Am 19.04.24 um 18:28 schrieb Steve Grubb:

Hello,

I have run into an issue on F39 that I wanted to ask about. I decided that I
wanted to develop an application on github from another account to simplify
which keys are being used. I created the user acct and used "su - myacct" to
login to it. I then tried to import gpg keys and got this:

gpg: key 495F8DEXXX/495F8DEXXX: error sending to agent: Permission denied
gpg: error building skey array: Permission denied
gpg: error reading 'myacct-secret.gpg': Permission denied
gpg: import from 'myacct-secret.gpg' failed: Permission denied

So then I logged in by ssh localhost and run "gpg --import" and got this:

gpg: Note: database_open 134217901 waiting for lock (held by 16325) ...
gpg: Note: database_open 134217901 waiting for lock (held by 16325) ...
gpg: Note: database_open 134217901 waiting for lock (held by 16325) ...
gpg: Note: database_open 134217901 waiting for lock (held by 16325) ...
^C
gpg: signal Interrupt caught ... exiting

Process 16325 is keyboxd pointing to the right homedir path. But then I
notice there are 2 keyboxd running for this acct. I log out and as root kill
everything under the new account and then ssh back to it. This time gpg pops
up a screen to ask the passphrase and it succeeds.

This is weird. In the past I know that you could "su" into an account and
everything just worked. The difference between "su" and "ssh" is that "ssh"
creates /usr/lib/systemd/systemd --user.

Should "su -" also start it's own systemd instance since things seemingly
can't function without it?
By extension, what does this mean for sudo?
Why do 2 instances of keyboxd for that acct get started? (Should the second
one have gracefully exited?)
Or is this expected behavior?



Briefly:

- su - , into account
- tmux , use a terminal multiplexer for terminal env sanity
- gpg your stuff

Before that - put in your target .bash_profile
# GPG AGENT
GPG_TTY=$(tty)
export GPG_TTY
eval "$(gpg-agent --daemon)"

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

Re: Redis will no longer be OSS... now what?

[Leon Fauster via devel]

Am 17.04.24 um 16:44 schrieb Jonathan Wright:

On Wed, Apr 17, 2024 at 9:43 AM Leon Fauster via devel 
mailto:devel@lists.fedoraproject.org>> 
wrote:


Am 17.04.24 um 15:59 schrieb Jonathan Wright via devel:
 > Valley 7.2.5 stable was released yesterday.  Builds are in Bodhi and
 > ready for testing/feedback.
 >
 > https://bodhi.fedoraproject.org/updates/?search=valkey-7.2.5-1
<https://bodhi.fedoraproject.org/updates/?search=valkey-7.2.5-1>
 > <https://bodhi.fedoraproject.org/updates/?search=valkey-7.2.5-1
<https://bodhi.fedoraproject.org/updates/?search=valkey-7.2.5-1>>
 >

Thanks for the work on it. I wonder why valkey conflicts with redis,
redict for instance does not!? Is this a decision for a preferred
upgrade path? What about leaving this decision to the user (keydb,
redict, valkey, redis on RHEL, etc) and allowing parallel installation
for testing, decision making processes and migration.


It is due to redict renaming some libs, while valkey has opted to retain 
"redis" on some lib file names.




It seems to be just links in the bin directory that overlaps (and not 
libs). Why not putting these links into the compat subpackage including
also the conflict statement. That would allow to install the main 
package side-by-side to the other key-value-db forks.


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

Re: Redis will no longer be OSS... now what?

[Leon Fauster via devel]

Am 17.04.24 um 15:59 schrieb Jonathan Wright via devel:
Valley 7.2.5 stable was released yesterday.  Builds are in Bodhi and 
ready for testing/feedback.


https://bodhi.fedoraproject.org/updates/?search=valkey-7.2.5-1 





Thanks for the work on it. I wonder why valkey conflicts with redis,
redict for instance does not!? Is this a decision for a preferred
upgrade path? What about leaving this decision to the user (keydb, 
redict, valkey, redis on RHEL, etc) and allowing parallel installation

for testing, decision making processes and migration.

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

Re: convert everything to rpmautospec?

[Leon Fauster via devel]

Am 08.04.24 um 08:01 schrieb Miro Hrončok:

On 08. 04. 24 6:08, Carlos Rodriguez-Fernandez wrote:


Not all commits correspond with a new release downstream, and not all 
commit messages are relevant to the end user to be part of the change 
log. For example, commits related with increasing gating test coverage 
efforts, or setting up gating.yaml itself. Another example is linting 
setting and/or configurations. How is that handled with autochangelog? 
Can we tell it to skip certain commits? Or should we include it all?


Put [skip changelog] in the commit message.

https://fedora-infra.github.io/rpmautospec-docs/autochangelog.html#skipping-changelog-entries



May be an [add rpmchangelog] would be more appropriate for some
scenarios, where branching and merging or whatever would clutter
the git log. Would lead to a more curated rpm changelog. Still,
not ideal.

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

Re: convert everything to rpmautospec?

[Leon Fauster via devel]

Am 08.04.24 um 22:22 schrieb Michel Lind:

On Mon, Apr 08, 2024 at 08:47:20PM +0200, Leon Fauster via devel wrote:

Am 08.04.24 um 20:12 schrieb Michel Lind:

(this might require coordination with RH's Leapp developers and
AlmaLinux's ELevate developers, to make sure those support upgrading
to lower NEVRAs too)


Would have a major EL release have a lower package NEVRA?
Mmmh, how many fedora releases are in between? :-)


If, say, EL9 inherits a Fedora 34 package with epoch set to 1, and we
allow Fedora epoch to be reset in Rawhide, and EL10 then inherits a
Fedora 40 package with epoch reset to 0 (change as suitable - more
likely to be EL10 from F40 and EL11 from F46, but in general there are 6
Fedora releases in between) -- then even if the version is higher
because the epoch is dropped, the EL(N+1) NEVRA will be lower.



Fair enough. Such change could be scoped just for fedora and keeping
the epoch for RHEL (I know it contradicts the plan). Anyway, as far as
I understand it, epoch support will still be available and its not
forbidden to use it, right? For some cases similar to xz-5.6-to-xz-5.4 
downgrades even necessary. Just wondering, why a reset of epoch in 
rawhide is desirable?


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

Re: convert everything to rpmautospec?

[Leon Fauster via devel]

Am 08.04.24 um 20:12 schrieb Michel Lind:

   (this might require coordination with RH's Leapp developers and
   AlmaLinux's ELevate developers, to make sure those support upgrading
   to lower NEVRAs too)


Would have a major EL release have a lower package NEVRA?
Mmmh, how many fedora releases are in between? :-)

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

Re: convert everything to rpmautospec?

[Leon Fauster via devel]

Am 07.04.24 um 17:15 schrieb Zbigniew Jędrzejewski-Szmek:

Hi everyone,

I'm revisting the topic of rpmautospec because I was doing some work
on various packages, and it's annoying that some packages are using
rpmautospec and others are not.

All my packages have been converted, so in day-to-day work, I don't
even think about %changelog. When working with other packages, I'll
forget to update the Relase and/or %changelog. Today I was rebasing
some pull requests in pagure, and the _only_ conflicts that I had were
about Release and %changelog.

I think it's time to switch to rpmautospec completely.
Thus, the proposal:
- new packages MUST use rpmautospec
- packagers SHOULD convert their packages
- provenpackagers MAY convert existing packages
   (e.g. when they want to push some fix or separately from other
work)
- people submitting pull requests against src.fp.o MAY also
   include a conversion in the pull request and packagers SHOULD
   merge it.

(FTR, 'rpmautospec convert' does the conversion, incl. the commit
to dist-git. Manual conversion should not be used.)



IIRC - EPEL8 is not ready for this?

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

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

[Leon Fauster via devel]

Am 05.04.24 um 12:20 schrieb Vít Ondruch:


Dne 04. 04. 24 v 17:32 Kevin Kofler via devel napsal(a):

Neal Gompa wrote:

By default, GNOME only presents the close window button. The other
buttons are missing, and there isn't really an intuitive way to
discover the other window management actions.



I agree that there are no other buttons. But still, Gnome opens the 
windows in normalized state, not maximized what was the original claim.



It feels strange when a discussion is done about such things, to argue
against or for a component/DE/software etc.

As I said intuition is not something that is inherently in the 
technology. For instance, the "scale a photo"-gesture on a common

mobile device OS, is not "natural". Its something that was communicated
by advertisements.

Such communication could look like (with alternatives):
In Gnome, with the focus on a window, use the leftAlt+Space shortcut
to get your needed function. All that from the keyboard (intentional 
efficient short cut). And for the mouse pushers, open the tweak app to 
configure the top bar of the windows to get your button. For the distro, 
just configure for example the minimize button to be present as default.


All that said, does not solve the dialectic discussion. I would suggest
the equal authorization to be present for both desktop environments. And
such principle should lead the further activities. Remember diversity 
wins, ideology not.


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

Re: Switching XZ for ZSTD?

[Leon Fauster via devel]

Am 04.04.24 um 19:23 schrieb Kevin Fenzi:

On Thu, Apr 04, 2024 at 01:26:14PM +, Arnie T via devel wrote:

Hi,

I just installed Fedora on 2 of my PCs a couple of weeks ago.  One version of 
Fedora 39 release and one of Fedora 40 to see where things are going.

I learned about this XZ-hack from Ars Technica & The Economist.

I got to the Fedora Magazine article and wasn't really clear on that.

So I followed the discussion to this thread in this Development mailing list.

I read a lot of it but _still_ can't 100% figure out what the final solution is 
going to be.


There's no 'solution' really... there's a lot of discussion around what
we can improve at the distro level, what we can urge upstreams to do,
how we can help out more, etc.

I'm hopeful some things will come out of this as it's a chance for us to
look at our processes and improve them.



One approach that would be at least bring some light into "weak"
(non technical layer) components (albeit not sure how feasible it is),
could be:

 - Checking the resources of a packaged project.
   Resources in terms of man or firm power that backup the project

 - Contribution activity of people

 - General activity of the project

 - Transparency of the workflow / tools

and that for all projects that the distribution includes.

Why? This would allow to plan internal review activities
(or processes) more effectively. They would be directed
to the "weak" components with higher priority (recurrent, actions).


Like the current process for checking the license (SPDX) of a project,
it could also collect such metrics right away.


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

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

[Leon Fauster via devel]

Am 04.04.24 um 00:44 schrieb Kevin Kofler via devel:

Leon Fauster via devel wrote:

I already had RHL installed on a Sun IPX with Gnome, so I'm biased.


Interesting that you were not put off by the changes that have happened to
GNOME since the old RHL days. I tried GNOME 1 at one point long ago, it was
actually pretty good. (It was very configurable back then. Remember when it
shipped Enlightenment as the window manager, how many options that had?)
Then GNOME 2 came, removing much of the configurability of GNOME 1. And then
GNOME 3 came, removing AGAIN much of the remaining configurability of GNOME
2, leading to a very hardcoded experience. GNOME 2 was already too much for
me, and I switched back to KDE, back because I had already tried KDE 1.1.1
on another distro. And I have never looked back.



Honestly, I know both worlds of the desktop environment paradigms. 
Therefore I do not compare these two because its pointless. Both follow

some design principles and addresses different goals. If KDE do expose
some knobs to configure something in the UI, its fine. I prefer Gnome
because its more tidier (no diving into dconf/gsettings possibilities).
For the proposal: both DEs are legit, one should not substitute the other.



Well, actually, I wanted to be fair and give GNOME 3 a chance, so I tried it
out once. But it took less than 10 minutes for me to realize that it is not
for me. The user experience is just too unfamiliar (the unified application
menu and open window selector (launch menu AND task bar replacement), the
always maximized windows, the lack of a system tray, the shut down options
in the mouse menu hidden behind a keyboard dead key, etc.), and GNOME does
not make it easy for you to change it. (You can actually get a pretty
standard desktop experience nowadays if you install a lot of "unbreak this",
"unbreak that" GNOME Shell extensions, but that kinda defeats the point of
GNOME.) The default experience felt pretty much unusable to me personally.



10 minutes is not enough to do a remodeling of the "familiar" 
experience, so that you reaches the so called realm of intuition.
The latter is something that we learn over time and the desktop 
environment does not offer this on its own. It provides only a

framework where this can happen.



KDE Plasma not only has more familiar defaults (actually looking and feeling
much more similar to GNOME 1 than GNOME 3 does), but also lets you easily
change those defaults that you do not like.




PS: Imagine the first CLI steps and the corresponding bad
experience, but we have not given up :-)!

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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)

[Leon Fauster via devel]

Am 03.04.24 um 20:56 schrieb Adam Williamson:

On Wed, 2024-04-03 at 20:24 +0200, Marc Deop i Argemí wrote:


Let's assume that we all agree with what you stated ( and I personally partly
do).

Why do we promote Workstation (with Gnome) over any other alternative that
might arise? (in this case, a Fedora Workstation KDE)


It's an interesting question. I would say my answer is "because it
works better if we promote *something*". Forcing the choice on people
who just want "desktop Fedora" is awkward. The reason we default to
GNOME is because we ~always have. To me, this is a reasonable



I second that. I prefer to have a clean path to go instead the endless
choice. Call it *nix philosophy, Hick's law or what ever. I call it
consistency and that is evidently the reason for Fedora's success, but
not alone.

Fedora's "variants" provides a coherent experience in the particular
usage. I already had RHL installed on a Sun IPX with Gnome, so I'm
biased. I would not change the place or what defines the Workstation
variant but other artifacts (editions, spins, labs) should get better 
visibility.


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

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

[Leon Fauster via devel]

Am 02.04.24 um 23:32 schrieb Adam Williamson:

On Tue, 2024-04-02 at 17:37 -0300, Sergio Belkin wrote:


I am a happy KDE user, since the good old days of version 1.0. I celebrate
this decision! My recognition goes to the enormous and sustained work of
the entire KDE community.
Cheers,
Sergiio


To be clear, there is no 'decision'. This is a Change proposal. Any
Fedora community member can submit a Change proposal proposing just
about any change; I could submit one tomorrow proposing we abandon all
software development and open a yak farm instead.

A Change proposal existing is in no way an indication of any ultimate
outcome. Change proposals can be, and frequently are, rejected.



Sorry, for not knowing the process right but where to vote up/down for 
such proposal?


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

Re: xz backdoor

[Leon Fauster via devel]

Am 31.03.24 um 21:33 schrieb Sandro:

On 31-03-2024 20:54, Christopher Klooz wrote:

On 31/03/2024 20.52, Christopher Klooz wrote:


On 31/03/2024 20.21, Michael Catanzaro wrote:
On Sun, Mar 31 2024 at 09:56:04 AM -05:00:00, Michael Catanzaro 
 wrote:
I'm really frustrated with our communication regarding this issue. 
Does anybody know who can fix this?


The Fedora Magazine article has been fixed (thanks!).

"*Fedora Linux 40 branched users (i.e. pre-Beta) likely received the 
potentially vulnerable /5.6.0-2.fc40/ build 
 if 
the system updated between March 2nd and March 6th*. Fedora Linux 40 
Beta users only using stable repositories are NOT impacted. Fedora 
Linux 39 and 38 users are also NOT impacted."


 -> only pre-beta, not beta, affected
 -> F40 beta using stable NOT impacted (without challenging the 
previously distributed assumption that testing is disabled by default)


That's still the same false information, isn't it?
Justin just has shown up in discourse. I suggested to get in touch 
with you, Adam or Kevin since he seemed to be convinced the article is 
fine as it is. When I refresh the article, it still seems to be 
unchanged. Is the update you mean already online Michael?


I clarified what's wrong with Justin in a DM on Matrix. He was on the 
same garden path as I was regarding "Beta release" vs. "Final release".


There will be another update to the article.




Not sure, if it was already mentioned -> containers. I had here a 
toolbox environment with F40. That I had not in my first actions

on the screen. The last state had 5.6.0-3 installed but not sure
if the previous release was also installed ...

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

Re: Unresponsive maintainer: petersen / Pandoc package not updated since June 2023: Security vulnerability, CVE-2023-35936 (medium)

[Leon Fauster via devel]

Am 01.03.24 um 07:55 schrieb Jens-Ulrik Petersen:
On Fri, Feb 9, 2024 at 8:05 PM Christopher Klooz > wrote:


__

The package "pandoc" remains at 3.1.3 in Fedora, but pandoc is
already at 3.1.11.1. Among the updates since 3.1.3, there have been
two security-critical (including the medium CVE-2023-35936. Security
fixes are in 3.1.4 & 3.1.6).

The actual risk is limited, but these should be updated nevertheless.

Just noting here for the record too, that those pandoc CVEs are now 
fixed with backports in Rawhide, and I will gradually push them back to 
current releases in the near future.


Is EPEL9 also included? That would be great!

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

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Leon Fauster via devel]

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.

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

Re: Mounting USB Storage devices with "sync" option ?

[Leon Fauster via devel]

Am 31.01.24 um 09:57 schrieb Larina Loriasel via devel:

'sync' has some strong downsides though: various operations become
painfully slow (this depends a lot on the hardware and its age, and
the history of previous writes, etc.), write operations block read
operations, and the total number of writes may be increased, leading
to more wear on the hardware.


The udev rule only applies to USB Storage devices, and I think the total number 
of writes increasing only happens if the data to be written is changed 
constantly (e.g. writes that overlap on same region/block of a device)
Most USB Storage devices are used for storing simple, consecutive streams of 
data, such as Music, Pictures and other simple files and are not usually 
modified much, thus, I think enabling sync makes sense in this regard.
In my opinion, the benefits of mounting USB Storage devices with sync outweigh 
the detriments.
Writes blocking reads is concerning.




Thats a to narrow view, as the USB interface is used in a ton of 
scenarios (backups etc.) where maximum data flow is an expectation.





We approach this problem from a different angle: the user is supposed
to sync the filesystem before removing. Graphical environments have
an "eject" button, and for non-graphical environments, the user
just needs to do a sync manually.


I am aware of that, but it leads to a poor user experience, being notified that 
a copying operation has been completed, while in reality, it has not.



CLI: Doesn't that trigger the umount command already ... so no need to 
think about it (as user). As soon the umount completes the device can be

unplugged.




The same is true for "normal" writes to a harddrive. Operations are
generally async, and the user needs to do a shutdown, during which
we sync and unmount filesystems. If you "yank" the cord, this may (*)
result in lost data and file system inconsistency.


My proposal was exclusively for USB Storage devices, not internal ones, as I 
can understand the benefits of async outweighing the detriments in the case of 
internal/network etc storage devices.



I never had a big issue in the GUI (long time/waits), as it clearly 
states to wait until removal is allowed (also stated via notify).

Normally (here) this is just a few seconds (single digit).

Maybe the idea can be implemented more transparently via vm.dirty_* 
sysctl per device if possible or is it a global threshold only?



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

Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)

[Leon Fauster via devel]

Am 24.12.23 um 15:03 schrieb Robert Nichols:

On 12/23/23 16:40, Sam Varshavchik wrote:

Christopher Klooz writes:

Btw, does anyone know if this (in the practically-same manner) is 
really already introduced in Windows, Mac, Android by default? 
Globally? This


Most recent Android phones, and iPhones do this by default.

What they do is pin each randomized MAC address per AP. They're not 
randomizing MACs for each connect, but basically generate a randomized 
MAC for each AP known to the phoneto spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


I hope that's per SSID and not per AP, or else that would mean that as a 
device roams among access points in my network it would keep generating 
new MAC addresses that are not known to my DHCP server?



https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/main/src/libnm-core-impl/nm-setting-wireless.c#L1598




It's bad enough that I can't know in advance what MAC address a new 
device will be using, and might thus have to decide which, of several 
possible DHCP requests that might appear, is the one to which I want to 
grant access.




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

Re: DNF5: Checking signatures of packages installed out of a repository?

[Leon Fauster via devel]

Am 14.11.23 um 22:04 schrieb Christopher:

On Tue, Nov 14, 2023 at 9:30 AM Michael Catanzaro  wrote:


On Tue, Nov 14 2023 at 08:16:39 AM -0500, Christopher
 wrote:

I think for the sake of security, it'd be better if this were on by
default, and you just had to specify the --nogpgcheck
For convenience, the error message should probably say "Error: GPG
check FAILED (try again with '--nogpgcheck' to ignore)"
I don't think this use case is so important that everybody's security
should be lowered to avoid the minor inconvenience of passing a simple
flag.


Thing is, when manually installing RPMs that don't come from a
repository, 98% of the time they are not expected to be signed by a GPG
key that you have installed, so the check is expected to fail.


The failure indicates that the source and integrity of the RPM is
uncertain. The fact that the user is expected to make a conscious
decision to bypass it when they want to accept that risk, but to be
stopped if they don't want to accept that risk, is the whole point.
So, yes, the check is expected to fail under those circumstances.

As for how common those circumstances are, I just surveyed my Fedora
systems, and 100% of the RPMs I've manually installed, including some
pertaining to Slack, Docker, Chrome, Jenkins, and InfluxDB, as well as
my own that I've built, all are signed. In my personal experience,
it's rare to come across an unsigned RPM. You may have a different
experience, but the frequency isn't the point... the point is to
provide protection by default and user choice to override and accept
the risks. Right now, we have acceptance of risk by default instead of
protection.


GPG check is just not the right thing to do in this case.


I disagree. I think it *is* the right thing to do to check, and offer
the option to skip the check. That gives users the choice to be
insecure if they want, but leaves the default secure.


If we enable GPG checking when not appropriate,


I disagree that the failure implies that GPG checking isn't
appropriate. I think the fact that an un-bypassed check failed, in
response to an RPM from an unknown or untrusted source, is very
appropriate. The only time it would not be appropriate, in my opinion,
is if the user chose to bypass it.


***we will train users to reflexively ignore GPG errors.***


So, your position is: "don't train users to ignore GPG errors... we'll
ignore them for you" ?!?!

First, I don't agree that this will happen. I think it's more likely
that users who are lax with security will continue to be lax with
security, and users who aren't will pay attention to the failures and
use that as a signal to inform their acceptance of the risks. But
second, even if you're right, the worst case scenario here is the
scenario we already have as the default: the check being ignored by
the user is nearly the same as the check not being performed at all,
which is what's happening today. If you're concerned that GPG errors
will be ignored, I don't understand why you're not concerned with the
fact that the only reason why users aren't seeing those errors today
is because GPG checks aren't running at all! All the same security
risks are still there... including the risks for an invalid or
fraudulent signature when it is present on a local RPM, in addition to
the risks when the signature is missing... they're just being ignored
by default. You're worried about a situation where a user *might*
ignore security check errors... but I'm worried that they are
auto-ignored by the system, before the user even has a chance to take
them seriously.



(We have already trained users to approve importing new GPG keys as
long as they claim to be from Fedora, since this is required every
Fedora release. This is bad enough.)


I don't agree with that either. I verify the signatures of Fedora keys
using https://fedoraproject.org/security and the keys of other repos I
use, and other users who care about security can do the same. I think
Fedora has done as good a job as one can expect, for the most part, in
trying to provide good security to those who care. But, of course,
users have to care first and do their part as well.



GPG check makes sense when installing RPMs from a configured
repository, not when manually installing RPMs from a filesystem path or
URL.


Again, I completely disagree. The check protects against corrupt
and/or malicious software, and is one of the few steps the package
management system has to proactively prevent harm to the user's system
*before* the harm is done. Skipping these checks by default is bad for
software supply chain security, regardless of whether the supply chain
involves a repo or just an RPM. The signatures are in the RPM, and the
keys in the RPM database. The fact that it came from a repo or not is
completely irrelevant for good software supply chain security
defaults.




I completly agree with you. Just wanted to note (as mcatanzaro already 
pointed at). Even when all sec-checks are enabled, the 

Re: Help running centpkg

[Leon Fauster via devel]

Am 07.10.23 um 17:30 schrieb Stephen Smoogen:



On Sat, 7 Oct 2023 at 10:50, stan via devel 
mailto:devel@lists.fedoraproject.org>> 
wrote:


On Fri, 06 Oct 2023 16:05:25 -
"Michael Dawson" mailto:midaw...@redhat.com>>
wrote:

 > I'm trying to build
 > https://gitlab.com/redhat/centos-stream/rpms/nodejs
 using centpkg but
 > am running into errors.
 >
 > I'm using Fedora 37 and get this error when I run centpkg mockbuild
 > --with=bundled in the directory where I've cloned the
 > https://gitlab.com/redhat/centos-stream/rpms/nodejs
 respository and
 > switched to the stream-nodejs-18-rhel-8.10.0 branch.
 >
 > I'm getting this error:
 >
 > Total
 >                                                    3.7 MB/s |  50 MB
 >    00:13 Running transaction check Transaction check succeeded.
 > Running transaction test
 > Error: Transaction test error:
 >   file /usr/sbin/alternatives from install of
 > chkconfig-1.19.2-1.el8.x86_64 conflicts with file from package
 > alternatives-1.24-1.fc38.x86_64
                       


Good catch. You should not mix and match el and fedora packages or 
repositories like that.


Michael if you are using Fedora 37 as you say lower down, you have 3 
different releases trying to put packages on the system:
EL8, Fedora 37 and Fedora 38. You can possibly match Fedora 37 and 
Fedora 38, but EL8 is like bringing in EL29 packages into the mix.. 
years of changing file locations and such.


I generally use toolbox these days for this sort of development:
1. Install the Linux you want to use daily. Get it the way you want it 
for that day driving work.

2. `dnf install toolbox`
3. some variation of `toolbox create --image 
quay.io/toolbx-images/centos-toolbox 
 centos-stream-9`

4. `toolbox enter centos-stream-9`
5. Do the package installs of centpkg
6. Do the builds



Just out of curiosity because I never used toolbox.
Is the above not also accomplishable with a local container?

podman run -ti --name=dev quay.io/centos/centos:stream bash -li

Or does it have additional features?

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

Re: Orphaning all my packages

[Leon Fauster via devel]

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.

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

Re: Orphaning all my packages

[Leon Fauster via devel]

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


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

Re: Orphaning all my packages

[Leon Fauster via devel]

Am 03.10.23 um 20:23 schrieb Stephen Gallagher:

On Tue, Oct 3, 2023 at 2:14 PM 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.



The *exact* set of source code that the package was built for is
included in the Source RPM and all of the individual changes that
comprised it are part of the c9s branch in CentOS Stream (or the
maintainer has been regressing code, in which case that should be
addressed). No, the git repo might not contain a specific git
reference that directly matches the SRPM you cite, but that's not at
all the same thing as "the code isn't available in git".



Not sure if its intentional or not but the misunderstanding
in the communication is ridiculous. Some one argues that the code
is available and forget to explain what code is mentioned. If a bumped
version of a package fixes an issue (stream variant of CentOS) e.g 2.2,
and a released package (rhel variant) has a backported fix for e.g. 2.1,
that doesn't mean that the code is also in the stream git just because
both code fragments fixes the same issue. The backported code can be
very different, and its not in the git branch of the stream variant.
So, that code is not available in git, and to cite Michael "and never
will be."

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

Re: Orphaning all my packages

[Leon Fauster via devel]

Am 03.10.23 um 17:33 schrieb Todd Zullinger:

Sérgio Basto wrote:

On Tue, 2023-10-03 at 10:25 -0400, Todd Zullinger wrote:

a project
where the primary sponsor and downstream no longer provides
source code freely and openly


what you are talking about ? all RHEL Source are freely available on
Centos Stream , and RHEL never was free .


That's not the case, but I don't wish to go wildly off-topic
about it either.

_Most_ of the source is available, but not all of it.  This
is a case where -- for me -- close is not good enough.

To each their own.



I personally was shocked after the related announcement of RH
and my affective reaction was similar to yours. But, taking
a wider look at the ecosystem reveals that RH is giving a lot
to the "community" [1] and I am sure that the landscape would not
look like this (viable projects) if RH did not exist.

Anyway, a lot of companies provide commercial products, that use
open source as their ground floor. Stopping the support in upstream
projects because of that, hits the wrong "people" (IMO).

Nevertheless, thank you for your long contribution!

[1] https://www.redhat.com/en/about/open-source-program-office/contributions

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

Re: An update on RHEL moving to issues.redhat.com

[Leon Fauster via devel]

Am 15.09.23 um 07:43 schrieb Clement Verna:

At the risk of being controversial and a voice of the minority, I think 
using GitHub would be beneficial for the Fedora project. In practice 
already most of packagers have to use GitHub to collaborate with 
upstream so it wouldn't  be a tool to learn. But where, GitHub would be 
really beneficial IMO is for making our work more visible and reachable 
to attract new contributors. It is also worth to mention that other 
distros close to Fedora like Alma Linux or Rocky Linux are using GitHub 
for their development and it doesn't seems to be a problem.


IIRC, github just get copies of the self-hosted git-instances that are 
based on gitea (https://git.almalinux.org/) or gitlab 
(https://git.rockylinux.org/) ...


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

Re: Intent to orphan vpnc

[Leon Fauster via devel]

Am 06.09.23 um 00:08 schrieb Christian Krause:

Hello,

vpnc is a VPN client which can be used with certain VPN devices:
https://www.unix-ag.uni-kl.de/~massar/vpnc/ 



The last co-maintainer who actively maintained the package for the last 
few years just stepped back. Since I don't have a use case for it 
anymore (and no ability for testing), I'm going to orphan it in the next 
few days.


The only package which depends on vpnc is NetworkManager-vpnc.

There is no active upstream for vpnc. However, according to the bug 
reports for NetworkManager-vpnc, there might be still a few users.





Just curious - are there other IPsec implementations that could fill the 
gap of vpnc? Or is vpnc very specific?


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

Re: KDE and GNOME Join Hands To Add Payments To Turn Flathub Into a Store for the Linux Desktop

[Leon Fauster via devel]

Am 04.09.23 um 03:48 schrieb Ryan Bach via devel:

Ryan Bach via devel wrote:

First of all, as has been pointed out by others, the headline is misleading,
since KDE and GNOME are not actually parties to the proposal and since the
proposal was not even accepted.

Secondly, IMHO, allowing fee-charging downloads is an anti-feature of an
application repository that I specifically do not want. One of the nicest
features of GNU/Linux is that I can just open the package manager and
download whatever I want without having to pay anything.

And finally, Red Hat trying to monetize the Desktop would be the worst
nightmare. I do not want my desktop GNU/Linux to be "monetized" by anyone,
neither by Red Hat nor by any other company.

 Kevin Kofler

What is so wrong about buying open source software?



The real question should be how to compensate for the
expenses/ressources so that the development is substantially
maintained. Any more concepts? The mentioned one is just one
way. I actually would suggest a micro-pay approach, not for
the software but for the motivation of the developers ...

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

Re: Adding Passim as a Fedora 40 feature?

[Leon Fauster via devel]

Hi Richard,

Am 25.08.23 um 13:42 schrieb Richard Hughes:

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.




whats the benefit of this "self-signed TLS certificate" (as it does
not provide any "security")? Is this stub for something later ... ?

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

Re: Dropping of sshd.socket unit

[Leon Fauster via devel]

Am 17.08.23 um 20:14 schrieb Tomasz Torcz:

On Thu, Aug 17, 2023 at 08:25:10AM -0500, Chris Adams wrote:

Once upon a time, Lennart Poettering  said:

Yes, and if this is not what you want, then disable the
ratelimit. That's what I am saying?


It would be useful for systemd to have "cooldown periods" for things,
similar to inetd and classic init, where misbehaving things (whether
services or sockets) were paused for a time (configurable even) and then
returned to service.  AFAIK this is a flaw in general in systemd's
limits; if something exceeds them, it takes manual intervention to reset
them.


   Very recent systemd versions have exponentially-growing restart intervals.
I guess you can use very large limit for number of restart, and use
RestartSteps=/RestartSecMax= to make "cooldown periods".




for systemd.sockets ?


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

Re: Potential (security) issue for beginners/non-experts when release is End Of Life: Fedora doesn’t consider the behavior of beginners/non-experts sufficiently

[Leon Fauster via devel]

Am 11.08.23 um 17:59 schrieb Michael Catanzaro:
On Fri, Aug 11 2023 at 02:24:22 PM +, Christopher Klooz 
 wrote:
First of all, I don’t use my Fedora installations until their end of 
life, so I don’t know if we have any means in place that shall make 
users aware once their release reaches end of life?


Fedora Workstation will display a nag notification once per week when a 
newer release is available, so unless you uninstall GNOME Software or 
ignore all notifications, you should at least be aware that a newer 
version is available.


I had thought we had daily nag notifications once the release has 
reached end of life, but maybe I was imagining it because I can't find 
any evidence that this actually exists. I think GNOME Software should 
look at SUPPORT_END in /etc/os-release and nag more frequently.




Please do not clutter the user experience with such _additional_
informations. The user on such workstations are not always the
administrator and such informations would not help/change the
situation either. I actually do a lot of config work to disable
such UI "features". For my case the user does not even understands
or notice it when a major upgrade was done (albeit some UI improvments).
Of course the active usage of Gnome software or dnf could and should
provide such information in a prominent way ...

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

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

[Leon Fauster via devel]

Am 26.07.23 um 18:00 schrieb Chris Adams:

Once upon a time, Solomon Peachy  said:

None of the other SSDs I have deployed (Samsung and Crucual SATA) are
updatable via LVFS, unfortunately.  But, hilariously, both Samsung and
Crucial's official updaters appear to be self-contained linux ISOs.  So
clearly the technical capability is there...


The difference is often the update method.  fwupd supports a specific
standard way of applying firmware updates, but often things use very
proprietary methods.  Some storage may not support applying updates
while be accessed for example (so have to boot from ISO/etc. to apply
while unmounted).

While there's a standard for updating UEFI firmware, lots of
motherboards still use older custom methods.  Also, many are unable to
carry over config properly, so they reset all settings on a firmware
update (which is problematic and arguably a reason for making it harder
to do).  I think most of the systems I've used that support fwupd UEFI
updates are able to do so without a config reset.

Which... having to have a config reset on a firmware update in this day
is so dumb.  Very rarely do config options change (and even then, it is
typically "new options added", not old options changed), so there's
really no excuse for not storing the config in a forward-compatible way
and restoring those settings after a firmware update.  Dell PowerEdge
servers have managed this for years, why can't they apply it to
everything?

And also, why can't Dell get PowerEdge updates into LVFS? :)



While reading this discussion, I tried it on my local Dell XPS and
was surprised that LVFS suggests a firmware update (bios) for my
model (it says that I'm 4 versions behind), albeit on Dell's support
page such updates are not listed (here I would have already the latest).

Not sure about the integrity / quality of the uploads to LVFS??

Does anyone know how to compare the artifacts on LVFS (.cab) with
the ones on Dell's support page (.exe, .rcv)?


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

Re: Restricting automounting of uncommon filesystems?

[Leon Fauster via devel]

Am 23.07.23 um 09:35 schrieb Vitaly Zaitsev via devel:

On 22/07/2023 08:01, Matthew Garrett wrote:

1) Automounting of removable media exposes the kernel to a lot of
untrusted input


Disable automatic mount by default. Problem solved.




We use a whitelist approach here based
on usbguard daemon (hw centered), and

# cat /etc/dconf/db/local.d/s-media-automount
[org/gnome/desktop/media-handling]
automount=false
automount-open=false

Our scenario is clearly modelled around an user
in front of a GUI. So, it tackles it in different
layers and the actual fs attack vector is not addressed.

Should a "middleware" based on guestmount just check
for the integrity of the fs or keeping it in such
sandbox?

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

Re: [Question] how to make Fedora linux os ?

[Leon Fauster via devel]

Am 16.07.23 um 21:24 schrieb Christopher:

On Sun, Jul 16, 2023 at 7:30 AM Kevin Kofler via devel
 wrote:


Miao, Jun wrote:

Hi Guys,


First of all, we are not all guys. (I happen to be one though.)


I would advise not to get too picky about this. The term "guys" isn't
necessarily gender-specific. In its plural form, it has basically
replaced "folks" in many English dialects, and holds the same
non-gendered meaning. The antonyms, "guy" and "gal" have largely
fallen out of favor in English, with the latter being quite rare, and
the former's plural form evolving into a non-gendered usage, similar
to "dude(s.)" and "dudes(pl.)" being used in non-gendered ways. While
I think it's a good idea to use gender-neutral language when gendered
language isn't needed, this one actually is pretty gender-neutral
already, at least in the way many people use it. So, I recommend not
reading too much into casual greetings like this. Getting too picky
runs the risk of polarizing people and making it harder to make
changes for the better where it matters. Assuming good intentions, it
seems like the author intended this in the common, modern,
non-gendered plural form to me.




AFAIK, the Yocto Project is an open source collaboration project that
provides tools, templates, and methods to help developers create custom
Linux-based systems for embedded devices.

My confusion is that:

   1.  what`s the tool to make our Fedora Linux 38 released like Yocto?


There is more than one tool in use. The main build tool is Koji, but it
depends on other underlying tools such as Mock, DNF, RPM, etc. Also keep in
mind that in Fedora, all binaries are natively compiled, not cross-compiled
as in Yocto. I.e., the rpmbuild process needs to run on a (real or emulated)
CPU of the architecture for which you want to build the package. RPMs do not
typically support cross-compilation.


When I saw the original post, I was interested to see what responses
it would trigger. I must admit that this one is a bit disappointing.
While I've been building RPMs for Fedora for awhile now, one of the
things that has eluded me is that the Fedora OS composes seem to be
very opaque to me. I know enough to understand that Koji tags rpm
builds from individual buildroots, but from there, the process to
build the repos and the installation media, or how the buildroots are
created in the first place for Koji, or any other weirdness involved
in the construction of the OS as a whole from the individual RPM
builds, all of that seems opaque to me. I think it'd be great if there
was an up-to-date and detailed step-by-step guide for how to build a
Fedora release. Such documentation should be detailed enough that one
could stand up their own fork of the Fedora OS... not because we want
to encourage that... but because that's the level of detail that I
think is needed to allow volunteers to step in and get involved, as
the current folks move on, due to retirement, death, boredom, or
whatever. If such documentation already exists, I don't know where it
could be found.

Do you know of any such detailed documentation, step-by-step
instructions, or maybe slides/presentations on the compose process or
overall Fedora OS build systems?


https://docs.pagure.org/releng/

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

Re: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Leon Fauster via devel]

Am 11.07.23 um 21:02 schrieb Chris Adams:

Once upon a time, Mattia Verga  said:

Since RHEL is made out from Centos Stream and Centos Stream is made out from 
Fedora ELN, can't Alma and Rocky branch directly from Fedora?
Can we collaborate in some way with those communities so that we support each 
other? I mean, like we have Fedora ELN and EPEL...


Their goal is to replicate, as near as practical, the versions, bug
fixes, patches, etc. in RHEL, so that the usage (and for some people,
running of pre-compiled binaries) is functionally identical to a given
RHEL release.  Since Red Hat has long used the "patch rather than
upgrade" approach for most packages during a release's lifetime, the
only way to get a practically-identical system is to get those same
patches.

In theory, any patch to a package in say RHEL 9.2 should eventually land
in CentOS Stream 9, because RHEL 9.3 should be forked from CentOS Stream
9, but that doesn't always happen in a convenient time frame (plus
sometimes something may be fixed one way in a 9.2 update but differently
in 9.3).  Also, CentOS Stream 9 will stop getting updated much sooner
than RHEL 9.x - when RHEL 9.x transitions to "maintenance mode" (no new
functionality planned, just bug/security fixes), CentOS Stream 9 will
stop altogether.

And Fedora ELN is aimed at CentOS Stream 10, which will eventually be
used to make RHEL 10.0, so is not useful for replicating RHEL 9.x
updates.



An addendum to this:

C8S ends 2024, while RHEL8 ends 2029
C9S ends 2027, while RHEL9 ends 2032

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

Re: more distinct default bash prompt?

[Leon Fauster via devel]

Am 08.07.23 um 22:44 schrieb Barry:




On 8 Jul 2023, at 19:56, Kushal Das  wrote:

White background is a good choice for accessibility iirc.


Isn’t is contrast that matters not any particular background?



On the contrary it helps, a white background helps the human visual
system to distinguish patterns better then a black on do but this is
just one aspect to prefer the one or the other ... :-)

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

Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)

[Leon Fauster via devel]

Am 07.07.23 um 12:19 schrieb Richard W.M. Jones:

On Thu, Jul 06, 2023 at 05:10:24PM +0100, Aoife Moloney wrote:

Important process note: we are experimenting with using Fedora
Discussion as part of the Changes process. Change announcements (like
the one you are reading right now) will still be sent to the
devel-announce mailing list, but the conversation about each change
will take place on Fedora Discussion at
https://discussion.fedoraproject.org/t/f40-change-request-privacy-preserving-telemetry-for-fedora-workstation-system-wide/85320


Why?  This was discussed a while back and the number problems with
discourse were covered, and to my knowledge none of them have been
fixed.


== Summary ==

The Red Hat Display Systems Team (which develops the desktop) proposes
to enable limited data collection of anonymous Fedora Workstation
usage metrics.

Fedora is an open source community project, and nobody is interested
in violating user privacy. We do not want to collect data about
individual users. We want to collect only aggregate usage metrics that
are actually needed to achieve specific Fedora improvement objectives,
and no more. We understand that if we violate our users' trust, then
we won't have many users left, so if metrics collection is approved,
we will need to be very careful to roll this out in a way that
respects our users at all times. (For example, we should not collect
users' search queries, because that would be creepy.)


This also keeps coming up and the answer is again, no!  There's no
such thing as anonymous data collection, people don't want it, it must
not be enabled by default (making it useless to you), it's probably
illegal in the Europe, so stop asking for it.


+1

General Data Protection Regulation in EU law.

"... consent can't be implied and must always be given through an opt-in 
..."


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

Re: more distinct default bash prompt?

[Leon Fauster via devel]

Should this also take into account some common individual prompts? 
We have for instance /usr/share/git-core/contrib/completion/git-prompt.sh 
sourced. 
Maybe a form of compat for such wide used customisations? Thought ... 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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)

[Leon Fauster via devel]

Am 03.07.23 um 18:07 schrieb Simon de Vlieger:

On 7/3/23 13:46, Ralf Corsépius wrote:


It is the core of the problem esp. big US companies tend to ignore.

May-be you guys are not aware of there are tendencies to legally 
prohibit such "cloud solutions" in many countries?


It's generally not so much 'legally prohibit' as 'data has to be kept 
within $jurisdiction and is not to be shared outside of it'. If 
$jurisdiction is large enough cloud operators tend to offer that solution.



Its not a cloud provider its a software vendor. Further more a couple of
authoritative entities have proven that such solutions do not comply 
with data protection requirements. Its of value having a standalone 
package (to getting back to the topic). If not now, for sure in the near 
future.


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

Re: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Leon Fauster via devel]

Am 03.07.23 um 02:00 schrieb Michael Catanzaro:
On Sun, Jul 2 2023 at 06:27:48 PM -0400, Demi Marie Obenour 
 wrote:

What about stuff that is too urgent to wait on Red Hat QA?  There have
been vulnerabilities (such as CVE-2013-0156 and Log4Shell) for which
unauthenticated, fully automated, remote code execution exploits have
been found very, _very_ quickly.  There may well be times when
attackers can write and use an exploit faster than Red Hat QA can
process an update.  For these vulnerabilities waiting on Red Hat QA
is not an option.


Dire emergencies like these are extremely rare, but when they do occur, 
everybody needs to work together to get updates out to all users ASAP. 
That's true for every distro. Hypothetically speaking, if I were ever 
unfortunate enough to be responsible for an emergency scenario like 
that, I'd still want enough basic QA to at least ensure that the update 
won't eat your disk, but such decisions would surely be handled on a 
case-by-case basis.


In a more normal situation, updates take a few days to prepare. I really 
don't think there's any problem with how CVEs are handled in CentOS 
Stream *except* for the problem I mentioned earlier about maintainers 
forgetting to push package updates to CentOS Stream by mistake. We need 
a better process to ensure human error doesn't result in CentOS Stream 
missing security or non-security updates. (This impacts RHEL too, 
because future minor releases are built from CentOS Stream, and we don't 
want fixes to disappear in future releases.)



There is also demand between major release, some "features" are missing 
in EL9 for instance.


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

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

[Leon Fauster via devel]

Am 03.07.23 um 00:41 schrieb Michael Catanzaro:



On Sun, Jul 2 2023 at 08:33:46 AM -0700, Carlos Rodriguez-Fernandez 
 wrote:

Hi Michael,

We have been told repeatedly that "the source is there" in CentOS
stream.


The source for the next minor version is there.


I can see the scenario that RH branches from CentOS stream to
create a new minor release, and during QA, a bug is discovered and a
patch is backported (or created) to fix it internally in your minor
release branch. However, if that bug wants to be addressed also in the
next minor release, it will need to appear in the CentOS stream at some
point, whether via a patch or an entire source version bump.


Right; nobody wants regressions. In this particular example, the fix is 
there via "an entire source version bump."



If that's not the case, then RH is having some long living parallel git
repo which will eventually create ABI compatibility issues, and it is
also not what we have been told.


So I'm really primarily here to talk about Fedora and CentOS Stream, 
because we often can't talk very much about RHEL. I'm going to point you 
to this page:


https://access.redhat.com/support/policy/updates/errata/

And in particular this graphic:

https://access.redhat.com/sites/default/files/images/337_rhel_9_life_cycle_updates_0423.png



With the transitioning to "maintenance phase" next summer (EL8), I
assume that for the next 5 years nothing gets pushed into c8s git
anymore??

So, the mentioned mantra is only the half of the story ...

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

Re: Orphaning packages (was LibreOffice packages)

[Leon Fauster via devel]

Am 01.07.23 um 14:28 schrieb 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.



No really, it defines requirements that a non-cloud solution addresses.
Just to rephrase it; "it's often more secure (confidential) on corporate 
networks than with cloud providers". So a legitimately contribution to

the discourse in having a functional desktop (office) environment.
Whether its being flatpaked, rpmish, immutable packaged or what ever the
future brings ...

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

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

[Leon Fauster via devel]

Am 30.06.23 um 15:41 schrieb Leslie Satenstein via devel:


What should I do, if the person I gave the software to, removes my
copyright, rebrands the software and sells my software as their own?
Is it right? And when I release a bug fix, they take it, insert the
fix into the rebranded copy they are selling, and they quietly say,
"Screw You, Leslie".


Ask yourself; how does open source methodology works?

Just using your words: Apple Inc. releases a bug fix, RedHat takes it,
insert it into the rebranded copy (RHEL) they are selling ...

https://git.centos.org/rpms/webkit2gtk3/c/f1679e95706409206b768d4f0a03563066c52bda?branch=c8


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

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

[Leon Fauster via devel]

Am 30.06.23 um 16:05 schrieb Sérgio Basto:

On Thu, 2023-06-29 at 23:57 +, Piotr Szubiakowski wrote:

Hey!

On Thu, 2023-06-29 at 19:12 +0200, Paolo Bonzini wrote:



On 6/26/23 18:47, Jeff Law wrote:

What Red Hat has done may be technically legal and perhaps
good
for
its business.


Something I'm having trouble with is Red Hat's position that
you can choose to be a customer or to exercise your rights
under the GPL, but you cannot be both.


The thing is, many people are learning this only now, because
things
indeed have become tougher for people who prepare the RHEL
rebuilds,
but
this is not new.  _Nothing_ in the service agreement or in any
other
legal document has changed since last week, the exact same terms
have
been applicable to the extended-support branches since the
beginning
of
RHEL.  In fact, as Frank pointed out elsewhere, this is something
that
other companies have been doing for decades as well.



In my opinion, people haven't complained about service agreements
because, till recent changes, RHEL sources were available publicly.
The
only important contract was the open-source license of the software.
Now we have both the license of the software and the service
agreement.



First I think this a storm in a teacup .
Second Centos Stream is the RHEL without branding, people in general
didn't like the idea of Centos be updated before RHEL , when Centos was
updated after RHEL , but that was the main change.
After whats happened was that not all was updated first in Centos
Stream like kernel (we saw updates with ABI breakage first on RHEL ...
). This announce is mainly , as I read, saying that exceptions will be
over and all will be first on Centos Stream and than in RHEL



Someone says or writes it, other reads it, but the reality is that in 
CentOS Stream are always continuously missing parts of RHEL. I do not

complain about it, but its annoying when the narratives that everything
is there are spreaded.

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

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

[Leon Fauster via devel]

Am 29.06.23 um 17:49 schrieb Carlos O'Donell:

On 6/26/23 18:47, Jeff Law wrote:

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.


Why is it ethically unconscionable? There is a lot of confusion around
what has happened and why. What you are saying, and what actually happened
don't line up in my mind :-)




Well, lets start just (and that alone is reprehensible) with untrue 
sentences  that just miscredited the open EL-community (open 
EL-community == all without RH and RH customers). Its just a slap in the 
face of contributers, EPEL maintainers (non @redhat.com owners) and so 
on ...

This is just done to have a bigger gap in the reasoning argumentation.
This is FUD tactic and dignityless for RH. They have reasonable 
arguments to do what they do, but the "style" is ethically unconscionable.



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

Re: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Leon Fauster via devel]

I do have packages on a RHEL9 system that do not appear in 
https://kojihub.stream.centos.org/koji/ - so the fix is unknown from an 
external view
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: What is Fedora?

[Leon Fauster via devel]

Yep! I (We) spend a lot of unpaid time to provide EL bug reports, helping the 
devs to test their fixes, until it gets into the next EL minor release. 
Especially when a new major EL release is GA, it has a lot of bugs that I 
normally do report (doing it since EL5 personally). This is sometimes only 
possible when having the source code to test some patches before adding them to 
the report. Despite the argument that the srpms are available in the portal 
area, I wonder if the mentioned decision had included this "tacit" input that 
is coming from the "community". Not having such input in combination with a 
reduced community will for sure have a negative impact. I'm already reading 
statements from Fedora maintainers of their EPEL backtracks and I can imagine 
that the same is happening for less visible contributions ... 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Leon Fauster via devel]

> I will also point out that CentOS Stream is perfectly suitable for
> production use, and I would argue it provides a differentiated

Nope, its not perfect for production use. Just an example of _many_:

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

Despite the fact that some critical fixes only land into the compose many weeks 
later, if at all. 
Some are only in RHEL while CentOS Stream have a rebased version without the 
fix. Nope, its not perfect 
for prod use. Emphasizing perfect here. Everything else is corporate speak. Its 
just perfect to make
contributions, and this is the main intention of "CentOS Stream".
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: What is Fedora?

[Leon Fauster via devel]

https://access.redhat.com/security/updates/backporting/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: What is Fedora?

[Leon Fauster via devel]

> 3) So what happened?
> 
> - CentOS Engineers will not be producing that git repo of exploded SRPMs 
> anymore because there is no need for them in CentOS project.
> 
> - Red Hat recommends to take RHEL sources from CentOS Stream 
> repositories because that is the actual source from which RHEL packages 
> are built by RHEL Engineers.

How to interpret it this way; "Red Hat recommends"? Its the other way around!
RH does want minimize the source availability by putting stones in the way! 
This is in line with other activities (kernel patches).

Regarding Dev Account - that can be also disappear in the future!

Furthermore:

Take a look at the Unauthorized Use section

https://www.redhat.com/licenses/Appendix_1_Global_English_20230309.pdf

and "Partner will not use Red Hat Products or >>>Services to create an 
offering competitive with Red Hat," 

from 

https://www.redhat.com/licenses/Partner_Agreement_Webversion_North_America_English_20220308.pdf

The tactic here - not the sources are used against the community its the road 
to them ("Services")!

This is the cathedral method. 


BTW; The sources "state" in gitlab is not stable and "far" away from RH GA 
releases!
 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: LibreOffice packages

[Leon Fauster via devel]

Is the Fedora OCI flatpak approach not about the trust into the chain of 
flatpak creation? src -> signed rpm -> flatpak? So, even in an ideal world 
where RHEL is immutable and the best workstation experience is based on 
flatpaks - RPMs are the building block. This is completly different to the 
Flathub approach ... https://fedoraproject.org/wiki/Flatpak#Fedora_flatpaks
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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