Re: F42 Change Proposal: Enable Drm Panic (system-wide)

V Sat, Jul 13, 2024 at 11:32:49AM +0200, Javier Martinez Canillas napsal(a): > For the non-panic case, as Jocelyn mentioned in the change proposal plymouth > already supports redirecting the kernel messages (reading /dev/kmsg) to the > VT and for systems without plymouth, a serial console could be

Re: Screen brightness keys not working

Hello Iñaki, I don't know what caused your issue but I had screen brightness issues in the past and started using a tool called `light` as an alternative to `xbacklight`. It is in Fedora https://src.fedoraproject.org/rpms/light. Maybe you want to try it as a temporary workaround until you find a pr

Re: Error building new package in sidetag

Thanks, Kevin and Mikel Looks good now *Mark E. Fuller, Ph.D.* *ful...@fedoraproject.org* *ful...@mefuller.dev* *@fuller:fedora.im* *@fuller:one.ems.host* *https://mefuller.dev* *PGP Fingerprint: 73F1 A30C BDF4 DB4B C75F FD0F D599 E76C FFCA BF60* Jul 14, 2024 22:59:14 Kevin Fenzi : > On Sun, Jul

Re: Screen brightness keys not working

On 7/11/24 4:08 AM, Iñaki Ucar wrote: The Fn keys to increase/decrease the screen brightness always worked, but have stopped working at some point, and the problem is that I have no clue what may have caused it, because I don't remember when was the last time I used them. It's an LG Gram runn

Re: Screen brightness keys not working

On Mon, 15 Jul 2024 at 09:56, Samuel Sieb wrote: > On 7/11/24 4:08 AM, Iñaki Ucar wrote: > > The Fn keys to increase/decrease the screen brightness always worked, > > but have stopped working at some point, and the problem is that I have > > no clue what may have caused it, because I don't rememb

sbin-merge: what to do?

Hi! I've been trying to implement the sbin-merge for F41 [1]. Side tag f41-build-side-92231 was created and about 80 packages were rebuilt there. This is enough to implement the merge on "normal" end-user systems and in buildroots for packages in mock and koji. The current status is that the pend

The future Fedora Copr "rolling" chroot cleanup policy

Hello maintainers. This is a gentle heads-up (at least a year in advance) that we plan to address Fedora Copr storage consumption related to Fedora Rawhide builds. Currently, Rawhide build results are kept indefinitely, but this is going to change in the future. For the full story, see the blog

Re: F42 Change Proposal: Enable Drm Panic (system-wide)

On Sat, Jul 13, 2024 at 10:20:53AM -0500, Chris Adams wrote: > Once upon a time, Javier Martinez Canillas said: > > In other words, a user should still be able to log into a VT and fbcon is > > still attached to an (DRM emulated) fbdev. The only difference is that the > > kernel messages are not g

Re: the sad state of installability tests

V Sun, Jul 14, 2024 at 06:04:25PM +, Zbigniew Jędrzejewski-Szmek napsal(a): > CI for Bodhi updates has a bunch of tests like > fedora-ci.koji-build.tier0.functional > fedora-ci.koji-build./plans/public.functional > that routinely fail. In fact, they are designed in a way where they > _must_

Re: Screen brightness keys not working

On 7/15/24 1:23 AM, Iñaki Ucar wrote: On Mon, 15 Jul 2024 at 09:56, Samuel Sieb > wrote: On 7/11/24 4:08 AM, Iñaki Ucar wrote: > The Fn keys to increase/decrease the screen brightness always worked, > but have stopped working at some point, and the pr

Re: the sad state of installability tests

Hi Zbyszek, On 2024/07/14 20:04, Zbigniew Jędrzejewski-Szmek wrote: I'm looking for a solution which doesn't just skip the installability tests altogether. On PRs with zuul or FedoraCI automation, the same instability tests that are done for Bodhi are performed. But what would help is to make

Re: the sad state of installability tests

On Mon, Jul 15, 2024 at 10:31:06AM +0200, Petr Pisar wrote: > Yes. Installability is a very basic test and it should be reliable. My > feeling is that broken dependencies are the most common packaging bug. > > > Or if it's not possible to make them work, disable them? In the > > current state we j

Re: Screen brightness keys not working

On Mon, 15 Jul 2024 at 10:34, Samuel Sieb wrote: > On 7/15/24 1:23 AM, Iñaki Ucar wrote: > > > > > > On Mon, 15 Jul 2024 at 09:56, Samuel Sieb > > wrote: > > > > On 7/11/24 4:08 AM, Iñaki Ucar wrote: > > > The Fn keys to increase/decrease the screen brightness al

Re: Screen brightness keys not working

On 7/15/24 1:47 AM, Iñaki Ucar wrote: On Mon, 15 Jul 2024 at 10:34, Samuel Sieb > wrote: On 7/15/24 1:23 AM, Iñaki Ucar wrote: > > > On Mon, 15 Jul 2024 at 09:56, Samuel Sieb mailto:sam...@sieb.net> >

Re: the sad state of installability tests

On Mon, Jul 15, 2024 at 10:39:37AM +0200, Cristian Le via devel wrote: > Hi Zbyszek, > > On 2024/07/14 20:04, Zbigniew Jędrzejewski-Szmek wrote: > > I'm looking for a solution which doesn't just skip the installability > > tests altogether. > > On PRs with zuul or FedoraCI automation, the same in

Re: F42 Change Proposal: Enable Drm Panic (system-wide)

On 15/07/2024 10:30, Zbigniew Jędrzejewski-Szmek wrote: On Sat, Jul 13, 2024 at 10:20:53AM -0500, Chris Adams wrote: Once upon a time, Javier Martinez Canillas said: In other words, a user should still be able to log into a VT and fbcon is still attached to an (DRM emulated) fbdev. The only

Re: the sad state of installability tests

Hello, po 15. 7. 2024 o 10:57 Zbigniew Jędrzejewski-Szmek napísal(a): > On Mon, Jul 15, 2024 at 10:39:37AM +0200, Cristian Le via devel wrote: > > Hi Zbyszek, > > > > On 2024/07/14 20:04, Zbigniew Jędrzejewski-Szmek wrote: > > > I'm looking for a solution which doesn't just skip the installabili

Fedora rawhide compose report: 20240715.n.0 changes

OLD: Fedora-Rawhide-20240714.n.0 NEW: Fedora-Rawhide-20240715.n.0 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 15 Dropped packages:0 Upgraded packages: 42 Downgraded packages: 0 Size of added packages: 643.24 KiB Size of dropped packages:0

Re: whatcanidoforfedora.org is stale

On Sun, Jul 14, 2024 11:58:38 GMT, Zbigniew Jędrzejewski-Szmek wrote: > snip > > There's also this page in the docs: > > https://docs.fedoraproject.org/en-US/project/join/ > > > > Perhaps we incorporate the banner to this docs page and make both wcidff > > and the wiki page redirect to it (so tha

Re: F42 Change Proposal: Enable Drm Panic (system-wide)

> On 15 Jul 2024, at 10:21, Jocelyn Falempe wrote: > > Normally, systemd logging should fill the gap, (and a userspace daemon could > do the same, by copying /proc/kmsg to /dev/tty0), but it is started a bit > later than what we had. The hard to fix issues are when systemd does not get a cha

Re: The future Fedora Copr "rolling" chroot cleanup policy

On 15-07-2024 10:24, Pavel Raiskup wrote: TL;DR: We plan to start monitoring build activity in Copr projects. If no builds appear for a long time in these "rolling" chroots (such as Fedora Rawhide), we'll disable such chroots, preserve the built results for a while, and then delete them if no act

Next Open NeuroFedora Meeting: Monday, 17 July 2024 (today) at 13:00 UTC

Hello everyone, Please join us at the next Open NeuroFedora team meeting on Monday, 17 July at 13:00 UTC. The meeting is a public meeting, and open for everyone to attend. You can join us over on Matrix in the Fedora Meeting channel: https://matrix.to/#/#meeting:fedoraproject.org You can use th

Epel8 build with python > 3.6?

I want to make a minor update to an EPEL 8 package, but the default Python is 3.6 where the update requires >=3.7 Is this possible to do (with modules?)? How would I specify it in the spec file if it is? *Mark E. Fuller, Ph.D.* *ful...@fedoraproject.org* *ful...@mefuller.dev* *@fuller:fedora.im*

Re: the sad state of installability tests

V Mon, Jul 15, 2024 at 08:45:53AM +, Zbigniew Jędrzejewski-Szmek napsal(a): > On Mon, Jul 15, 2024 at 10:31:06AM +0200, Petr Pisar wrote: > > I guess the test does not take RPM Conflicts into account. It's overly > > optimistic when populating a system by installing all tested packages > > tog

Re: the sad state of installability tests

On Mon, Jul 15, 2024 at 01:26:09PM +0200, Petr Pisar wrote: > V Mon, Jul 15, 2024 at 08:45:53AM +, Zbigniew Jędrzejewski-Szmek > napsal(a): > > On Mon, Jul 15, 2024 at 10:31:06AM +0200, Petr Pisar wrote: > > > I guess the test does not take RPM Conflicts into account. It's overly > > > optimis

Re: the sad state of installability tests

On Mon, Jul 15, 2024 at 8:03 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Mon, Jul 15, 2024 at 01:26:09PM +0200, Petr Pisar wrote: > > V Mon, Jul 15, 2024 at 08:45:53AM +, Zbigniew Jędrzejewski-Szmek > > napsal(a): > > > On Mon, Jul 15, 2024 at 10:31:06AM +0200, Petr Pisar wrote: > > > > I gu

Re: The future Fedora Copr "rolling" chroot cleanup policy

On Mon, Jul 15, 2024 at 4:25 AM Pavel Raiskup wrote: > > Hello maintainers. > > This is a gentle heads-up (at least a year in advance) that we plan to > address Fedora Copr storage consumption related to Fedora Rawhide > builds. Currently, Rawhide build results are kept indefinitely, but > this i

Re: the sad state of installability tests

On Mon, Jul 15, 2024 at 11:52:07AM +, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Jul 15, 2024 at 01:26:09PM +0200, Petr Pisar wrote: > > V Mon, Jul 15, 2024 at 08:45:53AM +, Zbigniew Jędrzejewski-Szmek > > napsal(a): > > > On Mon, Jul 15, 2024 at 10:31:06AM +0200, Petr Pisar wrote: > > >

Re: F42 Change Proposal: Enable Drm Panic (system-wide)

On 15/07/2024 12:04, Barry wrote: On 15 Jul 2024, at 10:21, Jocelyn Falempe wrote: Normally, systemd logging should fill the gap, (and a userspace daemon could do the same, by copying /proc/kmsg to /dev/tty0), but it is started a bit later than what we had. The hard to fix issues are wh

Fedora 41 Mass Rebuild Notification - Scheduled for 2024-07-17

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list. -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...

Re: Fedora 41 Mass Rebuild Notification - Scheduled for 2024-07-17

Dne 15. 07. 24 v 3:38 odp. samyak.j...@gmail.com napsal(a): The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list. This is not first time I see this. First I thought it is my setup. But it is in ML archives too. https://lis

Re: Fedora 41 Mass Rebuild Notification - Scheduled for 2024-07-17

On Mon, Jul 15, 2024 at 9:43 AM Miroslav Suchý wrote: > > Dne 15. 07. 24 v 3:38 odp. samyak.j...@gmail.com napsal(a): > > The content of this message was lost. It was probably cross-posted to > > multiple lists and previously handled on another list. > > This is not first time I see this. First I

Re: Fedora 41 Mass Rebuild Notification - Scheduled for 2024-07-17

Does this message arrived on Friday? I did some change on Friday that should prevent this issue. For more info look at https://pagure.io/fedora-infrastructure/issue/12043. Basically the archives/mailman workers were killed by OOM from time to time. I assume the messages handled during that tim

Re: Fedora 41 Mass Rebuild Notification - Scheduled for 2024-07-17

On Mon, Jul 15, 2024 at 7:29 PM Stephen Gallagher wrote: > On Mon, Jul 15, 2024 at 9:43 AM Miroslav Suchý wrote: > > > > Dne 15. 07. 24 v 3:38 odp. samyak.j...@gmail.com napsal(a): > > > The content of this message was lost. It was probably cross-posted to > > > multiple lists and previously han

Re: Fedora 41 Mass Rebuild Notification - Scheduled for 2024-07-17

On Mon, Jul 15, 2024 at 7:45 PM Michal Konecny wrote: > Does this message arrived on Friday? I did some change on Friday that > should prevent this issue. > The email was sent today, and the reply to post two hours of posting (I guess when Stephen approved it from the queue) > > For more info lo

Re: The future Fedora Copr "rolling" chroot cleanup policy

Dne 15. 07. 24 v 2:57 odp. Stephen Gallagher napsal(a): Instead of always keeping "Rawhide" around as a separate buildroot, why not just rename it at Branching and then create a NEW Rawhide chroot? 1) Different workflow compared to the one we have in Fedora. 2) Create it with what? Empty conte

Re: Fedora 41 Mass Rebuild Notification - Scheduled for 2024-07-17

In this case we still have something to investigate in new mailman deployment. We have issue for it here https://pagure.io/fedora-infrastructure/issue/12011. I will reopen it as it seems that it's still happening. Michal On 15. 07. 24 16:17, Samyak Jain wrote: On Mon, Jul 15, 2024 at 7:45

Re: The future Fedora Copr "rolling" chroot cleanup policy

On Mon, Jul 15, 2024 at 10:21 AM Miroslav Suchý wrote: > > Dne 15. 07. 24 v 2:57 odp. Stephen Gallagher napsal(a): > > Instead of always keeping "Rawhide" around as a separate buildroot, > why not just rename it at Branching and then create a NEW Rawhide > chroot? > > 1) Different workflow compare

Re: the sad state of installability tests

On 2024/07/15 13:52, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Jul 15, 2024 at 01:26:09PM +0200, Petr Pisar wrote: V Mon, Jul 15, 2024 at 08:45:53AM +, Zbigniew Jędrzejewski-Szmek napsal(a): Maybe I conflate installability tests with rpmdeplint tests. We need both: A test which checks that

Intent to orphan receptor rpm

All, I am considering orphaning the receptor[1] rpm, I have tried to maintain the package but with the constant build issues and my lack of experience with golang it has become very difficult for me to maintain. I am reaching out to see if anyone wants to take over the package before I go thought

unfixed CVE-2024-39929 in exim

https://bugzilla.redhat.com/show_bug.cgi?id=2297728 Luckily is not a RCE, but we have an unpatched CVE in Exim .. can someone pls poke the right person for it? There was no reaction to the exim accouncement on OSS and to the bugreport. thank you. best regards, Marius Schwarz -- ___

Re: the sad state of installability tests

On Mon, 2024-07-15 at 08:45 +, Zbigniew Jędrzejewski-Szmek wrote: > > Yes, I've opened many issues regarding Fedora CI. I think the problem is > > that > > the CI maintainer is not a regular packager and thus does not observe CI > > reults in real life. On the other hand, package maintainers d

Re: unfixed CVE-2024-39929 in exim

On 15/07/2024 16:46, Marius Schwarz wrote: https://bugzilla.redhat.com/show_bug.cgi?id=2297728 Luckily is not a RCE, but we have an unpatched CVE in Exim .. can someone pls poke the right person for it? There was no reaction to the exim accouncement on OSS and to the bugreport. It was only

Re: F42 Change Proposal: Enable Drm Panic (system-wide)

> On 15 Jul 2024, at 14:05, Jocelyn Falempe wrote: > > If you want to see the kernel boot log, before userspace is started, > you can add "init=/does_not_exist drm.panic_screen=kmsg" to the kernel > command line. It will panic, and you will see all relevant logs with > drm_panic. > It's not id

Re: Screen brightness keys not working

Are you running KDE with HDR enabled by chance? That will make the keys non-functional. On Mon, Jul 15, 2024 at 3:52 AM Samuel Sieb wrote: > On 7/15/24 1:47 AM, Iñaki Ucar wrote: > > On Mon, 15 Jul 2024 at 10:34, Samuel Sieb > > wrote: > > > > On 7/15/24 1:23 AM, Iñ

Re: F42 Change Proposal: Enable Drm Panic (system-wide)

On 7/15/24 09:12, Petr Pisar wrote: V Sat, Jul 13, 2024 at 11:32:49AM +0200, Javier Martinez Canillas napsal(a): For the non-panic case, as Jocelyn mentioned in the change proposal plymouth already supports redirecting the kernel messages (reading /dev/kmsg) to the VT and for systems without ply

Re: F42 Change Proposal: Enable Drm Panic (system-wide)

On 15/07/2024 18:13, Barry wrote: On 15 Jul 2024, at 14:05, Jocelyn Falempe wrote: If you want to see the kernel boot log, before userspace is started, you can add "init=/does_not_exist drm.panic_screen=kmsg" to the kernel command line. It will panic, and you will see all relevant logs wit

Re: F42 Change Proposal: Enable Drm Panic (system-wide)

On Mon, 15 Jul 2024 at 13:28, Jocelyn Falempe wrote: > > > > On 15/07/2024 18:13, Barry wrote: > > > >> On 15 Jul 2024, at 14:05, Jocelyn Falempe wrote: > >> > >> If you want to see the kernel boot log, before userspace is started, > >> you can add "init=/does_not_exist drm.panic_screen=kmsg" to

Re: Epel8 build with python > 3.6?

On Mon, 2024-07-15 at 12:56 +0200, Mark E. Fuller via devel wrote: >  I want to make a minor update to an EPEL 8 package, but the default > Python is 3.6 where the update requires >=3.7 > > Is this possible to do (with modules?)? How would I specify it in the > spec file if it is? > you have p

Re: Epel8 build with python > 3.6?

On Mon, 15 Jul 2024 at 06:57, Mark E. Fuller via devel wrote: > > I want to make a minor update to an EPEL 8 package, but the default Python is > 3.6 where the update requires >=3.7 > > Is this possible to do (with modules?)? How would I specify it in the spec > file if it is? BuildRequires: py

Re: Screen brightness keys not working

On Mon, 15 Jul 2024 at 18:53, Jonathan Wright via devel < devel@lists.fedoraproject.org> wrote: > Are you running KDE with HDR enabled by chance? That will make the keys > non-functional. > No, I don't think so. I don't see any HDR option anyways. Iñaki > > On Mon, Jul 15, 2024 at 3:52 AM Sam

Re: Screen brightness keys not working

It's the kernel. Going back to 6.9.6 fixes the issue... Iñaki On Mon, 15 Jul 2024 at 21:34, Iñaki Ucar wrote: > > > On Mon, 15 Jul 2024 at 18:53, Jonathan Wright via devel < > devel@lists.fedoraproject.org> wrote: > >> Are you running KDE with HDR enabled by chance? That will make the keys >>

Re: the sad state of installability tests

On Mon, Jul 15, 2024 at 08:55:03AM -0400, Stephen Gallagher wrote: > This seems like overkill. Wouldn't the simplest valid installability > test just be to test whether each subpackage *individually* could be > installed? That's a really nice idea. > If we have 20 subpackages, just launch 20 sepa

Re: sbin-merge: what to do?

This change also appears to affect /usr/local[1]. This commit[2] introduced a regression with missing directories in /usr/local. Configuration from F40: /usr/local/bin (missing in F41) /usr/local/etc /usr/local/games /usr/local/include /usr/local/lib /usr/local/lib64 /usr/local/libexec (missin

Schedule for Tuesday's FESCo Meeting (2024-07-16)

Following is the list of topics that will be discussed in the FESCo meeting Tuesday at 17:00 UTC in #meeting:fedoraproject.org on Matrix. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2024-07-16 17:00 UTC' Links to all issues to be

Re: sbin-merge: what to do?

I do not envy you this work. The documentation fallout alone... a quick and dirty scan of only the man pages that happen to be *currently installed* on my F40 system reveals that 487 / 2673 man pages in section 8 contain the string 'sbin' somewhere in the troff source. While I'm sure SOME of th

Re: whatcanidoforfedora.org is stale

Cristian Le wrote: > > My opinion is that whatcanidoforfedora is nice visually and easy to > navigate being just a few big font words and buttons, useful for people > like me with short attention span to read small text. It gives a more > general overview of what composes the Fedora ecosystem, r

Re: sbin-merge: what to do?

On Mon, Jul 15, 2024 at 08:23:05AM GMT, Zbigniew Jędrzejewski-Szmek wrote: > Hi! > > I've been trying to implement the sbin-merge for F41 [1]. > Side tag f41-build-side-92231 was created and about 80 packages were > rebuilt there. This is enough to implement the merge on "normal" end-user > system

Re: sbin-merge: what to do?

Frank R Dana Jr. wrote: > I do not envy you this work. The documentation fallout alone... So WHY again are we doing this then? All this is achieving is causing breakage, for zero user-visible benefit. IMHO, the sbin merge should NOT be merged/pushed from the side tag into Rawhide. Instead, the

Re: sbin-merge: what to do?

Zbigniew Jędrzejewski-Szmek wrote: > So… the question now: should I pull the plug on the change for F41, > dump the side tag, Yes please! > and try again for F42? No thanks! Please just dump this broken idea into the trashcan it belongs in. Kevin Kofler -- ___

Re: sbin-merge: what to do?

Kevin Fenzi wrote: > I guess you are talking about live images here? > > If so, they shouldn't need rpm as they don't install using it... The live images MUST contain the rpm executable because their contents are installed to disk (HDD/SSD/whatever) when installing the live image, and at that p

Re: The future Fedora Copr "rolling" chroot cleanup policy

Pavel Raiskup wrote: > This is a gentle heads-up (at least a year in advance) that we plan to > address Fedora Copr storage consumption related to Fedora Rawhide > builds. Currently, Rawhide build results are kept indefinitely, but > this is going to change in the future. > > For the full story,

Re: The future Fedora Copr "rolling" chroot cleanup policy

On pondělí 15. července 2024 12:10:58, SELČ Sandro via devel wrote: > On 15-07-2024 10:24, Pavel Raiskup wrote: > > TL;DR: We plan to start monitoring build activity in Copr projects. > > If no builds appear for a long time in these "rolling" chroots (such as > > Fedora Rawhide), we'll disable such

Re: Epel8 build with python > 3.6?

Thanks, I have tried a few variations on this, but get the following error (trying presently with python 3.8): Error: Problem: conflicting requests   - package python38-pytest-4.6.6-3.module+el8.9.0+1418+f0d66789.noarch from powertools is filtered out by modular filtering (try to add '--skip-bro

Re: Epel8 build with python > 3.6?

Sorry, left out that using python3.12 works until the version checker in the scons builder returns that I'm using unsupported Python3.6, hence asking whether there needs to be a switch somewhere *Mark E. Fuller, Ph.D.* *ful...@fedoraproject.org* *ful...@mefuller.dev* *@fuller:fedora.im* *@fuller:

Re: The future Fedora Copr "rolling" chroot cleanup policy

Dne 16. 07. 24 v 3:34 dop. Kevin Kofler via devel napsal(a): The real issue still appears to be that "Disk storage is the commodity that incurs the highest cloud costs.", which means that cloud might not be the right technology to use here. Or at least the particular cloud implementation you are