checksec: Problem: conflicting requests in s390x

Hi, I am running the scratch build for rpms/ruby [1] rawhide branch right now, and I see the following error in the root.log on only s390x CPU architecture. Do you know what's wrong? https://koji.fedoraproject.org/koji/taskinfo?taskID=105910607 s390x:

Re: checksec: Problem: conflicting requests in s390x

On Fri, Sep 8, 2023 at 6:06 PM Yaakov Selkowitz wrote: > > On Fri, 2023-09-08 at 17:53 +0200, Jun Aruga wrote: > > I am running the scratch build for rpms/ruby [1] rawhide branch right > > now, and I see the following error in the root.log on only s390x CPU > > architecture. Do you know what's

Re: checksec: Problem: conflicting requests in s390x

> > > DEBUG util.py:442:- nothing provides python3.12dist(unicorn) >= > > > 1.0.2~rc1 needed by python3-pwntools-4.9.0-4.fc39.noarch from build > > > > This is a result of > > https://src.fedoraproject.org/rpms/unicorn/c/27cee3896b9c51abe3139222024e0a4def5e30e1?branch=rawhide > > > >

Re: checksec: Problem: conflicting requests in s390x

> > Why is the following one not a proper solution? I don't understand it. > > > > ``` > > Requires: %{_bindir}/nm > > ``` > > RPM cannot evaluate the %{_bindir} in Requires:. So it's essentially > looking for a virtual provides with those literal characters, which it > won't find. OK. I

Submit your questions and vote: Fedora on the Framework Laptop

Hi Fedora devel people, I am sending this email, as I think that you might be interested in this topic. We are going to have a talk session below at an event, Nest with Fedora on 4-6th August after around 2 weeks.[1] The topic is to give the community an idea of what Fedora people have done to

Missing the .gnu.version_d section in binaries on Fedora?

When I was trying to use binaries built on the Ubuntu environment, on Fedora 36, I couldn't use it due to the missing the `.gnu.version_d section`.[1] I tried to run Ruby's configure referring to the binary (wasi-sdk). And I got the errors below. ``` $ ./configure LDFLAGS="-Xlinker

Re: Missing the .gnu.version_d section in binaries on Fedora?

On Fri, Oct 21, 2022 at 2:32 PM Florian Weimer wrote: > > * Jun Aruga: > > > When I was trying to use binaries built on the Ubuntu environment, on > > Fedora 36, I couldn't use it due to the missing the `.gnu.version_d > > section`.[1] I tried to run Ruby's configure referring to the binary > >

Re: Packaging a cross-compilation environment (wasi-libc)

On Mon, Oct 24, 2022 at 1:19 PM Jan Staněk wrote: > > Hi Jun, > > "Jun Aruga (he / him)" writes: > > Do you have a plan to create the RPM package for wasi-sdk[1]? > > Not really, since we already (almost) have it available :) > > The wasi-sdk consists of l

Re: Packaging a cross-compilation environment (wasi-libc)

Hi Jan, Thanks for the work around WebAssembly. Do you have a plan to create the RPM package for wasi-sdk[1]? The coming Ruby new version 3.2 supports WebAssembly, and it requires wasi-sdk to use it.[2] But the released wasi-sdk binaries on the upstream project don't have the binary

Re: Packaging a cross-compilation environment (wasi-libc)

> So, I am building the wasi-sdk from the source on Fedora 36. But I > feel it takes more than 60 minutes, and is still in progress. > I wonder how other program languages supporting WebAssembly manage > this situation. I just finished building the source. The building time was 60 minutes. ``` $

Re: Submit your questions and vote: Fedora on the Framework Laptop

Thanks for attending this talk session! Now the recording is available on the event platform Hopin. And I created the detailed chapters (timecodes) of the video. You can see the link below to find it. https://pagure.io/flock/issue/389#comment-809656 Jun On Tue, Jul 19, 2022 at 6:23 PM Jun Aruga

Re: Can't pull fedora rawhide container image

Thanks! I confirmed it works now. On Thu, Dec 8, 2022 at 9:58 PM Clement Verna wrote: > > This is fixed now, happy containering :-D -- Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic See for the timezone.

Re: RISC-V -- are we ready for more, and what do we need to do it?

I posted the same article on Fedora Discussion.[1] However let me share it again on the devel@ to tell it to many people. This is interesting news about RISC-V this week. Perhaps, it’s time to prepare to add the RISC-V CPU to the Koji build system? Google wants RISC-V to be a “tier-1” Android

HyperKitty: Thread tree broken?

I see one issue on HyperKitty on the Fedora project. Below is thread 1 and 2 for the actual thread: "RISC-V -- are we ready for more, and what do we need to do it?" Do you know why it's not one thread page? 1.

Re: HyperKitty: Thread tree broken?

> > > 1. > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/Z2RR2OE5TAQH5CVJ5VB5T3R7OM5ULYPQ/#QZUTH6DSULKYBMGPPYNZMPX7YSYKOBTT > > > 2. > > >

Re: WASM from Ruby - Lightning Chess Web App

> On 2023-01-09 00:36, Jun Aruga (he / him) wrote: > > On Sun, Jan 8, 2023 at 11:51 AM Philip Rhoades via devel > > wrote: > >> > >> People, > >> > >> Over the holidays we had our irregular Family Lightning Chess > >> comp

Can't pull fedora rawhide container image

I am trying to pull the fedora rawhide image from https://registry.fedoraproject.org/ . First, the URL below to print available tags is empty on my browser. https://registry.fedoraproject.org/repo/fedora/tags/ But I was able to see the available tags by skopeo. And the "rawhide" tag is included.

Re: Can't pull fedora rawhide container image

On Thu, Dec 8, 2022 at 11:02 AM Clement Verna wrote: > > There is a BZ to track this too > https://bugzilla.redhat.com/show_bug.cgi?id=2151833 > > > On Thu, 8 Dec 2022 at 10:50, Clement Verna wrote: >> >> The last working build [1] had only the aarch64 image. Since the rawhide >> images are

Re: Web Assembly on Fedora: interested in a Fedora SIG to work on this?

The Ruby new version 3.2.0 will start to support Web Assembly. It is planned to release the official version next month. https://www.ruby-lang.org/en/news/2022/11/11/ruby-3-2-0-preview3-released/ https://github.com/ruby/ruby/blob/master/wasm/README.md However, I had to build the necessary tools

Re: Web Assembly on Fedora: interested in a Fedora SIG to work on this?

I am happy to join the group Now. I have a limited time, and more prioritized tasks in Fedora, but maybe I can help something for the SIG. -- Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic See for the timezone.

Re: WASM from Ruby - Lightning Chess Web App

On Sun, Jan 8, 2023 at 11:51 AM Philip Rhoades via devel wrote: > > People, > > Over the holidays we had our irregular Family Lightning Chess > competition (10 seconds per move) - I have not found an online web site > that will work exactly with our rules and it occurs to me that this > would be

Re: New WASM related mailing list

On Thu, Jan 19, 2023 at 6:23 PM Zuzana Svetlikova wrote: > > Hi all, > > as there has been an interest in creating WASM SIG, I moved on with it. > > You can already join our mailing list: wasm-...@lists.fedoraproject.org Thanks for the malling list! I just wanted to share the page to subscribe

Re: New WASM related mailing list

>> as there has been an interest in creating WASM SIG, I moved on with it. >> >> You can already join our mailing list: wasm-...@lists.fedoraproject.org Thanks for the malling list! I just wanted to share the page to subscribe to the WASM SIG.

Re: SIG status, visibility, etc. [Re: Risc-V SIG?

> I am big fan of using FAS for SIG membership: > > https://fedoraproject.org/wiki/SIGs/Ruby#Members > > Not that we would did some cleanup of that group, but in theory, the > inactive members could be removed easier then just editing some random > wiki page. I am sure that maintaining members of

Unretired and BuildError: blocked for tag f39-updates-candidate

I reviviced a retired package (rpms/smide) by the process below. https://pagure.io/releng/issue/11281 Then when I added a new commit to rebase on the rawhide branch, and build, I got the following error by `fedpkg build`. Do you know what's wrong and what I need to do to fix the error?

Re: Self Introduction:

On Tue, Feb 28, 2023 at 10:19 PM Kanagaraj, Raghavan wrote: > > Hi All, > > I work as a Senior Kernel Engineer in Intel. I am responsible to create > Intel-cmt-cat package for Intel. I would like to join in Fedora packager > group. So that I can create and release the Intel-cmt-cat package

Re: It’s time to transform the Fedora devel list into something new

In my opinion, in this kind of big change, it's important for us to make things reversible, and to consider a possibility for us to go back. I think it's better for us to keep the infra of the mailing list for a while. When we migrate the devel@ to the discourse, we should still keep to manage

Re: openldap: gdb: symbol lookup error: /lib64/libldap.so.2: undefined symbol: EVP_md2, version OPENSSL_3.0.0

th the system area. > You shouldn't replace or shadow the system library with your own one, > otherwise you get PROBLEMS. > > On Tue, Mar 28, 2023 at 3:06 PM Jun Aruga (he / him) > wrote: > > > > Dear Dmitry, > > > > Thanks! The workaround worked! >

openldap: gdb: symbol lookup error: /lib64/libldap.so.2: undefined symbol: EVP_md2, version OPENSSL_3.0.0

Hi, I opened this issue's ticket for openldap on Bugzilla. https://bugzilla.redhat.com/show_bug.cgi?id=2181668 But let me ask on the devel@ mailing list too, as I want to debug a program with gdb and the source-compiled openssl soon. I am using Fedora 37. I built the openssl 3.0.8 from the

Re: openldap: gdb: symbol lookup error: /lib64/libldap.so.2: undefined symbol: EVP_md2, version OPENSSL_3.0.0

Belyavskiy wrote: > > Dear Jan, > > Yes. gdb expects system openssl (providing this function) > > To workaround it, you have to provide the LD_SET_LIBRARY inside gdb, via > (gdb) set environment LD_LIBRARY_PATH /home/jaruga/.local/openssl-3.0.8/lib/ > > On Mon, Mar 27, 20

Re: List of long term FTBFS packages to be retired this week and orphaned now

Hi Miro, Sorry I will fix and rebuild the packages below on the rawhide asap. > bowtie jaruga, verdurin ... > simde jaruga -- Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic See

Re: Risc-V SIG?

> Yep. Sigs exist because they say they do. ;) > > The risc-v sig has been around for a while, but I guess a sig wiki page > was never made. :( > > So, sure, we should setup a page and point to the discussion topic and > irc/matrix rooms. :) > > If you could do that it would be great... otherwise

Re: RISC-V -- are we ready for more, and what do we need to do it?

This is exciting news related to the RISC-V ecosystem. I expect that the RISC-V Software Ecosystem (RISE) Project will be a leading organization to help open source projects by providing free RISC-V CI services to them, and sponsoring the free RISC-V SSH servers on the clouds to them. It is like

Re: RISC-V -- are we ready for more, and what do we need to do it?

> Red Hat is a member. In fact there's an (internal) kick-off meeting > for RISE today which I'll be attending. I saw that Red Hat is a member of the RISE project on the page. And it's really great to see that you will be attending the kick-off meeting. Thank you for that. I am looking forward

Re: disabling yum modular repos by default?

> "No fedora-repos-modular in default installation" ? I feel that's a better way than disabling (enabled=0) module repos by default. /etc/yum.repos.d/fedora-modular.repo /etc/yum.repos.d/fedora-updates-modular.repo #enabled=1 enabled=0 For people who want to use the modularity, once they

Re: disabling yum modular repos by default?

> 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. I am in the Ruby SIG. In the case of Ruby, I don't think we have the

Re: disabling yum modular repos by default?

On Tue, May 9, 2023 at 6:32 AM Jens-Ulrik Petersen wrote: > > I have been thinking about proposing a Change to Fedora 39, > which would disable yum modular repos by default in installs. > I thought I would float the idea here first. > > I suspect the vast majority of Fedora users don't use > the

mock: ImportError: /lib64/libdnf.so.2: undefined symbol: g_once_init_enter_pointer

Hello, I faced the following error by running the mock for Fedora rawhide on my Fedora 39 local environment. Anyone, do you know how to avoid this error? Thanks for your help. I filed this issue to the Bugzilla ticket below. ImportError: /lib64/libdnf.so.2: undefined symbol:

Re: mock: ImportError: /lib64/libdnf.so.2: undefined symbol: g_once_init_enter_pointer

On Wed, Feb 21, 2024 at 6:05 PM Miroslav Suchý wrote: > > Dne 21. 02. 24 v 17:38 Jun Aruga (he / him) napsal(a): > > $ mock -r fedora-rawhide-x86_64 --shell > > > > --setenv=LC_MESSAGES=C.UTF-8 --resolv-conf=off /usr/bin/dnf-3 > --disableplugin=versionl

Re: mock: ImportError: /lib64/libdnf.so.2: undefined symbol: g_once_init_enter_pointer

On Wed, Feb 21, 2024 at 6:09 PM Stephen Smoogen wrote: > > > > On Wed, 21 Feb 2024 at 12:05, Miroslav Suchý wrote: >> >> Dne 21. 02. 24 v 17:38 Jun Aruga (he / him) napsal(a): >> >> $ mock -r fedora-rawhide-x86_64 --shell >> >> >> >

Re: mock: ImportError: /lib64/libdnf.so.2: undefined symbol: g_once_init_enter_pointer

> That said, DNF3 should work too. But instead of hunting this bug it may be > easier to update configs and use DNF5 that should be used anyway. As my mock-core-configs RPM version is below, I got the same version's RPM from the koji build link below, and plan to recover the files in the

Re: Help packaging PyTorch dependencies for Fedora

Congratulations for the PyTorch package! https://src.fedoraproject.org/rpms/python-torch I hope someone will announce this great achievement to the Fedora community too, and update the following page too. https://fedoraproject.org/wiki/SIGs/PyTorch/packagingStatus Jun On Wed, Oct 11, 2023 at

Re: mock: ImportError: /lib64/libdnf.so.2: undefined symbol: g_once_init_enter_pointer

> Fedora 35 ^^ buildroot? Probably something to check. My /etc/mock/fedora-rawhide-x86_64.cfg had the `config_opts['releasever'] = '35'`. I changed it to the `config_opts['releasever'] = '41'`. As I still see the same error, it's not the root cause. But I need to recover files the /etc/mock from

Re: mock: ImportError: /lib64/libdnf.so.2: undefined symbol: g_once_init_enter_pointer

Hi, I restored the /etc/mock ``` $ rpm -q mock-core-configs mock-core-configs-40.1-1.fc39.noarch $ sudo dnf upgrade mock-core-configs $ rpm -q mock-core-configs mock-core-configs-40.2-1.fc39.noarch ``` I needed to copy the logging.ini manually, as I saw an error related to this file when

Re: mock: ImportError: /lib64/libdnf.so.2: undefined symbol: g_once_init_enter_pointer

> I see that the `/usr/bin/dnf5` doesn't exist in the > `/var/lib/mock/fedora-rawhide-x86_64-bootstrap`. Do you know how to > fix it? Now the error `/usr/bin/dnf5` doesn't exist in the `/var/lib/mock/fedora-rawhide-x86_64-bootstrap` came from a cache. When I ran the following commands, I was able

Re: F41 Change Proposal: Disable openSSL Engine Support (system-wide)

On Wed, Mar 20, 2024 at 2:36 PM Dmitry Belyavskiy wrote: > ... >> > == Detailed Description == >> > We are going to build OpenSSL without engine support. Engines are not >> > FIPS compatible and corresponding API is deprecated since OpenSSL 3.0. >> > The engine functionality we are aware of

Re: F41 Change Proposal: Disable openSSL Engine Support (system-wide)

On Thu, Mar 21, 2024 at 12:16 PM Dmitry Belyavskiy wrote: > > Dear Jun, > > > > On Thu, Mar 21, 2024 at 11:04 AM Jun Aruga (he / him) > wrote: >> >> On Wed, Mar 20, 2024 at 2:36 PM Dmitry Belyavskiy >> wrote: >> > >> ... >> >>