Re: do we need CONFIG_UPROBES=y in our kernels?

[Marius Schwarz]

Am 15.02.24 um 23:09 schrieb Kevin Kofler via devel:

They should instead learn some basic concepts of security.
It's about trust in integrity of system encapsulated in something else 
which is disrupted.


From host to guest:  you need to trust the guest not to ... spam, scan, 
hack aso.
From guest to host:  you need to trust the host not to spy on you, your 
data, connection targets aso.


"not per se bad faith" kernel mechanics that can do that, do not help 
with trust. That's what the original author wanted to express, and here 
i agree.


My work would also suffer, if i could not just trace a process when i 
need to. On the other hand, I can imagine that hardening the system
against "espionage" can only help to gain that trust into computing and 
turn the lifes of some bad actors worse.


Having talked about it, is a good start.

conveniently read if they ever manage to compromise your computer. That
contraption is one of the first things I disable on my computers!


Agreed, for a more profane reason: it trashes the logfiles for 99.9+% of 
the time ;)


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

do we need CONFIG_UPROBES=y in our kernels?

[Marius Schwarz]

Hi,

I excuse myself if this has been already discussed, bastion ML server 
was blacklisted (has been removed btw).


Short summary(for details use the source link):

In a german developer blog article was the topic raised, that with 
uprobes enabled, userland apps can i.e. circumvent tls security(and 
other protections),
by telling the kernel to probe the function calls with the uprobes api. 
As this enables i.e. the hosting system of a vm or container, to track 
activity inside the container, trust is lost i.e. from customer to 
hoster. To be fair, you need to be root on the host to do this, but as 
it "wasn't possible before", and it is "now" ( out in a greater public 
), it tends to create trust issues, just for being there*.


As this only works with uprobes enabled and has no use case besides a 
developer debugging apps, the question is:


Do we need this for all others out there enabled by default?

If noone can name an app/lib that needs this outside of the C* 
development process, a change proposal would be wise. maybe adding a 
kernel boot argument switch?


Source: http://blog.fefe.de/?ts=9b3a23b2

*) You may not have a clue, what security auditors tell you about "a 
vulnerability & it's just there, but inexploitable". I had a case 2 
weeks ago, about a missing patch for the ssh-agent CVE vulnerability in 
fedora's openssh. Trust me, it will create trouble the more the topic is 
discussed in the pubic.



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

FYI: removal of bastion server in DNSBL spam.dnsbl.anonmails.de requested

[Marius Schwarz]

Hi,

as die Infrastructure ML did not react ( or could not react ;) ), I 
requested the removal at that antispam blacklist.


2024-02-11 05:20:16 H=bastion-iad01.fedoraproject.org 
(bastion.fedoraproject.org) [38.145.60.11] 
X=TLS1.3:TLS_AES_256_GCM_SHA384:256 CV=no 
F= rejected RCPT 
: found in spam.dnsbl.anonmails.de


I hope it gets removed soon.

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

Xen F37 destroyed it, grub2 from Fedora 30 needed to rescue it

[Marius Schwarz]

 how can it be prevented <==


I never found out what exactly happend!

C) How can the user nowadays update grub on disk, without moving it's 
partitions aside? ( which could not be possible regarding the age of the 
installationmedia or the setup)


I suggest to have a check ready, that detects this problem, and than 
uses a reduced amount of mods that's gets stored into "core.img".

(I have to assume, that is what caused this).

I had an old core.img ready, which would have worked, but it got moved 
aside to create a new, now too big core.img :(


I also suggest an option to grub2-install to force a small core.img.. If 
I do not need ZFS, why bothering about it? ( Just an Example )


D) Fix the output of grub2-install for an up2date mkimage process, the 
display output is obsolete for years.


A word about man pages: They are useless if they copy "cmd --help" .

It's this kind of problem, where you need infos, when a browser is not 
available, but you would need to search for answers.. guess what, that's 
what man pages are for ;) Guess what was no help, grub manpages :(


I hope we can improve the situation for others here by adding some safty 
checks and an rescue core.img mode .


best regards,
Marius Schwarz


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

time is running: security issue BZ#2241470

[Marius Schwarz]

Hi,

this is emerg ping for the security team, to take a look at this bz :

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

excuse me, for bringing this to the list, as a security bz is the way to 
go, but time is running fast and the patched release needs to be build 
and shipped in 36h hours from now.


The deadline for having a fix shipped is the afternoon of SUN, 1. of Oct 
2023 . On this date, the patches in upstream go public and exploits
will be developed for them. this impacts ALL of redhat based 
installations which run as servers and are publically reachable. The 
component in question is the default package for rh based installations.


best regards,
Marius Schwarz

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Access superseded Fedora RPMs

[Marius Schwarz]

Am 08.09.23 um 22:32 schrieb Michel Lind:

Try installing fedora-repos-archive -- you'll get a repo definition for
fedora-updates-archive, which has all versions of released updates
rather than just the latest.



Are you sure it's working?

[root ~]# dnf --enablerepo=updates-archive list firefox*
Letzte Prüfung auf abgelaufene Metadaten: vor 0:04:10 am Sa 09 Sep 2023 
09:39:57 CEST.

Installierte Pakete
firefox.x86_64 117.0-1.fc37 @@commandline
firefox-langpacks.x86_64 117.0-1.fc37 
@@commandline

Verfügbare Pakete
firefox-pkcs11-loader.x86_64 
3.13.6-8.fc37    fedora

firefox-wayland.x86_64 117.0-1.fc37 updates
firefox-wayland.x86_64 117.0-1.fc37 
updates-archive

firefox-x11.x86_64 117.0-1.fc37 updates
firefox-x11.x86_64 117.0-1.fc37 
updates-archive

[root ~]#

The Base URL accessed via firefox gives out an ACCESS DENIED. That may 
be intended, but isn't helpfull ;)


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

Re: firefox builds seem stuck on the farm - pls check

[Marius Schwarz]

Hi all,

Am 30.08.23 um 20:54 schrieb Kevin Fenzi:


Perhaps some folks could try building on an x86_64 vm and see if it
happens outside of koji?



The updates are not in the testing repo. They are now "just build". The 
usual workflow seems to be interrupted somehow.


best regards,
Marius Schwarz
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: CVE: Python-twisted a.o. needs update for F37 due to matrix-synapse security issue

[Marius Schwarz]

Am 30.08.23 um 20:44 schrieb Jonathan Steffan:
On Sat, May 27, 2023 at 3:45 AM Vitaly Zaitsev via devel 
 wrote:


On 26/05/2023 16:22, Marius Schwarz wrote:
> This brings me to the question: whats the main issue for twisted
here?

1. Contact python-twisted maintainers.


Marius,

According to the upstream matrix-synapse pyproject.toml the minimum 
requirement is met in F37: Twisted = {extras = ["tls"], version = 
">=18.9.0"} which is available in F37. Were you able to resolve this?
On the day F38 had the synapse update rdy, I used that package ( without 
a flaw yet ) to upgrade synapse to the f38 version on f37.


This brings up the question, what the really issue on f37 with the 
dependencies was, as those did not change at all. it just worked.


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

Re: firefox builds seem stuck on the farm - pls check

[Marius Schwarz]

Thanks Kevin,

Am 30.08.23 um 20:54 schrieb Kevin Fenzi:


Was there any changes from the last version that would increase
memory/cpu use? or have any issues building on a vm instead of a real
machine?

Perhaps some folks could try building on an x86_64 vm and see if it
happens outside of koji?




F37 X86_64 has finished and is already running here. Works fine. Can go 
to stable \o/


There seems to be no bohi entry, to give karma too yet.

best regards,
Marius



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

Re: firefox builds seem stuck on the farm - pls check

[Marius Schwarz]

Am 30.08.23 um 10:59 schrieb Peter Robinson:

On Wed, Aug 30, 2023 at 9:55 AM Martin Stransky  wrote:

On 8/30/23 10:51, Peter Robinson wrote:

The builds are here:

https://koji.fedoraproject.org/koji/packageinfo?packageID=37
So you mean all 3?

Yes.

Well I've freed the 3 x86 builds, I presume you didn't want the whole
lot just cancelled, please be more specific next time.
___



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

firefox builds seem stuck on the farm - pls check

[Marius Schwarz]

Hi,

as mozilla released the updates notes for ff 117, there are a lot of 
high impact security fixes for ff 117.


unfortunatly, the ff 117 builds on the farm seem stuck for 40+h , 
according to koji.


I informed  Martin, but can someone else take a look too, in case hes 
not available?


Thanks.

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

CVE: Python-twisted a.o. needs update for F37 due to matrix-synapse security issue

[Marius Schwarz]

Hi,

due to an outdated(afaik) python-twisted version, it's not possible to 
build matrix-synapse in version 1.8x .
Unlucky for all F37 users, matrix-synpase has 3 embargoed CVEs coming, 
which need fixing asap.


As "releng" has shipped the last twisted update, I have no clue who 
could help here on the python side and upgrade the packages.


Kai Hiller tries to cherry pick the required patches for synapse, but it 
would of course be better to build the newest

synapse version for F37 too.

ATM we can only workaround this by using the f38 packages for synapse 
and it's dependencies. AFAICT it's works without issues atm.

This brings me to the question: whats the main issue for twisted here?

best regards,
Marius Schwarz


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

Re: package WP-CLI needs update

[Marius Schwarz]

Am 20.04.23 um 11:01 schrieb Dan Horák:

On Thu, 20 Apr 2023 09:20:27 +0200
Marius Schwarz  wrote:


Hi,

package WP-CLI needs an update to 2.7.1 in all releases as in the
current state, it's useless.

A bugreport against the package is open since nov. 2022:

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

the maintainer hasn't been active in years if I see right, feel free to
take over the maintainership via
https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/



No big deal, besides, i need to get into the packager group first, 
therefor i need a sponsor afaik.


best regards,
Marius Schwarz
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: It’s time to transform the Fedora devel list into something new

[Marius Schwarz]

Am 21.04.23 um 01:34 schrieb Stephen Smoogen:


That said, I don't think I will be greatly active after the move. I 
have tried Discourse for a year, but have found it to be like every 
forum and BBS I have tried for the last 30 years.. frustrating and needy.


ACK.

- you do not see, what new answeres have arrived
- you need to open and login into it, everytime your browser gets started
- you need to actively look into any open TAB for any ML with theire own 
discourse-like-websolution

- you are required to work with tools that specific service offers
- "offline" breaks the workflow
- you need a shitload of traffic to archive the same result, as you can 
have with one single email.

- it takes longer to find something
aso. aso.

and best of all:

- you (multiply this with any participant) need way more cpu power (at 
home and on the server) to archive the same results => Which is bad for 
the climate!!!


Mails get concentrated in one place in an efficient way, with a short 
and easy workflow in one system, we all need to work on a day-by-day 
basis, or do you know anyone who can uninstall his/her mailapp after the 
Fedora ML has moved to Discourse? I don't think so.


If "you",reader, have problems following the threads with your mailapp, 
which was the main argument here, get a better mailapp to handle it.


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

package WP-CLI needs update

[Marius Schwarz]

Hi,

package WP-CLI needs an update to 2.7.1 in all releases as in the 
current state, it's useless.


A bugreport against the package is open since nov. 2022:

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


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

httpd 2.4.56 fixes CVE-2023-25690 (crit 9.8) and CVE-2023-27522 (high 7.5)

[Marius Schwarz]

Hi,

httpd 2.4.56 fixes CVE-2023-25690 (crit 9.8) and CVE-2023-27522 (high 
7.5) but Fedora packages do not name those fixes in the rpm changelog.


These kind of infos are important for admins to know, so it would be 
wise to always add them and not just write "new version".
Of course, this kind of info is vital for any kind of package, but just 
httpd. So, pls do not forget to add those informations.


2.4.56 has been put to stable already, nothing else to do here. Thanks.

best regards,
Marius Schwarz

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: FYI: boot issues with kernel 6.1.5+

[Marius Schwarz]

Am 16.01.23 um 08:37 schrieb Dominik 'Rathann' Mierzejewski:



Issues with nvidia driver init/usage detected.

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

Missing CONFIG_FB_EFI, apparently.

$ grep FB_EFI /boot/config-6.0.15-300.fc37.x86_64
CONFIG_FB_EFI=y
$ grep FB_EFI /boot/config-6.1.5-200.fc37.x86_64
# CONFIG_FB_EFI is not set

Regards,
Dominik


CONFIG_FB_VESA is not set either.

Best regards,
Marius Schwarz
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: FYI: boot issues with kernel 6.1.5+

[Marius Schwarz]

Am 15.01.23 um 22:35 schrieb Marius Schwarz:

Hi,

on Asrock 550B / Ryzen 5600X kernel 6.1.5 - 6.2.0 alpha are not 
booting, not even complaining about the irq vector bug in the firmware 
anymore, which happens extrem early. As it's not logging anything at 
that point, debugging will be a p.i.t.a .


Kernel 6.0.18 boots without any problems.



Issues with nvidia driver init/usage detected.

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

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

FYI: boot issues with kernel 6.1.5+

[Marius Schwarz]

Hi,

on Asrock 550B / Ryzen 5600X kernel 6.1.5 - 6.2.0 alpha are not booting, 
not even complaining about the irq vector bug in the firmware anymore, 
which happens extrem early. As it's not logging anything at that point, 
debugging will be a p.i.t.a .


Kernel 6.0.18 boots without any problems.

Best regards,
Marius Schwarz
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: split package cgnslib-common into ui and none-ui part

[Marius Schwarz]

Hi,

Am 08.12.22 um 11:05 schrieb Sandro Mani:

Hi

Like so?

https://koji.fedoraproject.org/koji/taskinfo?taskID=95082476

Sandro


I noticed, that parts of the content have been moved.

I can't do final judge on that package, as it still contains the desktop 
files and if refered by other app (OpenShot)
it will still get installed. But if those apps change theire 
dependencies, I thnik it will be perfect ;) Thanks.


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

split package cgnslib-common into ui and none-ui part

[Marius Schwarz]

Hi all,

the package "cgnslib-common" contains libs necessary to do some 
calculations i.e. Libreoffice

Openshot, Shotcut etc. etc.

It comes packed with some UI Apps, that look like something from the 
80ties and are most likely never used
as cgnslib-common is a just a dependency install and the apps are very 
special:


/usr/share/applications/cgnscalc.desktop
/usr/share/applications/cgnsnodes.desktop
/usr/share/applications/cgnsplot.desktop
/usr/share/applications/cgnsview.desktop
/usr/share/applications/unitconv.desktop

As I can image someone  could still make use of them, I suggest to split 
the package into the ui and none-ui parts.


This way, the depending apps are happy, and users do not get borrowed 
with apps they did not want and suddenly popped up

on theire app panel.

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

FYI: mutter + wayland are broken in F36 ATM

[Marius Schwarz]

Hi,

Mutter for Gnome 42.5.3 does not work with wayland for AST and Intel 
Graphics .

ATM, it ends in a black screen.

This involves M$ Surface devices, server onboard graphics and maybe more.

Workarounds for users are switching to lightdm or downgrading to mutter 
41.9-1.


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

best regards,
Marius





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

Re: Replacing GNOME Disks with Blivet GUI in comps' admin-tools?

[Marius Schwarz]

Am 09.10.22 um 05:17 schrieb Kevin Kofler via devel:


IMHO, we need a proper solution for the general comps issue rather than that
half-baked compromise that does not really improve the situation. KDE Plasma
users should get KDE applications by default everywhere.




On what criteria does the algorithm decide which package to install, if 
the system it should judge on,

has more than one DE installed?

Example:

I have 4 DEs installed: openbox, gnome, cinnamon and kde

Now the installing root user logs in via ssh and all the fantasies about 
reading out the used DE from the loggedin user become
null and void. To make it short: there is no 100% to be sure way to 
automatically decide what to install, except...


Solution:(Example)

admin-tools-kde
admin-tools-gnome
admin-tools-cinnamon
admin-tools-openbox
admin-tools-i3
...

with overlapping packagelists and DE dependend choices.

The installation requirements is than the fact, if the DE is installed 
or not.


best regards,
Marius Schwarz
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Marius Schwarz]

Am 20.09.22 um 22:53 schrieb Tommy Nguyen:

DNF5 is ridiculously fast. The new text output using the C++ fmt
library is also a bonus.


Yes, it's fast, which is a great improvement \o/ The new output format 
is ... debateable. It has advantages with "screen -x"-sessions with 
different resolutions,
but hardcore dnf fans will need to adapt to it. The old one was a bit 
simplier and had a more eased, not to say relaxed, flair ;)


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

FYI: livesys and livesys-late init.d files left over after Fedora installation

[Marius Schwarz]

Hi,

if Fedora 35 Liveimage is used to install Fedora, livesys and 
livesys-late initscripts are incorrectly copied onto the system

or not deleted after they lost their functionality.

This happens afterwards...

[Jul 5 17:01] systemd-sysv-generator[72798]: SysV service 
'/etc/rc.d/init.d/livesys' lacks a native systemd unit file. 
Automatically generating a unit file for compatibility. Please update 
package to include a native systemd unit file, in order to make it more 
safe and robust.
[  +0,26] systemd-sysv-generator[72798]: SysV service 
'/etc/rc.d/init.d/livesys-late' lacks a native systemd unit file. 
Automatically generating a unit file for compatibility. Please update 
package to include a native systemd unit file, in order to make it more 
safe and robust.
[  +0,368763] systemd-sysv-generator[72836]: SysV service 
'/etc/rc.d/init.d/livesys' lacks a native systemd unit file. 
Automatically generating a unit file for compatibility. Please update 
package to include a native systemd unit file, in order to make it more 
safe and robust.
[  +0,24] systemd-sysv-generator[72836]: SysV service 
'/etc/rc.d/init.d/livesys-late' lacks a native systemd unit file. 
Automatically generating a unit file for compatibility. Please update 
package to include a native systemd unit file, in order to make it more 
safe and robust.


afaik they don't do harm if not deleted.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Marius Schwarz]

Am 06.09.22 um 20:28 schrieb Ben Cotton:

* Removal of duplicated implementation
** LIBDNF evolved from LIBHIF (PackageKit library) and HAWKEY (DNF
library). The integration was never finished, therefore LIBDNF still
contains duplicated functionality.
** decrease of the code maintenance cost in future

* Unify Python bindings


If it's still written in python, it will still be slow on devices like 
Pinephones. I was under the impression, that microdnf + libdnf was 
developed to counter this slowness?


best regards,
Marius Schwarz

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Thunderbird 102 pushed to F36 stable

[Marius Schwarz]

Am 03.09.22 um 08:58 schrieb Mattia Verga via devel:

clearly happened here (pushed to stable just after 5 hours). I think
critpath updates should spend more time in testing, maybe we should
increase the critpath min karma to, at least, +5.



Judging from past critpath updates for several apps, I'm pretty sure, 
you won't get those many votes for both stable fedora releases.


bets regards,
Marius Schwarz

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Thunderbird 102 pushed to F36 stable

[Marius Schwarz]

Am 02.09.22 um 19:49 schrieb Mattia Verga via devel:

Here we go again: thunderbird 102 update was submitted to F36.

This new version was known to bring incompatible changes to several
addons, yet it has been submitted to a stable Fedora release with
autopush enable and just a karma threshold of 2. It took less than 5
hours from the time the update was submitted to the time the update was


and less than <24h for the first thunderbird 102 bugs to come in.

- addons not removeable
- safe-mode not working

I know it was a security update for 
https://www.mozilla.org/en-US/security/advisories/mfsa2022-38/ 
,

so better safe and live with some minor bugs, than to be sorry.

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

Rawhide: gnome-software: "not a public key" for F39 GPG Key

[Marius Schwarz]

Hi,

FYI:  AARCH64 rawhide produces this output every now and than ...

Aug 17 10:18:16 fedorapine gnome-software[1203]: failed to refresh the 
cache: PKI file 
/var/cache/PackageKit/38/metadata/rawhide-modular-rawhide-aarch64.tmp/RPM-GPG-KEY-fedora-39-aarch64 
is not a public key
Aug 17 10:18:16 fedorapine gnome-software[1203]: failed to refresh the 
cache: PKI file 
/var/cache/PackageKit/38/metadata/rawhide-modular-rawhide-aarch64.tmp/RPM-GPG-KEY-fedora-39-aarch64 
is not a public key


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

Re: Is system upgrade automatic or not?

[Marius Schwarz]

Hi,

Am 15.08.22 um 13:58 schrieb Stephen Smoogen:


I don't know of an Operating System which isn't a rolling operating 
system which works this way. MacOS, Windows, Debian, Ubuntu, Fedora 
all require a manual clickthru to get to the 'next' version which is 
available. This is because these updates are the most likely to fail 
and you need to usually put the system in a 'do not touch, alter, 
etc.' while this is going on. It is also most likely that the failure 
state is 'broken, reinstall.' or 'I need to change a lot of different 
things on here and you need to actually know what they do when I ask 
if you still want this'.




small report on the "should work" statement:

My daily used DesktopPC got installed as a Fedora 15 and is 
updated/upgraded with dnf every 6 months since.


Result: fully working Fedora with Ext4FS  and "next to no" issues on the 
way. I used the second cycle, means I upgrade from 34 to 35 if 36 gets 
released.

This helps a lot with upgrade issues.

"Next to no" means concrete:

it started after every upgrade
some minor updates in global configs had to be corrected once in a while 
(usual work after a major version change of an app)
had to install some "old" apps after they got auto-cleaned, but thats 
special software and only once in a while.


In the end, if you don't upgrade to the "latest" stable version of 
Fedora, you can expect to have a working system on every upgrade.



Best regards,
Marius Schwarz___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: rpmbuild is very slow with large files

[Marius Schwarz]

Am 13.07.22 um 16:30 schrieb John Reiser:

On 7/11/22 Marius Schwarz wrote:
I have just create(d/ not finished yet, started 15 minutes ago) a 
~2.5 GB rpm and found, that rpmbuild is an extrem bottleneck.


IMHO, this is caused by a fileread function which reads files in 32k 
blocks, which is very slow and extrem IO intensive.  The result is a 
task running at 1 core at 100% perma. With changes to larger chunks, 
we can speed up so many build tasks on the farm.


Multicore use would also be helpful i.e. while packing the files.

Any counter-arguments ?


If you give the complete package name and URL of the repo,
then more persons may be likely to help investigate.
Specifying a reproducible example is always good.



All issues solved for far.  Just to give you (all) an impression, here 
are source and result in my test repo:


3,2G    /usr/share/pva/vosk-model-de-0.21

[vosk-model-de-0.21]# du -sh *
100M    am
12K    conf
685M    graph
8,2M    ivector
4,0K    README
2,1G    rescore
281M    rnnlm

[rescore]# ll
insgesamt 2171812
-rw-r--r-- 1 root root 2115929988 14. Sep 2021  G.carpa <-
-rw-r--r-- 1 root root  107992138 14. Sep 2021  G.fst

So compressing this 2+ GB file (and others) was slowing down the process 
because of the one core compression default.


Building this now takes just ~4-5 minutes on 8 cores and a system doing 
other things in parallel.


Resulting in a 1.7 GB rpm :

-rw-r--r-- 1 root root 1758210157 14. Jul 09:44 
/home/linux-am-dienstagde/repo/x86_64/fedora/35/pva-vosk-model-de-large-1-2.x86_64.rpm


Luckily, not all vosk language models are not changing frequently and 
are not that big, but some are.


If this ever makes it into Fedora repo, it will take a lot of space and 
bind resources on builds ;)


@BCotton:

No idea, if you remember, but when i said it will waste 100gb + updates, 
in the last year, there were only a few updates to the languages models, 
reducing the expected needed space over time a lot.


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

Re: rpmbuild is very slow with large files

[Marius Schwarz]

Am 12.07.22 um 10:55 schrieb Marius Schwarz:


The rpmbuild process for this one rpm was single thread. With a 
lsof-loop,  I could see "bytes" getting attached to the resulting file 
with an awful slow progression rate. Which is very frustrating to see 
on a 8 core system.


The thing is, I do testbuilds of VOSK with language model and code 
etc. on one of my servers. If this project ever reaches the Fedora 
build farm,
we can expect a very long build time, if nothing is changed in 
rpmbuild. Is there maybe a hidden parallel compression option somewhere?




Looks like someone else had the same problem with rpmbuilds XZ single 
core compression:


https://insujang.github.io/2020-11-07/accelerating-ceph-rpm-packaging-using-multithreaded-compression/

|--define "_binary_payload w2T16.xzdio" |

|Question: Is the resulting compression format suitable for Fedora repo 
or a against a policy?|

||
|best regards,|
|Marius|
||

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

Re: rpmbuild is very slow with large files

[Marius Schwarz]

Am 12.07.22 um 09:47 schrieb Kamil Dudka:

On Tuesday, July 12, 2022 12:52:13 AM CEST Marius Schwarz wrote:

Multicore use would also be helpful i.e. while packing the files.

What do you mean by packing?  Creation of the resulting RPM packages?
I believe this phase already runs in parallel in case multiple RPM
packages are being created out of a single source RPM package.


"packing" aka "compression" .

The rpmbuild process for this one rpm was single thread. With a 
lsof-loop,  I could see "bytes" getting attached to the resulting file 
with an awful slow progression rate. Which is very frustrating to see on 
a 8 core system.


The thing is, I do testbuilds of VOSK with language model and code etc. 
on one of my servers. If this project ever reaches the Fedora build farm,
we can expect a very long build time, if nothing is changed in rpmbuild. 
Is there maybe a hidden parallel compression option somewhere?


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

Re: rpmbuild is very slow with large files

[Marius Schwarz]

Am 12.07.22 um 10:30 schrieb Miroslav Lichvar:

be selected by the kernel, or it could be a VM which doesn't have one
that would work with migrations, etc.


I think your right, it's a vm on xen base.

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

Re: rpmbuild is very slow with large files

[Marius Schwarz]

Am 12.07.22 um 09:26 schrieb Florian Weimer:

* Marius Schwarz:


I have just create(d/ not finished yet, started 15 minutes ago) a ~2.5
GB rpm and found, that rpmbuild is an extrem bottleneck.

IMHO, this is caused by a fileread function which reads files in 32k
blocks, which is very slow and extrem IO intensive.  The result is a
task running at 1 core at 100% perma. With changes to larger chunks,
we can speed up so many build tasks on the farm.

That's unlikely.  32K is not a small buffer size.

It's more likely that time is spent during compression.


In this case, a pigz , pbiz2 or other parallel compression mode, would 
be helpful.



strace shouldn't see a system call here because clock_gettime should be
handled in the vDSO.  This suggests something is wrong with the system
(unless it's some obscure variant that really doesn't have vDSO support).

Thanks,
Florian


it's a "normal" ( desktopless ) F 35 on a Xeon E5-2620v4 .

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

rpmbuild is very slow with large files

[Marius Schwarz]

Hi,

I have just create(d/ not finished yet, started 15 minutes ago) a ~2.5 
GB rpm and found, that rpmbuild is an extrem bottleneck.


IMHO, this is caused by a fileread function which reads files in 32k 
blocks, which is very slow and extrem IO intensive.  The result is a 
task running at 1 core at 100% perma. With changes to larger chunks, we 
can speed up so many build tasks on the farm.


Multicore use would also be helpful i.e. while packing the files.

Any counter-arguments ?

strace example:

[pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
tv_nsec=477601377}) = 0
[pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
tv_nsec=477685727}) = 0
[pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
tv_nsec=477892054}) = 0
[pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
tv_nsec=47876}) = 0
[pid 2604060] read(5, "_I @_I s_I t_E\nauss\303\244het 
auss\303\244h"..., 32768) = 32768
[pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
tv_nsec=478212651}) = 0
[pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
tv_nsec=478301347}) = 0
[pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
tv_nsec=478409015}) = 0
[pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
tv_nsec=478505273}) = 0
[pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
tv_nsec=478701366}) = 0
[pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
tv_nsec=478784826}) = 0

[pid 2604060] read(5, " Y_I k_I t_E\naustun austun 'aU_B"..., 32768) = 32768
[pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
tv_nsec=478962539}) = 0
[pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
tv_nsec=479045029}) = 0
[pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
tv_nsec=479130924}) = 0
[pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
tv_nsec=479213446}) = 0
[pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
tv_nsec=479407336}) = 0

[pid 2604060] clock_gettime(CLOCK_REAobjections
LTIME, {tv_sec=1657579222, tv_nsec=479489832}) = 0
[pid 2604060] read(5, "s_I v_I u:_I k_I s_I @_I s_E\naus"..., 32768) = 32768
[pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
tv_nsec=479720335}) = 0
[pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
tv_nsec=479803090}) = 0
[pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
tv_nsec=479950309}) = 0
[pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
tv_nsec=480067186}) = 0
[pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
tv_nsec=480305924}) = 0
[pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
tv_nsec=480417985}) = 0

[pid 2604060] read(5, "B s_I ts_I u:_I g_I R_I E_I n_I "..., 32768) = 32768
[pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
tv_nsec=480654716}) = 0
[pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
tv_nsec=480763606}) = 0


and I don't think, this tasks needs to read the clock that often too.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Bugzilla: You can't ask Lennart Poettering because that account is disabled.

[Marius Schwarz]

Am 03.07.22 um 04:02 schrieb Neal Gompa:

On Sat, Jul 2, 2022 at 8:52 PM Kevin Kofler via devel
 wrote:

Kevin Kofler via devel wrote:

The e-mail address reaches nowhere

or actually, does it still work? Have you tried it? I assume that the fact
that the Bugzilla account was disabled means he has left Red Hat and hence
the @redhat.com e-mail address has also become invalid, but I might be
mistaken.


That is what that means.


So, someone could cross check with the account db before setting the 
assignee and skip disabled accounts? If none is available, set QA as 
assignee, because it is part of QA to see, that bugreports are handled 
(not by the qa itself ofcourse).


Back to the actual problem: can someone grab that bug and handle it pls?

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

Re: Bugzilla: You can't ask Lennart Poettering because that account is disabled.

[Marius Schwarz]

Hi,

Am 02.07.22 um 10:37 schrieb Adam Williamson:


Probably not, no. Lennart hasn't maintained PA upstream or downstream
for a long time. The current downstream maintainer is Wim Taymans (I
think).



Can we change the defaults for PA inside bugzilla to Wim and transfer 
the open tickets to him?
it does not make sense to have Leonard as default assignee if the 
accoutn is disabled.


Best regards,
Marius

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

Bugzilla: You can't ask Lennart Poettering because that account is disabled.

[Marius Schwarz]

Hi,

I have some bug reports for PA opening BZ and only one ever got a response.

Is it possible that this is the cause:

You can't ask /Lennart Poettering / because that 
account is disabled.


I tried a needinfo request after a month long silence.

Short: PAVU shows the input meter at the app output tab since the 
upgrade from f34 to f35.

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

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

Re: RFI/RFC: Fedora Linux graphical recovery environment

[Marius Schwarz]

Am 31.03.22 um 23:38 schrieb Neal Gompa:

Hey all,

Earlier this week, the Fedora Workstation WG discussed a ticket
brought to us asking for a GUI-based rescue/recovery environment[1].
While we all agreed in principle that such a thing would be a very
good thing to have, we don't really know how to achieve such a thing.
Additionally, we're not really sure what the scope of things should be
provided in said recovery environment and what kind of things people
would expect to be able to fix in there.

So I come to y'all to ask about this and give us some feedback on the
idea, how to do it, and what kinds of things you expect people to need
a recovery environment for.


My suggestion, as i needed it last week:

Preinstall Qphotorec into a normal Fedora LiveDisk and put it in the 
autostart config.
The "do you want  to test Fedora or install it " requester could be 
removed, or extended for the third option "Recovery"


But, if you walk this path, you can add a fourth option rightaway, as 
requests will come in soon: "Do AVScan of System".


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

Re: CVE 9.8 rated httpd update stuck in updates-testing for a week

[Marius Schwarz]

Am 24.03.22 um 18:53 schrieb Adam Williamson:


It's been stuck for five days, not a week. After a week it will be



It's a crit update with security implications and needs that push to 
stable, when the basis tests have been finished ( 6 days ago btw ) . I 
know it had one automated test failed, but thats AFAICS just the 
filesize check from jenkins.


Can someone now pls push it?

Best regards,
Marius Schwarz




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

CVE 9.8 rated httpd update stuck in updates-testing for a week

[Marius Schwarz]

hi all,

the critpath update for httpd-2.4.53.fc34 is stuck in updates-testing. 
bodhi reports a pending test for this package.


https://bodhi.fedoraproject.org/updates/FEDORA-2022-21264ec6db

I can confirm, that i rolled out this update on my web->cluster<- and 
pages do still work. httpd test suite passed (php, ssl, static ). Pls 
push it to stable.



best regards,
Marius Schwarz

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

Re: FESCo wants to know what you use i686 packages for

[Marius Schwarz]

Am 16.03.22 um 14:54 schrieb David Cantrell:

If you use i686 packages for something now, please respond to this thread.


mainly for Wine 32 bit compatibility, which is still a think with 
windows-software today :(


Best regards,
Marius

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

security: pls push thunderbird update to stable

[Marius Schwarz]

Hi,

91.6.2. is working so far, but it's not available yet:


[marius@eve ~]$ sudo dnf  --showduplicates list thunderbird 
--enablerepo=updates-testing
Letzte Prüfung auf abgelaufene Metadaten: vor 0:00:33 am Di 08 Mär 2022 
17:29:24 CET.

Installierte Pakete
thunderbird.x86_64 *91.6.2-1.fc34 @@commandline*
Verfügbare Pakete
thunderbird.x86_64 78.8.1-2.fc34 fedora
thunderbird.x86_64 91.5.0-1.fc34 updates

please push the 91.6.2 build update to stable: possible Remote Code 
Execution


08.03.2022
Betroffene Systeme:
Mozilla Firefox < 97.0.2
Mozilla Firefox for Android < 97.3.0
Mozilla Firefox ESR < 91.6.1
Mozilla Thunderbird < 91.6.2
Zusammenfassung:
Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Mozilla 
Firefox, Mozilla Firefox
ESR und Mozilla Thunderbird ausnutzen, um beliebigen Programmcode auszuführen.

Quellen:
-https://www.mozilla.org/en-US/security/advisories/mfsa2022-09/
-https://ubuntu.com/security/notices/USN-5314-1
-https://lists.debian.org/debian-security-announce/2022/msg00057.html
-https://lists.debian.org/debian-lts-announce/2022/03/msg6.html

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

Re: unsafe systemd setup in Fedora

[Marius Schwarz]

Am 03.03.22 um 16:04 schrieb Rahul Sundaram:
What I would suggest here is we make it easier to adopt the opt out 
model by explicitly setting services to opt out for things they can't 
handle, ie) 


Honestly, I expected more of a wake-up-call to those service-maintainers 
(upstream/downstream) to make use of some basic security features.


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

Re: multiply revision of the same package in rawhide installation(s)

[Marius Schwarz]

Am 27.02.22 um 13:00 schrieb Zbigniew Jędrzejewski-Szmek:


Such duplicate packages usually happen when an upgrade is interrupted.
Are you sure you didn't have an upgrade fail at some point?


AFAIK, some failed, due to lack of free space, but all other run throu 
without errors, when they finally started.



Is there an easy way to find and erase the old packages reliable?

package-cleanup --cleandupes



Thx, 460 replaces happend after this cmd.

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

multiply revision of the same package in rawhide installation(s)

[Marius Schwarz]

Hi,

having run "rpm -qa | uniq -d -w 10 | sort " , I got some packages two 
or three times installed, and I'm not sure, that it is intended:


Device: pinephone ( rawhide )
Update Status: 2021-02-27 fully upgraded
rpm database: rebuild before running it

This could be caused by the process, how the release changes happen. I 
have run the same command on a system upgraded continuously from f15 to 
f34, I could not detect any doubles, except the kernel depending 
packages like kernel-core, nvidia etc. .


Is there an easy way to find and erase the old packages reliable?

An incomplete list:

geolite2-country-20191217-4.fc34.noarch
geolite2-country-20191217-5.fc35.noarch
geolite2-country-20191217-6.fc36.noarch

python3-gobject-base-3.42.0-1.fc36.aarch64
python3-gobject-base-3.42.0-3.fc36.aarch64

device-mapper-1.02.175-5.fc35.aarch64
device-mapper-1.02.175-6.fc35.aarch64

hunspell-en-GB-0.20140811.1-19.fc35.noarch
hunspell-en-GB-0.20140811.1-20.fc35.noarch
hunspell-en-GB-0.20140811.1-22.fc36.noarch

python-unversioned-command-3.10.1-1.fc36.noarch
python-unversioned-command-3.10.2-3.fc36.noarch

pkgconf-1.7.4-2.fc35.aarch64
pkgconf-1.8.0-1.fc35.aarch64
pkgconf-1.8.0-2.fc36.aarch64

filesystem-3.16-1.fc36.aarch64
filesystem-3.16-2.fc36.aarch64

onboard-data-1.4.1-25.fc35.noarch
onboard-data-1.4.1-26.fc36.noarch

ncurses-base-6.2-7.20210508.fc35.noarch
ncurses-base-6.2-8.20210508.fc35.noarch
ncurses-base-6.2-9.20210508.fc36.noarch

libXrender-0.9.10-14.fc34.aarch64
libXrender-0.9.10-15.fc35.aarch64
libXrender-0.9.10-16.fc36.aarch64

libX11-common-1.7.3.1-1.fc36.noarch
libX11-common-1.7.3.1-2.fc36.noarch

libkcapi-1.3.1-3.fc35.aarch64
libkcapi-1.3.1-4.fc36.aarch64

libcdio-2.1.0-4.fc34.aarch64
libcdio-2.1.0-5.fc35.aarch64
libcdio-2.1.0-6.fc36.aarch64

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

unsafe systemd setup in Fedora

[Marius Schwarz]

Hi Guys,

running a hardening tool I stumpled about systemd own security analysis,
which doesn't look good:


$ systemd-analyze security
UNIT EXPOSURE PREDICATE HAPPY
NetworkManager.service    7.8 EXPOSED   
abrt-journal-core.service 9.6 UNSAFE    
abrt-oops.service 9.6 UNSAFE    
abrt-xorg.service 9.6 UNSAFE    
abrtd.service 9.6 UNSAFE    
accounts-daemon.service   9.6 UNSAFE    
alsa-state.service    9.6 UNSAFE    
atd.service   9.6 UNSAFE    
auditd.service    8.7 EXPOSED   
avahi-daemon.service  9.6 UNSAFE    
chronyd.service   8.9 EXPOSED   
colord.service    8.8 EXPOSED   
crond.service 9.6 UNSAFE    
cups.service  9.6 UNSAFE    
dbus-:1.8-org.freedesktop.problems@0.service  9.6 UNSAFE    
dbus-broker.service   8.7 EXPOSED   
dm-event.service  9.5 UNSAFE    
emergency.service 9.5 UNSAFE    
fail2ban.service  9.6 UNSAFE    
fcoe.service  9.6 UNSAFE    
flatpak-system-helper.service 9.6 UNSAFE    
gdm.service   9.8 UNSAFE    
getty@tty1.service    9.6 UNSAFE    
irqbalance.service    6.2 MEDIUM    
iscsid.service    9.5 UNSAFE    
iscsiuio.service  9.5 UNSAFE    
libvirtd.service  9.6 UNSAFE    
lvm2-lvmpolld.service 9.5 UNSAFE    
mdmonitor.service 9.6 UNSAFE    
multipathd.service    9.5 UNSAFE    
network.service   9.6 UNSAFE    
nmb.service   9.6 UNSAFE    
nscd.service  9.6 UNSAFE    
ntpd.service  9.2 UNSAFE    
lines 1-35...skipping...
UNIT EXPOSURE PREDICATE HAPPY
NetworkManager.service    7.8 EXPOSED   
abrt-journal-core.service 9.6 UNSAFE    
abrt-oops.service 9.6 UNSAFE    
abrt-xorg.service 9.6 UNSAFE    
abrtd.service 9.6 UNSAFE    
accounts-daemon.service   9.6 UNSAFE    
alsa-state.service    9.6 UNSAFE    
atd.service   9.6 UNSAFE    
auditd.service    8.7 EXPOSED   
avahi-daemon.service  9.6 UNSAFE    
chronyd.service   8.9 EXPOSED   
colord.service    8.8 EXPOSED   
crond.service 9.6 UNSAFE    
cups.service  9.6 UNSAFE    
dbus-:1.8-org.freedesktop.problems@0.service  9.6 UNSAFE    
dbus-broker.service   8.7 EXPOSED   
dm-event.service  9.5 UNSAFE    
emergency.service 9.5 UNSAFE    
fail2ban.service  9.6 UNSAFE    
fcoe.service  9.6 UNSAFE    
flatpak-system-helper.service 9.6 UNSAFE    
gdm.service   9.8 UNSAFE    
getty@tty1.service    9.6 UNSAFE    
irqbalance.service    6.2 MEDIUM    
iscsid.service    9.5 UNSAFE    
iscsiuio.service  9.5 UNSAFE    
libvirtd.service  9.6 UNSAFE    
lvm2-lvmpolld.service 9.5 UNSAFE    
mdmonitor.service 9.6 UNSAFE    
multipathd.service    9.5 UNSAFE    
network.service   9.6 UNSAFE    
nmb.service   9.6 UNSAFE    
nscd.service  9.6 UNSAFE    
ntpd.service  9.2 UNSAFE    
nvidia-powerd.service 9.6 UNSAFE    
plymouth-start.service    9.5 UNSAFE    
polkit.service $ systemd-analyze security
UNIT  

Re: some dnf dependency quirks in rawhide?

[Marius Schwarz]

Am 06.02.22 um 22:43 schrieb Fabio Valentini:

On Sun, Feb 6, 2022 at 10:34 PM Marius Schwarz  wrote:

Hi,

deinstalling the rpmfusion package
"pulseaudio-module-bluetooth-freeworld", which should not be required by
anything:

[root@fedorapine ~]# rpm -q --whatrequires
pulseaudio-module-bluetooth-freeworld
Kein Paket benötigt pulseaudio-module-bluetooth-freeworld
(no package needs ... )

Looks like you fell into the trap of not considering "virtual provides".
The rpm query you pasted above only queries for exact matches, but not
for dependencies on virtual provides provided by the package of the
same name.


Yes, that may cause the missing output in rpm, but it wasn't the point 
of my post:


Why can a rpmfusion rpm be so deep "chained" into the tree, that it 
removes i.e. gnome-shell,
a major package from Fedora repo, which does not have even heared about 
that subpackage in rpmfusion.


if the "pulseaudio-module-bluetooth-freeworld" package has been 
installed independently from all those
(in the erase tree) additional considered packages, why can it trigger 
such a cascade? It is simply not important enough to cause this.
If it never had been installed, the functionality of all those apps 
would not change.


I want to understand, why this could happen. What caused this big 
cascade, if we add some unimportant part, noone needs to operate 
correctly?!?


I hope, i made myself clear this time ;)

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

some dnf dependency quirks in rawhide?

[Marius Schwarz]

Hi,

deinstalling the rpmfusion package 
"pulseaudio-module-bluetooth-freeworld", which should not be required by 
anything:


[root@fedorapine ~]# rpm -q --whatrequires 
pulseaudio-module-bluetooth-freeworld

Kein Paket benötigt pulseaudio-module-bluetooth-freeworld
(no package needs ... )

but when actually erasing the package, this happens:

[root@fedorapine ~]# dnf erase pulseaudio-module-bluetooth-freeworld
Abhängigkeiten sind aufgelöst.

 Package Architecture Version Repository Size

Entfernen:
 pulseaudio-module-bluetooth-freeworld aarch64 1.4-8.fc36 
@rpmfusion-free-rawhide 469 k

Abhängige Pakete werden entfernt:
 chrome-gnome-shell aarch64 10.1-15.fc36 @rawhide 61 k
 gnome-bluetooth aarch64 1:3.34.5-3.fc36 @rawhide 126 k
 gnome-classic-session noarch 42~alpha-2.fc36 @rawhide 233 k
 gnome-shell aarch64 42~alpha-3.fc36 @rawhide 9.9 M
 gnome-shell-extension-apps-menu noarch 42~alpha-2.fc36 @rawhide 23 k
 gnome-tweaks noarch 40.0-5.fc36 @rawhide 1.4 M
 nemo-gsconnect noarch 48-2.fc36 @rawhide 6.6 k
Nicht benötigte Abhängigkeiten werden entfernt:
 bluez-obexd aarch64 5.63-3.fc36 @rawhide 606 k
 bolt aarch64 0.9.2-1.fc36 @rawhide 527 k
 cheese-libs aarch64 2:41.1-2.fc36 @rawhide 2.5 M
 clutter-gst3 aarch64 3.0.27-7.fc36 @rawhide 262 k
 color-filesystem noarch 1-28.fc36 @rawhide 151
 colord aarch64 1.4.5-4.fc36 @rawhide 2.8 M
 colord-gtk aarch64 0.2.0-8.fc36 @rawhide 150 k
 cups-pk-helper aarch64 0.2.6-14.fc36 @rawhide 363 k
 firewalld-filesystem noarch 1.0.1-2.fc36 @rawhide 239
 freerdp-libs aarch64 2:2.4.1-2.fc36 @System 3.9 M
 freerdp-libs aarch64 2:2.4.1-3.fc36 @rawhide 3.9 M
 gdm aarch64 1:41.3-3.fc36 @rawhide 5.1 M
 gnome-bluetooth aarch64 1:3.34.5-2.fc35 @rawhide 126 k
 gnome-bluetooth-libs aarch64 1:3.34.5-2.fc35 @rawhide 1.1 M
 gnome-bluetooth-libs aarch64 1:3.34.5-3.fc36 @rawhide 1.1 M
 gnome-color-manager aarch64 3.36.0-6.fc35 @rawhide 3.4 M
 gnome-color-manager aarch64 3.36.0-7.fc36 @rawhide 3.4 M
 gnome-control-center aarch64 41.2-3.fc36 @rawhide 22 M
 gnome-keyring-pam aarch64 40.0-4.fc36 @rawhide 68 k
 gnome-remote-desktop aarch64 41.2-1.fc36 @rawhide 464 k
 gnome-remote-desktop aarch64 41.2-2.fc36 @rawhide 464 k
 gnome-session-wayland-session aarch64 41.3-2.fc36 @rawhide 15 k
 gnome-session-xsession aarch64 41.3-2.fc36 @rawhide 15 k
 gnome-settings-daemon aarch64 42~alpha-3.fc36 @rawhide 6.5 M
 gnome-shell-extension-common noarch 42~alpha-2.fc36 @rawhide 511 k
 gnome-shell-extension-gsconnect aarch64 48-2.fc36 @rawhide 1.1 M
 gnome-shell-extension-launch-new-instance noarch 42~alpha-2.fc36 
@rawhide 1.0 k

 gnome-shell-extension-places-menu noarch 42~alpha-2.fc36 @rawhide 21 k
 gnome-shell-extension-user-theme noarch 42~alpha-2.fc36 @rawhide 8.4 k
 gnome-shell-extension-window-list noarch 42~alpha-2.fc36 @rawhide 72 k
 gst-editing-services aarch64 1.20.0-1.fc36 @rawhide 2.5 M
 gupnp-av aarch64 0.14.0-2.fc36 @rawhide 352 k
 gupnp-dlna aarch64 0.12.0-2.fc36 @rawhide 547 k
 highcontrast-icon-theme noarch 3.28-13.fc35 @rawhide 4.2 M
 ibus aarch64 1.5.25-9.fc36 @rawhide 98 M
 ibus-gtk2 aarch64 1.5.25-9.fc36 @rawhide 68 k
 ibus-gtk3 aarch64 1.5.25-9.fc36 @rawhide 68 k
 ibus-libs aarch64 1.5.25-9.fc36 @rawhide 833 k
 ibus-setup noarch 1.5.25-9.fc36 @rawhide 243 k
 libmediaart aarch64 1.9.5-3.fc36 @rawhide 104 k
 libnma aarch64 1.8.32-1.fc36.4 @rawhide 1.2 M
 libnma aarch64 1.8.34-1.fc36.1 @rawhide 1.2 M
 libpciaccess aarch64 0.16-6.fc36 @rawhide 73 k
 libvncserver aarch64 0.9.13-11.fc35 @rawhide 1.0 M
 libvncserver aarch64 0.9.13-12.fc36 @rawhide 1.0 M
 libwinpr aarch64 2:2.4.1-2.fc36 @System 1.2 M
 libwinpr aarch64 2:2.4.1-3.fc36 @rawhide 1.2 M
 libxcvt aarch64 0.1.1-2.fc36 @rawhide 71 k
 mutter aarch64 42~alpha-3.fc36 @rawhide 13 M
 nm-connection-editor aarch64 1.24.0-1.fc36.1 @rawhide 4.5 M
 power-profiles-daemon aarch64 0.10.1-3.fc36 @rawhide 122 k
 rygel aarch64 0.40.3-1.fc36 @rawhide 5.0 M
 setxkbmap aarch64 1.3.2-5.fc36 @rawhide 71 k
 switcheroo-control aarch64 2.4-5.fc36 @rawhide 142 k
 xdg-user-dirs-gtk aarch64 0.10-22.fc36 @rawhide 235 k
 xmodmap aarch64 1.0.10-3.fc36 @rawhide 76 k
 xorg-x11-drv-libinput aarch64 1.2.1-1.fc36 @rawhide 141 k
 xorg-x11-server-Xorg aarch64 1.20.14-4.fc36 @rawhide 4.0 M
 xorg-x11-server-Xwayland aarch64 22.0.99.902-1.fc36 @rawhide 2.2 M
 xorg-x11-server-common aarch64 1.20.14-4.fc36 @rawhide 127 k
 xrdb aarch64 1.2.1-3.fc36 @rawhide 75 k

Transaktionsübersicht

use of kernel/yama/ptrace_scope in rpm scriptlets

[Marius Schwarz]

Happy New Year everyone,

noticed on device: Pinephone

At least since early last year, most likely much longer, rpm scriptlets 
report this message:


Couldn't write '0' to 'kernel/yama/ptrace_scope', ignoring: No such file 
or directory


Can the one responsible please add some sort of check to the scriptlet:

if [ -e "..kernel/yama/ptrace_scope" ]; then
  echo "0" > ..kernel/yama/ptrace_scope
fi

or, as it seems to be an irrelevant message, use > /dev/null ?

I would really like to help out with such small stuff, when I'm allowed 
in the maintaier/packager gang ;)



best regards,
Marius

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

Re: Advise needed: guideline for very big data rpms?

[Marius Schwarz]

Am 26.12.21 um 20:51 schrieb Matthew Miller:


Marius, are the different language packs updated continually and separately,
or is there one versioned set of all of them released at intervals? Is it a
case where everything is regenerated, or are additions incremental? (And do
they _replace_ or just add?)


The language files are seperate for any language. They do not update 
together.


It more the massive amount of storage space in total that worries me.

The first release would be less than 40G, that was just a size the 
entire project will reach easily, if it grows

like it did in the past.


It does seem like it'd be nice to have a way to deliver (officially from
Fedora in a way that can be shipped in Spins and containers) static files
that don't change, without needing to redownload gigabytes on upgrade. Of
course, delta RPMs are one way, but need a lot of investment in actually
working again. Ostree deltas are another — and maybe upcoming work on
container deltas could be helpful.


I don't see a way to reduce the update size, as it mostly one big file:

[marius@eve ~]$ ll /usr/share/pva/vosk-model-de-0.21/
insgesamt 28
drwxr-xr-x. 2 marius marius 4096 21. Aug 2020  am
drwxr-xr-x. 2 marius marius 4096  2. Aug 2020  conf
drwxr-xr-x. 3 marius marius 4096  9. Aug 2020  graph
drwxr-xr-x. 2 marius marius 4096 21. Aug 2020  ivector
-rw-r--r--. 1 marius marius  740 15. Sep 00:21 README
drwxr-xr-x. 2 marius marius 4096  9. Aug 2020  rescore
drwxr-xr-x. 2 marius marius 4096 15. Sep 00:14 rnnlm
[marius@eve ~]$ du -sh  /usr/share/pva/vosk-model-de-0.21/*
100M    /usr/share/pva/vosk-model-de-0.21/am
12K /usr/share/pva/vosk-model-de-0.21/conf
685M    /usr/share/pva/vosk-model-de-0.21/graph
8,2M    /usr/share/pva/vosk-model-de-0.21/ivector
4,0K    /usr/share/pva/vosk-model-de-0.21/README
2,1G    /usr/share/pva/vosk-model-de-0.21/rescore
281M    /usr/share/pva/vosk-model-de-0.21/rnnlm
[marius@eve ~]$ ll /usr/share/pva/vosk-model-de-0.21/rescore/
insgesamt 2171812
*-rw-r--r--. 1 marius marius 2115929988 14. Sep 20:58 G.carpa*
-rw-r--r--. 1 marius marius  107992138 14. Sep 20:50 G.fst



(And... I think it'd be useful in a lot of cases to be able to do dist-git
-> container without needing to build RPMs as an intermediate step. But...
that's not a thing we have now.)



As far as I understand the packaging rules, autodownloaders are not welcome,
and for security reasons, i absolutly support this.

We could downsize the problem at the beginning, because there are no 
voice commands ready for other languages, so it does not make sense to
have the language models around. I really hope the project gets a kick 
start once the first people use. it's quite easy to write a set of commands
and get it running. I suggest a nice feature in the fedora magazin about 
a working assistent for fedora.


So at the beginning, we talk about 2-4 GB for german and english. the 
pva itself  isn't that storage hungry, a mb at best. A few vosk deps 
here and there:

~100mb uncompressed maybe.

For now, I'm rebuilding the compile process against our fedora libs, so 
we can ship the required packages for kaldi & vosk. The required libs 
shipped with Fedora are older than the actual ones used by vosk devs, 
which is a problem.


With pip as source for vosk, it works as expected, but the local vosk & 
kaldi builds do not yet work :(


best regards,
Marius





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

Advise needed: guideline for very big data rpms?

[Marius Schwarz]

Hi,

for a new project hopefully coming to soon to Fedora,  I like to know 
the policy for really big data rpms.


The project could offer 18 language files for a voice recognition 
system, which is ( unpacked ) up to 2.4 GB each and packed upto around 
1.6~1.8 GB each.

+ 18 small ones ~50-60 MB each.

So round about, we are talking about 40 GB just for those language packs 
just for the first release + a lot more for new updates per Fedora 
version, and those packages grow constantly over time. Of course, users 
do not need all of them at the same time, but they should be available.


Is this a valid scenario for the Fedoraproject or would this be a nogo?

Best regards,
Marius Schwarz

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

inconsistent installprocess between spins

[Marius Schwarz]

Hi,

i just noticed, that the gnome main image and the cinnamon spin image 
offering different install options.


Gnome does not ask or allow to set the root user account / password, 
while the cinnamon spin does offer this option.


Shouldn't "Fedora" Images be consitent here?

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

Re: Fedora 35 - gedit

[Marius Schwarz]

Am 09.11.21 um 10:13 schrieb Michael J. Baars:

Hi All,

I've been working with Fedora for years now, and I just installed the newest 
Fedora Workstation 35 on one of my computers.

Since I use gedit a lot for editing source codes, gedit was one of the first 
programs I tried to launch. Now, there I get into trouble. After opening a few
source files and trying to start off where I left, I noticed that the mouse 
pointer (and the line number) often does not end up where I clicked the mouse 
when
trying to position the cursor (for cutting and pasting for example). This is 
the very first time that I experience this problem.



I just checked this with Fedora 35 Live Image and I can't reproduce this 
even with big 500k+ textfiles.


Could you pls start your pc via the actual Liveimage and try to 
reproduce this on our hw?


Best regards,
Marius Schwarz

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

Re: deltarpm usefulness?

[Marius Schwarz]

Am 11.08.21 um 22:03 schrieb Marek Marczykowski-Górecki:

- there is also argument that people's connection bandwidth nowadays
tends to be fast enough to make the package rebuilding actually
slower than downloading the whole package (but that really vary between
different installations)


Since we now have Linux on smartphonesd, i heavily disagree with this 
assumption and advocate to expand the drpm usage.


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

Fedora 35 Liveimage needs an update

[Marius Schwarz]

Hi,

On the first test of F35 Livedisk we found a Bug in "gnome-connections".

According to:

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

this has been fixed. So the liveimage needs an update, that people 
interessed in F35 do no longer get a buggy version when they download 
it. I'm able to verifiy this, in case the liveimage team wants it tested.



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

Re: Pipeware issue in KDE after F34->F35

[Marius Schwarz]

Am 19.10.21 um 17:44 schrieb Miroslav Suchý:


Any hints, please?



JFYI, pipewire has been replaced by pulseaudio on the Fedora Pinephone 
Edition, because pipewire had issues with profile switching, which 
pulseaudio does not have. We also had missing audio devices, which was 
an interaction between alsa and pipewire.


Try to swap pipewire-pulseaudio with pulseaudio package and recheck your 
issue.


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

Re: Fedora minimum hardware requirements

[Marius Schwarz]

Am 17.10.21 um 22:31 schrieb Robby Callicotte via devel:

On Sunday, October 17, 2021 3:05:13 PM CDT Dan Čermák wrote:

They are also much more intuitive to use for your average user/ newcomer
to Linux in contrast to a text interface (which will put them off when
compared to the Windows or Ubuntu installer). Yes, a text interface is
much more resource friendly, but imho that will cause more harm than
actual benefit.

I totally agree.  If presented with only a text interface, I believe that new
Linux users would perceive the install experience as either too daunting or
not up to par with other distros.




I think the real reason of my posting got out of sight:

it's not about how big the Installation Medium aka. iso-file is,
it's how much stuff lands on the disk after the os is installed.

Of course Fedora primary target is the desktop PC with lots of diskspace 
and ressources.


In case of the IoT mobility fraction, diskspace is limited and a 20 GB 
os is not desireable nor really useable on a phone.


i.E. all of the firmwarefiles are unneeded, no grub, no uefi, no 
printersupport, no wacom-artpadsupport, no colormanagementdemons,
and a lot of nice apps for a desktop, but not so practical on a phone 
i.e. Rythembox are not even the worst things. A "du -sh" showed a huge 
lot of libs on the system /usr was 2.5g alone.  All those icons sets, 
fonts etc.etc. took a lot of space.  journald has no default maxsize, 
and it does not really help, when pkcon generates it's on caches besides 
DNF ones.


The mobility has thrown out a lot of packages we don't need here, but 
thats only a fraction of what could go IMHO. Some folks helped to 
identify unneeded packages, but a real mininal image in sense of used 
diskspace, is something else, I think .


IF, like in the dark ages of linux, a list exists of "needed for the os 
to run" and "os can function without it" would exist, we could throw out 
so much more.


ATM, i still see a long way to go for Linux on Phones, but Android 
didn't do it overnight either.


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

Re: Fedora minimum hardware requirements

[Marius Schwarz]

Am 14.10.21 um 22:09 schrieb Zbigniew Jędrzejewski-Szmek:

I think that those numbers (20GB+2GB) are quite reasonable for the
stated purpose of "install and run successfully". I think that people

The smallest device Fedora runs on, will propably be the Pinephone.

ATM..it has 3 GB Ram and a 32 GB storage. A 20 GB base install + taking 
journald logsizes into account,

gives 8 GB of usable space.

I think any new reevaluation of "minimum" should really take mobil 
devices  into account.


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

Re: RH Bugzilla extrem slow loading at enter_bug.cgi for Fedora

[Marius Schwarz]

Am 15.09.21 um 14:38 schrieb Miro Hrončok:

On 10. 09. 21 18:50, Marius Schwarz wrote:

Hi,

since a few days, loading the enter_bug.cgi for "Product=Fedora" on 
RH BZ takes very long.

It's quite possible, that it's happening for any other product too ;)

It's over a minute ATM.


I have the same problem. have you contacted the RH bugzilla admins or 
should I do that?



Update:

Under first impression, the amount of components in Fedora makes it 
slow, as other BZ "Products" are loading as expected.


For anyone interessted, it's now a bug:

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

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

Re: RH Bugzilla extrem slow loading at enter_bug.cgi for Fedora

[Marius Schwarz]

Am 15.09.21 um 14:38 schrieb Miro Hrončok:

On 10. 09. 21 18:50, Marius Schwarz wrote:

Hi,

since a few days, loading the enter_bug.cgi for "Product=Fedora" on 
RH BZ takes very long.

It's quite possible, that it's happening for any other product too ;)

It's over a minute ATM.


I have the same problem. have you contacted the RH bugzilla admins or 
should I do that?



RH Admins are on it .. no results yet.

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

Heads-Up: Matrix clients need urgent update

[Marius Schwarz]

Hi,

Fedora is offering a range of different native Matrix clients. I suggest 
to have an eye open on monday for related maintainers:



2021-09-10 — Security <https://matrix.org/blog/category/security> 
— Matrix Security


Hi all,

A critical security vulnerability impacting several popular Matrix 
clients and libraries was recently discovered. A coordinated security 
release of the affected components will be happening in the afternoon 
(from an UTC perspective) of *Monday, Sept 13th*.


We will be reaching out to downstream packagers to ensure they can 
prepare patched versions of affected packages at the time of the 
release. The details of the vulnerability will be disclosed in a blog 
post on the day of the release. There is so far no evidence of the 
vulnerability being exploited in the wild.


*Please be prepared to upgrade as soon as the patched versions are 
released.*


Thank you for your patience while we work to resolve this issue.


Source: 
https://matrix.org/blog/2021/09/10/pre-disclosure-upcoming-critical-fix-for-several-popular-matrix-clients



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

RH Bugzilla extrem slow loading at enter_bug.cgi for Fedora

[Marius Schwarz]

Hi,

since a few days, loading the enter_bug.cgi for "Product=Fedora" on RH 
BZ takes very long.

It's quite possible, that it's happening for any other product too ;)

It's over a minute ATM.

Can someone take a look at this, or do i need to contact rh's adminteam?

best regards,
Marius Schwarz

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

Re: F35 3x slower boot than F34

[Marius Schwarz]

Am 03.09.21 um 18:51 schrieb Chris Murphy:

Bug 2001057 - F35 boots 3x slower than F34, large time gaps in systemd journal
https://bugzilla.redhat.com/show_bug.cgi?id=2001057


This one really has gotten my goat. I'm not finding any reason why
it's taking this long to boot. Usually the critica-chain or svg plot
exposes the culprit but not in this case, I just have multiple 10s+
gaps in the journal.

I might have to do some tedious regression testing by doing a clean
install of 35 to see if it's some artifact of upgrading from 34. But
it'd be nicer if I can just directly expose the culprit(s).



Any updates on this?

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

Re: Request: Speedup of Firefox 92 buildprocess / CERT messages gone public

[Marius Schwarz]

Am 08.09.21 um 17:28 schrieb Leigh Scott:

None of those issue affect Linux, they only affect Windows and Android.



Good to know.

As it seems, the buildprocess of FF has gone stuck yesterday. maybe 
someone here can restart it?


Best regards,
Marius Schwarz

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

Request: Speedup of Firefox 92 buildprocess / CERT messages gone public

[Marius Schwarz]

Hi,

all FF 92 buildprocesses are still running, unfortunatly the messages 
about RCE Exploits have already gone public.


If possible, speed things up.

Thunderbird 91.1 got ready in time, but is stuck in the testrepo. I 
suggest to emerg push them to stable.

TB 91.1 FC 33 as been tested and is working in acceptable condition.


References:

https://www.mozilla.org/en-US/security/advisories/mfsa2021-38/
https://www.mozilla.org/en-US/security/advisories/mfsa2021-39/
https://www.mozilla.org/en-US/security/advisories/mfsa2021-40/
https://www.mozilla.org/en-US/security/advisories/mfsa2021-41/
https://www.mozilla.org/en-US/security/advisories/mfsa2021-42/

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

Re: ansible-pcp package contains placeholder in update notification

[Marius Schwarz]

Am 03.09.21 um 10:37 schrieb Petr Pisar:
 


Fedora Update Notification
FEDORA-2021-2b65aac5d5
2021-09-02 23:52:43.161269


Name : ansible-pcp
Product : Fedora 33
Version : 2.2.1
Release : 1.fc33
*URL : %{ansible_collection_url}*
Summary : Ansible Metric collection for Performance Co-Pilot


Where did you get this message from? The URL value in the package as
downloadable from
 is fine. Was
is an output of a DNF command? Which command exactly?



No, from the message send to "package-annou...@lists.fedoraproject.org".

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

ansible-pcp package contains placeholder in update notification

[Marius Schwarz]

just noticed:


Fedora Update Notification
FEDORA-2021-2b65aac5d5
2021-09-02 23:52:43.161269


Name : ansible-pcp
Product : Fedora 33
Version : 2.2.1
Release : 1.fc33
*URL : %{ansible_collection_url}*
Summary : Ansible Metric collection for Performance Co-Pilot



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

problem to compile fedora kernel: BTF/pahole

[Marius Schwarz]

Hi,

while trying to recompiling  fedora 5.12.17 kernel, I got a final error:

scripts/link-vmlinux.sh: Line 214: 273523 Killed 
LLVM_OBJCOPY="${OBJCOPY}" ${PAHOLE} -J ${1}


"dwarves" is installed, so this should not happen.

The config file is taken from /boot/ and adjusted via "make menuconfig" 
to use GZIP compression instead of libstd. Besides this, no other changes

are done.

# make bzImage
.. message that pahole is missing ..
# dnf -y install dwarves

# make bzImage
  CALL    scripts/checksyscalls.sh
  CALL    scripts/atomic/check-atomics.sh
  DESCEND  objtool
  DESCEND  bpf/resolve_btfids
  CHK include/generated/compile.h
  GEN .version
  CHK include/generated/compile.h
  UPD include/generated/compile.h
  CC  init/version.o
  AR  init/built-in.a
  LD  vmlinux.o
  MODPOST vmlinux.symvers
  MODINFO modules.builtin.modinfo
  GEN modules.builtin
  LD  .tmp_vmlinux.btf
  BTF .btf.vmlinux.bin.o
scripts/link-vmlinux.sh: Zeile 214: 273523 Getötet 
LLVM_OBJCOPY="${OBJCOPY}" ${PAHOLE} -J ${1}

  LD  .tmp_vmlinux.kallsyms1
  KSYMS   .tmp_vmlinux.kallsyms1.S
  AS  .tmp_vmlinux.kallsyms1.S
  LD  .tmp_vmlinux.kallsyms2
  KSYMS   .tmp_vmlinux.kallsyms2.S
  AS  .tmp_vmlinux.kallsyms2.S
  LD  vmlinux
  BTFIDS  vmlinux
FAILED: load BTF from vmlinux: No such file or directory
make: *** [Makefile:1207: vmlinux] Fehler 255

Used: dwarves-1.21-1.fc33

Any ideas why this is happening?

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

Re: Preventing supply chain attacks via rekor

[Marius Schwarz]

Am 12.06.21 um 02:51 schrieb Kevin Fenzi:



Also, not having it available has made it *very* hard to prioritize
getting the issues fixed in DNF. So being able to improve this is
predicated on the existence of signed metadata.

This seems odd to me. I mean, it can't be hard to setup a test repo, is
it? I suspect we could even ask QE folks to do some testing and map out
the issues they find. I don't think it's nice/ethical to break users
just as a means to make bugs we want to have fixed higher priority.

Anyhow, we are pretty off topic for this thread, so I'll try and stop...

kevin



Does it really hurt someone, if the repos get signed and clients just do 
not check this by default?


Of course, the signing should not break the unchecked repo in any form, 
which needs a small testcase ;)



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

Re: The future of legacy BIOS support in Fedora.

[Marius Schwarz]

Am 30.06.20 um 15:34 schrieb Jóhann B. Guðmundsson:
Given Hans proposal [1] introduced systemd/grub2/Gnome upstream 
changes it beg the question if now would not be the time to stop 
supporting booting in legacy bios mode and move to uefi only supported 
boot which has been available on any common intel based x86 platform 
since atleast 2005.


Now in 2017 Intel's technical marketing engineer Brian Richardson 
revealed in a presentation that the company will require UEFI Class 3 
and above as in it would remove legacy BIOS support from its client 
and datacenter platforms by 2020 and one might expect AMD to follow 
Intel in this regard.


This will fail i.e. on M$ Surface Pro * systems.

Also, a lot of laptops are installed in Legacy Mode, as setting them up 
in EFI was impossible.



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

FYI: F32 Calf packages seem to be outdated

[Marius Schwarz]

Hi,

Calf packages seem to need some attention:

 Problem 1: package calf-0.90.3-6.fc32.x86_64 requires 
libfluidsynth.so.1()(64bit), but none of the providers can be installed
  - cannot install both fluidsynth-libs-2.1.8-3.fc32.x86_64 and 
fluidsynth-libs-1.1.11-7.fc32.x86_64
  - cannot install both fluidsynth-libs-1.1.11-7.fc32.x86_64 and 
fluidsynth-libs-2.1.8-3.fc32.x86_64
  - cannot install the best update candidate for package 
fluidsynth-libs-1.1.11-7.fc32.x86_64
  - cannot install the best update candidate for package 
calf-0.90.3-6.fc32.x86_64
 Problem 2: package lv2-calf-plugins-0.90.3-6.fc32.x86_64 requires calf 
= 0.90.3-6.fc32, but none of the providers can be installed
  - package calf-0.90.3-6.fc32.x86_64 requires 
libfluidsynth.so.1()(64bit), but none of the providers can be installed
  - cannot install both fluidsynth-libs-2.1.8-3.fc32.x86_64 and 
fluidsynth-libs-1.1.11-7.fc32.x86_64
  - cannot install both fluidsynth-libs-1.1.11-7.fc32.x86_64 and 
fluidsynth-libs-2.1.8-3.fc32.x86_64
  - package fluidsynth-2.1.8-3.fc32.x86_64 requires 
libfluidsynth.so.2()(64bit), but none of the providers can be installed
  - package fluidsynth-2.1.8-3.fc32.x86_64 requires 
fluidsynth-libs(x86-64) = 2.1.8-3.fc32, but none of the providers can be 
installed
  - cannot install the best update candidate for package 
lv2-calf-plugins-0.90.3-6.fc32.x86_64
  - cannot install the best update candidate for package 
fluidsynth-1.1.11-7.fc32.x86_64



the latest build is for F34 only. The F33 version of Calf solves the 
problem:


Workaround: sudo dnf update calf --releasever=33

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

Re: Fedora 33 and 34 Workstation images not booting in Hyper-V

[Marius Schwarz]

Am 11.04.21 um 07:27 schrieb Patrick Lang:
I just did a quick test with Fedora 34 beta on Hyper-V on Windows 10 
version 2009, build 19042. These settings should work on Windows 
Server 2016 and later too as far as I know. The live boot and install 
worked as usual.


The hyperv_fb driver defaults to 1024x768, but you can change the 
resolution after you install. I put those steps in the same gist.


Hyper-V example setup for Fedora 34 (github.com) 
<https://gist.github.com/PatrickLang/03dcda94a93b8b2960aa41c29ded057f>




I checked it again with all the suggested changes, Fedora 34 Beta bootet 
like a charm.


Windows Server 2019  Hyper-V  MNC Build 1809

The lack of 3D hardware is mention when using Cinnamon
and a gnome crash in the gnome-init-setup are the only "problems" so far.

A reboot later  gnome-init-setup finished successfully.

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

Re: Fedora 33 and 34 Workstation images not booting in Hyper-V

[Marius Schwarz]

Am 09.04.21 um 23:03 schrieb Patrick Lang:


Yes, that’s the right setting for secure boot on Linux. Fedora, 
Ubuntu, and probably more distros use that setting. There is a list of 
distros that support secure boot here: Supported Linux and FreeBSD 
virtual machines for Hyper-V on Windows | Microsoft Docs 



The default template is “Microsoft Windows” which only allows the MS 
signing certificate.


If you run into other issues related to Hyper-V, feel free to file 
bugs and mention me on them. I use it frequently.





Thanks Patrick and Stephen, checking it next week.


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

Re: Fedora 33 and 34 Workstation images not booting in Hyper-V

[Marius Schwarz]

Am 09.04.21 um 20:58 schrieb Stephen John Smoogen:



On Fri, 9 Apr 2021 at 14:34, Marius Schwarz <mailto:fedora...@cloud-foo.de>> wrote:


Hi,

I had the chance check Fedora Workstation Images F33 + F34 Beta  on a
brandnew Windows Server with Hyper-V latest.


I am able to boot Fedora 33 and Fedora 34 beta iso's on Hyper-V 
Manager 10.0.19041.1 but I don't know if you could also and you are 
talking post-install or something else.


I did un-check the 'This machine is running WIndows' button which 
turns off Secure Boot.


I had choosen "64bit machine only" , selected 4 GB Ram, selected the iso 
image to boot from and run it.


The result was a screen with hyper-V logo and a text, to press a key 
combination to boot pxe ( or something similar ) and no further activity.


As it's not my Windowsserver I don't now the exact version. System was 
updated to latest yesterday. I will ask, if i can recheck it next week,

which will give us the version of hyper-v too.

Best regards,
Marius


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

Fedora 33 and 34 Workstation images not booting in Hyper-V

[Marius Schwarz]

Hi,

I had the chance check Fedora Workstation Images F33 + F34 Beta  on a 
brandnew Windows Server with Hyper-V latest.


Both are not booting, not even grub showing up.

There is no error message visible, so I can't supply you any more infos.

The only additional info i can offer is the fact, that the fedora 33 
workstation image has also problems with the Surface Pro 4 Bios,
it only boots from usb after some wired timed usb drive inserting-> bios 
forced boot override.


The diagnosis with the pro 4 was, that it would need a bios update, but 
as hyper-v does not boot the image too, maybe it's not the M$ bios thats 
defective.


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

very slow boot process with F33 caused by mysql entry in nssswitch.conf

[Marius Schwarz]

Hi,

#        worked in F31
# caused problems in F33

I upgraded a system from F31 to F33 via dnf distro-sync and it did boot 
extrem slow.


A systemd.debug-shell=1 && strace of systemd-tmpfiles later, it looked 
like a massive resolve problem,
as next to any step from  the tmpfiles process created at least 2 dns 
lookups.


ls -la /dev/ took round about 20 seconds, also creating dns lookups.

Due to the dns lookuped hostname I could nail it down to having "mysql" 
to nsswitch.conf  like this:


passwd:  mysql files systemd
shadow:  mysql files
group:   mysql files systemd

System takes up to *10 Minutes* to boot due to massive failing dns 
resolve calls for the configured mysql auth servername when enabled, 
when removed it boots in seconds.


>> The same config did not cause delays on F31.  <<

As this config is needed to do an enterprise like login schema based on 
mysql, I think the order of starting services and sockets needs a 
correction.


Can someone involved in Systemd take a look at it?

Those two processes are the only ones running besides pid 1, when the 
problem hits the boot process, which starts at switchroot() to the real 
sysroot:


|- .. root bash tty 9
|- systemd-tmpfiles
'- systemd-journald

the mysql server is ofcourse a remote server, otherwise it would not 
make any sense to use this , but it would not matter due to the lack of 
network at this point.


libnss-mysql.cfg looks like this, just to give an impression of what 
needs to go on:


$ cat /etc/libnss-mysql.cfg

getpwnam    SELECT username,'x',uid,gid,name,homedir,shell \
    FROM users \
    WHERE username='%1$s' \
    LIMIT 1
getpwuid    SELECT username,'x',uid,gid,name,homedir,shell \
    FROM users \
    WHERE uid='%1$u' \
    LIMIT 1
getspnam    SELECT username,password,lstchg,min,max,warn,inact,expire,flag \
    FROM users \
    WHERE username='%1$s' \
    LIMIT 1
getpwent    SELECT username,'x',uid,gid,name,homedir,shell \
    FROM users
getspent    SELECT username,password,lstchg,min,max,warn,inact,expire,flag \
    FROM users
getgrnam    SELECT name,password,gid \
    FROM groups \
    WHERE name='%1$s' \
    LIMIT 1
getgrgid    SELECT name,password,gid \
    FROM groups \
    WHERE gid='%1$u' \
    LIMIT 1
getgrent    SELECT name,password,gid \
    FROM groups
memsbygid   SELECT username \
    FROM grouplist \
    WHERE gid='%1$u'
gidsbymem   SELECT gid \
    FROM grouplist \
    WHERE username='%1$s'

host remote.hostname
port 3XXX
database    Xx
username    X
password    
#socket  /var/lib/mysql/mysql.sock

I'm pretty sure, this would also fail on F34, if the network is not 
reachable when needed.


libnss-mysql updated from 1.5-34 to 1.5-37 and nss from 3.58 to 3.63, 
just in case, nss caused this behaviour.


Of

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

FYI: IETF deprecates TLS 1.0 + 1.1

[Marius Schwarz]

Hi,

the IETF has now deprecated TLS 1.0 and 1.1 .

https://datatracker.ietf.org/doc/rfc8996/

Do we plan an official Old-TLS-Deactivation date or do gnutls and 
openssl decide when it's time to deactivate them?


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

Re: is the license AGPL 3.0 useable in terms of distributing the software as a package?

[Marius Schwarz]

Am 24.03.21 um 02:44 schrieb Kevin Kofler via devel:

Kevin Kofler via devel wrote:

This is the reason why MBROLA is not in Fedora. MBROLA is not new. It is
much older than the 2-year-old GitHub project. The license of the voices
has always been the blocker.

PS: This was already discussed when the GitHub project was created in 2019:
https://lists.fedoraproject.org/archives/list/le...@lists.fedoraproject.org/thread/MAAY3B6KUVAV7YRNUSW7G6672WUAFWYJ/
with the same conclusion. (It is not acceptable for Fedora, unfortunately.)

And, a small correction: according to the Wikipedia article:
https://en.wikipedia.org/wiki/MBROLA
the license of the software itself did actually change from a non-free
license to the AGPL when the project was imported into GitHub. But
unfortunately, the license of the data files is still a blocker, sorry.



A very helpfull explanation. Thanks.

Best regards,
Marius Schwarz

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

is the license AGPL 3.0 useable in terms of distributing the software as a package?

[Marius Schwarz]

hi,

is the license AGPL 3.0 useable in terms of distributing the software as 
a package in a Fedora repo?


This project is meant:

https://github.com/numediart/MBROLA/blob/master/LICENSE

Example license for voices:

https://github.com/numediart/MBROLA-voices/blob/master/data/de1/license.txt

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

Re: Packages hijacking configuration files

[Marius Schwarz]

Am 17.03.21 um 16:47 schrieb Kevin Fenzi:

On Wed, Mar 17, 2021 at 10:25:24AM +0100, Florian Weimer wrote:

Does Fedora has any policies regarding editing or replacing (say with
symbolic links) of configuration files owned by another package?  That
is, automatically on system or package installation, and not as a tool
that system administrators run explicitly to make changes to those
files.

I don't see anything explicit. There's:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_ownership
which talks about a package owning all it's files, but it doesn't
explicitly say no to this.

That said, IMHO this should be forbidden.

Whats the use case?
It maybe not Florians use-case, but we may have a similar situation on 
pinephone:


fedora-release-common-32-4.noarch  owns /etc/os-release

our spin should identify itself as "XX" via variant_id added to 
os-release.


3 Ways:

1) contacting the package owner, and ask for his help on this case.
2) a replacement package with a changed version of os-release is stored 
into copr ( higher priority )
3) a helper package post-script adds the needed line to os-release if 
not present  (*USE-CASE here* )


Whats actually the best way to deal with it?

Best regards,
Marius



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

Re: [Test-Announce] GNOME 40 Test Day is around the corner!

[Marius Schwarz]

Am 16.03.21 um 18:03 schrieb Sumantro Mukherjee:

Hey All

Fedora 34 GNOME 40 Test Day is happening[0] on 2021-03-17 through 2021-03-19.
This is the time when we test the new features and version bumps of
all the GNOME apps which came with the mega-update.
This time, we have a lot of new changes coming along and we would
appreciate as much
testing as possible.

If you have some spare time, please help run the test cases
mentioned[1] and report the bugs on Gnome GitLab or RHBZ (if it's
Fedora specific).




Can you pls fix this nasty 100%-cpu-usage problem for  gdm first? 
gdm-beta2 did not fix it on aarch64.


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

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

Re: Interesting growth trend in Rawhide

[Marius Schwarz]

Hi,

Am 12.03.21 um 18:50 schrieb Kevin Fenzi:


Well, sure, but I doubt it. None of the pinephone editions has shipped
with Fedora, so it would take people seeking it out and installing it,
so I don't know that there would be too much increase just from this.



It was just a theory, that matched with the points in time.

True, Fedora did not get shiped with the PP CEs, but it's a fact that 
around Sep. 2020 the popularity of PP kickstarted, due to the available 
hardware release, which got marked by the CE availability. As anyone 
could write it's beloved distro release on a sdcard and boot it with any 
PP, so people did it. Thats also i came to my Fedora PP ;)


We already discussed it in the mobiliy channel, we can add "VARIANT_ID" 
to our /etc/os-release and mark it mobiliy ( not a finally decided yet 
). This way we get more reliable data. This also will help with the 
question, if an own Fedora Spin is  worth the effort.


@SJSmoogen:

I agree, from those numbers, it looks more like x86_64 as source of the 
increase.


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

Re: F35 Change: "Fedora Linux" in /etc/os-release

[Marius Schwarz]

Am 09.03.21 um 17:54 schrieb Matthew Miller:

  We don't need to reach 100% compliance (or any other metric) to
be an improvement.


I don't think adding "Linux" is an improvement.  Everyone who does not 
think of a hat first, when someone mentions Fedora, already knows,  this 
is a Linux distribution called Fedora.


I'm also pretty sure, that the Linux Kernel is the most important part 
of the distro, but compared in size to all that what the Fedora 
distribution contains, it's just a tiny little fragment.


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

Re: systemd-resolved fallback DNS servers: usability vs. GDPR

[Marius Schwarz]

Am 25.02.21 um 10:51 schrieb Florian Weimer:


Why do you think that?

Caching DNS server availability is a commonly requested feature even in
data center deployments.  The way Fedora currently implements its DNS
client, it more or less defeats the built-in high availability mechanism
of DNS, and complex network-based mitigations are needed (like using
anycast DNS resolvers).


If you run a server farm with mailservers, you usually have antispam 
services like spamhaus enabled.


If one server from an ip adressrange is using spamhaus, spamhaus is fine 
with it.
If a hundret ips from that ip addressrange ask spamhaus, you get blocked 
quite fast.


The cache on the server itself, is of limit use here. Thats why you use 
a central dns cache on one server,

so anyone benefits from the caching and spamhaus is happy : win-win.

On a desktop / laptop you won't have such a scenario in the first place, 
here local caching makes more sense.


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

Re: systemd-resolved fallback DNS servers: usability vs. GDPR

[Marius Schwarz]

Am 23.02.21 um 20:34 schrieb Zbigniew Jędrzejewski-Szmek:


Everything, that is not prepresenting a person, is not regulated by
GDPR, therefor it does not "need" to comply.

No. GDPR is about "personally identifying information". In particular,
it talks about information which may be combined with other information
(now or in the future) to identify a specific person. And an IP address
falls into this category in the general case.

The scenario we are considering here is e.g. a company which provides
computers with Fedora installed to its employees or customers. Whatever
resolver is used gets the source IP information which as described
above can be identifying (depending on the network setup and other
circumstances). By removing the fallback, we're removing a possible
information expose and violation of the law by the company.


I didn't say anything else ;)

If a  PC in a companies network, is accessing the companies dns cache, 
the dns cache uses it's own ip for the root dns request, hiding the 
personal IP from that root dns.  This is fine.


If the copmanies DNS cache is failing and the PC is falling back, using 
IPv6 to connect to a fallback server, that is an issue.


 I personally think, IPv4 doesn't matter here, as most companies do use 
NAT to connect the lan to the outside world. Individual traceback is no 
possible that way.


Which leads to the conclusion, that a workstation should not have 
fallbackservers for dns, where Cloudinstances need to check that 
requirement themselves as it matters how and where they do dns. It 
relies heavily on the service and how many people use it.


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

Re: systemd-resolved fallback DNS servers: usability vs. GDPR

[Marius Schwarz]

Am 22.02.21 um 11:17 schrieb Zbigniew Jędrzejewski-Szmek:

1) Use different defaults for different Fedora editions, e.g. container
and cloud images include the fallback DNS servers list while
workstation (and similar) images don't.

Yes, I think this would be the way to go.
Everything, that is not prepresenting a person, is not regulated by 
GDPR, therefor it does not "need" to comply.


About fallbacks in general:

Es the example shows cleary to me, having fallback dns means, that you 
do not see, that your dns config is faulty

and will fail in unexpected ways.

Best regards,
Marius


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

Re: Don't update to the latest f33!

[Marius Schwarz]

Am 16.02.21 um 15:03 schrieb Ed Greshko:



Thanks for the help!


FWIW, I suppose I don't know why a BZ is needed since the 
/etc/systemd/resolved.conf has a sample

for the DNS= parameter showing:




I think that "," is received by a dhcp answere from the dhcpd, which 
knows two dns and sets it that way. Maybe a mistake in the dhcp 
implementation or config line. IMHO systemd should be fail-tolerant to 
this kind of "bug", so a br is a good idea.


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

glib2 2.67.3-2 seems to cause crashes with pipewire and pulse

[Marius Schwarz]

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


If 2.67.3 is installed, and audio settings get changed, after a few 
changes, mostly on the input devices, phosh is crashing.


Crashing started 2 days ago, which is exactly the time, that package 
came on the system.

Downgrading glib2 back to 2.67.1-4 from late Jan, fixed the crashes.

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

Re: Grub2 patches in Fedora

[Marius Schwarz]

Am 05.02.21 um 15:03 schrieb Marek Marczykowski-Górecki:

  I know it's problematic when you run Fedora VM on non-fedora Xen host if you 
use
pvgrub/pygrub - in that case it uses host's grub to parse guest grub.cfg
and load the actual kernel. But I'm pretty sure there are other
problematic cases too.




... not to speak of the xen problems with kernel images not able to run 
on the xen host, due to recent changes in structures from one major 
kernel version to another.


I can sing a song about it...

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

Re: mesa 21.0.0-rc3 making rawhide really unstable?

[Marius Schwarz]

Am 02.02.21 um 22:53 schrieb Matthew Miller:

On Tue, Feb 02, 2021 at 10:20:03PM +0100, Marius Schwarz wrote:

And worth repeating: lookit this nice new functionality...

sudo dnf offline-upgrade download
sudo dnf offline-upgrade reboot



# dnf offline-upgrade
Kein solcher Befehl: offline-upgrade. Bitte /usr/bin/dnf --help verwenden.
It could be a DNF plugin command, try: "dnf install
'dnf-command(offline-upgrade)'" (failed too)

and there is no seperate dnf package for this cmd, at least i can't
see one adhoc.

It is part of the system-upgrade plugin, so

   sudo dnf install 'dnf-command(system-upgrade)'

will do it. I've created a PR for the package to add the missing virtual
provides:

https://src.fedoraproject.org/rpms/dnf-plugins-extras/pull-request/2



The rawhide installation did not have that plugin, my F32 system had 
it.. FTR those have been missing:


 python3-dnf-plugin-system-upgrade
 python3-dnf-plugins-extras-common


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

Re: mesa 21.0.0-rc3 making rawhide really unstable?

[Marius Schwarz]

Am 02.02.21 um 21:58 schrieb Matthew Miller:

On Tue, Feb 02, 2021 at 12:36:36PM -0800, Kevin Fenzi wrote:

landed (from koji) and gnome-shell did crash while upgrading. I did of
course have the dnf running in a tmux session, but just a heads up for
anyone upgrading via dnf live... your session may go away, so please use
tmux/screen or offline updates.

And worth repeating: lookit this nice new functionality...

sudo dnf offline-upgrade download
sudo dnf offline-upgrade reboot



# dnf offline-upgrade
Kein solcher Befehl: offline-upgrade. Bitte /usr/bin/dnf --help verwenden.
It could be a DNF plugin command, try: "dnf install 
'dnf-command(offline-upgrade)'" (failed too)


and there is no seperate dnf package for this cmd, at least i can't see 
one adhoc.


dnf-4.6.0-1.fc34.noarch
dnf-data-4.6.0-1.fc34.noarch
dnf-plugins-core-4.0.19-1.fc34.noarch
libdnf-0.58.0-1.fc34.aarch64
python3-dnf-4.6.0-1.fc34.noarch
python3-dnf-plugins-core-4.0.19-1.fc34.noarch
python3-libdnf-0.58.0-1.fc34.aarch64

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

Solved: new koji problem: 404 errors on downloadlinks

[Marius Schwarz]

Am 27.01.21 um 16:29 schrieb Marius Schwarz:



https://kojipkgs.fedoraproject.org//packages/firefox/85.0/4.fc32/x86_64/firefox-85.0-4.fc32.x86_64.rpm

which just retruns a 404:

$ curl -I 
http://kojipkgs.fedoraproject.org//packages/firefox/85.0/4.fc32/x86_64/firefox-85.0-4.fc32.x86_64.rpm

HTTP/1.1 404 Not Found
Server: Apache-Coyote/1.1
Transfer-Encoding: chunked
Date: Wed,*27 Jan 2021 15:28:45 GMT***


looks like it got fixed @15:40 GMT


best regards,
Marius


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

new koji problem: 404 errors on downloadlinks

[Marius Schwarz]

The new firefox build 85.0.4 :

https://koji.fedoraproject.org/koji/buildinfo?buildID=1680475

offers this link:

https://kojipkgs.fedoraproject.org//packages/firefox/85.0/4.fc32/x86_64/firefox-85.0-4.fc32.x86_64.rpm

which just retruns a 404:

$ curl -I 
http://kojipkgs.fedoraproject.org//packages/firefox/85.0/4.fc32/x86_64/firefox-85.0-4.fc32.x86_64.rpm

HTTP/1.1 404 Not Found
Server: Apache-Coyote/1.1
Transfer-Encoding: chunked
Date: Wed,*27 Jan 2021 15:28:45 GMT**
*

best regards,
Marius

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

Re: COMMERCIAL - Bosch - Architect

[Marius Schwarz]

Am 27.01.21 um 15:37 schrieb Stephen John Smoogen:


The following is an official statement.

This list is NOT meant for these sorts of emails. Please do not post 
either CV or requests for hiring on this list. We will be deleting all 
further posts in this vein




The legal departement of Bosch has already informed yesterday.

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

JFYI: grub2-efi problem and how to fix it.

[Marius Schwarz]

Hi,

as there is a small problem with pinephones and grub2-efi, heres how to 
fix it:


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

Problem:

[root@fedorapine boot]# rpm -U 
/var/cache/dnf/rawhide-135a69fc59e3201d/packages/grub2-efi-aa64-2.04-34.fc34.aarch64.rpm
Fehler: Entpacken des Archivs fehlgeschlagen bei Datei 
/boot/grub2/grubenv;60101be4: cpio: symlink fehlgeschlagen - Datei oder 
Verzeichnis nicht gefunden
Fehler: grub2-efi-aa64-1:2.04-34.fc34.aarch64: installieren fehlgeschlagen
Fehler: grub2-efi-aa64-1:2.04-31.fc34.aarch64: löschen übersprungen
[root@fedorapine boot]# ll /boot/
insgesamt 14164
drwxr-xr-x 2 root root 4096 24. Jan 20:27 allwinner
-rwxr-xr-x 1 root root  568 22. Jan 19:47 boot.cmd
-rwxr-xr-x 1 root root  640 22. Jan 19:47 boot.scr
drwxr-xr-x 4 root root 4096 16. Jan 18:58 efi
drwxr-xr-x 2 root root 4096 26. Jan 14:39 grub2
-rwxr-xr-x 1 root root 13672456 22. Jan 19:47 Image
drwxr-xr-x 2 root root 4096 16. Jan 19:00 loader
-rwxr-xr-x 1 root root   796915 12. Jan 18:55 u-boot-sunxi-with-spl.bin
-rwxr-xr-x 1 root root  194 12. Jan 18:55 update-uboot.sh

[root@fedorapine boot]# ll /boot/grub2
insgesamt 0
[root@fedorapine boot]#


Fix:

[root@fedorapine boot]# touch /boot/grub2/grubenv
[root@fedorapine boot]# rpm -U 
/var/cache/dnf/rawhide-135a69fc59e3201d/packages/grub2-efi-aa64-2.04-34.fc34.aarch64.rpm
[root@fedorapine boot]#

best regards,
Marius

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

Re: Software Management (RPM, DNF) 2020 retrospective

[Marius Schwarz]

Am 18.01.21 um 09:35 schrieb Daniel Mach:

DNF 5
-
  * The goal is to remove redundant code and make sure all tools built 
on top libdnf work the same (DNF currently uses a different code path 
than microdnf and PackageKit) 


Can you add a new goal:

Don't use Python for it, as it it's slow on mobile devices like 
Pinephone a.s.o.



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

Re: Orphaned packages looking for new maintainers

[Marius Schwarz]

Am 12.01.21 um 11:51 schrieb Vitaly Zaitsev via devel:

On 11.01.2021 22:30, Peter Lemenkov wrote:

So right now we don't have a opensource VoIP client application for
SIP/XMPP networks in Fedora as far as I know.


You can use psi-plus for VoIP over XMPP. It supports voice and video 
calls.




Jitsi is still inside the repo and offers SIP, Audio, Video, XMPP .

And with some luck, we get a newer version soon ;)

Best regards,
Marius


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

Re: Orphaned packages looking for new maintainers

[Marius Schwarz]

Am 11.01.21 um 16:07 schrieb Vitaly Zaitsev via devel:

On 11.01.2021 14:43, Peter Lemenkov wrote:

XMPP-based and it looks like XMPP days
are numbered.


XMPP is alive. I maintain 2 XMPP clients in Fedora.



I just tried Jitsi latest Build 5633 on Fedora 32 and it started and run 
... for approximatly 10 seconds before it crashed :)


It still relies on Java 1.8 where Java 15 is the current release. Even 
with Java 11 it did not even compile in 1.8 mode. it will be a lot of work
to get all the old constructions out of the code before we can even 
think to run it with Java 11+.


If i get it to work proper with the help of the devs, I hope to get it 
back into Fedora Copr or stable.



Best regards,
Marius

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