Hi
The subject pretty much sums it up. We are currently not adding our packages on packages.x2go.org to mock and obs builds. Is there any specific reason, why not?
To build cleanly?
This is a deal breaker for packages that require x2go packages at build time when downstream does not have official x2go* packages.
For instance, any package depending on x2goserver at build time will fail to build for OpenSUSE, because OpenSUSE is not providing any x2go packages.
Another incarnation is the issue I mentioned here: http://lists.x2go.org/pipermail/x2go-dev/2015-March/009739.html
On Fedora (possibly EPEL, too), x2goserver-extensions does not exist as a special package, but the functionality is merged into the "x2goserver" package.
A more general description: our builds for packages.x2go.org will fail whenever there is a build dependency on x2go packages, that may have been edited by distribution maintainers. We have no control over this.
Adding the x2go repositories will, though, make sure we control this aspect.
Furthermore, Debian builds always* add our own package repository.
I will go ahead and add our repository to obs and mock builds, if the reason is merely "because nobody implemented it so far".
Mihai
*) No rule without an exception. In this case the exception is "x2go-keyring".
Hi Mihai,
----- Original message -----
Hi
The subject pretty much sums it up. We are currently not adding our packages on packages.x2go.org to mock and obs builds. Is there any specific reason, why not?
To build cleanly?
This is a deal breaker for packages that require x2go packages at build time when downstream does not have official x2go* packages.
For instance, any package depending on x2goserver at build time will fail to build for OpenSUSE, because OpenSUSE is not providing any x2go packages.
Another incarnation is the issue I mentioned here: http://lists.x2go.org/pipermail/x2go-dev/2015-March/009739.html
On Fedora (possibly EPEL, too), x2goserver-extensions does not exist as a special package, but the functionality is merged into the "x2goserver" package.
A more general description: our builds for packages.x2go.org will fail whenever there is a build dependency on x2go packages, that may have been edited by distribution maintainers. We have no control over this.
Adding the x2go repositories will, though, make sure we control this aspect.
Furthermore, Debian builds always* add our own package repository.
I will go ahead and add our repository to obs and mock builds, if the reason is merely "because nobody implemented it so far".
Mihai
*) No rule without an exception. In this case the exception is "x2go-keyring".
normally (at the moment) no X2Go component build-depends (in the strict sense) on any other X2Go component.
Since we provide openSUSE/SLE builds the situation has slightly changed. The obs-build scripts runs rpmlint at end of build and IIRC that required a change in build-deps, pulling in other X2Go components at build time.
Please go ahead and add X2Go's own builds into the build process as available dependencies.
Mike
--
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976148
GnuPG Key ID 0x25771B13 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
On 18.03.2015 08:48 AM, Mike Gabriel wrote:
normally (at the moment) no X2Go component build-depends (in the strict sense) on any other X2Go component.
This was true before my change to x2gomatebindings. This package now build-depends on x2goserver and x2goserver-extensions, so that it does not own directories it shouldn't own -- like $LIBDIR/x2go. Owning directories that are "really" owned by other packages is very bad practice (unless it really cannot be handled any other way) and frowned upon in RPM-land.
I will probably have to change other components in the same vain, too.
Since we provide openSUSE/SLE builds the situation has slightly changed. The obs-build scripts runs rpmlint at end of build and IIRC that required a change in build-deps, pulling in other X2Go components at build time.
Please go ahead and add X2Go's own builds into the build process as available dependencies.
OK, will do. Thanks.
Mihai
On 18.03.2015 08:58 AM, Mihai Moldovan wrote:
Since we provide openSUSE/SLE builds the situation has slightly changed. The obs-build scripts runs rpmlint at end of build and IIRC that required a change in build-deps, pulling in other X2Go components at build time.
Please go ahead and add X2Go's own builds into the build process as available dependencies. OK, will do. Thanks.
I have added the functionality and put it into production.
With quite some nasty workarounds for mock...
I have also created /home/_x2go_shared_ with x2go-admin being the owner and this directory being world-readable. It contains another directory mock-config.
I have created symlinks $HOME/mock-config to /home/_x2go_shared_/mock-config for users x2go-admin and jenkins.
I have added (empty) "extras" repositories for fedora 20, 21 and rawhide, because they are now referenced for everything.
I will still need to write up automatic mock config file creation stuff (and probably remove /home/_x2go_shared_ and replace $HOME/mock-config with real directories, to which the automatically generated configs are written), because manually creating 4 config files for each arch and distribution and version (so 4 * #distros * #arches files) is a huge waste of time.
It's also more complicated to implement, so I leave that "for a later date".
At the same time, I have fixed x2gomatebindings and used this as a test of the deployed changes. It generally seems to work fine, but has sparked a bug in x2goserver, discovered while building OpenSUSE 13.2 packages:
[ 40s] Preparing...
########################################
[ 40s] file /etc/sudoers.d conflicts between attempted installs of
x2goserver-4.1.0.0-0.0x2go1.0.git20150316.1268.heuler.x86_64 and
sudo-1.8.10p3-2.1.6.x86_64
[ 41s] exit ...
This is why one should *never* own files or directories that are owned by other packages, even if it is convenient, "happens to work" and mock is less strict about it.
Luckily, the fix is easy and I'll implement it "tomorrow".
All this said, the changes are still pretty new and untested for all the other packages. Please note that build failures due to this are to be expected - both real ones as well as false positives (i.e., bugs in packages, but not the build script.) I'll fix those along the way.
Mihai
On Di 24 Mär 2015 08:02:41 CET, Mihai Moldovan wrote:
All this said, the changes are still pretty new and untested for all the other packages. Please note that build failures due to this are to be expected - both real ones as well as false positives (i.e., bugs in packages, but not the build script.) I'll fix those along the way.
Mihai
Thanks for doing this, Mihai!
Mike
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
-
Mihai Moldovan -
Mike Gabriel