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

[Neal Gompa]

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 support these packages being added. It is putting additional 
> > effort on the KDE-SIG up to once per every week; especially since we're at 
> > the beginning of the Plasma 6 release cycle and releases are going to be 
> > hectic.
> > The proposed resolutions by adamw, zbyszek, etc. seem to imply that it 
> > would not be required.
> > blogilo is as much of a non-release-blocking component as 
> > plasma-workspace-x11 would be.
> > --
>
> There I was referring to stable releases. I assume you're not going to
> rebuild and push updates into stable releases once per week.
>
> FWIW I am an happy user of Plasma on Wayland and don't need X11.
> However, Fedora is a community project, so the fact one don't care about
> a software doesn't mean they can stop someone else packaging it, as long
> as there someone interested in doing the work. If that means delaying
> updates by one week waiting for the other maintainers to rebuild their
> packages, we must allow that, as we do for all other cases.
>
> I am also quite sure that things would be much more simple for both
> parties if -x11 guys would make use of COPR instead of building their
> packages in distgit. That way they can choose to rebuild the kde plasma
> common stack with the epoch bumped, so that anyone using the COPR
> repository will have that packages overwrite the Fedora ones, and build
> their -x11 with their "LTS" version. That way anyone using X11 will not
> see any breakage and they can choose to upgrade the base packages when
> they want/have free time.
>

I started providing a COPR specifically for this reason a few months
ago[1], and we moved it to the KDE SIG namespace earlier this week[2].
It tracks our DistGit packages and turns back on X11 support
automatically. The KDE SIG instance of the COPR is configured with a
higher priority than the distribution packages, so they "overshadow"
them and prevent Plasma X11 from being uninstalled on upgrade by
blocking upgrades until a compatible package is available.

My position as the KDE SIG lead based on discussions within the SIG is
that re-introducing these packages in the main distribution would
destroy the main point of our efforts: driving KDE Plasma Wayland to
be the best and most complete experience. The signal of dropping
Plasma X11 largely drove a lot of improvements in Plasma 6 very
quickly that I do not believe would have otherwise occurred. The
upstream KDE developers did a lot of work for us because we
communicated priorities and worked with them very early to frame the
roadmap for the future of Plasma Wayland.

The truth is we started hitting a wall about two years ago because
with the crutch of Plasma X11, there was just simply not enough
motivation to find solutions for the remaining missing
features/capabilities. We started signaling our intent two years ago
to drop Plasma X11 with Plasma 6 at Akademy 2022, but even most of
that effort wasn't taken seriously until last year, when I reiterated
it again at Akademy there. A huge burst of feature development
occurred precisely because of the feedback from the discussion in the
Change proposal.

To put it bluntly, KDE Plasma Wayland has features and capabilities
that neither X11 nor GNOME Wayland has. There are both compatibility
modes (X11 hotkey support and alternate X11 application scaling modes)
and amazing features (VRR, fullscreen HDR, hardware accelerated screen
recording/sharing/remote desktop). The remaining gaps are being worked
on with a decent pace in a large part because Fedora KDE will only
offer Plasma Wayland. Today, there are people who consider Fedora KDE
a "premium experience"[3] and that's a tremendous credit to the team
who have worked really hard to deliver the best KDE Plasma experience
possible.

The consensus from the KDE SIG is that we believe that reintroducing
the packages into the distribution will not only unwind a major part
of the approved Change, but it will add complications for the SIG for
shipping updates to KDE Plasma on the cadence that we typically do and
we would rather the X11 packages stay in COPR.

[1]: https://copr.fedorainfracloud.org/coprs/ngompa/kde6-x11-unsupported/
[2]: https://copr.fedorainfracloud.org/coprs/g/kdesig/plasma6-x11-unsupported/
[3]: 
https://www.reddit.com/r/kde/comments/1advyxe/pretty_sure_fedora_40_will_be_the_premium/



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 

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

[Leigh Scott]

> 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 to see kkofler rant in every plasma update that their xorg 
> stack
> breaks?

kde users with nvidia are going to suffer if x11 is removed.
I wont be accepting any kde wayland issues filed at rpmfusion.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Leigh Scott]

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

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

[Mattia Verga via devel]

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 KDE-SIG up to once per every week; especially since we're at 
> the beginning of the Plasma 6 release cycle and releases are going to be 
> hectic.
> The proposed resolutions by adamw, zbyszek, etc. seem to imply that it would 
> not be required.
> blogilo is as much of a non-release-blocking component as 
> plasma-workspace-x11 would be.
> --

There I was referring to stable releases. I assume you're not going to 
rebuild and push updates into stable releases once per week.

FWIW I am an happy user of Plasma on Wayland and don't need X11. 
However, Fedora is a community project, so the fact one don't care about 
a software doesn't mean they can stop someone else packaging it, as long 
as there someone interested in doing the work. If that means delaying 
updates by one week waiting for the other maintainers to rebuild their 
packages, we must allow that, as we do for all other cases.

I am also quite sure that things would be much more simple for both 
parties if -x11 guys would make use of COPR instead of building their 
packages in distgit. That way they can choose to rebuild the kde plasma 
common stack with the epoch bumped, so that anyone using the COPR 
repository will have that packages overwrite the Fedora ones, and build 
their -x11 with their "LTS" version. That way anyone using X11 will not 
see any breakage and they can choose to upgrade the base packages when 
they want/have free time.

Mattia

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

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

[Florian Weimer]

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

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

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

[Kevin Kofler via devel]

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 forward with fixes to the
> new versions (either from upstream, or by the
> packager).

There are plenty of valid reasons to bump an Epoch. IMHO, reverting a 
Rawhide-only version bump that never made it to a stable release is not. I 
do not see why it cannot just be reverted.

Actually, the downgrade masquerading as an "upgrade" (due to the Epoch) only 
makes it more likely that any issues related to the downgrade (such as the 
ones the other Kevin, Kevin Fenzi, pointed out) will catch the user by 
surprise. If the distro-sync (which should be the default way to do updates 
at least on Rawhide, if not everywhere) mentions a package being downgraded, 
that is much more likely to be noticed.

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

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

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #12 from Fedora Update System  ---
FEDORA-2024-e1f11870f6 has been pushed to the Fedora 39 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2024-e1f11870f6`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2024-e1f11870f6

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2232294

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202232294%23c12
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Gary Buhrmaster]

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 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 forward with fixes to the
new versions (either from upstream, or by the
packager).

Sometimes the packager (or upstream) screws up,
and  the epoch bump is the "get out of  jail (mostly)
free card" for the packager.

If you don't want a "get out of jail (mostly) free
card", more power to you, for you are committing
to fix any/all issues.  Sometimes not every Fedora
packager has commit access to the upstream
sources.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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

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

[bugzilla]

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-
   |2.049-1.fc40|2.049-1.fc40
   |perl-Dist-Zilla-Plugin-Git- |perl-Dist-Zilla-Plugin-Git-
   |2.049-1.fc38|2.049-1.fc38
   ||perl-Dist-Zilla-Plugin-Git-
   ||2.049-1.fc39



--- Comment #7 from Fedora Update System  ---
FEDORA-2024-c68cc68da0 has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2256302

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202256302%23c7
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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 can leave things in a pretty unfortunate state.

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.

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

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

[bugzilla]

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-
   |2.049-1.fc40|2.049-1.fc40
   ||perl-Dist-Zilla-Plugin-Git-
   ||2.049-1.fc38
 Resolution|--- |ERRATA
 Status|ON_QA   |CLOSED
Last Closed||2024-02-01 01:24:51



--- Comment #6 from Fedora Update System  ---
FEDORA-2024-47f8bff7d3 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2256302

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202256302%23c6
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Unretire request idle and Go packages working through approval

[W. Michael Petullo]

> 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, then when that finishes a long time later, a new ticket is
> filed instead of updating the old one. ;(

Sorry about that. I learned of my mistake from the comments the crew
left therein!
 
> We are also working on automating unretirements... hopefully that will land
> soon and you will not need to wait on a manual process anymore. 

This would be a big deal, thank you! I have been patiently working through
14 Go packages with intermingled dependencies and it is slow going.
Speeding up the unretirements and instead waiting only on the reviews
would speed things up a lot.

-- 
Mike

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

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

[kevin]

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


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

Re: Unretire request idle and Go packages working through approval

[kevin]

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:
> 
> https://pagure.io/releng/issue/11880

Yeah, appologies... things have been very busy of late. I went and
processed that now.

However, a few things to mention: 

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, then when that finishes a long time later, a new ticket is
filed instead of updating the old one. ;(

We are also working on automating unretirements... hopefully that will land
soon and you will not need to wait on a manual process anymore. 

kevin


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

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

[updates]

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  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-272d6fcaca   
atril-1.26.2-1.el8
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-93d34f40f0   
chromium-121.0.6167.85-1.el8


The following builds have been pushed to Fedora EPEL 8 updates-testing

ansible-collection-containers-podman-1.12.0-5.el8
python-aiohttp-3.7.4-2.el8

Details about builds:



 ansible-collection-containers-podman-1.12.0-5.el8 (FEDORA-EPEL-2024-14d752a5a2)
 Podman Ansible collection for Podman containers

Update Information:

Bump to 1.12.0

ChangeLog:

* Tue Jan 30 2024 Sagi Shnaidman  - 1.12.0-1
- Bump to 1.12.0
* Mon Jan 22 2024 Fedora Release Engineering  - 
1.10.1-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
* Fri Jan 19 2024 Fedora Release Engineering  - 
1.10.1-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
* Wed Jul 19 2023 Fedora Release Engineering  - 
1.10.1-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
* Wed Jan 18 2023 Fedora Release Engineering  - 
1.10.1-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild

References:

  [ 1 ] Bug #2211545 - ansible-collection-containers-podman-1.11.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2211545




 python-aiohttp-3.7.4-2.el8 (FEDORA-EPEL-2024-11fae9c7fb)
 Python HTTP client/server for asyncio

Update Information:

Security fix for CVE-2024-23334

ChangeLog:

* Tue Jan 30 2024 Benjamin A. Beasley  - 3.7.4-2
- Backport patch for CVE-2024-23334 (fix RHBZ#2261892)

References:

  [ 1 ] Bug #2261887 - CVE-2024-23334 aiohttp: follow_symlinks directory 
traversal vulnerability
https://bugzilla.redhat.com/show_bug.cgi?id=2261887


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

Re: Orphaned python-mccabe (dependency of pylint)

[Miro Hrončok]

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 changes, the fedora bugzilla contact needs to be changed as well. 
I've just done that.


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

Re: Orphaned python-mccabe (dependency of pylint)

[Michel Lind]

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 dependency of pylint.
> 
Apologies for the hypothesmith breakage - it's not meant to last that
long but turns out updating hypothesmith requires bumping libcst first
and it now has a Rust component.

libcst is built, hypothesmith seems to build fine locally but the test
suite (using hypothesis) is ... not fast. I'll try and submit it ASAP.

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

-- 
Michel Lind (né Salim)
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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

Re: Orphaned python-mccabe (dependency of pylint)

[Michel Lind]

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 dependency of pylint.
> 
Apologies for the hypothesmith breakage - it's not meant to last that
long but turns out updating hypothesmith requires bumping libcst first
and it now has a Rust component.

libcst is built, hypothesmith seems to build fine locally but the test
suite (using hypothesis) is ... not fast. I'll try and submit it ASAP.

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

-- 
Michel Lind (né Salim)
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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

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

[Alessandro Astone]

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 at the 
beginning of the Plasma 6 release cycle and releases are going to be hectic.
The proposed resolutions by adamw, zbyszek, etc. seem to imply that it would 
not be required.
blogilo is as much of a non-release-blocking component as plasma-workspace-x11 
would be.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Mattia Verga via devel]

 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 updates? See example: 
> https://bodhi.fedoraproject.org/updates/FEDORA-2023-977de87584
>  
>  Am I going to have to see kkofler rant in every plasma update that their 
> xorg stack breaks?
>  --

Firstly, let's not make personal attacks.

The reported example refers to an update submitted for a stable release, where 
every effort in order to not to break things must be made. Was that happened 
before the side-tag update was pushed? imo, saying "blogilo is dead upstream 
and you're the only one left using it" is not enough.

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

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

[Alessandro Astone]

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

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

[Alessandro Astone]

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 to see kkofler rant in every plasma update that their xorg 
stack breaks?
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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

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

[Jitka Plesnikova]

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

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

[Chris Murphy]

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 causing 
things to get clobbered that shouldn't be.

The kernel OOM killer is strictly concerned about kernel survival in 
dramatically low memory situations. It is unconcerned about user space making 
progress. Hence user space oom managers.

I admit this is probably suboptimal in some cases. Full resource control is a 
better way of handling the ambiguity whether a program is incorrectly hogging 
resources versus simply doing its job. Resource control may not obviate a user 
space oom killer but I think what we really care about is giving a program all 
the resources it needs, up to the point that the user wants an interactive 
desktop - and then the kernel needs to (in effect) preempt the resource hungry 
processes in favor of user-desktop interactivity. Resource control can do this 
but we don't have everything wired up yet, more work is needed.


--
Chris Murphy
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Figure out what killed an app (rhbz#2253099)

[Paul Grosu]

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:

https://www.cjjackson.dev/posts/what-is-systemd-oomd-how-to-disable-it/

The man pages which other folks referred to is here (in case you want to
tweak with configuring it):

https://man7.org/linux/man-pages/man8/systemd-oomd.service.8.html

Hope it helps,
~p

On Wed, Jan 31, 2024 at 1:04 PM Michael Catanzaro 
wrote:

> 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 code does not seem to be called at this time (or my debug
> > code
> > was wrong, it's possible).
>
> That code is for terminating child processes. It's certainly not
> supposed to terminate itself.
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Michael Catanzaro]

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 code does not seem to be called at this time (or my debug 
code

was wrong, it's possible).


That code is for terminating child processes. It's certainly not 
supposed to terminate itself.


--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Figure out what killed an app (rhbz#2253099)

[Milan Crha]

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 had been more lines involving bwrap and WebKitWebProcess, if I
recall correctly (I closed the machine already and did not save the
full log, I'm sorry). The above lines were those directly involving the
evolution process. I did not want to spam the list with a too long log.
Bye,
Milan
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Figure out what killed an app (rhbz#2253099)

[Milan Crha]

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 to clean up after itself.

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 code does not seem to be called at this time (or my debug code
was wrong, it's possible).


There was an update on the bug #2253099 that also liferea is affected,
thus at least evo is not alone. There is suspect that either glib2 or
kernel update caused it, but who knows.
Bye,
Milan
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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

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

[rawhide]

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:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/40iot

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_40_RC_20240131.1_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_40_RC_20240131.1_General

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
--
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Stephen Smoogen]

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 that’s what’s happening here?
>
> I don't think so. flatpak does use seccomp filters [1], but on
> violations the syscalls should just fail with EPERM or ENOSYS, not kill
> the process.
>
>
Could the problem with evolution be really with something else and getting
masked out ? I saw there was another thread about bogofilter killing
evolution due to the database needing to change from berkeley to sqllite by
running a helper. If the helper is being run but it runs out of memory,
would that cause the whole chain of OOM ?




> [1]
>
> https://github.com/flatpak/flatpak/blob/d5f891e0035e50b24211688a7fa5f61924a2e51c/common/flatpak-run.c#L1791
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 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
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Figure out what killed an app (rhbz#2253099)

[Michael Catanzaro]

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 seccomp filters [1], but on 
violations the syscalls should just fail with EPERM or ENOSYS, not kill 
the process.


[1] 
https://github.com/flatpak/flatpak/blob/d5f891e0035e50b24211688a7fa5f61924a2e51c/common/flatpak-run.c#L1791


--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: poppler soname bump in Rawhide soon

[Tom Callaway]

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,
> > >>
> > >> 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 packages.
> > >>
> > >> I'll prepare the build in a side tag and will message relevant
> > >> maintainers to rebuild their packages there.
> > >>
> > >> The packages which will need rebuilds:
> > >>calligra
> > >>gambas3
> > >>gdal
> > >>gdcm
> > >>inkscape
> > >>kf5-kitinerary
> > >>libreoffice
> > >>pdf2djvu
> > >>scribus
> > >
> > > That list is surprisingly short. For example, poppler-glib requires a
> > > specific poppler version, and via poppler-glib-devel that affects more
> > > packages (zathura-pdf-poppler comes to my mind).
> > >
> > > Does libpoppler-glib stay at the same soname and "absorb" all poppler
> > > changes behind its ABI?
> >
> > yes, libpoppler-glib and other front-ends are stable so they'll stay on
> > their sonames. The soname which is going to be changed is soname of the
> > core library which is not stable. The packages mentioned above uses the
> > core library directly so we have to keep the unstable API available.
>
> Thanks, that clarifies everything.
>
> Cheers
> Michael
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #11 from Fedora Update System  ---
FEDORA-2024-e1f11870f6 has been submitted as an update to Fedora 39.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-e1f11870f6


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2232294

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202232294%23c11
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Jitka Plesnikova]

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

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

[Jitka Plesnikova]

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

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

[Clemens Lang]

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 "sent by the kernel from somewhere". It means the first signal does not
> come a user space. It's genuinly generated by kernel. E.g. when the process is
> killed for out-of-memory reason. However, in this case, I would expect kernel
> to log this event into dmesg. E.g. out-of-memory killer is very verbose in
> dmesg.
> 
> Strange thing is the second line. It reads that process 3211 (code=0 meads
> SI_USER, "sent by kill, sigsend, raise") sent SIGKILL to 3257. It's
> questionable how a process 3211 killed with the first signal can still emit
> signals. 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.


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?

For software that regularly deals with untrusted input, it doesn’t seem 
unreasonable that the developers might have implemented something like that, 
and a seccomp kill might actually look like that.


-- 
Clemens Lang
RHEL Crypto Team
Red Hat


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

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

[Jitka Plesnikova]

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

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

[Petr Pisar]

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 res=0
> 
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 "sent by the kernel from somewhere". It means the first signal does not
come a user space. It's genuinly generated by kernel. E.g. when the process is
killed for out-of-memory reason. However, in this case, I would expect kernel
to log this event into dmesg. E.g. out-of-memory killer is very verbose in
dmesg.

Strange thing is the second line. It reads that process 3211 (code=0 meads
SI_USER, "sent by kill, sigsend, raise") sent SIGKILL to 3257. It's
questionable how a process 3211 killed with the first signal can still emit
signals. 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.

-- Petr


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

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

[Michael Catanzaro]

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?


WebKitGTK doesn't use SIGKILL to clean up after itself. The parent 
process just closes its IPC socket to the child process, then the child 
should either (a) exit normally, or (b) crash itself, if its watchdog 
thread detects the main thread has hung.


On Wed, Jan 31 2024 at 11:08:16 AM +01:00:00, Milan Crha 
 wrote:

Jan 31 10:49:23 localhost.localdomain xdg-desktop-por[2697]: Realtime
error: Could not map pid: Could not determine pid namespace: Could not
find instance-id in process's /.flatpak-info


This one is https://bugs.webkit.org/show_bug.cgi?id=238403 (fixed 
recently)


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

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

[Stephen Gallagher]

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 if they are included in the main repository. From a purely
> > technical perspective, I think that we should state clearly that the
> > KDE SIG would be required only to provide advance notice of major
> > changes but would NOT be responsible for ensuring that these packages
> > adapt to them. Of course, communicating that to users is harder (and
> > they'll naturally report bugs to the wrong place in many cases), but I
> > think the KDE SIG is completely permitted to refuse and retarget any
> > issues that come up to the appropriate group.
> >
> >
> > > My proposal for consideration is this:
> > > "FESCo will allow these packages in the main Fedora repositories,
> > > however they may not be included by default on any release-blocking
> > > deliverable (ISO, image, etc.)"
>
> I think we should reword this proposal to address this point:
>
> "FESCo will allow these packages in the main Fedora repositories,
> however they may not be included by default on any release-blocking
> deliverable (ISO, image, etc.). The KDE SIG should provide a notice
> before major changes, but is NOT responsible for ensuring that these
> packages adapt."

I can absolutely support that.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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

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

[bugzilla]

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.
https://bugzilla.redhat.com/show_bug.cgi?id=2261386

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202261386%23c7
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[bugzilla]

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 this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2261386

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202261386%23c6
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Zbigniew Jędrzejewski-Szmek]

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 perspective, I think that we should state clearly that the
> KDE SIG would be required only to provide advance notice of major
> changes but would NOT be responsible for ensuring that these packages
> adapt to them. Of course, communicating that to users is harder (and
> they'll naturally report bugs to the wrong place in many cases), but I
> think the KDE SIG is completely permitted to refuse and retarget any
> issues that come up to the appropriate group.
> 
> 
> > My proposal for consideration is this:
> > "FESCo will allow these packages in the main Fedora repositories,
> > however they may not be included by default on any release-blocking
> > deliverable (ISO, image, etc.)"

I think we should reword this proposal to address this point:

"FESCo will allow these packages in the main Fedora repositories,
however they may not be included by default on any release-blocking
deliverable (ISO, image, etc.). The KDE SIG should provide a notice
before major changes, but is NOT responsible for ensuring that these
packages adapt."

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

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

[Sérgio Basto]

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 and foremost and that X11 support is
> > > intended as a migration-support tool rather than a first-class
> > > citizen.
> > 
> > Does it?  This is very much news to me, so I don't think you can
> > call
> > it "well-communicated".  We also have an XFCE desktop spin and
> > probably others that require X11.
> > https://fedoraproject.org/uk/spins/xfce/
> > 
> > In addition Wayland doesn't actually replace all the basic
> > functionality of X11 even after all these years, which is why I
> > need
> > to use it.
> 
> I'm in the same boat.  Back in September when this topic came up,
> folks were invited to write bugs so the missing functionality could
> presumably be worked on.
> 
> I wrote two bugs:
> 
> Bug 2239016 - Plasma(Wayland) does not honor window positioning when
> setting window geometry
> Bug 2239029 - Plasma(Wayland) does not save windows between sessions
> 
> For 2239016 the response was "That's just how wayland works" and for
> 2239029 someone added a reference to an upstream KDE bug (from 2021).
> 
> I realize that this is a volunteer-driven project, and that I cannot
> expect someone to address the above wayland limitations, especially
> since the wayland design philosophy appears to exclude such features.
> 
> But that doesn't change the fact that I need the missing
> functionality, and based on how this discussion is going, I
> personally doubt wayland will ever meet my needs.
> 
> I'm delighted that there are like-minded folks who want to maintain
> X11.  Please allow them to do so.
> 
> Steve


Steven, thank you for the serene explanations and for highlighting an
important point about waynland, wayland seems to miss some important
features. 



> > > 4) There was a comment on the FESCo ticket to the effect of '"you
> > > must
> > > move to Wayland because no one maintains X11!". Here are some
> > > people
> > > who are maintaining X11 packages, so let them do their thing.'
> > > This is
> > > misleading, as the move to Wayland is specifically because the
> > > upstream of X11 *itself* is largely unmaintained. These packages
> > > are
> > > not maintaining X11, they are adding new dependencies on it.
> > 
> > They're maintaining parts of the X11 stack.
> > 
> > > My proposal for consideration is this:
> > > "FESCo will allow these packages in the main Fedora repositories,
> > > however they may not be included by default on any release-
> > > blocking
> > > deliverable (ISO, image, etc.)"
> > 
> > It seems quite strong.  I'm unclear why having X11 packages and
> > spins
> > for those that want to use them is a problem.  It seems like the
> > missing functionality of Wayland is the bigger issue that needs to
> > be
> > addressed.
> > 
> > Rich.
> > 
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue


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

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

[bugzilla]

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

Andrew Bauer  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Comment #5 from Andrew Bauer  ---
Thanks Petr. I completely agree. Some of my other packages are failing on i686
as well. Seems it's due to the new GCC in rawhide.

At the moment, I'm not sure how to fix this, and I can't exclude i686 arch
because mod_perl is not a leaf package.

I have summitted a bug report upstream and will continue to search the
interwebs for clues.
https://rt.cpan.org/Public/Bug/Display.html?id=151469


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2261386

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202261386%23c5
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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" \
--ex "b exit" \
--ex "b __kill" \
--ex "b _kill" \
--ex "b _exit" \
--ex "b pidfd_send_signal" \
--ex "b tkill if sig==9" \
--ex r

and it did not catch any of these. The last lines are:

   [Thread 0x7fffd92006c0 (LWP 3086) exited]
   [New process 3080]

   Program terminated with signal SIGKILL, Killed.
   The program no longer exists.
   (gdb)

which may or may not mean it is sent by a different function, I guess.
I cannot tell how much time was between the kill signal and the "[New
process 3080]" line.

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

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

[Leon Fauster via devel]

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

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


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




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





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


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



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

unplugged.




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


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



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

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

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



--
Leon


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

Re: poppler soname bump in Rawhide soon

[Michael J Gruber]

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 would like to get it to rawhide before
> >> the branching together with rebuilds of dependent packages.
> >>
> >> I'll prepare the build in a side tag and will message relevant
> >> maintainers to rebuild their packages there.
> >>
> >> The packages which will need rebuilds:
> >>calligra
> >>gambas3
> >>gdal
> >>gdcm
> >>inkscape
> >>kf5-kitinerary
> >>libreoffice
> >>pdf2djvu
> >>scribus
> >
> > That list is surprisingly short. For example, poppler-glib requires a
> > specific poppler version, and via poppler-glib-devel that affects more
> > packages (zathura-pdf-poppler comes to my mind).
> >
> > Does libpoppler-glib stay at the same soname and "absorb" all poppler
> > changes behind its ABI?
>
> yes, libpoppler-glib and other front-ends are stable so they'll stay on
> their sonames. The soname which is going to be changed is soname of the
> core library which is not stable. The packages mentioned above uses the
> core library directly so we have to keep the unstable API available.

Thanks, that clarifies everything.

Cheers
Michael
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Zbigniew Jędrzejewski-Szmek]

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 or issues that take away from real
> requests to the kde sig, then perhaps things should be re-evaluated.

+1 to this. (And implicitly, to what at least Stephen, Adam, and Gary
wrote before in slightly different words. It seems that we arrived at
a consensus very quickly for a relatively controversial topic.)

Zbyszek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Figure out what killed an app (rhbz#2253099)

[Milan Crha]

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 evo killed itself (the first three bwrap-s are
probably unrelated, it could be when I opened and closed a composer,
which let WebKitGTK create a new WebKitWebProcess; the last line might
be when WebKitGTK cleans up after itself, or all the bwraps are at last
created by the WebKitGTK):

  bwrap-3756 [002] d..2.   341.677197: signal_generate: sig=9 errno=0 
code=0 comm=bwrap pid=3757 grp=1 res=1
  bwrap-3753 [000] d..2.   341.677296: signal_generate: sig=9 errno=0 
code=0 comm=bwrap pid=3754 grp=1 res=1
  bwrap-3856 [002] d..2.   345.231590: signal_generate: sig=9 errno=0 
code=0 comm=bwrap pid=3857 grp=1 res=1
  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 res=0

In such case, I might be able to catch this in gdb, right? Maybe with a
breakpoint in the `kill` function, and any other? These things are very
low-level for me, I'm sorry.

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

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

[Florian Weimer]

* 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 : 
>> https://github.com/larina3315/personal-stuff/blob/main/linux/10-usb-storage.rules
>> 
>> Currently, USB Storage devices are mounted without the "sync" option, 
>> causing their writes to be cached.
>> This causes an issue, especially with GUI file managers like GNOME Files, 
>> where after a file copy operation, it would notify the user that the 
>> operation has been completed. If the user then tries to unmount the USB 
>> Storage device, they get notified that data is still being written to disk 
>> and that they should not remove the USB Storage device from their 
>> PC/Laptop/device.
>
> 'sync' has some strong downsides though: various operations become
> painfully slow (this depends a lot on the hardware and its age, and
> the history of previous writes, etc.), write operations block read
> operations, and the total number of writes may be increased, leading
> to more wear on the hardware.

I think this is somewhat counteracted by Linux treating USB mass storage
devices as not having write caches (according to dmesg at least).
Doesn't this mean that those costly barriers won't be used?

Of course it also means that “sync” is not effective as we would like.

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

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

[Daniel P . Berrangé]

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 not know what killed it, thus even why it had been killed. It's
> > even not killed after certain steps, it's killed "randomly", on various
> > occasions.
> > 
> > I did search the internet, but they usually expect the killer is the
> > OOM service, which logs about the action either in the dmesg or in the
> > journal, but in this case there is no sign about whom killed it in
> > either of these logs.
> > 
> > The evolution terminal just says:
> > 
> > Killed
> 
> At the end of of the day it means a SIGKILL was sent to the process
> and that's not something that is logged anywhere as a matter of course
> so you're reliant on whatever sends it saying so.
> 
> You're right that OOM is the usual cause so if you've ruled that out
> you need to think about other things.
> 
> The problem is that SIGKILL is deliberately a very hard stop that
> nothing can trap so normal things like using strace or gdb to catch
> who went it aren't going to work.

The audit subsystem is probably the first choice to find out what's
killing it. Other than that, systemtap or eBPF scripts can be written
to trace this.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Figure out what killed an app (rhbz#2253099)

[Petr Pisar]

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 been killed. It's
> even not killed after certain steps, it's killed "randomly", on various
> occasions.
> 
> I did search the internet, but they usually expect the killer is the
> OOM service, which logs about the action either in the dmesg or in the
> journal, but in this case there is no sign about whom killed it in
> either of these logs.
>

This procedure works for me
. The
tracefs file system has a nice log. An example of /usr/bin/sleep receiving
SIGKILL from bash:

root@fedora-40:/sys/kernel/debug/tracing # cat trace
# tracer: nop
#
# entries-in-buffer/entries-written: 1/1   #P:4
#
#_-=> irqs-off/BH-disabled
#   / _=> need-resched
#  | / _---=> hardirq/softirq
#  || / _--=> preempt-depth
#  ||| / _-=> migrate-disable
#   / delay
#   TASK-PID CPU#  |  TIMESTAMP  FUNCTION
#  | | |   | | |
bash-4867[002] d..1. 10571.864270: signal_generate: sig=9 
errno=0 code=0 comm=sleep pid=4866 grp=1 res=0

-- Petr


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

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

[Tom Hughes via devel]

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 certain steps, it's killed "randomly", on various
occasions.

I did search the internet, but they usually expect the killer is the
OOM service, which logs about the action either in the dmesg or in the
journal, but in this case there is no sign about whom killed it in
either of these logs.

The evolution terminal just says:

Killed


At the end of of the day it means a SIGKILL was sent to the process
and that's not something that is logged anywhere as a matter of course
so you're reliant on whatever sends it saying so.

You're right that OOM is the usual cause so if you've ruled that out
you need to think about other things.

The problem is that SIGKILL is deliberately a very hard stop that
nothing can trap so normal things like using strace or gdb to catch
who went it aren't going to work.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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

Fedora rawhide compose report: 20240130.n.1 changes

[Fedora Rawhide Report]

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 B
Size of upgraded packages:   8.52 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   37.78 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: KDE live aarch64
Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-Rawhide-20240130.n.1.iso
Image: Comp_Neuro live x86_64
Path: Labs/x86_64/iso/Fedora-Comp_Neuro-Live-x86_64-Rawhide-20240130.n.1.iso

= DROPPED IMAGES =
Image: Kinoite ociarchive aarch64
Path: Kinoite/aarch64/images/Fedora-Kinoite-Rawhide.20240130.n.0.ociarchive
Image: Kinoite ociarchive x86_64
Path: Kinoite/x86_64/images/Fedora-Kinoite-Rawhide.20240130.n.0.ociarchive
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20240130.n.0.s390x.raw.xz
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20240130.n.0.s390x.qcow2

= ADDED PACKAGES =
Package: rust-cached_proc_macro-0.18.1-1.fc40
Summary: Generic cache implementations and simplified function memoization
RPMs:rust-cached_proc_macro+default-devel rust-cached_proc_macro-devel
Size:23.82 KiB

Package: rust-cached_proc_macro_types-0.1.1-1.fc40
Summary: Generic cache implementations and simplified function memoization
RPMs:rust-cached_proc_macro_types+default-devel 
rust-cached_proc_macro_types-devel
Size:16.94 KiB

Package: rust-pkcs1_0.2-0.2.4-1.fc40
Summary: Pure Rust implementation of PKCS#1 (RFC 8017)
RPMs:rust-pkcs1_0.2+alloc-devel rust-pkcs1_0.2+default-devel 
rust-pkcs1_0.2+pem-devel rust-pkcs1_0.2+pem-rfc7468-devel 
rust-pkcs1_0.2+std-devel rust-pkcs1_0.2+zeroize-devel rust-pkcs1_0.2-devel
Size:84.79 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  ORBit2-2.14.19-36.fc40
Old package:  ORBit2-2.14.19-33.fc39
Summary:  A high-performance CORBA Object Request Broker
RPMs: ORBit2 ORBit2-devel
Size: 1.75 MiB
Size change:  -8.39 KiB
Changelog:
  * Fri Jan 19 2024 Fedora Release Engineering  - 
2.14.19-34
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild

  * Mon Jan 22 2024 Fedora Release Engineering  - 
2.14.19-35
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild

  * Tue Jan 30 2024 Gwyn Ciesla  - 2.14.19-36
  - Patch for modern C.


Package:  R-XML-3.99.0.16.1-1.fc40
Old package:  R-XML-3.99.0.15-2.fc40
Summary:  Tools for Parsing and Generating XML Within R and S-Plus
RPMs: R-XML
Size: 7.82 MiB
Size change:  -16.43 KiB
Changelog:
  * Fri Jan 19 2024 Fedora Release Engineering  - 
3.99.0.15-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild

  * Mon Jan 22 2024 Fedora Release Engineering  - 
3.99.0.15-4
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild

  * Tue Jan 30 2024 Elliott Sales de Andrade  - 
3.99.0.15-5
  - Switch to SPDX license

  * Tue Jan 30 2024 Elliott Sales de Andrade  - 
3.99.0.16.1-1
  - Update to latest version


Package:  R-jqr-1.3.3-1.fc40
Old package:  R-jqr-1.2.3-4.fc39
Summary:  Client for 'jq', a 'JSON' Processor
RPMs: R-jqr
Size: 761.84 KiB
Size change:  -8.99 KiB
Changelog:
  * Fri Jan 19 2024 Fedora Release Engineering  - 
1.2.3-5
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild

  * Wed Jan 24 2024 Fedora Release Engineering  - 
1.2.3-6
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild

  * Tue Jan 30 2024 Elliott Sales de Andrade  - 
1.3.3-1
  - Update to latest version (#2239938)


Package:  SDL_image-1.2.12-37.fc40
Old package:  SDL_image-1.2.12-34.fc39
Summary:  Image loading library for SDL
RPMs: SDL_image SDL_image-devel
Size: 288.01 KiB
Size change:  7.11 KiB
Changelog:
  * Fri Jan 19 2024 Fedora Release Engineering  - 
1.2.12-35
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild

  * Mon Jan 22 2024 Fedora Release Engineering  - 
1.2.12-36
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild

  * Tue Jan 30 2024 Gwyn Ciesla  - 1.2.12-37
  - Fixes for modern C


Package:  alsa-tools-1.2.11-2.fc40
Old package:  alsa-tools-1.2.5-12.fc40
Summary:  Specialist tools for ALSA
RPMs: alsa-tools alsa-tools-firmware
Size: 1.53 MiB
Size change:  1.65 KiB
Changelog:
  * Mon Jan 29 2024 Jaroslav Kysela  - 1.2.11-2
  - Updated to 1.2.11


Package:  alsa-utils-1.2.11-1.fc40
Old package:  alsa-utils-1.2.10-3.fc40
Summary:  Advanced Linux Sound Architecture (ALSA) utilities
RPMs: alsa-topology-utils alsa-ucm-utils alsa-utils alsa-utils-alsabat
Size: 5.18 MiB
Size change:  -15.77 KiB
Changelog:
  * Mon Jan 29 2024 Jaroslav Kysela  - 1.2.11-1
  * Updated to 1.2.11

Re: poppler soname bump in Rawhide soon

[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 would like to get it to rawhide before
the branching together with rebuilds of dependent packages.

I'll prepare the build in a side tag and will message relevant
maintainers to rebuild their packages there.

The packages which will need rebuilds:
   calligra
   gambas3
   gdal
   gdcm
   inkscape
   kf5-kitinerary
   libreoffice
   pdf2djvu
   scribus


That list is surprisingly short. For example, poppler-glib requires a
specific poppler version, and via poppler-glib-devel that affects more
packages (zathura-pdf-poppler comes to my mind).

Does libpoppler-glib stay at the same soname and "absorb" all poppler
changes behind its ABI?


yes, libpoppler-glib and other front-ends are stable so they'll stay on 
their sonames. The soname which is going to be changed is soname of the 
core library which is not stable. The packages mentioned above uses the 
core library directly so we have to keep the unstable API available.


I'm sorry for not explaining this in the original message.


Michael


Regards
Marek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: [rawhide] libavif soname bump

[Frantisek Zatloukal]

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 (after mass rebuild before branching), I'll start
>> > with bumping libavif in rawhide from 0.11.x to 1.0.3
>> > ( https://src.fedoraproject.org/rpms/ libavif/pull-request/2 ,
>> > soname bump from 15 to 16).
>>
>> I'm confused .. Wouldn't it be better to do this after branching?
>> Otherwise you're introducing an SONAME bump into the stabilising
>> Fedora 40.
>>
>
> I would prefer to have this in F40 too (not to block gamescope rebases
> (which do require libavif >= 1.0) there for the lifetime of the F40
> release), and, this isn't a big of a risky rebase in my opinion (there will
> be more impactful and riskier rebases coming far later in the cycle, such
> as LLVM rebase, again, in my opinion).
>
> --
>
> Best regards / S pozdravem,
>
> František Zatloukal
> Senior Quality Engineer
> Red Hat
>


-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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

Figure out what killed an app (rhbz#2253099)

[Milan Crha]

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 "randomly", on various
occasions.

I did search the internet, but they usually expect the killer is the
OOM service, which logs about the action either in the dmesg or in the
journal, but in this case there is no sign about whom killed it in
either of these logs.

The evolution terminal just says:

   Killed

and the `dmesg | grep -i kill` only shows:

   [3.435200] systemd[1]: Listening on systemd-oomd.socket - Userspace
  Out-Of-Memory (OOM) Killer Socket.
   [6.051242] rfkill: input handler disabled
   [   22.579276] rfkill: input handler enabled
   [   23.539350] rfkill: input handler disabled

and `journalctl -xb | grep -i kill` doesn't reveal anything useful. The
`journalctl -xb | grep -i evolution` has as its last line:

   Jan 31 10:49:22 localhost.localdomain rtkit-daemon[826]:
   Successfully made thread 4820 of process 4640 (/usr/bin/evolution)
   owned by '1000' RT at priority 5.

which does not explain anything. Grepping for the 4640 (evo's PID)
didn't show anything either.

That being said, is there a way to figure out what killed the app,
please?

Thanks and bye,
Milan

P.S.: the above-pasted journalctl line is followed by these three,
which look suspicious, but maybe they are unrelated. I even do not know
whether they had been added immediately after the app was killed or
before it. At least the terminal should not matter, because evo is
killed when being started from the GUI too. Three log lines follow:

Jan 31 10:49:23 localhost.localdomain xdg-desktop-por[2697]: Realtime
error: Could not map pid: Could not determine pid namespace: Could not
find instance-id in process's /.flatpak-info

Jan 31 10:50:46 localhost.localdomain gnome-terminal-[2939]: void
terminal_screen_shell_preexec(VteTerminal*): assertion
 '!priv->between_preexec_and_precmd' failed

Jan 31 10:50:49 localhost.localdomain gnome-terminal-[2939]: void
terminal_screen_shell_preexec(VteTerminal*): assertion
 '!priv->between_preexec_and_precmd' failed
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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

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

[bugzilla]

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: Module A is in sitelib and
requires module B in sitearch. The user is unaware of B, he explicitly
installed A. After upgrading Fedora, A becomes broken because B is not
available. The user attempts to reinstall A, but that "succeeds" with an
explanation that A is already installed. Hence the user cannot repair it.

I was aware of the inconvenience the current approach brings, but weighting in
the CPAN problem and the fact other Linux distribution do it, I concluded that
this it the best compromise.
Current Fedora perl maintainers might have a different opinion.

If you want to argument with RHEL, please report your issue to Red Hat support
.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1936241

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%201936241%23c4
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Larina Loriasel via devel]

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

The udev rule only applies to USB Storage devices, and I think the total number 
of writes increasing only happens if the data to be written is changed 
constantly (e.g. writes that overlap on same region/block of a device)
Most USB Storage devices are used for storing simple, consecutive streams of 
data, such as Music, Pictures and other simple files and are not usually 
modified much, thus, I think enabling sync makes sense in this regard.
In my opinion, the benefits of mounting USB Storage devices with sync outweigh 
the detriments.
Writes blocking reads is concerning.
 
> We approach this problem from a different angle: the user is supposed
> to sync the filesystem before removing. Graphical environments have
> an "eject" button, and for non-graphical environments, the user
> just needs to do a sync manually.

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

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

My proposal was exclusively for USB Storage devices, not internal ones, as I 
can understand the benefits of async outweighing the detriments in the case of 
internal/network etc storage devices.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Lennart Poettering]

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 Storage devices are mounted without the "sync"
> option, causing their writes to be cached.  This causes an issue,
> especially with GUI file managers like GNOME Files, where after a
> file copy operation, it would notify the user that the operation has
> been completed. If the user then tries to unmount the USB Storage
> device, they get notified that data is still being written to disk
> and that they should not remove the USB Storage device from their
> PC/Laptop/device.
>
> This can take a more severe form if the user is using a CLI/GUI
> utility that DOES NOT inform the user that data is still being
> written, like the 'cp' CLI utility, the user might be misled into
> thinking that all writes have finished and plug the USB drive out,
> at which point data corruption due to unfinished writes occur.
>
> This is why, I think functionality should be included in Fedora
> Linux (or atleast in Fedora Workstation and other desktop spins)
> such that USB Storage devices are mounted with the "sync" options by
> default.

This tanks performance when writing to the device though. There's a
much better approach however: use an automount in between with a very
short timeout (2s or so). This means the mount appears continously
available from application PoV but the backing fs is only mounted for
a brief time around accesses. This allows caching and asynchronous
behaviour to work, but after 2s everything is forced out to disk
anyway and it is guaranteed the superblock of the disk is put back
into a clean state.

systemd supports this natively, for example with a simple
"systemd-mount -A /dev/sda1".

I wished the desktop UIs would use this, or that udisks would learn
such a mode too, and in fact default to it.

Lennart

--
Lennart Poettering, Berlin
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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

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

[bugzilla]

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:
   |odperl_common_util.c:57:53: |odperl_common_util.c:57:53:
   |error: initialization of|error: initialization of
   |‘int (*)(PerlInterpreter *, |‘int (*)(PerlInterpreter *,
   |SV *, MAGIC *, SV *, const  |SV *, MAGIC *, SV *, const
   |char *, I32)’ {aka ‘int |char *, I32)’
   |(*)(struct interpreter *,   |
   |struct sv *, struct magic   |
   |*, struct sv *, const char  |
   |*, lo   |




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2261386
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[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

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

   Hardware|Unspecified |i686
   Doc Type|--- |If docs needed, set a value
Summary|mod_perl: FTBFS in Fedora   |mod_perl: FTBFS in F40:
   |rawhide/f40 |odperl_common_util.c:57:53:
   ||error: initialization of
   ||‘int (*)(PerlInterpreter *,
   ||SV *, MAGIC *, SV *, const
   ||char *, I32)’ {aka ‘int
   ||(*)(struct interpreter *,
   ||struct sv *, struct magic
   ||*, struct sv *, const char
   ||*, lo



--- Comment #4 from Petr Pisar  ---
From i686 build.log:

gcc -I/builddir/build/BUILD/mod_perl-2.0.13/src/modules/perl
-I/builddir/build/BUILD/mod_perl-2.0.13/xs -I/usr/include/apr-1
-I/usr/include/apr-1  -I/usr/include/httpd -D_REENTRANT -D_GNU_SOURCE -O2
-flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall
-Wno-complain-wrong-lang -Werror=format-security
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m32 -march=i686 -mtune=generic
-msse2 -mfpmath=sse -mstackrealign -fasynchronous-unwind-tables
-fstack-clash-protection -fwrapv -fno-strict-aliasing -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/lib/perl5/CORE -DMOD_PERL
-DMP_COMPAT_1X -fgnu89-inline -DLINUX -D_LARGEFILE64_SOURCE -g -fPIC \
-c modperl_common_util.c && mv modperl_common_util.o modperl_common_util.lo
modperl_common_util.c:57:53: error: initialization of ‘int (*)(PerlInterpreter
*, SV *, MAGIC *, SV *, const char *, I32)’ {aka ‘int (*)(struct interpreter *,
struct sv *, struct magic *, struct sv *, const char *, long int)’} from
incompatible pointer type ‘int (*)(PerlInterpreter *, SV *, MAGIC *, SV *,
const char *, int)’ {aka ‘int (*)(struct interpreter *, struct sv *, struct
magic *, struct sv *, const char *, int)’} [-Wincompatible-pointer-types]
   57 |
modperl_table_magic_copy};
  |
^~~~

Since Koschei  is happy on
all 64-bit architecture, I conclude this is specific for 32-bit platforms.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2261386

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202261386%23c4
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[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 : 
> https://github.com/larina3315/personal-stuff/blob/main/linux/10-usb-storage.rules
> 
> Currently, USB Storage devices are mounted without the "sync" option, causing 
> their writes to be cached.
> This causes an issue, especially with GUI file managers like GNOME Files, 
> where after a file copy operation, it would notify the user that the 
> operation has been completed. If the user then tries to unmount the USB 
> Storage device, they get notified that data is still being written to disk 
> and that they should not remove the USB Storage device from their 
> PC/Laptop/device.

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

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

> This can take a more severe form if the user is using a CLI/GUI
> utility that DOES NOT inform the user that data is still being
> written, like the 'cp' CLI utility, the user might be misled into
> thinking that all writes have finished and plug the USB drive out,
> at which point data corruption due to unfinished writes occur.

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

Zbyszek


(*) There are extensive mechanisms to avoid loss of data, so
"may" does not mean it's likely.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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