Re: [SPDX] Mass license change - batch #2 of all remaining packages
On Mon, Aug 26, 2024 at 7:17 AM Miroslav Suchý wrote: > > Yes, the package "inchi" will end up with with LicenseRef-IUPAC-InChI-Trust > license. But right now it is not on fedora-license-data because the wording > of the exception is missing. So right now the license will be recognized as > invalid. > > So my recomendation is to leave it to be mass converted to > LicenseRef-Callaway-* and when the issue #430 is resolved convert it to > LicenseRef-IUPAC-InChI-Trust. Ok, got it. I'm leaving it as it is for now. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Pyliblo3 fails to build on Fedora 41 with python 3.13.0
I am trying to build pyliblo3 from your repo on Fedora 41 with python 3.13.0. I've got a build error during compilation: # wget https://github.com/gesellkammer/pyliblo3/archive/refs/heads/master.zip # unzip pyliblo3-master.zip; cd pyliblo3-master; ./setup build root@fc41:/tmp/pyliblo3-master# ./setup.py build running build running build_py creating build creating build/lib.linux-x86_64-cpython-313 creating build/lib.linux-x86_64-cpython-313/pyliblo3 copying pyliblo3/__init__.py -> build/lib.linux-x86_64-cpython-313/pyliblo3 copying pyliblo3/_liblo.pyi -> build/lib.linux-x86_64-cpython-313/pyliblo3 running build_ext Compiling pyliblo3/_liblo.pyx because it changed. [1/1] Cythonizing pyliblo3/_liblo.pyx /usr/lib64/python3.13/site-packages/Cython/Compiler/Main.py:381: FutureWarning: Cython directive 'language_level' not set, using '3str' for now (Py3). This has changed from earlier releases! File: /tmp/pyliblo3-master/pyliblo3/_liblo.pxd tree = Parsing.p_module(s, pxd, full_module_name) building 'pyliblo3._liblo' extension creating build/temp.linux-x86_64-cpython-313 creating build/temp.linux-x86_64-cpython-313/pyliblo3 gcc -fno-strict-overflow -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -fcf-protection -fexceptions -fcf-protection -fexceptions -fcf-protection -fexceptions -O3 -fPIC -Ipyliblo3 -I/usr/include -I/usr/local/include -I/usr/include/python3.13 -c pyliblo3/_liblo.c -o build/temp.linux-x86_64-cpython-313/pyliblo3/_liblo.o -fno-strict-aliasing -Werror-implicit-function-declaration -Wfatal-errors pyliblo3/_liblo.c: In function ‘__pyx_f_8pyliblo3_6_liblo__msg_callback’: pyliblo3/_liblo.c:9011:92: error: passing argument 1 of ‘lo_blob_dataptr’ from incompatible pointer type [-Wincompatible-pointer-types] 9011 | __pyx_t_7 = __Pyx_PyBytes_FromCString(((unsigned char *)lo_blob_dataptr((__pyx_v_argv[__pyx_v_i]; if (unlikely(!__pyx_t_7)) __PYX_ERR(0, 274, __pyx_L1_error) | ~^~~~ | | | lo_arg * pyliblo3/_liblo.c:1353:78: note: in definition of macro ‘__Pyx_PyBytes_FromCString’ 1353 | #define __Pyx_PyBytes_FromCString(s) __Pyx_PyBytes_FromString((const char*)s) | ^ compilation terminated due to -Wfatal-errors. error: command '/usr/bin/gcc' failed with exit code 1 if i edit pyliblo3-master/pyliblo3/_liblo.c and change the line 9011 to: __pyx_t_7 = __Pyx_PyBytes_FromCString((unsigned char *)lo_blob_dataptr(*(struct lo_blob_ **)&__pyx_v_argv[__pyx_v_i])); if (unlikely(!__pyx_t_7)) __PYX_ERR(0, 274, __pyx_L1_error) pyliblo3 compiles with ./setup build. but how can I patch this file permanently ? Regards Martin -- ___ 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: `Unix-domain socket path "..." is too long (maximum 107 bytes)` can we change that?
* Peter Pentchev: > On Thu, Aug 22, 2024 at 05:06:53PM +0200, Florian Weimer wrote: >> * Lennart Poettering: >> > You don't really have to live with such a limitation. In systemd we >> > have code that works around this limitation via O_PATH. i.e. when >> > connect()ing you first open the socket inode with O_PATH, and then you >> > fire the connect() specifying /proc/self/fd/ as path. That always >> > fits into the 108ch limit. >> >> Do you think this is useful more generally? What about opening files >> with names longer than PATH_MAX? >> >> > bind()ing to an overly long unix socket path is also doable, but >> > harder (since you cannot O_PATH on an inode that doesn't exist >> > yet). The way I'd do it is via chdir() to the dir of the target path >> > and binding to a relative path then. But chdir() is of course icky, >> > since it's a global property of a process, hence will affect all >> > threads. Hence, maybe do this in a short-lived forked off process. >> >> I would have expected that it's possible to use a directory descriptor >> under /proc/self/fd as the base, but that doesn't seem to work for some >> reason. > > I think the reason is O_PATH - bind(2) is not among the syscalls that > it is documented to allow. However, see the attached program that > creates a subdirectory with a long name in the current working > directory, opens it without O_PATH, but with O_DIRECTORY, and then > binds a Unix-domain socket to /proc/self/fd/N; it works for me at > least on Debian testing and a month-or-two-old Fedora pre-42 Rawhide. Yes, that's what I meant with “as the base”. But my test program was broken, and fixing it allowed me to creat the socket. *However*, if you do this, getsockname keeps returning /proc/self/fd/3/meow even if descriptor 3 is closed. /proc/self/fd is also visible across process boundaries. I wonder if the socket name is actually /proc/self/fd/3/meow and not the alternate long name. But then why does it show up in the file system at this point? Anyway, this looks like it triggers some sort of kernel bug, so I really don't think this can be recommended as an approach. Thanks, Florian -- ___ 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: `Unix-domain socket path "..." is too long (maximum 107 bytes)` can we change that?
On Do, 22.08.24 17:06, Florian Weimer (fwei...@redhat.com) wrote: > > You don't really have to live with such a limitation. In systemd we > > have code that works around this limitation via O_PATH. i.e. when > > connect()ing you first open the socket inode with O_PATH, and then you > > fire the connect() specifying /proc/self/fd/ as path. That always > > fits into the 108ch limit. > > Do you think this is useful more generally? What about opening files > with names longer than PATH_MAX? Internally in systemd, we have a function chase() which basically does something like canonicalize_file_name(), but built around O_PATH, and ultimately returning an O_PATH fd. It resolves paths in userspace, taking alternative roots into account, being careful with symlinks and so on. As a side effect this means we do not have any limits on paths lengths anywhere. I mean, things like this I sense are really fundamental if you want to safely use the POSIX file system API, without risking being tricked into opening/creating files one shouldn't use by the various tricks available. But I have no illusions there: I think it's really tough to wrap this into a public libc-level API. > > bind()ing to an overly long unix socket path is also doable, but > > harder (since you cannot O_PATH on an inode that doesn't exist > > yet). The way I'd do it is via chdir() to the dir of the target path > > and binding to a relative path then. But chdir() is of course icky, > > since it's a global property of a process, hence will affect all > > threads. Hence, maybe do this in a short-lived forked off process. > > I would have expected that it's possible to use a directory descriptor > under /proc/self/fd as the base, but that doesn't seem to work for some > reason. Well, the path gets propagated into what /proc/net/unix shows, hence I don't think going via /proc/self/fd/ is desriable there. I think the best option is to use a relative bind then, via chdir() as I mentioned. It will then just show a relative path, which is not perfect, but at least communicates clearly what's going on, and still is descriptive. From my perspective I think having the ability to connect to sockets with arbitrarily long paths is a lot more interesting then the ability to bind to them. That's because connection paths often are result of concatenating paths due to nesting of chroot/container trees, bind mounting and such. But services typically bind their own sockets as somewhat constant singletons, without having to nest anything. Or in other words: if you provide an API via AF_UNIX, already for compat with other tools it's a really good idea to stick to a 109ch path. But if you connect to someone's API via AF_UNIX, you never know what you'll get passed because of bind mounts/nesting yadda yadda, it's great to be able to consume anything they throw at you then. It's an instance of the rule to be lenient in what you accept, and strict with what you generate i guess. Hence, in systemd's tree, we do the O_PATH thing only for connect(), we do not actually bother with any of that for the binding of sockets. Lennart -- Lennart Poettering, Berlin -- ___ 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: `Unix-domain socket path "..." is too long (maximum 107 bytes)` can we change that?
On Mon, Aug 26, 2024 at 12:06:23PM +0200, Florian Weimer wrote: > * Peter Pentchev: > > > On Thu, Aug 22, 2024 at 05:06:53PM +0200, Florian Weimer wrote: > >> * Lennart Poettering: > >> > You don't really have to live with such a limitation. In systemd we > >> > have code that works around this limitation via O_PATH. i.e. when > >> > connect()ing you first open the socket inode with O_PATH, and then you > >> > fire the connect() specifying /proc/self/fd/ as path. That always > >> > fits into the 108ch limit. > >> > >> Do you think this is useful more generally? What about opening files > >> with names longer than PATH_MAX? > >> > >> > bind()ing to an overly long unix socket path is also doable, but > >> > harder (since you cannot O_PATH on an inode that doesn't exist > >> > yet). The way I'd do it is via chdir() to the dir of the target path > >> > and binding to a relative path then. But chdir() is of course icky, > >> > since it's a global property of a process, hence will affect all > >> > threads. Hence, maybe do this in a short-lived forked off process. > >> > >> I would have expected that it's possible to use a directory descriptor > >> under /proc/self/fd as the base, but that doesn't seem to work for some > >> reason. > > > > I think the reason is O_PATH - bind(2) is not among the syscalls that > > it is documented to allow. However, see the attached program that > > creates a subdirectory with a long name in the current working > > directory, opens it without O_PATH, but with O_DIRECTORY, and then > > binds a Unix-domain socket to /proc/self/fd/N; it works for me at > > least on Debian testing and a month-or-two-old Fedora pre-42 Rawhide. > > Yes, that's what I meant with “as the base”. But my test program was > broken, and fixing it allowed me to creat the socket. > > *However*, if you do this, getsockname keeps returning > /proc/self/fd/3/meow even if descriptor 3 is closed. /proc/self/fd is > also visible across process boundaries. I wonder if the socket name is > actually /proc/self/fd/3/meow and not the alternate long name. But then > why does it show up in the file system at this point? Anyway, this > looks like it triggers some sort of kernel bug, so I really don't think > this can be recommended as an approach. Argh, I didn't even think about the "across process boundaries" aspect, and it is actually an important one - I think there is precedent for servers that have an out-of-band way to advertise to clients where the endpoints that they listen on are (at the very least there is varlink, but there surely are other ways, too). So, yeah, you are correct that this should not be recommended as a general approach, even with a list of caveats. Thanks! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com PGP key:https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 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: pyliblo3-0.13.0 error: unknown file type '.pxd' (from 'src/liblo.pxd')
the following patcch [3] fix_liblo3.patch should now working [1] https://martinkg.fedorapeople.org/ErrorReports/pyliblo3-0.16.2-0.1.git91d1781.fc41.src.rpm [2] https://martinkg.fedorapeople.org/ErrorReports/pyliblo3.spec [3] https://martinkg.fedorapeople.org/ErrorReports/fix_liblo3.patch Regards Martin -- ___ 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: [SPDX] Mass license change - batch #2 of all remaining packages
On Sun, Aug 25, 2024 at 3:18 AM Miroslav Suchý wrote:
>
> Here is the second batch of changes for 1000 packages
> (golang-github-danwakefield-fnmatch to perl-Image-Xbm)
>
> https://miroslav.suchy.cz/fedora/rest-of-callaway-batch2-normal-diff.txt
>
> Shorten version without the context is here:
>
> https://miroslav.suchy.cz/fedora/rest-of-callaway-batch2-small-diff.txt
>
> I will appreciate a review. If there will be no issue I will commit and push
> this to dist-git in a week. And then I will post another (larger) batch for a
> review.
In this:
%package -n crystalhd-firmware
Summary: Firmware for the Broadcom Crystal HD video decoder
-License: Redistributable, no modification permitted
+# Automatically converted from old format: Redistributable, no
modification permitted - review is highly recommended.
+License:
LicenseRef-Callaway-Freely-redistributable-no-modification-permitted
BuildArch: noarch
Requires: %{name} = %{version}-%{release}
It seems you are incorrectly converting from "Redistributable, no
modification permitted" to
"LicenseRef-Callaway-Freely-redistributable-no-modification-permitted"
instead of "LicenseRef-Callaway-Redistributable-no-modification-permitted".
I think under the Callaway system a distinction was drawn between
those two.
Richard
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Pyliblo3 fails to build on Fedora 41 with python 3.13.0
On Mon, 2024-08-26 at 07:40 +, Martin Gansser wrote: > I am trying to build pyliblo3 from your repo on Fedora 41 with python 3.13.0. > I've got a build error during compilation: > > # wget https://github.com/gesellkammer/pyliblo3/archive/refs/heads/master.zip > # unzip pyliblo3-master.zip; cd pyliblo3-master; ./setup build > > root@fc41:/tmp/pyliblo3-master# ./setup.py build > running build > running build_py > creating build > creating build/lib.linux-x86_64-cpython-313 > creating build/lib.linux-x86_64-cpython-313/pyliblo3 > copying pyliblo3/__init__.py -> build/lib.linux-x86_64-cpython-313/pyliblo3 > copying pyliblo3/_liblo.pyi -> build/lib.linux-x86_64-cpython-313/pyliblo3 > running build_ext > Compiling pyliblo3/_liblo.pyx because it changed. > [1/1] Cythonizing pyliblo3/_liblo.pyx > /usr/lib64/python3.13/site-packages/Cython/Compiler/Main.py:381: > FutureWarning: Cython directive 'language_level' not set, using '3str' for > now (Py3). This has changed from earlier releases! File: > /tmp/pyliblo3-master/pyliblo3/_liblo.pxd > tree = Parsing.p_module(s, pxd, full_module_name) > building 'pyliblo3._liblo' extension > creating build/temp.linux-x86_64-cpython-313 > creating build/temp.linux-x86_64-cpython-313/pyliblo3 > gcc -fno-strict-overflow -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 > -DNDEBUG -fcf-protection -fexceptions -fcf-protection -fexceptions > -fcf-protection -fexceptions -O3 -fPIC -Ipyliblo3 -I/usr/include > -I/usr/local/include -I/usr/include/python3.13 -c pyliblo3/_liblo.c -o > build/temp.linux-x86_64-cpython-313/pyliblo3/_liblo.o -fno-strict-aliasing > -Werror-implicit-function-declaration -Wfatal-errors > pyliblo3/_liblo.c: In function ‘__pyx_f_8pyliblo3_6_liblo__msg_callback’: > pyliblo3/_liblo.c:9011:92: error: passing argument 1 of ‘lo_blob_dataptr’ > from incompatible pointer type [-Wincompatible-pointer-types] > 9011 | __pyx_t_7 = __Pyx_PyBytes_FromCString(((unsigned char > *)lo_blob_dataptr((__pyx_v_argv[__pyx_v_i]; if (unlikely(!__pyx_t_7)) > __PYX_ERR(0, 274, __pyx_L1_error) > | > ~^~~~ > | > | > | > lo_arg * > pyliblo3/_liblo.c:1353:78: note: in definition of macro > ‘__Pyx_PyBytes_FromCString’ > 1353 | #define __Pyx_PyBytes_FromCString(s) > __Pyx_PyBytes_FromString((const char*)s) > | >^ > compilation terminated due to -Wfatal-errors. > error: command '/usr/bin/gcc' failed with exit code 1 > > if i edit pyliblo3-master/pyliblo3/_liblo.c > and change the line 9011 to: > __pyx_t_7 = __Pyx_PyBytes_FromCString((unsigned char > *)lo_blob_dataptr(*(struct lo_blob_ **)&__pyx_v_argv[__pyx_v_i])); if > (unlikely(!__pyx_t_7)) __PYX_ERR(0, 274, __pyx_L1_error) > > pyliblo3 compiles with ./setup build. > but how can I patch this file permanently ? I'm a bit confused who you're directing this to. Who is the "you" in "your repo"? You seem to be the person who submitted the review request for this package: https://bugzilla.redhat.com/show_bug.cgi?id=2307912 If you want to maintain a package, you should probably know how to generate and include patches, it's a basic skill for package maintenance. There is a guide at https://rpm-packaging-guide.github.io/#patching-software , although for software maintained in git, I would usually do it by checking out upstream git, committing the change to my local checkout, then using git format-patch to produce a patch file and copying it to the package directory. Miro already posted a patch for this issue in the FTBFS bug for pyliblo: https://bugzilla.redhat.com/show_bug.cgi?id=2248131#c5 -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ 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
rpminspect-data-fedora outdated?
Hi, isn't there a problem with rpminspect-data-fedora used in the bodhi automated tests? My recent build of s390utils failed on stuff that was no problem 2 weeks ago. Does rpminspect-data-fedora need branching? See eg. https://bodhi.fedoraproject.org/updates/FEDORA-2024-bb726e3bd3 and https://bodhi.fedoraproject.org/updates/FEDORA-2024-70c403f743 Thanks, Dan -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rpminspect-data-fedora outdated?
On 8/26/24 12:23, Dan Horák wrote: Hi, isn't there a problem with rpminspect-data-fedora used in the bodhi automated tests? My recent build of s390utils failed on stuff that was no problem 2 weeks ago. Does rpminspect-data-fedora need branching? See eg. https://bodhi.fedoraproject.org/updates/FEDORA-2024-bb726e3bd3 and https://bodhi.fedoraproject.org/updates/FEDORA-2024-70c403f743 Probably. A lot of the data files are mapped from the dist tag. Any time a new dist tag is created, that is not automatically created in rpminspect-data-fedora. The owner of the data has to do that. That's been entirely manual on my part so far. I solicited for volunteers to take over ownership and maintenance of rpminspect-data-fedora and have neglected to follow through on the hand over to them. I imagine people could come up with clever ways to automatically set up placeholder data files for new dist tags when we make a new dist tag for rawhide builds. As it stands right now, anyone can submit a PR with data file updates. Any time a PR is merged, it triggers a snapshot rebuild of the package in a Copr repo. These builds are what's used in gating. Ideally the "released" versions of rpminspect-data-fedora (and rpminspect-data-centos) would be more closely aligned with any snapshot builds, but that requires one or more package maintainers. That's why I was seeking out help. Thanks, -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT -- ___ 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: Pyliblo3 fails to build on Fedora 41 with python 3.13.0
Add to the following, "Aisleriot" and "Meld" I definitely need "Meld". Leslie Satenstein On Monday, August 26, 2024 at 12:22:18 p.m. EDT, Adam Williamson wrote: On Mon, 2024-08-26 at 07:40 +, Martin Gansser wrote: > I am trying to build pyliblo3 from your repo on Fedora 41 with python 3.13.0. > I've got a build error during compilation: > > # wget https://github.com/gesellkammer/pyliblo3/archive/refs/heads/master.zip > # unzip pyliblo3-master.zip; cd pyliblo3-master; ./setup build > > root@fc41:/tmp/pyliblo3-master# ./setup.py build > running build > running build_py > creating build > creating build/lib.linux-x86_64-cpython-313 > creating build/lib.linux-x86_64-cpython-313/pyliblo3 > copying pyliblo3/__init__.py -> build/lib.linux-x86_64-cpython-313/pyliblo3 > copying pyliblo3/_liblo.pyi -> build/lib.linux-x86_64-cpython-313/pyliblo3 > running build_ext > Compiling pyliblo3/_liblo.pyx because it changed. > [1/1] Cythonizing pyliblo3/_liblo.pyx > /usr/lib64/python3.13/site-packages/Cython/Compiler/Main.py:381: > FutureWarning: Cython directive 'language_level' not set, using '3str' for > now (Py3). This has changed from earlier releases! File: > /tmp/pyliblo3-master/pyliblo3/_liblo.pxd > tree = Parsing.p_module(s, pxd, full_module_name) > building 'pyliblo3._liblo' extension > creating build/temp.linux-x86_64-cpython-313 > creating build/temp.linux-x86_64-cpython-313/pyliblo3 > gcc -fno-strict-overflow -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 > -DNDEBUG -fcf-protection -fexceptions -fcf-protection -fexceptions > -fcf-protection -fexceptions -O3 -fPIC -Ipyliblo3 -I/usr/include > -I/usr/local/include -I/usr/include/python3.13 -c pyliblo3/_liblo.c -o > build/temp.linux-x86_64-cpython-313/pyliblo3/_liblo.o -fno-strict-aliasing > -Werror-implicit-function-declaration -Wfatal-errors > pyliblo3/_liblo.c: In function ‘__pyx_f_8pyliblo3_6_liblo__msg_callback’: > pyliblo3/_liblo.c:9011:92: error: passing argument 1 of ‘lo_blob_dataptr’ > from incompatible pointer type [-Wincompatible-pointer-types] > 9011 | __pyx_t_7 = __Pyx_PyBytes_FromCString(((unsigned char >*)lo_blob_dataptr((__pyx_v_argv[__pyx_v_i]; if (unlikely(!__pyx_t_7)) >__PYX_ERR(0, 274, __pyx_L1_error) > | > ~^~~~ > | > | > | > lo_arg * > pyliblo3/_liblo.c:1353:78: note: in definition of macro > ‘__Pyx_PyBytes_FromCString’ > 1353 | #define __Pyx_PyBytes_FromCString(s) __Pyx_PyBytes_FromString((const >char*)s) > | > ^ > compilation terminated due to -Wfatal-errors. > error: command '/usr/bin/gcc' failed with exit code 1 > > if i edit pyliblo3-master/pyliblo3/_liblo.c > and change the line 9011 to: > __pyx_t_7 = __Pyx_PyBytes_FromCString((unsigned char > *)lo_blob_dataptr(*(struct lo_blob_ **)&__pyx_v_argv[__pyx_v_i])); if > (unlikely(!__pyx_t_7)) __PYX_ERR(0, 274, __pyx_L1_error) > > pyliblo3 compiles with ./setup build. > but how can I patch this file permanently ? I'm a bit confused who you're directing this to. Who is the "you" in "your repo"? You seem to be the person who submitted the review request for this package: https://bugzilla.redhat.com/show_bug.cgi?id=2307912 If you want to maintain a package, you should probably know how to generate and include patches, it's a basic skill for package maintenance. There is a guide at https://rpm-packaging-guide.github.io/#patching-software , although for software maintained in git, I would usually do it by checking out upstream git, committing the change to my local checkout, then using git format-patch to produce a patch file and copying it to the package directory. Miro already posted a patch for this issue in the FTBFS bug for pyliblo: https://bugzilla.redhat.com/show_bug.cgi?id=2248131#c5 -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ 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/co
libsvm soname bump
Version 3.34 of libsvm has been released, and bumps the soname of the library. I would like to update libsvm and rebuild the consuming packages: - clisp - openms - perl-Algorithm-SVM I maintain clisp. The other maintainers are BCCed on this message. I will do these builds in Rawhide sometime next week, unless any maintainer has a reason why I should wait. I am open to opinions on whether builds should also be done for F41 or not. -- Jerry James http://www.jamezone.org/ -- ___ 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: pyliblo3-0.13.0 error: unknown file type '.pxd' (from 'src/liblo.pxd')
On Mon, Aug 26, 2024 at 10:13 AM Martin Gansser wrote: > > the following patcch [3] fix_liblo3.patch should now working > > [1] > https://martinkg.fedorapeople.org/ErrorReports/pyliblo3-0.16.2-0.1.git91d1781.fc41.src.rpm > [2] https://martinkg.fedorapeople.org/ErrorReports/pyliblo3.spec > [3] https://martinkg.fedorapeople.org/ErrorReports/fix_liblo3.patch > This last patch is incorrect; you should not be using upstream's Cythonized sources, but run Cython on the originals: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_using_cython > Regards > Martin -- Elliott -- ___ 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
[Test-Announce]Fedora 41 Branched 20240826.n.1 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 41 Branched 20240826.n.1. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: anaconda - 20240823.n.1: anaconda-41.30-1.fc41.src, 20240826.n.1: anaconda-41.31-1.fc41.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/41 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_41_Branched_20240826.n.1_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_41_Branched_20240826.n.1_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_41_Branched_20240826.n.1_Base https://fedoraproject.org/wiki/Test_Results:Fedora_41_Branched_20240826.n.1_Server https://fedoraproject.org/wiki/Test_Results:Fedora_41_Branched_20240826.n.1_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_41_Branched_20240826.n.1_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_41_Branched_20240826.n.1_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer -- ___ 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
Fedora 41 compose report: 20240826.n.1 changes
OLD: Fedora-41-20240824.n.0 NEW: Fedora-41-20240826.n.1 = SUMMARY = Added images:3 Dropped images: 4 Added packages: 12 Dropped packages:4 Upgraded packages: 141 Downgraded packages: 0 Size of added packages: 883.12 MiB Size of dropped packages:75.30 MiB Size of upgraded packages: 5.03 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 114.33 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Kinoite ociarchive x86_64 Path: Kinoite/x86_64/images/Fedora-Kinoite-41.20240826.n.1.ociarchive Image: Sericea ociarchive x86_64 Path: Sericea/x86_64/images/Fedora-Sericea-41.20240826.n.1.ociarchive Image: Server_KVM qcow2 ppc64le Path: Server/ppc64le/images/Fedora-Server-KVM-41-20240826.n.1.ppc64le.qcow2 = DROPPED IMAGES = Image: Workstation live-osbuild x86_64 Path: Workstation/x86_64/iso/Fedora-Workstation-Live-osb-41-20240824.n.0.x86_64.iso Image: LXQt live aarch64 Path: Spins/aarch64/iso/Fedora-LXQt-Live-aarch64-41-20240824.n.0.iso Image: Silverblue ociarchive ppc64le Path: Silverblue/ppc64le/images/Fedora-Silverblue-41.20240824.n.0.ociarchive Image: Workstation live-osbuild aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-osb-41-20240824.n.0.aarch64.iso = ADDED PACKAGES = Package: fyi-1.0.3-1.fc41 Summary: Command line utility to send desktop notifications RPMs:fyi fyi-bash-completion fyi-fish-completion Size:107.60 KiB Package: kubernetes1.30-1.30.4-1.fc41 Summary: Open Source Production-Grade Container Scheduling And Management Platform RPMs:kubernetes1.30 kubernetes1.30-client kubernetes1.30-kubeadm kubernetes1.30-systemd Size:438.81 MiB Package: kubernetes1.31-1.31.0-4.fc41 Summary: Open Source Production-Grade Container Scheduling And Management Platform RPMs:kubernetes1.31 kubernetes1.31-client kubernetes1.31-kubeadm kubernetes1.31-systemd Size:441.70 MiB Package: openjph-0.15.0-2.fc41 Summary: Open-source implementation of JPEG2000 Part-15 (or JPH or HTJ2K) RPMs:libopenjph libopenjph-devel openjph Size:645.87 KiB Package: python-PyAVM-0.9.6-2.fc41 Summary: Python package to handle Astronomy Visualization Metadata RPMs:python3-PyAVM Size:274.31 KiB Package: python-glfw-2.7.0-1.fc41 Summary: A ctypes-based wrapper for GLFW3 RPMs:python3-glfw Size:74.46 KiB Package: python-irodsclient-2.1.0-1.fc41 Summary: A python API for iRODS RPMs:python3-irodsclient Size:571.31 KiB Package: python-ndeflib-0.3.3-1.fc41 Summary: Python package for parsing and generating NFC Data Exchange Format messages. RPMs:python3-ndeflib Size:141.42 KiB Package: python-pydes-2.0.1^20240820gite988a5f-1.fc41 Summary: Pure python implementation of DES and TRIPLE DES encryption algorithm RPMs:python3-pyDes Size:26.76 KiB Package: python-reflink-0.2.2-1.fc41 Summary: Python wrapper around the reflink system calls RPMs:python-reflink-doc python3-reflink Size:313.52 KiB Package: rust-cli-table-derive-0.4.6-1.fc41 Summary: For printing tables on command line RPMs:rust-cli-table-derive+default-devel rust-cli-table-derive-devel Size:26.51 KiB Package: rust-jiff-0.1.10-1.fc41 Summary: Date-time library that encourages you to jump into the pit of success RPMs:rust-jiff+alloc-devel rust-jiff+default-devel rust-jiff+logging-devel rust-jiff+serde-devel rust-jiff+std-devel rust-jiff+tz-system-devel rust-jiff+tzdb-bundle-platform-devel rust-jiff+tzdb-zoneinfo-devel rust-jiff-devel Size:488.82 KiB = DROPPED PACKAGES = Package: pygobject2-2.28.7-22.fc41 Summary: Python 2 bindings for GObject RPMs:pygobject2 pygobject2-codegen pygobject2-devel pygobject2-doc Size:2.28 MiB Package: pygtk2-2.24.0-44.fc41 Summary: Python bindings for GTK+ RPMs:pygtk2 pygtk2-codegen pygtk2-devel pygtk2-doc Size:5.19 MiB Package: python2-cairo-1.18.2-17.fc41 Summary: Python 2 bindings for the cairo library RPMs:python2-cairo python2-cairo-devel Size:495.15 KiB Package: python2.7-2.7.18-43.fc41 Summary: Version 2.7 of the Python interpreter RPMs:python2.7 Size:67.34 MiB = UPGRADED PACKAGES = Package: CuraEngine_grpc_definitions-0.1.0-7.fc41 Old package: CuraEngine_grpc_definitions-0.1.0-6.fc41 Summary: gRPC Proto Definitions for CuraEngine RPMs: CuraEngine_grpc_definitions CuraEngine_grpc_definitions-devel Size: 1.82 MiB Size change: 1.03 KiB Changelog: * Sun Aug 25 2024 Benjamin A. Beasley - 0.1.0-7 - Rebuilt for abseil-cpp-20240722.0 Package: Macaulay2-1.24.05-3.fc41 Old package: Macaulay2-1.24.05-2.fc41 Summary: System for algebraic geometry and commutative algebra RPMs: Macaulay2 Size: 117.60 MiB Size change: -3.96 KiB Changelog: * Sat Aug 24 2024 Jerry James - 1.24.05-3 - Rebuild for Singular 4.4.0p4 Package: Singular-4.4.0p4-1.fc41 Old package: Singular-4.4.0p2-2.fc41 Summary: Computer Algebra System
Heads-up: usd 24.08 coming to Fedora 42/Rawhide and 41/Branched
In one week, 2024-09-02, I plan to update the usd package from 24.03 to 24.08[1] in F42/Rawhide and F41/Branched (where it will not reach the repositories until the end of the Beta Freeze). As always, this is an ABI-incompatible update with an SONAME version bump. The sole dependent package is blender. I used a local mock build to confirm that blender 4.2.1 is compatible with the new USD version, and repeated the exercise in COPR[2]. While the blender package in F41 and F42 has some Python 3.13 issues at the moment[3], it currently builds from source, and if that’s still true when I build usd then I will rebuild blender too. (Blender co-maintainers, please feel free to build further Blender updates during the F41 beta freeze into my side tag and ask me to “refresh” the Bodhi update to include them. I will send a follow-up email with the side tag when I do the builds.) [1] https://src.fedoraproject.org/rpms/usd/pull-request/25 [2] https://copr.fedorainfracloud.org/coprs/music/usd/packages/ [3] https://bugzilla.redhat.com/show_bug.cgi?id=2291492#c10 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
On Sat, Aug 03, 2024 at 10:05:55AM -0500, maxw...@gtmx.me wrote: > Report started at 2024-08-03 14:00:44 UTC > > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > python-tmuxp @epel-packagers-sig, orphan 4 weeks > ago I've just picked this up. Looks like Igor Raits fixed the FTI but did not take up the package, so I've now filed a request to unretire it https://pagure.io/releng/issue/12287 Igor, let me know if you want to co-maintain. 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: rpminspect-data-fedora outdated?
Dne 26. 08. 24 v 8:50 odp. David Cantrell napsal(a): Probably. A lot of the data files are mapped from the dist tag. Any time a new dist tag is created, that is not automatically created in rpminspect-data-fedora. The owner of the data has to do that. That's been entirely manual on my part so far. You can likely utilize https://github.com/rpm-software-management/fedora-distro-aliases -- 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
