On Thursday, July 2, 2020 11:45:09 PM MST Christopher Engelhard wrote:
> Can we maybe not restart this entire debate? i686 in Fedora has run down
> the curtain and joined the choir invisible. Whether we think that was
> the correct decision or not, there is absolutely no point in rehashing
> all th
Can we maybe not restart this entire debate? i686 in Fedora has run down
the curtain and joined the choir invisible. Whether we think that was
the correct decision or not, there is absolutely no point in rehashing
all the original arguments, let alone in a thread about BIOS support.
Christopher
O
On Thursday, July 2, 2020 6:56:03 PM MST Solomon Peachy wrote:
> 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.
On Thursday, July 2, 2020 4:06:55 PM MST Alexander Ploumistos wrote:
> On Fri, Jul 3, 2020 at 12:49 AM John M. Harris Jr
> > None of the linked blockers are core packages, and some of them are
> > outright not designed to work on anything other than 64 bit. I really
> > don't understand how you ca
On Thursday, July 2, 2020 4:06:07 PM MST Rahul Sundaram wrote:
> 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 respo
Hello,
I'm sorry for a late notice, the 3.37.3 release (will be done today) of
the evolution-data-server has a soname version bump on the
libedataserver library. It has a change on an EWebDAVSession API, which
I do not think is used by many components, if any other than evolution
itself at
On Thu, Jul 02, 2020 at 03:17:58PM -0500, Brandon Nielsen wrote:
> 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 envi
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 _ctag1H
-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
>
>
> https://download.copr.fedorainfracloud.org/results/pgfed/
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 d
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 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 i
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
> __
(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, an
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 data
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 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 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 fi
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 st
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 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
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 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
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 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
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 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 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 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 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
> sup
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
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 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 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 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 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 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 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 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 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/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
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: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
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 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 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 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 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 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 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
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, 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
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
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 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
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
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 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 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 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
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 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 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 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
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 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:
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/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 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 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 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 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
> > 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.
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
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
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,
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 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 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 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 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
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
>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...@
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
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 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
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 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
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
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
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
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
-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
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
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
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
* 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
* 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
1 - 100 of 120 matches
Mail list logo
