Re: Adjusting python-django to latest Python Packaging Guidelines
> https://fedoraproject.org/wiki/Mailman3_Migration > https://fedoraproject.org/wiki/Mailman3_Migration/Status As an added point, there would be nice to be added here: https://fedoraproject.org/wiki/Changes ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Adjusting python-django to latest Python Packaging Guidelines
https://fedoraproject.org/wiki/Mailman3_Migration https://fedoraproject.org/wiki/Mailman3_Migration/Status ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Packaging pgAdmin4
On Thursday, 16 December 2021 23:59:23 CET Demi Marie Obenour wrote: > On 12/10/21 6:56 AM, Sandro Mani wrote: > > On 10.12.21 01:54, Demi Marie Obenour wrote: > >> On 12/9/21 1:05 PM, Sandro Mani wrote: > >>> On 09.12.21 17:31, Vitaly Zaitsev via devel wrote: > On 09/12/2021 16:56, Sandro Mani wrote: > > This does not appear to be accurate for nodejs packages - take i.e. > > node-svgo, which compliant with the guidelines bundles node_modules > > dir in svgo-2.8.0-nm-dev.tgz resp svgo-2.8.0-nm-prod.tgz. > > You can vendor only sources. No prebuilt assets are allowed. > >>> > >>> Which would basically mean bundling the node_modules folder? > >> > >> No, it would mean bundling the source from which the stuff in > >> node_modules is generated. > > > > Well this isn't what is the current nodejs packaging guidelines state > > and as noted by Ben elsewhere in this thread would make it prohibitive > > to package anything but the most trivial nodejs library. > > If some of the dependencies are unnecessary, the package maintainers > could patch the code to not use them, and send the patches upstream. > That said, this really needs to be solved at the NPM level, by having > NPM packages include machine-extractable source code. > > In any case, node_modules is not source code, since it is not “the > preferred form of the work for making modifications to it.” (quoting > LGPLv2.1 here, but I believe Fedora uses an equivalent definition). > The question then becomes whether it is more like bundling a prebuilt > binary, which is not acceptable, or like the bundling of the output > of lex, yacc, or pandoc in autotools-generated tarballs, which I > consider fine. One distinction might be whether the output files are > portable and can be automatically regenerated, which is invariably > true in the latter case. I don't see a problem if the node modules don't ship prebuilt libraries or binaries. If you look at my scripts they remove all of this. https://src.fedoraproject.org/rpms/nodejs-bash-language-server/blob/rawhide/f/ prepare_vendor.sh#_55 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Sundials 6.0.0
On 12/19/21 12:17, Antonio T. sagitter wrote: Hi all. Sundials-6.0.0 is available, it's a major release that includes many changes (https://github.com/LLNL/sundials/blob/master/CHANGELOG.md) I compiled the new packages in Copr, rebuilt bout++ and octave which need attention before we can push them in Rawhide: https://copr.fedorainfracloud.org/coprs/sagitter/ForTesting/builds/ Looks like octave upstream is aware: https://savannah.gnu.org/bugs/?func=detailitem&item_id=61701 Hopefully will be addressed relatively soon. -- Orion Poplawski he/him/his - surely the least important thing about me Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Any interest in ROCm packaging?
> Well I think OpenCL would be a good starting point since it's been around for > a while > and lots of applications use it. > > Fedora already has some of the base components already (hsakmt, rocm-runtime, > llvm). For > OCL, fedora would just need: > - ROCm-Device-Libs (bitcode compiled by LLVM, needed to upgrade rocm-runtime > to the latest > version) > - ROCm-CompilerSupport (LLVM plugin, used for runtime compilation) > - ROCclr (a middle layer that does the generic compute work) > - ROCm-OpenCL-Runtime (the opencl frontend for rocclr) Done: https://release-monitoring.org/project/231448/ https://release-monitoring.org/project/231447/ https://release-monitoring.org/project/241725/ https://release-monitoring.org/project/231450/ ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Wayland By Default with NVIDIA proprietary Driver (System-Wide Change)
> Should it work in KDE/Gnome,etc? > > https://ask.fedoraproject.org/t/refresh-rate-of-monitor/13481/3 @ Reon Beon I don't really know what you are asking ... If there is an issue with your monitor refresh rate, or changing the refresh rate does not work in any desktop environment, maybe open an issue in a window manager bug tracker (e.g. in mutter gitlab) with the whole configuration of your PC. Even if this is not a problem with a window manager, their developers may be more helpful in diagnosing the problem. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Wayland By Default with NVIDIA proprietary Driver (System-Wide Change)
Or xrandr? ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Wayland By Default with NVIDIA proprietary Driver (System-Wide Change)
Should it work in KDE/Gnome,etc? https://ask.fedoraproject.org/t/refresh-rate-of-monitor/13481/3 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Any interest in ROCm packaging?
> For anyone else wondering: > > https://rocmdocs.amd.com/en/latest/index.html > > AMD ROCm is the first open-source software development platform for > HPC/Hyperscale-class GPU computing. AMD ROCm brings the UNIX > philosophy of choice, minimalism and modular software development to > GPU computing. > > Since the ROCm ecosystem is comprised of open technologies: frameworks > (Tensorflow / PyTorch), libraries (MIOpen / Blas / RCCL), programming > model (HIP), inter-connect (OCD) and up streamed Linux® Kernel support Everything is packaged in that I can see except PyTorch, OCD and "up streamed Linux Kernel support"? > – the platform is continually optimized for performance and > extensibility. Tools, guidance and insights are shared freely across > the ROCm GitHub community and forums. > > Rich. Thoughts? ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Wayland By Default with NVIDIA proprietary Driver (System-Wide Change)
I know that "Fedora" cannot do it. I didn't made any request. The point is that this proposal can be canceled/reverted if the nvidia-settings GUI does not work on Wayland on time, or depending on what others think about the use of nvidia-settings. And... Please don't imagine things I didn't say... (take it fairly). ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Any interest in ROCm packaging?
It would be nice to have the latest version of https://src.fedoraproject.org/rpms/rocm-runtime also. https://bugzilla.redhat.com/show_bug.cgi?id=1877523 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: debug_package when using go_generate_buildrequires
On 12/6/21 12:42, Mikel Olasagasti wrote:
Hi all,
I was updating some golang specs I've and switching them to use
go_generate_buildrequires.
I realized that some specs that are using it fail to build if `%global
debug_package %{nil}` is not set. Same spec with all BuildRequires
defined works just fine.
Example:
- Full spec (go2rpm):
https://mikel.olasagasti.info/tmp/fedora/golang-github-alecaivazis-survey-2.spec
- go_generate_buildrequires spec:
https://raw.githubusercontent.com/mikelolasagasti/github-cli/main/golang-github-alecaivazis-survey-2.spec
- Full spec build: https://koji.fedoraproject.org/koji/taskinfo?taskID=79642572
- go_generate_buildrequires build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=79642147
Is this expected?
Is adding `%global debug_package %{nil}` correct or good practice for
this scenario?
Kind regards,
Mikel Olasagasti (mikelo2)
Hello,
Yes this is an issue I have noticed but I don't know where/what causes it.
I know that if we have a %build section it will cause the debug info to
be looked for. It does it too with %generate_buildrequires and I think
it shouldn't, but I don't know if this is a behavior triggered by rpm
itself or is it triggered somewhere else during the build process?
CC Panu and Devel to weigh in.
In the meantime, as long as you don't have a %build section and thus do
not produce a binaries, you can use %global debug_package %{nil}
Best regards,
Robert-André
___
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 on the list, report it:
https://pagure.io/fedora-infrastructure
Re: About how Go is updated in Fedora
On Sat, Dec 18, 2021 at 11:06:45PM +0100, Fabio Valentini wrote: > > Basically, it seems like we're moving too slowly to keep up with changes in > > Kubernetes, with trickle-down consequences. > > Sure, I saw that ticket. But I fail to see how this is this a "new problem". > If you use, for example, some shiny, new features that are only going > to be in GCC 12 or LLVM 14, you'd be out of luck on stable Fedora > branches, as well. I don't think it's a new problem at all. -- Matthew Miller Fedora Project Leader ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-34-20211219.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20211218.0): ID: 1089876 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1089876 ID: 1089887 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1089887 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Mock v2.16 release, mock-core-configs v36.4
On Sunday, December 19, 2021 10:22:57 PM CET Pavel Raiskup wrote: > So it seems that fedpkg doesn't (yet) know there's ~/.config/mock* at all. Proposed fix: https://pagure.io/rpkg/pull-request/595 Pavel ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: HEADS UP: Update to tesseract-5.0.0 in rawhide
On 19.12.21 18:52, Sandro Mani wrote: On 19.12.21 15:56, Michael J Gruber wrote: Now, depending packages seem to be broken. Have ypu pushed the side-tag incompletely, or does the new tesseract -3 bump soname again? https://bugzilla.redhat.com/show_bug.cgi?id=2033986 https://bugzilla.redhat.com/show_bug.cgi?id=2033984 https://bugzilla.redhat.com/show_bug.cgi?id=2033988 Sigh, yes, as noted elsewhere, the soname changed from libtesseract.so.5.0.0 to libtesseract.so.5 by switching back to autotools. I'll rebuild the affected packages. Should be done for real now... 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Mock v2.16 release, mock-core-configs v36.4
On Sunday, December 19, 2021 9:56:20 PM CET Pavel Raiskup wrote:
> On Sunday, December 19, 2021 4:55:28 PM CET Maxwell G via devel wrote:
> > On Thursday, December 16, 2021 12:25:12 PM CST Pavel Raiskup wrote:
> > > Hello!
> > >
> > > I'm glad I can announce that we have a new release of Mock. See the full
> > > release notes [1]. The major change that happened is the removal of
> > > 'epel-8' config files, as a follow-up for [2] discussion (and of course on
> > > *devel lists, big thanks to everyone for the discussion).
> > >
> > > Note that this is is the last v2 release being shipped to all supported
> > > Fedora/EPEL versions. From now on, we'll move to v3 with development (in
> > > 'main' branch) and EPEL 7 stays on v2 (in 'mock-2' branch, bugfix only).
> > >
> > > [1] https://rpm-software-management.github.io/mock/Release-Notes-2.16
> > > [2] https://pagure.io/epel/issue/133
> > > [Fedora 35]:
> > > https://bodhi.fedoraproject.org/updates/FEDORA-2021-a7d4aaa6fe
> > > [Fedora 34]:
> > > https://bodhi.fedoraproject.org/updates/FEDORA-2021-0947974f0a
> > > [EPEL 8]:
> > > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-2d0f959e00
> > > [EPEL 7]:
> > > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-82ccb8f2b7
> > >
> > > Happy building!
> > > Pavel
> >
> > I have tested this update and found a couple problems. Please see my
> > comment on the Fedora 35 update page (linked above) or see below:
> >
> > > Hi @praiskup et. al,
> > >
> > > There are a couple problems:
> > >
> > > - `fedpkg --release epel8 mockbuild ` does not work properly. It defaults
> > > to
> > > rhel8, which does not work by default and results in a 403 error when
> > > dnf/mock attempts to install packages. After running `ln -s
> > > /etc/mock/alma+epel-8-x86
>
> Mock doesn't default to RHEL, there must be some other problem. I quickly
> tried
> running that command, and fedpkg seems to create some temporary configuration
> directory and defaults to building from Koji repos (aka `--enablerepo
> local`?).
>
> Thank you for the report though, I will take a look. ATM I'm curious if this
> is
> a bug in Mock ...
Ok, I see it now:
$ fedpkg -v mockbuild -N
Creating repo object from /home/praiskup/rh/packages/mock
Not downloading already downloaded mock-2.16.tar.gz
Srpm found, rewriting it.
Running: rpmbuild --define '_sourcedir /home/praiskup/rh/packages/mock'
--define '_specdir /home/praiskup/rh/packages/mock' --define '_builddir
/home/praiskup/rh/packages/mock' --define '_srcrpmdir
/home/praiskup/rh/packages/mock' --define '_rpmdir
/home/praiskup/rh/packages/mock' --define '_rpmfilename
%%{ARCH}/%%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm' --define 'dist
%{?distprefix}.el8' --define 'rhel 8' --eval '%undefine fedora' --define 'el8
1' --nodeps -bs /home/praiskup/rh/packages/mock/mock.spec
setting SOURCE_DATE_EPOCH=1639612800
Wrote: /home/praiskup/rh/packages/mock/mock-2.16-1.el8.src.rpm
Mock config /etc/mock/epel-8-x86_64.cfg was not found. Going to request koji
to create new one.
...
^Z
[1]+ Stopped fedpkg -v mockbuild -N
$ cat /tmp/epel-8-x86_64.zbs7jxysmockconfig/epel-8-x86_64.cfg
# Auto-generated by the Koji build system
So this is basically a config you also get by:
$ koji mock-config --target epel8-candidate --arch x86_64
And this config can not work, since we don't have that repository locally
available. But, doing this (or alike):
sudo ln -s /etc/mock/rhel+epel-8-x86_64.cfg /etc/mock/epel-8-x86_64.cfg
... fixes the problem for me. So it seems that fedpkg doesn't (yet) know
there's ~/.config/mock* at all.
Pavel
___
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 on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Mock v2.16 release, mock-core-configs v36.4
On Sunday, December 19, 2021 4:55:28 PM CET Maxwell G via devel wrote: > On Thursday, December 16, 2021 12:25:12 PM CST Pavel Raiskup wrote: > > Hello! > > > > I'm glad I can announce that we have a new release of Mock. See the full > > release notes [1]. The major change that happened is the removal of > > 'epel-8' config files, as a follow-up for [2] discussion (and of course on > > *devel lists, big thanks to everyone for the discussion). > > > > Note that this is is the last v2 release being shipped to all supported > > Fedora/EPEL versions. From now on, we'll move to v3 with development (in > > 'main' branch) and EPEL 7 stays on v2 (in 'mock-2' branch, bugfix only). > > > > [1] https://rpm-software-management.github.io/mock/Release-Notes-2.16 > > [2] https://pagure.io/epel/issue/133 > > [Fedora 35]: https://bodhi.fedoraproject.org/updates/FEDORA-2021-a7d4aaa6fe > > [Fedora 34]: https://bodhi.fedoraproject.org/updates/FEDORA-2021-0947974f0a > > [EPEL 8]: > > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-2d0f959e00 > > [EPEL 7]: > > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-82ccb8f2b7 > > > > Happy building! > > Pavel > > I have tested this update and found a couple problems. Please see my comment > on the Fedora 35 update page (linked above) or see below: > > > Hi @praiskup et. al, > > > > There are a couple problems: > > > > - `fedpkg --release epel8 mockbuild ` does not work properly. It defaults to > > rhel8, which does not work by default and results in a 403 error when > > dnf/mock attempts to install packages. After running `ln -s > > /etc/mock/alma+epel-8-x86 Mock doesn't default to RHEL, there must be some other problem. I quickly tried running that command, and fedpkg seems to create some temporary configuration directory and defaults to building from Koji repos (aka `--enablerepo local`?). Thank you for the report though, I will take a look. ATM I'm curious if this is a bug in Mock ... > _64.cfg ~/.config/mock/epel-8-x86_64.cfg`, it breaks entirely: > > > > ``` > > $ fedpkg --release epel8 mockbuild --no-cleanup-after > > Not downloading already downloaded ansible-core-2.12.1.tar.gz > > > > setting SOURCE_DATE_EPOCH=1638921600 > > Wrote: > > /home/gotmax/Sync/git-repos/packaging/fedora_rpms/forks.repos/ansible.repos/ansible-core/ansible-core-2.12.1-2.el8.src.rpm > > > > mockbuild.exception.ConfigError: Could not find included config file: > > /tmp/epel-8-x86_64.v230b0w7mockconfig/templates/almalinux-8.tpl > > > > ERROR: Error in configuration > > Could not execute mockbuild: Failed to execute command. > > ``` > > > > It is possible to override the buildroot with `--root alma+epel-8-x86_64`, > > but that is cumbersome and shouldn't be necessary. > > > > - Using `alma+epel-8-x86_64` works with `mock` itself and with `fedpkg` > > after applying the aforementioned fix, but mock/dnf repeatedly prints out > > the following error when installing packages: `Invalid configuration > > value: failoverm > ethod=priority in /var/lib/mock/alma+epel-8-x86_64/root/etc/dnf/dnf.conf; > Configuration: OptionBinding with id "failovermethod" does not exist`. This is an innocent warning, new DNF will not pollute the stderr: https://github.com/rpm-software-management/libdnf/pull/1276 > > - Even if I wanted to use the `rhel+epel-8-*` configs, they don't work at > > all, as `subscription-manager` is broken (rhbz#1995465) and it is impossible > > to obtain an entitlement. This is unfortunate, I hope we can get an update soon. > > In my opinion, this update should not be pushed until these crucial issues > > are fixed. This all looks like the same issue. There's no "RHEL default", same as no "Alma default". According to the previous discussion. Thanks again, Pavel > > Thanks, > > > > Maxwell > > > ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: s390x funkiness? (No route to host)
On Sun, Dec 19, 2021 at 07:40:00AM -0600, Richard Shaw wrote: > I tried building twice just in case it was a one-off issue but it failed > the same way with the s390x unable to connect? > > https://koji.fedoraproject.org/koji/taskinfo?taskID=80185813 > > Looks like I'm not the only one either: > > https://pagure.io/fedora-infrastructure/issue/10431 The hypervisor in our kvm lpar crashed early this morning. ;( We rebooted it, but the networking isn't working right on it now. We have a ticket into mainframe folks to look into it, but likely that won't be until tomorrow. In the mean time I have setup a new cache proxy in the zvm lpar and s390x builds should complete fine there for now. kevin 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 on the list, report it: https://pagure.io/fedora-infrastructure
Sundials 6.0.0
Hi all. Sundials-6.0.0 is available, it's a major release that includes many changes (https://github.com/LLNL/sundials/blob/master/CHANGELOG.md) I compiled the new packages in Copr, rebuilt bout++ and octave which need attention before we can push them in Rawhide: https://copr.fedorainfracloud.org/coprs/sagitter/ForTesting/builds/ -- --- Antonio Trande Fedora Project mailto: sagit...@fedoraproject.org GPG key: 0xCC1CFEF30920C8AE GPG key server: https://keyserver1.pgp.com/ OpenPGP_0xCC1CFEF30920C8AE.asc Description: OpenPGP public key OpenPGP_signature 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Non-responsive Maintainer Check for ishcherb
On 19. 12. 21 18:26, Maxwell G via devel wrote: Hi everyone, I hope you are having/had a good weekend. I am sending this email in accordance with the Non-Responsive Maintainer Policy[0]. I created a non-responsive maintainer bug[1] for @ishcherb over two weeks ago and have not received a response. I am happy to help maintain this package. A month ago, I created a PR[2] to update `python-ansi2html` to the latest upstream release (1.6.0) and implement the new Python Packaging Guidelines. The PR did not receive a response from the package's main maintainer (@ishcherb) nor the co-maintainer (@ralph). The latest upstream version, 1.6.0, was released a year ago. The release-monitoring bug[3] for this release similarly did not receive a response from the maintainers. ... Does anyone know if @ishcherb and @ralph are still active in Fedora? @ishcherb is a former teammate of mine and I think she is no longer active in Fedora, but I'll try to ask her. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: HEADS UP: Update to tesseract-5.0.0 in rawhide
On 19.12.21 15:56, Michael J Gruber wrote: Now, depending packages seem to be broken. Have ypu pushed the side-tag incompletely, or does the new tesseract -3 bump soname again? https://bugzilla.redhat.com/show_bug.cgi?id=2033986 https://bugzilla.redhat.com/show_bug.cgi?id=2033984 https://bugzilla.redhat.com/show_bug.cgi?id=2033988 Sigh, yes, as noted elsewhere, the soname changed from libtesseract.so.5.0.0 to libtesseract.so.5 by switching back to autotools. I'll rebuild the affected packages. 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 on the list, report it: https://pagure.io/fedora-infrastructure
Non-responsive Maintainer Check for ishcherb
Hi everyone, I hope you are having/had a good weekend. I am sending this email in accordance with the Non-Responsive Maintainer Policy[0]. I created a non-responsive maintainer bug[1] for @ishcherb over two weeks ago and have not received a response. I am happy to help maintain this package. A month ago, I created a PR[2] to update `python-ansi2html` to the latest upstream release (1.6.0) and implement the new Python Packaging Guidelines. The PR did not receive a response from the package's main maintainer (@ishcherb) nor the co-maintainer (@ralph). The latest upstream version, 1.6.0, was released a year ago. The release-monitoring bug[3] for this release similarly did not receive a response from the maintainers. Here is the output of fedora_active_user for @ishcherb: ``` $ fedora_active_user.py --nofas --user ishcherb --email shcherbina.ir...@gmail.com Last action on koji: Fri, 24 Sep 2021 tag_package_owners entry created by mohanboddu [still active] Last package update on bodhi: 2017-11-21 12:46:16 on package spec2scl-1.2.1-1.fc27 Last actions performed according to fedmsg: - gotmax@e.email filed a new bug RHBZ#2028650 'Non-responsive maintainer check for ishc...' on 2021-12-02 15:24:48 - gotmax@e.email commented on RHBZ#2028650 'Non-responsive maintainer check for ishc...' on 2021-12-02 15:24:47 - gotmax@e.email updated 'cc' on RHBZ#1888556 'python-ansi2html-1.6.0a1 is available' on 2021-11-03 05:29:12 - ishcherb moved to position 589 on the badges leaderboard on 2021-10-27 02:24:46 - ishcherb has been awarded the "Tadpole with Legs" badge on 2021-10-27 02:24:37 And for @ralph: ``` $ fedora_active_user.py --nofas --user ralph --email 'rb...@redhat.com' Last action on koji: Sun, 10 Oct 2021 tag_package_owners entry created by oscar [still active] Last package update on bodhi: 2020-11-16 15:46:58 on package python-jira-2.0.0-10.fc34 Last actions performed according to fedmsg: - jaclu unstarred ralphbean/bugwarrior on 2021-12-17 16:22:27 - jaclu starred ralphbean/bugwarrior on 2021-12-17 16:22:27 - None on 2021-12-17 14:02:49 - None on 2021-12-17 14:02:48 - None on 2021-12-17 14:02:48 - None on 2021-12-17 14:02:47 - None on 2021-12-17 13:59:34 - None on 2021-12-17 13:59:24 - None on 2021-12-17 13:59:24 - None on 2021-12-17 13:59:23 Last email on mailing list: On 2018-11-15T01:35:55Z rb...@redhat.com emailed as Ralph Bean on https://lists.fedoraproject.org/archives/api/list/infrastruct...@lists.fedoraproject.org/ On 2018-09-10T15:30:19Z rb...@redhat.com emailed as Ralph Bean on https://lists.fedoraproject.org/archives/api/list/infrastruct...@lists.fedoraproject.org/ On 2018-09-07T19:42:06Z rb...@redhat.com emailed as Ralph Bean on https://lists.fedoraproject.org/archives/api/list/infrastruct...@lists.fedoraproject.org/ On 2018-08-28T14:10:39Z rb...@redhat.com emailed as Ralph Bean on https://lists.fedoraproject.org/archives/api/list/infrastruct...@lists.fedoraproject.org/ On 2018-06-26T13:24:49Z rb...@redhat.com emailed as Ralph Bean on https://lists.fedoraproject.org/archives/api/list/infrastruct...@lists.fedoraproject.org/ On 2018-06-25T13:25:53Z rb...@redhat.com emailed as Ralph Bean on https://lists.fedoraproject.org/archives/api/list/infrastruct...@lists.fedoraproject.org/ On 2018-05-18T13:33:34Z rb...@redhat.com emailed as Ralph Bean on https://lists.fedoraproject.org/archives/api/list/infrastruct...@lists.fedoraproject.org/ On 2018-05-11T01:00:42Z rb...@redhat.com emailed as Ralph Bean on https://lists.fedoraproject.org/archives/api/list/infrastruct...@lists.fedoraproject.org/ On 2018-05-10T12:22:34Z rb...@redhat.com emailed as Ralph Bean on https://lists.fedoraproject.org/archives/api/list/infrastruct...@lists.fedoraproject.org/ On 2018-04-20T16:21:34Z rb...@redhat.com emailed as Ralph Bean on https://lists.fedoraproject.org/archives/api/list/infrastruct...@lists.fedoraproject.org/ Bugzilla activity 20 bugs assigned, cc or on which rb...@redhat.com commented Last comment on the most recent ticket on bugzilla: #1417509 2017-03-11 rbea ``` Does anyone know if @ishcherb and @ralph are still active in Fedora? Thanks, Maxwell [0]: https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ [1]: https://bugzilla.redhat.com/show_bug.cgi?id=2028650 [2]: https://src.fedoraproject.org/rpms/python-ansi2html/pull-request/3 [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1888556 [4]: https://koji.fedoraproject.org/koji/userinfo?userID=3662 (@ishcherb's Koji user page) [5]: https://koji.fedoraproject.org/koji/userinfo?userID=1974 (@ralph's Koji user page) -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 PGP Keyserver: hkp://keyserver.ubuntu.com gotmax@e.email signature.asc Description: This is a digitally signed message part. ___ devel mailing list -- devel@lists.fedorapro
Re: F36 Change: Wayland By Default with NVIDIA proprietary Driver (System-Wide Change)
On Sun, Dec 19, 2021 at 11:39 AM Julian Sikorski wrote: > > W dniu 19.12.2021 o 17:05, Michael Cronenworth pisze: > > On 12/17/21 8:11 PM, Michael Berteaux wrote: > >> On top of what others said, I add that there is also the > >> nvidia-settings GUI that does not work on Wayland. > >> > >> I don't use it personally, but other people can use, for example, > >> application/game profiles. > >> > >> It is also something to consider... > > > > The nvidia-settings app requires some support from NVIDIA to work under > > Wayland. There is nothing Fedora can do to make it work. > > Be that as it may, we should not be defaulting to a configuration which > causes significant usability regressions. Is some collaboration with > NVIDIA planned in order to fix these? My post to nvidia developer forums > about broken night light did not get any official response. > Judging about what's going on in Mutter upstream[1], I would say they're furiously working on uplifting NVIDIA GBM Wayland mode for GNOME 42. [1]: https://gitlab.gnome.org/GNOME/mutter/-/commits/main -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: How to reset a branch on fedpkg?
On Sunday, December 19, 2021 6:35:13 AM CST Chen Chen wrote: > Hi everyone, > > I recently adopted an orphaned package. There are unwanted commits in a > branch, and I'd like to reset this branch to be as same as rawhide. How can I > achieve this? > It seems force push were not allowed on src.f . I also do not want to commit > a "git revert" on it to avoid "x commits ahead - click to create new PR" on > web UI. > > Regards, > Chen Hi Chen, Have you tried `fedpkg push --force` (or `-f` for short)? Thanks, Maxwell -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 PGP Keyserver: hkp://keyserver.ubuntu.com gotmax@e.email signature.asc Description: This is a digitally signed message part. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Wayland By Default with NVIDIA proprietary Driver (System-Wide Change)
W dniu 19.12.2021 o 17:05, Michael Cronenworth pisze: On 12/17/21 8:11 PM, Michael Berteaux wrote: On top of what others said, I add that there is also the nvidia-settings GUI that does not work on Wayland. I don't use it personally, but other people can use, for example, application/game profiles. It is also something to consider... The nvidia-settings app requires some support from NVIDIA to work under Wayland. There is nothing Fedora can do to make it work. Be that as it may, we should not be defaulting to a configuration which causes significant usability regressions. Is some collaboration with NVIDIA planned in order to fix these? My post to nvidia developer forums about broken night light did not get any official response. Best regards, Julian ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: HEADS UP: Update to tesseract-5.0.0 in rawhide
On Sun, 2021-12-19 at 21:49 +0900, Mamoru TASAKA wrote: > Sandro Mani wrote on 2021/12/15 20:15: > > > > On 15.12.21 11:11, Michael J Gruber wrote: > > > Are you planning to bring these to F35, as well? > > > Tesseract-5.0.0 appears to be mostly a bugfix release along with > > > some other improvements, so I dunno (and haven't tested so far - > > > the heads up was a few hours before the push). > > > > Since it brings along a soname bump, I wasn't planning on building > > it for stable releases. > > > > Sandro > > Note that with tesseract-5.0.0-3.fc36 "Switch back to autotools" > changes, > soname changed from "libtesseract.so.5.0.0()(64bit)" (in -1.fc36) to > "libtesseract.so.5()(64bit)" . > As the dependent packages were built with -1.fc36, now all dependent > packages again need rebuilding > (especially currently opencv-contrib-0:4.5.4-7.fc36.x86_64 is broken > for now). > > I was going to rebuild at least opencv, however currently s390x > builder seems unhealthy... > https://pagure.io/fedora-infrastructure/issue/10431 > OK thank you ( by rebuild opencv ) > Regards, > Mamoru > ___ > 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 on the list, report it: > https://pagure.io/fedora-infrastructure -- Sérgio M. B. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Wayland By Default with NVIDIA proprietary Driver (System-Wide Change)
On 12/17/21 8:11 PM, Michael Berteaux wrote: On top of what others said, I add that there is also the nvidia-settings GUI that does not work on Wayland. I don't use it personally, but other people can use, for example, application/game profiles. It is also something to consider... The nvidia-settings app requires some support from NVIDIA to work under Wayland. There is nothing Fedora can do to make it work. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Mock v2.16 release, mock-core-configs v36.4
On Thursday, December 16, 2021 12:25:12 PM CST Pavel Raiskup wrote: > Hello! > > I'm glad I can announce that we have a new release of Mock. See the full > release notes [1]. The major change that happened is the removal of > 'epel-8' config files, as a follow-up for [2] discussion (and of course on > *devel lists, big thanks to everyone for the discussion). > > Note that this is is the last v2 release being shipped to all supported > Fedora/EPEL versions. From now on, we'll move to v3 with development (in > 'main' branch) and EPEL 7 stays on v2 (in 'mock-2' branch, bugfix only). > > [1] https://rpm-software-management.github.io/mock/Release-Notes-2.16 > [2] https://pagure.io/epel/issue/133 > [Fedora 35]: https://bodhi.fedoraproject.org/updates/FEDORA-2021-a7d4aaa6fe > [Fedora 34]: https://bodhi.fedoraproject.org/updates/FEDORA-2021-0947974f0a > [EPEL 8]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-2d0f959e00 > [EPEL 7]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-82ccb8f2b7 > > Happy building! > Pavel I have tested this update and found a couple problems. Please see my comment on the Fedora 35 update page (linked above) or see below: > Hi @praiskup et. al, > > There are a couple problems: > > - `fedpkg --release epel8 mockbuild ` does not work properly. It defaults to > rhel8, which does not work by default and results in a 403 error when > dnf/mock attempts to install packages. After running `ln -s > /etc/mock/alma+epel-8-x86 _64.cfg ~/.config/mock/epel-8-x86_64.cfg`, it breaks entirely: > > ``` > $ fedpkg --release epel8 mockbuild --no-cleanup-after > Not downloading already downloaded ansible-core-2.12.1.tar.gz > > setting SOURCE_DATE_EPOCH=1638921600 > Wrote: > /home/gotmax/Sync/git-repos/packaging/fedora_rpms/forks.repos/ansible.repos/ansible-core/ansible-core-2.12.1-2.el8.src.rpm > > mockbuild.exception.ConfigError: Could not find included config file: > /tmp/epel-8-x86_64.v230b0w7mockconfig/templates/almalinux-8.tpl > > ERROR: Error in configuration > Could not execute mockbuild: Failed to execute command. > ``` > > It is possible to override the buildroot with `--root alma+epel-8-x86_64`, > but that is cumbersome and shouldn't be necessary. > > - Using `alma+epel-8-x86_64` works with `mock` itself and with `fedpkg` after > applying the aforementioned fix, but mock/dnf repeatedly prints out the > following error when installing packages: `Invalid configuration value: > failoverm ethod=priority in /var/lib/mock/alma+epel-8-x86_64/root/etc/dnf/dnf.conf; Configuration: OptionBinding with id "failovermethod" does not exist`. > > - Even if I wanted to use the `rhel+epel-8-*` configs, they don't work at > all, as `subscription-manager` is broken (rhbz#1995465) and it is impossible > to obtain an entitlement. > > In my opinion, this update should not be pushed until these crucial issues > are fixed. > > Thanks, > > Maxwell -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 PGP Keyserver: hkp://keyserver.ubuntu.com gotmax@e.email 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: HEADS UP: Update to tesseract-5.0.0 in rawhide
Now, depending packages seem to be broken. Have ypu pushed the side-tag incompletely, or does the new tesseract -3 bump soname again? https://bugzilla.redhat.com/show_bug.cgi?id=2033986 https://bugzilla.redhat.com/show_bug.cgi?id=2033984 https://bugzilla.redhat.com/show_bug.cgi?id=2033988 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Is it possible to find out which packages were used when building the package?
Thanks, for answer. I build every day rpm packages from git locally with mock. ... It might be more efficient to run a shell command in your build environment to review /var/log/dnf.log, even in a "mock" build environment, rather than trying to parse out the dependencies directly b reading the RPM or the .spec file. It can be a real adventure to resolve all the dependencies on dependencies on dependencies, especially for a complex python based package. RPM and yum also do not prove a package was actually used, merely that it was managed as a build requirement. strace -f -e trace=file -o strace.out mock ... ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
s390x funkiness? (No route to host)
I tried building twice just in case it was a one-off issue but it failed the same way with the s390x unable to connect? https://koji.fedoraproject.org/koji/taskinfo?taskID=80185813 Looks like I'm not the only one either: https://pagure.io/fedora-infrastructure/issue/10431 Thanks, 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: How to reset a branch on fedpkg?
On 19. 12. 21 13:35, Chen Chen wrote: Hi everyone, I recently adopted an orphaned package. There are unwanted commits in a branch, and I'd like to reset this branch to be as same as rawhide. How can I achieve this? It seems force push were not allowed on src.f . I also do not want to commit a "git revert" on it to avoid "x commits ahead - click to create new PR" on web UI. Short answer: You cannot. Long answer: You can create a merge commit that resets the branch to a working state and push that merge commit to both rawhide and your branches. Assuming "mybranch" has the extra commit you don't want. [gitfu (mybranch)]$ git l * 66a3b65 2021-12-19 Miro Hrončok - Extra commit 2 (HEAD -> mybranch) * ade24ea 2021-12-19 Miro Hrončok - Extra commit * af838c5 2021-12-19 Miro Hrončok - Initial rawhide commit (rawhide) [gitfu (mybranhc)]$ git switch rawhide Switched to branch 'rawhide' [gitfu (rawhide)]$ git switch -c merger Switched to a new branch 'merger' [gitfu (merger)]$ git l * af838c5 2021-12-19 Miro Hrončok - Initial rawhide commit (HEAD -> merger, rawhide) [gitfu (merger)]$ git merge --no-ff mybranch Merge made by the 'recursive' strategy. gitfu.spec | 2 ++ 1 file changed, 2 insertions(+) [gitfu (merger)]$ git l * 677fcd7 2021-12-19 Miro Hrončok - Merge branch 'mybranch' into merger (HEAD -> merger) |\ | * 66a3b65 2021-12-19 Miro Hrončok - Extra commit 2 (mybranch) | * ade24ea 2021-12-19 Miro Hrončok - Extra commit |/ * af838c5 2021-12-19 Miro Hrončok - Initial rawhide commit (rawhide) [gitfu (merger)]$ git restore . --source=rawhide [gitfu (merger *)]$ git commit -a --amend -m 'Restore branch mybranch to rawhide state' [merger 2c3b417] Restore branch mybranch to rawhide state Date: Sun Dec 19 14:02:53 2021 +0100 [gitfu (merger)]$ git l * 2c3b417 2021-12-19 Miro Hrončok - Restore branch mybranch to rawhide state (HEAD -> merger) |\ | * 66a3b65 2021-12-19 Miro Hrončok - Extra commit 2 (mybranch) | * ade24ea 2021-12-19 Miro Hrončok - Extra commit |/ * af838c5 2021-12-19 Miro Hrončok - Initial rawhide commit (rawhide) [gitfu (merger)]$ git switch rawhide Switched to branch 'rawhide' [gitfu (rawhide)]$ git merge merger Updating af838c5..2c3b417 Fast-forward [gitfu (rawhide)]$ git switch mybranch Switched to branch 'mybranch' [gitfu (mybranch)]$ git merge merger Updating 66a3b65..2c3b417 Fast-forward gitfu.spec | 2 -- 1 file changed, 2 deletions(-) [gitfu (mybranch)]$ git branch -d merger Deleted branch merger (was 2c3b417). [gitfu (mybranch)]$ git l * 2c3b417 2021-12-19 Miro Hrončok - Restore branch mybranch to rawhide state (HEAD -> mybranch, rawhide) |\ | * 66a3b65 2021-12-19 Miro Hrončok - Extra commit 2 | * ade24ea 2021-12-19 Miro Hrončok - Extra commit |/ * af838c5 2021-12-19 Miro Hrončok - Initial rawhide commit [gitfu (mybranch)]$ git diff rawhide (nothing) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: HEADS UP: Update to tesseract-5.0.0 in rawhide
Sandro Mani wrote on 2021/12/15 20:15: On 15.12.21 11:11, Michael J Gruber wrote: Are you planning to bring these to F35, as well? Tesseract-5.0.0 appears to be mostly a bugfix release along with some other improvements, so I dunno (and haven't tested so far - the heads up was a few hours before the push). Since it brings along a soname bump, I wasn't planning on building it for stable releases. Sandro Note that with tesseract-5.0.0-3.fc36 "Switch back to autotools" changes, soname changed from "libtesseract.so.5.0.0()(64bit)" (in -1.fc36) to "libtesseract.so.5()(64bit)" . As the dependent packages were built with -1.fc36, now all dependent packages again need rebuilding (especially currently opencv-contrib-0:4.5.4-7.fc36.x86_64 is broken for now). I was going to rebuild at least opencv, however currently s390x builder seems unhealthy... https://pagure.io/fedora-infrastructure/issue/10431 Regards, Mamoru ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
How to reset a branch on fedpkg?
Hi everyone, I recently adopted an orphaned package. There are unwanted commits in a branch, and I'd like to reset this branch to be as same as rawhide. How can I achieve this? It seems force push were not allowed on src.f . I also do not want to commit a "git revert" on it to avoid "x commits ahead - click to create new PR" on web UI. Regards, Chen ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Any interest in ROCm packaging?
On Thursday, December 16, 2021 6:07:10 PM CET Jeremy Newton wrote: > Full disclosure, I am both a Fedora packager and an employee at AMD. > To be clear, the following is not at all endorsed by my employer; my > interest and use of Fedora is purely a personal hobby and I would like to > keep it that way. > There has been a recent effort to step up Debian packaging of ROCm, and > would like to see if anyone has some interest in expanding the Fedora ROCm > packages. > I see there's a few packages already, and I'm hoping to help with some > internal processes to make ROCm more distro friendly, such as better FHS > compliance, clearer licensing, etc. Anyone interested? I would be happy to > try to help or review package requests :) Hi Jeremy, some time ago I tried to start this. The first step would be to cleanup cmake to actually install them correctly and find the dependencies in the system. I've started with this but for some libraries it worked for other it took ages. See e.g. my PRs here: https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/pulls? q=is%3Apr+is%3Aclosed With every new release there are other strange defaults like building libraries as static by default: https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/blob/master/ CMakeLists.txt#L37 So before starting with packaging, cmake should be cleaned up: https://cliutils.gitlab.io/modern-cmake/ ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-35-20211219.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-35-20211218.0): ID: 1089747 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1089747 ID: 1089758 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1089758 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
