Comment 1 Andre Klapper 2009-08-04 19:16:24 UTC

Updating version info as libcal is still in nokia-binaries in Fremantle.

Comment 2 Quim Gil 2009-09-14 08:53:45 UTC

This is an enhancement request.

Comment 3 Quim Gil 2009-10-14 08:38:24 UTC

So, in practice this request means that libcal should be open source. The
reasons not to offer the information requested and not having the component
open are roughly the same.

Question: how badly needed is this? I'm trying to prioritize the components
that the community wants to see open.

(In reply to comment #3)
> So, in practice this request means that libcal should be open source. The
> reasons not to offer the information requested and not having the component
> open are roughly the same.
> 
> Question: how badly needed is this? I'm trying to prioritize the components
> that the community wants to see open.
> 

I do NOT request libcal source since I rewrote alternative to it. I only
request documentation of conf blocks data in /dev/mtd1. It's required in order
to produce free (as in speech) initfs.

Having requested documentation will reduce risks of bricking/damaging/improper
use of user devices.

Comment 5 Carsten Munk 2010-01-05 13:52:04 UTC

Weighing in on this one: 

I personally think we should open source libcal. The potential
Security/Liability issues with people editing CAL already exists in the fact it
is perfectly possible to maim your tablet / edit calibration area etc with
libcal-dev from nokia-binaries if you so wanted.

It would solve a source closed dependancy of DSME, libcal. Due to the existence
of BME data in CAL requiring proper read and write from BME and the fact that
charging ability should be possible in alternative OS'es, I would advise that
we either open source libcal or document it. 

I vote for the first - due to this problem I'm facing with BME on N900:

* In N8x0 we could just chroot into the initfs to get BME and charging ability.
We can't any longer and hence libcal just became a lot more relevant.
* BME speaks to DSME. DSME depends on libcal. libcal is closed and hence I
can't compile against it in the Mer build system.
* BME requires CAL read/write ability in order to store PMM data (see /dev/mtd1
dump). I personally don't want to trust a 3rd party library to store and
retrieve this. 
* If libcal was open sourced, we would be able to build our own DSME, drop in a
binary BME and have safe, proven charging and CAL read/writing ability.

My initial impression of libcal code is that it looks clean, well-written and
presentable and does not contain anything specific to Nokia devices. It is an
algorithm on top of a MTD/NAND device as Marat's open replacement also has
found it to be. 

libcal is on the top of my list of things that would be useful to open source
and I'd like to work the open sourcing process on this item.

Comment 6 Carsten Munk 2010-05-31 14:34:31 UTC

Some news, libcal is getting open sourced as part of the MeeGo on N900 effort.

(In reply to comment #6)
> Some news, libcal is getting open sourced as part of the MeeGo on N900 effort. 

Also, DSME's dependency on libcal is being removed.

Comment 8 Faheem Pervez 2010-06-12 10:56:40 UTC

Let me know when they're doing the same for sysinfod and libsysinfo. That's
where all the good stuff in CAL got moved to (well, it still remains in CAL)
for the N900.

(In reply to comment #6)
> Some news, libcal is getting open sourced as part of the MeeGo on N900 effort. 

Ping!  Is that still the plan?  It's present in MeeGo 1.1, but in the non-oss
repo.

Comment 10 Andre Klapper 2010-11-20 12:24:54 UTC

Quim: ping - comment 9?

Comment 11 Quim Gil 2010-12-06 23:48:57 UTC

I have asked Sakari Poussa and Mikko Ylinen (MeeGo architects at Nokia), CCing
Carsten (maintainer of MeeGo images for N900).

Comment 12 Quim Gil 2010-12-07 19:01:53 UTC

There discussion about providing an equivalent functionality to libcal in MeeGo
is being discussed publicly at
http://lists.meego.com/pipermail/meego-architecture/2010-November/000016.html &
following posts.

You are encouraged to get involved in that discussion. Sakari and Mikko have
been active in it. The chances of progress are more likely in that MeeGo
architecture discussion than here.

Comment 13 Andre Klapper 2011-01-18 17:29:09 UTC

Quim: So should this get closed as WONTFIX for Maemo or what is the status?

Comment 14 Quim Gil 2011-01-26 21:42:38 UTC

If we couldn't get any resolution as for yet, now I'm not expecting any release
on this for Maemo 5. Any discussion and work needs to happen in the MeeGo
context, as said in my previous comment.

Therefore yes, resolving as WONTFIX.

FYI, in case it's of use to anyone:  the OpenWrt project now has another free 
implementation in <https://dev.openwrt.org/browser/packages/utils/calvaria>.