The following Sources of the specfile are not valid URLs so we cannot automatically build the new version for you.  Please use URLs in your Source declarations if possible.

- kbd-latsun-fonts.tar.bz2
- kbd-latarcyrheb-32.tar.bz2
- xml2lst.pl
- vlock.pamd
- kbdinfo.1
- cz-map.patch

Latest upstream release: 2.2.0
Current version/release in rawhide: 2.0.4-14.fc31
URL: http://www.kbd-project.org/

Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy


More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream.


Based on the information from anitya: https://release-monitoring.org/project/1492/

The following Sources of the specfile are not valid URLs so we cannot automatically build the new version for you.  Please use URLs in your Source declarations if possible.

- kbd-latsun-fonts.tar.bz2
- kbd-latarcyrheb-32.tar.bz2
- xml2lst.pl
- vlock.pamd
- kbdinfo.1
- cz-map.patch

If someone is curious why it takes so long...

I have the rebase basically done but the build fails on s390x during
configure because of pam (recent scratch build is at [1]):

checking for pam_start in -lpam... no
checking for misc_conv in -lpam_misc... no
configure: error: libpam-devel required.

pam-devel is installed and should contain required header files as it
does on other architectures. I'm trying to get some s390x machine and
inspect config.log to see more detailed output.

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=38802740

(In reply to Vitezslav Crhonek from comment #4)

> If someone is curious why it takes so long...
> 
> I have the rebase basically done but the build fails on s390x during
> configure because of pam (recent scratch build is at [1]):
> 
> checking for pam_start in -lpam... no
> checking for misc_conv in -lpam_misc... no
> configure: error: libpam-devel required.

test without "-c" option in gcc. So, it's running the linker.

BFD and GOLD installed:
DEBUG util.py:595:   binutils                   s390x  2.33.1-4.fc32                    build 5.6 M
DEBUG util.py:595:   binutils-gold              s390x  2.33.1-4.fc32                    build 1.5 M


You should check the ld status with:

# grep link config.log
# alternatives --display ld



BTW: s390 is big endian

Vito, have you made progress with the s390 issue? I can take a look if you want. Or let me know if you need a s390 machine to test.

(In reply to Dan Horák from comment #6)
> Vito, have you made progress with the s390 issue? I can take a look if you
> want. Or let me know if you need a s390 machine to test.

No, I haven't. Please take a look if you can, that would be really great.

and this is the relevant part of config.log

...
configure:12676: checking for pam_start in -lpam
configure:12701: gcc -o conftest -g -O2 -D_FORTIFY_SOURCE=2 -Waggregate-return -Wall -Wcast-align -Wconversion -Wdisabled-optimization -Wextra -Wmissing-declarations -Wmissing-format-attribute -Wmissing-noreturn -Wmissing-prototypes -Wpointer-arith -Wredundant-decls -Wshadow -Wstrict-prototypes -Wwrite-strings  -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld conftest.c -lpam   >&5
conftest.c:67:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
   67 | char pam_start ();
      | ^~~~
conftest.c:69:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
   69 | main ()
      | ^~~~
/usr/bin/ld: /tmp/cc4vtcgH.o: `pam_start@@LIBPAM_1.0' non-PLT reloc for symbol defined in shared library and accessed from executable (rebuild file with -fPIC ?)
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status


looks to me that configure doesn't use the distro CFLAGS, but uses LDFLAGS, thus the PIC/no-PIC conflict

Created attachment 1662090 [details]
config.log

The distro-wide CFLAGS are lost somewhere during the configure process. I suppose all arches will be affected.

Dan, thanks for your help, the package is rebased now.