date:20240417

Re: F41 Change Proposal: Replace Redis with Valkey (system-wide)

2024-04-17 Thread Remi Collet


Le 17/04/2024 à 18:37, Maxwell G a écrit :

On Wed Apr 17, 2024 at 16:38 +0100, Aoife Moloney wrote:
Thank you for submitting this!


I agree we’ll have to get rid of redis in the future, and than such a 
switch will make a strong statement about our disapproval to redis about 
this License change.


But I also think this is a bit early (F41)

- Valkey is very young, and they is no proof it will be best choice

- Redis 7.2 is still there and maintained (even version 6.2 and 7.0 are 
maintained), and keeping it have no security issue.


So I’m -1 for F41 and probably +1 for F42


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

Re: F41 Change Proposal: Replace Redis with Valkey (system-wide)

2024-04-17 Thread Neal Gompa

On Wed, Apr 17, 2024 at 10:43 PM Nathan Scott  wrote:
>
> Hi Neal,
>
> On Thu, Apr 18, 2024 at 12:29 PM Neal Gompa  wrote:
> > [...]
> > retaining Redis will just hurt us in the long term.
>
> Noone is saying we should retain Redis.  I'm advocating for a more
> appropriate transition that is respectful of the work and expertise the
> existing package maintainers bring.
>
> I think f41 is appropriate and possible, but "more haste, less speed"
> is the way to get there, with minimal breakage to Fedora and users.
>

From my perspective, I don't see any breakage happening. We also
haven't *done* anything yet.


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

Picking up protobuf

2024-04-17 Thread Michel Lind

Hi all,

protobuf was recently orphaned without any announcement to this list.

I've picked it up since et depends on it.

Best regards,

-- 
 _o) Michel Lind
_( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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

Re: F41 Change Proposal: Replace Redis with Valkey (system-wide)

2024-04-17 Thread Nathan Scott

Hi Neal,

On Thu, Apr 18, 2024 at 12:29 PM Neal Gompa  wrote:
> [...]
> retaining Redis will just hurt us in the long term.

Noone is saying we should retain Redis.  I'm advocating for a more
appropriate transition that is respectful of the work and expertise the
existing package maintainers bring.

I think f41 is appropriate and possible, but "more haste, less speed"
is the way to get there, with minimal breakage to Fedora and users.

cheers.

--
Nathan
--
___
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: F41 Change Proposal: Replace Redis with Valkey (system-wide)

2024-04-17 Thread Neal Gompa

On Wed, Apr 17, 2024 at 9:52 PM Nathan Scott  wrote:
>
> Hi all,
>
> On Thu, Apr 18, 2024 at 2:38 AM Maxwell G  wrote:
> >
> > Thank you for submitting this!
>
> +1
>
> > > == Owner ==
> > > * Name: [[User:jonathanspw|Jonathan Wright]]
> > > * Email: jonat...@almalinux.org
> >
> > It would be nice to have Remi who currently maintains redis on board as 
> > well.
> >
>
> This is the second time this has been requested, but not yet actioned.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2274206
> https://src.fedoraproject.org/rpms/valkey
> https://src.fedoraproject.org/rpms/redis
>
> Can we resolve this before allowing this Change Proposal to proceed,
> please?  I think its in Fedora's interest to see 'new redis' maintained
> by group, rather than an individual, if the existing maintainers wish to
> (continue to) be involved.
>
> The 'new' valkey package is very closely derived from redis packaging
> which other Fedora maintainers have been looking after for ~14 years.
>
> There is no big rush to switch AFAICT though, as Redis[Labs] stated
> they continue to provide updates for redis-7.2.4 (including CVE fixes,
> which is a big part of the Fedora workload) for the foreseeable future.
>

On the contrary, we *have* to do it sooner rather than later. As
divergence among the forks occurs and the community shifts away,
retaining Redis will just hurt us in the long term. Not to mention,
now that they've pulled this change on us (after saying they wouldn't
five years ago), there's no guarantee that they'd continue to do
anything. Their word isn't worth a lot anymore.

> Some other technical questions:
> - it could be advantageous if the new compat sub-package contained
> the redis binary symlinks & not the primary valkey package (this could
> allow valkey and redict packages to coexist, for example).  Long-term
> we may want to drop those entirely (along with the compat package, to
> complete the transition away from Redis).

We will probably never be able to completely drop this, as stuff may
exist for a very long time that needs it.

> - what happened to the man page patch Remi made?  we should carry
> it forward into the new package (and try again with new upstream folks
> to get it merged there).

That patch should be completely rewritten for upstreaming anyway. It's
not written in a maintainable format, which really doesn't help for
upstreaming at all.



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

Re: F41 Change Proposal: Replace Redis with Valkey (system-wide)

2024-04-17 Thread Nathan Scott

Hi all,

On Thu, Apr 18, 2024 at 2:38 AM Maxwell G  wrote:
>
> Thank you for submitting this!

+1

> > == Owner ==
> > * Name: [[User:jonathanspw|Jonathan Wright]]
> > * Email: jonat...@almalinux.org
>
> It would be nice to have Remi who currently maintains redis on board as well.
>

This is the second time this has been requested, but not yet actioned.

https://bugzilla.redhat.com/show_bug.cgi?id=2274206
https://src.fedoraproject.org/rpms/valkey
https://src.fedoraproject.org/rpms/redis

Can we resolve this before allowing this Change Proposal to proceed,
please?  I think its in Fedora's interest to see 'new redis' maintained
by group, rather than an individual, if the existing maintainers wish to
(continue to) be involved.

The 'new' valkey package is very closely derived from redis packaging
which other Fedora maintainers have been looking after for ~14 years.

There is no big rush to switch AFAICT though, as Redis[Labs] stated
they continue to provide updates for redis-7.2.4 (including CVE fixes,
which is a big part of the Fedora workload) for the foreseeable future.

Some other technical questions:
- it could be advantageous if the new compat sub-package contained
the redis binary symlinks & not the primary valkey package (this could
allow valkey and redict packages to coexist, for example).  Long-term
we may want to drop those entirely (along with the compat package, to
complete the transition away from Redis).
- what happened to the man page patch Remi made?  we should carry
it forward into the new package (and try again with new upstream folks
to get it merged there).
- we need to coordinate on the handling of the redis modules in Fedora -
RediSearch, rebloom and rejson.  I've begun transitioning these working
with upstream, but more time would be helpful.

cheers.

--
Nathan
--
___
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: Three steps we could take to make supply chain attacks a bit harder

2024-04-17 Thread Kilian Hanich via devel


Am 17.04.24 um 23:34 schrieb Kevin Kofler via devel:

And in my view, the fact that, in those implementations, there is no
Treacherous Computing hardware preventing me from doing what I want with my
own private key (e.g., just copying the same key to all my devices, as I can
also do with TOTP) is actually a feature, even if it goes against the
"security" model.


The fact that you can share the keys is actually part of the design and
wanted. Apple for exmaple has (or wants to) implement easy sharing of
passkeys via AirDrop.


Regards

Kilian Hanich
--
___
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: Creating venv with latest python3.10 requires expat >= 2.6.0

2024-04-17 Thread Miro Hrončok


On 18. 04. 24 0:37, Miro Hrončok wrote:

On 17. 04. 24 23:10, Markus Falb wrote:

I wonder if there is a way to reflect that in the spec file
something like:

...snip
Requires: expat >= 2.6.0
snap...


Yes, we need to do that. I'm on it.


https://src.fedoraproject.org/rpms/python3.13/pull-request/54 -- other Pythons 
will follow after CI + review.




--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Creating venv with latest python3.10 requires expat >= 2.6.0

2024-04-17 Thread Miro Hrončok


On 17. 04. 24 23:10, Markus Falb wrote:

Hi,
I noticed that creating virtualenvs did not work anymore with the latest python 
3.10 package on Fedora 38


Hello Markus,

Thanks for the report, this is indeed happening.


[root@fe60c84b08f3 /]# python3.10 -m venv venv
Error: Command '['/venv/bin/python3.10', '-m', 'ensurepip', '--upgrade', 
'--default-pip']' returned non-zero exit status 1.
snap...


And the error is (when I run the failed command):

ImportError: 
/usr/lib64/python3.10/lib-dynload/pyexpat.cpython-310-x86_64-linux-gnu.so: 
undefined symbol: XML_SetReparseDeferralEnabled


Unfortunately this also happens with all python3.8 ... python3.13.

3.11 and 3.12 were still in updates testing, so I have blocked the autopush for 
now:


https://bodhi.fedoraproject.org/updates/FEDORA-2024-d615822702
https://bodhi.fedoraproject.org/updates/FEDORA-2024-98a723cb68

I am afraid this also impacts newer Fedoras once shipped with older expat.




https://www.python.org/downloads/release/python-31014/ tells us
... bundled libexpat was updated to 2.6.0 to address CVE-2023-52425...


And we unbundle it, yet we depend on the new symbol :(


using the fedora container for CI runs without doing global dnf update to save 
resources I had to update expat from
expat-2.5.0-2.fc38.x86_64
to
expat-2.6.0-1.fc38.x86_64


Fortunately, fedora:39 from registry.fedoraproject.org already has 
expat-2.6.2-1.fc39.



I wonder if there is a way to reflect that in the spec file
something like:

...snip
Requires: expat >= 2.6.0
snap...


Yes, we need to do that. I'm on it.

---

I wonder how to prevent this in the future. There is 
https://github.com/rpm-software-management/rpm/pull/2372 but that will take a 
while.

Perhaps we need to always Require expat >= version of expat used when building.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)

2024-04-17 Thread Maxwell G


On 4/17/24 02:20, Zbigniew Jędrzejewski-Szmek wrote:

I don't think we should make this particular functionality special.


Yeah, I tend to agree. If we want to reimagine the way BRP scripts work, 
that should be a separate discussion.

--
___
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: F41 Change Proposal - Reproducible Package Builds (System-Wide)

2024-04-17 Thread Maxwell G


On 4/13/24 06:41, Fabio Valentini wrote:

On Sat, Apr 13, 2024 at 1:18 PM Zbigniew Jędrzejewski-Szmek
  wrote:

Yes. But actually I think Rust is the optimal choice here. Writing
this in Python would be possibly slightly nicer, but we don't want
to pull the interpreter and packages into the buildroot. Python
also has the problem (challenge?) that it needs to be bootstrapped
once per year. The less packages are involved in the bootstrap, the
easier it is. And if the brp was written in Python, we'd need to
deal with that, and it would probably increase the number of builds
which are done without the cleanup. Having this as an indepedent
binary avoids some of the issues with bootstrap.

I think Rust*would*  be a good choice here ...
BUT add-determinism uses pyo3 to link to CPython, so it pulls in
python3-libs anyway.
So you get the downsides of pulling in Python without the upsides of
using Rust ...


Would it be possible to shell out to Python instead of using pyo3? I 
assume add-determinism's Python handler is not that complicated given 
that marshalparser does most of the work.
--
___
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: F41 Change Proposal - Reproducible Package Builds (System-Wide)

2024-04-17 Thread Fabio Valentini

On Wed, Apr 17, 2024 at 3:10 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> > Because this is written in Rust instead of Python, you will need a
> > build variant for *every* Python interpreter shipped in Fedora.
>
> No, just one one, at any given time.

Assuming that the marshalparser package can parse pyc files from newer
Python versions, I don't think this is necessary.

> Or in other words, it's the same as any application using Python in
> Fedora: it is built against some version of Python, usually the
> default one.
>
> (pyo3 has support for linking to the stable python abi, which
> theoretically would allow the program to be able to run with python
> versions newer than the one against which it was built. I didn't look
> at the details, so I don't know what would be needed to link it like
> that and whether that'd actually make things better for us.)

The functionality for building + linking only with the stable /
limited "abi3" CPython ABI is only relevant for *extension modules*,
i.e. Python modules that contain a native extension written in Rust.
This is not the case here - it's a Rust program that calls into
CPython (as opposed to the Python interpreter loading a native
extension module, which is effectively a "plugin" which is not linked
to libpython directly). add-determinism is linked *directly* to
libpython3.x.so, so it is only ever compatible with the major version
of the Python interpreter that it was built against.

Fabio
--
___
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: Three steps we could take to make supply chain attacks a bit harder

2024-04-17 Thread Kevin Kofler via devel

Gary Buhrmaster wrote:
> [2] As I understand it, the issue is the
> lack of the required trusted environment
> in generic Linux.  There are software
> implementations that do not have the
> hardware enclave protections,

And to be honest, I do not see the problem there. I will use whatever will 
let me pass the Fedora security theater checks without investing in extra 
hardware. (This also means that if I am offered the choice, I will pick TOTP 
over FIDO2 any day, because TOTP does not require me to emulate a fake 
hardware crypto device like FIDO2 does.)

And in my view, the fact that, in those implementations, there is no 
Treacherous Computing hardware preventing me from doing what I want with my 
own private key (e.g., just copying the same key to all my devices, as I can 
also do with TOTP) is actually a feature, even if it goes against the 
"security" model.

Kevin Kofler
--
___
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

Creating venv with latest python3.10 requires expat >= 2.6.0

2024-04-17 Thread Markus Falb

Hi,
I noticed that creating virtualenvs did not work anymore with the latest python 
3.10 package on Fedora 38

...snip
[root@fe60c84b08f3 /]# cat /etc/fedora-release
Fedora release 38 (Thirty Eight)
[root@fe60c84b08f3 /]# rpm -q python3.10
python3.10-3.10.14-1.fc38.x86_64
snap...

Here comes the error

...snip
[root@fe60c84b08f3 /]# python3.10 -m venv venv
Error: Command '['/venv/bin/python3.10', '-m', 'ensurepip', '--upgrade', 
'--default-pip']' returned non-zero exit status 1.
snap...

https://www.python.org/downloads/release/python-31014/ tells us
... bundled libexpat was updated to 2.6.0 to address CVE-2023-52425...

using the fedora container for CI runs without doing global dnf update to save 
resources I had to update expat from
expat-2.5.0-2.fc38.x86_64
to
expat-2.6.0-1.fc38.x86_64

I wonder if there is a way to reflect that in the spec file
something like:

...snip
Requires: expat >= 2.6.0
snap...

?

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

cloud-init + dhcpcd - dhclient

2024-04-17 Thread Major Hayden

Hey there,

I've updated cloud-init today to the latest version and as part of that change, 
it now uses dhcpcd rather than the unmaintained dhclient. The new versions are 
pending for rawhide and F40:

rawhide: https://bodhi.fedoraproject.org/updates/FEDORA-2024-afdd9f7364
F40: https://bodhi.fedoraproject.org/updates/FEDORA-2024-51d7f6b005

Cloud users shouldn't see any changes here since dhcpcd is used in the *very* 
early boot when cloud-init needs to hop on the network and retrieve metadata. 
It doesn't affect the operation of NetworkManager since it only runs *after* 
cloud-init has configured the network stack.

Thanks so much for all the help I received along the way on this one, 
especially Stephen Gallagher for helping to identify dhcpcd as a solution and 
to Zdenek Pytela for some SELinux policy updates. 

--
Major Hayden
--
___
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: F41 Change Proposal - Reproducible Package Builds (System-Wide)

2024-04-17 Thread Zbigniew Jędrzejewski-Szmek

On Wed, Apr 17, 2024 at 10:41:22AM -0700, Brian C. Lane wrote:
> On Sat, Apr 13, 2024 at 11:16:37AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > If we don't want to pull in an additional language framework, the
> > options are either a compiled language or a scripting language that is
> > already installed anyway, i.e. bash or awk. Considering that we want
> > to do multiprocessing and/or multithreading to make things quick, a
> > compiled language seems better. And among the compiled languages, I
> > think Rust should be the default choice nowadays.
> 
> But this does seem to be using python? The readme says it uses
> marshalparser and the pyc handler imports it:
> 
> https://github.com/keszybz/add-determinism/blob/ffdc8364839b42e22e846dce41061a061da64451/src/handlers/pyc.rs#L323
> 
> so you still need python, right?

Yes, kind of. Python and the marshalparser module are used for
.pyc files. The marshalparser module is already there, and I didn't
see a good reason to reimplement that code. But if there are no .pyc
files, that code is not used.

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

Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)

2024-04-17 Thread Brian C. Lane

On Sat, Apr 13, 2024 at 11:16:37AM +, Zbigniew Jędrzejewski-Szmek wrote:
> If we don't want to pull in an additional language framework, the
> options are either a compiled language or a scripting language that is
> already installed anyway, i.e. bash or awk. Considering that we want
> to do multiprocessing and/or multithreading to make things quick, a
> compiled language seems better. And among the compiled languages, I
> think Rust should be the default choice nowadays.

But this does seem to be using python? The readme says it uses
marshalparser and the pyc handler imports it:

https://github.com/keszybz/add-determinism/blob/ffdc8364839b42e22e846dce41061a061da64451/src/handlers/pyc.rs#L323

so you still need python, right?

Brian

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
--
___
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

Fedora CoreOS Community Meeting Minutes 2024-04-17

2024-04-17 Thread Gursewak Singh

Minutes:
https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2024-04-17/fedora-coreos-meeting.2024-04-17-16.32.html
Minutes (text):
https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2024-04-17/fedora-coreos-meeting.2024-04-17-16.32.txt
Log:
https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2024-04-17/fedora-coreos-meeting.2024-04-17-16.32.log.html

=
# #meeting-1:fedoraproject.org: fedora_coreos_meeting
=

Meeting started by @gurssing:matrix.org at 2024-04-17 16:32:01

Meeting summary
---
* TOPIC: roll call (@gurssing:matrix.org, 16:32:16) * TOPIC: Action items
from last meeting (@gurssing:matrix.org, 16:35:11) * TOPIC: Ship dnf in
FCOS and RHCOS (@gurssing:matrix.org, 16:36:45) * LINK:
https://github.com/coreos/fedora-coreos-tracker/issues/1687 (@gurssing:
matrix.org, 16:36:52) * TOPIC: Open Floor (@gurssing:matrix.org, 17:08:05)
Meeting ended at 2024-04-17 17:11:36 Action items


People Present (lines said)
---
* @jlebon:fedora.im (31)
* @siosm:matrix.org (28)
* @dustymabe:matrix.org (14)
* @gurssing:matrix.org (13)
* @zodbot:fedora.im (9)
* @jbtrystram:matrix.org (3)
* @meetbot:fedora.im (2)
* @ravanelli:matrix.org (2)
* @aaradhak:matrix.org (1)
* @marmijo:fedora.im (1)
* @jbrooks:matrix.org (1)
--
___
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: F41 Change Proposal: Replace Redit with Valkey (system-wide)

2024-04-17 Thread Tulio Magno Quites Machado Filho

Aoife Moloney  writes:

> == Scope ==
> * Proposal owners: add a valkey-compat package which will port Redis
> configurations to Valkey.  Valkey 7.2.5 is 100% compatible with Redis.
> Add "Obsolete: redis" to valkey-compat package.

I suggest to also mention in the presence of `Conflicts: redis` in the
change proposal. Just for clarity.

-- 
Tulio Magno
--
___
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: Handling --enable-experimental-jit in Python 3.13

2024-04-17 Thread Victor Stinner

On Wed, Apr 17, 2024 at 2:38 PM Miro Hrončok  wrote:
> Victor, do you think it would be possible to build in the JIT support but have
> a runtime opt-out/opt-in switch? That way, we can build it, but disable it by
> default, unless our users want to experiment with it.

PEP 744 "JIT Compilation" informal PEP is being discussed. I asked
your question there:
https://discuss.python.org/t/pep-744-jit-compilation/50756/33

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

Re: F41 Change Proposal: Replace Redis with Valkey (system-wide)

2024-04-17 Thread Maxwell G

On Wed Apr 17, 2024 at 16:38 +0100, Aoife Moloney wrote:
Thank you for submitting this!

> == Owner ==
> * Name: [[User:jonathanspw|Jonathan Wright]]
> * Email: jonat...@almalinux.org

It would be nice to have Remi who currently maintains redis on board as well.


> == Detailed Description ==
> We will replace Redis with Valkey due to the recent licensing changes
> in Redis, which have rendered it incompatible with Free and Open
> Source Software (FOSS) principles. This shift in Redis's licensing can
> impact Fedora's commitment to FOSS, potentially limiting users'
> freedom to modify and redistribute the software under the same terms.
> Valkey, a fork of Redis, emerges as a viable alternative because it
> retains a FOSS-compatible license and has robust community and
> developmental support. Adopting Valkey allows us to continue offering
> users a powerful in-memory data structure store without compromising
> on licensing restrictions.

I assume you've also considered https://codeberg.org/redict/redict as an
alternative? Redict seems more open to helping distributions. Redict
already plans to remove its in-tree, patched lua copy to benefit
distributions like ours that favor system libraries. It has committed to
using FOSS infrastructure (Codeberg, builds.sr.ht, Matrix, IRC, FOSS
container registry) instead of proprietary infrastructure (Github,
Discord) which is something that Fedora also values. It was started by
Drew Devault of Sourcehut who has a strong commitment to FOSS. On the
other hand, some of the original contributors and the Linux Foundation
have gotten behind Valkey. I would at least address Redict in passing in
the Change proposal even if you've already decided that Valkey is the
better choice.
--
___
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: F41 Change Proposal: Replace Redis with Valkey (system-wide)

2024-04-17 Thread Zbigniew Jędrzejewski-Szmek

On Wed, Apr 17, 2024 at 04:38:32PM +0100, Aoife Moloney wrote:
> == Contingency Plan ==
> * Contingency mechanism: (What to do?  Who will do it?) Do not
> obsolete Redis with Valkey
> * Contingency deadline: N/A

Hmm, is this coningency. plan realistic at all? IIUC, we can't update
redis, so we wouldn't want to make a new release with it.

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

Fedora 40 compose report: 20240417.n.0 changes

2024-04-17 Thread Fedora Branched Report

OLD: Fedora-40-20240416.n.0
NEW: Fedora-40-20240417.n.0

= SUMMARY =
Added images:3
Dropped images:  2
Added packages:  0
Dropped packages:0
Upgraded packages:   0
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   0 B
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Workstation live aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-40-20240417.n.0.iso
Image: i3 live aarch64
Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-40-20240417.n.0.iso
Image: Kinoite ociarchive ppc64le
Path: Kinoite/ppc64le/images/Fedora-Kinoite-40.20240417.n.0.ociarchive

= DROPPED IMAGES =
Image: KDE live aarch64
Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-40-20240416.n.0.iso
Image: Sericea ociarchive x86_64
Path: Sericea/x86_64/images/Fedora-Sericea-40.20240416.n.0.ociarchive

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

= DOWNGRADED 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal: Replace Redit with Valkey (system-wide)

2024-04-17 Thread Aoife Moloney

Apologies, this title should read *Redis*.
--
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal: Replace Redit with Valkey (system-wide)

2024-04-17 Thread Aoife Moloney

Apologies, this title should read *Redis*.
--
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Redis will no longer be OSS... now what?

2024-04-17 Thread Leon Fauster via devel

Am 17.04.24 um 16:44 schrieb Jonathan Wright:

On Wed, Apr 17, 2024 at 9:43 AM Leon Fauster via devel 
mailto:devel@lists.fedoraproject.org>> 
wrote:

Am 17.04.24 um 15:59 schrieb Jonathan Wright via devel:
 > Valley 7.2.5 stable was released yesterday.  Builds are in Bodhi and
 > ready for testing/feedback.
 >
 > https://bodhi.fedoraproject.org/updates/?search=valkey-7.2.5-1

 > >
 >

Thanks for the work on it. I wonder why valkey conflicts with redis,
redict for instance does not!? Is this a decision for a preferred
upgrade path? What about leaving this decision to the user (keydb,
redict, valkey, redis on RHEL, etc) and allowing parallel installation
for testing, decision making processes and migration.

It is due to redict renaming some libs, while valkey has opted to retain 
"redis" on some lib file names.

It seems to be just links in the bin directory that overlaps (and not 
libs). Why not putting these links into the compat subpackage including
also the conflict statement. That would allow to install the main 
package side-by-side to the other key-value-db forks.

--
Leon

--
___
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: Redis will no longer be OSS... now what?

2024-04-17 Thread Jonathan Wright via devel

On Wed, Apr 17, 2024 at 9:43 AM Leon Fauster via devel <
devel@lists.fedoraproject.org> wrote:

> Am 17.04.24 um 15:59 schrieb Jonathan Wright via devel:
> > Valley 7.2.5 stable was released yesterday.  Builds are in Bodhi and
> > ready for testing/feedback.
> >
> > https://bodhi.fedoraproject.org/updates/?search=valkey-7.2.5-1
> > 
> >
>
> Thanks for the work on it. I wonder why valkey conflicts with redis,
> redict for instance does not!? Is this a decision for a preferred
> upgrade path? What about leaving this decision to the user (keydb,
> redict, valkey, redis on RHEL, etc) and allowing parallel installation
> for testing, decision making processes and migration.
>
>
It is due to redict renaming some libs, while valkey has opted to retain
"redis" on some lib file names.


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


-- 
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat 
--
___
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: Redis will no longer be OSS... now what?

2024-04-17 Thread Leon Fauster via devel


Am 17.04.24 um 15:59 schrieb Jonathan Wright via devel:
Valley 7.2.5 stable was released yesterday.  Builds are in Bodhi and 
ready for testing/feedback.


https://bodhi.fedoraproject.org/updates/?search=valkey-7.2.5-1 





Thanks for the work on it. I wonder why valkey conflicts with redis,
redict for instance does not!? Is this a decision for a preferred
upgrade path? What about leaving this decision to the user (keydb, 
redict, valkey, redis on RHEL, etc) and allowing parallel installation

for testing, decision making processes and migration.

--
Leon

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

REMINDER: Fedora Linux 40 Final Go/No-Go Meeting Tomorrow

2024-04-17 Thread Aoife Moloney

Hi all,

Quick reminder that the Fedora Linux 40 Final Go/No-Go meeting[1] will be
held tomorrow, April 18th @ 1700 UTC in #meeting:fedoraproject.org on
Matrix.

At this time, we will determine the status of the F40 Final for the current
target
date[2] of Tuesday April 23rd. For more information about the Go/No-Go
meeting, see the wiki[3].



[1] https://calendar.fedoraproject.org/meeting/10791/
[2] https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html
[3] https://fedoraproject.org/wiki/Go_No_Go_Meeting



-- 

Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

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

[Test-Announce] REMINDER: Fedora Linux 40 Final Go/No-Go Meeting Tomorrow

2024-04-17 Thread Aoife Moloney

Hi all,

Quick reminder that the Fedora Linux 40 Final Go/No-Go meeting[1] will be
held tomorrow, April 18th @ 1700 UTC in #meeting:fedoraproject.org on
Matrix.

At this time, we will determine the status of the F40 Final for the current
target
date[2] of Tuesday April 23rd. For more information about the Go/No-Go
meeting, see the wiki[3].



[1] https://calendar.fedoraproject.org/meeting/10791/
[2] https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html
[3] https://fedoraproject.org/wiki/Go_No_Go_Meeting



-- 

Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

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

Re: Redis will no longer be OSS... now what?

2024-04-17 Thread Jonathan Wright via devel

Valley 7.2.5 stable was released yesterday.  Builds are in Bodhi and ready
for testing/feedback.

https://bodhi.fedoraproject.org/updates/?search=valkey-7.2.5-1

On Tue, Apr 9, 2024 at 12:54 PM Jonathan Wright 
wrote:

> Valkey 7.2.4 rc1 was released earlier today.  Package review opened at
> https://bugzilla.redhat.com/show_bug.cgi?id=2274206 which Neal Gompa has
> taken.
>
> Will update again when packages are in Bodhi testing.
>
> On Thu, Mar 28, 2024 at 1:41 PM Carlos Rodriguez-Fernandez <
> carlosrodrifernan...@gmail.com> wrote:
>
>> So, valkey is then the one the AWS employee did.
>>
>> Thank you Jonathan for the work on this.
>>
>> On 3/28/24 11:13, Jonathan Wright via devel wrote:
>> > This is the one previously known as "PlaceHolderKV".
>> >
>> > I forgot to mention but redict is packaged and ready for testing in
>> > Bodhi: https://bodhi.fedoraproject.org/updates/?search=redict-7.3.0~rc
>> > 
>> >
>> > I'll be packing up valkey as soon as they have a tagged release.
>> >
>> > After following redict and valkey closely for the past week or so I'm
>> > anticipating valkey becoming the defacto replacement for redis in most
>> > places.
>> >
>> > On Thu, Mar 28, 2024 at 1:09 PM Carlos Rodriguez-Fernandez
>> > mailto:carlosrodrifernan...@gmail.com>>
>>
>> > wrote:
>> >
>> > Valkey is another fork, sponsored by the Linux Foundation.
>> >
>> >
>> https://www.linuxfoundation.org/press/linux-foundation-launches-open-source-valkey-community
>> <
>> https://www.linuxfoundation.org/press/linux-foundation-launches-open-source-valkey-community
>> >
>> >
>> > It came out just today.
>> >
>> > On 3/23/24 11:35, Jonathan Wright via devel wrote:
>> >  > KeyDB builds are in Bodhi and ready for testing for all Fedora
>> > versions
>> >  > + EPEL8/9.
>> >  >
>> >  > https://bodhi.fedoraproject.org/updates/?search=keydb-6.3.4-2
>> > 
>> >  > > > >
>> >  >
>> >  > I'm still keeping an eye on, and chatting with the creators of
>> > the other
>> >  > two, redict and the unnamed one from an AWS employee and will
>> > package
>> >  > them when they have official builds.
>> >  >
>> >  > In the meantime I'd welcome any testing on the KeyDB packages in
>> > Bodhi.
>> >  >
>> >  > On Fri, Mar 22, 2024 at 11:10 PM Gary Buhrmaster
>> >  > mailto:gary.buhrmas...@gmail.com>
>> > > > >> wrote:
>> >  >
>> >  > On Sat, Mar 23, 2024 at 3:22 AM Kevin Kofler via devel
>> >  > > > 
>> >  > > > >> wrote:
>> >  >
>> >  >  > We will see whether that or redict will get the most
>> > attention. Cloud
>> >  >  > companies like Amazon will probably prefer BSD, whereas
>> >  > contributors worried
>> >  >  > about another "Redis, Inc." coming up and taking their
>> > forked code
>> >  >  > proprietary too will most likely prefer the LGPL fork
>> (redict)
>> >  > (unless they
>> >  >  > are unhappy about the use of version 3.0 only of the LGPL
>> > by that
>> >  > fork).
>> >  >
>> >  > "It is hard to make predictions, especially about the
>> future",
>> >  > but it appears that many of the recent non-redis contributors
>> >  > are cloud company entangled (and were previously willing to
>> >  > contribute under the BSD-3-Clause license).
>> >  > --
>> >  > ___
>> >  > 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
>> > 
>> >  > > >

Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)

2024-04-17 Thread Zbigniew Jędrzejewski-Szmek

On Wed, Apr 17, 2024 at 08:58:46AM -0400, Neal Gompa wrote:
> On Wed, Apr 17, 2024 at 5:30 AM Fabio Valentini  wrote:
> >
> > On Wed, Apr 17, 2024, 08:45 Tim Landscheidt  wrote:
> >>
> >> Zbigniew Jędrzejewski-Szmek  wrote:
> >>
> >> > […]
> >>
> >> >> - use dynamic buildrequires to detect what plugins are needed
> >>
> >> > My problem is that the binary is linked to the libpython3.12.so shared
> >> > library… The detection part is easy, the hard part is how to have the
> >> > binary work when the shared lib is not installed.
> >>
> >> Quick 'n' dirty: Have two binaries, unconditionally call
> >> add-determinism-python for *.pyc files, either from
> >> add-determinism or the BRP macro (which essentially should
> >> be called when %__brp_python_bytecompile is called?), rely
> >> on the packager to build-require add-determinism-python or
> >> require that from python3-devel (the missing binary should
> >> fail the build otherwise).
> >
> >
> > Something like this could be even made automatic.
> >
> > - split Python-specific functionality into a separate binary and subpackage 
> > of add-determinism
> > - add only add-determinism to the default buildroot
> > - add "Requires: (add-determinism-python if python3)" to add-determinism
> >
> > That way the pyc processing functionality would only be pulled in iff 
> > python3 is already getting installed by something else.
> 
> Because this is written in Rust instead of Python, you will need a
> build variant for *every* Python interpreter shipped in Fedora.

No, just one one, at any given time.

Or in other words, it's the same as any application using Python in
Fedora: it is built against some version of Python, usually the
default one.

(pyo3 has support for linking to the stable python abi, which
theoretically would allow the program to be able to run with python
versions newer than the one against which it was built. I didn't look
at the details, so I don't know what would be needed to link it like
that and whether that'd actually make things better for us.)

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

Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)

2024-04-17 Thread Neal Gompa

On Wed, Apr 17, 2024 at 5:30 AM Fabio Valentini  wrote:
>
> On Wed, Apr 17, 2024, 08:45 Tim Landscheidt  wrote:
>>
>> Zbigniew Jędrzejewski-Szmek  wrote:
>>
>> > […]
>>
>> >> - use dynamic buildrequires to detect what plugins are needed
>>
>> > My problem is that the binary is linked to the libpython3.12.so shared
>> > library… The detection part is easy, the hard part is how to have the
>> > binary work when the shared lib is not installed.
>>
>> Quick 'n' dirty: Have two binaries, unconditionally call
>> add-determinism-python for *.pyc files, either from
>> add-determinism or the BRP macro (which essentially should
>> be called when %__brp_python_bytecompile is called?), rely
>> on the packager to build-require add-determinism-python or
>> require that from python3-devel (the missing binary should
>> fail the build otherwise).
>
>
> Something like this could be even made automatic.
>
> - split Python-specific functionality into a separate binary and subpackage 
> of add-determinism
> - add only add-determinism to the default buildroot
> - add "Requires: (add-determinism-python if python3)" to add-determinism
>
> That way the pyc processing functionality would only be pulled in iff python3 
> is already getting installed by something else.

Because this is written in Rust instead of Python, you will need a
build variant for *every* Python interpreter shipped in Fedora.




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

Re: Handling --enable-experimental-jit in Python 3.13

2024-04-17 Thread Miro Hrončok


On 17. 04. 24 14:27, Victor Stinner wrote:

On Wed, Apr 10, 2024 at 8:23 PM Miro Hrončok  wrote:

Python 3.13 has an experimental JIT compiler:
https://docs.python.org/dev/whatsnew/3.13.html#experimental-jit-compiler

Enabling it is a configure (hence build-time) option.

How do we handle this in Fedora?

- We can keep it disabled, as it is experimental.


I concur with that.


- We can enable it, but be ready to revert if it causes problems.
- We can add yet another build variant, but we already have 4 of those
(regular, debug, freethreading, freethreading-debug), so I'd rather not make it
6 (or 8, if we include freethreading+jit combinations). I don't know yet if it
would be co-installable.


I don't think it's worth it.

Moreover, it doesn't build on Fedora 39 with clang-17, since Python
3.13 currently requires exactly clang-16.



We have multiple clangs/llvms:

https://src.fedoraproject.org/rpms/llvm16
https://src.fedoraproject.org/rpms/clang16

Victor, do you think it would be possible to build in the JIT support but have 
a runtime opt-out/opt-in switch? That way, we can build it, but disable it by 
default, unless our users want to experiment with it.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Handling --enable-experimental-jit in Python 3.13

2024-04-17 Thread Victor Stinner

On Wed, Apr 10, 2024 at 8:23 PM Miro Hrončok  wrote:
> Python 3.13 has an experimental JIT compiler:
> https://docs.python.org/dev/whatsnew/3.13.html#experimental-jit-compiler
>
> Enabling it is a configure (hence build-time) option.
>
> How do we handle this in Fedora?
>
> - We can keep it disabled, as it is experimental.

I concur with that.

> - We can enable it, but be ready to revert if it causes problems.
> - We can add yet another build variant, but we already have 4 of those
> (regular, debug, freethreading, freethreading-debug), so I'd rather not make 
> it
> 6 (or 8, if we include freethreading+jit combinations). I don't know yet if it
> would be co-installable.

I don't think it's worth it.

Moreover, it doesn't build on Fedora 39 with clang-17, since Python
3.13 currently requires exactly clang-16.

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

Re: Review request: mruby

2024-04-17 Thread Jarek Prokop



On 4/17/24 11:38 AM, Marián Konček wrote:
Nice catch, using it and removing the line "conf.enable_debug" makes 
the build use the proper flags. However, I still don't know how to 
tell Rake to add a `-Wl,-soname,...` option to each .so separately.


Check out `build_config/default.rb`. It has a lot of commented out 
options, one of those is config.linker. You can copy that over and 
adjust for Fedora.


Copying a bit of the following linker options into the host-shared.rb 
target, I get the -Wl,-z,relro etc from LDFLAGS in. However if something 
more is needed I do not know, but you can easily append more flags.

~~~
  # Linker settings
  conf.linker do |linker|
    linker.command = ENV['LD'] || 'gcc'
    linker.flags = ENV['LDFLAGS']
    linker.link_options = %Q[%{flags} -o "%{outfile}" %{objs} %{libs}]
  end
~~~

I'd also note that `readelf --dynamic` for any binary gives: `Shared 
library: [/builddir/build/BUILD/mruby-3.3.0/build/host/lib/libmruby.so]` 
and the solib has no NAME section on it.


It seems that for the host-shared config, `config.archiver` seems like 
the correct place for appending flags for .so files, since it is using GCC.
I spent some time with it, but so far I was unable to fully build 
everything properly with also the `-soname`. I got to libmruby_core.so, 
but then it started complaining for other artifacts. Probably the -L and 
-l options also need adjustments in the linker when it comes to paths 
after fixing the path.


It'll likely need more convincing. It seems it is doing a lot in 
absolute paths, almost everywhere with everything, including soname data.


To be more in line with the guidelines WRT to the -soname option.



On 16. 4. 2024 18:11, Jarek Prokop wrote:


On 4/16/24 4:16 PM, Marián Konček wrote:

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

I applied downstream changes which build a shared object (upstream 
provides no way of doing so, only a static library).


Upstream provides many ways to compile to many targets including 
using solibs, have a look:

https://github.com/mruby/mruby/tree/3.3.0/build_config

One can even write it themselves if the upstream ones doesn't cater 
to one's needs of their goal.


Definitions in that directory can be referred to in MRUBY_CONFIG 
variable used in rake command as the filename without the extension, 
for example to build a shared library:`rake MRUBY_CONFIG=host-shared 
all `


Though in my small tests some adjustment for the upstream code would 
be needed to have it respect Fedora {C,CXX,LD}FLAGS properly, but I 
might've missed something.


Regards,
Jarek
--

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

Re: Review request: mruby

2024-04-17 Thread Marián Konček

Nice catch, using it and removing the line "conf.enable_debug" makes the 
build use the proper flags. However, I still don't know how to tell Rake 
to add a `-Wl,-soname,...` option to each .so separately.


On 16. 4. 2024 18:11, Jarek Prokop wrote:


On 4/16/24 4:16 PM, Marián Konček wrote:

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

I applied downstream changes which build a shared object (upstream 
provides no way of doing so, only a static library).


Upstream provides many ways to compile to many targets including using 
solibs, have a look:

https://github.com/mruby/mruby/tree/3.3.0/build_config

One can even write it themselves if the upstream ones doesn't cater to 
one's needs of their goal.


Definitions in that directory can be referred to in MRUBY_CONFIG 
variable used in rake command as the filename without the extension, 
for example to build a shared library:`rake MRUBY_CONFIG=host-shared 
all `


Though in my small tests some adjustment for the upstream code would 
be needed to have it respect Fedora {C,CXX,LD}FLAGS properly, but I 
might've missed something.


Regards,
Jarek
--
___
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


--
Marián Konček
--
___
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: Handling --enable-experimental-jit in Python 3.13

2024-04-17 Thread Tomáš Orsava

I don't think it's a good idea to enable an experimental feature on the 
main Python that runs all the system tools, that could wreak untold 
havoc in ways we can't tell yet. Especially since it's a brand new 
experimental feature.


If we really want to try it, adding it as a variant sounds best to me. 4 
vs 6 build variants is not such a big leap, and for any time-sensitive 
work on the Python spec file it can be turned off anyway for scratch builds.


Tomas

On 4/10/24 20:23, Miro Hrončok wrote:

Hello Pythonistas,

Python 3.13 has an experimental JIT compiler:

https://docs.python.org/dev/whatsnew/3.13.html#experimental-jit-compiler

Enabling it is a configure (hence build-time) option.

How do we handle this in Fedora?

- We can keep it disabled, as it is experimental.
- We can enable it, but be ready to revert if it causes problems.
- We can add yet another build variant, but we already have 4 of those 
(regular, debug, freethreading, freethreading-debug), so I'd rather 
not make it 6 (or 8, if we include freethreading+jit combinations). I 
don't know yet if it would be co-installable.


Opinions?


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

Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)

2024-04-17 Thread Fabio Valentini

On Wed, Apr 17, 2024, 08:45 Tim Landscheidt  wrote:

> Zbigniew Jędrzejewski-Szmek  wrote:
>
> > […]
>
> >> - use dynamic buildrequires to detect what plugins are needed
>
> > My problem is that the binary is linked to the libpython3.12.so shared
> > library… The detection part is easy, the hard part is how to have the
> > binary work when the shared lib is not installed.
>
> Quick 'n' dirty: Have two binaries, unconditionally call
> add-determinism-python for *.pyc files, either from
> add-determinism or the BRP macro (which essentially should
> be called when %__brp_python_bytecompile is called?), rely
> on the packager to build-require add-determinism-python or
> require that from python3-devel (the missing binary should
> fail the build otherwise).
>

Something like this could be even made automatic.

- split Python-specific functionality into a separate binary and subpackage
of add-determinism
- add only add-determinism to the default buildroot
- add "Requires: (add-determinism-python if python3)" to add-determinism

That way the pyc processing functionality would only be pulled in iff
python3 is already getting installed by something else.

Fabio



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

Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)

2024-04-17 Thread Zbigniew Jędrzejewski-Szmek

On Wed, Apr 17, 2024 at 09:38:30AM +0200, Miroslav Suchý wrote:
> Dne 17. 04. 24 v 9:20 dop. Zbigniew Jędrzejewski-Szmek napsal(a):
> > > By adding this functionality to Mock itself. It can be optional 
> > > (--add-determinism). And then Mock can call
> > > 
> > >    add-determinism $chroot/%buildroot/
> > I don't think we should make this particular functionality special.
> > We have a bunch of brps:
> 
> It depends... if you want to have this check/sanitization part of rpmbuild.
> When it is small,and does not inflate buildroot, then fine.
> 
> Over the years, I learn that people have different view where each component 
> should go. :) I will not argue.
> 
> If you package add-determinism I can help you to add it to Mock. Likely as 
> plugin:
> 
> https://rpm-software-management.github.io/mock/#plugins
> 
> that is called in `postbuild`
> 
> https://rpm-software-management.github.io/mock/Plugin-Hooks
> 
> And by helping I mean that I will create the initial PR and you (and others) 
> will test the functionality. Deal?

Thank you for the offer. I _might_ take you up on it later, but
for now, I think it's better to keep this inside of the buildroot.

I don't think that this functionality should be tied to mock. Right
now, the helper runs for 'fedpkg local' (as all brps), but if it's
moved to mock, then we'd need to at least call it from two places.

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

Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)

2024-04-17 Thread Miroslav Suchý


Dne 17. 04. 24 v 9:20 dop. Zbigniew Jędrzejewski-Szmek napsal(a):

By adding this functionality to Mock itself. It can be optional 
(--add-determinism). And then Mock can call

   add-determinism $chroot/%buildroot/

I don't think we should make this particular functionality special.
We have a bunch of brps:


It depends... if you want to have this check/sanitization part of rpmbuild. When it is small,and does not inflate 
buildroot, then fine.


Over the years, I learn that people have different view where each component 
should go. :) I will not argue.

If you package add-determinism I can help you to add it to Mock. Likely as 
plugin:

https://rpm-software-management.github.io/mock/#plugins

that is called in `postbuild`

https://rpm-software-management.github.io/mock/Plugin-Hooks

And by helping I mean that I will create the initial PR and you (and others) 
will test the functionality. Deal?

--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
--
___
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: F41 Change Proposal - Reproducible Package Builds (System-Wide)

2024-04-17 Thread Zbigniew Jędrzejewski-Szmek

On Wed, Apr 17, 2024 at 08:39:48AM +0200, Miroslav Suchý wrote:
> Dne 16. 04. 24 v 10:04 odp. Zbigniew Jędrzejewski-Szmek napsal(a):
> > Hmm, how would that work? We call mock, which calls systemd-nspawn,
> > which runs rpmbuild, and the build env is completely isolated from the
> > host.
> 
> By adding this functionality to Mock itself. It can be optional 
> (--add-determinism). And then Mock can call
> 
>   add-determinism $chroot/%buildroot/

I don't think we should make this particular functionality special.
We have a bunch of brps:
+ /usr/lib/rpm/check-buildroot
+ /usr/lib/rpm/redhat/brp-ldconfig
+ /usr/lib/rpm/brp-compress
+ /usr/lib/rpm/redhat/brp-strip-lto
+ /usr/lib/rpm/brp-strip-static-archive
+ /usr/lib/rpm/check-rpaths
+ /usr/lib/rpm/redhat/brp-mangle-shebangs
+ /usr/lib/rpm/brp-remove-la-files
+ /usr/lib/rpm/redhat/brp-python-bytecompile
+ /usr/lib/rpm/redhat/brp-python-hardlink
And if such a feature is added, it should be generic to allow all
and any of those to be moved out of the build env.

In some ways, that'd be nice, because we wouldn't have to install
additional tools in the buildroot. But OTOH, those tools are rather
small and bash/find/etc probably need to be installed anyway. And
also, the package can configure and override the brps via macros. If
they were called from the outside, we'd need to at least figure out a
new protocol for that.

Certainly an interesting idea, but I'm not convinced, yet.

---

BTW.:
+ /usr/lib/rpm/brp-remove-la-files

This one means that various packages that remove .la files on their
own don't need to do this. Maybe we could have a pp sweep over the
specs and drop various 'find %{buildroot} -name *.la -delete'?

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

Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)

2024-04-17 Thread Tim Landscheidt

Zbigniew Jędrzejewski-Szmek  wrote:

> […]

>> - use dynamic buildrequires to detect what plugins are needed

> My problem is that the binary is linked to the libpython3.12.so shared
> library… The detection part is easy, the hard part is how to have the
> binary work when the shared lib is not installed.

Quick 'n' dirty: Have two binaries, unconditionally call
add-determinism-python for *.pyc files, either from
add-determinism or the BRP macro (which essentially should
be called when %__brp_python_bytecompile is called?), rely
on the packager to build-require add-determinism-python or
require that from python3-devel (the missing binary should
fail the build otherwise).

Tim
--
___
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: F41 Change Proposal - Reproducible Package Builds (System-Wide)

2024-04-17 Thread Miroslav Suchý


Dne 16. 04. 24 v 10:04 odp. Zbigniew Jędrzejewski-Szmek napsal(a):

Hmm, how would that work? We call mock, which calls systemd-nspawn,
which runs rpmbuild, and the build env is completely isolated from the
host.


By adding this functionality to Mock itself. It can be optional 
(--add-determinism). And then Mock can call

  add-determinism $chroot/%buildroot/


--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
--
___
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

44 matches

Mail list logo