PHP Fatal error: Class 'Sabre\VObject\Property\Text' not found

[hede]

Hi list,

I cannot read mail in roundcube:

[24-Jun-2016 21:16:54 Europe/Berlin] PHP Fatal error: Class
'Sabre\VObject\Property\Text' not found
in /usr/share/roundcubemail/plugins/libcalendaring/libvcalendar.php on
line 1386

all kolab packages compiled from:

http://obs.kolabsys.com:82/Kolab:/Winterfell/Debian_8.0/

like: roundcubemail-plugins-kolab_3.3~dev20160313-0~kolab1.dsc

It seems there's no Sabre\VObject at all. The one included in Debian 8 is to old for roundcubemail-plugin-libcalendaring (2.1.5 vs. 3.3.3). And those php-composer-thingy seems not to do what it has to do. Any hints?

Regards
hede

[Paul Ryszka]

Post by hede
Hi list,
[24-Jun-2016 21:16:54 Europe/Berlin] PHP Fatal error: Class
'Sabre\VObject\Property\Text' not found
in /usr/share/roundcubemail/plugins/libcalendaring/libvcalendar.php on
line 1386
http://obs.kolabsys.com:82/Kolab:/Winterfell/Debian_8.0/
like: roundcubemail-plugins-kolab_3.3~dev20160313-0~kolab1.dsc
It seems there's no Sabre\VObject at all. The one included in Debian 8 is to old for roundcubemail-plugin-libcalendaring (2.1.5 vs. 3.3.3). And those php-composer-thingy seems not to do what it has to do. Any hints?
Regards
hede

Hi,

Can you please tell me what error message you are getting when running
composer?

Best regards
Paul

[hede]

Post by Paul Ryszka
Can you please tell me what error message you are getting when running
composer?

First it said:
"Your configuration does not allow connections to http://plugins.roundcube.net/packages.json. See https://getcomposer.org/doc/06-config.md#secure-http for details."
I enabled http connections (testing machine - no security issues here...) and those messages are gone.

I do not know where composer is intended to run, so I tried it manually at the building host (where I think it's the place to load such things):
###
You are running composer with xdebug enabled. This has a major impact on runtime performance. See https://getcomposer.org/xdebug
./composer.json has been updated
Loading composer repositories with package information
Warning: Accessing plugins.roundcube.net over http which is an insecure protocol.
Updating dependencies (including require-dev)
- Installing roundcube/plugin-installer (0.1.7)
Loading from cache

- Installing sabre/vobject (3.3.5)
Loading from cache

Writing lock file
Generating autoload files
###
... ran from inside the package source tree. I did this yesterday and built the package with sabre/vobject included - didn't help.

Did run it directly on the machine where kolab is installed:
###
Do not run Composer as root/super user! See https://getcomposer.org/root for details
Loading composer repositories with package information
Warning: Accessing plugins.roundcube.net over http which is an insecure protocol.
Updating dependencies (including require-dev)
- Installing roundcube/plugin-installer (0.1.7)
Downloading: 100%

- Installing sabre/vobject (3.3.5)
Downloading: 100%

Writing lock file
Generating autoload files
###
... using root because the installed directory is owned by root: /usr/share/roundcubemail/plugins/libcalendaring

So both times it's downloading sabre/vobject to the vendor directory. Didn't help. Even after manually running composer in /usr/.../libcalendaring and even if all files seem to be in place, there's still the error message:
PHP Fatal error: Class 'Sabre\VObject\Property\Text' not found in /usr/share/roundcubemail/plugins/libcalendaring/libvcalendar.php on line 1386

Where does php tries to find Sabre\VObject?

And where is composer.sh intended to run? I didn't find those files in the offical Kolab 16 rpm packages neither. Is it really intended to get downloaded during runtime?

regards
hede

[hede]

Post by hede
Where does php tries to find Sabre\VObject?
And where is composer.sh intended to run? I didn't find those files in the offical Kolab 16 rpm packages neither. Is it really intended to get downloaded during runtime?

Nevermind. For rpm distributions there's php-sabre-vobject-3.4.5-1.4.el7.kolab_16.noarch.rpm which seems to be the reason why there's no sabre-vobject in the roundcube...libcalendar packages and no composer needed while runtime (!?).

I'll try to build my own php-sabre-vobject.deb with newer 3.4 sabre/vobject now...

[hede]

Post by hede
[24-Jun-2016 21:16:54 Europe/Berlin] PHP Fatal error: Class
'Sabre\VObject\Property\Text' not found
in /usr/share/roundcubemail/plugins/libcalendaring/libvcalendar.php on
line 1386

btw, that's not only the case with my own builds, but also with the binary builds from http://obs.kolabsys.com:82/Kolab:/Winterfell/Debian_8.0/

I freshly installed Debian 8.0 and Kolab via https://docs.kolab.org/installation-guide/winterfell/debian-8.html -> results in the same error while trying to read mail with roundcube:

PHP Fatal error: Class 'Sabre\VObject\Property\Text' not found in /usr/share/roundcubemail/plugins/libcalendaring/libvcalendar.php on line 1386
(/var/log/roundcubemail/errors)

I didn't find a solution so far. I've packaged php-sabre-vobject_3.4.5-1_all.deb and /usr/bin/vobject is working - finds it's libs - but libvcalendar.php is still non-functional.

regards
hede

[hede]

Post by hede
PHP Fatal error: Class 'Sabre\VObject\Property\Text' not found in /usr/share/roundcubemail/plugins/libcalendaring/libvcalendar.php on line 1386

Btw: Autoloading is the problem here. I'm not familar with php autoloading, but if I add the following lines to libvcalendar.php it works:

###
spl_autoload_register(function ($class) {
if (strpos($class, 'Sabre\\')===0) {
$file = '/usr/share/php/'.str_replace('\\', '/', $class).'.php';
@include $file;
}
});
###
(with my php-sabre-vobject_3.4.5-1_all.deb installed)

Obviously with Red Hat this is not needed. What's the difference there?

Or is Winterfell also broken for Red Hat!?

regards
hede

[hede]

Post by hede
Obviously with Red Hat this is not needed. What's the difference there?

To answer myself:
- in the rpm spec file composer gets run and the vendor dir gets copied
- in debian rules file there gets no composer ran and no vendor dir copied

result:
in roundcubemail-core.rpm there is /usr/share/roundcubemail/vendor/autoload.php and so on while with the debian packages there's no such directory. I've copied /usr/share/roundcubemail/vendor from CentOS to Debian and roundcube mail viewer starts working (php-sabre-vobject_3.4.5-1_all.deb also needed).

Btw: There are some Debian users here using Winterfell builds? Seems to be a regression then if it worked already previously!?

maybe this starts to suits better to the dev-list!?

regards
hede

[Jochen Hein]

Post by hede
Btw: There are some Debian users here using Winterfell builds? Seems to be a regression then if it worked already previously!?

I do have a testinstall with Debian and CentOS, but neither is ready for
my users and what I'd like to implement: SSO and OTP/Yubikey. So
production is still running Kolab 3.4 on Debian.

Jochen

[g.spellauge]

i gave up - too much time to invest. maybe it would be a good idea to
wait for another release of kolab (16.1, 17, ..?)

currently at my site kolab-3.4 seems to be the best choice - at least i
feel so.

Post by hede
Btw: There are some Debian users here using Winterfell builds? Seems
to be a regression then if it worked already previously!?

[Timotheus Pokorra]

Hello,

i gave up - too much time to invest. maybe it would be a good idea to wait
for another release of kolab (16.1, 17, ..?)

just to clarify: Winterfell is never considered a stable release. It
is a rolling release, which can break and should be fixed soon.
Winterfell should be used for development, testing and evalution.
Things should be fixed in Winterfell, so that the next release will be
working for the distribution of your choice.

currently at my site kolab-3.4 seems to be the best choice - at least i feel
so.

You are completely right.
I hope to write a blog post with a review of the Kolab Summit 2.0
later today, where the release cycle has been explained to some
degree.

Btw: There are some Debian users here using Winterfell builds? Seems to be a
regression then if it worked already previously!?

I have another Winterfell problem with Guam, already broken for two
weeks: https://git.kolab.org/T1305, on CentOS7. It seems I did not yet
get the attention of Aaron, the author of guam. On the other hand
nobody else confirmed the issue either, although it is totally
reproducible for me. I cannot access IMAP folders at all.

Timotheus

[hede]

Post by Timotheus Pokorra
I have another Winterfell problem with Guam, already broken for two
weeks: https://git.kolab.org/T1305, on CentOS7. It seems I did not yet
get the attention of Aaron, the author of guam. On the other hand
nobody else confirmed the issue either, although it is totally
reproducible for me. I cannot access IMAP folders at all.

The developers do not test their changes. If Winterfell breaks, it breaks and it stays in this state. Maybe it's even intended to break...

guam is one good example. Jeroen yesterday did some changes to guam. It compiled before he'd begun, he committed some changes, since then it doesn't even compile... it's left in that state.

Second example: Since its first commit, the debian.rules file for guam has a nonfunctional line. It simply doesn't work this way and was committed without testing any functionality - there is none.

Winterfells seems not to be as stable as other development platforms. Elsewhere its common to demand authors to check their commits. Like with Debian unstable or even experimental for example - unusable builds are quite uncommon, even with frequent changes. Developers are encouraged to commit only coherent changes into the non-private development repositories. Kolab:Winterfell is quite different here, leaving packages in a broken state seems quite common.

regards
hede

[Timotheus Pokorra]

Hello Aaron or Jeroen,

can you please comment on the issues of stability in Winterfell? See
conversation below.
What can the community do to help with this?

Thank you,
Timotheus

Post by hede

Post by Timotheus Pokorra
I have another Winterfell problem with Guam, already broken for two
weeks: https://git.kolab.org/T1305, on CentOS7. It seems I did not yet
get the attention of Aaron, the author of guam. On the other hand
nobody else confirmed the issue either, although it is totally
reproducible for me. I cannot access IMAP folders at all.

The developers do not test their changes. If Winterfell breaks, it breaks and it stays in this state. Maybe it's even intended to break...
guam is one good example. Jeroen yesterday did some changes to guam. It compiled before he'd begun, he committed some changes, since then it doesn't even compile... it's left in that state.
Second example: Since its first commit, the debian.rules file for guam has a nonfunctional line. It simply doesn't work this way and was committed without testing any functionality - there is none.
Winterfells seems not to be as stable as other development platforms. Elsewhere its common to demand authors to check their commits. Like with Debian unstable or even experimental for example - unusable builds are quite uncommon, even with frequent changes. Developers are encouraged to commit only coherent changes into the non-private development repositories. Kolab:Winterfell is quite different here, leaving packages in a broken state seems quite common.
regards
hede

[Aaron J. Seigo]

Post by Timotheus Pokorra
Hello Aaron or Jeroen,
can you please comment on the issues of stability in Winterfell? See
conversation below.
What can the community do to help with this?

...

Post by Timotheus Pokorra

Post by hede
Winterfells seems not to be as stable as other development platforms.
Elsewhere its common to demand authors to check their commits. Like with
Debian unstable or even experimental for example - unusable builds are
quite uncommon, even with frequent changes. Developers are encouraged to
commit only coherent changes into the non-private development
repositories. Kolab:Winterfell is quite different here, leaving packages
in a broken state seems quite common.

This will happen less and less over time. We have been adopting more peer-
review and test-assisted-development models along with a git-flow based
workflow that moves away from "dump into master" and even "dump into develop".

This is a change the Kolab developers have been taking on this year, and which
we really only managed to fully commit to across the breadth of the product
repositories. So if we do our job well in this area, we should see a much more
predictable (though with the usual caveats about runtime stability / feature
immaturity) Winterfell.

What the community can do is to participate in peer review on git.kolab.org as
differentials are posted there (which is happening pretty regularly now), and
also assist in testing with Winterfell.

As an aside: there are no "private development repositories" -> we use feature
branches, release branches, develop-vs-master branches, and hotfix branches
now. All public. While you almost certainly meant "release-target branches"
(which develop fits in the context of Winterfell), it is all public. Which
makes a perfect opportunity to get involved.

A simple `git flow feature list` can show you what features are being worked
on; a trip to https://git.kolab.org/maniphest/ shows what is current under
review ... etc. And anyone can post reviews there as well!

[hede]

I've patched roundcubemail.deb to run php-composer. See attachment. Additionally php-sabre-vobject_3.4.5-1_all.deb is needed. Reading Mails in roundcube now works for me.

Sources and armv7hf binaries are available, as usual:
http://packages.der-he.de/packages/

(disclaimer: my php-sabre-vobject package actually is violating debians package policy - to simplify matters I changed the orig-source. It's on my todo list...)

regards
hede

[Timotheus Pokorra]

Hello Hede,

Post by hede
I've patched roundcubemail.deb to run php-composer. See attachment. Additionally php-sabre-vobject_3.4.5-1_all.deb is needed. Reading Mails in roundcube now works for me.
http://packages.der-he.de/packages/

would you be able to fix this in Winterfell on OBS?
see http://www.pokorra.de/2013/10/howto-improve-debian-packages-using-obs/
there is a php-sabre-vobject, where you could add the debian package files.
https://obs.kolabsys.com/package/show/Kolab:Winterfell/php-sabre-vobject
That would be a great help for all the Debian users!

I am happy to merge the request on OBS if you submit one!

Thank you,
Timotheus

[hede]

Post by Timotheus Pokorra
would you be able to fix this in Winterfell on OBS?

I don't know if I'm able, but at least I'll try to do so. ;-)

Like I said, there's some coding styles to get fixed first. Btw. maybe I can ask it here:

With rpm spec files there's pure bash code (like heredoc) possible but with debians makefile-style rules file there's no such possibility. Thus I swapped out the scripting code to some non-standard shell file "debian/composer" which gets run by the rules file (with override_dh_auto_build). Is this ok or "bad style"?

regards
hede

[Timotheus Pokorra]

Post by hede
I don't know if I'm able, but at least I'll try to do so. ;-)

Great! if you have any questions, feel free to ask here or on IRC!

Post by hede
With rpm spec files there's pure bash code (like heredoc) possible but with debians makefile-style rules file there's no such possibility. Thus I swapped out the scripting code to some non-standard shell file "debian/composer" which gets run by the rules file (with override_dh_auto_build). Is this ok or "bad style"?

I don't know much about Debian coding styles and rules.
I guess building packages on OBS gives us the freedom to do things
that just work. If the packages are integrated into the Debian
distribution, only then the rules must be followed. But that is the
next stage I guess.

See how composer is called for iRony:
https://obs.kolabsys.com/package/view_file/Kolab:Winterfell/iRony/debian.rules?expand=1

hope this helps,
Timotheus