Bug 1518800 - libkolab: FTBFS in Fedora rawhide
Summary: libkolab: FTBFS in Fedora rawhide
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: libkolab
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Timotheus Pokorra
QA Contact: Fedora Extras Quality Assurance
URL: http://apps.fedoraproject.org/koschei...
Whiteboard:
: 1556048 1604607 (view as bug list)
Depends On:
Blocks: F28FTBFS 1562743 F29FTBFS
TreeView+ depends on / blocked
 
Reported: 2017-11-29 15:04 UTC by Jitka Plesnikova
Modified: 2019-01-16 11:03 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-01-16 11:03:39 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
fails to build now even earlier (6.62 KB, text/plain)
2018-02-13 09:34 UTC, Timotheus Pokorra
no flags Details
build.log (12.10 KB, text/plain)
2018-05-28 22:46 UTC, Fedora Release Engineering
no flags Details
root.log (133.29 KB, text/plain)
2018-05-28 22:46 UTC, Fedora Release Engineering
no flags Details
state.log (627 bytes, text/plain)
2018-05-28 22:46 UTC, Fedora Release Engineering
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1556048 0 unspecified CLOSED libkolab: FTBFS in F28 2021-02-22 00:41:40 UTC

Internal Links: 1556048

Description Jitka Plesnikova 2017-11-29 15:04:34 UTC
Description of problem:
Package libkolab fails to build from source in Fedora rawhide with following error:

In file included from /builddir/build/BUILD/libkolab-1.0.2/kolabformat/mimeobject.cpp:20:0:
/builddir/build/BUILD/libkolab-1.0.2/./conversion/kcalconversion.h:46:22: error: 'KDateTime' does not name a type; did you mean 'cDateTime'?
         KOLAB_EXPORT KDateTime toDate(const Kolab::cDateTime &dt);
                      ^~~~~~~~~
                      cDateTime
/builddir/build/BUILD/libkolab-1.0.2/./conversion/kcalconversion.h:47:47: error: 'KDateTime' does not name a type; did you mean 'cDateTime'?
         KOLAB_EXPORT cDateTime fromDate(const KDateTime &dt);
                                               ^~~~~~~~~
                                               cDateTime

Steps to Reproduce:
koji build --scratch f28 libkolab-1.0.2-9.fc27.src.rpm

Additional info:
This package is tracked by Koschei. See:
http://apps.fedoraproject.org/koschei/package/libkolab

A difference between working and failing build root is listed on
https://apps.fedoraproject.org/koschei/build/3784561

Comment 1 Rex Dieter 2017-12-21 15:50:06 UTC
FYI,

As of kdepim-runtime-17.12 release (which bundles a patched libkolab), nothing in fedora uses libkolab anymore as far as I can tell

Comment 2 Timotheus Pokorra 2018-02-13 09:32:09 UTC
I would like to keep libkolab in Fedora, just in case we package the Kolab server one day in Fedora.

Comment 3 Timotheus Pokorra 2018-02-13 09:34:03 UTC
Created attachment 1395253 [details]
fails to build now even earlier

Today, a scratch build on Rawhide failed even earlier:

CMake Error at cmake/modules/FindSWIG.cmake:4 (find_package_handle_standard_args):
  Unknown CMake command "find_package_handle_standard_args".

Comment 5 Timotheus Pokorra 2018-02-13 15:01:11 UTC
Thanks @Rex Dieter!

now we get this error:

[  2%] Building CXX object CMakeFiles/kolab.dir/kolabformat/kolabobject.cpp.o
/usr/bin/c++  -DKCOREADDONS_LIB -DKDEPIMLIBS_VERSION_MAJOR="" -DKDEPIMLIBS_VERSION_MINOR="" -DKDEPIMLIBS_VERSION_PATCH="" -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_XML_LIB -Dkolab_EXPORTS -I/builddir/build/BUILD/libkolab-1.0.2/build -I/builddir/build/BUILD/libkolab-1.0.2/kolabformatV2 -I/usr/lib64/cmake/Libkolabxml/../../../include/kolabxml -I/builddir/build/BUILD/libkolab-1.0.2/. -I/usr/include/python2.7 -isystem /usr/include/KF5/KCalCore -isystem /usr/include/KF5 -isystem /usr/include/qt5 -isystem /usr/include/qt5/QtCore -isystem /usr/lib64/qt5/./mkspecs/linux-g++ -isystem /usr/include/KF5/KCalUtils -isystem /usr/include/KF5/KCalUtils/kcalutils -isystem /usr/include/qt5/QtWidgets -isystem /usr/include/qt5/QtGui -isystem /usr/include/KF5/KCoreAddons -isystem /usr/include/KF5/KConfigGui -isystem /usr/include/qt5/QtXml -isystem /usr/include/KF5/KConfigCore -isystem /usr/include/KF5/KContacts -isystem /usr/include/KF5/KMime -isystem /usr/include/KF5/AkonadiCore -isystem /usr/include/KF5/KItemModels -isystem /usr/include/KF5/Akonadi/Notes -isystem /usr/include/KF5/akonadi/notes  -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 -mcet -fcf-protection -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -fno-exceptions -DQT_NO_EXCEPTIONS -fno-common -Woverloaded-virtual -fno-threadsafe-statics -fvisibility=hidden -Werror=return-type -fvisibility-inlines-hidden -fexceptions -UQT_NO_EXCEPTIONS -fPIC -g -std=c++11 -fPIC   -fPIC -fexceptions -std=gnu++11 -o CMakeFiles/kolab.dir/kolabformat/kolabobject.cpp.o -c /builddir/build/BUILD/libkolab-1.0.2/kolabformat/kolabobject.cpp
In file included from /builddir/build/BUILD/libkolab-1.0.2/kolabformat/v2helpers.h:23,
                 from /builddir/build/BUILD/libkolab-1.0.2/kolabformat/kolabobject.cpp:20:
/builddir/build/BUILD/libkolab-1.0.2/./kolabformatV2/kolabbase.h:40:10: fatal error: kdatetime.h: No such file or directory
 #include <kdatetime.h>
          ^~~~~~~~~~~~~
compilation terminated.
make[2]: *** [CMakeFiles/kolab.dir/build.make:70: CMakeFiles/kolab.dir/kolabformat/kolabobject.cpp.o] Error 1
make[2]: Leaving directory '/builddir/build/BUILD/libkolab-1.0.2/build'

In Kolab upstream, we are using an untagged (!!) version of libkolab 2.0. But I checked the file https://git.kolab.org/diffusion/LK/browse/master/kolabformatV2/kolabbase.h, it still references kdatetime.h

Comment 6 Fedora End Of Life 2018-02-20 15:35:06 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Comment 7 Rex Dieter 2018-04-04 15:26:15 UTC
*** Bug 1556048 has been marked as a duplicate of this bug. ***

Comment 8 Rex Dieter 2018-04-04 15:32:07 UTC
I'll echo a comment from the dup'd bug,

libkolab is (still) using a deprecated kdatetime api which was recently removed from kf5-kcalendarcore

Comment 9 Adam Williamson 2018-04-04 16:39:04 UTC
Also from that bug, Rex said: "My recommendation is to retire this, at least until it's fixed and/or anything else really needs it."

which I agree with. But note, please find a package that can Obsoletes: it, so that upgrades from F27 and earlier work without --allowerasing.

Comment 10 Rex Dieter 2018-04-04 16:59:27 UTC
libkolabxml (something libkolab depends on) is one good candidate

Otherwise, catch-all fedora-obsolete-packages is another

Comment 11 Adam Williamson 2018-04-04 18:17:40 UTC
libkolabxml sounds good to me. it's best to use a 'real' package if one makes sense, the catch-all is more of a fallback.

Comment 12 Rex Dieter 2018-04-04 19:09:46 UTC
OK, i'll take care of implementing the Obsoletes

Comment 13 Fedora Release Engineering 2018-05-28 22:46:36 UTC
Created attachment 1444892 [details]
build.log

Comment 14 Fedora Release Engineering 2018-05-28 22:46:42 UTC
Created attachment 1444893 [details]
root.log

Comment 15 Fedora Release Engineering 2018-05-28 22:46:46 UTC
Created attachment 1444894 [details]
state.log

Comment 16 Rex Dieter 2018-06-01 15:31:06 UTC
Re comment #12

Obsoletes: implemented awhile back,
https://src.fedoraproject.org/rpms/libkolabxml/c/286610e929238bd5ef0f659de2915db05434c848

Comment 17 Zbigniew Jędrzejewski-Szmek 2018-07-09 04:28:02 UTC
Dear Maintainer,

your package has not been built successfully in F28. Action is required from you.

If you can fix your package to build, perform a build in koji, and either create
an update in bodhi, or close this bug without creating an update, if updating is
not appropriate [1]. If you are working on a fix, set the status to ASSIGNED to
acknowledge this. Following the latest policy for such packages [2], your package
will be orphaned if this bug remains in NEW state more than 8 weeks.

[1] https://fedoraproject.org/wiki/Updates_Policy
[2] https://fedoraproject.org/wiki/Fails_to_build_from_source#Package_Removal_for_Long-standing_FTBFS_bugs

Comment 18 Zbigniew Jędrzejewski-Szmek 2018-07-09 04:30:10 UTC
Dear Maintainer,

your package has not been built successfully in F28. Action is required from you.

If you can fix your package to build, perform a build in koji, and either create
an update in bodhi, or close this bug without creating an update, if updating is
not appropriate [1]. If you are working on a fix, set the status to ASSIGNED to acknowledge this. Following the latest policy for such packages [2], your package will be orphaned if this bug remains in NEW state more than 8 weeks.

[1] https://fedoraproject.org/wiki/Updates_Policy
[2] https://fedoraproject.org/wiki/Fails_to_build_from_source#Package_Removal_for_Long-standing_FTBFS_bugs

Comment 19 Zbigniew Jędrzejewski-Szmek 2018-07-09 04:32:40 UTC
Dear Maintainer,

your package has not been built successfully in F28. Action is required from you.

If you can fix your package to build, perform a build in koji, and either create
an update in bodhi, or close this bug without creating an update, if updating is
not appropriate [1]. If you are working on a fix, set the status to ASSIGNED to
acknowledge this. Following the latest policy for such packages [2], your package
will be orphaned if this bug remains in NEW state more than 8 weeks.

[1] https://fedoraproject.org/wiki/Updates_Policy
[2] https://fedoraproject.org/wiki/Fails_to_build_from_source#Package_Removal_for_Long-standing_FTBFS_bugs

Comment 20 Timotheus Pokorra 2018-07-31 05:14:02 UTC
I guess we all agree that this package cannot be revived?

Should I just let it be orphaned, or should I actively orphan it? I will try the latter.

Comment 21 Adam Williamson 2018-07-31 22:52:48 UTC
It would be best to *explicitly retire* it, not to orphan it. See https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life .

Comment 22 Timotheus Pokorra 2019-01-16 07:52:47 UTC
*** Bug 1604607 has been marked as a duplicate of this bug. ***

Comment 23 Timotheus Pokorra 2019-01-16 11:03:39 UTC
I have now retired the package libkolab, it is obsoleted by libkolabxml.
I hope it worked.

https://src.fedoraproject.org/rpms/libkolab/commits/master


Note You need to log in before you can comment on or make changes to this bug.