From aspineux at gmail.com  Fri Jan  2 13:36:13 2009
From: aspineux at gmail.com (Alain Spineux)
Date: Fri, 2 Jan 2009 13:36:13 +0100
Subject: [Kolab-devel] Horde can now store Preferences in IMAP (was:
	Horde preferences: LDAP or IMAP?)
In-Reply-To: <20081221234248.12067680kz9f5dgc@webmail.pardus.de>
References: <87zlz1trxh.fsf@home.pardus.de>
	<200710022328.32145.martin.konold@erfrakon.de>
	<71fe4e760710021605l6a2d79c0le78f0d70adb8347d@mail.gmail.com>
	<200710301025.13994.stephane@voyageonline.co.uk>
	<87odeetdzx.fsf@home.pardus.de> <87ejaf84wp.fsf_-_@home.pardus.de>
	<20081221234248.12067680kz9f5dgc@webmail.pardus.de>
Message-ID: <71fe4e760901020436q73afb633lada4ac0f620881c8@mail.gmail.com>

2008/12/21 Gunnar Wrobel <wrobel at pardus.de>:
> Hi!
>
> A while back (beginning of this year) we had a discussion on how to store
> the user preferences of the Kolab webclient (based on Horde).
>
> Horde preferences are being handled by a single module called "prefs". This
> module supports several backends. Among them are
>
>  - SQL
>  - LDAP
>  - File based
>  - IMAP
>
> Horde usually uses SQL. Kolab has traditionally used the LDAP backend. This
> LDAP backend has been replaced with the file based backend for Kolab Server
> 2.2.1 beta 1. An alternative would also be the storage in IMAP similar to
> the other groupware data of the Kolab server.
>
> The decision to switch to the file based approach was made since the
> developer team did not consider LDAP to be a decent place for such data
> anymore. It makes the LDAP entries rather complex and LDAP is usually meant
> primarily for read access rater than a standard storage space.
>
> We decided not to use IMAP at the moment as that would mean we would need to
> discuss the Kolab format for such entries wich would take a while until we
> finalize it.
>
> So the file based approach has been selected for now.
>
> This does not hinder anyone to choose any of the other possible backends.
> People that like to remain on LDAP can do so without problems while people
> preferring IMAP storage can also choose to do so.
>
> But the question still is: What is the best default?
>
> It would be great if people could add the pros and cons they see for the
> different solutions. I'll try to add an overview once we have some opinions
> and I'll include the relevant pieces from the discussion we had at the
> beginning of this year.
>
> I would like to add that I personally see the IMAP driver as the best
> choice. For me the Kolab server architecture results in one simple
> conclusion: User data belongs into IMAP. And preferences are user data.

Pro IMAP too.
File based approach require to add something into the backup or the
migration procedure.
Anyway, when does these data need to be READ or WRITTEN ?
At each mail access, or at each folrder access, or just once at login
and logout ?

>
> Cheers,
>
> Gunnar
>
> Quoting Gunnar Wrobel <wrobel at pardus.de>:
>
>> Gunnar Wrobel <wrobel at pardus.de> writes:
>>
>>> Stephane Konstantaropoulos <stephane at voyageonline.co.uk> writes:
>>>
>>>> Hello,
>>>>
>>>> I fully agree with Alain, the LDAP preferences backend for Horde is
>>>> efficient
>>>> and is there, I see no point in creating a new one. Plus it is very easy
>>>> to
>>>> admin for shops that use LDAP for a lot of things, such as Samba or
>>>> POSIX
>>>> auth. We use LDAP as a backend for most of our users' stuff and it is
>>>> very
>>>> solid.
>>>
>>> Thanks for the feedback. The LDAP preferences backend will definitely
>>> stay the default backend now. People convinced me :)
>>>
>>> The IMAP preferences backend might still find it's way into Horde CVS
>>> at some point. But it will be purely optional then.
>>
>> The IMAP driver for preferences is available since yesterday within Horde.
>>
>> While most people will probably use the older LDAP driver I want to be
>> able to have an "IMAP-only" Horde/Kolab with Horde 4.
>>
>> Cheers,
>>
>> Gunnar
>>
>>>
>>> Cheers,
>>>
>>> Gunnar
>>>
>>>>
>>>> We store iPlanet prefs, Samba prefs, Posix prefs and user data in there
>>>> and
>>>> that's what it is there for.
>>>>
>>>> I think you should stick to it with Horde, and perhaps see if you can
>>>> optmize
>>>> some stuff, like session caching or something.
>>>>
>>>> My production Horde is slowed down by the Imap server more than the LDAP
>>>> server. (a few thousand users).
>>>>
>>>> My 2 cents
>>>>
>>>> Stephane
>>>>
>>>> Le Wednesday 03 October 2007 00:05:27 Alain Spineux, vous avez ?crit :
>>>>>
>>>>> On 10/2/07, Martin Konold <martin.konold at erfrakon.de> wrote:
>>>>> > Am Dienstag 02 Oktober 2007 schrieb Gunnar Wrobel: out
>>>>> >
>>>>> > Hi Gunnar,
>>>>> >
>>>>> > thanks for taking up with this initiative.
>>>>> >
>>>>> > I am also not very happy with the current LDAP approach which
>>>>> > clutters up
>>>>> > the LDAP namespace very much and looks more like an abuse than like a
>>>>> > useful directory. (e.g. many unused empty entries)
>>>>>
>>>>> This is the way LDAP works.
>>>>>
>>>>> LDAP is the perfect place to store data from different application
>>>>> (but all related to the same object). Different apps can share the
>>>>> same data from different place. LDAP provide ACL at
>>>>> object and field level !
>>>>>
>>>>> > > I regard LDAP as a bad storage place for the web client preferences
>>>>> > > and wrote a new preferences driver for Horde that uses an IMAP
>>>>> > > folder
>>>>> >
>>>>> > Why did you rule out the simple option to use a plain file for each
>>>>> > user?
>>>>> > If this plain file is protected using Apache access control it would
>>>>> > be
>>>>> > trivial to make it available anywhere whithin a Kolab server cluster.
>>>>> > E.g. you could store the file on the kolabHomeServer and use a URL
>>>>> > like
>>>>> > https://kolabhomeserver.domain.tld/config/horde-preferences. Because
>>>>> > horde knows the users credentials it would be trivial to provide them
>>>>> > to
>>>>> > Apache. Using these credentials Apache or some php script could
>>>>> > internally use the correct user specific file
>>>>>
>>>>> And how do you modify this file from remote location ?
>>>>>
>>>>> You are designing file format, data access ... while LDAP already
>>>>> exist, with all this stuff.
>>>>> Why do you want to reinvent the wheel ?
>>>>>
>>>>> > If figuring out the kolabhomeserver via LDAP is not an option it
>>>>> > could be
>>>>> > handled trivially by the php script running on any server in a
>>>>> > transparent manner.
>>>>> >
>>>>> > > The advantages of this driver: The LDAP schemas don't have to be
>>>>> > > modified
>>>>>
>>>>> just add a "include" in slapd.conf ... not to much works
>>>>>
>>>>> >and the users can be plain KolabInetOrgPerson objects.
>>>>>
>>>>> is it an advantage ?  Could not my users be samba users ? Or asterisk
>>>>> one ?
>>>>>
>>>>> > In
>>>>> >
>>>>> > > addition this reduces LDAP read/write operations.
>>>>>
>>>>> Do you need to economize LDAP, are imap or file access cheaper ?
>>>>> You can cache these data into the PHP sessions data !
>>>>>
>>>>> > I fully agree!
>>>>> >
>>>>> > > The disadvantages: There is a new folder type and the other clients
>>>>> > > might display a "Preferences"-Folder with mails they can't really
>>>>> > > use.
>>>>> >
>>>>> > Well, you would still have the option of "hiding" this special folder
>>>>> > from other clients using ACLs and subscription state.
>>>>>
>>>>> Sure ? completely hidden ? No risk for the user to erase this "strange"
>>>>> folder ?
>>>>>
>>>>> > > 1) Do people regard it as a desired alternative to store the
>>>>> > > preferences on IMAP? Any specific drawbacks or advantages I missed?
>>>>>
>>>>> The main kolab idea was to retrieve/store all data from LDAP and then
>>>>> kolabd was synchronizing them into IMAP (creating mailbox, .......)
>>>>> Why do you want to put data somewhere else ?
>>>>> Then why not write directly postfix, apache, cyrus template from the
>>>>> GUI ?
>>>>>
>>>>> > I think that IMAP is an option while a plain URL pointing at some
>>>>> > trivial
>>>>> > PHP script is better. This script could provide transparency in case
>>>>> > of a
>>>>> > clustering setup and as an added bonus it could allow trivial REST
>>>>> > features.
>>>>>
>>>>> LDAP already provide this out of the box :-)
>>>>>
>>>>> > This means that calling the script without parameters e.g.
>>>>> > https://kolabhomeserver.domain.tld/config/horde-preferences will
>>>>> > provide
>>>>> > a single document with some trivial file format (e.g. key=value or
>>>>> > some
>>>>> > simple XML). E.g. in doing a HTTP GET to
>>>>> > https://kolabhomeserver.domain.tld/config/hordePrefs would provide
>>>>> > something like:
>>>>>
>>>>> Still imagining powerful, but less standard data access ?
>>>>>
>>>>> > [...]
>>>>> > summary_refresh_time=10
>>>>> > show_sidebar=true
>>>>> > sidebar_width=40
>>>>> > menu_refresh_time=100
>>>>> > [...]
>>>>> >
>>>>> > On the other hand
>>>>> >
>>>>> > https://kolabhomeserver.domain.tld/config/hordePrefs?action=get&key=show_
>>>>> >sidebar would return a document only containing the string "true". If
>>>>> > the
>>>>> > implementation benefits returning "show_sidebar=true" is also an
>>>>> > option.
>>>>> >
>>>>> > In this simple model it would be the job of the horde application to
>>>>> > know
>>>>> > that the string "true" refers to a bool. Doing so is imho trivial in
>>>>> > case
>>>>> > of horde. This would allow to limit the capabilities of the
>>>>> > preference
>>>>> > storage service to simple strings.
>>>>> >
>>>>> > The php script hordePrefs.php would trivially be able to distinguish
>>>>> > the
>>>>> > users from the mandatory credentials.
>>>>> >
>>>>> > The actual backend used (e.g. a flat file or a small berkley DB) is
>>>>> > then
>>>>> > a simple opaque implementation detail.
>>>>>
>>>>> Did I already suggested you can use LDAP instead ? :-)
>>>>>
>>>>> > Storing a single key would be done using an URL like
>>>>> >
>>>>> > https://kolabhomeserver.domain.tld/config/hordePrefs?action=set&key=show_
>>>>> >sidebar&value=false
>>>>> >
>>>>> > > 2) If this driver should be available what should be the default
>>>>> > > option?
>>>>> >
>>>>> > IMAP is definetly better than LDAP but imho other options like my
>>>>> > proposal should be considered.
>>>>>
>>>>> Yes IMAP is excel in storing /retrieving emails :-)
>>>>>
>>>>> > > The second question is important since we would need to ship the
>>>>> > > driver with the earliest release possible. Otherwise we might get
>>>>> > > people running this in production that will have to run
>>>>> > > "preferences
>>>>> > > conversion scripts" (that would have to be written) if we ever
>>>>> > > change
>>>>> > > the default option.
>>>>> >
>>>>> > Regards,
>>>>> > -- martin konold
>>>>> >
>>>>> > --
>>>>> > e r f r a k o n
>>>>> > Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
>>>>> > Sitz: Adolfstra?e 23 Stuttgart - Partnerschaftsregister Stuttgart PR
>>>>> > 126
>>>>> > http://www.erfrakon.com/
>>>>> >
>>>>> > _______________________________________________
>>>>> > Kolab-devel mailing list
>>>>> > Kolab-devel at kolab.org
>>>>> > https://kolab.org/mailman/listinfo/kolab-devel
>>>>
>>>>
>>>>
>>>> --
>>>> St?phane Konstantaropoulos
>>>> -- Creator, Web Applications
>>>> _______________________________________________
>>>> Kolab-devel mailing list
>>>> Kolab-devel at kolab.org
>>>> https://kolab.org/mailman/listinfo/kolab-devel
>>>
>>> --
>>> ______ http://kdab.com _______________ http://kolab-konsortium.com _
>>>
>>> p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium
>>>
>>> ____ http://www.pardus.de _________________ http://gunnarwrobel.de _
>>> E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
>>> Tel.   : +49 40 432 72335                           Bundesstrasse 29
>>> Fax    : +49 40 432 70855                            D-20146 Hamburg
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>   >> Mail at ease - Rent a kolab groupware server at p at rdus <<
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> _______________________________________________
>>> Kolab-devel mailing list
>>> Kolab-devel at kolab.org
>>> https://kolab.org/mailman/listinfo/kolab-devel
>>
>> --
>> ______ http://kdab.com _______________ http://kolab-konsortium.com _
>>
>> p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium
>>
>> ____ http://www.pardus.de _________________ http://gunnarwrobel.de _
>> E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
>> Tel.   : +49 700 6245 0000                          Bundesstrasse 29
>> Fax    : +49 721 1513 52322                          D-20146 Hamburg
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>   >> Mail at ease - Rent a kolab groupware server at p at rdus <<
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> _______________________________________________
>> Kolab-devel mailing list
>> Kolab-devel at kolab.org
>> https://kolab.org/mailman/listinfo/kolab-devel
>
>
>
> --
> ______ http://kdab.com _______________ http://kolab-konsortium.com _
>
> p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium
>
> ____ http://www.pardus.de _________________ http://gunnarwrobel.de _
> E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
> Tel.   : +49 700 6245 0000                          Bundesstrasse 29
> Fax    : +49 721 1513 52322                          D-20146 Hamburg
> --------------------------------------------------------------------
>   >> Mail at ease - Rent a kolab groupware server at p at rdus <<
> --------------------------------------------------------------------
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
Alain Spineux
aspineux gmail com
May the sources be with you


From bernhard.reiter at intevation.de  Mon Jan  5 09:36:54 2009
From: bernhard.reiter at intevation.de (Bernhard Reiter)
Date: Mon, 5 Jan 2009 09:36:54 +0100
Subject: [Kolab-devel] Multiple Kolab's php eat all the RAM
In-Reply-To: <20081227182825.16444p7ni4665b40@webmail.pardus.de>
References: <200812231807.41967.dvadell@linuxclusters.com.ar>
	<200812262113.52165.dvadell@linuxclusters.com.ar>
	<20081227182825.16444p7ni4665b40@webmail.pardus.de>
Message-ID: <200901050936.54654.bernhard.reiter@intevation.de>

On Samstag, 27. Dezember 2008, Gunnar Wrobel wrote:
> Quoting "Diego M. Vadell" <dvadell at linuxclusters.com.ar>:
> > On Wednesday 24 December 2008 04:55:09 Alain Spineux wrote:
> >> On Tue, Dec 23, 2008 at 10:59 PM, Diego M. Vadell
> >>
> >> <dvadell at linuxclusters.com.ar> wrote:

> >> > ? I think I found it: when I send an email to 30 people inside the
> >> > server (locals to the server) I get a lot of kolabmailfilter
> >> > processess. Is it the intended way of doing things?
> >>
> >> Unfortunately yes !

Not really.

The email transport system should be able to transport a single message
to several recipients as one message until the very end.
There have been several difficulties with this, so this ability
might be switched off until they are fixed.

> >> When you send to multiple recipients, one message is "cloned" by
> >> recipients ! This could be avoided by some more coding.
> >> This would reduce the CPU load and could reduce the space in the imap
> >> storage regarding
> >> the "singleinstancestore" in imapd.conf if handled
> >> appropriately.(divided by 3 with my own experience)

I do not recomment singleinstancestore on the imap backend,
as it might complicate backups and restores. Usually using group accounts
for account-less folders you can avoid too much double storage in the common 
cases. 


> > ? I mitigated (or solved?) the issue by editing master.cf.template and
> > changing this line:
> >
> > kolabmailboxfilter ? ? unix ?- ? ? ? n ? ? ? n ? ? ? - ? ? ?- ? ? ? ?pipe
> > user=kolab-n null_sender= argv=/kolab/bin/php
> >
> > to:
> >
> > kolabmailboxfilter ? ? unix ?- ? ? ? n ? ? ? n ? ? ? - ? ? ? 2 ? ? ? pipe
> > user=kolab-n null_sender= argv=/kolab/bin/php
> >
> >
> > Given that amavisd gets only 2 emails at a time, I thought 2 was a good
> > place to start.
>
> I believe that is a sensible safeguard.
>
> @thomas, bernhard: Should we add this as a default?

[the technical solution should be followed up on kolab-devel at .]
It would limit kolabmailboxfilter startup, right?
2 sounds too low to me for the general case.
We should also find out why it takes up so much time to complete
or how much memory is eaten.

Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20090105/50279286/attachment.bin

From daniel.vergien at rrz.uni-hamburg.de  Mon Jan  5 09:37:31 2009
From: daniel.vergien at rrz.uni-hamburg.de (Daniel Vergien)
Date: Mon, 05 Jan 2009 09:37:31 +0100
Subject: [Kolab-devel] Solaris 10 Sparc Kolab V2.2.1 Beta
 1	PEAR-Horde-Channel-1.0 find: cannot follow symbolic link
In-Reply-To: <F095FCE31D23483AA7CA445E013F429E@comcept.ch>
References: <F095FCE31D23483AA7CA445E013F429E@comcept.ch>
Message-ID: <4961C6CB.2060505@rrz.uni-hamburg.de>

On 12/31/08 03:37 PM, ComCept Soliva wrote:
> Hi Gunnar
> 
> the install-kolab.sh failed again also with a old issue for
> PEAR-Horde-Channel-1.0 (I think I saw already this issue). I have no idea
> how to proceed? Any suggestion? 

It seems to be a problem with /usr/sbin/install on solaris which is a 
bit limitated compared to the linux ones. I helpt myself by changing 
the install call in the specfile to /kolab/lib/openpkg/shtool install 
and remove the -p option.

See https://www.intevation.de/roundup/kolab/issue3315

Daniel




> Log is available
> http://www.comcept.ch/kolab2/2.2.1-beta1/kolab-install-Dec-31-10-14-54.zip:
> 
> 
> 
> :::: /tmp/install-kolab....8544/PEAR-Horde-Channel-1.0-20081210.src.rpm ::::
> Installing
> /tmp/install-kolab....8544/PEAR-Horde-Channel-1.0-20081210.src.rpm
> Executing(%prep): env -i /kolab/lib/openpkg/bash --norc --noprofile --posix
> -e /kolab/RPM/TMP/rpm-tmp.6248
> + cd /kolab/RPM/TMP
> + set +x
> +----------------------------------Warning----------------------------------
> --+
> | This OpenPKG package is of class JUNK.
> |
> | This means it is still in DEVELOPMENT state.
> |
> | Hence it is still NOT ready even for general evaluation.
> |
> | Do not use it at all, except in development environments!
> |
> | It is definitely unstable and incompletely packaged.
> |
> +---------------------------------------------------------------------------
> --+
> + cd /kolab/RPM/TMP
> + rm -rf PEAR-Horde-Channel-1.0
> + /kolab/lib/openpkg/shtool mkdir -f -p -m 755 PEAR-Horde-Channel-1.0
> + cd PEAR-Horde-Channel-1.0
> + exit 0
> Executing(%build): env -i /kolab/lib/openpkg/bash --norc --noprofile --posix
> -e /kolab/RPM/TMP/rpm-tmp.6248
> + cd /kolab/RPM/TMP
> + cd PEAR-Horde-Channel-1.0
> + exit 0
> Executing(%install): env -i /kolab/lib/openpkg/bash --norc --noprofile
> --posix -e /kolab/RPM/TMP/rpm-tmp.6248
> + cd /kolab/RPM/TMP
> + cd PEAR-Horde-Channel-1.0
> + rm -rf /kolab/RPM/TMP/PEAR-Horde-Channel-1.0-root
> + mkdir -p /kolab/RPM/TMP/PEAR-Horde-Channel-1.0-root/kolab/var/pear
> + install -pm 644 /kolab/RPM/SRC/PEAR-Horde-Channel/channel.xml
> /kolab/RPM/TMP/PEAR-Horde-Channel-1.0-root/kolab/var/pear/pear.horde.org.xml
> find: stat() error 644: No such file or directory
> find: stat() error
> /kolab/RPM/TMP/PEAR-Horde-Channel-1.0-root/kolab/var/pear/pear.horde.org.xml
> : No such file or directory
> find: cannot read dir /etc/inet/secret: Permission denied
> find: cannot read dir /etc/flash/postcreation: Permission denied
> find: cannot read dir /etc/flash/precreation: Permission denied
> find: cannot read dir /etc/flash/preexit: Permission denied
> find: cannot follow symbolic link /usr/lib/llib-lgen: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lnvpair.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ltermlib: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lsec.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lumem: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/libmeta.so.1: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lsendfile: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lsendfile.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/llib-lrtld_db.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lresolv.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lsec: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-luuid: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lrt.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ldoor: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lposix4: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lrt: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lscf.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lcurses: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lrtld_db.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-lrt.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lcurses.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-lefi.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lcontract.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/64/llib-lintl.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-laio.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-ldevid.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-ltermcap: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lpam.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lelf.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-ltsnet.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-lthread_db.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/64/llib-ltermlib.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-lpthread.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-ldl.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lgen.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lctf.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lthread.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-ltermlib: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-ldevice.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-lposix4.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-lscf.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lkstat.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-lsendfile.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/64/llib-lsocket.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-lc.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lsec.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-ldoor.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lsecdb.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-ltsol.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lumem.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lsysevent.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/64/llib-lbsm.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-ladm.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-ldevinfo.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-lnsl.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-ltermcap.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-lnvpair.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-lmd5.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lxnet.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lcmd.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lresolv.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-luuid.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lc.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lnsl.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ltermcap: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lc: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lcmd.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lsysevent.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/llib-lmd5.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lintl: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lsecdb.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lpthread.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ltermlib.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lbsm.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lsocket: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ldevinfo: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lkstat.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ladm.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lintl.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lsecdb: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lsocket.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ldl.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lsysevent: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lctf: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lcontract: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lposix4.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lxnet.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lrtld_db: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ldevice.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lcontract.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/llib-luuid.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ladm: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ldevice: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lkstat: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lthread.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lcurses: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lthread_db: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lumem.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lefi.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lscf: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-laio.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lefi: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ltsnet.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ldevid.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lgen.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lpthread: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lcurses: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lrtld_db.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lrt.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lcurses.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lefi.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lcontract.ln: No
> such file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lintl.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-laio.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ldevid.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ltermcap: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lpam.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lelf.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ltsnet.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lthread_db.ln: No
> such file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ltermlib.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lpthread.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ldl.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lgen.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lctf.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lthread.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ltermlib: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ldevice.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lposix4.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lscf.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lkstat.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lsendfile.ln: No
> such file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lsocket.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lc.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lsec.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ldoor.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lsecdb.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ltsol.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lumem.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lsysevent.ln: No
> such file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lbsm.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ladm.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ldevinfo.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lnsl.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ltermcap.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lnvpair.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lmd5.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lxnet.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lcmd.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lresolv.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-luuid.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/llib-lelf: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lctf.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ltsol.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lbsm: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lthread: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lthread_db.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/llib-ldoor.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ldevid: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ldevinfo.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/libmeta.so: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ltermcap.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-laio: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lelf.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lpam.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lcurses.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lnvpair: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lmd5: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lnsl: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lcmd: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lpam: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lresolv: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lxnet: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ldl: No such file or
> directory
> install: -pm was not found anywhere!
> error: Bad exit status from /kolab/RPM/TMP/rpm-tmp.6248 (%install)
> 
> 
> RPM build errors:
>     Bad exit status from /kolab/RPM/TMP/rpm-tmp.6248 (%install)
> + exit 1 
> 
> 
> kind regards
> 
> Andrea
> 
> 
> 
> Mail: soliva at comcept.ch 
> 
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel


From bernhard at intevation.de  Mon Jan  5 10:19:55 2009
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 5 Jan 2009 10:19:55 +0100
Subject: [Kolab-devel] Horde can now store Preferences in IMAP (was:
	Horde preferences: LDAP or IMAP?)
In-Reply-To: <71fe4e760901020436q73afb633lada4ac0f620881c8@mail.gmail.com>
References: <87zlz1trxh.fsf@home.pardus.de>
	<20081221234248.12067680kz9f5dgc@webmail.pardus.de>
	<71fe4e760901020436q73afb633lada4ac0f620881c8@mail.gmail.com>
Message-ID: <200901051019.55540.bernhard@intevation.de>

On Freitag, 2. Januar 2009, Alain Spineux wrote:
> > Horde usually uses SQL. Kolab has traditionally used the LDAP backend.

Ah, the us of "traditionally" is missleading, the Kolac Concept never
suggested putting client user preferences into LDAP.
In fact there has been no solution for this so far, so the clients
are on their own saving their settings.

The Kolab Web Client (based on Horde) is a Kolab Client, but a special one.
This is what makes the discussion interesting. The use of LDAP for 
daily client preferences in Kolab Server 2.2.0 was by mistake.

> > This LDAP backend has been replaced with the file based backend for Kolab
> > Server 2.2.1 beta 1. 

> > We decided not to use IMAP at the moment as that would mean we would need
> > to discuss the Kolab format for such entries wich would take a while
> > until we finalize it.

> > But the question still is: What is the best default?

Until we have a good proposal for the Kolab Format, it should be file,
as this is what most other clients also use.

> > It would be great if people could add the pros and cons they see for the
> > different solutions. I'll try to add an overview once we have some
> > opinions and I'll include the relevant pieces from the discussion we had
> > at the beginning of this year.
> >
> > I would like to add that I personally see the IMAP driver as the best
> > choice. For me the Kolab server architecture results in one simple
> > conclusion: User data belongs into IMAP. And preferences are user data.
>
> Pro IMAP too.
> File based approach require to add something into the backup or the
> migration procedure.

You'll have this anyway with all clients (unfortunately.)

> Anyway, when does these data need to be READ or WRITTEN ?
> At each mail access, or at each folrder access, or just once at login
> and logout ?

A client could potentially write this data on any display refresh
or client action. Just think about index files that contain special flags
per email. So I guess that there will be always client data that will need
to be saved client locally per user.

Bernhard

-- 
Managing Director - Owner: www.intevation.net      (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20090105/1e40650a/attachment-0001.bin

From aspineux at gmail.com  Mon Jan  5 11:06:22 2009
From: aspineux at gmail.com (Alain Spineux)
Date: Mon, 5 Jan 2009 11:06:22 +0100
Subject: [Kolab-devel] Multiple Kolab's php eat all the RAM
In-Reply-To: <200901050936.54654.bernhard.reiter@intevation.de>
References: <200812231807.41967.dvadell@linuxclusters.com.ar>
	<200812262113.52165.dvadell@linuxclusters.com.ar>
	<20081227182825.16444p7ni4665b40@webmail.pardus.de>
	<200901050936.54654.bernhard.reiter@intevation.de>
Message-ID: <71fe4e760901050206h7d4052e5w678ef79e951b0dee@mail.gmail.com>

On Mon, Jan 5, 2009 at 9:36 AM, Bernhard Reiter
<bernhard.reiter at intevation.de> wrote:
> On Samstag, 27. Dezember 2008, Gunnar Wrobel wrote:
>> Quoting "Diego M. Vadell" <dvadell at linuxclusters.com.ar>:
>> > On Wednesday 24 December 2008 04:55:09 Alain Spineux wrote:
>> >> On Tue, Dec 23, 2008 at 10:59 PM, Diego M. Vadell
>> >>
>> >> <dvadell at linuxclusters.com.ar> wrote:
>
>> >> >   I think I found it: when I send an email to 30 people inside the
>> >> > server (locals to the server) I get a lot of kolabmailfilter
>> >> > processess. Is it the intended way of doing things?
>> >>
>> >> Unfortunately yes !
>
> Not really.
>
> The email transport system should be able to transport a single message
> to several recipients as one message until the very end.
> There have been several difficulties with this, so this ability
> might be switched off until they are fixed.

And the "end" allso can keep the email alone.
This require some more LDAP queries inside the filter :-)

>
>> >> When you send to multiple recipients, one message is "cloned" by
>> >> recipients ! This could be avoided by some more coding.
>> >> This would reduce the CPU load and could reduce the space in the imap
>> >> storage regarding
>> >> the "singleinstancestore" in imapd.conf if handled
>> >> appropriately.(divided by 3 with my own experience)
>
> I do not recomment singleinstancestore on the imap backend,
> as it might complicate backups and restores. Usually using group accounts
> for account-less folders you can avoid too much double storage in the common
> cases.

This doesn't "complicate" the backup nor the restore,  except if you
want to keep this advantage during the backup and after the restore.

This reduce by 3 the space for my hosted domains.

This also require to use the good switch when using "du" :-)

>
>
>> >   I mitigated (or solved?) the issue by editing master.cf.template and
>> > changing this line:
>> >
>> > kolabmailboxfilter     unix  -       n       n       -      -        pipe
>> > user=kolab-n null_sender= argv=/kolab/bin/php
>> >
>> > to:
>> >
>> > kolabmailboxfilter     unix  -       n       n       -       2       pipe
>> > user=kolab-n null_sender= argv=/kolab/bin/php
>> >
>> >
>> > Given that amavisd gets only 2 emails at a time, I thought 2 was a good
>> > place to start.
>>
>> I believe that is a sensible safeguard.
>>
>> @thomas, bernhard: Should we add this as a default?
>
> [the technical solution should be followed up on kolab-devel at .]
> It would limit kolabmailboxfilter startup, right?
> 2 sounds too low to me for the general case.
> We should also find out why it takes up so much time to complete
> or how much memory is eaten.
>
> Bernhard
>
> --
> Managing Director - Owner: www.intevation.net       (Free Software Company)
> Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
> Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
> Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
Alain Spineux
aspineux gmail com
May the sources be with you


From martin.konold at erfrakon.de  Mon Jan  5 11:39:30 2009
From: martin.konold at erfrakon.de (Martin Konold)
Date: Mon, 5 Jan 2009 11:39:30 +0100
Subject: [Kolab-devel] Horde can now store Preferences in IMAP (was:
	Horde preferences: LDAP or IMAP?)
In-Reply-To: <200901051019.55540.bernhard@intevation.de>
References: <87zlz1trxh.fsf@home.pardus.de>
	<71fe4e760901020436q73afb633lada4ac0f620881c8@mail.gmail.com>
	<200901051019.55540.bernhard@intevation.de>
Message-ID: <200901051139.31696.martin.konold@erfrakon.de>

Am Montag, 5. Januar 2009 10:19:55 schrieb Bernhard Reiter:

Hi Bernhard,

> This is what makes the discussion interesting. The use of LDAP for
> daily client preferences in Kolab Server 2.2.0 was by mistake.

No it was an intermediate solution in order to avoid an additional piece of 
compley software (RDBMS).

> Until we have a good proposal for the Kolab Format, it should be file,
> as this is what most other clients also use.

Using a file instead of IMAP breaks the scalability aspect of the Kolab 
Webclient. 

> A client could potentially write this data on any display refresh
> or client action. Just think about index files that contain special flags
> per email. So I guess that there will be always client data that will need
> to be saved client locally per user.

I don't understand this. E.g. a webclient can easily use the more efficient 
session instead of persistent storage in order to keep volatile data (which 
can easily be regenerated anyway)

Regards,
-- martin

-- 
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Sitz: Adolfstra?e 23, 70469 Stuttgart, Partnerschaftsregister Stuttgart PR 126
http://www.erfrakon.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kolab.org/pipermail/kolab-devel/attachments/20090105/8a358cf0/attachment.html

From soliva at comcept.ch  Mon Jan  5 19:25:52 2009
From: soliva at comcept.ch (ComCept Soliva)
Date: Mon, 5 Jan 2009 19:25:52 +0100
Subject: [Kolab-devel] Solaris 10 Sparc Kolab V2.2.1 Beta 1
	PEAR-Horde-Channel-1.0 / PEAR-PHPUnit-Channel-1.0 find:
	cannot follow symbolic link
Message-ID: <DDD83D586B974E3BBB90148B97AFF288@comcept.ch>

Hi all

many thanks Daniel...I proceeded in the way you mentioned and it works.
There is another package whith this issue
https://www.intevation.de/roundup/kolab/issue3315:

PEAR-PHPUnit-Channel-1.0

I updated my documentation and added all issues with number recognized for
Solaris 10 until now because overview is becoming complecate/worse. To
install kolab on Solaris 10 is becoming more and more an adventure. It would
be great if this issues can be solved in a easy way. My documentation helps
probably to get the overview:

http://www.comcept.ch/kolab2/2.2.1-beta1/solaris_10_kolab2_install.txt

At the moment the installation is again running. Will give feedback as soon
as it is finished or I find another issue (hopefully not :-)

kind regards and a good start in 2009.

Andrea

Mail: soliva at comcept.ch 
-----Urspr?ngliche Nachricht-----
Von: Daniel Vergien [mailto:daniel.vergien at rrz.uni-hamburg.de] Im Auftrag
von kolab-devel-bounces at kolab.org
Gesendet: Montag, 5. Januar 2009 09:38
An: Kolab development coordination
Betreff: [Kolab-devel] Solaris 10 Sparc Kolab V2.2.1 Beta 1
PEAR-Horde-Channel-1.0 find: cannot follow symbolic link 

On 12/31/08 03:37 PM, ComCept Soliva wrote:
> Hi Gunnar
> 
> the install-kolab.sh failed again also with a old issue for
> PEAR-Horde-Channel-1.0 (I think I saw already this issue). I have no idea
> how to proceed? Any suggestion? 

It seems to be a problem with /usr/sbin/install on solaris which is a 
bit limitated compared to the linux ones. I helpt myself by changing 
the install call in the specfile to /kolab/lib/openpkg/shtool install 
and remove the -p option.

See https://www.intevation.de/roundup/kolab/issue3315

Daniel




> Log is available
>
http://www.comcept.ch/kolab2/2.2.1-beta1/kolab-install-Dec-31-10-14-54.zip:
> 
> 
> 
> :::: /tmp/install-kolab....8544/PEAR-Horde-Channel-1.0-20081210.src.rpm
::::
> Installing
> /tmp/install-kolab....8544/PEAR-Horde-Channel-1.0-20081210.src.rpm
> Executing(%prep): env -i /kolab/lib/openpkg/bash --norc --noprofile
--posix
> -e /kolab/RPM/TMP/rpm-tmp.6248
> + cd /kolab/RPM/TMP
> + set +x
>
+----------------------------------Warning----------------------------------
> --+
> | This OpenPKG package is of class JUNK.
> |
> | This means it is still in DEVELOPMENT state.
> |
> | Hence it is still NOT ready even for general evaluation.
> |
> | Do not use it at all, except in development environments!
> |
> | It is definitely unstable and incompletely packaged.
> |
>
+---------------------------------------------------------------------------
> --+
> + cd /kolab/RPM/TMP
> + rm -rf PEAR-Horde-Channel-1.0
> + /kolab/lib/openpkg/shtool mkdir -f -p -m 755 PEAR-Horde-Channel-1.0
> + cd PEAR-Horde-Channel-1.0
> + exit 0
> Executing(%build): env -i /kolab/lib/openpkg/bash --norc --noprofile
--posix
> -e /kolab/RPM/TMP/rpm-tmp.6248
> + cd /kolab/RPM/TMP
> + cd PEAR-Horde-Channel-1.0
> + exit 0
> Executing(%install): env -i /kolab/lib/openpkg/bash --norc --noprofile
> --posix -e /kolab/RPM/TMP/rpm-tmp.6248
> + cd /kolab/RPM/TMP
> + cd PEAR-Horde-Channel-1.0
> + rm -rf /kolab/RPM/TMP/PEAR-Horde-Channel-1.0-root
> + mkdir -p /kolab/RPM/TMP/PEAR-Horde-Channel-1.0-root/kolab/var/pear
> + install -pm 644 /kolab/RPM/SRC/PEAR-Horde-Channel/channel.xml
>
/kolab/RPM/TMP/PEAR-Horde-Channel-1.0-root/kolab/var/pear/pear.horde.org.xml
> find: stat() error 644: No such file or directory
> find: stat() error
>
/kolab/RPM/TMP/PEAR-Horde-Channel-1.0-root/kolab/var/pear/pear.horde.org.xml
> : No such file or directory
> find: cannot read dir /etc/inet/secret: Permission denied
> find: cannot read dir /etc/flash/postcreation: Permission denied
> find: cannot read dir /etc/flash/precreation: Permission denied
> find: cannot read dir /etc/flash/preexit: Permission denied
> find: cannot follow symbolic link /usr/lib/llib-lgen: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lnvpair.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ltermlib: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lsec.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lumem: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/libmeta.so.1: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lsendfile: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lsendfile.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/llib-lrtld_db.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lresolv.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lsec: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-luuid: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lrt.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ldoor: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lposix4: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lrt: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lscf.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lcurses: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lrtld_db.ln: No such
file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-lrt.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lcurses.ln: No such
file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-lefi.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lcontract.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/64/llib-lintl.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-laio.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-ldevid.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-ltermcap: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lpam.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lelf.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-ltsnet.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-lthread_db.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/64/llib-ltermlib.ln: No such
file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-lpthread.ln: No such
file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-ldl.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lgen.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lctf.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lthread.ln: No such
file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-ltermlib: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-ldevice.ln: No such
file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-lposix4.ln: No such
file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-lscf.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lkstat.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-lsendfile.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/64/llib-lsocket.ln: No such
file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-lc.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lsec.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-ldoor.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lsecdb.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-ltsol.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lumem.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lsysevent.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/64/llib-lbsm.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-ladm.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-ldevinfo.ln: No such
file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-lnsl.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-ltermcap.ln: No such
file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-lnvpair.ln: No such
file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-lmd5.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lxnet.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lcmd.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/64/llib-lresolv.ln: No such
file
> or directory
> find: cannot follow symbolic link /usr/lib/64/llib-luuid.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lc.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lnsl.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ltermcap: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lc: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lcmd.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lsysevent.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/llib-lmd5.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lintl: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lsecdb.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lpthread.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ltermlib.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lbsm.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lsocket: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ldevinfo: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lkstat.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ladm.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lintl.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lsecdb: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lsocket.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ldl.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lsysevent: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lctf: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lcontract: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lposix4.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lxnet.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lrtld_db: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ldevice.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lcontract.ln: No such file
> or directory
> find: cannot follow symbolic link /usr/lib/llib-luuid.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ladm: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ldevice: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lkstat: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lthread.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lcurses: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lthread_db: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lumem.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lefi.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lscf: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-laio.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lefi: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ltsnet.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ldevid.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lgen.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lpthread: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lcurses: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lrtld_db.ln: No
such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lrt.ln: No such
file
> or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lcurses.ln: No
such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lefi.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lcontract.ln: No
> such file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lintl.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-laio.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ldevid.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ltermcap: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lpam.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lelf.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ltsnet.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lthread_db.ln: No
> such file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ltermlib.ln: No
such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lpthread.ln: No
such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ldl.ln: No such
file
> or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lgen.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lctf.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lthread.ln: No
such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ltermlib: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ldevice.ln: No
such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lposix4.ln: No
such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lscf.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lkstat.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lsendfile.ln: No
> such file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lsocket.ln: No
such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lc.ln: No such
file
> or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lsec.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ldoor.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lsecdb.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ltsol.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lumem.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lsysevent.ln: No
> such file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lbsm.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ladm.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ldevinfo.ln: No
such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lnsl.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ltermcap.ln: No
such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lnvpair.ln: No
such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lmd5.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lxnet.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lcmd.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lresolv.ln: No
such
> file or directory
> find: cannot follow symbolic link /usr/lib/sparcv9/llib-luuid.ln: No such
> file or directory
> find: cannot follow symbolic link /usr/lib/llib-lelf: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lctf.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ltsol.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lbsm: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lthread: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lthread_db.ln: No such
file
> or directory
> find: cannot follow symbolic link /usr/lib/llib-ldoor.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ldevid: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ldevinfo.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/libmeta.so: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ltermcap.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/llib-laio: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lelf.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lpam.ln: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lcurses.ln: No such file
or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lnvpair: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lmd5: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lnsl: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lcmd: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lpam: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lresolv: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-lxnet: No such file or
> directory
> find: cannot follow symbolic link /usr/lib/llib-ldl: No such file or
> directory
> install: -pm was not found anywhere!
> error: Bad exit status from /kolab/RPM/TMP/rpm-tmp.6248 (%install)
> 
> 
> RPM build errors:
>     Bad exit status from /kolab/RPM/TMP/rpm-tmp.6248 (%install)
> + exit 1 
> 
> 
> kind regards
> 
> Andrea
> 
> 
> 
> Mail: soliva at comcept.ch 
> 
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel

_______________________________________________
Kolab-devel mailing list
Kolab-devel at kolab.org
https://kolab.org/mailman/listinfo/kolab-devel


From daniel.vergien at rrz.uni-hamburg.de  Mon Jan  5 22:20:26 2009
From: daniel.vergien at rrz.uni-hamburg.de (Daniel Vergien)
Date: Mon, 05 Jan 2009 22:20:26 +0100
Subject: [Kolab-devel] Solaris 10 Sparc Kolab V2.2.1 Beta
 1	PEAR-Horde-Channel-1.0 / PEAR-PHPUnit-Channel-1.0 find:	cannot follow
 symbolic link
In-Reply-To: <DDD83D586B974E3BBB90148B97AFF288@comcept.ch>
References: <DDD83D586B974E3BBB90148B97AFF288@comcept.ch>
Message-ID: <4962799A.7030809@rrz.uni-hamburg.de>

Hi list,

> I updated my documentation and added all issues with number recognized for
> Solaris 10 until now because overview is becoming complecate/worse. To
> install kolab on Solaris 10 is becoming more and more an adventure. It would
> be great if this issues can be solved in a easy way. My documentation helps
> probably to get the overview:
> 
> http://www.comcept.ch/kolab2/2.2.1-beta1/solaris_10_kolab2_install.txt
> 
The patch to apache.spec is not needed on x86 solaris. It compiles fine.

> At the moment the installation is again running. Will give feedback as soon
> as it is finished or I find another issue (hopefully not :-)

Is the webinterface (horde) working on your system? On my it's not :-( 
See https://www.intevation.de/roundup/kolab/issue3338

Daniel


From soliva at comcept.ch  Tue Jan  6 06:30:46 2009
From: soliva at comcept.ch (ComCept Soliva)
Date: Tue, 6 Jan 2009 06:30:46 +0100
Subject: [Kolab-devel] Solaris 10 Sparc Kolab V2.2.1 Beta 1 kolabd-2.2.1
	error: Failed dependencies
Message-ID: <80531C39A75C4904BBC671E38AB751C3@comcept.ch>

Hi all

as a pity another error which seesm to me funny:

Processing files: kolabd-2.2.1-20081212
Wrote: /kolab/RPM/PKG/kolabd-2.2.1-20081212.sparc64-solaris10-kolab.rpm
Executing(%clean): env -i /kolab/lib/openpkg/bash --norc --noprofile --posix
-e /kolab/RPM/TMP/rpm-tmp.31467
+ cd /kolab/RPM/TMP
+ cd kolabd-2.2.1
+ rm -rf /kolab/RPM/TMP/kolabd-2.2.1-root
+ exit 0
Executing(--clean): env -i /kolab/lib/openpkg/bash --norc --noprofile
--posix -e /kolab/RPM/TMP/rpm-tmp.31467
+ cd /kolab/RPM/TMP
+ rm -rf kolabd-2.2.1
+ exit 0
error: Failed dependencies:
	apache::with_mod_ssl = yes is needed by kolabd-2.2.1-20081212
	apache::with_mod_ldap = yes is needed by kolabd-2.2.1-20081212
	apache::with_mod_authn_alias = yes is needed by
kolabd-2.2.1-20081212
+ exit 1 


here is the full log file:

http://www.comcept.ch/kolab2/2.2.1-beta1/kolab-install-Jan-5-18-52-20.zip

Remember with issue https://www.intevation.de/roundup/kolab/msg18180 I was
not able to configure apache automatically and had to manipulate the .spec
file:

# vi /kolab/RPM/SRC/apache/apache.spec

-------------------- /kolab/RPM/SRC/apache/apache.spec --------------------

    ./configure \
        --without-zlib \

-------------------- /kolab/RPM/SRC/apache/apache.spec --------------------

# /kolab/bin/openpkg rpmbuild -bb /kolab/RPM/SRC/apache/apache.spec

# /kolab/bin/openpkg rpm -Uvh
/kolab/RPM/PKG/apache-2.2.10-20081111.sparc64-solaris10-kolab.rpm

   Preparing...             ###########################################
[100%]
   1:apache                 ###########################################
[100%]

Was going something wrong with the manual apache install? SRC and TMP from
apache still available. How should I proceed. As confirmation that apache is
in place:

# /kolab/bin/openpkg rpm -qa
openpkg-20071227-20071227
gpg-pubkey-61b7ae34-4544a6af
make-3.81-20080101
gcc-4.2.2-20080101
openpkg-tools-1.4.6-20071231
readline-5.2.12-20080101
procmail-3.22-20080101
texinfo-4.11-20080101
grep-2.5.3-20080101
bison-2.3-20080101
sasl-2.1.22-20080101
perl-module-5.10.0-20080101
perl-stats-5.10.0-20080101
perl-time-5.10.0-20080101
mm-1.4.2-20080101
sqlite-3.6.4-20081212
libiconv-1.12-20080101
autoconf-2.61-20080101
gettext-0.17-20080101
libxml-2.6.31-20080111
libmcrypt-2.5.8-20080101
expat-2.0.1-20080101
apache-2.2.10-20081111
libxslt-1.1.22-20080101
jpeg-6b-20080101
db-4.5.20.2-20070628
config-20060923-20080101
php-5.2.8-20081209_kolab
perl-sys-5.10.0-20080101
bzip2-1.0.5-20080318
perl-mail-5.10.0-20080117
perl-conv-5.10.0-20080101
perl-locale-5.10.0-20080112
lzo-2.02-20080101
perl-parse-5.10.0-20080117
perl-net-5.10.0-20080101
perl-ldap-5.10.0-20080101
perl-kolab-2.2.1-20081212
gmp-4.2.2-20080101_kolab
PEAR-Horde-Channel-1.0-20081210
Horde_iCalendar-0.1.0-20081209
PEAR-Mail_mimeDecode-1.5.0-20081209
Horde_Cache-0.0.2-20081209
PHPUnit-3.3.3-1
Horde_Browser-0.0.2-20081209
Kolab_Format-1.0.0-20081212
PEAR-Log-1.11.2-1
Horde_Serialize-0.0.2-20081209
Horde_Cipher-0.0.2-20081209
Horde_Auth-0.1.1-20081209
Horde_LDAP-0.0.2-20081209
Horde_Perms-0.1.0-20081209
Kolab_Storage-0.3.0-20081205
Horde_Date-0.1.0-20081209
file-4.23-20080101
spamassassin-3.2.4-20080107
Horde_Argv-0.1.0-20081209
PEAR-Net_Socket-1.0.9-1
PEAR-Auth_SASL-1.0.2-1
PEAR-Net_URL-1.0.15-1
Kolab_Filter-0.1.3-20081212
gpg-pubkey-63c4cb9f-3c591eda
gpg-pubkey-52197903-4544a74d
binutils-2.18-20080101
perl-5.10.0-20080103
openssl-0.9.8g-20080101
fsl-1.7.0-20080101
openldap-2.3.43-20081212
ncurses-5.6.20080112-20080113
pcre-7.5-20080110
m4-1.4.9-20080101
groff-1.19.2-20080101
perl-openpkg-5.10.0-20080109
perl-util-5.10.0-20080116
perl-ds-5.10.0-20080104
postfix-2.4.6-20080101_kolab
gawk-3.1.6-20080101
mhash-0.9.9-20080101
imap-2006k-20080101
automake-1.10-20080101
zlib-1.2.3-20080101
flex-2.5.34-20080101
sed-4.1.5-20080101
apr-1.2.12-20080101
png-1.2.24-20080101
freetype-2.3.5-20080101
gd-2.0.35-20080101
apache-php-5.2.8-20081209_kolab
imapd-2.3.11-20080101_kolab4
perl-term-5.10.0-20080116
diffutils-2.8.7-20080101
gzip-1.3.12-20080101
perl-ssl-5.10.0-20080101
perl-crypto-5.10.0-20080101
perl-text-5.10.0-20080101
perl-comp-5.10.0-20080110
perl-xml-5.10.0-20080101
perl-www-5.10.0-20080103
perl-db-5.10.0-20080118
curl-7.17.1-20080101
clamav-0.94.2-20081212
Horde_Util-0.1.0-20081209
Horde_History-0.0.2-20081209
Horde_MIME-0.0.2-20081209
PEAR-PHPUnit-Channel-1.0-20081012
Horde_DOM-0.1.0-20081209
Horde_NLS-0.0.2-20081209
Horde_CLI-0.0.2-20081209
Horde_Framework-0.0.2-20081209
Horde_DataTree-0.0.3-20081209
Horde_Secret-0.0.2-20081209
Horde_Group-0.1.0-20081209
Kolab_Server-0.2.0.20081114-20081114
Horde_SessionObjects-0.0.2-20081209
PEAR-Date-1.4.7-1
Kolab_FreeBusy-0.1.2-20081212
perl-dns-5.10.0-20080101
amavisd-2.5.3-20080101
PEAR-Mail-1.1.14-1
PEAR-Net_LMTP-1.0.1-1
PEAR-Net_SMTP-1.3.1-1
PEAR-HTTP_Request-1.4.3-1

Full documentation what was done etc. until to this time is availabel over
following link:

http://www.comcept.ch/kolab2/2.2.1-beta1/solaris_10_kolab2_install.txt


kind regards

Andrea

Mail: soliva at comcept.ch 


From soliva at comcept.ch  Tue Jan  6 06:42:18 2009
From: soliva at comcept.ch (ComCept Soliva)
Date: Tue, 6 Jan 2009 06:42:18 +0100
Subject: [Kolab-devel] Solaris 10 Sparc Kolab V2.2.1 Beta
	1PEAR-Horde-Channel-1.0 / PEAR-PHPUnit-Channel-1.0
	find:cannot follow symbolic link
In-Reply-To: <4962799A.7030809@rrz.uni-hamburg.de>
References: <DDD83D586B974E3BBB90148B97AFF288@comcept.ch>
	<4962799A.7030809@rrz.uni-hamburg.de>
Message-ID: <BC6A6E0DCFBB452F81344954E06F48B6@comcept.ch>

Hi Daniel

I do not know yet if the Web Interface is fully working because at the
moment I do not come to a end because I have with the kolabd package a
problem. Seems to me that apache is still not correct compiled because even
the kolabd package is full compiled and the rpm is written the kolabd
package will be not installed because of missing dependencies:

Processing files: kolabd-2.2.1-20081212
Wrote: /kolab/RPM/PKG/kolabd-2.2.1-20081212.sparc64-solaris10-kolab.rpm
Executing(%clean): env -i /kolab/lib/openpkg/bash --norc --noprofile --posix
-e /kolab/RPM/TMP/rpm-tmp.31467
+ cd /kolab/RPM/TMP
+ cd kolabd-2.2.1
+ rm -rf /kolab/RPM/TMP/kolabd-2.2.1-root
+ exit 0
Executing(--clean): env -i /kolab/lib/openpkg/bash --norc --noprofile
--posix -e /kolab/RPM/TMP/rpm-tmp.31467
+ cd /kolab/RPM/TMP
+ rm -rf kolabd-2.2.1
+ exit 0
error: Failed dependencies:
	apache::with_mod_ssl = yes is needed by kolabd-2.2.1-20081212
	apache::with_mod_ldap = yes is needed by kolabd-2.2.1-20081212
	apache::with_mod_authn_alias = yes is needed by
kolabd-2.2.1-20081212
+ exit 1 

As soon as I have a point how to proceed I will do and will give feedback
regarding the Web Interface. 

By the way could be your issue regarding Horde based on the circumstances
that probably on your system only PEAR-Horde-Channel is correct but the
second one with the -p issue PEAR-PHPUnit-Channel is not existing or not
correct installed?

kind regards

Andrea

Mail: soliva at comcept.ch 
-----Urspr?ngliche Nachricht-----
Von: Daniel Vergien [mailto:daniel.vergien at rrz.uni-hamburg.de] Im Auftrag
von kolab-devel-bounces at kolab.org
Gesendet: Montag, 5. Januar 2009 22:20
An: Kolab development coordination
Betreff: Re: [Kolab-devel] Solaris 10 Sparc Kolab V2.2.1 Beta1
PEAR-Horde-Channel-1.0 / PEAR-PHPUnit-Channel-1.0 find: cannot
followsymbolic link

Hi list,

> I updated my documentation and added all issues with number recognized for
> Solaris 10 until now because overview is becoming complecate/worse. To
> install kolab on Solaris 10 is becoming more and more an adventure. It
would
> be great if this issues can be solved in a easy way. My documentation
helps
> probably to get the overview:
> 
> http://www.comcept.ch/kolab2/2.2.1-beta1/solaris_10_kolab2_install.txt
> 
The patch to apache.spec is not needed on x86 solaris. It compiles fine.

> At the moment the installation is again running. Will give feedback as
soon
> as it is finished or I find another issue (hopefully not :-)

Is the webinterface (horde) working on your system? On my it's not :-( 
See https://www.intevation.de/roundup/kolab/issue3338

Daniel

_______________________________________________
Kolab-devel mailing list
Kolab-devel at kolab.org
https://kolab.org/mailman/listinfo/kolab-devel


From bernhard at intevation.de  Tue Jan  6 09:37:13 2009
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 6 Jan 2009 09:37:13 +0100
Subject: [Kolab-devel] Horde can now store Preferences in IMAP (was:
	Horde preferences: LDAP or IMAP?)
In-Reply-To: <200901051139.31696.martin.konold@erfrakon.de>
References: <87zlz1trxh.fsf@home.pardus.de>
	<200901051019.55540.bernhard@intevation.de>
	<200901051139.31696.martin.konold@erfrakon.de>
Message-ID: <200901060937.16694.bernhard@intevation.de>

Moin Martin,

[to kolab-devel@ only as this is mainly about the implementation]

On Montag, 5. Januar 2009, Martin Konold wrote:
> Am Montag, 5. Januar 2009 10:19:55 schrieb Bernhard Reiter:
> > This is what makes the discussion interesting. The use of LDAP for
> > daily client preferences in Kolab Server 2.2.0 was by mistake.
>
> No it was an intermediate solution in order to avoid an additional piece of
> compley software (RDBMS).

my remark was technical about the server 2.2.0 
and the web client implementation coming with it.
This web client was not scalable for several servers
(as it should have been) and it should not have used LDAP.

> > Until we have a good proposal for the Kolab Format, it should be file,
> > as this is what most other clients also use.
>
> Using a file instead of IMAP breaks the scalability aspect of the Kolab
> Webclient.

I merely suggested to use file as default until we have come up with a nice
proposal for the IMAP format which also incoporates other clients.

> > A client could potentially write this data on any display refresh
> > or client action. Just think about index files that contain special flags
> > per email. So I guess that there will be always client data that will
> > need to be saved client locally per user.
>
> I don't understand this. E.g. a webclient can easily use the more efficient
> session instead of persistent storage in order to keep volatile data (which
> can easily be regenerated anyway)

Hmm, I am also still thinking about this.

Let us assume a folder with 20K emails in it, 
Kontact keeps an index files to accelerate the display of this information.
If it would not keep such an index files between sessions, it would need to 
parse all 20K emails on the first selection of the folder or startup.
This seems to indicate that someone would need a permanent local storage
for the client.

Note that also for Kontact you would need different preferences
settings as you usually have one client in your workplace, one at home, one 
mobile netbook and you would want different settings with them, e.g. 
a different local subscription of folders.
It would be cool for the Kolab Concept to support all these different 
needs for storing configurations, but the problem seems to be hard.
There are meanwhile two discontinued attempts by the Cyrus people to solve 
this problems.

Bernhard

-- 
Managing Director - Owner: www.intevation.net      (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20090106/993cf654/attachment.bin

From bernhard at intevation.de  Tue Jan  6 09:45:10 2009
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 6 Jan 2009 09:45:10 +0100
Subject: [Kolab-devel] singleinstancestore within Cyrus (Re: Multiple
	Kolab's php eat all the RAM)
In-Reply-To: <71fe4e760901050206h7d4052e5w678ef79e951b0dee@mail.gmail.com>
References: <200812231807.41967.dvadell@linuxclusters.com.ar>
	<200901050936.54654.bernhard.reiter@intevation.de>
	<71fe4e760901050206h7d4052e5w678ef79e951b0dee@mail.gmail.com>
Message-ID: <200901060945.11128.bernhard@intevation.de>

On Montag, 5. Januar 2009, Alain Spineux wrote:
> > I do not recomment singleinstancestore on the imap backend,
> > as it might complicate backups and restores. Usually using group accounts
> > for account-less folders you can avoid too much double storage in the
> > common cases.
>
> This doesn't "complicate" the backup nor the restore, ?except if you
> want to keep this advantage during the backup and after the restore.
> This reduce by 3 the space for my hosted domains.
> This also require to use the good switch when using "du" :-)

So it is done by hardlinks I presume.
After a backup and restore the advantace is gone, 
which I would call a "complication". :)
(To me a backup - restore should lead to the same situation it was started 
from, at least in the main points a 3 times size increase is a main point.)


-- 
Managing Director - Owner: www.intevation.net      (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20090106/b35d16cf/attachment.bin

From bernhard at intevation.de  Tue Jan  6 09:47:25 2009
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 6 Jan 2009 09:47:25 +0100
Subject: [Kolab-devel] Solaris 10 Sparc Kolab V2.2.1 Beta 1
	PEAR-Horde-Channel-1.0 / PEAR-PHPUnit-Channel-1.0 find:
	cannot follow symbolic link
In-Reply-To: <DDD83D586B974E3BBB90148B97AFF288@comcept.ch>
References: <DDD83D586B974E3BBB90148B97AFF288@comcept.ch>
Message-ID: <200901060947.26234.bernhard@intevation.de>

Hi Andrea, Hi Daniel,

thanks for testing and giving feedback, we certainly want Kolab Server/OpenPKG 
to run on Solaris as well, so your feedback for the beta is quite important!

Bernhard

On Montag, 5. Januar 2009, ComCept Soliva wrote:
> I updated my documentation and added all issues with number recognized for
> Solaris 10 until now because overview is becoming complecate/worse. To
> install kolab on Solaris 10 is becoming more and more an adventure. It
> would be great if this issues can be solved in a easy way. My documentation
> helps probably to get the overview:
>
> http://www.comcept.ch/kolab2/2.2.1-beta1/solaris_10_kolab2_install.txt
>
> At the moment the installation is again running. Will give feedback as soon
> as it is finished or I find another issue (hopefully not :-)
>
> kind regards and a good start in 2009.



-- 
Managing Director - Owner: www.intevation.net      (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20090106/c84bbf01/attachment.bin

From aspineux at gmail.com  Wed Jan  7 07:57:59 2009
From: aspineux at gmail.com (Alain Spineux)
Date: Wed, 7 Jan 2009 07:57:59 +0100
Subject: [Kolab-devel] Horde can now store Preferences in IMAP (was:
	Horde preferences: LDAP or IMAP?)
In-Reply-To: <200901060937.16694.bernhard@intevation.de>
References: <87zlz1trxh.fsf@home.pardus.de>
	<200901051019.55540.bernhard@intevation.de>
	<200901051139.31696.martin.konold@erfrakon.de>
	<200901060937.16694.bernhard@intevation.de>
Message-ID: <71fe4e760901062257y4a96e77btf31cfd5c02940f20@mail.gmail.com>

On Tue, Jan 6, 2009 at 9:37 AM, Bernhard Reiter <bernhard at intevation.de> wrote:
> Moin Martin,
>
> [to kolab-devel@ only as this is mainly about the implementation]
>
> On Montag, 5. Januar 2009, Martin Konold wrote:
>> Am Montag, 5. Januar 2009 10:19:55 schrieb Bernhard Reiter:
>> > This is what makes the discussion interesting. The use of LDAP for
>> > daily client preferences in Kolab Server 2.2.0 was by mistake.
>>
>> No it was an intermediate solution in order to avoid an additional piece of
>> compley software (RDBMS).
>
> my remark was technical about the server 2.2.0
> and the web client implementation coming with it.
> This web client was not scalable for several servers
> (as it should have been) and it should not have used LDAP.
>
>> > Until we have a good proposal for the Kolab Format, it should be file,
>> > as this is what most other clients also use.
>>
>> Using a file instead of IMAP breaks the scalability aspect of the Kolab
>> Webclient.
>
> I merely suggested to use file as default until we have come up with a nice
> proposal for the IMAP format which also incoporates other clients.
>
>> > A client could potentially write this data on any display refresh
>> > or client action. Just think about index files that contain special flags
>> > per email. So I guess that there will be always client data that will
>> > need to be saved client locally per user.
>>
>> I don't understand this. E.g. a webclient can easily use the more efficient
>> session instead of persistent storage in order to keep volatile data (which
>> can easily be regenerated anyway)
>
> Hmm, I am also still thinking about this.
>
> Let us assume a folder with 20K emails in it,

A folder with 20K emails is only usable with a search engine.
Displaying the list of email is useless !
The user will quickly understand it should not access this folder with
a webmail :-)
If your webmail allow you to search on a folder without selecting it
as your current,
you must have enough functionalities !

Just my 0.02

> Kontact keeps an index files to accelerate the display of this information.
> If it would not keep such an index files between sessions, it would need to
> parse all 20K emails on the first selection of the folder or startup.
> This seems to indicate that someone would need a permanent local storage
> for the client.
>
> Note that also for Kontact you would need different preferences
> settings as you usually have one client in your workplace, one at home, one
> mobile netbook and you would want different settings with them, e.g.
> a different local subscription of folders.
> It would be cool for the Kolab Concept to support all these different
> needs for storing configurations, but the problem seems to be hard.
> There are meanwhile two discontinued attempts by the Cyrus people to solve
> this problems.
>
> Bernhard
>
> --
> Managing Director - Owner: www.intevation.net      (Free Software Company)
> Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
> Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
> Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
Alain Spineux
aspineux gmail com
May the sources be with you


From aspineux at gmail.com  Wed Jan  7 08:06:36 2009
From: aspineux at gmail.com (Alain Spineux)
Date: Wed, 7 Jan 2009 08:06:36 +0100
Subject: [Kolab-devel] singleinstancestore within Cyrus (Re: Multiple
	Kolab's php eat all the RAM)
In-Reply-To: <200901060945.11128.bernhard@intevation.de>
References: <200812231807.41967.dvadell@linuxclusters.com.ar>
	<200901050936.54654.bernhard.reiter@intevation.de>
	<71fe4e760901050206h7d4052e5w678ef79e951b0dee@mail.gmail.com>
	<200901060945.11128.bernhard@intevation.de>
Message-ID: <71fe4e760901062306i41e01e6exdaafca142369a6ec@mail.gmail.com>

On Tue, Jan 6, 2009 at 9:45 AM, Bernhard Reiter <bernhard at intevation.de> wrote:
> On Montag, 5. Januar 2009, Alain Spineux wrote:
>> > I do not recomment singleinstancestore on the imap backend,
>> > as it might complicate backups and restores. Usually using group accounts
>> > for account-less folders you can avoid too much double storage in the
>> > common cases.
>>
>> This doesn't "complicate" the backup nor the restore,  except if you
>> want to keep this advantage during the backup and after the restore.
>> This reduce by 3 the space for my hosted domains.
>> This also require to use the good switch when using "du" :-)
>
> So it is done by hardlinks I presume.
> After a backup and restore the advantace is gone,
> which I would call a "complication". :)

It depend the tool you are using for your backup, some manage the hard links,
afio was one

> (To me a backup - restore should lead to the same situation it was started
> from, at least in the main points a 3 times size increase is a main point.)

But this is also a shrinking of 3 !

3 times less time and less space to backup, 3 times less space on disk,
3 times less time when doing a "fsck", 3 times more user on the same disk ...

Best regards.



>
>
> --
> Managing Director - Owner: www.intevation.net      (Free Software Company)
> Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
> Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
> Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
Alain Spineux
aspineux gmail com
May the sources be with you


From wrobel at pardus.de  Wed Jan  7 13:22:29 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Wed, 07 Jan 2009 13:22:29 +0100
Subject: [Kolab-devel] Horde can now store Preferences in IMAP
	(was:	Horde preferences: LDAP or IMAP?)
In-Reply-To: <71fe4e760901020436q73afb633lada4ac0f620881c8@mail.gmail.com>
References: <87zlz1trxh.fsf@home.pardus.de>
	<200710022328.32145.martin.konold@erfrakon.de>
	<71fe4e760710021605l6a2d79c0le78f0d70adb8347d@mail.gmail.com>
	<200710301025.13994.stephane@voyageonline.co.uk>
	<87odeetdzx.fsf@home.pardus.de> <87ejaf84wp.fsf_-_@home.pardus.de>
	<20081221234248.12067680kz9f5dgc@webmail.pardus.de>
	<71fe4e760901020436q73afb633lada4ac0f620881c8@mail.gmail.com>
Message-ID: <20090107132229.61942f5wekgq8jgg@webmail.pardus.de>

Quoting Alain Spineux <aspineux at gmail.com>:

> 2008/12/21 Gunnar Wrobel <wrobel at pardus.de>:
>> Hi!
>>
>> A while back (beginning of this year) we had a discussion on how to store
>> the user preferences of the Kolab webclient (based on Horde).
>>
>> Horde preferences are being handled by a single module called "prefs". This
>> module supports several backends. Among them are
>>
>>  - SQL
>>  - LDAP
>>  - File based
>>  - IMAP
>>
>> Horde usually uses SQL. Kolab has traditionally used the LDAP backend. This
>> LDAP backend has been replaced with the file based backend for Kolab Server
>> 2.2.1 beta 1. An alternative would also be the storage in IMAP similar to
>> the other groupware data of the Kolab server.
>>
>> The decision to switch to the file based approach was made since the
>> developer team did not consider LDAP to be a decent place for such data
>> anymore. It makes the LDAP entries rather complex and LDAP is usually meant
>> primarily for read access rater than a standard storage space.
>>
>> We decided not to use IMAP at the moment as that would mean we would need to
>> discuss the Kolab format for such entries wich would take a while until we
>> finalize it.
>>
>> So the file based approach has been selected for now.
>>
>> This does not hinder anyone to choose any of the other possible backends.
>> People that like to remain on LDAP can do so without problems while people
>> preferring IMAP storage can also choose to do so.
>>
>> But the question still is: What is the best default?
>>
>> It would be great if people could add the pros and cons they see for the
>> different solutions. I'll try to add an overview once we have some opinions
>> and I'll include the relevant pieces from the discussion we had at the
>> beginning of this year.
>>
>> I would like to add that I personally see the IMAP driver as the best
>> choice. For me the Kolab server architecture results in one simple
>> conclusion: User data belongs into IMAP. And preferences are user data.
>
> Pro IMAP too.
> File based approach require to add something into the backup or the
> migration procedure.
> Anyway, when does these data need to be READ or WRITTEN ?
> At each mail access, or at each folrder access, or just once at login
> and logout ?

The data needs to be READ on nearly every page access. Preferences are  
used at many different places within the Kolab web client. E.g. which  
calendars to display, the last time you logged in, your real name etc.

This data needs to be WRITTEN whenever one or several of these  
preferences changes. This may sometimes be the result of user action  
where you don't actually see that you changed something (e.g. the  
login -> your last login time gets stored in the preferences backend)  
but usually only when you actually switch a setting.

Cheers,

Gunnar
>
>>
>> Cheers,
>>
>> Gunnar
>>
>> Quoting Gunnar Wrobel <wrobel at pardus.de>:
>>
>>> Gunnar Wrobel <wrobel at pardus.de> writes:
>>>
>>>> Stephane Konstantaropoulos <stephane at voyageonline.co.uk> writes:
>>>>
>>>>> Hello,
>>>>>
>>>>> I fully agree with Alain, the LDAP preferences backend for Horde is
>>>>> efficient
>>>>> and is there, I see no point in creating a new one. Plus it is very easy
>>>>> to
>>>>> admin for shops that use LDAP for a lot of things, such as Samba or
>>>>> POSIX
>>>>> auth. We use LDAP as a backend for most of our users' stuff and it is
>>>>> very
>>>>> solid.
>>>>
>>>> Thanks for the feedback. The LDAP preferences backend will definitely
>>>> stay the default backend now. People convinced me :)
>>>>
>>>> The IMAP preferences backend might still find it's way into Horde CVS
>>>> at some point. But it will be purely optional then.
>>>
>>> The IMAP driver for preferences is available since yesterday within Horde.
>>>
>>> While most people will probably use the older LDAP driver I want to be
>>> able to have an "IMAP-only" Horde/Kolab with Horde 4.
>>>
>>> Cheers,
>>>
>>> Gunnar
>>>
>>>>
>>>> Cheers,
>>>>
>>>> Gunnar
>>>>
>>>>>
>>>>> We store iPlanet prefs, Samba prefs, Posix prefs and user data in there
>>>>> and
>>>>> that's what it is there for.
>>>>>
>>>>> I think you should stick to it with Horde, and perhaps see if you can
>>>>> optmize
>>>>> some stuff, like session caching or something.
>>>>>
>>>>> My production Horde is slowed down by the Imap server more than the LDAP
>>>>> server. (a few thousand users).
>>>>>
>>>>> My 2 cents
>>>>>
>>>>> Stephane
>>>>>
>>>>> Le Wednesday 03 October 2007 00:05:27 Alain Spineux, vous avez ?crit :
>>>>>>
>>>>>> On 10/2/07, Martin Konold <martin.konold at erfrakon.de> wrote:
>>>>>> > Am Dienstag 02 Oktober 2007 schrieb Gunnar Wrobel: out
>>>>>> >
>>>>>> > Hi Gunnar,
>>>>>> >
>>>>>> > thanks for taking up with this initiative.
>>>>>> >
>>>>>> > I am also not very happy with the current LDAP approach which
>>>>>> > clutters up
>>>>>> > the LDAP namespace very much and looks more like an abuse than like a
>>>>>> > useful directory. (e.g. many unused empty entries)
>>>>>>
>>>>>> This is the way LDAP works.
>>>>>>
>>>>>> LDAP is the perfect place to store data from different application
>>>>>> (but all related to the same object). Different apps can share the
>>>>>> same data from different place. LDAP provide ACL at
>>>>>> object and field level !
>>>>>>
>>>>>> > > I regard LDAP as a bad storage place for the web client preferences
>>>>>> > > and wrote a new preferences driver for Horde that uses an IMAP
>>>>>> > > folder
>>>>>> >
>>>>>> > Why did you rule out the simple option to use a plain file for each
>>>>>> > user?
>>>>>> > If this plain file is protected using Apache access control it would
>>>>>> > be
>>>>>> > trivial to make it available anywhere whithin a Kolab server cluster.
>>>>>> > E.g. you could store the file on the kolabHomeServer and use a URL
>>>>>> > like
>>>>>> > https://kolabhomeserver.domain.tld/config/horde-preferences. Because
>>>>>> > horde knows the users credentials it would be trivial to provide them
>>>>>> > to
>>>>>> > Apache. Using these credentials Apache or some php script could
>>>>>> > internally use the correct user specific file
>>>>>>
>>>>>> And how do you modify this file from remote location ?
>>>>>>
>>>>>> You are designing file format, data access ... while LDAP already
>>>>>> exist, with all this stuff.
>>>>>> Why do you want to reinvent the wheel ?
>>>>>>
>>>>>> > If figuring out the kolabhomeserver via LDAP is not an option it
>>>>>> > could be
>>>>>> > handled trivially by the php script running on any server in a
>>>>>> > transparent manner.
>>>>>> >
>>>>>> > > The advantages of this driver: The LDAP schemas don't have to be
>>>>>> > > modified
>>>>>>
>>>>>> just add a "include" in slapd.conf ... not to much works
>>>>>>
>>>>>> >and the users can be plain KolabInetOrgPerson objects.
>>>>>>
>>>>>> is it an advantage ?  Could not my users be samba users ? Or asterisk
>>>>>> one ?
>>>>>>
>>>>>> > In
>>>>>> >
>>>>>> > > addition this reduces LDAP read/write operations.
>>>>>>
>>>>>> Do you need to economize LDAP, are imap or file access cheaper ?
>>>>>> You can cache these data into the PHP sessions data !
>>>>>>
>>>>>> > I fully agree!
>>>>>> >
>>>>>> > > The disadvantages: There is a new folder type and the other clients
>>>>>> > > might display a "Preferences"-Folder with mails they can't really
>>>>>> > > use.
>>>>>> >
>>>>>> > Well, you would still have the option of "hiding" this special folder
>>>>>> > from other clients using ACLs and subscription state.
>>>>>>
>>>>>> Sure ? completely hidden ? No risk for the user to erase this "strange"
>>>>>> folder ?
>>>>>>
>>>>>> > > 1) Do people regard it as a desired alternative to store the
>>>>>> > > preferences on IMAP? Any specific drawbacks or advantages I missed?
>>>>>>
>>>>>> The main kolab idea was to retrieve/store all data from LDAP and then
>>>>>> kolabd was synchronizing them into IMAP (creating mailbox, .......)
>>>>>> Why do you want to put data somewhere else ?
>>>>>> Then why not write directly postfix, apache, cyrus template from the
>>>>>> GUI ?
>>>>>>
>>>>>> > I think that IMAP is an option while a plain URL pointing at some
>>>>>> > trivial
>>>>>> > PHP script is better. This script could provide transparency in case
>>>>>> > of a
>>>>>> > clustering setup and as an added bonus it could allow trivial REST
>>>>>> > features.
>>>>>>
>>>>>> LDAP already provide this out of the box :-)
>>>>>>
>>>>>> > This means that calling the script without parameters e.g.
>>>>>> > https://kolabhomeserver.domain.tld/config/horde-preferences will
>>>>>> > provide
>>>>>> > a single document with some trivial file format (e.g. key=value or
>>>>>> > some
>>>>>> > simple XML). E.g. in doing a HTTP GET to
>>>>>> > https://kolabhomeserver.domain.tld/config/hordePrefs would provide
>>>>>> > something like:
>>>>>>
>>>>>> Still imagining powerful, but less standard data access ?
>>>>>>
>>>>>> > [...]
>>>>>> > summary_refresh_time=10
>>>>>> > show_sidebar=true
>>>>>> > sidebar_width=40
>>>>>> > menu_refresh_time=100
>>>>>> > [...]
>>>>>> >
>>>>>> > On the other hand
>>>>>> >
>>>>>> >  
>>>>>> https://kolabhomeserver.domain.tld/config/hordePrefs?action=get&key=show_
>>>>>> >sidebar would return a document only containing the string "true". If
>>>>>> > the
>>>>>> > implementation benefits returning "show_sidebar=true" is also an
>>>>>> > option.
>>>>>> >
>>>>>> > In this simple model it would be the job of the horde application to
>>>>>> > know
>>>>>> > that the string "true" refers to a bool. Doing so is imho trivial in
>>>>>> > case
>>>>>> > of horde. This would allow to limit the capabilities of the
>>>>>> > preference
>>>>>> > storage service to simple strings.
>>>>>> >
>>>>>> > The php script hordePrefs.php would trivially be able to distinguish
>>>>>> > the
>>>>>> > users from the mandatory credentials.
>>>>>> >
>>>>>> > The actual backend used (e.g. a flat file or a small berkley DB) is
>>>>>> > then
>>>>>> > a simple opaque implementation detail.
>>>>>>
>>>>>> Did I already suggested you can use LDAP instead ? :-)
>>>>>>
>>>>>> > Storing a single key would be done using an URL like
>>>>>> >
>>>>>> >  
>>>>>> https://kolabhomeserver.domain.tld/config/hordePrefs?action=set&key=show_
>>>>>> >sidebar&value=false
>>>>>> >
>>>>>> > > 2) If this driver should be available what should be the default
>>>>>> > > option?
>>>>>> >
>>>>>> > IMAP is definetly better than LDAP but imho other options like my
>>>>>> > proposal should be considered.
>>>>>>
>>>>>> Yes IMAP is excel in storing /retrieving emails :-)
>>>>>>
>>>>>> > > The second question is important since we would need to ship the
>>>>>> > > driver with the earliest release possible. Otherwise we might get
>>>>>> > > people running this in production that will have to run
>>>>>> > > "preferences
>>>>>> > > conversion scripts" (that would have to be written) if we ever
>>>>>> > > change
>>>>>> > > the default option.
>>>>>> >
>>>>>> > Regards,
>>>>>> > -- martin konold
>>>>>> >
>>>>>> > --
>>>>>> > e r f r a k o n
>>>>>> > Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
>>>>>> > Sitz: Adolfstra?e 23 Stuttgart - Partnerschaftsregister Stuttgart PR
>>>>>> > 126
>>>>>> > http://www.erfrakon.com/
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > Kolab-devel mailing list
>>>>>> > Kolab-devel at kolab.org
>>>>>> > https://kolab.org/mailman/listinfo/kolab-devel
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> St?phane Konstantaropoulos
>>>>> -- Creator, Web Applications
>>>>> _______________________________________________
>>>>> Kolab-devel mailing list
>>>>> Kolab-devel at kolab.org
>>>>> https://kolab.org/mailman/listinfo/kolab-devel
>>>>
>>>> --
>>>> ______ http://kdab.com _______________ http://kolab-konsortium.com _
>>>>
>>>> p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium
>>>>
>>>> ____ http://www.pardus.de _________________ http://gunnarwrobel.de _
>>>> E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
>>>> Tel.   : +49 40 432 72335                           Bundesstrasse 29
>>>> Fax    : +49 40 432 70855                            D-20146 Hamburg
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>   >> Mail at ease - Rent a kolab groupware server at p at rdus <<
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>
>>>> _______________________________________________
>>>> Kolab-devel mailing list
>>>> Kolab-devel at kolab.org
>>>> https://kolab.org/mailman/listinfo/kolab-devel
>>>
>>> --
>>> ______ http://kdab.com _______________ http://kolab-konsortium.com _
>>>
>>> p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium
>>>
>>> ____ http://www.pardus.de _________________ http://gunnarwrobel.de _
>>> E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
>>> Tel.   : +49 700 6245 0000                          Bundesstrasse 29
>>> Fax    : +49 721 1513 52322                          D-20146 Hamburg
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>   >> Mail at ease - Rent a kolab groupware server at p at rdus <<
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> _______________________________________________
>>> Kolab-devel mailing list
>>> Kolab-devel at kolab.org
>>> https://kolab.org/mailman/listinfo/kolab-devel
>>
>>
>>
>> --
>> ______ http://kdab.com _______________ http://kolab-konsortium.com _
>>
>> p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium
>>
>> ____ http://www.pardus.de _________________ http://gunnarwrobel.de _
>> E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
>> Tel.   : +49 700 6245 0000                          Bundesstrasse 29
>> Fax    : +49 721 1513 52322                          D-20146 Hamburg
>> --------------------------------------------------------------------
>>   >> Mail at ease - Rent a kolab groupware server at p at rdus <<
>> --------------------------------------------------------------------
>>
>>
>> ----------------------------------------------------------------
>> This message was sent using IMP, the Internet Messaging Program.
>>
>> _______________________________________________
>> Kolab-devel mailing list
>> Kolab-devel at kolab.org
>> https://kolab.org/mailman/listinfo/kolab-devel
>>
>
>
>
> --
> Alain Spineux
> aspineux gmail com
> May the sources be with you
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
Url : http://kolab.org/pipermail/kolab-devel/attachments/20090107/27467abf/attachment.bin

From soliva at comcept.ch  Wed Jan  7 13:33:10 2009
From: soliva at comcept.ch (ComCept Soliva)
Date: Wed, 7 Jan 2009 13:33:10 +0100
Subject: [Kolab-devel] Solaris 10 Sparc Kolab V2.2.1 Beta 1 kolabd-2.2.1
	error: Installing crontab entry
Message-ID: <7C80011DD4E44EDD9AB05076D4C26AF1@comcept.ch>

Hi all

I forced the installation of the kolabd package because my opinion is that
apache was correct installed.

Within the the installation of the package another error occured:

# /kolab/bin/openpkg rpm --force --nodeps -Uvh
/kolab/RPM/PKG/kolabd-2.2.1-20081212.sparc64-solaris10-kolab.rpm
Preparing...                ###########################################
[100%]
   1:kolabd                 ###########################################
[100%]
Installing crontab entry
crontab: illegal option -- u
crontab: proper usage is: 
        crontab [file | -e | -l | -r ] [user]crontab: 
proper usage is: 
        crontab [file | -e | -l | -r ] [user]
For a fresh install please initialize Kolab by running
'/kolab/sbin/kolab_bootstrap -b' as user root.
If you upgraded from a previous version simply refresh Kolab by running run
'/kolab/sbin/kolabconf' as user root.
In every case execute '/kolab/bin/openpkg rc kolabd restart' as user root.

Updated documentation is available here with all logs of install:

http://www.comcept.ch/kolab2/2.2.1-beta1/

kind regards

Andrea

Mail: soliva at comcept.ch 


From wrobel at pardus.de  Wed Jan  7 14:05:26 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Wed, 07 Jan 2009 14:05:26 +0100
Subject: [Kolab-devel] Solaris 10 Sparc Kolab V2.2.1
	Beta	1	PEAR-Horde-Channel-1.0 find: cannot follow symbolic link
In-Reply-To: <4961C6CB.2060505@rrz.uni-hamburg.de>
References: <F095FCE31D23483AA7CA445E013F429E@comcept.ch>
	<4961C6CB.2060505@rrz.uni-hamburg.de>
Message-ID: <20090107140526.111831rlhgyuhkmc@webmail.pardus.de>

Quoting Daniel Vergien <daniel.vergien at rrz.uni-hamburg.de>:

> On 12/31/08 03:37 PM, ComCept Soliva wrote:
>> Hi Gunnar
>>
>> the install-kolab.sh failed again also with a old issue for
>> PEAR-Horde-Channel-1.0 (I think I saw already this issue). I have no idea
>> how to proceed? Any suggestion?
>
> It seems to be a problem with /usr/sbin/install on solaris which is a
> bit limitated compared to the linux ones. I helpt myself by changing
> the install call in the specfile to /kolab/lib/openpkg/shtool install
> and remove the -p option.

Might be easier to rename the source file to the final file name in  
the Source0 statement. Commented in the bug.

Cheers,

Gunnar

>
> See https://www.intevation.de/roundup/kolab/issue3315
>
> Daniel
>
>
>
>
>> Log is available
>> http://www.comcept.ch/kolab2/2.2.1-beta1/kolab-install-Dec-31-10-14-54.zip:
>>
>>
>>
>> :::: /tmp/install-kolab....8544/PEAR-Horde-Channel-1.0-20081210.src.rpm ::::
>> Installing
>> /tmp/install-kolab....8544/PEAR-Horde-Channel-1.0-20081210.src.rpm
>> Executing(%prep): env -i /kolab/lib/openpkg/bash --norc --noprofile --posix
>> -e /kolab/RPM/TMP/rpm-tmp.6248
>> + cd /kolab/RPM/TMP
>> + set +x
>> +----------------------------------Warning----------------------------------
>> --+
>> | This OpenPKG package is of class JUNK.
>> |
>> | This means it is still in DEVELOPMENT state.
>> |
>> | Hence it is still NOT ready even for general evaluation.
>> |
>> | Do not use it at all, except in development environments!
>> |
>> | It is definitely unstable and incompletely packaged.
>> |
>> +---------------------------------------------------------------------------
>> --+
>> + cd /kolab/RPM/TMP
>> + rm -rf PEAR-Horde-Channel-1.0
>> + /kolab/lib/openpkg/shtool mkdir -f -p -m 755 PEAR-Horde-Channel-1.0
>> + cd PEAR-Horde-Channel-1.0
>> + exit 0
>> Executing(%build): env -i /kolab/lib/openpkg/bash --norc --noprofile --posix
>> -e /kolab/RPM/TMP/rpm-tmp.6248
>> + cd /kolab/RPM/TMP
>> + cd PEAR-Horde-Channel-1.0
>> + exit 0
>> Executing(%install): env -i /kolab/lib/openpkg/bash --norc --noprofile
>> --posix -e /kolab/RPM/TMP/rpm-tmp.6248
>> + cd /kolab/RPM/TMP
>> + cd PEAR-Horde-Channel-1.0
>> + rm -rf /kolab/RPM/TMP/PEAR-Horde-Channel-1.0-root
>> + mkdir -p /kolab/RPM/TMP/PEAR-Horde-Channel-1.0-root/kolab/var/pear
>> + install -pm 644 /kolab/RPM/SRC/PEAR-Horde-Channel/channel.xml
>> /kolab/RPM/TMP/PEAR-Horde-Channel-1.0-root/kolab/var/pear/pear.horde.org.xml
>> find: stat() error 644: No such file or directory
>> find: stat() error
>> /kolab/RPM/TMP/PEAR-Horde-Channel-1.0-root/kolab/var/pear/pear.horde.org.xml
>> : No such file or directory
>> find: cannot read dir /etc/inet/secret: Permission denied
>> find: cannot read dir /etc/flash/postcreation: Permission denied
>> find: cannot read dir /etc/flash/precreation: Permission denied
>> find: cannot read dir /etc/flash/preexit: Permission denied
>> find: cannot follow symbolic link /usr/lib/llib-lgen: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lnvpair.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-ltermlib: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lsec.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lumem: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/libmeta.so.1: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lsendfile: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lsendfile.ln: No such file
>> or directory
>> find: cannot follow symbolic link /usr/lib/llib-lrtld_db.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lresolv.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lsec: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-luuid: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lrt.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-ldoor: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lposix4: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lrt: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lscf.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lcurses: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lrtld_db.ln: No such file
>> or directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lrt.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lcurses.ln: No such file
>> or directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lefi.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lcontract.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lintl.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/64/llib-laio.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/64/llib-ldevid.ln: No such file
>> or directory
>> find: cannot follow symbolic link /usr/lib/64/llib-ltermcap: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lpam.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lelf.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/64/llib-ltsnet.ln: No such file
>> or directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lthread_db.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/64/llib-ltermlib.ln: No such file
>> or directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lpthread.ln: No such file
>> or directory
>> find: cannot follow symbolic link /usr/lib/64/llib-ldl.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lgen.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lctf.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lthread.ln: No such file
>> or directory
>> find: cannot follow symbolic link /usr/lib/64/llib-ltermlib: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/64/llib-ldevice.ln: No such file
>> or directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lposix4.ln: No such file
>> or directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lscf.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lkstat.ln: No such file
>> or directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lsendfile.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lsocket.ln: No such file
>> or directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lc.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lsec.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/64/llib-ldoor.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lsecdb.ln: No such file
>> or directory
>> find: cannot follow symbolic link /usr/lib/64/llib-ltsol.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lumem.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lsysevent.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lbsm.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/64/llib-ladm.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/64/llib-ldevinfo.ln: No such file
>> or directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lnsl.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/64/llib-ltermcap.ln: No such file
>> or directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lnvpair.ln: No such file
>> or directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lmd5.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lxnet.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lcmd.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/64/llib-lresolv.ln: No such file
>> or directory
>> find: cannot follow symbolic link /usr/lib/64/llib-luuid.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lc.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lnsl.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-ltermcap: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lc: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lcmd.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lsysevent.ln: No such file
>> or directory
>> find: cannot follow symbolic link /usr/lib/llib-lmd5.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lintl: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lsecdb.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lpthread.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-ltermlib.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lbsm.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lsocket: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-ldevinfo: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lkstat.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-ladm.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lintl.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lsecdb: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lsocket.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-ldl.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lsysevent: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lctf: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lcontract: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lposix4.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lxnet.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lrtld_db: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-ldevice.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lcontract.ln: No such file
>> or directory
>> find: cannot follow symbolic link /usr/lib/llib-luuid.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-ladm: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-ldevice: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lkstat: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lthread.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lcurses: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lthread_db: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lumem.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lefi.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lscf: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-laio.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lefi: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-ltsnet.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-ldevid.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lgen.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lpthread: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lcurses: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lrtld_db.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lrt.ln: No such file
>> or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lcurses.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lefi.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lcontract.ln: No
>> such file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lintl.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-laio.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ldevid.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ltermcap: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lpam.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lelf.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ltsnet.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lthread_db.ln: No
>> such file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ltermlib.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lpthread.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ldl.ln: No such file
>> or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lgen.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lctf.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lthread.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ltermlib: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ldevice.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lposix4.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lscf.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lkstat.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lsendfile.ln: No
>> such file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lsocket.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lc.ln: No such file
>> or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lsec.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ldoor.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lsecdb.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ltsol.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lumem.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lsysevent.ln: No
>> such file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lbsm.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ladm.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ldevinfo.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lnsl.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-ltermcap.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lnvpair.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lmd5.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lxnet.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lcmd.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-lresolv.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/sparcv9/llib-luuid.ln: No such
>> file or directory
>> find: cannot follow symbolic link /usr/lib/llib-lelf: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lctf.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-ltsol.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lbsm: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lthread: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lthread_db.ln: No such file
>> or directory
>> find: cannot follow symbolic link /usr/lib/llib-ldoor.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-ldevid: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-ldevinfo.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/libmeta.so: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-ltermcap.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-laio: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lelf.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lpam.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lcurses.ln: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lnvpair: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lmd5: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lnsl: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lcmd: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lpam: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lresolv: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-lxnet: No such file or
>> directory
>> find: cannot follow symbolic link /usr/lib/llib-ldl: No such file or
>> directory
>> install: -pm was not found anywhere!
>> error: Bad exit status from /kolab/RPM/TMP/rpm-tmp.6248 (%install)
>>
>>
>> RPM build errors:
>>     Bad exit status from /kolab/RPM/TMP/rpm-tmp.6248 (%install)
>> + exit 1
>>
>>
>> kind regards
>>
>> Andrea
>>
>>
>>
>> Mail: soliva at comcept.ch
>>
>> _______________________________________________
>> Kolab-devel mailing list
>> Kolab-devel at kolab.org
>> https://kolab.org/mailman/listinfo/kolab-devel
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
Url : http://kolab.org/pipermail/kolab-devel/attachments/20090107/5dd39b20/attachment-0001.bin

From soliva at comcept.ch  Wed Jan  7 14:19:43 2009
From: soliva at comcept.ch (ComCept Soliva)
Date: Wed, 7 Jan 2009 14:19:43 +0100
Subject: [Kolab-devel] Solaris 10 Sparc Kolab V2.2.1 Beta 1
	kolab-fbview-1.2.0 Permission denied
Message-ID: <FB00F26E4AA6450D8E1B47F17A341B15@comcept.ch>

Hi all

I proceeded and runned in the next error:

:::: /tmp/install-kolab....8544/kolab-fbview-1.2.0-20081212.src.rpm ::::
Installing /tmp/install-kolab....8544/kolab-fbview-1.2.0-20081212.src.rpm
Executing(%prep): env -i /kolab/lib/openpkg/bash --norc --noprofile --posix
-e /kolab/RPM/TMP/rpm-tmp.8672
+ cd /kolab/RPM/TMP
+ set +x
+----------------------------------Warning----------------------------------
--+
| This OpenPKG package is of class JUNK.
|
| This means it is still in DEVELOPMENT state.
|
| Hence it is still NOT ready even for general evaluation.
|
| Do not use it at all, except in development environments!
|
| It is definitely unstable and incompletely packaged.
|
+---------------------------------------------------------------------------
--+
+ cd /kolab/RPM/TMP
+ rm -rf kolab-fbview-1.2.0
+ /kolab/lib/openpkg/shtool mkdir -f -p -m 755 kolab-fbview-1.2.0
+ cd kolab-fbview-1.2.0
+ /kolab/lib/openpkg/gzip -dc
/kolab/RPM/SRC/kolab-fbview/horde-webmail-1.2.tar.gz
+ /kolab/lib/openpkg/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd horde-webmail-1.2
+ echo 'Patch #0 (horde-webmail-1.2.0_kolab_fbview_openpkg.patch):'
Patch #0 (horde-webmail-1.2.0_kolab_fbview_openpkg.patch):
+ /kolab/lib/openpkg/patch -p1 -s -b
+ cd ..
+ exit 0
Executing(%build): env -i /kolab/lib/openpkg/bash --norc --noprofile --posix
-e /kolab/RPM/TMP/rpm-tmp.30962
+ cd /kolab/RPM/TMP
+ cd kolab-fbview-1.2.0
+ exit 0
Executing(%install): env -i /kolab/lib/openpkg/bash --norc --noprofile
--posix -e /kolab/RPM/TMP/rpm-tmp.15032
+ cd /kolab/RPM/TMP
+ cd kolab-fbview-1.2.0
+ /kolab/lib/openpkg/shtool install -d
/kolab/RPM/TMP/kolab-fbview-1.2.0-root/kolab/var/kolab/www/fbview
+ /kolab/lib/openpkg/shtool install -d
/kolab/RPM/TMP/kolab-fbview-1.2.0-root/kolab/var/kolab/tmp
+ /kolab/lib/openpkg/shtool install -d
/kolab/RPM/TMP/kolab-fbview-1.2.0-root/kolab/var/kolab/storage
+ /kolab/lib/openpkg/shtool install -d
/kolab/RPM/TMP/kolab-fbview-1.2.0-root/kolab/etc/kolab/templates
+ cd horde-webmail-1.2
+ find . -name test.php
+ xargs rm
+ find . -name '*.orig'
+ xargs rm
+ rm -rf dimp imp ingo mimp mnemo nag
+ cd kronolith
+ rm add.php day.php view.php delete.php ics.php search.php week.php
contacts.php imple.php month.php pref_api.php workweek.php edit.php new.php
year.php attend.php data.php event.php
+ cd ..
+ cp -r COPYING README admin config docs index.php js kronolith lib locale
log login.php notconfigured.html pear po rpc rpc.php scripts services
signup.php storage templates themes tmp turba util
/kolab/RPM/TMP/kolab-fbview-1.2.0-root/kolab/var/kolab/www/fbview/
cp: cannot open log/.htaccess.orig: Permission denied
cp: cannot open storage/.htaccess.orig: Permission denied
cp: cannot open tmp/.htaccess.orig: Permission denied
error: Bad exit status from /kolab/RPM/TMP/rpm-tmp.15032 (%install)


RPM build errors:
    Bad exit status from /kolab/RPM/TMP/rpm-tmp.15032 (%install)
+ exit 1 



I had a look to the spec file but I can not find what is going wrong and why
it failed with Permission denied?

Any hints what can be manipulated that I can proceed?

Update documentation:

http://www.comcept.ch/kolab2/2.2.1-beta1/solaris_10_kolab2_install.txt

Here the log file for this part of installation:

http://www.comcept.ch/kolab2/2.2.1-beta1/kolab-install-Jan-7-13-35-20.zip

kind regards

Andrea

Mail: soliva at comcept.ch 


From daniel.vergien at rrz.uni-hamburg.de  Wed Jan  7 16:19:25 2009
From: daniel.vergien at rrz.uni-hamburg.de (Daniel Vergien)
Date: Wed, 07 Jan 2009 16:19:25 +0100
Subject: [Kolab-devel] Solaris 10 Sparc Kolab V2.2.1 Beta
 1	kolab-fbview-1.2.0 Permission denied
In-Reply-To: <FB00F26E4AA6450D8E1B47F17A341B15@comcept.ch>
References: <FB00F26E4AA6450D8E1B47F17A341B15@comcept.ch>
Message-ID: <4964C7FD.9050107@rrz.uni-hamburg.de>

Hi Andrea,

see https://www.intevation.de/roundup/kolab/issue3318

Daniel

On 01/07/09 02:19 PM, ComCept Soliva wrote:
> Hi all
> 
> I proceeded and runned in the next error:
> 
> :::: /tmp/install-kolab....8544/kolab-fbview-1.2.0-20081212.src.rpm ::::
> Installing /tmp/install-kolab....8544/kolab-fbview-1.2.0-20081212.src.rpm
> Executing(%prep): env -i /kolab/lib/openpkg/bash --norc --noprofile --posix
> -e /kolab/RPM/TMP/rpm-tmp.8672
> + cd /kolab/RPM/TMP
> + set +x
> +----------------------------------Warning----------------------------------
> --+
> | This OpenPKG package is of class JUNK.
> |
> | This means it is still in DEVELOPMENT state.
> |
> | Hence it is still NOT ready even for general evaluation.
> |
> | Do not use it at all, except in development environments!
> |
> | It is definitely unstable and incompletely packaged.
> |
> +---------------------------------------------------------------------------
> --+
> + cd /kolab/RPM/TMP
> + rm -rf kolab-fbview-1.2.0
> + /kolab/lib/openpkg/shtool mkdir -f -p -m 755 kolab-fbview-1.2.0
> + cd kolab-fbview-1.2.0
> + /kolab/lib/openpkg/gzip -dc
> /kolab/RPM/SRC/kolab-fbview/horde-webmail-1.2.tar.gz
> + /kolab/lib/openpkg/tar -xf -
> + STATUS=0
> + '[' 0 -ne 0 ']'
> + cd horde-webmail-1.2
> + echo 'Patch #0 (horde-webmail-1.2.0_kolab_fbview_openpkg.patch):'
> Patch #0 (horde-webmail-1.2.0_kolab_fbview_openpkg.patch):
> + /kolab/lib/openpkg/patch -p1 -s -b
> + cd ..
> + exit 0
> Executing(%build): env -i /kolab/lib/openpkg/bash --norc --noprofile --posix
> -e /kolab/RPM/TMP/rpm-tmp.30962
> + cd /kolab/RPM/TMP
> + cd kolab-fbview-1.2.0
> + exit 0
> Executing(%install): env -i /kolab/lib/openpkg/bash --norc --noprofile
> --posix -e /kolab/RPM/TMP/rpm-tmp.15032
> + cd /kolab/RPM/TMP
> + cd kolab-fbview-1.2.0
> + /kolab/lib/openpkg/shtool install -d
> /kolab/RPM/TMP/kolab-fbview-1.2.0-root/kolab/var/kolab/www/fbview
> + /kolab/lib/openpkg/shtool install -d
> /kolab/RPM/TMP/kolab-fbview-1.2.0-root/kolab/var/kolab/tmp
> + /kolab/lib/openpkg/shtool install -d
> /kolab/RPM/TMP/kolab-fbview-1.2.0-root/kolab/var/kolab/storage
> + /kolab/lib/openpkg/shtool install -d
> /kolab/RPM/TMP/kolab-fbview-1.2.0-root/kolab/etc/kolab/templates
> + cd horde-webmail-1.2
> + find . -name test.php
> + xargs rm
> + find . -name '*.orig'
> + xargs rm
> + rm -rf dimp imp ingo mimp mnemo nag
> + cd kronolith
> + rm add.php day.php view.php delete.php ics.php search.php week.php
> contacts.php imple.php month.php pref_api.php workweek.php edit.php new.php
> year.php attend.php data.php event.php
> + cd ..
> + cp -r COPYING README admin config docs index.php js kronolith lib locale
> log login.php notconfigured.html pear po rpc rpc.php scripts services
> signup.php storage templates themes tmp turba util
> /kolab/RPM/TMP/kolab-fbview-1.2.0-root/kolab/var/kolab/www/fbview/
> cp: cannot open log/.htaccess.orig: Permission denied
> cp: cannot open storage/.htaccess.orig: Permission denied
> cp: cannot open tmp/.htaccess.orig: Permission denied
> error: Bad exit status from /kolab/RPM/TMP/rpm-tmp.15032 (%install)
> 
> 
> RPM build errors:
>     Bad exit status from /kolab/RPM/TMP/rpm-tmp.15032 (%install)
> + exit 1 
> 
> 
> 
> I had a look to the spec file but I can not find what is going wrong and why
> it failed with Permission denied?
> 
> Any hints what can be manipulated that I can proceed?
> 
> Update documentation:
> 
> http://www.comcept.ch/kolab2/2.2.1-beta1/solaris_10_kolab2_install.txt
> 
> Here the log file for this part of installation:
> 
> http://www.comcept.ch/kolab2/2.2.1-beta1/kolab-install-Jan-7-13-35-20.zip
> 
> kind regards
> 
> Andrea
> 
> Mail: soliva at comcept.ch 
> 
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel


From soliva at comcept.ch  Wed Jan  7 16:52:55 2009
From: soliva at comcept.ch (ComCept Soliva)
Date: Wed, 7 Jan 2009 16:52:55 +0100
Subject: [Kolab-devel] Solaris 10 Sparc Kolab V2.2.1 Beta 1
	kolab-fbview-1.2.0 Permission denied
Message-ID: <3561A58F078444A68A42781068A02B99@comcept.ch>

Hi all

I found the issue. Within the RPM/TMP dir there is the extract source of
kolab-fbview-1.2.0. Within this source you will find the files without
permissions:

----------   1 kolab    kolab          0 Jan  7 14:10
/opt/kolab/RPM/TMP/kolab-fbview-1.2.0/horde-webmail-1.2/storage/.htaccess.or
ig
----------   1 kolab    kolab          0 Jan  7 14:10
/opt/kolab/RPM/TMP/kolab-fbview-1.2.0/horde-webmail-1.2/tmp/.htaccess.orig
----------   1 kolab    kolab          0 Jan  7 14:10
/opt/kolab/RPM/TMP/kolab-fbview-1.2.0/horde-webmail-1.2/log/.htaccess.orig

Why it is in this way I do not know. Gunnar any comment?

My workaround is not the best way of course but in this way I can proceed:

# vi /kolab/RPM/SRC/kolab-fbview/kolab-fbview.spec

-------------------- /kolab/RPM/SRC/kolab-fbview/kolab-fbview.spec
--------------------

%install

chown kolab:kolab
/opt/kolab/RPM/TMP/kolab-fbview-1.2.0/horde-webmail-1.2/storage/.htaccess.or
ig
chown kolab:kolab
/opt/kolab/RPM/TMP/kolab-fbview-1.2.0/horde-webmail-1.2/tmp/.htaccess.orig
chown kolab:kolab
/opt/kolab/RPM/TMP/kolab-fbview-1.2.0/horde-webmail-1.2/log/.htaccess.orig

chmod 644
/opt/kolab/RPM/TMP/kolab-fbview-1.2.0/horde-webmail-1.2/storage/.htaccess.or
ig
chmod 644
/opt/kolab/RPM/TMP/kolab-fbview-1.2.0/horde-webmail-1.2/tmp/.htaccess.orig
chmod 644
/opt/kolab/RPM/TMP/kolab-fbview-1.2.0/horde-webmail-1.2/log/.htaccess.orig

-------------------- /kolab/RPM/SRC/kolab-fbview/kolab-fbview.spec
--------------------

# opa /kolab

# /kolab/bin/openpkg rpmbuild -bb
/kolab/RPM/SRC/kolab-fbview/kolab-fbview.spec

# /kolab/bin/openpkg rpm -Uvh /kolab/RPM/PKG/ 

# /kolab/bin/openpkg rpm -Uvh
/kolab/RPM/PKG/kolab-fbview-1.2.0-20081212.sparc64-solaris10-kolab.rpm

Again documentation etc. updated and posted:

http://www.comcept.ch/kolab2/2.2.1-beta1/solaris_10_kolab2_install.txt

kind regards

Andrea

Mail: soliva at comcept.ch 
-----Urspr?ngliche Nachricht-----
Von: ComCept Soliva [mailto:soliva at comcept.ch] Im Auftrag von
kolab-devel-bounces at kolab.org
Gesendet: Mittwoch, 7. Januar 2009 14:20
An: kolab-devel at kolab.org
Betreff: [Kolab-devel] Solaris 10 Sparc Kolab V2.2.1 Beta 1
kolab-fbview-1.2.0 Permission denied

Hi all

I proceeded and runned in the next error:

:::: /tmp/install-kolab....8544/kolab-fbview-1.2.0-20081212.src.rpm ::::
Installing /tmp/install-kolab....8544/kolab-fbview-1.2.0-20081212.src.rpm
Executing(%prep): env -i /kolab/lib/openpkg/bash --norc --noprofile --posix
-e /kolab/RPM/TMP/rpm-tmp.8672
+ cd /kolab/RPM/TMP
+ set +x
+----------------------------------Warning----------------------------------
--+
| This OpenPKG package is of class JUNK.
|
| This means it is still in DEVELOPMENT state.
|
| Hence it is still NOT ready even for general evaluation.
|
| Do not use it at all, except in development environments!
|
| It is definitely unstable and incompletely packaged.
|
+---------------------------------------------------------------------------
--+
+ cd /kolab/RPM/TMP
+ rm -rf kolab-fbview-1.2.0
+ /kolab/lib/openpkg/shtool mkdir -f -p -m 755 kolab-fbview-1.2.0
+ cd kolab-fbview-1.2.0
+ /kolab/lib/openpkg/gzip -dc
/kolab/RPM/SRC/kolab-fbview/horde-webmail-1.2.tar.gz
+ /kolab/lib/openpkg/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd horde-webmail-1.2
+ echo 'Patch #0 (horde-webmail-1.2.0_kolab_fbview_openpkg.patch):'
Patch #0 (horde-webmail-1.2.0_kolab_fbview_openpkg.patch):
+ /kolab/lib/openpkg/patch -p1 -s -b
+ cd ..
+ exit 0
Executing(%build): env -i /kolab/lib/openpkg/bash --norc --noprofile --posix
-e /kolab/RPM/TMP/rpm-tmp.30962
+ cd /kolab/RPM/TMP
+ cd kolab-fbview-1.2.0
+ exit 0
Executing(%install): env -i /kolab/lib/openpkg/bash --norc --noprofile
--posix -e /kolab/RPM/TMP/rpm-tmp.15032
+ cd /kolab/RPM/TMP
+ cd kolab-fbview-1.2.0
+ /kolab/lib/openpkg/shtool install -d
/kolab/RPM/TMP/kolab-fbview-1.2.0-root/kolab/var/kolab/www/fbview
+ /kolab/lib/openpkg/shtool install -d
/kolab/RPM/TMP/kolab-fbview-1.2.0-root/kolab/var/kolab/tmp
+ /kolab/lib/openpkg/shtool install -d
/kolab/RPM/TMP/kolab-fbview-1.2.0-root/kolab/var/kolab/storage
+ /kolab/lib/openpkg/shtool install -d
/kolab/RPM/TMP/kolab-fbview-1.2.0-root/kolab/etc/kolab/templates
+ cd horde-webmail-1.2
+ find . -name test.php
+ xargs rm
+ find . -name '*.orig'
+ xargs rm
+ rm -rf dimp imp ingo mimp mnemo nag
+ cd kronolith
+ rm add.php day.php view.php delete.php ics.php search.php week.php
contacts.php imple.php month.php pref_api.php workweek.php edit.php new.php
year.php attend.php data.php event.php
+ cd ..
+ cp -r COPYING README admin config docs index.php js kronolith lib locale
log login.php notconfigured.html pear po rpc rpc.php scripts services
signup.php storage templates themes tmp turba util
/kolab/RPM/TMP/kolab-fbview-1.2.0-root/kolab/var/kolab/www/fbview/
cp: cannot open log/.htaccess.orig: Permission denied
cp: cannot open storage/.htaccess.orig: Permission denied
cp: cannot open tmp/.htaccess.orig: Permission denied
error: Bad exit status from /kolab/RPM/TMP/rpm-tmp.15032 (%install)


RPM build errors:
    Bad exit status from /kolab/RPM/TMP/rpm-tmp.15032 (%install)
+ exit 1 



I had a look to the spec file but I can not find what is going wrong and why
it failed with Permission denied?

Any hints what can be manipulated that I can proceed?

Update documentation:

http://www.comcept.ch/kolab2/2.2.1-beta1/solaris_10_kolab2_install.txt

Here the log file for this part of installation:

http://www.comcept.ch/kolab2/2.2.1-beta1/kolab-install-Jan-7-13-35-20.zip

kind regards

Andrea

Mail: soliva at comcept.ch 

_______________________________________________
Kolab-devel mailing list
Kolab-devel at kolab.org
https://kolab.org/mailman/listinfo/kolab-devel


From wrobel at pardus.de  Wed Jan  7 20:28:04 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Wed, 07 Jan 2009 20:28:04 +0100
Subject: [Kolab-devel] Solaris 10 Sparc Kolab V2.2.1 Beta
	1	kolab-fbview-1.2.0 Permission denied
In-Reply-To: <3561A58F078444A68A42781068A02B99@comcept.ch>
References: <3561A58F078444A68A42781068A02B99@comcept.ch>
Message-ID: <20090107202804.63585ja4k9cvb98g@webmail.pardus.de>

Quoting ComCept Soliva <soliva at comcept.ch>:

> Hi all
>
> I found the issue. Within the RPM/TMP dir there is the extract source of
> kolab-fbview-1.2.0. Within this source you will find the files without
> permissions:
>
> ----------   1 kolab    kolab          0 Jan  7 14:10
> /opt/kolab/RPM/TMP/kolab-fbview-1.2.0/horde-webmail-1.2/storage/.htaccess.or
> ig
> ----------   1 kolab    kolab          0 Jan  7 14:10
> /opt/kolab/RPM/TMP/kolab-fbview-1.2.0/horde-webmail-1.2/tmp/.htaccess.orig
> ----------   1 kolab    kolab          0 Jan  7 14:10
> /opt/kolab/RPM/TMP/kolab-fbview-1.2.0/horde-webmail-1.2/log/.htaccess.orig
>
> Why it is in this way I do not know. Gunnar any comment?
>
> My workaround is not the best way of course but in this way I can proceed:
>
> # vi /kolab/RPM/SRC/kolab-fbview/kolab-fbview.spec
>
> -------------------- /kolab/RPM/SRC/kolab-fbview/kolab-fbview.spec
> --------------------
>
> %install
>
> chown kolab:kolab
> /opt/kolab/RPM/TMP/kolab-fbview-1.2.0/horde-webmail-1.2/storage/.htaccess.or
> ig
> chown kolab:kolab
> /opt/kolab/RPM/TMP/kolab-fbview-1.2.0/horde-webmail-1.2/tmp/.htaccess.orig
> chown kolab:kolab
> /opt/kolab/RPM/TMP/kolab-fbview-1.2.0/horde-webmail-1.2/log/.htaccess.orig
>
> chmod 644
> /opt/kolab/RPM/TMP/kolab-fbview-1.2.0/horde-webmail-1.2/storage/.htaccess.or
> ig
> chmod 644
> /opt/kolab/RPM/TMP/kolab-fbview-1.2.0/horde-webmail-1.2/tmp/.htaccess.orig
> chmod 644
> /opt/kolab/RPM/TMP/kolab-fbview-1.2.0/horde-webmail-1.2/log/.htaccess.orig
>
> -------------------- /kolab/RPM/SRC/kolab-fbview/kolab-fbview.spec
> --------------------
>
> # opa /kolab
>
> # /kolab/bin/openpkg rpmbuild -bb
> /kolab/RPM/SRC/kolab-fbview/kolab-fbview.spec
>
> # /kolab/bin/openpkg rpm -Uvh /kolab/RPM/PKG/
>
> # /kolab/bin/openpkg rpm -Uvh
> /kolab/RPM/PKG/kolab-fbview-1.2.0-20081212.sparc64-solaris10-kolab.rpm
>
> Again documentation etc. updated and posted:
>
> http://www.comcept.ch/kolab2/2.2.1-beta1/solaris_10_kolab2_install.txt
>
> kind regards
>
> Andrea
>
> Mail: soliva at comcept.ch
> -----Urspr?ngliche Nachricht-----
> Von: ComCept Soliva [mailto:soliva at comcept.ch] Im Auftrag von
> kolab-devel-bounces at kolab.org
> Gesendet: Mittwoch, 7. Januar 2009 14:20
> An: kolab-devel at kolab.org
> Betreff: [Kolab-devel] Solaris 10 Sparc Kolab V2.2.1 Beta 1
> kolab-fbview-1.2.0 Permission denied
>
> Hi all
>
> I proceeded and runned in the next error:
>
> :::: /tmp/install-kolab....8544/kolab-fbview-1.2.0-20081212.src.rpm ::::
> Installing /tmp/install-kolab....8544/kolab-fbview-1.2.0-20081212.src.rpm
> Executing(%prep): env -i /kolab/lib/openpkg/bash --norc --noprofile --posix
> -e /kolab/RPM/TMP/rpm-tmp.8672
> + cd /kolab/RPM/TMP
> + set +x
> +----------------------------------Warning----------------------------------
> --+
> | This OpenPKG package is of class JUNK.
> |
> | This means it is still in DEVELOPMENT state.
> |
> | Hence it is still NOT ready even for general evaluation.
> |
> | Do not use it at all, except in development environments!
> |
> | It is definitely unstable and incompletely packaged.
> |
> +---------------------------------------------------------------------------
> --+
> + cd /kolab/RPM/TMP
> + rm -rf kolab-fbview-1.2.0
> + /kolab/lib/openpkg/shtool mkdir -f -p -m 755 kolab-fbview-1.2.0
> + cd kolab-fbview-1.2.0
> + /kolab/lib/openpkg/gzip -dc
> /kolab/RPM/SRC/kolab-fbview/horde-webmail-1.2.tar.gz
> + /kolab/lib/openpkg/tar -xf -
> + STATUS=0
> + '[' 0 -ne 0 ']'
> + cd horde-webmail-1.2
> + echo 'Patch #0 (horde-webmail-1.2.0_kolab_fbview_openpkg.patch):'
> Patch #0 (horde-webmail-1.2.0_kolab_fbview_openpkg.patch):
> + /kolab/lib/openpkg/patch -p1 -s -b
> + cd ..
> + exit 0
> Executing(%build): env -i /kolab/lib/openpkg/bash --norc --noprofile --posix
> -e /kolab/RPM/TMP/rpm-tmp.30962
> + cd /kolab/RPM/TMP
> + cd kolab-fbview-1.2.0
> + exit 0
> Executing(%install): env -i /kolab/lib/openpkg/bash --norc --noprofile
> --posix -e /kolab/RPM/TMP/rpm-tmp.15032
> + cd /kolab/RPM/TMP
> + cd kolab-fbview-1.2.0
> + /kolab/lib/openpkg/shtool install -d
> /kolab/RPM/TMP/kolab-fbview-1.2.0-root/kolab/var/kolab/www/fbview
> + /kolab/lib/openpkg/shtool install -d
> /kolab/RPM/TMP/kolab-fbview-1.2.0-root/kolab/var/kolab/tmp
> + /kolab/lib/openpkg/shtool install -d
> /kolab/RPM/TMP/kolab-fbview-1.2.0-root/kolab/var/kolab/storage
> + /kolab/lib/openpkg/shtool install -d
> /kolab/RPM/TMP/kolab-fbview-1.2.0-root/kolab/etc/kolab/templates
> + cd horde-webmail-1.2
> + find . -name test.php
> + xargs rm
> + find . -name '*.orig'
> + xargs rm
> + rm -rf dimp imp ingo mimp mnemo nag
> + cd kronolith
> + rm add.php day.php view.php delete.php ics.php search.php week.php
> contacts.php imple.php month.php pref_api.php workweek.php edit.php new.php
> year.php attend.php data.php event.php
> + cd ..
> + cp -r COPYING README admin config docs index.php js kronolith lib locale
> log login.php notconfigured.html pear po rpc rpc.php scripts services
> signup.php storage templates themes tmp turba util
> /kolab/RPM/TMP/kolab-fbview-1.2.0-root/kolab/var/kolab/www/fbview/
> cp: cannot open log/.htaccess.orig: Permission denied
> cp: cannot open storage/.htaccess.orig: Permission denied
> cp: cannot open tmp/.htaccess.orig: Permission denied
> error: Bad exit status from /kolab/RPM/TMP/rpm-tmp.15032 (%install)
>
>
> RPM build errors:
>     Bad exit status from /kolab/RPM/TMP/rpm-tmp.15032 (%install)
> + exit 1
>
>
>
> I had a look to the spec file but I can not find what is going wrong and why
> it failed with Permission denied?
>
> Any hints what can be manipulated that I can proceed?

See https://www.intevation.de/roundup/kolab/issue3318

It has already been fixed in cvs.

Cheers,

Gunnar

>
> Update documentation:
>
> http://www.comcept.ch/kolab2/2.2.1-beta1/solaris_10_kolab2_install.txt
>
> Here the log file for this part of installation:
>
> http://www.comcept.ch/kolab2/2.2.1-beta1/kolab-install-Jan-7-13-35-20.zip
>
> kind regards
>
> Andrea
>
> Mail: soliva at comcept.ch
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
Url : http://kolab.org/pipermail/kolab-devel/attachments/20090107/ed3ff2d4/attachment-0001.bin

From wrobel at pardus.de  Wed Jan  7 21:02:53 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Wed, 07 Jan 2009 21:02:53 +0100
Subject: [Kolab-devel] Solaris 10 Sparc Kolab V2.2.1 Beta 1	kolabd-2.2.1
	error: Installing crontab entry
In-Reply-To: <7C80011DD4E44EDD9AB05076D4C26AF1@comcept.ch>
References: <7C80011DD4E44EDD9AB05076D4C26AF1@comcept.ch>
Message-ID: <20090107210253.180254y7djuxrhk4@webmail.pardus.de>

Quoting ComCept Soliva <soliva at comcept.ch>:

> Hi all
>
> I forced the installation of the kolabd package because my opinion is that
> apache was correct installed.
>
> Within the the installation of the package another error occured:
>
> # /kolab/bin/openpkg rpm --force --nodeps -Uvh
> /kolab/RPM/PKG/kolabd-2.2.1-20081212.sparc64-solaris10-kolab.rpm
> Preparing...                ###########################################
> [100%]
>    1:kolabd                 ###########################################
> [100%]
> Installing crontab entry
> crontab: illegal option -- u
> crontab: proper usage is:
>         crontab [file | -e | -l | -r ] [user]crontab:
> proper usage is:
>         crontab [file | -e | -l | -r ] [user]

I guess this is a bug. My crontab man page does not even list "-u"  
(though it actually works).

@thomas: Do you see a possibility to add some kind of workaround for this?

Cheers,

Gunnar

> For a fresh install please initialize Kolab by running
> '/kolab/sbin/kolab_bootstrap -b' as user root.
> If you upgraded from a previous version simply refresh Kolab by running run
> '/kolab/sbin/kolabconf' as user root.
> In every case execute '/kolab/bin/openpkg rc kolabd restart' as user root.
>
> Updated documentation is available here with all logs of install:
>
> http://www.comcept.ch/kolab2/2.2.1-beta1/
>
> kind regards
>
> Andrea
>
> Mail: soliva at comcept.ch
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
Url : http://kolab.org/pipermail/kolab-devel/attachments/20090107/70f6f9d5/attachment.bin

From jan at horde.org  Thu Jan  8 12:35:13 2009
From: jan at horde.org (Jan Schneider)
Date: Thu, 08 Jan 2009 12:35:13 +0100
Subject: [Kolab-devel] Horde can now store Preferences in IMAP
 (was:	Horde preferences: LDAP or IMAP?)
In-Reply-To: <20090107132229.61942f5wekgq8jgg@webmail.pardus.de>
References: <87zlz1trxh.fsf@home.pardus.de>
	<200710022328.32145.martin.konold@erfrakon.de>
	<71fe4e760710021605l6a2d79c0le78f0d70adb8347d@mail.gmail.com>
	<200710301025.13994.stephane@voyageonline.co.uk>
	<87odeetdzx.fsf@home.pardus.de> <87ejaf84wp.fsf_-_@home.pardus.de>
	<20081221234248.12067680kz9f5dgc@webmail.pardus.de>
	<71fe4e760901020436q73afb633lada4ac0f620881c8@mail.gmail.com>
	<20090107132229.61942f5wekgq8jgg@webmail.pardus.de>
Message-ID: <20090108123513.468311qahgwdc8w0@neo.wg.de>

Zitat von Gunnar Wrobel <wrobel at pardus.de>:

> Quoting Alain Spineux <aspineux at gmail.com>:
>
>> 2008/12/21 Gunnar Wrobel <wrobel at pardus.de>:
>>> Hi!
>>>
>>> A while back (beginning of this year) we had a discussion on how to store
>>> the user preferences of the Kolab webclient (based on Horde).
>>>
>>> Horde preferences are being handled by a single module called "prefs". This
>>> module supports several backends. Among them are
>>>
>>> - SQL
>>> - LDAP
>>> - File based
>>> - IMAP
>>>
>>> Horde usually uses SQL. Kolab has traditionally used the LDAP backend. This
>>> LDAP backend has been replaced with the file based backend for Kolab Server
>>> 2.2.1 beta 1. An alternative would also be the storage in IMAP similar to
>>> the other groupware data of the Kolab server.
>>>
>>> The decision to switch to the file based approach was made since the
>>> developer team did not consider LDAP to be a decent place for such data
>>> anymore. It makes the LDAP entries rather complex and LDAP is usually meant
>>> primarily for read access rater than a standard storage space.
>>>
>>> We decided not to use IMAP at the moment as that would mean we  
>>> would need to
>>> discuss the Kolab format for such entries wich would take a while until we
>>> finalize it.
>>>
>>> So the file based approach has been selected for now.
>>>
>>> This does not hinder anyone to choose any of the other possible backends.
>>> People that like to remain on LDAP can do so without problems while people
>>> preferring IMAP storage can also choose to do so.
>>>
>>> But the question still is: What is the best default?
>>>
>>> It would be great if people could add the pros and cons they see for the
>>> different solutions. I'll try to add an overview once we have some opinions
>>> and I'll include the relevant pieces from the discussion we had at the
>>> beginning of this year.
>>>
>>> I would like to add that I personally see the IMAP driver as the best
>>> choice. For me the Kolab server architecture results in one simple
>>> conclusion: User data belongs into IMAP. And preferences are user data.
>>
>> Pro IMAP too.
>> File based approach require to add something into the backup or the
>> migration procedure.
>> Anyway, when does these data need to be READ or WRITTEN ?
>> At each mail access, or at each folrder access, or just once at login
>> and logout ?
>
> The data needs to be READ on nearly every page access. Preferences  
> are  used at many different places within the Kolab web client. E.g.  
> which  calendars to display, the last time you logged in, your real  
> name etc.

This is not quite true, because preferences are only read once per  
session and application and cached in the user session after that.

> This data needs to be WRITTEN whenever one or several of these   
> preferences changes. This may sometimes be the result of user action  
>  where you don't actually see that you changed something (e.g. the   
> login -> your last login time gets stored in the preferences  
> backend)  but usually only when you actually switch a setting.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/


From soliva at comcept.ch  Thu Jan  8 13:17:30 2009
From: soliva at comcept.ch (ComCept Soliva)
Date: Thu, 8 Jan 2009 13:17:30 +0100
Subject: [Kolab-devel] [issue3341] Solaris 10 Sparc Kolab V2.2.1 Beta 1
	SSL/TLS libraries were missing or unusable
In-Reply-To: <1231357012.99.0.402183287638.issue3341@intevation.de>
References: <1231357012.99.0.402183287638.issue3341@intevation.de>
Message-ID: <AD378BBEEDE14AE494C962BB2D0ADC9F@comcept.ch>

Hi Gunnar

the workaround does not work which means ssl will not be anymore incuded. I
was able to overall finish the compilation and to use bootstrap without
error but after launching openpkg rc all start I recognized that ssl is
overall not included in apache. 


From thomas at intevation.de  Fri Jan  9 11:10:11 2009
From: thomas at intevation.de (Arendsen Hein, Thomas)
Date: Fri, 9 Jan 2009 11:10:11 +0100
Subject: [Kolab-devel] Solaris 10 Sparc Kolab V2.2.1 Beta 1	kolabd-2.2.1
	error: Installing crontab entry
In-Reply-To: <20090107210253.180254y7djuxrhk4@webmail.pardus.de>
References: <7C80011DD4E44EDD9AB05076D4C26AF1@comcept.ch>
	<20090107210253.180254y7djuxrhk4@webmail.pardus.de>
Message-ID: <20090109101011.GB23351.thomas@intevation.de>

* Gunnar Wrobel <wrobel at pardus.de> [20090107 21:03]:
> Quoting ComCept Soliva <soliva at comcept.ch>:
> >Within the the installation of the package another error occured:
> >
> ># /kolab/bin/openpkg rpm --force --nodeps -Uvh
> >/kolab/RPM/PKG/kolabd-2.2.1-20081212.sparc64-solaris10-kolab.rpm
> >Preparing...                ###########################################
> >[100%]
> >   1:kolabd                 ###########################################
> >[100%]
> >Installing crontab entry
> >crontab: illegal option -- u
> >crontab: proper usage is:
> >        crontab [file | -e | -l | -r ] [user]crontab:
> >proper usage is:
> >        crontab [file | -e | -l | -r ] [user]
> 
> I guess this is a bug. My crontab man page does not even list "-u" (though it actually works).
> 
> @thomas: Do you see a possibility to add some kind of workaround for this?

Yes, I think I'll remove the crontab handling in kolabd completely
and add to the upgrading docs that the crontab entry (if it exists)
should be removed.

I did not want to do that automatically because admins might have
added other stuff than kolabquotawarn here.

Thomas

-- 
thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20090109/bbb7cbf8/attachment.bin

From soliva at comcept.ch  Fri Jan  9 15:44:14 2009
From: soliva at comcept.ch (ComCept Soliva)
Date: Fri, 9 Jan 2009 15:44:14 +0100
Subject: [Kolab-devel] Solaris 10 Sparc Kolab V2.2.1 Beta 1 Summary Overview
Message-ID: <A76E0F15CB1A4BCAAA1A80B41482EFCF@comcept.ch>

Hi all

here a summary/view overall:

# sh -x install-kolab.sh 2>&1 | tee kolab-install-Dec-29-07_24_22.log

-------------------- output install-kolab.sh --------------------
OpenPKG CURRENT Binary Bootstrap Package, version 20071227
Built for prefix /kolab on target platform sparc64-solaris10
++ hooking OpenPKG instance into system environment
ln: rc0.d/K00kolab: File exists
ln: rc1.d/K00kolab: File exists
+ exit 2 
-------------------- output install-kolab.sh --------------------

COMMENT Was the installation stopped because the both files in rc0 and rc1
was existing?
*******





# sh
/tmp/install-kolab....8544/openpkg-20071227-20071227.sparc64-solaris10-kolab
.sh

# sh -x install-kolab.sh 2>&1 | tee kolab-install-Dec-30-07-22-50.log

-------------------- output install-kolab.sh --------------------
checking for SSL_set_cert_store... no
configure: error: ... Error, SSL/TLS libraries were missing or unusable
error: Bad exit status from /kolab/RPM/TMP/rpm-tmp.9292 (%build)


RPM build errors:
    Bad exit status from /kolab/RPM/TMP/rpm-tmp.9292 (%build)
+ exit 1 
-------------------- output install-kolab.sh --------------------

ISSUE NOTED https://www.intevation.de/roundup/kolab/msg18180
***********

COMMENT The workaround to manipulate apache.spec and add --without-zlib did
not
******* work which means as soon as this option is in apache.spec ssl part
will
        not be anymore included within apache.





# sh -x install-kolab.sh 2>&1 | tee kolab-install-Dec-31-09-36-14.log

-------------------- output install-kolab.sh --------------------
checking for db4 major version... configure: error: Header contains
different version
error: Bad exit status from /kolab/RPM/TMP/rpm-tmp.12696 (%build)


RPM build errors:
    Bad exit status from /kolab/RPM/TMP/rpm-tmp.12696 (%build)
+ exit 1 
-------------------- output install-kolab.sh --------------------

ISSUE NOTED https://www.intevation.de/roundup/kolab/issue1809
***********

COMMENT Issue exists since 2.1.0 RC and workaround works on my site meaning

******* change option within db.spec to --enable-shared=yes





# sh -x install-kolab.sh 2>&1 | tee kolab-install-Dec-31-10-14-54.log

-------------------- output install-kolab.sh --------------------
find: cannot follow symbolic link /usr/lib/llib-ldevid: No such file or
directory
find: cannot follow symbolic link /usr/lib/llib-ldevinfo.ln: No such file or
directory
find: cannot follow symbolic link /usr/lib/libmeta.so: No such file or
directory
find: cannot follow symbolic link /usr/lib/llib-ltermcap.ln: No such file or
directory
find: cannot follow symbolic link /usr/lib/llib-laio: No such file or
directory
find: cannot follow symbolic link /usr/lib/llib-lelf.ln: No such file or
directory
find: cannot follow symbolic link /usr/lib/llib-lpam.ln: No such file or
directory
find: cannot follow symbolic link /usr/lib/llib-lcurses.ln: No such file or
directory
find: cannot follow symbolic link /usr/lib/llib-lnvpair: No such file or
directory
find: cannot follow symbolic link /usr/lib/llib-lmd5: No such file or
directory
find: cannot follow symbolic link /usr/lib/llib-lnsl: No such file or
directory
find: cannot follow symbolic link /usr/lib/llib-lcmd: No such file or
directory
find: cannot follow symbolic link /usr/lib/llib-lpam: No such file or
directory
find: cannot follow symbolic link /usr/lib/llib-lresolv: No such file or
directory
find: cannot follow symbolic link /usr/lib/llib-lxnet: No such file or
directory
find: cannot follow symbolic link /usr/lib/llib-ldl: No such file or
directory
install: -pm was not found anywhere!
error: Bad exit status from /kolab/RPM/TMP/rpm-tmp.6248 (%install)


RPM build errors:
    Bad exit status from /kolab/RPM/TMP/rpm-tmp.6248 (%install)
+ exit 1 
-------------------- output install-kolab.sh --------------------

ISSUE NOTED https://www.intevation.de/roundup/kolab/issue3315
***********

COMMENT change within PEAR-Horde-Channel.spec following line to: 
******* 

/kolab/lib/openpkg/shtool install -m 644 %{SOURCE0}
$RPM_BUILD_ROOT%{pear_xmldir}/pear.horde.org.xml


COMMENT Same issue for another package which means change within : 
******* PEAR-PHPUnit-Channel.spec following line to: 

/kolab/lib/openpkg/shtool install -m 644 %{SOURCE0}
$RPM_BUILD_ROOT%{pear_xmldir}/pear.phpunit.de.xml





# sh -x install-kolab.sh 2>&1 | tee kolab-install-Jan-5-18-52-20.log

-------------------- output install-kolab.sh --------------------
Processing files: kolabd-2.2.1-20081212
Wrote: /kolab/RPM/PKG/kolabd-2.2.1-20081212.sparc64-solaris10-kolab.rpm
Executing(%clean): env -i /kolab/lib/openpkg/bash --norc --noprofile --posix
-e /kolab/RPM/TMP/rpm-tmp.31467
+ cd /kolab/RPM/TMP
+ cd kolabd-2.2.1
+ rm -rf /kolab/RPM/TMP/kolabd-2.2.1-root
+ exit 0
Executing(--clean): env -i /kolab/lib/openpkg/bash --norc --noprofile
--posix -e /kolab/RPM/TMP/rpm-tmp.31467
+ cd /kolab/RPM/TMP
+ rm -rf kolabd-2.2.1
+ exit 0
error: Failed dependencies:
	apache::with_mod_ssl = yes is needed by kolabd-2.2.1-20081212
	apache::with_mod_ldap = yes is needed by kolabd-2.2.1-20081212
	apache::with_mod_authn_alias = yes is needed by
kolabd-2.2.1-20081212
+ exit 1 
-------------------- output install-kolab.sh --------------------

COMMENT This error could be related to above section with the apache issue
that as soon as
******* the option without-zlib is used ssl is not anymore included.





# /kolab/bin/openpkg rpm --force --nodeps -Uvh
/kolab/RPM/PKG/kolabd-2.2.1-20081212.sparc64-solaris10-kolab.rpm

-------------------- output install-kolab.sh --------------------
Preparing...                ###########################################
[100%]
   1:kolabd                 ###########################################
[100%]
Installing crontab entry
crontab: illegal option -- u
crontab: proper usage is: 
        crontab [file | -e | -l | -r ] [user]crontab: 
proper usage is: 
        crontab [file | -e | -l | -r ] [user]
For a fresh install please initialize Kolab by running
'/kolab/sbin/kolab_bootstrap -b' as user root.
If you upgraded from a previous version simply refresh Kolab by running run
'/kolab/sbin/kolabconf' as user root.
In every case execute '/kolab/bin/openpkg rc kolabd restart' as user root.

-------------------- output /var/spool/cron/crontabs/root
--------------------  

COMMENT The issue was comment that it seems to be a Bug. 
******* 





# sh -x install-kolab.sh 2>&1 | tee kolab-install-Jan-7-13-35-20.log

-------------------- output install-kolab.sh --------------------
+ rm add.php day.php view.php delete.php ics.php search.php week.php
contacts.php imple.php month.php pref_api.php workweek.php edit.php new.php
year.php attend.php data.php event.php
+ cd ..
+ cp -r COPYING README admin config docs index.php js kronolith lib locale
log login.php notconfigured.html pear po rpc rpc.php scripts services
signup.php storage templates themes tmp turba util
/kolab/RPM/TMP/kolab-fbview-1.2.0-root/kolab/var/kolab/www/fbview/
cp: cannot open log/.htaccess.orig: Permission denied
cp: cannot open storage/.htaccess.orig: Permission denied
cp: cannot open tmp/.htaccess.orig: Permission denied
error: Bad exit status from /kolab/RPM/TMP/rpm-tmp.15032 (%install)


RPM build errors:
    Bad exit status from /kolab/RPM/TMP/rpm-tmp.15032 (%install)
+ exit 1 

-------------------- output install-kolab.sh --------------------


ISSUE NOTED https://www.intevation.de/roundup/kolab/issue3318
***********

COMMENT Change within kolab-fbview.spec file to following entry: 
******* 
		find . -type f | grep '\.orig$' | xargs rm

COMMENT Same issue for another package which means change within : 
******* kolab-webclient.spec following entry: 

		find . -type f | grep '\.orig$' | xargs rm





# sh -x install-kolab.sh 2>&1 | tee kolab-install-Jan-7-16-26-29.log





Befor launching Bootstrap do following:


COMMENT More information on this
http://www.postfix.org/SMTPD_POLICY_README.html
*******

# vi /kolab/etc/kolab/templates/main.cf.template

--------------- /kolab/etc/kolab/templates/main.cf.template ---------------

default_database_type = hash

#debug_peer_list = 127.0.0.0/8

## Kolab Policy Server
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated,
        reject_unauth_destination, reject_unlisted_recipient,
        check_policy_service inet:127.0.0.1:10028
smtpd_sender_restrictions = permit_mynetworks,
        check_policy_service inet:127.0.0.1:10028
127.0.0.1:10028_time_limit = 3600
127.0.0.1:10028_max_idle = 20

--------------- /kolab/etc/kolab/templates/main.cf.template ---------------

# vi /kolab/etc/kolab/templates/master.cf.template

--------------- /kolab/etc/kolab/templates/master.cf.template
---------------

#kolabpolicy    unix  -       n       n       -       -       spawn
user=kolab-n argv=/kolab/bin/kolab_smtpdpolicy

127.0.0.1:10028  inet    n       n       n       -       0       spawn
user=kolab-n argv=/kolab/etc/kolab/kolab_smtpdpolicy

--------------- /kolab/etc/kolab/templates/master.cf.template
---------------





COMMENT Solaris works with inet for syslog
*******

# vi /opt/kolab/bin/kolab_smtpdpolicy

--------------- /opt/kolab/bin/kolab_smtpdpolicy ---------------

#
# Syslogging options for verbose mode and for fatal errors.
# NOTE: comment out the $syslog_socktype line if syslogging does not
# work on your system.
#
my %conf;
my %attr;
my $ldap;
my $verbose;
my $syslog_socktype = 'inet'; # inet, unix, stream, console

--------------- /opt/kolab/bin/kolab_smtpdpolicy ---------------

# vi /opt/kolab/bin/kolabquotawarn

--------------- /opt/kolab/bin/kolabquotawarn ---------------

#
# Syslogging options for verbose mode and for fatal errors.
# NOTE: comment out the $syslog_socktype line if syslogging does not
# work on your system.
#
my $syslog_socktype = 'inet'; # inet, unix, stream, console

--------------- /opt/kolab/bin/kolabquotawarn ---------------





COMMENT Config error within Kolab-Server-2.2.1-beta-1
*******

# vi /kolab/etc/kolab/templates/resmgr.conf.template

--------------- /kolab/etc/kolab/templates/resmgr.conf.template
---------------

/* Local delivery backend (default LMTP) */
$conf['kolab']['filter']['delivery_backend'] = 'lmtp';

--------------- /kolab/etc/kolab/templates/resmgr.conf.template
---------------






# /kolab/sbin/kolab_bootstrap -b

COMMENT As loong as the correct package are installed bootstrap -p runs
fines without errors
*******


That's it.....source on my site is still available to troubleshoot the
apache stuff.

All logs etc. available at http://www.comcept.ch/kolab2/2.2.1-beta1/


kind regards

Andrea Soliva

Mail: soliva at comcept.ch 


From kolab-issues at intevation.de  Fri Jan  9 18:28:19 2009
From: kolab-issues at intevation.de (Mathieu Parent)
Date: Fri, 09 Jan 2009 17:28:19 +0000
Subject: [Kolab-devel] [issue3343] Shared folders should use the mail
	attribute if available
Message-ID: <1231522099.01.0.170171039187.issue3343@intevation.de>


New submission from Mathieu Parent <mathieuparent at users.sourceforge.net>:

If the sf LDAP object has a "mail" attribute, it should be used as mailbox name.

A patch is attached (against 2.2.0 but apply against HEAD).

Currently the shared folder name is constructed from the dn.

----------
files: use_mail_attr.diff
messages: 18216
nosy: mathieu.parent
status: unread
title: Shared folders should use the mail attribute if available
topic: patch, server
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3343>
___________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: use_mail_attr.diff
Url: http://kolab.org/pipermail/kolab-devel/attachments/20090109/2d7901bf/use_mail_attr.txt

From wrobel at pardus.de  Sun Jan 11 22:36:30 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Sun, 11 Jan 2009 22:36:30 +0100
Subject: [Kolab-devel] Horde webmail patch management for the Kolab web
	client
Message-ID: <20090111223630.41077haocs3qqfds@webmail.pardus.de>

Hi!

Mathieu Parent asked in  
https://www.intevation.de/roundup/kolab/issue2738 if there exists a  
possibility to follow the Horde Patch management for the Kolab web  
client.

I want to take this to the discussion list because this might be of  
interest to others, too.

The single patches required for the Kolab web client (based on Horde)  
can be found here:

http://hg.pardus.de/cgi-bin/hg.cgi/horde/HORDE/

What you find there might actually not be too trivial to understand in  
case you never worked with a patch queue - or mercurial queues - before.

The list of patches that is being used to generate the patches  
available in Kolab CVS  
(http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/patches/horde-webmail/1.2.0/) can be found in  
http://hg.pardus.de/cgi-bin/hg.cgi/horde/HORDE/file/tip/series

They are marked with #+release and #+release-kolab.

The reason why Mathieu asked about this is because he considers the  
big monolithic patch in Kolab CVS problematic to track.

He is certainly right about that and I'm not 100% certain I chose the  
right solution here.

We originally had less than ten Kolab specific patches which I kept in  
Kolab CVS. But I still had a lot of ongoing development within the  
Kolab libraries after the horde-webmail-1.2.0 release. So I'm  
currently at more than 50 patches (most of them are already integrated  
in Horde CVS though). And at some point I considered the monolithic  
patch a better alternative for most users. You download  
horde-webmail-1.2.0 to your machine, unpack it, download a single big  
patch, apply it and you are done.

I still believe this is the best way to go. But on the other hand the  
way from the mercurial repository linked above to the final patch may  
be somewhat obscure. Do people have better ideas? Or should I just  
document it better in the wiki? Hoping for comments ;)

Cheers,

Gunnar

-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
Url : http://kolab.org/pipermail/kolab-devel/attachments/20090111/25197fe3/attachment.bin

From bernhard at intevation.de  Mon Jan 12 15:18:35 2009
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 12 Jan 2009 15:18:35 +0100
Subject: [Kolab-devel] Horde webmail patch management for the Kolab web
	client
In-Reply-To: <20090111223630.41077haocs3qqfds@webmail.pardus.de>
References: <20090111223630.41077haocs3qqfds@webmail.pardus.de>
Message-ID: <200901121518.35962.bernhard@intevation.de>

On Sonntag, 11. Januar 2009, Gunnar Wrobel wrote:
> The reason why Mathieu asked about this is because he considers the ?
> big monolithic patch in Kolab CVS problematic to track.
>
> He is certainly right about that and I'm not 100% certain I chose the ?
> right solution here.
>
> We originally had less than ten Kolab specific patches which I kept in ?
> Kolab CVS. But I still had a lot of ongoing development within the ?
> Kolab libraries after the horde-webmail-1.2.0 release. So I'm ?
> currently at more than 50 patches (most of them are already integrated ?
> in Horde CVS though). And at some point I considered the monolithic ?
> patch a better alternative for most users. You download ?
> horde-webmail-1.2.0 to your machine, unpack it, download a single big ?
> patch, apply it and you are done.
>
> I still believe this is the best way to go. But on the other hand the ?
> way from the mercurial repository linked above to the final patch may ?
> be somewhat obscure. Do people have better ideas? Or should I just ?
> document it better in the wiki? Hoping for comments ;)

This is a good question.
Mathieu and other _could_ track changes to the big patch, which hopefully are 
not that large to stabilitze is.
Single patch files seems to be be nicer if there is the change that more and 
more patches are getting upstream. I have a slight tendency towards
smaller patch files, each patch addressing something which is a unit somehow.

However the question can only be answered if we write up all pros and cons
and consider them. (A wiki page is probably best for this.)

Bernhard


-- 
Managing Director - Owner: www.intevation.net      (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20090112/a8b27993/attachment.bin

From kolab-issues at intevation.de  Tue Jan 13 11:51:35 2009
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Tue, 13 Jan 2009 10:51:35 +0000
Subject: [Kolab-devel] [issue3344] Mail: Kontact needs a restart or sync to
	notice that a second identity has been entered
Message-ID: <1231843894.99.0.824503988217.issue3344@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise35 kdepim   20081221.899822
             kde-i18n 20081219.898920

Test: One identity is configured.
1. Open the mail configuration dialog.
2. Switch to "identities".
3. Enter a new second identity.
4. Press "OK".
5. Open a the creation dialog for a new mail.
=> The identity choose combobox is missing in the composer.

----------
assignedto: till
messages: 18233
nosy: bernhard, bh, ludwig, osterfeld, pradeepto, till
priority: minor bug
status: unread
title: Mail: Kontact needs a restart or sync to notice that a second identity has been entered
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3344>
___________________________________________________


From kolab-issues at intevation.de  Tue Jan 13 12:50:07 2009
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Tue, 13 Jan 2009 11:50:07 +0000
Subject: [Kolab-devel] [issue3345] Calendar: The default status of an
	organizer should be accepted.
Message-ID: <1231847407.14.0.191169854155.issue3345@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise35 kdepim   20081221.899822
             kde-i18n 20081219.898920

Test:
1. Switch to calendar.
2. Create a new test event.
3. Edit this test event.
=> At the top of the edit dialog the user is asked to accept or decline the event.

Normally an organizer of an event accepts his own event. That should be the
default. But it should be possible for the organizer to change the status to
decline, if he doesn't want to be part of the event.

----------
assignedto: till
messages: 18234
nosy: bernhard, bh, ludwig, osterfeld, pradeepto, till
priority: urgent
status: unread
title: Calendar: The default status of an organizer should be accepted.
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3345>
___________________________________________________


From akopciuch at bddf.ca  Tue Jan 13 16:26:54 2009
From: akopciuch at bddf.ca (Andrew J. Kopciuch)
Date: Tue, 13 Jan 2009 08:26:54 -0700
Subject: [Kolab-devel] Groups for shared folders
In-Reply-To: <200901130844.08259.bernhard@intevation.de>
References: <mailman.245.1231773956.2113.kolab-users@kolab.org>
	<496B688A.2080802@dragonrising.com>
	<200901130844.08259.bernhard@intevation.de>
Message-ID: <200901130826.59026.akopciuch@bddf.ca>

On January 13, 2009, Bernhard Reiter wrote:
> On Montag, 12. Januar 2009, Alex wrote:
> > Folder name: staff-shared at mydomain.com
> > Folder type: mails
> > Permission for UID/email/GID: "group:staff-group at mydomain.com"
> > Permission='all'
>
> Try "group:staff-group".

I just tested, and I can not make a group address work either.

The syntax to enter a distribution list is the full email address.

list at domain.com

The PHP interface determines it as a distribution list, and prepends "group:" 
to the acl entry.

I dug a little bit into the PHP code to see what was going on, and I have 
verified that the admin interface seems to be doing it's job, as the acl is 
added in LDAP properly :

<ldif>
# testshare at domain.ca, domain.ca
dn: cn=testshare at domain.ca,dc=domain,dc=ca
kolabHomeServer: mail.domain.ca
objectClass: kolabSharedFolder
cn: testshare at domain.ca
acl: group:test at domain.ca all
</ldif>


However ...

With only the group: acl entry, the shared folder does not appear in my 
account's subscription list.  Not until I specify the individual user in an 
acl.  Only then do I have the option to subscribe to the folder.

I can verify that the group does exist in /kolab/etc/imapd/imapd.group as one 
would expect.

I did modify things to test the LDAP entry without the group: on the acl, and 
that definitely does not work.  I also just for my own humor : 

- added the user UID acl, 
- subscribed, 
- then added some messages, 
- removed the UID, and left the GID acl.
- tried something else on the folder.

All to no avail.   All I did was verify that Kontact acted properly, and told 
me I have no rights to a shared folder, and things had been moved into 
lost+found for safe keeping.  (Which is exactly what I would expect to 
happen.


It appears that cyrus imapd is not utilizing the group: acl properly.   That's 
out of my knowledge at the current moment on how to debug without a great 
deal of time.   I hope my comments, and information can help someone else 
debug this further.


BTW ...

Kolab version 2.2 (OpenPKG)
Kontact Version 1.2.9


HTH,


Andy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20090113/9244f115/attachment.bin

From kolab-issues at intevation.de  Wed Jan 14 09:26:03 2009
From: kolab-issues at intevation.de (=?utf-8?q?Albrecht_Dre=C3=9F?=)
Date: Wed, 14 Jan 2009 08:26:03 +0000
Subject: [Kolab-devel] [issue3346] Cannot delete folders in shared accounts
	using Toltec connector
Message-ID: <1231921562.93.0.866370217243.issue3346@intevation.de>


New submission from Albrecht Dre? <albrecht.dress at lios-tech.com>:

If a common account (like "support" or "info") is used by several users, it is
impossible to erase folders using Outlook and the Toltec connector.  This
happens with different Outlook versions (from 2002 to 2007) and Toltec 2.3.1.

How to reproduce this bug:

(1) Create a Kolab account like "info" or "support".

(2) Map this account through the Toltec Connector for more than one user.

(3) User 1 now creates a mail folder like "New Folder" and syncs to Kolab/Cyrus.

(4) User 2 opens Outlook.  The "New Folder" is now visible.

(5) Now one user erases this folder and syncs to Cyrus.  If any *other* Outlook
user also syncs, instead of also erasing the folder locally, it gets sync'ed
back to Cyrus from the local Outlook/Toltec message store (pst).

(6) If the user who originally erased the folder connects (or syncs) again, the
folder is synced back from Cyrus.

In short, this makes it impossible to erase folders on the server in such a
setup.  The Toltec support came up with the "solution"

<quote>
You need to delete the folder on both PSTs in the same synchronization slice. If
Toltec detects a folder in a PST and cannot find it on the server it will upload
the folder.
</quote>

This is of course not a solution if e.g. for a "support" account ~8 people are
involved who are located in different places, have different working hours, etc.
- I cannot organise a "folder erase party" regularly just to make erasing
folders work.  As a side note, it is of course possible to erase /messages/ on
the server which are /not/ sync'ed back by Toltec.  This behaviour is really
unlogical.

Possible fixes for Toltec might be:
- Treat folders like messages, i.e. delete them locally if they were erased on
the server;
- If Toltec detects a folder locally, but not on the server, display a dialogue
asking if the folder should be erased locally or copied back to server.

----------
messages: 18241
nosy: albrecht.dress
priority: bug
status: unread
title: Cannot delete folders in shared accounts using Toltec connector
topic: concept, toltec
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3346>
___________________________________________________


From itsef-admin at brightsight.com  Wed Jan 14 14:38:48 2009
From: itsef-admin at brightsight.com (ITSEF Admin)
Date: Wed, 14 Jan 2009 14:38:48 +0100
Subject: [Kolab-devel] Massive loss of events in enterprise35 client
Message-ID: <200901141438.48428.itsef-admin@brightsight.com>

Hi all,

I'm Cc'ing this to both lists, as  I regard this as a major problem - "devel" 
to get some input from the developers and "users" just to see whether anybody 
else has seen things like this anywhere.

For the first time in enterprise35 (that I know of in our company), the old, 
ugly problem rears its head again: Massive loss of events from one's agenda. 
This time it has happened to myself - yesterday evening, several hundred 
events were deleted from my agenda, without my intervention. Here's the 
forensics:
- kontact --version
  Qt: 3.3.8b
  KDE: 3.5.10
  Kontact: 1.2.9 (enterprise35 20081202.891698)
  (Kubuntu 8.04)
- $HOME is on NFS
- Kontact was running, but I do not recall actually working with Kontact at 
the time, though I did start a new mail shortly afterwards
- According to the imap server logs (Kolab 2.1), the events in question were 
deleted - I can see hunderds of lines like this:
imapd.log.0:Jan 13 18:13:19 HOST <debug> imaps[3259]: mailbox_expunge: 
removing mail brightsight.com!user.USER.Calendar:18646
- Earlier that day, I had a crash - most likely due to connection problems 
with our mailserver (we had firewall problems), but I had already restarted 
Kontact
- I did not find anything suspicious in .xsession-errors, except for a bunch 
of SSL errors I could not place:
5594:error:140940E5:lib(20):func(148):reason(229):s3_pkt.c:990:
5594:error:14094415:lib(20):func(148):reason(1045):s3_pkt.c:1053:SSL alert 
number 45
- I am using four different calendars - my own, another "single user" 
calendar, one group calendar and a shared folder calendar. Only my own 
calendar was affected.
- Oddly enough, not all of the events in my calendar were deleted - 9 messages 
were left behind on the server, one of which was a real event from last 
October. The other eight were empty.


Another user also lost all events yesterday, however, in his case it happened 
with the Kontact instance that was still running during the connection 
problems with the mail server. His events were deleted (again, according to 
imapd.log) about three hours after the connection had been restored. He had 
not restarted Kontact since. His .xession-errors has already been 
overwritten, so no help there.


We have experienced problems like this rather frequently with proko2. 
enterprise35 is doing much better (in fact, I was lulled into the hope that 
the problem might have vanished) - but apparently, there's still something 
not quite right...

Any input - as always - welcome!

Regards,

Thomas


From kolab-issues at intevation.de  Wed Jan 14 22:25:10 2009
From: kolab-issues at intevation.de (Mike Gabriel)
Date: Wed, 14 Jan 2009 21:25:10 +0000
Subject: [Kolab-devel] [issue3347] recipient delimiter ignored by
	kolabmailboxfilter
Message-ID: <1231968309.92.0.44459626151.issue3347@intevation.de>


New submission from Mike Gabriel <m.gabriel at das-netzwerkteam.de>:

I am using the most recent kolab debian-packages from:
http://pkg-kolab.alioth.debian.org/packages/snapshots/kolab

one of my system's users works a lot with postfix's recipient delimiters.
unfortunately, the postfix delimiter is ignored on my system. kolabmailboxfilter
results with a ,,User unkown'', when such a recipient is processed.

works fine:
Jan 14 22:07:54 mailserver postfix/pipe[1442]: A0E9D93FD2:
to=<someone+test at domain.tld>, relay=kolabfilter, delay=0.23,
delays=0.05/0/0/0.17, dsn=2.0.0, status=sent (delivered via kolabfilter service)

but:
Jan 14 22:07:55 mailserver postfix/pipe[1450]: E533793FD2:
to=<someone+test at domain.tld>, relay=kolabmailboxfilter, delay=0.17,
delays=0.01/0/0/0.16, dsn=5.1.1, status=bounced (user unknown)

where as this one succeeds:
Jan 14 22:17:17 mailserver postfix/pipe[2479]: 5D2BC2E9F5:
to=<someone at domain.tld>, relay=kolabmailboxfilter, delay=0, delays=0/0/0/0,
dsn=2.0.0, status=sent (delivered via kolabmailboxfilter service)

----------
messages: 18244
nosy: mike
priority: bug
status: unread
title: recipient delimiter ignored by kolabmailboxfilter
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3347>
___________________________________________________


From kolab-issues at intevation.de  Thu Jan 15 13:32:23 2009
From: kolab-issues at intevation.de (Fricker Wigfield)
Date: Thu, 15 Jan 2009 12:32:23 +0000
Subject: [Kolab-devel] [issue3348] I love mmy babe
Message-ID: <4355777969.20090115122956@beds-bedding.nl>


New submission from Fricker Wigfield <virginium at beds-bedding.nl>:

How  to Give Her Absolute Pleasure?
	http://cid-d39b5e60616f1c09.spaces.live.com/blog/cns!D39B5E60616F1C09!106.entry/

Carefully kept everything from her. But, my dear had broke
through grief. Pendaran dyved, who had he has just tin enough
to want more, and she says thought seemed withered up. You
were absolutely no relationship between the two. As regards
the.

----------
messages: 18256
nosy: virginium
status: unread
title: I love mmy babe
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3348>
___________________________________________________


From kolab-issues at intevation.de  Thu Jan 15 14:44:57 2009
From: kolab-issues at intevation.de (Yemi Salau)
Date: Thu, 15 Jan 2009 13:44:57 +0000
Subject: [Kolab-devel] [issue3349] EMAIL Command died with status 255:
	"/kolab/bin/php"
Message-ID: <1232027097.6.0.509031094066.issue3349@intevation.de>


New submission from Yemi Salau <salauolayemi at yahoo.co.uk>:

Hello Everyone, it's my first posting, and this has come because I've searched
everywhere on the internet for the solution to my problem but couldn't get one.

Basically, I just installed the 2.2.1-beta version of Kolab on CentOS-5.2, so
far, everything I want off the box works, normal webclient(Horde) and stuff. I
followed the README.txt file with due diligence. However, I can't get a mail
client from outside the mynetworks to send email using the server.

For example, say I have an account: test at test.com in our company in the US, and
I move my Laptop to Germany or even work from home. The webclient works ok, but
things like Outlook and Thunderbird don't. Yes, I've configured the mail client
to authenticate to the server, also, I've ticked the SSL option and stuff.
Whenever I send an email via Outlook, all I get is error message. And when I do
this from Thunderbird I get "Command died with status 255: "/kolab/bin/php""
error message.

I'm not so vast with programing, but could it be some problem with pear module?

Thanks for your help.

LOGS
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

/kolab/var/apache/log/php/php-errors.log
PHP Fatal error:  Call to undefined method
Horde_Kolab_Server_ldap::addrsForUid() in
/kolab/lib/php/Horde/Kolab/Filter/Content.php on line 384

/kolab/var/postfix/log/postfix.log
Jan 15 14:34:49 test.test.com <warning> postfix/smtpd[4804]: warning: database
/kolab/etc/postfix/canonical.db is older than source file
/kolab/etc/postfix/canonical
Jan 15 14:34:49 test.test.com <info> postfix/smtpd[4804]: connect from
unknown[1.1.1.1]
Jan 15 14:34:49 test.test.com <info> postfix/smtpd[4804]: setting up TLS
connection from unknown[1.1.1.1]
Jan 15 14:34:49 test.test.com <info> postfix/smtpd[4804]: TLS connection
established from unknown[1.1.1.1]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256
bits)
Jan 15 14:34:49 test.test.com <warning> postfix/trivial-rewrite[4806]: warning:
database /kolab/etc/postfix/relocated.db is older than source file
/kolab/etc/postfix/relocated
Jan 15 14:34:49 test.test.com <warning> postfix/cleanup[4807]: warning: database
/kolab/etc/postfix/canonical.db is older than source file
/kolab/etc/postfix/canonical
Jan 15 14:34:49 test.test.com <info> postfix/smtpd[4804]: C6E855F389C:
client=unknown[1.1.1.1], sasl_method=PLAIN, sasl_username=testuser at test.com
Jan 15 14:34:49 test.test.com <info> postfix/cleanup[4807]: C6E855F389C:
message-id=<496F3C11.4090202 at test.com>
Jan 15 14:34:49 test.test.com <info> postfix/qmgr[4255]: C6E855F389C:
from=<testuser at test.com>, size=22434, nrcpt=1 (queue active)
Jan 15 14:34:49 test.test.com <info> postfix/smtpd[4804]: disconnect from
unknown[1.1.1.1]
Jan 15 14:34:50 test.test.com <info> postfix/pipe[4808]: C6E855F389C:
to=<testuser at otherdomain.com>, relay=kolabfilter, delay=0.31,
delays=0.04/0.01/0/0.26, dsn=5.3.0, status=bounced (Command died with status
255: "/kolab/bin/php")
Jan 15 14:34:50 test.test.com <info> postfix/cleanup[4807]: 1AF315F389F:
message-id=<20090115143450.1AF315F389F at test.test.com>
Jan 15 14:34:50 test.test.com <info> postfix/qmgr[4255]: 1AF315F389F: from=<>,
size=24240, nrcpt=1 (queue active)
Jan 15 14:34:50 test.test.com <info> postfix/bounce[4810]: C6E855F389C: sender
non-delivery notification: 1AF315F389F
Jan 15 14:34:50 test.test.com <info> postfix/qmgr[4255]: C6E855F389C: removed
Jan 15 14:34:50 test.test.com <info> postfix/pipe[4812]: 1AF315F389F:
to=<testuser at test.com>, relay=kolabmailboxfilter, delay=0.34,
delays=0.01/0.01/0/0.33, dsn=2.0.0, status=sent (delivered via
kolabmailboxfilter service)
Jan 15 14:34:50 test.test.com <info> postfix/qmgr[4255]: 1AF315F389F: removed

----------
messages: 18257
nosy: salauolayemi
status: unread
title: EMAIL Command died with status 255: "/kolab/bin/php"
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3349>
___________________________________________________


From kolab-issues at intevation.de  Thu Jan 15 20:24:48 2009
From: kolab-issues at intevation.de (Cadmen Skattebo)
Date: Thu, 15 Jan 2009 19:24:48 +0000
Subject: [Kolab-devel] [issue3350] I love my  babe
Message-ID: <8043188417.20090115192019@fga-cpas.com>


New submission from Cadmen Skattebo <championed at fga-cpas.com>:

How to Give Her Absolute  Pleasure?
 http://cid-2f7005b7a997e63e.spaces.live.com/blog/cns!2F7005B7A997E63E!106.entry/

Men who framed the american testimony and terms the desire
of injuring others, adorned with faith, forgiveness, and
selfrestraint, and purity, with suggested. So the young
man brought his saddle last in that shameful though rather
forcible declaration.

----------
messages: 18261
nosy: championed
status: unread
title: I love my  babe
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3350>
___________________________________________________


From bernhard at intevation.de  Fri Jan 16 09:42:04 2009
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 16 Jan 2009 09:42:04 +0100
Subject: [Kolab-devel] Groups for shared folders
In-Reply-To: <200901130826.59026.akopciuch@bddf.ca>
References: <mailman.245.1231773956.2113.kolab-users@kolab.org>
	<200901130844.08259.bernhard@intevation.de>
	<200901130826.59026.akopciuch@bddf.ca>
Message-ID: <200901160942.05106.bernhard@intevation.de>

On Dienstag, 13. Januar 2009, Andrew J. Kopciuch wrote:
> I just tested, and I can not make a group address work either.

Hmm, it should work, needs testing here.
You are running the OpenPKG version of Cyrus, right?

-- 
Managing Director - Owner: www.intevation.net      (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20090116/e45a6f18/attachment.bin

From bernhard at intevation.de  Fri Jan 16 09:46:10 2009
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 16 Jan 2009 09:46:10 +0100
Subject: [Kolab-devel] Groups for shared folders
In-Reply-To: <20090114165650.127449q2jw3upagw@webmail.pardus.de>
References: <mailman.245.1231773956.2113.kolab-users@kolab.org>
	<496B688A.2080802@dragonrising.com>
	<20090114165650.127449q2jw3upagw@webmail.pardus.de>
Message-ID: <200901160946.10356.bernhard@intevation.de>

On Mittwoch, 14. Januar 2009, Gunnar Wrobel wrote:
> Indeed, you don't need the "group:" prefix. The mail address is enough ?
> to identify that this is a group.
>
> I tested that the whole procedure works fine on the recent ?
> Kolab-Server-2.2.1-beta-1 release but I believe it should also work on ?
> 2.2.0 as I don't think we changed anything in that area.

Hmm, I think this is "group:" in the clients,
shouldn't this be consistant all over the place?
(I missunderstood the original report to say that he wanted to share folders 
via the clients, not the "anonymous folders" under the "/shared" prefix via 
the web admin.)


-- 
Managing Director - Owner: www.intevation.net      (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20090116/ed71209d/attachment.bin

From akopciuch at bddf.ca  Fri Jan 16 12:05:49 2009
From: akopciuch at bddf.ca (Andrew J. Kopciuch)
Date: Fri, 16 Jan 2009 04:05:49 -0700
Subject: [Kolab-devel] Groups for shared folders
In-Reply-To: <200901160942.05106.bernhard@intevation.de>
References: <mailman.245.1231773956.2113.kolab-users@kolab.org>
	<200901130826.59026.akopciuch@bddf.ca>
	<200901160942.05106.bernhard@intevation.de>
Message-ID: <200901160405.53731.akopciuch@bddf.ca>

On January 16, 2009, Bernhard Reiter wrote:
> On Dienstag, 13. Januar 2009, Andrew J. Kopciuch wrote:
> > I just tested, and I can not make a group address work either.
>
> Hmm, it should work, needs testing here.
> You are running the OpenPKG version of Cyrus, right?


Correct.

Kolab 2.2.0, fully patched (although I do not recall any security updates to 
imapd).

OpenPKG, compiled from SRC.RPM. (not the binaries provided).



Andy



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20090116/353672a5/attachment.bin

From kolab-issues at intevation.de  Fri Jan 16 12:54:11 2009
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Fri, 16 Jan 2009 11:54:11 +0000
Subject: [Kolab-devel] [issue3351] Reason for decryption problem "no secret
	key" not visible
Message-ID: <1232106851.5.0.693049573157.issue3351@intevation.de>


New submission from Bernhard Reiter <bernhard at intevation.de>:

When I get an email for which I do not have the secret key,
I can see the raw body in with blue borders 
with the message that decryption is not possible.

Doing this on the command line, gpg2 tells me the reason:
gpg: decryption failed: No secret key
This reason should be communicated to the user.
Getting an email without having the key is a common situation.

Tested with OpenPGP.
Kontact on Etch Version: 4:3.5.10.enterprise.0.20081202.891698-kk2


Ludwig, can you test this with S/MIME as well?
Ludwig, from my memory this worked with proko2, can you confirm?
(This is why, as regression I tag is "prokde35".)

----------
assignedto: allen
messages: 18265
nosy: allen, bernhard, ludwig, marc
priority: bug
status: unread
title: Reason for decryption problem "no secret key" not visible
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3351>
___________________________________________________


From kolab-issues at intevation.de  Fri Jan 16 12:58:17 2009
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Fri, 16 Jan 2009 11:58:17 +0000
Subject: [Kolab-devel] [issue3352] Way to show the OpenPGP keys a message is
	encrypted to
Message-ID: <1232107097.05.0.615584836076.issue3352@intevation.de>


New submission from Bernhard Reiter <bernhard at intevation.de>:

As of Kontact on Etch Version: 4:3.5.10.enterprise.0.20081202.891698-kk2
and also enterprise4, it is not possible to see from an Email 
to which keys it is encryted-to.

Lately I found out that I need that often for two reasons:
a) I did not have the secret key to decrypt and I wondered which key it is.
b) There were other recipients and I was wanted to reply-to all and fetch
   the same keys that the first sender used.

My workaround is to save the email and use gpg2 -v --decrypt
on the command line.

This wish might be interesting for S/MIME as well and might even influence the 
selection of keys or automatic key finding in the future.

----------
assignedto: allen
messages: 18266
nosy: allen, bernhard, bh, ludwig, marc
priority: wish
status: unread
title: Way to show the OpenPGP keys a message is encrypted to
topic: enterprise35, enterprise4, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3352>
___________________________________________________


From thomas at intevation.de  Fri Jan 16 16:57:38 2009
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Fri, 16 Jan 2009 16:57:38 +0100
Subject: [Kolab-devel] Kolab Server Hotfix 20090116
Message-ID: <20090116155738.GF10329.thomas@intevation.de>

This hotfix package fixes three issues in the groupware functions of
Kolab Server 2.2.0.  Users of 2.2 release candidates or beta versions
should upgrade to 2.2.0 first, users of Kolab Server 2.2.1-beta1 must
_not_ apply this hotfix since the issues are already fixed here.


kolab/issue3074 (Freebusy trigger fails for other users' calenders)
kolab/issue3236 (automatic acceptance, Attendee status email not
                 recognized by Outlook 2003)
kolab/issue3284 (Webclient or resmgr might send invitations that Outlook
                 2003 does not understand (unquoted CN with Umlauts))

Visit http://issues.kolab.org/ and enter the corresponding issue numbers
to view more details.


The hotfix is available from the Kolab download mirrors in the directory
server/release/kolab-server-2.2.0/hotfix-20090116
(see http://kolab.org/mirrors.html for a list of download mirrors)

While the mirrors are catching up, you can also get the hotfix files via rsync:
# rsync -tvP rsync://rsync.kolab.org/kolab/server/release/kolab-server-2.2.0/hotfix-20090116/iCalendar.php .
# rsync -tvP rsync://rsync.kolab.org/kolab/server/release/kolab-server-2.2.0/hotfix-20090116/kolab-issue3074.patch .

SHA1 sums:
5294eab5f874cfa4d76415a5e20a5122d5e86b3a  iCalendar.php
4eb16659513c07c38e4a7a7e5d1ed75d262ef3f6  kolab-issue3074.patch


The hotfix can be installed on your Kolab Server with the following
commands executed as user 'root' or 'kolab':

# cp iCalendar.php /kolab/lib/php/Horde/
# patch -s -p0 -d /kolab/lib/php < kolab-issue3074.patch

-- 
thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20090116/e767a289/attachment.bin

From kolab-issues at intevation.de  Sun Jan 18 21:07:29 2009
From: kolab-issues at intevation.de (marcello)
Date: Sun, 18 Jan 2009 20:07:29 +0000
Subject: [Kolab-devel] [issue3353] fetchmail fail in beta
Message-ID: <1232309249.31.0.0377645113876.issue3353@intevation.de>


New submission from marcello <info at network-ip.de>:

fetchmail fail in beta 2.2.1

----------
messages: 18273
nosy: wupp
status: unread
title: fetchmail fail in beta
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3353>
___________________________________________________


From albrecht.dress at lios-tech.com  Fri Jan 16 19:28:47 2009
From: albrecht.dress at lios-tech.com (Albrecht =?iso-8859-1?b?RHJl3w==?=)
Date: Fri, 16 Jan 2009 19:28:47 +0100
Subject: [Kolab-devel] Kolab Server Hotfix 20090116
In-Reply-To: <20090116155738.GF10329.thomas@intevation.de> (from
	thomas@intevation.de on Fri Jan 16 16:57:38 2009)
Message-ID: <1232130527.6048.0@antares>

Hi Thomas:

Am 16.01.09 16:57 schrieb(en) Thomas Arendsen Hein:
> kolab/issue3074 (Freebusy trigger fails for other users' calenders)

Does it also fix issue #3208 which if I understand the comments in  
#3074 correctly might be somehow related?

Cheers, Albrecht.


P.S.: BTW, the GnuPG structure of the message you sent is broken.  It  
has the content-type

Content-Type: multipart/signed; micalg=SHA1;  
protocol="application/pgp-signature"; boundary="H8ygTp4AXg6deix2"

which violates RFC 3156, sect. 5 which states that

<quote>
    The "micalg" parameter for the "application/pgp-signature" protocol
    MUST contain exactly one hash-symbol of the format "pgp-<hash-
    identifier>", where <hash-identifier> identifies the Message
    Integrity Check (MIC) algorithm used to generate the signature.
    Hash-symbols are constructed from the text names registered in [1]  
or
    according to the mechanism defined in that document by converting  
the
    text name to lower case and prefixing it with the four characters
    "pgp-".

    Currently defined values are "pgp-md5", "pgp-sha1", "pgp-ripemd160",
    "pgp-md2", "pgp-tiger192", and "pgp-haval-5-160".
</quote>


From thomas at intevation.de  Mon Jan 19 15:43:56 2009
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Mon, 19 Jan 2009 15:43:56 +0100
Subject: [Kolab-devel] Kolab Server Hotfix 20090116
In-Reply-To: <1232130527.6048.0@antares>
References: <20090116155738.GF10329.thomas@intevation.de>
	<1232130527.6048.0@antares>
Message-ID: <20090119144356.GC10616.thomas@intevation.de>

* Albrecht Dre? <albrecht.dress at lios-tech.com> [20090119 15:28]:
> Am 16.01.09 16:57 schrieb(en) Thomas Arendsen Hein:
> > kolab/issue3074 (Freebusy trigger fails for other users' calenders)
> 
> Does it also fix issue #3208 which if I understand the comments in  
> #3074 correctly might be somehow related?

They are related, but I do not think kolab/issue3208 is fixed with this.

> P.S.: BTW, the GnuPG structure of the message you sent is broken.  It  
> has the content-type
> 
> Content-Type: multipart/signed; micalg=SHA1;  
> protocol="application/pgp-signature"; boundary="H8ygTp4AXg6deix2"
> 
> which violates RFC 3156, sect. 5 which states that
> 
> <quote>
>     The "micalg" parameter for the "application/pgp-signature" protocol
...
>     Currently defined values are "pgp-md5", "pgp-sha1", "pgp-ripemd160",
>     "pgp-md2", "pgp-tiger192", and "pgp-haval-5-160".
> </quote>

You're right. This is fixed in a newer version of mutt, but I'm
still using an old mutt-ng with some patches I have to port to mutt
before switching back.

I did not notice problems with other clients yet, did you?

Regards,
Thomas Arendsen Hein

P.S.: Please answer to kolab-devel for issue3208 and in private mail
regarding the mutt-ng bug.

-- 
thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


From kolab-issues at intevation.de  Mon Jan 19 16:22:24 2009
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Mon, 19 Jan 2009 15:22:24 +0000
Subject: [Kolab-devel] [issue3354] Crash after deletion of an online account
Message-ID: <1232378543.97.0.724167187583.issue3354@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

Kontact-Installer-20081128.exe
kdelibs-branch  889739
kdepimlibs-branch  889781
kdepim-branch  890007
i10n-kde4  890045
kowi-crypto-files_gpg4win1.9.11-beta

Test:
1. Use the kolabwizard as a new user to create a online imap account.
2. Start kontact.
3. Sync some times.
4. Open the configure kontact dialog->KMail->Accounts->Receiving.
5. In this dialog remove the online IMAP account.
6. Press "Ok"
=> An error message appears:
Cannot open file "XXX /.kde/share/kmail/imap/23456".
Too many open files.
7. Pressing "OK"
=> Another Too many open files error message appears.
8. Closing Kontact
=> Crash.

----------
assignedto: allen
messages: 18283
nosy: allen, bh, ludwig
priority: urgent
status: unread
title: Crash after deletion of an online account
topic: enterprise4, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3354>
___________________________________________________


From kolab-issues at intevation.de  Mon Jan 19 23:03:36 2009
From: kolab-issues at intevation.de (Mathieu Parent)
Date: Mon, 19 Jan 2009 22:03:36 +0000
Subject: [Kolab-devel] [issue3355] POD manpages for perl-kolab
Message-ID: <1232402615.91.0.174606396619.issue3355@intevation.de>


New submission from Mathieu Parent <mathieuparent at users.sourceforge.net>:

The attached patch add POD documentation to perl-kolab binaries.

Those POD items permit the easy creation of manpages by using pod2man. bin/*
manpages are currently installed by ExtUtils::MakeMaker.

I will attach another patch to also install manpages for sbin/*

----------
assignedto: mathieu.parent
files: 70-manpages.diff
messages: 18290
nosy: bernhard, mathieu.parent, thomas, wrobel
status: unread
title: POD manpages for perl-kolab
topic: server
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3355>
___________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 70-manpages.diff
Url: http://kolab.org/pipermail/kolab-devel/attachments/20090119/b0c23c3a/70-manpages-0001.txt

From kolab-issues at intevation.de  Tue Jan 20 15:35:34 2009
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Tue, 20 Jan 2009 14:35:34 +0000
Subject: [Kolab-devel] [issue3356] Kleopatra doesn't open,
	if Tools->Certificate Manager is choosen a second time.
Message-ID: <1232462134.68.0.743068547478.issue3356@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

Kontact-Installer_20090115.exe
and gpg4win-1.9.13-beta.exe
Versions:
kdelibs-branch 913389
kdebase-runtime 913393
kdepimlibs-branch 912009
kdepim 913396
l10n-kde4 913445
kowi-crypto-files_gpg4win1.9.13-beta

Test:
1. Open the cert manager with "Tools->Cert Manager".
=> Kleopatra opens.
..[work a bit.]
2. Close the cert manager window.
3. Try to open again the cert manager with "Tools->Certificate Manager..."
=> Nothing happens.
Expected: The cert manager should open again, so that I can work with it.

----------
assignedto: allen
messages: 18295
nosy: allen, bh, ludwig, vkrause
priority: bug
status: unread
title: Kleopatra doesn't open, if Tools->Certificate Manager is choosen a second time.
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3356>
___________________________________________________


From kolab-issues at intevation.de  Wed Jan 21 12:40:49 2009
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Wed, 21 Jan 2009 11:40:49 +0000
Subject: [Kolab-devel] [issue3357] The carriage returns of a windows
	textfile are changed if the file is sent as attachment.
Message-ID: <1232538049.48.0.989659337185.issue3357@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise4 windows Kontact-Installer_20090115.exe

Sending a textfile attachment from one Windows Kontact to another changes the
carriage returns.

Test:
1. Create a textfile with some lines
2. Send this textfile as attachment to another test account.
3. Open the textfile attachment with the editor.
=> The carriage returns have changed.







Versions:
kdelibs-branch 913389
kdebase-runtime 913393
kdepimlibs-branch 912009
kdepim 913396
l10n-kde4 913445
kowi-crypto-files_gpg4win1.9.13-beta

----------
assignedto: allen
messages: 18303
nosy: allen, bh, ludwig
priority: bug
status: unread
title: The carriage returns of a windows textfile are changed if the file is sent as attachment.
topic: kde client, kowi, windows
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3357>
___________________________________________________


From kolab-issues at intevation.de  Wed Jan 21 12:46:25 2009
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Wed, 21 Jan 2009 11:46:25 +0000
Subject: [Kolab-devel] [issue3358] Copy mails with d'n'd in the same folder
	doubles the mails.
Message-ID: <1232538385.47.0.307132525141.issue3358@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

Kontact-Installer-20090115.exe

Test:
1. Switch to the mail plugin.
2. Select some mails from a test folder test1 and d'n'd them to test1.
3. Select "Copy to"
=> The test mails in test1 are doubled.

Excepted: D'N'D mails to the same folder should do nothing.

Versions:
kdelibs-branch 913389
kdebase-runtime 913393
kdepimlibs-branch 912009
kdepim 913396
l10n-kde4 913445
kowi-crypto-files_gpg4win1.9.13-beta

----------
assignedto: allen
messages: 18304
nosy: allen, bh, ludwig
priority: minor bug
status: unread
title: Copy mails with d'n'd in the same folder doubles the mails.
topic: enterprise4, kde client, kowi, windows
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3358>
___________________________________________________


From kolab-issues at intevation.de  Wed Jan 21 12:52:26 2009
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Wed, 21 Jan 2009 11:52:26 +0000
Subject: [Kolab-devel] [issue3359] No LDAP search appears if the user just
	enters one letter into the to field of a composer.
Message-ID: <1232538745.96.0.57596255997.issue3359@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

Kontact-Installer_20090115.exe

Test:
1. Switch to the mail plugin.
2. Start to create a new mail.
3. Enter one letter into the "to:" field.
4. Wait some time.
=> No LDAP search for the letter appears in selection list.

Excepted: A LDAP search for the letter and the kolab server should be displayed.

Versions:
kdelibs-branch 913389
kdebase-runtime 913393
kdepimlibs-branch 912009
kdepim 913396
l10n-kde4 913445
kowi-crypto-files_gpg4win1.9.13-beta

----------
assignedto: allen
messages: 18305
nosy: allen, bh, ludwig
priority: bug
status: unread
title: No LDAP search appears if the user just enters one letter into the to field of a composer.
topic: kde client, kowi, windows
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3359>
___________________________________________________


From kolab-issues at intevation.de  Wed Jan 21 13:58:56 2009
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Wed, 21 Jan 2009 12:58:56 +0000
Subject: [Kolab-devel] [issue3360] Mail: Open message in the Search dialog
	should open the selected mail
Message-ID: <1232542735.99.0.461723571566.issue3360@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise4 windows: Kontact-Installer-20090115.exe

Test:
1. Switch to mail plugin.
2. Open the search dialog and search for a mail.
3. Select that mail in the search list and click on "Open message".
=> Nothing seems to happen. (The mail is selected in the mail viewer of kontact,
but this window is in the background under the search dialog.)

Excepted: The mail is opened in a own window.

----------
assignedto: allen
messages: 18306
nosy: allen, bh, ludwig
priority: bug
status: unread
title: Mail: Open message in the Search dialog should open the selected mail
topic: kde client, kowi, windows
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3360>
___________________________________________________


From kolab-issues at intevation.de  Wed Jan 21 15:28:47 2009
From: kolab-issues at intevation.de (Loren)
Date: Wed, 21 Jan 2009 14:28:47 +0000
Subject: [Kolab-devel] [issue3361] Supergeile T.eenmodels zeigen alles
Message-ID: <0F60D5AB.FF41435A@j-cnet.jp>


New submission from Loren <nttilaouk at j-cnet.jp>:

Hi mein g-eiler Sch-atz, ich bin SweetSandy. Ich liebe es zu reisen und
immer neue Leute kennenzulernen, vor allem natuerlich maennlichen
Geschlechts! Dabei stehe ich ganz besonders auf humorvolle Maenner die aber
wild genug sind um sich im Bett ohne Tabus mit mir auszutoben! Bei der
schoensten Sache der Welt bin ich fuer vieles offen und gebe mich mit
Vorliebe D0minanten Maennern hin die im Bett den Ton angeben und die
Fuehrungsrolle uebernehmen! Ein langes, ausgedehntes Vorspiel in der 69-er
Stellung bringt mein Blut in Wallung und wenn mich dann erstmal die Lust
ergriffen hat, dann steht auch dem zuegellosen Einsatz von scharfen Toys
Iive im ch-at nichts mehr im Wege!

In meinem Chat geht die Post ab
http://www.Adora.privatesbueckstueck.net

----------
messages: 18308
nosy: nttilaouk
status: unread
title: Supergeile T.eenmodels zeigen alles
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3361>
___________________________________________________


From kolab-issues at intevation.de  Wed Jan 21 16:02:23 2009
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Wed, 21 Jan 2009 15:02:23 +0000
Subject: [Kolab-devel] [issue3362] calendar: strange <html> </html>in
	comment of an update mail
Message-ID: <1232550143.59.0.405138906236.issue3362@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise4 windows: Kontact-Installer_20090115.exe

Strange <html> </html> strings are displayed in an update mail of an event.

Test:
1. A invites B.
2. B syncs.
3. B forwards the event to C.
4. B accpets the test event.
5. C syncs and accepts the event.
6. A syncs and enters the update mails into calendar.
=> He is asked, if he wants to C for the test event.
7. A rejects C.
8. C syncs and looks at the update mail.
=> the update mail displays <html> and </html> in its comment.
(see screenshot)

----------
assignedto: allen
files: update-mail-20090121.png
messages: 18310
nosy: allen, bh, ludwig
priority: minor bug
status: unread
title: calendar: strange <html> </html>in comment of an update mail
topic: kde client, kowi, windows
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3362>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: update-mail-20090121.png
Type: image/png
Size: 17440 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20090121/0165b217/update-mail-20090121-0001.png

From thomas at intevation.de  Wed Jan 21 17:30:52 2009
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Wed, 21 Jan 2009 17:30:52 +0100
Subject: [Kolab-devel] Horde webmail patch management for the Kolab web
	client
In-Reply-To: <20090111223630.41077haocs3qqfds@webmail.pardus.de>
References: <20090111223630.41077haocs3qqfds@webmail.pardus.de>
Message-ID: <20090121163052.GA4838.thomas@intevation.de>

* Gunnar Wrobel <wrobel at pardus.de> [20090111 22:36]:
> The single patches required for the Kolab web client (based on Horde) can be found here:
> 
> http://hg.pardus.de/cgi-bin/hg.cgi/horde/HORDE/

I'm getting "abort: consistency error adding group!" when trying to
clone it, and I remember getting this in the past (December 2008?),
too.

When doing minimal incremental pulls I noticed that the server is
running out of memory, see
http://hg.pardus.de/cgi-bin/hg.cgi/horde/HORDE/rev/51

> The reason why Mathieu asked about this is because he considers the big monolithic patch in Kolab CVS problematic to track.

> I still believe this is the best way to go. But on the other hand the way from the mercurial repository linked above to the final patch may be somewhat obscure. Do people have better ideas? Or should I just 
> document it better in the wiki? Hoping for comments ;)

combinediff from the patchutils package could be used to
automatically create the monolithic patch:
cat series | xargs combinediff

Thomas

-- 
thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20090121/56ad247c/attachment.bin

From thomas at intevation.de  Wed Jan 21 18:17:16 2009
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Wed, 21 Jan 2009 18:17:16 +0100
Subject: [Kolab-devel] gunnar: server/patches/php/php-5.2.8
	KOLAB_php-5.2.8_Annotations.patch, NONE,
	1.1 KOLAB_php-5.2.8_myrights.patch, NONE, 1.1
In-Reply-To: <20081222053859.6B9B1600938@lists.intevation.de>
References: <20081222053859.6B9B1600938@lists.intevation.de>
Message-ID: <20090121171716.GF2390.thomas@intevation.de>

Hi Gunnar!

* cvs at kolab.org <cvs at kolab.org> [20081222 06:39]:
> Update of /kolabrepository/server/patches/php/php-5.2.8
> 
> Added Files:
> 	KOLAB_php-5.2.8_Annotations.patch 
> 	KOLAB_php-5.2.8_myrights.patch 
> Log Message:
> Kolab patches for 5.2.8. No changes though.

Currently the patches for 5.2.6 are used when building the package,
and there are some changes:

interdiff patches/php/php-5.2.8/KOLAB_php-5.2.8_KOLAB_php-5.2.8_Annotations.patch  php/KOLAB_php-5.2.8_myrights.patch
interdiff patches/php/php-5.2.8/KOLAB_php-5.2.8_myrights.patch php/KOLAB_php-5.2.6_myrights.patch

Should the new patches be used?

Regards,
Thomas Arendsen Hein

-- 
thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


From kolab-issues at intevation.de  Wed Jan 21 19:16:35 2009
From: kolab-issues at intevation.de (Mathieu Parent)
Date: Wed, 21 Jan 2009 18:16:35 +0000
Subject: [Kolab-devel] [issue3363] install manpages for bin/* and sbin/* in
	perl-kolab
Message-ID: <1232561795.1.0.583127562152.issue3363@intevation.de>


New submission from Mathieu Parent <mathieuparent at users.sourceforge.net>:

following kolab/issue3355, this patch installs the created manpages.

----------
assignedto: thomas
files: 71-install-sbin-manpages.diff
messages: 18316
nosy: bernhard, mathieu.parent, thomas, wrobel
priority: feature
status: unread
title: install manpages for bin/* and sbin/* in perl-kolab
topic: docs, server
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3363>
___________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 71-install-sbin-manpages.diff
Url: http://kolab.org/pipermail/kolab-devel/attachments/20090121/2e819527/71-install-sbin-manpages.txt

From kolab-issues at intevation.de  Wed Jan 21 21:08:12 2009
From: kolab-issues at intevation.de (Mathieu Parent)
Date: Wed, 21 Jan 2009 20:08:12 +0000
Subject: [Kolab-devel] [issue3364] manpages for kolabfilter and
	kolabmailboxfilter
Message-ID: <1232568492.75.0.146187803145.issue3364@intevation.de>


New submission from Mathieu Parent <mathieuparent at users.sourceforge.net>:

Hi,

As required by Debian policy, I have created manpages for kolabfilter and
kolabmailboxfilter. To share with other distributions, I should probably be
commited in horde CVS.

The manpage can be created with :
pod2man Kolab_Filter-0.1.3/man1/kolabfilter.pod > ./kolabfilter.1

And viewed with:
man ./kolabfilter.1

A symlink should be created for kolabmailboxfilter:
ln -s kolabfilter.1 ./kolabmailboxfilter.1

----------
assignedto: wrobel
files: 70-manpages.diff
messages: 18318
nosy: bernhard, mathieu.parent, thomas, wrobel
priority: feature
status: unread
title: manpages for kolabfilter and kolabmailboxfilter
topic: docs, filter
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3364>
___________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 70-manpages.diff
Url: http://kolab.org/pipermail/kolab-devel/attachments/20090121/7ff1cbce/70-manpages.txt

From wrobel at pardus.de  Thu Jan 22 05:32:58 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Thu, 22 Jan 2009 05:32:58 +0100
Subject: [Kolab-devel] gunnar:
	server/patches/php/php-5.2.8	KOLAB_php-5.2.8_Annotations.patch,
	NONE, 1.1	KOLAB_php-5.2.8_myrights.patch, NONE, 1.1
In-Reply-To: <20090121171716.GF2390.thomas@intevation.de>
References: <20081222053859.6B9B1600938@lists.intevation.de>
	<20090121171716.GF2390.thomas@intevation.de>
Message-ID: <20090122053258.940212go40icbcao@webmail.pardus.de>

Hi Thomas,

Quoting Thomas Arendsen Hein <thomas at intevation.de>:

> Hi Gunnar!
>
> * cvs at kolab.org <cvs at kolab.org> [20081222 06:39]:
>> Update of /kolabrepository/server/patches/php/php-5.2.8
>>
>> Added Files:
>> 	KOLAB_php-5.2.8_Annotations.patch
>> 	KOLAB_php-5.2.8_myrights.patch
>> Log Message:
>> Kolab patches for 5.2.8. No changes though.
>
> Currently the patches for 5.2.6 are used when building the package,
> and there are some changes:
>
> interdiff  
> patches/php/php-5.2.8/KOLAB_php-5.2.8_KOLAB_php-5.2.8_Annotations.patch   
> php/KOLAB_php-5.2.8_myrights.patch
> interdiff patches/php/php-5.2.8/KOLAB_php-5.2.8_myrights.patch  
> php/KOLAB_php-5.2.6_myrights.patch
>
> Should the new patches be used?

Hrm, we duplicated the patches in CVS and I apparently did not merge  
the fix from Thomas on the 5.2.6 patches back into the php directory.  
We should use the same approach as the patching in kolab-webclient  
does. Will fix that.

And yes, the newer patches should be used then.

Cheers,

Gunnar

>
> Regards,
> Thomas Arendsen Hein
>
> --
> thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key:  
> 0x5816791A
> Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck,  
> HR B 18998
> Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
Url : http://kolab.org/pipermail/kolab-devel/attachments/20090122/7141cd78/attachment.bin

From kolab-issues at intevation.de  Thu Jan 22 06:59:55 2009
From: kolab-issues at intevation.de (Gunnar Wrobel)
Date: Thu, 22 Jan 2009 05:59:55 +0000
Subject: [Kolab-devel] [issue3365] Selecting groups in fbview
Message-ID: <1232603994.92.0.217732155186.issue3365@intevation.de>


New submission from Gunnar Wrobel <p at rdus.de>:

Check giving group access in the fbview calender management section. This does
not seem to work in Kolab server 2.2.1-beta-1.

----------
assignedto: wrobel
messages: 18319
nosy: bernhard, thomas, wilde, wrobel
priority: bug
status: unread
title: Selecting groups in fbview
topic: fbview, release
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3365>
___________________________________________________


From wrobel at pardus.de  Thu Jan 22 08:19:54 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Thu, 22 Jan 2009 08:19:54 +0100
Subject: [Kolab-devel] Horde webmail patch management for the Kolab
	web	client
In-Reply-To: <200901121518.35962.bernhard@intevation.de>
References: <20090111223630.41077haocs3qqfds@webmail.pardus.de>
	<200901121518.35962.bernhard@intevation.de>
Message-ID: <20090122081954.10976aa2c5c7dtkw@webmail.pardus.de>

Quoting Bernhard Reiter <bernhard at intevation.de>:

> On Sonntag, 11. Januar 2009, Gunnar Wrobel wrote:
>> The reason why Mathieu asked about this is because he considers the  
>>  big monolithic patch in Kolab CVS problematic to track.
>>
>> He is certainly right about that and I'm not 100% certain I chose  
>> the  right solution here.
>>
>> We originally had less than ten Kolab specific patches which I kept  
>> in  Kolab CVS. But I still had a lot of ongoing development within  
>> the  Kolab libraries after the horde-webmail-1.2.0 release. So I'm   
>> currently at more than 50 patches (most of them are already  
>> integrated  in Horde CVS though). And at some point I considered  
>> the monolithic  patch a better alternative for most users. You  
>> download  horde-webmail-1.2.0 to your machine, unpack it, download  
>> a single big  patch, apply it and you are done.
>>
>> I still believe this is the best way to go. But on the other hand  
>> the  way from the mercurial repository linked above to the final  
>> patch may  be somewhat obscure. Do people have better ideas? Or  
>> should I just  document it better in the wiki? Hoping for comments ;)
>
> This is a good question.
> Mathieu and other _could_ track changes to the big patch, which hopefully are
> not that large to stabilitze is.

The patch is mainly that large because a lot of relevant development  
in the Kolab modules happened only after the horde release we are  
currently using in the server.

> Single patch files seems to be be nicer if there is the change that more and
> more patches are getting upstream.

Most of these are actually already upstream. I'll have to see if we  
can switch over to a newer release version soon (meaning "before 2.2.1  
release"). I don't know if that will be possible though.

> I have a slight tendency towards
> smaller patch files, each patch addressing something which is a unit somehow.

I think I will add my patch queue to Kolab CVS soon anyhow. We use  
Horde 3 for the Kolab server and will continue to do so during the  
next two or three years. But I'm now starting preparations on  
switching to Horde 4. So Horde 3 is moving to maintenance rather than  
being in active development. So the patches are not that variable  
anymore.

>
> However the question can only be answered if we write up all pros and cons
> and consider them. (A wiki page is probably best for this.)

I hope I'll be able to work on the consolidation of the patch queue  
soon and maybe things are clearer afterwards. Maybe a wiki page won't  
be necessary then. On the other hand there will be development on  
Horde 4 and that in turn might warrant another page :) Lets see.

Cheers,

Gunnar

>
> Bernhard
>
>
> --
> Managing Director - Owner: www.intevation.net      (Free Software Company)
> Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
> Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
> Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
Url : http://kolab.org/pipermail/kolab-devel/attachments/20090122/8de123b9/attachment-0001.bin

From wrobel at pardus.de  Thu Jan 22 08:24:26 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Thu, 22 Jan 2009 08:24:26 +0100
Subject: [Kolab-devel] Horde webmail patch management for the Kolab
	web	client
In-Reply-To: <20090121163052.GA4838.thomas@intevation.de>
References: <20090111223630.41077haocs3qqfds@webmail.pardus.de>
	<20090121163052.GA4838.thomas@intevation.de>
Message-ID: <20090122082426.14606x428ip20nwg@webmail.pardus.de>

Quoting Thomas Arendsen Hein <thomas at intevation.de>:

> * Gunnar Wrobel <wrobel at pardus.de> [20090111 22:36]:
>> The single patches required for the Kolab web client (based on  
>> Horde) can be found here:
>>
>> http://hg.pardus.de/cgi-bin/hg.cgi/horde/HORDE/
>
> I'm getting "abort: consistency error adding group!" when trying to
> clone it, and I remember getting this in the past (December 2008?),
> too.

Hm, I admit I never tried cloning from that url.

>
> When doing minimal incremental pulls I noticed that the server is
> running out of memory, see
> http://hg.pardus.de/cgi-bin/hg.cgi/horde/HORDE/rev/51

Hrm.

>
>> The reason why Mathieu asked about this is because he considers the  
>> big monolithic patch in Kolab CVS problematic to track.
>
>> I still believe this is the best way to go. But on the other hand  
>> the way from the mercurial repository linked above to the final  
>> patch may be somewhat obscure. Do people have better ideas? Or  
>> should I just
>> document it better in the wiki? Hoping for comments ;)
>
> combinediff from the patchutils package could be used to
> automatically create the monolithic patch:
> cat series | xargs combinediff

As I'm moving to Horde 4 soon (and that includes moving away from  
patch management with mercurial) I guess I won't fix the problems you  
mentioned but rather get the current patch queue into Kolab CVS.

The ongoing development on Horde 4 could then be followed using git.  
But I still have to get this set up.

Cheers,

Gunnar

>
> Thomas
>
> --
> thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key:  
> 0x5816791A
> Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck,  
> HR B 18998
> Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
Url : http://kolab.org/pipermail/kolab-devel/attachments/20090122/ff9b41cc/attachment.bin

From bernhard at intevation.de  Thu Jan 22 09:19:57 2009
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 22 Jan 2009 09:19:57 +0100
Subject: [Kolab-devel]
	=?iso-8859-15?q?Horde_webmail_patch_management_for_?=
	=?iso-8859-15?q?the_Kolab_web=09client?=
In-Reply-To: <20090122081954.10976aa2c5c7dtkw@webmail.pardus.de>
References: <20090111223630.41077haocs3qqfds@webmail.pardus.de>
	<200901121518.35962.bernhard@intevation.de>
	<20090122081954.10976aa2c5c7dtkw@webmail.pardus.de>
Message-ID: <200901220919.58474.bernhard@intevation.de>

On Donnerstag, 22. Januar 2009, Gunnar Wrobel wrote:
> We use ?
> Horde 3 for the Kolab server and will continue to do so during the ?
> next two or three years. But I'm now starting preparations on ?
> switching to Horde 4. So Horde 3 is moving to maintenance rather than ?
> being in active development. So the patches are not that variable ?
> anymore.

This sounds strange somehow.
Maybe we need an enterprise branch for Horde (preferable in their SCM)
like we have with Kontact. The problem is that we only want a stable
Kolab Webclient, but in order to do so, we need to be able to develop
(conservatively) and somehow track the differences.

Maybe I need to read-up on Horde release tactic, is there a document about 
this that you can recommend?


-- 
Managing Director - Owner: www.intevation.net      (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20090122/8cbfe1f6/attachment.bin

From wrobel at pardus.de  Thu Jan 22 09:45:16 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Thu, 22 Jan 2009 09:45:16 +0100
Subject: [Kolab-devel] Horde webmail patch management for the
	Kolab	web	client
In-Reply-To: <200901220919.58474.bernhard@intevation.de>
References: <20090111223630.41077haocs3qqfds@webmail.pardus.de>
	<200901121518.35962.bernhard@intevation.de>
	<20090122081954.10976aa2c5c7dtkw@webmail.pardus.de>
	<200901220919.58474.bernhard@intevation.de>
Message-ID: <20090122094516.65872b15f4h26k9w@webmail.pardus.de>

Quoting Bernhard Reiter <bernhard at intevation.de>:

> On Donnerstag, 22. Januar 2009, Gunnar Wrobel wrote:
>> We use  Horde 3 for the Kolab server and will continue to do so  
>> during the  next two or three years. But I'm now starting  
>> preparations on  switching to Horde 4. So Horde 3 is moving to  
>> maintenance rather than  being in active development. So the  
>> patches are not that variable  anymore.
>
> This sounds strange somehow.

Maybe I did convey the wrong impression here. Horde 3 is not plain  
maintenance (yet) and probably won't be for another year or so. But I  
don't think there will be many fancy new features. Horde 4 development  
has just started and is still broken all over the place. So this will  
not see releases very soon.

> Maybe we need an enterprise branch for Horde (preferable in their SCM)
> like we have with Kontact.

This is what the Kolab web client should be. It will remain based on  
Horde 3 and it might see updates to newer releases once we consider  
the effort worth the gain.

> The problem is that we only want a stable
> Kolab Webclient, but in order to do so, we need to be able to develop
> (conservatively) and somehow track the differences.

That is the plan and I believe that is what we are currently doing.

>
> Maybe I need to read-up on Horde release tactic, is there a document about
> this that you can recommend?

http://wiki.horde.org/ReleaseManagement

Cheers,

Gunnar

>
>
> --
> Managing Director - Owner: www.intevation.net      (Free Software Company)
> Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
> Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
> Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
Url : http://kolab.org/pipermail/kolab-devel/attachments/20090122/aca363b9/attachment.bin

From kolab-issues at intevation.de  Thu Jan 22 15:56:56 2009
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Thu, 22 Jan 2009 14:56:56 +0000
Subject: [Kolab-devel] [issue3366] Audit log not choosable
Message-ID: <1232636216.23.0.172071335314.issue3366@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

Kontact-Installer_20090115.exe and gpg4win 1.9.13-beta

Test:
1. Another user sends a S/MIME signed mail to the test user.
2. The test user syncs.
3. He looks at the mail and click on details.
=> It is not possible to open the audit log, because it is not available.

Versions:
kdelibs-branch 913389
kdebase-runtime 913393
kdepimlibs-branch 912009
kdepim 913396
l10n-kde4 913445
kowi-crypto-files_gpg4win1.9.13-beta

----------
assignedto: allen
messages: 18326
nosy: allen, bh, ludwig
priority: minor bug
status: unread
title: Audit log not choosable
topic: kde client, kowi, windows
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3366>
___________________________________________________


From kolab-issues at intevation.de  Fri Jan 23 11:24:53 2009
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Fri, 23 Jan 2009 10:24:53 +0000
Subject: [Kolab-devel] [issue3367] New event:Changing organizer's status
	doesn't work.
Message-ID: <1232706293.6.0.912809105361.issue3367@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise35 kdepim   20090121.914162
             kde-i18n 20090121.914156

Test:
1. Switch to the calendar plugin.
2. Start to create a new event.
3. Change the status of the organizer in the attendee list to decline.
=> The status combobox doesn't change
Sees screenshot new-event-status-20090123.png

----------
assignedto: allen
files: new-event-status-20090123.png
messages: 18328
nosy: allen, bh, ludwig
priority: minor bug
status: unread
title: New event:Changing organizer's status doesn't work.
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3367>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: new-event-status-20090123.png
Type: image/png
Size: 41242 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20090123/642f0350/new-event-status-20090123-0001.png

From kolab-issues at intevation.de  Fri Jan 23 13:48:02 2009
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Fri, 23 Jan 2009 12:48:02 +0000
Subject: [Kolab-devel] [issue3368] Moving todos creates conflicts.
Message-ID: <1232714882.31.0.281568437136.issue3368@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise35 kdepim   20090121.914162
             kde-i18n 20090121.914156

Test:
1. Clear all todos.
2. Create todos "1", "2", "3", "4"
3. Move todo 3 to 2 with d'n'd. 
4. Move todo 4 to 2
5. Move todo 2 to 1.
=> A conflict appears.
Move moved todos should not result in a conflict.

----------
assignedto: allen
messages: 18334
nosy: allen, bh, ludwig
priority: bug
status: unread
title: Moving todos creates conflicts.
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3368>
___________________________________________________


From kolab-issues at intevation.de  Sun Jan 25 12:04:23 2009
From: kolab-issues at intevation.de (georg)
Date: Sun, 25 Jan 2009 11:04:23 +0000
Subject: [Kolab-devel] [issue3369] Rep watches made easy
Message-ID: <gc9VPT.6288V95georg@intevation.de>


New submission from georg <georg at intevation.de>:

Dear Frederic,

If you've waited to get your IWC watch, this is the right time to go for it.
http://search.yahoo.com/search?y=Search&p=wallmast%2ecom&fr=sfp&ei=UTF-8 (please click on the link after "Go directly to ")

Get two deeply discounted watches and take an extra 15% discount.
http://search.yahoo.com/search?y=Search&p=wallmast%2ecom&fr=sfp&ei=UTF-8 (please click on the link after "Go directly to ")

Our IWC watches have all appropriate markings, wordings and engravings same as orginal.

Sincerely,
Mr Mcnamara

----------
messages: 18338
nosy: georg
status: unread
title: Rep watches made easy
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3369>
___________________________________________________


From kolab-issues at intevation.de  Sun Jan 25 12:18:30 2009
From: kolab-issues at intevation.de (georg)
Date: Sun, 25 Jan 2009 11:18:30 +0000
Subject: [Kolab-devel] [issue3370] Classy, new and inexpensive watches
Message-ID: <lm3FY.0469H35georg@intevation.de>


New submission from georg <georg at intevation.de>:

Dear Darius,

Looking for a Jaeger LeCoultre watch that no one can tell from the original? You're in luck, because we have the best copies
http://search.yahoo.com/search?y=Search&p=walleap%2ecom&fr=sfp&ei=UTF-8 (please click on the link after "Go directly to ")

Take advantage of our winter specials and get yourself Jaeger LeCoultre watch that you've always wanted!
http://search.yahoo.com/search?y=Search&p=walleap%2ecom&fr=sfp&ei=UTF-8 (please click on the link after "Go directly to ")

Our Jaeger LeCoultre watches have perfect weight and feel same as orginal.

Sincerely,
Mr Shaffer

----------
messages: 18339
nosy: georg
status: unread
title: Classy, new and inexpensive watches
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3370>
___________________________________________________


From kolab-issues at intevation.de  Mon Jan 26 11:47:00 2009
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Mon, 26 Jan 2009 10:47:00 +0000
Subject: [Kolab-devel] [issue3372] pxfb-readable-for implementation for xfb
	permissions (Z61)
Message-ID: <1232966820.09.0.299421061143.issue3372@intevation.de>


New submission from Bernhard Reiter <bernhard at intevation.de>:

Kontact Version: 4:3.5.10.enterprise.0.20090121.914162-kk1 on ia32 Etch
(e35) we miss implementation of the pxfb-readable-for implementation
for Kontact e35. (Prokde35-z/61).

It should be possible to see, set and manipulate the pxfb-readable-for
annotation contents
for at least folders with type event (and possibly tasks).
(Client shall check if setting this permission is allowed on the server
and for the current user before trying to set it.)

See the draft for xfb-concept
 https://ftp.intevation.de/users/bernhard/scratch/

md5sum
02911407f03f09575a312a9c834b36d5  
extended-freebusy-concept-0.92+dev20080503-ber1-pub2.pdf

(marked urgent, because this is a missing feature).

----------
assignedto: allen
messages: 18347
nosy: allen, bernhard, ludwig, till
priority: urgent
status: unread
title: pxfb-readable-for implementation for xfb permissions (Z61)
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3372>
___________________________________________________


From kolab-issues at intevation.de  Tue Jan 27 13:37:42 2009
From: kolab-issues at intevation.de (accu.claim_file@sify.com)
Date: Tue, 27 Jan 2009 12:37:42 +0000
Subject: [Kolab-devel] [issue3373] Ref.Nr:5687SPL876
Message-ID: <KE4QW5$918C06CD3877AB7846B93C381702979B@libero.it>


New submission from accu.claim_file at sify.com <accu.promocion at libero.it>:

Ref.Nr:5687SPL876.
Batch Nr:SPYU6868.
*****************
Attn:
This is to notify you that you have won 500,000.00 euro in our online email Promo Draw in which email addresses are picked randomly by computerized balloting, powered by the Internet,Your email address was amongst those chosen for this period.
******************************************************
To claim your prize, please contact:
Dr. Mike Mejia, Claim Officer.Accu Online Promotion.
Tel no: +34-634 174 204 Fax no: +34-911 015 432.
accu.claim_file at sify.com
******************************************************
With the following information's: Full Names, Address, Tel No,
Age & Occupation.
Due to mix up of some numbers and names,we ask that you keep your wining information confidential until your claim has been processed and your money remitted to you. This is part of our security protocols to avoid double claiming and unwarranted abuse of this program by some participants. Congratulations from our Mgt & Staff.
Yours Truly,
Mr.K Raul(Coordinator)
www.acculotto.com
Accu-Online Promotion.

----------
messages: 18356
nosy: accu.promocion
status: unread
title: Ref.Nr:5687SPL876
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3373>
___________________________________________________


From kolab-issues at intevation.de  Tue Jan 27 16:34:25 2009
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Tue, 27 Jan 2009 15:34:25 +0000
Subject: [Kolab-devel] [issue3374] Window behaviour of Kontact is
	undesirable sometimes if a message box comes up.
Message-ID: <1233070465.01.0.214599832133.issue3374@intevation.de>


New submission from Bernhard Reiter <bernhard at intevation.de>:

Window behaviour of Kontact is undesirable sometimes if a message box comes up.
Some windows with emails will be put behind the main window.

Source: kdepim Version: 4:3.5.10.enterprise.0.20090121.914162-kk1

How to reproduce
* Double click on an email to get the email view (A).
* Now use the forwaring button (to get a forward with attachment)
* on the appearing new composer window with the attachment (B),
  double click on the attachment to open it.

- There is an unexpected message, (this is not subject of this issue):
        Unable to edit attachment

        KMail is unable to detect when the choosen editor is closed. To avoid 
data loss, editing the attachment will be aborted.

Windows A and B are not behind the main window.
Expectation: They should stay above the main window even when
 such a message comes up.

----------
assignedto: allen
messages: 18358
nosy: allen, bernhard, ludwig, till
priority: minor bug
status: unread
title: Window behaviour of Kontact is undesirable sometimes if a message box comes up.
topic: enterprise35, kde client, kkc
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3374>
___________________________________________________


From kolab-issues at intevation.de  Tue Jan 27 16:37:08 2009
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Tue, 27 Jan 2009 15:37:08 +0000
Subject: [Kolab-devel] [issue3375] Attachments overview confusing with short
	emails.
Message-ID: <1233070628.51.0.129159486246.issue3375@intevation.de>


New submission from Bernhard Reiter <bernhard at intevation.de>:

Kontact Etch Version: 4:3.5.10.enterprise.0.20090121.914162-kk1

With a longer email with attachments, you can see a summary list
of the attachments in the header (e.g. for fancy or enterprise headers).
If you click on the attachment, the email contents will scroll so you
can see the attachment.

With shorter emails (and a large enough window size),
there is nothing to scroll as the attachment
in the email is already on the screen. Now clicking does not do anythink,
which is confusing.

At first we need an idea how to improve this (this idea is kkc so far).
One possible idea would be to add a visial feedback only if the attachment
is already seen in the email view. Maybe a tooltip saying: See below?
Another idea is to make a click to the open, only if the attachment
is already there. This is a bit magic, but might still be better.
Allen, Till what do you think?

----------
assignedto: allen
messages: 18359
nosy: allen, bernhard, ludwig, till
priority: bug
status: unread
title: Attachments overview confusing with short emails.
topic: enterprise35, kde client, kkc
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3375>
___________________________________________________


From kolab-issues at intevation.de  Tue Jan 27 16:43:14 2009
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Tue, 27 Jan 2009 15:43:14 +0000
Subject: [Kolab-devel] [issue3376] Make gui for option
	ForwardingInlineByDefault
Message-ID: <1233070993.98.0.922730857277.issue3376@intevation.de>


New submission from Bernhard Reiter <bernhard at intevation.de>:

Kontact Etch Version: 4:3.5.10.enterprise.0.20090121.914162-kk1

Experiences at the customer show that some users want the inline/text
and others the forward as attachment defaults. So it should be possible
for users to change this option easily. For this a GUI is needed.
(Do not forget to update the documentation, currently it is documented
in the "options without gui" section in kmail).

----------
assignedto: allen
messages: 18360
nosy: allen, bernhard, ludwig
priority: wish
status: unread
title: Make gui for option ForwardingInlineByDefault
topic: enterprise35, kde client, kkc
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3376>
___________________________________________________


From bernhard at intevation.de  Wed Jan 28 11:45:07 2009
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 28 Jan 2009 11:45:07 +0100
Subject: [Kolab-devel] martin: server/kolabd/kolabd kolab2.schema, 1.28,
	1.29
In-Reply-To: <20081209004603.906C660092A@lists.intevation.de>
References: <20081209004603.906C660092A@lists.intevation.de>
Message-ID: <200901281145.07884.bernhard@intevation.de>

On Dienstag, 9. Dezember 2008, cvs at kolab.org wrote:
> Modified Files:
> ????????kolab2.schema
> Log Message:
> Martin Konold: Added 3 new attributes. Fixed issue#3298 (illegal OID)

Note, interesting changes to the LDAP schema should be logged on
http://wiki.kolab.org/index.php/Directory_Service_Schema
Like new or deprecated OID.
My intention is to keep that Wiki page a record for
all used OIDs for Kolab Server over time.

Thomas, I think we need to add a entry there for the issue3298 changes.


-- 
Managing Director - Owner: www.intevation.net      (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20090128/9120c4bc/attachment.bin

From bernhard at intevation.de  Wed Jan 28 11:47:31 2009
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 28 Jan 2009 11:47:31 +0100
Subject: [Kolab-devel] martin: server/kolabd/kolabd kolab2.schema, 1.31,
	1.32
In-Reply-To: <20090107091856.E4A07600948@lists.intevation.de>
References: <20090107091856.E4A07600948@lists.intevation.de>
Message-ID: <200901281147.31557.bernhard@intevation.de>

Martin,

On Mittwoch, 7. Januar 2009, cvs at kolab.org wrote:
> Log Message:
> Martin Konold: Made postfix message size limit configurable via LDAP while
> remaining backwards compatible. Gunnar will do the final testing

doesn't this new attribute also need to be added as MAY be listed in the 
k=kolab object?

> Index: kolab2.schema

> +attributetype ( 1.3.6.1.4.1.19414.2.1.511
> + ?NAME 'postfix-message_size_limit'
> + ?EQUALITY integerMatch
> + ?SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

Bernhard
ps: New OIDs to http://wiki.kolab.org/index.php/Directory_Service_Schema 
please. :)

-- 
Managing Director - Owner: www.intevation.net      (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20090128/0d8080bd/attachment.bin

From ludwig.reiter at intevation.de  Wed Jan 28 12:47:42 2009
From: ludwig.reiter at intevation.de (Ludwig Reiter)
Date: Wed, 28 Jan 2009 12:47:42 +0100
Subject: [Kolab-devel] Freebusy Oddity
Message-ID: <200901281247.43222.ludwig.reiter@intevation.de>

Hi,

What is the reason, why Kontact checks, if the kolabserver and user id 
matchs before getting the fb list from the user id?

As example: both abc.def.xy and abc.xy map to the same kolab server. The user 
id of a test account is test at def.xy.
The configured "https://abc.def.xy/freebusy" works to get the fb list.
But "https://abc.xy/freebusy" fails, because abc.xy doesn't match the def.xy 
part of the id part of the account.

The output in this case is:
korganizer: Host 'abc.hq' doesn't match email 'test at def.xy'
korganizer: FreeBusyManager::processRetrieveQueue(): url:
korganizer: Invalid FB URL

Thanks,
Ludwig
-- 
Intevation GmbH, Osnabr?ck
Firmensitz: Neuer Graben 17, 49074 Osnabr?ck
Registereintrag: Amtsgericht Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


From kolab-issues at intevation.de  Mon Jan 26 11:37:00 2009
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Mon, 26 Jan 2009 10:37:00 +0000
Subject: [Kolab-devel] [issue3371] Folder properties dialog layoutproblem
	with freebusy block and common seendb options
Message-ID: <1232966220.5.0.679038054157.issue3371@intevation.de>


New submission from Bernhard Reiter <bernhard at intevation.de>:

Kontact Version: 4:3.5.10.enterprise.0.20090121.914162-kk1 on ia32 Etch
(e35) there is a layout problem with the folder properties dialog.
See attached screenshot, the last two options are inconsistently layouted.

Expectation: They should be consistantly layouted.
I believe that in kmail/kmfolderdia.cpp addMultiCellWidget() is used
for mSharedSeenFlagsCheckBox and this is the first use of addMultiCellWidget()
in that file.

Note that I believe that both options should be formatted more to the left
as the checkboxes above, otherwise the checkbox and the text is too far apard.
(As you can see from the German screenshot.)

----------
assignedto: allen
files: kontact-e35-folderproperties-bad-layout-20090126.png
messages: 18345
nosy: allen, bernhard, ludwig, pradeepto, till
priority: minor bug
status: unread
title: Folder properties dialog layoutproblem with freebusy block and common seendb options
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3371>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kontact-e35-folderproperties-bad-layout-20090126.png
Type: image/png
Size: 47660 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20090126/12e72571/kontact-e35-folderproperties-bad-layout-20090126-0001.png

From ml at radoeka.nl  Thu Jan 29 23:28:07 2009
From: ml at radoeka.nl (Richard Bos)
Date: Thu, 29 Jan 2009 23:28:07 +0100
Subject: [Kolab-devel] How to use the tests that are part of the pear
	modules?
Message-ID: <200901292328.08130.ml@radoeka.nl>

Hi,

I'm making some nice progress to get all the required pear modules for kolab 
available for openSUSE:
http://download.opensuse.org/repositories/server:/php:/applications/openSUSE_11.1/repodata/

How can I use the tests that are part of the pear modules to verify that the 
packages are build, and have been installed (include their required packages) 
correctly?

E.g.:
/usr/share/php5/PEAR/test/Kolab_FreeBusy/Horde/Kolab/FreeBusy/AllTests.php
/usr/share/php5/PEAR/test/Kolab_FreeBusy/Horde/Kolab/FreeBusy/FreeBusyTest.php

Should one just execute:
/usr/share/php5/PEAR/test/Kolab_FreeBusy/Horde/Kolab/FreeBusy/AllTests.php
and that's it, or are arguments needed and are there any requirements to the 
environment.  E.g. In case of kolab_freebusy is a webserver needed?
I did not yet investigate this, I hope that someone can point me in the right 
direction quickly, at least that would be appreciated!

-- 
Kind regards,

Richard


From thomas at intevation.de  Fri Jan 30 17:49:39 2009
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Fri, 30 Jan 2009 17:49:39 +0100
Subject: [Kolab-devel] martin: server/kolabd/kolabd kolab2.schema, 1.31,
	1.32
In-Reply-To: <200901281147.31557.bernhard@intevation.de>
References: <20090107091856.E4A07600948@lists.intevation.de>
	<200901281147.31557.bernhard@intevation.de>
Message-ID: <20090130164939.GF23543.thomas@intevation.de>

* Bernhard Reiter <bernhard at intevation.de> [20090128 11:47]:
> On Mittwoch, 7. Januar 2009, cvs at kolab.org wrote:
> > Log Message:
> > Martin Konold: Made postfix message size limit configurable via LDAP while
> > remaining backwards compatible. Gunnar will do the final testing
> 
> doesn't this new attribute also need to be added as MAY be listed in the 
> k=kolab object?

Yes, and I added that two days after Martin's commit.

> > Index: kolab2.schema
> 
> > +attributetype ( 1.3.6.1.4.1.19414.2.1.511
> > + ?NAME 'postfix-message_size_limit'
> > + ?EQUALITY integerMatch
> > + ?SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
> 
> Bernhard
> ps: New OIDs to http://wiki.kolab.org/index.php/Directory_Service_Schema 
> please. :)

And postfix-message-size-limit, too.

But wouldn't it be better to add comments in the schema file to note
what is import and what is deprecated?

Thomas

-- 
thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20090130/6cf82beb/attachment.bin

From tom at thomasbaumann.com  Sat Jan 31 22:08:58 2009
From: tom at thomasbaumann.com (Thomas Baumann)
Date: Sat, 31 Jan 2009 22:08:58 +0100
Subject: [Kolab-devel] kolab 2.2.1beta -- apache+php+mysql+memcached
Message-ID: <20090131220858.4adff91if4swo4kw@ox.thomasbaumann.com>

Hello list,

I tried to get PHP5 working with mysql but I didnt succeed.

I succeeded in rebuild mysql to mysql-5.1.30-20090102.ix86-debian4.0-kolab.rpm
(taken from openpkg).
I succeeded in rebuild libevent-1.4.9-20081222.ix86-debian4.0-kolab.rpm and
memcached-1.3.0-20090130.ix86-debian4.0-kolab.rpm to get all dependencies
to my php.src.rpm

I did a

/kolab/bin/openpkg rpm -ivh php-5.2.8-20081209_kolab.src.rpm

went to

cd /kolab/RPM/SRC/php

and tried to recompile with

  /kolab/bin/openpkg rpm -ba --define 'with_mysql yes' \
        --define 'with_pecl_memcache yes'  php.spec

But the result was a installable rpm-file, but it lacks on
mysql and pecl-memcache support.

What is going wrong - or what do i have to type to get
a RPM-file with all support as in the original but additional with
mysql and memcache support ?

The compile log is visible on

http://inhalt.serviert.de/ -->
http://inhalt.serviert.de/wissen/migration/kolab-2.2-beta-unter-debian-etch ->  
php_recompile

Thanks for your reply in advance.

Thomas.

-- 
Thomas Baumann

B?cher und mehr im Internet - meine neue Site: http://www.1-search.de  
- Viel Spass!

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.