Done.
Now you can add yshestakov as comaintainer.
чт, 9 июл. 2020 г. в 09:47, Andrey Maslennikov :
>
> Yes, I trust him completely on this matter.
>
> @Vascom thank you for your help! Should I open a ticket for it?
> ___
> devel mailing list -- devel@lis
Yes, I trust him completely on this matter.
@Vascom thank you for your help! Should I open a ticket for it?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct
Are you sure that he will be a good maintainer?
If you want to follow this
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer
I can be a sponsor.
чт, 9 июл. 2020 г. в 09:01, Andrey Maslennikov :
>
> Hello!
>
> I'm trying to add a co-maintainer to my
Kevin Fenzi writes:
> What does 'support for clevis' there look like? you mean just binding a
> encrypted drive to look for clevis servers on boot?
Yes, currently we only support the "tang" pin.
> I think tpm2 might be good, but lots of machines don't have tpm2.
> So I would think it would
Richard Hughes writes:
> On Wed, 8 Jul 2020 at 09:59, Marius Vollmer wrote:
>> As I understand it, there is a lot of evolving OS specific subtlety
>> involved, so I am asking specifically how this would look on current
>> Fedora and what to expect in the near future.
>
> Just a heads-up; the PC
Hello!
I'm trying to add a co-maintainer to my project
(https://src.fedoraproject.org/rpms/ucx). User I want to add just recently
joined to Fedora environment (the name is yshestakov) and need a sponsor to
become a packager. I've tried to add him to the group, but he didn't get any
notificatio
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2020-07-09 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.
Local time information (via. uitime):
= Day: Thursday ==
2020-07-09 09:00 PDT US/Pacific
2020-07-09 1
Hi
I'm working on updating the mingw toolchain [1], and am hitting the
situation [2] where I build with -fstack-protector in the ldflags, can
confirm that -lssp and -lssp_nonshared are automatically added to the
ldflags (seen via gcc -v [3] and strace), but I still get i.e. with this
minimal
On Wed, 2020-07-08 at 17:23 -0400, James Cassell wrote:
> On Tue, Jul 7, 2020, at 12:30 PM, Adam Williamson wrote:
> > On Mon, 2020-07-06 at 20:06 -0600, Chris Murphy wrote:
> > > On Mon, Jul 6, 2020 at 4:48 PM Gerald Henriksen
> > > wrote:
> > > >
> > > > On Wed, 1 Jul 2020 14:24:37 -0400, you
On Tue, Jul 7, 2020, at 12:30 PM, Adam Williamson wrote:
> On Mon, 2020-07-06 at 20:06 -0600, Chris Murphy wrote:
> > On Mon, Jul 6, 2020 at 4:48 PM Gerald Henriksen wrote:
> > >
> > > On Wed, 1 Jul 2020 14:24:37 -0400, you wrote:
> > >
> > > > On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew
On Wednesday, July 8, 2020 10:20:30 AM MST Matthew Miller wrote:
> On Wed, Jul 08, 2020 at 11:08:53AM -0600, Chris Murphy wrote:
>
> > I expect beefy CPU systems, including gaming systems, to have the same
> > or better read/write performance using mount option compress=zstd:1.
> > Where I've seen
On Wednesday, July 8, 2020 10:04:01 AM MST Richard Hughes wrote:
> On Wed, 8 Jul 2020 at 16:48, John M. Harris Jr
> wrote:
> > needlessly disables a lot of kernel functionality
>
>
> It disables functionality which can destroy platform security.
It disables functionality that users need, such a
On Wednesday, July 8, 2020 12:53:05 PM MST Przemek Klosowski via devel wrote:
> On 7/8/20 12:15 PM, John M. Harris Jr wrote:
> > Really, this is starting to sound like it's more of an issue with web
> > browsers, and less of a problem with our current configurations, without
> > EarlyOOM needlessly
On Wed, Jul 8, 2020 at 12:54 PM Adam Williamson
wrote:
>
> On Wed, 2020-07-08 at 00:24 -0600, Chris Murphy wrote:
> > Hi,
> >
> > The change proposal has a 'compression option' and we kinda need to
> > get organized.
> > https://fedoraproject.org/wiki/Changes/BtrfsByDefault#Compression
>
> It feel
On Wed, Jul 8, 2020 at 1:45 PM Matthew Miller wrote:
>
> On Wed, Jul 08, 2020 at 11:37:11AM -0600, Chris Murphy wrote:
> > If it's the center, I think that favors the mount option approach and
> > do it with the lowest level of compression, i.e. zstd:1. But this
> > suggests more benchmarking stil
On 7/8/20 12:15 PM, John M. Harris Jr wrote:
I'd rather crash and restart where I left off than have
the computer drag me along trying to save my application.
Sorry, what? Why would your data not be on your system? What about "the modern
way of computing" would move your data from your system to
On Wed, Jul 08, 2020 at 11:37:11AM -0600, Chris Murphy wrote:
> If it's the center, I think that favors the mount option approach and
> do it with the lowest level of compression, i.e. zstd:1. But this
> suggests more benchmarking still, to make certain it's well understood
> what the range of writ
It feels to me like this might be a great area to slow down a bit and
not try to do everything at once.
Why don't we just make the simplest change for F33 - going to btrfs by
default - and see how that goes, and consider the 'options' for F34 or
later, rather than changing too much stuff at onc
On 7/8/20 10:47 AM, John M. Harris Jr wrote:
On Tuesday, July 7, 2020 3:17:16 AM MST Gerd Hoffmann wrote:
On Mon, Jul 06, 2020 at 01:26:31PM -0700, John M. Harris Jr wrote:
Well, if that is your concern the answer is secure boot. That will not
only prevent tampering with /boot files, but als
Once upon a time, Richard Hughes said:
> tl;dr: if you care about platform security at all, enable secure boot.
If you want to use interesting and useful kernel technologies (namely
eBPF), disable secure boot. That's a real killer of secure boot IMHO.
--
Chris Adams
__
On Wed, 2020-07-08 at 00:24 -0600, Chris Murphy wrote:
> Hi,
>
> The change proposal has a 'compression option' and we kinda need to
> get organized.
> https://fedoraproject.org/wiki/Changes/BtrfsByDefault#Compression
It feels to me like this might be a great area to slow down a bit and
not try t
On Wed, Jul 8, 2020 at 11:20 AM Matthew Miller wrote:
>
> On Wed, Jul 08, 2020 at 11:08:53AM -0600, Chris Murphy wrote:
> > I expect beefy CPU systems, including gaming systems, to have the same
> > or better read/write performance using mount option compress=zstd:1.
> > Where I've seen equal or b
On Wed, Jul 8, 2020 at 1:20 PM Matthew Miller wrote:
>
> On Wed, Jul 08, 2020 at 11:08:53AM -0600, Chris Murphy wrote:
> > I expect beefy CPU systems, including gaming systems, to have the same
> > or better read/write performance using mount option compress=zstd:1.
> > Where I've seen equal or be
On Wed, Jul 8, 2020 at 10:54 AM Mark Pearson wrote:
>
> I personally haven't had any experience with btrfs but if there are any
> guidelines on testing that we can do and what data should be collected to
> help out let me know and I'll see if we can hit up some of our platforms and
> get some n
On Wed, Jul 8, 2020 at 9:50 AM Matthew Miller wrote:
>
> On Wed, Jul 08, 2020 at 12:24:27AM -0600, Chris Murphy wrote:
> > 2. Benchmarking: this is hard. A simple tool for doing comparisons
> > among algorithms on a specific bit of hardware is lzbench.
> > https://github.com/inikep/lzbench
> > How
On Wed, Jul 08, 2020 at 11:08:53AM -0600, Chris Murphy wrote:
> I expect beefy CPU systems, including gaming systems, to have the same
> or better read/write performance using mount option compress=zstd:1.
> Where I've seen equal or better read performance, there can be a write
> performance drop i
On Wed, Jul 8, 2020 at 5:13 AM Kamil Paral wrote:
>
> On Wed, Jul 8, 2020 at 11:22 AM Dominique Martinet
> wrote:
>>
>> Please test, but if a file is deemed not compressible (based on, not
>> sure what? the first few blocks?) then it will be stored in the
>> non-compressed version.
>> You can ch
On Wed, 8 Jul 2020 at 16:48, John M. Harris Jr wrote:
> needlessly disables a lot of kernel functionality
It disables functionality which can destroy platform security.
> You cannot load kernel modules you've built
If you can build and insert your own kernel module you can do almost
anything to
> -Original Message-
> From: Matthew Miller
> Sent: Wednesday, July 8, 2020 11:51 AM
>
> On Wed, Jul 08, 2020 at 12:24:27AM -0600, Chris Murphy wrote:
> > 2. Benchmarking: this is hard. A simple tool for doing comparisons
> > among algorithms on a specific bit of hardware is lzbench.
> >
On Wed, Jul 8, 2020 at 5:24 AM Zbigniew Jędrzejewski-Szmek
wrote:
>
> https://fedoraproject.org/wiki/RawhideKernelNodebug
> links to
> http://dl.fedoraproject.org/pub/alt/rawhide-kernel-nodebug/fedora-rawhide-kernel-nodebug.repo
> which gives 404 now. The kernels seems to be there though. But with
Le 2020-07-08 17:19, Pavel Raiskup a écrit :
Small experiment (few-liner) for copr with "%bid, build system tag":
https://pagure.io/copr/copr/pull-request/1436
Well, that ties the system to corp, not koji, and like the other
proposal, that makes releases that do not import from one system to
On Tuesday, July 7, 2020 8:54:40 AM MST Przemek Klosowski via devel wrote:
> On 7/6/20 6:49 PM, John M. Harris Jr wrote:
> > Unless you're actively using all of those tabs (I don't know how you would
> > be, but it's certainly possible), swap sounds like the perfect solution.
> > Unless Firefox kee
OLD: Fedora-Rawhide-20200707.n.0
NEW: Fedora-Rawhide-20200708.n.0
= SUMMARY =
Added images:1
Dropped images: 5
Added packages: 14
Dropped packages:1
Upgraded packages: 173
Downgraded packages: 0
Size of added packages: 44.65 MiB
Size of dropped packages
On Wed, Jul 08, 2020 at 12:24:27AM -0600, Chris Murphy wrote:
> 2. Benchmarking: this is hard. A simple tool for doing comparisons
> among algorithms on a specific bit of hardware is lzbench.
> https://github.com/inikep/lzbench
> How to compile on F32.
> https://github.com/inikep/lzbench/issues/69
On Tuesday, July 7, 2020 3:17:16 AM MST Gerd Hoffmann wrote:
> On Mon, Jul 06, 2020 at 01:26:31PM -0700, John M. Harris Jr wrote:
>
> > On Monday, July 6, 2020 5:24:32 AM MST Gerd Hoffmann wrote:
> >
> > > Default fedora disk layout in UEFI mode is partitions for ESP, /boot
> > > and
> > > LVM.
On Wednesday, July 8, 2020 1:10:12 AM MST Kamil Paral wrote:
> On Wed, Jul 8, 2020 at 8:26 AM Chris Murphy wrote:
> > D. Which directories? Some may be outside of the installer's scope.
> >
> > /usr
> > /var/lib/flatpak
> > ~/.local/share/flatpak
>
> I have a concern regarding games. Currently,
On Wed, Jul 08, 2020 at 03:48:23PM +0200, Till Maas wrote:
> Just had another idea, how about instead of branch down from the rawhide
> branch to new branched to make Rawhide always use the fxy version that
> it develops. So instead of creating branched f33 later we would rename
> master to f33 now
On Wednesday, July 8, 2020 4:16:34 PM CEST Pavel Raiskup wrote:
> On Monday, July 6, 2020 10:19:31 AM CEST Adam Saleh wrote:
> > Piere (a.k.a Pingou), Nils and me worked on Rpmautospec [1] to solve this
> > problem few months ago.
> > It is a koji plugin as well as CLI tool that makes bumping the r
On Tue, Jul 07, 2020 at 15:16:22 -0400,
Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/PostgreSQL_13
== Summary ==
Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora
from version 12 to version 13 in the non-modular (main) builds.
While I like to have the latest po
On Wed, 8 Jul 2020 at 09:59, Marius Vollmer wrote:
> As I understand it, there is a lot of evolving OS specific subtlety
> involved, so I am asking specifically how this would look on current
> Fedora and what to expect in the near future.
Just a heads-up; the PCR0 changes when you upgrade the sy
On 08.07.2020 16:29, Pierre-Yves Chibon wrote:
> One wonder which I have is: should we keep a "master" branch, just as a
> symlink
> to the "rawhide" one for backward compatibility purposes?
Yes. Master branch is hardcoded in lots of places (infra, maintainer's
scripts, etc.) and such rename will
On Wednesday, 08 July 2020 at 16:29, Pierre-Yves Chibon wrote:
> On Wed, Jul 08, 2020 at 10:09:35AM -0400, Kaleb Keithley wrote:
> >Whatever name is picked: devel, main, rawhide, next, etc., how about
> >setting the default branch.
> >E.g. `git symbolic-ref HEAD refs/heads/rawhide`
> >
On Wed, Jul 08, 2020 at 11:58:58AM +0300, Marius Vollmer wrote:
> Hi,
>
> we have some rudimentary support for Clevis in the Cockpit Web Console,
> and now the question is, should we add support for "tpm2" to that?
What does 'support for clevis' there look like? you mean just binding a
encrypted
On Wed, Jul 08, 2020 at 09:25:32AM +0200, Pierre-Yves Chibon wrote:
> On Tue, Jul 07, 2020 at 10:38:01AM -0700, Michel Alexandre Salim wrote:
> > Should we make the script more robust and ignore invalid watcher
> > emails? Seems worrying if someone who's not even a packager can block
> > packager c
Announcing the creation of a new nightly release validation test event
for Fedora 33 Rawhide 20200708.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki
On Wed, Jul 08, 2020 at 10:09:35AM -0400, Kaleb Keithley wrote:
>Whatever name is picked: devel, main, rawhide, next, etc., how about
>setting the default branch.
>E.g. `git symbolic-ref HEAD refs/heads/rawhide`
>This way when someone clones the repo they don't need to know or reme
Meeting started by mhroncok at 14:01:30 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-07-08/fesco.2020-07-08-14.01.log.html
.
Meeting summary
---
* init process#topic init process#topic init process (mhroncok,
14:01:41)
* init proces
On Monday, July 6, 2020 10:19:31 AM CEST Adam Saleh wrote:
> Piere (a.k.a Pingou), Nils and me worked on Rpmautospec [1] to solve this
> problem few months ago.
> It is a koji plugin as well as CLI tool that makes bumping the release
> field and generating changelog problem of Koji,
> instead of pa
Whatever name is picked: devel, main, rawhide, next, etc., how about
setting the default branch.
E.g. `git symbolic-ref HEAD refs/heads/rawhide`
This way when someone clones the repo they don't need to know or remember
which name Fedora is using as the mainline development branch.
On Wed, Jul
On 08. 07. 20 15:48, Till Maas wrote:
On Tue, Jul 07, 2020 at 09:03:19PM +0200, Till Maas wrote:
Hi,
in https://pagure.io/fesco/issue/2410 I proposed to name the dist-git
branch for Fedora Rawhide "rawhide" to clarify the purpose of that
branch. There was also some feedback that Rawhide might n
On Wed, Jul 8, 2020 at 2:44 PM Vipul Siddharth
wrote:
>
> oops, sent too soon (more like didn't read correctly)! please ignore last
> email
>
> On Wed, Jul 8, 2020 at 7:09 PM Remi Collet wrote:
> >
> > Le 08/07/2020 à 11:09, Aoife Moloney a écrit :
> >
> > > Our CPE Review Team
> > > include:
>
On Tue, Jul 07, 2020 at 09:03:19PM +0200, Till Maas wrote:
> Hi,
>
> in https://pagure.io/fesco/issue/2410 I proposed to name the dist-git
> branch for Fedora Rawhide "rawhide" to clarify the purpose of that
> branch. There was also some feedback that Rawhide might not be the best
> name and it co
oops, sent too soon (more like didn't read correctly)! please ignore last email
On Wed, Jul 8, 2020 at 7:09 PM Remi Collet wrote:
>
> Le 08/07/2020 à 11:09, Aoife Moloney a écrit :
>
> > Our CPE Review Team
> > include:
> > * Fedora - mmiller, mnordin, bcotton
> > * CentOS - rbowen, bex
>
On Wed, Jul 8, 2020 at 7:09 PM Remi Collet wrote:
>
> Le 08/07/2020 à 11:09, Aoife Moloney a écrit :
>
> > Our CPE Review Team
> > include:
> > * Fedora - mmiller, mnordin, bcotton
> > * CentOS - rbowen, bex
> > * RHEL - bex, dperpeet, aslobodova
>
>
> Where is EPEL ?
Extra Packages f
Le 08/07/2020 à 11:09, Aoife Moloney a écrit :
> Our CPE Review Team
> include:
> * Fedora - mmiller, mnordin, bcotton
> * CentOS - rbowen, bex
> * RHEL - bex, dperpeet, aslobodova
Where is EPEL ?
Remi
___
devel mailing list -- devel@li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Wed, 2020-07-08 at 14:13 +0200, Vitaly Zaitsev via devel wrote:
> On 07.07.2020 19:57, Orion Poplawski wrote:
> > What's the plan for EPEL8/7 compatibility?
>
> +1. The new Cmake macros behaviour must be backported to EPEL7/8.
Feel free to submi
Hi Everyone,
As we kick off our team's work for Quarter 3 of this year, we would
like to take this opportunity to ask for your feedback on our
engagement over the last few months.
The CPE has been working on trying to improve our communication with
our communities and increase visibility on how w
On 07.07.2020 19:57, Orion Poplawski wrote:
> What's the plan for EPEL8/7 compatibility?
+1. The new Cmake macros behaviour must be backported to EPEL7/8.
Currently all fixed by proven packages SPEC files cannot be built on
EPEL branches.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
_
On Wed, Jul 8, 2020 at 4:11 AM Igor Raits
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Wed, 2020-07-08 at 09:12 +0800, Qiyu Yan wrote:
> > Richard Shaw 于 2020年7月8日周三 上午6:11写道：
> >
> > > Ok, so it appears this change was for F32+ only, so I can't merge
> > > master
> > > into
On Wed, Jul 8, 2020 at 11:22 AM Dominique Martinet
wrote:
> Please test, but if a file is deemed not compressible (based on, not
> sure what? the first few blocks?) then it will be stored in the
> non-compressed version.
> You can check with compsize after the fact if the file had been
> compress
Sure, but when updating the javamail package, you will be providing
compatibility aliases for the old maven coordinates using %mvn_alias and
compatibility symlinks for the old filename using %mvn_file in order to not
break dependent packages, right? Right? ;-)
Unless a package somehow is not using
On 07. 07. 20 21:16, Ben Cotton wrote:
== Scope ==
* Proposal owners:
**Prepare PostgreSQL 13 as a module for Rawhide and at least one
stable Fedora release (done)
**Prepare PostgreSQL 12 as a module for Rawhide, so there would be a
failover in case of problems
**Build PostgreSQL 13 to Rawhide
*
https://fedoraproject.org/wiki/RawhideKernelNodebug
links to
http://dl.fedoraproject.org/pub/alt/rawhide-kernel-nodebug/fedora-rawhide-kernel-nodebug.repo
which gives 404 now. The kernels seems to be there though. But without
the repo file it's not easy to enable.
Zbyszek
_
Kamil Paral wrote on Wed, Jul 08, 2020:
> On Wed, Jul 8, 2020 at 8:26 AM Chris Murphy wrote:
>
> > D. Which directories? Some may be outside of the installer's scope.
> >
> > /usr
> > /var/lib/flatpak
> > ~/.local/share/flatpak
>
> I have a concern regarding games. Currently, we have a few a bit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Wed, 2020-07-08 at 09:12 +0800, Qiyu Yan wrote:
> Richard Shaw 于 2020年7月8日周三 上午6:11写道：
>
> > Ok, so it appears this change was for F32+ only, so I can't merge
> > master
> > into f32 or earlier...
> >
> Maybe wait it to be backported into f31.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-07-07 at 11:57 -0600, Orion Poplawski wrote:
> On 6/15/20 1:47 PM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
> >
> > == Summary ==
> > %cmake macro will be adjusted (-B
> > parameter)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-07-07 at 12:07 -0600, Orion Poplawski wrote:
> On 6/15/20 1:47 PM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
> >
> > == Summary ==
> > %cmake macro will be adjusted (-B
> > parameter)
Hi,
we have some rudimentary support for Clevis in the Cockpit Web Console,
and now the question is, should we add support for "tpm2" to that?
As I understand it, there is a lot of evolving OS specific subtlety
involved, so I am asking specifically how this would look on current
Fedora and what t
On Tue, Jul 07, 2020 at 10:13:36PM +, Gary Buhrmaster wrote:
> I (strongly) support the renaming of the branch, but I really
> really would prefer there to be a rough consensus on the
> replacement name across the entire git community, so
> that I don't need to remember to git-checkout devel i
On Wed, Jul 8, 2020 at 8:26 AM Chris Murphy wrote:
> D. Which directories? Some may be outside of the installer's scope.
>
> /usr
> /var/lib/flatpak
> ~/.local/share/flatpak
>
I have a concern regarding games. Currently, we have a few a bit more
demanding titles on Flathub already, like 0AD, Xon
On Tue, Jul 07, 2020 at 10:38:01AM -0700, Michel Alexandre Salim wrote:
> On Tue, 2020-07-07 at 10:30 +0200, Pierre-Yves Chibon wrote:
> > On Tue, Jul 07, 2020 at 08:17:00AM +, Mattia Verga wrote:
> > > Il 06/07/20 22:04, Pierre-Yves Chibon ha scritto:
> > > > Good Morning Everyone,
> > > >
>
71 matches
Mail list logo
