Hi,
During 2020 Open Source Summit North America, Josef shared some
details about how btrfs excels in production at Facebook. And where
the problems were.
I cannot find the recording, but the write up is at Linux Weekly News:
https://lwn.net/SubscriberLink/824855/e601d11e157e1b4a/
I hi
On Thu, Jul 02, 2020 at 12:10:58PM +0200, Björn Persson wrote:
> Nicolas Mailhot wrote:
> > The same process that commits a new state of the changelog file in
> > sources,
> > commits the date that was written in the changelog in a separate key =
> > value
> > file (with the components of the bui
Le July 2, 2020 2:47:49 PM UTC, Vitaly Zaitsev via devel
a écrit :
>On 02.07.2020 11:27, Nicolas Mailhot wrote:
>> Why? Koji schedules a build. The build registers its own build date
>in
>> the produced packages. Koji decides to keep and commit the result, or
>> drop it (scratch build, failed s
Le vendredi 03 juillet 2020 à 07:26 +0200, Pavel Raiskup a écrit :
Hi,
> I'm not familiar with the %forge* macros, but I don't think it is
> expected that you will add commands that need the Internet into the
> macro definition.
It’s neither expected nor unexpected. For a Fedora-oriented spec,
Le jeudi 02 juillet 2020 à 17:44 -0400, Josef Bacik a écrit :
> However just because we know something
> went wrong doesn't mean we can do anything about it, it just means
> that the user knows now that they need to restore from backups
That’s a perfect answer for an Enterprise server setup with
Le 2020-07-02 15:11, Kamil Dudka a écrit :
On Thursday, July 2, 2020 1:02:05 PM CEST Nicolas Mailhot via devel
wrote:
If there is buy-in, it will be implemented by goodwill people. If
there
is no buy-in, it won’t, normal community development process. Put
yourself in the category you want to be
On Thu, Jul 02, 2020 at 03:44:51PM +0200, Nicolas Mailhot via devel wrote:
> Le 2020-07-02 15:11, Kamil Dudka a écrit :
> >On Thursday, July 2, 2020 1:02:05 PM CEST Nicolas Mailhot via
> >devel wrote:
> >>If there is buy-in, it will be implemented by goodwill people.
> >>If there
> >>is no buy-in,
Le jeudi 02 juillet 2020 à 15:19 -0500, Martin Jackson a écrit :
> > 5-10 years? A better estimate would be 15-20 years. People aren't
> > going to
> > throw away perfectly fine systems and jump to new "cloud" platforms
> > just
> > because the OS they were using dropped BIOS support. They'll just
Would you mind to follow this page to get sponsored?
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
Also, it would be probably good to join the Node.js SIG to coordinate
and start contributing via PRs.
While I could sponsor you, I don't think I'd be good mentor for node
p
Le jeudi 02 juillet 2020 à 18:00 -0700, PGNet Dev a écrit :
Hi,
As usual for those things the reason is dead stupid (so stupid the
human brain refuses to see it)
> submitting the _same_ spec to COPR for online build FAILS @,
> supposedly, similar Mock build
>
> Here's a diff
>
> https://
On Friday, July 3, 2020 9:01:16 AM CEST Nicolas Mailhot wrote:
> Le jeudi 02 juillet 2020 à 18:00 -0700, PGNet Dev a écrit :
>
> Hi,
>
> As usual for those things the reason is dead stupid (so stupid the
> human brain refuses to see it)
>
> > submitting the _same_ spec to COPR for online build F
Le vendredi 03 juillet 2020 à 10:06 +0200, Pierre-Yves Chibon a écrit :
> On Thu, Jul 02, 2020 at 03:44:51PM +0200, Nicolas Mailhot via devel
> wrote:
> > Le 2020-07-02 15:11, Kamil Dudka a écrit :
> > > On Thursday, July 2, 2020 1:02:05 PM CEST Nicolas Mailhot via
> > > devel wrote:
> > > > If the
On Friday, July 3, 2020 9:48:06 AM CEST Pierre-Yves Chibon wrote:
> So if we were to give the builders commit access to dist-git, an attacker
> could easily commit to any other packages, potentially from something as easy
> as a scratch-build.
Absolutely!
Koji authenticates build submitters (I'm
On Friday, July 3, 2020 9:51:20 AM CEST Nicolas Mailhot via devel wrote:
> it will certainly be possible to compute a second level of sources
> during the dynamic buildrequires first pass over prep, and the change
> makes the forge macro code modular enough the second level will be
> auto-registere
On Tue, Jun 30, 2020 at 09:01:21AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Jun 29, 2020 at 05:52:07PM +0200, Till Maas wrote:
> > On Mon, Jun 29, 2020 at 08:16:29AM -0400, Gerald Henriksen wrote:
> >
> > > While it may be worth vim making themselves better, it really doesn't
> > > chan
Le vendredi 03 juillet 2020 à 09:48 +0200, Pierre-Yves Chibon a écrit :
> On Thu, Jul 02, 2020 at 12:10:58PM +0200, Björn Persson wrote:
> > Nicolas Mailhot wrote:
> > > The same process that commits a new state of the changelog file
> > > in
> > > sources,
> > > commits the date that was written
Le vendredi 03 juillet 2020 à 11:03 +0200, Pavel Raiskup a écrit :
> On Friday, July 3, 2020 9:51:20 AM CEST Nicolas Mailhot via devel
> wrote:
> > it will certainly be possible to compute a second level of sources
> > during the dynamic buildrequires first pass over prep, and the
> > change
> > ma
Le vendredi 03 juillet 2020 à 11:03 +0200, Pavel Raiskup a écrit :
>
> I'd appreciate the link to spectool rewrite, though.
Here it is:
https://pagure.io/rpmdevtools/blob/master/f/rpmdev-spectool
Regards,
--
Nicolas Mailhot
___
devel mailing list --
Hi
On Fri, Jul 3, 2020 at 2:14 AM John M. Harris wrote:
>
> None of those bugs were release blocking, and none of them meant that x86
> wouldn't boot, or that core packages didn't work
>
When you add so many qualifiers, you are now admitting a) you did get a
response b) that things weren't perf
On 2020-07-03 08:07, Zbigniew Jędrzejewski-Szmek wrote:
Ubuntu's MOTD are well known and people seem to like them a
lot. Fedora hasn't been making that much use of them. But I think we
should in general.
Do not follow Ubuntu on this too much.
I've had a case of a machine with many short-lived
On Wed, 1 Jul 2020 20:16:36 +0200
Iñaki Ucar wrote:
> > No, this is exactly the wrong way around. You should use the serial
> > library for code that you want to be running in serial (this way you
> > can get several instances of the program running efficiently), and
> > the pthreads version if yo
On Fri, Jul 03, 2020 at 11:08:01AM +0200, Till Maas wrote:
> On Tue, Jun 30, 2020 at 09:01:21AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Mon, Jun 29, 2020 at 05:52:07PM +0200, Till Maas wrote:
> > > On Mon, Jun 29, 2020 at 08:16:29AM -0400, Gerald Henriksen wrote:
> > >
> > > > While it ma
On Fri, 3 Jul 2020 at 13:02, Susi Lehtola
wrote:
>
> On Wed, 1 Jul 2020 20:16:36 +0200
> Iñaki Ucar wrote:
> > > No, this is exactly the wrong way around. You should use the serial
> > > library for code that you want to be running in serial (this way you
> > > can get several instances of the pr
On Fri, Jul 3, 2020 at 1:18 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:
> > So all those people are happy with vi? IMHO an argument for changing
> > this would be that a lot of people are already changing EDITOR to nano,
> > so it makes sense to make it a default. If this is actuall
On Thu, 02 Jul 2020 02:04:48 +0200, Kevin Fenzi wrote:
> I have fixed the buildhw-x86 boxes, they all now have ~365GB now.
Yes, it has built fine:
https://koji.fedoraproject.org/koji/taskinfo?taskID=46455864
> Sorry, I misunderstood you... I thought you were wanting to test a
> scratch
On Fri, Jul 3, 2020 at 6:50 AM Roberto Ragusa wrote:
>
> On 2020-07-03 08:07, Zbigniew Jędrzejewski-Szmek wrote:
>
> > Ubuntu's MOTD are well known and people seem to like them a
> > lot. Fedora hasn't been making that much use of them. But I think we
> > should in general.
>
> Do not follow Ubunt
On 03.07.2020 08:07, Zbigniew Jędrzejewski-Szmek wrote:
> Ubuntu's MOTD are well known and people seem to like them a
> lot. Fedora hasn't been making that much use of them. But I think we
> should in general.
Ubuntu MOTD contains ads. Most of Ubuntu users completely disable it
right after the ins
On 03.07.2020 13:42, Neal Gompa wrote:
> Ubuntu's MOTD requires network connectivity to function, I think ours
> would not. That would eliminate the network resource contention issues
> you were seeing.
The good MOTD is an empty MOTD.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
__
On Wed, Jul 01, 2020 at 10:36:59AM +0200, Benjamin Berg wrote:
> On Tue, 2020-06-30 at 17:48 +0200, Vitaly Zaitsev via devel wrote:
> > On 30.06.2020 15:25, Ben Cotton wrote:
> > > Better thermal management and peak performance on Intel CPUs by
> > > including thermald in the default install.
> >
On Thu, 02 Jul 2020 02:04:48 +0200, Kevin Fenzi wrote:
> On Wed, Jul 01, 2020 at 11:22:26PM +0200, Jan Kratochvil wrote:
> > I will file a ticket after Spot says his opinion (or not).
>
> Sure.
https://src.fedoraproject.org/rpms/chromium/pull-request/27
__
On Wed, Jul 01, 2020 at 10:24:27AM -0400, Ben Cotton wrote:
> == User Experience ==
> Users will have a new CLI tool, called flexiblas, which will allow
> them to properly switch the BLAS/LAPACK backend without administrative
> privileges and any compatibility issues.
Based on this description, th
On Thu, Jul 2, 2020, at 12:05 PM, Daniel P. Berrangé wrote:
> I presume you're referring to regular Fedora here, but this description
> feels like it is approx asking for what Fedora Silverblue has delivered,
> only with the writable area for apps being just a ram disk with no
> persistence.
No
On Thu, Jul 2, 2020, at 11:53 AM, Zbigniew Jędrzejewski-Szmek wrote:
> It would be great if we could fairly reliably boot with a read-only
> root file system,
Eh, just mount a tmpfs for /var, and an overlayfs for /etc (backed by a tmpfs).
That's what we do for Fedora CoreOS based live images, se
On Fri, Jul 03, 2020 at 01:15:29PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Jul 01, 2020 at 10:24:27AM -0400, Ben Cotton wrote:
> > == User Experience ==
> > Users will have a new CLI tool, called flexiblas, which will allow
> > them to properly switch the BLAS/LAPACK backend without adm
On Fri, 3 Jul 2020 at 15:23, Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Wed, Jul 01, 2020 at 10:24:27AM -0400, Ben Cotton wrote:
> > == User Experience ==
> > Users will have a new CLI tool, called flexiblas, which will allow
> > them to properly switch the BLAS/LAPACK backend without administrativ
On Fri, Jul 03, 2020 at 09:18:42AM -0400, Colin Walters wrote:
> On Thu, Jul 2, 2020, at 11:53 AM, Zbigniew Jędrzejewski-Szmek wrote:
>
> > It would be great if we could fairly reliably boot with a read-only
> > root file system,
>
> Eh, just mount a tmpfs for /var, and an overlayfs for /etc (bac
Hi,
On 03/07/2020 14:18, Colin Walters wrote:
On Thu, Jul 2, 2020, at 11:53 AM, Zbigniew Jędrzejewski-Szmek wrote:
It would be great if we could fairly reliably boot with a read-only
root file system,
Eh, just mount a tmpfs for /var, and an overlayfs for /etc (backed by a tmpfs).
That's what
On Fri, 3 Jul 2020 at 15:29, Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Fri, Jul 03, 2020 at 01:15:29PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Wed, Jul 01, 2020 at 10:24:27AM -0400, Ben Cotton wrote:
> > > == User Experience ==
> > > Users will have a new CLI tool, called flexiblas, which
On Wed, Jul 01, 2020 at 10:24:27AM -0400, Ben Cotton wrote:
> == Documentation ==
> See the
> [https://gitlab.mpi-magdeburg.mpg.de/software/flexiblas-release/-/blob/master/README.md
> README] of the upstream project and their
> [https://www.mpi-magdeburg.mpg.de/projects/flexiblas homepage] for
> f
On 7/1/20 2:50 PM, Josef Bacik wrote:
> On 7/1/20 2:24 PM, Matthew Miller wrote:
>> On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew Jędrzejewski-Szmek wrote:
>>> Making btrfs opt-in for F33 and (assuming the result go well) opt-out for
>>> F34
>>> could be good option. I know technically it is
On Fri, Jul 03, 2020 at 01:32:12PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Jul 03, 2020 at 09:18:42AM -0400, Colin Walters wrote:
> > On Thu, Jul 2, 2020, at 11:53 AM, Zbigniew Jędrzejewski-Szmek wrote:
> >
> > > It would be great if we could fairly reliably boot with a read-only
> > >
On Fri, Jul 3, 2020, at 9:32 AM, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Jul 03, 2020 at 09:18:42AM -0400, Colin Walters wrote:
> > On Thu, Jul 2, 2020, at 11:53 AM, Zbigniew Jędrzejewski-Szmek wrote:
> >
> > > It would be great if we could fairly reliably boot with a read-only
> > > root f
On Fri, 3 Jul 2020 at 15:43, Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Wed, Jul 01, 2020 at 10:24:27AM -0400, Ben Cotton wrote:
> > == Documentation ==
> > See the
> > [https://gitlab.mpi-magdeburg.mpg.de/software/flexiblas-release/-/blob/master/README.md
> > README] of the upstream project and t
On Fri, Jul 3, 2020 at 9:56 AM Colin Walters wrote:
>
> What I was pointing at is the Fedora CoreOS *LIVE* ISO, which is definitely
> fully read only (or phased more usefully), does not support persistence
> at all because physical ISOs don't - same as any other "Live" system
> from Anaconda to al
On Fri, Jul 03, 2020 at 03:57:04PM +0200, Iñaki Ucar wrote:
> On Fri, 3 Jul 2020 at 15:43, Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > On Wed, Jul 01, 2020 at 10:24:27AM -0400, Ben Cotton wrote:
> > > == Documentation ==
> > > See the
> > > [https://gitlab.mpi-magdeburg.mpg.de/software/flexiblas
On Thu, Jul 02, 2020 at 09:50:47AM +0200, Iñaki Ucar wrote:
> On Wed, 1 Jul 2020 at 18:39, Miro Hrončok wrote:
> >
> > On 01. 07. 20 16:24, Ben Cotton wrote:
> > > https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager
> > >
> > > == Summary ==
> > > BLAS/LAPACK packages will be c
On Fri, Jul 03, 2020 at 09:56:03AM -0400, Colin Walters wrote:
>
>
> On Fri, Jul 3, 2020, at 9:32 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > On Fri, Jul 03, 2020 at 09:18:42AM -0400, Colin Walters wrote:
> > > On Thu, Jul 2, 2020, at 11:53 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > >
> > > > It
On 7/3/20 9:37 AM, Eric Sandeen wrote:
On 7/1/20 2:50 PM, Josef Bacik wrote:
On 7/1/20 2:24 PM, Matthew Miller wrote:
On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew Jędrzejewski-Szmek wrote:
Making btrfs opt-in for F33 and (assuming the result go well) opt-out for F34
could be good option.
hi,
> ...
All the above^ is an interesting/informative read.
On 7/3/20 2:31 AM, Nicolas Mailhot via devel wrote:
> The requester is clearly attempting the second approach.
Well, not explicitly. I'm not requesting any _specific_ approach.
The goal is simply to 'build it here (locally, via mock)
OLD: Fedora-Rawhide-20200702.n.0
NEW: Fedora-Rawhide-20200703.n.0
= SUMMARY =
Added images:12
Dropped images: 4
Added packages: 15
Dropped packages:0
Upgraded packages: 84
Downgraded packages: 0
Size of added packages: 18.37 MiB
Size of dropped packages:0
On Fri, 3 Jul 2020 at 16:15, Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Thu, Jul 02, 2020 at 09:50:47AM +0200, Iñaki Ucar wrote:
> > On Wed, 1 Jul 2020 at 18:39, Miro Hrončok wrote:
> > >
> > > On 01. 07. 20 16:24, Ben Cotton wrote:
> > > > https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/
Thanks for the insight and link Fabio and Mat. I'll look into the
compatibility and verify if any changes need to be made and if so,
contact the maintainers. Following a week or two for responses, I'll
submit an update for rawhide.
Regards,
Jie Kang
Senior Software Engineer, Red Hat Canada
On Th
On Thu, Jul 2, 2020 at 10:29 PM Scott Schmit wrote:
>
> On Sun, Jun 28, 2020 at 03:40:11PM -0600, Chris Murphy wrote:
> > Databases and VM images are things btrfs is bad at out of the box.
> > Most of this has to do with fsync dependency of other file systems.
> > Btrfs is equipped to deal with an
On Fri, Jul 3, 2020 at 10:37 AM Chris Murphy wrote:
> To give the nodatacow suggestion a try:
> ## shutdown the database
> # mkdir /var/lib/mysql2
> # chattr +C /var/lib/mysql2
> # cp /var/lib/mysql/* /var/lib/mysql2/
> # rm /var/lib/mysql/
# rm -rf /var/lib/mysql/
> # mv /var/lib/mysql2/ /var/
Announcing the creation of a new nightly release validation test event
for Fedora-IoT 33 RC 20200703.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/QA:Release_validation_test_pl
FWIW looks like OCaml 4.11 beta 1 was released earlier this week.
https://discuss.ocaml.org/t/ocaml-4-11-first-beta-release/6042
So I will try a mass rebuild into a side tag soon, and see what the
fallout is. I believe I've added all the new packages added recently
to my list.
I've no intent
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Just wanted to provide some update on this change.
* %__cmake_in_source_build macro has been introduced and set to 1. It
controls what arguments are passed to `cmake -B ...`, `cmake --build
...`, `cmake --install ...` and in which directory `ctest`
on F32,
date +FORMAT,
date +%Y%m%d_%H%M%S
returns
20200703_105351
as expected.
in an rpm .spec, if I define
%define _build_timestamp %( date +%Y%m%d_%H%M%S )
and _use_ %{_build_timestamp) _anywhere_ else in the spec, at exec of any of
rpmbuild/mock
On Fri, 3 Jul 2020 11:09:47 -0700
PGNet Dev wrote:
> on F32,
>
> date +FORMAT,
> date +%Y%m%d_%H%M%S
>
> returns
> 20200703_105351
>
>
>
> as expected.
>
> in an rpm .spec, if I define
>
> %define _build_timestamp %( date +%Y%m%d_%H%M%S )
>
> and _use_ %{_build_timestamp
PGNet Dev wrote:
> %define _build_timestamp %( date +%Y%m%d_%H%M%S )
Percent signs that are not to be interpreted as RPM syntax need to be
doubled. Write this as:
%define _build_timestamp %(date +%%Y%%m%%d_%%H%%M%%S)
Björn Persson
pgpSR1gksDcHm.pgp
Description: OpenPGP digital signatur
On 7/3/20 11:22 AM, Paul Howarth wrote:
> Remember
ugh. well, i certainly will NOW! ;-)
> that '%' introduces a macro expansion, so if that's not what
> you want, you should escape the '%' as '%%':
>
> %define _build_timestamp %( date +%%Y%%m%%d_%%H%%M%%S )
works perfectly. thx!
___
SSDs can fail in weird ways. Some spew garbage as they're failing,
some go read-only. I've seen both. I don't have stats on how common it
is for an SSD to go read-only as it fails, but once it happens you
cannot fsck it. It won't accept writes. If it won't mount, your only
chance to recover data is
On Thu, 2020-06-25 at 13:18 -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/UseNanoByDefault
>
> == Summary ==
>
> Let's make Fedora more approachable, by having a default editor that
> doesn't require specialist knowledge to use.
>
> == Owner ==
> * Name: [[User:chrismurphy| C
On 3 July 2020 21:30:26 CEST, Adam Williamson
wrote:
>On Thu, 2020-06-25 at 13:18 -0400, Ben Cotton wrote:
>> https://fedoraproject.org/wiki/Changes/UseNanoByDefault
>>
>> == Summary ==
>>
>> Let's make Fedora more approachable, by having a default editor that
>> doesn't require specialist kn
On Friday, 3 July 2020 19:41:40 CEST Igor Raits wrote:
> Just wanted to provide some update on this change.
>
> * %__cmake_in_source_build macro has been introduced and set to 1. It
> controls what arguments are passed to `cmake -B ...`, `cmake --build
> ...`, `cmake --install ...` and in which di
On Fri, Jul 3, 2020 at 3:44 PM Robert-André Mauchin wrote:
>
> On Friday, 3 July 2020 19:41:40 CEST Igor Raits wrote:
> > Just wanted to provide some update on this change.
> >
> > * %__cmake_in_source_build macro has been introduced and set to 1. It
> > controls what arguments are passed to `cmak
On Fri, 2020-07-03 at 21:35 +0200, Markus Larsson wrote:
>
> On 3 July 2020 21:30:26 CEST, Adam Williamson
> wrote:
> > On Thu, 2020-06-25 at 13:18 -0400, Ben Cotton wrote:
> > > https://fedoraproject.org/wiki/Changes/UseNanoByDefault
> > >
> > > == Summary ==
> > >
> > > Let's make Fedora mor
On 3 July 2020 21:54:10 CEST, Adam Williamson
wrote:
>On Fri, 2020-07-03 at 21:35 +0200, Markus Larsson wrote:
>>
>> On 3 July 2020 21:30:26 CEST, Adam Williamson
>> wrote:
>> > On Thu, 2020-06-25 at 13:18 -0400, Ben Cotton wrote:
>> > > https://fedoraproject.org/wiki/Changes/UseNanoByDefaul
On Friday, July 3, 2020 12:15:03 AM MST Nicolas Mailhot via devel wrote:
> Le jeudi 02 juillet 2020 à 15:19 -0500, Martin Jackson a écrit :
>
> > > 5-10 years? A better estimate would be 15-20 years. People aren't
> > > going to
> > > throw away perfectly fine systems and jump to new "cloud" platf
On Friday, July 3, 2020 3:37:34 AM MST Rahul Sundaram wrote:
> Hi
>
> On Fri, Jul 3, 2020 at 2:14 AM John M. Harris wrote:
> > None of those bugs were release blocking, and none of them meant that x86
> > wouldn't boot, or that core packages didn't work
>
> When you add so many qualifiers, you a
Hi,
it seems fedora:latest on docker hub is still F31.
$ docker run -it fedora:latest cat /etc/redhat-release
Unable to find image 'fedora:latest' locally
latest: Pulling from library/fedora
4c69497db035: Pull complete
Digest: sha256:ee55117b3058f2f12961184fae4b9c392586e400487626c6bd0d15b4eae94ecc
On 7/3/20 8:24 AM, PGNet Dev wrote:
> git _was_ trivially added to the local mock chroot, for its use, with obvious
> success, in the local mock build of the spec.
>
> COPR uses mock.
>
> So far, I have not seen how that's to be similarly done for the COPR env.
>
> Is is possible to, similarly,
On 7/3/20 2:07 PM, PGNet Dev wrote:
> from cmd line,
>
> copr-cli edit-chroot --packages git
>
> looks like it should work as well
and it does, nicely:
==> 14:26:43 Build 1517366: succeeded
___
devel mailing list -- devel@lists.fedoraproject.or
I just came from Windows 10 not too long ago, and it was the worst computer
experience that I've ever had. Had it since the first week it came out, so glad
that I don't see it anymore. Hope I never see it again. It was really rough
getting my laptop downgraded to Windows 7, since my pc was being
# Fedora Quality Assurance Meeting
# Date: 2020-07-06
# Time: 15:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net
Greetings testers!
We didn't meet for a few weeks, so let's check in and see where
things are. There's a bumper crop of
You can try fedora:rawhide instead...while I don't know to whom this
problem should be reported.
And Fedora have registry.fedoraproject.org/fedora, where fedora:latest
= fedora 33(rawhide)
Christoph Junghans 于2020年7月4日周六 上午4:49写道：
>
> Hi,
>
> it seems fedora:latest on docker hub is still F31.
>
Seems that fedora:latest is f31 at dockerhub, is this intentional?
CC: cve...@fedoraproject.org, maintainer for the docker image at dockerhub
Christoph Junghans 于2020年7月4日周六 上午4:49写道：
>
> Hi,
>
> it seems fedora:latest on docker hub is still F31.
> $ docker run -it fedora:latest cat /etc/redhat-
Hi all,
I know I unretired non-daw, but the Linux Audio community has developed
a drop-in replacement for non-session-manager as a fork called
new-session-manager. I've packaged it for both Ubuntu and now Fedora.
If anybody would be so kind as to review this package, the bug is at
https://bugzill
On 7/3/20 1:41 PM, Chris Murphy wrote:
> SSDs can fail in weird ways. Some spew garbage as they're failing,
> some go read-only. I've seen both. I don't have stats on how common it
> is for an SSD to go read-only as it fails, but once it happens you
> cannot fsck it. It won't accept writes. If it w
Hi
On Fri, Jul 3, 2020 at 4:32 PM John M. Harris Jr wrote:
> These "qualifiers" are important.
>
> 1) Yes, I did get a response, as I said in the first email. The response
> showed that there weren't any issues with the kernel or core packages at
> the
> time it was dropped.
>
What you originall
On Friday, July 3, 2020 9:40:34 PM MST Rahul Sundaram wrote:
> Hi
>
> On Fri, Jul 3, 2020 at 4:32 PM John M. Harris Jr wrote:
> > These "qualifiers" are important.
> >
> > 1) Yes, I did get a response, as I said in the first email. The response
> > showed that there weren't any issues with the ke
>it should be disabled so it doesn't kill our software
What should people who suffer from the fact that the kernel's OOM killer does
not work, and they are forced to hard reboot (and lose unsaved data) the
computer when it freezes? This is a serious and very common problem that exists
for a lo
>It is also unclear that it can prevent full OOM (both
>RAM and swap completely full) in all cases
Kernel's killer is also cannot prevent full OOM in all cases. earlyoom prevent
full OOM (and situations close to OOM) much more effective - faster (selects
victim in 5-50ms, monitoring interval is
83 matches
Mail list logo
