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

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

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

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

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

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

Re: Review request: mruby

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:

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

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

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

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

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

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

Re: Review request: mruby

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

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

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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 >

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

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 >

Fedora 40 compose report: 20240417.n.0 changes

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

Fedora CoreOS Community Meeting Minutes 2024-04-17

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:

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

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

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

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

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

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

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

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`

Re: Three steps we could take to make supply chain attacks a bit harder

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

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

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

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

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

cloud-init + dhcpcd - dhclient

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:

Re: Three steps we could take to make supply chain attacks a bit harder

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

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

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

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

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

Picking up protobuf

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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"

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

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

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

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

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

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.