Re: Spec file using github repo - not tarball

[Nico Kadel-Garcia]

On Wed, May 8, 2024 at 4:36 PM Kenneth Goldman  wrote:
>
> Is it possible for a .spec file to clone a github.com repo rather than
> download a tarball?  Can someone link to a working example?

Git clones are bulky, with the entire history of a project rather than
merely the state of the repo at the moment of that tag or git commit.
The "Source:" line can point to a specific archibal tarball or zipfile
export of sourcecode at github.com, such as:

https://github.com/aws/aws-cli/archive/refs/tags/2.15.46.zip




> I found a few hints that it's possible.  However, the fedoraproject.org
> examples use pseudocode or placeholders.  I'd like a working example.
> --
> ___
> 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
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LLVM Packaging Ideas for Fedora 41

[Nico Kadel-Garcia]

On Sat, Apr 27, 2024 at 12:35 AM Tom Stellard  wrote:
>
> Hi,
>
> After each Fedora release we do a retrospective with the LLVM package 
> maintainers
> and talk about how we can improve the LLVM packages[1] in Fedora.  We've come 
> up
> with some ideas for Fedora 41 that we'd like to share to raise awareness and
> get feedback.  Right now these are just ideas, and we plan to write up a 
> formal
> change proposal once we have decided which of these we are going to implement:
>
> * Spec file merge.  We plan to merge the clang, compiler-rt, and libomp 
> packages
> in with llvm and have them be sub-packages of the llvm package.  This will 
> allow
> us to use the build configuration recommended by upstream and also make it 
> possible
> to optimize the packages using Profile-Guided Optimizations (PGO).
>
> * Build compat packages (e.g. llvm18) as early as possible.  When we package 
> a new
> major release of llvm, we create a compat package so that packages that aren't
> compatible with the new version can still use the old version.  In the past, 
> we've
> waited to introduce the compat packages until the new version of LLVM was 
> ready
> (typically during the Beta Freeze).  However, this proved to be an issue this
> release for packages the were ready to switch to the compat packages early in
> the release cycle, but then had to wait for Beta freeze.

From other tools and venues and history with gcc and gnutls releaes, I like it.

> * Switch to python-style compat/main packages.  In order to make the 
> packaging more
> consistent between the main package (e.g. llvm) and the compat package (e.g. 
> llvm18),
> we would retire the un-versioned dist-git for llvm, and create a new 
> versioned dist-git
> for each new release (e.g. llvm19, llvm20, llvm21 etc.).  We would then 
> designate one
> of these as the 'main version', and that version would produce binary rpms 
> that look
> like the current main package (i.e. llvm-libs instead of  llvm19-libs).
>
> * Invert the order of compat/main packages.  Instead of having the compat 
> package be
> the old version, and the main package be the new version, we would have the 
> compat package
> be newer and the main package be older.  This would allow us to introduce a 
> new version of
> llvm without impacting other packages that depend on the main version of LLVM.

My first thought is "don't make me hurt you". So are my second and
third thoughts. Please do not leave the nominally obsolete version as
the default cnotemporary version, the "main" release should always be
the defult. New, pre-release versions should be as short-lived as
possible.

> If anyone has any feedback on these ideas we'd like to hear it and are happy 
> to discuss
> these more.
>
> Thanks,
> Tom
>
>
> [1] LLVM Packages are: llvm, clang, compiler-rt, libomp, lld, lldb, 
> llvm-test-suite, libclc,
> llvm-bolt, libcxx, mlir, flang, python-lit, and polly.
> --
> ___
> 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
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)

[Nico Kadel-Garcia]

On Sun, Jan 28, 2024 at 2:54 PM Gary Buhrmaster
 wrote:
>
> On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney  wrote:
> >
> > Wiki -> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin
> >
>
> One additional item to consider is to review
> the packager guidelines for use of /sbin
> (and /usr/sbin) in additional locations from
> those involved directly with installing binaries.
>
> In particular, I am thinking of the sysusers
> examples where the use of /sbin/nologin
> should, perhaps, be changed to /usr/bin/nologin.
>
> There are almost certainly other places
> in the docs/guidelines.
>
> The documentation updates are always
> the most annoying in my experience.

Please, don't. Deliberately ignoring years of the File System
Hierarchy for some big-vision architectural ideal is one of the things
that has consumed thousands if not millions of man-hours of sysadmin
time since UNIX was invented.

Nico Kadel-Garcia
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning python-flit

[Nico Kadel-Garcia]

On Thu, Jan 25, 2024 at 6:43 PM Maxwell G  wrote:
>
> On Thu Jan 25, 2024 at 20:34 +0100, Miro Hrončok wrote:
> > Hello.
>
> Hi Miro,
>
> Thanks for the announcement!
>
> > Now when python-flit-core has been split out of python-flit, I do no longer
> > have a use-case for python-flit and hence I have orphaned it.
>
> For context, flit-core is the PEP 517 build backend that we need for use
> with %pyproject_* in RPM builds. python3-flit provides the flit CLI that
> can be used for basic Python project management (publishing to PyPI and
> such). python3-flit and python3-flit-core used to be built from the same
> SRPM, but we recently split it into two separate packages to simply the
> specfile and help with RHEL builds.

What is the *fascination* with splitting and renaming packages this
way? Ansible did this, and confused the heck out of their users by
shoving a hundred add-ons into "ansible" and leaving the actually
useful tools in "ansible-core". Why isn't the core packages left in
the original name for the package, and add-ons published as the
distinct package, rather than this apparently popular and breaking
change reverse procedure?

I've recently tried RHEL builds for these flit tools, and they
interweave badly with a circular build dependency involving  of flit,
flit-core, flit-scm. setuptools-scm and exceptiongroups. The dodging
and weaving names of the base packages for their dependencies compound
the difficulties resolving these, at least resolving them from scratch
for RHEL backports.


> While Python developers can always install the flit CLI with pipx or in
> a virtual environment, it is nice to have a global version managed by
> the system package manager.

Agreed, especially considering the recent "bitcoin miner" burdened
modules published at pypi.org. It's very hard to maintain confidence
in a tool suite when any author of a module, upstream, may insert
quite baroque dependency chains.


>
> I'll probably end up taking the package.
>
> > $ repoquery -q --repo=rawhide{,-source} --whatrequires flit
> > python-perky-0:0.8.2-3.fc39.src
> > python-pydyf-0:0.8.0-1.fc40.src
> > python-pyrpm-0:0.14.1-3.fc39.src
> > python-signature-dispatch-0:1.0.1-4.fc39.src
> > python-vecrec-0:0.3.1-11.fc40.src
> > weasyprint-0:60.2-1.fc40.src
> >
> > The packages would probably build fine with flit-core (happy to help with 
> > that
> > if you are interested).
>
> Regardless, those packages should switch to using flit-core to build.
> Pulling in all of flit is not necessary for RPM builds.
>
> --
> Maxwell G (@gotmax23)
> Pronouns: He/They
> --
> ___
> 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
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: python3-PyPDf2 -> python3-pydf package

[Nico Kadel-Garcia]

On Sun, Aug 27, 2023 at 5:39 AM Sandro  wrote:
>
> On 27-08-2023 06:33, Globe Trotter via devel wrote:
> > I am the maintainer of python-PyPDF2 for Fedora (which I do since I
> > was interested in pdf-stapler that I also maintain as a consequence).
> > For a while now, upstream has been wanting all PyPDF2 users to pypdf.
> > I was wondering how I go about this for the F38 repos. Do I need to
> > go through packaging again, or is there an easier way to update
> > python3-PyPDF2 to python3-pypdf? If so, what do I have to do?
>
> Could you provide some links to the upstream sources of PyPDF2 and
> pypdf? And me be also to the issue where the switch from PyPDF2 to pypdf
> is discussed.

Perhaps check pypi.org?

  https://pypi.org/search/?q=pypdf=

Python module capitalization, and inconsist names used by RPM
published modules, are an old problem for Fedora and RHEL.

> I'm assuming PyPDF2 and pypdf are separate packages. In that case you
> would need to submit pypdf as a new package. Once pdf-stapler is built
> against pypdf you can retire PyPDF2 if no other package depends on it.

The above search indicates they are, and that there is a pypdf3.

> If pypdf is a rename of PyPDF2 you'd submit a re-review of the package
> and you need to take care of proper Provides: and Obsoletes: in the new
> package. See the docs for more info:
>
> https://docs.fedoraproject.org/en-US/package-maintainers/Package_Renaming_Process/
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages
>
> I hope that helps.
>
> -- Sandro
> ___
> 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
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Perl 5.38 (System-Wide Change proposal)

[Nico Kadel-Garcia]

On Thu, Jul 20, 2023 at 8:34 AM Xiaojie Chen  wrote:
>
> Hi，I am interesting in the upgrading of perl. Where can I find the detailed 
> process of upgrading and building Perl, including the entire build steps, the 
> list of built RPM packages, and the building order of Perl module packages?

Out of curiosity: why the upgrade? Perl has been pretty stable, why
pursue a local update ahead of the next Fedora release?
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: DNF5-5.0.1 has a stable API

[Nico Kadel-Garcia]

On Mon, Jul 24, 2023 at 4:43 PM Chuck Anderson  wrote:
>
> On Mon, Jul 24, 2023 at 02:08:25PM -0400, Stephen Smoogen wrote:
> > Personally I would have preferred to call this a new tool versus trying to
> > use dnf name still. It makes it clearer that the break is going to happen.
>
> I propose "qzw".  It's so easy to type on a qwerty keyboard layout.

"Bless you."
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: UW-IMAP

[Nico Kadel-Garcia]

On Thu, Jun 29, 2023 at 9:18 AM Marcin Juszkiewicz
 wrote:
>
> W dniu 29.06.2023 o 14:57, David Both pisze:
> > I have noticed that uw-imap is no longer in the Fedora repo and that the
> > last was F33. I like it far better than the other options because it is
> > the IMAP server that best "does one things and does it well." It also
> > requires the least amount of configuration and it just works so it also
> > meets the KISS test.
>
> UW IMAP development ended in 2008. Development of Panda IMAP (successor)
> ended in 2012 when Mark Crispin died.
>
> https://github.com/jonabbey/panda-imap holds complete public history.
>
> I would rather go Dovecot rather than revive 11 years old project. Did
> setup of it once, about 10 years, and it serves my private mail since then.

uw-imap got pretty weird, with Mark Crispin getting very, very upset
and accusing people of stealing his university's code if they merely
*pointed to* off-shore repositories where SSL patches were published
and could be legally imported without running into US export laws. He
had SSL hooks which he refused to publish, except for his university's
internal use. The arguments got *weird*, and heated, and some of us
were very grateful to be able to switch to dovecot and avoid the
issues.

David, have you tried dovecot as a "simple IMAP server"?
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a chance to phase out `/lib64` directory?

[Nico Kadel-Garcia]

On Tue, Jun 27, 2023 at 5:02 AM Vít Ondruch  wrote:
>
> I don't think that GCC is always the best example to follow.
>
> Nevertheless, wouldn't it be worth of phasing out the /lib64? I don't
> know what is the history behind, but I don't think this layout is
> conceptual.
>
>
> Vít

Until, and unless, 32-bit compatibility on 64-bit hosts gets discarded
and the File System Hierarchy rewritten, probably not.
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Proposal: drop delta rpms (for real this time)

[Nico Kadel-Garcia]

On Fri, Mar 3, 2023 at 7:06 AM Geraldo Simião Kutz
 wrote:
>
> Testing F38 KDE spin today, I see this:
> Delta RPMs reduced 235.2 MB to 23.8 MB (89.9%)
>
> So, it seems we do still have some cornercases when deltaRPM shows its value.

Not really. That's local dis, but the aggregate burden of regularly
downloading additional repodata exceeds that pretty quickly in
environments that do daily update audits.

> But, ok, In agree that in most cases it's irrelevant this days.
> +1 for dropping deltarpm
>
> geraldosimiao

It's a complex feature to support, we're not scrambling for slivers of
disk space these days, and maintaining all the deltas grows very
quickly for environments that, in theory, no longer have point
releases to use as references for deltarpm.
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Willing to unretire package: rust-starship

[Nico Kadel-Garcia]

On Fri, Feb 17, 2023 at 10:17 AM Maxwell G  wrote:
>
> On Fri Feb 17, 2023 at 08:37 -0500, Nico Kadel-Garcia wrote:
> > On Fri, Feb 17, 2023 at 7:51 AM Andreas Schneider  wrote:
> > > It downloads packages from the internet and doesn't use system rust 
> > > packages.
>
> > ansible-core and awscli also install internal versions of what should
> > be separately published python modules,
>
> To be clear, it's RHEL/CentOS Stream's ansible-core package that does
> this. They include sdists of jinja2, markupsafe (neeeded by jinja2),
> packaging, pyparsing (needed by packaging), and resolvelib in the SRPM
> and build/install them into a special vendor directory that ansible adds
> to sys.path :(. Fedora's ansible-core's package does not do this, and I
> very much am not a fan of the practice.

Also "straightplugin".  I see your name in the %changelog for
ansible-core in Fedora, thanks for your work there. I based my
published SRPM code on Fedora. If you've successfully navigated the
Fedora submission process, which I've never managed, despite a few
attempts. Would you care to help me walk through them? Or can I
feed you the needed .spec files  to get them into EPEL and possibly
help clean up the RHEL backports? I've some significant speedups and
improvements for the "ansible" package, as well, and I see your name
in the %changelog for that as well.
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Willing to unretire package: rust-starship

[Nico Kadel-Garcia]

On Fri, Feb 17, 2023 at 7:51 AM Andreas Schneider  wrote:
>
> On Wednesday, 30 November 2022 18:43:50 CET Mauricio Teixeira wrote:
> > Fabio,
>
> Hi Fabio,
>
> > What is so bad about the COPR package that can't be used in the main repo?
>
> It downloads packages from the internet and doesn't use system rust packages.

There are a lot of tools that do this. I just noticed that the
docker-ce SRPMs over at www.docker.com do this. ansible-core and
awscli also install internal versions of what should be separately
published python modules, it's an ongoing issue, and one of the
reasons to build things in "mock" or "koji" to prevent just that sort
of reaching out to thard party web sites during package compilation.
It's just the sort of off-site requirement that broke nodejs for a
*lot* of people for a while,
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: When is dnf5 going to replace dnf4?

[Nico Kadel-Garcia]

On Thu, Jan 26, 2023 at 8:31 PM Reon Beon via devel
 wrote:
>
> Are there still some outstanding bugs preventing this from happening?

Is there any one critical feature that justifies the update? Avoiding
the requirement of python is... OK, maybe understandable, but I don't
see it as a "must-have" improvement. And better modularity support
My observation so far is that modularity simply destabilizes systems,
because the authors of the "modularized" tools do not build up the
full suites of likely necessary components. I'm running into that
right now with python310 back in RHEL 8 for ansible, the results are
not pretty.
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Proposal: dnf should offer to update all of the dependencies of any package installed or updated

[Nico Kadel-Garcia]

On Sat, Jan 28, 2023 at 1:23 PM Gordon Messmer  wrote:
>
> On 2023-01-28 00:14, Bruno Wolff III wrote:
> > If there is a problem with not uodating dependencies when you do an
> > install or an update on selected packages, the packages dependencies
> > are not properly defined.
>
>
> By definition, yes.  But rpm auto-detects dependencies, and rpm doesn't
> do symbol-level dependency detection, so it doesn't capture
> minor-version dependency creep.  In order for rpm to do this, you'd
> probably have to throw out the current implementation of dependency
> resolution that provides "libfoo.so.2()(64bit)" and instead provide a
> dependency like "(foo-libs >= 2.4 with foo-libs < 3)", at least for the
> cases where libraries do not provide versioned symbols -- which I
> believe includes the vast majority of them.  (You'd also need to forbid
> restructuring packages within a stable release.)

The RPM build process tries to do so, but it can't possibly outsmart
the morass of dependencies that "modularity" tends to create. It's why
so many have given up on modularity since its introduction in Fedora,
and one of the reasons I have trouble getting approval to do RHEL 8
and RHEL 9 updates. The various sets of "modularity" components are
not tested against all the other versions of related packages: I'm
running into this headlong with ansible collections and the morass of
dependency chains weaving into and out of modularity deployed
coponents, myself. The "modular" channels are almost invariably
incomplete and require additional RPM builds to satisfy "test" or
"doc" building steps from the same base software package.

Modularity and its inevitable build-time and deployment
inconsistencies have consistently hindered dependency management.

> > I think the case where you don't want to keep the full system up to
> > date, but a selective update or install causes problems as well is
> > pretty rare. I think it might be reasonable to have an option that
> > requests doing a recursive update. I would consider this to be a low
> > priority feature request that has to compete with all of the other
> > work being done on dnf, rather than a bug. I don't work on dnf and the
> > people that do might feel differently.
>
>
> Yeah, I agree, it's not super high priority.  But it's also not really
> well understood among the community that partial updates (such as `dnf
> update --security`) and package installation without a contemporaneous
> update are unreliable.

Yeah. It's hard to predict exactly when it will break, but it *does*
break. Unfortunately, so do fork list upgrades, such as using a base
OS image that is three years old and then doing "dnf -y update" on it.
It's very difficult to predict which update will break what, but
updating 700 packages at once as I just saw on a base OS image of RHEL
8. It's one reason Fedora's frequent releases are useful: they provide
a much fresher, smoke tested baseline image to apply changes to,
rather than relying on upgrades in places.

> I can work on some of those changes to documentation and to rpm or dnf,
> but I'd like input from the developer community before starting.  (And
> at some point I think that Fedora, the org, should probably consider
> whether `dnf update --security` is broken and unreliable.)

It's popular. I'm remembering when the "dnf update -y --security"
broke curl, because either "curl-libs" or "crypto-policies" was not
listed in those updates, and hilarity ensued. It's why I try to
schedule regular "dnf -y update" operations, and updating my base OS
images to match. It can get a bit awkward when the base OS images at
your favorite cloud vendor fall increasingly out of date over time.
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

[Nico Kadel-Garcia]

On Fri, Dec 30, 2022 at 12:02 PM Tomasz Torcz  wrote:
>
> On Fri, Dec 30, 2022 at 12:59:19AM -0500, Nico Kadel-Garcia wrote:
> > On Wed, Dec 28, 2022 at 7:01 AM Ralf Corsépius  wrote:
> > >
> > > Am 28.12.22 um 11:49 schrieb Peter Boy:
> > > >
> > > > It is a good idea to make the timeout configurable.  But the default 
> > > > timeout for servers must remain unchanged.
> > >
> > > My problem is not "defined timeouts" it is systemd delaying shutdowns
> > > for no obvious reasons.
> >
> > You've apparently not encountered the corruption of a database under
> > heavy load where the cache where swapspace has not yet been propagated
> > to disk. Imagine a server running a lot of virtual machines for an
> > image of what an overly aggressive shutdown timeout can do to your
> > otherwise stable systems.
>
>   This sounds serious, and this is the situation in which default
> setting is not correct, no matter if its 15 seconds or 120 seconds.
> The database and VM services should define own timeout (it goes from 0
> to infinity, plenty of values to choose from).

I didn't mean to give Talf a hard time.

systemd has been used to inflict unwelcome timeouts before, so it
should be modified only with caution. I'm especially thinking of that
infamous "let's make systemd responsible for ending logins" change
that broke screen, nohup, tux, and leaving background tasks running.
(See https://lwn.net/Articles/690151/ ) We need to be cautious about
not being able to personally picture why someone would use an existing
default and overriding it casually, and inflicting our new logic on
the unsuspecting existing userbase.
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

[Nico Kadel-Garcia]

On Wed, Dec 28, 2022 at 7:01 AM Ralf Corsépius  wrote:
>
> Am 28.12.22 um 11:49 schrieb Peter Boy:
> >
> > It is a good idea to make the timeout configurable.  But the default 
> > timeout for servers must remain unchanged.
>
> My problem is not "defined timeouts" it is systemd delaying shutdowns
> for no obvious reasons.

You've apparently not encountered the corruption of a database under
heavy load where the cache where swapspace has not yet been propagated
to disk. Imagine a server running a lot of virtual machines for an
image of what an overly aggressive shutdown timeout can do to your
otherwise stable systems.

> And as you asked: On my (bare metal) servers, Im am occasionally
> experiencing delayed shutdowns in the order of several minutes.
>
> This is simply inacceptable!
>
> Ralf

I'm assuming you have very busy filesystems, perhaps not well
configured for their load. There databases that can be *really*
corrupted by interrupted shutdowns, especially when the change has
been written to the disk cache but not yet committed to disk. And some
network services, like NFS, can take way too long to shut down
gracefully, but risk the upstream server if clients are forcefully
shut down.

Nico Kadel-Garcia
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Macro expanded on comment?

[Nico Kadel-Garcia]

On Tue, Dec 27, 2022 at 1:30 PM Ron Olson  wrote:
>
> Hey all-
>
> I commented out a SOURCES line in a spec file to test something and got an 
> interesting warning: “Macro expanded in comment on line …”. I assume it’s 
> just that, a warning, but was kinda surprised to see a commented-out line 
> being evaluated at all. I did some searching and came across this BZ from 
> 2015: https://bugzilla.redhat.com/show_bug.cgi?id=1224660 that seems to 
> suggest there’s a better way (%dnl), so if I want to comment something out 
> instead of putting a # in front of the line, I should use %dnl?

When I do things like this, I also replace '%" with "%%" at every
instance within the commented out line to avoid just this issue. I do
the same thing in %changelog. You may find this to be more effective.

Nico Kadel-Garcia


> Thanks for any info!
>
> Ron
> ___
> 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
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Review Request: ImageMagick7

[Nico Kadel-Garcia]

On Sat, Dec 3, 2022 at 5:57 AM Vitaly Zaitsev via devel
 wrote:
>
> On 03/12/2022 00:30, Sérgio Basto wrote:
> > The proposal now is to keep ImageMagick 6 and make a new package with
> > ImageMagick 7 , when we have all applications use only ImageMagick 7,
> > we move the sources from ImageMagick7 to ImageMagick
>
> I think it would be better to update the ImageMagick package to version
> 7 and create a compatibility package ImageMagick6.
>
> --
> Sincerely,
>Vitaly Zaitsev (vit...@easycoding.org)

We've had just these issues with Java and python, and years ago with
perl and gcc upgrades. Do the "add a suffix" first, to make the new
version available for testing and debugging, because it's going to
break a *lot* of working code that uses tools like "convert". After
that's had a chance to sink in, then switch the default to be the new
ImageMagick 7 tools, and leave a previous version around as
ImageMagick 6.

The "compat-*" packages, such as the compat-gnutls I've worked with in
RHEL, have been useful for compilation of tools demanding current
versions of libraries, but are not helpful with such a large suite of
executable tools as ImageMagick.
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Troubleshooting EPEL 8 build

[Nico Kadel-Garcia]

On Tue, Sep 13, 2022 at 3:56 PM Neal Gompa  wrote:
>
> On Tue, Sep 13, 2022 at 3:36 PM Ron Olson  wrote:
> >
> > Unfortunately I can’t get that rhel+epel8 to work, as it complains “ERROR: 
> > /etc/pki/entitlement is not a directory is subscription-manager 
> > installed?”. I went through all the other epel-8 flavors and they all work. 
> > I added this to the spec file as a test:
> >
> > %if 0%{?rhel} && 0%{?rhel} == 8
> > BuildRequires: gcc-toolset-11
> > %endif
> >
> > So I could try a scratch build on koji but it failed too 
> > (https://koji.fedoraproject.org/koji/taskinfo?taskID=91951147).
> >
> > Not sure how to fix this; I can’t get it to fail on any local instance, and 
> > apparently Koji uses its own special flavor of EPEL-8 so it’s pretty 
> > frustrating. The weird thing is that it was working before with earlier 
> > builds of Swift.
> >
>
> You need to enable it at the beginning of %build
>
> %If 0%{?el8}
> # Enable GCC Toolset 11
> . /opt/rh/gcc-toolset-11/enable
> %endif
>
> Then it'll work.

The use of the "el8" is also cleaner, and a bit more clear about being
compatible for other RHEL baed systems.

Nico Kadel0-Garcia
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Nico Kadel-Garcia]

On Thu, Sep 8, 2022 at 8:27 AM Milan Crha  wrote:
>
> On Thu, 2022-09-08 at 12:20 +0200, Jaroslav Mracek wrote:
> > DNF5 is completely a different component. It does not depend like
> > microdnf on Python. DNF plugins are not compatible with DNF5. There
> > will be changes in commands, options, outputs and so on therefore
> > selling it as an update will be quite confusing.
>
> Hi,
> the current COPR builds for early testers conflict on the libdnf5-devel
> package:
>
>   - package libdnf5-devel-5.0.0-20220826011404.2.g05e0c2c0.fc37.x86_64
> conflicts with libdnf-devel < 5 provided by libdnf-devel-0.68.0-
> 1.fc37.x86_64
>
> Is that going to be solved anyhow, or it's expected? The
> library/executable files can be installed in parallel, it seems, or at
> least those I tried, but having the devel files for both is not
> possible at the moment. It would be useful to not conflict the files,
> thus one can build on one machine for both versions, not replace the
> devel files constantly, if the two are supposed to live together for
> some time.
> Bye,
> Milan

And I'd like a pony. More seriously, installing parallel versions of
the same development tools overn conflict due to files in
/usr/include/ unless the original others thought to distribute the
software in major version specific subdirectories. Not many utilities
do that.
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Help needed with Python fc36 build failing

[Nico Kadel-Garcia]

On Tue, Sep 6, 2022 at 10:52 AM Michael J Gruber  wrote:
>
> > On Mon, Sep 5, 2022 at 2:01 PM Sandro  >
> > pyproject does not work well, and is not backwards compatible. This is
> > particularly a problem for EPEL ports from Fedora. Personally, I'd
> > like to see it fixed for EPEL before relying on it for anything in
> > Fedora.

I believe that was quoting me?

> The current py packaging guidelines recommend the opt-in dependency generator 
> (which uses pyproject.toml) unless EPEL 8 or non-current Fedoras are used. 
> Should this caveat be extended to F36 and EPEL 9, or am I mis-understanding 
> the role of pyproject.toml for the packaging macros?

If possible, I'd much rather see backports to RHEL 8 and RHEL 9
completed to ease backporting before any further python modules
whatsoever get pyproject activated in Fordera. Grabbing a current
Fedora release of anything with pyproject and backporting it to RHEL
is now a serious pain in the keister.
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Help needed with Python fc36 build failing

[Nico Kadel-Garcia]

On Mon, Sep 5, 2022 at 2:01 PM Sandro  wrote:

> Thank you, Miro, for the explanation and the pull request. I remember
> switching away from setup.cfg after being told that pyproject.toml is
> the way forward. I must have missed the fact that this required a newer
> minimum version of setuptools.

pyproject does not work well, and is not backwards compatible. This is
particularly a problem for EPEL ports from Fedora. Personally, I'd
like to see it fixed for EPEL before relying on it for anything in
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: GTK 2 removal from RHEL 10+

[Nico Kadel-Garcia]

On Mon, Aug 29, 2022 at 2:05 AM Tomáš Popela  wrote:
>
> Hi Sérgio,
>
> Dne so 27. 8. 2022 21:53 uživatel Sérgio Basto  napsal:
>>
>> As Kevin Kofler (more or less) wrote in "Pcre Deprecation" thread,
>> maybe we should be prepared to support pcre-1 forever and IMO we also
>> can extend the concept to other packages, btw GTK2 is one of them .
>>
>>
>> Checking on rawhide gtk2 still have 385 packages that depend on gtk2
>> ...
>
>
> Please don't mix apple and oranges - the email is about RHEL and not about 
> Fedora. We don't have any intentions for removing GTK 2 from Fedora (at least 
> not for the foreseeable future) and even if that would happen, we would 
> orphan the package so anyone from the community can step in.
>
> Bye,
> Tom

Since that orange grows in the apple orange, and since RHEL is based
on Fedora, it seems a reasonable concern. We just had this with
python2 and python3, which is still messy.
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: future of dual booting Windows and Fedora, redux

[Nico Kadel-Garcia]

On Tue, Jul 26, 2022 at 9:16 PM Kevin Kofler via devel
 wrote:
>
> Chris Murphy wrote:
> > Summary: Windows 10/11 increasingly enables Bitlocker (full disk
> > encryption) out of the box with the encryption key sealed in the TPM.
> […]
> > The Bitlocker encryption key is unsealed only if the boot chain
> > measurement by the TPM matches the expected values in a TPM PCR.
>
> So, basically, they set up things without the user's knowledge so that the
> user's data can only be decrypted from Windows, only when booted directly,
> and only with Restricted Boot enabled. Does that not fit the definition of
> ransomware? Treacherous Computing at its finest… Does anyone still believe
> that all this is about security?

It's DRM, not ransomware. It's locking in, not deleting, your existing
access and tying it to specific hardware and software. It was
presented originally as a "security feature", but it was pretty clear
from day one that it was designed for digital rights management and
vendor lock-in.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: future of dual booting Windows and Fedora, redux

[Nico Kadel-Garcia]

On Tue, Jul 26, 2022 at 4:07 PM Kevin Kofler via devel
 wrote:
>
> Chris Murphy wrote:
> > a. Fix GRUB by giving it the ability to modify UEFI NRAM "bootnext" value,
> > so that instead of chainloading the Windows bootloader from GRUB, GRUB
> > will modify the system NVRAM such that the next boot (only) will directly
> > boot the Windows bootloader. Thus far there's no interest by GRUB
> > upstream. Whereas systemd-boot has implemented it.
>
> As I already mentioned the last time this has come up: Why can we not,
> instead of chainloading Windows directly, chainload a systemd-boot
> configured to always bootnext to Windows? GRUB would still think it boots
> Windows directly. (I do not see why it would notice any difference, all that
> would change is the name of the image that gets chainloaded.) And systemd-
> boot does not need to know that it is being chainloaded from GRUB. So I do
> not see why that would not work, without any changes to the software.
>
> Kevin Kofler

Why wase the cycles trying to outsmart TPM? Why not use a virtualized
Fedora in a VM on the Windows box, or vice versa, instead of
continuing to burn cycles on what has been  a long running source of
instability and incompatibility on new hardware and with new
bootloaders? If there were anyone actually working on improving the
upstream BIOS to handle dual-booting better, I might see it. But I
don't see hardware vendors pusuing this. Do you?
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

[Nico Kadel-Garcia]

On Fri, Jun 24, 2022 at 5:14 AM Dmitry Belyavskiy  wrote:
>
>
>
> On Wed, Jun 22, 2022 at 11:02 PM Miro Hrončok  wrote:
>>
>> On 22. 06. 22 21:05, Vipul Siddharth wrote:
>> > We are going to deprecate openssl1.1 package, stop shipping the
>> > corresponding devel package, and stop respecting crypto policies in
>> > openssl1.1 package itself.
>>
>> +1 to deprecating it
>
>
> Great!

Please don't stop shipping the devel package while still shipping the
old library package. RHEL has been doing that with python3-ldb-devel,
and python3-talloc-devel, and used to do that with lmdb-devel, and
it's been... infuriating, especially since Red Hat and CentOS kept
them around for internal use in their build environments, they just
neglected to include them in the published operating. It wasn't
*exactly* a GPL violation, since they continued to provide SRPMs, but
it was quite irksome.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ansible-core license change and update (Re: `ansible` Package License Change)

[Nico Kadel-Garcia]

On Thu, Jun 23, 2022 at 12:22 AM Maxwell G via devel
 wrote:
>
> On Monday, May 9, 2022 10:20:25 PM CDT Maxwell G via devel wrote:
> > The license of `ansible` 2.9.x has been corrected from `GPLv3+` to `GPLv3+
> > and BSD and Python and MIT and ASL 2.0`. The previous `License:` tag did
> > not properly account for the multi-licensing.
> >
> > Please note that this only applies to EPEL and Fedora 34 and 35. The license
> > of `ansible` 5.x (the collections bundle), which is available on Fedora 36
> > and above, remains the same.
>
> This has now been corrected[1] in Rawhide's ansible-core. To be explicit,
> ansible-core's license has also been corrected from `GPLv3+` to `GPLv3+ and
> BSD and Python and MIT and ASL 2.0`. This will propagate to F35 and F36 when I
> get around to updating them.
>
> This shouldn't have any practical consequences, as the GPL is still the
> primary and most restrictive license.
>
> On a related note, ansible-core 2.13.1 and ansible 6.0.0 were just released
> upstream and have been updated in Rawhide[1]. In Fedora 36, ansible-core and
> ansible will stay on 2.12.x and 5.x.x, respectively. However, I have also made
> a COPR available[2] for F35 and F36 users who want to use the latest versions
> of ansible-core, ansible, and the standalone collections that we have
> packaged.

Whoever is working with that right now is welcome to my notes and
tools, at https://github.com/nkadel/ansiblerepo/ . 2.13.1 broke the
documentation creation tools, and the continuing insistence of
ansible-core on using "#!/usr/bin/env python" instead of
"#!/usr/bin/env python3" causes problems for Fedora unless you add a
"BuildRequires: /usr/bin/python". The "wibbly-wobbly, timey-wimey"
selection of "/usr/bin/env python" versus "/usr/bin/python" vs.
"/usr/bin/python3 vs. "%{__python3}" vs. "why are we putting a #! line
in this file, it's a module not an executable script and gets
imported, not executed" is... well, it's a source of confusion. Using
'%py3_shebang_fix' would resolve a lot of this in the .spec file, but
my suggestions to apply such changes upstream have not been well
received.

Packaging ansible-core 2.13 for EPEL takes work. It requires python
3.8 or better, which require the commands "dnf modules enable
python38-devel; dnf modules enable python38" to be able to install on
RHEL 8 or 9, and there is a modest raft of missing python modules for
python38. That includes a pretty big tower of dependencies to provide
python38-jinja2 >= 3.0. Check the jinja2 dependency issue I reported
at https://github.com/ansible/ansible/issues/77620 . The conversation
got very strange, and I was pretty firmly informed that RPM packaging
is not supported by the ansible core developers. pm, only pip
installations. That will not work well for koji or mock, and I was
surprised at the insistence, since Red Hat owns ansible.com and sells
Ansible Tower licenses. See the ticket:

 https://github.com/ansible/ansible/issues/77620

EPEL 8 or EPEL 9 would probably benefit from my list of associated
python38 RPMs to satisfy the other ansible-core requirements, such as
the python38-resolvelib update and python38-pbr. I've tried before to
assemble the credentials and permissions to build EPEL packages
myself, but have been balked so far by the variety of registration
requirements. I'm willing to put those in myself if I can get some
walkthrough help getting the permissions together. Or I'm happy to
work with someone with EPEL and/or Fedora privileges to get these
published, and I'm not insistent on credit. Any takers?

Nico Kadel-Garcia

> [1]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-5fa1185e04
> [2]: https://copr.fedorainfracloud.org/coprs/gotmax23/ansible-6/
>
> --
> Thanks,
>
> Maxwell G (@gotmax23)
> Pronouns: He/Him/His___
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [HEADS UP] Fedora 37 Python 3.11 rebuilds to start in a side tag early next week

[Nico Kadel-Garcia]

On Sat, Jun 18, 2022 at 2:50 AM Miro Hrončok  wrote:
>
>
>
> On 18. 06. 22 2:33, Adam Williamson wrote:
> > On Sat, 2022-06-18 at 00:31 +0200, Miro Hrončok wrote:
> 
>  Interesting bugzillas:
> 
>  fedpkg: FTBFS in Fedora Rawhide with bodhi-client 6: Failed to establish 
>  a new
>  connection: [Errno -3] Temporary failure in name resolution
>  https://bugzilla.redhat.com/show_bug.cgi?id=2097858
> >>>
> >>> If fedpkg will be rendered unusable by the merge, though, that seems
> >>> like a problem. All the other things look like ones we can reasonably
> >>> work through over time.
> >>
> >> It won't. Worst case, I am going to disable the bodhi testes temporarily 
> >> in the
> >> spirit of "it's already broken with 3.10".

That should avoid reproducing the problem
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Copr - EPEL-9 buildroot

[Nico Kadel-Garcia]

On Thu, Jun 9, 2022 at 3:32 PM David Sommerseth  wrote:
>
>
> Hi,
>
> I've been trying to complete the OpenVPN 3 Linux v18_beta release in my
> Fedora Copr repository for EPEL-9.  But there seems to be something odd
> going on here.  I tried to reach out on IRC earlier today but didn't get
> much further.
>
> The issue, how I see it, is that the buildroot for EPEL-9 seems to use
> CentOS 9 Stream (centos-stream+epel-9-x86_64) instead of RHEL-9.  The
> end result is that the openvpn3-selinux package depends on a newer
> selinux-policy package than what is available in RHEL-9.

Can you run "mock -r rhel+epel-9-x86_64: to test your build's on a
local host with mock? You'd have to use a RHEL build server to get
access to the RHEL published repos, or if you're a complete weasel
like, oh, I dunno, the guy who wrote this, build your own internal
RHEL mirrors for mock use?

 
https://github.com/nkadel/nkadel-rsync-scripts/blob/master/reposync-rhel-8.sh

It's not full koji deployment, but useful for smoke testing your
builds. I use something related for building tool suites for samba,
awscli, and ansible.

> My latest attempt is available here:
> 
>
> And the paradox is that trying 'yum copr enable dsommers/openvpn3' on a
> CentOS 9 Stream also doesn't work.  But manually downloading and
> installing the .repo file, installing 'openvpn3-client' works smooth on
> CentOS 9 Stream.
>
> Is this a known issue?  Shouldn't EPEL-9 repository builds happen on
> proper RHEL-9?  And buildi
> ng on CentOS 9 Stream sounds wrong as well.
>
> Doing the EPEL-9 build on Fedora Koji works fine and installs fine.
> 
>
>
> In addition, trying to do a build with the proper CentOS 9 Stream
> repository also fails - as the moce config used there is the plain
> centos-stream-9-x86_64, not the '+epel' variant used in EPEL-9.
>
> I do understand this last issue (CentOS 9 Stream build) is different
> from the EPEL-9 build issue.
>
>
> Any advice would be appreciated.
>
>
> --
> kind regards,
>
> David Sommerseth
> ___
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Copr - EPEL-9 buildroot

[Nico Kadel-Garcia]

On Fri, Jun 10, 2022 at 4:18 AM Michael J Gruber  wrote:
>
> > On Thu, Jun 9, 2022 at 3:32 PM David Sommerseth  > wrote:
> >
> > I'm surprised that the EPEL 9 chroots haven't switched to RHEL 9 yet.
> > We've had RHEL 9 + EPEL 9 configs for almost a month now...
> >
> > Pavel, do you know when they're going to be deployed to COPR?
>
> Also, there seems to be a general problem (or caveat) here: Apparantly, COPR 
> uses Centos Stream X + EPEL X in the build root for EPEL X until RHEL X is 
> released. If it switches to RHEL X + EPEL X at that point then some packages 
> are moving "back", aren't they? IAW: What is the branch point for RHEL X(.0) 
> off Stream X? That seems to be the point from which the EPEL 9 copr should 
> follow RHEL X.${released} instead of Stream X (which prepares for X.$(( 
> ${released} + 1 ))).

Welcome to "CentOS Stream". The phase lag from Fedora to RHEL has been
tough enough, dealing with this sort of issue just makes it worse.

It's difficult to avoid this kind of incompatibility, and it's a
deliberate choice to destabilize CentOS and to reverse the RHEL/CentOS
stability relationship, deliberately compounded by discarding point
releases. It used to be possible to work builds from the point
releases. It's pretty clear that Red Hat uses some kind of point
release system internally, because when the "redhat-release" package
and the number listed in /etc/redhat-release and /etc/os-release gets
incremented, there is a flood of hundreds of new packages gets
released on the same day. I'm assuming that Red Hat uses the previous
point release and uses the "stream
" repos only when compelled, to avoid just such incompatible upgrades
breaking their build environments.

The CentOS machines could build from a local, stable snapshot of
CentOS, rather than using the current pieces. It's re-inventing the
wheel, re-inventing local point releases, and it's a pain to maintain.
But it's what some CentOS users feel compelled to do to avoid being
unannounced beta testers of new releases without warning. Or they're
switching to AlmaLinux, or Rocky Linux. Burning down both point
releases and reversing the update relationshp both so close together
has led to many companies expressing concern about RHEL and CentOS,
and disarding them in favor of Ubuntu.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Intent to retire containerd in EPEL 7 and co-maintainer request

[Nico Kadel-Garcia]

On Thu, Jun 9, 2022 at 6:55 PM Stewart Smith via devel
 wrote:
>
> Maxwell G via devel  writes:
> > Hi everyone,
> >
> > I have been de-facto maintaining containerd in Fedora as a member of the go-
> > sig for a little while now, as the previous maintainer no longer has time to
> > do. In addition to the Fedora branches, this package also exists on EPEL 7.
> > That branch has not been maintained for a while and has unpatched CVEs. I am
> > not interested in maintaining it myself, so unless someone steps up to
> > maintain it and fix the vulnerabilities, I will retire the package from 
> > EPEL 7
> > in a week from today, on June 15th.
>
> Specifically on this, I'd love to say that someone at Amazon could help
> here, especially considering we're not too distant from CentOS 7 for a
> bunch of Amazon Linux 2. Unfortunately I don't think we can given the
> likely packaging differences, the containerd version differences, and
> that we don't have infinite time and given a choice between EPEL7 work
> and jumping into modern Fedora packaging to enhance both Fedora and our
> Amazon Linux 2022 efforts, I'd pick the latter.

Backporting potent tools to RHEL 7 or CentOS 7 is often awkward. I've
run into it fullblast with Samba, and contmeporary releases of awscli
and ansible. The obsolete python is a problem, as is Amazon's decision
to use python 3.7 instead of python 3.6, making EPEL profounly
incompatible with it, and along with Red Hat's decision to package
python 3.6 as python3" and Amazon's decision to package python 3.7 as
python 3. Been there, done that, have the scar tissue. The default of
"python" as "python2.7" on CentOS 7 is now burdensome.

> > Additionally, I would appreciate co-maintainers to help with the Fedora
> > branches of containerd, its unbundled go dependencies, and moby-engine
> > (bundled go package). Long term, I'm not sure I'll have the time or the
> > interest to maintain these packages. Note that on EPEL 7, containerd bundles
> > its dependencies; moby-engine is not packaged there.
>
> This is 100% somewhere that Amazon Linux can step in and help with. We
> have a continued interest in the containerd ecosystem working in Fedora
> like distros (namely Amazon Linux), and the bundled/not-bundled split
> existing in some working bconds is certainly in our interest (we're
> likely to continue to bundle dependencies for the forseeable future).

I have repeatedly sent Amazon pointers to my tools for bundling awscli
for python 3, helped with an Amazon Linux 2 port of Samba a few years
ago, and *gave* them the tools to build a contemporary version of mock
on Amazon Linux 2. The silence was deafening. I'm afraid I was told
not to distract our sales engineer with these sorts of concerns, and
never actually got to the engineers who could or should to the actual
work. I found it disappointing.

> I'm going to go chat to some of the people internally who'd be doing the
> bulk of the work I'm just signing them up for, but would love to sync up
> on what our respective pain points are at some point soon.

If it's for server rather than local tools, you may simply wish to
discard RHEL 7 support of Fedora published tools. The dependency chain
can get quite painful. I was informed on the ansible bug list, for
example, that such packaging integration is not the developers' task.
It's the operating system distributor's problem. ansible.com was a
spinoff of Red Hat, and since Red Hat later purchased the company, it
seems much like calling the support line and getting steered back to
the same person you reached on your first, second, and third call.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

[Nico Kadel-Garcia]

On Sat, May 28, 2022 at 2:53 PM Vitaly Zaitsev via devel
 wrote:
>
> On 28/05/2022 19:31, drago01 wrote:
> > That's incorrect. They can be outdated, but there is no inherit reason
> > why they have to be.
>
> Most upstreams don't care about bundled libraries. They bundle them once
> and then forget.

Internally bundled libraries are an issue. I deal with it in the Samba
backports, enabling the Heimdal kerberos rather than Fedora and RHEL
built-in MIT Kerberos for better support from the Samba project. The
python s3transfer includes internal modules, as do the latest
ansible-core packages, and subversion has been a nightmare with SQLite
and other internal library dependencies on various platforms. It can
be quite difficult to keep them up to date.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fwd: ImageMagick in EPEL 8

[Nico Kadel-Garcia]

On Fri, May 27, 2022 at 3:01 PM Sérgio Basto  wrote:

> I'm going change this thread to epel-devel ,
>
> On Fri, 2022-05-27 at 11:40 -0700, Luya Tshimbalanga wrote:
>
> Shared message to address an issue below.
>
>
>  Forwarded Message 
> Subject: ImageMagick in EPEL 8
> Date: Wed, 25 May 2022 15:20:54 -0700
> From: Patrick J. LoPresti  
> To: l...@fedoraproject.org
>
> Hi. I just noticed that ImageMagick in EPEL for RHEL8 uses major version
> number 7, as in "libMagickWand-6.Q16.so.7".
>
> I have a number of binaries compiled for RHEL7 against ImageMagick, where
> the major number was 6, as in "libMagickWand-6.Q16.so.6". These binaries do
> not run on RHEL8 because of this major version mismatch.
>
>
Recompile them for RHEL 8. A *lot* of libraries changed. If you'd like
structure on how to do that sort of thing, look at my pretty potent setup
for ansible, at https://github.com/nkadel/ansiblerepo/ .


>
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What happened to umask?

[Nico Kadel-Garcia]

On Fri, May 20, 2022 at 9:08 PM Neal Gompa  wrote:
>
> On Fri, May 20, 2022 at 8:13 PM Owen Taylor  wrote:
> >
> > For years, Red Hat Linux / Fedora systems have had a umask of 0002 for 
> > regular users as part of the "user private group" scheme [*]. Basically the 
> > idea is that you can set a directory group-sticky and use it as a common 
> > work area for a group of users.
> >
> > A change a couple of years ago seems to have partially changed this - the 
> > code in /etc/profile was removed with the idea that it should be controlled 
> > by pam_umask / login.defs instead.
> >
> >  
> > https://pagure.io/setup/c/102b349c39e196cc1e34e645c9310acdab7afeef?branch=master
> >  https://bugzilla.redhat.com/show_bug.cgi?id=1722387
> >
> > However, the corresponding code in /etc/bashrc was left .This means that 
> > for a *login* shell (VT, ssh session, etc.) the umask is 0022 but for an 
> > interactive *non-login* shell (e.g., gnome-terminal with default settings) 
> > the umask stayed 0002.
> >
> > I'm not sure how much the change from 0002 to 0022 was thought through - 
> > that idea first appears in 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1722387#c4 with Tomas Mraz 
> > saying:  I do not think that the default umask should be 002 for regular 
> > users." - I would have expected a short change proposal, honestly.
> >
> > It seems like we need to do one of two things:
> >
> >  - Go back to the old behavior, maybe by using the usergroups option to 
> > pam_umask and removing the code from /etc/bashrc
> >  - Or just go fully to 0022 by removing the code from /etc/bashrc.
> >
> > What do people think? If the current situation has lasted for several 
> > years, it clearly isn't *that* much of a concern to most people :-)
> >
> > - Owen
> >
> > [*] 
> > https://docs.fedoraproject.org/en-US/fedora/latest/system-administrators-guide/basic-system-configuration/Managing_Users_and_Groups/#s2-users-groups-private-groups
> >
>
> I think we should complete the transition to 0022 umask. IIRC, this is
> how most Linux distributions have it work today, so we should fall in
> line here, unless there's a compelling reason not to.

This came up for me a few days ago. Some high security distributions
elect to set the umask to '077' by default, typically though a setting
in /etc/profile.d/, so that sharing with the group or with others
requires specific steps.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: How much free space in /var is required for upgrades?

[Nico Kadel-Garcia]

On Mon, May 16, 2022 at 2:55 PM Dusty Mabe  wrote:
>
>
>
> On 5/16/22 12:10, Chris Murphy wrote:
> > On Fri, May 13, 2022 at 3:20 PM przemek klosowski via devel
>
> >
> >
> >> Unfortunately, I believe that the current upgrade workflow requires a
> >> root disk three times the total installed package size: each package is
> >> there as the original version, the RPM of the upgrade in the cache
> >> directory, and as a new image before the old one is purged.
> >
> > Yeah I'm not sure it's currently possible to do an atomic update with
> > dnf or rpm, hence rpm-ostree. Or txnupd and btrfs snapshots
> > (essentially dnf and rpm keep doing what they're doing, but create a
> > snapshot of the running system, and update the snapshot out of band,
> > rather than stomping on the currently running OS).
>
> Exactly. This is one of the big value propositions of RPM-OSTree. Silverblue
> (desktop), Fedora CoreOS (Server), or Fedora IoT (Edge/IoT) are options here.
> If your "update" runs out of space for whatever reason then the upgrade is 
> stopped
> and you won't be in a half upgraded state.
>
> As Chris mentioned there are also things like BTRFS snapshots or LVM 
> snapshots,
> etc. that can help you go back in time.
>
> Dusty

If you have the spare time and disk to set up that sort of thing, you
have too much time on your hands and should focus on something useful
to more people, including yourself. It can be fun to outsmart yourself
with resource allocation, it's usually a form of "premature
optimization" that puts your systems at risk when you guess wrong. And
you *will* guess wrong at least once per project. From Donald Knuth:

 “The real problem is that programmers have spent far too much
time worrying about efficiency in the wrong places and at the wrong
times; premature optimization is the root of all evil (or at least
most of it) in programming.”
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: How much free space in /var is required for upgrades?

[Nico Kadel-Garcia]

On Mon, May 16, 2022 at 12:14 PM Chris Murphy  wrote:
>
> On Mon, May 16, 2022 at 8:07 AM Nico Kadel-Garcia  wrote:
> > An in-place system upgrade is not an "unexpected event". It is a risky
> > transaction.
> >
> > The big space pig is not /var/lib/rpm: it's /var/cache/dnf, which can
> > be quite flooded by updated packages  tool suites such as openoffice
> > or tetex. Another of my favorites for such in-place upgrades is to
> > take a package list before hand and delete such bulky suites, to
> > re-install them after the upgrade is complete.
>
> I wonder if it makes sense to advise users do a 'dnf clean packages'
> before starting a system upgrade? e.g. step 2.
>
> https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/

It's not as thorough as "dnf clean all --enablerepo=*' to catch
disabled repos, or "rm -rf /var/cache//dnf/*', or wherever the cache
is this week, but either way it's a risky proposition if other dnf
processes occur in that moment without a lock set up. This sort of
"let me work around one problem" creates other risks, and is why
running upgrades on live systems are so adventuresome.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: How much free space in /var is required for upgrades?

[Nico Kadel-Garcia]

On Mon, May 16, 2022 at 6:39 AM Panu Matilainen  wrote:
>
> On 5/13/22 21:54, Jason L Tibbitts III wrote:
> > So I went to do a dnf system-upgrade from F35 to F36 on a test machine,
> > as part of my usual testing.  In the middle of the process, it appears
> > that /var filled up and that left the system in an unfortunate state.
> > Surprisingly (to me) it did boot with a random mix of F35 and F36
> > packages and even though it's a throwaway test box, I wanted to play
> > around with fixing it a bit and trying to understand why it ran out of
> > space instead of just reinstalling.
> >
> > Turns out that "dnf --releasever 36 --nogpgcheck remove --duplicates"
> > was able to effectively everything in the system, and while running this
> > /var filled up again.  When that happened, dnf couldn't even be aborted;
> > I had to kill -9.  The culprit is the write-ahead log,
> > /var/lib/rpm/rpmdb.sqlite-wal.  I resized /var and reran, and by the end
> > of the process had grown to over 9GB:
> >
> > -rw-r--r--. 1 root root 9124576392 May 13 13:11 rpmdb.sqlite-wal
> >
> > Of course it immediately went to 0 once the transaction completed,
> > though rpmdb.sqlite went from:
> >
> > -rw-r--r--. 1 root root 281739264 May 11 14:24 rpmdb.sqlite
> >
> > to
> >
> > -rw-r--r--. 1 root root 730648576 May 13 13:15 rpmdb.sqlite
> >
> > which seems... odd for what's effectively just reinstalling the existing
> > package set.
> >
> > Anyway, obviously the solution is to make sure that /var is "big enough"
> > before you do a system upgrade.  And we do have warnings about
> > filesystems being too small, but nothing about needing an extra 10GB for
> > this.  Certainly my case might be somewhat pathological and it was good
> > that in the end I was able to get the system back into a useful state
> > without wiping it.  But in the end I wonder:
> >
> > 1) Is it really expected that the wal file will grow to that size?
>
> No.
>
> > 2) Is there anything to be done to reduce the size of the log?
>
> Yeah, such as reporting incidents like this.
>
> > 3) Is there any better way to handle a lack of space in /var during an
> > RPM transaction?
> >
> > 4) Can we estimate how large the file will grow, and refuse to start a
> > system upgrade if there is not enough space?  Certainly we already do
> > this to some degree, but it seems that the estimate of the required
> > space is a bit too small.
>
> Rpm has had a heuristic on the rpmdb growth for years, but no heuristics
> can help against unexpected events eating the space.

An in-place system upgrade is not an "unexpected event". It is a risky
transaction.

The big space pig is not /var/lib/rpm: it's /var/cache/dnf, which can
be quite flooded by updated packages  tool suites such as openoffice
or tetex. Another of my favorites for such in-place upgrades is to
take a package list before hand and delete such bulky suites, to
re-install them after the upgrade is complete.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: How much free space in /var is required for upgrades?

[Nico Kadel-Garcia]

Ooops: forgot the awk statement:

   dnf clean all --enablerepo=*
  dnf check-update | grep '^[a-zA-Z0-0]' | awk '{print $1}' |while
read name; do
dnf update "$name" -y
done

On Sat, May 14, 2022 at 8:35 AM Nico Kadel-Garcia  wrote:
>
> On Fri, May 13, 2022 at 2:54 PM Jason L Tibbitts III  wrote:
> >
> > So I went to do a dnf system-upgrade from F35 to F36 on a test machine,
> > as part of my usual testing.  In the middle of the process, it appears
> > that /var filled up and that left the system in an unfortunate state.
> > Surprisingly (to me) it did boot with a random mix of F35 and F36
> > packages and even though it's a throwaway test box, I wanted to play
> > around with fixing it a bit and trying to understand why it ran out of
> > space instead of just reinstalling.
>
> It can be a problem for bulky upgrades, and it's why I loathe the
> "let's make every partition as small as possible" approach to laying
> out disks. A look can help:
>
> dnf clean all --enablerepo=*
> dnf check-update | grep '^[a-zA-Z0-0]' | while read name; do
> dnf update "$name" -y
> done
>
> > Turns out that "dnf --releasever 36 --nogpgcheck remove --duplicates"
> > was able to effectively everything in the system, and while running this
> > /var filled up again.  When that happened, dnf couldn't even be aborted;
> > I had to kill -9.  The culprit is the write-ahead log,
> > /var/lib/rpm/rpmdb.sqlite-wal.  I resized /var and reran, and by the end
> > of the process had grown to over 9GB:
> >
> > -rw-r--r--. 1 root root 9124576392 May 13 13:11 rpmdb.sqlite-wal
> >
> > Of course it immediately went to 0 once the transaction completed,
> > though rpmdb.sqlite went from:
> >
> > -rw-r--r--. 1 root root 281739264 May 11 14:24 rpmdb.sqlite
> >
> > to
> >
> > -rw-r--r--. 1 root root 730648576 May 13 13:15 rpmdb.sqlite
> >
> > which seems... odd for what's effectively just reinstalling the existing
> > package set.
> >
> > Anyway, obviously the solution is to make sure that /var is "big enough"
> > before you do a system upgrade.  And we do have warnings about
> > filesystems being too small, but nothing about needing an extra 10GB for
> > this.  Certainly my case might be somewhat pathological and it was good
> > that in the end I was able to get the system back into a useful state
> > without wiping it.  But in the end I wonder:
>
> It's an unusual situation. /var/cache/ is one of the culprits for this
> kind of bulky upgrade.
>
> > 1) Is it really expected that the wal file will grow to that size?
> >
> > 2) Is there anything to be done to reduce the size of the log?
> >
> > 3) Is there any better way to handle a lack of space in /var during an
> > RPM transaction?
> >
> > 4) Can we estimate how large the file will grow, and refuse to start a
> > system upgrade if there is not enough space?  Certainly we already do
> > this to some degree, but it seems that the estimate of the required
> > space is a bit too small.
> >
> >  - J<
> > ___
> > 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
> > Do not reply to spam on the list, report it: 
> > https://pagure.io/fedora-infrastructure
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: How much free space in /var is required for upgrades?

[Nico Kadel-Garcia]

On Fri, May 13, 2022 at 2:54 PM Jason L Tibbitts III  wrote:
>
> So I went to do a dnf system-upgrade from F35 to F36 on a test machine,
> as part of my usual testing.  In the middle of the process, it appears
> that /var filled up and that left the system in an unfortunate state.
> Surprisingly (to me) it did boot with a random mix of F35 and F36
> packages and even though it's a throwaway test box, I wanted to play
> around with fixing it a bit and trying to understand why it ran out of
> space instead of just reinstalling.

It can be a problem for bulky upgrades, and it's why I loathe the
"let's make every partition as small as possible" approach to laying
out disks. A look can help:

dnf clean all --enablerepo=*
dnf check-update | grep '^[a-zA-Z0-0]' | while read name; do
dnf update "$name" -y
done

> Turns out that "dnf --releasever 36 --nogpgcheck remove --duplicates"
> was able to effectively everything in the system, and while running this
> /var filled up again.  When that happened, dnf couldn't even be aborted;
> I had to kill -9.  The culprit is the write-ahead log,
> /var/lib/rpm/rpmdb.sqlite-wal.  I resized /var and reran, and by the end
> of the process had grown to over 9GB:
>
> -rw-r--r--. 1 root root 9124576392 May 13 13:11 rpmdb.sqlite-wal
>
> Of course it immediately went to 0 once the transaction completed,
> though rpmdb.sqlite went from:
>
> -rw-r--r--. 1 root root 281739264 May 11 14:24 rpmdb.sqlite
>
> to
>
> -rw-r--r--. 1 root root 730648576 May 13 13:15 rpmdb.sqlite
>
> which seems... odd for what's effectively just reinstalling the existing
> package set.
>
> Anyway, obviously the solution is to make sure that /var is "big enough"
> before you do a system upgrade.  And we do have warnings about
> filesystems being too small, but nothing about needing an extra 10GB for
> this.  Certainly my case might be somewhat pathological and it was good
> that in the end I was able to get the system back into a useful state
> without wiping it.  But in the end I wonder:

It's an unusual situation. /var/cache/ is one of the culprits for this
kind of bulky upgrade.

> 1) Is it really expected that the wal file will grow to that size?
>
> 2) Is there anything to be done to reduce the size of the log?
>
> 3) Is there any better way to handle a lack of space in /var during an
> RPM transaction?
>
> 4) Can we estimate how large the file will grow, and refuse to start a
> system upgrade if there is not enough space?  Certainly we already do
> this to some degree, but it seems that the estimate of the required
> space is a bit too small.
>
>  - J<
> ___
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RHEL and CentOS specific Requires in spec file

[Nico Kadel-Garcia]

On Tue, May 10, 2022 at 12:28 PM Vitaly Zaitsev via devel
 wrote:
>
> On 10/05/2022 18:00, Ben Beasley wrote:
> > Could you please elaborate on why this form is better?
>
> For building on RHEL without EPEL being enabled.
>
> > At minimum, “%if 0%{?rhel} && 0%{?rhel} == 8” is exactly equivalent to
> > “%if 0%{?rhel} == 8”.
>
> Double checks are preferable, because "%if 0%{?rhel} < X" can easily
> break things.
>
> For example, on Fedora the %{?rhel} macro is not defined, so the
> condition 0%{?rhel} < 9 will be true because 0 is less than 9.

So what? If you're checking:

  %if 0%{?rhel} == 8

There's no need for the double check. If you were looking for RHEL <
8, yeah, it could make sense

  %if 0%{?rhel} && 0%{?rhel} < 8
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Ancient Puppet version in EPEL-7: remove it?

[Nico Kadel-Garcia]

On Thu, Apr 28, 2022 at 11:49 PM Neal Gompa  wrote:
>
> On Thu, Apr 28, 2022 at 11:38 PM Demi Marie Obenour
>  wrote:
> >
> > On 4/28/22 07:09, Nico Kadel-Garcia wrote:
> > > On Wed, Apr 27, 2022 at 9:08 PM Demi Marie Obenour
> > >  wrote:
> > >>
> > >> On 4/27/22 07:40, Ewoud Kohl van Wijngaarden wrote:
> > >>> On Tue, Apr 26, 2022 at 09:03:45PM -0500, Carl George wrote:
> > >>>> On Tue, Apr 26, 2022 at 1:25 PM Ewoud Kohl van Wijngaarden
> > >>>>  wrote:
> > >>>>>
> > >>>>> Hello everyone,
> > >>>>>
> > >>>>> There is an ancient version of Puppet in EPEL-7. Version 3.6 has been
> > >>>>> EOL for ages now. https://binford2k.com/2016/11/22/puppet-3.x-eol/ 
> > >>>>> has a
> > >>>>> nice EOL overview:
> > >>>>>
> > >>>>> * Puppet 3 - 2016-12-31
> > >>>>> * Puppet 4 - 2018-10-??
> > >>>>> * Puppet 5 - 2021-02-??
> > >>>>>
> > >>>>> Puppet 6 requires a newer Ruby version than is available in EL7 so
> > >>>>> rebasing the whole stack is not going to work. In theory you could use
> > >>>>> SCLs but I think it's unrealistic to expect that.
> > >>>>>
> > >>>>> However, all bugs open for Puppet relate to EPEL-7[1] so I'm wondering
> > >>>>> what to do.
> > >>>>>
> > >>>>> We can close all bugs as WONTFIX (including the security ones), but
> > >>>>> would it be better to also remove the package from EPEL-7?
> > >>>>>
> > >>>>> Regards,
> > >>>>> Ewoud Kohl van Wijngaarden
> > >>>>>
> > >>>>> [1]: 
> > >>>>> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=puppet_id=12574395=Fedora=Fedora%20EPEL
> > >>>>
> > >>>> Retiring epel7's puppet may be the preferred option.  It is allowed
> > >>>> [0], but if you go this route please mention it on the epel-devel list
> > >>>> (and perhaps epel-announce) first.
> > >>>
> > >>> I should have realized this, will bring it up there.
> > >>>
> > >>>> Alternatively, have you considered doing an incompatible update [1] to
> > >>>> version 5?  It may already be EOL, but surely that's a better option
> > >>>> than the current version 3 or removing it entirely.
> > >>>
> > >>> The Ruby version in EL7 is simply too old. In theory you could write a
> > >>> ton of patches to make it compatible again, but the Puppet modules users
> > >>> have may be assuming Ruby 2.4+ with Puppet 5. Also note that Puppet 5
> > >>> itself is already EOL (for more than a year), but packaging Puppet 6 vs
> > >>> Puppet 5 (or really, Puppet 7 as well) isn't a big difference: you need
> > >>> a newer Ruby. After that it's all minor differences.
> > >>>
> > >>>> [0] 
> > >>>> https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#what_can_be_retired
> > >>>> [1] 
> > >>>> https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
> > >>
> > >> Bundle a newer Ruby?
> > >
> > > RHEL 7 has published "software collection library" versions of ruby,
> > > titled "rh-ruby25".
> > >
> > > As somebody who's backported bulky software for RHEL based operating
> > > systems, like Samba and current ansible and airflow and yes, years
> > > ago, puppet, I don't recommend installing your own ruby. Resolving the
> > > dependencies gets painful, fast.
> >
> > In that case, I would be fine with saying, “if you need to run Puppet
> > on RHEL 7, do so in a container or VM based on a newer RHEL”.
> >
>
> Puppet is not very useful in a container. It's a systems management
> tool, so it's designed to manage the computer itself.

That did take a bit of giggling when I saw it.

"puppet-agent" is available, updated, from puppetlabs at
http://yum.puppetlabs.com/puppet/el/7/ . They even have a
"puppetlabs-release" repo to enable that repo in yum.

Maybe it's time to drop the obsolete EPEL version altogether? Or to
beg puppetlabs to publish an EPEL package themselves? I don't
currently have a subscription, so have little leverage with them these
days.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Ancient Puppet version in EPEL-7: remove it?

[Nico Kadel-Garcia]

On Wed, Apr 27, 2022 at 9:08 PM Demi Marie Obenour
 wrote:
>
> On 4/27/22 07:40, Ewoud Kohl van Wijngaarden wrote:
> > On Tue, Apr 26, 2022 at 09:03:45PM -0500, Carl George wrote:
> >> On Tue, Apr 26, 2022 at 1:25 PM Ewoud Kohl van Wijngaarden
> >>  wrote:
> >>>
> >>> Hello everyone,
> >>>
> >>> There is an ancient version of Puppet in EPEL-7. Version 3.6 has been
> >>> EOL for ages now. https://binford2k.com/2016/11/22/puppet-3.x-eol/ has a
> >>> nice EOL overview:
> >>>
> >>> * Puppet 3 - 2016-12-31
> >>> * Puppet 4 - 2018-10-??
> >>> * Puppet 5 - 2021-02-??
> >>>
> >>> Puppet 6 requires a newer Ruby version than is available in EL7 so
> >>> rebasing the whole stack is not going to work. In theory you could use
> >>> SCLs but I think it's unrealistic to expect that.
> >>>
> >>> However, all bugs open for Puppet relate to EPEL-7[1] so I'm wondering
> >>> what to do.
> >>>
> >>> We can close all bugs as WONTFIX (including the security ones), but
> >>> would it be better to also remove the package from EPEL-7?
> >>>
> >>> Regards,
> >>> Ewoud Kohl van Wijngaarden
> >>>
> >>> [1]: 
> >>> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=puppet_id=12574395=Fedora=Fedora%20EPEL
> >>
> >> Retiring epel7's puppet may be the preferred option.  It is allowed
> >> [0], but if you go this route please mention it on the epel-devel list
> >> (and perhaps epel-announce) first.
> >
> > I should have realized this, will bring it up there.
> >
> >> Alternatively, have you considered doing an incompatible update [1] to
> >> version 5?  It may already be EOL, but surely that's a better option
> >> than the current version 3 or removing it entirely.
> >
> > The Ruby version in EL7 is simply too old. In theory you could write a
> > ton of patches to make it compatible again, but the Puppet modules users
> > have may be assuming Ruby 2.4+ with Puppet 5. Also note that Puppet 5
> > itself is already EOL (for more than a year), but packaging Puppet 6 vs
> > Puppet 5 (or really, Puppet 7 as well) isn't a big difference: you need
> > a newer Ruby. After that it's all minor differences.
> >
> >> [0] 
> >> https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#what_can_be_retired
> >> [1] 
> >> https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
>
> Bundle a newer Ruby?

RHEL 7 has published "software collection library" versions of ruby,
titled "rh-ruby25".

As somebody who's backported bulky software for RHEL based operating
systems, like Samba and current ansible and airflow and yes, years
ago, puppet, I don't recommend installing your own ruby. Resolving the
dependencies gets painful, fast.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Ancient Puppet version in EPEL-7: remove it?

[Nico Kadel-Garcia]

On Tue, Apr 26, 2022 at 2:10 PM Ewoud Kohl van Wijngaarden
 wrote:
>
> Hello everyone,
>
> There is an ancient version of Puppet in EPEL-7. Version 3.6 has been
> EOL for ages now. https://binford2k.com/2016/11/22/puppet-3.x-eol/ has a
> nice EOL overview:
>
> * Puppet 3 - 2016-12-31
> * Puppet 4 - 2018-10-??
> * Puppet 5 - 2021-02-??
>
> Puppet 6 requires a newer Ruby version than is available in EL7 so
> rebasing the whole stack is not going to work. In theory you could use
> SCLs but I think it's unrealistic to expect that.

Rebuild it with the sco packages, namely rh-ruby25 ?

> However, all bugs open for Puppet relate to EPEL-7[1] so I'm wondering
> what to do.
>
> We can close all bugs as WONTFIX (including the security ones), but
> would it be better to also remove the package from EPEL-7?
>
> Regards,
> Ewoud Kohl van Wijngaarden
>
> [1]: 
> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=puppet_id=12574395=Fedora=Fedora%20EPEL
> ___
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Nico Kadel-Garcia]

On Thu, Mar 10, 2022 at 6:41 AM Paul Howarth  wrote:
>
> On Thu, 10 Mar 2022 12:26:54 +0100
> Vitaly Zaitsev via devel  wrote:
>
> > On 10/03/2022 11:55, Alex wrote:
> > > May I suggest to leave at least the telnet protocol in curl-minimal
> > > for debugging purposes.
> >
> > Telnet is an extremely vulnerable protocol. It must be disable.
> >
> > If you need it, you can always install libcurl-full.
>
> I wonder, do you have the "telnet" program installed on your machine(s)?

"netcat" or "nc" is a much better, more scriptable tool than telnet.
There is no reason for the telnet binary. And the telnet daemon,
itself, is profoundly deprecated.

> I'd be surprised if anyone using curl's telnet *client* support wasn't
> aware that it was sending plain text over the network, possibly
> including any credentials that were being used. A telnet client is,
> however, a very useful debugging tool for various other network
> protocols, not just the telnet protocol itself. That is, I believe,
> what Alex was advocating for, since the curl tool's presence is
> well-nigh universal and hence always available for debugging some
> network issues.

curl rather than netcat is simply not being aware of a better tool. Enjoy.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Orphaning deltarpm

[Nico Kadel-Garcia]

On Sun, Mar 6, 2022 at 8:51 AM Jonathan Dieter  wrote:
>
> Hi everyone,
>
> I'm orphaning deltarpm because, as it's currently used in Fedora, it's
> not very effective, bugs keep getting opened against it because it's
> not working as well as it should (mostly an infra issue as opposed to a
> problem with the tool itself), and I no longer have the time or
> motivation to deal with these tickets when it seems like there's not
> much benefit.

I have always disliked deltarpms. They expand the size of the
frequently downloaded metadata with little overall benefit.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retire openCOLLADA?

[Nico Kadel-Garcia]

"uninitalized variables" is generally easy to fix in the source code.
Has the author dropped the project, the last update in the github repo
is frm at least 3 years ago.

On Sat, Jan 29, 2022 at 4:28 PM Richard Shaw  wrote:
>
> It seems to fail with gcc 12 due to uninitialized variables. That's easy 
> enough to work around but the last release was in 2018 and the only consumer 
> in Fedora in Blender.
>
> Maybe it's time to retire it?
>
> I would hate that as it's actually my first package...
>
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: is there an offshoot or branch of early Fedora for simple UI

[Nico Kadel-Garcia]

On Sun, Jan 9, 2022 at 6:58 PM Peter Boy  wrote:
>
>
>
> > Am 10.01.2022 um 00:25 schrieb Nico Kadel-Garcia :
> >
> > ... it has gotten out of hand.
>
> Indeed. When Gnome 3 hit Fedora years ago, I tried hard, but then decided 
> heavy heartedly to switch all my desktops and laptops to macOS. It has 
> remained that way until today. But I’m happy with Fedora Server for all our 
> servers. There is no window at all :-)
>
> > Is it worth trying to
> > bring back "tvtwm", as an even lighter andmore stable window manager
> > with very good hooks for managing multiple virtual windows?
>
> Taking the physical screen as a viewport onto a much larger, continuous 
> virtual screen is a very interesting idea. But if I understand the Wikipedia 
> article correctly, the number of users is currently very small. A port is 
> probably not very likely. But really a nice idea. Didn’t know that one.

I used it last year. It's *really, really* stable.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: is there an offshoot or branch of early Fedora for simple UI

[Nico Kadel-Garcia]

On Sun, Jan 9, 2022 at 6:02 PM Peter Boy  wrote:

> > Am 09.01.2022 um 23:43 schrieb None Business :
> >
> > I use(d) fedora to run my IDEs ( c++), now it is all floating-contracting 
> > windows , with gazilion 'drag-your-window' nonsense . I guess I am not cool 
> > enough to use this clusterfu..k, it is simply unusable for me , so I am 
> > looking for something that looks like early Fedora  to simplify my 
> > development . Is there Fedora offshoot with a sane UI ?
> > ___
>
>
> Apart from the fact that your style is not particularly respectful and 
> cooperative, others can't get along with the Gnome interface either. They 
> have developed alternatives, which now also work very stable and reliable. 
> Check out https://spins.fedoraproject.org/. There you will find more 
> "traditional" desktops, e.g. Mate or Cinnamon.
>
> You can install the desktops parallel to your current Gnome and try them out. 
> So you don't need to reinstall.

Crudities aside, it has gotten out of hand. Is it worth trying to
bring back "tvtwm", as an even lighter andmore stable window manager
with very good hooks for managing multiple virtual windows?
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

[Nico Kadel-Garcia]

That addresses my concern. I'd assumed that it would occur as part of
an RPM update, rather than as a triggered out of band event. It makes
rebooting mandatory and slightly risky, especially if /usr overflows
halfway through, the process, but that becomes far, far less likely
with systemd doing it at boot time running at the same time other RPM
updates. I do hope the scripting will exit gracefully if /usr
overflows or is unwriteable for other reasons, such as being part of
the "immutable" Linux concept.

Nico Kadel-Garcia

On Sat, Jan 8, 2022 at 8:30 PM Chris Murphy  wrote:
>
> On Sat, Jan 8, 2022 at 6:07 PM Nico Kadel-Garcia  wrote:
> >
> > On Sat, Jan 8, 2022 at 7:53 PM Chris Murphy  wrote:
> > >
> > > On Sat, Jan 8, 2022 at 7:53 AM Fabio Valentini  
> > > wrote:
> > > >
> > > > On Sat, Jan 8, 2022 at 3:39 PM Neal Gompa  wrote:
> > > > >
> > > > > On Sat, Jan 8, 2022 at 8:58 AM Fabio Valentini  
> > > > > wrote:
> > > > > >
> > > > > > On Wed, Dec 29, 2021 at 4:03 PM Ben Cotton  
> > > > > > wrote:
> > > > > > >
> > > > > >
> > > > > > (snip)
> > > > > >
> > > > > > >
> > > > > > > == Detailed Description ==
> > > > > > > === Current location ===
> > > > > > > /var/lib/rpm
> > > > > > >
> > > > > > > === New location ===
> > > > > > > /usr/lib/sysimage/rpm
> > > > > > >
> > > > > > > /var/lib/rpm will be a symlink pointing to
> > > > > > > /usr/lib/sysimage/rpm
> > > > > >
> > > > > > I did not find a mention of this in the thread or in the Change
> > > > > > proposal, so I'll ask:
> > > > > > How do you plan to handle the directory -> symlink replacement on 
> > > > > > upgrade?
> > > > > >
> > > > > > As far as I can tell, those always required special treatment via
> > > > > > %pretrans scriptlets or something, and even the method currently
> > > > > > recommended by the Packaging Guidelines seems to be broken due to 
> > > > > > the
> > > > > > way dnf / RPM verifies validity of transactions.
> > > > > >
> > > > > > Additionally, that "special" handling will probably need to stay in
> > > > > > the RPM package's .spec file for years, given that upgrades from
> > > > > > Fedora 34 to 36 will need to be supported.
> > > > > >
> > > > >
> > > > > This is documented in the Change:
> > > > > https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr#Upgrade.2Fcompatibility_impact
> > > > >
> > > > > The part that's probably missing there is that the upgraded package
> > > > > will release ownership of /var/lib/rpm and own the
> > > > > /usr/lib/sysimage/rpm directory.
> > > > >
> > > > > The configuration will change in the upgrade, and then an rpmdb
> > > > > rebuild on reboot will finalize the transition, as rpmdb rebuilds are
> > > > > done by loading the rpmdb in memory, renaming the directory,
> > > > > recreating it, and re-initializing the database files from memory.
> > > > >
> > > > > This avoids the pitfalls you've described with the pretrans stuff.
> > > >
> > > > Oh, great. Looks like I'm ~tired~ and missed that this is in the
> > > > Change proposal after all ...
> > > > Thanks for confirming that you found a way to handle upgrades.
> > >
> > > I did a manual proof of concept with the pseudo-sequence in the change
> > > proposal on a Fedora Rawhide VM. And it did work, and continues to do
> > > both GNOME Software and dnf updates OK. This is a sample size of 1, so
> > > there's more work to do to make sure it can be done safely, using the
> > > rpm sqlite upgrade as a guide. But I can write up the steps I used, so
> > > that anyone can test before we have it wired up.
> > >
> > > We have considered not applying the change to upgrades. Strictly
> > > speaking the release criterion say we only support upgrades from
> > > *clean installs* of the current two releases. But in practice quite a
> > > lot of users depend on reliable upgrades for *many* releases, and they
> > > get mad

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

[Nico Kadel-Garcia]

On Sat, Jan 8, 2022 at 7:53 PM Chris Murphy  wrote:
>
> On Sat, Jan 8, 2022 at 7:53 AM Fabio Valentini  wrote:
> >
> > On Sat, Jan 8, 2022 at 3:39 PM Neal Gompa  wrote:
> > >
> > > On Sat, Jan 8, 2022 at 8:58 AM Fabio Valentini  
> > > wrote:
> > > >
> > > > On Wed, Dec 29, 2021 at 4:03 PM Ben Cotton  wrote:
> > > > >
> > > >
> > > > (snip)
> > > >
> > > > >
> > > > > == Detailed Description ==
> > > > > === Current location ===
> > > > > /var/lib/rpm
> > > > >
> > > > > === New location ===
> > > > > /usr/lib/sysimage/rpm
> > > > >
> > > > > /var/lib/rpm will be a symlink pointing to
> > > > > /usr/lib/sysimage/rpm
> > > >
> > > > I did not find a mention of this in the thread or in the Change
> > > > proposal, so I'll ask:
> > > > How do you plan to handle the directory -> symlink replacement on 
> > > > upgrade?
> > > >
> > > > As far as I can tell, those always required special treatment via
> > > > %pretrans scriptlets or something, and even the method currently
> > > > recommended by the Packaging Guidelines seems to be broken due to the
> > > > way dnf / RPM verifies validity of transactions.
> > > >
> > > > Additionally, that "special" handling will probably need to stay in
> > > > the RPM package's .spec file for years, given that upgrades from
> > > > Fedora 34 to 36 will need to be supported.
> > > >
> > >
> > > This is documented in the Change:
> > > https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr#Upgrade.2Fcompatibility_impact
> > >
> > > The part that's probably missing there is that the upgraded package
> > > will release ownership of /var/lib/rpm and own the
> > > /usr/lib/sysimage/rpm directory.
> > >
> > > The configuration will change in the upgrade, and then an rpmdb
> > > rebuild on reboot will finalize the transition, as rpmdb rebuilds are
> > > done by loading the rpmdb in memory, renaming the directory,
> > > recreating it, and re-initializing the database files from memory.
> > >
> > > This avoids the pitfalls you've described with the pretrans stuff.
> >
> > Oh, great. Looks like I'm ~tired~ and missed that this is in the
> > Change proposal after all ...
> > Thanks for confirming that you found a way to handle upgrades.
>
> I did a manual proof of concept with the pseudo-sequence in the change
> proposal on a Fedora Rawhide VM. And it did work, and continues to do
> both GNOME Software and dnf updates OK. This is a sample size of 1, so
> there's more work to do to make sure it can be done safely, using the
> rpm sqlite upgrade as a guide. But I can write up the steps I used, so
> that anyone can test before we have it wired up.
>
> We have considered not applying the change to upgrades. Strictly
> speaking the release criterion say we only support upgrades from
> *clean installs* of the current two releases. But in practice quite a
> lot of users depend on reliable upgrades for *many* releases, and they
> get mad when things break even when it's been 10+ releases since they
> did a clean install. And also, Workstation edition PRD  "upgrade
> process should give a result that is the same as an original install".
> That is a tall order, but so long as it's safe, it's probably better
> to apply this change to upgrades. If we run into issues or establish
> the risk is too high, it's not such a big deal to apply the change to
> only new clean installs.

I'm personally concerned that the RPM transactions may not be handled
atomically if the /var/lib/rpm/ is migrated in the midst of an RPM
update. I'm not personally sure if RPM and Berkeley DB will handle
that correctly if there's any issues with the migration, particularly
if /usr/ overflows in the process of other bulky updates such as
libreoffice. Part of my work involves looking for where multiple
things can go wrong at once.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Is it okay to use /usr/bin/python again?

[Nico Kadel-Garcia]

On Wed, Jan 5, 2022 at 2:34 AM Vitaly Zaitsev via devel
 wrote:
>
> On 04/01/2022 19:36, Nico Kadel-Garcia wrote:
> > #!/usr/bin/env python3
>
> Forbidden by Python guidelines too.

Can you point to where that is forbidden? Because it remains quite
popular for various working environments with multiple python
releases, such as RHEL 7 supported through EPEL.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Is it okay to use /usr/bin/python again?

[Nico Kadel-Garcia]

On Tue, Jan 4, 2022 at 8:11 AM Miro Hrončok  wrote:
>
> On 04. 01. 22 13:57, Vitaly Zaitsev via devel wrote:
> > On 04/01/2022 11:09, Florian Weimer wrote:
> >> We have some scripts that are dual Python 2/Python 3, and Fedora tooling
> >> forced us to carry a downstream-only patch to replace /usr/bin/python
> >> with /usr/bin/python3.  I'd like to remove this patch.
> >
> > It is forbidden.
> >
> > You should switch your SPEC to modern 201x-era guidelines
>
> 202x-era
>
> > and all shebangs will
> > be handled automatically with the %pyproject_install macro.
>
> That is only happening for files installed to /usr/bin, not to files you use
> during builds.

It confuses the heck out of building Fedora. "/ur/bin/python" may not
be python3 on a remote system, especially a legacy system. Please,
explicitly use "#!/usr/bin/python3" or "#!/usr/bin/env python3".
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: DIGLIM (System-Wide Change proposal)

[Nico Kadel-Garcia]

On Fri, Dec 31, 2021 at 3:32 AM Vitaly Zaitsev via devel
 wrote:
>
> On 30/12/2021 12:58, Roberto Sassu wrote:
> > This has not been decided yet, but likely the Fedora kernel will
> > contain the official Fedora keys, and the user will decide to add
> > new keys (including those from COPR).
>
> 1. What about self-built RPMs? I always build RPMs in mock and test them
> locally before submitting them to Koji as Fedora updates.

Sounds like, if this is enabled, they'll need a GPG key associated
with their personal repository.

> 2. Such keys must be added/removed automatically with the corresponding
> COPR repositories.

Key management is one of the reasons GPG validation od deployed
software has never really taken off.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

[Nico Kadel-Garcia]

On Wed, Dec 29, 2021 at 3:36 PM Stephen John Smoogen  wrote:
>
>
>
> On Wed, 29 Dec 2021 at 13:51, Gordon Messmer  wrote:
>>
>> On 12/29/21 09:59, Stephen John Smoogen wrote:
>> > The modern day case where /usr is read-only is inside a container and
>> > you put an overlay or using some sort of linking to /var which is
>> > read-write in case of reboots.
>>
>>
>> Right, that makes sense.
>>
>>
>> > To me this is like saying 'move everything into /usr but because its
>> > volitile move it back into /var but in a sub-directory from where it
>> > was so you can keep an image running.' In this case, this doesn't
>> > sound like any savings and more of a headache of why did it corrupt
>> > this time.
>>
>>
>> But this doesn't.  Why would you need to move the rpmdb?  Users probably
>> aren't installing rpm packages in containers at run time (particularly
>> if /usr is read-only); installation typically happens when building the
>> container image, at which point /usr isn't read-only.
>>
> Most of the containers I am dealing with are
> Grab the base image,
> Create a layer, and add the images you want,
> Test and deploy the layered image.
> Update that image over time.
>
> Theoretically people should build the thing from scratch every time but 
> instead you get someone downloading the base image which they have gotten an 
> OK to use, then adding the stuff they need, and then running with that for 
> YEARS because the person who built the first one left long ago and no one 
> wants to break the paycheck program again.

This is a very, very old problem: I was dealing with it with OS images
20 years ago.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

[Nico Kadel-Garcia]

On Wed, Dec 29, 2021 at 12:48 PM Gordon Messmer
 wrote:
>
> On 12/29/21 07:26, Vitaly Zaitsev via devel wrote:
> > On 29/12/2021 16:01, Ben Cotton wrote:
> >> Currently, the RPM databases is located in `/var`. Let's move it to
> >> `/usr`. The move is already under way in rpm-ostree-based
> >> installations, and in (open)SUSE.
> >
> > It will break FHS compatibility. /usr must contain read-only data.
>
>
> If /usr really is read-only, then it probably doesn't matter where the
> rpmdb is, since packages can't be installed (generally).

There are plenty of packages which do not write to /usr/, especially
third party add-ons over in /opt/ .
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: DIGLIM (System-Wide Change proposal)

[Nico Kadel-Garcia]

On Wed, Dec 29, 2021 at 1:35 PM Neal Gompa  wrote:
>
> On Wed, Dec 29, 2021 at 11:03 AM Stephen Snow  wrote:
> >
> > On Wed, 2021-12-29 at 06:38 -0500, Neal Gompa wrote:
> > > With Windows 11, they're *mandatory*. Corporate policies now
> > > effectively *require* TPM-based mechanisms *in addition* to classical
> > > password or token-based multi-factor authentication.
> > This certainly is not any reason to adopt this for Fedora. So far in my
> > life with TPM, it has been an annoyance that I find refreshing not to
> > have to even contemplate with my Fedora Linux installation.
> > I see no benefit for the Fedora Community and the Fedora Project it
> > supports to follow the lead of the proprietary driven objectives. The
> > only obvious one that comes to mind is the recent announcements of it's
> > inclusion on traditionally proprietary OS vendor supplied hardware.
> > This wreaks of "for profit" motivation.
> >
> > Just my opinion on what I am reading here in the comments.
>
> To be fully transparent, the reason I mentioned that stuff is that
> having the capability to do these things in Fedora Linux is key for
> growth and adoption in more circles. At no point do I want to have
> these features implemented in such a way that the user doesn't have
> the capability to control and self-authenticate their whole system. If
> we ever want Fedora Linux to displace Windows or macOS, we *need* to
> be able to satisfy people's security requirements, including so-called
> "zero trust" architectures.
>
> But none of that has much to do with this Change, since this is about
> making it possible for a user to configure their system to enforce the
> integrity of the system based on RPM database information. As users of
> Fedora Linux systems, we *already* control the RPM database and the
> RPM signature trust directly, so *if* you turn it on, all it does is
> decrease the risk of external tampering.

I'm staring at the introduction letter at:
https://lore.kernel.org/linux-integrity/20210914163401.864635-1-roberto.sa...@huawei.com/
RPM headers are a *possible* use. I'd expect this to be used, very
quickly, for other signed metadata for less benign uses.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: DIGLIM (System-Wide Change proposal)

[Nico Kadel-Garcia]

On Wed, Dec 29, 2021 at 6:39 AM Neal Gompa  wrote:
>
> On Wed, Dec 29, 2021 at 6:06 AM Nico Kadel-Garcia  wrote:
> >
> > On Wed, Dec 29, 2021 at 5:42 AM Roberto Sassu via devel
> >  wrote:
> > >
> > > > From: Nico Kadel-Garcia [mailto:nka...@gmail.com]
> > > > Sent: Wednesday, December 29, 2021 10:29 AM
> > >
> > > [...]
> > >
> > > > From one of the patches:
> > > >
> > > >  It accomplishes this task by storing reference values coming from
> > > > software vendors and by reporting whether or not the
> > > > digest of file content or metadata calculated by IMA (or EVM) is found
> > > > among those values.
> > > >
> > > > That has no use but digital rights management.
> > >
> > > Hi Nico
> > >
> > > I give some clarifications.
> >
> > You've been very clear. To wit:
> >
> > > This applies if you want to enforce an IMA appraisal policy,
> > > which denies access to the files if file verification fails. I
> >
> > That is also spelled "DRM", The idea that only code approved by a
> > third party is permitted access to specific files violates the core
> > principles of "free software". Putting the code in the kernel makes it
> > more awkward for ordinary users to access the data and software on
> > their own computers.
> >
> > > This will be possible because you will have the ability to load
> > > your own GPG (or RSA) keys to the kernel to verify data source
> > > authenticity of the digest lists.
> >
> > There is no need to do this in the kernel. It can happen in userland.
> >
> > > This applies if you want to enforce an IMA appraisal policy,
> > > which denies access to the files if file verification fails. If you
> >
> > Replace the word "IMA" with DRM everywhere to understand the end goal
> > of such features. I'm sorry if I seem a bit vehement about this. We
> > saw this attempted with Palladium or "Trusted Computing" for boot
> > loaders, and it wasted a lot of time for features that were defeated
> > pretty easily in the end by virtualization.
>
> Were they really? TPM devices *are* commonly used today to support
> attestation and multi-factor encryption and authentication mechanisms.
> In many ways, the trusted computing initiative was a success. And even
> virtualization is used for implementing trusted computing in some
> platforms.
>
> With Windows 11, they're *mandatory*. Corporate policies now
> effectively *require* TPM-based mechanisms *in addition* to classical
> password or token-based multi-factor authentication.

As often occurs with DRM. it's proven burdensome and there are
numerous published workarounds, including those published by
Microsoft.

Can you point to a particular multi-factor authentication technology
that uses TPM? I'd not seen that in any server based setups, though I
could believe it exists for portable devices which support less
development. It's a problem partly because TPM puts private escrow
keys in the centralized hands, and the root keys to revoke other keys
in manufacturer's hands. The key management, and signature authority
management, is a problem. I'd be concerned at yet another attempt to
re-invent the security wheel, and secrete the wheel itself away in the
kernel without direct visibility to the user running or writing the
software.

> The difference between IMA/verity and DRM is that the former is under
> the system owner's control (in this case, *you*), and the latter is
> *not*.

Since IMA is oriented to third party vendor keys, according to its own
documentation, I don't see how this would be. It would be easier, and
more visible, for signature validation and verification to occur in
userspace. There are old tools that attempted to provide such
validation for system files, such as "chkrootkit". and for which I've
provided up-to-date bundling.

The work of signing and validating one's own data or software files is
so large, I don't see the benefit of embedding it in the kernel except
to enforce it for DRM use.

> While Palladium as a whole hasn't *yet* made it, huge chunks of it
> has. Verified and measured boot mechanisms exist in Windows and macOS,
> remote and local attestation for integrity exist for Windows, and so
> on. Some of these features exist in Linux, but not all just yet.

Nor should they, precisely for "free software" reasons. Palladium was
an attempt to provide a hardware verified, vendor signed stack from
boot to kernel to software to data files, all under the authority of
third-party generated signatures which could be revoked, at whim, 

Re: F36 Change: DIGLIM (System-Wide Change proposal)

[Nico Kadel-Garcia]

On Wed, Dec 29, 2021 at 5:42 AM Roberto Sassu via devel
 wrote:
>
> > From: Nico Kadel-Garcia [mailto:nka...@gmail.com]
> > Sent: Wednesday, December 29, 2021 10:29 AM
>
> [...]
>
> > From one of the patches:
> >
> >  It accomplishes this task by storing reference values coming from
> > software vendors and by reporting whether or not the
> > digest of file content or metadata calculated by IMA (or EVM) is found
> > among those values.
> >
> > That has no use but digital rights management.
>
> Hi Nico
>
> I give some clarifications.

You've been very clear. To wit:

> This applies if you want to enforce an IMA appraisal policy,
> which denies access to the files if file verification fails. I

That is also spelled "DRM", The idea that only code approved by a
third party is permitted access to specific files violates the core
principles of "free software". Putting the code in the kernel makes it
more awkward for ordinary users to access the data and software on
their own computers.

> This will be possible because you will have the ability to load
> your own GPG (or RSA) keys to the kernel to verify data source
> authenticity of the digest lists.

There is no need to do this in the kernel. It can happen in userland.

> This applies if you want to enforce an IMA appraisal policy,
> which denies access to the files if file verification fails. If you

Replace the word "IMA" with DRM everywhere to understand the end goal
of such features. I'm sorry if I seem a bit vehement about this. We
saw this attempted with Palladium or "Trusted Computing" for boot
loaders, and it wasted a lot of time for features that were defeated
pretty easily in the end by virtualization.

> want to enforce an IMA measurement policy instead, access
> to the files will be always granted, regardless of whether
> the digest lists are signed or not. IMA, in this case, will simply
> record the execution of unknown files, in addition to the
> digest lists you generated.
>
> The IMA measurement list remains in your system, unless
> you decide that your system should be remotely attested
> by a remote verifier.
>
> Roberto
>
> HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
> Managing Director: Li Peng, Zhong Ronghua
> ___
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: DIGLIM (System-Wide Change proposal)

[Nico Kadel-Garcia]

On Tue, Dec 28, 2021 at 8:07 PM Samuel Sieb  wrote:
>
> On 12/28/21 16:45, Nico Kadel-Garcia wrote:
> > On Tue, Dec 28, 2021 at 4:35 AM Mattia Verga via devel
> >  wrote:
> >>
> >> Il 28/12/21 04:28, Kevin Kofler via devel ha scritto:
> >>> But even off by default, I do not see how the "feature" implemented by 
> >>> this
> >>> Change provides any value at all that does not contradict the very
> >>> definition of Free Software.
> >>>
> >>>   Kevin Kofler
> >>
> >> I do not see how this change goes against the definition of Free
> >> Software. It doesn't deny a user to install any software they want, it
> >> is about preventing unwanted/unsolicited/malevolent software from being
> >> installed without user (admin) approval.
> >
> > This looks like pure DRM. While there are security benefits to
> > controlling access to data or to executables, doing so deep in the
> > kernel takes away too much desirable freedom.
>
> How is this taking away any freedom?  You, as the owner of the computer,
> are free to enable or disable or reconfigure this security system as you
> please.  No one is forcing you to use it.  Why is it bad that it's
> implemented in the kernel?  If it wasn't, it probably wouldn't be very
> useful.

From one of the patches:

 It accomplishes this task by storing reference values coming from
software vendors and by reporting whether or not the
digest of file content or metadata calculated by IMA (or EVM) is found
among those values.

That has no use but digital rights management.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: DIGLIM (System-Wide Change proposal)

[Nico Kadel-Garcia]

On Tue, Dec 28, 2021 at 4:35 AM Mattia Verga via devel
 wrote:
>
> Il 28/12/21 04:28, Kevin Kofler via devel ha scritto:
> > Matthew Miller wrote:
> >> 1. There is a mechanism for users to add their own digest lists, if they
> >> want. The change proposal could be a little more clear on how this
> >> would work.
> > There is no way I am going to jump through hoops to whitelist software I
> > compiled myself, or installed from a third-party repository, out of a
> > hardware-enforced vendor lock-in that attempts to deny me Freedom Zero
> > (contradicting the "Freedom" in the "Four F's" of Fedora).
> >
> >> 2. The proposal calls for a checkbox in Anaconda to enable the feature.
> >> (We probably do not actually want a checkbox in Anaconda, though.) It
> >> also says "The feature might be enabled later by the user without any
> >> change required for the image generation" — which I think is primarily
> >> saying that the feature could be turned on without needing to remake
> >> the boot image, but which also seems to also say that it's not
> >> necessarily on by default.
> > Hopefully really only *by the user* and not, e.g., by the upgrade to a newer
> > Fedora release.
> >
> > But even off by default, I do not see how the "feature" implemented by this
> > Change provides any value at all that does not contradict the very
> > definition of Free Software.
> >
> >  Kevin Kofler
>
> I do not see how this change goes against the definition of Free
> Software. It doesn't deny a user to install any software they want, it
> is about preventing unwanted/unsolicited/malevolent software from being
> installed without user (admin) approval.

This looks like pure DRM. While there are security benefits to
controlling access to data or to executables, doing so deep in the
kernel takes away too much desirable freedom.

Nico Kadel-Garcia
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: DIGLIM (System-Wide Change proposal)

[Nico Kadel-Garcia]

On Sun, Dec 26, 2021 at 1:10 AM Dan Čermák
 wrote:
>
> Ben Cotton  writes:
>
> *snip*
>
> >
> > It will also make Fedora able to detect tampering of its components at
> > a more privileged level, the kernel, without the interference of user
> > space programs. Once tampering has been detected, the actions of the
> > altered component are prevented before that component gets the chance
> > to perform any action. Fedora could be configured to also allow the
> > usage of components provided by the user, if he wishes to do so
> > (DIGLIM has a tool to build custom digest lists).
>
> How would that look in practice? Will a user just get a message in the
> journal?
>
> > == Upgrade/compatibility impact ==
> > The user should ensure that software (not updated) from the old
> > distribution is packaged and the package header is signed, or he
> > should create and sign a custom digest list for the software he wishes
> > to use after the upgrade.
>
> Uhm, so locally/manually installed software (i.e. not signed by Fedora's
> signkeys) will silently break when switching to F36? How about 3rd party
> repositories?

It wouldn't be the first time software has been deliberately broken by
well-intended kernel security changes. Remember when systemd decided
to cancel all backgrounded processes belong to a user when they logged
out, breaking "screen" and "tux", with no record of killing the jobs
whatsover? Fortunately, people screamed pretty hard about that one.

Nico Kadel-Garcia

> Cheers,
>
> Dan
> ___
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Is it possible to find out which packages were used when building the package?

[Nico Kadel-Garcia]

On Sat, Dec 18, 2021 at 4:38 PM Mikhail Gavrilov
 wrote:
>
> Thanks, for answer. I build every day rpm packages from git locally with 
> mock. And every build erases the contents of the `/var/lib/mock`. I did not 
> save build log and I suppose that the rpm package itself does not contain 
> information about what versions of packages was used for build.

It might  be more efficient to run a shell command in your build
environment to review /var/log/dnf.log, even in a "mock" build
environment, rather than trying to parse out the dependencies directly
b reading the RPM or the .spec file.  It can be a real adventure to
resolve all the dependencies on dependencies on dependencies,
especially for a complex python based package.

RPM and yum also do not prove a package was actually used, merely that
it was managed as a build requirement.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Mock v2.16 release, mock-core-configs v36.4

[Nico Kadel-Garcia]

I see there is a more specific thread where just these issues have
been discussed. I'll take this over to
https://github.com/rpm-software-management/mock/issues/755 . to avoid
cluttering a general Fedora maliling list.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: About how Go is updated in Fedora

[Nico Kadel-Garcia]

On Sat, Dec 18, 2021 at 3:35 AM Alejandro Saez Morollon  wrote:
>
>
>
> On Tue, Dec 14, 2021 at 5:01 AM Matthew Miller  
> wrote:
>>
>> On Mon, Dec 13, 2021 at 02:22:24PM +0100, Alejandro Saez Morollon wrote:
>> > A hypothetical new release cycle would look like this:
>> >
>> >- Fedora N release follows Go upstream as close as we can.
>> >- Fedora N-1 sticks with the latest major version of Go that was
>> >available on it until the release of Fedora N.
>> >
>> >
>> > Another hypothetical approach could be using modules with each upstream
>> > supported release in a stream.
>>
>> This seems like the thing Modularity was invented to do, and would have the
>> advantage of being able to be consistent across a release with a
>> "baseline" version but also provide options.
>>
>
> But AFAIK, only users can select a module stream, right? I mean, packages 
> can't be build on top of a module stream
> so new needs of package maintainers cannot be satisfy with modules.
>
> I'm curious about how other SIGs deal with these scenarios...

I can't think of anyone I know personally who actually uses
"modularity" since its introduction, As Zathros said in the old
Babylon Five episode "this is wrong tool!"
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Mock v2.16 release, mock-core-configs v36.4

[Nico Kadel-Garcia]

On Sat, Dec 18, 2021 at 6:14 PM Miroslav Suchý  wrote:
>
> Dne 18. 12. 21 v 22:09 Nico Kadel-Garcia napsal(a):
> > Discarding RHEL 7 and CentOS 7  for
> > EPEL, and by implication Amazon Linux 2,  will discourage people
> > further from using RHEL based releases at all, I'd not consider it an
> > encouragement to switch to RHEL 8. Commercial users are avoiding
> > CentOS 8.  Discarding EPEL 7 is salting the earth for existing users
> > of RHEL 7 and CentOS 7.
>
> 
>
> No one is discarding RHEL/CentOS.  Mock will stay there. No one is going to 
> delete it.

I'm afraid that "no one" is perhaps overstated. Various companies are
discarding CentOS since the CentOS 8 Stream fiasco, and questioning
their use of RHEL or CentOS at all. I've had several interviews lately
included evaluating the company use of RHEL/CentOS after their seeing
various issues with CentOS 8, more properly described in the CentOS
mailing lists. I'm a big uer of mock for multi-platform compilation,
I'd like to be able to use whichever build host in whatever standard
build server I get to work with.

For mock v3, that's not how I read your quote:

> Mock v3 will be available for EPEL 8+ and Fedora. We are deliberately
> removing RHEL 7 host support from Mock in Mock v3, so it won't be
> available in EPEL 7. Mock v2 will remain in EPEL 7.

EPEL typically deletes old versions of software when new releases are
published though perhaps not if the new version is simply never
backported to the old OS, I'd expect an unsupported mock v2 to go the
way o the dodo when v3 is released, even if it is only released for
RHEL 8 compatible EPEL and for Fedora.

The statement sounds at first glance like even building for CentOS 7
and RHEL 7 is being discarded from mock v3. If you're saying it will
support building for RHEL 7, mock v3 simply won't run on RHEL 7, OK,
that seems far more sensible. I'm sorry I misread that..

> So what is the problem?
>
> Miroslav

Various companies I've worked with seek to standardize on base
platforms. So do I personally, for my mock build environments. There
is a great deal to dislike about RHEL 8 and CentOS 8 for that base
platform for doing mock builds. If there is no technological reason,
I'd prefer to have any advances in mock, such as any features of v3
available on my CentOS 7 basic build servers. I'd consider using my
Fedora testing server as a build server, but I update that every 6
months, and hesitate to use Fedora itself as my build server.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Mock v2.16 release, mock-core-configs v36.4

[Nico Kadel-Garcia]

On Sat, Dec 18, 2021 at 8:03 AM Neal Gompa  wrote:
>
> On Sat, Dec 18, 2021 at 4:16 AM Nico Kadel-Garcia  wrote:
> >
> > On Thu, Dec 16, 2021 at 1:55 PM Pavel Raiskup  wrote:
> > >
> > > Hello!
> > >
> > > I'm glad I can announce that we have a new release of Mock.  See the full
> > > release notes [1].  The major change that happened is the removal of
> > > 'epel-8' config files, as a follow-up for [2] discussion (and of course on
> > > *devel lists, big thanks to everyone for the discussion).
> >
> > Why would v3 not be available for EPEL ?
>
> Mock v3 will be available for EPEL 8+ and Fedora. We are deliberately
> removing RHEL 7 host support from Mock in Mock v3, so it won't be
> available in EPEL 7. Mock v2 will remain in EPEL 7.
>
> Personally, I think people are nuts to use RHEL as a build host,
> because it makes things quite difficult to work forwards, but if
> you're going to use RHEL as a build host, you should always use the
> latest RHEL instead of the oldest, even if that version of RHEL isn't
> in production in the rest of your infrastructure yet.

Many are unhappy with RHEL 8 and especially with CentOS 8 switching to
CentOS 8 Stream without up front discussion, and have issued internal
policies not to use it at all. Discarding RHEL 7 and CentOS 7  for
EPEL, and by implication Amazon Linux 2,  will discourage people
further from using RHEL based releases at all, I'd not consider it an
encouragement to switch to RHEL 8. Commercial users are avoiding
CentOS 8.  Discarding EPEL 7 is salting the earth for existing users
of RHEL 7 and CentOS 7.

I agree that RHEL can be awkward as a build platform, but Folks who
want it can use local RHEL mirrors. I've published tools for years, at
https://github.com/nkadel/nkadel-rsync-scripts, to help people build
internal RHEL mirrors for just such usages. They're a useful basis for
snapshotting RHEL, CentOS 8 Stream and EPEL for locked internal
mirrors, and useful for setting EPEL to use "rsync -a" rather than
"rsync -a --delete" and and locally running "createrepo" to aggregate
rather than prune EPEL repos for rolling back individual components.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Recent python-pytest-cov update in F34/F35 causes many FTBFS

[Nico Kadel-Garcia]

On Thu, Dec 16, 2021 at 3:54 PM Ben Beasley  wrote:
>
> It looks like python-pytest-cov was recently updated to 3.0.0 in F35[1]
> and F34[2]. I noticed this because, between my own packages and those
> maintained through @neuro-sig, I saw a wave of FTBFS notifications from
> Koschei.

It's been screwing up "mock" builds for Fedora 34 and Fedora 35, as
well. It's one of the risks of many python modules, with a
requirement.txt like "ansible-core<2.13,>=2.12.0", but do not
necessarily list a maximum value range or a completely valid minimum
value for their dependencies. Hilarity ensues.


> Unfortunately, because packages commonly pin a particular major version,
> and because pytest-cov has been in 2.x for a long time, a huge number of
> packages are likely to be affected.
>
> It would be nice if Koschei could build against updates-testing so that
> problems like this could be more easily detected before the updates have
> already reached stable.
>
> – Ben
>
> [1] https://bodhi.fedoraproject.org/updates/FEDORA-2021-3b53235332
> [2] https://bodhi.fedoraproject.org/updates/FEDORA-2021-379e60a35b
> ___
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Mock v2.16 release, mock-core-configs v36.4

[Nico Kadel-Garcia]

On Thu, Dec 16, 2021 at 1:55 PM Pavel Raiskup  wrote:
>
> Hello!
>
> I'm glad I can announce that we have a new release of Mock.  See the full
> release notes [1].  The major change that happened is the removal of
> 'epel-8' config files, as a follow-up for [2] discussion (and of course on
> *devel lists, big thanks to everyone for the discussion).

Why would v3 not be available for EPEL ?
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: rpm bug for multiple README.md or LICENSE.md in EPEL 8 and Fedora

[Nico Kadel-Garcia]

On Tue, Dec 7, 2021 at 11:21 AM Kevin Kofler via devel
 wrote:

> The thing is, the path stripping of %doc path/to/README is a feature. The
> directory path in the sources is not necessarily useful to replicate in the
> installed documentation directory. Removing that path stripping would be an
> incompatible change and make the doc directories of some packages a mess of
> unnecessary subdirectories. If desired, this needs a new syntax that does
> not clash with existing usage.
>
> Kevin Kofler

A binary '__doc_path_stripping' flag, set to "true" by default, might
serve to preserve the paths and avoid overlaps if and as desired. I'd
agree that changing default behavior should be unwelcome.

This path stripping behavior is not mentioned in the RPM
documentation, though people may have become accustomed to it. And
"not necessarily useful" does not mean "never useful", as we are
seeing right now.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: rpm bug for multiple README.md or LICENSE.md in EPEL 8 and Fedora

[Nico Kadel-Garcia]

On Tue, Dec 7, 2021 at 5:46 AM Panu Matilainen  wrote:
>
> On 12/5/21 05:07, Nico Kadel-Garcia wrote:
> > I've been trying to bundle the current ansible-5.0.1 release as an RPM
> > for Fedora and EPEL use. Leaving aside the peculiar decisions to
> > replace the pypi.org "ansible" tarball with a tarball of roughly 150
> > modules from the "ansiblee-collections" repos, and moving the actual
> > ansible software to a distinct python tarball called "ansible-core"
> > without changing the source repo or the actual critical installed
> > python modules, the new "ansible" has more than 300 files called
> > "README.md" and more than 100 files called "LICENSE.md".
> >
> > This breaks building RPMs for EPEL 8 or Fedora, because the '%doc' and
> > '%license' macros strip off the subdirectories of the files and
> > install them directly at the top of the docdir.
> >
> > Basicely these only generate one file:
> >
> > %doc README.md
> > %doc dir1/README.md
> > %doc dir2/README.md
> >
> > %license LICENSE.md
> >  %license dir1/LICENSE
> >  %license dir2/LICENSE.md
> >
> > When compiled, these would only produce:
> >
> >/usr/share/doc/package-%{fersion}/README.md
> >/usr/share/doc/package-%{fersion}/LICENSE.md
> >
> > RHEL 7 didn't have this problem. I'm not sure if other folks have
> > noticed this for tools that are built with multiple internal tarballs.
> > The new "ansible" tarball is fairly unique ints authors insistance on
> > putting more than one hundred distinct third party packages in the
> > same master tarball. But for now, this is going to cause a license and
> > documentation problem in packaging it due to an "optimization" of
> > stripping out the directory names of document files and licenses.
> >
> > Does anyone know a decent workaround, or a specfile setting to disable
> > this filename stripping and restore the RHEL 7 behavior?
>
> There were changes in how %doc is handled around rpm 4.13 (whereas
> RHEL-7 has 4.11), maybe there's a regression that nobody noticed (or
> complained about) until now. The use-case there seems quite reasonable
> to me.
>
> File a bug on rpm (preferably upstream ticket) to have it looked at.
>
> - Panu -

I've submitted one, at https://bugzilla.redhat.com/show_bug.cgi?id=2029877 .

It seems that the problem existed as well with earlier versions of
rpmbuild, say on RHEL 7, but the warning messages about "files listed
twice" weren't generated. And various slightly differently named
README.md and LICENSE.md files make it not as obvious as one might
expect.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: rpm bug for multiple README.md or LICENSE.md in EPEL 8 and Fedora

[Nico Kadel-Garcia]

On Mon, Dec 6, 2021 at 8:09 PM Maxwell G  wrote:
>
> On Monday, December 6, 2021 6:43:57 PM CST Nico Kadel-Garcia wrote:
> > On Mon, Dec 6, 2021 at 3:59 AM Vitaly Zaitsev via devel
> >  wrote:
> > >
> > > On 05/12/2021 04:07, Nico Kadel-Garcia wrote:
> > > > This breaks building RPMs for EPEL 8 or Fedora, because the '%doc' and
> > > > '%license' macros strip off the subdirectories of the files and
> > > > install them directly at the top of the docdir.
> > >
> > > You should deal with them manually.
> > >
> > > Example:
> > > https://github.com/rpmfusion/tg_owt/blob/master/tg_owt.spec#L124-L161
> > > https://github.com/rpmfusion/tg_owt/blob/master/tg_owt.spec#L178-L179
> >
> > Simply put, "no". Manually organizing component names for more than
> > 300 README files and more than 100 LICENSE files does not seem a wise
> > use of anyone's package compilation time.
> >
> > If it's necessary, I could see doing something like this instead, or
> > using a local macro
> >
> >   cp -D ansible_collections/foo/bar/baz/README.md
> > %{buildroot}%{defaultdocdir}/%{package}-%{version}/foo/bbar/baz/README.md
> >
> > I'll still want to separate '%license" files from "%doc", which means
> > I won't just be able to use:
> >
> >   %doc %{defaultdocdir}/%{package}-%{version
>
> The specfile that Vitaly linked also marks the license files with `%license`.

I'm staring at that pull request, which is similar to my tesstable
.spec file in various ways. Mind you, in my testing setup, I use:

BuildRequires: ansible-core >= 2.11.0
BuildRequires: ansible-core < 2.13.0

Requires: ansible-core >= 2.11.0
Requires: ansible-core < 2.13.0

ansible-5.x works well with ansible-core 2.11, the 2.12 requirement
and the related python 3.8 requirement seem to be spurious for the
pypo.org published ansible tarball of hundreds of ansible galaxy
modules.

The suggestion there that those dependencies should be autogenerated
does not and will not work because of the mislabeling of the tarball
with all the actualy core python modules called "ansible" within the
"ansible-core" tarball and RPM, and mislabeling of the moe than 100
ansible_collections python submodules as the new "ansible" tarball.
And yes, I'm being a bit harsh about that split and calling it a
mislabeling, since it's inconsistent and breaks automated processing.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: rpm bug for multiple README.md or LICENSE.md in EPEL 8 and Fedora

[Nico Kadel-Garcia]

On Mon, Dec 6, 2021 at 3:59 AM Vitaly Zaitsev via devel
 wrote:
>
> On 05/12/2021 04:07, Nico Kadel-Garcia wrote:
> > This breaks building RPMs for EPEL 8 or Fedora, because the '%doc' and
> > '%license' macros strip off the subdirectories of the files and
> > install them directly at the top of the docdir.
>
> You should deal with them manually.
>
> Example:
> https://github.com/rpmfusion/tg_owt/blob/master/tg_owt.spec#L124-L161
> https://github.com/rpmfusion/tg_owt/blob/master/tg_owt.spec#L178-L179

Simply put, "no". Manually organizing component names for more than
300 README files and more than 100 LICENSE files does not seem a wise
use of anyone's package compilation time.

If it's necessary, I could see doing something like this instead, or
using a local macro

  cp -D ansible_collections/foo/bar/baz/README.md
%{buildroot}%{defaultdocdir}/%{package}-%{version}/foo/bbar/baz/README.md

I'll still want to separate '%license" files from "%doc", which means
I won't just be able to use:

  %doc %{defaultdocdir}/%{package}-%{version}
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: New openssh in Rawhide can't connect to RHEL 6 servers

[Nico Kadel-Garcia]

On Sun, Dec 5, 2021 at 8:15 AM Richard W.M. Jones  wrote:
>
> openssh 8.8p1 (just released in Rawhide) cannot connect to older
> servers.  The error is:
>
>   Unable to negotiate with [server] port 22: no matching host key type found. 
> Their offer: ssh-rsa,ssh-dss
>
> It seems like the cut-off point is RHEL <= 6 broken, RHEL >= 7 is OK.

RHEL 6 is obsolete for more than the last year: retaining
compatibility with obsolete distributions of an operating system is
work that likely no one is pursuing. I used to do that sort of thing,
but no one is paying me for it right now. That sort of thing used to
be available at repoforge, but that repo stopped getting updates some
time ago.

> I eventually found a workaround/solution to this deep in an Arch
> thread:
>
>   https://bbs.archlinux.org/viewtopic.php?pid=2006291#p2006291
>
> or the equivalent on the command line:
>
>   ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa rhel6

So. you can set it up in ~/.ssh/config for specific remote hosts as needed?

> Both config options seem to be necessary.
>
> Rich.
>
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-builder quickly builds VMs from scratch
> http://libguestfs.org/virt-builder.1.html
> ___
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: rpm bug for multiple README.md or LICENSE.md in EPEL 8 and Fedora

[Nico Kadel-Garcia]

On Sun, Dec 5, 2021 at 10:51 AM Michael Catanzaro  wrote:
>
> The webkit2gtk3 package has a %add_to_license_files macro that you can
> copy as a workaround, but you might not be satisfied because it
> requires listing each affected file individually

I have no moral issue with listing them individually. Listing them in
a single long line breaks rpm very thoroughly, due to the resulting
%doc line of over 20,000 characters. It's another confusing
consequence of the more than 100 ansible galaxy modules in the same
python tarball.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: rpm bug for multiple README.md or LICENSE.md in EPEL 8 and Fedora

[Nico Kadel-Garcia]

On Sun, Dec 5, 2021 at 1:49 AM Otto Urpelainen  wrote:
>
> Nico Kadel-Garcia kirjoitti 5.12.2021 klo 5.07:
> > I've been trying to bundle the current ansible-5.0.1 release as an RPM
> > for Fedora and EPEL use. Leaving aside the peculiar decisions to
> > replace the pypi.org "ansible" tarball with a tarball of roughly 150
> > modules from the "ansiblee-collections" repos, and moving the actual
> > ansible software to a distinct python tarball called "ansible-core"
> > without changing the source repo or the actual critical installed
> > python modules, the new "ansible" has more than 300 files called
> > "README.md" and more than 100 files called "LICENSE.md".
> >
> > This breaks building RPMs for EPEL 8 or Fedora, because the '%doc' and
> > '%license' macros strip off the subdirectories of the files and
> > install them directly at the top of the docdir.
> >
> > Basicely these only generate one file:
> >
> > %doc README.md
> > %doc dir1/README.md
> > %doc dir2/README.md
> >
> > %license LICENSE.md
> >  %license dir1/LICENSE
> >  %license dir2/LICENSE.md
> >
> > When compiled, these would only produce:
> >
> >/usr/share/doc/package-%{fersion}/README.md
> >/usr/share/doc/package-%{fersion}/LICENSE.md
>
> Path stripping only happens if you list relative paths with %doc or
> %license, which which case rpm looks for them from the build directory.
> If you specify absolute paths, rpm looks for them in the buildroot like
> it does for any other files. See section %doc and %license at rpm spec
> file format reference [1].
>
> So something like this should work:
>
>  %install
>  cp README.md
> %{buildroot}/%{_datadir}/doc/%{package}-%{version}/README.md
>  cp dir1/README.md
> %{buildroot}/%{_datadir}/doc/%{package}-%{version}/dir1/README.md
>  # ...
>
>  %files
>  %doc %{_datadir}/doc/%{package}-%{version}/README.md
>  %doc %{_datadir}/doc/%{package}-%{version}/dir1/README.md
>  # ...
>
> [1]: https://rpm-software-management.github.io/rpm/manual/spec.html
>
> Otto

I'm reading that documentation. It says *nothing* about path
stripping, a behavior which has apparently changed sometime since RHEL
7 or its ancestorFedora 12. So if this is expected behavior, I'd like
to see it documented.

Does anyone know how to turn it off for '%doc' and ''%license'? It
doesn't seem to be in the macros, and diving into the C code to get
this change reverted for a future release of rpm seems like a very
long term goal. It seems to me to be unwelcome and undesirable
behavior for precisely the kind of situation of 'ansible tarball has
more than 300 README.md files'. And given my previous concerns about
that very large bundle, I suspect I'll not have good success getting
the authors to discard it and use a more typical factored python
submodule distribution.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: rpm bug for multiple README.md or LICENSE.md in EPEL 8 and Fedora

[Nico Kadel-Garcia]

Aarggh, I had a cat attacking my hands at one moment. I meant:

  /usr/share/doc/%}package}-%{version}/README.md
  /usr/share/doc/%{package}-%{version}/LICENSE.md

On Sat, Dec 4, 2021 at 10:07 PM Nico Kadel-Garcia  wrote:
>
> I've been trying to bundle the current ansible-5.0.1 release as an RPM
> for Fedora and EPEL use. Leaving aside the peculiar decisions to
> replace the pypi.org "ansible" tarball with a tarball of roughly 150
> modules from the "ansiblee-collections" repos, and moving the actual
> ansible software to a distinct python tarball called "ansible-core"
> without changing the source repo or the actual critical installed
> python modules, the new "ansible" has more than 300 files called
> "README.md" and more than 100 files called "LICENSE.md".
>
> This breaks building RPMs for EPEL 8 or Fedora, because the '%doc' and
> '%license' macros strip off the subdirectories of the files and
> install them directly at the top of the docdir.
>
> Basicely these only generate one file:
>
>%doc README.md
>%doc dir1/README.md
>%doc dir2/README.md
>
>%license LICENSE.md
> %license dir1/LICENSE
> %license dir2/LICENSE.md
>
> When compiled, these would only produce:
>
>   /usr/share/doc/package-%{fersion}/README.md
>   /usr/share/doc/package-%{fersion}/LICENSE.md
>
> RHEL 7 didn't have this problem. I'm not sure if other folks have
> noticed this for tools that are built with multiple internal tarballs.
> The new "ansible" tarball is fairly unique ints authors insistance on
> putting more than one hundred distinct third party packages in the
> same master tarball. But for now, this is going to cause a license and
> documentation problem in packaging it due to an "optimization" of
> stripping out the directory names of document files and licenses.
>
> Does anyone know a decent workaround, or a specfile setting to disable
> this filename stripping and restore the RHEL 7 behavior?
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

rpm bug for multiple README.md or LICENSE.md in EPEL 8 and Fedora

[Nico Kadel-Garcia]

I've been trying to bundle the current ansible-5.0.1 release as an RPM
for Fedora and EPEL use. Leaving aside the peculiar decisions to
replace the pypi.org "ansible" tarball with a tarball of roughly 150
modules from the "ansiblee-collections" repos, and moving the actual
ansible software to a distinct python tarball called "ansible-core"
without changing the source repo or the actual critical installed
python modules, the new "ansible" has more than 300 files called
"README.md" and more than 100 files called "LICENSE.md".

This breaks building RPMs for EPEL 8 or Fedora, because the '%doc' and
'%license' macros strip off the subdirectories of the files and
install them directly at the top of the docdir.

Basicely these only generate one file:

   %doc README.md
   %doc dir1/README.md
   %doc dir2/README.md

   %license LICENSE.md
%license dir1/LICENSE
%license dir2/LICENSE.md

When compiled, these would only produce:

  /usr/share/doc/package-%{fersion}/README.md
  /usr/share/doc/package-%{fersion}/LICENSE.md

RHEL 7 didn't have this problem. I'm not sure if other folks have
noticed this for tools that are built with multiple internal tarballs.
The new "ansible" tarball is fairly unique ints authors insistance on
putting more than one hundred distinct third party packages in the
same master tarball. But for now, this is going to cause a license and
documentation problem in packaging it due to an "optimization" of
stripping out the directory names of document files and licenses.

Does anyone know a decent workaround, or a specfile setting to disable
this filename stripping and restore the RHEL 7 behavior?
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: /usr/bin/ld.so as a symbolic link for the dynamic loader

[Nico Kadel-Garcia]

On Thu, Dec 2, 2021 at 1:39 PM Florian Weimer  wrote:
>
> I'd like to provide an ld.so command as part of glibc.  Today, ld.so can
> be used to activate preloading, for example.  Compared to LD_PRELOAD,
> the difference is that it's specific to one process, and won't be
> inherited by subprocesses—something is that exactly what is needed.
> There is also some useful diagnostic output in --help,
> --list-diagnostics.

That seems a horrible idea. The ".so" suffix indicates that it is a
library file, not an executable

"ld.so.preload" might make more sense if you really feel the need for
such a tool to live in /usr/bin/.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [EPEL-devel] Mock/Copr default epel-8-* configuration to be changed

[Nico Kadel-Garcia]

On Sun, Nov 28, 2021 at 7:06 PM Neal Gompa  wrote:
>
> On Thu, Nov 25, 2021 at 2:02 PM Nico Kadel-Garcia  wrote:
> >
> > On Thu, Nov 25, 2021 at 8:26 AM Neal Gompa  wrote:
> > >
> > > On Thu, Nov 25, 2021 at 6:19 AM Nico Kadel-Garcia  
> > > wrote:
> > > >
> > > > On Thu, Nov 25, 2021 at 3:05 AM Miroslav Suchý  
> > > > wrote:
> > > > >
> > > > > Dne 22. 11. 21 v 15:00 Pavel Raiskup napsal(a):
> > > > > > Hello Fedora EPEL maintainers!
> > > > > >
> > > > > > First I don't feel comfortable announcing this, I'm not happy about 
> > > > > > the
> > > > > > situation and so I don't want to be the lightning rod :-).  But I 
> > > > > > believe
> > > > > > that we can come to acceptable Copr/Mock solution and this needs to 
> > > > > > be
> > > > > > discussed...  so here we are.
> > > > > >
> > > > > > By the end of the year 2021 we have to fix our default EPEL 8 Mock
> > > > > > configuration (mock-core-configs.rpm, /etc/mock/epel-8-*.cfg) as 
> > > > > > CentOS 8
> > > > > > goes EOL by then.
> > > > >
> > > > >
> > > > > I wrote down the possible options and their pros and cons and I done 
> > > > > my best to catch all the feedback here.
> > > > >
> > > > > https://docs.google.com/document/d/1wF7-7_y6Ac_oB-kCFdE6VBWPW8o8zjXd2Z0SGy4VxUA/edit?usp=sharing
> > > > >
> > > > > Miroslav
> > > >
> > > > That seems to be a succinct listing. I think you left out my
> > > > suggestion.of "support people re-inventing point releases for CentOS",
> > > > which is what major CentOS users will do using internal mirrors. due
> > > > to concern about unexpected and unwelcome updates of CentOS Stream,
> > > > while they assess whether AlmaLinux or Rocky are reliable and stable
> > > > enough to use. It's not an uncommon behavior for EPEL itself, partly
> > > > because of EPEL's bad habit of deleting RPMs without warning and
> > > > stripping out all previous releases. That's caused me problems with
> > > > chromium and firefox when updates were incompatible with contemporary
> > > > regression testing systems.
> > > >
> > >
> > > It's not a "bad habit", it happens because when packages are retired,
> > > keeping the packages there does a disservice to the community by
> > > effectively forcing a maintenance burden when there's no maintainer.
> > > As for stripping out previous releases, that's just how Pungi and
> > > Bodhi do update composes at the moment. Someday that'll be fixed, but
> > > then we'd have to come up with a policy on how many because there are
> > > storage concerns for mirrors if we kept everything published forever.
> >
> > It causes problems and confusion for people who need to lock down
> > evisting versions for deployment. And it happens for packages that are
> > not retired, but merely updated. I was bitten by it myself with
> > chromium updates last year. It forces users of EPEL to maintain
> > internal repos, or out of band access to previously accessible RPMs.
> > It's destabilizing and breaks the use of bills-of-material based
> > deployments with complete lists of all desired RPMs.
> >
> > Storage and bandwidth concerns are legitimate concerns, as is
> > potentially continuing to publish older releases with known
> > vulnerabilities or bugs.  But neither Fedora nor RHEL simply discard
> > previously published versions this way, they aggregate new releases. I
> > consider this a longstanding bug for EPEL, and one of the reasons I
> > set up internal mirrors in large deployments.
> >
>
> This is not true. Fedora and EPEL share the same system, and have the
> same issues. The only difference is that the release repo is frozen in
> Fedora, so only the updates repo is affected this way. So there's at
> most two versions of a package at any time.

You're correct. With the current setup, it's also relatively simple to
revert to the "frozen" release, which handles most of the regression
situations. And Fedora releases are nowhere near so long-lived as RHEL
and EPEL, so it tends to be less of a long-lived problem.

> RHEL *does* maintain multiple old versions, but their system is
> completely different and supports that capability.

What would it take to get Fedora, or at least EPEL, to preserve old
releases in the default published repos? I appreciate that it would
require thought and expand them noticeably, especially for bulky and
frequently updating components like chromium. I admit to not having
numbers on how much churn happens there: does anyone have numbers?

Nico Kadel-Garcia
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [EPEL-devel] Mock/Copr default epel-8-* configuration to be changed

[Nico Kadel-Garcia]

@Miroslav Suchý asked me to sum up my suggestions for using internal
mirrors more clearly, So, adding to his published Google Doc:

5 - Use internal RHEL mirrors.

It's difficult to license multiple RHEL releases and enable multiple
yum dnf or yum channels and supported RHEL or CentOS releases and
architectures on a single server. Instead, support a local repository
with "reposync" used to mirror RHEL channels for designated
architectures and releases as needed. It is possible to mount DVD
images for local copies of specific releases to ease the mirroring
process.

Pros:
Provides multiple RHEL channels, architectures, and distributions
as desired.
Allows locking streams for scheduled updates of build environments
for compatibility inaccessible to streaming releases.
Allows aggregated, rather than directly mirrored, EPEL repos to
avoid regression failures.

Cons:
Requires local storage space and web server for registered clients
to load new content.
Requires individual tuning for distinct local environments
Adds RPM provenance concerns for local repos.

6. Use snapshotted CentOS 8 Stream mirrors

The CentOS 8 Stream uncertainties are described above. Creating a
local CentOS 8 mirror with locked snapshots can help stabilize the
stream, update the build components only if and when an update is
scheduled.

Pros:
Reduces burden of multiple build hosts on upstream mirrors.
Allows site specific scheduling of build repo updates.
Allows easy and efficient rsync internal mirrors.
Allows aggregated, rather than directly mirrored, EPEL repos to
avoid regression failures.

Cons:
Reposync based mirrors for RHEL require more work.
Includes inevitable phase lags between upstream changes and local
snapshotted repos..
Reduces, though does not completely eliminate risk of CentOS 8
Stream regression errors
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: GitHub source URLs not working

[Nico Kadel-Garcia]

On Fri, Nov 26, 2021 at 5:50 PM Fabio Valentini  wrote:
>
> On Fri, Nov 26, 2021 at 11:30 PM Nico Kadel-Garcia  wrote:
> >
> > It's also Friday right after Thanksgiving, "Black Friday". And most
> > python modules .spec files, which use pypi.org as their source
> > repository rathter than github, seem to be workin.
>
> (snip)
>
> > Directly referencing github is sometimes useful, for example for
> > anyone who bothers to straighten the somewhat crazed renaming of
> > "ansible" and ansible-core" as "ansible-core" and
> > "ansible-collections, or who works with ansible colleciton modules.
> > But how much of github references use 'codeload.github.com' rather
> > than 'github.com' ?There hae been way, way too many syntaxes for
> > pulling tarballs for git repos, it's sometimes quite confusing.
> > Especially for python modules, since the e python repo owner can
> > delete and replace arbitrary tags at whim.
>
> If you look at the actual request URL, you'll see that it is for github.com.
> The codeload.github.com URL is then a result of a server-side redirect.

To quote Willie Wonka: "Strike that: reverse it". The
codeload.github.com URL typically generates a successful redirect,
which is not working.

I'd encourage throwing most of thee varied 'get the designated
tarball' schemes to simplify the schemes and make it more reliable.

> There *have* been many way to load tarballs from GitHub, but this has
> pretty much standardized in recent 2-3 years.
> And the fact that the URL scheme that is documented in the Packaging
> Guidelines (and probably the one used by the forge macros) is broken
> does not bode well.

*Absolutely* correct! I'd hate to have to change it in the standards.
Do any of us know anyone over at github.com to let them know directly?
I'm not working for a company with such a contract right now, my repos
there are personal right now.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: GitHub source URLs not working

[Nico Kadel-Garcia]

On Fri, Nov 26, 2021 at 4:39 PM Fabio Valentini  wrote:
>
> Fri, Nov 26, 2021 at 8:37 PM Susi Lehtola
>  wrote:
> >
> > Hi,
> >
> >
> > I am experiencing problems updating packages employing GitHub source
> > URLs. For instance,
> >
> > $ spectool -g python-pyscf.spec
> > Downloading:
> > https://github.com/pyscf/pyscf/archive/v2.0.1/pyscf-2.0.1.tar.gz
> > Download failed:
> > 404 Client Error: Not Found for url:
> > https://codeload.github.com/pyscf/pyscf/tar.gz/v2.0.1/pyscf-2.0.1
> > -   0.0 B Elapsed Time: 0:00:00
> >
> >
> >
> > The URLs used to work. Has anyone else noticed the same problem?
>
> Yes, I've experienced similar problems today.
>
> If this is not a bug but a deliberate change by GitHub, it's going to
> be a major PITA to fix all those .spec files for sources hosted on
> GitHub ...
> So ... does anybody know (or can find out) whether it's the former or
> the latter?
>
> Fabio

It's also Friday right after Thanksgiving, "Black Friday". And most
python modules .spec files, which use pypi.org as their source
repository rathter than github, seem to be workin.

Directly referencing github is sometimes useful, for example for
anyone who bothers to straighten the somewhat crazed renaming of
"ansible" and ansible-core" as "ansible-core" and
"ansible-collections, or who works with ansible colleciton modules.
But how much of github references use 'codeload.github.com' rather
than 'github.com' ?There hae been way, way too many syntaxes for
pulling tarballs for git repos, it's sometimes quite confusing.
Especially for python modules, since the e python repo owner can
delete and replace arbitrary tags at whim.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [EPEL-devel] Mock/Copr default epel-8-* configuration to be changed

[Nico Kadel-Garcia]

On Thu, Nov 25, 2021 at 8:26 AM Neal Gompa  wrote:
>
> On Thu, Nov 25, 2021 at 6:19 AM Nico Kadel-Garcia  wrote:
> >
> > On Thu, Nov 25, 2021 at 3:05 AM Miroslav Suchý  wrote:
> > >
> > > Dne 22. 11. 21 v 15:00 Pavel Raiskup napsal(a):
> > > > Hello Fedora EPEL maintainers!
> > > >
> > > > First I don't feel comfortable announcing this, I'm not happy about the
> > > > situation and so I don't want to be the lightning rod :-).  But I 
> > > > believe
> > > > that we can come to acceptable Copr/Mock solution and this needs to be
> > > > discussed...  so here we are.
> > > >
> > > > By the end of the year 2021 we have to fix our default EPEL 8 Mock
> > > > configuration (mock-core-configs.rpm, /etc/mock/epel-8-*.cfg) as CentOS 
> > > > 8
> > > > goes EOL by then.
> > >
> > >
> > > I wrote down the possible options and their pros and cons and I done my 
> > > best to catch all the feedback here.
> > >
> > > https://docs.google.com/document/d/1wF7-7_y6Ac_oB-kCFdE6VBWPW8o8zjXd2Z0SGy4VxUA/edit?usp=sharing
> > >
> > > Miroslav
> >
> > That seems to be a succinct listing. I think you left out my
> > suggestion.of "support people re-inventing point releases for CentOS",
> > which is what major CentOS users will do using internal mirrors. due
> > to concern about unexpected and unwelcome updates of CentOS Stream,
> > while they assess whether AlmaLinux or Rocky are reliable and stable
> > enough to use. It's not an uncommon behavior for EPEL itself, partly
> > because of EPEL's bad habit of deleting RPMs without warning and
> > stripping out all previous releases. That's caused me problems with
> > chromium and firefox when updates were incompatible with contemporary
> > regression testing systems.
> >
>
> It's not a "bad habit", it happens because when packages are retired,
> keeping the packages there does a disservice to the community by
> effectively forcing a maintenance burden when there's no maintainer.
> As for stripping out previous releases, that's just how Pungi and
> Bodhi do update composes at the moment. Someday that'll be fixed, but
> then we'd have to come up with a policy on how many because there are
> storage concerns for mirrors if we kept everything published forever.

It causes problems and confusion for people who need to lock down
evisting versions for deployment. And it happens for packages that are
not retired, but merely updated. I was bitten by it myself with
chromium updates last year. It forces users of EPEL to maintain
internal repos, or out of band access to previously accessible RPMs.
It's destabilizing and breaks the use of bills-of-material based
deployments with complete lists of all desired RPMs.

Storage and bandwidth concerns are legitimate concerns, as is
potentially continuing to publish older releases with known
vulnerabilities or bugs.  But neither Fedora nor RHEL simply discard
previously published versions this way, they aggregate new releases. I
consider this a longstanding bug for EPEL, and one of the reasons I
set up internal mirrors in large deployments.

> > The difficulty with switching mock to AlmaLinux or Rocky is that there
> > is likely to be significant phase lag with new point releases by Red
> > Hat, and that it will inflict quite a bandwidth burden for all the
> > "mock" setups in the field. Can they scale up to handle that?
>
> Insofar as "phase lag with new point releases", AlmaLinux made their
> release 48 hours after Red Hat did with RHEL. So, frankly, I'm not
> worried there with AlmaLinux.

48 hours is pretty danged good. I hesitate to rely on a new OS
publisher with so little track record, even if they've been very good
in their first year. I'm very curious how well they'll do with RHEL
8.6, without a published CentOS example to compare with. And I'd be
very, very wary of the "planning fallacy", where people underestimate
the time of future tasks, despite knowledge that previous tasks have
sometimes taken far longer.

> For bandwidth burdens, mirror networks are designed to alleviate that
> burden and both have those in place.

Sure, and they're very helpful. But to the one managing such networks,
a massive increase in bandwidth use or in the *breadth* of content
used for a particular mirrored repo for a particular product is very
helpful to plan for and avoid local choke points. I'm especially
thinking of the cache on relevant proxy servers.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [EPEL-devel] Mock/Copr default epel-8-* configuration to be changed

[Nico Kadel-Garcia]

On Thu, Nov 25, 2021 at 3:05 AM Miroslav Suchý  wrote:
>
> Dne 22. 11. 21 v 15:00 Pavel Raiskup napsal(a):
> > Hello Fedora EPEL maintainers!
> >
> > First I don't feel comfortable announcing this, I'm not happy about the
> > situation and so I don't want to be the lightning rod :-).  But I believe
> > that we can come to acceptable Copr/Mock solution and this needs to be
> > discussed...  so here we are.
> >
> > By the end of the year 2021 we have to fix our default EPEL 8 Mock
> > configuration (mock-core-configs.rpm, /etc/mock/epel-8-*.cfg) as CentOS 8
> > goes EOL by then.
>
>
> I wrote down the possible options and their pros and cons and I done my best 
> to catch all the feedback here.
>
> https://docs.google.com/document/d/1wF7-7_y6Ac_oB-kCFdE6VBWPW8o8zjXd2Z0SGy4VxUA/edit?usp=sharing
>
> Miroslav

That seems to be a succinct listing. I think you left out my
suggestion.of "support people re-inventing point releases for CentOS",
which is what major CentOS users will do using internal mirrors. due
to concern about unexpected and unwelcome updates of CentOS Stream,
while they assess whether AlmaLinux or Rocky are reliable and stable
enough to use. It's not an uncommon behavior for EPEL itself, partly
because of EPEL's bad habit of deleting RPMs without warning and
stripping out all previous releases. That's caused me problems with
chromium and firefox when updates were incompatible with contemporary
regression testing systems.

The difficulty with switching mock to AlmaLinux or Rocky is that there
is likely to be significant phase lag with new point releases by Red
Hat, and that it will inflict quite a bandwidth burden for all the
"mock" setups in the field. Can they scale up to handle that?
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [EPEL-devel] Mock/Copr default epel-8-* configuration to be changed

[Nico Kadel-Garcia]

On Tue, Nov 23, 2021 at 9:16 PM Kevin Kofler via devel
 wrote:
>
> Nico Kadel-Garcia wrote:
> > Neither of those have much track history.
>
> Of course they don't. How can they, when CentOS had stolen their show for
> years and the sudden "change of directions" was announced only earlier this
> year? Blame RH for not having given the rebuild community more time to
> prepare. (Pulling the plug on CentOS 8 7-8 years before its originally
> announced EOL was a huge surprise, and not a good one.)
>
> > The easy move is to use CentOS 8 Stream for "mock", at least in the short
> > term.
>
> With CentOS Stream, you want to use epel-next, not plain epel. And the epel-
> next configs already use CentOS Stream.

Which is available. It would need to be designated as the "default"
for compilation. The changes would be in the default settings for
mock-core-configs, nowhere else, and not require other repo changes.

> > The alternative is to designate the CentOS switch to streaming
> > deployments as a non-starter, and re-invent point releases on top of
> > CentOS 8 Stream It's likely to create small discrepancies with
> > packages released, and rejected or withdrawn, from CentOs 8 Stream
> > before they get to RHEL 8. Since CentOS 8 Stream is the new beta for
> > RHEL 8, this would seem inevitable.
>
> Why would we want to reinvent the wheel instead of using one of the two
> already working solutions? And how would that not necessarily have even less
> "track history", considering that Alma and Rocky already exist, whereas your
> idea has not even be started yet?

I'm not saying this is the best option, but it invelves less change to
the build systems to rely on mirrors and base repos that Red Hat does
not own. It's feasible as a technology, and it's something that some
of us are going to have to do anyway to use CentOS for production
deployments. I've been doing something like it since... well, since
Red Hat 9 in 2003, and for Fedora, to lock down static internal
mirrors for staged rather than streaming updates.

> > It's a waste of time and resources to generate and manage the relevant
> > repodata, exacerbated by the multiple unwelcome and randomly
> > overlapping channels of CentOS 8. Multiple snapshots of a repo are
> > also not free in disk space or inodes.
>
> Of course it is. So do not do that.

Assess the alternatives before discarding them.

> > But I'm not sure if the more "replicate only" distributions will be
> > long-lived multi-platform enough to rely on for EPEL,
>
> Then you switch to another rebuild. The demand is not going to vanish
> overnight, so I do not expect them to go away without a replacement, just as
> CentOS did not go away without a replacement either.

That is *expensive* to do. It leads to people discarding
distributions, which I observe has been happening for CentOS and RHEL.
Some previous fans are biting the bullet and switching to Ubuntu to
avoid this mess, others are switching to Amazon Linux or simply
skipping RHEL 8 and CentOS 8 entirely. Amazon, for example, is not
planning to publish a matching "Amazon Linux 3", I've asked them.
Unfortunately, Amazon Linux 2 is too divergent from RHEL and CentOS to
be usable for EPEL, it's python 3.7 instead of python 3.6.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [EPEL-devel] Mock/Copr default epel-8-* configuration to be changed

[Nico Kadel-Garcia]

On Tue, Nov 23, 2021 at 7:31 PM Kevin Kofler via devel
 wrote:
>
> Pavel Raiskup wrote:
> > First I don't feel comfortable announcing this, I'm not happy about the
> > situation and so I don't want to be the lightning rod :-).  But I believe
> > that we can come to acceptable Copr/Mock solution and this needs to be
> > discussed...  so here we are.
>
> I, too, believe that we can come to an acceptable solution. Unfortunately, I
> do not consider the one you propose to be acceptable, at all.
>
> > I am proposing (as PR against mock upstream ATM [1]) to switch the default
> > epel-* configuration from CentOS+EPEL to RHEL+EPEL as soon as possible
> > (see the pull request [1]).
>
> I think there are only 2 reasonable defaults: Rocky Linux or AlmaLinux (just
> pick whatever of those works better in practice, it should not really
> matter). In particular:

Neither of those have much track history. The easy move is to use
CentOS 8 Stream for "mock", at least in the short term.

The alternative is to designate the CentOS switch to streaming
deployments as a non-starter, and re-invent point releases on top of
CentOS 8 Stream It's likely to create small discrepancies with
packages released, and rejected or withdrawn, from CentOs 8 Stream
before they get to RHEL 8. Since CentOS 8 Stream is the new beta for
RHEL 8, this would seem inevitable.

It's a waste of time and resources to generate and manage the relevant
repodata, exacerbated by the multiple unwelcome and randomly
overlapping channels of CentOS 8. Multiple snapshots of a repo are
also not free in disk space or inodes. But I'm not sure if the more
"replicate only" distributions will be long-lived multi-platform
enough to rely on for EPEL, and I'd expect screaming from various
security and support experts if EPEL relies on anything not directly
published by Red Hat. I'm finding myself sad that Scientific Linux
withdrew from publishing new releases in deference to CentOS.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Mock/Copr default epel-8-* configuration to be changed

[Nico Kadel-Garcia]

On Mon, Nov 22, 2021 at 9:01 AM Pavel Raiskup  wrote:
>
> Hello Fedora EPEL maintainers!
>
> First I don't feel comfortable announcing this, I'm not happy about the
> situation and so I don't want to be the lightning rod :-).  But I believe
> that we can come to acceptable Copr/Mock solution and this needs to be
> discussed...  so here we are.
>
> By the end of the year 2021 we have to fix our default EPEL 8 Mock
> configuration (mock-core-configs.rpm, /etc/mock/epel-8-*.cfg) as CentOS 8
> goes EOL by then.
>
> The same thing needs to happen in Fedora Copr, with the epel-8-* chroots
> (side note, in Fedora Copr we use the mock-core-configs package for builds
> without any deployment specific modifications).
>
> I am proposing (as PR against mock upstream ATM [1]) to switch the default
> epel-* configuration from CentOS+EPEL to RHEL+EPEL as soon as possible
> (see the pull request [1]).

This would seem to be an exceptionally bad idea. Red Hat elected to
force this CentOS Stream release structure down everyone's throats
unannounced, compelling default mock behavior to use the stream is a
logical consequence. Trying to outsmart Red Hat on this is going to
break EPEL dependencies and keep breaking EPEL for Stream deployments.

> This would bring some consequences, namely newly with epel-8* chroots,
>
> - builds will require a valid Red Hat subscription (the no-cost variant is
>   OK as well, though [2])
> - we will miss some build-time packages that Red Hat is not shipping, at
>   least at the beginning till they are added (to RHEL CRB, or other
>   currently unknown place).
> - cross-arch compilation can not be used, Red Hat subscriptions don't
>   allow that (using QEMU and rpm --forcearch), [3]

Which is precisely why pointing it to the 'stream' release seems the
only workable solution.

> The positive thing is that the default configuration will be much closer
> to the official EPEL builds (because Fedora Koji EPEL builds are actually done
> also against RHEL).

That does seem desirable. Frankly, I don't expect this mid-stream
pivot to last more than 2 years: it was tried before with Red Hat 9,
and discarded thoroughly for RHEL 2.1. Point releases are too useful
for environments that cannot afford CI/CD with the underlying
operating system, and don't want to spend the time re-inventing point
releases themselves.

> For the Fedora Copr builders, we already have the necessary Red Hat
> subscriptions in hand (will be deployed by the end of the year).  So we will
> only loose the opportunity to build on emulated epel-8-armhfp permanently, and
> epel-8-s390x temporarily (as we already work on the native s390x support).
>
> Any thoughts?  Feedback is needed here.
>
> [1] https://github.com/rpm-software-management/mock/pull/802
> [2] https://rpm-software-management.github.io/mock/Feature-rhelchroots
> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1912847
>
> Pavel
>
>
> ___
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Drop NIS(+) support from PAM (System-Wide Change proposal)

[Nico Kadel-Garcia]

On Fri, Oct 29, 2021 at 8:00 AM Stephen John Smoogen  wrote:

> Company internal only is a rarity these days with cloud deployments
> and people putting Alexa's and similar devices on the company
> internet. That 'smart fridge' in the company workroom or 'smart tv' in
> the executive lounge is both an internal and external device. That
> 'smart speaker' someone stuck on the wireless to play their music is
> just as likely to be able to send all that company data out as it is
> able to get Conway Twitty into the workplace.

You'd probably be surprised at the number of companies, and especially
NAT'ed internal networks.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [Rawhide] ImageMagick-6.9.12-26 available

[Nico Kadel-Garcia]

On Thu, Oct 28, 2021 at 8:02 PM Sérgio Basto  wrote:
>
> On Tue, 2021-10-26 at 16:42 -0700, Luya Tshimbalanga wrote:
> > Hello team,
> >
> >   I would like to let you know ImageMagick-6.9.12-26 recently landed
> > upstream.
>
> Hello , when you update from 6.9.11 to 6.9.12, we need rebuild all
> depended packages because we got one soname bump and packages won't
> will give us rpm broken dependencies on dnf update

I would not expect an update of the third number in semver numbering
to update the sonames. That sounds like an issue with the upstream
numbering versus release building.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Ansible 5 (Self-Contained Change proposal)

[Nico Kadel-Garcia]

On Wed, Oct 20, 2021 at 8:52 AM Nico Kadel-Garcia  wrote:
>
> On Wed, Oct 20, 2021 at 2:24 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > FWIW, I think the upstream renaming of ansible and ansible-core is something
> > that we just have to accept. But we have some flexibility in how this is
> > packaged in Fedora.
> >
> > On Tue, Oct 19, 2021 at 09:34:34PM -, David Moreau-Simard wrote:
> > [> Richard Meggins wrote:]
> > > >   *  Produce multiple RPM packages from this spec file
> > > >  *  ansible-core
> > > >  *  one RPM package for each collection in the pypi ansible package 
> > > > -
> > > > these could be created programatically in the spec file using LUA or 
> > > > other
> > > > spec file automation to create separate package, documentation, files,
> > > > Requires, etc. for each collection package
> > > >  * a package called "ansible" which is essentially a meta-package 
> > > > which
> > > > simply does a "Requires: ansible-core" and also "Requires" every
> > > > collection
> > > > package
> > > >
> > > > That way, there is a single source for any/all combinations of 
> > > > ansible-core
> > > > + collection rpms, or the entire ansible containing everything.
> > > >
> > > > One downside is that this restricts the ability to produce fixes or
> > > > upgrades for individual collections independently of the rest of the
> > > > Ansible packages. But I think that's only a problem if
> > > >
> > > >  * the independent collections change frequently
> > > >  * the https://pypi.org/project/ansible lags behind and doesn't keep up
> > > > with the collections
> > >
> > > In fact, we first considered proposing something that was similar to
> > > what you suggest -- an ansible package that pulls in individually
> > > packaged collections as well as ansible-core - before settling on
> > > the change at https://fedoraproject.org/wiki/Changes/Ansible5.
> > >
> > > We concluded that it would be hard to do in practice because:
> > > - Ansible 5 will ship with ~95 individual collections 
> > > (https://github.com/ansible-community/ansible-build-data/blob/main/5/ansible.in)
> > > - Of these 95 collections, there's only about a dozen that are already 
> > > packaged (I wrote down some notes here: 
> > > https://hackmd.io/iAloYlTQQ3e-yi99w_o54A)
> > > - The versions of individually packaged collections could diverge from 
> > > those shipped inside the 'ansible' package (ex: 
> > > https://github.com/ansible-community/ansible-build-data/blob/main/5/ansible-5.0.0a2.deps)
> > > - Even considering we develop tooling and automation around the process, 
> > > it would still be error prone and a lot of work without mentioning the 
> > > administrative overhead of maintaining 95+ packages
> > >
> > > In short: it would require a non-negligible amount of effort to
> > > package each individual collection, keep them updated while in sync
> > > with the versions that the upstream package ships without conflicts.
> >
> > The Change proposal is not very clear in this regard… Please correct me
> > if I'm wrong, but my understanding is that there's a giant SRPM which
> > produces a giant 'ansible' binary package. In addition there's a second
> > small SRPM which produces the 'ansible-core' binary package.
> >
> > When I'm reading Richard's proposal, I understand it as a giant SRPM
> > package + ~95 binary packages. In your answer, you are clearly discussing
> > ~95 SRPM packages with ~95 binary packages.
>
> There is no SRPM, because no one has successfully packaged it. There
> is a very bulky upstream tarball, and it is peculiarly constructed.
> and it is mislabeled because all of its contents except some
> ansible.egg-info files wind up in
> /usr/lib/python3.x/site-packages/ansible_collections/, and are
> referred to in python based on that location and with the prefix name
> "ansible_collections", not "ansible".

I've published a .spec file for ansible-4.7.0, as much as I've
protested the unwelcome mishandling of the ansible split. I've
included RHEL 7, RHEL 8. and Fedora Core 34 compatible .spec files for
ansible-core, ansible, and all the rawhide published
ansible-collections are available at:

  https://github.com/nkadel/ansiblerepo/

I'm not currently an authorized Fedora packager, so anyone willing to
take these on or accept them a

Re: F37 Change: Ansible 5 (Self-Contained Change proposal)

[Nico Kadel-Garcia]

On Wed, Oct 20, 2021 at 2:24 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> FWIW, I think the upstream renaming of ansible and ansible-core is something
> that we just have to accept. But we have some flexibility in how this is
> packaged in Fedora.
>
> On Tue, Oct 19, 2021 at 09:34:34PM -, David Moreau-Simard wrote:
> [> Richard Meggins wrote:]
> > >   *  Produce multiple RPM packages from this spec file
> > >  *  ansible-core
> > >  *  one RPM package for each collection in the pypi ansible package -
> > > these could be created programatically in the spec file using LUA or other
> > > spec file automation to create separate package, documentation, files,
> > > Requires, etc. for each collection package
> > >  * a package called "ansible" which is essentially a meta-package 
> > > which
> > > simply does a "Requires: ansible-core" and also "Requires" every
> > > collection
> > > package
> > >
> > > That way, there is a single source for any/all combinations of 
> > > ansible-core
> > > + collection rpms, or the entire ansible containing everything.
> > >
> > > One downside is that this restricts the ability to produce fixes or
> > > upgrades for individual collections independently of the rest of the
> > > Ansible packages. But I think that's only a problem if
> > >
> > >  * the independent collections change frequently
> > >  * the https://pypi.org/project/ansible lags behind and doesn't keep up
> > > with the collections
> >
> > In fact, we first considered proposing something that was similar to
> > what you suggest -- an ansible package that pulls in individually
> > packaged collections as well as ansible-core - before settling on
> > the change at https://fedoraproject.org/wiki/Changes/Ansible5.
> >
> > We concluded that it would be hard to do in practice because:
> > - Ansible 5 will ship with ~95 individual collections 
> > (https://github.com/ansible-community/ansible-build-data/blob/main/5/ansible.in)
> > - Of these 95 collections, there's only about a dozen that are already 
> > packaged (I wrote down some notes here: 
> > https://hackmd.io/iAloYlTQQ3e-yi99w_o54A)
> > - The versions of individually packaged collections could diverge from 
> > those shipped inside the 'ansible' package (ex: 
> > https://github.com/ansible-community/ansible-build-data/blob/main/5/ansible-5.0.0a2.deps)
> > - Even considering we develop tooling and automation around the process, it 
> > would still be error prone and a lot of work without mentioning the 
> > administrative overhead of maintaining 95+ packages
> >
> > In short: it would require a non-negligible amount of effort to
> > package each individual collection, keep them updated while in sync
> > with the versions that the upstream package ships without conflicts.
>
> The Change proposal is not very clear in this regard… Please correct me
> if I'm wrong, but my understanding is that there's a giant SRPM which
> produces a giant 'ansible' binary package. In addition there's a second
> small SRPM which produces the 'ansible-core' binary package.
>
> When I'm reading Richard's proposal, I understand it as a giant SRPM
> package + ~95 binary packages. In your answer, you are clearly discussing
> ~95 SRPM packages with ~95 binary packages.

There is no SRPM, because no one has successfully packaged it. There
is a very bulky upstream tarball, and it is peculiarly constructed.
and it is mislabeled because all of its contents except some
ansible.egg-info files wind up in
/usr/lib/python3.x/site-packages/ansible_collections/, and are
referred to in python based on that location and with the prefix name
"ansible_collections", not "ansible".

I've gotten a vaguely built RPM for it, for RHEL use, but I'm having
some issues with the "pwsh" and other pecularities of "ansible-core"
and it needs some work before I can install and test both. Backporting
ansible-corre to my preferred working environments is more important
for me than installing more than half a Gigabyte of modules I don't
want, or need, to provide a few choice modules from the "ansible"
package. Life also gets a bit weird with python2 still being
/usr/bn/python on RHEL 7 based systems: that's a concern for EPEL.

> I agree that ~95 separate *source* packages is not a good approach:
> - the obvious reason is the packaging overhead you mention
> - but a more subtle reason is that upstream will test those 95 packages
>   in the versions listed in 'ansible' pypi package, so we want them in
>   the exact versions specified in the 'ansible' pypi package, and not
>   in the latest version each of those upstreams may have released.

Why not? One github repo, one source tarball, one package. Ignore the
pypi.org published tarball, it's way too big and clunky.

Since I've seen previously that Fedora packaging standards are to
follow pypi.org packaging OK. Use the tarball if needed. But yeah,
the submodules are easily split in the .spec file.

> But the approach with 1 SRPM and many *binary* packages 

Re: Fedora minimum hardware requirements

[Nico Kadel-Garcia]

Is it worth paying hundreds of MBytes of installer space, and the new
2 GB minimum RAM to simply install Fedora? I'm not saying "discard
anaconda". I'm saying "be aware of some very real reasons the
installer has gotten so huge". And keep it in mind for your own
projects.

On Sun, Oct 17, 2021 at 4:32 PM Robby Callicotte via devel
 wrote:
>
> On Sunday, October 17, 2021 3:05:13 PM CDT Dan Čermák wrote:
> > They are also much more intuitive to use for your average user/ newcomer
> > to Linux in contrast to a text interface (which will put them off when
> > compared to the Windows or Ubuntu installer). Yes, a text interface is
> > much more resource friendly, but imho that will cause more harm than
> > actual benefit.
>
> I totally agree.  If presented with only a text interface, I believe that new
> Linux users would perceive the install experience as either too daunting or
> not up to par with other distros.
>
> Robby
>
>
> ___
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora minimum hardware requirements

[Nico Kadel-Garcia]

On Sun, Oct 17, 2021 at 3:36 PM Chris Murphy  wrote:
>
>
>
> On Sat, Oct 16, 2021, 10:01 PM Kevin Kofler via devel 
>  wrote:
>>
>>
>>
>> I still remember how Red Hat Linux and (IIRC) Fedora Core 1 could be booted
>> from a floppy (older Red Hat Linux releases even had a fully functioning
>> rescue mode on the floppy, later ones could at least still boot a HDD
>> install from the boot floppy, which is how I installed them, and in that way
>> also boot the rescue mode). These days, the minimum boot image (know known
>> as the netinst ISO) barely fits on a CD, and in Fedora 33 even exceeded CD
>> size (https://pagure.io/minimization/issue/23). The Fedora 34 netinst image
>> is still 450 times the size of a floppy!
>
>
>
> The top two reasons for this: a significant portion of anaconda used to be 
> downloaded, and now is included on the media; linux-firmware bloat, which is 
> the fastest growing package for the past few years. Front this point there's 
> a bunch of pressure points and trade-offs. This cycle we were over CD-ROM 
> size of 700MiB, and ended up trimming out about 30M from linux-firmware.
>
> --
> Chris Murphy

It's also X based with GUI's, rather than an ncurses based graphical
interface. Reviewing a fresh install, there is little to nothing that
couldn't be done in a much, much smaller text interface going through
a linear checklist with ncurses, and follow Eric Raymond's old
guidelines for open source interfaces titled "The Luxury of
Ignorance". But some folks like pretty GUIs, even though sophisticated
GUI's cost resources to run.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Ansible 5 (Self-Contained Change proposal)

[Nico Kadel-Garcia]

On Sat, Oct 16, 2021 at 10:22 PM Kevin Fenzi  wrote:
>
> On Sat, Oct 16, 2021 at 08:51:46PM -0500, Maxwell G via devel wrote:
> >
> > Hi everyone,
> >
> > I have a couple comments/questions about this change.
> >
> > How will this effect EPEL? Is the plan to keep Ansible 2.9 there for
> > now?
>
> For now yes, but 2.9 will go EOL at the end of the year (last I heard).

I think someone is being very, very optimistic. It's especially tricky
because EPEL does not keep previously released versions of software in
their primary repos. If ansible the github tagged ansible 2.10,
rebundled as ansible-core

> > Could we also consider making Ansible a modular package on both Fedora
> > and EPEL? Then, it would be possible to install any of the currently
> > supported versions of the Ansible core/engine (ansible 2.9, ansible-
> > base 2.10, and ansible-core 2.11).
>
> No thanks. It would be a ton of effort, and those will all EOL soon
> or already have...

Don't count on it. The python 3.8 requirement for ansible-core 2.12
and ansible 5.0, as described at Installing Ansible — Ansible
Documentation is going to case difficulties porting it to RHEL
especially RHEL 7. There are no "python38" or "python310" packages
I've found for RHEL 7, except the SCLO packages which are awkward to
use. Many people have been very, very reluctant to update to RHEL 8
and CentOS 8 for various reasons, so I expect to see some demand for
ansible to roll back that pending required python update, or perhaps
EPEL to organize a python310 suite of python components.

> (from the ansible 4.7.0 release announcement:
>
> "* Except for ansible-2.9.x, older versions of ansible are no longer
> seeing maintenance releases."
>
> > Will the new `ansible` package have virtual provides for the
> > collections it provides? While there is not a good reason to, it will
> > still be possible to install both the new `ansible` package and any of
> > the ansible-collection-* packages, right?
>
> I don't think we will do provides, that would cause problems installing
> the stand alone collections. So, yeah, we want to be able to install the
> stand alone collections along with or in addition to the bundle.

I'd prefer "instead of". That might require a more complete set of
collection components, to avoid installing "ansible" and potentially
conflicting.

> > Also, I would be happy to help with Ansible packaging in Fedora;
> > however, I am not yet part of the packager group and still need a
> > sponsor.

You'll also need a stiff drink. The process is slow because of the
size of the monolithic collection, and the cleanups needed to get all
the docs and licenses packaged.

> Thanks. I appreciate the PR's... :)
>
> kevin
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Ansible 5 (Self-Contained Change proposal)

[Nico Kadel-Garcia]

On Sat, Oct 16, 2021 at 3:03 PM Gordon Messmer  wrote:
>
> On 10/15/21 16:29, Nico Kadel-Garcia wrote:
> >
> > I would publish ansible-core as just that, with a "Provides: ansible
> > %{version{-%{release}" and even "Obsoletes: ansible >= %{version}".
> ...
> > The "ansible" package could be a
> > meta package with "Requires: ansible-core ansible_collections" to
> > avoid the versioning confusion.
>
>
> Those two things can't both be done, though, can they?  If the
> "ansible-core" package provides and obsoletes "ansible", then users
> wouldn't be able to install the "ansible" package that requires
> ansible_collections.

They *can* physically, but doing both together would get very silly.
I'd meant "do one or the other". The current model of "install
ansible, get a few Megabytes of material you actually use that is
almost entirely in ansible-core and 576 Megabytes of bulky material,
more than 90% of which you will never use" is awkward, and I'd much
rather see the galaxy collection packages published, and remain,
distinct. Discard the "ansible" package as an unwelcome approach, it's
too big and too confusing.

It does make me wish I'd been on the IRC channels that came up with
this bundling to walk through the concerns much earlier. In practical
terms and the relationship between Red Hat sponsored software like
Ansible, and Fedora development,  I acknowledge that it may be too
late to revise. But that "too late" is a political and social issue,
not necessarily a technical one.

> As a practical matter, I don't see any functional difference between the
> proposed change (publishing an ansible-core package, and an ansible
> package that contains collections) and your suggested alternative
> (publishing an ansible-core package, and an ansible package that
> requires collections), unless we disregard the meta package.

It distinguishes the newly bundled ansible-core, which OK, that made
sense to fragment, from an extremely bulky and therefore brittle
bundle that is mostly unwelcome, even dangerous.

> Publishing an ansible-core package that provides "ansible" (or more
> specifically python3.Xdist(ansible)) wouldn't be compatible with the
> updated Python packaging policy, which requires PyPI parity.

If that's the locked in policy, and no exceptions. then I'd agree that
we as Fedora and as RHEL users are stuck with following PyPi and
ansible off the cliff in this case.

What, then, about the existing
ansible-collection-ansible-netcommon-2.2.0-1.fc35.src.rpm and the
like? Would those be swept up as part of the "ansible" package? I'd
dislike that, and if we or the current maintainers can keep them
separate, it presrves the groundwork for a much more modular and much,
much smaller ansible deployment.

>  Anything
> that provides python3.Xdist(ansible) needs to provide at least a
> complete compatible interface with the package from PyPI, and an
> "ansible-core" package wouldn't.

That is a potential problem. Upstream broke it with the renumbering
without generating a distinct package. I don't think anyone or
anything will "Requires:" the new ansible package in RPM except as a
legacy entry for software that really relies on python components in
"ansible-core". I think they'll specifically need to import from
'ansible_collections' to get those individual python modules. It's
very messy.

There were a stack of options when ansible split up. Fedora is going
to have to deal with this peculiar layout one way or another. For
anyone who packages the new pypi "ansible" modules, I've some notes,
such as "rename the files with whitespace in their names", "Exchange
'#!/usr/bin/python' for '#!/usr/bin/python3'" and "#!/usr/bin/python'
for '#!/usr/bin/python3' for better cross-platform behavior, and
beware excessively long '%doc' and '%license' files with hundreds of
quite long entries.


> ___
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Ansible 5 (Self-Contained Change proposal)

[Nico Kadel-Garcia]

On Fri, Oct 15, 2021 at 11:39 PM Kevin Fenzi  wrote:
>
> On Fri, Oct 15, 2021 at 07:44:12PM -0400, Nico Kadel-Garcia wrote:
> > On Fri, Oct 15, 2021 at 7:29 PM Nico Kadel-Garcia  wrote:
> > >
> > > On Fri, Oct 15, 2021 at 4:32 PM Ben Cotton  wrote:
> > > >
> > > > https://fedoraproject.org/wiki/Changes/Ansible5
> > > >
> > > > == Summary ==
> > > >
> > > > The ansible project has re-organized how they release and distribute
> > > > ansible. This change moves Fedora to be in sync with those changes and
> > > > retires the old 'ansible classic/2.9.x' package in favor of a
> > > > 'ansible' package that pulls in ansible-core (the engine) and includes
> > > > all the collections in upstream ansible releases.
> > >
> > > I wrote to the various upstream bugtrackers about this already. The
> > > re-org upstream is confusing and unwelcome, and creates a stack of
> > > problems.
>
> Yeah, it's been confusing to people for sure, but it does also help out
> a lot with other problems. :(

it could have made good sense, and still would, for the "ansible"
package to be what is now being colloquially referred to as
"ansible-core", but for which the published upstream git repo is still
https://github.com/ansible/ansible, and which is and will remain
accessible as a github release tarball with the old numbering. The
pypi.org published "ansible-core" is a republication of that repo with
a new name duck-taped on it. Fragmenting out the bulky and potentially
dynamic set of tools that are now in the "galaxy collections" suite
makes some sense, but the result is that to get any of the core
modules like "ansible.posix"  we wind up including 573 Megabytes of
unneeded and unwelcome debris in
/usr/lib/python3.6/site-packages/ansible_collections. Very few of us
need more than 10% of the list

There is no specific source repository for the "ansible_collections"
tarball, as best I can tell. The list of modules selected from the
galaxy collection is very large, but incomplete and I've not seen any
criteria for what goes in that tarball and what does not. Have you
seen any?

I'd suggest that discarding the pypi.org renaming and instead using
the raw tarballs from github as sources for individual galaxy
collection modules helps resolve. This would keep the numbering of the
"ansible" RPM consistent, and its core functionality. The modules
which have been shifted to the galaxy collection, such as the "ec2"
and "cisco" modules, could and should be bundled individually as
Fedora has been doing quite effectively. I did some tests: an RPM of
the current pypi.org tarball mislabeled as "ansible" occupies more
than 570 MBytes of local disk. If you want a lightweight Ansible
setup, say for applying some playbooks to your localhost, it's an
unreasonable burden.

Those numbers do not include the documentation: The sphinx build of
the HTML docs is something I've tried, but so far is not working with
my test SRPM. As it is, I've had to rename doc or license files that
have " " in the filename because the '%doc' and '%license' macros do
not like whitespace in filenames, and split them up because a
'%license' or '%doc' that have so many hundreds of entries overwhelms
SRPM scripting. Packaging up the individual modules or sets of modules
individually avoids this unwelcome burden.

> > > I would publish ansible-core as just that, with a "Provides: ansible
> > > %{version{-%{release}" and even "Obsoletes: ansible >= %{version}".
>
> That would radically diverge from upstream and cause _more_ confusion.

Upstream already confused people. I don't think it justifies repeating
their bundling mistakes, mistakes that are not reflected in the
upstream source code for the software but only in intermediate
repackaging and which Fedora has so far effectively avoided.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Ansible 5 (Self-Contained Change proposal)

[Nico Kadel-Garcia]

On Fri, Oct 15, 2021 at 7:29 PM Nico Kadel-Garcia  wrote:
>
> On Fri, Oct 15, 2021 at 4:32 PM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/Ansible5
> >
> > == Summary ==
> >
> > The ansible project has re-organized how they release and distribute
> > ansible. This change moves Fedora to be in sync with those changes and
> > retires the old 'ansible classic/2.9.x' package in favor of a
> > 'ansible' package that pulls in ansible-core (the engine) and includes
> > all the collections in upstream ansible releases.
>
> I wrote to the various upstream bugtrackers about this already. The
> re-org upstream is confusing and unwelcome, and creates a stack of
> problems.
>
> I would publish ansible-core as just that, with a "Provides: ansible
> %{version{-%{release}" and even "Obsoletes: ansible >= %{version}".
> The new pypi.org tarball published as "ansible" isn't. It's a tarball
> of components from the Ansible galaxy collection, and it is
> unnecessary for the basic ansible-core operation, which are much
> bulkier than the previous "ansible" and contains approximately 145
> distinct software licenses. That is a sign of a packaging problem
> that I've discussed on the pypi.org issues pages, at

I realize I was unclear. The new "ansible" tarball from pypi.org has
145 distinct software licenses, and many distinct galaxy collection
published ansible modules. The new "ansible-core" tarball is much
smaller, even smaller than the old "ansible" package due to some bulky
modules being transferred to the galaxy collection.

Splitting off the variety of add-on modules makes sense. Replacing the
core package with the add-on modules and moving aside the core seems
exactly backwards.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Ansible 5 (Self-Contained Change proposal)

[Nico Kadel-Garcia]

On Fri, Oct 15, 2021 at 4:32 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/Ansible5
>
> == Summary ==
>
> The ansible project has re-organized how they release and distribute
> ansible. This change moves Fedora to be in sync with those changes and
> retires the old 'ansible classic/2.9.x' package in favor of a
> 'ansible' package that pulls in ansible-core (the engine) and includes
> all the collections in upstream ansible releases.

I wrote to the various upstream bugtrackers about this already. The
re-org upstream is confusing and unwelcome, and creates a stack of
problems.

I would publish ansible-core as just that, with a "Provides: ansible
%{version{-%{release}" and even "Obsoletes: ansible >= %{version}".
The new pypi.org tarball published as "ansible" isn't. It's a tarball
of components from the Ansible galaxy collection, and it is
unnecessary for the basic ansible-core operation, which are much
bulkier than the previous "ansible" and contains approximately 145
distinct software licenses. That is a sign of a packaging problem
that I've discussed on the pypi.org issues pages, at

The new "ansible" labeled pypi.org module has no full provenance I've
been able to find. It assembles a number of distinct galaxy collection
published re[ps from https://github.com/orgs/ansible-community/, but
assembled without any reference tool that I can find or detect any
documentation for. I'd say that this is messy and not ready for
bundling, and hope that its authors can clean this up.

Given choices I'd publish the "ansible_collections" tarball as just
such an RPM, since it is installed in
/usr/lib/python3.[subversion]/site-packages/ansible_collections/ and
should have been labeled that way. The "ansible" package could be a
meta package with "Requires: ansible-core ansible_collections" to
avoid the versioning confusion.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 3x slower boot than F34

[Nico Kadel-Garcia]

On Sun, Sep 5, 2021 at 4:10 AM Vitaly Zaitsev via devel
 wrote:
>
> On 05/09/2021 09:19, Peter Boy wrote:
> > Much to my chagrin, you describe the biggest problem in Fedora for years 
> > and the one why Fedora is falling further and further behind among 
> > distributions. The problem overshadows all that many positive features that 
> > otherwise distinguish Fedora.
>
> SELinux has saved Fedora users from many critical vulnerabilities (eg.
> telnetd RCE CVE last year). This is a last line of defense.

You're referring to CVE-2020-10188? Who that is sane runs telnetd
these days, or lets it past their firewalls? It's an unencrypted
protocol vulnerable to packet sniffing. I'm afraid it's a poor example
of the benefits of SELinux: if you're running telnetd, you generally
have *much* bigger problems.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 3x slower boot than F34

[Nico Kadel-Garcia]

On Fri, Sep 3, 2021 at 12:52 PM Chris Murphy  wrote:
>
> Bug 2001057 - F35 boots 3x slower than F34, large time gaps in systemd journal
> https://bugzilla.redhat.com/show_bug.cgi?id=2001057
>
>
> This one really has gotten my goat. I'm not finding any reason why
> it's taking this long to boot. Usually the critica-chain or svg plot
> exposes the culprit but not in this case, I just have multiple 10s+
> gaps in the journal.
>
> I might have to do some tedious regression testing by doing a clean
> install of 35 to see if it's some artifact of upgrading from 34. But
> it'd be nicer if I can just directly expose the culprit(s).

So disable SELinux and time it?
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure