Learn more about these different git repos.
Other Git URLs
I am rebuilding a package named xmlrpc-c, the source is https://src.fedoraproject.org/rpms/xmlrpc-c/tree/f36
then I have used mock to rebuild it, then it is failed, I have modified some contents of spec file, then building in mock is successful, but in my local koji, it is also failed, the error message is:
/builddir/build/BUILD/xmlrpc-c-1.51.0/tools/xml/xmlrpcparsecall.c:85:undefined reference to dumpValue
after checking the process, I found a symlink blddir/tools/lib/ is not regarded as a real symlink
blddir -› /builddir/build/BUILD/xmlrpc-c-1.51.0
after I have modified the makefile, it works
-DUMPVALUE = blddir/tools/lib/dumpvalue.o +DUMPVALUE = $(TOOLSDIR)/lib/dumpvalue.o
$(TOOLSDIR) is a absolute path.
so I want to know, if koji only support absolute or relative path, rather than symlink?
It shouldn't be a problem. Do you've some srpm which I can test with? I've tried with f36 branch but it fails for me on lib/libutil/meson.build:35:5: ERROR: Got unknown keyword arguments "install"
lib/libutil/meson.build:35:5: ERROR: Got unknown keyword arguments "install"
Metadata Update from @tkopecek: - Custom field Size adjusted to None
<img alt="xmlrpc-c-1.51.0-16.src.rpm" src="/koji/issue/raw/files/837d58a7de8c8013beea9ab8dee0ae1a8e330d702aefc1f2f1afa50e93cc5e5e-xmlrpc-c-1.51.0-16.src.rpm" /> you can try this one, it should be successful in mock but failed in koji. then you can uncomment the 3001 patch, it will work in koji.
Interesting - it looks non-deterministic. I would suspect some race condition as it is more likely to happen with "make -j48" tasks. (failed 2 from 12) I wonder if common.mk target (creating symlnik) in tools/lib/Makefile is really evaluated every time as that file is there from the beginning. But I'm not able to figure out why it is called in most of the cases.
common.mk
tools/lib/Makefile
Compare two tasks on the same builder: https://koji.fedoraproject.org/koji/taskinfo?taskID=85490951 https://koji.fedoraproject.org/koji/taskinfo?taskID=85491046
With your patch is working in 10/10, so it really fixes it. I'm inclined to some race condition causing in the end that symlink sometimes doesn't exist in the moment when linking happens.
Anyway, to the original issue: koji is treating symlinks normally. What we see here is the concrete package problem (probably already present in upstream).
Metadata Update from @tkopecek: - Issue close_status updated to: Invalid - Issue status updated to: Closed (was: Open)
thanks
Login to comment on this ticket.