Summary/Minutes from today's FESCo Meeting (2019-05-31)
by Zbigniew Jędrzejewski-Szmek
I forgot to send out the agenda today, so this summary includes both tickets
approved in the meeting and outside.
= Discussed and Voted in the Ticket =
#2134 F31 System-Wide Change: Perl 5.30
https://pagure.io/fesco/issue/2134
APPROVED (+7, 0, 0)
#2131 F31 System-Wide Change: MinGW environment and toolchain update
https://pagure.io/fesco/issue/2131
APPROVED (+4, 0, 0)
#2130 Exception request: Use Python 2.7 to build PyPy (2 & 3)
https://pagure.io/fesco/issue/2130
APPROVED (+4, 1, 0)
#2129 knot / knot-resolver package rebase exception request
https://pagure.io/fesco/issue/2129
APPROVED for Fedora. EPSCo should decide for EPEL (+3, 0, 0)
= Discussed and Voted in the Meeting =
#2137 Bodhi 4 to stable releases?
https://pagure.io/fesco/issue/2137
The proposal in https://pagure.io/fesco/issue/2137#comment-573003 is
APPROVED (+5, 0, 0).
= Summary =
Meeting started by zbyszek at 15:01:27 UTC. The full logs are available at
https://meetbot.fedoraproject.org/fedora-meeting/2019-05-31/fesco.2019-05...
Meeting summary
---------------
* init process (zbyszek, 15:01:30)
* #2137 Bodhi 4 to stable releases? (zbyszek, 15:08:26)
* LINK: https://pagure.io/fesco/issue/2137 (zbyszek, 15:08:40)
* ACTION: zbyszek to chair next week's meeting (zbyszek, 15:10:14)
* ACTION: zbyszek to remember to send out the agenda (zbyszek,
15:10:25)
* Open floor (zbyszek, 15:10:42)
* #2140 F31 System-Wide Change: RPM 4.15 (zbyszek, 15:17:47)
* LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1693751#c8 here
the issue for fedpkg was reported too. And it was in 4.14 minor
update (bookwar, 15:26:24)
* Open Floor (again) (zbyszek, 15:29:01)
Meeting ended at 15:44:31 UTC.
Action Items
------------
* zbyszek to chair next week's meeting
* zbyszek to remember to send out the agenda
People Present (lines said)
---------------------------
* zbyszek (45)
* bowlofeggs (23)
* ignatenkobrain (17)
* zodbot (17)
* sgallagh (16)
* bookwar (12)
* nirik (10)
* bcotton (4)
* mhroncok (0)
* jforbes (0)
* otaylor (0)
* contyk (0)
Minutes: https://meetbot.fedoraproject.org/fedora-meeting/2019-05-31/fesco.2019-05...
Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting/2019-05-31/fesco.2019-05...
Log: https://meetbot.fedoraproject.org/fedora-meeting/2019-05-31/fesco.2019-05...
5 years
Copr builders moved to Fedora 30, added AARCH64 support
by Pavel Raiskup
Hello, fyi,
Fedora Copr builders were recently upgraded to Fedora 30 (from F28).
The major change is that `yum` package is not working ideally on F30
anymore, and soon (on F31) there will be no `yum` at all [1].
Mock (which is used on builders) though uses /usr/bin/yum-deprecated (yum)
by default for epel* chroots installation usually (on Fedora host), even
though it may use /usr/bin/yum symlink to /usr/bin/dnf as a fallback.
The major difference from mock perspective (and why yum-deprecated is
actually preferred, when available) is that dnf might calculate the
install transactions a little bit differently from yum. And repositories
for epel are designed for/tested against yum; ... so using dnf can cause
some unexpected problems..
We decided to move to dnf (dnf-yum) rather sooner in Copr, to have a bit
more time for solving potential problems, and inform others. So if you
face any related issues to this movement in copr (packages were installed
fine before, but are not now), you might want to enable the
bootstrap_chroot feature in your copr project; go to:
Project -> Settings
-> [x] Enable mock's use_bootstrap_container experimental feature
.. and if useful, fill a bug report. For more info about bootstrap_chroot
feature consult the man 1 mock.
As a bonus, we now have builders (F30) for aarch64 architecture! Expect
slightly slower queue processing there than on other architectures (only
up 8 builders, and slightly slower boxes). Feel free to try them, and - as
always - please report the issues :-)
If you happen to work with epel* and mock on F30:
- yum.rpm requires up2date urlgrabber package (rhbz#1707657) on highly
python3-oriented F30, and to avoid unnecessary hassle you might want
to rather uninstall yum package, but when you do this..
- using dnf (/bin/yum) for epel* builds might lead to problems with
bootstrap chroot installation (elfutils from DTS from sclo* repos
installed instead of default elfutils) [2]
- also systemd-resolved running on host (even when it is unused) might
cause some problems with name resolution in --bootstrap chroot, resp.
if you happen to use --enable-network; work-around is to disable
systemd-resolved.service
[1] https://src.fedoraproject.org/rpms/yum/blob/master/f/dead.package
[2] https://github.com/rpm-software-management/mock/pull/268
Hope that the transition will be smooth, happy building!
Pavel
5 years
Gating tests from tarball in Fedora - how to set up them?
by Jan Tulak
Hi guys
I'm trying to enable gating tests for package system-storage-manager.
The tarball contains upstream tests and I would like to use these
(with the ability to apply patches to them, same as to the rest of the
code). I have a gating.yaml and tests.yml that works in RHEL exactly
as I want it, but when I try to apply them to Fedora, I can't get it
to work.
It looks as the tests are not included in the VM built for the test.
If I change tests.yml and use only "run: some_system_command," then
the system command is executed.
My tests.yml looks very similar to swid-tools, where it works
(according to jenkins logs), so I'm cc-ing Jan Pazdziora just in case.
(Jan, sorry for two emails, the first one bounced back from the list.)
I tried to find some solution on
https://docs.fedoraproject.org/en-US/ci/ (and subpages), but if it is
there, I didn't notice. I also found some other pages as
https://docs.pagure.org/greenwave/package-specific-policies.html, with
the same result.
I'm using this PR to start the tests:
https://src.fedoraproject.org/rpms/system-storage-manager/pull-request/1
A failed run: https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/je...
Any ideas what I'm doing wrong? gating.yaml and tests.yml bellow.
Thanks
Jan
--------------------------
File tests/tests.yml:
---
- hosts: localhost
roles:
# Fetch source tarball and unpack it into the test environment
- role: standard-test-source
tags:
- always
- role: standard-test-basic
tags:
- atomic
- classic
required_packages:
- lvm2
- cryptsetup
tests:
- smoke: # Run tests
dir: ./source/
run: ./test.py --system --logs
--------------------------
File gating.yml:
--- !Policy
product_versions:
- fedora-*
decision_context: bodhi_update_push_testing # was osci_compose_gate
rules:
- !PassingTestCaseRule {test_case_name: osci.brew-build.tier0.functional}
I tried to replace the osci.brew-build.tier0.functional with some
build.foo cases, but it didn't change anything.
--
Jan Tulak
5 years
Orphaned crypto-utils
by Joe Orton
I've orphaned crypto-utils. If there is any interest in keeping
/usr/bin/certwatch I created a new upstream for that so could revive
it as a new package without all the other stuff which accumulated in
crypto-utils, let me know.
Regards, Joe
5 years
xindy, texlive, and concurrency
by Jerry James
I finally found some time to look at the xindy failure to build.
First, let me say that I've got a workaround for the problem, which
resulted in the beautiful green colors in this xindy-enabled scratch
build of texlive-base:
https://koji.fedoraproject.org/koji/taskinfo?taskID=34877270
When the build process reached the xindy part of the build, it would
successfully build xindy itself, then go to work on some
documentation. This involved invoking latex on several input files.
This marked the first (and possibly only) point in the build where
latex was invoked, so latex.fmt had not yet been generated. Since we
build with %{?_smp_mflags}, several independent threads invoked latex
at approximately the same time. Every one of those invocations
detected that latex.fmt was missing and tried to generate it.
If you got lucky, each one of those threads would generate latex.fmt,
then quickly consume it as it ran on its appointed input file. If you
didn't get lucky, one or more threads would start reading latex.fmt
after some other thread started writing it, but before it finished
writing it all the way. That's why xindy would sometimes build and
sometimes fail to build: the build process had a race condition.
It is unfortunate that texlive is smart enough to detect missing
format files and generate them, but not smart enough to stop that from
happening multiple times concurrently. Anyway, poor xindy has been
maligned: none of this was xindy's fault, nor clisp's. We, the Fedora
packagers, threw concurrency at a job that lacked concurrency control.
And the whole xindy_arches thing is useless: this is not an
arch-specific problem, so removing random arches from the build
accomplishes nothing.
The workaround is to invoke latex on a dummy input file early in
%build. This causes latex.fmt to be generated, and then everything is
hunky-dory when xindy is built later.
My recommendation is to remove the xindy_arches conditional from the
texlive-base and texlive spec files. Make it unconditionallly on
again. Then insert something like this at the top of %build:
# Make texlive generate latex.fmt, so that multiple threads do not race to
# make it during the xindy build.
cat > dummy.tex << EOF
\documentclass{article}
\begin{document}
This is a document.
\end{document}
EOF
latex dummy.tex
rm -f dummy.*
That is the substance of this pull request:
https://src.fedoraproject.org/rpms/texlive-base/pull-request/6
Also, I should be able to push a clisp build with s390x support to F30
stable tomorrow. I, personally, would really appreciate having xindy
reappear in F30, due to Sphinx assuming it is available.
Regards,
--
Jerry James
http://www.jamezone.org/
5 years
Wiki page correction: GRUB2
by Michal Schorm
Hello,
I'd like to propose tiny correction for the Fedora wiki page about GRUB2 [1].
However I'm not confident enought to edit it prior to any discussions,
so that's why I'm writing here.
In the chapter "Updating GRUB 2 configuration on UEFI systems"
In the section "Install the bootloader files"
I believe, there should be an information added, that the 'grub2-efi'
package *must* match your architecture. So e.g. for x86_64, you want
the 'grub2-efi-x64' package.
By default the 'dnf install grub2-efi' will find 'grub2-efi-ia32'
package which doesn't contain the files you need for boot on x86_64
system, nor pulls the correct package as a dependency.
Also, on once of my old F28 Cinnamon system, I can see, that there are packages:
$ dnf list installed | grep grub2-efi | awk '{ print $1 }'
grub2-efi-ia32.x86_64
grub2-efi-ia32-cdboot.x86_64
grub2-efi-x64.x86_64
grub2-efi-x64-cdboot.x86_64
but I believe I only need the 'grub2-efi-x64.x86_64'.
Given that, maybe the anaconda installation should be checked to not
pull uneeded packages?
Correct me, if I'm wrong, thanks.
[1] https://fedoraproject.org/wiki/GRUB_2
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
5 years
requesting feedback on Mock default
by Miroslav Suchý
Hi,
you - fedora developers - are most significant users of Mock. Therefore I would like to ask you about feedback on:
https://github.com/rpm-software-management/mock/issues/266
The summary is:
Previously all output - both stdout and stderr - were mixed together. Like you will get on normal console.
Nowadays, if there is output to stderr, mock will prefix it with BUILDSTDER to indicate that it is coming from stdout.
I can definitely make this configurable. That is easy. The question is, what should be the default? Prefix the stderr?
Or print it without the prefix and mix stdout and stderr together?
I would love to hear your opinion. Either here in the mailing list or directly in the issue mentioned above.
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
5 years
