Re: Help for FTBFS packages: apcupsd and firefox-pkcs11-loader
On 1/30/21 7:37 PM, Germano Massullo wrote:
I tried fixing apcupsd and firefox-pkcs11-loader that started to fail
after introduction of "CMake to do out-of-source builds", but I got some
errors about missing files, that is strange since package structure has
not changed, it's the same that built successfully on older Fedora
branches problems. So I am writing this message to ask for your help.
Details at following bugzilla comments
firefox-pkcs11-loader
https://bugzilla.redhat.com/show_bug.cgi?id=1863558#c7
It seems out of tree builds are not supported by the build script.
Just copy the xpi to the build directory to make it work:
cp -a *.xpi %{_vpath_builddir}/
(after the %cmake call)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Help for FTBFS packages: apcupsd and firefox-pkcs11-loader
apcupsd package has been fixed by Jason L Tibbitts III ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Test timeouts in Fedora Copr emulated envs
On Sat, Jan 30, 2021 at 12:08:18PM -0800, Kevin Fenzi wrote: > On Fri, Jan 29, 2021 at 03:26:18PM +, Daniel P. Berrangé wrote: > > When we attempt to build libvirt in Copr, the test suite times out on > > s390 builds. > > > > IIUC, this is because s390 in Copr is using a QEMU emulated system, > > not native hardware, and thus is massively slower to execute. > > > > We don't want to bump up the default test suite timeout unconditonally, > > as that makes it slower to diagnose problems for the common case > > where the build env is not emulated. > > > > Is there a good way to detect that the build is in an emulated copr > > env rather than native. Does Copr / mock set any env variable to > > show that you're emulated ? > > systemd-detect-virt ? > > I've not tested, but I'd expect it to say 'qemu' for the emulated case > and 'kvm' for the vm case? > > But some of our s390x builders are ZVM instances and it says 'zvm' > there. Oh, and for now our 32 bit arm builders return 'qemu' for this as well, even though they are accelerated. This is because they are doing a direct kernel/initramfs boot. If/when we can ever get them on f33, they will be using uefi to boot and would return 'kvm' for this. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Test timeouts in Fedora Copr emulated envs
On Fri, Jan 29, 2021 at 03:26:18PM +, Daniel P. Berrangé wrote: > When we attempt to build libvirt in Copr, the test suite times out on > s390 builds. > > IIUC, this is because s390 in Copr is using a QEMU emulated system, > not native hardware, and thus is massively slower to execute. > > We don't want to bump up the default test suite timeout unconditonally, > as that makes it slower to diagnose problems for the common case > where the build env is not emulated. > > Is there a good way to detect that the build is in an emulated copr > env rather than native. Does Copr / mock set any env variable to > show that you're emulated ? systemd-detect-virt ? I've not tested, but I'd expect it to say 'qemu' for the emulated case and 'kvm' for the vm case? But some of our s390x builders are ZVM instances and it says 'zvm' there. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: bootstrapping without .spec modification
On Fri, Jan 29, 2021 at 03:49:28PM +0100, Miro Hrončok wrote:
>
> Currently a Koji task says:
>
> Source:
> git+https://src.fedoraproject.org/rpms/python3.9.git#563b4f4b59a9f81095acfe30899fdc4b040c1b9b
> Build Target: f34-rebuild
> Options:
> fail_fast = True
> wait_builds =
>
> Example taken from
> https://koji.fedoraproject.org/koji/taskinfo?taskID=60654655
>
> With this feature, it would say:
>
> Source:
> git+https://src.fedoraproject.org/rpms/python3.9.git#563b4f4b59a9f81095acfe30899fdc4b040c1b9b
> Build Target: f34-rebuild
> Options:
> fail_fast = True
> wait_builds =
> Macro overrides:
> _with_bootstrap: 1
>
> And when reproducing, you'd just run the same command, e.g.
>
> $ koji build f34-rebuild --fail-fast --macro '_with_bootstrap 1'
> 'git+https://src.fedoraproject.org/rpms/python3.9.git#563b4f4b59a9f81095acfe30899fdc4b040c1b9b'
>
> The Koji web interface could even display the command.
>
> That's very much as reproduce as now.
So, koji already can set macros per tag.
For example, eln sig uses this:
➜ ~ koji taginfo eln-build
Tag: eln-build [22493]
Arches: i686 x86_64 aarch64 ppc64le s390x
Groups: appliance-build, build, livecd-build, livemedia-build, srpm-build
Tag options:
mock.new_chroot : 0 [f34]
mock.package_manager : 'dnf' [f34]
rpm.macro.dist : ('%{!?distprefix0:%{?distprefix}}%{expand:%{lua:for i=0,
do '
'print("%{?distprefix" .. i .."}") '
'end}}.eln%{eln}%{?with_bootstrap:~bootstrap}')
rpm.macro.eln : 108
rpm.macro.rhel : 9
This tag is a buildroot for one or more targets
Current repo: repo#2902927: 2021-01-30 19:46:56.747509+00:00
Targets that build from this tag:
eln-rebuild
eln
eln-candidate
Inheritance:
0 eln [22492]
5 f34-build [27045]
We had a request to enable this for side-tags:
https://pagure.io/fedora-infrastructure/issue/9048
but didn't want to due to how this could be used.
My thought was to try and ask koji developers to add some kind of
'non-mergable' bit on side-tags. So, if you want to use a side tag to
play around with/test something you could, but if you adjusted things
beyond some whitelist, the side-tag would not be mergable back into
rawhide, and we could allow _with_bootstrap.
Ideally though this could be something in rpm... so it keeps track of
what was passed in for the build so if you just had the src.rpm you
could figure out what was going on?
kevin
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Help wanted] Setting vi/view/vim via alternatives
> Am 30.01.2021 um 19:41 schrieb Fabio Valentini : > > On Sat, Jan 30, 2021 at 7:24 PM Peter Boy wrote: >> >> >> >>> Am 30.01.2021 um 17:45 schrieb Vitaly Zaitsev via devel >>> : >>> >>> On 30.01.2021 16:58, Peter Boy wrote: But it’s perfectly usable for Fedora Workstation or Server and almost indispensable for some development projects, e.g. Java (and vi/vim for a terminal environment). Why should alternatives not be usable there? Or what is a suitable and adequate replacement? >>> >>> https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/ >> >> Thanks for the info. Unfortunately, I don’t see a connection to immutable >> Fedora (it is about drop-in, user configurable, etc). Or do I miss something? > > If you read the Packaging Guidelines, they actually explicitly mention > that vi / vim are a bad example for using the alternatives system - > because they're not drop-in replacements. Yes, I got that (and mentioned the drop-in criteria), but the original post can /could be interpreted as, alternatives is / has to be altogether "banned" from Fedora. And that seems to me to be the trigger of the discussion here. > Additionally, as far as I know, OSTree based Fedora variants do not > execute any RPM scriptlets, but implement their own handling of e.g. > ldconfig and such things. > And alternatives is definitely not compatible with OSTree - according > to these bug reports, at least Java alternatives are broken - > apparently primarily because OSTree stores configuration in /var > instead of /etc: Yes, but what will we do about it? The fix mentioned previously (manually symlink) is not as powerful as alternatives. But it may be a bad idea to remove alternatives from workstation (and server) just because it doesn’t work with silverblue. That’s the core of discussion here. Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
FedoraRespin-33-updates-20210129.0 compose check report
Missing expected images: Soas live x86_64 Workstation live x86_64 Xfce live x86_64 Mate live x86_64 Failed openQA tests: 3/19 (x86_64) ID: 765677 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/765677 ID: 765687 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/765687 ID: 765689 Test: x86_64 KDE-live-iso release_identification URL: https://openqa.fedoraproject.org/tests/765689 Passed openQA tests: 16/19 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Help wanted] Setting vi/view/vim via alternatives
On Sat, 30 Jan 2021 at 20:03, Vitaly Zaitsev via devel wrote: > > On 30.01.2021 18:50, clime wrote: > > Hey, what do you mean by this? > > https://docs.fedoraproject.org/en-US/fedora-coreos/alternatives/ > > > Why should scriplets usage be incompatible with immutable Fedora > > releases? > > rpm-ostree doesn't execute any scriptlets. It doesn't seem true per what Fabio linked: https://github.com/coreos/fedora-coreos-tracker/issues/703 (and the fix https://src.fedoraproject.org/rpms/wireshark/pull-request/5#request_diff) That rather suggests they need the scriplets to be OSTree-compatible. I think the main reason for the problem with alternatives is really just that it tries to put its db under /var/, which is not supported as /var is not synced by OSTree. By the way, this is really cool thing: https://docs.fedoraproject.org/en-US/packaging-guidelines/EnvironmentModules/ Not usable for this particular case but really cool. It's interesting that it itself uses alternatives for switching between the lmod and the env implementation. > > -- > Sincerely, >Vitaly Zaitsev (vit...@easycoding.org) > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Help wanted] Setting vi/view/vim via alternatives
On Sat, 30 Jan 2021 at 19:48, Fabio Valentini wrote: > > On Sat, Jan 30, 2021 at 7:24 PM Peter Boy wrote: > > > > > > > > > Am 30.01.2021 um 17:45 schrieb Vitaly Zaitsev via devel > > > : > > > > > > On 30.01.2021 16:58, Peter Boy wrote: > > >> But it’s perfectly usable for Fedora Workstation or Server and almost > > >> indispensable for some development projects, e.g. Java (and vi/vim for a > > >> terminal environment). Why should alternatives not be usable there? Or > > >> what is a suitable and adequate replacement? > > > > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/ > > > > Thanks for the info. Unfortunately, I don’t see a connection to immutable > > Fedora (it is about drop-in, user configurable, etc). Or do I miss > > something? > > If you read the Packaging Guidelines, they actually explicitly mention > that vi / vim are a bad example for using the alternatives system - > because they're not drop-in replacements. > > Additionally, as far as I know, OSTree based Fedora variants do not > execute any RPM scriptlets, but implement their own handling of e.g. > ldconfig and such things. > And alternatives is definitely not compatible with OSTree - according > to these bug reports, at least Java alternatives are broken - > apparently primarily because OSTree stores configuration in /var > instead of /etc: I think you meant: "...because alternatives stores configuration in /var instead of /etc" > > - https://bugzilla.redhat.com/show_bug.cgi?id=1657367 > - https://github.com/coreos/rpm-ostree/issues/1614 > > > Fabio > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Help wanted] Setting vi/view/vim via alternatives
On 30.01.2021 18:50, clime wrote: Hey, what do you mean by this? https://docs.fedoraproject.org/en-US/fedora-coreos/alternatives/ Why should scriplets usage be incompatible with immutable Fedora releases? rpm-ostree doesn't execute any scriptlets. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Help wanted] Setting vi/view/vim via alternatives
On 30.01.2021 19:24, Peter Boy wrote: Thanks for the info. Unfortunately, I don’t see a connection to immutable Fedora (it is about drop-in, user configurable, etc). Or do I miss something? https://docs.fedoraproject.org/en-US/fedora-coreos/alternatives/ -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Help wanted] Setting vi/view/vim via alternatives
On Sat, Jan 30, 2021 at 7:24 PM Peter Boy wrote: > > > > > Am 30.01.2021 um 17:45 schrieb Vitaly Zaitsev via devel > > : > > > > On 30.01.2021 16:58, Peter Boy wrote: > >> But it’s perfectly usable for Fedora Workstation or Server and almost > >> indispensable for some development projects, e.g. Java (and vi/vim for a > >> terminal environment). Why should alternatives not be usable there? Or > >> what is a suitable and adequate replacement? > > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/ > > Thanks for the info. Unfortunately, I don’t see a connection to immutable > Fedora (it is about drop-in, user configurable, etc). Or do I miss something? If you read the Packaging Guidelines, they actually explicitly mention that vi / vim are a bad example for using the alternatives system - because they're not drop-in replacements. Additionally, as far as I know, OSTree based Fedora variants do not execute any RPM scriptlets, but implement their own handling of e.g. ldconfig and such things. And alternatives is definitely not compatible with OSTree - according to these bug reports, at least Java alternatives are broken - apparently primarily because OSTree stores configuration in /var instead of /etc: - https://bugzilla.redhat.com/show_bug.cgi?id=1657367 - https://github.com/coreos/rpm-ostree/issues/1614 Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Help for FTBFS packages: apcupsd and firefox-pkcs11-loader
I tried fixing apcupsd and firefox-pkcs11-loader that started to fail after introduction of "CMake to do out-of-source builds", but I got some errors about missing files, that is strange since package structure has not changed, it's the same that built successfully on older Fedora branches problems. So I am writing this message to ask for your help. Details at following bugzilla comments firefox-pkcs11-loader https://bugzilla.redhat.com/show_bug.cgi?id=1863558#c7 apcupsd https://bugzilla.redhat.com/show_bug.cgi?id=1863218#c4 Thank you ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Help wanted] Setting vi/view/vim via alternatives
> Am 30.01.2021 um 17:45 schrieb Vitaly Zaitsev via devel > : > > On 30.01.2021 16:58, Peter Boy wrote: >> But it’s perfectly usable for Fedora Workstation or Server and almost >> indispensable for some development projects, e.g. Java (and vi/vim for a >> terminal environment). Why should alternatives not be usable there? Or what >> is a suitable and adequate replacement? > > https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/ Thanks for the info. Unfortunately, I don’t see a connection to immutable Fedora (it is about drop-in, user configurable, etc). Or do I miss something? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git
clime wrote: > So if some other maintainer pushes his work to the server meanwhile, > this will just delete his work? Or what's the idea here? I guess the safe thing to do would be to wait and see whether that commit also fails to build (i.e., if the CI build fails, check whether the built commit is still the current HEAD, and trigger the revert only if it is, otherwise defer the decision to the new HEAD's CI build), but if that is the case, yes, it will definitely be deleted from the server. But it will still be present in the maintainer's local checkout and can be trivially pushed back together with a build fix. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora rawhide compose report: 20210129.n.0 changes
On Sat, Jan 30, 2021 at 12:45:42PM +0100, Miro Hrončok wrote: > On 30. 01. 21 0:16, Fabio Valentini wrote: > > On Fri, Jan 29, 2021 at 2:49 PM Fedora Rawhide Report > > wrote: > > > > > > > (snip) > > > > > > > > Package: golang-torproject-pluggable-transports-goptlib-1.1.0-6.fc34 > > > Old package: golang-torproject-pluggable-transports-goptlib-1.1.0-5.fc33 > > > Summary: Library for writing Tor pluggable transports in Go > > > RPMs: golang-torproject-pluggable-transports-goptlib-devel > > > Size: 37.12 KiB > > > Size change: 129 B > > > Changelog: > > >* Tue Jan 26 2021 Fedora Release Engineering > > > - 1.1.0-6 > > >- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild > > > > What's going on here? This is one of a lot of packages that only have > > the mass rebuild changelog entry but no other changes, and have not > > been built by releng, but by other packagers, according to koji. > > Did people resubmit failed mass rebuild builds themselves (and not for > > f34-build)? I thought there's going to be an official second round of > > builds to weed out transient issues? I'm not sure what happened there. resubmit should resubmit it just the way it was, ie, against f34-rebuild. A new build should get a new taskid, but this seemed to be the same one the releng one had. Dunno. Perhaps we could ask the people doing this? > > Yes and yes. Both can happen. Yeah, we are doing that now... the main rebuild finished, and all the failures were resubmitted. We hope to merge it in later today. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git
On Sat, 30 Jan 2021 at 01:28, Kevin Kofler via devel wrote: > > Michael Catanzaro wrote: > > Alternative: use automated reverts instead of force pushes, and don't > > worry about maintaining a clean history. > > Sure, it is possible to make an implementation with lower quality of > implementation with possibly less work, by omitting the force pushes and the > smart "fedpkg build" behavior. > > That said, I think you will find that reverts are actually more work to get > right in complex cases such as multi-commit pushes, possibly even with merge > commits, than a simple: > git reset --hard $last_successful_build > git push -f > which only needs the CI to be exempted from the git hook banning force > pushes. So if some other maintainer pushes his work to the server meanwhile, this will just delete his work? Or what's the idea here? > > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Help wanted] Setting vi/view/vim via alternatives
On Sat, 30 Jan 2021 at 16:08, Vitaly Zaitsev via devel wrote: > > On 29.01.2021 09:49, Zdenek Dohnal wrote: > > I'm currently trying to rewrite the current shell aliases for making > > Vi/View/Vim use the correct compiled binary based on which Vim package > > is installed. > > Alternatives are not suitable for Fedora, because they will break > immutable Fedora releases due to scriptlets usage. Hey, what do you mean by this? Why should scriplets usage be incompatible with immutable Fedora releases? I guess thousands of rpms use some kind of scriplets in spec? Otherwise, alternatives subcommands alter stuff under `/etc/alternatives` and `/var/lib/alternatives`. Both places should be writable on immutable releases. > > -- > Sincerely, >Vitaly Zaitsev (vit...@easycoding.org) > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Help wanted] Setting vi/view/vim via alternatives
On 30.01.2021 16:58, Peter Boy wrote: But it’s perfectly usable for Fedora Workstation or Server and almost indispensable for some development projects, e.g. Java (and vi/vim for a terminal environment). Why should alternatives not be usable there? Or what is a suitable and adequate replacement? https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/ -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git
Kevin Kofler via devel writes: > Matthew Miller wrote: >> Yeah, honestly, this is also a pretty serious hardship for the long tail >> of people maintaining a handful of infrequently updated packages. I'm >> hugely in favor of not checking in work in progress on the main or release >> branches, but let's not make more steps. > > I still think that the best way to do CI would be what I already suggested > at least once: > 1. maintainer pushes the commit to the branch "rawhide" or "fn" > 2. a quick synchronous commit hook validates obvious things such as the >presence of source files and patches > If this fails, the push fails and we stop here. Otherwise: > 3. another commit hook asynchronously triggers a CI build > 4. the push succeeds (without waiting for the CI build to complete) > 5. the asynchronous CI attempts to build the package > 6. if the CI build fails, the branch "rawhide" or "fn" is automatically >force-pushed back to the last commit that successfully built, and an >e-mail notification is sent. Force-pushing is safe in that case because >there was by definition no successful build, hence nothing that shipped >in any repos. Rewinding to the last successful build should work even if >multiple broken commits by multiple maintainers have been pushed since. > 7. by default, CI builds are treated as scratch builds, but in order to >conserve resources, it should be possible for the maintainer to mark a CI >build as a production build either during the build or within a >reasonable time after completion. Ideally, fedpkg build should >automatically do that instead of triggering another, redundant build if >it finds a suitable CI build to retain. > > If fully implemented (including the "ideally" part), this achieves the goal > that maintainers need not adjust their workflow at all. They just push their > changes and run "fedpkg build", the CI happens behind the scenes, "fedpkg > build" automatically sets the CI flag to retain the build if successful, and > watches the CI build unless --nowait is used. And if the build fails, they > can just commit a fix locally and redo a new push, which will also push the > previous failed commit back (but the CI will not attempt to build it again > because there is now a newer commit on top which will be built instead – and > if that, too, fails, the CI will rewind the whole thing). > > At the same time, broken commits never persist in dist-git once they are > known not to build, the history remains clean (because everything broken > gets force-pushed out of the way), and, thanks to the automatic force-pushed > rewind, maintainers can, if they wish, opt to push an amended commit (clean > history!) instead of the "the last commit was broken, fix it" commit they > have to do now (but they can still do the latter if they wish, as explained > above). In contrast, any kind of pull-request workflow, even an automatic > one, makes the history even less clean than it is now. I really like this idea! I'm afraid it's going to be pretty hard to pull off, especially the promotion of scratch builds to real builds and the force push that reverts to the latest working commit (also, that one might not work anymore at this point…), but still a goal worth pursuing. Cheers, Dan signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Help wanted] Setting vi/view/vim via alternatives
> Am 30.01.2021 um 15:58 schrieb Vitaly Zaitsev via devel > : > > On 29.01.2021 09:49, Zdenek Dohnal wrote: >> I'm currently trying to rewrite the current shell aliases for making >> Vi/View/Vim use the correct compiled binary based on which Vim package >> is installed. > > Alternatives are not suitable for Fedora, because they will break immutable > Fedora releases due to scriptlets usage. But it’s perfectly usable for Fedora Workstation or Server and almost indispensable for some development projects, e.g. Java (and vi/vim for a terminal environment). Why should alternatives not be usable there? Or what is a suitable and adequate replacement? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: uEFI for ARMv7 (Self-Contained Change proposal)
On Sat, Jan 30, 2021 at 11:46 AM Neal Gompa wrote: > > On Sat, Jan 30, 2021 at 6:43 AM Peter Robinson wrote: > > > > On Sat, Jan 30, 2021 at 11:28 AM Neal Gompa wrote: > > > > > > On Mon, Jan 18, 2021 at 10:21 AM Ben Cotton wrote: > > > > > > > > https://fedoraproject.org/wiki/Changes/ARMv7UEFI > > > > > > > > == Summary == > > > > > > > > Move ARMv7 to use UEFI as default for all armhfp generated images > > > > > > > > == Owner == > > > > * Name: [[User:pbrobinson| Peter Robinson]] > > > > * Email: pbrobinson at fedoraproject dot org > > > > > > > > > > > > == Detailed Description == > > > > > > > > In Fedora 30 we tried to move ARMv7 to UEFI and as part of that change > > > > we got all the infrastructure changes in place as described in that > > > > change. It turned out there were issues with upstream kernel, > > > > bootloaders and a number of other pieces out of our control. Those > > > > pieces of the puzzle are now fixed and we've been building the core > > > > pieces since before Fedora 33 so we know it's now fixed and working > > > > having engaged with upstream since. > > > > > > > > == Benefit to Fedora == > > > > > > > > This allows ARMv7 to move to grub2 providing the same experience to > > > > ARMv7 users as all other architectures across the distribution. It > > > > simplifies a number of software stacks across the distribution due to > > > > being able to use a single install/support/upgrade path as well as > > > > providing a single set of docs. > > > > > > > > == Scope == > > > > * Proposal owners: Changes to kickstarts. > > > > * Other developers: None, all the required changes landed as part of > > > > the prior feature, this is just flipping the switch. > > > > * Release engineering: [https://pagure.io/releng/issue/9946 #9946] (a > > > > check of an impact with Release Engineering is needed) > > > > * Policies and guidelines: N/A > > > > * Trademark approval: N/A (not needed for this Change) > > > > > > > > > > > > == Upgrade/compatibility impact == > > > > Upgrades from prior versions of Fedora will continue to work as they > > > > do currently. Devices booting with extlinux will continue to upgrade > > > > and work as planned. For recent (F-25 and later) clean installs there > > > > will be a documented migration process for those that wish to migrate > > > > to grub2 boot process. For older installs (those without a VFAT > > > > partition for firmware) will need to do a clean install. Devices with > > > > non Fedora built u-boot will need to ensure they have a recent enough > > > > u-boot to support the required uEFI functionality. > > > > > > > > == How To Test == > > > > The process for testing will be the same as aarch64. This standardises > > > > the arm architectures ultimately making things more straight forward > > > > and eventually allowing code clean up. > > > > > > > > == User Experience == > > > > The user experience will be the same as uEFI on aarch64 and x86_64 > > > > with the grub2 menu and features. This will provide a consistent > > > > experience across all Fedora architectures and resolves a number of > > > > issues seen with the basic extlinux menu system on ARMv7. > > > > > > > > == Dependencies == > > > > There are no dependencies. The changes required are artefact output. I > > > > will work with release engineering on this. > > > > > > > > == Contingency Plan == > > > > * Contingency mechanism: Revert back to current extlinux boot process. > > > > The IoT Edition has been supporting this method since Fedora 33 and > > > > it's reported to work fine. We produced prototype > > > > Workstation/Server/Minimal images in Fedora 33 with few issues. > > > > * Contingency deadline: Beta Freeze > > > > * Blocks release? Yes > > > > > > > > == Documentation == > > > > Yes. There will need to be a review of the documentation pertaining to > > > > ARMv7, in a lot of cases this will be deleting the old process so the > > > > universal distribution defaults are the only docs. > > > > > > > > == Release Notes == > > > > To be written once process is complete > > > > > > > > > > > > > Will we also get a shim binary for this? The shim spec file has noted > > > that it's possible to produce one for ARMv7, we just haven't had a > > > need for it yet, since we don't use UEFI for ARM. Now that this is > > > changing, will we get one? > > > > No, currently grub2 provides the expected binary there on ARMv7 and > > ATM shim provides no extra value as there's not current intention to > > provide it. The pieces we have in place have worked quite well for IoT > > on ARMv7. > > > > There has been some mutterings from the arm ecosystem as there's a > > number of companies there interested in secure boot on ARMv7 but I'm > > yet to see any actual commitments in that space. With the ability for > > U-Boot now to support it and the EBBR spec evolving to add it that may > > change later in the year and if that does happen it would be easy > > enough to adjust to add it in. > > Would it
Fedora stand "Welcome Session" chat sign-up for FOSDEM 2021
Next weekend is "FOSDEM [1] weekend" and The Fedora Project is going to be there with a virtual stand! [2] We will have our own stand/ page where people will be able to "pass by" and join the Fedora chat to ask questions. Please keep an eye during the next few days on both the CommunityBlog and Magazine for a blogpost explaining how to join both! For both days, the FOSDEM organizers have set up a "Welcome Session" for each stand at 8:30-9 AM UTC (9:30-10 AM CET). It would be great to have as many Fedorans as possible at this time slot. If this is not super early/ late for you, add your name on the wiki page and join us! [3] Note: if you have a presentation at the conference which is Fedora/ CentOS related to let us know in order to put it on our site and promote it :) Also, it’s not too late to add your videos on Fedora and/or CentOS things! Drop them on this wiki! [1] https://fosdem.org/2021/ [2] https://fedoraproject.org/wiki/FOSDEM_2021 [3] https://fedoraproject.org/wiki/FOSDEM_2021#Fedora_Stand_Welcome_Session_Chat_Sign_Up -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Help wanted] Setting vi/view/vim via alternatives
On 29.01.2021 09:49, Zdenek Dohnal wrote: I'm currently trying to rewrite the current shell aliases for making Vi/View/Vim use the correct compiled binary based on which Vim package is installed. Alternatives are not suitable for Fedora, because they will break immutable Fedora releases due to scriptlets usage. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Rawhide-20210130.n.0 compose check report
Missing expected images: Minimal raw-xz armhfp Xfce raw-xz armhfp Compose FAILS proposed Rawhide gating check! 8 of 43 required tests failed, 8 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 34/181 (x86_64), 40/123 (aarch64) New failures (same test not failed in Fedora-Rawhide-20210129.n.0): ID: 765309 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/765309 ID: 765312 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/765312 ID: 765429 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/765429 ID: 765430 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/765430 ID: 765545 Test: x86_64 Workstation-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/765545 ID: 765546 Test: x86_64 Workstation-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/765546 Old failures (same test failed in Fedora-Rawhide-20210129.n.0): ID: 765236 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/765236 ID: 765241 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/765241 ID: 765253 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/765253 ID: 765254 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/765254 ID: 765257 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/765257 ID: 765263 Test: x86_64 Server-dvd-iso server_cockpit_updates URL: https://openqa.fedoraproject.org/tests/765263 ID: 765264 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/765264 ID: 765265 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/765265 ID: 765267 Test: x86_64 Server-dvd-iso server_cockpit_basic URL: https://openqa.fedoraproject.org/tests/765267 ID: 765290 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/765290 ID: 765331 Test: aarch64 Minimal-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/765331 ID: 765332 Test: aarch64 Minimal-raw_xz-raw.xz base_selinux@uefi URL: https://openqa.fedoraproject.org/tests/765332 ID: 765333 Test: aarch64 Minimal-raw_xz-raw.xz base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/765333 ID: 765334 Test: aarch64 Minimal-raw_xz-raw.xz release_identification@uefi URL: https://openqa.fedoraproject.org/tests/765334 ID: 765340 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi URL: https://openqa.fedoraproject.org/tests/765340 ID: 765343 Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi URL: https://openqa.fedoraproject.org/tests/765343 ID: 765347 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi URL: https://openqa.fedoraproject.org/tests/765347 ID: 765351 Test: aarch64 Server-dvd-iso install_standard_partition_ext4@uefi URL: https://openqa.fedoraproject.org/tests/765351 ID: 765355 Test: aarch64 Server-dvd-iso server_role_deploy_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/765355 ID: 765362 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi URL: https://openqa.fedoraproject.org/tests/765362 ID: 765366 Test: aarch64 Server-dvd-iso install_resize_lvm@uefi URL: https://openqa.fedoraproject.org/tests/765366 ID: 765370 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/765370 ID: 765372 Test: aarch64 Server-dvd-iso modularity_tests@uefi URL: https://openqa.fedoraproject.org/tests/765372 ID: 765374 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi URL: https://openqa.fedoraproject.org/tests/765374 ID: 765380 Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/765380 ID: 765381 Test: aarch64 Server-raw_xz-raw.xz base_selinux@uefi URL: https://openqa.fedoraproject.org/tests/765381 ID: 765382 Test: aarch64 Server-raw_xz-raw.xz base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/765382 ID: 765383 Test: aarch64 Server-raw_xz-raw.xz release_identification@uefi URL: https://openqa.fedoraproject.org/tests/765383 ID: 765403 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/765403 ID: 765408 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/765408 ID: 7654
Re: fedpkg output dir
Fabio Valentini kirjoitti 30.1.2021 klo 12.37:
On Sat, Jan 30, 2021 at 9:19 AM Otto Urpelainen wrote:
Jonathan Wakely kirjoitti 29.1.2021 klo 18.22:
On 29/01/21 17:04 +0100, Miro Hrončok wrote:
On 29. 01. 21 16:03, Jonathan Wakely wrote:
So if fedpkg clone just added things to .git/info/exclude there would
be no need to modify every .gitignore file in every repo on every
active branch.
That is already the case \o/
https://docs.pagure.org/fedpkg/releases/1.37.html#ignore-files-in-a-cloned-repository
Nice! But making 'fedpkg local' unpack into ./build and then build in
there still seems sensible, so the excluded patterns would change for
that (I don't care about that as I don't use 'fedpkg local', but it
seems like a good suggestion).
Since I got bitten by this, I could try to improve it. Suggestion here
seems workable to me. So 1) using ./build in 'fedpkg local' and 2)
adding that directory 'fedpkg clone' excludes. Clearly defined task with
limited scope.
One question that remains is this: 'fedpkg clone' already does what it
does and from this discussion we know that many people are using it. If
the file locations change, changing fedpkg will lead to confusion,
annoyance and perhaps worse. And while I have not seen any scripts using
'fedpkg local', there may be such. Those would break. So perhaps it
should actually be a new command, maybe 'fedpkg localbuild' (to match
'fedpkg mockbuild'), together with documentation update and runtime
deprecation notice when using 'fedpkg local'.
How does that sound? Particularly to all of you who actually use 'fedpkg
local'. I got the understanding that while generally users are happy
with the current behavior, there is no reason why the file generation
paths could not or should not be made more git friendly.
If you're doing something like this, why not have it match what
"fedpkg mockbuild" already does?
Everything (including rebuilt srpm, built rpms, build logs) goes into
./results_%{name}/%{version}/%{release}/
And that directory is already covered by the default exclude rules
generated by "fedpkg clone".
Fabio
That is a good idea.
Otto
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-IoT-34-20210130.0 compose check report
Missing expected images: Iot dvd aarch64 Iot dvd x86_64 Failed openQA tests: 4/16 (x86_64), 8/15 (aarch64) Old failures (same test failed in Fedora-IoT-34-20210129.0): ID: 765593 Test: x86_64 IoT-dvd_ostree-iso podman URL: https://openqa.fedoraproject.org/tests/765593 ID: 765596 Test: x86_64 IoT-dvd_ostree-iso podman_client URL: https://openqa.fedoraproject.org/tests/765596 ID: 765597 Test: x86_64 IoT-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/765597 ID: 765601 Test: x86_64 IoT-dvd_ostree-iso iot_rpmostree_overlay URL: https://openqa.fedoraproject.org/tests/765601 ID: 765605 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/765605 ID: 765607 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/765607 ID: 765608 Test: aarch64 IoT-dvd_ostree-iso podman@uefi URL: https://openqa.fedoraproject.org/tests/765608 ID: 765611 Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi URL: https://openqa.fedoraproject.org/tests/765611 ID: 765612 Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/765612 ID: 765616 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi URL: https://openqa.fedoraproject.org/tests/765616 ID: 765617 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_rebase@uefi URL: https://openqa.fedoraproject.org/tests/765617 ID: 765618 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/765618 Soft failed openQA tests: 1/16 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-34-20210129.0): ID: 765589 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/765589 Passed openQA tests: 11/16 (x86_64), 7/15 (aarch64) Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default@uefi: System load changed from 0.68 to 0.46 Previous test data: https://openqa.fedoraproject.org/tests/765107#downloads Current test data: https://openqa.fedoraproject.org/tests/765590#downloads Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload: System load changed from 0.44 to 0.64 Previous test data: https://openqa.fedoraproject.org/tests/765108#downloads Current test data: https://openqa.fedoraproject.org/tests/765591#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: fedpkg output dir
On Sat, Jan 30, 2021 at 11:37:27AM +0100, Fabio Valentini wrote:
> On Sat, Jan 30, 2021 at 9:19 AM Otto Urpelainen wrote:
> >
> > Jonathan Wakely kirjoitti 29.1.2021 klo 18.22:
> > > On 29/01/21 17:04 +0100, Miro Hrončok wrote:
> > >> On 29. 01. 21 16:03, Jonathan Wakely wrote:
> > >>>
> > >>> So if fedpkg clone just added things to .git/info/exclude there would
> > >>> be no need to modify every .gitignore file in every repo on every
> > >>> active branch.
> > >>
> > >> That is already the case \o/
> > >>
> > >> https://docs.pagure.org/fedpkg/releases/1.37.html#ignore-files-in-a-cloned-repository
> > >>
> > >
> > > Nice! But making 'fedpkg local' unpack into ./build and then build in
> > > there still seems sensible, so the excluded patterns would change for
> > > that (I don't care about that as I don't use 'fedpkg local', but it
> > > seems like a good suggestion).
> > >
> >
> > Since I got bitten by this, I could try to improve it. Suggestion here
> > seems workable to me. So 1) using ./build in 'fedpkg local' and 2)
> > adding that directory 'fedpkg clone' excludes. Clearly defined task with
> > limited scope.
> >
> > One question that remains is this: 'fedpkg clone' already does what it
> > does and from this discussion we know that many people are using it. If
> > the file locations change, changing fedpkg will lead to confusion,
> > annoyance and perhaps worse. And while I have not seen any scripts using
> > 'fedpkg local', there may be such. Those would break. So perhaps it
> > should actually be a new command, maybe 'fedpkg localbuild' (to match
> > 'fedpkg mockbuild'), together with documentation update and runtime
> > deprecation notice when using 'fedpkg local'.
I don't think this is so important. The name of the build directory changes
with each package version and build architecture, so it would be awkward to
use in a script. I'd just an an option to 'local', something like
--location=cwd|subdir, and maybe initially keep the default unchanged, and
later flip the default once the new paths have become established.
> > How does that sound? Particularly to all of you who actually use 'fedpkg
> > local'. I got the understanding that while generally users are happy
> > with the current behavior, there is no reason why the file generation
> > paths could not or should not be made more git friendly.
> If you're doing something like this, why not have it match what
> "fedpkg mockbuild" already does?
> Everything (including rebuilt srpm, built rpms, build logs) goes into
> ./results_%{name}/%{version}/%{release}/
> And that directory is already covered by the default exclude rules
> generated by "fedpkg clone".
It would be great to make 'fedpkg local' use the same output dirs are 'fedpkg
mockbuild'.
The difference between the workflows is annoying.
Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: uEFI for ARMv7 (Self-Contained Change proposal)
On Sat, Jan 30, 2021 at 6:43 AM Peter Robinson wrote: > > On Sat, Jan 30, 2021 at 11:28 AM Neal Gompa wrote: > > > > On Mon, Jan 18, 2021 at 10:21 AM Ben Cotton wrote: > > > > > > https://fedoraproject.org/wiki/Changes/ARMv7UEFI > > > > > > == Summary == > > > > > > Move ARMv7 to use UEFI as default for all armhfp generated images > > > > > > == Owner == > > > * Name: [[User:pbrobinson| Peter Robinson]] > > > * Email: pbrobinson at fedoraproject dot org > > > > > > > > > == Detailed Description == > > > > > > In Fedora 30 we tried to move ARMv7 to UEFI and as part of that change > > > we got all the infrastructure changes in place as described in that > > > change. It turned out there were issues with upstream kernel, > > > bootloaders and a number of other pieces out of our control. Those > > > pieces of the puzzle are now fixed and we've been building the core > > > pieces since before Fedora 33 so we know it's now fixed and working > > > having engaged with upstream since. > > > > > > == Benefit to Fedora == > > > > > > This allows ARMv7 to move to grub2 providing the same experience to > > > ARMv7 users as all other architectures across the distribution. It > > > simplifies a number of software stacks across the distribution due to > > > being able to use a single install/support/upgrade path as well as > > > providing a single set of docs. > > > > > > == Scope == > > > * Proposal owners: Changes to kickstarts. > > > * Other developers: None, all the required changes landed as part of > > > the prior feature, this is just flipping the switch. > > > * Release engineering: [https://pagure.io/releng/issue/9946 #9946] (a > > > check of an impact with Release Engineering is needed) > > > * Policies and guidelines: N/A > > > * Trademark approval: N/A (not needed for this Change) > > > > > > > > > == Upgrade/compatibility impact == > > > Upgrades from prior versions of Fedora will continue to work as they > > > do currently. Devices booting with extlinux will continue to upgrade > > > and work as planned. For recent (F-25 and later) clean installs there > > > will be a documented migration process for those that wish to migrate > > > to grub2 boot process. For older installs (those without a VFAT > > > partition for firmware) will need to do a clean install. Devices with > > > non Fedora built u-boot will need to ensure they have a recent enough > > > u-boot to support the required uEFI functionality. > > > > > > == How To Test == > > > The process for testing will be the same as aarch64. This standardises > > > the arm architectures ultimately making things more straight forward > > > and eventually allowing code clean up. > > > > > > == User Experience == > > > The user experience will be the same as uEFI on aarch64 and x86_64 > > > with the grub2 menu and features. This will provide a consistent > > > experience across all Fedora architectures and resolves a number of > > > issues seen with the basic extlinux menu system on ARMv7. > > > > > > == Dependencies == > > > There are no dependencies. The changes required are artefact output. I > > > will work with release engineering on this. > > > > > > == Contingency Plan == > > > * Contingency mechanism: Revert back to current extlinux boot process. > > > The IoT Edition has been supporting this method since Fedora 33 and > > > it's reported to work fine. We produced prototype > > > Workstation/Server/Minimal images in Fedora 33 with few issues. > > > * Contingency deadline: Beta Freeze > > > * Blocks release? Yes > > > > > > == Documentation == > > > Yes. There will need to be a review of the documentation pertaining to > > > ARMv7, in a lot of cases this will be deleting the old process so the > > > universal distribution defaults are the only docs. > > > > > > == Release Notes == > > > To be written once process is complete > > > > > > > > > Will we also get a shim binary for this? The shim spec file has noted > > that it's possible to produce one for ARMv7, we just haven't had a > > need for it yet, since we don't use UEFI for ARM. Now that this is > > changing, will we get one? > > No, currently grub2 provides the expected binary there on ARMv7 and > ATM shim provides no extra value as there's not current intention to > provide it. The pieces we have in place have worked quite well for IoT > on ARMv7. > > There has been some mutterings from the arm ecosystem as there's a > number of companies there interested in secure boot on ARMv7 but I'm > yet to see any actual commitments in that space. With the ability for > U-Boot now to support it and the EBBR spec evolving to add it that may > change later in the year and if that does happen it would be easy > enough to adjust to add it in. Would it be too much extra work to see if we can get that added as part of the next rev of the shim package? We already know one is coming in about a month, so it'd be nice to just get that in place regardless if possible. -- 真実はいつも一つ！/ Always, there's only one truth! _
Re: Fedora rawhide compose report: 20210129.n.0 changes
On 30. 01. 21 0:16, Fabio Valentini wrote: On Fri, Jan 29, 2021 at 2:49 PM Fedora Rawhide Report wrote: (snip) Package: golang-torproject-pluggable-transports-goptlib-1.1.0-6.fc34 Old package: golang-torproject-pluggable-transports-goptlib-1.1.0-5.fc33 Summary: Library for writing Tor pluggable transports in Go RPMs: golang-torproject-pluggable-transports-goptlib-devel Size: 37.12 KiB Size change: 129 B Changelog: * Tue Jan 26 2021 Fedora Release Engineering - 1.1.0-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild What's going on here? This is one of a lot of packages that only have the mass rebuild changelog entry but no other changes, and have not been built by releng, but by other packagers, according to koji. Did people resubmit failed mass rebuild builds themselves (and not for f34-build)? I thought there's going to be an official second round of builds to weed out transient issues? Yes and yes. Both can happen. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: uEFI for ARMv7 (Self-Contained Change proposal)
On Sat, Jan 30, 2021 at 11:28 AM Neal Gompa wrote: > > On Mon, Jan 18, 2021 at 10:21 AM Ben Cotton wrote: > > > > https://fedoraproject.org/wiki/Changes/ARMv7UEFI > > > > == Summary == > > > > Move ARMv7 to use UEFI as default for all armhfp generated images > > > > == Owner == > > * Name: [[User:pbrobinson| Peter Robinson]] > > * Email: pbrobinson at fedoraproject dot org > > > > > > == Detailed Description == > > > > In Fedora 30 we tried to move ARMv7 to UEFI and as part of that change > > we got all the infrastructure changes in place as described in that > > change. It turned out there were issues with upstream kernel, > > bootloaders and a number of other pieces out of our control. Those > > pieces of the puzzle are now fixed and we've been building the core > > pieces since before Fedora 33 so we know it's now fixed and working > > having engaged with upstream since. > > > > == Benefit to Fedora == > > > > This allows ARMv7 to move to grub2 providing the same experience to > > ARMv7 users as all other architectures across the distribution. It > > simplifies a number of software stacks across the distribution due to > > being able to use a single install/support/upgrade path as well as > > providing a single set of docs. > > > > == Scope == > > * Proposal owners: Changes to kickstarts. > > * Other developers: None, all the required changes landed as part of > > the prior feature, this is just flipping the switch. > > * Release engineering: [https://pagure.io/releng/issue/9946 #9946] (a > > check of an impact with Release Engineering is needed) > > * Policies and guidelines: N/A > > * Trademark approval: N/A (not needed for this Change) > > > > > > == Upgrade/compatibility impact == > > Upgrades from prior versions of Fedora will continue to work as they > > do currently. Devices booting with extlinux will continue to upgrade > > and work as planned. For recent (F-25 and later) clean installs there > > will be a documented migration process for those that wish to migrate > > to grub2 boot process. For older installs (those without a VFAT > > partition for firmware) will need to do a clean install. Devices with > > non Fedora built u-boot will need to ensure they have a recent enough > > u-boot to support the required uEFI functionality. > > > > == How To Test == > > The process for testing will be the same as aarch64. This standardises > > the arm architectures ultimately making things more straight forward > > and eventually allowing code clean up. > > > > == User Experience == > > The user experience will be the same as uEFI on aarch64 and x86_64 > > with the grub2 menu and features. This will provide a consistent > > experience across all Fedora architectures and resolves a number of > > issues seen with the basic extlinux menu system on ARMv7. > > > > == Dependencies == > > There are no dependencies. The changes required are artefact output. I > > will work with release engineering on this. > > > > == Contingency Plan == > > * Contingency mechanism: Revert back to current extlinux boot process. > > The IoT Edition has been supporting this method since Fedora 33 and > > it's reported to work fine. We produced prototype > > Workstation/Server/Minimal images in Fedora 33 with few issues. > > * Contingency deadline: Beta Freeze > > * Blocks release? Yes > > > > == Documentation == > > Yes. There will need to be a review of the documentation pertaining to > > ARMv7, in a lot of cases this will be deleting the old process so the > > universal distribution defaults are the only docs. > > > > == Release Notes == > > To be written once process is complete > > > > > Will we also get a shim binary for this? The shim spec file has noted > that it's possible to produce one for ARMv7, we just haven't had a > need for it yet, since we don't use UEFI for ARM. Now that this is > changing, will we get one? No, currently grub2 provides the expected binary there on ARMv7 and ATM shim provides no extra value as there's not current intention to provide it. The pieces we have in place have worked quite well for IoT on ARMv7. There has been some mutterings from the arm ecosystem as there's a number of companies there interested in secure boot on ARMv7 but I'm yet to see any actual commitments in that space. With the ability for U-Boot now to support it and the EBBR spec evolving to add it that may change later in the year and if that does happen it would be easy enough to adjust to add it in. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: uEFI for ARMv7 (Self-Contained Change proposal)
On Mon, Jan 18, 2021 at 10:21 AM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/ARMv7UEFI > > == Summary == > > Move ARMv7 to use UEFI as default for all armhfp generated images > > == Owner == > * Name: [[User:pbrobinson| Peter Robinson]] > * Email: pbrobinson at fedoraproject dot org > > > == Detailed Description == > > In Fedora 30 we tried to move ARMv7 to UEFI and as part of that change > we got all the infrastructure changes in place as described in that > change. It turned out there were issues with upstream kernel, > bootloaders and a number of other pieces out of our control. Those > pieces of the puzzle are now fixed and we've been building the core > pieces since before Fedora 33 so we know it's now fixed and working > having engaged with upstream since. > > == Benefit to Fedora == > > This allows ARMv7 to move to grub2 providing the same experience to > ARMv7 users as all other architectures across the distribution. It > simplifies a number of software stacks across the distribution due to > being able to use a single install/support/upgrade path as well as > providing a single set of docs. > > == Scope == > * Proposal owners: Changes to kickstarts. > * Other developers: None, all the required changes landed as part of > the prior feature, this is just flipping the switch. > * Release engineering: [https://pagure.io/releng/issue/9946 #9946] (a > check of an impact with Release Engineering is needed) > * Policies and guidelines: N/A > * Trademark approval: N/A (not needed for this Change) > > > == Upgrade/compatibility impact == > Upgrades from prior versions of Fedora will continue to work as they > do currently. Devices booting with extlinux will continue to upgrade > and work as planned. For recent (F-25 and later) clean installs there > will be a documented migration process for those that wish to migrate > to grub2 boot process. For older installs (those without a VFAT > partition for firmware) will need to do a clean install. Devices with > non Fedora built u-boot will need to ensure they have a recent enough > u-boot to support the required uEFI functionality. > > == How To Test == > The process for testing will be the same as aarch64. This standardises > the arm architectures ultimately making things more straight forward > and eventually allowing code clean up. > > == User Experience == > The user experience will be the same as uEFI on aarch64 and x86_64 > with the grub2 menu and features. This will provide a consistent > experience across all Fedora architectures and resolves a number of > issues seen with the basic extlinux menu system on ARMv7. > > == Dependencies == > There are no dependencies. The changes required are artefact output. I > will work with release engineering on this. > > == Contingency Plan == > * Contingency mechanism: Revert back to current extlinux boot process. > The IoT Edition has been supporting this method since Fedora 33 and > it's reported to work fine. We produced prototype > Workstation/Server/Minimal images in Fedora 33 with few issues. > * Contingency deadline: Beta Freeze > * Blocks release? Yes > > == Documentation == > Yes. There will need to be a review of the documentation pertaining to > ARMv7, in a lot of cases this will be deleting the old process so the > universal distribution defaults are the only docs. > > == Release Notes == > To be written once process is complete > Will we also get a shim binary for this? The shim spec file has noted that it's possible to produce one for ARMv7, we just haven't had a need for it yet, since we don't use UEFI for ARM. Now that this is changing, will we get one? -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora rawhide compose report: 20210130.n.0 changes
OLD: Fedora-Rawhide-20210129.n.0 NEW: Fedora-Rawhide-20210130.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 10 Dropped packages:0 Upgraded packages: 134 Downgraded packages: 0 Size of added packages: 115.61 MiB Size of dropped packages:0 B Size of upgraded packages: 2.59 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 122.77 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: efifs-1.7-2.fc34 Summary: Free software EFI/UEFI standalone file system drivers RPMs:efifs Size:589.61 KiB Package: golang-github-cockroachdb-gostdlib-1.13.0-1.fc34 Summary: Vendor-friendly Go standard library packages RPMs:golang-github-cockroachdb-gostdlib-devel Size:246.89 KiB Package: golang-github-containerd-nri-0-0.1.20210129git7669bcb.fc34 Summary: Node Resource Interface RPMs:golang-github-containerd-nri-devel Size:18.45 KiB Package: golang-github-containerd-stargz-snapshotter-0.3.0-2.fc34 Summary: Fast docker image distribution plugin for containerd, based on CRFS/stargz RPMs:golang-github-containerd-stargz-snapshotter golang-github-containerd-stargz-snapshotter-devel golang-github-containerd-stargz-snapshotter-estargz-devel Size:70.86 MiB Package: golang-github-dave-dst-0.26.2-1.fc34 Summary: Manipulate Go source with perfect fidelity RPMs:golang-github-dave-dst golang-github-dave-dst-devel Size:7.37 MiB Package: golang-github-google-containerregistry-0.4.0-1.fc34 Summary: Go library and CLIs for working with container registries RPMs:golang-github-google-containerregistry golang-github-google-containerregistry-devel Size:30.15 MiB Package: golang-github-gorhill-cronexpr-1.0.0-1.fc34 Summary: Cron expression parser in Go language RPMs:golang-github-gorhill-cronexpr golang-github-gorhill-cronexpr-devel Size:3.49 MiB Package: golang-github-pierrre-compare-1.0.2-1.fc34 Summary: Comparison library for Golang RPMs:golang-github-pierrre-compare-devel Size:17.38 KiB Package: golang-github-pierrre-geohash-1.0.0-1.fc34 Summary: Geohash library for Go RPMs:golang-github-pierrre-geohash golang-github-pierrre-geohash-devel Size:2.88 MiB Package: golang-github-zabawaba99-gitignore-0-0.1.20210130git39e6bdd.fc34 Summary: Gitignore implementation in Go RPMs:golang-github-zabawaba99-gitignore-devel Size:15.51 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: FAudio-21.01-1.fc34 Old package: FAudio-20.12-1.fc34 Summary: FNA is a reimplementation of the Microsoft XNA Game Studio 4.0 Refresh libraries RPMs: libFAudio libFAudio-devel Size: 826.66 KiB Size change: -11.20 KiB Changelog: * Mon Jan 25 2021 Fedora Release Engineering - 20.12-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Fri Jan 29 2021 Michael Cronenworth - 21.01-1 - Update to 21.01 Package: Field3D-1.7.3-9.fc34 Old package: Field3D-1.7.3-7.fc34 Summary: Library for storing voxel data RPMs: Field3D Field3D-devel Size: 9.41 MiB Size change: 3.03 KiB Changelog: * Mon Jan 25 2021 Fedora Release Engineering - 1.7.3-8 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Fri Jan 29 2021 Richard Shaw - 1.7.3-9 - Add openexr to build requirements. Package: OpenImageIO-2.2.10.1-3.fc34 Old package: OpenImageIO-2.2.10.1-1.fc34 Summary: Library for reading and writing images RPMs: OpenImageIO OpenImageIO-devel OpenImageIO-iv OpenImageIO-utils python3-openimageio Size: 20.72 MiB Size change: 116.25 KiB Changelog: * Fri Jan 22 2021 Jonathan Wakely - 2.2.10.1-2 - Rebuilt for Boost 1.75 * Mon Jan 25 2021 Fedora Release Engineering - 2.2.10.1-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild Package: SuperLU-5.2.2-1.fc34 Old package: SuperLU-5.2.1-14.fc33 Summary: Subroutines to solve sparse linear systems RPMs: SuperLU SuperLU-devel SuperLU-doc Size: 2.04 MiB Size change: 55.31 KiB Changelog: * Mon Jan 25 2021 Fedora Release Engineering - 5.2.1-15 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Thu Jan 28 2021 Antonio Trande - 5.2.2-1 - Release 5.2.2 Package: adobe-source-serif-pro-fonts-4.004-1.fc34 Old package: adobe-source-serif-pro-fonts-3.001-3.fc33 Summary: Typeface for setting text in many sizes, weights, and languages RPMs: adobe-source-serif-pro-fonts Size: 4.72 MiB Size change: 3.75 MiB Changelog: * Mon Jan 25 2021 Fedora Release Engineering - 3.001-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Fri Jan 29 2021 Michael Kuhn - 4.004-1 - Update to 4.004 Package: apitrace-9.0-0.12.git37c36e6.fc34 Old package: apitrace-9.0-0.10.git1aa8391.fc34 Summary: Tools for tracing OpenGL
Re: fedpkg output dir
On Sat, Jan 30, 2021 at 9:19 AM Otto Urpelainen wrote:
>
> Jonathan Wakely kirjoitti 29.1.2021 klo 18.22:
> > On 29/01/21 17:04 +0100, Miro Hrončok wrote:
> >> On 29. 01. 21 16:03, Jonathan Wakely wrote:
> >>>
> >>> So if fedpkg clone just added things to .git/info/exclude there would
> >>> be no need to modify every .gitignore file in every repo on every
> >>> active branch.
> >>
> >> That is already the case \o/
> >>
> >> https://docs.pagure.org/fedpkg/releases/1.37.html#ignore-files-in-a-cloned-repository
> >>
> >
> > Nice! But making 'fedpkg local' unpack into ./build and then build in
> > there still seems sensible, so the excluded patterns would change for
> > that (I don't care about that as I don't use 'fedpkg local', but it
> > seems like a good suggestion).
> >
>
> Since I got bitten by this, I could try to improve it. Suggestion here
> seems workable to me. So 1) using ./build in 'fedpkg local' and 2)
> adding that directory 'fedpkg clone' excludes. Clearly defined task with
> limited scope.
>
> One question that remains is this: 'fedpkg clone' already does what it
> does and from this discussion we know that many people are using it. If
> the file locations change, changing fedpkg will lead to confusion,
> annoyance and perhaps worse. And while I have not seen any scripts using
> 'fedpkg local', there may be such. Those would break. So perhaps it
> should actually be a new command, maybe 'fedpkg localbuild' (to match
> 'fedpkg mockbuild'), together with documentation update and runtime
> deprecation notice when using 'fedpkg local'.
>
> How does that sound? Particularly to all of you who actually use 'fedpkg
> local'. I got the understanding that while generally users are happy
> with the current behavior, there is no reason why the file generation
> paths could not or should not be made more git friendly.
If you're doing something like this, why not have it match what
"fedpkg mockbuild" already does?
Everything (including rebuilt srpm, built rpms, build logs) goes into
./results_%{name}/%{version}/%{release}/
And that directory is already covered by the default exclude rules
generated by "fedpkg clone".
Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
fedpkg output dir
Jonathan Wakely kirjoitti 29.1.2021 klo 18.22: On 29/01/21 17:04 +0100, Miro Hrončok wrote: On 29. 01. 21 16:03, Jonathan Wakely wrote: So if fedpkg clone just added things to .git/info/exclude there would be no need to modify every .gitignore file in every repo on every active branch. That is already the case \o/ https://docs.pagure.org/fedpkg/releases/1.37.html#ignore-files-in-a-cloned-repository Nice! But making 'fedpkg local' unpack into ./build and then build in there still seems sensible, so the excluded patterns would change for that (I don't care about that as I don't use 'fedpkg local', but it seems like a good suggestion). Since I got bitten by this, I could try to improve it. Suggestion here seems workable to me. So 1) using ./build in 'fedpkg local' and 2) adding that directory 'fedpkg clone' excludes. Clearly defined task with limited scope. One question that remains is this: 'fedpkg clone' already does what it does and from this discussion we know that many people are using it. If the file locations change, changing fedpkg will lead to confusion, annoyance and perhaps worse. And while I have not seen any scripts using 'fedpkg local', there may be such. Those would break. So perhaps it should actually be a new command, maybe 'fedpkg localbuild' (to match 'fedpkg mockbuild'), together with documentation update and runtime deprecation notice when using 'fedpkg local'. How does that sound? Particularly to all of you who actually use 'fedpkg local'. I got the understanding that while generally users are happy with the current behavior, there is no reason why the file generation paths could not or should not be made more git friendly. Otto ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
