f34 google authenticator fails
-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- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
build failure using boost-python3 on ppc64le
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I am trying a scratch build of libpst, and I don't understand the error. http://koji.fedoraproject.org/koji/taskinfo?taskID=35373272 This package uses boost-python3. On x86, the build log contains: make[2]: Entering directory '/builddir/build/BUILD/libpst-0.6.72/python' /bin/sh ../libtool --tag=CXX --mode=link g++ -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -module -avoid-version -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o _libpst.la -rpath /usr/lib64/python3.7/site-packages python-libpst.lo -lboost_python37 ../src/libpst.la -lpthread libtool: link: g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-redhat-linux/9/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/9/crtbeginS.o .libs/python-libpst.o -Wl,-rpath -Wl,/builddir/build/BUILD/libpst-0.6.72/src/.libs -lboost_python37 ../src/.libs/libpst.so -lpthread -L/usr/lib/gcc/x86_64-redhat-linux/9 -L/usr/lib/gcc/x86_64-redhat-linux/9/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/9/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-redhat-linux/9/crtendS.o /usr/lib/gcc/x86_64-redhat-linux/9/../../../../lib64/crtn.o -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -O2 -g -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,-soname -Wl,_libpst.so -o .libs/_libpst.so which works. On ppc, the build log contains: make[2]: Entering directory '/builddir/build/BUILD/libpst-0.6.72/python' /bin/sh ../libtool --tag=CXX --mode=link g++ -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mcpu=power8 -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection -module -avoid-version -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o _libpst.la -rpath /usr/lib64/python3.7/site-packages python-libpst.lo -l ../src/libpst.la -lpthread libtool: link: g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/ppc64le-redhat-linux/9/../../../../lib64/crti.o /usr/lib/gcc/ppc64le-redhat-linux/9/crtbeginS.o .libs/python-libpst.o -Wl,-rpath -Wl,/builddir/build/BUILD/libpst-0.6.72/src/.libs -l ../src/.libs/libpst.so -lpthread -L/usr/lib/gcc/ppc64le-redhat-linux/9 -L/usr/lib/gcc/ppc64le-redhat-linux/9/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/ppc64le-redhat-linux/9/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/ppc64le-redhat-linux/9/crtendS.o /usr/lib/gcc/ppc64le-redhat-linux/9/../../../../lib64/crtn.o -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -O2 -g -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mcpu=power8 -mtune=power8 -Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,-soname -Wl,_libpst.so -o .libs/_libpst.so which fails. Notice that on x86, we have BUILD/libpst-0.6.72/src/.libs - -lboost_python37 ../src/.libs/libpst.so -lpthread but on ppc, we have BUILD/libpst-0.6.72/src/.libs -l ../src/.libs/libpst.so -lpthread The -lboost_python37 turns into a plain -l, so the next token ../src/.libs/libpst.so is taken as a library name which fails. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAlz6qS0ACgkQL6j7milTFsGulgCfUhXGs70fysofV8NRlI9LgUlP mCEAnRmIz6burXpZFkwCpB+7LbIyH4uu =coL1 -END 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
f28 dnf update, passivetex texlive broken?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Problem 1: package passivetex-1.25-23.fc28.noarch requires xmltex >= 20020625-10, but none of the providers can be installed - package texlive-xmltex-7:20170520-29.fc28.noarch obsoletes texlive- xmltex-bin < 7:20170520 provided by texlive-xmltex- bin-6:svn3006.0-42.20160520.fc28.noarch - cannot install the best update candidate for package texlive- xmltex-6:svn40855-42.fc28.2.noarch - cannot install the best update candidate for package passivetex-1.25-23.fc28.noarch Problem 2: package xmlto-tex-0.0.28-6.fc28.noarch requires passivetex >= 1.11, but none of the providers can be installed - package passivetex-1.25-23.fc28.noarch requires xmltex >= 20020625-10, but none of the providers can be installed - package texlive-xmltex-7:20170520-29.fc28.noarch obsoletes texlive- xmltex-bin < 7:20170520 provided by texlive-xmltex- bin-6:svn3006.0-42.20160520.fc28.noarch - cannot install the best update candidate for package xmlto- tex-0.0.28-6.fc28.noarch - cannot install the best update candidate for package texlive-xmltex- bin-6:svn3006.0-42.20160520.fc28.noarch I am not sure how to work around this. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAlset9EACgkQL6j7milTFsGwdgCfZ6MWAq3mhC7Sh1dpzkm4NUsa EEwAn1FSOKbHfembvKHltEyAx7nnNLy9 =5eKF -END 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SHRRQYHC2YJWOIAB4UHGSGOQNK4NYV76/
Orphaning ghemical and related packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ghemical libghemical liboglappth mopac7 mpqc I hope someone is able to pick them up. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAlJm7LYACgkQL6j7milTFsEY/ACbBCxTi5Z21XwHMIPOTPSMK/4I ywsAoIEwfZ9J+r63sFe56r1u00TScDXi =uTZg -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
any hope for logstash?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am working on packaging logstash http://www.logstash.net/ but the build procedure described here https://github.com/logstash/logstash/wiki/ Building-and-running-logstash-from-source seems to be incompatible with Fedora packaging. How do other jruby packages (are there any?) deal with this? http://www.five-ten-sg.com/mapper/logstash/ points to a method to build a source rpm, but it is source only if you consider a java .jar file to be source code. At least that lets me install this on multiple machines easily. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAlFWLuEACgkQL6j7milTFsHMfwCcDKA0r55ognMjDOy7gwR2AMJu n7gAnjiRqYg3fWV8V5tn628R5xSxq6GW =JBNW -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for dnssec-triggerd alpha testers!
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, 2011-09-17 at 14:00 -0400, Paul Wouters wrote:
You can find source and package pre-releases at:
ftp://ftp.xelerance.com/dnssec-trigger/
At least for Fedora 15:
BuildRequires: glib-devel, gtk2-devel, ldns-devel
and in %install
mkdir -p %{buildroot}%{_localstatedir}/run/dnssec-triggerd
After killing off dnsmasq and starting unbound and dnssec-trigger,
Sep 17 18:19:02 laptop setroubleshoot: SELinux is preventing
/usr/sbin/unbound from name_bind access on the tcp_socket port 8953. For
complete SELinux messages. run sealert -l 924dfa70-fe9e-4cc0-add0-
364b8ae90ef6
grep unbound /var/log/audit/audit.log | audit2allow -M unboundpatch
semodule -i unboundpatch.pp
cat /etc/resolv.conf
# Generated by dnssec-trigger 0.3
nameserver 127.0.0.1
It took over dns via unbound, even though the dhcp assigned dns servers
allow dnssec queries.
dnssec-trigger-control-setup
setup in directory /etc
dnssec_trigger_server.key exists
dnssec_trigger_control.key exists
create dnssec_trigger_server.pem (self signed certificate)
create dnssec_trigger_control.pem (signed client certificate)
Signature ok
subject=/CN=dnssec-trigger-control
Getting CA Private Key
Setup success. Certificates created.
dnssec-trigger-control-setup -i
setup in directory /etc
unbound-checkconf: no errors in /etc/unbound/unbound.conf
checking if unbound-control needs to be enabled
checking if root trust anchor needs to be enabled
fetching or updating root trust anchor: unbound-anchor
[1316311135] libunbound[17598:0] error: ldns error while converting
string to RR: Syntax error, could not parse the RR's rdata
[1316311135] libunbound[17598:0] error: failed to load trust anchor from
/etc/unbound/root.key at line 2, skipping
[1316311135] libunbound[17598:0] error: ldns error while converting
string to RR: Syntax error, could not parse the RR's TTL
[1316311135] libunbound[17598:0] error: failed to load trust anchor from
/etc/unbound/root.key at line 4, skipping
[1316311135] libunbound[17598:0] error: failed to read
/etc/unbound/root.key
[1316311135] libunbound[17598:0] error: error reading auto-trust-anchor-
file: /etc/unbound/root.key
[1316311135] libunbound[17598:0] error: validator: error in trustanchors
config
[1316311135] libunbound[17598:0] error: validator: could not apply
configuration settings.
[1316311135] libunbound[17598:0] error: module init for module validator
failed
add to /etc/unbound/unbound.conf: auto-trust-anchor-file:
/etc/unbound/root.key
check for search path in resolv.conf and edit /etc/dnssec-trigger.conf
check for domain in resolv.conf and edit /etc/dnssec-trigger.conf
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFOdVItL6j7milTFsERAjHqAKCDFvKuwgKiYvRtvJBUVRpunvAxmQCbBVJP
lsJmLAFHfCBnFPrR4/exxME=
=KN8D
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 15 Beta TC1 Live images now available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 2011-04-01 at 11:38 -0700, Adam Williamson wrote: http://serverbeach1.fedoraproject.org/pub/alt/stage/15-Beta.TC1/Live/ Now we can get down to the desktop validation testing: https://fedoraproject.org/wiki/Test_Results:Fedora_15_Beta_TC1_Desktop Is USB 3.0 testing part of this? Dell Vostro 230ST, two dual port pci - usb3.0 cards, two usb 3.0 hubs, and some Western Digital usb3.0 disks. Without the hubs (disks attached directly to the ports on the pci cards, everything works nicely. I have lsusb/lspci output but am unsure where to post that. http://comments.gmane.org/gmane.linux.usb.general/43664 might be applicable. Filed Bug 694293 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFNnNkhL6j7milTFsERApLDAJ4j08kDoC3SylfFIZAUThMz3KJfXgCfR/C3 t2dAxoMlq6ojRNsPS/1YlQA= =45UN -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
nightly compose not bootable?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 desktop-i386-20100916.15.iso fails to boot from cd on dell dimension 2350. Does it work for other folks? -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFMk7CjL6j7milTFsERAhItAJ0Tx+fLkRQwUFcwOtsObwsQIscN1QCcDfeJ pSAP+UAIGMv6qwZOR7Q0k5Q= =lpwJ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: nightly compose not bootable?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 desktop-i386-20100916.15.iso fails to boot from cd on dell dimension 2350. Does it work for other folks? Do you have some more symptoms you can tell us? I did a local compose from around the same time and it worked on a USB drive. So I suspect it's a harware specific problem. If it might be video related, you can hit tab at the first window to get the boot menu and then try using the basic video boot option. There was also a recent thread about a problem related to VT-d on a different Dell model which mentioned that disabling iommu at boot made things better. That physical CD does boot nicely on a Dell dimension 8400. On the 2350, we just get the small dash in the upper left corner of the screen. It never shows the ISOLINUX line, and so never shows the grub menu, and eventually boots from the hard drive. Neither escape nor tab do anything while sitting with the small dash at the top left corner. Ah, bizarre. That physical cd will boot on the 2350 from the second (cd only) drive, but not from the first (dvd) drive. Other cd's (vyatta 6.0, 6.1, an old ubuntu 7) will boot from the dvd drive on that machine. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFMk+CSL6j7milTFsERAmkcAJ4pIYhdhqNWlxBf4chvSglQuioIEwCeOpkM aXX+b39FRIYg+uH9IvIa0Vw= =9nPO -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
font dependency packaging question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have a package (ghemical) which requires a courier 12 font for use in its xwindow gui. I clearly need some dependency that will drag in xorg-x11-fonts-ISO8859-1-100dpi or xorg-x11-fonts-ISO8859-1-75dpi but those probably depend on the actual user's display resolution. What is the appropriate 'requires' for the .spec file? -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFMfc9BL6j7milTFsERAvQgAJkByQ2BRJIIeyWXpf9j6wmYsf9w2ACgir9l AjGShLqx93Et1+xYBJTizGA= =9v0a -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
