Re: [Owncloud] Owncloud on Fedora/RHEL 6
Hi, I just wanna step in here to clarify some things. FYI: I'm the 'main' maintainer of owncloud in fedora. On Monday 20 January 2014 11:35:06 Klaas Freitag wrote: > On 19.01.2014 21:06, Matěj Cepl wrote: > > Hi Matěj, > > > And if insted of pushing new version to your system (or OpenSUSE > > build) you would push it to the Koji, then you would have build > > for Rawhide and -testing distros in the same time. > > How about already released versions of Fedora? For example, will it be > possible to provide _version_ updates of ownCloud to users of Fedora 20 > through Koji? AFAIK for released distros, only security fixes but no > version updates are allowed?! This is not the case for fedora. You are allowed to bump releases as you please. Actually the updates policy states otherwise but since nobody really enforces it, it's basically a maintainer decision [1]. > > If it is possible to ship version updates of ownCloud through the > official Fedora channels within hours or days, we could immediately > switch to Koji, as I said before. Technically it's possible within hours but the main issue is bundling. As you know distros try really hard to avoid bundling. So if: A: the 3rdparty dep is already packaged B: and is compatible with owncloud (version, patches) C: can easily be integrated (read: I just delete the bundled lib in 3rdparty and add it to requires) it would be very easy to track new owncloud releases in fedora. In reality of course it's not that easy: - often php includes are all messed up with hardcoded paths. If you drop a 3rdparty lib owncloud breaks, even if the system lib is installed. Adamw has created a set of patches to address this issues. There are even pull requests. - also some libs are seemingly randomly patched (this time we had some fun with doctrine and ownloud6, after applying the patches to doctrine it works again but of course it took some time) Another, more social, issue is: What to do with users that don't want to switch? I.e. you have a nice working oc 5 install and now your package manager wants to upgrade it, although oc 5 is still supported and receives fixes. Imho we would need for this case packages in multiple versions i.e. ownloud6, owncloud5, ... so there can't be unwanted upgrades. All this takes quite some effort and my time is limited, after all I don't get paid :). And as long as those issues are not resolved I kinda see the point of an upstream rpm channel distributing vanilla oc releases, though of course I would prefer it to keep it all inside fedora... > > >> They don't wanna have their operating system platform having > >> dictating the versions of the apps they're using. > > > > ??? Nobody dictates you anything, if you put you hand down to > > the shovel. > > You misunderstood. I meant: If the distro does not allow version > updates, it dictates you more or less which version of ownCloud you as a > user can use. > > >> You might want to check how that is on other, successful > >> platforms like android how it works there. Time has changed > >> a bit, and we as distro guys shouldn't close the eyes IMHO. > > > > If you think that the mess of multiple copies of huge libraries > > bundled in individual packages half of them unmaintained (a mess > > from which Java folks are trying to get out ... > > http://openjdk.java.net/projects/jigsaw/ ... so far > > unsuccessfully) and thus half of them with unpatched security > > vulnerabilities makes me envious, then you are sorely mistaken. > > Haha, me neither of course. But we have to admit: Even though users are > pestering their systems and probably get into dangerous situations > without realizing that, Android as a system is hugely successful. People > _want_ that. Unfortunately. > > > I didn’t say that. Just because you are doing your separate > > community, you didn’t have time and resources to do it > > correctly. Completely without any sneering, how should I report > > bugs against your RHEL packaging? GitHub Issue tracker? > > Yes, please. It is useful to prepend the subject with something like > [Packaging]. > > >> a) RHEL 6 ships Qt 4.6 IIRC. That is so much outdated that we could not > >> backport the client without taking too much away. And RHEL not being > >> desktop system no 1 on the planet, we decided to ship an useful Qt > >> version in /opt/. I know, distro people hate that, but please consider > >> reality here as well. What do users want? A _working_ solution. And I > >> don't think that the Qt in /opt/.. steps in the way of anything else on > >> the system as we also provide wrapper scripts. > > > > What do users want? Well, users of RHEL want also _maintained_ > > solution. Are you certain you will maintain Qt (it is a huge > > library) as well as Fedora maintainers? As I said we have php53 > > package (for EPEL 5; don’t tell me how RHEL-6 is obsolete before > > supporting RHEL-5 ;)), or perhaps somebody can think about > > patching reasonable subset of ownclo
Re: [Owncloud] Owncloud on Fedora/RHEL 6
On 19.01.2014 21:06, Matěj Cepl wrote: Hi Matěj, And if insted of pushing new version to your system (or OpenSUSE build) you would push it to the Koji, then you would have build for Rawhide and -testing distros in the same time. How about already released versions of Fedora? For example, will it be possible to provide _version_ updates of ownCloud to users of Fedora 20 through Koji? AFAIK for released distros, only security fixes but no version updates are allowed?! If it is possible to ship version updates of ownCloud through the official Fedora channels within hours or days, we could immediately switch to Koji, as I said before. They don't wanna have their operating system platform having dictating the versions of the apps they're using. ??? Nobody dictates you anything, if you put you hand down to the shovel. You misunderstood. I meant: If the distro does not allow version updates, it dictates you more or less which version of ownCloud you as a user can use. You might want to check how that is on other, successful platforms like android how it works there. Time has changed a bit, and we as distro guys shouldn't close the eyes IMHO. If you think that the mess of multiple copies of huge libraries bundled in individual packages half of them unmaintained (a mess from which Java folks are trying to get out ... http://openjdk.java.net/projects/jigsaw/ ... so far unsuccessfully) and thus half of them with unpatched security vulnerabilities makes me envious, then you are sorely mistaken. Haha, me neither of course. But we have to admit: Even though users are pestering their systems and probably get into dangerous situations without realizing that, Android as a system is hugely successful. People _want_ that. Unfortunately. I didn’t say that. Just because you are doing your separate community, you didn’t have time and resources to do it correctly. Completely without any sneering, how should I report bugs against your RHEL packaging? GitHub Issue tracker? Yes, please. It is useful to prepend the subject with something like [Packaging]. a) RHEL 6 ships Qt 4.6 IIRC. That is so much outdated that we could not backport the client without taking too much away. And RHEL not being desktop system no 1 on the planet, we decided to ship an useful Qt version in /opt/. I know, distro people hate that, but please consider reality here as well. What do users want? A _working_ solution. And I don't think that the Qt in /opt/.. steps in the way of anything else on the system as we also provide wrapper scripts. What do users want? Well, users of RHEL want also _maintained_ solution. Are you certain you will maintain Qt (it is a huge library) as well as Fedora maintainers? As I said we have php53 package (for EPEL 5; don’t tell me how RHEL-6 is obsolete before supporting RHEL-5 ;)), or perhaps somebody can think about patching reasonable subset of owncloud-client to work with old Qt, or perhaps old owncloud-client can be patched to work with new server API. Something. Reasonable people are able to negotiate solutions for their problems. We used to maintain patches for Qt 4.6, but at some point of it was not longer reasonable. So hard to find a good solution. I am sure we're not alone with the problem on RHEL and, if you search, you find more project shipping their "own" Qt. Have you thought about how other web oriented platforms solve this problem? Why does the ruby gem stuff exist? Because they want to be faster than the distros update cycle, as we want. And I think you agree with me that a third party repo with proper rpms is the better solution. https://admin.fedoraproject.org/pkgdb/acls/list/*rubygem* well not exactly shabby. I know, all distros package gems, perl modules etc. But for the distro users, there are always the two alternatives: Do I use the distro package of the ldap gem (example) or do I use gem install which brings a newer version but conflicts with my installed other ruby stuff. The philosophy behind in the ruby world is: Since using gem is so easy, we can provide new and incompatible versions very often and quick. Bad for "traditional" distro users. As long as we can not, I think we need to keep up our third party repo for those who are interested in new versions on your distro. If our packages are broken, sorry, please help us fixing. How about coming you come up with concrete things to fix? I am sorry, I have already too much on my plate, and I don’t know any PHP, so with regards to ownCloud I am just (very happy and excited) pure user. Hmm, see what I mean? I am quite busy in implementing more cool desktop client sync features or fix bugs in there. So that is why our packages are not yet optimal: Nobody has time to make them really good. So everybody who has some minutes left: Please jump in and help! regards, Klaas ___ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo
Re: [Owncloud] Owncloud on Fedora/RHEL 6
(sorry, for the late reply ... I have sent it to the list with wrong From: address and it apparently got lost) On 2014-01-13, 21:25 GMT, you wrote: > And here is the problem: Fedora 19 (!) seems to provide > ownCloud 4.5.13 which is about nine month old. That's not what > people want. They want ownCloud 6. And we seek a way to > provide them, even if they are on Fed19. And if insted of pushing new version to your system (or OpenSUSE build) you would push it to the Koji, then you would have build for Rawhide and -testing distros in the same time. When I was working as part of the team dealing with Mozilla programs (Firefox and Thunderbird) we were proud to have 0day upgrades. I don’t see the reason why you couldn’t have the same in Fedora (note, Fedora is not RHEL so updates and rebases are mostly decision of the maintainers). > Yes, I know, I worked long enough for another distro. But one > of the distro communities problems is that they don't really > face todays reality: As said above, people want to have > up-to-date apps. And if a new version (!) comes out, they > wanna use it and not hear "Well, you have a nine month old > version, and we will provide you with security fixes. Be > happy!" I am not sure which distro you are talking about. If you think Debian/stable, then RHEL is not exactly like that. Of course, stability is very very important, but it is not exactly completely dead frozen stability as with the Debian/stable (and this is not meant to say anything against Debian maintainers ... when I see how incredible amount of work my colleagues have to spend on keeping RHEL together, I fully understand Debian with its limited resources is not capable of such feat). Notice that we have many server side (even PHP) programs in EPEL (https://fedoraproject.org/wiki/EPEL), and if you think that keeping up with WordPress (http://koji.fedoraproject.org/koji/packageinfo?packageID=4118) is so simple, then you are badly mistaken. For example, we had to create php53 for it (or because of Zarafa http://koji.fedoraproject.org/koji/packageinfo?packageID=9907, another not exactly simple package to maintain). > They don't wanna have their operating system platform having > dictating the versions of the apps they're using. ??? Nobody dictates you anything, if you put you hand down to the shovel. > You might want to check how that is on other, successful > platforms like android how it works there. Time has changed > a bit, and we as distro guys shouldn't close the eyes IMHO. If you think that the mess of multiple copies of huge libraries bundled in individual packages half of them unmaintained (a mess from which Java folks are trying to get out ... http://openjdk.java.net/projects/jigsaw/ ... so far unsuccessfully) and thus half of them with unpatched security vulnerabilities makes me envious, then you are sorely mistaken. I don’t mind if people put such mess on their phones (their problem), but to have something like that on server doesn’t seem like a good idea. Yes, many people do it, but probably mostly because they have no other choice (especially in Java world which lacks appropriate technology, http://openjdk.java.net/projects/jigsaw/ still hasn’t materialized), but a part of the Fedora’s mission is to provide excellent engineering. This doesn’t seem like a way to get there. BTW, so far, RHEL customers seem to agree with this opinion. > Of course not. This is speed: If ownCloud upstream releases > a new ownCloud version, the users can install it through their > distro package manager an hour later. 6.0.0a on Fedora 19. As I said, as the old rabbi said ... it depends just on you. > Whooohooo, now you're starting! Please calm down a bit, we're > not doing bad stuff intentional. I didn’t say that. Just because you are doing your separate community, you didn’t have time and resources to do it correctly. Completely without any sneering, how should I report bugs against your RHEL packaging? GitHub Issue tracker? > a) RHEL 6 ships Qt 4.6 IIRC. That is so much outdated that we could not > backport the client without taking too much away. And RHEL not being > desktop system no 1 on the planet, we decided to ship an useful Qt > version in /opt/. I know, distro people hate that, but please consider > reality here as well. What do users want? A _working_ solution. And I > don't think that the Qt in /opt/.. steps in the way of anything else on > the system as we also provide wrapper scripts. What do users want? Well, users of RHEL want also _maintained_ solution. Are you certain you will maintain Qt (it is a huge library) as well as Fedora maintainers? As I said we have php53 package (for EPEL 5; don’t tell me how RHEL-6 is obsolete before supporting RHEL-5 ;)), or perhaps somebody can think about patching reasonable subset of owncloud-client to work with old Qt, or perhaps old owncloud-client can be patched to work with new server API.
Re: [Owncloud] Owncloud on Fedora/RHEL 6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014-01-13, 21:25 GMT, you wrote: > And here is the problem: Fedora 19 (!) seems to provide > ownCloud 4.5.13 which is about nine month old. That's not what > people want. They want ownCloud 6. And we seek a way to > provide them, even if they are on Fed19. And if insted of pushing new version to your system (or OpenSUSE build) you would push it to the Koji, then you would have build for Rawhide and -testing distros in the same time. When I was working as part of the team dealing with Mozilla programs (Firefox and Thunderbird) we were proud to have 0day upgrades. I don’t see the reason why you couldn’t have the same in Fedora (note, Fedora is not RHEL so updates and rebases are mostly decision of the maintainers). > Yes, I know, I worked long enough for another distro. But one > of the distro communities problems is that they don't really > face todays reality: As said above, people want to have > up-to-date apps. And if a new version (!) comes out, they > wanna use it and not hear "Well, you have a nine month old > version, and we will provide you with security fixes. Be > happy!" I am not sure which distro you are talking about. If you think Debian/stable, then RHEL is not exactly like that. Of course, stability is very very important, but it is not exactly completely dead frozen stability as with the Debian/stable (and this is not meant to say anything against Debian maintainers ... when I see how incredible amount of work my colleagues have to spend on keeping RHEL together, I fully understand Debian with its limited resources is not capable of such feat). Notice that we have many server side (even PHP) programs in EPEL (https://fedoraproject.org/wiki/EPEL), and if you think that keeping up with WordPress (http://koji.fedoraproject.org/koji/packageinfo?packageID=4118) is so simple, then you are badly mistaken. For example, we had to create php53 for it (or because of Zarafa http://koji.fedoraproject.org/koji/packageinfo?packageID=9907, another not exactly simple package to maintain). > They don't wanna have their operating system platform having > dictating the versions of the apps they're using. ??? Nobody dictates you anything, if you put you hand down to the shovel. > You might want to check how that is on other, successful > platforms like android how it works there. Time has changed > a bit, and we as distro guys shouldn't close the eyes IMHO. If you think that the mess of multiple copies of huge libraries bundled in individual packages half of them unmaintained (a mess from which Java folks are trying to get out ... http://openjdk.java.net/projects/jigsaw/ ... so far unsuccessfully) and thus half of them with unpatched security vulnerabilities makes me envious, then you are sorely mistaken. I don’t mind if people put such mess on their phones (their problem), but to have something like that on server doesn’t seem like a good idea. Yes, many people do it, but probably mostly because they have no other choice (especially in Java world which lacks appropriate technology), but a part of the Fedora’s mission is to provide excellent engineering. This doesn’t seem like a way there. BTW, so far, RHEL customers seem to agree with this opinion. > Of course not. This is speed: If ownCloud upstream releases > a new ownCloud version, the users can install it through their > distro package manager an hour later. 6.0.0a on Fedora 19. As I said, as the old rabbi said ... it depends just on you. > Whooohooo, now you're starting! Please calm down a bit, we're > not doing bad stuff intentional. I didn’t say that. Just that because you are doing your separate community, you didn’t have time and resources to do it correctly. Completely without any sneering, how should I report bugs against your RHEL packaging? GitHub Issue tracker? > a) RHEL 6 ships Qt 4.6 IIRC. That is so much outdated that we could not > backport the client without taking too much away. And RHEL not being > desktop system no 1 on the planet, we decided to ship an useful Qt > version in /opt/. I know, distro people hate that, but please consider > reality here as well. What do users want? A _working_ solution. And I > don't think that the Qt in /opt/.. steps in the way of anything else on > the system as we also provide wrapper scripts. What do users want? Well, users of RHEL want also _maintained_ solution. Are you certain you will maintain Qt (it is a huge library) as well as Fedora maintainers? As I said we have php53 package (for EPEL 5; don’t tell me how RHEL-6 is obsolete before supporting RHEL-5 ;)), or perhaps somebody can think about patching reasonable subset of owncloud-client to work with old Qt, or perhaps old owncloud-client can be patched to work with new server API. Something. Reasonable people are able to negotiate solutions for their problems. > b) issue tracker: https://github.com/owncloud/mir
Re: [Owncloud] Owncloud on Fedora/RHEL 6
On 13.01.2014 18:32, Matěj Cepl wrote: Hi, On 2014-01-12, 20:32 GMT, Klaas Freitag wrote: Where is that package, who maintains it and how long does it take until it is updated after we released a new ownCloud version? It is a problem for us if downstream falls behind with the versions provided for the systems in question. You can get all these information from https://admin.fedoraproject.org/pkgdb/acls/name/owncloud (e.g., http://pkgs.fedoraproject.org/cgit/owncloud.git/ shows all packaging files, https://admin.fedoraproject.org/updates/owncloud shows current updates in stable repos, http://koji.fedoraproject.org/koji/packageinfo?packageID=15599 shows builds (note, that F21 is current Rawhide)). Thanks. And here is the problem: Fedora 19 (!) seems to provide ownCloud 4.5.13 which is about nine month old. That's not what people want. They want ownCloud 6. And we seek a way to provide them, even if they are on Fed19. I am not sure what is the name of the package maintainer (his/her Fedora login name is brummbq and he is also helped by Adam Williams, one of the Fedora QA people, who uses ownCloud for his own use), but what stops you from comaintaining the package? I couldn’t imagine any complaints if you stepped up and provided patches for (not that many) bugs against owncloud packages (https://bugzilla.redhat.com/buglist.cgi?quicksearch=component%3Aowncloud) or to start to comaintain the packages. I know. People who do work are seldomly facing complaints for the fact that they do work ;-) Also, I am a Fedora provenpackager, so if there were any delays with building packages or something of that sort, I have power to push it through (of course, I would seek first advice from the current package maintainer). We use the build system that suits us best to provide packages to the ownCloud users very fast, and currently that is the openSUSE Build Service. I am not big fan of the third party repos created by people who are not willing to work with the distro community (and looking at http://packages.debian.org/search?keywords=owncloud I am not alone). Yes, I know, I worked long enough for another distro. But one of the distro communities problems is that they don't really face todays reality: As said above, people want to have up-to-date apps. And if a new version (!) comes out, they wanna use it and not hear "Well, you have a nine month old version, and we will provide you with security fixes. Be happy!" They don't wanna have their operating system platform having dictating the versions of the apps they're using. You might want to check how that is on other, successful platforms like android how it works there. Time has changed a bit, and we as distro guys shouldn't close the eyes IMHO. I don’t understand the word “very fast” here. It certainly doesn’t mean speed literally. Of course not. This is speed: If ownCloud upstream releases a new ownCloud version, the users can install it through their distro package manager an hour later. 6.0.0a on Fedora 19. Do you mean that your own repo allows you to create sloppy packages which break rest of the system? Do you mean that instead of proper resolving the issues you can introduce new versions of libraries incompatible with the rest of the system? (is it finally possible to build owncloud client on RHEL-6 without introducing new versions of the third party libraries?) Do you mean that by hiding issue tracker you can happily ignore complaints of your users (where is the issue tracker of the Fedora/RHEL packages)? Whooohooo, now you're starting! Please calm down a bit, we're not doing bad stuff intentional. a) RHEL 6 ships Qt 4.6 IIRC. That is so much outdated that we could not backport the client without taking too much away. And RHEL not being desktop system no 1 on the planet, we decided to ship an useful Qt version in /opt/. I know, distro people hate that, but please consider reality here as well. What do users want? A _working_ solution. And I don't think that the Qt in /opt/.. steps in the way of anything else on the system as we also provide wrapper scripts. b) issue tracker: https://github.com/owncloud/mirall/issues - not exactly hidden... If the packages are not behaving well, please help us fixing. Why should I help to split Fedora/EPEL distro by supporting incompatible packages (and if they are not incompatible, what they are good for)? Because you're a constructive guy that helps to provide the best for FOSS and it's users. > I don’t know where this mentality of splitting distro into thousand of incompatible subcommunities growth from? Ubuntu, with its PPAs, because Canonical doesn’t allow you to fix bugs in the core libraries, or what (not trying to libel them, just really honestly don’t know why you need to separate yourself from the rest of the Fedora/RHEL community)? It's not that we want to separate, why should we? We see the benefit of stable and maintained distros. But as I tried to explain
Re: [Owncloud] Owncloud on Fedora/RHEL 6
[This message has also been posted to gmane.comp.kde.devel.owncloud.] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014-01-12, 20:32 GMT, Klaas Freitag wrote: > Where is that package, who maintains it and how long does it > take until it is updated after we released a new ownCloud > version? It is a problem for us if downstream falls behind > with the versions provided for the systems in question. You can get all these information from https://admin.fedoraproject.org/pkgdb/acls/name/owncloud (e.g., http://pkgs.fedoraproject.org/cgit/owncloud.git/ shows all packaging files, https://admin.fedoraproject.org/updates/owncloud shows current updates in stable repos, http://koji.fedoraproject.org/koji/packageinfo?packageID=15599 shows builds (note, that F21 is current Rawhide)). I am not sure what is the name of the package maintainer (his/her Fedora login name is brummbq and he is also helped by Adam Williams, one of the Fedora QA people, who uses ownCloud for his own use), but what stops you from comaintaining the package? I couldn’t imagine any complaints if you stepped up and provided patches for (not that many) bugs against owncloud packages (https://bugzilla.redhat.com/buglist.cgi?quicksearch=component%3Aowncloud) or to start to comaintain the packages. Also, I am a Fedora provenpackager, so if there were any delays with building packages or something of that sort, I have power to push it through (of course, I would seek first advice from the current package maintainer). > We use the build system that suits us best to provide packages to the > ownCloud users very fast, and currently that is the openSUSE > Build Service. I am not big fan of the third party repos created by people who are not willing to work with the distro community (and looking at http://packages.debian.org/search?keywords=owncloud I am not alone). I don’t understand the word “very fast” here. It certainly doesn’t mean speed literally. Koji (Fedora build system) builds not slower than any other build system I know about (or not significantly slower). Do you mean that your own repo allows you to create sloppy packages which break rest of the system? Do you mean that instead of proper resolving the issues you can introduce new versions of libraries incompatible with the rest of the system? (is it finally possible to build owncloud client on RHEL-6 without introducing new versions of the third party libraries?) Do you mean that by hiding issue tracker you can happily ignore complaints of your users (where is the issue tracker of the Fedora/RHEL packages)? > If the packages are not behaving well, please help us fixing. Why should I help to split Fedora/EPEL distro by supporting incompatible packages (and if they are not incompatible, what they are good for)? I don’t know where this mentality of splitting distro into thousand of incompatible subcommunities growth from? Ubuntu, with its PPAs, because Canonical doesn’t allow you to fix bugs in the core libraries, or what (not trying to libel them, just really honestly don’t know why you need to separate yourself from the rest of the Fedora/RHEL community)? What is the source of the perceived speed of the building? > Fully agreed. The problem is probably that nobody had time and > knowledge enough to get that fixed. Can you help us and test > and tell us what needs to be done to make it work well with > SELinux? Well, if you were using packages build together with the rest of the distro (so they would have proper configuration files, etc.), then you won’t need that time and knowledge yourself. You just file bugs to RH BZ. That’s what sharing is all about. Best, Matěj -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iD8DBQFS1CM34J/vJdlkhKwRAvymAJ4u4fcibku5o4pET2yGipwCgbW+MwCcCN1o w3JZk538EO00LlWzW5RBA5A= =M9rf -END PGP SIGNATURE- ___ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] Owncloud on Fedora/RHEL 6
On 12.01.2014 01:54, Matej Cepl wrote: Hi, after following the discussion about SQLite I wondered whether you support also PostgreSQL (whcih I prefer over MySQL of any variety, and it is ... good) and I stumbled upon http://doc.owncloud.org/server/6.0/admin_manual/installation/installation_linux.html which says in the relevant part: Fedora: Make sure SELinux is disabled or else theinstallation process might fail. That isn’t a nice thing to say. I have no idea how that made it to the docs, but probably there were reasons at the time it was written. But I agree, that is not a solution. a) There is an officially provided Fedora/EPEL6 package, so there is no need to send people to OpenSUSE build system. Where is that package, who maintains it and how long does it take until it is updated after we released a new ownCloud version? It is a problem for us if downstream falls behind with the versions provided for the systems in question. We use the build system that suits us best to provide packages to the ownCloud users very fast, and currently that is the openSUSE Build Service. If the packages are not behaving well, please help us fixing. b) I see in our selinux-policy package that there have been already made changes to the policy because of OwnCloud. I am certain that our SELinux maintainers would love to hear about troubles with OwnCloud and SELinux. They are usually really fast in fixing any possible problems. Please, ask them to help you and do not switch off SELinux. Fully agreed. The problem is probably that nobody had time and knowledge enough to get that fixed. Can you help us and test and tell us what needs to be done to make it work well with SELinux? Thanks, Klaas ___ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
