Re: Chromium built in rawhide does not render most strings

Florian Weimer wrote: > I suspect some of the preprocessor conditionals in > SyscallSets::IsFileSystem in > > > > need fixing. Unfortunately, the fix is more complicated tha

Re: orphaning fakeroot

Adopted :D , I already maintain fakechroot which have the same problem On Tue, 2021-01-19 at 19:25 +0100, Dominik 'Rathann' Mierzejewski wrote: > I've decided to orphan fakeroot. I haven't used it for a long time, > it's FTBFS with the latest glibc in rawhide and fixing the build > issue > only o

Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling

On Sat, Jan 23, 2021 at 4:39 PM Matthew Miller wrote: > > On Sat, Jan 23, 2021 at 03:11:32PM -0700, Chris Murphy wrote: > > - low memory (4G or less, somewhat subjective) > > From what I can see in my informal survey, a lot of 8GB users are benefiting > too, with 1-2GB in the zram swap being commo

Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling

On Sat, Jan 23, 2021 at 03:11:32PM -0700, Chris Murphy wrote: > - low memory (4G or less, somewhat subjective) From what I can see in my informal survey, a lot of 8GB users are benefiting too, with 1-2GB in the zram swap being common, often with that compressing very well. -- Matthew Miller Fe

Re: 32bit arm builder issues

On Sat, Jan 23, 2021 at 02:53:26PM -0800, Kevin Fenzi wrote: > On Sat, Jan 23, 2021 at 11:34:03PM +0100, Jakub Jelinek wrote: > > On Fri, Jan 22, 2021 at 09:27:40AM -0800, Kevin Fenzi wrote: > > > * vm's started 'pausing' (which requires a full reboot). This was > > > tracked to a kernel config cha

Re: 32bit arm builder issues

On Sat, Jan 23, 2021 at 11:34:03PM +0100, Jakub Jelinek wrote: > On Fri, Jan 22, 2021 at 09:27:40AM -0800, Kevin Fenzi wrote: > > * vm's started 'pausing' (which requires a full reboot). This was > > tracked to a kernel config change we made in f29 getting lost along > > the way. A new f33 kernel b

Re: 32bit arm builder issues

On Fri, Jan 22, 2021 at 09:27:40AM -0800, Kevin Fenzi wrote: > * vm's started 'pausing' (which requires a full reboot). This was > tracked to a kernel config change we made in f29 getting lost along > the way. A new f33 kernel build fixed this issue. > > * Then, the vm's seemed to just build thing

Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling

On Sat, Jan 23, 2021 at 4:29 AM Zbigniew Jędrzejewski-Szmek wrote: > > Hi, > > the proposal for Fedora 34 is to use zram-size == 1.0 * ram. > (Which I think is OK for the reasons listed in the Change page [0].) > But the original motivation for this change was boosting the size on > machines with

live respin archive

Hi, Have we a FedoraRespin-32 ? we might want install a Fedora 32 . And about archive , shouldn't we archive 3 or 4 versions ? if last one have a problem, we can check the previous versions ... Thank you . -- Sérgio M. B. ___ devel mailing list --

Re: thinking journal retention timelimits

On Sat, Jan 23, 2021 at 3:39 pm, Matthew Miller wrote: Sure, it should be easy to change, but that doesn't mean we shouldn't also look at defaults. Again, particularly on desktops where having years of logs probably more of a problem than a benefit. One year sounds like a good default to me.

Re: thinking journal retention timelimits

On Sat, Jan 23, 2021 at 02:32:15PM -0600, Chris Adams wrote: > Log rotation is something that can have vastly different requirements > for different environments - I don't think it is up to a distribution to > try to determine that and match them. Stick with one more or less sane > default and app

Re: thinking journal retention timelimits

Once upon a time, Sérgio Basto said: > I use 52 weeks in my machines or even 104 weeks if they are important, > because specially on security issues , we need dig for more than 2 or > 3 months and for statistic like watch disk usage , etc > Like logrotate, I'd like have journal retention for on

Fedora-IoT-34-20210123.0 compose check report

Missing expected images: Iot dvd x86_64 Iot dvd aarch64 Failed openQA tests: 2/16 (x86_64), 3/15 (aarch64) Old failures (same test failed in Fedora-IoT-34-20210122.0): ID: 761073 Test: x86_64 IoT-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/761073 ID: 7610

Fedora-Rawhide-20210123.n.0 compose check report

Missing expected images: Minimal raw-xz armhfp Xfce raw-xz armhfp Compose FAILS proposed Rawhide gating check! 3 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 22/181 (x86_64), 13/123 (aarch64) New failures (sa

Re: thinking journal retention timelimits

On Sat, Jan 23, 2021 at 07:02:17PM +, Sérgio Basto wrote: > I use 52 weeks in my machines or even 104 weeks if they are important, > because specially on security issues , we need dig for more than 2 or > 3 months and for statistic like watch disk usage , etc > Like logrotate, I'd like have

Re: thinking journal retention timelimits

On Fri, 2021-01-01 at 12:15 -0500, Matthew Miller wrote: > As we start a new year, I'm thinking about data retention in general. > :) > > In my experience, it's pretty rare on an end-user laptop or desktop > system for > logs from much more than the previous boot to be interesting. Maybe I > occas

Fedora rawhide compose report: 20210123.n.0 changes

OLD: Fedora-Rawhide-20210122.n.0 NEW: Fedora-Rawhide-20210123.n.0 = SUMMARY = Added images:0 Dropped images: 3 Added packages: 22 Dropped packages:0 Upgraded packages: 183 Downgraded packages: 1 Size of added packages: 368.70 MiB Size of dropped packages

Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling

On Sat, Jan 23, 2021 at 11:28:00AM +, Zbigniew Jędrzejewski-Szmek wrote: > Now I'm a bit torn: the code is nice enough, but it seems to be a solution > in search of a problem. So I thought I'd try a little crowd-sourcing: > Would we have a real use for something like this? I like the syntax. I

Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling

Hi, the proposal for Fedora 34 is to use zram-size == 1.0 * ram. (Which I think is OK for the reasons listed in the Change page [0].) But the original motivation for this change was boosting the size on machines with little ram [1]. I wrote an exploratory patch [2] to specify the size as a formula