Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)

[Ewoud Kohl van Wijngaarden]

On Thu, Jul 06, 2023 at 08:17:27PM -0500, Michael Catanzaro wrote:
On Thu, Jul 6 2023 at 07:42:47 PM -0400, Demi Marie Obenour 
 wrote:

Then make the metrics be neither opt-in nor opt-out.  Have
“Enable telemetry (y/n)?” be a mandatory question in the installer,
which the user must answer.


The problem is if users are expected to answer, they are going to 
probably answer No and it's effectively the same as an opt-in. But if 
we have a default value, users will be inclined to leave the default 
value.


So you do not trust users to answer the way you want? So much for 
respecting your users.

___
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: How to deal with sysusers files inside the package

[Ewoud Kohl van Wijngaarden]

On Fri, Jun 30, 2023 at 10:15:35PM +0200, Björn Persson wrote:

Ewoud Kohl van Wijngaarden wrote:

I'm looking at converting my package (where I'm also the upstream) to
use sysusers.d but I'd prefer shipping the sysusers.d file inside the
source tarball rather than in packaging. This allows me to use the same
definition on Debian, which I think is a huge benefit of systemd
standardizing these kinds of things.


Yes, of course you'd want to do it that way, but Fedora isn't ready.


I got the same impression.


The documentation[1] only mentions shipping it as a separate source, not
inside the tarball. Should I simply replace %{SOURCE3} in the docs with
the path from the extracted tarball?


My experience is that sysusers_create_compat can't be made to work with
a file extracted from the tarball. It requires a separate source file.
As long as user and group accounts must be added in the packaging, it's
more convenient to do it in the spec file than in a separate sysusers
file. Thus sysusers_create_compat seems rather useless to me.


I wouldn't say completely useless, but useless in the ideal case.


If your program needs its user account only at run time (such as a
daemon that runs as non-root), then it's enough to drop the sysusers
file into /usr/lib/sysusers.d. The account will then be created at the
end of the RPM transaction, after all the packages have been installed.
In that case shipping the sysusers file inside the tarball should work,
and you don't need sysusers_create_compat.

If your package contains any files owned by the account it creates,
then installing the sysusers file is not sufficient. In that case the
account must be created in %pre before the files are installed, either
with sysusers_create_compat (which requires a separate source file) or
with plain old useradd or groupadd.


Sadly, this is the case (owning /var/lib/%{name}).


I've seen some discussion recently about integrating sysusers support
into RPM. That should allow an upstream sysusers file to work in all
cases, if I understand correctly. If your package currently works, then
I suggest waiting until the RPM integration is done before you change
how user accounts are created.


Thanks for the advice.
___
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

How to deal with sysusers files inside the package

[Ewoud Kohl van Wijngaarden]

I'm looking at converting my package (where I'm also the upstream) to 
use sysusers.d but I'd prefer shipping the sysusers.d file inside the 
source tarball rather than in packaging. This allows me to use the same 
definition on Debian, which I think is a huge benefit of systemd 
standardizing these kinds of things.


The documentation[1] only mentions shipping it as a separate source, not 
inside the tarball. Should I simply replace %{SOURCE3} in the docs with 
the path from the extracted tarball? If so, is this something that the 
packaging-guidelines should document?


I also noticed that %sysusers_create_compat isn't in EL8 and I'd rather 
not depend on epel-rpm-macros. Today we build completely outside of EPEL 
and I'd prefer to keep it that way. Is the recommended way to use 
%sysusers_create_package (provided by systemd-rpm-macros) instead?


[1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/
___
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: disabling yum modular repos by default?

[Ewoud Kohl van Wijngaarden]

On Wed, May 10, 2023 at 07:09:49PM +0200, Peter Boy wrote:




Am 10.05.2023 um 18:45 schrieb Kevin Fenzi :

On Wed, May 10, 2023 at 12:21:51PM +0800, Jens-Ulrik Petersen wrote:

Thanks for all the helpful comments and feedback,
though more is still welcome of course.
So I am leaning now towards not installing fedora-repos-modular by default
(rather than disabling the modular repos by default): also for upgrade
compatibility.

I have started a Change proposal draft, which I think should be ready soon,
with current working title *"Turn off modular dnf repos by default"*.
Perhaps *"No default fedora-repos-modular"* would be more precise.
Or any better suggestions (that don't sound like modularity is being
removed)?

I think the actual work (PR's) required is not huge,
but if someone is particularly keen to join the effort let me know.


So, at the risk of opening a larger can of worms...and increasing the
scope here beyond what you have any desire to do...

Should we consider just retiring modular repos entirely?

I do know there's a number of active module builds, but I am not sure
how much users use them. While RHEL still uses modules, EPEL has retired
their epel8 modular repos.

Can the things using modules now switch to compat packages in the main
repository?

I realize we may want to just say 'no, not now' here, but I thought I
would bring it up.



I suppose I would belong to the latter. From a Server admin’s POV the modules 
are a great chance to keep some backwards compatibility with our fast pacing 
distro. The most prominent example is PostgreSQL. It is not so rare that the 
new major version requires an adjustment in the application programme or at 
least an extensive test. And every major update also requires a migration of 
the entire data stock. Modularisation is a welcome opportunity to quickly 
switch to a new release and use new capabilities, but to carry out the 
adaptation / tests with PostgreSQL at your leisure.

And that is just one example. Another example is changes in languages such as 
Ruby, where application programmes sometimes cannot keep up with the changes. 
Same is true for httpd or tomcat - just some other examples.

If we could manage compat packages or parallel use of different major versions 
(as, for example, the Java runtime environment has managed to provide perfectly 
for decades), then modularisation would probably no longer be needed.


Debian has parallel installation with PostgreSQL. It does mean the major 
versions show up in the DB paths, but I don't think that's a bad thing. 
I think various problems that modularity tries to solve could also be 
solved with parallel installs and sometimes provide a better user 
experience.

___
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: Orphaned packages looking for new maintainers

[Ewoud Kohl van Wijngaarden]

On Mon, May 01, 2023 at 10:26:27PM +0200, Miro Hrončok wrote:

ruby-augeas   brandfbb, ignatenkobrain,0 weeks ago
 orphan


Taken
___
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: redhat-lsb-core

[Ewoud Kohl van Wijngaarden]

On Tue, Apr 04, 2023 at 10:19:56AM -0400, Steven A. Falco wrote:

On 4/4/23 09:56 AM, Neal Gompa wrote:

On Tue, Apr 4, 2023 at 9:49 AM Steven A. Falco  wrote:

On 4/4/23 05:58 AM, ser...@serjux.com wrote:

Please open a bug report , I'm reviewing redhat-lsb [1] , this package is so 
old that still called redhat ...
Anyone suggest another name ?

I'm happy to write a bug.  Do you prefer something along the lines of "Split lsb_release into 
a subpackage" or perhaps "Split redhat-lsb-core into finer-grained subpackages"?

For me, having an lsb_release subpackage would be best, because that is all I 
need for KiCad.  But I'll also pursue Neal's comment about changing wxWidgets 
to get the info another way.



The distro command from python3-distro may also help if you *must* use
a command-line tool.

But reading the file directly would be better.


I've created a bug [2] requesting that wxGTK use a file from os-release rather 
than lsb_release.


Worst case scenario, I could bring over a port of SUSE's lsb_release
package that uses os-release for its data into Fedora[1].


That is a very interesting approach that could potentially help other customers 
of the information.


Given where the Linux ecosystem is today, I think lsb_release should be 
deprecated and no tool should depend on it anymore.


The idea behind LSB is that all systems would have it and tools can 
count on it, but in practice that's not true. os-release is now well 
defined and much more relevant given it's present without installing 
additional tools. So effectively os-release is fulfilling the LSB 
promise, but on a much smaller scope.


Investing in lsb_release feels like a wasted effort.
___
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: How to depend on a .so.X in RPM specs?

[Ewoud Kohl van Wijngaarden]

On Mon, Mar 06, 2023 at 02:27:46PM +0100, Vít Ondruch wrote:


Dne 06. 03. 23 v 12:49 Ewoud Kohl van Wijngaarden napsal(a):
While rubygem-openscap is retired in Fedora, the Foreman project 
still packages it.


For context: rubygem-openscap can load libopenscap.so.8 and 
libopenscap.so.25 through FFI. Today we depend on a specific 
version, but every time it's bumped we go through a verification to 
see if the SO version hasn't been bumped.


At first I started with a trivial Requires: libopenscap.so.25 but 
that pulls in both openscap for i686 and x86_64. Directly depending 
on
libopenscap.so.25()(64bit) feels wrong, so what is the correct 
approach here? Is there some helper macro here?



https://src.fedoraproject.org/rpms/rubygem-ruby-vips/blob/rawhide/f/rubygem-ruby-vips.spec#_29-30


This is the solution that I was looking for. It only installs 
openscap.x86_64 and not openscap.i686.


The ISA based approach doesn't work since it's a noarch package, meaning 
the __isa* macros are unavailable.


Thanks everyone for your help.
___
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: How to depend on a .so.X in RPM specs?

[Ewoud Kohl van Wijngaarden]

On Mon, Mar 06, 2023 at 01:27:18PM +0100, Jarek Prokop wrote:

Interesting situation.

On 3/6/23 12:49, Ewoud Kohl van Wijngaarden wrote:
While rubygem-openscap is retired in Fedora, the Foreman project 
still packages it.


For context: rubygem-openscap can load libopenscap.so.8 and 
libopenscap.so.25 through FFI. Today we depend on a specific 
version, but every time it's bumped we go through a verification to 
see if the SO version hasn't been bumped.


A bit of a tangent first.
This sounds like it could be checked via a "simple" FFI load check in 
%check section, in ruby, something like:


~~~

require 'ffi'

module Check
  extend FFI::Library
  ffi_lib 'libopenscap.so.25'
end
~~~

This will throw an exception if the .so is not available.


This is indeed pretty much how the code looks:
https://github.com/OpenSCAP/ruby-openscap/blob/master/lib/openscap/openscap.rb

So adding a verification step in %check is actually a good idea, though 
I'd also consider including the actual class rather than a mock.




At first I started with a trivial Requires: libopenscap.so.25 but 
that pulls in both openscap for i686 and x86_64. Directly depending 
on
libopenscap.so.25()(64bit) feels wrong, so what is the correct 
approach here? Is there some helper macro here?


There are *some*, but nothing universal it seems. JFTR other packages 
that require libs like this are (and make use of some _isa macros):


cross-gcc.spec
ghdl.spec
glib2.spec
julia.spec
libreoffice.spec
redhat-lsb.spec
systemd.spec
asahi-installer.spec

You can grep through all specfiles using this tar: 
https://pkgs.fedoraproject.org/repo/rpm-specs-latest.tar.xz


I'd recommend reading the systemd and Julia files as inspiration, 
those 2 seem to be doing what you are speaking of.


tl;dr those spec files indicate you need to conditionally depend on 
both, depending on whether it is 32 or 64bit build.


Those look very useful. The __isa_bits part in systemd.spec looks like 
what I've been looking for.


Technically speaking I think it should depend on what rubygem-ffi 
can load, but on x86_64 that's probably 64 bit only. However, this 
is a bit out of my knowledge area.


This could, in theory, be checked in the %check section of the package 
as I indicated above, if you add the same to BuildRequires, even if it 
won't help if openscap changes the .so version.


Will do, this has been very useful.



For completeness, the discussion started in a PR:
https://github.com/theforeman/foreman-packaging/pull/9051

___
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

How to depend on a .so.X in RPM specs?

[Ewoud Kohl van Wijngaarden]

While rubygem-openscap is retired in Fedora, the Foreman project still 
packages it.


For context: rubygem-openscap can load libopenscap.so.8 and 
libopenscap.so.25 through FFI. Today we depend on a specific version, 
but every time it's bumped we go through a verification to see if the SO 
version hasn't been bumped.


At first I started with a trivial Requires: libopenscap.so.25 but that 
pulls in both openscap for i686 and x86_64. Directly depending on
libopenscap.so.25()(64bit) feels wrong, so what is the correct approach 
here? Is there some helper macro here?


Technically speaking I think it should depend on what rubygem-ffi can 
load, but on x86_64 that's probably 64 bit only. However, this is a bit 
out of my knowledge area.


For completeness, the discussion started in a PR:
https://github.com/theforeman/foreman-packaging/pull/9051
___
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: fkinit -u instructions

[Ewoud Kohl van Wijngaarden]

On Tue, Feb 14, 2023 at 06:10:39PM +, Kenneth Goldman wrote:

-Original Message-
From: Clemens Lang 
Sent: Tuesday, February 14, 2023 12:59 PM
To: Development discussions related to Fedora



>> Someone posted that the prompt for an OTP can be ignored and that the
>> Fedora password is enough.
>
> IIRC, if you *have* an OTP, you have to include it. If you *don't*
> have one, of course you just put your password. We should make this
> clear too (assuming I'm right).

You are right, but fkinit will tell you, so I don’t think we need to clarify 
this in
the documentation:


:) cllang@frootmig:~$ fkinit -u clang
Enter your password and OTP concatenated. (Ignore that the prompt is for
only the token) Enter OTP Token Value:
:) cllang@frootmig:~$


For a newbie (me), it's not clear what the OTP is.  Is it something from here?


Perhaps it should spell out One Time Password. Just as 2FA should 
probably be written as two-factor authentication.



https://accounts.fedoraproject.org/user/kgold/settings/otp/

If correct, might a link be useful, along with some guidance on then to use it?


It does indeed refer to 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: SPECfiles - conditionals with EOLed Fedora releases - any value in keeping them ?

[Ewoud Kohl van Wijngaarden]

On Thu, Jan 19, 2023 at 04:13:02PM +0100, Michal Schorm wrote:

On Thu, Jan 19, 2023 at 4:04 PM Ewoud Kohl van Wijngaarden
 wrote:

>Do you agree it would be safe to remove such conditionals and the code
>they hold ?

Only if they're purely for Fedora. In many examples you also see a rhel
conditional and that could be used for EPEL. A good number of packagers
like to use the same spec since it reduces maintenance burden on
updates. So in that case the mentioned RHEL/EPEL version should also be
EOL.


I agree.
I'd just add that the same may apply to the %{rhel} macros too - Is
there any need to check for *EOLed* RHEL releases?


That's what I also suggested.

In Fedora we can reasonably say we mostly care about EPEL and if that 
goes EOL then it's actually removed from the mirrors.


In theory people could keep the spec compatible so users can manually 
rebuild for older release, even if Fedora infrastructure doesn't. Hence 
why I suggested SHOULD rather than MUST.



I'm not sure this is great. For example, it may introduce revbumps,
which can cause a package rebuild but in the resulting RPM these should
make no difference (otherwise they wouldn't be safe).

To me the right time is to on version bump of a package where you're
already making changes anyway.


I don't see a need to make a bump and build for every change, only for
changes that are expected to be built.
There are mass rebuilds anyway, so it will be bumped and built eventually.


I'm used that for each release there is also a build. My assumption was 
that rpmautospec would create a release, but if it's skipped then my 
objection would be gone.


To be clear, I'd actually like to see robots sending in pull requests. 
Many version bumps are actually trivial and the-new-hotness could send a 
pull request. In a similar way I can see some sort of nanny cleaning up 
specs in an automated fashion doing the same. For example, conversion to 
SPDX license tags feels like a good candidate (if there's no ambiguity).


If this is automated then it should be easy to opt-out on a repository 
basis.


On Debian there is lintian-brush[1] which has a similar objective.

[1]: https://salsa.debian.org/jelmer/lintian-brush
___
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: SPECfiles - conditionals with EOLed Fedora releases - any value in keeping them ?

[Ewoud Kohl van Wijngaarden]

On Thu, Jan 19, 2023 at 11:52:04AM +0100, Michal Schorm wrote:

While playing around with Sourcegraph, which indexed all Fedora
package repositories, I was able to craft a query listing all '%if'
conditionals referencing Fedora releases that reached EOL.

https://sourcegraph.com/search?q=context:global+repo:%5Esrc%5C.fedoraproject%5C.org/rpms+file:.spec+%28%25if.*%25%7B%5C%3Ffedora%7D.*%5B%3C%3D%3E%5D.*%29%28%5B12%5D%5B0-9%5D%7C%5B3%5D%5B012345%5D.*%29+count:all&patternType=regexp&case=yes&sm=0&groupBy=group

I don't believe such conditions have any value and I think we can
remove them right away.
I think the removal shouldn't affect neither Fedora nor derived
operating systems.

If removed, they will be preserved in the git history anyway, for
anyone seeking historical code.

In some cases the conditionals hold patches that could be removed with them:

https://sourcegraph.com/search?q=context:global+repo:%5Esrc%5C.fedoraproject%5C.org/rpms+file:.spec+%28%25if.*%25%7B%5C%3Ffedora%7D.*%5B%3C%5D.*%29%28%5B12%5D%5B0-9%5D%7C%5B3%5D%5B0123456%5D.*%5Cn%2B%29%28.*%5Cn%3F%29%28%25patch.*%29+count:all&patternType=regexp&case=yes&sm=0&groupBy=group

--

Do you agree it would be safe to remove such conditionals and the code
they hold ?


Only if they're purely for Fedora. In many examples you also see a rhel 
conditional and that could be used for EPEL. A good number of packagers 
like to use the same spec since it reduces maintenance burden on 
updates. So in that case the mentioned RHEL/EPEL version should also be 
EOL.



Do you agree that removing obsolete code such as this brings value to
the package codebase ?


Yes, RFC 2119 SHOULD sense.


Would you see a value in e.g. some kind of a robot reminding
maintainers of such obsolete code? (e.g. new RPMinspect or ZUUL CI
check)


I'm not sure this is great. For example, it may introduce revbumps, 
which can cause a package rebuild but in the resulting RPM these should 
make no difference (otherwise they wouldn't be safe).


To me the right time is to on version bump of a package where you're 
already making changes anyway.

___
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: [Modularity] XML format for in-repository modules

[Ewoud Kohl van Wijngaarden]

On Wed, Dec 07, 2022 at 02:23:18PM +0100, Petr Pisar wrote:

Those who should be concerned most are DNF5 developers and relengs producing
composes.


There are third party repositories which also publish modular metadata. 
I know this because in yum.theforeman.org we do this. Do we fall under 
relengs producing composes?



If you are interested in it, I recommend starting with overview.xml file. It
shows a skeleton of the format. It's so small I can quote it here:

http://fedoraproject.org/metadata/moduleindex"; version="" 
revision="">
   

   
   
   ...
   


Is comunity a typo for community?


A grand plan how to implement and deploy this format is outlined in
top-level README.md
.
Basically it will be injected into createrepo_c tool to produce the XML data
in YUM repositories.


I really like integration into the existing tooling like createrepo_c. 
That was a massive gap in functionality. The plan is rather light on 
these details so I'd be interested to see how you plan to expose this 
functionality.

___
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: Policy on supporting old and external software packages and compat RPMS

[Ewoud Kohl van Wijngaarden]

On Tue, Dec 06, 2022 at 03:44:37PM +, Terry Barnaby wrote:

On 06/12/2022 10:40, Dominik 'Rathann' Mierzejewski wrote:

On Tuesday, 06 December 2022 at 07:43, Terry Barnaby wrote:
[...]

My view is that compat versions of the commonly used shared libraries
for programs that are used on Redhat7 should be kept available until
most people are not producing programs for that system at least
+nyears and then I guess Redhat8 once that really becomes a core base
platform that external people use. A core list of these (there are
only a few) could be kept somewhere and when one is to be depreciated,
or users see problems when Fedora is updated,  a decision on this can
be then made with that info. This would keep the Fedora system
relevant for more users needs without too much work.

Well, that is still *some* work and someone would have to do it. Are you
volunteering?


In the case of ncurses, it is really just putting back into the SPEC
file that which was removed for F37 plus the extra storage on mirrors
for the compat RPM's.

If it's "just" that, why don't you do it yourself? Obviously, the
current ncurses maintainer decided it was time to drop the old v5 ABI
compat libs from the package. However, nothing is stopping you from
picking that up and maintaining an "ncurses5" package for as long as you
need it.

Regards,
Dominik


Well in this case I have created a suitable compat lib, all I did was 
re-introduce the bits to the SPEC file that removed the building of 
the compat lib and we are fine. I haven't separated it out from the 
main ncurses SPEC through and have only done this locally as I have no 
knowledge of the hoops to create a separate package and that seems 
like the wrong way to do this in general. I have made this available 
to others who will be in the same boat.


But the purpose of my thread here is a more general Fedora policy 
question as it affects users of Fedora as to what applications the OS 
is likely to support. If the policy is to just support Fedora built 
binaries within the particular version of Fedora and to ignore 
external and commercial binaries built with say Redhat7 and provide no 
degree of compatibility so be it, but it would be useful for everyone 
to know where the land lies and be on the same page. The maintainer of 
the ncurses package wasn't sure of the policy on this. In my case, a 
lack of being able to easily run particular external/commercial 
programs built for Redhat7 will likely move me further away from 
working with Fedora (using, reporting bugs, promoting it etc.) as it 
will be a less useful system for our usage.


I'm not in charge of policy, but I always assumed it was based on 
technical possibilities (within reason) and people wanting to invest 
time in it.


Open source is for me all based on fixing your own issues and doing it 
in such a way that it others can benefit from it too. If you have a use 
case for something and are willing to spend the time to keep it alive 
while not limiting others, Fedora can support 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Prevent from building RPM packages providing python3dist(...) = 0 (Self-Contained Change proposal)

[Ewoud Kohl van Wijngaarden]

On Tue, Nov 22, 2022 at 12:10:39PM +0100, Karolina Surma wrote:

On 11/15/22 12:42, Ewoud Kohl van Wijngaarden wrote:

On Tue, Nov 15, 2022 at 12:35:32PM +0100, Karolina Surma wrote:

On 11/15/22 08:37, Mattia Verga via devel wrote:

Il 15/11/22 00:23, Neal Gompa ha scritto:

On Mon, Nov 14, 2022 at 6:03 PM Kevin Kofler via devel
 wrote:

So let me sum up:


Some Python building backends, eg. setuptools, explicitly allow
creating package with version `0.0.0` when the version used by a
project is not known. This was
[https://github.com/pypa/setuptools/issues/2329 discussed upstream]
with conclusion that it's an intended behavior.

Upstream says that it is intended that packages are able to set their
version to 0 or 0.0.0, but…


Based on discussion on python-devel mailing list there will be no way
to opt out from this change. There will be no possibility 
to package a

Python package with version `0`.
… your proposed Change will fail those packages' build with 
no opt-out!? You

cannot be serious!

(Though actually, would %global __provides_exclude_from … 
together with a

manual Provides: python3dist(…) = 0 not work?)

A clear -1 to this Change as proposed.

We've never encountered a situation when packaging the 
version `0` was

the package maintainers intention.
What if it is the *upstream* maintainer's intention? Are we 
now dictating
versioning schemes on upstream projects, disallowing version 
numbers that

upstream setuptools explicitly considers valid?


Unfortunately, I have to agree here. Nobody said we should be
dictating the versions for people. PEP-440 does not even make 0
version illegal, so this is unnecessarily punishing.


IMO, the policy is right, it just have to allow to opt out, so that the
maintainer is informed that **there could be** something wrong with the
package metadata / build process. Maybe an opt-out + file a ticket in BZ
to have track of the opt out, just like the ExcludeArch is the right
approach.

Mattia



Hello,

The standard invocation of the Python dependency generator will be
changed to always run with option like `--fail-if-version-zero`. (This
is the subject of the current proposal.)

Based on your concerns, an opt out mechanism would be added:
If you wanted to bypass the option, you could define a macro in the
specfile, eg.
`%{!?__python_dist_allow_version_zero:--fail-if-version-zero}`

This would allow to build RPMs without bothering with versions. Also, if
it's upstream's decision to use version 0, that would be the way to go.
In Fedora this would give us an insight into how often this is needed.

What do you think of enhancing the proposal this way?


I wonder how many Python packages have ever been packaged with 
version 0. Are we trying to solve a problem that doesn't exist?


Semver recommends[1] starting at 0.1.0 and without proof I think 
today most packages start by following semver. Any old packages that 
predate semver have a version > 0 by now.




Hi Ewoud,

Let me answer to two possible interpretations of your question.

The problem that exists is that you can incorrectly package a Python 
RPM with Provides = 0 (without even knowing it unless inspecting the 
metadata). I feel we could benefit from the proposed Change, if not 
for anything else, then by getting rid of unnecessary steps of 
discovery that a package is wrong (typically when it prevents other 
packages from building/running), opening a Bugzilla and working to fix 
it. That's costly and avoidable, so let's avoid it.


I'm 100% on board with that. Software should be hard to misuse and this 
looks like a case where it's hardly ever (possibly never) what the 
packager intended. That was not what my comment was about.


Does it happen that Python packages have a legitimate version 0 that 
should make it to Fedora? We don't believe so, hence the proposed 
Change, but as the others mentioned, it's not forbidden by PEP 440. 
setuptools and flit will let you create package with 0.0.0. Poetry 
automatically starts versioning the projects at 0.1.0.


That was indeed what my question was about. Yes, in theory a version 0 
or 0.0.0 is possible but is there any proof that this is something that 
has ever been needed?


Providing an opt-out is trivial and if this is what makes the Change 
acceptable for the community, let's do it. It's definitely better than 
forcing people to opt out from the generators altogether.


I'd argue that any code has a cost, even if it's trivial. Code that's 
never executed is likely to be forgotten and/or have bugs.


So in short: this looks like a good proposal to me and I question the 
need for an opt-out.



[1]: 
https://semver.org/#how-should-i-deal-with-revisions-in-the-0yz-initial-development-phase

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Co

Re: F38 proposal: Prevent from building RPM packages providing python3dist(...) = 0 (Self-Contained Change proposal)

[Ewoud Kohl van Wijngaarden]

On Tue, Nov 15, 2022 at 12:35:32PM +0100, Karolina Surma wrote:

On 11/15/22 08:37, Mattia Verga via devel wrote:

Il 15/11/22 00:23, Neal Gompa ha scritto:

On Mon, Nov 14, 2022 at 6:03 PM Kevin Kofler via devel
 wrote:

So let me sum up:


Some Python building backends, eg. setuptools, explicitly allow
creating package with version `0.0.0` when the version used by a
project is not known. This was
[https://github.com/pypa/setuptools/issues/2329 discussed upstream]
with conclusion that it's an intended behavior.

Upstream says that it is intended that packages are able to set their
version to 0 or 0.0.0, but…


Based on discussion on python-devel mailing list there will be no way
to opt out from this change. There will be no possibility to package a
Python package with version `0`.

… your proposed Change will fail those packages' build with no opt-out!? You
cannot be serious!

(Though actually, would %global __provides_exclude_from … together with a
manual Provides: python3dist(…) = 0 not work?)

A clear -1 to this Change as proposed.


We've never encountered a situation when packaging the version `0` was
the package maintainers intention.

What if it is the *upstream* maintainer's intention? Are we now dictating
versioning schemes on upstream projects, disallowing version numbers that
upstream setuptools explicitly considers valid?


Unfortunately, I have to agree here. Nobody said we should be
dictating the versions for people. PEP-440 does not even make 0
version illegal, so this is unnecessarily punishing.


IMO, the policy is right, it just have to allow to opt out, so that the
maintainer is informed that **there could be** something wrong with the
package metadata / build process. Maybe an opt-out + file a ticket in BZ
to have track of the opt out, just like the ExcludeArch is the right
approach.

Mattia



Hello,

The standard invocation of the Python dependency generator will be
changed to always run with option like `--fail-if-version-zero`. (This
is the subject of the current proposal.)

Based on your concerns, an opt out mechanism would be added:
If you wanted to bypass the option, you could define a macro in the
specfile, eg.
`%{!?__python_dist_allow_version_zero:--fail-if-version-zero}`

This would allow to build RPMs without bothering with versions. Also, if
it's upstream's decision to use version 0, that would be the way to go.
In Fedora this would give us an insight into how often this is needed.

What do you think of enhancing the proposal this way?


I wonder how many Python packages have ever been packaged with version 
0. Are we trying to solve a problem that doesn't exist?


Semver recommends[1] starting at 0.1.0 and without proof I think today 
most packages start by following semver. Any old packages that predate 
semver have a version > 0 by now.


[1]: 
https://semver.org/#how-should-i-deal-with-revisions-in-the-0yz-initial-development-phase
___
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: Karma for OpenSSL needed

[Ewoud Kohl van Wijngaarden]

On Tue, Nov 01, 2022 at 12:30:31PM -0500, Jason L Tibbitts III wrote:

Ewoud Kohl van Wijngaarden  writes:



Right now you can't test them since they haven't been migrated to
testing yet.


You can download the packages directly from koji.  From the relevant
update page, you can clock the "Builds" tab which will give you a link.
You can down exactly the packages you need from there.


Ah yes, I forgot that.


Feels a bit like blindly bypassing the tests, right?


Obviously you shouldn't give karma without actually testing, but you are
in ho way prevented from doing so by the current state.  It's just more
convenient to wait until the build is pushed to testing and then out to
the mirrors.


Fair enough, but giving these instructions in the email could be useful 
to speed it up further.

___
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: Karma for OpenSSL needed

[Ewoud Kohl van Wijngaarden]

On Tue, Nov 01, 2022 at 06:22:27PM +0100, Dmitry Belyavskiy wrote:

Dear colleagues,

I've just pushed the updates for OpenSSL fixing 2 CVEs evaluated as HIGH.
Could you please check the freshly pushed builds to get necessary karma
ASAP?

Many thanks!


These would be:

https://bodhi.fedoraproject.org/updates/FEDORA-2022-0f1d2e0537
https://bodhi.fedoraproject.org/updates/FEDORA-2022-502f096dce

Right now you can't test them since they haven't been migrated to 
testing yet. Feels a bit like blindly bypassing the tests, right?

___
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: Node.js Repackaging (Self-Contained Change proposal)

[Ewoud Kohl van Wijngaarden]

On Wed, Sep 07, 2022 at 12:31:27PM -0400, Stephen Gallagher wrote:

On Tue, Sep 6, 2022 at 7:07 PM Ewoud Kohl van Wijngaarden
 wrote:


On Tue, Sep 06, 2022 at 02:28:39PM -0400, Ben Cotton wrote:
>== Benefit to Fedora ==
>=== Packager Benefits ===
>* No more modules to maintain.
>* Availability of multiple Node.js versions in the buildroot means
>that other `nodejs-*` packages can test against multiple supported
>options.
>
>== Scope ==
>* Other developers:
>There should be no need to change any dependent packages, though
>packagers of Node.js software may wish to take advantage of the
>testing opportunities afforded.

How would I, as a packager, deal with this? Will RPM macros be changed?
Should we start to build nodejs-XY-$package similar to how we have
python3-$package (and previously python2-$package) from the source
package python-$package?


The only case where you might need to do this is if you're building an
extension module that needs to be an arch-ful package. For the vast
majority of Node modules, they are noarch.


But what if $package a.b only supports node 16 and $package x.y only 
supports node 20. Looking at /usr/lib/node_modules/npm/node_modules I 
don't see any version numbers in directories so they can't be 
coinstalled. Does it mean you drop the node 16 package once node 20 is 
packaged? It will still be in the load path for node 16 so it could 
accidentally load incompatible code.



What will the new RPM provides be? today it's simply npm($package) but I
can imagine you want to change that to something versioned too.


See above; I don't think that will be needed in the vast majority of cases.


That you say vast majority of cases means there are edge cases. I think 
a proposal needs to address those, even if it's saying that it becomes 
unsupported.

___
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: Node.js Repackaging (Self-Contained Change proposal)

[Ewoud Kohl van Wijngaarden]

On Tue, Sep 06, 2022 at 02:28:39PM -0400, Ben Cotton wrote:

== Benefit to Fedora ==
=== Packager Benefits ===
* No more modules to maintain.
* Availability of multiple Node.js versions in the buildroot means
that other `nodejs-*` packages can test against multiple supported
options.

== Scope ==
* Other developers:
There should be no need to change any dependent packages, though
packagers of Node.js software may wish to take advantage of the
testing opportunities afforded.


How would I, as a packager, deal with this? Will RPM macros be changed? 
Should we start to build nodejs-XY-$package similar to how we have 
python3-$package (and previously python2-$package) from the source 
package python-$package?


What will the new RPM provides be? today it's simply npm($package) but I 
can imagine you want to change that to something versioned too.

___
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: List of long term FTBFS packages to be retired in August

[Ewoud Kohl van Wijngaarden]

On Wed, Jul 20, 2022 at 10:30:14AM +0200, Vít Ondruch wrote:


Dne 19. 07. 22 v 9:58 Ewoud Kohl van Wijngaarden napsal(a):

On Tue, Jul 19, 2022 at 09:48:33AM +0200, Vít Ondruch wrote:

Dear Ewoud,


Dne 12. 07. 22 v 15:16 Ewoud Kohl van Wijngaarden napsal(a):

On Tue, Jul 12, 2022 at 01:03:59PM +0200, Miro Hrončok wrote:

rubygem-bundler_ext jaruga, ruby-packagers-sig, vondruch


I have an interest in this package so I started to look into 
this. It mostly comes down to porting to rspec 3 which I have 
passing.


https://github.com/bundlerext/bundler_ext/pull/23 is the 
upstream PR, I'll look into a packaging PR too.



Would you mind to take over the package from me? I inherited the 
package from previous maintainer together with other packages and 
I was never doing the right job maintaining it, mainly because I 
am not user of the package.


I'd be happy to take it over.



I have transferred the package to you. Thx I lot.


Thanks! I just managed to get an upstream 0.4.2 release out with all the 
fixes and currently pushing that to Fedora. That should resolve 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

Re: List of long term FTBFS packages to be retired in August

[Ewoud Kohl van Wijngaarden]

On Tue, Jul 19, 2022 at 05:17:44PM +0900, Mamoru TASAKA wrote:

Ewoud Kohl van Wijngaarden wrote on 2022/07/19 16:58:

On Tue, Jul 19, 2022 at 09:48:33AM +0200, Vít Ondruch wrote:

Dear Ewoud,


Dne 12. 07. 22 v 15:16 Ewoud Kohl van Wijngaarden napsal(a):

On Tue, Jul 12, 2022 at 01:03:59PM +0200, Miro Hrončok wrote:

rubygem-bundler_ext    jaruga, ruby-packagers-sig, vondruch


I have an interest in this package so I started to look into this. It mostly 
comes down to porting to rspec 3 which I have passing.

https://github.com/bundlerext/bundler_ext/pull/23 is the upstream PR, I'll look 
into a packaging PR too.



Would you mind to take over the package from me? I inherited the package from 
previous maintainer together with other packages and I was never doing the 
right job maintaining it, mainly because I am not user of the package.


I'd be happy to take it over.


BTW are you working on this FTBFS? For now I've added minimum patches to make 
rubygem-bundler_ext rpm
build (with porting to rspec3) and I can commit these changes myself.


Right now I'm trying the upstream route first. I just sent an email to 
the listed contributors who still work for Red Hat to see about a new 
upstream release. That would be easier than carrying downstream patches. 
If not, we can go with a large downstream patch.

___
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: List of long term FTBFS packages to be retired in August

[Ewoud Kohl van Wijngaarden]

On Tue, Jul 19, 2022 at 09:48:33AM +0200, Vít Ondruch wrote:

Dear Ewoud,


Dne 12. 07. 22 v 15:16 Ewoud Kohl van Wijngaarden napsal(a):

On Tue, Jul 12, 2022 at 01:03:59PM +0200, Miro Hrončok wrote:
rubygem-bundler_ext    jaruga, 
ruby-packagers-sig, vondruch


I have an interest in this package so I started to look into this. 
It mostly comes down to porting to rspec 3 which I have passing.


https://github.com/bundlerext/bundler_ext/pull/23 is the upstream 
PR, I'll look into a packaging PR too.



Would you mind to take over the package from me? I inherited the 
package from previous maintainer together with other packages and I 
was never doing the right job maintaining it, mainly because I am not 
user of the package.


I'd be happy to take it over.
___
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: List of long term FTBFS packages to be retired in August

[Ewoud Kohl van Wijngaarden]

On Tue, Jul 12, 2022 at 01:03:59PM +0200, Miro Hrončok wrote:

Dear maintainers.

Based on the current fail to build from source policy, the following packages
will be retired from Fedora 37 approximately one week before branching 
(August 2022).


Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/

The packages in rawhide were not successfully built at least since Fedora 35.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please 
let me know and we can work together to get a FESCo approval for that.


If you see a package that can be rebuilt, please do so.

   Package(co)maintainers
===
rubygem-bundler_extjaruga, ruby-packagers-sig, vondruch


I have an interest in this package so I started to look into this. It 
mostly comes down to porting to rspec 3 which I have passing.


https://github.com/bundlerext/bundler_ext/pull/23 is the upstream PR, 
I'll look into a packaging PR too.

___
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: proposal idea: EOL notifications

[Ewoud Kohl van Wijngaarden]

On Wed, Jul 06, 2022 at 11:47:21AM -0400, Neal Gompa wrote:

On Wed, Jul 6, 2022 at 11:45 AM Zbigniew Jędrzejewski-Szmek
 wrote:


Hi,

In https://pagure.io/fesco/issue/2803 Artem asked for a user-visible
notification when a Fedora stops being supported. Various proposals
for online checks were discussed in the bug, but I think we might make
do with something much simpler.

https://github.com/systemd/systemd/pull/23924 proposes adding
SUPPORT_END=-MM-DD to /usr/lib/os-release. My idea would that we'd
e.g. pop up a desktop notification when that date is close, and a
bigger redder notification once it has been passed. The date could be
set to some initial value even on the initial release, and then
adjusted through updates to fedora-release.rpm if our schedule slips.
I guess we could add a notification during boot in systemd itself, but
most users wouldn't see that, so a graphical notification would also
be needed.

The advantage of this proposal that it is very simple and will work
even on machines that don't have network connectivity, and can be easily
integrated into various DEs and tools.

WDYT?


I like the idea. It's very easy to use and because it's offline it 
doesn't have any privacy considerations. The service can't be offline 
either.



Wouldn't it make sense to have the start date and the time period
supported instead?


It would be more complicated. With an end date you can easily parse it. 
Start date + time period means you need to perform date calculations, 
which is never easy.

___
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

Fedora CI runs tests on the wrong branch?

[Ewoud Kohl van Wijngaarden]

Hello everyone,

I've been taking a look at adding tests to the Puppet package. Initially 
this worked well when I added it to Rawhide[1] and it did what I 
expected.


Now I'm trying to add the same tests to the epel9 branch[2]. It should 
be noted that epel9 is exactly the same as rawhide now (same git commit 
sha) and I think this causes a problem. If you look at the epel9 pr[2] 
you can see the test results for the rawhide pr[1]. You also see a new 
scratch build, but no new dist-git test job. That is incorrect to me.


Is this a known problem/limitation of Pagure/Fedora CI or did I 
misconfigure something?


Regards,
Ewoud

[1]: https://src.fedoraproject.org/rpms/puppet/pull-request/17
[2]: https://src.fedoraproject.org/rpms/puppet/pull-request/18
___
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: Updated criteria proposal: networking requirements

[Ewoud Kohl van Wijngaarden]

On Fri, Jun 03, 2022 at 04:35:41PM -0700, Adam Williamson wrote:

It must be possible to establish both IPv4 and IPv6 network connections
using both typical router-provided addressing systems (e.g. DHCP on
IPv4 or SLAAC or IPv6) and static addressing.


I'd like to see clarification whether this is tested in IPv4-only, 
IPv6-only and dual stack environments. Ideally all 3 are tested but at 
least the environment should be specified.

___
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: Review request: python-jenkins-job-builder - unretire and update to 4.0.0

[Ewoud Kohl van Wijngaarden]

On Thu, May 12, 2022 at 08:00:18AM +0200, Christoph Erhardt wrote:

Hi all,

I'm willing to revive python-jenkins-job-builder by updating it to the latest
release 4.0.0 and backporting an upstream patch.
I already have a working Copr build: https://copr.fedorainfracloud.org/coprs/
sicherha/python-jenkins-job-builder/packages/

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


I'd welcome this back in Fedora so I placed a review.

If you have some time, I'd appreciate reviews in return on BZs I opened:
https://bugzilla.redhat.com/show_bug.cgi?id=2053420
https://bugzilla.redhat.com/show_bug.cgi?id=2082032
___
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: Taking over maintenance for orphaned git-up package

[Ewoud Kohl van Wijngaarden]

On Thu, May 05, 2022 at 11:27:45AM +0200, Fabio Valentini wrote:

On Thu, May 5, 2022 at 11:11 AM Ewoud Kohl van Wijngaarden
 wrote:


On Thu, May 05, 2022 at 08:39:27AM -, Artur Frenszek-Iwicki wrote:
>git-up has been retired for over a year now. Packages that have been
>retired for over 8 weeks need to go through Package Review again.
>
>https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming

I filed https://bugzilla.redhat.com/show_bug.cgi?id=2082032 for that.

https://src.fedoraproject.org/rpms/git-up has a button "Retired" which
opened a pre-filled ticket, which was the wrong template. Would it make
sense (and be technically feasible) to detect it was retired >= 8 weeks
ago and use the correct template? If so, where would I file this RFE?


I see the problem:
https://pagure.io/releng/new_issue?title=Unretire%20rpms/git-up&template=package_unretiremet

There's a typo in the URL the button takes you to (should be unretiremeNt).
Otherwise it would take you to the correct template.

The component that's responsible for that button should be either
https://pagure.io/pagure-dist-git or https://pagure.io/pagure itself,
I'm not sure, because I can't find the code for it in the
pagure-dist-git plugin.


Looks like it's in pagure itself: https://pagure.io/pagure/pull-request/5296
___
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: Taking over maintenance for orphaned git-up package

[Ewoud Kohl van Wijngaarden]

On Thu, May 05, 2022 at 08:39:27AM -, Artur Frenszek-Iwicki wrote:

git-up has been retired for over a year now. Packages that have been
retired for over 8 weeks need to go through Package Review again.

https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming


I filed https://bugzilla.redhat.com/show_bug.cgi?id=2082032 for that.

https://src.fedoraproject.org/rpms/git-up has a button "Retired" which 
opened a pre-filled ticket, which was the wrong template. Would it make 
sense (and be technically feasible) to detect it was retired >= 8 weeks 
ago and use the correct template? If so, where would I file this RFE?

___
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

Taking over maintenance for orphaned git-up package

[Ewoud Kohl van Wijngaarden]

Hello everyone,

I see git-up[1] is orphaned for a lack of time, but I already maintain a 
COPR[2] so I'd like to take over maintenance. Per the policy[3] I'm 
notifying devel@ and also opened a ticket[4].


Regards,
Ewoud

[1]: https://src.fedoraproject.org/rpms/git-up
[2]: https://copr.fedorainfracloud.org/coprs/ekohl/git-up
[3]: 
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Orphaning_Process/#claiming_ownership_of_an_orphaned_package
[4]: https://pagure.io/releng/issue/10777
___
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?

[Ewoud Kohl van Wijngaarden]

On Thu, Apr 28, 2022 at 07:09:41AM -0400, 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&bug_status=ASSIGNED&classification=Fedora&component=puppet&list_id=12574395&product=Fedora&product=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.


I agree you don't want to do that. And if you're going that route 
anyway, why not use the official RPMs which do take that approach:


https://yum.puppet.com/
___
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?

[Ewoud Kohl van Wijngaarden]

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&bug_status=ASSIGNED&classification=Fedora&component=puppet&list_id=12574395&product=Fedora&product=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/

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

[Ewoud Kohl van Wijngaarden]

On Tue, Apr 26, 2022 at 02:49:26PM -0400, Nico Kadel-Garcia wrote:

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 ?


I'll state that I have extensive SCL knowledge, after working with it in 
packaging Foreman. With that I'll clarify why I think it's unrealistic.


The primary reason is that I have no interest nor use for it at all. 
Right my last EL7 machine is using the Puppet AIO package and I'll phase 
it out soon.


Second, I don't know if anyone has done this and what the effects will 
be. Providers such as the gem package provider will behave different. 
You also won't have access to any Ruby gems that you may have installed. 
As such it'll be a massive non-trivial migration for any user.


Speaking of gems, you will need to build all the dependent gems in the 
SCL. This means a lot of gems need to be modified and released. From 
experience I can tell you there are many things you can easily mess up, 
as well as bugs in the SCL stack you need to work around (BZ1995018 
being particularly nasty). Which brings me back to my primary reason: I 
have no time for this.


BZ1995018: https://bugzilla.redhat.com/show_bug.cgi?id=1995018
___
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

Ancient Puppet version in EPEL-7: remove it?

[Ewoud Kohl van Wijngaarden]

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&bug_status=ASSIGNED&classification=Fedora&component=puppet&list_id=12574395&product=Fedora&product=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

Re: Update for fedora-obsolete-packages

[Ewoud Kohl van Wijngaarden]

On Wed, Apr 06, 2022 at 09:07:59AM +0200, Petr Pisar wrote:

V Mon, Apr 04, 2022 at 01:04:01AM +0200, Ewoud Kohl van Wijngaarden napsal(a):

On Sun, Apr 03, 2022 at 10:47:45PM +0100, Ian McInerney via devel wrote:
> There hasn't been an update to the fedora-obsolete-packages package after
> the upgrade testing that was done last month in preparation for the release
> of F36. There are currently 3 open bugs that are targetted against F36 [1,
> 2, 3]. Since we are entering the final freeze this week, can someone make
> an update to the package so these are properly obsoleted for F36 upgrades?
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=2068936
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=2050836
> [3] https://bugzilla.redhat.com/show_bug.cgi?id=2063412

I also noticed the same problem with python(3)-jenkins-job-builder but I
haven't filed a bug yet. Do I file that against the
python-jenkins-job-builder component or fedora-obsolete-packages?


fedora-obsolete-packages.


https://bugzilla.redhat.com/show_bug.cgi?id=2072424
___
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: Update for fedora-obsolete-packages

[Ewoud Kohl van Wijngaarden]

On Sun, Apr 03, 2022 at 10:47:45PM +0100, Ian McInerney via devel wrote:

There hasn't been an update to the fedora-obsolete-packages package after
the upgrade testing that was done last month in preparation for the release
of F36. There are currently 3 open bugs that are targetted against F36 [1,
2, 3]. Since we are entering the final freeze this week, can someone make
an update to the package so these are properly obsoleted for F36 upgrades?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2068936
[2] https://bugzilla.redhat.com/show_bug.cgi?id=2050836
[3] https://bugzilla.redhat.com/show_bug.cgi?id=2063412


I also noticed the same problem with python(3)-jenkins-job-builder but I 
haven't filed a bug yet. Do I file that against the 
python-jenkins-job-builder component or fedora-obsolete-packages?

___
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: No daemon-reload or restart with %systemd_postun_with_restart

[Ewoud Kohl van Wijngaarden]

On Mon, Mar 21, 2022 at 07:12:23PM -0400, Sam Varshavchik wrote:

Ewoud Kohl van Wijngaarden writes:


On Mon, Mar 21, 2022 at 08:27:35AM -0400, Sam Varshavchik wrote:

Ewoud Kohl van Wijngaarden writes:


On Fri, Mar 18, 2022 at 06:22:08PM -0400, Sam Varshavchik wrote:

The only thing that https://docs.fedoraproject.org/en-US/packaging-
guidelines/Scriptlets/ tells me to do is to put 
%systemd_postun_with_restart in my %post. However:


1) systemd complains that it wants a daemon-reload, in order 
to pick up an updated .service file


2) I still must manually run systemctl reload-or-restart 
--marked, in order to actually restart an updated service


It seems to be there's a missing step, in here. By comparison 
I prepared comparable .deb packages for Ubuntu, using 
dh_installsystemd in the install script. The end result:


A) The initial .deb install enabled and started the service.

B) Bumping the release, rebuilding, and installing the newer 
package results in an automatic daemon-reload and restart, 
restarting the service.


Overall .deb's systemd integration seems to go smoother 
(compared to the rest of the .deb packaging process) than 
rpm's.


Is there a specific reason why %systemd_postun_with_restart 
stops before finishing the job? Am I missing something that I 
can install, to have this happen auto-magically?


I think daemon-reload changed to file triggers in systemd 228:

https://github.com/systemd/systemd/commit/873e413323dfff4023604849c70944674ae5cd29

However, the scriptlets documentation[1] states to use 
%systemd_post with %post and %systemd_postun_with_restart with 
%postun. %Perhaps that you're using %systemd_postun_with_restart 
in %post is the source of your problems?


No, my invocation is in %postun. Furthermore, it wouldn't matter, 
since at %post time the new package and the new service unit 
should already be installed and restartable.


And, as I wrote:

1) systemd complains that it wants a daemon-reload, in order 
to pick up an updated .service file


If ot was "changed to file triggers", well, it's not working since 
nothing is getting triggered. Furthermore, 
%systemd_postun_with_restart runs:


/usr/lib/systemd/systemd-update-helper mark-restart-system-units

which does:

systemctl set-property "$unit" Markers=+needs-restart &

That's all it does. Then, as I wrote:

2) I still must manually run systemctl reload-or-restart 
--marked, in order to actually restart an updated service


So, the shipped systemd scriptlets are still, very much, under an 
impression that explicit action needs to be taken to restart 
and/or reload updated .services. But, nothing gets reloaded. The 
.service files gets marked for a restart, but, from what I can 
tell, nothing ever gets restarted.


Do you happen to have the spec file and/or the RPMs? How can we 
replicate the findings?


Take the following spec file, below, and just feed it to rpmbuild -ba.

Then, rpm -ivh the binary rpm. Then:

systemctl enable testsystemd
systemctl start testsystemd
systemctl status testsystemd

You'll get something like this:

[mrsam@jack tmp]$ systemctl status testsystemd
● testsystemd.service - testsystemd
   Loaded: loaded (/usr/lib/systemd/system/testsystemd.service; 
enabled; vend>

   Active: active (exited) since Mon 2022-03-21 19:02:37 EDT; 10s ago
  Process: 88834 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
 Main PID: 88834 (code=exited, status=0/SUCCESS)
  CPU: 2ms

Mar 21 19:02:37 jack systemd[1]: Starting testsystemd…
Mar 21 19:02:37 jack systemd[1]: Finished testsystemd.

Up to now, everything looks good.

Now, take this spec file, bump the release, feed it to rpmbuild again.

According to my best understanding of systemd's published 
documentation: installing an updated package should automatically 
restart the active service, shouldn't it?


But after I fed the new version to rpm -UvhF, what I got was:

[mrsam@jack tmp]$ systemctl status testsystemd | cat
Warning: The unit file, source configuration file or drop-ins of 
testsystemd.service changed on disk. Run 'systemctl daemon-reload' to 
reload units.

● testsystemd.service - testsystemd
   Loaded: loaded (/usr/lib/systemd/system/testsystemd.service; 
enabled; vendor preset: disabled)

   Active: active (exited) since Mon 2022-03-21 19:02:37 EDT; 4min 35s ago
  Process: 88834 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
 Main PID: 88834 (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 76902)
   Memory: 0B
  CPU: 0
   CGroup: /system.slice/testsystemd.service

Mar 21 19:02:37 jack systemd[1]: Starting testsystemd…
Mar 21 19:02:37 jack systemd[1]: Finished testsystemd.

A loud complaint at the beginning that systemd wasn't reload. Same, 
unchanged, syslog timestamp from the initial start.


This is on up to date F35.

Then, at this point:

sudo systemctl daemon-reload
sudo systemctl reload-or-restart --marked

[mrsam@jack tmp]$ 

Re: No daemon-reload or restart with %systemd_postun_with_restart

[Ewoud Kohl van Wijngaarden]

On Mon, Mar 21, 2022 at 08:27:35AM -0400, Sam Varshavchik wrote:

Ewoud Kohl van Wijngaarden writes:


On Fri, Mar 18, 2022 at 06:22:08PM -0400, Sam Varshavchik wrote:

The only thing that https://docs.fedoraproject.org/en-US/packaging-
guidelines/Scriptlets/ tells me to do is to put 
%systemd_postun_with_restart in my %post. However:


1) systemd complains that it wants a daemon-reload, in order to 
pick up an updated .service file


2) I still must manually run systemctl reload-or-restart --marked, 
in order to actually restart an updated service


It seems to be there's a missing step, in here. By comparison I 
prepared comparable .deb packages for Ubuntu, using 
dh_installsystemd in the install script. The end result:


A) The initial .deb install enabled and started the service.

B) Bumping the release, rebuilding, and installing the newer 
package results in an automatic daemon-reload and restart, 
restarting the service.


Overall .deb's systemd integration seems to go smoother (compared 
to the rest of the .deb packaging process) than rpm's.


Is there a specific reason why %systemd_postun_with_restart stops 
before finishing the job? Am I missing something that I can 
install, to have this happen auto-magically?


I think daemon-reload changed to file triggers in systemd 228:

https://github.com/systemd/systemd/commit/873e413323dfff4023604849c70944674ae5cd29

However, the scriptlets documentation[1] states to use %systemd_post 
with %post and %systemd_postun_with_restart with %postun. %Perhaps 
that you're using %systemd_postun_with_restart in %post is the 
source of your problems?


No, my invocation is in %postun. Furthermore, it wouldn't matter, 
since at %post time the new package and the new service unit should 
already be installed and restartable.


And, as I wrote:

1) systemd complains that it wants a daemon-reload, in order to 
pick up an updated .service file


If ot was "changed to file triggers", well, it's not working since 
nothing is getting triggered. Furthermore, 
%systemd_postun_with_restart runs:


/usr/lib/systemd/systemd-update-helper mark-restart-system-units

which does:

systemctl set-property "$unit" Markers=+needs-restart &

That's all it does. Then, as I wrote:

2) I still must manually run systemctl reload-or-restart --marked, 
in order to actually restart an updated service


So, the shipped systemd scriptlets are still, very much, under an 
impression that explicit action needs to be taken to restart and/or 
reload updated .services. But, nothing gets reloaded. The .service 
files gets marked for a restart, but, from what I can tell, nothing 
ever gets restarted.


Do you happen to have the spec file and/or the RPMs? How can we 
replicate the findings?

___
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: No daemon-reload or restart with %systemd_postun_with_restart

[Ewoud Kohl van Wijngaarden]

On Fri, Mar 18, 2022 at 06:22:08PM -0400, Sam Varshavchik wrote:

The only thing that https://docs.fedoraproject.org/en-US/packaging-
guidelines/Scriptlets/ tells me to do is to put 
%systemd_postun_with_restart in my %post. However:


1) systemd complains that it wants a daemon-reload, in order to pick 
up an updated .service file


2) I still must manually run systemctl reload-or-restart --marked, in 
order to actually restart an updated service


It seems to be there's a missing step, in here. By comparison I 
prepared comparable .deb packages for Ubuntu, using dh_installsystemd 
in the install script. The end result:


A) The initial .deb install enabled and started the service.

B) Bumping the release, rebuilding, and installing the newer package 
results in an automatic daemon-reload and restart, restarting the 
service.


Overall .deb's systemd integration seems to go smoother (compared to 
the rest of the .deb packaging process) than rpm's.


Is there a specific reason why %systemd_postun_with_restart stops 
before finishing the job? Am I missing something that I can install, 
to have this happen auto-magically?


I think daemon-reload changed to file triggers in systemd 228:

https://github.com/systemd/systemd/commit/873e413323dfff4023604849c70944674ae5cd29

However, the scriptlets documentation[1] states to use %systemd_post 
with %post and %systemd_postun_with_restart with %postun. %Perhaps that 
you're using %systemd_postun_with_restart in %post is the source of your 
problems?


[1]: 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_systemd
___
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)

[Ewoud Kohl van Wijngaarden]

On Wed, Feb 23, 2022 at 02:52:02PM +0100, Kamil Dudka wrote:

On Wednesday, February 23, 2022 10:22:00 AM CET Dmitry Belyavskiy wrote:

Dear Kamil,

On Wed, Feb 23, 2022 at 8:51 AM Kamil Dudka  wrote:
> On Tuesday, February 22, 2022 10:50:06 PM CET Chris Adams wrote:
> > Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
> > > Yes. But how many domains using idn are there? I worked on idn support
> > > in systemd, but when preparing the description of this change I
>
> realized
>
> > > that I have _never_ once used an idn domain outside of testing.
> > >
> > > And note that this is not about user-facing programs like firefox.
> > > I assume that there might be _some_ use of idn in firefox. But for
> > > command-line tools like curl this seems even less likely.
> >
> > I'm pretty sure use of IDN domains is a regional thing.  I live in the
> > US and don't see IDN domains in my normal use.  But dropping support for
> > them from a core utility would be bad for those that live in regions
> > where IDN domains may be more common.
>
> If this appears to be a real problem, it is easy for us to re-enable IDN
> in libcurl-minimal, even in an update of a stable Fedora release.  So I do
> not think we need to enable it proactively.
>
> Being from Russia and having several years of interacting with Universal

Acceptance, I'd say IDN is a must nowadays.


To be clear, I am not completely against including IDN in libcurl-minimal.
On the other hand, we removed IDN from libcurl in ubi9 images in September
and nobody has complained about it so far:

   https://bugzilla.redhat.com/1994521


Isn't this also a bit of chicken and egg problem? You can't really use 
IDN since tooling doesn't support it and tooling doesn't support it 
because nobody uses it.


I'll note that personally I have no need for IDN.
___
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: Koji notifications arriving days late

[Ewoud Kohl van Wijngaarden]

On Sun, Jan 02, 2022 at 12:03:25PM -0800, Kevin Fenzi wrote:

On Fri, Dec 31, 2021 at 10:25:31AM +0100, Julian Sikorski wrote:

Hello,

is it a known problem that koji notifications arrive way too late? For


yes.


example, I got mame build notifications in the wee hours today (31.12)
wheras the builds completed around noon on the 29th:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1871260
https://koji.fedoraproject.org/koji/buildinfo?buildID=1871254
https://koji.fedoraproject.org/koji/buildinfo?buildID=1871253
This does not seem normal. Is anybody seeing this too?


Everyone. :(

The problem here is our notification system ( fmn ) has a number of
issues:

* The current version is still python2 and crashes from time to time for
difficult to debug reasons. So, sometimes it has crashed and takes a bit
to realize it's not processing and get restarted. :( We do have a
python3 port almost ready to swap in. Once thats in at least we can
hopefully debug any crashes. I hope that will happen in the first
quarter.

* The current version has issues processing when 'large' amounts of
messages flood the bus. Examples of this include:
- When a beta or final release is 'go' releng tags all the packages to
 record they were part of the release, so ~23k messages in a few
 minutes.
- when copr rebuilds all rubygems
- mass rebuilds, thats ~23*N messages
- Most recently, when epel9 branching opened, because say 200 packages
 branched quicky and merged every commit from rawhide into the epel9
 branch and each commit is a message.


I'm right now the unlucky receiver of this. It's really annoying. Facter 
has a ~15 year history so it's a lot of commits.


Couldn't this be grouped? I don't see a multi commit viewer in Pagure 
where you can say $start..$end (like regular git, github, gitlab and 
others). That would save a lot of notifications and actually be 
effective.



So, anyhow, I hope the python3 version will help out some, but really we
need to do a re-write of the application to better handle lots of
messages. The current app is... difficult to use, but super flexible.
If we made it easier to use, simpliler, but some less flexable it could
help processing speed. There has also been talk about seeing if we can
just use rabbitmq for the heavy lifting here (ie, have queues for people
who customize messages with those topics and have rabbitmq sort them for
us), that might work or help.  I hope we can work on this this year.


Is there anything people could do to help here? Like is there a roadmap?
I think the source is https://github.com/fedora-infra/fmn and there is 
https://github.com/fedora-infra/fmn/issues/143 but that has very little 
activity.

___
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: Koji notifications arriving days late

[Ewoud Kohl van Wijngaarden]

On Fri, Dec 31, 2021 at 09:59:08AM -, Artur Frenszek-Iwicki wrote:

This is happening to me, too - but it doesn't seem to be limited
to koji notifications. It happens with bugzilla notifications as well.

There isn't any pattern to the delays that I can see.
I regularly receive notification digests during the day,
yet every now and then I receive a digest informing me
of stuff that happened 2 or 3 days ago. I think once
it informed me on stuff that was almost a week old.

My settings in Fedora Notifications are "100 messages or 1 hour".
I don't receive many notifications, so 100% of the time,
the time limit kicks in first; most digests I receive
have single-digit message counts. This applies to the delayed digests
as well - I've never seen one actually reach 100.


For me the notifications over IRC arrive a few days after the events 
happened. I'm not sure when this started (I don't receive that many 
notifications) but I get the impression that they were never instant on 
Libera while I have received them instantly on Freenode in the past.

___
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: Creating users/groups in RPMs with EL7 compatibility

[Ewoud Kohl van Wijngaarden]

On Tue, Dec 21, 2021 at 02:47:10PM +0100, Vít Ondruch wrote:

Dne 21. 12. 21 v 13:13 Ewoud Kohl van Wijngaarden napsal(a):
Thanks for that. It looks like Fedora 32 added the new 
%sysusers_create_compat macro. That means the guidelines apply to 
all supported Fedora versions but not to EL7 & EL8. Is this 
something that would normally be noted in the docs or are the docs 
intended as purely Fedora? As a packager I feel it should be 
mentioned that given EPEL falls under the Fedora umbrella.


There is this chapter of guidelines:

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_applicability


Great: https://pagure.io/packaging-committee/pull-request/1143

Ideally speaking the macros would become available in EL7 & EL8 but 
I'm guessing that's unlikely



Speaking with my Red Hat hat on, maintainers typically tries to 
backport as much as possible. However, not everything is possible to 
backport. But the best way to provide feedback about RHEL is by 
contacting RH support to help prioritize your issue.


With my own Red Hat hat I'm well aware of this :)

Please note that you might also consider to use CentOS Stream to 
propose your suggestions. Certainly for RHEL 9.


I didn't check, but I since EL9 is based on Fedora 34 and this was 
added in Fedora 32 I assumed it will be present. I guess it could be 
submitted to Stream 8.



, especially for EL7.



Well ...

https://access.redhat.com/support/policy/updates/errata#Maintenance_Support_2_Phase


That's why I said it. Technically on EL7 there is no systemd-rpm-macros 
package so it could be introduced in EPEL7 but that's rather ugly so I'd 
rather not touch that.



On Tue, Dec 21, 2021 at 11:33:28AM +0100, Vít Ondruch wrote:
I don't have direct answer to your question, but if I wanted to 
have an answer to this question, I'd try to go back in history, so 
this would be my start:


https://pagure.io/packaging-committee/history/guidelines/modules/ROOT/pages/UsersAndGroups.adoc


And this is the place where the guidelines lived previously:

https://fedoraproject.org/wiki/Packaging:UsersAndGroups

If RHEL7 was released on June 10, 2014, the guidelines somewhere 
around that date should work. But best would be to try as recent 
version of the guidelines as possible.


Dne 20. 12. 21 v 15:50 Ewoud Kohl van Wijngaarden napsal(a):
I'm looking at modernizing the upstream Jenkins RPM packaging 
and reading through the packaging guidelines[1]. I see some 
decent macros but these are incompatible with EL7. What would be 
the recommendation for RPM specs that should work on EL7 and 
newer?


[1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/

___
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: Creating users/groups in RPMs with EL7 compatibility

[Ewoud Kohl van Wijngaarden]

Thanks for that. It looks like Fedora 32 added the new 
%sysusers_create_compat macro. That means the guidelines apply to all 
supported Fedora versions but not to EL7 & EL8. Is this something that 
would normally be noted in the docs or are the docs intended as purely 
Fedora? As a packager I feel it should be mentioned that given EPEL 
falls under the Fedora umbrella.


Ideally speaking the macros would become available in EL7 & EL8 but I'm 
guessing that's unlikely, especially for EL7.


On Tue, Dec 21, 2021 at 11:33:28AM +0100, Vít Ondruch wrote:
I don't have direct answer to your question, but if I wanted to have 
an answer to this question, I'd try to go back in history, so this 
would be my start:


https://pagure.io/packaging-committee/history/guidelines/modules/ROOT/pages/UsersAndGroups.adoc

And this is the place where the guidelines lived previously:

https://fedoraproject.org/wiki/Packaging:UsersAndGroups

If RHEL7 was released on June 10, 2014, the guidelines somewhere 
around that date should work. But best would be to try as recent 
version of the guidelines as possible.


Dne 20. 12. 21 v 15:50 Ewoud Kohl van Wijngaarden napsal(a):
I'm looking at modernizing the upstream Jenkins RPM packaging and 
reading through the packaging guidelines[1]. I see some decent 
macros but these are incompatible with EL7. What would be the 
recommendation for RPM specs that should work on EL7 and newer?


[1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/

___
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

Creating users/groups in RPMs with EL7 compatibility

[Ewoud Kohl van Wijngaarden]

Hello everyone,

I'm looking at modernizing the upstream Jenkins RPM packaging and 
reading through the packaging guidelines[1]. I see some decent macros 
but these are incompatible with EL7. What would be the recommendation 
for RPM specs that should work on EL7 and newer?


Regards,
Ewoud Kohl van Wijngaarden

[1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/
___
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

Updating Puppet from 5.5 to 7.7 in Fedora 34

[Ewoud Kohl van Wijngaarden]

Hello everyone,

For additional visibility: there is currently an open update to bump 
Puppet from version 5.5 to 7.7 in Fedora 34. While this can be 
considered a big change (especially since the config directory changes), 
it should be ok. Puppet 5.5 is completely broken under Ruby 3 and only 
Puppet 7.7 added support for Ruby 3.


https://bodhi.fedoraproject.org/updates/FEDORA-2021-ec4a4b2634

If you're a Puppet user, please git it a spin.

Also a big shout out to brandfbb for his efforts. From here on out, I 
hope we can keep Puppet up to date.


Regards,
Ewoud Kohl van Wijngaarden
___
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: use unit names in systemd output by default?

[Ewoud Kohl van Wijngaarden]

On Fri, Jun 25, 2021 at 10:21:05AM +, Zbigniew Jędrzejewski-Szmek wrote:

systemd has systemd.status_unit_format= / [Manager].StatusUnitFormat=
/ -Dstatus-unit-format-default= option to use unit names instead of the
Description in messages on the kernel console and in logs:

- Jun 20 22:04:48 krowka systemd[1]: Started Rule-based Manager for Device 
Events and Files.
+ Jun 20 22:04:48 krowka systemd[1]: Started systemd-udevd.service.

I find this more convenient because it's briefer, so it fits better on
a terminal, but primarily because I can select&paste the unit name for
further lookup. When Description is used, and I'm not familiar with
the unit, I'll often use grep first to figure out what the unit name
actually is. Finally, unit Descriptions are often not very good, and
the name is at least as informative…


I agree with this preference. You could consider both.


Would people be opposed to making this the default (setting
-Dstatus-unit-format-default=name in build options)? People who like
the old default could set StatusUnitFormat=description in systemd.conf


I think Fedora should stick to upstream defaults in most places. 
Especially with systemd it's nice if all distros align (which is one of 
the big benefits of systemd over sysvinit IMHO).


What does upstream think about this change? What do other distros think 
about this change?

___
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: Updating sources file using fedpkg

[Ewoud Kohl van Wijngaarden]

On Tue, Jun 22, 2021 at 01:03:54AM +0300, Otto Urpelainen wrote:

Ewoud Kohl van Wijngaarden kirjoitti 21.6.2021 klo 14.50:

On Thu, Jun 17, 2021 at 09:02:12PM +0300, Otto Urpelainen wrote:
I am a bit confused about this discussion. My fedpkg does not care 
about the 'sources' file or the lookaside cache at all on 'fedpkg 
mockbuild'. It simply looks up the expected filename of downloaded 
Source, grabs it from the local working directory and uses that. 
So for me this works:


   rpmdev-bumpspec -D -n 1.2.3 *.spec
   # Update specfile as needed
   spectool -g *.spec
   fedpkg mockbuild


Now it also downloads the old files mentioned in sources. In my 
experience it certainly does care about it.


Maybe my request can be reduced to: mockbuild should not download 
files not mentioned in the spec file. Ken did give a good 
workaround. Taking that a step further I think something like this 
would suffice for me:


spectool -l *.spec | awk '/https?:/ { print $2 }' | xargs -n 1 
basename | xargs sha512sum --tag > sources


Ah, you are right. Since I settled on my current workflow, I did not 
even notice those useless files being downloaded. I guess I have not 
encounters are very large one, then.


I filed an issue about this: https://pagure.io/rpkg/issue/559


Thanks!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Updating sources file using fedpkg

[Ewoud Kohl van Wijngaarden]

On Thu, Jun 17, 2021 at 09:02:12PM +0300, Otto Urpelainen wrote:

Ken Dreyer kirjoitti 17.6.2021 klo 19.04:

On Thu, Jun 17, 2021 at 8:33 AM Richard Shaw  wrote:


On Thu, Jun 17, 2021 at 7:22 AM Ewoud Kohl van Wijngaarden 
 wrote:



To be clear: I don't want to fiddle with the sources file, hence this
email. However, I would like to at least complete a local mockbuild
before uploading to the lookaside cache. It is my understanding that
new-sources always does this.



That's actually a nit I've been tempted to complain about. If I'm upgrading a 
package to a new version I update the spec file:

rpmdev-bumpspec -n  -c "Update to ." *.spec

And download the new source:

spectool -g *.spec

But then I have to upload the new source with 'fedpkg new-sources' if I don't 
want it to download the old version.


Yeah, the way I deal with this is I zero out the sources file, like ">
sources". Or another alternative that I use sometimes is "sha512sum
--tag", like:

  sha512sum --tag kstart-4.2.tar.gz > sources


This is really helpful! I did not know it's the output of the --tag 
parameter.




Hi Ewould and everybody,

I am a bit confused about this discussion. My fedpkg does not care 
about the 'sources' file or the lookaside cache at all on 'fedpkg 
mockbuild'. It simply looks up the expected filename of downloaded 
Source, grabs it from the local working directory and uses that. So 
for me this works:


   rpmdev-bumpspec -D -n 1.2.3 *.spec
   # Update specfile as needed
   spectool -g *.spec
   fedpkg mockbuild


Now it also downloads the old files mentioned in sources. In my 
experience it certainly does care about it.


Maybe my request can be reduced to: mockbuild should not download files 
not mentioned in the spec file. Ken did give a good workaround. Taking 
that a step further I think something like this would suffice for me:


spectool -l *.spec | awk '/https?:/ { print $2 }' | xargs -n 1 basename | xargs 
sha512sum --tag > sources

After that is done, the rpm is available at results_mypackage, I 
install it locally and see that everything works. At that point it is 
a good time do 'fedpkg new-sources'.


This I understand.

This also means that non-packagers actually *can* properly test their 
changes. The maintainer has to do new-sources, commit, push and build 
after merging the pull request, so annoyingly there are those steps to 
remember. But at least the pull request author does not have to submit 
their changes blindly.


A simple test to make sure that it really uses the local download:

   $ sed -i 's/^Source.*/Source:https:\/\/example.com\/foo/' *.spec
   $ fedpkg mockbuild
   SOME_OUTPUT
   error: Bad file: SOMEPATH/foo: No such file or directory
   $ touch foo
   $ fedpkg mockbuild
   LOTS_OF_OUTPUT
   SOME_ERROR_DUE_TO_EMPTY_SOURCE

When I started, I was having exactly the same trouble, so wrote 
something in the wiki:


https://fedoraproject.org/wiki/Package_maintenance_guide#Using_fedpkg_anonymously


That's certainly a good start. I'm hoping to remove even more obstackles 
for new contributors.

___
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: Updating sources file using fedpkg

[Ewoud Kohl van Wijngaarden]

On Thu, Jun 17, 2021 at 02:11:41PM +0200, Matthias Runge wrote:

On Thu, Jun 17, 2021 at 01:57:03PM +0200, Ewoud Kohl van Wijngaarden wrote:

Hello everyone,

As someone who just got started, I'm looking for some help.

I'd like to update packages. I'm used to git, so my typical flow is to make
sure I have some clean branch to start working from (clone is just for
completeness):

fedpkg clone mypackage
cd mypackage
git checkout -b rawhide-update-to-new-version
rpmdev-bumpspec -n 1.2.3 mypackage.spec

Now comes the part I'm not sure about. To fetch the new sources I usually
perform:

spectool -g mypackage.spec

After that, I'm looking for a command to update the sources file with new
checksums so I can run:


fedpkg new-sources

This should push the new sources (compressed tarball, whatever), defined
under SOURCE* in the spec file to the cache storing the sources.
For just local builds, this step is not necessary. You could run

fedpkg mockbuild


I found that mockbuild still retrieves what's in sources. I guess a 
possible workaround is to remove the entries from sources and rely on 
spectool.


As a non-packager you also can't run new-source. So perhaps new-sources 
should gain a --no-upload flag? --noop sounds wrong if it does make 
changes and a prep-sources command makes the command listing less 
useful.

___
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: Updating sources file using fedpkg

[Ewoud Kohl van Wijngaarden]

On Thu, Jun 17, 2021 at 02:05:16PM +0200, Fabio Valentini wrote:

On Thu, Jun 17, 2021 at 1:57 PM Ewoud Kohl van Wijngaarden
 wrote:


Hello everyone,

As someone who just got started, I'm looking for some help.

I'd like to update packages. I'm used to git, so my typical flow is to
make sure I have some clean branch to start working from (clone is just
for completeness):

fedpkg clone mypackage
cd mypackage
git checkout -b rawhide-update-to-new-version
rpmdev-bumpspec -n 1.2.3 mypackage.spec

Now comes the part I'm not sure about. To fetch the new sources I
usually perform:

spectool -g mypackage.spec

After that, I'm looking for a command to update the sources file with
new checksums so I can run:

fedpkg --release f35 mockbuild

I could not find such a command so until now I've been using sha512sum
manually, but there must be a better way :)


I assume you're looking for the "fedpkg new-sources" subcommand.

Using sha512sum alone is not doing everything you need, i.e. it's not
uploading the sources to the dist-git lookaside cache, so not using
"fedpkg new-sources" but only fiddling with the "sources" file
manually would result in broken builds, because the build system would
not find those sources.


To be clear: I don't want to fiddle with the sources file, hence this 
email. However, I would like to at least complete a local mockbuild 
before uploading to the lookaside cache. It is my understanding that 
new-sources always does this.



PS: I would recommend not creating custom branches, not even locally.
If you ever accidentally push such a branch, you might not be able to
delete it, *ever*. Additionally, if you stick to the normal "rawhide",
"f34", "f33" branches, then "fedpkg mockbuild" will infer the
"--release fXX" argument for you instead of you having to specify it
manually.


This feels very odd to me as a new contributor but very familiar with 
git.

___
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

Updating sources file using fedpkg

[Ewoud Kohl van Wijngaarden]

Hello everyone,

As someone who just got started, I'm looking for some help.

I'd like to update packages. I'm used to git, so my typical flow is to 
make sure I have some clean branch to start working from (clone is just 
for completeness):


fedpkg clone mypackage
cd mypackage
git checkout -b rawhide-update-to-new-version
rpmdev-bumpspec -n 1.2.3 mypackage.spec

Now comes the part I'm not sure about. To fetch the new sources I 
usually perform:


spectool -g mypackage.spec

After that, I'm looking for a command to update the sources file with 
new checksums so I can run:


fedpkg --release f35 mockbuild

I could not find such a command so until now I've been using sha512sum 
manually, but there must be a better way :)


Regards,
Ewoud Kohl van Wijngaarden
___
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: Rubygem package smoke testing [was: Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)]

[Ewoud Kohl van Wijngaarden]

On Wed, Jun 16, 2021 at 02:21:18PM +0200, Vít Ondruch wrote:


Dne 16. 06. 21 v 13:36 Ewoud Kohl van Wijngaarden napsal(a):

On Wed, Jun 16, 2021 at 01:17:31PM +0200, Vít Ondruch wrote:


Dne 15. 06. 21 v 19:34 Ewoud Kohl van Wijngaarden napsal(a):

On Tue, Jun 15, 2021 at 01:51:12PM +0200, Miro Hrončok wrote:

On 15. 06. 21 13:46, Vitaly Zaitsev via devel wrote:

If that is not possible with reasonable effort,
at least a basic smoke test (such as importing the packaged module)
*MUST* be run in `+%check+`.


A simple scriplet should be introduced I think:

%check
%do_import_test


Already on it:
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/99


This may be not be the right place, but in Foreman's Ruby 
packaging we've also felt a similar pain. Mostly with C 
extensions that were built in the wrong directory. We also added 
a %check section to do a basic "import" (require) test.


Is there a similar macro for Ruby smoke testing?



No, there is no similar macro for Ruby. Historically, it was not 
clear what should be actually required. With Bundler putting into 
place more conventions, the situation is better.


Nevertheless, what is the specific issue you are referring to 
above? There are many examples of fixing such issue, e.g.


https://src.fedoraproject.org/rpms/rubygem-bcrypt/blob/rawhide/f/rubygem-bcrypt.spec#_52


And there are probably more complex cases.


Perhaps we should take this to a separate discussion, but we found 
that there are various bugs in SCL macros that s.o ended up in the 
wrong directories so it wouldn't load.



SCLs or not, this is what always happens for several reasons:

1) While upstream leaves the .so files along side other parts of the 
library, we place the platform independent code in /usr/share while 
placing the platform dependent code into /usr/lib. This is done via 
[1] and it was actually supposed to be default in RubyGems 3, but 
unfortunately with change of upstream maintainers, it got forgotten 
[2].


2) The paths used during rpmbuild are never on Ruby LOAD_PATH. 
Upstream might add the `lib` directory on the load path, which be 
defaults contains the .so file. But that is not case on Fedora as I 
explained in (1), therefore it is always necessary to add the 
directory with .so file on the LOAD_PATH explicitly.


In theory, we could somehow extend the GEM_PATH to include the RPM 
directories, but upstream test suites are not prepared for this 
scenario, so it would not help.



Really, majority of Ruby packages has fragments like `-Ilib` or 
`-Ilib:test` in the `%check` section. This is grep across the Fedora 
.spec files [3]:


~~~

$ find . -name rubygem\* -exec grep ' \-I' {} \; | wc -l
311

~~~

You just need to add the path to the .so file on the LOAD_PATH similarly.


That does leave a feeling that we can't test the correct .so location at 
all in %check.


It feels like we need a phase where the package was installed 
(respecting %files and all). If we can *then* import the library using 
Ruby, then we're content. While it may not be RPMs job, an easy 
verification point that's also usable outside of some fixed 
infrastructure (such as Fedora) would be great. Is there such a thing 
today?

___
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: Experience on src.fedoraproject.org as non-packager

[Ewoud Kohl van Wijngaarden]

On Wed, Jun 16, 2021 at 09:57:13AM -0700, Kevin Fenzi wrote:

On Wed, Jun 16, 2021 at 03:05:59PM +0200, Ewoud Kohl van Wijngaarden wrote:

Interesting, I had not tried that.

What I used was the clone button. That shows a small dialog with this (as
packager):

   Source Code

 SSH 
 GIT 

As non-packager it does NOT have the SSH URL. So what I initially did was to
manually clone it with git, not fedpkg. Then you have no way to push.


You can stll use 'fedpkg push' in this case and it will setup things and
push. But you have to use fedpkg for one of clone/push.


This wasn't clear to me. I was used to Github where it's more of a 
vanilla git experience.



It looks like fedpkg clone does configure a credential helper which probably
allows you to push via SSH.


It's via https and a token. fedpkg sets up the token for you. After the
initial setup in fedpkg, you can use normal git for everything.


Good to know. Thanks!


It would be my recommendation to add a third "URL" to it and that's the
fedpkg command to clone.


Yeah, might be a reasonable idea indeed. Can you file a issue at
https://pagure.io/pagure/issues/ ?


Filed as https://pagure.io/pagure/issue/5185 which also links back to 
the archive URL for this thread.

___
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: Experience on src.fedoraproject.org as non-packager

[Ewoud Kohl van Wijngaarden]

On Wed, Jun 16, 2021 at 01:33:08PM +0100, Ankur Sinha wrote:

On Wed, Jun 16, 2021 14:03:26 +0200, Ewoud Kohl van Wijngaarden wrote:

Hello everyone,


Hi Ewoud,


Even though I've now been sponsored as a packager, I did want to share my
experience since it was a bit frustrating.

If you do have a FAS account, you can log in on src.fedoraproject.org and
can even fork repositories. However, on the clone URL you only see the
anonymous git URL. That means you have no way to push changes to your fork.
That also means you can't submit a PR to repositories using your fork. The
end result is that it's very hard to contribute to repositories.

My suggestion is to either give non-packagers the URL (and if needed
permission) to push to their own forks or remove the ability to fork a
repository.


Thanks for the feedback. Do these instructions not work? They indicate
that one is able to push to their forks. If this doesn't work,
something's broken somewhere and will need looking into.

https://fedoraproject.org/wiki/Package_maintenance_guide#Using_fedpkg_anonymously

(linked from: 
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#One-off_contributions)


Interesting, I had not tried that.

What I used was the clone button. That shows a small dialog with this 
(as packager):


   Source Code

 SSH 
 GIT 

As non-packager it does NOT have the SSH URL. So what I initially did 
was to manually clone it with git, not fedpkg. Then you have no way to 
push.


It looks like fedpkg clone does configure a credential helper which 
probably allows you to push via SSH.


It would be my recommendation to add a third "URL" to it and that's the 
fedpkg command to clone.


If a non-packager can push using SSH, I would also add that URL 
unconditonally. I could not find the URL as non-packager so I can't say 
if you have that permission. It would make sense to me that you do.


This may be difficult. It looks like this is the relevant template:

https://pagure.io/pagure/blob/master/f/pagure/templates/repo_master.html

That suggests it can't easily be modified just for 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Experience on src.fedoraproject.org as non-packager

[Ewoud Kohl van Wijngaarden]

Hello everyone,

Even though I've now been sponsored as a packager, I did want to share 
my experience since it was a bit frustrating.


If you do have a FAS account, you can log in on src.fedoraproject.org 
and can even fork repositories. However, on the clone URL you only see 
the anonymous git URL. That means you have no way to push changes to 
your fork. That also means you can't submit a PR to repositories using 
your fork. The end result is that it's very hard to contribute to 
repositories.


My suggestion is to either give non-packagers the URL (and if needed 
permission) to push to their own forks or remove the ability to fork a 
repository.


Regards,
Ewoud Kohl van Wijngaarden
___
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

Rubygem package smoke testing [was: Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)]

[Ewoud Kohl van Wijngaarden]

On Wed, Jun 16, 2021 at 01:17:31PM +0200, Vít Ondruch wrote:


Dne 15. 06. 21 v 19:34 Ewoud Kohl van Wijngaarden napsal(a):

On Tue, Jun 15, 2021 at 01:51:12PM +0200, Miro Hrončok wrote:

On 15. 06. 21 13:46, Vitaly Zaitsev via devel wrote:

If that is not possible with reasonable effort,
at least a basic smoke test (such as importing the packaged module)
*MUST* be run in `+%check+`.


A simple scriplet should be introduced I think:

%check
%do_import_test


Already on it:
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/99


This may be not be the right place, but in Foreman's Ruby packaging 
we've also felt a similar pain. Mostly with C extensions that were 
built in the wrong directory. We also added a %check section to do a 
basic "import" (require) test.


Is there a similar macro for Ruby smoke testing?



No, there is no similar macro for Ruby. Historically, it was not clear 
what should be actually required. With Bundler putting into place more 
conventions, the situation is better.


Nevertheless, what is the specific issue you are referring to above? 
There are many examples of fixing such issue, e.g.


https://src.fedoraproject.org/rpms/rubygem-bcrypt/blob/rawhide/f/rubygem-bcrypt.spec#_52

And there are probably more complex cases.


Perhaps we should take this to a separate discussion, but we found that 
there are various bugs in SCL macros that s.o ended up in the wrong 
directories so it wouldn't load.


Our specific case is that we have our own SCL that depends on rh-ruby27 
and must override GEM_PATH[1], GEM_HOME[2] and replace %%gem_install[3]. 
We forgot this at some point. Providing the explicit paths masked this 
failure. Perhaps this simply can't work inside RPM builds and you need 
to really install it in some chroot to test it.


[1]: 
https://github.com/theforeman/foreman-packaging/blob/7b1dd67c08f4f17b818dd0b7d2b80e243c652211/packages/foreman/tfm/tfm.spec#L220
[2]: 
https://github.com/theforeman/foreman-packaging/blob/7b1dd67c08f4f17b818dd0b7d2b80e243c652211/packages/foreman/tfm/tfm.spec#L221
[3]: 
https://github.com/theforeman/foreman-packaging/blob/7b1dd67c08f4f17b818dd0b7d2b80e243c652211/packages/foreman/tfm/macros.tfm#L1-L13



And for those of us who also maintain packages for EL7/8, what's the 
availability of these macros?



RHEL7 is in Maintenance Support 2 Phase [1], so don't expect too much. 
There are better chances to get such macro into RHEL8, but in the 
context of Ruby, there are 3 supported versions ATM, therefore it 
might get complex.


Anyway, it is good idea to use such macros in the following way:


~~~

%{?import_smoke_test}

~~~


This does the right thing where such macro is supported and is ignored 
elsewhere, where such macro is not available.


Thanks! That makes sense.
___
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 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

[Ewoud Kohl van Wijngaarden]

On Tue, Jun 15, 2021 at 12:50:03PM +0200, Petr Viktorin wrote:

On 15. 06. 21 2:11, Neal Gompa wrote:

It's not terribly different from how organizations may have private
Python package indexes that may use whatever names they want for
Python software they build and release.


I agree, in fact, I think Fedora's problems here are a subset of the 
problems the private organizations have: if issues of proprietary 
corps are solved, we can use the solution as well. (However, it'll 
need more work than is necessary for Fedora/FOSS needs, so I don't 
want to drive the effort.)
BUT, if the issues are solved, it'll likely be through namespacing: 
we'd need to prefix our names with `fedora-` or `fedora:`. I still 
think it is better for Fedora to reuse the public PyPI namespace 
rather than start its own.


Registering on PyPI for private packages can be useful to avoid 
dependency confusion attacks[1]. Essentially we're talking about the 
same problem here.


[1]: https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610
___
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 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

[Ewoud Kohl van Wijngaarden]

On Tue, Jun 15, 2021 at 01:51:12PM +0200, Miro Hrončok wrote:

On 15. 06. 21 13:46, Vitaly Zaitsev via devel wrote:

If that is not possible with reasonable effort,
at least a basic smoke test (such as importing the packaged module)
*MUST* be run in `+%check+`.


A simple scriplet should be introduced I think:

%check
%do_import_test


Already on it:
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/99


This may be not be the right place, but in Foreman's Ruby packaging 
we've also felt a similar pain. Mostly with C extensions that were built 
in the wrong directory. We also added a %check section to do a basic 
"import" (require) test.


Is there a similar macro for Ruby smoke testing?

And for those of us who also maintain packages for EL7/8, what's the 
availability of these macros?

___
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: Self Introduction: Odilon Junior

[Ewoud Kohl van Wijngaarden]

On Fri, Jun 11, 2021 at 07:00:52PM -0300, Odilon Junior wrote:

My name is Odilon Junior,


Hi :)


I'm also introducing myself because I want to become a maintainer of a new
package in Fedora/EPEL, the new package is called obal[2], there's already
one version of the package in copr. This package is heavily used by the
Foreman/Katello team, which I joined last month, we use it everyday in our
workstations and also in our tooling, obal is a python wrapper around
ansible, obal is the tool that we use to create/update/release packages for
Foreman/Katello/Satellite.

I already created one build on koji to check if the build would pass for
F34, obal[4] and python-obsah[5]. I'm uploading the 2 spec files to one
repo on github[6].

2 - https://github.com/theforeman/obal
3 - https://copr.fedorainfracloud.org/coprs/ekohl/obal/
4 - https://koji.fedoraproject.org/koji/taskinfo?taskID=69896768
5 - https://koji.fedoraproject.org/koji/taskinfo?taskID=69897019
6 - https://github.com/Odilhao/obal-specs


As the current maintainer of the copr, I happily support adding this to 
Fedora. However, I'm not sure I'm the right person to review given I 
authored the specs.

___
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 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)

[Ewoud Kohl van Wijngaarden]

On Tue, Jun 08, 2021 at 03:18:10PM +0200, Björn 'besser82' Esser wrote:

Unfortunately there is no automatic way to update the hash from
anything, but yescrypt, to yescrypt without knowing / entering the
actual user password; in the future existing yescrypt hashes can be
updated to new yescrypt hashes with stronger salts and/or cost
parameters in-place without changing the password, and without user
interaction.

Has anyone some better idea?


I'd advise against this. People can use a system like Puppet to sync 
password hashes between systems (as a cheap alternative to LDAP). If 
they use older distros that don't support it, it'll end up flapping 
where one system sets it to the older hashing and one to the newer.


Or maybe I'm just the only person who does this.
___
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

Self Introduction: Ewoud Kohl van Wijngaarden

[Ewoud Kohl van Wijngaarden]

Hello everyone,

https://fedoraproject.org/wiki/Join_the_package_collection_maintainers 
recommended to introduce myself so here it is.


My name is Ewoud Kohl van Wijngaarden (commonly known as ekohl) and I in 
my day job I work on the Foreman project[1]. Historically I've mostly 
been involved with the (Puppet-based) installer but over time I've also 
worked on most aspects of the project. Most notably I've also done quite 
a bit of the packaging[2].


Right now I want to become a Fedora maintainer to improve the state of 
the Puppet package and its dependencies. It's totally broken in Fedora 
34 which is holding back my F33 -> F34 upgrade.


I've also contributed patches upstream and have a good working 
relationship with Puppet (formerly Puppetlabs).


As a start I've reviewed a PR to update Facter[3].

Something else I'd like to do is bring puppet-resource_api into Fedora. 
Right now it's only packaged for EPEL8[4] but we'd need it in Fedora 
too.


Once that's all done, I'd like to update Puppet itself from 5.5.20 
(incompatible with Ruby 3) to 7.7.0. I have a patch ready, but need to 
fix it to also package the bundled modules.


So a concrete list of packages I'd be interested in keeping up to date:
* https://src.fedoraproject.org/rpms/facter
* https://src.fedoraproject.org/rpms/puppet
* https://src.fedoraproject.org/rpms/rubygem-puppet-resource_api

Regards,
Ewoud Kohl van Wijngaarden

[1]: https://theforeman.org/
[2]: https://github.com/theforeman/foreman-packaging
[3]: https://src.fedoraproject.org/rpms/facter/pull-request/7
[4]: https://src.fedoraproject.org/rpms/rubygem-puppet-resource_api
___
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