Re: Mock Configs v39.3 released - DNF5 used for F40+ builds
On 18. 12. 23 10:08, Pavel Raiskup wrote:
In any case, if you need to - stay with DNF4 for a while - either do
$ cat ~/.config/mock/fedora-rawhide-x86_64.cfg
include("/etc/mock/fedora-rawhide-x86_64.cfg")
config_opts["package_manager"] = "dnf"
... or stay with the `mock-core-configs v39.2` a bit longer please.
Hi Pavel,
this works locally, but not in Copr.
Our Python 3.13 Copr builds started failing today with the builddep globbing
issue.
What do we do?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Obsolete of DNF by DNF5 in RAWHIDE
On 26. 05. 23 11:51, Miro Hrončok wrote:
On 26. 05. 23 11:47, Miro Hrončok wrote:
On 24. 05. 23 9:40, Jaroslav Mracek wrote:
Hello,
I have great news that the upcoming release of DNF5 will obsolete DNF in
rawhide (Fedora 39). The release is planned not before the end of May. The
change was already announced in
https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5
<https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5>.
It seem rawhide copr builds are broken...
To reproduce, try:
$ COPR=whatever
$ copr create $COPR
--repo='http://kojipkgs.fedoraproject.org/repos/rawhide/latest/$basearch/'
--chroot fedora-rawhide-x86_64 --delete-after-days 7
$ copr add-package-distgit $COPR --name dummy-test-package-gloster --commit
rawhide
$ copr build-package $COPR --name dummy-test-package-gloster
See https://copr.fedorainfracloud.org/coprs/churchyard/whatever/builds/
I get:
...
Finish(bootstrap): dnf install
Start(bootstrap): creating root cache
Finish(bootstrap): creating root cache
Finish(bootstrap): chroot init
Start: chroot init
INFO: mounting tmpfs at
/var/lib/mock/fedora-rawhide-x86_64-1685094318.073555/root.
INFO: calling preinit hooks
INFO: enabled root cache
INFO: enabled package manager cache
Start: cleaning package manager metadata
Finish: cleaning package manager metadata
INFO: enabled HW Info plugin
Mock Version: 3.5
INFO: Mock Version: 3.5
Start: dnf install
Unknown argument "--allowerasing" for command "dnf5". Add "--help" for more
information about the arguments.
WARNING: Dnf command failed, retrying, attempt #2, sleeping 10s
Unknown argument "--allowerasing" for command "dnf5". Add "--help" for more
information about the arguments.
WARNING: Dnf command failed, retrying, attempt #3, sleeping 10s
Unknown argument "--allowerasing" for command "dnf5". Add "--help" for more
information about the arguments.
ERROR:
Exception(/var/lib/copr-rpmbuild/workspace/workdir-0s4wy2p4/dummy-test-package-gloster/dummy-test-package-gloster.spec) Config(fedora-rawhide-x86_64) 1 minutes 26 seconds
INFO: Results and/or logs in: /var/lib/copr-rpmbuild/results
INFO: Cleaning up build root ('cleanup_on_failure=True')
Start: clean chroot
INFO: unmounting tmpfs.
Finish: clean chroot
ERROR: Command failed:
# /usr/bin/systemd-nspawn -q -M fb947d9bf50448af8a0250f849d154de -D
/var/lib/mock/fedora-rawhide-x86_64-bootstrap-1685094318.073555/root -a
--capability=cap_ipc_lock --rlimit=RLIMIT_NOFILE=10240
--capability=cap_ipc_lock --bind=/tmp/mock-resolv.4as66jul:/etc/resolv.conf
--console=pipe --setenv=TERM=vt100 --setenv=SHELL=/bin/bash
--setenv=HOME=/var/lib/mock/fedora-rawhide-x86_64-1685094318.073555/root/installation-homedir --setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin --setenv=PROMPT_COMMAND=printf "\033]0;\007" --setenv=PS1= \s-\v\$ --setenv=LANG=C.UTF-8 --setenv=LC_MESSAGES=C.UTF-8 --setenv=SYSTEMD_NSPAWN_TMPFS_TMP=0 --setenv=SYSTEMD_SECCOMP=0 --resolv-conf=off /usr/bin/dnf --installroot /var/lib/mock/fedora-rawhide-x86_64-1685094318.073555/root/ --releasever 39 --setopt=deltarpm=False --allowerasing --disableplugin=local --disableplugin=spacewalk --disableplugin=versionlock install @buildsys-build --setopt=tsflags=nocontexts --setopt=tsflags=nocontexts --setopt=tsflags=nocontexts
Unknown argument "--allowerasing" for command "dnf5". Add "--help" for more
information about the arguments.
Copr build error: Mock build failed
OK, Koji is broken as well, this is not limited to Copr.
See e.g. https://koji.fedoraproject.org/koji/taskinfo?taskID=101549275
https://kojipkgs.fedoraproject.org//work/tasks/9276/101549276/root.log
...
DEBUG util.py:443: Unknown argument "groupinstall" for command "dnf5". Add
"--help" for more information about the arguments.
DEBUG util.py:596: Child return code was: 2
I've requested the update to be untagged in https://pagure.io/releng/issue/11441
Please ship this change by means that will not distrupt the work of all others
unnecessarily.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Obsolete of DNF by DNF5 in RAWHIDE
On 26. 05. 23 11:47, Miro Hrončok wrote:
On 24. 05. 23 9:40, Jaroslav Mracek wrote:
Hello,
I have great news that the upcoming release of DNF5 will obsolete DNF in
rawhide (Fedora 39). The release is planned not before the end of May. The
change was already announced in
https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5
<https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5>.
It seem rawhide copr builds are broken...
To reproduce, try:
$ COPR=whatever
$ copr create $COPR
--repo='http://kojipkgs.fedoraproject.org/repos/rawhide/latest/$basearch/'
--chroot fedora-rawhide-x86_64 --delete-after-days 7
$ copr add-package-distgit $COPR --name dummy-test-package-gloster --commit
rawhide
$ copr build-package $COPR --name dummy-test-package-gloster
See https://copr.fedorainfracloud.org/coprs/churchyard/whatever/builds/
I get:
...
Finish(bootstrap): dnf install
Start(bootstrap): creating root cache
Finish(bootstrap): creating root cache
Finish(bootstrap): chroot init
Start: chroot init
INFO: mounting tmpfs at
/var/lib/mock/fedora-rawhide-x86_64-1685094318.073555/root.
INFO: calling preinit hooks
INFO: enabled root cache
INFO: enabled package manager cache
Start: cleaning package manager metadata
Finish: cleaning package manager metadata
INFO: enabled HW Info plugin
Mock Version: 3.5
INFO: Mock Version: 3.5
Start: dnf install
Unknown argument "--allowerasing" for command "dnf5". Add "--help" for more
information about the arguments.
WARNING: Dnf command failed, retrying, attempt #2, sleeping 10s
Unknown argument "--allowerasing" for command "dnf5". Add "--help" for more
information about the arguments.
WARNING: Dnf command failed, retrying, attempt #3, sleeping 10s
Unknown argument "--allowerasing" for command "dnf5". Add "--help" for more
information about the arguments.
ERROR:
Exception(/var/lib/copr-rpmbuild/workspace/workdir-0s4wy2p4/dummy-test-package-gloster/dummy-test-package-gloster.spec) Config(fedora-rawhide-x86_64) 1 minutes 26 seconds
INFO: Results and/or logs in: /var/lib/copr-rpmbuild/results
INFO: Cleaning up build root ('cleanup_on_failure=True')
Start: clean chroot
INFO: unmounting tmpfs.
Finish: clean chroot
ERROR: Command failed:
# /usr/bin/systemd-nspawn -q -M fb947d9bf50448af8a0250f849d154de -D
/var/lib/mock/fedora-rawhide-x86_64-bootstrap-1685094318.073555/root -a
--capability=cap_ipc_lock --rlimit=RLIMIT_NOFILE=10240
--capability=cap_ipc_lock --bind=/tmp/mock-resolv.4as66jul:/etc/resolv.conf
--console=pipe --setenv=TERM=vt100 --setenv=SHELL=/bin/bash
--setenv=HOME=/var/lib/mock/fedora-rawhide-x86_64-1685094318.073555/root/installation-homedir --setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin --setenv=PROMPT_COMMAND=printf "\033]0;\007" --setenv=PS1= \s-\v\$ --setenv=LANG=C.UTF-8 --setenv=LC_MESSAGES=C.UTF-8 --setenv=SYSTEMD_NSPAWN_TMPFS_TMP=0 --setenv=SYSTEMD_SECCOMP=0 --resolv-conf=off /usr/bin/dnf --installroot /var/lib/mock/fedora-rawhide-x86_64-1685094318.073555/root/ --releasever 39 --setopt=deltarpm=False --allowerasing --disableplugin=local --disableplugin=spacewalk --disableplugin=versionlock install @buildsys-build --setopt=tsflags=nocontexts --setopt=tsflags=nocontexts --setopt=tsflags=nocontexts
Unknown argument "--allowerasing" for command "dnf5". Add "--help" for more
information about the arguments.
Copr build error: Mock build failed
OK, Koji is broken as well, this is not limited to Copr.
See e.g. https://koji.fedoraproject.org/koji/taskinfo?taskID=101549275
https://kojipkgs.fedoraproject.org//work/tasks/9276/101549276/root.log
...
DEBUG util.py:443: Unknown argument "groupinstall" for command "dnf5". Add
"--help" for more information about the arguments.
DEBUG util.py:596: Child return code was: 2
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Obsolete of DNF by DNF5 in RAWHIDE
On 24. 05. 23 9:40, Jaroslav Mracek wrote:
Hello,
I have great news that the upcoming release of DNF5 will obsolete DNF in
rawhide (Fedora 39). The release is planned not before the end of May. The
change was already announced in
https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5
<https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5>.
It seem rawhide copr builds are broken...
To reproduce, try:
$ COPR=whatever
$ copr create $COPR
--repo='http://kojipkgs.fedoraproject.org/repos/rawhide/latest/$basearch/'
--chroot fedora-rawhide-x86_64 --delete-after-days 7
$ copr add-package-distgit $COPR --name dummy-test-package-gloster --commit
rawhide
$ copr build-package $COPR --name dummy-test-package-gloster
See https://copr.fedorainfracloud.org/coprs/churchyard/whatever/builds/
I get:
...
Finish(bootstrap): dnf install
Start(bootstrap): creating root cache
Finish(bootstrap): creating root cache
Finish(bootstrap): chroot init
Start: chroot init
INFO: mounting tmpfs at
/var/lib/mock/fedora-rawhide-x86_64-1685094318.073555/root.
INFO: calling preinit hooks
INFO: enabled root cache
INFO: enabled package manager cache
Start: cleaning package manager metadata
Finish: cleaning package manager metadata
INFO: enabled HW Info plugin
Mock Version: 3.5
INFO: Mock Version: 3.5
Start: dnf install
Unknown argument "--allowerasing" for command "dnf5". Add "--help" for more
information about the arguments.
WARNING: Dnf command failed, retrying, attempt #2, sleeping 10s
Unknown argument "--allowerasing" for command "dnf5". Add "--help" for more
information about the arguments.
WARNING: Dnf command failed, retrying, attempt #3, sleeping 10s
Unknown argument "--allowerasing" for command "dnf5". Add "--help" for more
information about the arguments.
ERROR:
Exception(/var/lib/copr-rpmbuild/workspace/workdir-0s4wy2p4/dummy-test-package-gloster/dummy-test-package-gloster.spec)
Config(fedora-rawhide-x86_64) 1 minutes 26 seconds
INFO: Results and/or logs in: /var/lib/copr-rpmbuild/results
INFO: Cleaning up build root ('cleanup_on_failure=True')
Start: clean chroot
INFO: unmounting tmpfs.
Finish: clean chroot
ERROR: Command failed:
# /usr/bin/systemd-nspawn -q -M fb947d9bf50448af8a0250f849d154de -D
/var/lib/mock/fedora-rawhide-x86_64-bootstrap-1685094318.073555/root -a
--capability=cap_ipc_lock --rlimit=RLIMIT_NOFILE=10240
--capability=cap_ipc_lock --bind=/tmp/mock-resolv.4as66jul:/etc/resolv.conf
--console=pipe --setenv=TERM=vt100 --setenv=SHELL=/bin/bash
--setenv=HOME=/var/lib/mock/fedora-rawhide-x86_64-1685094318.073555/root/installation-homedir
--setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin
--setenv=PROMPT_COMMAND=printf "\033]0;\007"
--setenv=PS1= \s-\v\$ --setenv=LANG=C.UTF-8
--setenv=LC_MESSAGES=C.UTF-8 --setenv=SYSTEMD_NSPAWN_TMPFS_TMP=0
--setenv=SYSTEMD_SECCOMP=0 --resolv-conf=off /usr/bin/dnf --installroot
/var/lib/mock/fedora-rawhide-x86_64-1685094318.073555/root/ --releasever 39
--setopt=deltarpm=False --allowerasing --disableplugin=local
--disableplugin=spacewalk --disableplugin=versionlock install @buildsys-build
--setopt=tsflags=nocontexts --setopt=tsflags=nocontexts --setopt=tsflags=nocontexts
Unknown argument "--allowerasing" for command "dnf5". Add "--help" for more
information about the arguments.
Copr build error: Mock build failed
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Excluding older builds of packages from Fedora when testing new ones in Copr
On 09. 07. 21 13:27, Pavel Raiskup wrote:
On Friday, July 9, 2021 11:36:09 AM CEST Miro Hrončok wrote:
On 09. 07. 21 11:30, Pavel Raiskup wrote:
On Friday, July 9, 2021 10:19:57 AM CEST Miro Hrončok wrote:
On 09. 07. 21 9:46, Pavel Raiskup wrote:
This is pre-production experiment, right? Couldn't you just specify
"Provides: python3dist(click) = 7.9"?
It is, but it would not help me. By manually providing this, I would:
- confuse %pyproject_buildrequires generator -- Python would think 'click <
8' is not satisfied, by RPM/dnf would insist it is.
- still not get a root.log resolution failure I want
- still not "satisfy" packages that BR "python3click" instead of
"python3dist(click)"
I wonder if adding Obsoletes: python3-click < %{version} helps, but I don't
think so.
We have an RFEhttps://pagure.io/copr/copr/issue/1336 that could help you if you
could specify dnf.conf excludepkgs= option for the rawhide repo. But this is
not an easy one.
Yes, this would work.
Another idea...
What if you had a syntetic package, say "click-blocker", with 'Conflicts:
python3-click < XYZ'? That package could be added as always-installed package
into "Packages" field (chroot Edit form).
Or maybe it could simply require 'python3-click >= XYZ', too?
Is "Packages" always-installed or initially-installed? What prevents dnf to
downgrade it?
I'll test this approach thou, seems reasonable.
You are right, it is always "initially installed".. It is definitely
interesting topic, please share the results of the experiment :-)
If DNF really removes the artificial package because it depends on a _newer_
click package (than the following transaction requires) -- we could probably
consider an upstream report..
Finally got to it. It actually downgrades it:
https://copr.fedorainfracloud.org/coprs/thrnciar/python-platformdirs/build/5951351/
Installing:
python3-platformdirsnoarch 3.5.1-1.fc39copr_base 38 k
...
Downgrading:
python3-platformdirs noarch 2.6.0-2.fc38 fedora 42 k
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Can a Copr group be migrated to a different FAS group?
On 07. 03. 23 18:33, Miro Hrončok wrote: On 05. 03. 23 14:17, Pavel Raiskup wrote: As long as - we can keep the '@python' naming Copr-side, and Yes, that was the plan. - you have no other Copr group defined for the `python-packagers-sig` FAS group already We don't. it should be possible. Ping me off-list next week and we can test this first on stg.* and do the change. Will try to reach you tomorrow. Thanks. For the record, this has now been done. Thanks. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Can a Copr group be migrated to a different FAS group?
On 05. 03. 23 14:17, Pavel Raiskup wrote: As long as - we can keep the '@python' naming Copr-side, and Yes, that was the plan. - you have no other Copr group defined for the `python-packagers-sig` FAS group already We don't. it should be possible. Ping me off-list next week and we can test this first on stg.* and do the change. Will try to reach you tomorrow. Thanks. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RPM Sequoia crypto breaks RPM
On 10. 11. 22 14:24, Panu Matilainen wrote: On 11/10/22 15:05, Miro Hrončok wrote: Hello Panu, Copr folks, In https://copr.fedorainfracloud.org/coprs/ksurma/docutils-0.19/build/5030501/ We see: Error: Transaction test error: package python3-pytest-7.1.3-1.fc38.noarch does not verify: Header RSA signature: BAD (package tag 268: invalid OpenPGP signature) package python3-docutils-0.19-1.fc38.noarch does not verify: Header RSA signature: BAD (package tag 268: invalid OpenPGP signature) Those are packages built in the copr. Okay, AFAICS those would be https://download.copr.fedorainfracloud.org/results/ksurma/docutils-0.19/fedora-rawhide-x86_64/05025807-pytest/python3-pytest-7.1.3-1.fc38.noarch.rpm and https://download.copr.fedorainfracloud.org/results/ksurma/docutils-0.19/fedora-rawhide-x86_64/05025169-python-docutils/python3-docutils-0.19-1.fc38.noarch.rpm They are not the usual SHA1 case, both are RSA/SHA256 signed so this looks like an actual bug. Please report on bugzilla so it gets properly tracked and we have a place to direct people to. https://bugzilla.redhat.com/show_bug.cgi?id=2141686 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RPM Sequoia crypto breaks RPM
On 10. 11. 22 14:05, Miro Hrončok wrote: Hello Panu, Copr folks, In https://copr.fedorainfracloud.org/coprs/ksurma/docutils-0.19/build/5030501/ We see: Error: Transaction test error: package python3-pytest-7.1.3-1.fc38.noarch does not verify: Header RSA signature: BAD (package tag 268: invalid OpenPGP signature) package python3-docutils-0.19-1.fc38.noarch does not verify: Header RSA signature: BAD (package tag 268: invalid OpenPGP signature) Those are packages built in the copr. The subject was supposed to say: "breaks Copr" -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
RPM Sequoia crypto breaks RPM
Hello Panu, Copr folks, In https://copr.fedorainfracloud.org/coprs/ksurma/docutils-0.19/build/5030501/ We see: Error: Transaction test error: package python3-pytest-7.1.3-1.fc38.noarch does not verify: Header RSA signature: BAD (package tag 268: invalid OpenPGP signature) package python3-docutils-0.19-1.fc38.noarch does not verify: Header RSA signature: BAD (package tag 268: invalid OpenPGP signature) Those are packages built in the copr. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Outage: Upgrading the Fedora Copr backend storage, 2022-10-28 -- 2022-10-30
On 21. 10. 22 15:17, Pavel Raiskup wrote: We need to replace the volume hosting our RPM/YUM repo data with a larger one. As a consequence, we'll have to stop the build queue processing for about 20 hours, and we'll have two "full" (but short) outages (2x5 minutes) when the yum repositories will be unavailable. The anticipated start of the outage (queue stops processing) is Saturday 2022-10-29: $ date --date "2022-10-29 17:00 UTC" Sat Oct 29 07:00:00 PM CEST 2022 But a few hours before, we'll lower the build throughput a bit to prioritize the I/O we have on the data migration task.. We'd like to kindly ask you to minimize the build throughput in the Fedora Copr build service during the weekend in question — just to allow us to make the transition as smooth as possible. It would be ideal if you could e.g. delay your mass rebuilding and other large data modifications tasks until the storage movement is over. That said, we don't plan to turn the frontend machine off (API and web-UI) during the whole outage period. For more info, see the more detailed schedule: https://docs.google.com/spreadsheets/d/1URopuw2R533H6i4vSTH8Nt47EIhs3ubWcLUXvRcxTRQ/edit#gid=0 Affected services: - Copr service (frontend): https://copr.fedorainfracloud.org - Copr (backend) repositories: https://download.copr.fedorainfracloud.org/ (AWS CloudFront proxy) https://copr-be.cloud.fedoraproject.org/ (storage) Sorry for the inconvenience, Copr Team FWIW it seems the alert-danger banner at top of https://copr.fedorainfracloud.org added bootstrap css and changed (broke?) the design of the web interface slightly. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: ATTENTION: Copr will be temporarily deleting failed and outdated builds after 7 days
On 30. 09. 22 18:05, Jiri Kyjovsky wrote: Hello, Due to problems with free disk storage, Copr will be temporarily deleting failed and outdated builds after 7 days instead of the default 14 days until migration to another disk storage takes place. Hey, is there any ETA for the migration? Thanks, -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How to add a another copr repo to my copr builds
On 26. 06. 22 16:28, Barry Scott wrote: I want to build by projects against PyQt6 from copr https://copr.fedorainfracloud.org/coprs/g/kdesig/python-qt6/ What would I have to do to allow my copr build to use that repo? 1. Go to *Settings* of your copr project 2. Scroll to the bottom of *2. Build options* 3. In *External Repositories:* enter: copr://@kdesig/python-qt6 4. Profit As a side note, the @kdesig/python-qt6 repo needs a Python 3.11 rebuild. on rawhide. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Outage: Upgrade of Copr servers - 2022-06-22 12:00 UTC
On 24. 06. 22 14:14, Jakub Kadlčík wrote: Hello, for anyone interested, you can read the release notes here https://docs.pagure.org/copr.copr/release-notes/2022-06-22.html """ Better build badges in Pagure For a long time, Copr supports automatical rebuilds for pull requests in any Pagure instance. We enhanced the information that is sent back to Pagure, and show package names for each build displayed in the PR. This is especially useful for projects with multiple packages. """ Where can I see such a build badge? The description reminded me this RFE which was not implemented https://pagure.io/copr/copr/issue/1327 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Drop fedora-rawhide-armhfp config?
Fedora 37 no longer has armhfp/armv7hl compose nor Koji repo. Could you please remove the Copr chroot? I've opened https://github.com/rpm-software-management/mock/pull/867 for mock-core-configs. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: On copr.fedorainfracloud.org, is the filesystem where the package is built local?
On 07. 01. 22 1:40, Pavel Raiskup wrote: On Thursday, January 6, 2022 5:20:40 PM CET Miro Hrončok wrote: Hello Copr, just a quick question. When I build a package in Copr (the Fedora one) on x86_64, is the mock chroot located on a local filesystem, or a NFS? Local, it is tmpfs. Thanks for confirming. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On copr.fedorainfracloud.org, is the filesystem where the package is built local?
Hello Copr, just a quick question. When I build a package in Copr (the Fedora one) on x86_64, is the mock chroot located on a local filesystem, or a NFS? Thanks, -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
copr.fedorainfracloud.org down?
It seems that copr.fedorainfracloud.org is down. I don't recall any planned outages. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [EPEL-devel] Mock/Copr default epel-8-* configuration to be changed
On 22. 11. 21 15:25, Miroslav Suchý wrote: But EPEL is built against RHEL (not Alma, not Rocky). True. As well as it is true today that it is not built against CentOS Linux (and yet we do that in mock). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [EPEL-devel] Mock/Copr default epel-8-* configuration to be changed
On 22. 11. 21 15:00, Pavel Raiskup wrote: - builds will require a valid Red Hat subscription (the no-cost variant is OK as well, though [2]) I cannot help myself but I consider this very unpleasant for EPEL packagers. Getting and configuring the subscription was always so unfriendly for me that I've been using EPEL mocks even for my RHEL work. This basically means using EPEL mocks will once again be as complicated as using RHEL. However, enough of my personal views. Since we have not used RHEL for copr/mock EPEL buidlroots until now, but we used a downstream freely-available RHEL-copy (CentOS Linux), could we not continue doing so by using e.g. AlmaLinux? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Bad exit status from %prep during chmod -Rf a+rX,u+w,g-w,o-w .
On 04. 10. 21 11:49, Miro Hrončok wrote: Hello, I see this failure in dnf: https://copr.fedorainfracloud.org/coprs/churchyard/patch251/build/2872812/ Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.x8REO2 + umask 022 + cd /builddir/build/BUILD + cd /builddir/build/BUILD + rm -rf dnf-4.9.0 + /usr/bin/gzip -dc /builddir/build/SOURCES/dnf-4.9.0.tar.gz + /usr/bin/tar -xof - + STATUS=0 + '[' 0 -ne 0 ']' + cd dnf-4.9.0 + /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w . error: Bad exit status from /var/tmp/rpm-tmp.x8REO2 (%prep) Bad exit status from /var/tmp/rpm-tmp.x8REO2 (%prep) I am perplexed with the error. Could it be some problem with Copr builders? Unlikely, I've reproduced this in Koji: https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/GO3LFGR3IDOUVFRZYD4LY2D6LV252I2S/ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Bad exit status from %prep during chmod -Rf a+rX,u+w,g-w,o-w .
Hello, I see this failure in dnf: https://copr.fedorainfracloud.org/coprs/churchyard/patch251/build/2872812/ Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.x8REO2 + umask 022 + cd /builddir/build/BUILD + cd /builddir/build/BUILD + rm -rf dnf-4.9.0 + /usr/bin/gzip -dc /builddir/build/SOURCES/dnf-4.9.0.tar.gz + /usr/bin/tar -xof - + STATUS=0 + '[' 0 -ne 0 ']' + cd dnf-4.9.0 + /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w . error: Bad exit status from /var/tmp/rpm-tmp.x8REO2 (%prep) Bad exit status from /var/tmp/rpm-tmp.x8REO2 (%prep) I am perplexed with the error. Could it be some problem with Copr builders? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Excluding older builds of packages from Fedora when testing new ones in Copr
On 09. 07. 21 11:30, Pavel Raiskup wrote:
On Friday, July 9, 2021 10:19:57 AM CEST Miro Hrončok wrote:
On 09. 07. 21 9:46, Pavel Raiskup wrote:
This is pre-production experiment, right? Couldn't you just specify
"Provides: python3dist(click) = 7.9"?
It is, but it would not help me. By manually providing this, I would:
- confuse %pyproject_buildrequires generator -- Python would think 'click <
8' is not satisfied, by RPM/dnf would insist it is.
- still not get a root.log resolution failure I want
- still not "satisfy" packages that BR "python3click" instead of
"python3dist(click)"
I wonder if adding Obsoletes: python3-click < %{version} helps, but I don't
think so.
We have an RFEhttps://pagure.io/copr/copr/issue/1336 that could help you if you
could specify dnf.conf excludepkgs= option for the rawhide repo. But this is
not an easy one.
Yes, this would work.
Another idea...
What if you had a syntetic package, say "click-blocker", with 'Conflicts:
python3-click < XYZ'? That package could be added as always-installed package
into "Packages" field (chroot Edit form).
Or maybe it could simply require 'python3-click >= XYZ', too?
Is "Packages" always-installed or initially-installed? What prevents dnf to
downgrade it?
I'll test this approach thou, seems reasonable.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Excluding older builds of packages from Fedora when testing new ones in Copr
On 09. 07. 21 9:46, Pavel Raiskup wrote:
This is pre-production experiment, right? Couldn't you just specify
"Provides: python3dist(click) = 7.9"?
It is, but it would not help me. By manually providing this, I would:
- confuse %pyproject_buildrequires generator -- Python would think 'click <
8' is not satisfied, by RPM/dnf would insist it is.
- still not get a root.log resolution failure I want
- still not "satisfy" packages that BR "python3click" instead of
"python3dist(click)"
I wonder if adding Obsoletes: python3-click < %{version} helps, but I don't
think so.
We have an RFEhttps://pagure.io/copr/copr/issue/1336 that could help you if you
could specify dnf.conf excludepkgs= option for the rawhide repo. But this is
not an easy one.
Yes, this would work.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Excluding older builds of packages from Fedora when testing new ones in Copr
Hello Copr users and developers.
When we update packages in Fedora, we regularly use Copr to test the impact of
the upgrade.
For me, the procedure usually goes like this:
1) create a new copr with Fedora rawhide x86_64 chroot (and added Koji repo)
$ copr create $COPR
--repo='http://kojipkgs.fedoraproject.org/repos/rawhide/latest/$basearch/'
--chroot fedora-rawhide-x86_64 --delete-after-days 30
2) define and build the updated package in the copr
$ copr add-package-distgit $COPR --name $PKG --webhook-rebuild on --commit
$BRANCH --namespace forks/$(whoami)
$ copr build-package $COPR --name $PKG
3) get the list of dependent packages
$ repoquery -q --repo=rawhide{,-source} [--whatrequires $spkg for each
subpackage] --recursive | grep src$ | pkgname
4) define and build the depended packages in the copr
$ parallel copr add-package-distgit $COPR --webhook-rebuild on --commit
rawhide --name -- $(repoquery from above ...)
$ parallel copr build-package $COPR --nowait --background --name --
$(repoquery from above ...)
5) analyze build failures, do a "control" rebuild in another copr if needed
However, this procedure has a flaw. Let's say I'm working on upgrading
python-click from 7.x to 8.x. And let's say a package (even transitively)
BuildRequires:
python3dist(click) < 8
The way that dnf dependency resolution works, that package will be built with
Rawhide's python3-click 7.x and it will be marked as successful. However, I'd
like to see a failure here to be notified that such package cannot be build and
will be negatively impacted by the update.
Is there a way to solve this? I have couple ideas, but none of them is fully
working:
A) Compose my own repo with the updated package and Rawhide content without it,
use that repo in the copr.
Pros:
- this is similar to what will happen in Koji once the package is updated
Cons:
- this requires tooling that I don't think exists
- this requires a place to put that repo to
- the repo creation could take a lot of time and would need to be repeated
on-demand each time rawhide changes
- Copr's Fedora chroots always include Fedora repos (maybe I can use
custom-1-x86_64 chroot?)
B) Create a Fedora side tag, explicitly block the package from it, use that
side tag's Koji repo.
Pros:
- same as (A)
Cons:
- I don't think on-demand side tags allow users to block packages
- Copr's Fedora chroots always include Fedora repos (same as (A))
- this wastes Koji's resources a bit
- requires waiting for the initial Koji regen-repo
C) Block (exclude) python3-click < 8 from the chroot.
Pros:
- no custom repos required
- no resources overhead
- no time overhead
Cons:
- There is no way exclude packages in chroot settings. Mock settings possibly
allow me to do this in config_opts['dnf.conf'].
- The exclude could obfuscate root.log resolution problems logs.
- Packager needs to figure out what exactly to exclude (possibly need to
exclude all subpackage's NEVRAs from rawhide compose (and Koji buildroot if
they differ))
Is there another way? If not, I think (C) is easiest to actually implement, if
the chroot settings page in copr gains an "excludes" option.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Best practices for mass rebuilds in Copr
On 03. 03. 21 20:18, Jakub Kadlčík wrote: Hello, we observe more and more people using Copr for rebuilding large amounts of packages from some third-party repositories. We have projects providing all python packages, R packages, we have projects providing all Fedora packages rebuilt with some proposal change, etc. These are all valid use-cases and Copr should be able to sustain such loads (even though we still have some bottlenecks to get rid of). To make the mass-rebuilding experience better for new users, we put together a short list of best practices. https://docs.pagure.org/copr.copr/user_documentation.html#mass-rebuilds If you think that some useful tip is missing, let us know. I'd add: If possible, use the --background flag when building large amount of packages. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Failing ELN jobs due to broken GPG signatures
On 15. 02. 21 15:22, Frantisek Sumsal wrote: Hello, I noticed that for the past couple of days all our builds in fedora-eln-* chroots have been failing due to GPG-related issues: warning: /var/lib/mock/fedora-eln-x86_64-bootstrap-1613383811.551938/root/var/cache/dnf/eln-78c0f68aeb10b59c/packages/alternatives-1.15-2.eln109.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 45719a39: NOKEY Fedora - ELN - Developmental packages for the n 1.6 MB/s | 1.6 kB 00:00 GPG key at file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary (0x9867C58F) is already installed The GPG keys listed for the "Fedora - ELN - Developmental packages for the next Enterprise Linux release" repository are already installed but they are not correct for this package. Check that the correct key URLs are configured for this repository.. Failing package is: alternatives-1.15-2.eln109.x86_64 GPG Keys are configured as: file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary Public key for audit-libs-3.0-2.eln109.x86_64.rpm is not installed. Failing package is: audit-libs-3.0-2.eln109.x86_64 GPG Keys are configured as: file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary ... See: - https://copr.fedorainfracloud.org/coprs/packit/systemd-systemd-18596/build/1966540/ - https://copr.fedorainfracloud.org/coprs/packit/systemd-systemd-18600/build/1966703/ According to https://pagure.io/releng/issue/10007 this should already be fixed, but the reality begs to differ. Is there anything else I need to do on our side or there's still some underlying unresolved issue? I believe this requires a successful ELN compose to propagate to Copr chroots. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Order of External Repositories matters?
On 11. 02. 21 16:35, Miro Hrončok wrote: I've been surprised by a behavior of External Repositories. I've done two builds of python-six in this copr: https://copr.fedorainfracloud.org/coprs/churchyard/tmp/ First with: External Repositories: copr://@python/python3.10 http://kojipkgs.fedoraproject.org/repos/rawhide/latest/$basearch/ And the second with: External Repositories: http://kojipkgs.fedoraproject.org/repos/rawhide/latest/$basearch/ copr://@python/python3.10 The results suprised me ... Does the order of external repos defines their priority/cost? Is that a feature or a bug? I guess this has to do with either mock or dnf directly: $ mock -r fedora-rawhide-x86_64 -a 'https://copr-be.cloud.fedoraproject.org/results/@python/python3.10/fedora-rawhide-$basearch/' -a 'http://kojipkgs.fedoraproject.org/repos/rawhide/latest/$basearch/' install python3-setuptools $ mock -r fedora-rawhide-x86_64 -a 'http://kojipkgs.fedoraproject.org/repos/rawhide/latest/$basearch/' -a 'https://copr-be.cloud.fedoraproject.org/results/@python/python3.10/fedora-rawhide-$basearch/' install python3-setuptools They install python3-setuptools from the first -a REPO. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Order of External Repositories matters?
I've been surprised by a behavior of External Repositories. I've done two builds of python-six in this copr: https://copr.fedorainfracloud.org/coprs/churchyard/tmp/ First with: External Repositories: copr://@python/python3.10 http://kojipkgs.fedoraproject.org/repos/rawhide/latest/$basearch/ And the second with: External Repositories: http://kojipkgs.fedoraproject.org/repos/rawhide/latest/$basearch/ copr://@python/python3.10 The results suprised me. The first build installs python 3.9 from koji in the bootstrap chroot and successfully bootstraps only with packages from koji. Then it creates the default chroot with packages mostly from koji but python-srpm-macros from @python/python3.10 (higher version). The installation of buildrequires fails with: Error: Problem 1: package python3-pip-21.0-1.fc34.noarch requires python(abi) = 3.9, but none of the providers can be installed - package python3-devel-3.10.0~a5-1.fc34.x86_64 conflicts with python3 < 3.10.0~a5-1.fc34 provided by python3-3.9.1-5.fc34.x86_64 - package python3-devel-3.10.0~a5-1.fc34.x86_64 conflicts with python3 < 3.10.0~a5-1.fc34 provided by python3-3.9.1-5.fc34.i686 - cannot install the best candidate for the job Problem 2: python3-3.9.1-5.fc34.i686 has inferior architecture - package python3-wheel-1:0.36.2-2.fc34.noarch requires python(abi) = 3.9, but none of the providers can be installed - cannot install both python3-3.10.0~a5-1.fc34.x86_64 and python3-3.9.1-5.fc34.x86_64 - cannot install both python3-3.9.1-5.fc34.x86_64 and python3-3.10.0~a5-1.fc34.x86_64 - package python3-tkinter-3.10.0~a5-1.fc34.x86_64 requires python3 = 3.10.0~a5-1.fc34, but none of the providers can be installed - cannot install the best candidate for the job The second build installs python 3.10 from @python/python3.10 in the bootstrap chroot and successfully bootstraps with packages from koji + Python packages from @python/python3.10. Then it creates the default chroot with packages from koji + Python packages from @python/python3.10. Then it successfully installs Python 3.10 with other buildrequires. Does the order of external repos defines their priority/cost? Is that a feature or a bug? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: %{python3} no defined in epel-7-aarch64?
On 04. 01. 21 18:38, José Abílio Matos wrote:
I have used copr to build the first alpha release of lyx-2.4:
https://copr.fedorainfracloud.org/coprs/jamatos/lyx-devel/build/1858028/
<https://copr.fedorainfracloud.org/coprs/jamatos/lyx-devel/build/1858028/>
For EPEL7 it build for x86_64 and it fails for aarch64, due to %{python3} not
being defined.
The spec file has BR: python3-devel.
In the install stage I have this:
%py_byte_compile %{python3} %{buildroot}%{_datadir}/%{name}/lyx2lyx
This fails in epel-7-aarch64...
Is this known?
Yes. The macro was added to EPEL 7 only after aarch64 was discontinued there:
https://lists.fedoraproject.org/archives/list/epel-annou...@lists.fedoraproject.org/thread/YVLZGTBBW2M3GMXHLIA2QMKENBEGPEJY/
No easy way to solve this except to stop building for aarch64 on EPEL 7. You
could use the %__python3 macro instead to workaround this particular problem,
but you will most likely hit another one later.
I wonder whether Copr should disable EPEL 7 aarch64 chroots or at least put a
big red sign next to them.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Highlights from the latest Copr release
On 11/13/20 5:25 PM, Pavel Raiskup wrote: Hello! On Nov 13 2020, a new Copr release landed production. The list of user visible changes is in the release notes document: https://docs.pagure.org/copr.copr/release-notes/2020-11-13.html Happy building! Indeed it is happy. I've just finally got to trying out the batch thing. $ copr build-package --nowait @python/python3.10 --name python-pytest-relaxed --after-build-id 1776391 Build was added to python3.10. Created builds: 1776396 $ copr build-package --nowait @python/python3.10 --name python-invoke --after-build-id 1776396 Build was added to python3.10. Created builds: 1776397 $ copr build-package --nowait @python/python3.10 --name python-paramiko --after-build-id 1776397 Build was added to python3.10. Created builds: 1776398 $ copr build-package --nowait @python/python3.10 --name ansible --after-build-id 1776398 Build was added to python3.10. Created builds: 1776399 This is awesome! One small suggestion: The pending builds are not visibly marked as waiting for another build (or at least I have not find the information in the web UI). That might be confusing for others when multiple people work on one copr project. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: 100+ jobs importing, some for 5+ hours
On 11/19/20 9:56 PM, Pavel Raiskup wrote: On Thursday, November 19, 2020 9:19:15 PM CET Miro Hrončok wrote: Hello. Is there some copr outage in progress? There are (close to) 0 running or pending builds, but 100+ builds are being imported: https://copr.fedorainfracloud.org/status/importing/ Some of them for many hours. Thank you for reporting this! We got async report also on IRC in the meantime. The problem was that copr-dist-git went out of storage. I enlarged the volume, and restarted the service. Thanks! -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
100+ jobs importing, some for 5+ hours
Hello. Is there some copr outage in progress? There are (close to) 0 running or pending builds, but 100+ builds are being imported: https://copr.fedorainfracloud.org/status/importing/ Some of them for many hours. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Highlights from the latest Copr release
On 11/13/20 6:32 PM, Pavel Raiskup wrote: On Friday, November 13, 2020 6:30:48 PM CET Miro Hrončok wrote: On 11/13/20 6:24 PM, Pavel Raiskup wrote: $ copr edit-package-distgit --name ... Indeed, thanks. I needed: https://bodhi.fedoraproject.org/updates/FEDORA-2020-b9d29463b5 Does the Auto-rebuild option of such packages still include src.fp.o pull requests? Yes, it should. Awesome. Thanks, Pavel! -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Highlights from the latest Copr release
On 11/13/20 6:24 PM, Pavel Raiskup wrote:
On Friday, November 13, 2020 6:06:49 PM CET Miro Hrončok wrote:
On 11/13/20 5:25 PM, Pavel Raiskup wrote:
Hello!
On Nov 13 2020, a new Copr release landed production. The list of user visible
changes is in the release notes document:
https://docs.pagure.org/copr.copr/release-notes/2020-11-13.html
Dist-Git packages \o/
Is there a way to edit the packages to use this via CLI?
E.g. when we added packages like this:
copr add-package-scm --clone-url https://src.fedoraproject.org/rpms/${pkg}.git
--name $pkg --webhook-rebuild on --commit master ${copr}
How can I run copr edit-package-... or some other command to convert such
packages to fedora dist-git packages?
The 'edit-package-*' pattern should just work:
$ copr edit-package-distgit --name ...
Indeed, thanks. I needed:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-b9d29463b5
Does the Auto-rebuild option of such packages still include src.fp.o pull
requests?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Highlights from the latest Copr release
On 11/13/20 5:25 PM, Pavel Raiskup wrote:
Hello!
On Nov 13 2020, a new Copr release landed production. The list of user visible
changes is in the release notes document:
https://docs.pagure.org/copr.copr/release-notes/2020-11-13.html
Dist-Git packages \o/
Is there a way to edit the packages to use this via CLI?
E.g. when we added packages like this:
copr add-package-scm --clone-url https://src.fedoraproject.org/rpms/${pkg}.git
--name $pkg --webhook-rebuild on --commit master ${copr}
How can I run copr edit-package-... or some other command to convert such
packages to fedora dist-git packages?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Building sagemath in copr: SRPM fails with No space left on device
On 11/1/20 11:13 PM, Pavel Raiskup wrote: On Sunday, November 1, 2020 12:18:55 AM CET Miro Hrončok wrote: Hello. I am trying to build sagemath from dist git in Copr. https://copr.fedorainfracloud.org/coprs/churchyard/parso-0.8/build/1730316/ https://copr.fedorainfracloud.org/coprs/churchyard/parso-0.8/build/1733717/ I get this when the SRPM is created: RPM build errors: stderr: error: create archive failed on file /tmp/copr-rpmbuild-2o1bpkg6/sage-9.1.tar.gz: cpio: write failed - No space left on device create archive failed on file /tmp/copr-rpmbuild-2o1bpkg6/sage-9.1.tar.gz: cpio: write failed - No space left on device Failed to execute command. Is it too big for copr or can the space be allocated somehow? Dunno, there should be ~8GB free space in /tmp by default. How big is the tarball (or srpm) supposed to be? The SRPM in Koji is ~2GB. $ df -h /tmp/ Filesystem Size Used Avail Use% Mounted on tmpfs 7.5G 124M 7.4G 2% /tmp Perhaps we still don't clean some storage in /tmp for recycled builders? That was my thought as well. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Building sagemath in copr: SRPM fails with No space left on device
Hello. I am trying to build sagemath from dist git in Copr. https://copr.fedorainfracloud.org/coprs/churchyard/parso-0.8/build/1730316/ https://copr.fedorainfracloud.org/coprs/churchyard/parso-0.8/build/1733717/ I get this when the SRPM is created: RPM build errors: stderr: error: create archive failed on file /tmp/copr-rpmbuild-2o1bpkg6/sage-9.1.tar.gz: cpio: write failed - No space left on device create archive failed on file /tmp/copr-rpmbuild-2o1bpkg6/sage-9.1.tar.gz: cpio: write failed - No space left on device Failed to execute command. Is it too big for copr or can the space be allocated somehow? Thanks, -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Highlights from the latest Copr release
On 12. 08. 20 11:19, Iñaki Ucar wrote:
- Copr newly provides a build-time macro %buildtag. Its format is
`.copr` and is useable for auto-incrementing the package's NVR
in subsequent builds. It may be used in spec file like:
Release: 1%{?dist}%{?buildtag}
It could be useful as good-enough alternative for the Release
auto-bumping proposal. See the fedora devel discussion [2] for more
info. This is not any kind of encouragement to use it. We added it
there to easy testing your ideas about the automatic filling of the
Release tag.
Nice one! I understand that having a mix of builds with and without
this tag isn't an issue, right? I.e., would
--.copr.fcXX be picked as an update of
--.fcXX? Or do we need to rebuild all with the
new tag and remove the old ones?
It's actually --.fcXX.copr in the example above. An
that sorts higher.
$ rpmdev-vercmp e:v-r.fc34.copr1234567 e:v-r.fc34
e:v-r.fc34.copr1234567 > e:v-r.fc34
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Highlights from the latest Copr release
On 12. 08. 20 11:20, Pavel Raiskup wrote:
- Copr newly provides a build-time macro %buildtag. Its format is
`.copr` and is useable for auto-incrementing the package's NVR
in subsequent builds. It may be used in spec file like:
Release: 1%{?dist}%{?buildtag}
It could be useful as good-enough alternative for the Release
auto-bumping proposal. See the fedora devel discussion [2] for more
info. This is not any kind of encouragement to use it. We added it
there to easy testing your ideas about the automatic filling of the
Release tag.
This is really interesting feature for some of the projects.
Can this be used in official Fedora specfiles
It is meant to be no-op as long as build system doesn't define it. So at
least technically there's no problem.
or does it need a guideline?
I don't think it is forbidden by guidelines (we can not use macros for
other distributions, but that is a different topic). Dunno if we need to
have an explicit ACK for this. Ideas?
Most likely we don't. I was just trying to think ahead.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Highlights from the latest Copr release
On 12. 08. 20 10:29, Pavel Raiskup wrote:
Hello.
On Aug 12 2020, a new Copr release landed production. Here is the list
of visible changes:
- Project karma implemented; Logged-in users can give
thumbs-up/thumbs-down to the existing copr projects. This is just
another way to give feedback about a particular Copr project quality.
This is merely subjective. We do not give you guidance what "thumbs
up/down" means. When it is good for you - for whatever reason - give it
thumbs up. It may be just feedback for the maintainer or other users.
Or we may automatically select and group high-quality projects in the
future - and e.g. revive the idea of the Playground [1]. The options
are open. We would like to hear your feedback about this feature!
Assuming the arrows up and down near the copr name are for karma, I find the UI
for this is a tad confusing. I've seen it before reading your announcement and
had no idea what it is.
(This is true especially before refreshing the browser cache, it gets a bit
better after.)
- Copr newly provides a build-time macro %buildtag. Its format is
`.copr` and is useable for auto-incrementing the package's NVR
in subsequent builds. It may be used in spec file like:
Release: 1%{?dist}%{?buildtag}
It could be useful as good-enough alternative for the Release
auto-bumping proposal. See the fedora devel discussion [2] for more
info. This is not any kind of encouragement to use it. We added it
there to easy testing your ideas about the automatic filling of the
Release tag.
This is really interesting feature for some of the projects.
Can this be used in official Fedora specfiles or does it need a guideline?
- Command-line interface for the project package listing was significantly
optimized, and should now be faster than the web-UI on large projects
(issue/757).
Thanks, I'll test it instead of my "parse-HTML-by-regex" mad script :)
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Minor Copr release 2020-06-19
On 20. 06. 20 0:29, Pavel Raiskup wrote: 2. Newly, we don't always run createrepo_c after each build (or delete request). Iff there are a concurrent createrepo_c requests on the same directory (multiple builds finished at a similar time in the same project chroot) we will likely group them into a batch and execute the createrepo_c only once for the whole batch. This saves some resources in general, but the major speedup will be in large projects (where createrepo_c used to block us historically). Thank you so much for this. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Koji side tag as external repo?
On 15. 06. 20 10:10, Iñaki Ucar wrote: * If there's too much traffic and it causes problems, external repo users may get blocked.;) Noted. I need to rebuild 14k packages for R 4.0. I hope I'm not causing trouble. We have used the f33-python repo in the Python 3.9 copr when the side tag was "open". That was for about 5000 builds I guess. It was not blocked. We also generally use the "Koji repo" for rawhide (served from the same location) with posibly hundreds thousand builds, where other people use that in Copr as well. I guess the main thing that helps is that Copr itself only runs a small integer of such builds at the same time. To avoid this for the use case I'm describing, Copr could have a "create repo from koji tag" button that simply downloads the artifacts from Koji and publishes a repo with those builds. That only makes sense if the repo is not changing any more, right? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Koji side tag as external repo?
On 14. 06. 20 13:56, Iñaki Ucar wrote: Hi, Is there any way to expose a Koji side tag as an external repo for Copr? This would be useful to start a rebuild for rawhide before the side tag is merged without having to set up a temporary Copr repo just to rebuild that side tag. Yes, for example: https://kojipkgs.fedoraproject.org/repos/f33-boost/latest/$basearch -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Highlights from the latest Copr release 2020-06-10
On 10. 06. 20 21:41, Pavel Raiskup wrote: Hello! On Jun 10, 2020, a new Copr release landed production. Thank You! Here is the list of visible changes, and new features: - Increased build task throughput. The VM spawner is more flexible now. First, we don't allocate that many workers if they are not actually needed, but more importantly the upper limit for concurrently running workers has risen to 140 (including all architectures), previously we had ~70. We'll see how things go from the backend perspective, but it is expected that we'll go even higher (waiting for a new HW in the new Fedora lab, cheaper VM instances in the future, etc.). So the numbers will likely change; this is to make clear the current state of things. Happy to see this in action. - Copr project "runtime" dependencies were implemented. Newly you can specify set of repositories your project depends on. Such repositories will be installed together with the copr project repo file (e.g., by 'dnf copr enable YOU/YOUR_PROEJCT'). Those repositories can be other project in Copr or some 3rd party repository. This is very similar to build-time dependencies implemented long time ago. Take a look at blog post: https://fedora-copr.github.io/posts/runtime-dependencies This sounds really interesting and helpful. Thanks. - There's now more fair build scheduler. Previously, no matter whether the "background" attribute was set or not for the build - once builder was allocated for a concrete copr user - copr never terminated the builder as long as the user kept filling the build queue with new tasks (and it blocked the quota for others). Newly, there's a limit of at most eight consecutive builds or 30 minutes for one user (sandbox) on one builder and the builder is immediately terminated - which gives a chance to assign new builders to others' tasks (which have a higher priority at that point). I've been personalyl affected by the old behavior, happy to see this. - Copr-cli supports batch build delete feature: $ copr-cli delete build_id [build_id ...] Please use this instead of requesting removal of each build_id separately - it will be much faster because you will save the copr backend useless createrepo_c runs after each request. Yet again, \o/ - Cancel build feature was fixed, and the "cancel" request should reliably release all occupied builder machines (allowing them to be re-used, or terminated). Awesome as well. Thanks for this release. I've also seen some UX changes wehn viewing builds, the builder-live.log.gz is now 1 click closer. This seems slow, but in bulk, is really awesome. Keep up the good work. I am so glad we have such innovations! -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Highlights from the latest Copr release
On 20. 01. 20 10:15, Tomas Hrnciar wrote: Hello, recently (on Jan 16, 2020) a new Copr release landed production. Here is the list of visible changes: - We contributed to createrepo_c to speed up Copr for building large projects. Building large projects should be significantly faster. Thanks for this. It indeed feels faster! -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: What does "Rebuild all" do with SCM packages?
On 15. 01. 20 17:08, Pavel Raiskup wrote: On Wednesday, January 15, 2020 10:17:02 AM CET Miro Hrončok wrote: Hello. I have noticed the "Rebuild all" button on packages page. Does "Rebuild all" pull from committish with SCM packages, or does it rebuilt the latest SRPM? It builds from the default source definition, so committish (when defined). Awesome, thanks. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
What does "Rebuild all" do with SCM packages?
Hello. I have noticed the "Rebuild all" button on packages page. Does "Rebuild all" pull from committish with SCM packages, or does it rebuilt the latest SRPM? Thanks, -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: I might have just broken copr
On 19. 12. 19 11:21, Miro Hrončok wrote: I have submitted couple hundreds scm packages + their builds to https://copr.fedorainfracloud.org/coprs/churchyard/pytest-4/ Since then, it has been error 504, later 503. Have I broken it? It works again. Submitting more packages. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
I might have just broken copr
I have submitted couple hundreds scm packages + their builds to https://copr.fedorainfracloud.org/coprs/churchyard/pytest-4/ Since then, it has been error 504, later 503. Have I broken it? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Failed builds for no apparent reasons
On 18. 06. 19 10:09, Pavel Raiskup wrote: On Tuesday, June 18, 2019 10:07:19 AM CEST Miro Hrončok wrote: On 18. 06. 19 9:43, Pavel Raiskup wrote: On Tuesday, June 18, 2019 12:05:58 AM CEST Miro Hrončok wrote: Hey, I have coupe dozens (or hundreds?) builds like this: https://copr.fedorainfracloud.org/coprs/g/python/python3.8/build/936777/ Any idea what went wrong? Thanks for the report. Long story short, there were IO problems on copr-dist-git machine. Sorry for inconvenience. Longer sum up: This was caused by rsync started yesterday to move the dist-git data to new storage. We have one script (related to cgit, /var/lib/copr-dist-git/cgit_pkg_list) which is suffering from IO performance for some time, but it was not noticeable before (rsync made the problems visible). Plus there's https://pagure.io/copr/copr/issue/807 which multiplies those two above. Thanks. From the past tense I assume this has been fixed? I disabled the cgit_pkg_list for now, so yes. Please report a bug if you see the same problem again. Thank you! -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Failed builds for no apparent reasons
On 18. 06. 19 9:43, Pavel Raiskup wrote: On Tuesday, June 18, 2019 12:05:58 AM CEST Miro Hrončok wrote: Hey, I have coupe dozens (or hundreds?) builds like this: https://copr.fedorainfracloud.org/coprs/g/python/python3.8/build/936777/ Any idea what went wrong? Thanks for the report. Long story short, there were IO problems on copr-dist-git machine. Sorry for inconvenience. Longer sum up: This was caused by rsync started yesterday to move the dist-git data to new storage. We have one script (related to cgit, /var/lib/copr-dist-git/cgit_pkg_list) which is suffering from IO performance for some time, but it was not noticeable before (rsync made the problems visible). Plus there's https://pagure.io/copr/copr/issue/807 which multiplies those two above. Thanks. From the past tense I assume this has been fixed? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Failed builds for no apparent reasons
Hey, I have coupe dozens (or hundreds?) builds like this: https://copr.fedorainfracloud.org/coprs/g/python/python3.8/build/936777/ Any idea what went wrong? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
stderr: /bin/bash: UsernameToken: command not found
I just got this weird failure when building SRPM: https://copr.fedorainfracloud.org/coprs/g/python/python3.8/build/934036/ https://copr-be.cloud.fedoraproject.org/results/@python/python3.8/srpm-builds/00934036/builder-live.log Running: rpkg srpm --outdir /var/lib/copr-rpmbuild/resultseqe87l75 --spec /tmp/tmpksx72x08/python-suds cmd: ['rpkg', 'srpm', '--outdir', '/var/lib/copr-rpmbuild/resultseqe87l75', '--spec', '/tmp/tmpksx72x08/python-suds'] cwd: /tmp/tmpksx72x08/python-suds rc: 0 stdout: Downloading 94664ddd46a6.tar.bz2 from lookaside cache at src.fedoraproject.org stderr: /bin/bash: UsernameToken: command not found UsernameToken failed with value 127 Output: [] -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
FileNotFoundError: [Errno 2] No usable temporary directory found in ['/tmp', '/var/tmp', '/usr/tmp', '/home/mockbuilder']
I get failures in SRPM builds: FileNotFoundError: [Errno 2] No usable temporary directory found in ['/tmp', '/var/tmp', '/usr/tmp', '/home/mockbuilder'] -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Is it possible to add extra contributors to a group copr
It seem that individuals can requests permissions in individual coprs, but not in group coprs. Is that correct? I for example don't see the settings tab at @copr/copr (group) but I see it at packit/packit-service-packit-359 (individual). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Automatic rawhide rebuilds vs. src.fp.o Pull Requests
On 28. 05. 19 6:11, Pavel Raiskup wrote: On Monday, May 27, 2019 5:42:01 PM CEST Miro Hrončok wrote: It seems that the package is not available in the copr repo. It is not in the main copr repo (directory), but in separate one (dedicated to a concrete PR). It seems to me that the directories are all called :pr:. What happens when 2 or more PRs to different repos have the same number? https://copr.fedorainfracloud.org/coprs/g/python/python3.8/builds/?dirname=python3.8:pr:5 Does the second build "see" the previous one? It seems that namesapcing by package name is missing. Is that a bug or an intentionally made decision? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Automatic rawhide rebuilds vs. src.fp.o Pull Requests
On 28. 05. 19 6:11, Pavel Raiskup wrote: On Monday, May 27, 2019 5:42:01 PM CEST Miro Hrončok wrote: It seems that the package is not available in the copr repo. It is not in the main copr repo (directory), but in separate one (dedicated to a concrete PR). Could you help me understand this feature? It was designed so you can 'dnf copr enable /:pr:' instead. It's though not something people should trust automatically.. Can anyone build anything in my copr via this feature, but for obvious reasons, the builds are not added to the repo? Right, anyone who is able to submit PR is able to build within your project, though in separate directory so the production repo isn't affected. Thanks. I think I understand this now. I'm glad this is not "poisoning" the repository. Either way however, I'm afraid of quota issues (for the record, I've just added ~2700 such integrations). Is there a way to opt-out? (I'm also curious about the UX of the builds page once there are hundreds of PRs.) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Automatic rawhide rebuilds vs. src.fp.o Pull Requests
I have several copr setup to automatically rebuild rawhide packages in various buildroots. The source of the package is set to: https://src.fedoraproject.org/rpms/.git And committish is set to master. Yet when I made Pull Request on src.fp.o, Copr built that package. On the builds tab, I see that Copr understands what a PR is, as it lists it separately as a special "directory". See ":pr:11" at https://copr.fedorainfracloud.org/coprs/g/python/pypy36/builds/ It seems that the package is not available in the copr repo. Could you help me understand this feature? Can anyone build anything in my copr via this feature, but for obvious reasons, the builds are not added to the repo? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
API feedback: It's faster to grep HTML
Hi, For each package in a Copr, I want to get: * latest build ID (doesn't matter if latest successful or latest any) * that build status To get it I can either use this: copr list-packages --with-latest-succeeded-build Or parse the HTML returned from the Monitor page. Here's my feedback: The API option should be faster. It isn't. For a copr with only 24 builds, the JSON option takes 29 seconds, the HTML option takes 1 second. For a copr with 10k+ builds, the JSON option takes longer than I was willing to wait, the HTML option takes 6 seconds. If getting the information I need by parsing HTML is more pleasant than getting it via the API, something is wrong with the API. Not sure if this is severe enough to file a bug report, but please consider this feedback in your future API design decisions. Thank you, -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
builder-live.log: Can we get Content-Type: text/plain; charset=utf-8?
It happens to me often that my browser displays the builder-live.log like this: /usr/include/bits/string_fortified.h:106:10: warning: ‘__builtin_strncpy’ specified bound depends on the length of the source argument [-Wstringop-overflow=] When in fact it should be: /usr/include/bits/string_fortified.h:106:10: warning: ‘__builtin_strncpy’ specified bound depends on the length of the source argument [-Wstringop-overflow=] I believe this is a text encoding problem. Both Firefox and Chromium read it as Windows 1252 and not UTF-8. The headers sent by the web server are: Content-Type: text/plain I wonder whether it can be changed to: Content-Type: text/plain; charset=utf-8 Thanks, -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
copr-dist-git.fedorainfracloud.org down?
I have some trouble with copr dist git: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/copr_rpmbuild/providers/scm.py", line 145, in clone_and_checkout helpers.run_cmd(clone_cmd) File "/usr/lib/python3.6/site-packages/copr_rpmbuild/helpers.py", line 79, in run_cmd raise RuntimeError(result.stderr) RuntimeError: Cloning into '/tmp/tmp2o0qogr2/dnf'... fatal: repository 'https://copr-dist-git.fedorainfracloud.org/git/@python/python3.8/dnf.git/' not found https://copr.fedorainfracloud.org/coprs/g/python/python3.8/build/906973/ I cannot accesss the address either. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Why is copr downloading the sources from the Source URL?
I found this in several builder-live.logs: Start: rpmbuild -bs warning: Downloading http://downloads.tryton.org/4.0/trytond-analytic-account-4.0.1.tar.gz to /builddir/build/SOURCES/trytond-analytic-account-4.0.1.tar.gz curl: (6) Could not resolve host: downloads.tryton.org error: Couldn't download http://downloads.tryton.org/4.0/trytond-analytic-account-4.0.1.tar.gz https://copr.fedorainfracloud.org/coprs/g/python/python3.8/build/899299/ Several other tryton packages in https://copr.fedorainfracloud.org/coprs/g/python/python3.8/builds/ have the same problem. Their sources indeed 404. Is Copr downloading sources a known thing? I upload SRPMS. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Resubmit via CLI or Python API
Hey again. I like to resubmit a failed build via command line. I didn't find this option in copr --help or in https://python-copr.readthedocs.io I'd like to avoid reuploading the SRPM. In the web frontend, I just navigate to a failed build, click Resubmit - "Resubmitting a build will rebuild the same sources again." -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Determine root.log vs build.log failures
Hey! Koji is always very nice and it tells me whether a build failure was caused by root.log or build.log. See for example: https://koji.fedoraproject.org/koji/taskinfo?taskID=28963878 BuildError: error building package (arch x86_64), mock exited with status 1; see build.log for more information Is Copr presenting this kind of information somewhere? (I need to fetch it for hundreds of builds.) I could probably HTTP HEAD the build.log and check Content-Length to guess a root.log failure, but it feels weird... Thanks for tips. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Forked project
On 10. 04. 19 12:38, Antonio Trande wrote: Hi all. This [1] is a forked project of python3.8 [2]; inside there are all forked packages previously built but, if i require a new build for testing Python 3.8, are not used the packages from the project [3] (i see Python 3.7.3 as dependency). What am I doing wrong? Maybe it takes time before the repo is properly generated? As a workaround, you can (instead of forking or additionally to forking) add the original Copr repo as "external repository" in project settings. https://copr-be.cloud.fedoraproject.org/results/@python/python3.8/fedora-rawhide-$basearch/ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Build is pending but not listed in pending queue
On 02. 04. 19 19:52, Miro Hrončok wrote: Hi. My build has been pending for hours: https://copr.fedorainfracloud.org/coprs/g/python/python3.8/build/876568/ But it is not listed in https://copr.fedorainfracloud.org/status/pending/ I've tried to add another build, it is again pending and again not listed. Is something broken? It started. No idea what happened. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Build is pending but not listed in pending queue
Hi. My build has been pending for hours: https://copr.fedorainfracloud.org/coprs/g/python/python3.8/build/876568/ But it is not listed in https://copr.fedorainfracloud.org/status/pending/ I've tried to add another build, it is again pending and again not listed. Is something broken? Thanks. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
IOError: Failed to write to /tmp/numpy_test_big_arrays....npy: [Errno 28] No space left on device
I just got this error in Copr. Should I skip big_arrays tests, or is this some quota on /tmp that can be enlarged? Thanks. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Mock root cache - is there some? can I clean it?
On 21. 03. 19 7:50, Miro Hrončok wrote: Does copr cache mock roots? Can I clean the cache somehow? New gdb build from Fedora requires Python 3.7, but I had 3.8 in the buildroot. I've deleted my 3.8 builds, so i can rebuild gdb --without python, but apparently Python 3.8 stays in the buildroot and I get --allowerasing errors when I try to build anything. I think I found a workaround: - rebuild gdb --without python in another copr - add that copr as external repo - continue as usual However I'd still like to know if I forget to delete something, or if there's indeed a root cache that is not invalidated when I delete builds. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Mock root cache - is there some? can I clean it?
Does copr cache mock roots? Can I clean the cache somehow? New gdb build from Fedora requires Python 3.7, but I had 3.8 in the buildroot. I've deleted my 3.8 builds, so i can rebuild gdb --without python, but apparently Python 3.8 stays in the buildroot and I get --allowerasing errors when I try to build anything. Error: Problem: package gdb-headless-8.3.50.20190319-2.fc31.x86_64 requires libpython3.7m.so.1.0()(64bit), but none of the providers can be installed - cannot install both python3-libs-3.8.0~a2-2.fc31.x86_64 and python3-libs-3.7.2-7.fc30.x86_64 - cannot install both python3-libs-3.7.2-7.fc30.x86_64 and python3-libs-3.8.0~a2-2.fc31.x86_64 - cannot install the best update candidate for package python3-libs-3.7.2-7.fc30.x86_64 - cannot install the best update candidate for package gdb-headless-8.3.50.20190319-2.fc31.x86_64 (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages) https://copr.fedorainfracloud.org/coprs/g/python/python3.8/builds/ Maybe I left something undeleted, but it is hard to see what. Thanks for help, -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: What's wrong with my build? Attempt to build SRPM have failed
On 14. 03. 19 18:41, Kevin Fenzi wrote: On 3/14/19 10:20 AM, Robert-André Mauchin wrote: On jeudi 14 mars 2019 18:08:22 CET Miro Hrončok wrote: I don't understand the failure, can you please help me debug it? https://copr.fedorainfracloud.org/coprs/g/python/python3.8/build/868314/ Thanks, -- Miro Hrončok -- Same here w/ a Go package One of our cloud compute nodes (fed-cloud04) decided to just reboot for no reason. ;( It happened to have copr-dist-git instance on it. I've restarted the instance, so it should be back to normal now if you resubmit. Confirmed. Thank You. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
What's wrong with my build? Attempt to build SRPM have failed
I don't understand the failure, can you please help me debug it? https://copr.fedorainfracloud.org/coprs/g/python/python3.8/build/868314/ Thanks, -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Rawhide buildroot broken: GPG problem
https://copr.fedorainfracloud.org/coprs/g/python/python3.8/build/865744/ DEBUG util.py:554: BUILDSTDERR: warning: /var/lib/mock/865744-fedora-rawhide-x86_64-1552046861.342034/root/var/cache/dnf/fedora-2d95c80a1fa0a67d/packages/shadow-utils-4.6-8.fc30.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 3c3359c4: NOKEY DEBUG util.py:554: BUILDSTDERR: Importing GPG key 0xCFC659B9: DEBUG util.py:554: BUILDSTDERR: Userid : "Fedora (30) " DEBUG util.py:554: BUILDSTDERR: Fingerprint: F1D8 EC98 F241 AAF2 0DF6 9420 EF3C 111F CFC6 59B9 DEBUG util.py:554: BUILDSTDERR: From : /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-30-primary DEBUG util.py:556: Key imported successfully DEBUG util.py:554: BUILDSTDERR: Importing GPG key 0x429476B4: DEBUG util.py:554: BUILDSTDERR: Userid : "Fedora 29 (29) " DEBUG util.py:554: BUILDSTDERR: Fingerprint: 5A03 B4DD 8254 ECA0 2FDA 1637 A20A A56B 4294 76B4 DEBUG util.py:554: BUILDSTDERR: From : /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-29-primary DEBUG util.py:556: Key imported successfully DEBUG util.py:556: Import of key(s) didn't help, wrong key(s)? DEBUG util.py:554: BUILDSTDERR: Public key for shadow-utils-4.6-8.fc30.x86_64.rpm is not installed. Failing package is: shadow-utils-2:4.6-8.fc30.x86_64 DEBUG util.py:554: BUILDSTDERR: GPG Keys are configured as: file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-30-primary, file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-29-primary DEBUG util.py:554: BUILDSTDERR: Public key for diffutils-3.7-2.fc30.x86_64.rpm is not installed. Failing package is: diffutils-3.7-2.fc30.x86_64 ...snip... DEBUG util.py:554: BUILDSTDERR: GPG Keys are configured as: file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-30-primary, file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-29-primary DEBUG util.py:554: BUILDSTDERR: Error: GPG check FAILED -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Importing stuck?
On 20. 01. 19 12:56, Michal Novotny wrote: Hello! On Sun, Jan 20, 2019 at 12:59 AM Miro Hrončok wrote: Hi, I've noticed my importing task take a while and the queue looks long already: https://copr.fedorainfracloud.org/status/importing/ While there are no pending on running builds. Is something broken? Yes, there was a problem with backend<->builder communication presumably due to too new OpenStack client installed. It is now fixed. Thanks, clime! I confirm it works now. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Importing stuck?
Hi, I've noticed my importing task take a while and the queue looks long already: https://copr.fedorainfracloud.org/status/importing/ While there are no pending on running builds. Is something broken? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Copr overusing python standard library backports on Python 3
On 30.6.2018 15:22, Miro Hrončok wrote: See https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/message/KARHO4ZVELJIFBCJG6TEG5ZWUXVVKBSR/ particularly: copr-backend copr-frontend copr-dist-git copr-frontend copr-keygen copr-rpmbuild python-copr use: python3-mock python3-simplejson Also note that in that thread linked above a point was made that simplejson might not just be a backport but porjects utilize it for spped. So my question is, why do you use simplejson in Copr? Is it speed? If so, do you have some actual data? Have you tried ujson? https://pypi.org/project/ujson/ Thanks for info. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/copr-devel@lists.fedorahosted.org/message/IYQINVI2K4IUG3YRZJXT746YG2P3D4RG/
Copr overusing python standard library backports on Python 3
See https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/message/KARHO4ZVELJIFBCJG6TEG5ZWUXVVKBSR/ particularly: copr-backend copr-frontend copr-dist-git copr-frontend copr-keygen copr-rpmbuild python-copr use: python3-mock python3-simplejson Could you please see how hard it is to get rid of those? For compatibility with Python 2 + 3, you can always do: try: from unittest import mock except ImportError: # Python 2 version depends on mock import mock and: try: # Python 2 version depends on simplejson import simplejson as json except ImportError: import json If you have dependencies in setup.py, you can do something like: https://github.com/zopefoundation/ZEO/blob/master/setup.py#L137 https://github.com/qtile/qtile/blob/develop/setup.py#L95 or https://www.python.org/dev/peps/pep-0508/ See also https://hynek.me/articles/conditional-python-dependencies/ Thank you, -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/copr-devel@lists.fedorahosted.org/message/LNQZYFZJAWWRYN2PH7BSD6LXX3XUMGPG/
Re: Backporting from rawhide: setting %fedora to 29
On 14.5.2018 15:18, Michal Novotny wrote: I will do some basic implementation, probably just with per-chroot granularity. We will add the package specific setting when the new API and new copr-cli comes. Thank you very much. Feel free to let me test it on staging or so. If this works, I'll gladly buy you a beverage. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Re: Backporting from rawhide: setting %fedora to 29
On 14.5.2018 14:20, Michal Novotny wrote: Can we cover it just by providing "with" and "without" fields for chroots/builds which would then basically translate to --with/--without options for mock, rpkg, and similar tools? Yes! Good idea. Thanks. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Re: Backporting from rawhide: setting %fedora to 29
On 14.5.2018 12:35, Michal Novotny wrote:
Now to my problem: some packages update rawhide only and the
fedpkg+rpkg integration works like a charm. Other packages however
keep all the branches synced and they use the %{fedora} variable to
determine different behavior. I'd like to tell copr: Set fedora to
29 even if building for older Fedoras. Can I do that?
Thank you for the positive feedback. I need to admit I don't exactly
understand the use-case. When a package keeps the branches synced,
wouldn't it help to build e.g. for rawhide branch only and ignore
incoming push events for all the other branches?
The use case for example:
fedpkg switches to python3 in rawhide only with a conditional (if fedora
> 28).
I want to build a fedpkg package for f28 that uses python3.
Currently that would require:
1. fedpkg clone fedpkg && cd fedpkg
2. change the conditional in spec
3. fedpkg srpm
4. copr upload and build
5. script the above or manually do it with every rawhide update
What I'd like to do:
1. add fedpkg package with fedmsg+rpkg integration
2. set fedora to 29 via a configuration dialog
3. keep it running automatically
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Backporting from rawhide: setting %fedora to 29
Hi,
I do backport stuff from rawhide in my coprs a lot. The relatively newly
announced fedmsg+rpkg thing is making my life easier than ever. So first
of all, kudos!
Now to my problem: some packages update rawhide only and the fedpkg+rpkg
integration works like a charm. Other packages however keep all the
branches synced and they use the %{fedora} variable to determine
different behavior. I'd like to tell copr: Set fedora to 29 even if
building for older Fedoras. Can I do that?
Thanks.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Plenty of bogus builds with rpkg s.f.o push automation
See https://src.fedoraproject.org/rpms/git/commits/master -> last commit
is from 2018-04-02. Yet the automation in
https://copr.fedorainfracloud.org/coprs/churchyard/git/package/git/
still builds several empty builds every couple hours.
I also get notifications like:
Automated git copr build of None for srpm-builds finished with 'failed'
Notification time stamped 2018-04-12 04:21:05 UTC
{
"certificate":
"LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUVUakNDQTdlZ0F3SUJBZ0lDQVBZd0RRWUpL\nb1pJaHZjTkFRRUZCUUF3Z2FBeEN6QUpCZ05WQkFZVEFsVlQKTVFzd0NRWURWUVFJRXdKT1F6RVFN\nQTRHQTFVRUJ4TUhVbUZzWldsbmFERVhNQlVHQTFVRUNoTU9SbVZrYjNKaApJRkJ5YjJwbFkzUXhE\nekFOQmdOVkJBc1RCbVpsWkcxelp6RVBNQTBHQTFVRUF4TUdabVZrYlhObk1ROHdEUVlEClZRUXBF\nd1ptWldSdGMyY3hKakFrQmdrcWhraUc5dzBCQ1FFV0YyRmtiV2x1UUdabFpHOXlZWEJ5YjJwbFkz\nUXUKYjNKbk1CNFhEVEUwTURReU16RTBNamsxTVZvWERUSTBNRFF5TURFME1qazFNVm93Z2R3eEN6\nQUpCZ05WQkFZVApBbFZUTVFzd0NRWURWUVFJRXdKT1F6RVFNQTRHQTFVRUJ4TUhVbUZzWldsbmFE\nRVhNQlVHQTFVRUNoTU9SbVZrCmIzSmhJRkJ5YjJwbFkzUXhEekFOQmdOVkJBc1RCbVpsWkcxelp6\nRXRNQ3NHQTFVRUF4TWtZMjl3Y2kxamIzQnkKTFdKbExtTnNiM1ZrTG1abFpHOXlZWEJ5YjJwbFkz\nUXViM0puTVMwd0t3WURWUVFwRXlSamIzQnlMV052Y0hJdApZbVV1WTJ4dmRXUXVabVZrYjNKaGNI\nSnZhbVZqZEM1dmNtY3hKakFrQmdrcWhraUc5dzBCQ1FFV0YyRmtiV2x1ClFHWmxaRzl5WVhCeWIy\ncGxZM1F1YjNKbk1JR2ZNQTBHQ1NxR1NJYjNEUUVCQVFVQUE0R05BRENCaVFLQmdRQ2UKREs5VFQy\nM05BdTZPWTVGMnVVNHpMRW9Ld2k1RnRRTU5jVWV5eDdmOHJxMUZXaUxDWHBjWFhpU2tzUE1XV1NM\nWQo5SHNoa1pvM3ZjMHFSRXVBWDNweWRuM2VFRDA0UExrUmRlaWpvSXA5L0Y2YlZ3MmlLMDdXRmc5\nU2MwNlRsKzhSCld1RHNaeTQ1SVJKYXhCRTlJaHBYL0x2Y2JnQ1cvZmVHVGp5WG1iRHd0UUlEQVFB\nQm80SUJWekNDQVZNd0NRWUQKVlIwVEJBSXdBREF0QmdsZ2hrZ0JodmhDQVEwRUlCWWVSV0Z6ZVMx\nU1UwRWdSMlZ1WlhKaGRHVmtJRU5sY25ScApabWxqWVhSbE1CMEdBMVVkRGdRV0JCUm5lNTg0d3Bs\nWGYrZVE2K25zSTZCbm5BNENaRENCMVFZRFZSMGpCSUhOCk1JSEtnQlJyUUZyNUVnaUpXZWRaNVFY\nMUFoMEtUbjhVQUtHQnBxU0JvekNCb0RFTE1Ba0dBMVVFQmhNQ1ZWTXgKQ3pBSkJnTlZCQWdUQWs1\nRE1SQXdEZ1lEVlFRSEV3ZFNZV3hsYVdkb01SY3dGUVlEVlFRS0V3NUdaV1J2Y21FZwpVSEp2YW1W\namRERVBNQTBHQTFVRUN4TUdabVZrYlhObk1ROHdEUVlEVlFRREV3Wm1aV1J0YzJjeER6QU5CZ05W\nCkJDa1RCbVpsWkcxelp6RW1NQ1FHQ1NxR1NJYjNEUUVKQVJZWFlXUnRhVzVBWm1Wa2IzSmhjSEp2\nYW1WamRDNXYKY21lQ0NRRGpVQjVIVHhjZVJUQVRCZ05WSFNVRUREQUtCZ2dyQmdFRkJRY0RBakFM\nQmdOVkhROEVCQU1DQjRBdwpEUVlKS29aSWh2Y05BUUVGQlFBRGdZRUFVazNlbjBYUXpDQm5IUlh4\nZDhyOHp2ZFAwVURvbEpiUysyTEl3Z3NDClJDMnNkZ1UwNGdFblYxdFpVTjNydEk1SzQ2MnpKT0JQ\nOFhQd3h4eUZMN1lOYmVtWTgyTG52Y1pHdzliMGdxTDMKdHNKbzllSFV5SXBZMG93TlVKdzgzU1Ax\neFJvb3NwVGJRK3BsNm9qdjVPNVpGZ1lBUG1yckRWZ0M4a2gzRlp4Rgp0SWc9Ci0tLS0tRU5EIENF\nUlRJRklDQVRFLS0tLS0K\n",
"crypto": "x509",
"i": 3,
"msg": {
"build": 740145,
"chroot": "srpm-builds",
"copr": "git",
"ip": "172.25.94.241",
"owner": "churchyard",
"pid": 14794,
"pkg": null,
"status": 0,
"user": null,
"version": null,
"what": "build end: user:None copr:git build:740145 pkg:None
version:None ip:172.25.94.241 pid:14794 status:0",
"who": "backend.worker-9816-PPC64LE"
},
"msg_id": "2018-6688f20e-7d09-4b52-8708-8a2eedd3e490",
"signature":
"HqiUY1n7uatfPGVXjjOTN71cDz/zzwGYpUtIwM+pPK5v0/r9De9GIjAEXnpLBLqIsha8sGLGXx9x\n4sk6yIOtMGoaSC6r/YRT3A/DwyChl8wBap8nxJl3ApW8uU5vyZ9iyV67rUBQad95BVQuBZ8OtWPc\nQo6nR6U0XyYm8Y0hDOw=\n",
"timestamp": 1523506865,
"topic": "org.fedoraproject.prod.copr.build.end",
"username": "copr"
}
https://copr.fedoraproject.org/coprs/churchyard/git/build/740145/
--
You received this message due to your preference settings at
https://apps.fedoraproject.org/notifications/churchyard.id.fedoraproject.org/email/908
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Re: COPR src.fp.o auto-rebuilds
On 27.2.2018 00:04, Michal Novotny wrote: Hello, you can now very easily setup auto-rebuilds for your src.fp.o package: 1) make a SCM package in COPR with Clone URL pointing to the src.fp.o fork (please, use the https:// cloning option) 2) make sure "Webhook Rebuild" checkbox is checked when you are creating the package 3) Go to settings for your package at src.fp.o and almost at the bottom in Hooks->Fedmsg section, check "Activate" checkbox and then click on "Update" button. This is awesome! Thanks. I've pushed several commits at once and copr triggered a build for every one of them. It would make sense in my POV to only trigger once per push. Is there a technical reason for current behavior, or is it intentional? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Re: copr-dist-git Internal Server Error
On 3.1.2018 14:30, Michal Novotny wrote: Hey, thank you for noticing. There was a SELinux configuration problem causing cgit (git_script_t) not being able to access any git content (git_user_content_t). We have fixed it by adding map permission for the git_script_t type: allow git_script_t git_user_content_t:file map; map permission is necessary since f27. Thanks for the quick fix. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
copr-dist-git Internal Server Error
Hi, I keep getting Internal Server Error every time I want to see copr-dist-git, such as clicking any link at [1] or a commit has next to build details at copr frontend. [1] http://copr-dist-git.fedorainfracloud.org/cgit/ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Re: Error 500 : Internal Server Error ('url')
On 13.10.2017 14:36, Michal Novotny wrote: The problem should be fixed now. Please try and let me know. Confirming. clime On Thu, Oct 5, 2017 at 4:39 PM, Michal Novotny <cl...@redhat.com <mailto:cl...@redhat.com>> wrote: Hey, On Thu, Oct 5, 2017 at 2:56 PM, Miro Hrončok <mhron...@redhat.com <mailto:mhron...@redhat.com>> wrote: I may have found an issue with copr: Yes, it's a bug when accessing not-so-new builds that have not-updated build definition in DB. I can fix it manually in DB and in any case, this will be fixed upon next copr-frontend deploy (might be more than week though). Let me know if you want fast fix. I can do it immediately then. 1. go to https://copr.fedorainfracloud.org/coprs/g/python/pypy35/builds/ <https://copr.fedorainfracloud.org/coprs/g/python/pypy35/builds/> 2. click a build ID -> https://copr.fedorainfracloud.org/coprs/g/python/pypy35/build/564097/ <https://copr.fedorainfracloud.org/coprs/g/python/pypy35/build/564097/> Error 500 : Internal Server Error 'url' Note: This is a repository owned by a group. -- Miro Hrončok -- Phone: +420777974800 <tel:%2B420777974800> IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org <mailto:copr-devel@lists.fedorahosted.org> To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org <mailto:copr-devel-le...@lists.fedorahosted.org> ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Re: Child pid '4787' is dead
On 8.9.2016 13:59, Miroslav Suchý wrote:
Dne 6.9.2016 v 23:22 Miro Hrončok napsal(a):
My builds in [python26], IDs 450012 and 450019 end weird on F23, while
succeeding on other Fedoras.
The last lines of build.log.gz are:
+ exit 0
Child pid '4787' is dead
Child dead, killing orphans
Child return code was: 0
While on other Fedoras:
+ exit 0
Child return code was: 0
The [koji] build is fine (at least for non-arm now).
The RPM files are there in the output directory, but not installable from the
repo.
Is that some problem in Copr?
Not Copr problem. May be a mock problem. Lookin in mock code:
i_rdy, o_rdy, e_rdy = select.select(fds, [], [], 1)
if not i_rdy and not o_rdy and not e_rdy:
if child and child.poll() is not None:
logger.info("Child pid '%s' is dead", child.pid)
To me is looks like a race condition: select() waited 1 second and returned
empty list and exactly at the same time the
process ended so pool() returned "not None". The strange is that it happened
twice in row for you.
Well, three times in a row. Trying again.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org
Re: Please kill my 47 hours old build
On 11.8.2016 22:23, Michal Novotny wrote: Done :-). M. Thanks. Here are two other candidates (I've isolated the issue, so it should not happen again any time soon): https://copr.fedorainfracloud.org/coprs/g/python/python33/build/446247/ https://copr.fedorainfracloud.org/coprs/g/python/python33/build/446340/ On Thu, Aug 11, 2016 at 7:21 PM, Miro Hrončok <mhron...@redhat.com <mailto:mhron...@redhat.com>> wrote: https://copr.fedorainfracloud.org/coprs/g/python/python33/build/439804/ <https://copr.fedorainfracloud.org/coprs/g/python/python33/build/439804/> Thanks -- Miro Hrončok -- Phone: +420777974800 <tel:%2B420777974800> IRC: mhroncok ___ copr-devel mailing list copr-devel@lists.fedorahosted.org <mailto:copr-devel@lists.fedorahosted.org> https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org <https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org> ___ copr-devel mailing list copr-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list copr-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org
Please kill my 47 hours old build
https://copr.fedorainfracloud.org/coprs/g/python/python33/build/439804/ Thanks -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list copr-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org
Re: Copr cannot see it's own repo
On 21.3.2016 14:05, Miroslav Suchý wrote: Dne 19.3.2016 v 11:54 Miro Hrončok napsal(a): See the log here: https://copr-be.cloud.fedoraproject.org/results/churchyard/horus/fedora-22-i386/00169302-simarrange/root.log.gz https://copr-be.cloud.fedoraproject.org/results/churchyard/horus/fedora-22-i386/devel/repodata/repomd.xml: [Errno 14] HTTPS Error 404 - Not Found I believe the word devel is not supposed to be in the URL. This is intended. In fact in next release there will be something like "Please ignore the error above". This is part of feature where you can check in your settings "Create repositories manually". This is intended for big projects like Gnome or KDE, which consist of hundreds of packages. And you want to release them all at the same time. But on the other hand it take days to build them. And of course during the buildtime you need to enable that repository, while at the same time have it disabled/frozen for users. So if you check "Create repositories manually", we do not run createrepo_c in normal directory, but in ./devel/ directory. This is directory is always passed to mock with skip_if_unavailable=1 So if Copr have it, then it is used, otherwise ignored. But if it is missing DNF/YUM print the warning above even if it is ignored. Currently there is no way to tell DNF/YUM to not print this warning. Thanks for clarifying. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list copr-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org
Re: help with failing build
Dne 30.1.2015 v 13:37 Miroslav Suchý napsal(a): pyOpenSSL=0.14 Not available on F21 :( That's weird. I have it working with 0.13 but it doesn't work in virtual machine. I'm going to investigate. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list copr-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/copr-devel
Re: help with failing build
Dne 30.1.2015 v 14:40 Miro Hrončok napsal(a): That's weird. I have it working with 0.13 but it doesn't work in virtual machine. I'm going to investigate. Ok, uninstalling and installing pyOpenSSL package reintroduced the behavior (SNI not working) However pyOpenSSL form rawhide is installable and makes SNI work. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list copr-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/copr-devel
Re: help with failing build
The problem is, that apps on OpenShift use SNI to enable custom domain names with custom certificates. Which is a standard for a bazillion years and the only thing that does not support it is Windows XP with IE 6 and... ehm, Python 2. http://en.wikipedia.org/wiki/Server_Name_Indication On Python 3 with request, this is completely supported. However, on Python 2, there's a workaround needed. You'll need the following to use SNI from requests: requests=2.3.0 ndg_httpsclient=0.3.2 pyOpenSSL=0.14 pyasn1=0.1.7 On Fedora 21, for example, this is all available in the following packages: python-requests python-ndg_httpsclient pyOpenSSL python-pyasn1 See: * http://docs.python-requests.org/en/latest/community/faq/#what-are-hostname-doesn-t-match-errors * https://stackoverflow.com/questions/18578439/using-requests-with-tls-doesnt-give-sni-support/18579484#18579484 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list copr-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/copr-devel
