Almost and another issue occurred when doing a scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=46986219
It seems related to cycles
On 2020-07-10 9:06 a.m., Miro Hrončok wrote:
On 10. 07. 20 17:22, Luya Tshimbalanga wrote:
Right, upstream provided a patch which landed on Ra
Le vendredi 10 juillet 2020 à 08:55 -0400, Przemek Klosowski a écrit :
>
> The marginal cost of a digital key has got to be smaller than the
> marginal cost of the button
The marginal cost of a button is completely marginal, on devices that
already include other buttons, on a assembly line that
On Friday, July 10, 2020 11:45:06 PM MST Samuel Sieb wrote:
> On 7/10/20 10:55 PM, John M. Harris Jr wrote:
>
> > I demonstrated how it adds ~1ms to requests. That's one of the major
> > downsides to using FastCGI, and it's unavoidable.
>
>
> You didn't demonstrate anything, you made an unsubsta
On Sat, 2020-07-11 at 08:43 +0200, Igor Raits wrote:
> On Fri, 2020-07-10 at 15:55 -0400, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Reserve_resources_for_active_user_WS
> >
> > == Summary ==
> > This proposal adds cgroup based resource protections for the active
> > graphical se
On 7/11/20 1:09 AM, John M. Harris Jr wrote:
It's demonstrably false that php-fpm "saves hundreds" of milliseconds, unless
you're counting up every single saved ms over the course of a server's
runtime. It's not really faster than mod_php, except in cases where opcache is
used, and you can config
On Saturday, July 11, 2020 1:34:12 AM MST Samuel Sieb wrote:
> On 7/11/20 1:09 AM, John M. Harris Jr wrote:
>
> > It's demonstrably false that php-fpm "saves hundreds" of milliseconds,
> > unless you're counting up every single saved ms over the course of a
> > server's runtime. It's not really fa
On Tue, Jul 7, 2020 at 6:17 AM Gerd Hoffmann wrote:
>
> On Mon, Jul 06, 2020 at 01:26:31PM -0700, John M. Harris Jr wrote:
> > I guess that shows how unfamiliar I am with UEFI boot Fedora. You would
> > encrypt /boot to ensure that your boot images have not been tampered with,
>
> Well, if that i
On Fri, Jul 10, 2020 at 03:55:20PM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/XorgUtilityDeaggregation
>
> == Summary ==
>
> The collection packages
> `xorg-x11-{apps,font-utils,server-utils,utils,xkb-utils}` will be
> retired, and the individual utilities within them will
On Sat, Jul 11, 2020 at 10:03:47AM +0200, Nicolas Mailhot via devel wrote:
> The marginal cost of a button is completely marginal, on devices that
> already include other buttons, on a assembly line that already builds a
> ton of such things.
Marginal costs are still costs. They add up _very_ qu
On Fri, 10 Jul 2020 20:05:07 +0200, Kevin Fenzi wrote:
> Perhaps a compromise could be to generate them for rawhide builds, but
> not stable releases and if someone needs to debug things ask them to use
> the rawhide one/debuginfo?
That is not useful, system debuginfos are there to catch bugs easi
> That said, as one of the change owners, I *want* to know about your
> issues.
Yes, I understand. It's just that I believe that the burden of proof is on my
shoulders to prove that I have this and that issue before making bug reports.
The problem I often face with btrfs is that it is highly inc
BTRFS WA is ~8 times higher than ext4. Average profit from compression about
50% max. Not that hard arithmetic.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Con
Artem Tim wrote on Sat, Jul 11, 2020:
> BTRFS WA is ~8 times higher than ext4. Average profit from compression
> about 50% max. Not that hard arithmetic.
It's not that simple.
The pattern used in that paper is far from a standard workload (random
writes within a file with cow is just about as bad
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Sat, 2020-07-11 at 10:33 +0200, Benjamin Berg wrote:
> On Sat, 2020-07-11 at 08:43 +0200, Igor Raits wrote:
> > On Fri, 2020-07-10 at 15:55 -0400, Ben Cotton wrote:
> > >
> > > https://fedoraproject.org/wiki/Changes/Reserve_resources_for_active_
On Sat, Jul 11, 2020 at 2:28 pm, Igor Raits
wrote:
My question was more targeted whether we are not going to ship anymore
earlyoom by default with this change or will they be both shipped at
thie moment until something better is ready?
We'll continue to ship earlyoom for the foreseeable future
On Sat, Jul 11, 2020 at 5:55 AM Antti wrote:
> For example btrfs has for a long-time had this issue where after several
> months and being maybe more than 75% of disk space being in use, that when
> run on SSDs, system can randomly stops reading from the file system, starts
> thinking and then
Hi,
I'm not sure if this is a bug and if it is, where it is...
$ coredumpctl gdb
...
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/lib/systemd/systemd-oomd'.
Program terminated with signal SIGABRT, Aborted.
warning: Unexpected size of section `.reg-xstat
On Fri, Jul 10, 2020 at 11:14 AM Vitaly Zaitsev via devel
wrote:
>
> On 26.06.2020 16:42, Ben Cotton wrote:
> > ** transparent compression: significantly reduces write amplification,
> > improves lifespan of storage hardware
>
> What can you say about this? https://arxiv.org/pdf/1707.08514.pdf
Th
On Sat, Jul 11, 2020 at 6:11 AM Artem Tim wrote:
>
> BTRFS WA is ~8 times higher than ext4. Average profit from compression about
> 50% max. Not that hard arithmetic.
The paper is with respect to metadata write amplification. This has no
effect on data writes. Compression applies to data writes,
On Fri, Jul 10, 2020 at 1:45 PM Tomasz Torcz wrote:
>
> On Fri, Jul 10, 2020 at 07:14:09PM +0200, Vitaly Zaitsev via devel wrote:
> > On 26.06.2020 16:42, Ben Cotton wrote:
> > > ** transparent compression: significantly reduces write amplification,
> > > improves lifespan of storage hardware
> >
I think if we really want to advocate for btrfs, we also should provide the
tools to take full advantage of it. I've been using btrfs since it was
offered as an option on Fedora. On Ubuntu, there is a tool "snapper" to
help manage snapshots. Unfortunately I didn't manage to get this setup on
Hello team,
I attempt to build openshadinglanguage. For some reasons, cmake keeps on
claiming c++14 is required for LLVM10 despite the inclusion of
parameter. Can someone investigate it?
Build result:
https://download.copr.fedorainfracloud.org/results/luya/openshadinglanguage/fedora-rawhide-
Dear all,
I am coding as a hobby, besides a day job totally different.
Recently, I developed the Full Text Search based on Xapian for Dovecot
* https://doc.dovecot.org/configuration_manual/fts/
* https://github.com/grosjo/fts-xapian/
I am now giving a second life to Tomboy and Tombroid applicat
On Sat, 2020-07-11 at 18:04 +0100, Joan Moreau via devel wrote:
>
> I am now learning how to maintain packages, and especially on Tomboy
> - AUR (ArchLInux) version :
> https://aur.archlinux.org/packages/tomboy-reborn-bin
> - RPM (Fedora) :
>
> https://github.com/grosjo/tomboy-reborn/blob/mas
>
> My suggestion is to stop the 'complaining for the sake of complaining'
> phase of the feature. And move to the "when I do X Y Z, this other app
> is killed off - how to tweak this?" And then does the tweak represent
> covering an edge case? Or is it good enough to be the new default?
>
>
Nice,
On Sat, 2020-07-11 at 07:33 -0500, Michael Catanzaro wrote:
> On Sat, Jul 11, 2020 at 2:28 pm, Igor Raits
> wrote:
> > My question was more targeted whether we are not going to ship anymore
> > earlyoom by default with this change or will they be both shipped at
> > thie moment until something be
On Sat, 2020-07-11 at 12:05 -0400, Neal Becker wrote:
> I think if we really want to advocate for btrfs, we also should
> provide the
> tools to take full advantage of it. I've been using btrfs since it
> was
> offered as an option on Fedora. On Ubuntu, there is a tool "snapper"
> to
> help man
Solomon,
On 2020-07-11 21:41, Solomon Peachy wrote:
On Sat, Jul 11, 2020 at 10:03:47AM +0200, Nicolas Mailhot via devel
wrote:
The marginal cost of a button is completely marginal, on devices that
already include other buttons, on a assembly line that already builds
a
ton of such things.
M
On Saturday, 11 July 2020 18:46:18 CEST Luya Tshimbalanga wrote:
> Hello team,
>
> I attempt to build openshadinglanguage. For some reasons, cmake keeps on
> claiming c++14 is required for LLVM10 despite the inclusion of
> parameter. Can someone investigate it?
>
> Build result:
>
> https://do
I'm not sure if this is a bug and if it is, where it is...
$ coredumpctl gdb
...
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/lib/systemd/systemd-oomd'.
Program terminated with signal SIGABRT, Aborted.
warning: Unexpected size of section `.reg-xstate/
On Sun, Jul 12, 2020 at 03:35:05AM +1000, Philip Rhoades wrote:
> > Marginal costs are still costs. They add up _very_ quickly.
> >
> > If they can save $0.01 by eliminating a physical button, over a
> > million-unit production run that's a cool $1 million of potantial
> > profit.
> Really?
Yea
On Sat, Jul 11, 2020 at 11:32 AM Sergio Belkin wrote:
>>
>> My suggestion is to stop the 'complaining for the sake of complaining'
>> phase of the feature. And move to the "when I do X Y Z, this other app
>> is killed off - how to tweak this?" And then does the tweak represent
>> covering an edge
On 11/07/20 01:44 -0700, John M. Harris Jr wrote:
I said that php-fpm was fast than mod_php, however it's just not a huge
When?
I see the opposite claim, repeatedly:
On 10/07/20 18:38 -0700, John M. Harris Jr wrote:
They've been running just fine for years. I don't see any reason to lose
per
On Sat, 2020-07-11 at 14:31 -0300, Sergio Belkin wrote:
> My only question is if measuring memory pressure is a better indication.
> If nohang-desktop uses PSI, isn't it a more proper solution?
The basic problem is that PSI can only be reactive. You need to measure
it over a period of time and the
On Saturday, 11 July 2020 20:04:17 CEST you wrote:
> On Saturday, 11 July 2020 18:46:18 CEST Luya Tshimbalanga wrote:
> > Hello team,
> >
> > I attempt to build openshadinglanguage. For some reasons, cmake keeps on
> > claiming c++14 is required for LLVM10 despite the inclusion of
> > parameter. C
El sáb., 11 jul. 2020 a las 16:39, Benjamin Berg ()
escribió:
> On Sat, 2020-07-11 at 14:31 -0300, Sergio Belkin wrote:
> > My only question is if measuring memory pressure is a better indication.
> > If nohang-desktop uses PSI, isn't it a more proper solution?
>
> The basic problem is that PSI ca
On Saturday, July 11, 2020 11:47:30 AM MST Jonathan Wakely wrote:
> On 11/07/20 01:44 -0700, John M. Harris Jr wrote:
>
> >I said that php-fpm was fast than mod_php, however it's just not a huge
>
>
> When?
>
> I see the opposite claim, repeatedly:
>
> On 10/07/20 18:38 -0700, John M. Harris J
On Saturday, July 11, 2020 11:43:29 AM MST Chris Murphy wrote:
> It's known from the outset that earlyoom is temporary. And as the
> resource control picture more fully develops on the desktop, both
> GNOME and KDE, that we have an eye on a PSI based approach. It's a
> long arc with multiple compon
On Sat, Jul 11, 2020 at 3:15 PM John M. Harris Jr wrote:
>
> On Saturday, July 11, 2020 11:43:29 AM MST Chris Murphy wrote:
> > It's known from the outset that earlyoom is temporary. And as the
> > resource control picture more fully develops on the desktop, both
> > GNOME and KDE, that we have an
On Sat, Jul 11, 2020 at 5:15 PM John M. Harris Jr wrote:
>
> On Saturday, July 11, 2020 11:43:29 AM MST Chris Murphy wrote:
> > It's known from the outset that earlyoom is temporary. And as the
> > resource control picture more fully develops on the desktop, both
> > GNOME and KDE, that we have an
On Sat, Jul 11, 2020 at 9:11 PM John M. Harris Jr wrote:
> None of this is relevant ... (to) ... a package which is ...
> widely used, however.
You keep making that assertion. Please provide
the audited numbers from a reputable source(*).
(*) Preferably for sites that actually are more than
>oomd (or rather systemd-oomd) and will make heavy use of cgroups to work
well
Other side of this is high CPU usage:
https://github.com/facebookincubator/oomd/issues/79
сб, 11 июл. 2020 г. в 17:34, Benjamin Berg :
> On Sat, 2020-07-11 at 08:43 +0200, Igor Raits wrote:
> > On Fri, 2020-07-10 at 1
On Sun, 2020-07-12 at 07:18 +0900, Alexey A. wrote:
> >oomd (or rather systemd-oomd) and will make heavy use of cgroups to
> work well
>
> Other side of this is high CPU usage:
> https://github.com/facebookincubator/oomd/issues/79
That is an implementation problem of oomd. And irrelevant in the
Hi all,
As you know many nodejs packages have been removed recently but that has
created dependency issues. I maintain a few nodejs packages in Fedora but
those I added a few years back to learn nodejs packaging.
As more and more packages per release are getting retired it has become
difficult for
On 11.07.2020 14:20, Dominique Martinet wrote:
> BTW, given the size gains ws. time difference for compression I would
> advocate for default zstd compression instead of :1 -- I'd think another
> 12% compression improvement[1] for almost no time difference isn't to be
> sneezed at?
Now please open
On 11.07.2020 17:28, Chris Murphy wrote:
> The paper is with respect to metadata write amplification. This has no
> effect on data writes. Compression applies to data writes, not
> metadata. As the data amount is significantly larger than metadata
> (the file system itself), any reduction in data w
46 matches
Mail list logo
