Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Igor Raits]

-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. The documents said this
> will be
> backported into older supported version.
> 
> But now, merging master into older version is impossible, can cause
> FTBTS.

https://bodhi.fedoraproject.org/updates/FEDORA-2020-a66614733c
https://bodhi.fedoraproject.org/updates/FEDORA-2020-2b99724ef6

Test them and leave karma please :)

> 
> > 
> > This whole change is still broken AF.
> > 
> > Thanks,
> > Richard
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: 
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

- -- 
Igor Raits 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8FjcEACgkQEV1auJxc
Hh6+yxAAoJAojZ3en5ip2Lov+rciwDYKQaNW7231oYN2FsuG5EakUtu9CPjCAjRW
9n7W7Z2QmkrV/aPg3V304n4UFfNiKp01HHVF9vco8ljryrJObWSgwhzsv/8VO1k7
O+3rSieII8TcUyupAP5VfEqgJb0GFqdPeJpDNh3kovMbDAH6kdEH4ZGmwg/+xoPn
7gNBNl5r7FBik9i8nLhxm3sgglw0zjzAT1ac9PFrx8fx7eXo8clbuAD0i6bi8qJM
7i0NSTppf0KaeDRv88VZUwQMeZmjL2FrUvFIiWDlPvynjqZ6aGa4rNnJrEOLYbRy
mpZTYa4qIWQ4+rgwwQbFfHoc168ZDenoWLR5YE+Qr/SzlyFN09WPmwffnFELHCX+
DJgv2vUHbwpAW7WTDrwjPLb2vmfK3wtI5StPGTh4Ntp8uy7j/B2hZipvub1TLeDb
i26ouzKmHDOohizWrA/CQwlpxx7qFRPl5NuQveCp4oV7A8Xram/2h/J9UEA3skxr
+3m5RJBtjUVWfdMGUkxqL88H/WN4Z6EkCQXhnZA9IAU043kORu3uImMArmv3ZkPT
rhiSq443HNIpvUOd0nwtxx3O47YSv9uvQWY35PL27VqSznzuPnK1MiOxShF3w/iR
MpYadfe/lruo6xwppPUhLRqilumQZDUUZuZptWwVwV5ykBkRxfw=
=IeUt
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Igor Raits]

-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)
> > to use separate build folder (already standardized
> > %{_vpath_builddir} macro). Additionally,
> > %cmake_build, %cmake_install and
> > %ctest macro will be created (and backported to the
> > older
> > supported Fedora releases) to perform various operations that are
> > commonly used with CMake in a backend-agnostic (Makefiles, Ninja,
> > etc.) way.
> > 
> > Packages that will stop building are trivial to fix and will be
> > adjusted either by maintainers or change owners.
> > 
> > == Owner ==
> > * Name: [[User:ignatenkobrain|Igor Raits]], [[User:besser82|Björn
> > Esser]], [[User:ngompa|Neal Gompa]]
> > * Email: ignatenkobr...@fedoraproject.org, 
> > besse...@fedoraproject.org,
> > ngomp...@gmail.com
> > 
> > == Detailed Description ==
> > Historically, software builds had a singular build configuration
> > and
> > required running the build within the project root. Nowadays, there
> > are many build modes and options that can be configured in
> > projects,
> > different build settings (e.g. compiler flags) / types (release,
> > debug) that can be applied and different tools that can be used to
> > actually execute builds (compilers like gcc/clang, build job
> > schedulers like make/ninja, and so on). Thus, CMake upstream
> > strongly
> > discourages users of doing in-source builds and recommends doing
> > out-of-source builds.
> > 
> >  From cmake.1:
> > 
> > 
> > To maintain a pristine source tree, perform an out-of-source build
> > by
> > using a separate dedicated build tree. An in-source build in which
> > the
> > build tree is placed in the same directory as the source tree is
> > also
> > supported, but discouraged.
> > 
> > 
> > The other part of the change is introduction of additional macros
> > is
> > creation of set of macro that can build, install and run tests in a
> > backend-agnostic, vpath-aware (out-of-source, in-source) way.
> > 
> > === Migration ===
> > 
> >  %cmake +
> > %(make|ninja)_(build|install) 
> > 
> > There are multiple paths to complete the migration:
> > 
> > * Add -C "%{_vpath_builddir}" to the
> > %(make|ninja)_*
> > * Replace %(make|ninja)_build and
> > %(make|ninja)_install with %cmake_build
> > and
> > %cmake_install respectively
> > * Redefine vpath builddir %global _vpath_builddir . to
> > continue performing in-source builds (and optionally converting to
> > the
> > %cmake_*)
> > 
> > Depending on the package, one of these options may be used to adapt
> > to
> > this change.
> > 
> >  %cmake -B builddir +
> > %(make|ninja)_(build|install) -C builddir 
> > 
> > No changes are needed.
> > 
> > == Benefit to Fedora ==
> > * Follow CMake upstream recommendations when building packages
> > * Brings Fedora package builds more in-line with how upstream
> > projects
> > expect them to be built
> > * Improve compatibility with other RPM distributions that already
> > do this
> > * Support backend-agnostic way of building CMake projects
> > 
> > == Scope ==
> > * Proposal owners: Implement necessary macros, try to build
> > packages
> > that BuildRequires: cmake in a side tag, analyze
> > failures
> > and fix the relevant ones (introduced by this change).
> > * Other developers: While proposal owners will try to fix all
> > affected
> > packages, there might be some cases where package is already FTBFS
> > so
> > the fix can't be performed. Other package maintainers will have to
> > fix
> > the issue themselves after they fix FTBFS.
> > * Release engineering: [https://pagure.io/releng/issue/9524 #9524]
> > * Policies and guidelines: CMake page will be adjusted to mention
> > newly created macros and the documentation about relevant VPATH
> > macros
> > needs to be restructured a bit (they are already documented on the
> > Meson page, they need to be moved to the separate page and
> > referenced
> > both from CMake and Meson page).
> > * Trademark approval: N/A (not needed for this Change)
> > 
> > == Upgrade/compatibility impact ==
> > Existing packages can (and most likely will) become FTBFS, but
> > proposal owners will fix as many Fedora packages as possible.
> > However
> > fixing third-party packages is not possible and out of scope.
> > Third-party packagers will need to adapt based on the
> > recommendations
> > noted in this Change.
> 
> What's the plan for EPEL8/7 compatibility?

Ask people that work on EPEL :) The change talks only about Fedora
backports that have been done already and are sitting in the testing
now.

> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> 

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Igor Raits]

-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)
> > to use separate build folder (already standardized
> > %{_vpath_builddir} macro). Additionally,
> > %cmake_build, %cmake_install and
> > %ctest macro will be created (and backported to the
> > older
> > supported Fedora releases) to perform various operations that are
> > commonly used with CMake in a backend-agnostic (Makefiles, Ninja,
> > etc.) way.
> > 
> > Packages that will stop building are trivial to fix and will be
> > adjusted either by maintainers or change owners.
> > 
> > == Owner ==
> > * Name: [[User:ignatenkobrain|Igor Raits]], [[User:besser82|Björn
> > Esser]], [[User:ngompa|Neal Gompa]]
> > * Email: ignatenkobr...@fedoraproject.org, 
> > besse...@fedoraproject.org,
> > ngomp...@gmail.com
> > 
> > == Detailed Description ==
> > Historically, software builds had a singular build configuration
> > and
> > required running the build within the project root. Nowadays, there
> > are many build modes and options that can be configured in
> > projects,
> > different build settings (e.g. compiler flags) / types (release,
> > debug) that can be applied and different tools that can be used to
> > actually execute builds (compilers like gcc/clang, build job
> > schedulers like make/ninja, and so on). Thus, CMake upstream
> > strongly
> > discourages users of doing in-source builds and recommends doing
> > out-of-source builds.
> > 
> >  From cmake.1:
> > 
> > 
> > To maintain a pristine source tree, perform an out-of-source build
> > by
> > using a separate dedicated build tree. An in-source build in which
> > the
> > build tree is placed in the same directory as the source tree is
> > also
> > supported, but discouraged.
> > 
> > 
> > The other part of the change is introduction of additional macros
> > is
> > creation of set of macro that can build, install and run tests in a
> > backend-agnostic, vpath-aware (out-of-source, in-source) way.
> > 
> > === Migration ===
> > 
> >  %cmake +
> > %(make|ninja)_(build|install) 
> > 
> > There are multiple paths to complete the migration:
> > 
> > * Add -C "%{_vpath_builddir}" to the
> > %(make|ninja)_*
> > * Replace %(make|ninja)_build and
> > %(make|ninja)_install with %cmake_build
> > and
> > %cmake_install respectively
> > * Redefine vpath builddir %global _vpath_builddir . to
> > continue performing in-source builds (and optionally converting to
> > the
> > %cmake_*)
> > 
> > Depending on the package, one of these options may be used to adapt
> > to
> > this change.
> > 
> >  %cmake -B builddir +
> > %(make|ninja)_(build|install) -C builddir 
> > 
> > No changes are needed.
> > 
> > == Benefit to Fedora ==
> > * Follow CMake upstream recommendations when building packages
> > * Brings Fedora package builds more in-line with how upstream
> > projects
> > expect them to be built
> > * Improve compatibility with other RPM distributions that already
> > do this
> > * Support backend-agnostic way of building CMake projects
> > 
> > == Scope ==
> > * Proposal owners: Implement necessary macros, try to build
> > packages
> > that BuildRequires: cmake in a side tag, analyze
> > failures
> > and fix the relevant ones (introduced by this change).
> > * Other developers: While proposal owners will try to fix all
> > affected
> > packages, there might be some cases where package is already FTBFS
> > so
> > the fix can't be performed. Other package maintainers will have to
> > fix
> > the issue themselves after they fix FTBFS.
> > * Release engineering: [https://pagure.io/releng/issue/9524 #9524]
> > * Policies and guidelines: CMake page will be adjusted to mention
> > newly created macros and the documentation about relevant VPATH
> > macros
> > needs to be restructured a bit (they are already documented on the
> > Meson page, they need to be moved to the separate page and
> > referenced
> > both from CMake and Meson page).
> > * Trademark approval: N/A (not needed for this Change)
> > 
> > == Upgrade/compatibility impact ==
> > Existing packages can (and most likely will) become FTBFS, but
> > proposal owners will fix as many Fedora packages as possible.
> > However
> > fixing third-party packages is not possible and out of scope.
> > Third-party packagers will need to adapt based on the
> > recommendations
> > noted in this Change.
> 
> What's with %{nil}?  If we're writing macros that require the use of 
> %{nil} I think we have a problem.
> 
>   %cmake3 \
>  %{?_with_cppunit: -DENABLE_CPPUNIT=ON} \
> %{nil}

It is not strictly needed, but I wanted to avoid moving lines around to
keep diff as small as possible.

> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To 

Re: Using "rawhide" for the dist-git branch for Fedora Rawhide

[Till Maas]

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 in one
> project, git-checkout trunk in another, git-checkout main in
> a third, git-checkout release in a fourth, git-checkout default
> in a fifth, etc.(*).  In this case, I would prefer Fedora follow
> the rough consensus presuming that one can be achieved
> rather than pick yet another (different) name.

There are several other branches than the branch for Rawhide that have a
name that is unlikely to be found in many other projects like f32, el6,
epel7, epel8-playground. Why is it more intuitive to use a name from
other projects as the name for the branch for Rawhide?

Thanks
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

TPM2 for disk encryption, clevis

[Marius Vollmer]

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 to expect in the near future.

Here is the discussion that prompted my question:

https://github.com/cockpit-project/cockpit/issues/14313[1]

In most concrete terms: Which PCRs should we use on which version of
Fedora?  ("None" is a totally nice answer.)

I don't think we can let the user enter the PCR numbers, that requires
way to much intimate knowledge of the current state of support for
secure boot of their OS.  I.e., the best way I have to answer that for
myself is to ask here.

The user needs to be shielded from that knowledge, I'd say, and ideally
clevis would already shield me from it, but I am happy to do it in
Cockpit.

Thanks!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Btrfs by default, the compression option

[Chris Murphy]

Hi,

The change proposal has a 'compression option' and we kinda need to
get organized.
https://fedoraproject.org/wiki/Changes/BtrfsByDefault#Compression

 - Compression saves space, significantly reduces write amplification
and therefore increases flash lifespan, and in some cases increases
performance.
 - Desired but not a requirement of the change proposal.

1. Goal: probably the goal performance wise is to perform as good or
better than now. Is it OK if there's a write time performance hit for
a small percent of folks, for a high value target like usr that isn't
updated that often, and is also updated out of band (offline updates
typically, but also isn't something directly related to the daily
workload)? How to decide this?

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
But is that adequate? How do we confirm/deny on a wide variety of
hardware that this meets the goal? And how is this test going to
account for parallelization, and read ahead? Do we need a lot of data
or is it adequate to get a sample "around the edges" (e.g. slow cpu
fast drive; fast cpu slow drive; fast cpu fast drive; slow cpu slow
drive). What algorithm?

3. Improvements and upgrades. We'll do plan A, but learn new things
later, and come up with plan B. How do we get the plan A folks
upgraded to plan B? Or just don't worry?

4. The whole file system (using a mount option) or curated (using an
XATTR set on specific "high value" directories)? This part is
elaborated below.

A.  do this with a mount option '-o compress=zstd:1'
   - dilemma: it doesn't always lead to equal or better performance.
On some systems and workloads, write performance is slightly reduced.
What about LZO?

B. do this with per directory XATTR
   - dilemma: the target directories don't exist at install time,
depending on whether the installation is rsync, rpm, or unsquashfs
based.

C. do the install with '-o compres=zstd', then set XATTR post-install
   - dilemma: the installed files won't have XATTR set, only new files
inherit;  does a 'dnf update' overwrite files and therefore the XATTR
is not inherited, or are they new files and do inherit the XATTR?

D. Which directories? Some may be outside of the installer's scope.

/usr
/var/lib/flatpak
~/.local/share/flatpak
/var/lib/containers/
~/.local/share/containers/
~/.var
~/.cache

(Plausible this list should be reversed. While compressing ~/.cache
may not save much space, it's likely hammered with more changes than
other locations, hence more benefit in terms of reducing write
amplification.)

For reference, the above is mostly from the description in the RFE bug
attached to the feature's tracker bug. But I think it's best to have
most discussion here and leave the bug for implementing+testing the
implementation details.
https://bugzilla.redhat.com/show_bug.cgi?id=1851276

Thanks,

-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Btrfs by default, the compression option

[Kamil Paral]

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, Xonotic or Albion Online. In
the glorious future (tm) we might get more. Games are very sensitive to
available CPU cycles and context switching and usually come with their data
files already compressed. Including the btrfs compression by default on
flatpak dirs could lead to lowered performance whenever the game tries to
load some assets (older titles do that during the loading screen, newer
titles stream new assets constantly during gameplay and any slowdown
manifests as game stuttering).

May it make sense to have different compression defaults per Edition/Spin?
For example, Workstation is likely used on computers which have sufficient
disk space, don't suffer from disk wear out that much (compared to SD
cards), and users are likely to play games on them. On the other hand, ARM
or IoT devices are the very opposite and compression can be very useful
there.


> /var/lib/containers/
> ~/.local/share/containers/
> ~/.var
>

If we enable it on ~/.var, it will affect all Steam games installed through
the Steam flatpak. So any AAA games you play including those emulated
through Proton will need to deal with extra compression. I find it unlikely
that the user experience would be unchanged. It would be similar to
Microsoft enabling disk compression on Program Files by default. I actually
tried to figure out which locations are compressed by default on Windows
10, and I failed in searching, but I looked at my Win10 instance and I
didn't find any folders that would have compression enabled.


> ~/.cache
>
> (Plausible this list should be reversed. While compressing ~/.cache
> may not save much space, it's likely hammered with more changes than
> other locations, hence more benefit in terms of reducing write
> amplification.)
>

I'm personally more concerned about reduced performance in e.g. my web
browser than disk wear out. I don't see much harm in compressing /usr,
because it's a read-only location that gets loaded once when the app starts
(it might delay the app startup a bit, though, and decrease the perceived
snappiness of the desktop). But I'm concerned about compressing locations
which are hit often, like ~/.var or ~/.cache. I've had my 120GB SSD for 5
years and I'm just at 10% of expected TBW (total bytes written). If the SSD
lasts 50 or 100 years is not really important for me, but the desktop and
app responsiveness is (and game performance, of course:)). I think write
amplification is a problem specific to devices with SD cards, and for
anyone else, it might be better to leave it unset and let people enable it
(it's simple) if they want it for their use case.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Btrfs by default, the compression option

[Dominique Martinet]

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 more
> demanding titles on Flathub already, like 0AD, Xonotic or Albion Online. In
> the glorious future (tm) we might get more. Games are very sensitive to
> available CPU cycles and context switching and usually come with their data
> files already compressed. Including the btrfs compression by default on
> flatpak dirs could lead to lowered performance whenever the game tries to
> load some assets (older titles do that during the loading screen, newer
> titles stream new assets constantly during gameplay and any slowdown
> manifests as game stuttering).

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
compressed or not.

This should be true unless the compress-force mount option is used, even
the chattr is only a hint


> I'm personally more concerned about reduced performance in e.g. my web
> browser than disk wear out. I don't see much harm in compressing /usr,
> because it's a read-only location that gets loaded once when the app starts
> (it might delay the app startup a bit, though, and decrease the perceived
> snappiness of the desktop). But I'm concerned about compressing locations
> which are hit often, like ~/.var or ~/.cache. I've had my 120GB SSD for 5
> years and I'm just at 10% of expected TBW (total bytes written). If the SSD
> lasts 50 or 100 years is not really important for me, but the desktop and
> app responsiveness is (and game performance, of course:)). I think write
> amplification is a problem specific to devices with SD cards, and for
> anyone else, it might be better to leave it unset and let people enable it
> (it's simple) if they want it for their use case.

This obviously needs testing on a wide variety of hardware but I haven't
noticed any difference in the feeling on an intel laptop (kabylake i5
throttled at 2GHz) ; that being said firefox isn't the most responsive
app in my book...

-- 
Dominique
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Packagers with no corresponding valid bugzilla accounts

[Pierre-Yves Chibon]

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,
> > > > 
> > > > The list is slowly going down, we have now 38 accounts that are
> > > > still
> > > > problematic, they have all received several personal emails over
> > > > the last few
> > > > weeks and none but one reacted.
> > > > I will likely start to ping FESCo about them starting next week.
> > > > ...
> > > 
> > >  From a quick look to that list, there are some users that have no 
> > > package assigned... I wonder if the unresponsive maintainer
> > > process 
> > > implies the user to be removed from the packager group when their 
> > > packages get orphaned and the user has no more any package
> > > associated to 
> > > their account.
> > 
> > The source of info is: 
> > https://src.fedoraproject.org/extras/pagure_bz.json
> > which includes people that are packagers as well as people who are
> > watching the
> > packages (ie who asked to be included in the CC list on bugzilla).
> > 
> 
> 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 changes from being reflected in Bugzilla.

As you can see in this JSON there is no difference between maintainers and
watchers, so the script syncing to bugzilla does not have this information.
I think that asking FESCo for a policy on how to deal with this + an automated
way to detect this situation (which we didn't really have so far) may be
sufficient. However, if this situation happens too frequently, and leads to too
much manual work to clean things up, we may need to see about somehow adding
this information to the JSON file and teaching the script the difference.
It would increase the load on bugzilla though :(

Pierre


pgp2uDfJPHgDl.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Btrfs by default, the compression option

[Kamil Paral]

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
> compressed or not.
>
> This should be true unless the compress-force mount option is used, even
> the chattr is only a hint
>

OK, this is an interesting piece of information I wasn't aware of. In this
case, if the btrfs heuristics work OK in the majority of cases, the
performance hit might not be there, as I feared. Some thorough
investigation would be needed, though.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CPE Team Engagement Feedback

[Aoife Moloney]

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:
> > > * Fedora - mmiller, mnordin, bcotton
> > > * CentOS - rbowen, bex
> > > * RHEL - bex, dperpeet, aslobodova
> >
> >
> > Where is EPEL ?
> >
> >

Hi Remi,

This list represents the CPE Teams stakeholders and as EPEL is a part
of the Fedora project, its representation is covered by Matthew, Marie
& Ben.


Hope that clarifies!
Aoife
> >
> >
> > Remi
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>
>
> --
> Vipul Siddharth
> He/His/Him
> Fedora | CentOS CI Infrastructure Team
> Red Hat
> w: vipul.dev
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 

Aoife Moloney

Product Owner

Community Platform Engineering Team

Red Hat EMEA

Communications House

Cork Road

Waterford
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Using "rawhide" for the dist-git branch for Fedora Rawhide

[Till Maas]

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 could be renamed. In that case, the branch could be named as
> this. This is just the first step to check if there is enough support
> for this to move forward. The next step would be to start a change
> process.

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 and then once we need to branch we branch of Rawhide
as f34? There could still be a symbolic ref called rawhide for the
latest rawhide for convenience. What do you think?

Thanks
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

nodebug kernel repo file missing

[Zbigniew Jędrzejewski-Szmek]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: PostgreSQL 13 - Fedora 33 Self-Contained Change proposal

[Miro Hrončok]

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
**Check software that requires or depends on `postgresql-server` or
`libpq` packages for incompatibilities
**Gather user input on the changes between PostgreSQL 12 and PostgreSQL 13


When we updated from PostgreSQL 11 to PostgreSQL 12 in Fedora 32, there was no 
targeted rebuild of the dependent packages and a dozen of packages failed to 
install. We were firefighting this between beta and final in:


https://bugzilla.redhat.com/show_bug.cgi?id=1811800

I would very much like to see a targeted rebuild of dependent packages in a side 
tag in the scope (who does it? when?) and a contingency mechanism that reverts 
to PostgreSQL 12 if many packages cannot build.



== Contingency Plan ==

Modules will provide the functional version of PostgreSQL 12,
available to all users.


If the 13 dependent packages don't install, a module with PostgreSQL 12 is 
**not** a contingency plan.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Vitaly Zaitsev via devel]

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)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

CPE Team Engagement Feedback

[Aoife Moloney]

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 we decide on what to
work on. We have taken many steps to improve our communication such as
IRC Office hours, regular initiative updates on our taiga board,
weekly mail and blog posts on what we achieved in each quarter and
what we are planning to work on next.
We have also had a few discussions before with some Fedora Council and
CentOS Board members on how best to engage with the CPE Team when you
wish to brief in an initiative or need to file a
bug/issue/enhancement, and as time goes by we are refining our
processes.
We would like to share with you our current approaches that we are
using for you to provide feedback on how you feel these are working.




It is important for our team to feel like their time is protected so
that they are able to enjoy a healthy work-life balance, so we have
categorized work requests that the team responds to into two
categories which we believe benefits both the CPE team and the
communities we serve:

- Project Teams
- These teams are created based on an initiative that has been:
- Received by our product owner in advance
- The work involved has been scoped, reviewed and accepted to
the backlog by the CPE Review Team
- Prioritized and actioned for work during our teams quarterly
planning sessions by CPE Team Stakeholders and Review Team

- Sustaining Team
- This team responds to 'lights on work' and requests that come in
on an ad hoc & regular basis such as:
- BAU infra/releng requests
- RFEs
- Bug fixes



## How we propose to deal with Project Team Initiatives?

* We have published deadlines for initiatives to be briefed into our
team by for each quarter here:
https://docs.fedoraproject.org/en-US/cpe/time_tables/
* Project requests that are recieved are then discussed further with
the requestor and relevant team lead(s) with our product owner
* During our monthly quarterly planning sessions, the CPE Review Team
reviews and prioritises which proposals to scope.
* All scoped proposed initiatives are brought into our QP session for
review and consideration to be worked on in the next quarter.
* Our CPE Review Team review all and vote on the initiatives they
would like to see actioned in the next quarter. Our CPE Review Team
include:
* Fedora - mmiller, mnordin, bcotton
* CentOS - rbowen, bex
* RHEL - bex, dperpeet, aslobodova
* CPE -
* CPE Product Owner - amoloney
* CPE Management - lgriffin, antcarroll, smattejiet
* CPE Team Leads - pingou, bstinson

As a picture is worth a thousand words, so here is one :)

> ![](https://i.imgur.com/Ro08PsE.png)


> Image Credit goes to Smera Goel, the very talented graphic designer that is 
> currently interning as part of the Fedora Outreachy Project.




## How we propose to deal with Sustaining Team BAU requests, RFEs and bug fixes?

In order to allow the people working on initiatives to focus on them,
our Sustaining Team members will be responsible for dealing with all
these requests. They can be filed in the normal ways by community
members.

BAU infra requests can be made on the fedora-infrastructure issue tracker:
https://pagure.io/fedora-infrastructure/
BAU releng requests can be made on the releng issue tracker:
https://pagure.io/releng/




## Project Team vs Sustaining Team Work Classification

### Project Initiatives
Initiatives are weeks to months long projects involving a team of
people to work on and deliver.

We have some deadlines that we try to work towards
Examples of initiatives:
 - rawhide package gating
 - FAS replacement
 - ...


### BAU infra/releng requests
Business As Usual (BAU) requests are simple requests that do not need
anyone to code something, just run some code to solve the request.

Examples of BAU requests:
  - A new mailing list
  - A new FAS/dist-git/copr group
  - A new IRC channel
  - A new project on ci.centos.org
  - A new tag in koji


### RFE

Requests For Enhancements (RFE) are requests to improve a changes made
to either an application or a workflow used in Fedora.


### Bug fixes

Bug fixes are what they are, request to fix bugs.

Examples of bug fixes:
  - Well you know: https://github.com/fedora-infra/bodhi/issues or
pagure.io/pagure/issues are full of them ;-)






This is our team's current way of working, and we are seeing the
benefits from this but wanted to have your feedback too. We would like
to publish this as a 'policy' of sorts for our team on docs.fpo and on
the CentOS wiki and want to include you in this process.
So what are your thoughts on these ideas?
Are they suitable for you or do they need more adjustments?
If they do, what are your suggestions?

To view this email in hackmd, please 

Re: CPE Team Engagement Feedback

[Vipul Siddharth]

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 for Enterprise Linux
https://fedoraproject.org/wiki/EPEL
>
>
>
>
> Remi
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Vipul Siddharth
He/His/Him
Fedora | CentOS CI Infrastructure Team
Red Hat
w: vipul.dev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CPE Team Engagement Feedback

[Vipul Siddharth]

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
> > * RHEL - bex, dperpeet, aslobodova
>
>
> Where is EPEL ?
>
>
>
>
> Remi
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Vipul Siddharth
He/His/Him
Fedora | CentOS CI Infrastructure Team
Red Hat
w: vipul.dev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Using "rawhide" for the dist-git branch for Fedora Rawhide

[Miro Hrončok]

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 not be the best
name and it could be renamed. In that case, the branch could be named as
this. This is just the first step to check if there is enough support
for this to move forward. The next step would be to start a change
process.


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 and then once we need to branch we branch of Rawhide
as f34? There could still be a symbolic ref called rawhide for the
latest rawhide for convenience. What do you think?


I like that idea. However IMHO packagers tend to forget about branching if they 
are not following Fedora development closely.


When they do that now, they still do changes in rawhide and they might not 
update their package in branched -- however in long term, this does not matter 
because their change is in all future versions.


When they do that after this, their change will be in branched but not in 
rawhide and in the long term, it will be lost.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Richard Shaw]

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 f32 or earlier...
> > >
> >  Maybe wait it to be backported into f31. The documents said this
> > will be
> > backported into older supported version.
> >
> > But now, merging master into older version is impossible, can cause
> > FTBTS.
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-a66614733c
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-2b99724ef6
>
> Test them and leave karma please :)
>

So the F32 update already had negative karma so auto push is disabled.
Additionally this doesn't help with infra or mock builds,though I suppose I
could force the update into my mock buildroot.

Although non-traditional, perhaps a buildroot override for testing would
have worked to allow infra builds and could be removed if it caused a
problem.

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Igor Raits]

-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 submit patches to cmake3 and epel-rpm-macros.

> Currently all fixed by proven packages SPEC files cannot be built on
> EPEL branches.
> 
> -- 
> Sincerely,
>   Vitaly Zaitsev (vit...@easycoding.org)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

- -- 
Igor Raits 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8Fx9EACgkQEV1auJxc
Hh7JzxAAtK8VXZz+jEdw1KICPRBOnsRvEcPBzpXbT7SLJd+84HRzxTFnWWJKqn3I
8hOKDl+lm00DKnplcIVPQXJ2g9CkV3a17bDWFGq9oW47eyH97lGRNUZifTKWcv7n
OJNBB3OsU1jbhkKs0WtCX8NVmux2w9C/pCrSfcxCXxiWT7vz70NALqPX526sCDyb
6Unid5W/dZ35xl7tWmLm4WEwefpDOoCUF+khc9x8JPY6laczHmPk1RIdZ6g9a2FI
Nwe6GNry1CWP22+wqxJlNQI0AEoev/olerIRD9hZ/TYiH+fRGqcOSefKDLE5TE3Y
y9SF+5pEsELZgZm0hnI8b9QjIiNjf7m7RELn+Pdm/nS5eqJyIKuUUr/Zz+M4oDYW
aZ2xToIyak769PmF6wr7x3oMAiT/OkvZRzwdpB6lC7cDslMAonsDisFIK8D7kE8x
du/fHb/tIbbYuVVm4CnhxxY304U8NmBxCRsXZIYJNKdinG0nSAZUdy0Z5UqRk5VQ
Tt2NMjSRBa2jV+AurM3thRCrJaVf6oPTKb6+pUsM6fBCF/HAoDN52AstxXNB97sS
j/yOF4rPFg9N6i+ojDF7893n2ThkZXFERiqVTg2CWozLzK1g8AwfA66J38B5FQBJ
QhL9vp8IO/aSrUa6pcfTbFTTozMncz7XZUDl4uStLFgUvkSzLxQ=
=TyCb
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [fedora-java] Re: Questions on an update to javamail in ursine

[Mat Booth]

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 the felix-bundle-plugin or aqute-bnd,
a simple rebuild should fix OSGi metadata (i.e. the next mass rebuild
should take care of it).

On Mon, 6 Jul 2020 at 19:59, Jie Kang  wrote:

> Hey Mat,
>
> On further investigation, the compatibility changes that require
> attention are made in javamail 1.6.3 and later, see:
>
> https://eclipse-ee4j.github.io/mail/docs/COMPAT.txt
>
> The maven coordinates are changed, generally javax -> jakarta. This
> also affects the osgi provides.
>
>
> Regards,
> Jie Kang
>
> On Thu, Jul 2, 2020 at 5:54 AM Mat Booth  wrote:
> >
> >
> >
> > 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.6.x releases have different exports for OSGi, making an update to
> >> > them potentially breaking for users.
> >> >
> >> > I'd like to update ursine to 1.6.x, but I understand packages
> >> > depending on them should be notified or some such. However I realized
> >> > I don't know what commands to run to get a list of such and then where
> >> > to send it. Could anyone advise?
> >> >
> >> > Also, upstream repo was renamed: https://github.com/eclipse-ee4j/mail
> >> > so maybe a new package 'mail' can be introduced to use it? Any
> >> > thoughts there?
> >>
> >> I use this command to check for dependent packages:
> >>
> >> $ dnf --repo rawhide --repo rawhide-source --releasever rawhide
> >> repoquery --whatrequires javamail
> >>
> >> Which is enough, since there are no other subpackages except -javadoc.
> >> The command yielded (on July 1):
> >>
> >> ant-0:1.10.8-1.fc33.src
> >> ant-javamail-0:1.10.8-1.fc33.noarch
> >> bouncycastle-0:1.65-2.fc33.src
> >> httpunit-0:1.7-29.fc32.src
> >> log4j-0:2.13.1-1.fc33.src
> >> log4j12-0:1.2.17-26.fc32.src
> >> openas2-0:2.10.0-2.fc33.src
> >> openas2-lib-0:2.10.0-2.fc33.noarch
> >>
> >> So the list of affected packages seems to be:
> >>
> >> - ant (Stewardship / Java SIG will deal with this)
> >> - bouncycastle (?)
> >
> >
> > Bouncycastle is me (it is a dep of jgit). From reading the javamail
> "compat" document: https://javaee.github.io/javamail/docs/COMPAT.txt it
> looks like I probably will need to take no action at all.
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> java-devel mailing list -- java-de...@lists.fedoraproject.org
> To unsubscribe send an email to java-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/java-de...@lists.fedoraproject.org
>


-- 
Mat Booth
http://fedoraproject.org/get-fedora
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CPE Team Engagement Feedback

[Remi Collet]

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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Test-Announce] Fedora 33 Rawhide 20200708.n.0 nightly compose nominated for testing

[rawhide]

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/QA:Release_validation_test_plan

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/33

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200708.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200708.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200708.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200708.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200708.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200708.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200708.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: TPM2 for disk encryption, clevis

[Kevin Fenzi]

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 drive to look for clevis servers on boot?
> 
> 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.

> 
> Here is the discussion that prompted my question:
> 
> https://github.com/cockpit-project/cockpit/issues/14313[1]
> 
> In most concrete terms: Which PCRs should we use on which version of
> Fedora?  ("None" is a totally nice answer.)
> 
> I don't think we can let the user enter the PCR numbers, that requires
> way to much intimate knowledge of the current state of support for
> secure boot of their OS.  I.e., the best way I have to answer that for
> myself is to ask here.
> 
> The user needs to be shielded from that knowledge, I'd say, and ideally
> clevis would already shield me from it, but I am happy to do it in
> Cockpit.

I think tpm2 might be good, but lots of machines don't have tpm2. 
So I would think it would need to be optional?

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Using "rawhide" for the dist-git branch for Fedora Rawhide

[Dominik 'Rathann' Mierzejewski]

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`
> >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.
> 
> That is easy to do, already supported by our forge and I am definitely +1 on
> this.
> 
> One wonder which I have is: should we keep a "master" branch, just as a 
> symlink
> to the "rawhide" one for backward compatibility purposes?

I'd say yes. I believe muscle memory will make most people do
git checkout master
for a long time, even after git upstream decides on a new default
branch name. 

It'd be nice if this was handled similar to foo->rpms/foo namespace
transition.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Btrfs by default, the compression option

[John M. Harris Jr]

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, we have a few a bit more
> demanding titles on Flathub already, like 0AD, Xonotic or Albion Online. In
> the glorious future (tm) we might get more. Games are very sensitive to
> available CPU cycles and context switching and usually come with their data
> files already compressed. Including the btrfs compression by default on
> flatpak dirs could lead to lowered performance whenever the game tries to
> load some assets (older titles do that during the loading screen, newer
> titles stream new assets constantly during gameplay and any slowdown
> manifests as game stuttering).

Flatpack stuff aside, we have games like 0AD, Xonotic, Albion and others in 
the repos as well, where compression should not be used.

Also, just wondering, how are you planning to enable compression on an unknown 
user's home directory? As a modification to the homedir helper?

-- 
John M. Harris, Jr.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[John M. Harris Jr]

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.  If you ask for full disk encryption LVM is encrypted, ESP + boot
> > > are not.  Which makes sense to me.  Why would you encrypt /boot?  The
> > > files you can find there are public anyway, you can download them from
> > > the fedora servers.  Encrypting /boot would make the boot process more
> > > fragile for no benefit.
> > 
> > 
> > I guess that shows how unfamiliar I am with UEFI boot Fedora. You would 
> > encrypt /boot to ensure that your boot images have not been tampered
> > with,
> 
> 
> Well, if that is your concern the answer is secure boot.  That will not
> only prevent tampering with /boot files, but also prevent tampering with
> the bootloader itself.

No, Secure Boot doesn't solve that problem. Secure Boot, in Fedora anyway, 
needlessly disables a lot of kernel functionality, which makes it completely 
unusable. You cannot load kernel modules you've built, hibernate your system, 
etc. Additionally, Secure Boot does not prevent tampering with /boot files. 
You can still change grub.cfg as you like.

> > or  config files haven't been read by somebody other than the end
> > user.
> 
> 
> Hmm, typically that is pretty standard stuff and very simliar on all
> fedora installs.  Only the root filesystem uuid differs, and possibly
> local tweaks like configuring a serial console.  I can't see how reading
> that is of much concern.

There's no reason to allow these files to be read to begin with, if the system 
is going to be encrypted.

-- 
John M. Harris, Jr.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Can we do away with release and changelog bumping?

[Nicolas Mailhot via devel]

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 
another (which definitely matters to me, because my packager workflow 
has rpmbuild, mock, copr and koji stages).


I honestly do not see how you can bump safely, without providing the 
bumping code the "bump from that point" information.


When you bump, you graft new release growth over an existing release 
tree. Stacking something blindly without looking upon where you stack it 
will work in a lot of cases, but will fail horribly in others. I like 
KISS but this KISS is too SS for my tastes. If linear history worked for 
a project the size of Fedora we’d be all still using CVS.


The bumping code itself is not hard to write

Serializing 'bump from here' in a format that can be reliably read later 
is also not hard (as long as you do not insist on expanding Release and 
trying to decompose it back at the next build).


The hard part is moving 'bump from here' info between builds.

Regards,

--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Using "rawhide" for the dist-git branch for Fedora Rawhide

[Kaleb Keithley]

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 8, 2020 at 9:57 AM Miro Hrončok  wrote:

> 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 not be the best
> >> name and it could be renamed. In that case, the branch could be named as
> >> this. This is just the first step to check if there is enough support
> >> for this to move forward. The next step would be to start a change
> >> process.
> >
> > 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 and then once we need to branch we branch of Rawhide
> > as f34? There could still be a symbolic ref called rawhide for the
> > latest rawhide for convenience. What do you think?
>
> I like that idea. However IMHO packagers tend to forget about branching if
> they
> are not following Fedora development closely.
>
> When they do that now, they still do changes in rawhide and they might not
> update their package in branched -- however in long term, this does not
> matter
> because their change is in all future versions.
>
> When they do that after this, their change will be in branched but not in
> rawhide and in the long term, it will be lost.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora rawhide compose report: 20200708.n.0 changes

[Fedora Rawhide Report]

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:567.81 KiB
Size of upgraded packages:   5.03 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   71.89 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Mate live x86_64
Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20200708.n.0.iso

= DROPPED IMAGES =
Image: Container_Minimal_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20200707.n.0.ppc64le.tar.xz
Image: Container_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Base-Rawhide-20200707.n.0.ppc64le.tar.xz
Image: Cloud_Base vmdk ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200707.n.0.ppc64le.vmdk
Image: Cloud_Base raw-xz ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200707.n.0.ppc64le.raw.xz
Image: Cloud_Base qcow2 ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200707.n.0.ppc64le.qcow2

= ADDED PACKAGES =
Package: badwolf-1.0.0-2.fc33
Summary: Web Browser which aims at security and privacy over usability
RPMs:badwolf
Size:375.61 KiB

Package: cvise-1.4.0-1.fc33
Summary: Super-parallel Python port of the C-Reduce
RPMs:cvise
Size:17.08 MiB

Package: jgmenu-4.2.1-3.fc33
Summary: Simple X11 application menu
RPMs:jgmenu jgmenu-gtktheme jgmenu-lx jgmenu-pmenu jgmenu-xfce4
Size:998.39 KiB

Package: perl-Color-ANSI-Util-0.164-1.fc33
Summary: Routines for dealing with ANSI colors
RPMs:perl-Color-ANSI-Util
Size:25.17 KiB

Package: perl-Color-RGB-Util-0.601-1.fc33
Summary: Utilities related to RGB colors
RPMs:perl-Color-RGB-Util
Size:27.21 KiB

Package: perl-ColorThemeBase-Static-0.008-1.fc33
Summary: Base class for color theme modules with static list of items
RPMs:perl-ColorThemeBase-Static
Size:31.92 KiB

Package: perl-Graphics-ColorNamesLite-WWW-1.14.000-1.fc33
Summary: WWW color names and equivalent RGB values
RPMs:perl-Graphics-ColorNamesLite-WWW
Size:18.83 KiB

Package: perl-Module-Load-Util-0.003-1.fc33
Summary: Some utility routines related to module loading
RPMs:perl-Module-Load-Util
Size:21.37 KiB

Package: perl-Regexp-Pattern-Perl-0.002-1.fc33
Summary: Regexp patterns related to Perl
RPMs:perl-Regexp-Pattern-Perl
Size:20.43 KiB

Package: perl-Test-RandomResult-0.001-1.fc33
Summary: Test that results of a running code look random
RPMs:perl-Test-RandomResult
Size:18.92 KiB

Package: python-flask-compress-1.5.0-2.fc33
Summary: Compress responses in your Flask app with gzip or brotli
RPMs:python3-flask-compress
Size:15.47 KiB

Package: python-jose-3.1.0-1.fc33
Summary: JOSE implementation in Python
RPMs:python3-jose python3-jose-cryptography python3-jose-pycrypto 
python3-jose-pycryptodome
Size:76.12 KiB

Package: qxmledit-0.9.15-3.fc33
Summary: Simple XML Editor and XSD Viewer
RPMs:libqxmledit libqxmledit-devel qxmledit qxmledit-doc
Size:25.93 MiB

Package: rust-libcryptsetup-rs-0.4.2-1.fc33
Summary: High level Rust bindings for libcryptsetup
RPMs:rust-libcryptsetup-rs+default-devel rust-libcryptsetup-rs-devel
Size:50.07 KiB


= DROPPED PACKAGES =
Package: lv2-artyfx-plugins-1.3-0.14.20150506gitff73e5a.fc32
Summary: A collection of LV2 RT plugins
RPMs:lv2-artyfx-plugins
Size:567.81 KiB


= UPGRADED PACKAGES =
Package:  OpenImageIO-2.1.17.0-1.fc33
Old package:  OpenImageIO-2.1.16.0-3.fc33
Summary:  Library for reading and writing images
RPMs: OpenImageIO OpenImageIO-devel OpenImageIO-iv OpenImageIO-utils 
python3-openimageio
Size: 19.84 MiB
Size change:  -532 B
Changelog:
  * Thu Jul 02 2020 Richard Shaw  - 2.1.17.0-1
  - Update to 2.1.17.0.


Package:  aom-2.0.0-1.fc33
Old package:  aom-1.0.0-9.20190810git9666276.fc32
Summary:  Royalty-free next-generation video format
RPMs: aom libaom libaom-devel
Size: 10.54 MiB
Size change:  445.13 KiB
Changelog:
  * Wed Jul 01 2020 Robert-Andr?? Mauchin  - 2.0.0-1
  - Update to 2.0.0 (#1852847)


Package:  awscli-1.18.94-1.fc33
Old package:  awscli-1.18.93-1.fc33
Summary:  Universal Command Line Environment for AWS
RPMs: awscli
Size: 1.80 MiB
Size change:  -14 B
Changelog:
  * Tue Jul 07 2020 Gwyn Ciesla  - 1.18.94-1
  - 1.18.94


Package:  bemenu-0.5.0-1.fc33
Old package:  bemenu-0.4.1-2.fc33
Summary:  Dynamic menu library and client program inspired by dmenu
RPMs: bemenu bemenu-devel
Size: 592.11 KiB
Size change:  1.51 KiB
Changelog:
  * Tue Jul 07 2020 Jan Stan??k  - 0.5.0-1
  - Upgrade to version 0.5.0


Package:  binutils-2.34.0-8.fc33
Old package:  binutils-2.34.0-7.fc33
Summary:  A GNU collection

Re: Packagers with no corresponding valid bugzilla accounts

[Kevin Fenzi]

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 changes from being reflected in Bugzilla.
> 
> As you can see in this JSON there is no difference between maintainers and
> watchers, so the script syncing to bugzilla does not have this information.
> I think that asking FESCo for a policy on how to deal with this + an automated
> way to detect this situation (which we didn't really have so far) may be
> sufficient. However, if this situation happens too frequently, and leads to 
> too
> much manual work to clean things up, we may need to see about somehow adding
> this information to the JSON file and teaching the script the difference.
> It would increase the load on bugzilla though :(

In the ideal world, we would just add checks so that people couldn't get
into this state. But thats going to require a lot of coordination/those
checks might be very difficult right now. I wonder though, if we could
get the new account system to help us here: I think there was a plan to
have it allow for a 'bugzilla email'. Could it perhaps also verify the
bugzilla email and have some 'bugzilla ok' property? 

Then, pagure could check it before allowing someone to watch/own/be
point of contact on a package and tell them to go set it before
allowing?

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: TPM2 for disk encryption, clevis

[Richard Hughes]

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 system
firmware. Dell already requested that fwupd somehow "informs" clevis
about the new PCR0, but until vendors start supplying this in the
firmware metadata it's not super useful to know "it's going to be
different".

Richard.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Can we do away with release and changelog bumping?

[Pavel Raiskup]

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 package-maintainer. Currently it sits deployed in staging koji,
> so you can give it a test-drive :-)
> 
> We hope we can return to it later this year, to have it deployed in prod
> koji.

+1 to what Florian proposes over rpmautospec, though.  I think bumping the
release flag is the bare minimal technical change that is needed (except that
bodhi should pre-fill the description by diffs from %changelogs).

I before stated my opinion that I don't like the generated %changelog
idea.  Fedora git changelog and `rpm --changelog` are two different
things.  Mixing them up will bring more costs than savings (fixing
mistakes in git commit messages retrospectively).  Or in other extreme the
ugly `rpm --changelog` output (people don't care they mistakenly provided
broken git commit message).

I think that it would be just enough to allow people to stop producing
`rpm --changelog`s if they think that it so awful amount of work (both
better than more expensive %changelog variant, or ugly variant).  Let's
allow packagers to specify something like:

%changelog
* there's no package metadata in changelog

Or in the worst case, automatize:

* there's no package metadata in changelog
- check %_pkgdocdir/fedora-git-changelog file

I'm not saying that we can not see every proposed approach in action as
opt-in.  But, IMVHO, we are wasting to much efforts time here that could
be spent on our content served to our users instead (== I mean the overall
%changelog quality).

Pavel

> [1] https://docs.pagure.org/Fedora-Infra.rpmautospec/principle.html
> 
> On Mon, Jul 6, 2020 at 8:22 AM Florian Weimer  wrote:
> 
> > * Björn Persson:
> >
> > > The macro could be defined like this for example:
> > >
> > >   %buildtag .%(date +%%s)
> >
> > Using time for synchronization is always a bit iffy.
> >
> > > It would be used in each spec like this:
> > >
> > >   Release: 1%{?dist}%{?buildtag}
> >
> > We could put the Koji task ID directly into the %dist tag.  We know that
> > this works in principle.  If we are worried that the number gets too
> > large, we could subtract the current task ID at the time the fcNN part
> > of the %dist tag changes.
> >
> > The %dist tag is not recorded in the changelog by most packages, so the
> > changelog does not need changing.
> >
> > Thanks,
> > Florian
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> >
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Summary/Minutes from today's FESCo Meeting (2020-07-08)

[Miro Hrončok]

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 process  (mhroncok, 14:01:43)

*  #2420 F33 System-Wide Change: Use %make_build and %make_install
  macros  (mhroncok, 14:05:09)
  * LINK: https://pagure.io/fesco/issue/2420   (mhroncok, 14:05:25)
  * LINK:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CPRVJJ56XSF4S6DSYIPVXHEXUXGR4PUX/
(mhroncok, 14:09:34)
  * AGREED: Neal's proposal in
https://pagure.io/fesco/issue/2420#comment-662515 and ask change
owner to reopen discussion if they think more should happen than
that. APPROVED (+6, 2, -0)  (mhroncok, 14:16:00)

* Next week's chair  (mhroncok, 14:16:36)
  * ACTION: zbyszek will chair next meeting  (mhroncok, 14:17:57)

* Open Floor  (mhroncok, 14:18:09)

Meeting ended at 14:24:44 UTC.




Action Items

* zbyszek will chair next meeting




Action Items, by person
---
* zbyszek
  * zbyszek will chair next meeting
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* mhroncok (48)
* dcantrell (21)
* zodbot (15)
* zbyszek (15)
* nirik (9)
* decathorpe (9)
* bcotton (8)
* King_InuYasha (3)
* ignatenkobrain (2)
* cverna (2)
* Conan_Kudo (0)
* Eighth_Doctor (0)
* sgallagh (0)
* Sir_Gallantmon (0)
* Son_Goku (0)
* Pharaoh_Atem (0)

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: PostgreSQL 13 - Fedora 33 Self-Contained Change proposal

[Bruno Wolff III]

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 postgresql available for my use, 
it seems pretty aggressive to try to get postgresql 13 into 
F33. Using the beta versions is a pain because the catalog will often 
change right up to release and you need to dump and reload or run 
a conversion on your data with each update. So this won't be practical 
to put in rawhide until it is released. While the release might 
be done soon, postgresql releases often end up happening in October.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Using "rawhide" for the dist-git branch for Fedora Rawhide

[Matthew Miller]

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 and then once we need to branch we branch of Rawhide
> as f34? There could still be a symbolic ref called rawhide for the
> latest rawhide for convenience. What do you think?

I do like this, because it reflects the actual process. However, it does ask
something of our git forge web front end: what would it show by default?



-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

[John M. Harris Jr]

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 keeps JS running in there, and it's updating the DOM,
> > these would likely be able to get swapped out.
> > 
> > Firefox will actually unload tabs that you haven't done anything with in a
> > while under specific circumstances, but I don't know what those are. You
> > may notice, for example, that the page "reloads" without network traffic,
> > when going to a tab you haven't had open in a while. I've seen this on my
> > system recently.
> 
> Take a look at the Task Manager. You will see tabs running even though
> you're not touching that: the pages have elements (ads, animations, etc)
> that run even though the tabs are not visible. True, the browser tries
> to pacify them (turns off sound/video, and whatnot) but they still
> run---and if the JS engine has memory leaks their memory footprint
> increases. You can see the culprits---sort them by "Energy Impact" or
> "Memory" by clicking on the column headers.

I don't really use web browsers on "intensive" pages, so I've never noticed 
that sort of issue, but I alluded to that above, JS running or updating the 
DOM. Most of the pages I use, with the exception of those included in Fedora's 
repos (doh), don't require JavaScript in order to function, for example, LWN.

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 killing things.

> >> More swap doesn't necessarily solve this problem: remember that 1GB/min
> >> is a ballpark HD speed so if you have 10GB swap  that your system is
> >> actually trying to use, you will just sit there for 10 minutes.
> > 
> > I don't really understand how that'd be the case. For that to happen,
> > you'd
> > have to load all of those into memory, have them swap out, then try to
> > swap
> > them all back in at the same time.
> 
> That's my point---you don't have control over it. Swap algorithm decides
> which pages are evicted from RAM or brought back---if the browser starts
> allocating memory, my FreeCAD might get pushed out, and if I click on
> GIMP window after not using it for an hour it tries to bring it back in.

You do have control over it, with the swappiness value, for example. 
Currently, pages that haven't been used in a while are the ones that would get 
swapped out first, which I'm sure we can all agree is the most sane option. 
Your GIMP example is accurate, but that'll take a fraction of a second.

> One way to think about it is that disk is tens of thousands times slower
> than RAM. If you need to use it, your system is commensurably slower.
> That's why zram is such a good idea. Swap was always a tradeoff: you
> saved $'s not spent on RAM, and paid with your time sitting idle waiting
> for the computer.

Well, no. It's not "tens of thousands times slower than RAM". If you need to 
use it, you're swapping in a few pages at a time, not the entire contents of 
swap. Swap isn't a replacement for RAM. It's an optimization that doesn't 
waste RAM needlessly.

> With the modern way of computing, where your data is mostly NOT on your
> system---so you don't lose it if your application shuts down---I am
> beginning to think that application crashes aren't such a big deal as
> they used to be. 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 something else? I'd 
rather not see software crash, and risk data loss, or have my system "drag me 
along".

> Having said that, of course lots of applications ARE local and will lose
> data if crashed, so maybe the cgroup-based approach is the definitive
> solution: hard-limit the memory for cloud apps, to protect the local
> apps from resource exhaustion.

How would you differentiate between "cloud apps" and "local apps"? Are you 
defining "cloud apps" as things that run in web browsers, or use a web browser 
engine, or just anything running from a remote system? If the web browser 
approach, I'd support that handling.

-- 
John M. Harris, Jr.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

RE: [External] Re: Btrfs by default, the compression option

[Mark Pearson]

> -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.
> > https://github.com/inikep/lzbench
> > How to compile on F32.
> > https://github.com/inikep/lzbench/issues/69
> > But is that adequate? How do we confirm/deny on a wide variety of
> > hardware that this meets the goal? And how is this test going to
> > account for parallelization, and read ahead? Do we need a lot of data
> > or is it adequate to get a sample "around the edges" (e.g. slow cpu
> > fast drive; fast cpu slow drive; fast cpu fast drive; slow cpu slow
> > drive). What algorithm?
> 
> More data is always better. I like qualifying the situations in that way. I
> think we should make our decision based on the "center" rather than the
> edges, though.
> 
> For I hope obvious reasons, I'd love to see this tested on a Lenovo X1
> Carbon Gen 8 with the default SSD options.
> 
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 numbers.

Mark
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Using "rawhide" for the dist-git branch for Fedora Rawhide

[Pierre-Yves Chibon]

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 remember
>which name Fedora is using as the mainline development branch.

That is easy to do, already supported by our forge and I am definitely +1 on
this.

One wonder which I have is: should we keep a "master" branch, just as a symlink
to the "rawhide" one for backward compatibility purposes?



>On Wed, Jul 8, 2020 at 9:57 AM Miro Hrončok <[1]mhron...@redhat.com>
>wrote:
> 
>  On 08. 07. 20 15:48, Till Maas wrote:
>  > On Tue, Jul 07, 2020 at 09:03:19PM +0200, Till Maas wrote:
>  >> Hi,
>  >>
>  >> in [2]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 could be renamed. In that case, the branch could be named
>  as
>  >> this. This is just the first step to check if there is enough support
>  >> for this to move forward. The next step would be to start a change
>  >> process.
>  >
>  > 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 and then once we need to branch we branch of Rawhide
>  > as f34? There could still be a symbolic ref called rawhide for the
>  > latest rawhide for convenience. What do you think?
> 
>  I like that idea. However IMHO packagers tend to forget about branching
>  if they
>  are not following Fedora development closely.
>
>  When they do that now, they still do changes in rawhide and they might
>  not
>  update their package in branched -- however in long term, this does not
>  matter
>  because their change is in all future versions.
> 
>  When they do that after this, their change will be in branched but not
>  in
>  rawhide and in the long term, it will be lost.

Having a "rawhide" symlink to whatever is the current FXX rawhide *may* solve
this, if and only if they work on that rawhie branch, if they do not, the risk
you are pointing is real and would trigger potentially more upgrade path break.

Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Using "rawhide" for the dist-git branch for Fedora Rawhide

[Vitaly Zaitsev via devel]

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 break lots of greatly working things.

-- 
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Can we do away with release and changelog bumping?

[Pavel Raiskup]

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 release
> > field and generating changelog problem of Koji,
> > instead of package-maintainer. Currently it sits deployed in staging koji,
> > so you can give it a test-drive :-)
> > 
> > We hope we can return to it later this year, to have it deployed in prod
> > koji.
> 
> +1 to what Florian proposes over rpmautospec, though.  I think bumping the
> release flag is the bare minimal technical change that is needed (except that
> bodhi should pre-fill the description by diffs from %changelogs).

Small experiment (few-liner) for copr with "%bid, build system tag":
https://pagure.io/copr/copr/pull-request/1436

Pavel

> I before stated my opinion that I don't like the generated %changelog
> idea.  Fedora git changelog and `rpm --changelog` are two different
> things.  Mixing them up will bring more costs than savings (fixing
> mistakes in git commit messages retrospectively).  Or in other extreme the
> ugly `rpm --changelog` output (people don't care they mistakenly provided
> broken git commit message).
> 
> I think that it would be just enough to allow people to stop producing
> `rpm --changelog`s if they think that it so awful amount of work (both
> better than more expensive %changelog variant, or ugly variant).  Let's
> allow packagers to specify something like:
> 
> %changelog
> * there's no package metadata in changelog
> 
> Or in the worst case, automatize:
> 
> * there's no package metadata in changelog
> - check %_pkgdocdir/fedora-git-changelog file
> 
> I'm not saying that we can not see every proposed approach in action as
> opt-in.  But, IMVHO, we are wasting to much efforts time here that could
> be spent on our content served to our users instead (== I mean the overall
> %changelog quality).
> 
> Pavel
> 
> > [1] https://docs.pagure.org/Fedora-Infra.rpmautospec/principle.html
> > 
> > On Mon, Jul 6, 2020 at 8:22 AM Florian Weimer  wrote:
> > 
> > > * Björn Persson:
> > >
> > > > The macro could be defined like this for example:
> > > >
> > > >   %buildtag .%(date +%%s)
> > >
> > > Using time for synchronization is always a bit iffy.
> > >
> > > > It would be used in each spec like this:
> > > >
> > > >   Release: 1%{?dist}%{?buildtag}
> > >
> > > We could put the Koji task ID directly into the %dist tag.  We know that
> > > this works in principle.  If we are worried that the number gets too
> > > large, we could subtract the current task ID at the time the fcNN part
> > > of the %dist tag changes.
> > >
> > > The %dist tag is not recorded in the changelog by most packages, so the
> > > changelog does not need changing.
> > >
> > > Thanks,
> > > Florian
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct:
> > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > >
> > 
> 
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Btrfs by default, the compression option

[Matthew Miller]

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
> But is that adequate? How do we confirm/deny on a wide variety of
> hardware that this meets the goal? And how is this test going to
> account for parallelization, and read ahead? Do we need a lot of data
> or is it adequate to get a sample "around the edges" (e.g. slow cpu
> fast drive; fast cpu slow drive; fast cpu fast drive; slow cpu slow
> drive). What algorithm?

More data is always better. I like qualifying the situations in that way. I
think we should make our decision based on the "center" rather than the
edges, though.

For I hope obvious reasons, I'd love to see this tested on a Lenovo X1
Carbon Gen 8 with the default SSD options.

And, for benchmarks, I'm thinking more application benchmarks than a
benchmark of the compression itself. How much does compressed /usr affect
boot times for GNOME and KDE? What about startup time for LibreOffice,
Firefox, etc? Any impact on run-time usage?


[...]
> D. Which directories? Some may be outside of the installer's scope.

As I noted in the bugzilla entry, the /var/log on this system compresses to
3.6% of its original size.

(Methodology: I tarred up the dir and then ran zstd -1 on the tar file. If I
use -19, it's unsurprisingly slow and saves another whole one percent of the
original.)

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: nodebug kernel repo file missing

[Justin Forbes]

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 without
> the repo file it's not easy to enable.
>

I just put a new one up, unfortunately my home directory was deleted
as part of the datacenter move, and I did not have a proper back up.
of everything, so the sync scripts got rid of it. Thanks for pointing
it out.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

[Przemek Klosowski via devel]

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 something else? I'd
rather not see software crash, and risk data loss, or have my system "drag me
along".


I am talking about every process that has enough safeguards to be 
effectively idempotent, either because it doesn't use local data or 
saves it often enough to have a reliable, resumeable checkpoints. Here's 
a couple of examples:


 * browsing, because it both displays remote data and because it saves
   the state (tabs and whatnot)
 * make -j 30
 * even emacs editing, because emacs saves the buffers when it's killed

If the computer gets in trouble doing those things, I don't want it to 
do heroics trying to recoverit's OK to abort and retry. I think the 
'modern cloud computing' is, for many reasons, having to be like 
that---resilient to failures and idempotent.



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 killing things.
[...]
Currently, pages that haven't been used in a while are the ones that would get
swapped out first, which I'm sure we can all agree is the most sane option.
Your GIMP example is accurate, but that'll take a fraction of a second.
Argumentative, Your Honor! It's not just an issue with web 
browsers---you say that yourself few lines further down, it happens with 
every program that uses big data---GIMP with lots of images, FreeCAD 
with a complex geometry, rmaxima with a combinatiorally exploding 
symbolic expression, even your editor where you read in the entire 
/var/log/httpd/access_log against your better judgement. Literally all 
those examples happened to me fairly recently---the system went 
unresponsive, essentially requiring hard reset, whereas the preferred 
outcome would have been to abort those runaway tasks.

One way to think about it is that disk is tens of thousands times slower
than RAM. If you need to use it, your system is commensurably slower.
That's why zram is such a good idea. Swap was always a tradeoff: you
saved $'s not spent on RAM, and paid with your time sitting idle waiting
for the computer.

Well, no. It's not "tens of thousands times slower than RAM". If you need to
use it, you're swapping in a few pages at a time, not the entire contents of
swap. Swap isn't a replacement for RAM. It's an optimization that doesn't
waste RAM needlessly.


I think we both understand what the other person is trying to say, to 
the point where no further explanations are needed. Having said that, 
I'd prefer if you would qualify and augment instead of denying my 
statements. I stand by both of them:


 * disk access is literally O(1) slower than RAM access
 * swap is a cheap substitute for RAM, with the right swap/RAM mix
   determined by cost-benefit considerations

You're right that there's a sweet spot where swap just provides a buffer 
for occasional peak demand---but this entire discussion results from 
complaints about system behavior under heavy swap use, when swap is 
being an inadequate replacement for the needed RAM.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Btrfs by default, the compression option

[Chris Murphy]

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 check with compsize after the fact if the file had been
>> compressed or not.
>>
>> This should be true unless the compress-force mount option is used, even
>> the chattr is only a hint
>
>
> OK, this is an interesting piece of information I wasn't aware of. In this 
> case, if the btrfs heuristics work OK in the majority of cases, the 
> performance hit might not be there, as I feared. Some thorough investigation 
> would be needed, though.

There is a cheap estimator of how well blocks will compress and Btrfs
will do an early bail, and not compress if there's no good gain. It's
common to see mixed compression on files.

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 if the IO storage has been upgraded. Sample size 1,
and the workload was kernel compiling.

The mount option method is file system wide, and permits level to be
specified (except lzo). Whereas using the XATTR is
subvolume/directory/file granularity, and works by inheritance when
set on a directory, it doesn't yet support levels. Upstream
development tells me it's straightforward to include the level in the
XATTR - but that is an RFE so we can't plan for it just yet. The
default level for zstd is 3. The read time performance is about the
same, but the write time performance takes a bigger hit. This isn't a
big deal if we're "curating" specific directories that are likely to
have their write performance limited by, for example internet
bandwidth, or perception wise that the offline update takes however
many tens of seconds longer.

I also tentatively agree that many users' drives are not likely to see
their drive lifetime writes exceeded without compression. But if they
can save ~50% of the space without a read time performance hit (or
even a gain) that's a win. For folks compiling, that needs more
testing. It might work out in favor of some cases and not others - and
if they do a lot of writes the write amplification reduction is more
meaningful. And also some low end very high density chip SSDs can have
low write endurance these days.

SD Card and eMMC  it's a win for sure. Also an argument could be made
do use Btrfs+compression on USB sticks. This class of flash will just
return garbage if they encounter uncorrectable errors - rather than a
discrete read error. In this case, Btrfs refuses to hand over the
corrupt data, in normal operation. A good question is, whether the
desktop should warn that the file is corrupt, and then permit a
degraded read somehow to still get the file off the media. It might
imply necessary desktop integration.


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Btrfs by default, the compression option

[Adam Williamson]

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 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 once?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Brandon Nielsen]

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 also prevent tampering with
the bootloader itself.


No, Secure Boot doesn't solve that problem. Secure Boot, in Fedora anyway,
needlessly disables a lot of kernel functionality, which makes it completely
unusable. You cannot load kernel modules you've built, hibernate your system,
etc. Additionally, Secure Boot does not prevent tampering with /boot files.
You can still change grub.cfg as you like.




Yet here I am, happily using it, across multiple systems...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Btrfs by default, the compression option

[Chris Murphy]

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 to compile on F32.
> > https://github.com/inikep/lzbench/issues/69
> > But is that adequate? How do we confirm/deny on a wide variety of
> > hardware that this meets the goal? And how is this test going to
> > account for parallelization, and read ahead? Do we need a lot of data
> > or is it adequate to get a sample "around the edges" (e.g. slow cpu
> > fast drive; fast cpu slow drive; fast cpu fast drive; slow cpu slow
> > drive). What algorithm?
>
> More data is always better. I like qualifying the situations in that way. I
> think we should make our decision based on the "center" rather than the
> edges, though.

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 write performance hit could be in those scenarios.
Whereas the curated approach can just bypass most of that question -
the payload and workload for flatpak and usr and containers is fairly
fixed across all Fedora users rather than mixed content and workloads
found in ~/


> For I hope obvious reasons, I'd love to see this tested on a Lenovo X1
> Carbon Gen 8 with the default SSD options.
>
> And, for benchmarks, I'm thinking more application benchmarks than a
> benchmark of the compression itself. How much does compressed /usr affect
> boot times for GNOME and KDE? What about startup time for LibreOffice,
> Firefox, etc? Any impact on run-time usage?
>
>
> [...]
> > D. Which directories? Some may be outside of the installer's scope.
>
> As I noted in the bugzilla entry, the /var/log on this system compresses to
> 3.6% of its original size.

Yep. I'm not opposed to it by any means. I'm not sure what things
other than VMs and databases would be there - and we still have to
figure out who "owns" those locations to decide how we get them to set
nodatacow.

There is bit of a rabbit hole for /var/log/journals. systemd-journald
detects btrfs and automatically does nodatacow on its journals. That
means no compression. On a HDD, it makes sense. But on SSD the files
are relatively small and while fragmentation can be bad the tracking
isn't that bad on an SSD, I'm pretty sure compression makes up for it
but I haven't benchmarked it. Anyway I 'touch
/etc/tmpfiles.d/journal-nocow.conf' to prevent the setting of
nodatacow on journals.


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Btrfs by default, the compression option

[Neal Gompa]

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 better read performance, there can be a write
> > performance drop if the IO storage has been upgraded. Sample size 1,
> > and the workload was kernel compiling.
>
> Yeah I guess for /usr the most relevant write metric is "does it slow down
> DNF upgrades or install operations enough to be noticeable / annoying /
> problematic"?
>
> > SD Card and eMMC  it's a win for sure. Also an argument could be made
> > do use Btrfs+compression on USB sticks. This class of flash will just
> > return garbage if they encounter uncorrectable errors - rather than a
> > discrete read error. In this case, Btrfs refuses to hand over the
> > corrupt data, in normal operation. A good question is, whether the
> > desktop should warn that the file is corrupt, and then permit a
> > degraded read somehow to still get the file off the media. It might
> > imply necessary desktop integration.
>
> A related question: Are we planning on using btrfs on live media?
>

Not for this change, no. Part of the reason is that I didn't want to
bite off more than I can chew, and part of it is that I want to
explore some of the Btrfs-specific enhancements with seed images and
the seed/sprout flow before I go down that road.

There's some seriously cool opportunities there, but I want to
actually try it before I propose it. :)

We are, however, changing all the disk image deliverables to Btrfs
(like the ARM ones), since that's how people wind up using it anyway.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Btrfs by default, the compression option

[Chris Murphy]

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 better read performance, there can be a write
> > performance drop if the IO storage has been upgraded. Sample size 1,
> > and the workload was kernel compiling.
>
> Yeah I guess for /usr the most relevant write metric is "does it slow down
> DNF upgrades or install operations enough to be noticeable / annoying /
> problematic"?

I'm pretty fussy and impatient. I think I'd notice. But this is not a
reliable metric. I think a sane test might be looking at the
program.log for a netinstall on lvm+ext4 vs btrfs vs btrfs +compress.
Delete the download portion of the test to eliminate network variation
error, and only look at payload delivery time.

I have done this just today with a Live installation, but this has the
problem that we're significantly read bound due to a tightly wound up
xz compressed image. That acts as a moderator for whoever is really
faster. All these results tell is is that we don't have a problem with
live install performance being meaningfully different.

https://paste.centos.org/view/7ce7b52f


> > SD Card and eMMC  it's a win for sure. Also an argument could be made
> > do use Btrfs+compression on USB sticks. This class of flash will just
> > return garbage if they encounter uncorrectable errors - rather than a
> > discrete read error. In this case, Btrfs refuses to hand over the
> > corrupt data, in normal operation. A good question is, whether the
> > desktop should warn that the file is corrupt, and then permit a
> > degraded read somehow to still get the file off the media. It might
> > imply necessary desktop integration.
>
> A related question: Are we planning on using btrfs on live media?

No. It will still be ext4 nested in a squashfs image, and rsync to
copy. There is/was an idea to move to plain squashfs image, and
unsquashfs to copy - but I'm not certain of its status.
https://fedoraproject.org/wiki/Category:Changes/OptimizeSquashFS
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/L6ZQCOYXZOIIOZM7SUFQDGEUEQU2QY7N/

There is a trade off using Btrfs as the image for media.
(a) compression won't be as good as plain squashfs, images will get
bigger. Maybe as much as 20% - but I've done no optimizing to see if
that can be improved.
(b) Always on checksumming of the payload we care about (excludes the
bootloader, kernel, initramfs for the live environment boot). We can
get rid of the long slow one time media checker option. With no
meaningful performance hit to the user. And catch even transient
corruption due to flakey USB media, etc.
(c) We can use rsync for installs to non-btrfs file systems, they
still get the benefit of (b); and an optimization for installs to
Btrfs is using a seed/sprout replication feature that avoids the
decompression/recompression hit of the (b) option because it just
copies compressed block groups intact, it's not a file copy. Also
these things can be chained (dependently stacked in order; not like
independent overlays).
https://btrfs.wiki.kernel.org/index.php/Seed-device

But yea, as Neal says. Not this cycle.

--
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Btrfs by default, the compression option

[Matthew Miller]

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 write performance hit could be in those scenarios.
> Whereas the curated approach can just bypass most of that question -
> the payload and workload for flatpak and usr and containers is fairly
> fixed across all Fedora users rather than mixed content and workloads
> found in ~/

I just did some quick tests out of curiousity. I tarred up /usr on my
system, resulting in a 9.8GB file. Ran this in my home dir on a
run-of-the-mill Western Digital SSD.


This results in:

compression file  compression   % better than 
  level size ratio previous

1   4.1G41.36%- 
2   3.8G38.97%   6.1%
3   3.6G36.81%   5.9%
4   3.6G36.36%   1.2%
5   3.5G35.63%   2.8%
6   3.5G35.33%   2.0%

9   3.4G34.19%-
   19   2.8G29.72%-


That's pretty good even at level 1. I don't think my setup is useful for
timing benchmarks, and also that takes more care than I want to put into it
this minute, but the interesting note is that levels 1-4 are all about the
same in speed (within 10 seconds) and level 5 suddenly 3x slower. I assume
that's not surprising to anyone who knows how zstd works. But also, unless
you go to crazy high levels, the gains above level 3 really drop off.

(19, by the way, is amazingly slow. Took almost an hour.)




-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Btrfs by default, the compression option

[Martin Jackson]

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 once


Considering how controversial the change has been already,?? I think it 
would make a lot of sense to make one change at a time. If someone were 
to have a bad experience with the new default, it would be unclear 
whether that's because of the filesystem itself or because of the 
options we chose to deploy the filesystem with. If we make those changes 
separately, and the compression change goes badly, the changes would 
still be clearly independent.


Changing one thing at a time is responsible change management in any 
case, especially when we're talking about defaults.


Thanks,

Marty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Richard Hughes]

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 the hardware, including disabling various firmware
protection technologies.

tl;dr: if you care about platform security at all, enable secure boot.

Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Btrfs by default, the compression option

[Matthew Miller]

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 if the IO storage has been upgraded. Sample size 1,
> and the workload was kernel compiling.

Yeah I guess for /usr the most relevant write metric is "does it slow down
DNF upgrades or install operations enough to be noticeable / annoying /
problematic"?

> SD Card and eMMC  it's a win for sure. Also an argument could be made
> do use Btrfs+compression on USB sticks. This class of flash will just
> return garbage if they encounter uncorrectable errors - rather than a
> discrete read error. In this case, Btrfs refuses to hand over the
> corrupt data, in normal operation. A good question is, whether the
> desktop should warn that the file is corrupt, and then permit a
> degraded read somehow to still get the file off the media. It might
> imply necessary desktop integration.

A related question: Are we planning on using btrfs on live media?

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [External] Re: Btrfs by default, the compression option

[Chris Murphy]

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 numbers.
>

As much as benchmarks make me loopy... they are only as valid, as they
actually represent the workload, and many don't. But. The Phoronix
test suite might be a starting point in finding unusually bad things
to look into. (Conversely, unusually good results I consider equally
suspicious but, like, haha ... am I gonna care as much? No.)


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Chris Adams]

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 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[John M. Harris Jr]

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 as inserting their kernel 
modules on their own system, or hibernating to disk. Let's be honest about 
what this does. This is not something that's beneficial here, it's only 
harming our users.

> > You cannot load kernel modules you've built
> 
> 
> If you can build and insert your own kernel module you can do almost
> anything to the hardware, including disabling various firmware
> protection technologies.
> 
> tl;dr: if you care about platform security at all, enable secure boot.

If you've got root, you can STILL do almost anything to the hardware, 
including disabling various "firmware protection technologies". This is 
needlessly kneecapping users.

-- 
John M. Harris, Jr.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

mingw GCC help needed: -fstack-protector and -lssp, undefined reference to `__strcpy_chk'

[Sandro Mani]

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 testcase:


#include 
int main () {
    return closedir (NULL);
}

$ i686-w64-mingw32-gcc -o test.exe test.c -fstack-protector
/usr/lib/gcc/i686-w64-mingw32/10.1.1/../../../../i686-w64-mingw32/bin/ld: 
/usr/i686-w64-mingw32/sys-root/mingw/lib/../lib/libmingwex.a(lib32_libmingwex_a-dirent.o):(.text+0x22f): 
undefined reference to `__strcpy_chk'

collect2: error: ld returned 1 exit status

OTOH, if I write

$ i686-w64-mingw32-gcc -o test.exe test.c -fstack-protector 
/usr/i686-w64-mingw32/sys-root/mingw/bin/libssp-0.dll


it links correctly.

The only other thing which came to mind to verify is that the import 
library references the correct dll, and this appears to be the case:


$ i686-w64-mingw32-dlltool -I 
/usr/i686-w64-mingw32/sys-root/mingw/lib/libssp.dll.a

libssp-0.dll

I'd appreciate any pointers as I'm pretty much in the dark here.

Thanks
Sandro


[1] https://copr.fedorainfracloud.org/coprs/smani/mingw-7.0.0/builds/

[2] Specifically when building mingw-gdb, which adds 
-D_FORTIFY_SOURCES=2 internally, hence adding -fstack-protector to the 
ldflags


[3] I.e. I gtt COLLECT_GCC_OPTIONS='-v' '-o' 'test.exe' 
'-fstack-protector' '-mtune=generic' '-march=pentiumpro'
 /usr/libexec/gcc/i686-w64-mingw32/10.1.1/collect2 -plugin 
/usr/libexec/gcc/i686-w64-mingw32/10.1.1/liblto_plugin.so 
-plugin-opt=/usr/libexec/gcc/i686-w64-mingw32/10.1.1/lto-wrapper 
-plugin-opt=-fresolution=/tmp/cckKHr8u.res 
-plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc 
-plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lmoldname 
-plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt 
-plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-ladvapi32 
-plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32 
-plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lmingw32 
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh 
-plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex 
-plugin-opt=-pass-through=-lmsvcrt 
--sysroot=/usr/i686-w64-mingw32/sys-root -m i386pe -Bdynamic -o test.exe 
/usr/i686-w64-mingw32/sys-root/mingw/lib/../lib/crt2.o 
/usr/lib/gcc/i686-w64-mingw32/10.1.1/crtbegin.o 
-L/usr/lib/gcc/i686-w64-mingw32/10.1.1 
-L/usr/lib/gcc/i686-w64-mingw32/10.1.1/../../../../i686-w64-mingw32/lib/../lib 
-L/usr/i686-w64-mingw32/sys-root/mingw/lib/../lib 
-L/usr/lib/gcc/i686-w64-mingw32/10.1.1/../../../../i686-w64-mingw32/lib 
-L/usr/i686-w64-mingw32/sys-root/mingw/lib /tmp/ccpeowDx.o 
/usr/i686-w64-mingw32/sys-root/mingw/bin/libssp-0.dll -lssp_nonshared 
-lssp -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt -lpthread 
-ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc -lgcc_eh 
-lmoldname -lmingwex -lmsvcrt /usr/lib/gcc/i686-w64-mingw32/10.1.1/crtend.o

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[James Cassell]

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 J?drzejewski-Szmek 
> > > > wrote:
> > > > > Making btrfs opt-in for F33 and (assuming the result go well) opt-out 
> > > > > for F34
> > > > > could be good option. I know technically it is already opt-in, but 
> > > > > it's not
> > > > > very visible or popular. We could make the btrfs option more 
> > > > > prominent and
> > > > > ask people to pick it if they are ready to handle potential fallout.
> > > > 
> > > > I'm leaning towards recommending this as well. I feel like we don't have
> > > > good data to make a decision on -- the work that Red Hat did previously 
> > > > when
> > > > making a decision was 1) years ago and 2) server-focused, and the 
> > > > Facebook
> > > > production usage is encouraging but also not the same use case. I'm
> > > > particularly concerned about metadata corruption fragility as noted in 
> > > > the
> > > > Usenix paper. (It'd be nice if we could do something about that!)
> > > 
> > > So if one has a spare partition to play with btrfs, is there an easy
> > > way to install a second copy of Fedora without having the /boot/efi/
> > > entries overwrite the existing Fedora installation?  Or fix it to have
> > > 2 separate entries after the fact?
> > 
> > 
> > It's possible but has challenges. Separate ESP's you'll need to either
> > (a) use the firmware's built-in boot manager to choose what will
> > probably appear to be identically named Fedora's
> 
> No, you have to rename the first one before doing the second install.
> anaconda explicitly deletes any existing efibootmgr entry named
> "Fedora" before creating a new one.

Any idea if this process is documented?

I typically install on a laptop, with the "encrypt my data" option.

I can confirm that the only way to successfully have 2 side-by-side Fedora 
installs with UEFI, using only Anaconda to set it up, is to have 2 separate 
physical disks, and choose which physical disk to boot by hitting F12 at 
machine power on.

Any attempts to share /boot result in at least one of the installs being broken.

Any attempts to share /boot/efi breaks at least fedora-by-fedora installs.

Adding a separate /boot/efi partition for the second Fedora install makes the 
resulting system usable on the new Fedora install, but there is no obvious way 
to boot into the older Fedora install.

If you unlock the disks within Anaconda for the existing Fedora install, grub 
gets boot entries for that install, but they are non-functional.  (No password 
is prompted for unlocking the disk, indefinite hang.)

What /does/ seem to work is having RHEL and Fedora side-by-side on the same 
disk, as long as each has its own /boot and /boot/efi partitions.

Generally, I'd like the fedora-by-fedora parallel installs to work better 
because that's how I'm best able to participate in the Test Matrix.


V/r,
James Cassell
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

[John M. Harris Jr]

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 killing things.
> > [...]
> > Currently, pages that haven't been used in a while are the ones that would
> > get swapped out first, which I'm sure we can all agree is the most sane
> > option. Your GIMP example is accurate, but that'll take a fraction of a
> > second.
> Argumentative, Your Honor! It's not just an issue with web
> browsers---you say that yourself few lines further down, it happens with
> every program that uses big data---GIMP with lots of images, FreeCAD
> with a complex geometry, rmaxima with a combinatiorally exploding
> symbolic expression, even your editor where you read in the entire
> /var/log/httpd/access_log against your better judgement. Literally all
> those examples happened to me fairly recently---the system went
> unresponsive, essentially requiring hard reset, whereas the preferred
> outcome would have been to abort those runaway tasks.

That other software's data would get swapped out doesn't mean "it's not just 
an issue with web browsers". It's not an issue with anything else. It's okay 
to swap out a few pages, and it doesn't hurt GIMP, FreeCAD, etc. If it does 
with browsers, that's a bug.

> >> One way to think about it is that disk is tens of thousands times slower
> >> than RAM. If you need to use it, your system is commensurably slower.
> >> That's why zram is such a good idea. Swap was always a tradeoff: you
> >> saved $'s not spent on RAM, and paid with your time sitting idle waiting
> >> for the computer.
> > 
> > Well, no. It's not "tens of thousands times slower than RAM". If you need
> > to use it, you're swapping in a few pages at a time, not the entire
> > contents of swap. Swap isn't a replacement for RAM. It's an optimization
> > that doesn't waste RAM needlessly.
> 
> I think we both understand what the other person is trying to say, to
> the point where no further explanations are needed. Having said that,
> I'd prefer if you would qualify and augment instead of denying my
> statements. I stand by both of them:
> 
>   * disk access is literally O(1) slower than RAM access

This is just false, and you can prove that on your own system using only `dd`. 
In fact, if your system is newer than my Lenovo ThinkPad X200 Tablet, you'll 
probably have even faster reads/writes from/to disk.

>   * swap is a cheap substitute for RAM, with the right swap/RAM mix
> determined by cost-benefit considerations

It can be used as such, but really shouldn't be. It's more of an optimization 
such that you don't waste RAM than anything else.

> You're right that there's a sweet spot where swap just provides a buffer
> for occasional peak demand---but this entire discussion results from
> complaints about system behavior under heavy swap use, when swap is
> being an inadequate replacement for the needed RAM.

That's not what this discussion results from. This discussion results from 
somebody outside the KDE SIG deciding the KDE Spin needs EarlyOOM killing our 
applications at random, and ruining our desktop experience.

-- 
John M. Harris, Jr.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Btrfs by default, the compression option

[John M. Harris Jr]

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 equal or better read performance, there can be a write
> > performance drop if the IO storage has been upgraded. Sample size 1,
> > and the workload was kernel compiling.
> 
> 
> Yeah I guess for /usr the most relevant write metric is "does it slow down
> DNF upgrades or install operations enough to be noticeable / annoying /
> problematic"?

More importantly, does it hurt the performance of installed packages?

-- 
John M. Harris, Jr.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Btrfs by default, the compression option

[Chris Murphy]

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 still, to make certain it's well understood
> > what the range of write performance hit could be in those scenarios.
> > Whereas the curated approach can just bypass most of that question -
> > the payload and workload for flatpak and usr and containers is fairly
> > fixed across all Fedora users rather than mixed content and workloads
> > found in ~/
>
> I just did some quick tests out of curiousity. I tarred up /usr on my
> system, resulting in a 9.8GB file. Ran this in my home dir on a
> run-of-the-mill Western Digital SSD.

Btrfs uses a cheap entropy estimator to decide if it should even try
to compress blocks. So it won't always do it. Hence results like this:

$ sudo compsize /usr
Processed 204133 files, 108496 regular extents (114715 refs), 101700 inline.
Type   Perc Disk Usage   Uncompressed Referenced
TOTAL   57%  3.2G 5.7G 6.2G
none   100%  1.8G 1.8G 1.9G
zstd36%  1.3G 3.8G 4.3G


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Btrfs by default, the compression option

[Chris Murphy]

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 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 once?

Yes, it's completely reasonable to not do it. It might seem like a big
change on its own, but Btrfs has had native compression for 10+ years,
and at least three years for most all of the workloads at Facebook. So
it's quite safe. It does, however, touch parts in Anaconda.

So yeah, we definitely do not have to do it. But if we are, I guess my
point is, we need to get serious and act quick like a bunny. This
isn't gonna be some late addition.

-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Adam Williamson]

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 wrote:
> > > > 
> > > > > On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew J?drzejewski-Szmek 
> > > > > wrote:
> > > > > > Making btrfs opt-in for F33 and (assuming the result go well) 
> > > > > > opt-out for F34
> > > > > > could be good option. I know technically it is already opt-in, but 
> > > > > > it's not
> > > > > > very visible or popular. We could make the btrfs option more 
> > > > > > prominent and
> > > > > > ask people to pick it if they are ready to handle potential fallout.
> > > > > 
> > > > > I'm leaning towards recommending this as well. I feel like we don't 
> > > > > have
> > > > > good data to make a decision on -- the work that Red Hat did 
> > > > > previously when
> > > > > making a decision was 1) years ago and 2) server-focused, and the 
> > > > > Facebook
> > > > > production usage is encouraging but also not the same use case. I'm
> > > > > particularly concerned about metadata corruption fragility as noted 
> > > > > in the
> > > > > Usenix paper. (It'd be nice if we could do something about that!)
> > > > 
> > > > So if one has a spare partition to play with btrfs, is there an easy
> > > > way to install a second copy of Fedora without having the /boot/efi/
> > > > entries overwrite the existing Fedora installation?  Or fix it to have
> > > > 2 separate entries after the fact?
> > > 
> > > 
> > > It's possible but has challenges. Separate ESP's you'll need to either
> > > (a) use the firmware's built-in boot manager to choose what will
> > > probably appear to be identically named Fedora's
> > 
> > No, you have to rename the first one before doing the second install.
> > anaconda explicitly deletes any existing efibootmgr entry named
> > "Fedora" before creating a new one.
> 
> Any idea if this process is documented?

I think it's `efibootmgr -b  -L DefinitelyNotFedora`, where  is
the number of the entry called 'Fedora', which you could find by just
running `efibootmgr` to get a list of entries. -b selects the entry to
operate on and -L changes the 'label', which I think is what we're
dealing with here.

If you do that before doing the second install, you *should* be able to
choose between them by using whatever mechanism your firmware offers to
select an EFI boot manager entry at boot time. The one called
DefinitelyNotFedora would be the first install, the one called Fedora
would be the second install.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Schedule for Thursday's FPC Meeting (2020-07-09 16:00 UTC)

[James Antill]

 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 12:00 EDT  --> US/Eastern <--
2020-07-09 16:00 UTC  UTC   
2020-07-09 17:00 BST  Europe/London 
2020-07-09 18:00 CEST Europe/Berlin 
2020-07-09 18:00 CEST Europe/Paris  
2020-07-09 21:30 IST  Asia/Calcutta 
 New Day: Friday -
2020-07-10 00:00 HKT  Asia/Hong_Kong
2020-07-10 00:00 +08  Asia/Singapore
2020-07-10 01:00 JST  Asia/Tokyo
2020-07-10 02:00 AEST Australia/Brisbane


 Links to all tickets below can be found at: 

https://pagure.io/packaging-committee/issues?status=Open=meeting

= Followup Issues =

#topic #907 Which %__foo macros for executables are acceptable? 
.fpc 907
https://pagure.io/packaging-committee/issue/907

#topic #909 Suggest that linting/measuring-coverage is not for %check
.fpc 909
https://pagure.io/packaging-committee/issue/909

#topic #977 Get new members? 
.fpc 977
https://pagure.io/packaging-committee/issue/977

= Followup Pull Requests =

#topic #pr-814 Add SELinux Independent Policy Guidelines.
https://pagure.io/packaging-committee/pull-request/814

#topic #pr-938 Add Package Review Process page.
https://pagure.io/packaging-committee/pull-request/938

#topic #pr-947 Deprecate Old Style Dependency Generators.
https://pagure.io/packaging-committee/pull-request/947

#topic #pr-954 Prohibit use of `rpm` command from specfile.
https://pagure.io/packaging-committee/pull-request/954

= New Pull Requests =

#topic #pr-942 Recommend storing changelog entries in separate file. 
https://pagure.io/packaging-committee/pull-request/942

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open=meeting

 If you would like to add something to this agenda, you can:
  * Reply to this e-mail
  * File a new ticket at: https://pagure.io/packaging-committee
  * E-mail me directly
  * Bring it up at the end of the meeting, during the open floor topic.
Note
that added topics may be deferred until the following meeting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1854753] perl-Sereal-4.015 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854753

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|ppi...@redhat.com   |
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1854754] perl-Sereal-Decoder-4.015 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854754

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|jples...@redhat.com,|
   |ppi...@redhat.com   |
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1854753] New: perl-Sereal-4.015 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854753

Bug ID: 1854753
   Summary: perl-Sereal-4.015 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Sereal
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: de...@fateyev.com, perl-devel@lists.fedoraproject.org,
ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 4.015
Current version/release in rawhide: 4.011-1.fc32
URL: http://search.cpan.org/dist/Sereal/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/7605/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1854752] perl-Sereal-Encoder-4.015 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854752

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-2020-43a6a0fdca has been submitted as an update to Fedora 32.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-43a6a0fdca


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1854753] perl-Sereal-4.015 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854753



--- Comment #2 from Fedora Update System  ---
FEDORA-2020-43a6a0fdca has been submitted as an update to Fedora 32.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-43a6a0fdca


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1854754] perl-Sereal-Decoder-4.015 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854754

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-2020-43a6a0fdca has been submitted as an update to Fedora 32.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-43a6a0fdca


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1854752] New: perl-Sereal-Encoder-4.015 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854752

Bug ID: 1854752
   Summary: perl-Sereal-Encoder-4.015 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Sereal-Encoder
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: de...@fateyev.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 4.015
Current version/release in rawhide: 4.011-1.fc32
URL: http://search.cpan.org/dist/Sereal-Encoder/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/8065/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1854754] New: perl-Sereal-Decoder-4.015 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854754

Bug ID: 1854754
   Summary: perl-Sereal-Decoder-4.015 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Sereal-Decoder
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: de...@fateyev.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 4.015
Current version/release in rawhide: 4.011-1.fc32
URL: http://search.cpan.org/dist/Sereal-Decoder/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/8066/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1854752] perl-Sereal-Encoder-4.015 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854752

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|jples...@redhat.com,|
   |ppi...@redhat.com   |
 Depends On||1854754
   Doc Type|--- |If docs needed, set a value





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1854754
[Bug 1854754] perl-Sereal-Decoder-4.015 is available
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1854754] perl-Sereal-Decoder-4.015 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854754

Petr Pisar  changed:

   What|Removed |Added

 Blocks||1854752





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1854752
[Bug 1854752] perl-Sereal-Encoder-4.015 is available
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1854754] perl-Sereal-Decoder-4.015 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854754

Petr Pisar  changed:

   What|Removed |Added

 Blocks|1854752 |





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1854752
[Bug 1854752] perl-Sereal-Encoder-4.015 is available
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1854752] perl-Sereal-Encoder-4.015 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854752

Petr Pisar  changed:

   What|Removed |Added

 Depends On|1854754 |
   Fixed In Version||perl-Sereal-Encoder-4.015-1
   ||.fc33



--- Comment #1 from Petr Pisar  ---
An enhancement release release suitable for all Fedoras and EPEL ≥ 8.



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1854754
[Bug 1854754] perl-Sereal-Decoder-4.015 is available
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1854078] perl-Parse-CPAN-Packages required in EPEL 8

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854078

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1854720] perl-Archive-Peek required in EPEL 8

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854720

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Comment #1 from Paul Howarth  ---
https://pagure.io/releng/fedora-scm-requests/issue/26899
https://pagure.io/releng/fedora-scm-requests/issue/26900


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1854753] perl-Sereal-4.015 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854753

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
 Depends On||1854754, 1854752
   Fixed In Version||perl-Sereal-4.015-1.fc33



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for all Fedoras and EPEL ≥ 8.



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1854752
[Bug 1854752] perl-Sereal-Encoder-4.015 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1854754
[Bug 1854754] perl-Sereal-Decoder-4.015 is available
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1854752] perl-Sereal-Encoder-4.015 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854752

Petr Pisar  changed:

   What|Removed |Added

 Blocks||1854753





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1854753
[Bug 1854753] perl-Sereal-4.015 is available
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1854754] perl-Sereal-Decoder-4.015 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854754

Petr Pisar  changed:

   What|Removed |Added

 Blocks||1854753





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1854753
[Bug 1854753] perl-Sereal-4.015 is available
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1854754] perl-Sereal-Decoder-4.015 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854754

Petr Pisar  changed:

   What|Removed |Added

   Fixed In Version||perl-Sereal-Decoder-4.015-1
   ||.fc33



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for all Fedoras and EPEL ≥ 8.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1854720] perl-Archive-Peek required in EPEL 8

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854720

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-EPEL-2020-283ef67e51 has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-283ef67e51


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1854754] perl-Sereal-Decoder-4.015 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854754



--- Comment #3 from Fedora Update System  ---
FEDORA-2020-1f18f358d0 has been submitted as an update to Fedora 31.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-1f18f358d0


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1854753] perl-Sereal-4.015 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854753



--- Comment #3 from Fedora Update System  ---
FEDORA-2020-1f18f358d0 has been submitted as an update to Fedora 31.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-1f18f358d0


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1854752] perl-Sereal-Encoder-4.015 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854752



--- Comment #3 from Fedora Update System  ---
FEDORA-2020-1f18f358d0 has been submitted as an update to Fedora 31.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-1f18f358d0


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1854078] perl-Parse-CPAN-Packages required in EPEL 8

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854078



--- Comment #1 from Jitka Plesnikova  ---
https://pagure.io/releng/fedora-scm-requests/issue/26919
https://pagure.io/releng/fedora-scm-requests/issue/26920


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

CPE Team Engagement Feedback

[Aoife Moloney]

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 we decide on what to
work on. We have taken many steps to improve our communication such as
IRC Office hours, regular initiative updates on our taiga board,
weekly mail and blog posts on what we achieved in each quarter and
what we are planning to work on next.
We have also had a few discussions before with some Fedora Council and
CentOS Board members on how best to engage with the CPE Team when you
wish to brief in an initiative or need to file a
bug/issue/enhancement, and as time goes by we are refining our
processes.
We would like to share with you our current approaches that we are
using for you to provide feedback on how you feel these are working.




It is important for our team to feel like their time is protected so
that they are able to enjoy a healthy work-life balance, so we have
categorized work requests that the team responds to into two
categories which we believe benefits both the CPE team and the
communities we serve:

- Project Teams
- These teams are created based on an initiative that has been:
- Received by our product owner in advance
- The work involved has been scoped, reviewed and accepted to
the backlog by the CPE Review Team
- Prioritized and actioned for work during our teams quarterly
planning sessions by CPE Team Stakeholders and Review Team

- Sustaining Team
- This team responds to 'lights on work' and requests that come in
on an ad hoc & regular basis such as:
- BAU infra/releng requests
- RFEs
- Bug fixes



## How we propose to deal with Project Team Initiatives?

* We have published deadlines for initiatives to be briefed into our
team by for each quarter here:
https://docs.fedoraproject.org/en-US/cpe/time_tables/
* Project requests that are recieved are then discussed further with
the requestor and relevant team lead(s) with our product owner
* During our monthly quarterly planning sessions, the CPE Review Team
reviews and prioritises which proposals to scope.
* All scoped proposed initiatives are brought into our QP session for
review and consideration to be worked on in the next quarter.
* Our CPE Review Team review all and vote on the initiatives they
would like to see actioned in the next quarter. Our CPE Review Team
include:
* Fedora - mmiller, mnordin, bcotton
* CentOS - rbowen, bex
* RHEL - bex, dperpeet, aslobodova
* CPE -
* CPE Product Owner - amoloney
* CPE Management - lgriffin, antcarroll, smattejiet
* CPE Team Leads - pingou, bstinson

As a picture is worth a thousand words, so here is one :)

> ![](https://i.imgur.com/Ro08PsE.png)


> Image Credit goes to Smera Goel, the very talented graphic designer that is 
> currently interning as part of the Fedora Outreachy Project.




## How we propose to deal with Sustaining Team BAU requests, RFEs and bug fixes?

In order to allow the people working on initiatives to focus on them,
our Sustaining Team members will be responsible for dealing with all
these requests. They can be filed in the normal ways by community
members.

BAU infra requests can be made on the fedora-infrastructure issue tracker:
https://pagure.io/fedora-infrastructure/
BAU releng requests can be made on the releng issue tracker:
https://pagure.io/releng/




## Project Team vs Sustaining Team Work Classification

### Project Initiatives
Initiatives are weeks to months long projects involving a team of
people to work on and deliver.

We have some deadlines that we try to work towards
Examples of initiatives:
 - rawhide package gating
 - FAS replacement
 - ...


### BAU infra/releng requests
Business As Usual (BAU) requests are simple requests that do not need
anyone to code something, just run some code to solve the request.

Examples of BAU requests:
  - A new mailing list
  - A new FAS/dist-git/copr group
  - A new IRC channel
  - A new project on ci.centos.org
  - A new tag in koji


### RFE

Requests For Enhancements (RFE) are requests to improve a changes made
to either an application or a workflow used in Fedora.


### Bug fixes

Bug fixes are what they are, request to fix bugs.

Examples of bug fixes:
  - Well you know: https://github.com/fedora-infra/bodhi/issues or
pagure.io/pagure/issues are full of them ;-)






This is our team's current way of working, and we are seeing the
benefits from this but wanted to have your feedback too. We would like
to publish this as a 'policy' of sorts for our team on docs.fpo and on
the CentOS wiki and want to include you in this process.
So what are your thoughts on these ideas?
Are they suitable for you or do they need more adjustments?
If they do, what are your suggestions?

To view this email in hackmd, please 

[Bug 1854752] perl-Sereal-Encoder-4.015 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854752



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2020-87dd78b491 has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-87dd78b491


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1854754] perl-Sereal-Decoder-4.015 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854754



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2020-87dd78b491 has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-87dd78b491


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1854753] perl-Sereal-4.015 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854753



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2020-87dd78b491 has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-87dd78b491


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Perl 7 in Fedora

[Petr Pisar]

Hello packagers,

have you noticed an announcement about Perl 7

on a Perl5 Porters list? Saywer X presented an idea that now, when Perl 6 is
called Raku, Perl 5 can resume using the higher numbers and that the next Perl
will be Perl 7.

That part of the announcement wouldn't be exciting at all if there wasn't
the second part that Perl since now will be more aggressive in adding new
features and removing old ones and that Perl will enable all the new
stabilized features by default (without "use v7;").

To comfort conservative users there was a third part that Perl 5 will move
into a maintance mode and it will be supported for the next 5 (up to 10)
years.

That second part provoked many reactions. Especially about a feasibility of
such undertaking. The third part raised questions about compatibility with
a third-party code, especially CPAN, and a coexistence of two Perls on one
system.

A similarity with Python upgrading from version 2 to version 3 is extensive.
Because I observered the Python move in Fedora from a close proximity, I can
tell you that I do not want to experience it again. (It took many years,
cost at least 5 full-time Red Hat employes, and meant significant overhaul in
packaging.)

Then Sawyer X sent an update

that addressed the people's reactions. It introduced a mandatory Perl API
versioning ("use v5", "use v7", "use v8") in every Perl script, a prospect
that each perl release will support at most 3 APIs (old, current, future) and
that the interpreter executable will be called /usr/bin/perl7 while
/usr/bin/perl will be kept unused.

In the mean time, core-p7 branch was revelead in the Perl git tree that
started migrating Perl 5 sources to Perl 7 version and introduced "use p5" and
"use p7"

for enforcing Perl 5 and Perl 7 compatibility mode in the interpreter.

Yesterday Perl 5.33.0

was released with an unclear prospect whether it will lead to 5.34 or 7.0. So
far it seems it will contain changes from core-p7 branch that assure
core modules compatibility among both Perl 5 and Perl 7 mode.


My question four you is what and how you want to package in Fedora.

In my humble opinion, Perl 7 interpreter won't diverge from Perl 5 too far in
the next year (or two years) and many prominent CPAN distributions will be
promptly updated to preserve compatibility with both of the languages (it
actually already happens, see perl-Socket-2.030). Thus I'm for upgrading
Perl 5 to Perl 7 as soon as possible in Fedora. That means when stable Perl 7 is
released and keep it up-to-date and all Perl packages rebuilt against it as we
were used with Perl 5.

I can imagine that some people will insist of having Perl 5 available next to
Perl 7. I can package it either as a module or as a normal package (but keep in
mind that Perl would conflict on /usr/bin scripts and manual pages; we could
strip the manuals and rename the scripts).

But I'm not sure it's worth of repackaging all the CPAN distributions we have
twice for both Perls. Either as a subpackage of one spec file. (Few years back
I proposed few macros  that
would make the packaging agnostic of perl version and they were rejected as
unneeded. I don't know whether the mood has has changed since then.) Or
as a completely independend source packages (that would had the benefit that
a breakage in one language would not affect the other language). There is still
a possibility of using modularity, but that does not bring parallel
installability and recently Fedora banned default streams which makes all
modules a second-class citizen.

So what do you want? Will you be fine with only having the latest Perl (i.e.
Perl 7 next year)? 

-- Petr


signature.asc
Description: PGP signature
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Heads up: Python 3.9.0b4 is in rawhide

[Miro Hrončok]

Hello, we have update Python to Python 3.9.0b4 in rawhide.

We don't anticipate much breakage and it should be ABI compatible with b3.

Let us know if there is trouble.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org

[Bug 1854078] perl-Parse-CPAN-Packages required in EPEL 8

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854078

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-EPEL-2020-b48be8a4ba has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b48be8a4ba


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1854752] perl-Sereal-Encoder-4.015 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854752

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
FEDORA-2020-1f18f358d0 has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-1f18f358d0`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-1f18f358d0

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1854754] perl-Sereal-Decoder-4.015 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854754

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
FEDORA-2020-1f18f358d0 has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-1f18f358d0`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-1f18f358d0

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1854753] perl-Sereal-4.015 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1854753

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
FEDORA-2020-1f18f358d0 has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-1f18f358d0`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-1f18f358d0

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1751896] perl-Verilog-Perl-3.468 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1751896

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2020-07-09 04:43:30




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org