Hi Morty, Reinhard, Arw,
Morty mentioned recently (I think in a Jabber session) that there is a
build-server available at Uni Erlangen. Will it be possible to install
qemubuilder on that system and use it for building X2go packages? I
volunteer to do that, the qemubuilder can be used for other build jobs
as well...
I have looked at the different systems available for package building
and I liked qemubuilder best. However, qemubuilder does only build in
kvm-mode on native systems (that is: not on already virtualized
systems). In Intel-based kvm-VMs it can not access the VT technology
of the CPU (so-called VT nesting).
However, AMD Pacifica CPUs support KVM nesting (never tried it out,
though). @Morty: if you run VMs on an AMD CPU that would also be great
and functional for our needs.
Anyone else: if you can provide such a build server, please let me
know that, too. I currently use my notebook for building X2go packages
(it is a really fast one, but still, it is a notebook). The server
behind code.x2go.org also runs a similar qemubuilder setup, but it
only falls back to slow qemu software emulation as it already as a
virtual machine...
Any help is appreciated, Thanks a lot Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hi Mike,
we do have such a thing and in principle this is possible. None the less, if I remember right, Reinhard has a something similar in preparation for another project. @Reinhard: Any news? I also think that compile-time shouldn't be an issue - worst case the package is published an hour later. If you've got a system up and running we should probably use that. Anyway the next two or three weeks are very busy for me, therefore I'd like to avoid doing this unless it is absolutely necessary until then.
Cheers. Morty
On 2011-04-26 22:09, Mike Gabriel wrote:
Hi Morty, Reinhard, Arw,
Morty mentioned recently (I think in a Jabber session) that there is a build-server available at Uni Erlangen. Will it be possible to install qemubuilder on that system and use it for building X2go packages? I volunteer to do that, the qemubuilder can be used for other build jobs as well...
I have looked at the different systems available for package building and I liked qemubuilder best. However, qemubuilder does only build in kvm-mode on native systems (that is: not on already virtualized systems). In Intel-based kvm-VMs it can not access the VT technology of the CPU (so-called VT nesting).
However, AMD Pacifica CPUs support KVM nesting (never tried it out, though). @Morty: if you run VMs on an AMD CPU that would also be great and functional for our needs.
Anyone else: if you can provide such a build server, please let me know that, too. I currently use my notebook for building X2go packages (it is a really fast one, but still, it is a notebook). The server behind code.x2go.org also runs a similar qemubuilder setup, but it only falls back to slow qemu software emulation as it already as a virtual machine...
Any help is appreciated, Thanks a lot Mike
X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
-- Dipl.-Ing. Moritz 'Morty' Struebe (Wissenschaftlicher Mitarbeiter) Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme) Friedrich-Alexander-Universität Erlangen-Nürnberg Martensstr. 1 91058 Erlangen
Tel : +49 9131 85-25419 Fax : +49 9131 85-28732 eMail : struebe@informatik.uni-erlangen.de WWW : http://www4.informatik.uni-erlangen.de/~morty
On Wed, Apr 27, 2011 at 12:17:41 (CEST), Moritz Struebe wrote:
we do have such a thing and in principle this is possible. None the less, if I remember right, Reinhard has a something similar in preparation for another project. @Reinhard: Any news?
No.
Also, the most problematic part I see here is the build scheduling. All scripts I've seen from Mike so far seem to assume manual scheduling only.
-- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4
Hi Reinhard,
On Mi 27 Apr 2011 12:45:54 CEST Reinhard Tartler wrote:
On Wed, Apr 27, 2011 at 12:17:41 (CEST), Moritz Struebe wrote:
we do have such a thing and in principle this is possible. None the less, if I remember right, Reinhard has a something similar in preparation for another project. @Reinhard: Any news?
No.
Also, the most problematic part I see here is the build scheduling. All scripts I've seen from Mike so far seem to assume manual scheduling only.
with investing some brain tissue it should be possible to setup
qemubuilder together with torque... This would handle CPU core
ressource and give us / your institute a build system with a genuine
job scheduler.
For rebuilding packages regularly I already have peered at rebuildd...
But your are right, currently I kick-off build jobs manually on my notebook.
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hi Morty,
On Mi 27 Apr 2011 12:17:41 CEST Moritz Struebe wrote:
Hi Mike,
we do have such a thing and in principle this is possible. None the less, if I remember right, Reinhard has a something similar in preparation for another project. @Reinhard: Any news? I also think that compile-time shouldn't be an issue - worst case the package is published an hour later.
Compile time is not an issue really, you are right. But the VM (ymir
aka code.x2go.org) is on a KVM server with other VM guests and qemu in
software emulation mode is (a) very slow compared to kvm-qemu and (b)
sucks CPU ressources that also affects other VM guests hosted on the
same VM host.
If this could be avoided I would be very glad...
If you've got a system up and running we should probably use that.
I have two systems running:
code.x2go.org (very slow, qemu software emulation) my notebook (not accessible by others than me)
Anyway the next two or three weeks are very busy for me, therefore I'd like to avoid doing this unless it is absolutely necessary until then.
My offer is to put a qemubuilder environment on your server. I would
need an account for that and I would need sudo -i access temporarily.
This qemubuilder env could be used by X2go and by any others of your
projects.
Cheers. Morty
About scheduling and ressource management I will write as a reply to
another of Reinhard's mail...
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hi Mike.
On 2011-04-28 01:56, Mike Gabriel wrote:
Anyway the next two or three weeks are very busy for me, therefore I'd like to avoid doing this unless it is absolutely necessary until then.
My offer is to put a qemubuilder environment on your server. I would need an account for that and I would need sudo -i access temporarily. This qemubuilder env could be used by X2go and by any others of your projects.
Giving root isn't an option, unfortunately. It's also not trivial to give accounts to externals, as we have an rather complex infrastructure.
I'll have a chat with Reinhard and see what we can do.
BTW: Has anyone looked into http://en.opensuse.org/openSUSE:Build_Service_cross_distribution_howto. Seems like quite a few systems can be covered using that.
Morty
-- Dipl.-Ing. Moritz 'Morty' Struebe (Wissenschaftlicher Mitarbeiter) Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme) Friedrich-Alexander-Universität Erlangen-Nürnberg Martensstr. 1 91058 Erlangen
Tel : +49 9131 85-25419 Fax : +49 9131 85-28732 eMail : struebe@informatik.uni-erlangen.de WWW : http://www4.informatik.uni-erlangen.de/~morty
Hi Morty, hi all,
On Fr 29 Apr 2011 15:39:30 CEST Moritz Struebe wrote:
Hi Mike.
On 2011-04-28 01:56, Mike Gabriel wrote:
Giving root isn't an option, unfortunately. It's also not trivial to give accounts to externals, as we have an rather complex infrastructure.
OK, acknowledged.
BTW: Has anyone looked into http://en.opensuse.org/openSUSE:Build_Service_cross_distribution_howto. Seems like quite a few systems can be covered using that.
The above link refers to RPM build systems only, doesn't it?
I think our focus should be:
o provide tarballs with proper Makefiles o offer these tarballs (or the Git itself) for other (RPM-base) packagers o concentraint on our .de-based testing environments
To my mind the reasons why we build Debian/Ubuntu packages are primarily
(a) testing developmental code (b) continuation of providing .deb packages for current X2go users (most of them Debian/Ubuntu) until X2go is officially in Debian
The idea about the build-main tag is that we give packagers a
recommendation on what code base to use for packaging stable X2go code.
The build-main tag will mostly point to the latest release, but
sometimes it will point to a newer commit (i.e. a commit that contains
a valuable update for an internal package revision for our own .deb
packages).
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On Fri, Apr 29, 2011 at 15:57:30 (CEST), Mike Gabriel wrote:
The idea about the build-main tag is that we give packagers a recommendation on what code base to use for packaging stable X2go code.
What about blessing source tarballs and publishing them on the website like almost all other free software projects do?
AFAIUI this 'build-main' tag as you propose is a moving target that is deleted and recreated every then and when. To me, this seems confusing.
-- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4
Hi Reinhard,
On Fr 29 Apr 2011 17:34:48 CEST Reinhard Tartler wrote:
On Fri, Apr 29, 2011 at 15:57:30 (CEST), Mike Gabriel wrote:
The idea about the build-main tag is that we give packagers a recommendation on what code base to use for packaging stable X2go code.
What about blessing source tarballs and publishing them on the website like almost all other free software projects do?
Ok, that might be another option. I invented the build-main tag
actually mainly as a pointer for my x2go-buildpackage script.
AFAIUI this 'build-main' tag as you propose is a moving target that is deleted and recreated every then and when. To me, this seems confusing.
Yes, indeed it is a moving target. Here I think, that it can be a
matter of documentation working against confusion.
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...