Re: rich deps result in packages being uninstalled from buildroot

On 16-05-2024 13:14, Petr Pisar wrote: A workaround could be rpm-build or mock to register rpm-build package in /etc/dnf/protected.d configuration files. Packages listed there are prevented from removal no matter of --allow-erasing. A bit late to the party, but I was wondering if making `add

Re: rich deps result in packages being uninstalled from buildroot

On Fri, 17 May 2024 13:32:24 + Zbigniew Jędrzejewski-Szmek wrote: > > Oh, this is embarrasing. I added two patches but they didn't get > > applied because %setup not %autosetup. :( > > I'll push a fixed build in a moment. Sorry for breaking the builds. > > > >

Re: rich deps result in packages being uninstalled from buildroot

M +0200, Fabio Valentini wrote: > > > > This looks like you're putting the resolver between a rock and a > > > > hard place. :thinking: > > > > I don't think I've ever seen packages being *removed* when > > > > installing BuildRequires on top of the minima

Re: rich deps result in packages being uninstalled from buildroot

k and a > > > hard place. :thinking: > > > I don't think I've ever seen packages being *removed* when > > > installing BuildRequires on top of the minimal buildroot ... > > > > > > Would it be possible to adapt the packages so that add-determinism

Re: rich deps result in packages being uninstalled from buildroot

of the packages in the buildroot are libraries, pulled in via dependencies. @buildsys-build group is: Mandatory packages   : bash  # basic shell env   : bzip2 # source extraction   : coreutils # basic shell env   : cpio

Re: rich deps result in packages being uninstalled from buildroot

On Thu, 16 May 2024 10:52:29 + Zbigniew Jędrzejewski-Szmek wrote: > On Thu, May 16, 2024 at 11:09:01AM +0200, Fabio Valentini wrote: > > This looks like you're putting the resolver between a rock and a > > hard place. :thinking: > > I don't think I've ever seen packages

Re: rich deps result in packages being uninstalled from buildroot

On 5/16/24 16:10, Vít Ondruch wrote: Dne 16. 05. 24 v 14:28 Zbigniew Jędrzejewski-Szmek napsal(a): On Thu, May 16, 2024 at 01:14:16PM +0200, Petr Pisar wrote: Proper solution is actually minimazing content of the minimal build root Most of the packages in the buildroot are libraries, pulled

Re: rich deps result in packages being uninstalled from buildroot

Neal Gompa wrote: > I have the question of why is dnf5 running as if "--allow-erasing" is > always passed to it? Older versions of DNF explicitly didn't do that > because we get weird behaviors like this. Without --allow-erasing (which was actually passed explicitly, as Petr Pisar pointed out),

Re: rich deps result in packages being uninstalled from buildroot

Dne 16. 05. 24 v 14:28 Zbigniew Jędrzejewski-Szmek napsal(a): On Thu, May 16, 2024 at 01:14:16PM +0200, Petr Pisar wrote: Proper solution is actually minimazing content of the minimal build root Most of the packages in the buildroot are libraries, pulled in via dependencies. @buildsys-build

Re: rich deps result in packages being uninstalled from buildroot

On Thu, May 16, 2024 at 01:14:16PM +0200, Petr Pisar wrote: > Proper solution is actually minimazing content of the minimal build root Most of the packages in the buildroot are libraries, pulled in via dependencies. @buildsys-build group is: Mandatory packages : bash # basic shell

Re: rich deps result in packages being uninstalled from buildroot

t; > > self-contained, > > > but if python3 is installed into the buildroot, we pull in the heavier > > > version > > > which has a dependency on python3-libs.) > > > > > > This works well enough when installing packages using dnf on

Re: rich deps result in packages being uninstalled from buildroot

On Thu, May 16, 2024 at 11:09:01AM +0200, Fabio Valentini wrote: > This looks like you're putting the resolver between a rock and a hard > place. :thinking: > I don't think I've ever seen packages being *removed* when installing > BuildRequires on top of the minimal buildroot ..

Re: rich deps result in packages being uninstalled from buildroot

opython) > > Suggests:add-determinism-nopython > > > > (The idea is that we install 'add-determinism-nopython' which is > > self-contained, > > but if python3 is installed into the buildroot, we pull in the heavier > > version > > which has a depend

Re: rich deps result in packages being uninstalled from buildroot

self-contained, > but if python3 is installed into the buildroot, we pull in the heavier version > which has a dependency on python3-libs.) > > This works well enough when installing packages using dnf on a test system. > But, in koji and mock builds, this results in rpm-build being unistal

rich deps result in packages being uninstalled from buildroot

well enough when installing packages using dnf on a test system. But, in koji and mock builds, this results in rpm-build being unistalled (!). For example, see https://koji.fedoraproject.org/koji/taskinfo?taskID=117684626 and root.log there: first rpm-build is installed along with a bunch of other

Re: Smaller buildroot for Perl packages

Hi - > > OK, build-time dependency changes may not need the side tag but do > > need a spec update to prevent a FTBFS at next build. > > Only those packages that actually need dtrace would require changes. Such > changes could land gradually as needed. They'd have to la

Re: Smaller buildroot for Perl packages

On 13. 05. 24 17:11, Frank Ch. Eigler wrote: Hi - I also did a test rebuild of all packages directly build-requiring systemtap-sdt-devel and identified these packages that really need the dtrace script: [...] (The logistic challenge there will be side-tag rebuilding all those after

Re: Smaller buildroot for Perl packages

V Mon, May 13, 2024 at 11:11:05AM -0400, Frank Ch. Eigler napsal(a): > > > > > I also did a test rebuild of all packages directly build-requiring > > > > > systemtap-sdt-devel and identified these packages that really need the > > > > > dtrac

Re: Smaller buildroot for Perl packages

V Mon, May 13, 2024 at 04:14:53PM +0200, Vít Ondruch napsal(a): > Dne 10. 05. 24 v 14:16 Petr Pisar napsal(a): > > V Fri, May 10, 2024 at 01:13:53PM +0200, Lumír Balhar napsal(a): > > > I also did a test rebuild of all packages directly build-requiring > > > systemt

Re: Smaller buildroot for Perl packages

Hi - > > > > I also did a test rebuild of all packages directly build-requiring > > > > systemtap-sdt-devel and identified these packages that really need the > > > > dtrace script: [...] > > (The logistic challenge there will be side-tag rebuilding al

Re: Smaller buildroot for Perl packages

Dne 10. 05. 24 v 14:16 Petr Pisar napsal(a): V Fri, May 10, 2024 at 01:13:53PM +0200, Lumír Balhar napsal(a): I might have an idea how to make building Perl packages faster and their buildroot a little bit smaller. perl-devel depends on systemtap-sdt-devel and that package contains a single

Re: Intention to take over orphaned packages: php-aws-sdk3, php-ralouphie-getallheaders, php-guzzlehttp-guzzle6

php-aws-sdk3 alive. It will be a challenge but a good learning opportunity too. As I said, because of bundled libraries And also lack or PHP reviewers I already have tons of packages waiting for review for months Remi -- ___ devel mailing list -- devel@lists.fedoraprojec

Re: Smaller buildroot for Perl packages

On 10. 05. 24 17:16, Frank Ch. Eigler wrote: [...] I also did a test rebuild of all packages directly build-requiring systemtap-sdt-devel and identified these packages that really need the dtrace script: glib2, sssd, qemu, python2.7, postgresql15, postgresql16, perl, php, mariadb10.11

Re: Smaller buildroot for Perl packages

On Fri, May 10, 2024 at 01:13:53PM +0200, Lumír Balhar wrote: > My idea is to split systemtap-sdt-devel into two packages: one with all the > content but without the python script (/usr/bin/dtrace) and a new one > containing only the mentioned script. +1 I think it's weird that a use

Re: Smaller buildroot for Perl packages

Hi - > [...] > > My idea is to split systemtap-sdt-devel into two packages: one with all the > > content but without the python script (/usr/bin/dtrace) and a new one > > containing only the mentioned script. No objection here. > > [...] > > I also did a test

Re: Smaller buildroot for Perl packages

V Fri, May 10, 2024 at 01:13:53PM +0200, Lumír Balhar napsal(a): > I might have an idea how to make building Perl packages faster and their > buildroot a little bit smaller. > > perl-devel depends on systemtap-sdt-devel and that package contains a single > script written in P

Smaller buildroot for Perl packages

Hi. I might have an idea how to make building Perl packages faster and their buildroot a little bit smaller. perl-devel depends on systemtap-sdt-devel and that package contains a single script written in Python and using pycparser. The single script bring python3-pycparser and therefore

F41 Change Proposal: Multiple Versioned CRI-O and CRI-Tools Packages (self-contained)

- https://fedoraproject.org/wiki/Changes/VersionedCRI-OandCRI-ToolsPackages Discussion Thread - https://discussion.fedoraproject.org/t/f41-change-proposal-multiple-versioned-cri-o-and-cri-tools-packages-self-contained/116526 == Summary == The installed versions of CRI-O and CRI-Tools are supposed

F41 Change Proposal: Multiple Versioned CRI-O and CRI-Tools Packages (self-contained)

- https://fedoraproject.org/wiki/Changes/VersionedCRI-OandCRI-ToolsPackages Discussion Thread - https://discussion.fedoraproject.org/t/f41-change-proposal-multiple-versioned-cri-o-and-cri-tools-packages-self-contained/116526 == Summary == The installed versions of CRI-O and CRI-Tools are supposed

Orphaned packages looking for new maintainers

Report started at 2024-05-06 17:14:29 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

Orphaned packages looking for new maintainers

Report started at 2024-04-27 20:06:57 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

Re: Ownership request for retired packages libtsm and kmscon

ested in taking > ownership of these packages and re-adding them to Fedora if I get sponsored. > > Upstream has ceased development for both `libtsm` and `kmscon`, however, > they've been forked and continue to be well maintained: > > - `libtsm`: https://github.com/Aetf/libtsm > - `kmscon`

Re: RFC: Flaws detected by static analyzers in Fedora 41 Core Critical Path Packages

age to get feedback from the community on possibly > new defects identified by static analyzers in Core Critical Path packages > that have changed in Fedora 41. > > TLDR: This report[2] contains 14188 identified defects. Please review the > report and provide feedback.

Ownership request for retired packages libtsm and kmscon

Hey folks, `libtsm` was retired because it was orphaned. `kmscon` was retired because it relied on this package. I'm currently not in the "packagers" group, but I'm interested in taking ownership of these packages and re-adding them to Fedora if I get sponsored. Upstream

Orphaned packages looking for new maintainers

Report started at 2024-05-06 17:14:29 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

Re: Orphaned packages looking for new maintainers

On Fri May 3, 2024, Maxwell G wrote: > Report started at 2024-04-27 20:06:57 UTC Apologizes, I accidentally sent an outdated report. I will resend later today. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

Orphaned packages looking for new maintainers

Report started at 2024-04-27 20:06:57 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

[EPEL-devel] RFC: incompatible upgrade of catch for EPEL; packages that do not rebuild to be retargeted to catch2

Dear all, I plan to upgrade catch in epel8 and epel9 to the latest 3.5.4 from Fedora, and introduce catch2 for packages that are currently using EPEL's catch (v2) and won't rebuild against catch v3 ❯ fedrq pkgs -P catch-devel -b epel8 catch-devel-2.13.8-1.el8.x86_64 ❯ fedrq pkgs -P catch

Re: Intention to take over orphaned packages: php-aws-sdk3, php-ralouphie-getallheaders, php-guzzlehttp-guzzle6

> On 04/24/2024 4:21 PM CEST Remi Collet wrote: > > I can probably help for PHP reviews Thank you, appreciated! > Notice: > > - php-ralouphie-getallheaders: this is a compat layer providing a > missing function in PHP < 7.3 for php-fpm users > > Please check you really still need it ;)

Re: RFC: Flaws detected by static analyzers in Fedora 41 Core Critical Path Packages

1] about OpenScanHub > >> Prototype for Fedora. > >> Thank you to those who have provided early feedback. Your help is > >> truly appreciated! > >> > >> I am writing this message to get feedback from the community on > >> possibly new defe

Re: RFC: Flaws detected by static analyzers in Fedora 41 Core Critical Path Packages

who have provided early feedback. Your help is truly > > appreciated! > > > > I am writing this message to get feedback from the community on possibly > > new defects identified by static analyzers in Core Critical Path > > packages that have changed in Fedora 41. > > >

Re: RFC: Flaws detected by static analyzers in Fedora 41 Core Critical Path Packages

defects identified by static analyzers in Core Critical Path packages that have changed in Fedora 41. TLDR: This report[2] contains 14188 identified defects. Please review the report and provide feedback. A mass scan was performed this week on the packages that have changed in Fedora 41

Re: RFC: Flaws detected by static analyzers in Fedora 41 Core Critical Path Packages

by static analyzers in Core Critical Path packages that have changed in Fedora 41. TLDR: This report[2] contains 14188 identified defects. Please review the report and provide feedback. A mass scan was performed this week on the packages that have changed in Fedora 41. This report[2] contains all

RFC: Flaws detected by static analyzers in Fedora 41 Core Critical Path Packages

in Core Critical Path packages that have changed in Fedora 41. TLDR: This report[2] contains 14188 identified defects. Please review the report and provide feedback. A mass scan was performed this week on the packages that have changed in Fedora 41. This report[2] contains all the new defects

Re: Intention to take over orphaned packages: php-aws-sdk3, php-ralouphie-getallheaders, php-guzzlehttp-guzzle6

Le 24/04/2024 à 11:41, domi...@wombacher.cc a écrit : I'm not in the packager group yet and looking for a Sponsor to completed the onboarding process. Afterwards I want to become the maintainer of the orphaned packages php-aws-sdk3 [1], php-ralouphie-getallheaders [2] and php-guzzlehttp

Intention to take over orphaned packages: php-aws-sdk3, php-ralouphie-getallheaders, php-guzzlehttp-guzzle6

Hi everyone, I'm not in the packager group yet and looking for a Sponsor to completed the onboarding process. Afterwards I want to become the maintainer of the orphaned packages php-aws-sdk3 [1], php-ralouphie-getallheaders [2] and php-guzzlehttp-guzzle6 [3]. My main motivation is to keep

Re: Orphaning my packages: elvish, git-delta & dependencies

Thanks, I opened a re-review request of elvish to follow package renaming process [1]. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2276356 [1] https://docs.fedoraproject.org/en-US/package-maintainers/Package_Renaming_Process/ -- ___ devel

Re: Orphaning my packages: elvish, git-delta & dependencies

Hau idatzi du Felix Wang (topa...@outlook.com) erabiltzaileak (2024 api. 22(a), al. (03:57)): > > I'd like to take elvish package, Current package golang-github-elves-elvish should be replaced by a new one[1], set correct Obsoletes tag and retired. The name and goipath are not correct anymore.a

Re: Orphaning my packages: elvish, git-delta & dependencies

I'd like to take elvish package, and I filed a review request of golang-pkg-nimblebun-lsp, which it is a dependency of elvish. I would be grateful If you can take the review, or I can do the review swap if am familiar the knowledge with it.

Re: Orphaning my packages: elvish, git-delta & dependencies

Hau idatzi du Janet Black (uhh...@gmail.com) erabiltzaileak (2024 api. 19(a), or. (21:06)): > > Hi, I do not have the time to contribute packages to Fedora these days. Thanks for your work Janet. > I am orphaning the following packages under my maintainership: > - golang-github-elv

Re: Orphaning my packages: elvish, git-delta & dependencies

On Fri, Apr 19, 2024 at 9:06 PM Janet Black wrote: > > Hi, I do not have the time to contribute packages to Fedora these days. > > I am orphaning the following packages under my maintainership: > - golang-github-elves-elvish > - golang-github-xiaq-persistent > - rust-box

Orphaning my packages: elvish, git-delta & dependencies

Hi, I do not have the time to contribute packages to Fedora these days. I am orphaning the following packages under my maintainership: - golang-github-elves-elvish - golang-github-xiaq-persistent - rust-box_drawing - rust-git-delta -- ___ devel mailing

Re: F41 Change Proposal: Versioned Kubernetes Packages (Self-Cont

One of the characteristics of Kubernetes is that skipping minor versions during an upgrade is not supported. This reduces the potential complexity in correctly setting Obsoletes/Provides in the package for the replacing version. The unsupported version can also be marked deprecated. These steps

Re: F41 Change Proposal: Versioned Kubernetes Packages (Self-Cont

On Mon, Mar 25, 2024 at 04:15:44PM +, Aoife Moloney wrote: > Wiki - https://fedoraproject.org/wiki/Changes/VersionedKubernetesPackages > == Owner == > * Name: [[User:Buckaroogeek| Brad Smith]] > * Email: bradley.g.sm...@gmail.com > > > == Detailed Description == > The Kubernetes project

Re: Orphaned packages looking for new maintainers

Michel Lind venit, vidit, dixit 2024-04-12 21:59:42: > On Fri, Apr 12, 2024 at 07:59:46AM -0700, Carlos Rodriguez-Fernandez wrote: > > Regarding libteam, the author of the package is the maintainer, email in > > bugzilla is different than the one on the project. I wonder if Jiro just > > missed

Orphaned packages looking for new maintainers

Report started at 2024-04-12 13:04:40 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

Re: Orphaned packages looking for new maintainers

On Fri, Apr 12, 2024 at 07:59:46AM -0700, Carlos Rodriguez-Fernandez wrote: > Regarding libteam, the author of the package is the maintainer, email in > bugzilla is different than the one on the project. I wonder if Jiro just > missed the notification that his package is failing to build in F40. >

Re: Orphaned packages looking for new maintainers

On Fri, Apr 12, 2024 at 09:09:31AM -0500, Maxwell G wrote: > Report started at 2024-04-12 13:04:40 UTC > libteam orphan 0 weeks > ago > > The following packages require above mentioned packages: > Depending on: libteam (

Re: Orphaned packages looking for new maintainers

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

Orphaned packages looking for new maintainers

Report started at 2024-04-12 13:04:40 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

Re: "fedpkg local" builds fail for rust packages

Dne 09. 04. 24 v 14:15 Fabio Valentini napsal(a): On Tue, Apr 9, 2024 at 1:19 PM Vít Ondruch wrote: Dne 08. 04. 24 v 12:32 Neal Gompa napsal(a): Packaged Rust crates work *fine* for local development as long as you are willing to cut yourself off from crates.io. Unlike *every other language

Re: "fedpkg local" builds fail for rust packages

On Tue, Apr 9, 2024 at 1:19 PM Vít Ondruch wrote: > > Dne 08. 04. 24 v 12:32 Neal Gompa napsal(a): > > Packaged Rust crates work *fine* for local development as long as you > > are willing to cut yourself off from crates.io. Unlike *every other > > language package manager*, Cargo does not

Re: "fedpkg local" builds fail for rust packages

Dne 08. 04. 24 v 12:32 Neal Gompa napsal(a): On Mon, Apr 8, 2024 at 6:17 AM Richard W.M. Jones wrote: On Fri, Apr 05, 2024 at 03:33:35PM +0200, Fabio Valentini wrote: On Fri, Apr 5, 2024 at 9:51 AM Michael J Gruber wrote: So you're saying that those packages are in the repos for everyone

Orphaning some Java packages

Hi, I'm orphaning a couple of packages of mine which I no longer use or were used as a dependency of a package I've maintained before and am no longer using: Packages without co-maintainers: jolokia-jvm-agent prometheus-simpleclient-java prometheus-jmx-exporter

Re: "fedpkg local" builds fail for rust packages

On Mon, Apr 8, 2024 at 6:17 AM Richard W.M. Jones wrote: > > On Fri, Apr 05, 2024 at 03:33:35PM +0200, Fabio Valentini wrote: > > On Fri, Apr 5, 2024 at 9:51 AM Michael J Gruber > > wrote: > > > > > > So you're saying that those packages are in the re

Re: "fedpkg local" builds fail for rust packages

On Fri, Apr 05, 2024 at 03:33:35PM +0200, Fabio Valentini wrote: > On Fri, Apr 5, 2024 at 9:51 AM Michael J Gruber > wrote: > > > > So you're saying that those packages are in the repos for everyone but > > not meant to be installed by anyone (besides mock chroots), and

Re: "fedpkg local" builds fail for rust packages

On Sat, Apr 6, 2024 at 12:42 PM Björn Persson wrote: > > Fabio Valentini wrote: > > - Installing rust-*-devel packages on your local system (i.e. outside > > of ephemeral build environments) is not supported. > > - The "rust-*-devel" packages are build system

Re: "fedpkg local" builds fail for rust packages

On Sat, Apr 6, 2024 at 4:45 AM Scott Schmit wrote: > > This perhaps explains why my efforts to use these packages did nothing > but waste my time for days.  > > It sounds like you've wasted others' time as well. That's not very > Friendly, and playing nitpicky language la

Re: "fedpkg local" builds fail for rust packages

Fabio Valentini wrote: > - Installing rust-*-devel packages on your local system (i.e. outside > of ephemeral build environments) is not supported. > - The "rust-*-devel" packages are build system implementation details, > if you want to say it like that. > - They

Re: "fedpkg local" builds fail for rust packages

l you that you're not going to like the experience: > > - Using "fedpkg local" is not supported for Rust packages, and I won't > be adding workarounds to the Rust macros for it. > - Installing rust-*-devel packages on your local system (i.e. outside > of ephemeral build env

Re: "fedpkg local" builds fail for rust packages

On Fri, Apr 5, 2024 at 7:35 AM Fabio Valentini wrote: > On Fri, Apr 5, 2024 at 9:51 AM Michael J Gruber > wrote: > > Is there any other set of packages which we package like that? > > Probably golang ... maybe Haskell, OCaml? Not OCaml, no. The OCaml packages can be

Re: "fedpkg local" builds fail for rust packages

On Fri, Apr 5, 2024 at 3:16 PM Emanuel Lima wrote: > > I'm not sure this helps, but I maintain a Rust and Go package that builds > fine with fedpkg local. If you want to take a look at the spec: > > https://src.fedoraproject.org/rpms/kata-containers/blob/rawhide/f/kata-containers.spec This is a

Re: "fedpkg local" builds fail for rust packages

On Fri, Apr 5, 2024 at 9:51 AM Michael J Gruber wrote: > > So you're saying that those packages are in the repos for everyone but > not meant to be installed by anyone (besides mock chroots), and that is > how and why they are packaged. Yes. That is the best we can do given how cargo

Re: "fedpkg local" builds fail for rust packages

I'm not sure this helps, but I maintain a Rust and Go package that builds fine with fedpkg local. If you want to take a look at the spec: https://src.fedoraproject.org/rpms/kata-containers/blob/rawhide/f/kata-containers.spec -- ___ devel mailing list

Re: "fedpkg local" builds fail for rust packages

Fabio Valentini venit, vidit, dixit 2024-04-04 22:41:19: > On Thu, Apr 4, 2024 at 9:42 PM pfed--- via devel > wrote: > > > > On Thu, Apr 04, 2024 at 09:51:31AM +0200, Fabio Valentini wrote: > > > > > The short answer is: No, "fedpkg local" is not e

Re: "fedpkg local" builds fail for rust packages

On Thu, Apr 4, 2024 at 9:42 PM pfed--- via devel wrote: > > On Thu, Apr 04, 2024 at 09:51:31AM +0200, Fabio Valentini wrote: > > > > The short answer is: No, "fedpkg local" is not expected to work for > > > > Rust packages, and probably won't ever wo

Re: "fedpkg local" builds fail for rust packages

On Thu, Apr 04, 2024 at 09:51:31AM +0200, Fabio Valentini wrote: > > > The short answer is: No, "fedpkg local" is not expected to work for > > > Rust packages, and probably won't ever work as expected for Rust > > > packages. > > > > > >

Re: Orphaned packages looking for new maintainers

Hi, sorry for the late response, have been a bit busy recently... Yes, we should remove botan (1) from Fedora - that has also been a request by upstream. The point is, I want to keep monotone, and it needs a bit of work to switch it over to botan2. There exists a branch that should have the

Re: Orphaned packages looking for new maintainers

https://botan.randombit.net/handbook/support.html#branch-support-status can be referenced in the retirement commit: Branch First Release End of Active Development End of Life Botan 1.8 2008-12-08 2010-08-31 2016-02-13 Botan 1.10 2011-06-20 2012-07-10 2018-12-31 (Though 1.11.x also

Re: Orphaned packages looking for new maintainers

On Thu, Apr 4, 2024 at 12:51 AM Sandro wrote: > On 03-04-2024 18:35, Jens-Ulrik Petersen wrote: > > I took botan [...] > I guess that was a bad idea - so I have re-orphaned it after some detailed discussions with @penguinpee in #devel. He also helped to decouple monotone from ikiwiki in

Re: "fedpkg local" builds fail for rust packages

> > > > > Or are there other ways to get this to work? > > > > > > The short answer is: No, "fedpkg local" is not expected to work for > > > Rust packages, and probably won't ever work as expected for Rust > > > packages. > > > >

Re: "fedpkg local" builds fail for rust packages

et this to work? > > > > The short answer is: No, "fedpkg local" is not expected to work for > > Rust packages, and probably won't ever work as expected for Rust > > packages. > > > > I am not really interested in adding the "--allow-dirty" flag (no

Re: "fedpkg local" builds fail for rust packages

not > > sure. There does not seem to be a general "ignore-git" option for cargo. > > > > Or are there other ways to get this to work? > > The short answer is: No, "fedpkg local" is not expected to work for > Rust packages, and probably won't eve

Re: "fedpkg local" builds fail for rust packages

quot; option for cargo. > > Or are there other ways to get this to work? The short answer is: No, "fedpkg local" is not expected to work for Rust packages, and probably won't ever work as expected for Rust packages. I am not really interested in adding the "--allow-dirty" flag (not sure if

"fedpkg local" builds fail for rust packages

Hi all, I like using `fedpkg local` builds to speed up testing of packaging, but now encountered a problem trying to package a rust program for the first time. It turns out a local build fails in the install step for all rust packages (that I tried out) with an error like error: 152 files

Re: Orphaned packages looking for new maintainers

On 03-04-2024 18:35, Jens-Ulrik Petersen wrote: I took botan as a penance for my sins in the previous thread  haha  הַלְּלוּ־יָהּ  Thanks! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

Re: Orphaned packages looking for new maintainers

I took botan as a penance for my sins in the previous thread ;-) haha  -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct:

Orphaned packages looking for new maintainers

Report started at 2024-04-02 16:05:20 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

Orphaned packages looking for new maintainers

Report started at 2024-04-02 16:05:20 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

Re: Obsoleted packages in F40

Kevin Kofler via devel kirjoitti 31.3.2024 klo 14.14: Otto Liljalaakso wrote: So, I would actually much prefer if package retirement automatically added the package to fedora-obsolete-packages. Perhaps there are special cases where that would not be a good idea - if there are some, `fedpkg

Re: Obsoleted packages in F40

Otto Liljalaakso wrote: > So, I would actually much prefer if package retirement automatically > added the package to fedora-obsolete-packages. Perhaps there are special > cases where that would not be a good idea - if there are some, `fedpkg > retire` could have a flag to preve

Re: Obsoleted packages in F40

at the end mention adding the package to https://src.fedoraproject.org/rpms/fedora-obsolete-packages I do not think the "Completely Removing a Package" section is meant for the cases you mention. The only example given in that section is licensing issues, i.e. a situation where Fedora wa

Re: Obsoleted packages in F40

Kevin Kofler via devel kirjoitti 25.3.2024 klo 20.34: Miroslav Suchý wrote: I just upgraded my workstation to F40 and it surprised how many packages were reported by `remove-retired-packages`. There was lots of orphaned packages - there is nothing to do about them. But there was lot of packages

[EPEL-devel] EPEL Packages SIG page rewrite

I have done a first draft to rewrite the EPEL Packagers SIG page.[1] The most dramatic thing was that I took out all of the "What is EPEL" stuff. That is all found elsewhere in the EPEL docs and was (in my opinion) the confusing stuff, making people think you needed to join the SIG, and that by

Re: Orphaned packages looking for new maintainers

On 27. 03. 24 16:03, Jens-Ulrik Petersen wrote: On Wed, Mar 27, 2024 at 9:46 PM Miro Hrončok > wrote: On 25. 03. 24 7:48, Jens-Ulrik Petersen wrote: > Also botan got orphaned despite the FTI going away >

Re: Orphaned packages looking for new maintainers

On Wed, Mar 27, 2024 at 9:46 PM Miro Hrončok wrote: > On 25. 03. 24 7:48, Jens-Ulrik Petersen wrote: > > Also botan got orphaned despite the FTI going away > > [1] ;-( > > Could it be un-orphaned back? > > > [1] Seems FTI failed to close the

Re: Orphaned packages looking for new maintainers

On 25. 03. 24 7:48, Jens-Ulrik Petersen wrote: Also botan got orphaned despite the FTI going away [1] ;-( Could it be un-orphaned back? Yes, by clicking the *Take* button. [1] Seems FTI failed to close the bug fixed on 2024-03-07 It

Re: Obsoleted packages in F40

Miroslav Suchý wrote: > I just upgraded my workstation to F40 and it surprised how many packages > were reported by `remove-retired-packages`. There was lots of orphaned > packages - there is nothing to do about them. But there was lot of > packages that were removed intentionally.

F41 Change Proposal: Versioned Kubernetes Packages (Self-Cont

Engineering Steering Committee. = Multiple Versioned Kubernetes Packages = == Summary == Provide all maintained Kubernetes releases in Fedora as multiple, versioned packages. Current practice is a separate Kubernetes release matched with each Fedora release. == Owner == * Name: [[User:Buckaroogeek| Brad

F41 Change Proposal: Versioned Kubernetes Packages (Self-Cont

Engineering Steering Committee. = Multiple Versioned Kubernetes Packages = == Summary == Provide all maintained Kubernetes releases in Fedora as multiple, versioned packages. Current practice is a separate Kubernetes release matched with each Fedora release. == Owner == * Name: [[User:Buckaroogeek| Brad

  1   2   3   4   5   6   7   8   9   10   >