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
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 -
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
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
>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
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
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
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:
>
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
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"
>
> > 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 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
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
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.
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
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,
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
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
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
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
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
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:
>
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
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
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
> >
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 -
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)
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
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:
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
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
>
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
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,
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
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/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.
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 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,
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
>
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
On Thursday, July 2, 2020 3:47:00 PM MST Alexander Ploumistos wrote:
> 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
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 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
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
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
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
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 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
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,
>
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,
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
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
>
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
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
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 --
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
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
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
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
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
On Fri, Jul 3, 2020 at 12:49 AM John M. Harris Jr wrote:
>
> On Thursday, July 2, 2020 3:47:00 PM MST Alexander Ploumistos wrote:
> > 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
Hi
On Thu, Jul 2, 2020 at 6:49 PM John M. Harris Jr wrote:
>That's a link to the release announcement.
Hardly the first time it was announced. It refers to x86_32 sig that was
formed much earlier which itself was a response to an earlier warning that
x86_32 support is going away unless people
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
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
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
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
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 ;)
On 2020-07-02 13:08, Peter Robinson wrote:
I suppose "very good state" is a relative term, upstream hasn't seen a
release since 2016 so is essentially "unmaintained", not sure it
supports secure boot, probably has a bunch of CVEs (see point about
maintenance). I think it only lives on in Fedora
On Thu, 2020-07-02 at 21:37 +0300, Konstantin Kharlamov wrote:
> 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
On 7/2/20 4:44 PM, Josef Bacik wrote:
> We're talking about this issue like it's reasonable that xfs and ext4 are
> going to allow the user to get back a bunch of data they don't know is ok or
> not. We're also talking about it like the user should be able to carry on his
> happy merry way. In
On Friday, July 3, 2020 3:00:48 AM CEST PGNet Dev wrote:
> https://download.copr.fedorainfracloud.org/results/pgfed/nginx-mainline/fedora-32-x86_64/01516680-nginx/nginx.spec
There are things like:
%global forgeurl1 https://github.com/openresty/headers-more-nginx-module
%define _ctag1
Yeah I mean the general discussion, not you specifically. Thanks,
Josef
On Thu, Jul 2, 2020 at 8:38 PM Eric Sandeen wrote:
> On 7/2/20 4:44 PM, Josef Bacik wrote:
> > We're talking about this issue like it's reasonable that xfs and ext4
> are going to allow the user to get back a bunch of
(i'd been discussing this issue with praiskup @ copr-devel/buildsys; he
suggested that I bring it here ...)
This spec
https://download.copr.fedorainfracloud.org/results/pgfed/nginx-mainline/fedora-32-x86_64/01516680-nginx/nginx.spec
which uses forgemeta to pull multiple SCM sources,
On Thu, Jul 02, 2020 at 02:00:16PM -0700, John M. Harris Jr wrote:
> If it doesn't have any reported CVEs, that's because nobody uses it.
You may be right, but one can't have vulnerabilies in functionality that
doesn't exist.
(I find it hilarious that "small, simple, single-purpose" is suddenly
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
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
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)
Nikos Mavrogiannopoulos 于2020年7月2日周四 下午8:17写道：
>
> 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!
OKay, I am taking this.
>
> regards,
> Nikos
>
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 fsync heavy world out of the box,
> using treelog enabled by
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, 2020-07-02 at 18:00 -0700, PGNet Dev wrote:
> (i'd been discussing this issue with praiskup @ copr-devel/buildsys;
> he suggested that I bring it here ...)
>
> This spec
>
>
>
-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,
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
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
* 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
On Wed, Jul 1, 2020 at 11:25 PM Chris Murphy wrote:
>
> This is called 'dup' profile in Btrfs. Two copies of a block group.
Two copies of a block group ^on the same drive.
--
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To
* 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
>
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.
--
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
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
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
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
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
> >
* 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,
>
1 - 100 of 136 matches
Mail list logo
