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
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
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
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),
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
>
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
>
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
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:
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:
> 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
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.
>
https://bugzilla.redhat.com/show_bug.cgi?id=2261386
Andrew Bauer changed:
What|Removed |Added
Resolution|--- |RAWHIDE
Status|ASSIGNED
* 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
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.
> 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
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
>
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
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
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
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
>
https://bugzilla.redhat.com/show_bug.cgi?id=2261449
Petr Pisar changed:
What|Removed |Added
Resolution|--- |RAWHIDE
Status|ON_QA
https://bugzilla.redhat.com/show_bug.cgi?id=2261449
Petr Pisar changed:
What|Removed |Added
Status|ASSIGNED|ON_QA
Fixed In Version|
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
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
>> 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
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
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
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
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
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
*
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
> 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
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
> 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
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
35 matches
Mail list logo
