There are some pretty important fixes/upgrades. And I think it is a good idea to release mga5 with 1.7.x series ownCloud (and we alrerady have latest stable server version - I noticed 1.7.3 came with updates and works nicely here.) Reproducible: Steps to Reproduce:
I can test cauldron 32 and 64 bit. Using server 7.0.3 on mga5-64 on LAN. (and also using MSWIN7 OC client)
CC: (none) => christian.julia.pro, fabien.thierry, luigiwalser, mageia, mageia
Summary: owncloud-client 1.7.0 stable released 13 nov - please can we have it in mga5? => owncloud-client 1.7.1 stable released - please can we have it in mga5?
1.7.x brings selective sync which is very important as oc client do not support filesystem links. many bugfixes. I guess it is extra important to have same version as the other os when suncing same folder on an dualboot system... 1.7.1 from PCLos seem to work on cauldron. I am trying it out now. https://forums.mageia.org/en/viewtopic.php?f=8&t=8916&p=54192#p54193 Maybe there is something so sneak at there http://rpm.pbone.net/index.php3/stat/4/idpl/28454810/dir/pclinuxos/com/owncloud-client-1.7.1-1pclos2015.x86_64.rpm.html
1.7.1 is in core/updates_testing in Cauldron. Please test.
GREAT! thanks, I will.
(In reply to David Walser from comment #3) > 1.7.1 is in core/updates_testing in Cauldron. Please test. Thanks a lot! I will try :-)
Will test ASAP - I was having severe performance problem with the default database on the server, so i reinstalled it and use now MariaDB and I also made a wiki page about that (feel free to improve/correct where necesary); Only problem now is a strange error maybe someone here can help with, see https://wiki.mageia.org/en/OwnCloud#Other
Like the earlier mageia version 1.6.4 this package have a slight GUI bug: When you have the KDE panel autohiding and right click OC icon there you get a popup menu, but when moving the pointer into that menu the menu disappears when panel hides. For testing this I uninstalled mga5 oc client 1.7.1, and instead installed PCLOS version from http://rpm.pbone.net/index.php3/stat/4/idpl/28454810/dir/pclinuxos/com/owncloud-client-1.7.1-1pclos2015.x86_64.rpm.html Using that package the pupup menu stays up when panel hides. So i guess it is a packaging issue.
No, not a packaging issue. The only real difference in their package is they build it against Qt4 and we built it against Qt5. Either it's an upstream issue, or possibly a Qt5 or even a theme issue. pclos also didn't package the new nautilus-python extension file syncstate.py in 1.7.1. They removed it, along with this interesting comment in their SPEC file: #we dont have nautilus in pclos because fuck gnome3 and systemd
Ah, thanks for the clarification. Good work David ! Well Qt4 and that line in PCLOS SPEC say something about that packagers' ambitions... but lets say he/she had a bad day :) I am a bit stumped about what to try against my server problem, hints welcome.
So can you confirm that there are no regressions in our 1.7.1 package vs. the 1.6.4 package? For the server problem, I guess you're referring to the performance problem you mentioned in Comment 6? Switching to mariadb didn't fix it?
My server until a half hour ago could not sync at all due to that issue at bottom of the wiki page... Now i uninstalled all *php* packages, then installed them and that pulled three more packages and now it works. No idea what it was. I will update wiki with that fix. I quickly tested your 1.7.1 works OK syncing and performance is high :) Heavier tests in weekend.
I see no problem in owncloud client 1.7.1-1mga5. - OK for me to move it to official release :) Sidenote about the server: As for performance it here moves five small files (a couple kb) per second (before i reinstalled server i had two seconds per file, so it is 10x increase! That is still very little in bandwidth. Servers dual atom 1,6MHz is topped out, Mysql taking 40% and three httpd 15% each. (Yes it is a low power energy saving unit.) At the same time owncloud-client takes less than a percent. Large files are topping disk bandwidth. So the problem is database speed - or owncloud could upload large filesets in a more intelligent way.
I have two files that client can not upload. That is probably owncloud internal error but I post it here as a note anyway. Although the filenames are not beautiful I find it strange that owncloud chokes on characters that is no problem for neither linux nor windows when i use them. Both files are from a folder that is shared trough Virtualbox to a virtual WinXP machine. Did not try these files on earlier client. One is /home/morgan/ownCloud/VBoxDelning/TECO/Tankat/SG2_V3.72-firmware-for-all-3.x-series/IMO_V3.72/SMTV3_UpDate V3.72.exe:Zone.Identifier owncloud-client report the file contain illegal characters. I suppose it meant to say the *filename* contain illegal characters. That is a part of an install set from TECO and both mageia and WinXP handles it. The other is /home/morgan/ownCloud/VBoxDelning/PICAXE/PICAXEs-dokument-och-program/Programmeringsprogram/Microsoft ATL Security Runtime Update %0AInstall if you get a splashscreen lockup at startup-details.htm And for that the server just replies bad request. It is an web page archived by Opera or Firefox running on XP or mageia i forgot which, bot again nothing else have problem with it.
I believe 1.7.1 use a bit less CPU for same load, and do not have more problems. The few problems i found are the same in 1.6.4 and probably not due to packaging. Example: if one client syncs a folder located on a NTFS share to a folder shared by another user, the server seem to go crazy and uploads already downloadsd files back from it even when they have not been altered, and then shove them back to the other client that shared them in the first place and it goes slooooow and server spits errors in log. There are a few other problems, or i just need to RTFM, but my time i can put on owncloud is out for now. What i try to say is I think your packaging is OK, but the owncloud folks have things to catch up...
Hi, using mga 5 KDE 64, I installed owncloud-client and lib64owncloudsync1 from update-testing, but I get a error when starting it: from console: $ owncloud SocketApi: server started, listening at "/run/user/500/ownCloud/socket" ==== added system ignore list to socketapi: "/etc/ownCloud/sync-exclude.lst" ==== added user defined ignore list to csync: "/home/steph/.local/share/data/ownCloud/sync-exclude.lst" setting remote poll timer interval to 30000 msec Erreur de segmentation (segmentation fault) It happens a few seconds after entering my password. Any idea? Thanks
CC: (none) => mageia
I have no idea. In general, things you can look at with a segfault would be, if the application has a debug option, strace, ltrace, and gdb.
Now pushed to core/release as owncloud-client-1.7.1-2.mga5.
Status: NEW => RESOLVEDResolution: (none) => FIXED
Hi, I removed it and installed it again from the core/release media after. It is now working fine. don't understand what happened before. Thank you ;)
Great to have latest owncloud server and client in mga5! Thank you :)
(In reply to David Walser from comment #17) > Now pushed to core/release as owncloud-client-1.7.1-2.mga5. Thanks a lot! It works fine :-) (with a new VM on Virtual Box and an 22Gb user on owncloud)
Those who are using it: can you select a second local base folder? Me and at least one other (presumably non mageian) linux user have problem. http://forum.owncloud.org/viewtopic.php?f=14&t=25309&p=78838#p78838 (Me=Morgano)
(In reply to Morgan Leijström from comment #21) > Those who are using it: can you select a second local base folder? > Me and at least one other (presumably non mageian) linux user have problem. > http://forum.owncloud.org/viewtopic.php?f=14&t=25309&p=78838#p78838 > (Me=Morgano) Euh... It seems to work fine. I have removed my "full" share folder and have created with success 2 folders... But i can't add a new folder if I have a "full" share folder :-)
(In reply to Fabien THIERRY from comment #22) > (In reply to Morgan Leijström from comment #21) > > Those who are using it: can you select a second local base folder? > > Me and at least one other (presumably non mageian) linux user have problem. > > http://forum.owncloud.org/viewtopic.php?f=14&t=25309&p=78838#p78838 > > (Me=Morgano) > > Euh... > It seems to work fine. > I have removed my "full" share folder and have created with success 2 > folders... > > But i can't add a new folder if I have a "full" share folder > > :-) Now 1.8.0 is packaged in core/updates_testing in Cauldron (by Sander). Please test it.
(In reply to David Walser from comment #23) > (In reply to Fabien THIERRY from comment #22) > > (In reply to Morgan Leijström from comment #21) > > > Those who are using it: can you select a second local base folder? > > > Me and at least one other (presumably non mageian) linux user have problem. > > > http://forum.owncloud.org/viewtopic.php?f=14&t=25309&p=78838#p78838 > > > (Me=Morgano) > > > > Euh... > > It seems to work fine. > > I have removed my "full" share folder and have created with success 2 > > folders... > > > > But i can't add a new folder if I have a "full" share folder > > > > :-) > > Now 1.8.0 is packaged in core/updates_testing in Cauldron (by Sander). > Please test it. Hello. owncloud client 1.8.0 is installed and seems to work fine! :-)
Thank you for keeping it updated :) This 1.8.0 seem to work OK on my main machine. However on my laptops it fails, saying it failed to create a journal file, "check that you have write and read rights" - yes i have *). Plus, if i close it or let it run a while (presumably to next sync) it segmentation faults. *) i actually see the .csync_journal.db-shm got a timestamp when i run 1.8.0, but the .csync_journal.db-wal and .owncloudsync.log are old. All have same rights. All are fully updated 64 bit cauldrons and were running the earlier current cauldron owncloud client package before. The main machine is an intel i7, laptops are centrino dual cores. I cant tell much more difference between the faulting and working machines. Server is owncloud 7.0.5 by mageia package. Any ideas to test?
Did you update all packages? Client and libs as well?
Spot on, thanks! i forgot lib64ocsync0 on the laptops... Can you make owncloud-client package demand same version of the other packages? It would ease manual maintenance if its name contain "owncloud", like the other lib do. Why not lib64owncloudsync0 like lib64owncloudsync1 ? ( Just to complete of my *) paragraph if other see same symptoms: I forgot to list that the .csync_journal.db are also not updated. However if i delete all mentined files (.csync_journal.db, .csync_journal.db-wal, .csync_journal.db-shm, .owncloudsync.log *all* are recreated, but it still complains on access rights, and segfaults... running it with --logwindow dont tell me any news except normal operation plus the same message it say it can not write log file - but it did. ) All OK now :)
Sander, will you do the honors for the freeze push request?
Done /o\ :)
Now they have released 1.8.1 with many bugfixes. ... https://forum.owncloud.org/viewtopic.php?f=9&t=28168
this is a candidate for update when mg5 will be released.
1.8.1 building in updates_testing now. Please test when it's available.
Thanks, 64 bit update test pass OK
Nah, wait! It works but I forgot to check - and it is not first time i forget: it did not update lib64ocsync0 Not on mirror yet. It is possible to make the main package demand equal versions on all three packages?
No, weird: it is on mirror (at least now) but why is it not automatically selected for update, like the other two packages ? Package or urpmi bug?
Please test next rpm
Yes now i see... ocsync1 != ocsync0 ;) I report back when tested.
Trying auto update, /usr/lib64/libocsync.so.0 from lib64ocsync1-1.8.1-2.mga5.x86_64 conflicts the file from lib64ocsync0-1.8.0-2.mga5.x86_64 : # urpmi --auto-update --auto -snip- http://192.168.0.12/mageia/distrib/5/x86_64/media/core/updates_testing/lib64ocsync1-1.8.1-2.mga5.x86_64.rpm http://192.168.0.12/mageia/distrib/5/x86_64/media/core/updates_testing/owncloud-client-1.8.1-2.mga5.x86_64.rpm http://192.168.0.12/mageia/distrib/5/x86_64/media/core/updates_testing/lib64owncloudsync1-1.8.1-2.mga5.x86_64.rpm installerar owncloud-client-1.8.1-2.mga5.x86_64.rpm lib64owncloudsync1-1.8.1-2.mga5.x86_64.rpm lib64ocsync1-1.8.1-2.mga5.x86_64.rpm från /var/cache/urpmi/rpms Förbereder... ############################################################## Installationen misslyckades: fil /usr/lib64/libocsync.so.0 från installation av lib64ocsync1-1.8.1-2.mga5.x86_64 står i konflikt med filen från paket lib64ocsync0-1.8.0-2.mga5.x86_64
Yes, it's fixed now in owncloud-client-1.8.1-3.mga5, please try when that's available. The problem is, the real soname of the libraries is still 0, but the filenames are .so.1.8.1, which looks like it should be a soname of 1. So the package still provides it as .so.0, which is satisfied by your existing libocsync0 and the updated libocsync1, but it won't automatically update one to the other because they have different package names. Technically, these packages should still be using 0 as their major. Upstream really messed us up here. Anyway, I just had the major 1 lib packages obsolete the major 0 ones, so now it will update cleanly.
Success! (tested on another computer that had 1.8.0)
owncloud-client-1.8.1-4.mga5 is now available in core/release in Cauldron.
Very good! So now we have the stable latest versions of both owncloud server and client in release. :)