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

On Thu, Feb 1, 2024 at 6:58 AM Mattia Verga via devel wrote: > > Il 31/01/24 23:38, Alessandro Astone ha scritto: > > The "personal attack" is a consideration on the proposed maintainer of > > these packages. > > > >> every effort in order to not to break things must be made. > > Then I cannot

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

> I can support that. > > But am I supposed to ignore the fact that kkofler is already bullying the KDE > SIG into not > breaking that one other package they maintain that occasionally breaks on kde > updates? See > example: https://bodhi.fedoraproject.org/updates/FEDORA-2023-977de87584 > > Am

Re: [Test-Announce] Kernel 6.7 Test Week is underway!

Kernel-6.7.3 still has debugging enabled which will break the nvidia driver https://bugzilla.rpmfusion.org/show_bug.cgi?id=6859 https://forums.developer.nvidia.com/t/linux-6-7-beta-550-40-07-error-modpost-gpl-incompatible-module-nvidia-ko-uses-gpl-only-symbol-rcu-read-lock/280908 --

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

Il 31/01/24 23:38, Alessandro Astone ha scritto: > The "personal attack" is a consideration on the proposed maintainer of these > packages. > >> every effort in order to not to break things must be made. > Then I cannot support these packages being added. It is putting additional > effort on the

CI failure: Too many packages to install: 233 (threshold 100). Please use 'repository-file' artifact instead.

How can we fix this error? I think it's related to the fact that glibc has many subpackages. This used to be a problem with slow tests timing out in Zuul, but it didn't prevent any rpm-tmt-test subtests from

Re: Re: A reminder: you cannot just "revert" package version bumps

Gary Buhrmaster wrote: > While I don't like epochs, there is nothing intrinsically > wrong with an epoch bump when a packager > determines that they need to downgrade because > the testing for the upgrade was insufficient or > inadequately performed and the packager found > that there was no way

[Bug 2232294] perl-Wx needs a rebuild with perl(Alien::wxWidgets::Config::gtk_3_2_2_uni_gcc_3_4)

https://bugzilla.redhat.com/show_bug.cgi?id=2232294 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #12 from

Re: Re: A reminder: you cannot just "revert" package version bumps

On Thu, Feb 1, 2024 at 1:53 AM Kevin Kofler via devel wrote: > And the proposed "solution" of bumping Epoch fixes none of that. It just > introduces an Epoch that we will be stuck with forever. It will not > magically make the downgrade safe in any of the 3 situations you describe. While I

[Bug 2256302] perl-Dist-Zilla-Plugin-Git-2.049 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2256302 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Dist-Zilla-Plugin-Git- |perl-Dist-Zilla-Plugin-Git-

Re: Re: A reminder: you cannot just "revert" package version bumps

kevin wrote: > distro-sync is nice and all, but it's not a silver bullet. > In cases of simple packages a downgrade may not break anything, but in > cases where other things already built upon it, where the new one > changed conguration or interface, or even where the upgrade changed > data, it

[Bug 2256302] perl-Dist-Zilla-Plugin-Git-2.049 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2256302 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Dist-Zilla-Plugin-Git- |perl-Dist-Zilla-Plugin-Git-

Re: Unretire request idle and Go packages working through approval

> IMHO, it's helpfull if you don't open an unretirement request releng > ticket until the package has been re-reviewed (if needed). Trying to > keep track of old tickets waiting for reviews to finish is not a good > workflow. It also results in people filing a ticket, told to do the > re-review,

[EPEL-devel] Re: Incompatible Upgrade Request - singularity-ce

On Mon, Jan 29, 2024 at 06:40:19AM -0800, Troy Dawson wrote: > On Mon, Jan 29, 2024 at 6:37 AM Neal Gompa wrote: > > > > This seems reasonable to me. > > > > I agree with Neal, this looks good to me. > Thank you for the nice explanation/write-up. Yeah, same here. Seems reasonable... kevin

Re: Unretire request idle and Go packages working through approval

On Tue, Jan 30, 2024 at 01:51:50PM -0600, W. Michael Petullo wrote: > I would like to unretire golang-github-apex-logs, and Mikel Olasagasti > Uranga was kind enough to review and approve my review request [1]. > The unretire request has been idle for a while: > >

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

The following Fedora EPEL 8 Security updates need testing: Age URL 27 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-3a29f0d349 python-paramiko-2.12.0-2.el8 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-76443fce3f indent-2.2.13-5.el8 6

Re: Orphaned python-mccabe (dependency of pylint)

On 01. 02. 24 0:51, Michel Lind wrote: I see limb already took the package (thanks limb) - note that the default bugzilla assignee still seems to be 'orphan', I'm assuming that will fix itself eventually Not by itself, the package has a epel bugzilla contact override, so when the main admin

Re: Orphaned python-mccabe (dependency of pylint)

On Tue, Jan 30, 2024 at 02:59:04PM +0100, Miro Hrončok wrote: > Hello. > > I have orphaned python-mccabe. > > It does not build with updated hypothesis, because the update broke > hypothesmith and I don't have time to look into it: > > https://bugzilla.redhat.com/2261579 > > mccabe is a

Re: Orphaned python-mccabe (dependency of pylint)

On Tue, Jan 30, 2024 at 02:59:04PM +0100, Miro Hrončok wrote: > Hello. > > I have orphaned python-mccabe. > > It does not build with updated hypothesis, because the update broke > hypothesmith and I don't have time to look into it: > > https://bugzilla.redhat.com/2261579 > > mccabe is a

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

The "personal attack" is a consideration on the proposed maintainer of these packages. > every effort in order to not to break things must be made. Then I cannot support these packages being added. It is putting additional effort on the KDE-SIG up to once per every week; especially since we're

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

Messaggio originale 31/01/24 22:27, Alessandro Astone ha scritto: > I can support that. > > But am I supposed to ignore the fact that kkofler is already bullying the > KDE SIG into not breaking that one other package they maintain that > occasionally breaks on kde

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

Also "major changes" would be the ~fibonacci-weekly~ Plasma bugfix release, as the -x11 package will require an exact version match of the common libraries. Not really a rare occasion. -- ___ devel mailing list -- devel@lists.fedoraproject.org To

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

I can support that. But am I supposed to ignore the fact that kkofler is already bullying the KDE SIG into not breaking that one other package they maintain that occasionally breaks on kde updates? See example: https://bodhi.fedoraproject.org/updates/FEDORA-2023-977de87584 Am I going to have

[rpms/perl-TimeDate] PR #1: Package tests

jplesnik merged a pull-request against the project: `perl-TimeDate` that you are following. Merged pull-request: `` Package tests `` https://src.fedoraproject.org/rpms/perl-TimeDate/pull-request/1 -- ___ perl-devel mailing list --

Re: Figure out what killed an app (rhbz#2253099)

On Wed, Jan 31, 2024, at 11:40 AM, Paul Grosu wrote: > > > https://github.com/facebookincubator/oomd/ > > 2) Or you can completely disable it: > > https://www.cjjackson.dev/posts/what-is-systemd-oomd-how-to-disable-it/ We need bug reports to get it fixed rather than disabling it, if it's

Re: Figure out what killed an app (rhbz#2253099)

I think your options are two: 1) Write a plugin for the oom service to capture the state (and log it) before it kills the process. Here's the source code to learn more about that: https://github.com/facebookincubator/oomd/ 2) Or you can completely disable it:

Re: Figure out what killed an app (rhbz#2253099)

On Wed, Jan 31 2024 at 06:53:25 PM +01:00:00, Milan Crha wrote: Evo itself doesn't use any seccomp or such, these things can be used by the WebKitGTK. A quick grep revealed: https://github.com/WebKit/WebKit/blob/main/Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp#L258 but that

Re: Figure out what killed an app (rhbz#2253099)

On Wed, 2024-01-31 at 16:24 +0100, Petr Pisar wrote: > A possible explanation is that the signals are procecessed > asychnously and evolution manages to dispatch the signal to bwrap > before kernel > termites evolution because of the first signal. Or I misinterpret the > log. Hi, there

Re: Figure out what killed an app (rhbz#2253099)

On Wed, 2024-01-31 at 08:31 -0600, Michael Catanzaro wrote: > Maybe it could also be sent by mutter if a program > is unresponsive? Hi, the app is perfectly responsive. I click on a widget and the app is killed immediately. There is no freeze of the app. > WebKitGTK doesn't use SIGKILL

[Test-Announce] Fedora-IoT 40 RC 20240131.1 nightly compose nominated for testing

Announcing the creation of a new nightly release validation test event for Fedora-IoT 40 RC 20240131.1. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see:

Re: Figure out what killed an app (rhbz#2253099)

On Wed, 31 Jan 2024 at 12:00, Michael Catanzaro wrote: > On Wed, Jan 31 2024 at 04:42:08 PM +01:00:00, Clemens Lang > wrote: > > Throwing some ideas out there, is it possible that evolution runs > > with a seccomp filter or other BPF program configured to kill the > > process on violation, and

Re: Figure out what killed an app (rhbz#2253099)

On Wed, Jan 31 2024 at 04:42:08 PM +01:00:00, Clemens Lang wrote: Throwing some ideas out there, is it possible that evolution runs with a seccomp filter or other BPF program configured to kill the process on violation, and that’s what’s happening here? I don't think so. flatpak does use

Re: poppler soname bump in Rawhide soon

efl should be fixed in rawhide now. ~spot On Wed, Jan 31, 2024 at 7:32 AM Michael J Gruber wrote: > Am Mi., 31. Jan. 2024 um 11:15 Uhr schrieb Marek Kasik >: > > > > Hi, > > > > On 1/30/24 12:15, Michael J Gruber wrote: > > > Marek Kasik venit, vidit, dixit 2024-01-30 12:02:34: > > >> Hi, > >

[Bug 2232294] perl-Wx needs a rebuild with perl(Alien::wxWidgets::Config::gtk_3_2_2_uni_gcc_3_4)

https://bugzilla.redhat.com/show_bug.cgi?id=2232294 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #11 from

[rpms/perl-TimeDate] PR #1: Package tests

jplesnik opened a new pull-request against the project: `perl-TimeDate` that you are following: `` Package tests `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-TimeDate/pull-request/1 -- ___ perl-devel mailing list --

[rpms/perl-XML-SAX] PR #1: Package tests

jplesnik merged a pull-request against the project: `perl-XML-SAX` that you are following. Merged pull-request: `` Package tests `` https://src.fedoraproject.org/rpms/perl-XML-SAX/pull-request/1 -- ___ perl-devel mailing list --

Re: Figure out what killed an app (rhbz#2253099)

Hey, > On 31. Jan 2024, at 16:24, Petr Pisar wrote: > > Key information is code=128. That code is probably si_code member described in > sigaction(2). The manual lists a lot of values as constants. 128 value is > SI_KERNEL according to /usr/include/asm-generic/siginfo.h. It is documented > as

[rpms/perl-XML-SAX] PR #1: Package tests

jplesnik opened a new pull-request against the project: `perl-XML-SAX` that you are following: `` Package tests `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-XML-SAX/pull-request/1 -- ___ perl-devel mailing list --

Re: Figure out what killed an app (rhbz#2253099)

V Wed, Jan 31, 2024 at 01:07:42PM +0100, Milan Crha napsal(a): > evolution-3211 [003] d..1. 355.904404: signal_generate: sig=9 errno=0 > code=128 comm=evolution pid=3211 grp=1 res=0 > evolution-3211 [003] d..2. 355.904450: signal_generate: sig=9 errno=0 > code=0 comm=bwrap pid=3257 grp=1

Re: Figure out what killed an app (rhbz#2253099)

SIGKILL is almost always sent by systemd-oomd (or the kernel OOM killer). That's the most likely explanation. Theoretically it could also be sent by systemd if a service didn't quit quickly enough following a SIGTERM. Maybe it could also be sent by mutter if a program is unresponsive?

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

On Wed, Jan 31, 2024 at 8:44 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, Jan 30, 2024 at 08:45:37AM -0500, Stephen Gallagher wrote: > > One additional point I forgot to address: the initial concern was that > > the KDE SIG would be implicitly responsible for maintaining these > > packages

[Bug 2261386] mod_perl: FTBFS in F40: odperl_common_util.c:57:53: error: initialization of ‘int (*)(PerlInterpreter *, SV *, MAGIC *, SV *, const char *, I32)’

https://bugzilla.redhat.com/show_bug.cgi?id=2261386 --- Comment #7 from Andrew Bauer --- Thank you sir. I am travelling for work this week and will test this patch over the weekend. -- You are receiving this mail because: You are on the CC list for the bug.

[Bug 2261386] mod_perl: FTBFS in F40: odperl_common_util.c:57:53: error: initialization of ‘int (*)(PerlInterpreter *, SV *, MAGIC *, SV *, const char *, I32)’

https://bugzilla.redhat.com/show_bug.cgi?id=2261386 --- Comment #6 from Joe Orton --- Created attachment 2014197 --> https://bugzilla.redhat.com/attachment.cgi?id=2014197=edit possible fix A naive attempt to fix it seems to compile here, can you try it in rawhide? -- You are receiving

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

On Tue, Jan 30, 2024 at 08:45:37AM -0500, Stephen Gallagher wrote: > One additional point I forgot to address: the initial concern was that > the KDE SIG would be implicitly responsible for maintaining these > packages if they are included in the main repository. From a purely > technical

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

On Tue, 2024-01-30 at 09:57 -0500, Steven A. Falco wrote: > On 1/30/24 08:55 AM, Richard W.M. Jones wrote: > > On Tue, Jan 30, 2024 at 08:38:51AM -0500, Stephen Gallagher wrote: > > > 3) Fedora has a long-standing and well-communicated stance that > > > we are > > > a Wayland distribution first

[Bug 2261386] mod_perl: FTBFS in F40: odperl_common_util.c:57:53: error: initialization of ‘int (*)(PerlInterpreter *, SV *, MAGIC *, SV *, const char *, I32)’

https://bugzilla.redhat.com/show_bug.cgi?id=2261386 Andrew Bauer changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #5 from Andrew

Re: Figure out what killed an app (rhbz#2253099)

On Wed, 2024-01-31 at 13:07 +0100, Milan Crha wrote: > In such case, I might be able to catch this in gdb, right? Maybe with > a breakpoint in the `kill` function, and any other? Okay, I tried with the following (more variants, just in case): gdb evolution \ --ex "b kill" \

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

Am 31.01.24 um 09:57 schrieb Larina Loriasel via devel: 'sync' has some strong downsides though: various operations become painfully slow (this depends a lot on the hardware and its age, and the history of previous writes, etc.), write operations block read operations, and the total number of

Re: poppler soname bump in Rawhide soon

Am Mi., 31. Jan. 2024 um 11:15 Uhr schrieb Marek Kasik : > > Hi, > > On 1/30/24 12:15, Michael J Gruber wrote: > > Marek Kasik venit, vidit, dixit 2024-01-30 12:02:34: > >> Hi, > >> > >> I plan to rebase poppler to 24.02.0 once it is released. It will be > >> probably released this week and I

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

On Tue, Jan 30, 2024 at 01:48:08PM -0800, kevin wrote: > If Adam's summary is understood by all the involved parties, then I > don't think there would be a problem allowing the packages in. > Everyone involved should just try and not place undue burdens on others. > If there's a flood of reports

Re: Figure out what killed an app (rhbz#2253099)

On Wed, 2024-01-31 at 12:19 +0100, Petr Pisar wrote: > This procedure works for me > . > The tracefs file system has a nice log. Hi, that works pretty well, thank you. Funny enough, if I read it correctly, it says

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

* Zbigniew Jędrzejewski-Szmek: > On Wed, Jan 31, 2024 at 06:43:00AM -, Abyss Ether via devel wrote: >> I created a simple PoC udev rule to mount USB Storage devices with the "sync >> option. >> Available here : >>

Re: Figure out what killed an app (rhbz#2253099)

On Wed, Jan 31, 2024 at 11:06:02AM +, Tom Hughes via devel wrote: > On 31/01/2024 10:08, Milan Crha wrote: > > > I tried to investigate a rawhide bug: > > https://bugzilla.redhat.com/show_bug.cgi?id=2253099 > > which is about Evolution being killed "by something". That's the thing, > > I do

Re: Figure out what killed an app (rhbz#2253099)

V Wed, Jan 31, 2024 at 11:08:16AM +0100, Milan Crha napsal(a): > Hi, > I tried to investigate a rawhide bug: > https://bugzilla.redhat.com/show_bug.cgi?id=2253099 > which is about Evolution being killed "by something". That's the thing, > I do not know what killed it, thus even why it had

Re: Figure out what killed an app (rhbz#2253099)

On 31/01/2024 10:08, Milan Crha wrote: I tried to investigate a rawhide bug: https://bugzilla.redhat.com/show_bug.cgi?id=2253099 which is about Evolution being killed "by something". That's the thing, I do not know what killed it, thus even why it had been killed. It's even not killed after

Fedora rawhide compose report: 20240130.n.1 changes

OLD: Fedora-Rawhide-20240130.n.0 NEW: Fedora-Rawhide-20240130.n.1 = SUMMARY = Added images:2 Dropped images: 4 Added packages: 3 Dropped packages:0 Upgraded packages: 191 Downgraded packages: 0 Size of added packages: 125.55 KiB Size of dropped packages:0

Re: poppler soname bump in Rawhide soon

Hi, On 1/30/24 12:15, Michael J Gruber wrote: Marek Kasik venit, vidit, dixit 2024-01-30 12:02:34: Hi, I plan to rebase poppler to 24.02.0 once it is released. It will be probably released this week and I would like to get it to rawhide before the branching together with rebuilds of dependent

Re: [rawhide] libavif soname bump

libavif-1.0.3 built in f40-build-side-82609. Proceeding with rebuilds... On Thu, Jan 25, 2024 at 11:37 AM Frantisek Zatloukal wrote: > > > On Thu, Jan 25, 2024 at 11:23 AM Richard W.M. Jones > wrote: > >> On Thu, Jan 25, 2024 at 11:14:04AM +0100, Frantisek Zatloukal wrote: >> > In about a week

Figure out what killed an app (rhbz#2253099)

Hi, I tried to investigate a rawhide bug: https://bugzilla.redhat.com/show_bug.cgi?id=2253099 which is about Evolution being killed "by something". That's the thing, I do not know what killed it, thus even why it had been killed. It's even not killed after certain steps, it's killed

[Bug 1936241] Compiled @INC in 5.32 No longer Includes Suitable Path For Custom System-Wide Modules

https://bugzilla.redhat.com/show_bug.cgi?id=1936241 --- Comment #4 from Petr Pisar --- You want an optimization for architecture independent modules. That understandable. However, that optimization would break reinstallation from CPAN that mixes architecture dependent and independent modules:

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

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

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

On Mi, 31.01.24 06:43, Fedora Development ML (devel@lists.fedoraproject.org) wrote: > I created a simple PoC udev rule to mount USB Storage devices with the "sync > option. > Available here : > https://github.com/larina3315/personal-stuff/blob/main/linux/10-usb-storage.rules > > Currently, USB

[Bug 2261386] mod_perl: FTBFS in F40: odperl_common_util.c:57:53: error: initialization of ‘int (*)(PerlInterpreter *, SV *, MAGIC *, SV *, const char *, I32)’

https://bugzilla.redhat.com/show_bug.cgi?id=2261386 Petr Pisar changed: What|Removed |Added Summary|mod_perl: FTBFS in F40: |mod_perl: FTBFS in F40:

[Bug 2261386] mod_perl: FTBFS in F40: odperl_common_util.c:57:53: error: initialization of ‘int (*)(PerlInterpreter *, SV *, MAGIC *, SV *, const char *, I32)’ {aka ‘int (*)(struct interpreter *, stru

https://bugzilla.redhat.com/show_bug.cgi?id=2261386 Petr Pisar changed: What|Removed |Added Hardware|Unspecified |i686 Doc Type|---

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

On Wed, Jan 31, 2024 at 06:43:00AM -, Abyss Ether via devel wrote: > I created a simple PoC udev rule to mount USB Storage devices with the "sync > option. > Available here : > https://github.com/larina3315/personal-stuff/blob/main/linux/10-usb-storage.rules > > Currently, USB Storage