Hi Morty,

Am 08.03.2013 17:15, schrieb Moritz Struebe:

Wow, the new wiki looks so cleaned up. /me likes it. I don't like the shadows of the headlines, though. IMO it looks good, but makes them harder to read.

Morty

It was planned to use the default dokuwiki template with only small changes. So I changed only things that I thought to be usefull.

As the default Template changed again with the last update I already applied, I'll need to do a lot of work again.

So I can respect ideas and criticism with the new version. The layout is planned to adopt the wiki use. I still think, that we will need some glossy and easy to read pages for the first time visitors...

Regards,

Heinz

Hi Heinz,

On Di 12 Mär 2013 09:55:15 CET Moritz Struebe wrote:

...

So I can respect ideas and criticism with the new version. The layout is planned to adopt the wiki use. I still think, that we will need some glossy and easy to read pages for the first time visitors...

I do agree here. I just think the contrast of the headlines is to weak (light gray on white with shadows making it even more blury). I played around a bit and came the the conlcusion that changing the headlines to: color: #555555 font-weight: bold and removing the shadow makes it so much easier to read. Give it a try. ;)

have you played with the headline settings?

I personally like the shadowy stuff better. The headline are easier to
read now, but the whole wiki experience has weakened a great deal.

:-(

Mike

--

DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein 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...

Hi Jan,

On Fr 08 Mär 2013 18:54:02 CET Jan Engelhardt wrote:

On Friday 2013-03-08 16:50, Mike Gabriel wrote:

...

Hi all,

I have started a project organigram for X2Go. Feel free to help editing it. http://wiki.x2go.org/doku.php?id=doc:organigram

Jan Engelhard (X2Go for RPM-based distros)

-rdt seems so hard for many ;-(

(It's really my employer who wants the RPMs..)

I am sorry. Please fix your name and add your employer here: http://wiki.x2go.org/doku.php?id=doc:sponsors

Thanks! Mike

--

DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein 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...

Hi Oliver,

On Di 12 Mär 2013 09:56:42 CET Oliver Burger wrote:

2013/3/8 Jan Engelhardt <jengelh@inai.de>:

...

On Friday 2013-03-08 16:50, Mike Gabriel wrote:

...

Jan Engelhard (X2Go for RPM-based distros)

Wouldn't it be better to let the distros provide their packages? After all that's what distros are there for, aren't they? Of course it's nice for an end user, when his distro does not provide a package and the upstream project provides it, but from a distro packager perspective, it's bad, since

I can only speak for Debian. At the time of writing I do not see a
chance to get nx-libs (full) into Debian due to this outdated X.org
tree that is behind it. So, for Debian systems, we have to provide
packages by upstream.

Differently for Ubuntu. X2Go Server & co. could be in Ubuntu, however,
so far I have not bothered.

Another reason for providing packages by upstream is: give the users
the opportunity to retrieve latest releases for their favourite distro.

• you will necver know about conflicts between third party packages and those provided by the distro itself.

Unless you know the distro you package for outside the distro really
well. I am about to become a Debian Developer (only thing left is the
account creation on the Debian infrastructure), so I am pretty much
involved in that anyway.

• it's kind of hard to provide universal rpm packages, as the naming shema of libraries and other needed packages does vary quite a lot

I have no clue at all about RPM. Others have to comment on this.

• people will always complain to the distro's bug tracker and triaging teams have much fun explaining to those, that it's not the distro's fault as the packages in use are not provided by the distro

With Debian, you can only report bugs to packages that exist in
Debian. The described experience I do not have here.

Greets, Mike

--

DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein 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...

Hi Oliver,

On Di 12 Mär 2013 10:27:27 CET Oliver Burger wrote:

2013/3/12 Mike Gabriel <mike.gabriel@das-netzwerkteam.de>:

...

I have no clue at all about RPM. Others have to comment on this.

The problem is, that while (at least almost) all deb-based distros are really Debian-based distros and thus their base systems are quite similar to each other, rpm-based distros aren't. Of course there are similarities between openSUSE, Fedora, Mageia and so on, but there are quite some differences as well. All of those distros use rpm as a package format, but not all are RedHat-based and even those who are (like Mageia by way of Mandrake and Mandriva), they split up so early, that they moved apart.

Yes, that is surely a different thing with RPM based distros. Fully
agreed here.

So for those distros that do provide packages, wouldn't it be better to talk to the package maintainers there and ask them to provide up to date distro specific packages for their distro, when a new x2go version is released? They would still have to be hosted as third party packages since most distros don't allow for version upgrades during the release cycle of a distro, but at least, the problem of having conflicts would be minimized...

That's what I normally do with Debian (not much so far actually, but
it is the plan). Once Debian wheezy is out, I plan (not only for X2Go)
to provide new versions uploaded to Debian unstable->testing with a
little delay in wheezy-backports, so users have a chance to get latest
code via backports for already released stable distro versions.

...

...

• people will always complain to the distro's bug tracker and triaging teams have much fun explaining to those, that it's not the distro's fault as the packages in use are not provided by the distro

With Debian, you can only report bugs to packages that exist in Debian. The described experience I do not have here.

Well I have, as in Mageia's bugzilla, you can open a bug report without providing the source rpm package against which the bug report should be opened.

Oh! Please make sure your X2Go related distro bug reports reach us. In
Debian packaging there are many upstream bugs reported in Debian BTS
(not for x2goclient nor pyhoca-* at the moment, though). As package
maintainer you have the duty to forward bug reports upstream whenever
you consider it an upstream problem. We cannot improve X2Go without
this workflow from the distributions (and we will neither look into
all distros' bug trackers!!!).

Thanks+Greets, Mike

--

DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein 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...

2013/3/12 Jan Engelhardt <jengelh@inai.de>:

On Tuesday 2013-03-12 09:56, Oliver Burger wrote:

...

2013/3/8 Jan Engelhardt <jengelh@inai.de>:

...

On Friday 2013-03-08 16:50, Mike Gabriel wrote:

...

Jan Engelhard[t] (X2Go for RPM-based distros)

Wouldn't it be better to let the distros provide their packages? After all that's what distros are there for, aren't they?

Yes, distros exist to do NIH [they will write the spec from scratch again] :)

Are you involved with any distro so you can say that? And let's see whose spec is older and who did write it from scrath again... My first x2go packages date back to 2008 and were actually not written from scratch but based on ALT Linux packages that were already there. And yours?

...

Of course it's nice for an end user, when his distro does not provide a package and the upstream project provides it, but from a distro packager perspective, it's bad, since

• you will necver know about conflicts between third party packages and those provided by the distro itself.

This point is valid.

...

• it's kind of hard to provide universal rpm packages, as the naming shema of libraries and other needed packages does vary quite a lot

For libraries, it is not a problem, because their names are not used at all, but RPM-ELF dependencies. And the latter are the same across all RPM-using distros.

About the names of non-library packages: not a problem either, as we can just make a %if that, then that, %else that, %endif. For each and every distro?

-- obgr_seneca aka Oliver Burger Mageia.Org

i18n team leader doc team deputy leader secretary of the Association

Mageia council Mageia board

2013/3/12 Moritz Struebe <Moritz.Struebe@informatik.uni-erlangen.de>:

Ok, I followed this only biefly, but is this a fight who is allowed to package X2Go? IMO if we can (in terms of manpower) package for a distro upstream that is good. If we have a packager downstream the better. After all that person is free to adjust the upstream packing to his/her likes or provide patches to the upstram packaging to make his/her life easier.

Or did I miss the point.

Well, of course anyone may package any software for any OS as long as the license allows to do so.

Perhaps my point didn't come across. My point is, I'm just not a fan of third party packages. I've seen to much bad ones as I went along and I've seen too much Windows style "let's download software from some site in the web and try to install it somehow", that is just not the way it works using GNU/Linux. Of course it is nice, when upstream projects do package their stuff and I'm always basing my distro packages on the upstream srpms, if they are available and if they are not crap (which I've seen as well over the years). My problem is the "rpm-based distros" part. As I see it, packaging for any and all rpm based distros at the same time is just not possible. Of course you can package for some of them at the same time using OBS, but then you will just have some rpm packages and you should note that somewhere. The way user's minds work is "There is a rpm package, I can't install it on my distro, so that distro must have some serious problems", even if the problem is just the package was not built for that distro...

2013/3/12 Moritz Struebe <Moritz.Struebe@informatik.uni-erlangen.de>:

...

My problem is the "rpm-based distros" part. As I see it, packaging for any and all rpm based distros at the same time is just not possible. Of course you can package for some of them at the same time using OBS, but then you will just have some rpm packages and you should note that somewhere. The way user's minds work is "There is a rpm package, I can't install it on my distro, so that distro must have some serious problems", even if the problem is just the package was not built for that distro...

---

Ok, so what is your suggestion? Do not provide no packages at all. Add a big red warning? Try to find packagers for those (are you volunteering?).

I personally prefer the latter two. ;)

Yes, I am. If you are interested in Mageia packages... For me it would just mean rebuilding my packages for the stable releases and make sure not to break anything by doing so.

As for other distros, we will just have to find the package maintainers...

Oliver

On Di 12 Mär 2013 13:09:36 CET Jan Engelhardt wrote:

There was no spec inside nx-libs.tar.gz, so I can in good faith claim "there was none" :-) And since the nx-libs compile procedure seems to change every other release, it would be out of date rather soon.

The goal is to have something that does not change regularly. The last
changes (3.5.0.16 -> 3.5.0.17) were necessary to ease code maintenance
in the quilt patch system.

So don't get too frustrated, will try to become better!

Mike

--

DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein 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...