* Konstantin Kharlamov:
> FWIW, I was just thinking about it, and I came up with example you
> may like which shows exactly why BTRFS is bad for HDD. Consider
> development process. It includes rewriting source files over and
> over: you do `git checkout foo` and files are overwritten, you
> chang
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 compiled against the FlexiBLAS wrapper
> > library, which will set OpenBLAS
* Nicolas Mailhot via devel:
>> How do I let rpm generate the changelog automatically?
>
> This feature is not changelog generation, just changelog bumping on
> build events. You still need some other method to put non-build events
> in the changelog.
What is “changelog bumping”? Why is it neede
On 02.07.2020 07:35, Nicolas Mailhot via devel wrote:
> The detached changelog is just one more file in SRPM sources, which is
> modified by rpmbuild at `%build` time with other files rpmbuild
> modifies.
I don't like that. %changelog should be generated automatically on Koji
side.
--
Sincerely,
On 01.07.2020 23:00, Neal Gompa wrote:
> We still can't use NVIDIA proprietary drivers on UEFI because Fedora's
> kernel configuration is too strict for that. I personally consider it
> a good thing, but that's a problem for others.
NVIDIA proprietary drivers from RPM Fusion repository works absol
I just met something which might be of similar nature. Recent FF
78.0-1.fc33.x86_64 fails to start with older glibc:
~~~
$ firefox
XPCOMGlueLoad error for file /usr/lib64/firefox/libxul.so:
/usr/lib64/firefox/libxul.so: undefined symbol: pthread_getattr_np,
version GLIBC_2.32
Couldn't load XPCOM
On Wed, Jul 01, 2020 at 05:50:05PM -0400, Neal Gompa wrote:
> Red Hat probably doesn't care because most server users are not using
> UEFI yet.
That statement is false. UEFI is absolutely important to server users.
> That proportion goes down a lot as people transition from on
> premise
On Wed, 2020-07-01 at 11:07 -0500, Michael Catanzaro wrote:
> So the last two times thermald was proposed (first as a F32 change
> proposal, then more recently to the Workstation WG) it was rejected on
> the grounds that it was not useful without dptfxtract installed. Now
> it's clear that every
Alexey A. wrote:
> 2. Firefox's children processes "Web Content" gets +300 to its oom_score.
> It means that earlyoom will prefer to kill firefox tabs rather than entire
> browser. Similar behavior is already practiced in chromium and
> electron-based apps by default.
What about /usr/lib64/qt5/lib
On 01. 07. 20 19:34, Nicolas Mailhot via devel wrote:
Le mercredi 01 juillet 2020 à 18:35 +0200, Miro Hrončok a écrit :
Given the /usr/share font links in CSS won't work when the
documentation is
exposed via a webserver, I assume the docs are mostly intended to be
browsed
(possibly offline) from
Le 2020-07-02 09:52, Florian Weimer a écrit :
* Nicolas Mailhot via devel:
How do I let rpm generate the changelog automatically?
This feature is not changelog generation, just changelog bumping on
build events. You still need some other method to put non-build events
in the changelog.
What
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, 2020-07-02 at 11:17 +0200, Nicolas Mailhot wrote:
> Le 2020-07-02 09:52, Florian Weimer a écrit :
> > * Nicolas Mailhot via devel:
> >
> > > > How do I let rpm generate the changelog automatically?
> > >
> > > This feature is not changelog
* Nicolas Mailhot:
> Le 2020-07-02 09:52, Florian Weimer a écrit :
>> * Nicolas Mailhot via devel:
>>
How do I let rpm generate the changelog automatically?
>>>
>>> This feature is not changelog generation, just changelog bumping on
>>> build events. You still need some other method to put no
Le 2020-07-02 09:59, Vitaly Zaitsev via devel a écrit :
On 02.07.2020 07:35, Nicolas Mailhot via devel wrote:
The detached changelog is just one more file in SRPM sources, which is
modified by rpmbuild at `%build` time with other files rpmbuild
modifies.
I don't like that. %changelog should be
Le 2020-07-02 11:17, Nicolas Mailhot via devel a écrit :
This may seem a bit complex and convoluted, but that’s because
autobumping
https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog_bumping
is a small addition over the big %auto_macros change.
https://fedoraproject
Le 2020-07-02 11:21, Igor Raits a écrit :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, 2020-07-02 at 11:17 +0200, Nicolas Mailhot wrote:
Le 2020-07-02 09:52, Florian Weimer a écrit :
> * Nicolas Mailhot via devel:
>
> > > How do I let rpm generate the changelog automatically?
> >
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, 2020-07-02 at 11:27 +0200, Nicolas Mailhot via devel wrote:
> Le 2020-07-02 09:59, Vitaly Zaitsev via devel a écrit :
> > On 02.07.2020 07:35, Nicolas Mailhot via devel wrote:
> > > The detached changelog is just one more file in SRPM sources
Le 2020-07-02 10:51, Miro Hrončok a écrit :
On 01. 07. 20 19:34, Nicolas Mailhot via devel wrote:
Le mercredi 01 juillet 2020 à 18:35 +0200, Miro Hrončok a écrit :
Given the /usr/share font links in CSS won't work when the
documentation is
exposed via a webserver, I assume the docs are mostly i
Le 2020-07-02 11:38, Igor Raits a écrit :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, 2020-07-02 at 11:27 +0200, Nicolas Mailhot via devel wrote:
Le 2020-07-02 09:59, Vitaly Zaitsev via devel a écrit :
> On 02.07.2020 07:35, Nicolas Mailhot via devel wrote:
> > The detached changelo
On Wed, 1 Jul 2020 at 15:05, Fabio Valentini wrote:
> On Mon, Jun 29, 2020 at 4:06 PM Jie Kang wrote:
> >
> > Hi all,
> >
> > javamail ursine is using version 1.5.2 while there are some module
> > streams at 1.6.x
> >
> > The upstream project also moved to the eclipse foundation and these
> > 1.
* Vít Ondruch:
> I just met something which might be of similar nature. Recent FF
> 78.0-1.fc33.x86_64 fails to start with older glibc:
>
>
> ~~~
>
> $ firefox
> XPCOMGlueLoad error for file /usr/lib64/firefox/libxul.so:
> /usr/lib64/firefox/libxul.so: undefined symbol: pthread_getattr_np,
> versi
* Nicolas Mailhot via devel:
> Le 2020-07-02 09:59, Vitaly Zaitsev via devel a écrit :
>> On 02.07.2020 07:35, Nicolas Mailhot via devel wrote:
>>> The detached changelog is just one more file in SRPM sources, which is
>>> modified by rpmbuild at `%build` time with other files rpmbuild
>>> modifie
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 build evr, the last packager id, etc).
Do you mean that the key/value file wi
On Wed, 2020-07-01 at 21:14 -0400, Sam Varshavchik wrote:
> Solomon Peachy writes:
>
> > Even putting that aside, for the past several years CSM/BIOS has
> > been
> > slowly bitrotting due to a lack of real testing, as the last few
> > Windows
> > releases have mandated use of UEFI for preinstalle
Le 2020-07-02 11:59, Florian Weimer a écrit :
* Nicolas Mailhot via devel:
Le 2020-07-02 09:59, Vitaly Zaitsev via devel a écrit :
On 02.07.2020 07:35, Nicolas Mailhot via devel wrote:
The detached changelog is just one more file in SRPM sources, which
is
modified by rpmbuild at `%build` tim
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, 2020-07-02 at 12:20 +0200, Nicolas Mailhot via devel wrote:
> Le 2020-07-02 11:59, Florian Weimer a écrit :
> > * Nicolas Mailhot via devel:
> >
> > > Le 2020-07-02 09:59, Vitaly Zaitsev via devel a écrit :
> > > > On 02.07.2020 07:35, Nicol
On Thu, Jul 2, 2020 at 4:06 AM Vitaly Zaitsev via devel
wrote:
>
> On 01.07.2020 23:00, Neal Gompa wrote:
> > We still can't use NVIDIA proprietary drivers on UEFI because Fedora's
> > kernel configuration is too strict for that. I personally consider it
> > a good thing, but that's a problem for
On Thu, Jul 2, 2020 at 1:55 AM John M. Harris Jr wrote:
>
> On Wednesday, July 1, 2020 7:30:37 AM MST Lennart Poettering wrote:
> > On Mi, 01.07.20 14:45, Hans de Goede (hdego...@redhat.com) wrote:
> >
> >
> > > I'm not in the bootloader-team, but I do work very closely with them,
> > > so I have
Le 2020-07-02 12:42, Igor Raits a écrit :
So who is going to implement necessary changes in mock and koji for
this proposal to be complete?
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 th
Sergio Belkin wrote:
> Regarding to " format not a string literal and no format arguments
> [-Werror=format-security]" message.
> Afaik instructions of kind printf(format,var1,var2,...) always be fail,
> since it can't verify in compile time that the format includes the number
> of variables that
On 2.7.2020 10:16, nick...@gmail.com wrote:
On Wed, 2020-07-01 at 21:14 -0400, Sam Varshavchik wrote:
Solomon Peachy writes:
Even putting that aside, for the past several years CSM/BIOS has
been
slowly bitrotting due to a lack of real testing, as the last few
Windows
releases have mandated use
On Thu, Jul 02, 2020 at 10:35:27AM +0200, Vít Ondruch wrote:
> I just met something which might be of similar nature. Recent FF
> 78.0-1.fc33.x86_64 fails to start with older glibc:
>
>
> ~~~
>
> $ firefox
> XPCOMGlueLoad error for file /usr/lib64/firefox/libxul.so:
> /usr/lib64/firefox/libxul.s
In fact, I am not at this time.
On Wed, 2020-07-01 at 15:38 +0200, Vít Ondruch wrote:
> Hi Alexandre,
>
> Thank you for your offer. I just wonder, are you sponsored into
> packager group?
>
>
>
> Vít
>
>
>
>
>
> Dne 29. 06. 20 v 17:57 alexandrebfar...@gmail.com napsal(a):
> > I'm interest
On Wed, Jul 1, 2020 at 12:19 AM Jóhann B. Guðmundsson
wrote:
>
> On 30.6.2020 22:38, Kevin Kofler wrote:
> > Jóhann B. Guðmundsson wrote:
> >> sd-boot is already installed on end users system, is light weight
> >> compared to Grub ( sd-boot only supports uefi,smaller code size, easier
> >> to main
On 7/2/20 12:55 AM, John M. Harris Jr wrote:
Lennart,
We don't need more systemd-bloat just to boot our systems. However your
bootloader works, it doesn't really matter if it's not up to snuff with GRUB2.
When it supports LUKS, LVM, LUKS+LVM, a recovery console and several
filesystems, then
On Wed, Jul 1, 2020 at 3:29 PM Alek Paunov wrote:
>
> On 2020-06-30 14:34, Jóhann B. Guðmundsson wrote:
> > Share your thoughts and comments on how such move might affect you so
> > feedback can be collected for the future on why such a change might be
> > bad, how it might affect the distribution
>What about /usr/lib64/qt5/libexec/QtWebEngineProcess processes?
These processes get oom_score_adj=300 out of the box, see
https://pastebin.com/AFVU9U8X
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@
Hi,
I've orphaned the nuttcp component. It is long time since I last used
it, and I do not plan updating it again. If you like networking tools
this may be a package for you!
regards,
Nikos
___
devel mailing list -- devel@lists.fedoraproject.org
To unsu
On Thu, Jul 02, 2020 at 01:16:43PM +0300, nick...@gmail.com wrote:
> The only Windows that no longer supports 32-bit systems is Windows
> Server. So the obsolescence of Windows 7 and XP is irrelevant.
I'm not talking about *old* hardware here, which obviously works as well
now as it did before. I
On Wed, Jul 1, 2020 at 10:31 pm, Ralf Corsepius
wrote:
I definitely own BIOS-only systems, which have been sold long after
2005
and which are still in everyday use.
If we're looking for more data points, my System76 laptop is from 2015
(still just under five years old!) and only supports leg
On Wed, Jul 1, 2020 at 11:01 pm, Roberto Ragusa
wrote:
The real solution would be to make wise usage of LVM, for example by
not
allocating 100% of the extents at the beginning (or even dm-thin)
and/or
using filesystems where a shrink is supported (I'm here blaming xfs
for not having this, whil
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 in, your choice, not mine.
I believe
Just to revisit this, my issue turned out to be a bug in a p11-kit
component, opencryptoki, that failed to lock, causing its
deinitialization routine to trample some stuff. That's been fixed
now. Sorry for blaming glibc, Florian! :)
- Alex
- Original Message -
> From: "Vít Ondruch"
> To
On Wednesday, July 1, 2020 4:47:51 PM EDT Sergio Belkin wrote:
> The line in the code is :
>
> if(upLogPerror) ::write(2,logbuf,n); \
>
> Regarding to " format not a string literal and no format arguments
> [-Werror=format-security]" message.
> Afaik instructions of kind printf(format,var1,var2,
On Wed, Jul 1, 2020 at 10:01 PM Neal Gompa wrote:
>
> On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson
> wrote:
> >
> > On 1.7.2020 16:10, Solomon Peachy wrote:
> > > On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragusa wrote:
> > >> I'm currently using BIOS, grub, grub2 basically everyw
Dropping the "legacy BIOS" support is a horrible idea:
Not just there are a lot of "legacy BIOS" PCs, especially in a corporate world
where the upgrades are slower than in the domestic environments.
There are also a lot of really modern PCs running a coreboot firmware with a
SeaBIOS payload - whi
> > If you need Secure Boot feature to be enabled, you must sign the
> > compiled kmod packages with your own CA.
> >
>
> This is what's wrong with everything. *This is not okay*. This is
> intentionally a poisonous user experience because we provide no
> automatic or easy way for this to be done.
On Thu, Jul 2, 2020 at 9:49 AM Peter Robinson wrote:
>
> On Wed, Jul 1, 2020 at 10:01 PM Neal Gompa wrote:
> >
> > On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson
> > wrote:
> > >
> > > On 1.7.2020 16:10, Solomon Peachy wrote:
> > > > On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragus
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 side tag, whatever). Koji is still in
> charge, the bumping is just integrate
On Thu, Jul 02, 2020 at 02:07:17PM -, Ivan Ivanov wrote:
> hopefully those which don't have a SystemD security-vulnerable
> bloatware
Oh, FFS.
In this comparison, grub2 is the _highly_ bloated,
everything-AND-the-kitchen-sink solution with multiple CVEs under its
belt, and systemd-boot i
On Wed, Jul 01, 2020 at 05:47:51PM -0300, Sergio Belkin wrote:
> So the question is: in this case I can override the Fedora compiler flags?
Other people replied with suggestions how to make the code better, but
let me also answer this question directly:
yes you can, the guidelines say:
> Adding
On 7/2/20 4:46 AM, Peter Robinson wrote:
On Wed, Jul 1, 2020 at 12:19 AM Jóhann B. Guðmundsson
wrote:
On 30.6.2020 22:38, Kevin Kofler wrote:
In addition, as far as I know, systemd-boot is not compatible with the
"Secure Boot" shim.
sd-boot works fine with secure boot but good point I'll add
On 7/2/20 3:16 AM, nick...@gmail.com wrote:
Note that, even though Microsoft is pushing for UEFI on new systems in
the OEM version of Windows, they still support booting in legacy BIOS
mode in the latest Windows 10 version and they even support a 32-bit
version of Windows 10, which Fedora no long
On 7/1/20 9:24 AM, Josef Bacik wrote:
> On 7/1/20 7:49 AM, Steven Whitehouse wrote:
>> Hi,
>>
>> On 01/07/2020 12:09, Zbigniew Jędrzejewski-Szmek wrote:
>>> On Wed, Jul 01, 2020 at 11:28:10AM +0100, Steven Whitehouse wrote:
Hi,
On 01/07/2020 07:54, Zbigniew Jędrzejewski-Szmek wrote:
Hi,
this is partially an outgrowth of the discussion about btrfs as
default, but makes sense independently too...
It would be great if we could fairly reliably boot with a read-only
root file system, all the way to the graphical environment. Obviously,
such a machine will not be fully functional,
On Thu, Jul 2, 2020 at 11:54 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:
> Hi,
>
> this is partially an outgrowth of the discussion about btrfs as
> default, but makes sense independently too...
>
> It would be great if we could fairly reliably boot with a read-only
> root file syst
On Thu, Jul 02, 2020 at 03:53:26PM +, Zbigniew Jędrzejewski-Szmek wrote:
> Hi,
>
> this is partially an outgrowth of the discussion about btrfs as
> default, but makes sense independently too...
>
> It would be great if we could fairly reliably boot with a read-only
> root file system, all th
On Thu, Jul 2, 2020 at 12:05 PM Daniel P. Berrangé wrote:
>
> On Thu, Jul 02, 2020 at 03:53:26PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > Hi,
> >
> > this is partially an outgrowth of the discussion about btrfs as
> > default, but makes sense independently too...
> >
> > It would be great if
Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Jul 01, 2020 at 05:47:51PM -0300, Sergio Belkin wrote:
> > So the question is: in this case I can override the Fedora compiler flags?
>
> Other people replied with suggestions how to make the code better, but
> let me also answer this question directl
On Thu, Jul 02, 2020 at 05:05:09PM +0100, Daniel P. Berrangé wrote:
> On Thu, Jul 02, 2020 at 03:53:26PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > Hi,
> >
> > this is partially an outgrowth of the discussion about btrfs as
> > default, but makes sense independently too...
> >
> > It would be
On 02.07.2020 17:53, Zbigniew Jędrzejewski-Szmek wrote:
> It would be great if we could fairly reliably boot with a read-only
> root file system, all the way to the graphical environment.
Already implemented - Silverblue.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
On 01.07.2020 22:47, Sergio Belkin wrote:
> So the question is: in this case I can override the Fedora compiler flags?
Don't do this, please. You should fix such potentially vulnerable parts
of code and send your patch to upstream.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
_
OLD: Fedora-Rawhide-20200701.n.0
NEW: Fedora-Rawhide-20200702.n.0
= SUMMARY =
Added images:0
Dropped images: 1
Added packages: 11
Dropped packages:0
Upgraded packages: 73
Downgraded packages: 0
Size of added packages: 34.52 MiB
Size of dropped packages:0
Hello all!
Is it okay to package Google's static-only WebRTC library? This package
will provide only webrtc-static and webrtc-devel subpackages.
I need this library to build another packages. Bundling it directly is
not a good idea, because this library is very big and significantly
slows down th
On Thu, Jul 2, 2020 at 12:41 PM Vitaly Zaitsev via devel
wrote:
>
> Hello all!
>
> Is it okay to package Google's static-only WebRTC library? This package
> will provide only webrtc-static and webrtc-devel subpackages.
>
> I need this library to build another packages. Bundling it directly is
> no
El jue., 2 jul. 2020 a las 13:30, Vitaly Zaitsev via devel (<
devel@lists.fedoraproject.org>) escribió:
> On 01.07.2020 22:47, Sergio Belkin wrote:
> > So the question is: in this case I can override the Fedora compiler
> flags?
>
> Don't do this, please. You should fix such potentially vulnerable
On 02/07/20 14:41 -0300, Sergio Belkin wrote:
El jue., 2 jul. 2020 a las 13:30, Vitaly Zaitsev via devel (<
devel@lists.fedoraproject.org>) escribió:
On 01.07.2020 22:47, Sergio Belkin wrote:
> So the question is: in this case I can override the Fedora compiler
flags?
Don't do this, please. Y
On Thu, 2020-07-02 at 09:44 +0200, Florian Weimer wrote:
> * Konstantin Kharlamov:
>
> > FWIW, I was just thinking about it, and I came up with example you
> > may like which shows exactly why BTRFS is bad for HDD. Consider
> > development process. It includes rewriting source files over and
> > o
Sergio Belkin wrote:
> Thanks everyone, I guess the same thing goes for:
>
> warning: ignoring return value of 'ssize_t write(int, const void*, size_t)'
> declared with attribute 'warn_unused_result'
>
> (The line in the source code is if(upLogPerror) ::write(2,logbuf,n); \ )
>
> doesn't it?
On Thu, Jul 02, 2020 at 06:27:44PM +0200, Vitaly Zaitsev via devel wrote:
> On 02.07.2020 17:53, Zbigniew Jędrzejewski-Szmek wrote:
> > It would be great if we could fairly reliably boot with a read-only
> > root file system, all the way to the graphical environment.
>
> Already implemented - Silv
On 7/1/20 9:49 PM, Chris Adams wrote:
Once upon a time, Josef Bacik said:
This sounds like a "wtf, why are you doing this btrfs?" sort of
thing, but this is just the reality of using checksums. It's a
checksum, not ECC. We don't know _which_ bits are fucked, we just
know somethings fucked, so
On Thursday, July 2, 2020 5:08:14 AM MST Brandon Nielsen wrote:
> On 7/2/20 12:55 AM, John M. Harris Jr wrote:
>
>
>
>
> >
> > Lennart,
> >
> > We don't need more systemd-bloat just to boot our systems. However your
> > bootloader works, it doesn't really matter if it's not up to snuff with
>
On Thursday, July 2, 2020 5:08:31 AM MST Peter Robinson wrote:
> On Wed, Jul 1, 2020 at 3:29 PM Alek Paunov wrote:
>
> >
> >
> > On 2020-06-30 14:34, Jóhann B. Guðmundsson wrote:
> >
> > > Share your thoughts and comments on how such move might affect you so
> > > feedback can be collected for t
On 7/2/20 2:56 PM, John M. Harris Jr wrote:
On Thursday, July 2, 2020 5:08:14 AM MST Brandon Nielsen wrote:
On 7/2/20 12:55 AM, John M. Harris Jr wrote:
Lennart,
We don't need more systemd-bloat just to boot our systems. However your
bootloader works, it doesn't really matter if it's not
On 02.07.20 17:53, Zbigniew Jędrzejewski-Szmek wrote:
> It would be great if we could fairly reliably boot with a read-only
> root file system, all the way to the graphical environment. Obviously,
> such a machine will not be fully functional, but for users, debugging a
> disk problem when they hav
On Wednesday, July 1, 2020 2:28:39 PM MST Jóhann B. Guðmundsson wrote:
> On 1.7.2020 21:00, Neal Gompa wrote:
>
> > On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson
> > wrote:
> >
> >> On 1.7.2020 16:10, Solomon Peachy wrote:
> >>
> >>> On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Rag
On 7/2/20 3:10 PM, Christopher Engelhard wrote:
On 02.07.20 17:53, Zbigniew Jędrzejewski-Szmek wrote:
It would be great if we could fairly reliably boot with a read-only
root file system, all the way to the graphical environment. Obviously,
such a machine will not be fully functional, but for us
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 stop
updating, and likely move to something that is still supporting BIOS, if the
On 7/2/20 3:19 PM, Martin Jackson wrote:
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 stop
updating, and likely move to somet
On Thu, 2020-07-02 at 08:24 -0700, Gordon Messmer wrote:
> On 7/2/20 3:16 AM, nick...@gmail.com wrote:
> > Note that, even though Microsoft is pushing for UEFI on new systems
> > in
> > the OEM version of Windows, they still support booting in legacy
> > BIOS
> > mode in the latest Windows 10 versi
On 7/1/20 12:50 PM, Chris Murphy wrote:
...
> Integrity checking is highly valued by some and less by others.
> Considering that we know hardware isn't 100% reliable, and doesn't
> always report its own failures as expected, and hence why most file
> systems now at least checksum metadata, it's n
On Thursday, July 2, 2020 1:19:22 PM MST Martin Jackson wrote:
> > 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 stop
>
On Thursday, July 2, 2020 1:30:41 PM MST Brandon Nielsen wrote:
> On 7/2/20 3:19 PM, Martin Jackson wrote:
>
> >
> >
> >> 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 th
On 2020-07-01 23:04, Michael Catanzaro wrote:
On Wed, Jul 1, 2020 at 11:01 pm, Roberto Ragusa wrote:
The real solution would be to make wise usage of LVM, for example by not
allocating 100% of the extents at the beginning (or even dm-thin) and/or
using filesystems where a shrink is supported (I
On Thursday, July 2, 2020 8:24:49 AM MST Gordon Messmer wrote:
> On 7/2/20 3:16 AM, nick...@gmail.com wrote:
>
> > Note that, even though Microsoft is pushing for UEFI on new systems in
> > the OEM version of Windows, they still support booting in legacy BIOS
> > mode in the latest Windows 10 vers
On Thursday, 2 July 2020 21.38.46 WEST Eric Sandeen wrote:
> 3 files in lost+found, -1 files gone/unreachable
This last line from the xfs test seems suspicious (the -1 file gone). :-)
--
José Abílio
___
devel mailing list -- devel@lists.fedoraproject.o
On Thursday, July 2, 2020 7:50:25 AM MST Solomon Peachy wrote:
> On Thu, Jul 02, 2020 at 02:07:17PM -, Ivan Ivanov wrote:
> > hopefully those which don't have a SystemD security-vulnerable
> > bloatware
>
> Oh, FFS.
>
> In this comparison, grub2 is the _highly_ bloated,
> everything-AND-the-k
On Wednesday, July 1, 2020 10:44:03 AM MST Alexey Avramov wrote:
> >10% and 5% to 1% and 0%
>
>
> Default values is already changed to 4% (but not more than 400 MiB) and 2%
> (but not more than 200 MiB). A nonzero threshold helps maintain disk cache
> and speeds up system recovery after correctio
On Thu, Jul 2, 2020 at 6:01 AM Neal Gompa wrote:
>
> Here's the thing: systemd-boot is very good at what it does. The
> Gummiboot project was a great demonstration of a nice, simple boot
> manager. Kay decided to fold it into the systemd project, which is
> fine. It has benefited from the tighter
HI
On Thu, Jul 2, 2020 at 4:54 PM John M. Harris Jr
> That's not really true. When it came down to it, it was dropped while 32
> bit
> Fedora still worked perfectly. I'm left with 5 systems that will never be
> updated as a result. I asked for a list of issues that warranted ending 32
> bit
> sup
On 02/07/20 07:08 -0500, Brandon Nielsen wrote:
On 7/2/20 12:55 AM, John M. Harris Jr wrote:
Lennart,
We don't need more systemd-bloat just to boot our systems. However your
bootloader works, it doesn't really matter if it's not up to snuff with GRUB2.
When it supports LUKS, LVM, LUKS+LVM,
On 7/2/20 3:58 PM, José Abílio Matos wrote:
> On Thursday, 2 July 2020 21.38.46 WEST Eric Sandeen wrote:
>> 3 files in lost+found, -1 files gone/unreachable
>
> This last line from the xfs test seems suspicious (the -1 file gone). :-)
It is weird, but it shows I didn't fudge the numbers ;)
direc
On 7/2/20 3:42 PM, John M. Harris Jr wrote:
GRUB2, which is a UEFI bootloader as well, is a far superior bootloader to
systemd-bloat, and it supports usecases that are supported by Anaconda (the
Fedora installer framework) that systemd-bloat doesn't, as addressed elsewhere
in this thread by m
On 7/2/20 4:38 PM, Eric Sandeen wrote:
On 7/1/20 12:50 PM, Chris Murphy wrote:
...
Integrity checking is highly valued by some and less by others.
Considering that we know hardware isn't 100% reliable, and doesn't
always report its own failures as expected, and hence why most file
systems now
On Thu, Jul 2, 2020 at 10:54 PM John M. Harris Jr wrote:
>
> On Thursday, July 2, 2020 8:24:49 AM MST Gordon Messmer wrote:
> > On 7/2/20 3:16 AM, nick...@gmail.com wrote:
> >
> > > Note that, even though Microsoft is pushing for UEFI on new systems in
> > > the OEM version of Windows, they still
On Thursday, July 2, 2020 3:09:14 PM MST Alexander Ploumistos wrote:
> On Thu, Jul 2, 2020 at 10:54 PM John M. Harris Jr
> wrote:
> >
> >
> > On Thursday, July 2, 2020 8:24:49 AM MST Gordon Messmer wrote:
> >
> > > On 7/2/20 3:16 AM, nick...@gmail.com wrote:
> > >
> > >
> > >
> > > > Note that, e
Question about systemd-boot vs GRUB2.
One of the current stumbling blocks is the lack of LUKS2 support in
GRUB2. Does sytemd-boot support LUKS2?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedo
On Thu, Jul 2, 2020 at 6:24 PM Alex Thomas wrote:
>
> Question about systemd-boot vs GRUB2.
> One of the current stumbling blocks is the lack of LUKS2 support in
> GRUB2. Does sytemd-boot support LUKS2?
GRUB2 supports LUKS2 in v2.06. sd-boot does not support it.
--
真実はいつも一つ！/ Always, there's
Ok thought I had read somewhere that is was in the pipeline but had
not merged. Must be old data.
On Thu, Jul 2, 2020 at 5:34 PM Neal Gompa wrote:
>
> On Thu, Jul 2, 2020 at 6:24 PM Alex Thomas wrote:
> >
> > Question about systemd-boot vs GRUB2.
> > One of the current stumbling blocks is the la
On Fri, Jul 3, 2020 at 12:22 AM John M. Harris Jr wrote:
>
> That's a link to the release announcement. If you follow the thread, you'll
> find that I was provided a link to two bugzilla links are to meta links to
> blockers, where the items that are blocking are not issues preventing x86
> system
1 - 100 of 120 matches
Mail list logo
