Re: Failure on fedora default backgrounds
On 2024-02-01 11:26 p.m., Neal Gompa wrote:
On Fri, Feb 2, 2024 at 2:04 AM Mamoru TASAKA wrote:
>
> Luya Tshimbalanga wrote on 2024/02/02 10:25:
>> Hello team,
>>
>> It appears a change within %{_kde4_datadir} macro caused failures on Rawhide
affecting default Fedora backgrounds starting from 21.
>> Could someone from KDE SIG address that issue? Thanks.
>>
>>
>> Here is an extract of failure[1] on for f35-backgrounds built on Rawhide:
>>
>>
>>
>> RPM build errors:
>> error: File must begin with "/": %{_kde4_datadir}/wallpapers/F35/
>> File must begin with "/": %{_kde4_datadir}/wallpapers/F35/
>> Child return code was: 1
>> '''
>>
>> Reference:
>> [1]https://koji.fedoraproject.org/koji/taskinfo?taskID=112257075
>>
>
> I am not KDE sig member, but the above failure is most likely due to
> the following change:
>
>
https://src.fedoraproject.org/rpms/kde-filesystem/c/3cc17949d085bef5476638f2fbade0f19dbcea32
>
> /usr/lib/rpm/macros.d/macros.kde4 (which provides %{_kde4_datadir} macro
definition)
> was moved from kde-filesystem.rpm to kde4-filesystem.rpm .
>
Yes, just add "BuildRequires: kde4-filesystem".
Thank you all for the solution. I notice I lack access to commit changes on
f21-backgrounds so proven packagers are welcome to do so. Thanks
--
___
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
Gary Buhrmaster wrote: > So, just to be clear, and to eliminate any > possible misinterpretation, you are > stating this is a one-person show at > this time? The Fedora package review policy states that the submitter automatically becomes the point of contact of the submitted packages. So, since I submitted those packages, if they are approved, I will be the one who will have to approve any comaintainers. By default, there will be none, which is just how the policy works. I believe from the discussions that there are already at least 1 or 2 people interested in comaintaining, but ultimately it is those people who will have to explicitly sign up for it. I obviously cannot announce somebody as a comaintainer without the alleged comaintainer's permission. Any interested people can already request comaintainership now (e.g., by replying to this mail), and I will almost certainly grant it (though I will have reservations about some specific types of requests, such as blanket admin permissions for the entire @kde-sig group), but of course contingent on the packages being approved (i.e., the FESCo hold on them being lifted, and the reviews subsequently passing), because there is nothing to comaintain before that point and also nowhere I can fill in those comaintainership requests before the dist-git Pagure repository is created. 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
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Sat, Feb 3, 2024 at 2:32 AM Kevin Kofler via devel
wrote:
>
> Gary Buhrmaster wrote:
> > For something that has the potential to
> > impact KDE users that would choose to
> > remain on X11, I would absolutely hope
> > there is more than just you involved in
> > the effort (busses, and vacations, happen).
> >
> > Having something like a KDE-X11-SIG
> > team (made up name), with a few known
> > active members, would probably go a long
> > way to reduce the concerns of others
> > regarding tracking (and taking) bugs, and
> > lack of timely updates, for something as
> > visible as the entire desktop.
>
> I welcome any comaintainers to the {kwin,plasma-workspace}-x11 packages (as
> long as they do not intend to abuse their access to retire the package
> without my agreement, of course). More helping hands = less work per person.
So, just to be clear, and to eliminate any
possible misinterpretation, you are
stating this is a one-person show at
this time?
--
___
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
Gary Buhrmaster wrote:
> For something that has the potential to
> impact KDE users that would choose to
> remain on X11, I would absolutely hope
> there is more than just you involved in
> the effort (busses, and vacations, happen).
>
> Having something like a KDE-X11-SIG
> team (made up name), with a few known
> active members, would probably go a long
> way to reduce the concerns of others
> regarding tracking (and taking) bugs, and
> lack of timely updates, for something as
> visible as the entire desktop.
I welcome any comaintainers to the {kwin,plasma-workspace}-x11 packages (as
long as they do not intend to abuse their access to retire the package
without my agreement, of course). More helping hands = less work per person.
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
Re: Help packaging go with its dependencies
On Fri, Feb 2, 2024 at 4:03 PM Priscila Gutierres wrote: > > I'm trying to package kubectl for Fedora, but I'm having a bad time with some > dependencies. > I created the specfile using go2rpm, and I'm using auto dependencies: > https://pastebin.com/fmvttDBt > > %generate_buildrequires > %go_generate_buildrequires > > But it is blaming that some dependencies are missing: > > Failed to resolve the transaction: > Package "go-rpm-macros-3.3.1-3.fc40.x86_64" is already installed. > No match for argument: golang(github.com/chai2010/gettext-go/gettext) It appears you are attempting to package a very old version of kubectl; this import path was removed 1.5 years ago: https://github.com/kubernetes/kubectl/commit/4bf64b98777b846942aacf6e787cec7764c5b576 > No match for argument: golang(github.com/russross/blackfriday) > No match for argument: golang(k8s.io/kubectl/pkg/generated) > > I could find, for example, golang-github-chai2010-gettext: > https://src.fedoraproject.org/rpms/golang-github-chai2010-gettext > But it isn't found when trying to create a mock package. > > Can someone please help me? -- ___ 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: Help packaging go with its dependencies
On Fri, Feb 02, 2024 at 06:02:13PM -0300, Priscila Gutierres wrote: > I'm trying to package kubectl for Fedora, but I'm having a bad time with > some dependencies. > I created the specfile using go2rpm, and I'm using auto dependencies: > https://pastebin.com/fmvttDBt > > %generate_buildrequires > %go_generate_buildrequires > > But it is blaming that some dependencies are missing: > > Failed to resolve the transaction: > Package "go-rpm-macros-3.3.1-3.fc40.x86_64" is already installed. > No match for argument: golang(github.com/chai2010/gettext-go/gettext) > No match for argument: golang(github.com/russross/blackfriday) > No match for argument: golang(k8s.io/kubectl/pkg/generated) > > I could find, for example, golang-github-chai2010-gettext: > https://src.fedoraproject.org/rpms/golang-github-chai2010-gettext > But it isn't found when trying to create a mock package. > Looks like that package provides golang(github.com/chai2010/gettext-go), as well as gettext-go/mo, /plural, and /po, but not gettext-go/gettext ❯ fedrq pkgs golang-github-chai2010-gettext-devel -F provides golang(github.com/chai2010/gettext-go) = 1.0.2-12.fc40 golang(github.com/chai2010/gettext-go/mo) = 1.0.2-12.fc40 golang(github.com/chai2010/gettext-go/plural) = 1.0.2-12.fc40 golang(github.com/chai2010/gettext-go/po) = 1.0.2-12.fc40 golang-github-chai2010-gettext-devel = 1.0.2-12.fc40 golang-ipath(github.com/chai2010/gettext-go) = 1.0.2-12.fc40 Curious, given upstream's go.mod lists github.com/chai2010/gettext-go without the additional /gettext: https://github.com/kubernetes/kubectl/blob/b73518af09755bb9607e8755e7fc111ee1adceb5/go.mod#L9 Seems like either %go_generate_buildrequires is doing the wrong thing, or the golang-github-chai2010-gettext package is not exporting the right virtual provide. Best regards, -- 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: Mounting USB Storage devices with "sync" option ?
Barry Scott wrote on Fri, Feb 02, 2024 at 08:07:46PM +:
> > On 2 Feb 2024, at 17:58, Florian Weimer wrote:
> > The second one is a standard SATA drive in an USB enclosure, and those
> > have write-reordering caches, as far as I understand it.
>
> We need a kernel storage expert to tell us the definitive truth on this stuff.
> I may be out of date on this stuff.
This isn't really my turf so I just "read the code" (as of 6.7), but...
> What I understand is that the drive will be told via the appropriate SCSI(?)
> command
> that it must not reorder the writes. Failure to implement that command means
> the
> drive will not have WHQL from Microsoft. Without WHQL its very hard to sell a
> drive
> in the market place.
What seems to happen is the other way around:
- the scsi layer sends a SENSE command to query what the drive supports,
but that fails ("No Caching mode page found")
- it then goes on to pick whatever default value is configured
(litteraly assuming the drive works as per the default, hence the
"Assuming drive cache: write through" message)
- In this write through mode the 'WCE' flag is set to 0, which'll in
turn configure the blk queue (linux side) to clear "QUEUE_FLAG_WC" and
"QUEUE_FLAG_HW_WC" flags
- Things are starting to get a little harder to follow from here, but it
looks like that flush ops when QUEUE_FLAG_WC isn't set will clear
REQ_PREFLUSH | REQ_FUA from the request, and if there was no data to
write straight out skip the op... (submit_bio_noacct around the "Filter
flush bio's early so that bio based drivers without flush support don't
have to worry about them." comment - I definitely could be
misunderstanding the code below)
- I also don't see anything that'd tell the disk about our assumption --
there's a "cache_type_store" function that'll expose a cache_type sysfs
knob for userspace to override, but at least kernel doesn't look like
it'll send a scsi command to set it by default.
Also, since we couldn't read the cache mode, there's no guarantee it'd
be settable in the first place.
So I think Florian is correct in that barriers won't be issued on
these disks, and if they internally have such a cache it'd probably be
unsafe...
Now does the disk itself know that it's in such an enclosure and
properly behaves as write through?
I think we'd have a lot more corruptions on our hands if it was
incorrect here, btrfs in particular is very sensitive to disks that
lie with barriers but I'm not sure how much it's used on such drivers.
I've had a quick look but didn't find any 'disk barrier sanity tool'
that'd issue a succession of write + flush ops in an order that'd be
easy to reorder (e.g. 13___2) for one to unplug the disk and then
check there was no hole after plugging it back in; if someone is aware
of one that'd be interesting to test on such an enclosed HDD.
(Of course, getting safe order back is no guarantee that the disk is
always consistent, but it's probably possible to come up with a few
patterns that often fail when manually misconfiguring a disk)
--
Dominique Martinet | Asmadeus
--
___
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 2262451] New: perl-URI-5.26 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2262451 Bug ID: 2262451 Summary: perl-URI-5.26 is available Product: Fedora Version: rawhide Status: NEW Component: perl-URI Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, ka...@ucw.cz, mspa...@redhat.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org, rhug...@redhat.com, rstr...@redhat.com Target Milestone: --- Classification: Fedora Releases retrieved: 5.26 Upstream release that is considered latest: 5.26 Current version/release in rawhide: 5.25-1.fc40 URL: https://metacpan.org/dist/URI/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/3485/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-URI -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2262451 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202262451%23c0 -- ___ 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
Help packaging go with its dependencies
I'm trying to package kubectl for Fedora, but I'm having a bad time with some dependencies. I created the specfile using go2rpm, and I'm using auto dependencies: https://pastebin.com/fmvttDBt %generate_buildrequires %go_generate_buildrequires But it is blaming that some dependencies are missing: Failed to resolve the transaction: Package "go-rpm-macros-3.3.1-3.fc40.x86_64" is already installed. No match for argument: golang(github.com/chai2010/gettext-go/gettext) No match for argument: golang(github.com/russross/blackfriday) No match for argument: golang(k8s.io/kubectl/pkg/generated) I could find, for example, golang-github-chai2010-gettext: https://src.fedoraproject.org/rpms/golang-github-chai2010-gettext But it isn't found when trying to create a mock package. Can someone please help me? -- ___ 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 ?
> On 2 Feb 2024, at 17:58, Florian Weimer wrote: > > The second one is a standard SATA drive in an USB enclosure, and those > have write-reordering caches, as far as I understand it. We need a kernel storage expert to tell us the definitive truth on this stuff. I may be out of date on this stuff. What I understand is that the drive will be told via the appropriate SCSI(?) command that it must not reorder the writes. Failure to implement that command means the drive will not have WHQL from Microsoft. Without WHQL its very hard to sell a drive in the market place. Barry -- ___ 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
On Fri, Feb 2, 2024 at 1:51 AM Kevin Kofler via devel
wrote:
> Unlike you ("you" = the KDE SIG), I actually believe I can probably keep my
> *-x11 packages on life support for some time even if and when KDE upstream
> drops their X11 support. Kinda like I have been doing for, e.g., Blogilo.
> Realistic would be until the release of Plasma 7, unless some Plasma 6.x
> introduces major changes that make it impractical. But I hope this is not
> going to be a concern for Fedora 40.
For something that has the potential to
impact KDE users that would choose to
remain on X11, I would absolutely hope
there is more than just you involved in
the effort (busses, and vacations, happen).
Having something like a KDE-X11-SIG
team (made up name), with a few known
active members, would probably go a long
way to reduce the concerns of others
regarding tracking (and taking) bugs, and
lack of timely updates, for something as
visible as the entire desktop.
--
___
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)’
https://bugzilla.redhat.com/show_bug.cgi?id=2261386 Andrew Bauer changed: What|Removed |Added Resolution|--- |RAWHIDE Status|ASSIGNED|CLOSED Last Closed||2024-02-02 18:12:58 --- Comment #9 from Andrew Bauer --- CLOSED RAWHIDE https://koji.fedoraproject.org/koji/taskinfo?taskID=112819630 -- 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%23c9 -- ___ 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 ?
* Barry Scott: > As I understand it the kernel will request that writes are not > cached. Which means that journaling file systems do in fact work well. The kernel messages I get look like this: kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0 kernel: sd 0:0:0:0: [sda] 15814656 512-byte logical blocks: (8.10 GB/7.54 GiB) kernel: sd 0:0:0:0: [sda] Write Protect is off kernel: sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00 kernel: sd 0:0:0:0: [sda] No Caching mode page found kernel: sd 0:0:0:0: [sda] Assuming drive cache: write through kernel: sd 0:0:0:0: [sda] Attached SCSI removable disk kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0 kernel: sd 0:0:0:0: [sda] Spinning up disk... kernel: sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16). kernel: sd 0:0:0:0: [sda] 7814035456 512-byte logical blocks: (4.00 TB/3.64 TiB) kernel: sd 0:0:0:0: [sda] 4096-byte physical blocks kernel: sd 0:0:0:0: [sda] Write Protect is off kernel: sd 0:0:0:0: [sda] Mode Sense: 53 00 10 08 kernel: sd 0:0:0:0: [sda] No Caching mode page found kernel: sd 0:0:0:0: [sda] Assuming drive cache: write through kernel: sd 0:0:0:0: [sda] Attached SCSI disk I thought that ‘Assuming drive cache: write through’ means that no barriers are used. The second one is a standard SATA drive in an USB enclosure, and those have write-reordering caches, as far as I understand it. 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
[Bug 2261386] mod_perl: FTBFS in F40: odperl_common_util.c:57:53: error: initialization of ‘int (*)(PerlInterpreter *, SV *, MAGIC *, SV *, const char *, I32)’
https://bugzilla.redhat.com/show_bug.cgi?id=2261386 --- Comment #8 from Andrew Bauer --- Scratch build succeeds, so I'm going to run with this patch. https://koji.fedoraproject.org/koji/taskinfo?taskID=112818639 -- 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%23c8 -- ___ 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 ?
> On 2 Feb 2024, at 11:30, Florian Weimer wrote: > > Yes, the kernel assumes that there are no such caches, but I think in > practice there are. I think this means that journaling file systems are > not working correctly, in the sense that you do not get just user data > loss if the device is unplugged prematurely, but also metadata > corruption. As I understand it the kernel will request that writes are not cached. Which means that journaling file systems do in fact work well. As an aside a few years ago (10+ years?) Microsoft found that HDDs where using caching to spoof benchmark results. But this was leading to support hell for Microsoft with user reporting corrupt file systems to them. What Microsoft did was refuse to issue WHQL for any disk that did not have a write through cache. We in Linux land benefit from this as spoofing hardware, I believe, is not a common occurrence any more. Barry -- ___ 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)
On Thu, 2024-02-01 at 09:44 +0100, Ondrej Mosnáček wrote: > On Thu, 1 Feb 2024 at 09:13, Milan Crha wrote: > > The kernel tracing log for sig==9 shows: > > > > gnome-terminal--2924[002] dN.2. 2520.462889: signal_generate: > > sig=9 errno=0 code=128 comm=alloc-too-much pid=3502 grp=1 res=0 > > > > There is no such thing (apart of the tracing log) when Evolution is > > suddenly killed, the logs are muted. That makes me believe it's not the > > OOM killer whom kills the application. I'm back at square 1; or maybe > > square 2, as I know possibly kernel sends it, but not why. > > Try running `echo stacktrace >/sys/kernel/tracing/trace_options` (as > root) and then collect the kernel trace again. That should give you a > backtrace of kernel functions from the signal generation, which could > help you/us to figure out the reason the process was killed. So, figured the easiest way to help trigger the kill here is to put load on the machine. $ stress-ng --cpu -1 --cpu-method all -t 5m --cpu-load 95 then starting evolution seems to do it almost every time shortly after start (I have around 200k messages in the folder its trying to display) I've enabled the stacktrace tracing option and like Milan set a sig==9 filter. And here is what I got in the trace buffer after it was killed # tracer: nop # # entries-in-buffer/entries-written: 34/34 #P:16 # #_-=> irqs-off/BH-disabled # / _=> need-resched # | / _---=> hardirq/softirq # || / _--=> preempt-depth # ||| / _-=> migrate-disable # / delay # TASK-PID CPU# | TIMESTAMP FUNCTION # | | | | | | evolution-9096[002] d..1. 1207.016489: signal_generate: sig=9 errno=0 code=128 comm=evolution pid=9096 grp=1 res=0 evolution-9096[002] d..1. 1207.016495: => trace_event_raw_event_signal_generate => __send_signal_locked => posix_cpu_timers_work => task_work_run => irqentry_exit_to_user_mode => asm_sysvec_apic_timer_interrupt evolution-9096[002] d..2. 1207.016564: signal_generate: sig=9 errno=0 code=0 comm=bwrap pid=9145 grp=1 res=0 evolution-9096[002] d..2. 1207.016568: => trace_event_raw_event_signal_generate => __send_signal_locked => do_send_sig_info => do_exit => do_group_exit => get_signal => arch_do_signal_or_restart => irqentry_exit_to_user_mode => asm_sysvec_apic_timer_interrupt ... and 32 other events of bwrap cleaning up. Does that shed any light? Other that is seems to be sending the signal to itself. -Yanko -- ___ 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
On Fri, 2024-02-02 at 14:42 +0100, Kevin Kofler via devel wrote: > Peter Hutterer wrote: > > Fedora still ships the previous release, server 1.20.x > > So should we not upgrade that to the latest upstream release (Xorg > 21.0)? I'm working on one pull request https://src.fedoraproject.org/fork/sergiomb/rpms/xorg-x11-server/c/ac2a6dbc9caa351f650f08461afe4196c756c801?branch=rawhide builds still fails here: + cp hw/dmx/doxygen/doxygen.conf.in /builddir/build/BUILDROOT/xorg-x11- server-21.1.11-1.fc38.x86_64//usr/share/xorg-x11-server- source/hw/dmx/doxygen/doxygen.conf.in cp: cannot stat 'hw/dmx/doxygen/doxygen.conf.in': No such file or directory https://bugzilla.redhat.com/show_bug.cgi?id=1949144 > 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 -- 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
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
Jonathan Bennett via devel wrote: > Hey folks, outside observer, and long-time Fedora user weighing in with > some thoughts. First off, I've been hyped to see Fedora lead the way > with finally making a real move to Wayland, and retire X11. And now I'm > fairly disappointed to hear that there's a real chance that move will > get killed. And especially that it's not because of a technical problem > or blocker bug. Well, "killed" is a really strong word for what amounts to resurrecting 2 packages to give users a choice. I am actually trying to prevent Plasma X11 support from being "killed". > It really seems like KDE-x11 would do better to live in a copr, with > whatever packages needs rebuilt to make it work. Probably a better > experience for everyone. I do not see how it is a better experience to have to enable an additional repository, for which dnf will warn the user that it is "unsupported" (even if it does not have that in the name as the kde6-x11-unsupported Copr does) than to have those packages available in the standard Fedora repository. > The proposal was to go to KDE 6 and drop X11 support. " KDE Plasma will > not offer an X11 session" That change was approved by FESCo. And from my > perspective running Fedora Rawhide and KDE 6, it looks great. We even > have HDR working! That's amazing! So let's go all in. Glad to hear that Plasma on Wayland is working so great for you. Nobody is taking that away from you. Wayland will still be the default (as it has been for a few releases already), and the X11 packages will not even be installed by default (in fact, they will be uninstalled by default when upgrading to Fedora 40! My packages do not change that). So you get to enjoy your "amazing" HDR etc. with no changes whatsoever. Nobody is taking that away from you. All I am asking, and willing to make happen, is to not take Plasma X11 away from us. 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
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
Peter Hutterer wrote: > Fedora still ships the previous release, server 1.20.x So should we not upgrade that to the latest upstream release (Xorg 21.0)? 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
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Fri, 2024-02-02 at 01:34 -0600, Jonathan Bennett via devel wrote: > Hey folks, outside observer, and long-time Fedora user weighing in > with > some thoughts. First off, I've been hyped to see Fedora lead the way > with finally making a real move to Wayland, and retire X11. And now > I'm > fairly disappointed to hear that there's a real chance that move will > get killed. And especially that it's not because of a technical > problem > or blocker bug. I don't understand , why you want the others use a crap of software, fully buggy, without many features , which is not supported by many (like nvidia) , because is new ? Who wants use Wayland and test it, may use wayland and test it, it is even the default . It is really difficult to me understand your point of view , users should be free to use what they want and have choices, It is really weird (for me) that you want that I use wayland and test wayland . > It really seems like KDE-x11 would do better to live in a copr, with > whatever packages needs rebuilt to make it work. Probably a better > experience for everyone. > > The proposal was to go to KDE 6 and drop X11 support. " KDE Plasma > will > not offer an X11 session" That change was approved by FESCo. And from > my > perspective running Fedora Rawhide and KDE 6, it looks great. We > even > have HDR working! That's amazing! So let's go all in. > > > --Jonathan Bennett > -- > ___ > 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 2261449] perl-Prima-1.71-3.fc40: FTBFS in F40: img/codec_Xpm.c:635:28: error: assignment to ‘Bool (*)(struct ImgCodec *, struct _ImgLoadFileInstance *)’ {aka ‘long int (*)(struct ImgCodec *, stru
https://bugzilla.redhat.com/show_bug.cgi?id=2261449 Petr Pisar changed: What|Removed |Added Resolution|--- |RAWHIDE Status|ON_QA |CLOSED Last Closed||2024-02-02 12:07:08 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2261449 -- ___ 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 2261449] perl-Prima-1.71-3.fc40: FTBFS in F40: img/codec_Xpm.c:635:28: error: assignment to ‘Bool (*)(struct ImgCodec *, struct _ImgLoadFileInstance *)’ {aka ‘long int (*)(struct ImgCodec *, stru
https://bugzilla.redhat.com/show_bug.cgi?id=2261449 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|ON_QA Fixed In Version||perl-Prima-1.71-4.fc40 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2261449 -- ___ 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 ?
On Wednesday, 31 January 2024 06:43:00 GMT 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. > 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. -- Coming at the problem in a different direction; the kernel has options to limit how much data is in flight to any given device, but the Fedora system doesn't set these. See https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-bdi for documentation. As per the experiment documented below, if we set per- device BDI options "sensibly" based on the device's performance, we'd be able to reduce the window of surprise for users, without forcing all writes to be unbuffered via the "sync" option; instead, we could reduce the buffer to under a second for removable devices, and thus ensure that the user isn't surprised by massive data loss when they remove a device. As a nice side-effect, these changes would also speed up unmount operations from a GUI, since it limits the amount of dirty data to be written back before the unmount completes. The experiment follows: First, there's global settings: [sfarnsworth@ USB]$ sysctl vm | grep dirty sysctl: permission denied on key 'vm.mmap_rnd_bits' sysctl: permission denied on key 'vm.mmap_rnd_compat_bits' vm.dirty_background_bytes = 0 vm.dirty_background_ratio = 10 vm.dirty_bytes = 0 vm.dirty_expire_centisecs = 3000 vm.dirty_ratio = 20 vm.dirty_writeback_centisecs = 1500 vm.dirtytime_expire_seconds = 43200 sysctl: permission denied on key 'vm.stat_refresh' This tells me that on my system, we use up to 10% of my total RAM (64 GiB) as buffering for writes without even accessing the device, and up to 20% as buffering before the kernel will force a process to wait while it writes data out to the device. I just plugged a 4 GiB USB 2.0 stick into my machine, and I get the following values: [sfarnsworth@ /sys/class/bdi/8:0]$ grep . * max_bytes:7245996032 max_ratio:100 max_ratio_fine:100 min_bytes:0 min_ratio:0 min_ratio_fine:0 grep: power: Is a directory read_ahead_kb:128 stable_pages_required:0 strict_limit:0 This tells the kernel that it can buffer up to 7 GiB of data (max_bytes), and it doesn't need to consider the per-device limit until it's exhausted a global dirty limit (strict_limit). The default kernel settings allow you to complete your write immediately if you've used not more than 10% of the total buffer. If I tell dd to write a gigabyte to the device with the dsync flag set to ensure that it writes data to the device before returning (although not metadata), I can see that the kernel is permitted to buffer a huge amount of data in terms of time taken to write everything out: [sfarnsworth@ USB]$ dd if=/dev/zero of=test bs=$((1024 * 1024)) count=1024 oflag=dsync 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 174.692 s, 6.1 MB/s I change the mount options to remove "flush", since this is a FAT32 stick, and the "flush" option causes the kernel to block on file close until the data is fully written: [sfarnsworth@USB]$ dd if=/dev/zero bs=$((1024 * 1024)) count=1024 of=test 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.664286 s, 1.6 GB/s This means we've buffered (quite happily) 3 minutes worth of writeback, which I'd have to wait for before removing the stick - but dd has already exited, so it's not "obvious" to me that I need to wait a long time. I now change the per-device BDI options for the USB stick, based on what I've found out above: [root@ 8:0]# echo $((10 * 1024 * 1024)) > max_bytes [root@ 8:0]# echo 1 > strict_limit [root@8:0]# pwd && grep . * /sys/devices/virtual/bdi/8:0 max_bytes:10475956 max_ratio:0 max_ratio_fine:1485 min_bytes:0 min_ratio:0 min_ratio_fine:0 grep: power: Is a directory read_ahead_kb:128 stable_pages_required:0 strict_limit:1 grep:
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
Dne 31. 01. 24 v 14:44 Zbigniew Jędrzejewski-Szmek napsal(a): 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." Maybe it would be worth of extending the proposal with something like that "the -x11 package maintainers have to actively monitor relevant components and reassign the -x11 issues appropriately". I would not be surprised if that is the case already, but this could officially relief the KDE SIG. Vít 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 OpenPGP_signature.asc Description: OpenPGP digital 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: Mounting USB Storage devices with "sync" option ?
>> On 31 Jan 2024, at 11:41, Florian Weimer wrote: >> >> 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? > > Isn’t that a reference to caches within the drive and not the buffer > cache in the kernel? Yes, the kernel assumes that there are no such caches, but I think in practice there are. I think this means that journaling file systems are not working correctly, in the sense that you do not get just user data loss if the device is unplugged prematurely, but also metadata corruption. 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Fri, Feb 2, 2024 at 10:47 AM Peter Hutterer wrote: > > On Thu, Feb 01, 2024 at 03:40:24PM +, Sérgio Basto wrote: > > On Thu, 2024-02-01 at 15:31 +0100, Leon Fauster via devel wrote: > > > Am 01.02.24 um 14:18 schrieb Sérgio Basto: > > > > > > > > > > The problem is not KDE SIG not support X11, the problem is KDE SIG > > > > want > > > > drop X11 and force user to use wayland . > > > > > > > > > Looking from the side I wonder If its the SIG or more the > > > circumstances > > > that everything is in a forward flow and the SIG is facing it. So, if > > > the best time was not two or one year ago, and obviously also not > > > now. > > > When then? The fact is that there must be a point in time when the > > > display server takes an evolution step forward. > > > > > > Pressure in such transition helps to get forward, so I understand the > > > SIGs POV. Albeit, from the practical POV there are some issue and > > > therefore X11 is still the place to be. > > > > > > Maybe some elaboration should be done about the current state of X11 > > > vs > > > Wayland (is it just nvidia?) and a timeframe calculation to have a > > > resolution. Maybe it won't look so bad then and a interim solution is > > > then more acceptable. > > > > > > I have an obvious answer is when the authors decide, in this case Xorg, > > when Xorg decides that it will stop supporting X11, like happened to > > Python2 or PHP5 and 7 or Gnome > > X.org (the ppl doing X development) doesn't work that way, there won't > be an official "we're no longer supporting this". More likely > development will languish (except for Xwayland) and actual Xorg releases > will be few and far in between, at unpredictable cadence and subject to > someone wanting to do it. > > The last Xorg release (21.0) from the master branch was in Oct 2021. The > only reason that one happened was because Povilas (who wanted a new > feature in X) stepped up and did the work of collecting the MRs and > doing the release maintainership. Every 21.x release since has been > backports and, especially more recently, a huge percentage are CVE fixes. > > Fedora still ships the previous release, server 1.20.x, which was > originally released from git master in 2018, the 1.20.14 version we're > on (excluding fixes and CVEs) is from Dec 2021. > > Xwayland on the other hand (which lives in the same git repo) continues > on its merry way with the 23.2 series branched as recently as last > August. But an Xwayland release does not include Xorg because, well, > there is little motivation to do more Xorg releases. > > When it comes down to it it "just" needs someone (trustworthy enough) to > step up and do them. Whether the releases get picked up immediately like in > the olden days is a different matter. But I doubt there'll be an X.org > statement of "we no longer support Xorg" anytime soon, even though that > is, to some extent functionally already true. > And even before that, things were already only limping along. That was happening for over a decade and in that timeframe *nobody* has wanted to step up and work on it. Wayland is the future because otherwise we have no graphics future, as things currently stand. This is why *every* graphical environment is *finally* working on their Wayland environments if they have any development resources at all. Last year, we had Cinnamon release its own experimental Wayland session with v6.0. Budgie is working on replacing X11 with Wayland this year. LXQt will be on Wayland with v2. Xfce is working on the same for v4.20. MATE is looking at Wayfire after previously looking at Mirco for Wayland. Pantheon has been working on it for over a year now and has an experimental session. Everyone is making a path to Wayland a priority because finally enough is done so that they can. -- 真実はいつも一つ！/ 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: 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 40 Rawhide 20240202.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 40 Rawhide 20240202.n.0. 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 Notable package version changes: anaconda - 20240130.n.0: anaconda-40.18-1.fc40.src, 20240202.n.0: anaconda-40.20-1.fc40.src python-blivet - 20240130.n.0: python-blivet-3.8.2-4.fc40.src, 20240202.n.0: python-blivet-3.9.0-1.fc40.src pykickstart - 20240130.n.0: pykickstart-3.51-3.fc40.src, 20240202.n.0: pykickstart-3.52-1.fc40.src lorax - 20240130.n.0: lorax-40.3-5.fc40.src, 20240202.n.0: lorax-40.4-1.fc40.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/40 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_40_Rawhide_20240202.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_40_Rawhide_20240202.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_40_Rawhide_20240202.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_40_Rawhide_20240202.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_40_Rawhide_20240202.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_40_Rawhide_20240202.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_40_Rawhide_20240202.n.0_Security_Lab 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Thu, Feb 01, 2024 at 03:40:24PM +, Sérgio Basto wrote: > On Thu, 2024-02-01 at 15:31 +0100, Leon Fauster via devel wrote: > > Am 01.02.24 um 14:18 schrieb Sérgio Basto: > > > > > > > The problem is not KDE SIG not support X11, the problem is KDE SIG > > > want > > > drop X11 and force user to use wayland . > > > > > > Looking from the side I wonder If its the SIG or more the > > circumstances > > that everything is in a forward flow and the SIG is facing it. So, if > > the best time was not two or one year ago, and obviously also not > > now. > > When then? The fact is that there must be a point in time when the > > display server takes an evolution step forward. > > > > Pressure in such transition helps to get forward, so I understand the > > SIGs POV. Albeit, from the practical POV there are some issue and > > therefore X11 is still the place to be. > > > > Maybe some elaboration should be done about the current state of X11 > > vs > > Wayland (is it just nvidia?) and a timeframe calculation to have a > > resolution. Maybe it won't look so bad then and a interim solution is > > then more acceptable. > > > I have an obvious answer is when the authors decide, in this case Xorg, > when Xorg decides that it will stop supporting X11, like happened to > Python2 or PHP5 and 7 or Gnome X.org (the ppl doing X development) doesn't work that way, there won't be an official "we're no longer supporting this". More likely development will languish (except for Xwayland) and actual Xorg releases will be few and far in between, at unpredictable cadence and subject to someone wanting to do it. The last Xorg release (21.0) from the master branch was in Oct 2021. The only reason that one happened was because Povilas (who wanted a new feature in X) stepped up and did the work of collecting the MRs and doing the release maintainership. Every 21.x release since has been backports and, especially more recently, a huge percentage are CVE fixes. Fedora still ships the previous release, server 1.20.x, which was originally released from git master in 2018, the 1.20.14 version we're on (excluding fixes and CVEs) is from Dec 2021. Xwayland on the other hand (which lives in the same git repo) continues on its merry way with the 23.2 series branched as recently as last August. But an Xwayland release does not include Xorg because, well, there is little motivation to do more Xorg releases. When it comes down to it it "just" needs someone (trustworthy enough) to step up and do them. Whether the releases get picked up immediately like in the olden days is a different matter. But I doubt there'll be an X.org statement of "we no longer support Xorg" anytime soon, even though that is, to some extent functionally already true. Cheers, Peter > > In fact, it is something I've been thinking about, IMHO, downstream > shouldn't decide when software is deprecated or not like KDE and Red > HAt did , it's weird to me [1], although in RHEL we could have the > packages via EPEL, I think, and RHEL 10 is only in a year and a half > > > [1] > https://www.reddit.com/r/linux/comments/13c7hfk/red_hat_considers_xorg_deprecated_and_will_remove/ > > > > -- > > 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 > > -- > 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 -- ___ 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 ?
On 2/2/24 10:25, Lennart Poettering wrote: Another possible approach: run "sync -f" every 3 seconds. While that should make sure the unwritten data hits the disk it doesn't put the superblock in order to mark it as "this fs has been cleanly unmounted". That's quite limiting. Sure. Sounds like a possible improvement at kernel level: - half-unmount: sync the data, write a clean superblock, keep the memory cache alive, when a new write happens make the superblock dirty again Sort of "suspend/wakeup" for filesystems. Should be a cousin of FIFREEZE / FITHAW ioctl for quiescing. Regards. -- Roberto Ragusamail at robertoragusa.it -- ___ 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
SPDX Statistics - Selkirk edition
Hot news: Richard and I had several days PTOs, so the progress of MR in fedora-license-data was affected by this. Now lets dive into numbers: Two weeks ago we had: * 23681 spec files in Fedora * 30232license tags in all spec files * 11697 tags have not been converted to SPDX yet * 5264tags can be trivially converted using `license-fedora2spdx` * Progress: 61,31% ░░ 100% ELN subset: 250 out of 2439 packages are not converted yet (progress 89.75%) Today we have: * 23711spec files in Fedora * 30306license tags in all spec files * 11542 tags have not been converted to SPDX yet * 5193 tags can be trivially converted using `license-fedora2spdx` * Progress: 61,92% ░░ 100% ELN subset: 217 out of 2766 packages are not converted yet (progress 92.15%) Graph of these data with the burndown chart: https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807rpCjus-8s/edit?usp=sharing The list of packages needed to be converted is here: https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final.txt List by package maintainers is here https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final-maintainers.txt List of packages from ELN subset that needs to be converted: https://pagure.io/copr/license-validate/blob/main/f/eln-not-migrated.txt New version of fedora-license-data has been released. With 3 new licenses (plus some public domain declarations). 28 licenses are waiting to be review by SPDX.org (and then to be added to fedora-license-data) https://gitlab.com/fedora/legal/fedora-license-data/-/issues/?label_name%5B%5D=SPDX%3A%3Ablocked Legal docs and especially https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ was updated too. License analysis of remaining packages: http://miroslav.suchy.cz/fedora/spdx-reports/ New projection when we will be finished is 2025-01-05 (+15 days from last report). Pure linear approximation. If your package does not have neither git-log entry nor spec-changelog entry mentioning SPDX and you know your license tag matches SPDX formula, you can put your package on ignore list https://pagure.io/copr/license-validate/blob/main/f/ignore-packages.txt Either pull-request or direct email to me is fine. Why Selkirk edition? On this day, in 1709 Alexander Selkirk was rescued after living as a castaway for four years and four months. His story heavily inspired Daniel Defoe to write Robinson Crusoe. https://en.wikipedia.org/wiki/Alexander_Selkirk Miroslav -- ___ 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 ?
On Fr, 02.02.24 10:10, Roberto Ragusa (m...@robertoragusa.it) wrote: > On 1/31/24 09:41, Lennart Poettering wrote: > > > 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". > > > > Another possible approach: run "sync -f" every 3 seconds. While that should make sure the unwritten data hits the disk it doesn't put the superblock in order to mark it as "this fs has been cleanly unmounted". That's quite limiting. 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
Re: Mounting USB Storage devices with "sync" option ?
> On 31 Jan 2024, at 11:41, Florian Weimer wrote: > > 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? Isn’t that a reference to caches within the drive and not the buffer cache in the kernel? It is the kernel buffer cache flushing that eject/umount triggers getting written out. Barry -- ___ 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 ?
On 1/31/24 09:41, Lennart Poettering wrote: 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". Another possible approach: run "sync -f" every 3 seconds. The filesystem will still be dirty, but data should be there for careless users too. But performance will not be ideal. On the other hand it avoids a problem that your continuous mount/umount has: read cache is lost as soon as the device is not continuously active, which is not optimal. Regards. -- Roberto Ragusamail at robertoragusa.it -- ___ 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
> Am 01.02.2024 um 16:47 schrieb Steve Cossette : > > On 2024-02-01 10:27 a.m., Peter Boy wrote: >> >> Sorry, a bit off-topic here, but nevertheless: >> >>> Am 01.02.2024 um 15:14 schrieb Steve Cossette : >>> >> >> > Will do! Thanks, see you there -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@fedoraproject.org Timezone: CET (UTC+1) / CEST (UTC+2) Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast -- ___ 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 ?
On 1/31/24 00:57, Larina Loriasel via devel wrote: 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. As far as I know, every operating system does it the same way, so it's not as if users should be unaccustomed to dealing with this correctly. I've told windows users since windows existed that you need to "eject" the usb drive before taking it out. I don't know if windows syncs more aggressively though. I haven't actually tested how long it takes to eject after copying large amounts of data. I think that's something that can be tuned in Linux. -- ___ 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
