Willkommen im kivitendo Forum! Hier erweitern und teilen AnwenderInnen und EntwicklerInnen ihr Wissen.

Teste kivitendo!

kivitendo Demo

kivitendo Demo mit Schweizer Kontenplan und neuem Layout

Unterstützt kivitendo mit der Basis-Subskription!

0 Punkte

Ohne dass ich irgend etwas, zumindest wissentlich, geändert habe läuft kivitendo plötzlich nicht mehr.
Ob sich etwas bei Pg geändert hat in der Zeit (ca. 3 Monate) weiss ich nicht.

Rose::DB und RoseDB::Object sind nicht ok und lassen sich nicht neu installieren wegen Fehler zu den
Parametern von DateTime::Locale.
Weitere Fehler meldet der Installlcheck nicht.

Der gleiche Fehler tritt auf mit (aus akt. Repo)
perl t/test.pl t/locale/format_date_object.t

t/locale/format_date_object.t .. Parameter #1 ("DateTime::Locale::en_US=HASH(0xa74e950)") to DateTime::Locale::load was a 'hashref object', which is not one of the allowed types: scalar
at /usr/lib/perl5/site_perl/5.16.2/DateTime/Locale.pm line 182.

    DateTime::Locale::load(undef, 'DateTime::Locale::en_US=HASH(0xa74e950)') called at /usr/lib/perl5/site_perl/5.16.2/Rose/DateTime/Util.pm line 58    
    Rose::DateTime::Util::init_european_dates('Rose::DateTime::Util') called at /usr/lib/perl5/site_perl/5.16.2/Rose/DateTime/Util.pm line 25    
    require Rose/DateTime/Util.pm called at /usr/lib/perl5/site_perl/5.16.2/Rose/DB.pm line 12    
    Rose::DB::BEGIN() called at /usr/lib/perl5/site_perl/5.16.2/Rose/DateTime/Util.pm line 0    
    eval {...} called at /usr/lib/perl5/site_perl/5.16.2/Rose/DateTime/Util.pm line 0    
    require Rose/DB.pm called at SL/DB.pm line 8    
    SL::DB::BEGIN() called at /usr/lib/perl5/site_perl/5.16.2/Rose/DateTime/Util.pm line 0    
    eval {...} called at /usr/lib/perl5/site_perl/5.16.2/Rose/DateTime/Util.pm line 0    
    require SL/DB.pm called at SL/DBConnect.pm line 6    
    SL::DBConnect::BEGIN() called at /usr/lib/perl5/site_perl/5.16.2/Rose/DateTime/Util.pm line 0    
    eval {...} called at /usr/lib/perl5/site_perl/5.16.2/Rose/DateTime/Util.pm line 0    
    require SL/DBConnect.pm called at SL/DB/AuthClient.pm line 8    
    SL::DB::AuthClient::BEGIN() called at /usr/lib/perl5/site_perl/5.16.2/Rose/DateTime/Util.pm line 0    
    eval {...} called at /usr/lib/perl5/site_perl/5.16.2/Rose/DateTime/Util.pm line 0    
    require SL/DB/AuthClient.pm called at SL/User.pm line 41    
    User::BEGIN() called at /usr/lib/perl5/site_perl/5.16.2/Rose/DateTime/Util.pm line 0    
    eval {...} called at /usr/lib/perl5/site_perl/5.16.2/Rose/DateTime/Util.pm line 0    
    require SL/User.pm called at SL/Auth.pm line 19    
    SL::Auth::BEGIN() called at /usr/lib/perl5/site_perl/5.16.2/Rose/DateTime/Util.pm line 0                                                                                                      eval {...} called at /usr/lib/perl5/site_perl/5.16.2/Rose/DateTime/Util.pm line 0
    require SL/Auth.pm called at t/Support/TestSetup.pm line 8                                                                                                                                    Support::TestSetup::BEGIN() called at /usr/lib/perl5/site_perl/5.16.2/Rose/DateTime/Util.pm line 0
    eval {...} called at /usr/lib/perl5/site_perl/5.16.2/Rose/DateTime/Util.pm line 0                                                                                                             require Support/TestSetup.pm called at t/locale/format_date_object.t line 6
    main::BEGIN() called at /usr/lib/perl5/site_perl/5.16.2/Rose/DateTime/Util.pm line 0                                                                                                          eval {...} called at /usr/lib/perl5/site_perl/5.16.2/Rose/DateTime/Util.pm line 0

Compilation failed in require at /usr/lib/perl5/site_perl/5.16.2/Rose/DB.pm line 12.
BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.16.2/Rose/DB.pm line 12.
Compilation failed in require at SL/DB.pm line 8.
BEGIN failed--compilation aborted at SL/DB.pm line 8.
Compilation failed in require at SL/DBConnect.pm line 6.
BEGIN failed--compilation aborted at SL/DBConnect.pm line 6.
Compilation failed in require at SL/DB/AuthClient.pm line 8.
BEGIN failed--compilation aborted at SL/DB/AuthClient.pm line 8.
Compilation failed in require at SL/User.pm line 41.
BEGIN failed--compilation aborted at SL/User.pm line 41.
Compilation failed in require at SL/Auth.pm line 19.
BEGIN failed--compilation aborted at SL/Auth.pm line 19.
Compilation failed in require at t/Support/TestSetup.pm line 8.
BEGIN failed--compilation aborted at t/Support/TestSetup.pm line 8.
Compilation failed in require at t/locale/format_date_object.t line 6.
BEGIN failed--compilation aborted at t/locale/format_date_object.t line 6.
t/locale/format_date_object.t .. Dubious, test returned 255 (wstat 65280, 0xff00)

Gibt es da vielleicht eine Info, die ich verpasst habe?

von (60 Punkte)

2 Antworten

+1 Punkt
 
Beste Antwort

Das ist ein Bug im Paket Rose::DateTime, welches das Modul Rose::DateTime::Util enthält. Das API von DateTime->DefaultLocale hat sich irgendwann geändert. Release 0.540 von Rose::DateTime fixt dies.

von
ausgewählt von Anonym

Danke, das war's!

Ich habe mich wohl verwirren lassen durch scripts/installation_check.pl.

SL/InstallationCheck.pm sollte ergänzt werden mit (z.B. Zeile 37):

{ name => "Rose::DateTime", version => 0.540, url => "http://search.cpan.org/~jsiracusa/", debian => 'librose-datetime-perl' },

Ob das Debian-Paket stimmt, weiss ich nicht.

Die neue Version von Rose::DateTime wird nur dann benötigt, wenn DateTime selber neu genug ist. Insofern ist eine generelle Abhängigkeit von Rose::DateTime 0.540 eben gerade nicht gegeben und würde auf älteren Distributionen dazu führen, dass man dort Rose aus dem CPAN installieren muss und nicht die Distro-Pakete nutzen kann. Das halte ich für kontraproduktiv, weshalb kivitendo eben nicht auf die genaue Version prüft.

Ich glaube nicht, dass man davon ausgehen sollte, dass ein System nie auf den neuesten Stand
gebracht wird, d.h. irgendwann trifft es auch den Distropaketen.
Bei der Installation eines Distropakets wird wohl kein Installcheck gemacht.

Das Problem ist doch, dass im Nachhinein kaum festgestellt werden kann, welche Date::Time
Version noch lief und vielleicht andere Programme von einer neueren Version abhängig sind.
In diesem Fall wäre ein Versionstest für Date::Time mit Hinweis auf max-Version sicher hilfreich.

kivitendos Versionscheck ist relativ simpel. Ist eine Version angegeben, so ist dies die Mindestversion, die kivitendo erfordert. Wichtig ist: kivitendo erfordert diese Version.

Der Code in kivitendo beherrscht keine Checks wie »wenn DateTime zwischen Version 14 und 17 dann muss Rose::DateTime mindestens 0.540 sein«. Wenn du dafür Code beisteuern willst: bitte gerne. Ansonsten bleibe ich bei meinem oben beschriebenen Einwand, dass ein generelles Anheben der Versionsabhängigkeit von Rose::DateTime zu mehr überflüssige (!) Arbeit für all diejenigen führen würde, die eben rein Distro-Pakete nutzen.

Überflüssig wären Hinweise, wenn die Installation auch nach einem Update des Systems einwandfrei
weiter läuft. Das war bei mir nicht der Fall.

Folgende Änderungen in InstallationsCheck.pm liefern für den Fall des Falles die Mindestnfo.
(es wird ein "comment"-Feld hinzugefügt):

ca. Zeile 23:
{ name => "DateTime", url => "http://search.cpan.org/~drolsky/", debian => 'libdatetime-perl', comment=> "(Install Rose::DateTime, V 0.540 if newer than XXX)" },
{ name => "Rose::DateTime", version => 0.540, url => "http://search.cpan.org/~jsiracusa/", debian => 'librose-datetime-perl', comment=>'(Only install if DateTime newer than XXX)' },

ca. Zeile 75:

$->{fullname} = join ' ', grep $, @$_{qw(name version comment)}
for @required_modules, @optional_modules, @developer_modules;
}

0 Punkte

Falls noch aktuell (und nur weil bisher noch keine Antwort..):

Bitte mal den Output vom Installer posten.

Falls du nicht zu viele Perl-Module im System hast, wuerde ich mal ALLE deinstallieren und neu draufspielen, am besten aus den Debian/Ubuntu/DeinerDistro-Paketen (dann hast du auch immer die passenden Versionen zu den Upgrades)..

Ich kenne mich mit Perl zu wenig aus, aber vielleicht stimmen deine Locales im System nicht (bzw. wurde eine bestimmte geloescht oder so..).

von (1.0k Punkte)

Hallo mic,

alle meiner Module zu deinstallieren ist weder eine Lösung noch sinnvoll.
Es laufen viele Anwendungen mit z.T. mehr als 100 Perl-Modulen.
Auch DateTime::Locale wird dabei verwendet.

Das Ärgerliche war, dass es vorher (nach einer Umstellung von 2.x auf 3.1) einwandfrei lief.
(einwandfrei heisst: alles ok bis auf anscheinender Ajax-Fehler bei der Buchung.
Bei erster Aktualisierung wird grundsätzlich eine falscher Betrag übernommen)

Das Problem entgültig zu lösen schien mir schliesslich zu aufwendig und habe Kivitendo
jetzt auf ein anderes System übertragen können, wo es läuft.
Unterschied: 64 statt 32-bit System. (SuSE 12.3)

Sollte ich den Fehler auf ein anderes, noch Kivitendo-freies System reproduzieren
können, nehme ich den Faden wieder auf.

Ähnliche Fragen

0 Punkte
1 Antwort
0 Punkte
0 Antworten
Gefragt 4, Aug 2018 von volker (60 Punkte)
0 Punkte
3 Antworten
0 Punkte
1 Antwort
Gefragt 7, Dez 2022 von turtle (2.7k Punkte)
0 Punkte
0 Antworten
...