Re: Fedora 41 Python 3.13 mass rebuild status
On 14-06-2024 06:47, Ryan Bach via devel wrote: Could not depsolve transaction; 1 problem detected: Problem: conflicting requests nothing provides libboost_python312.so.1.83.0()(64bit) needed by blender-1:4.1.1-7.fc41.x86_64 from rawhide Assuming there's a question you having about the output. It means blender hasn't been rebuild against Python 3.13 yet and thus still depends on Python 3.12. According to the FTI bug filed after the merge of 3.13 into rawhide [1], this is blocked by python-pyproj [2] and usd [3] failing to build with Python 3.13. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2291492 [2] https://bugzilla.redhat.com/show_bug.cgi?id=2291596 [3] https://bugzilla.redhat.com/show_bug.cgi?id=2292015 -- Sandro -- ___ 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: Anaconda as native Wayland application (System Wide)
On Tue, Jun 11, 2024 at 04:22:24PM +0200, Jiri Konecny wrote: > On 11. 06. 24 11:53, Neal Gompa wrote: > > On Tue, Jun 11, 2024 at 10:41 AM Jiri Konecny wrote: > > > On 04. 06. 24 14:27, Neal Gompa wrote: > > > > On Tue, Jun 4, 2024 at 8:23 AM Jiri Konecny wrote: > > > > > > > > > > On 03. 06. 24 21:57, Jason L Tibbitts III wrote: > > > > > > > > > > > Aoife Moloney writes: > > > > > > > === VNC switch to RDP for remote GUI installations === > > > > > > I'm curious how my usual install workflow will be affected by this > > > > > > change. I use the kickstart "vnc --connect" option extensively in > > > > > > my > > > > > > workflow; I may have a bunch of installs running in parallel, and > > > > > > they > > > > > > just connect and display when they are ready. I use vinagre as the > > > > > > vnc > > > > > > client. > > > > > > > > > > > > It's not a huge thing; I could come up with another workflow but > > > > > > that's > > > > > > the one I've used since before Fedora existed. The installs are > > > > > > fully > > > > > > automated and the display connection is only used so that I can see > > > > > > the > > > > > > progress and potentially interact with a machine if it encounters a > > > > > > problem. I guess in the worst case I could just do the install > > > > > > blind > > > > > > and ssh in if something takes too long. > > > > > Hi, the only change should be that you will change "vnc --connect" > > > > > with > > > > > the new API we will provide and also use RDP as your client instead > > > > > of VNC. > > > > > > > > > Given that gnome-remote-desktop supports both VNC and RDP, can't VNC > > > > support still be wired up? > > > > > > > Hi, it is theoretically possible but we are not planning to do that > > > until there will be a reason for that. AFAIK it's not that simple change > > > to do that. > > > > > I think the reason is pretty obvious: there are many more high quality > > VNC clients than there are RDP ones. And even ignoring that, the > > existing Anaconda workflows for remote GUI expect VNC. There is no > > technical limitation preventing us from having VNC support through > > grd. In fact, one of the original reasons I wrote the Weston backend > > for Anaconda was so that I could have VNC for Linux and web clients, > > because the RDP clients are not very good in my experience. > > > In any case, I would see this more like a future improvement if we agree to > go this way. I would like to simplify things for now, it's already a big > change. > > Anyway, Jonas, could you please share your recommendation here as owner of > grd? Do you think that VNC should be enabled in grd? Currently in upstream grd VNC support is implemented using LibVNCServer, and completely lacks any way of encryption. Other than that, there are awkward limitations of password lengths that may be present, depending on various factors. All in all, it's awful for security. There are three things that would make me comfortable recommending making VNC an option: * Changing implementation to use neatvnc instead of LibVNCServer. The impression I have is that this VNC implementation has a bit higher code quality compared to LibVNCServer. * Implement TLS key/cert based encryption and require that by default, while dropping the anontls support we have downstream in Fedora. * Remove the "prompt" authorization method from grd. Other than that, a probably unenforcable thing would be to not allow it being exposed to the wider Internet. Jonas > > Best Regards, > Jirka -- ___ 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: heads up: julia has a bunch of incorrect Provides (bug 2291191)
On Mon, Jun 10, 2024 at 11:57 PM Adam Williamson wrote: > > On Mon, 2024-06-10 at 20:57 +0200, Fabio Valentini wrote: > > On Mon, Jun 10, 2024 at 8:52 PM Fabio Valentini > > wrote: > > > > > > On Mon, Jun 10, 2024 at 8:49 PM Colin Walters wrote: > > > > > > > > Worth a bit of wide distribution as I'm sure I'm not the only one who > > > > got burned: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2291191 > > > > > > The build of Julia that has this has been unpushed from > > > f40-updates-testing already: > > > https://bodhi.fedoraproject.org/updates/FEDORA-2024-8a00986001 > > > > > > Not sure why these changes landed in the f40 branch only, but not in > > > rawhide. > > > > Side note: The commits that are on the f40 branch *only* definitely > > look suspicious: > > https://src.fedoraproject.org/rpms/julia/commits/f40 > > > > Looks like Julia is bundling LLVM, libuv, libunwind, gmp, curl (!), > > libssh2 (!), and mbedtls (!) ... > > https://src.fedoraproject.org/rpms/julia/blob/f40/f/sources > > Back story is in https://bugzilla.redhat.com/show_bug.cgi?id=2274270 . > Not really suspicious, just an upstream terminally inhospitable to > downstreams. It kinda looks like we should just ditch the package, to > me. You are right - I meant to say it was suspicious that these commits were only done in the f40 branch, but are not present in rawhide. Usually packages are worked on in rawhide *first* and then changes are merged or backported to stable branches. Reading up on the bug, the situation with Julia does indeed sound like a major clusterf***. If Julia only supports running on top of the same versions of libraries that it was built against, maybe it needs to be rebuilt any time any of those libraries change? It also sounds like Julia packages are distributed as pre-compiled binaries? That seems like a major security issue if Julia is just downloading pre-compiled binaries from somewhere and running them ... 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: Issues with cgo and stack protection
So, I found out the stack-prot test was passing before simply because
the static analysis was skipping it:
```
Hardened: /usr/sbin/captree: skip: stack-prot test because GO is stack safe
```
However, it appears the new changes attempting to bring hardening to go
builds has made the static analysis test check the binary and find issues.
```
-%make_build prefix=%{_prefix} lib=%{_lib} SBINDIR=%{_sbindir}
CGO_REQUIRED=1 GO_BUILD_FLAGS="-buildmode=pie -ldflags='-B gobuildid'" all
+%make_build prefix=%{_prefix} lib=%{_lib} SBINDIR=%{_sbindir}
CGO_REQUIRED=1 CGO_CFLAGS="${CFLAGS}" CGO_LDFLAGS="${LDFLAGS}"
GO_BUILD_FLAGS="-buildmode=pie -a -v -x -ldflags='-compressdwarf=false
-B gobuildid'" all
```
Regards,
Carlos R.F.
On 6/13/24 09:30, Carlos Rodriguez-Fernandez wrote:
Hi All,
The build of libcap in Rawhide is failing the static analysis because of
the stack protection not enabled [1].
```
Hardened: /usr/sbin/captree: FAIL: stack-prot test because stack
protection not enabled (lto:threadentry)
Hardened: /usr/sbin/captree: FAIL: stack-prot test because stack
protection not enabled (lto:fatalf)
```
captree is a go application included in the libcap package. It uses cgo.
When you compile with cgo with the -x flag to show the commands being
used, you see a lot of -fno-stack-protector, which is coming from the
#cgo directive in the cgo files [2]. That's intentional, and has been
there for some time. At least since 1.21.9, which is in Fedora 39, and
where libcap didn't have those static analysis errors.
Has there been recent hardening efforts in Rawhide that can explain why
this is happening now?
Thank you!
1. https://bodhi.fedoraproject.org/updates/FEDORA-2024-7da5d4e363
2. https://cs.opensource.google/go/go/+/master:src/runtime/cgo/cgo.go;l=26
OpenPGP_signature.asc
Description: OpenPGP digital 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: heads up: julia has a bunch of incorrect Provides (bug 2291191)
Fabio Valentini venit, vidit, dixit 2024-06-14 16:25:56: > On Mon, Jun 10, 2024 at 11:57 PM Adam Williamson > wrote: > > > > On Mon, 2024-06-10 at 20:57 +0200, Fabio Valentini wrote: > > > On Mon, Jun 10, 2024 at 8:52 PM Fabio Valentini > > > wrote: > > > > > > > > On Mon, Jun 10, 2024 at 8:49 PM Colin Walters > > > > wrote: > > > > > > > > > > Worth a bit of wide distribution as I'm sure I'm not the only one who > > > > > got burned: > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2291191 > > > > > > > > The build of Julia that has this has been unpushed from > > > > f40-updates-testing already: > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2024-8a00986001 > > > > > > > > Not sure why these changes landed in the f40 branch only, but not in > > > > rawhide. > > > > > > Side note: The commits that are on the f40 branch *only* definitely > > > look suspicious: > > > https://src.fedoraproject.org/rpms/julia/commits/f40 > > > > > > Looks like Julia is bundling LLVM, libuv, libunwind, gmp, curl (!), > > > libssh2 (!), and mbedtls (!) ... > > > https://src.fedoraproject.org/rpms/julia/blob/f40/f/sources > > > > Back story is in https://bugzilla.redhat.com/show_bug.cgi?id=2274270 . > > Not really suspicious, just an upstream terminally inhospitable to > > downstreams. It kinda looks like we should just ditch the package, to > > me. > > You are right - I meant to say it was suspicious that these commits > were only done in the f40 branch, but are not present in rawhide. > Usually packages are worked on in rawhide *first* and then changes are > merged or backported to stable branches. > > Reading up on the bug, the situation with Julia does indeed sound like > a major clusterf***. > If Julia only supports running on top of the same versions of > libraries that it was built against, maybe it needs to be rebuilt any > time any of those libraries change? > It also sounds like Julia packages are distributed as pre-compiled > binaries? That seems like a major security issue if Julia is just > downloading pre-compiled binaries from somewhere and running them ... Julia comes from a mindset or background where reproducibility is important. Think of data science where you distribute both analysis and code and want your code to always support your analysis ;-) Now, one thing is enabling that (via explicit requirements, bundling, containerizing and such), another thing is basically inhibiting unbundling. Julia users might be best served by not packaging Julia as rpm any more. This implies not packaging it as Fedora flatpak either. I would not phrase this as "Fedora does not support Julia", though. Rather, "Julia does not support distribution packaging" but also "Fedora supports containerized workflows" such as those preferred by and supported by Julia. In fact, Fedora/RHEL are *the* base for containerized workflows, of course! Michael -- ___ 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: heads up: julia has a bunch of incorrect Provides (bug 2291191)
> Fabio Valentini venit, vidit, dixit 2024-06-14 16:25:56: > > Julia comes from a mindset or background where reproducibility is > important. Think of data science where you distribute both analysis and > code and want your code to always support your analysis ;-) > > Now, one thing is enabling that (via explicit requirements, bundling, > containerizing and such), another thing is basically inhibiting > unbundling. > > Julia users might be best served by not packaging Julia as rpm any more. > This implies not packaging it as Fedora flatpak either. > > I would not phrase this as "Fedora does not support Julia", though. > Rather, "Julia does not support distribution packaging" but also "Fedora > supports containerized workflows" such as those preferred by and > supported by Julia. In fact, Fedora/RHEL are *the* base for > containerized workflows, of course! The better way to use Julia is through juliaup (https://github.com/JuliaLang/juliaup), which will install it from versions compiled by the upstream project and hosted on their infrastructure - and also allow for installation of multiple versions side-by-side (since there are both long-term support versions like 1.6 and the current stable version). I had a look at packaging it before, but never followed up on that yet, just due to not having enough time yet. (I think it should just need to be a rust2rpm package, with one or two extra dependencies that need packaging). > > Michael -- ___ 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: heads up: julia has a bunch of incorrect Provides (bug 2291191)
On Fri, Jun 14, 2024 at 5:04 PM Ian McInerney via devel wrote: > > > Fabio Valentini venit, vidit, dixit 2024-06-14 16:25:56: > > > > Julia comes from a mindset or background where reproducibility is > > important. Think of data science where you distribute both analysis and > > code and want your code to always support your analysis ;-) > > > > Now, one thing is enabling that (via explicit requirements, bundling, > > containerizing and such), another thing is basically inhibiting > > unbundling. > > > > Julia users might be best served by not packaging Julia as rpm any more. > > This implies not packaging it as Fedora flatpak either. > > > > I would not phrase this as "Fedora does not support Julia", though. > > Rather, "Julia does not support distribution packaging" but also "Fedora > > supports containerized workflows" such as those preferred by and > > supported by Julia. In fact, Fedora/RHEL are *the* base for > > containerized workflows, of course! > > The better way to use Julia is through juliaup > (https://github.com/JuliaLang/juliaup), which will install it from versions > compiled by the upstream project and hosted on their infrastructure - and > also allow for installation of multiple versions side-by-side (since there > are both long-term support versions like 1.6 and the current stable version). > I had a look at packaging it before, but never followed up on that yet, just > due to not having enough time yet. (I think it should just need to be a > rust2rpm package, with one or two extra dependencies that need packaging). Oh, I didn't expect this to be written in Rust. If that is indeed a better way to manage local Julia installations, then I can look into packaging it and / or putting it on the Rust package wishlist. 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: heads up: julia has a bunch of incorrect Provides (bug 2291191)
> On Mon, Jun 10, 2024 at 11:57 PM Adam Williamson > > You are right - I meant to say it was suspicious that these commits > were only done in the f40 branch, but are not present in rawhide. > Usually packages are worked on in rawhide *first* and then changes are > merged or backported to stable branches. > > Reading up on the bug, the situation with Julia does indeed sound like > a major clusterf***. > If Julia only supports running on top of the same versions of > libraries that it was built against, maybe it needs to be rebuilt any > time any of those libraries change? It is more complex than that, because there is generally an FFI layer built into the Julia code, so if the API has changed at all for those libraries (which it did recently for SuiteSparse in a way that broke Julia), then parts inside Julia also need updating to match the new API. > It also sounds like Julia packages are distributed as pre-compiled > binaries? That seems like a major security issue if Julia is just > downloading pre-compiled binaries from somewhere and running them ... It is no more insecure than distributing RPM packages from mirrors in my view. They build all the binary packages using recipes from a GitHub repository here https://github.com/JuliaPackaging/Yggdrasil, and all the build logs are publicly viewable and build artifacts publicly downloadable for inspection. The binaries are then hosted as Julia packages in their own GitHub repo (in this org https://github.com/JuliaBinaryWrappers) with the binary artifacts attached as release artifacts. They also mirror them through packaging servers to distribute the load (so not everyone has to download from GitHub). So I don't see this as being any less secure than the RPM distribution chain. > > 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
Orphaned packages looking for new maintainers
Report started at 2024-06-14 19:04:03 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 Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in the left column on https://src.fedoraproject.org/rpms/ Full report available at: https://a.gtmx.me/orphans/orphans.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainers Status Change 3Depict orphan 4 weeks ago BitchXorphan, rdieter 4 weeks ago balsa orphan 4 weeks ago bti orphan 7 weeks ago buildstream atim, orphan 3 weeks ago container-exception-logger@abrt-sig, mmarusak, orphan 4 weeks ago cutecworphan 4 weeks ago dnssec-nodes orphan 4 weeks ago dnssec-system-trayorphan 4 weeks ago erlang-p1_acme@erlang-maint-sig, orphan5 weeks ago fleet-commander-admin orphan 4 weeks ago fleet-commander-clientorphan 4 weeks ago gofer orphan 4 weeks ago golang-github-client9-gospell @go-sig, orphan 4 weeks ago golang-github-elves-elvish@go-sig, orphan 8 weeks ago golang-github-xiaq-persistent @go-sig, orphan 8 weeks ago golang-k8s-cli-runtime@go-sig, orphan 5 weeks ago golang-k8s-kubectl@go-sig, orphan 5 weeks ago grpc defolos, orphan 2 weeks ago gtypist orphan 4 weeks ago jgit orphan 4 weeks ago jolokia-jvm-agent orphan 9 weeks ago kanotf-fonts orphan 4 weeks ago laf-pluginorphan 4 weeks ago levien-museum-fonts orphan 4 weeks ago libitlmoceap, orphan 4 weeks ago logserial orphan 4 weeks ago mingw-cppunit orphan 6 weeks ago mingw-freeimage orphan 9 weeks ago mingw-sword orphan 5 weeks ago neofetch orphan 6 weeks ago nuntius kalev, orphan4 weeks ago oc-inject orphan 4 weeks ago perl-Flickr-API orphan 4 weeks ago perl-Flickr-Uploadorphan 4 weeks ago perl-Getopt-GUI-Long orphan 4 weeks ago perl-QWizard orphan 4 weeks ago php-doctrine-common3 orphan 1 weeks ago php-doctrine-orm orphan, remi 1 weeks ago pidgin-guifications nosnilmot, orphan4 weeks ago polkit-gnome @epel-packagers-sig, orphan 0 weeks ago prometheus-jmx-exporter orphan 9 weeks ago prometheus-simpleclient-java orphan 9 weeks ago python-amico orphan 1 weeks ago python-glue orphan 4 weeks ago python-googleapis-common-protos @python-packagers-sig, fkolwa, 2 weeks ago miyunari, orphan
Koschei builds fail with "error: %patchN is obsolete", but no %patchN in the spec file
Hello, I found a moment to catch up on my package maintainer tasks and I noticed that for the past 15 days fityk's rawhide builds started by Koschei have been failing[1]. There are no build logs and the only error I can spot in the root.log is this: DEBUG util.py:461: error: %patchN is obsolete, use %patch N (or %patch -P N): %patch0 -p0 The odd thing here is that the spec file has %patch -P0 -p0 I also did a scratch build[2] and it completed without any errors. Is there something I need to do? Best regards, A. 1. https://koschei.fedoraproject.org/package/fityk?collection=f41 2. https://koji.fedoraproject.org/koji/taskinfo?taskID=119026186 -- ___ 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: Koschei builds fail with "error: %patchN is obsolete", but no %patchN in the spec file
On Saturday, 15 June 2024 at 00:07, Alexander Ploumistos wrote: > Hello, > > I found a moment to catch up on my package maintainer tasks and I > noticed that for the past 15 days fityk's rawhide builds started by > Koschei have been failing[1]. There are no build logs and the only > error I can spot in the root.log is this: > > DEBUG util.py:461: error: %patchN is obsolete, use %patch N (or > %patch -P N): %patch0 -p0 > > The odd thing here is that the spec file has > > %patch -P0 -p0 > > I also did a scratch build[2] and it completed without any errors. Is > there something I need to do? Do a new build of the package if you want koschei to be clean. The %patchN fixes were committed and pushed without bumping the release, so koschei is not aware of them (it's using the latest src.rpm, not git HEAD). Regards, Dominik -- Fedora https://fedoraproject.org Deep in the human unconscious is a pervasive need for a logical universe that makes sense. But the real universe is always one step beyond logic. -- from "The Sayings of Muad'Dib" by the Princess Irulan -- ___ 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: Koschei builds fail with "error: %patchN is obsolete", but no %patchN in the spec file
Thank you Dominik, I hadn't noticed the commit message, I was looking at everything else. -- ___ 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: Koschei builds fail with "error: %patchN is obsolete", but no %patchN in the spec file
It looks like builds were not started after %patch changes. Which is probably otherwise fine, but yes Koschei attempts to rebuild latest Koji build, not dist-git tip. Just do 'fedpkg build' to align Koji and dist-git and Koschei should get into sync. It would be great if Koschei somehow took this situation into account. On Rawhide it is not so bad, because I can just issue a build to recover. But currently, I also have similar situation for Tilix in Fedora 40 (due to different root cause) and I don't think it is appropriate to build&update just because of packaging changes. I would say it is not an error state I'd latest Koji build cannot be rebuilt, if dist-git tip builds. 15. kesäkuuta 2024 1.07.27 GMT+03:00 Alexander Ploumistos kirjoitti: >Hello, > >I found a moment to catch up on my package maintainer tasks and I >noticed that for the past 15 days fityk's rawhide builds started by >Koschei have been failing[1]. There are no build logs and the only >error I can spot in the root.log is this: > >DEBUG util.py:461: error: %patchN is obsolete, use %patch N (or >%patch -P N): %patch0 -p0 > >The odd thing here is that the spec file has > >%patch -P0 -p0 > >I also did a scratch build[2] and it completed without any errors. Is >there something I need to do? > > >Best regards, >A. > > >1. https://koschei.fedoraproject.org/package/fityk?collection=f41 >2. https://koji.fedoraproject.org/koji/taskinfo?taskID=119026186 >-- >___ >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
