On 7/10/20 11:12 PM, John M. Harris Jr wrote:
> On Thursday, July 9, 2020 2:19:27 PM MST Przemek Klosowski via devel wrote:
>> On 7/9/20 8:44 AM, Kevin Kofler wrote:
>>
>>> Przemek Klosowski via devel wrote:
>>>
* disk access is literally O(1) slower than RAM access
>>>
>>> This
On Sat, 11 Jul 2020 at 09:24, Jiri Vanek wrote:
>
> Hello!
>
> toatal packages: 610
> passed: 427
> failed: 176
>
> From the failures, there is 29 which passed in the copr before, and now
are thus failing from two
> reasons - unrelated change, or non-intel64-arch failure. I will put this
to FTBF
On Fr, 10.07.20 18:55, Chris Murphy (li...@colorremedies.com) wrote:
> > There's really no need to complicate things by pushing btrfsisms into
> > user-visible concepts needlessly.
>
> It's been this way in Fedora for a decade.
Well, that's an argument one could also use against btrfs. We are
On Sun, 2020-07-12 at 14:46 -0700, John M. Harris Jr wrote:
> That sounds like an excellent idea, but I'm not convinced that killing users'
> processes, while there's still tons of memory free available, is actually an
> improvement.
I think you should rather think of "MemAvailable" as a
Announcing the creation of a new nightly release validation test event
for Fedora 33 Rawhide 20200713.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 Sat, 11 Jul 2020 16:52:41 +0200, Zbigniew Jędrzejewski-Szmek wrote:
> warning: Unexpected size of section `.reg-xstate/59286' in core file.
> #0 0x7f552f8b3b95 in raise () from /lib64/libc.so.6
> (gdb)
>
> Is this gcc, gdb, binutils, something else?
gdb is older than kernel and you have
On Sun, Jul 12, 2020 at 02:27:49PM -0700, John M. Harris Jr wrote:
> There's no reason to "update" any config, php-fpm is just an alternative
> option. mod_php still works well, and doesn't need to be replaced by those
> currently using it. It's still supported by the upstream, is still widely
Le dimanche 12 juillet 2020 à 13:07 -0700, Kevin Fenzi a écrit :
> On Sun, Jul 05, 2020 at 02:15:23PM +0200, Nicolas Mailhot via devel
> wrote:
> >
> > This is now done in the latest code refresh and in the test copr
> >
On Fri, Jul 10, 2020 at 02:35:05PM -0700, John M. Harris Jr wrote:
> On Friday, July 10, 2020 4:39:21 AM MST Miro Hrončok wrote:
> > On 09. 07. 20 14:24, Petr Pisar wrote:
> >
> > > On Thu, Jul 09, 2020 at 12:55:44PM +0200, Igor Raits wrote:
> > >
> > >> One just noticed that `dnf autoremove` is
On 7/10/20 5:22 PM, John M. Harris Jr wrote:
Android, actually, is trying to get it right by a) being a platform so
that common security updates are available from the platform owner, and
can be applied to everyone's system and b) having a secure remote update
method.
The problem with
On Mon, Jul 13, 2020 at 9:22 AM John M. Harris Jr wrote:
>
> On Monday, July 13, 2020 1:58:30 AM MST Benjamin Berg wrote:
> > But, I also think that the people proposing this have done quite a lot
> > of testing to find reasonable values for various scenarios. If they
> > have done their job
Hello!
toatal packages: 610
passed: 427
failed: 176
From the failures, there is 29 which passed in the copr before, and now are
thus failing from two
reasons - unrelated change, or non-intel64-arch failure. I will put this to
FTBF bugs for those 29
pacakges,
In Monday, or as other duties
The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
Note: If
On Monday, July 13, 2020 7:52:51 AM MST Przemek Klosowski via devel wrote:
> On 7/10/20 5:22 PM, John M. Harris Jr wrote:
> >> Android, actually, is trying to get it right by a) being a platform so
> >> that common security updates are available from the platform owner, and
> >> can be applied to
OLD: Fedora-Rawhide-20200710.n.1
NEW: Fedora-Rawhide-20200713.n.0
= SUMMARY =
Added images:3
Dropped images: 4
Added packages: 5
Dropped packages:2
Upgraded packages: 296
Downgraded packages: 0
Size of added packages: 30.48 MiB
Size of dropped packages
On Mon, Jul 13, 2020 at 10:59:24AM +0100, Joe Orton wrote:
> > It'd be as simple as accepting ngompa's PR, here:
> > https://src.fedoraproject.org/rpms/php/pull-request/4
>
> Remi has rejected the PR. There is really nothing more to discuss here,
> and I cannot really see you are making a
On Monday, July 13, 2020 1:58:30 AM MST Benjamin Berg wrote:
> But, I also think that the people proposing this have done quite a lot
> of testing to find reasonable values for various scenarios. If they
> have done their job correctly, then EarlyOOM will *not* prevent you
> from fully utilizing
On Mon, 2020-07-13 at 08:21 -0700, John M. Harris Jr wrote:
> On Monday, July 13, 2020 1:58:30 AM MST Benjamin Berg wrote:
> > But, I also think that the people proposing this have done quite a lot
> > of testing to find reasonable values for various scenarios. If they
> > have done their job
limb: php-IDNA_Convert, php-simplepie, php-markdown
I took these, for moodle.
--
Gwyn Ciesla
she/her/hers
in your fear, seek only peace
in your fear, seek only love
-d. bowie
Sent with ProtonMail Secure Email.
signature.asc
Description:
On Mon, Jul 13, 2020 at 4:12 AM Lennart Poettering wrote:
>
> On Fr, 10.07.20 18:55, Chris Murphy (li...@colorremedies.com) wrote:
>
> > > There's really no need to complicate things by pushing btrfsisms into
> > > user-visible concepts needlessly.
> >
> > It's been this way in Fedora for a
> MemAvailable is a bad heuristic, it does *not* represent "free"
> memory.
MemAvailable is a good heuristic, it does represent available memory.
вт, 14 июл. 2020 г. в 00:49, Benjamin Berg :
> On Mon, 2020-07-13 at 08:21 -0700, John M. Harris Jr wrote:
> > On Monday, July 13, 2020 1:58:30 AM
On Monday, July 13, 2020 2:59:24 AM MST Joe Orton wrote:
> On Sun, Jul 12, 2020 at 02:27:49PM -0700, John M. Harris Jr wrote:
>
> > There's no reason to "update" any config, php-fpm is just an alternative
> > option. mod_php still works well, and doesn't need to be replaced by those
> >
On Monday, July 13, 2020 3:12:22 AM MST Lennart Poettering wrote:
> On Fr, 10.07.20 18:55, Chris Murphy (li...@colorremedies.com) wrote:
>
>
> > > There's really no need to complicate things by pushing btrfsisms into
> > > user-visible concepts needlessly.
> >
> >
> >
> > It's been this way in
On 7/13/20 8:21 AM, John M. Harris Jr wrote:
On Monday, July 13, 2020 1:58:30 AM MST Benjamin Berg wrote:
But, I also think that the people proposing this have done quite a lot
of testing to find reasonable values for various scenarios. If they
have done their job correctly, then EarlyOOM will
> The most
> common value I've found over a long period of time, for swap without
> hibernation is 50% of RAM.
With low RAM (2G) it's easy to use swap on zram with disksize = 150%
MemTotal with opening browsers.
50% maybe OK with MemTotal=8G.
> I'd like to hear from Alexey what he thinks about
On Monday, July 13, 2020 11:13:50 AM MST Lennart Poettering wrote:
> On Mo, 13.07.20 09:23, Chris Murphy (li...@colorremedies.com) wrote:
>
>
> > I offer it to contradict the assertion that the current arrangement is
> > "pushing btrfsisms". It is originally Fedora. And having to use btrfs
> >
On Mon, Jul 13, 2020 at 10:25:36AM +0200, Jan Kratochvil wrote:
> On Sat, 11 Jul 2020 16:52:41 +0200, Zbigniew Jędrzejewski-Szmek wrote:
> > warning: Unexpected size of section `.reg-xstate/59286' in core file.
> > #0 0x7f552f8b3b95 in raise () from /lib64/libc.so.6
> > (gdb)
> >
> > Is this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-07-14 at 01:28 +0900, Alexey A. wrote:
> > The most
> > common value I've found over a long period of time, for swap
> > without
> > hibernation is 50% of RAM.
>
> With low RAM (2G) it's easy to use swap on zram with disksize = 150%
>
Is this just about the specific URL or also about the "Naming Policy"?
I am asking, because I already had a lot of arguments about the
branching on this list and various different places but this guideline
still insist that "using upstream major versions as branches is
recommended". This is not
On Tue, 2020-07-14 at 00:55 +0900, Alexey A. wrote:
> > MemAvailable is a bad heuristic, it does *not* represent "free"
> > memory.
>
> MemAvailable is a good heuristic, it does represent available
> memory.
Maybe. But the point is that I expect a system to be in trouble long
before the value
On Monday, July 13, 2020 10:48:03 AM MST Samuel Sieb wrote:
> On 7/13/20 8:21 AM, John M. Harris Jr wrote:
>
> > On Monday, July 13, 2020 1:58:30 AM MST Benjamin Berg wrote:
> >
> >> But, I also think that the people proposing this have done quite a lot
> >> of testing to find reasonable values
>
> A cursory glance shows that some failed with network problems. E.g.
> plexus-velocity failed with this:
>
> DEBUG util.py:621: Errors during downloading metadata for repository 'build':
> DEBUG util.py:621: - Curl error (18): Transferred a partial file for
>
On Mo, 13.07.20 09:23, Chris Murphy (li...@colorremedies.com) wrote:
> I offer it to contradict the assertion that the current arrangement is
> "pushing btrfsisms". It is originally Fedora. And having to use btrfs
> specific commands to set/get the default, as you propose, is the
> "btrfsism" -
On Mon, 13 Jul 2020 18:32:10 +0200, Zbigniew Jędrzejewski-Szmek wrote:
> gdb-9.2-2.fc33.x86_64 which is the latest rawhide build... Does gdb need
> updating?
You may rather ask at gdb -at - sourceware.org.
Jan
___
devel mailing list --
> Upon reading the SwapOnZRAM feature proposal, I see it is advocating
> allocating 50% of ram for swap
50% means zram disksize (max size of uncompressed data stored in zram
device) = 50% MemTotal. This data will be compressed, so, its size in RAM
will be smaller than 50% MemTotal (maybe 25% with
On 12/07/20 12:52 +0100, Ian McInerney wrote:
On Sun, Jul 12, 2020 at 12:46 PM Jonathan Wakely
wrote:
On 12/07/20 12:33 +0100, Ian McInerney wrote:
This is what the upstream project explicitly says to do when using LLVM10:
>
i've installed a minimal F32 instance
building up the rpmbuild env, 'mock' pkg is installed
rpm -qa | grep mock
mock-core-configs-32.6-1.fc32.noarch
mock-2.3-1.fc32.noarch
there's _no_ expected 'mock' group installed
getent group mock
On Tue, Jul 14, 2020 at 08:33:04AM +1000, Bojan Smojver via devel wrote:
> Would someone with sufficient powers mind queueing up this update?
I would assume that person would be the one who built it...
perhaps there's some reason for not wanting to push it yet.
(CCing builder here)
kevin
Would someone with sufficient powers mind queueing up this update?
Thanks,
--
Bojan___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
On Mon, Jul 13, 2020 at 4:15 PM PGNet Dev wrote:
> i can easily manually create the group, but ... this suggests something's
> missing/broken in my install; I'd like to find/fix it.
>
> if not 'mock' what pkg (re)install creates the mock group?
The mock-core-configs package is supposed to do
On 7/13/20 3:20 PM, Jerry James wrote:
> On Mon, Jul 13, 2020 at 4:15 PM PGNet Dev wrote:
>> i can easily manually create the group, but ... this suggests something's
>> missing/broken in my install; I'd like to find/fix it.
>>
>> if not 'mock' what pkg (re)install creates the mock group?
>
>
On Mon, Jul 13, 2020 at 12:14 PM Lennart Poettering
wrote:
> Quite frankly, I don't see why the boot loader should care about the
> btrfs subvolume the initrd later picks at all.
As far as I'm aware, rootflags= is a kernel boot parameter, and it
informs the kernel of mount options for the file
On Mon, Jul 13, 2020 at 11:56 AM John M. Harris Jr wrote:
>
> On Monday, July 13, 2020 10:48:03 AM MST Samuel Sieb wrote:
> > On 7/13/20 8:21 AM, John M. Harris Jr wrote:
> >
> > > On Monday, July 13, 2020 1:58:30 AM MST Benjamin Berg wrote:
> > >
> > >> But, I also think that the people
On Mon, Jul 13, 2020 at 12:14 PM Lennart Poettering
wrote:
>
> On Mo, 13.07.20 09:23, Chris Murphy (li...@colorremedies.com) wrote:
>
> > Since it's mostly bootloader domain, and relates to a snapshot and
> > rollback paradigm as well, I think it's properly addressed in design
> > and planning
On Mon, Jul 13, 2020 at 12:00 PM Benjamin Berg wrote:
>
> If MemAvailable drops below 250MiB (roughly 6GiB * 4%), then this means
> that we have less than 500MiB left for file caches. If we can't swap
> (remember, swap is already pretty full too), then a big chunk of these
> caches need to be
On 2020-07-12 1:22 p.m., Robert-André Mauchin wrote:
On Sunday, 12 July 2020 22:13:54 CEST Luya Tshimbalanga wrote:
Thank you for Thumbleweed spec file. With some adjustment, the build
almost succeed as the shaders path managed to fail.
On 2020-07-11 12:46 p.m., Robert-André Mauchin wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1855963
--- Comment #2 from Sjoerd Mullender ---
I can't provide a reproducer. I haven't done any serious Perl programming
since about 1988 and have no intention of starting now.
A simple google search on utf8::SWASHNEW shows quite a few instances
https://bugzilla.redhat.com/show_bug.cgi?id=1856074
Jitka Plesnikova changed:
What|Removed |Added
Status|NEW |ASSIGNED
Doc Type|---
https://bugzilla.redhat.com/show_bug.cgi?id=1855963
Petr Pisar changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from Petr Pisar
https://bugzilla.redhat.com/show_bug.cgi?id=1855963
Petr Pisar changed:
What|Removed |Added
Doc Type|--- |If docs needed, set a value
--- Comment
https://bugzilla.redhat.com/show_bug.cgi?id=1855963
--- Comment #4 from Petr Pisar ---
perl-libs-5.30.3-452.fc31 is affected.
perl-libs-5.32.0-456.fc33 is not affected, because utf8_heavy.pl whose loading
is prevented by Safe was removed in perl 5.31.6 and is not loaded anymore.
That's
https://bugzilla.redhat.com/show_bug.cgi?id=1855963
Petr Pisar changed:
What|Removed |Added
Status|ASSIGNED|MODIFIED
Fixed In Version|
https://bugzilla.redhat.com/show_bug.cgi?id=1856319
Bug ID: 1856319
Summary: perl-Compress-Raw-Bzip2-2.094 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Compress-Raw-Bzip2
Keywords:
Hello!
toatal packages: 610
passed: 427
failed: 176
From the failures, there is 29 which passed in the copr before, and now are
thus failing from two
reasons - unrelated change, or non-intel64-arch failure. I will put this to
FTBF bugs for those 29
pacakges,
In Monday, or as other duties
https://bugzilla.redhat.com/show_bug.cgi?id=1856320
Jitka Plesnikova changed:
What|Removed |Added
Status|ASSIGNED|CLOSED
Fixed In Version|
https://bugzilla.redhat.com/show_bug.cgi?id=1856363
Bug ID: 1856363
Summary: Upgrade perl-HTTP-Entity-Parser to 0.23
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-HTTP-Entity-Parser
Assignee:
https://bugzilla.redhat.com/show_bug.cgi?id=1856362
Bug ID: 1856362
Summary: Upgrade perl-Hash-Merge to 0.301
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Hash-Merge
Assignee: spo...@gmail.com
https://bugzilla.redhat.com/show_bug.cgi?id=1855963
--- Comment #6 from Fedora Update System ---
FEDORA-2020-54c4dc151a has been submitted as an update to Fedora 31.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-54c4dc151a
--
You are receiving this mail because:
You are on the CC list
https://bugzilla.redhat.com/show_bug.cgi?id=1856367
Bug ID: 1856367
Summary: Upgrade perl-Text-Template to 1.59
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Text-Template
Assignee: spo...@gmail.com
https://bugzilla.redhat.com/show_bug.cgi?id=1855963
--- Comment #5 from Fedora Update System ---
FEDORA-2020-59f945f4be has been submitted as an update to Fedora 32.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-59f945f4be
--
You are receiving this mail because:
You are on the CC list
https://bugzilla.redhat.com/show_bug.cgi?id=1856319
Jitka Plesnikova changed:
What|Removed |Added
Status|NEW |ASSIGNED
Doc Type|---
https://bugzilla.redhat.com/show_bug.cgi?id=1856320
Jitka Plesnikova changed:
What|Removed |Added
Status|NEW |ASSIGNED
Doc Type|---
https://bugzilla.redhat.com/show_bug.cgi?id=1856074
Jitka Plesnikova changed:
What|Removed |Added
Status|ASSIGNED|CLOSED
Fixed In Version|
https://bugzilla.redhat.com/show_bug.cgi?id=1850793
--- Comment #3 from Fedora Update System ---
FEDORA-EPEL-2020-93edf0c8b8 has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-93edf0c8b8
--
You are receiving this mail because:
You are
https://bugzilla.redhat.com/show_bug.cgi?id=1856359
Bug ID: 1856359
Summary: Upgrade perl-DBIx-SearchBuilder to 1.68
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-DBIx-SearchBuilder
Assignee:
https://bugzilla.redhat.com/show_bug.cgi?id=1856320
Bug ID: 1856320
Summary: perl-Compress-Raw-Zlib-2.094 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Compress-Raw-Zlib
Keywords:
https://bugzilla.redhat.com/show_bug.cgi?id=1855963
Petr Pisar changed:
What|Removed |Added
Assignee|jples...@redhat.com |ppi...@redhat.com
Summary|bug
https://bugzilla.redhat.com/show_bug.cgi?id=1856319
Jitka Plesnikova changed:
What|Removed |Added
Status|ASSIGNED|CLOSED
Fixed In Version|
https://bugzilla.redhat.com/show_bug.cgi?id=1850793
Petr Pisar changed:
What|Removed |Added
Status|ASSIGNED|MODIFIED
Fixed In Version|
The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
Note: If
https://bugzilla.redhat.com/show_bug.cgi?id=1852414
--- Comment #3 from Frank Ch. Eigler ---
(In reply to Paul Howarth from comment #2)
> Looks like Bug #1855962, which would be a bugzilla bug rather than one in
> perl-Email-MIME-ContentType.
Arguably, infrastructure code should not add new
https://bugzilla.redhat.com/show_bug.cgi?id=1855963
--- Comment #8 from Fedora Update System ---
FEDORA-2020-54c4dc151a has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade
https://bugzilla.redhat.com/show_bug.cgi?id=1855963
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #7 from
Erick Wittman 于 2020年7月14日周二 上午11:22写道：
> Hi EPEL developers.
>
> I am using CentOS 8 and am using various packages in the EPEL
> repository. I am interested in seeing gcc-gnat added to EPEL.
>
> I cannot find a current Fedora maintainer listed for this package, but it is
> available in Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=1850792
Fedora Update System changed:
What|Removed |Added
Status|ON_QA |CLOSED
Resolution|---
https://bugzilla.redhat.com/show_bug.cgi?id=1850971
Fedora Update System changed:
What|Removed |Added
Status|ON_QA |CLOSED
Resolution|---
https://bugzilla.redhat.com/show_bug.cgi?id=1850795
Bug 1850795 depends on bug 1850915, which changed state.
Bug 1850915 Summary: Add perl-DateTime-Format-Natural to EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1850915
What|Removed |Added
https://bugzilla.redhat.com/show_bug.cgi?id=1850915
Fedora Update System changed:
What|Removed |Added
Status|ON_QA |CLOSED
Resolution|---
https://bugzilla.redhat.com/show_bug.cgi?id=1850915
Bug 1850915 depends on bug 1850971, which changed state.
Bug 1850971 Summary: Add perl-Module-Util to EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1850971
What|Removed |Added
https://bugzilla.redhat.com/show_bug.cgi?id=1850776
Bug 1850776 depends on bug 1850792, which changed state.
Bug 1850792 Summary: Add perl-MooseX-Types-DateTime to EPEL8 / co-maintainer
request
https://bugzilla.redhat.com/show_bug.cgi?id=1850792
What|Removed
https://bugzilla.redhat.com/show_bug.cgi?id=1850793
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #4 from
https://bugzilla.redhat.com/show_bug.cgi?id=1850913
Fedora Update System changed:
What|Removed |Added
Status|ON_QA |CLOSED
Resolution|---
https://bugzilla.redhat.com/show_bug.cgi?id=1850795
Bug 1850795 depends on bug 1850913, which changed state.
Bug 1850913 Summary: Add perl-DateTime-Format-Flexible to EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1850913
What|Removed |Added
https://fedorapeople.org/groups/389ds/ci/nightly/2020/07/14/report-389-ds-base-1.4.4.4-20200713git318a3ce.fc32.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to
Hi EPEL developers.
I am using CentOS 8 and am using various packages in the EPEL
repository. I am interested in seeing gcc-gnat added to EPEL.
I cannot find a current Fedora maintainer listed for this package, but
it is available in Fedora (at least in version 32). Are there any
EPEL
85 matches
Mail list logo
