Help with LDFLAGS for a golang package
by Jérémy Bertozzi
Hello,
I am trying to build a golang package in COPR, before opening the BZ for
inclusion into fedora.
go2rpm does almost everything, expect setting a LDFLAG needed for the
binary to display the appropriate binary version [1].
When I build locally using mock (with a default config), the binary within
the RPM generated is displaying the appropriate version.
When I install the package from the COPR repository (built using the same
SRPM), the binary is different and prints a version "dev build", like if
the LDFLAG was ignored.
Looking at the build.log [2], we can see the LDFLAG is set during the
gobuild command.
I suspected some cache at the COPR repository level, so I tried to clean
everything and rebuild it. Same result.
At this point I am a bit lost. Anybody to give some hint?
My spec file and my SRPM can be found here. [3]
Thanks in advance for your help.
Jérémy
[1] https://github.com/ivaaaan/smug/blob/v0.2.2/Makefile
[2]
https://download.copr.fedorainfracloud.org/results/jbertozzi/smug/fedora-...
[3] https://github.com/jbertozzi/copr-build-smug
3 years, 1 month
Upgrade to Fedora 34 broke the boot menu.
by Björn Persson
I used yum system-upgrade to upgrade from Fedora 32 to Fedora 34. Now
Grub complains about not finding some theme files, and then displays a
menu with two kernels from Fedora 29 and a rescue entry from Fedora 28.
If I choose one of the Fedora 29 entries, then Grub unsurprisingly
fails to find the kernel. The rescue entry actually boots to some kind
of shell, after printing lots of timeout messages, but getting from
there to a working system will be a major research project for me.
The menu also has entries for "advanced flags" (or something like that;
not sure what it would be in English) and "tboot". Both lead to other
menus with boot entries from Fedora 25.
The boot partition contains three sets of vmlinuz, initramfs, config
and System.map files – one fc34 set and two fc32 sets as expected – but
Grub has apparently reverted to a years-old boot menu program.
Which component in Bugzilla might be responsible for this mess?
Björn Persson
3 years, 1 month
Re: Self Introduction: Stefano Prina
by Felix Schwarz
Hi Stefano,
a few months ago certbot switched to Python 3 only. certbot on EPEL 7 still uses
Python 2 because EPEL 7 does not have all required Python 3 packages. So we need
to bring the missing packages to EPEL 7.
The main bug for this is:
https://bugzilla.redhat.com/show_bug.cgi?id=1797129
(Click on "TreeView+ depends on" / "Expand all")
As you can see I already added quite a few packages but some are still missing
(the list is probably incomplete but we need less than 10 additional packages).
- If python-X is in RHEL and does not offer a Python 3 version, we need to
create a new python3-X package (new package review).
- Package is in EPEL but Python 2 only
- is version recent enough for certbot?
-> submit pull request for package to build also a Python 3 version.
otherwise: create new review request for python3-X in EPEL 7.
- python3-X is already in RHEL or EPEL but too old.
-> tricky case, we need to check if certbot also works with the older version.
- once we know that it works we should file a bug upstream to relax the
requirements
From the top of my head:
- python3-augeas (bug 1823761), there is a non-responsive maintainer process at
the moment for the Fedora maintainer. Once there is an active maintainer again
I hope to (s)he will update the Fedora package so we can add that latest
version to EPEL.
- python-certbot-dns-route53:
- requires python3-boto3, python3-botocore
- need to package new versions
- python-dns-lexicon
- requires boto3, PyYAML
I didn't have time to work on that for many months now so I'm not sure what is
the best place to start.
However I created a COPR repo which contains some Python 3 packages:
https://copr.fedorainfracloud.org/coprs/fschwarz/certbot-python3-epel7/
So probably you could start by getting python-dns-lexicon 3.3.28 packaged for
EPEL 7 + Python 3.
I hope the long email does not deter you - in the end you do one step after the
next. The email is only so long because I don't have the exact state in my head
anymore so it takes longer to explain.
Please let me know if you are still interested so I can check for local changes
so you don't have to duplicate work.
Felix
PS: I just noticed that I had to disable some tests in python-dns-lexicon
(rawhide). If you know Python maybe you also want to check how to run more of
these tests (without new dependencies).
3 years, 1 month
Preparing grpc 1.37.1 in Rawhide (with so-version bumps)
by Benjamin Beasley
I am preparing to update grpc in Fedora Rawhide (35) to version 1.37.1. This
includes the following subpackages:
• grpc
• grpc-data
• grpc-doc
• grpc-cpp
• grpc-plugins
• grpc-cli
• grpc-devel
• python3-grpcio
• python3-grpcio-tools
• python3-grpcio-channelz
• python3-grpcio-health-checking
• python3-grpcio-reflection
• python3-grpcio-status
• python3-grpcio-testing
The C API/ABI so-version will be bumped to “15”, and the C++ API/ABI so-version
to “1”. Additionally, for compatibility with the system copy of abseil-cpp, the
C++ libraries are now built with C++17, which may affect their ABI.
I have built the new version into the side tag “f35-build-side-41105”.
Testing and contributions are welcome. I’ve improved the quality of this
package quite a bit over the last few months since I started maintaining it,
but it is still far from perfect (and will likely remain so, given the nature
of its upstream). Particularly, there are still a significant number of
unexplained test failures, many of which are architecture-specific, that I have
to skip. Any contributions to understanding these well enough to fix them or
usefully report them upstream (understanding that upstream runs the tests very
differently, with a dedicated test build using docker) are very welcome.
I have identified the following packages that will need to be rebuilt because
they depend on the C or C++ libraries. Each package has received a PR, or
a new Bugzilla issue in preparation for a PR.
• bear
• frr
• perl-grpc-xs
The following packages use the Python bindings. Testing with the new version
would be a good idea, but a rebuild should not be required. For the first two,
I performed a successful scratch-build using the side tag to check for any
issues. The last two are FTBFS for unrelated reasons
(https://bugzilla.redhat.com/show_bug.cgi?id=1959534,
https://bugzilla.redhat.com/show_bug.cgi?id=1959540).
• buildstream
• python-google-api-core
• python-opencensus
• python-opentelemetry
Any contributions are welcome, from testing to auditing the spec file (PRs
welcome) to co-maintainers. The missing language bindings (Ruby, PHP, C#,
Objective-C) are much more likely to be packaged if I have input from someone
with experience packaging for those languages. I’m not a user of this package,
and now that I’ve brought it back to usable and current condition, I’d welcome
those interested in taking co-maintainer responsibility for any of the following:
• the whole package (I would be happy for someone else to be the primary
maintainer in the long term)
• EPEL 8 (https://bugzilla.redhat.com/show_bug.cgi?id=1757147); currently
this means getting a significant number of dependencies into EPEL 8 and
perhaps offering to co-maintain them there
• particular language bindings (C++, Python, or the as-yet unpackaged Ruby,
PHP, C#, or Objective-C)
• running down test failures and other warts and figuring out patches and/or
reporting them upstream usefully
Drive-by contributions are appreciated too, of course.
3 years, 1 month
f34 google authenticator fails
by Carl Byington
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
This does not seem to be the same as Bug 1840113. That was an selinux
issue. This one happens even in permissive mode. Previous directions for
enabling 2fa were:
dnf -y install google-authenticator qrencode
# modify /etc/pam.d/sshd by adding one line at the top:
head -4 /etc/pam.d/sshd
#%PAM-1.0
auth required pam_google_authenticator.so nullok
auth substack password-auth
auth include postlogin
# modify /etc/ssh/sshd_config to enable 2fa
grep '^Chall' /etc/ssh/sshd_config
ChallengeResponseAuthentication yes
systemctl restart sshd.service
Are those directions still correct for F34? They work on Centos 8 and
F32. Using that on F34, connecting over ssh to an account with an
existing .google_authenticator file, we don't get the "Verification
code:" prompt, just the prompt for "root@hostxx's password:". It always
fails, since it looks like google is seeing that entry as the
verification code:
May 11 09:07:17 hostxx sshd(pam_google_authenticator)[102001]: Invalid
verification code for root
Feeding the verification code at the "root@hostxx's password:" prompt
results in the same journal message - no second prompt for the actual
password.
-----BEGIN PGP SIGNATURE-----
iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCYJqtmhUcY2FybEBmaXZl
LXRlbi1zZy5jb20ACgkQL6j7milTFsE2aQCeI4spLNRw7atvJtCnOTaFkZrc4m4A
njl8wlZZzNnfV7yb1jbNsftHtuDp
=0RfZ
-----END PGP SIGNATURE-----
3 years, 1 month