freenx-team team mailing list archive

[Per Hansen <spamhans@xxxxxxxx>]

Which emailclients do you use, it produces silly HTML-Code and bad quotes!
For a mailing-list it would be better to just send plain-text and insert
a empty line between quote and own text!

Marcelo Boveto Shima wrote:
>> What are the "outside packages" that Per uses?  I always have to repackage
>> a new tarball when a new version comes out in order to obtain all current NX
>> sources, but it may make more sense to divide the packaging to keep in line
>> with the way NX packages their sources if that's even possible.  If only the
>> packages weren't so interdependant this would be easier.

Cross-depends forces Marcelo and me to make a big (20MiB) nx_*.orig.tar.gz

> I do agree that we should use modified lib names as per Debian standards (at
>> least partial standard).  This reduces conflicts with existing libs at
>> least.

Only if the lib exists on debian or ubuntu.
We do not need a libnxonly-nx.so but we could need a libc-nx.so
(if a modified version of libc would be used by nx)

>> I think the version suffix makes sense for now and since we are
>> looking at cross dist building it may make better sense not to tag with
>> ubuntu so:

I think we should use
-0freenx1
-0freenx2
-0freenx3
for team releases

And we should use "-0freenx1username1" if we build a package based on
"-0freenx1" on our ppa!

NMUs would use
-0.1
-0.2
-0.3
But since we are Maintainers, we do not make NMUs...

NMU version numbering:
http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-nmu-version

Packaging tips for unofficial Debian packages:
http://people.debian.org/~calvin/unofficial/

>> We haven't discussed forums, [...]  Also, that forum is easy to find
>> on google for anyone searching for answers.

I think there are enough forums.
We should do a wiki if informations/howtos need to be written down.

> The packages code are hosted at launchpad and every member of the team has
> write permission
> to them. Another way is to post here your patches.

Small good changes should be directly committed to the bazaar main trunk.
If you are unsure or doing big changes, you should open a new branch and
which should be merged later.
The VCS is there to avoid emailing patches around.
We can always revert bad commits...

>> Finally, I have a patch for nxviewer_helper to assist console access and
>> desktop sharing (access to physical desktop).  The current nxviewer_helper
>> doesn't work with the x11vnc included with Debian/Ubuntu for local
>> X0,X1,etc. displays, but the patch makes local display references truly
>> local (:0.0, :1.0, :1000.0) instead of referring by loopback IP 127.0.0.1:0.0
>> which doesn't work.

Does that mean there are x11vnc-versions out there which works?

Can Debians x11vnc be fixed?

Are there any drawbacks in making them "truly local"?


Greets
Per