What about porting it to libical3? That might be easier. I tried to build it
and it does need some changes, but I don't think keeping libical2 is feasible.
See the attached for the error.
Scott K
On Friday, February 08, 2019 10:46:21 PM Sandro Knauß wrote:
> Hey,
>
> for me it looks like we won't be able to get kdepimlibs without libical 2
> for buster.
> Keep in mind, that kdepimlibs is an old grufted lib set that we also would
> like to kill. But we also have other packages depending on it like:
> * basket
> * kopete (it has a QT5 version in experimental, but this is suitable as
> replacement yet).
> and other that may can be killed.
>
> extract libical 2 out of kdepimlibs is not that simple, as the whole
> interface will leak into akonadi-calendar, calcore, calutils,...
>
> In short I won't have the time to do the work and test it in the near
> future.
>
> I added pino to this bug report, as pino successfully extracted other parts
> of old kdelibs/kdepimlibs.
>
> hefee
>
> --
>
> On Donnerstag, 17. Januar 2019 12:11:46 CET Emilio Pozuelo Monfort wrote:
> > On 11/01/2019 13:37, Emilio Pozuelo Monfort wrote:
> > > On 08/08/2018 10:38, Emilio Pozuelo Monfort wrote:
> > >> Source: kdepimlibs
> > >> Version: 4:4.14.10-10
> > >> Severity: serious
> > >> Control: block 884128 with -1
> > >>
> > >> Hi,
> > >>
> > >> libical2 from src:libical is superseded by libical3 (src:libical3).
> > >>
> > >> Please either port kdepimlibs to libical3 or try to disable the
> > >> libical support, so that we can only ship src:libical3 in buster.
> > >
> > > Could someone who knows kdepimlibs take a look at this? Can we disable
> > > libical support in kdepimlibs for buster? This is the last blocker for
> > > the libical 2 removal.
> >
> > Hi Sandro,
> >
> > Lisandro said you may be able to help with this. Do you know if libical
> > support could be disabled in kdepimlibs, or if the newer version libical3
> > could be used?
> >
> > >From [1] it seems that libical is kind of optional, though I don't know
> > >if
> > >we
> >
> > can disable the bits to drop that or if those bits have rdeps. Since
> > kdepimlibs is the last rdep of the old libical version, fixing this would
> > allow us to drop that one from buster. Otherwise the RC bugs that it has
> > will need to be fixed and we'll have to ship with two versions of the
> > library.
> >
> > Thanks,
> > Emilio
> >
> > [1]
> > https://sources.debian.org/src/kdepimlibs/4:4.14.10-10/CMakeLists.txt/#L81
/home/kdepimlibs-4.14.10/kcalcore/icalformat_p.cpp: In static member function
'static icaltimetype KCalCore::ICalFormatImpl::writeICalDate(const QDate&)':
/home/kdepimlibs-4.14.10/kcalcore/icalformat_p.cpp:2304:7: error:
'icaltimetype' {aka 'struct icaltimetype'} has no member named 'is_utc'; did
you mean 'is_date'?
t.is_utc = 0;
^~~~~~
is_date
/home/kdepimlibs-4.14.10/kcalcore/icalformat_p.cpp: In static member function
'static icaltimetype KCalCore::ICalFormatImpl::writeICalDateTime(const
KDateTime&)':
/home/kdepimlibs-4.14.10/kcalcore/icalformat_p.cpp:2326:7: error:
'icaltimetype' {aka 'struct icaltimetype'} has no member named 'is_utc'; did
you mean 'is_date'?
t.is_utc = datetime.isUtc() ? 1 : 0;
^~~~~~
is_date
/home/kdepimlibs-4.14.10/kcalcore/icalformat_p.cpp: In static member function
'static icalproperty*
KCalCore::ICalFormatImpl::writeICalDateTimeProperty(icalproperty_kind, const
KDateTime&, KCalCore::ICalTimeZones*, KCalCore::ICalTimeZones*)':
/home/kdepimlibs-4.14.10/kcalcore/icalformat_p.cpp:2401:12: error:
'icaltimetype' {aka 'struct icaltimetype'} has no member named 'is_utc'; did
you mean 'is_date'?
if (!t.is_utc) {
^~~~~~
is_date
/home/kdepimlibs-4.14.10/kcalcore/icalformat_p.cpp: In static member function
'static KDateTime KCalCore::ICalFormatImpl::readICalDateTime(icalproperty*,
const icaltimetype&, KCalCore::ICalTimeZones*, bool)':
/home/kdepimlibs-4.14.10/kcalcore/icalformat_p.cpp:2434:11: error: 'const
icaltimetype' {aka 'const struct icaltimetype'} has no member named 'is_utc';
did you mean 'is_date'?
if (t.is_utc || t.zone == icaltimezone_get_utc_timezone()) {
^~~~~~
is_date
