[389-devel] 389 DS nightly 2021-01-24 - 95% PASS

2021-01-23 Thread vashirov
https://fedorapeople.org/groups/389ds/ci/nightly/2021/01/24/report-389-ds-base-2.0.2-20210124git6ea32f9f5.fc33.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to

[Bug 1917453] perl-Git-Repository-1.324-5.fc34 FTBFS: t/24-errors.t fails 'warnings: 0' test with a new git 2.30.0

2021-01-23 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1917453 Fedora Release Engineering changed: What|Removed |Added Flags|

[Bug 1919611] New: perl-Role-Tiny-2.002004 is available

2021-01-23 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1919611 Bug ID: 1919611 Summary: perl-Role-Tiny-2.002004 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Role-Tiny Keywords: FutureFeature, Triaged

Re: Chromium built in rawhide does not render most strings

2021-01-23 Thread Kevin Kofler via devel
Florian Weimer wrote: > I suspect some of the preprocessor conditionals in > SyscallSets::IsFileSystem in > > > > need fixing. Unfortunately, the fix is more complicated

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

2021-01-23 Thread updates
The following Fedora EPEL 8 Security updates need testing: Age URL 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-e976495093 coturn-4.5.2-1.el8 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-47ea069c76 chromium-87.0.4280.141-1.el8 1

Re: orphaning fakeroot

2021-01-23 Thread Sérgio Basto
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

[Bug 1919603] New: perl-JSON-4.03 is available

2021-01-23 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1919603 Bug ID: 1919603 Summary: perl-JSON-4.03 is available Product: Fedora Version: rawhide Status: NEW Component: perl-JSON Keywords: FutureFeature, Triaged

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

2021-01-23 Thread Chris Murphy
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

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

2021-01-23 Thread Matthew Miller
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

Re: 32bit arm builder issues

2021-01-23 Thread Kevin Fenzi
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

Re: 32bit arm builder issues

2021-01-23 Thread Kevin Fenzi
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

Re: 32bit arm builder issues

2021-01-23 Thread Jakub Jelinek
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

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

2021-01-23 Thread Chris Murphy
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

2021-01-23 Thread Sérgio Basto
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

2021-01-23 Thread Michael Catanzaro
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

Re: thinking journal retention timelimits

2021-01-23 Thread Matthew Miller
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

Re: thinking journal retention timelimits

2021-01-23 Thread Chris Adams
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

Fedora-IoT-34-20210123.0 compose check report

2021-01-23 Thread Fedora compose checker
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:

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

2021-01-23 Thread Fedora compose checker
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

Re: thinking journal retention timelimits

2021-01-23 Thread Matthew Miller
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

2021-01-23 Thread Sérgio Basto
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 >

Fedora rawhide compose report: 20210123.n.0 changes

2021-01-23 Thread Fedora Rawhide Report
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

2021-01-23 Thread Matthew Miller
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.

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

2021-01-23 Thread Zbigniew Jędrzejewski-Szmek
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