Re: Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries

[Alexander Wirt]

brian m. carlson schrieb am Friday, den 13. January 2012:

> On Fri, Jan 13, 2012 at 12:57:37AM +0100, Mike Gabriel wrote:
> > On Fr 13 Jan 2012 00:37:57 CET Stefan Lippers-Hollmann wrote:
> > >forked monolithic X.org 6.9 source tree.
> > 
> > This is indeed the case.
> 
> I can't speak for the ftpmasters and Security Team, but honestly I can't
> see why they would allow this in the archive or in any stable release,
> respectively.
Indeed, we had this discussions a few years ago where I started the NX
packaging group. NX in its current state with the embedded code copys won't
be accepted by ftpmasters. That was stated clearly.

Alex


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120113075517.gd4...@smithers.snow-crash.org

Re: Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries

[Mike Gabriel]

Hi Alex,

On Fr 13 Jan 2012 08:55:17 CET Alexander Wirt wrote:


brian m. carlson schrieb am Friday, den 13. January 2012:


On Fri, Jan 13, 2012 at 12:57:37AM +0100, Mike Gabriel wrote:
> On Fr 13 Jan 2012 00:37:57 CET Stefan Lippers-Hollmann wrote:
> >forked monolithic X.org 6.9 source tree.
>
> This is indeed the case.

I can't speak for the ftpmasters and Security Team, but honestly I can't
see why they would allow this in the archive or in any stable release,
respectively.

Indeed, we had this discussions a few years ago where I started the NX
packaging group. NX in its current state with the embedded code copys won't
be accepted by ftpmasters. That was stated clearly.

Alex


Is that the code in nx-X11/extras? Or the full nx-X11 tree?

Note that we have tested loads of different build variants against  
Xorg 7. The highest stability (which is virtually no session crashes  
anymore) we ever achieved is by the way we currently build the code as  
one monolith.


Thanks,
Mike


--

DAS-NETZWERKTEAM
mike gabriel, dorfstr. 27, 24245 barmissen
fon: +49 (4302) 281418, fax: +49 (4302) 281419

GnuPG Key ID 0xB588399B
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


pgpzJQG2uE9Zt.pgp
Description: Digitale PGP-Unterschrift

Re: [Pkg-x2go-devel] Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries

[Paul van der Vlis]

Op 13-01-12 02:22, John A. Sullivan III schreef:

> As SPICE improves, I think we should consider it
> seriously.  Its cross platform support is very good which would no
> longer limit X2Go server to Windows only and the idea of an adaptive
> protocol is absolutely intriguing.  I long for the day we can
> realistically do video playing on the virtual desktop across a WAN.

X2go-server is not Windows-only, it even does not run on Windows.
Not sure what you want to say.

With regards,
Paul.

-- 
Paul van der Vlis Linux systeembeheer, Groningen
http://www.vandervlis.nl


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f0feb91.8030...@vandervlis.nl

Re: Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries

[Alexander Wirt]

Mike Gabriel schrieb am Freitag, den 13. Januar 2012:

> Hi Alex,
> 
> On Fr 13 Jan 2012 08:55:17 CET Alexander Wirt wrote:
> 
> >brian m. carlson schrieb am Friday, den 13. January 2012:
> >
> >>On Fri, Jan 13, 2012 at 12:57:37AM +0100, Mike Gabriel wrote:
> >>> On Fr 13 Jan 2012 00:37:57 CET Stefan Lippers-Hollmann wrote:
> >>> >forked monolithic X.org 6.9 source tree.
> >>>
> >>> This is indeed the case.
> >>
> >>I can't speak for the ftpmasters and Security Team, but honestly I can't
> >>see why they would allow this in the archive or in any stable release,
> >>respectively.
> >Indeed, we had this discussions a few years ago where I started the NX
> >packaging group. NX in its current state with the embedded code copys won't
> >be accepted by ftpmasters. That was stated clearly.
> >
> >Alex
> 
> Is that the code in nx-X11/extras? Or the full nx-X11 tree?
the latter. afair the first didn't existed to that time.
> 
> Note that we have tested loads of different build variants against
> Xorg 7. The highest stability (which is virtually no session crashes
> anymore) we ever achieved is by the way we currently build the code
> as one monolith.
This is not about stability. It is about being able to distribute it.
ftpmasters already said "no" to nx and I don't think anything changed since
then.

Alex
-- 
Alexander Wirt, formo...@formorer.de 
CC99 2DDD D39E 75B0 B0AA  B25C D35B BC99 BC7D 020A


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120113090028.ga8...@hawking.credativ.lan

Re: [Pkg-x2go-devel] Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries

[Mike Gabriel]

Hi Paul, hi John,

On Fr 13 Jan 2012 09:30:09 CET Paul van der Vlis wrote:


Op 13-01-12 02:22, John A. Sullivan III schreef:


As SPICE improves, I think we should consider it
seriously.  Its cross platform support is very good which would no
longer limit X2Go server to Windows only and the idea of an adaptive
protocol is absolutely intriguing.  I long for the day we can
realistically do video playing on the virtual desktop across a WAN.


X2go-server is not Windows-only, it even does not run on Windows.
Not sure what you want to say.


Note: we tend to get off-topic here. This thread is about packaging  
X2Go server / NX-libs for Debian. Please note by the To:/Cc: field,  
how many lists/people are involved in this discussion.


Let us discuss X2Go (upstream) issues on x2go-...@lists.berlios.de and  
open a new thread on this topic there if you feel like it.


Thanks,
Mike




--

DAS-NETZWERKTEAM
mike gabriel, dorfstr. 27, 24245 barmissen
fon: +49 (4302) 281418, fax: +49 (4302) 281419

GnuPG Key ID 0xB588399B
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


pgp760bdZlNCu.pgp
Description: Digitale PGP-Unterschrift

Re: Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries

[Mike Gabriel]

Hi Alex,

On Fr 13 Jan 2012 10:00:29 CET Alexander Wirt wrote:


Note that we have tested loads of different build variants against
Xorg 7. The highest stability (which is virtually no session crashes
anymore) we ever achieved is by the way we currently build the code
as one monolith.

This is not about stability. It is about being able to distribute it.
ftpmasters already said "no" to nx and I don't think anything changed since
then.


Yes, got that completely! And: I am searching for a new realm of  
possiblities here. Somehow some non-Debian binaries made it into  
Debian (by external download), for example. What new ways can be  
possible here is my question?


Mike


--

DAS-NETZWERKTEAM
mike gabriel, dorfstr. 27, 24245 barmissen
fon: +49 (4302) 281418, fax: +49 (4302) 281419

GnuPG Key ID 0xB588399B
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


pgpwPcm23M7si.pgp
Description: Digitale PGP-Unterschrift

Re: [Pkg-x2go-devel] Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries

[Reinhard Tartler]

clone 655618 -1
retitle 655618 ITP: nx-libs-light --- NX Protocol client-only libraries and 
binaries
retitle -1 ITP: nx-libs --- NX Protocol client/server libraries and binaries
stop

On Fr, Jan 13, 2012 at 10:20:15 (CET), Mike Gabriel wrote:

> Hi Paul, hi John,
>
> On Fr 13 Jan 2012 09:30:09 CET Paul van der Vlis wrote:
>
>> Op 13-01-12 02:22, John A. Sullivan III schreef:
>>
>>> As SPICE improves, I think we should consider it
>>> seriously.  Its cross platform support is very good which would no
>>> longer limit X2Go server to Windows only and the idea of an adaptive
>>> protocol is absolutely intriguing.  I long for the day we can
>>> realistically do video playing on the virtual desktop across a WAN.
>>
>> X2go-server is not Windows-only, it even does not run on Windows.
>> Not sure what you want to say.
>
> Note: we tend to get off-topic here. This thread is about packaging
> X2Go server / NX-libs for Debian. Please note by the To:/Cc: field,  how
> many lists/people are involved in this discussion.

I think the recipient list is appropriate. It includes everyone that
should discuss the inclusion of this software into the Debian Archive.

As some people raised concerns about including the x2go server into
Debian, I'm there splitting this ITP into two parts, following to the
way x2go provides its sources: At
http://code.x2go.org/releases/source/nx-libs/ two tarballs of nx-libs
are provided: one called 'lite' and one called 'full'. AFAIUI, the
'lite' tarball is a true subset of the 'full' tarball containing only
the parts that are relevant for building the client parts of the NX
stack. This is what bug #655618 is about from now on. The package is
being prepared at
http://anonscm.debian.org/gitweb/?p=collab-maint/x2go/nx-libs.git;a=tree
and, from what I see, is appropriate for being uploaded to unstable. For
clarity, I think we should rename the git repository from nx-libs.git to
nx-libs-light.git. Mike, can you please handle that?

For further discussion of the server parts (called "agent" in NX lingo),
which AFAIUI is a heavily patched fork of the old XNest codebase linked
against the Nomachine NX protocol libraries, please use the cloned bug.
I agree that without the blessing of the release team the security team,
it shouldn't go into unstable (or wheezy), but if the ftp-masters agree,
then I think it could go into experimental, so that interested parties
can start to have another serious look at it. If the project decides
that the server becomes suitable for inclusion into unstable, it will
then replace the 'nx-libs-light' package.

As I understand from Mike's other posting in this thread, there are
people looking at porting the agent to a newer codebase. But this is a
rarther long-term option. As are the suggestions to port x2go to SPICE.

As for the concerns with Nomachine, while it is true that NX 4.0 is no
longer GPL licensed, the 3.x codebase has seen updates, which maintain
its previous license, the GPLv3. I take this as indication that
Nomachine still has an interest in maintaining the 3.x codebase, which
included security fixes in the latest releases.

Cheers,
Reinhard

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/87ty3zc2sb@faui43f.informatik.uni-erlangen.de

Re: [Pkg-x2go-devel] Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries

[Mike Gabriel]

Hi Reinhard, dear all,

On Fr 13 Jan 2012 11:31:00 CET Reinhard Tartler wrote:


http://anonscm.debian.org/gitweb/?p=collab-maint/x2go/nx-libs.git;a=tree
and, from what I see, is appropriate for being uploaded to unstable. For
clarity, I think we should rename the git repository from nx-libs.git to
nx-libs-light.git. Mike, can you please handle that?


Renamed!
http://anonscm.debian.org/gitweb/?p=collab-maint/x2go/nx-libs-lite.git;a=tree


As I understand from Mike's other posting in this thread, there are
people looking at porting the agent to a newer codebase. But this is a
rarther long-term option. As are the suggestions to port x2go to SPICE.


Yes, we have still a casual but a discussion with an Austrian company  
that is heavily interested to provide some new NX'ish or similar  
technology. Very casual still, but yes.



As for the concerns with Nomachine, while it is true that NX 4.0 is no
longer GPL licensed, the 3.x codebase has seen updates, which maintain
its previous license, the GPLv3. I take this as indication that
Nomachine still has an interest in maintaining the 3.x codebase, which
included security fixes in the latest releases.


I have also had NoMachine contact before X-mas 2011 and they said that  
they would take a look at our patches. I have to update them about the  
location changes as they got informed about the Alioth Git. I will  
point then to X2Go Git now.


We (i.e. Alex from X2GO) also have just added a xinerama patch to NX. ;-)

From now on... using this ITP for client-only discussions.

Mike



--

DAS-NETZWERKTEAM
mike gabriel, dorfstr. 27, 24245 barmissen
fon: +49 (4302) 281418, fax: +49 (4302) 281419

GnuPG Key ID 0xB588399B
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


pgpZ7bmgPXh6C.pgp
Description: Digitale PGP-Unterschrift

Re: Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries

[Thomas Goirand]

On 01/13/2012 05:23 PM, Mike Gabriel wrote:
> Hi Alex,
>
> On Fr 13 Jan 2012 10:00:29 CET Alexander Wirt wrote:
>
>>> Note that we have tested loads of different build variants against
>>> Xorg 7. The highest stability (which is virtually no session crashes
>>> anymore) we ever achieved is by the way we currently build the code
>>> as one monolith.
>> This is not about stability. It is about being able to distribute it.
>> ftpmasters already said "no" to nx and I don't think anything changed
>> since
>> then.
>
> Yes, got that completely! And: I am searching for a new realm of
> possiblities here. Somehow some non-Debian binaries made it into
> Debian (by external download), for example. What new ways can be
> possible here is my question?
>
> Mike
>
>
If I may ask...
Why isn't the NX development made directly into Xorg?

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f101118.6020...@debian.org

Re: Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries

[Mike Gabriel]

Hi Thomas,

On Fr 13 Jan 2012 12:10:16 CET Thomas Goirand wrote:


On 01/13/2012 05:23 PM, Mike Gabriel wrote:

Hi Alex,

On Fr 13 Jan 2012 10:00:29 CET Alexander Wirt wrote:


Note that we have tested loads of different build variants against
Xorg 7. The highest stability (which is virtually no session crashes
anymore) we ever achieved is by the way we currently build the code
as one monolith.

This is not about stability. It is about being able to distribute it.
ftpmasters already said "no" to nx and I don't think anything changed
since
then.


Yes, got that completely! And: I am searching for a new realm of
possiblities here. Somehow some non-Debian binaries made it into
Debian (by external download), for example. What new ways can be
possible here is my question?

Mike



If I may ask...
Why isn't the NX development made directly into Xorg?

Thomas


That would have been optimal, indeed. I can only guess here...

For business development supporting free projects (that is:  
generically contributing to Xorg 6.9 when it was the newest stuff  
around, in the old days) takes a much greater amount of time and  
effort (and money) which not always works out for business models.


Esp. generic development and continuous maintenance needs idealism  
that some development businesses may have, some may not. In case of  
NX, NoMachine took the Xorg tree, made a very nice peace of software  
out of it but lacked community re-integration. This is nothing bad,  
this is normal for business strategies... But it lacks long-term  
sustainability. And in the Xorg community no one was interested in  
upstream integration either.


There are loads of other projects around that stumble over the same  
point... and fall... and vanish in the long run...


Everything in this mail is just a guess, things in reality have very  
probably been completely different.



Thanks for asking,
Mike



--

DAS-NETZWERKTEAM
mike gabriel, dorfstr. 27, 24245 barmissen
fon: +49 (4302) 281418, fax: +49 (4302) 281419

GnuPG Key ID 0xB588399B
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


pgpQeYVm5VQ8u.pgp
Description: Digitale PGP-Unterschrift

Re: [Pkg-x2go-devel] Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries

[Mike Gabriel]

Hi Reinhard, hi all,

On Fr 13 Jan 2012 11:31:00 CET Reinhard Tartler wrote:


clone 655618 -1
retitle 655618 ITP: nx-libs-light --- NX Protocol client-only  
libraries and binaries

retitle -1 ITP: nx-libs --- NX Protocol client/server libraries and binaries
stop


Once you know the BTS no. of the clone ITP, please send it to all, so  
that we know where to contribute more input to.


Thanks,
Mike (who openend the BTS issues for wnpp and waited for ages...)

--

DAS-NETZWERKTEAM
mike gabriel, dorfstr. 27, 24245 barmissen
fon: +49 (4302) 281418, fax: +49 (4302) 281419

GnuPG Key ID 0xB588399B
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


pgpq6iAj8MmOB.pgp
Description: Digitale PGP-Unterschrift

Re: Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries

[Philip Hands]

On Fri, 13 Jan 2012 12:35:30 +0100, Mike Gabriel 
 wrote:
...
> Everything in this mail is just a guess, things in reality have very  
> probably been completely different.

Yes, having talked to the lead developer on NX _years_ ago (2003 IIRC),
he spent quite some time trying to persuade the X folks that he had ways
of getting rid of (largely pointless) round-trips and the like.  He said
that having his contributions consistently rejected drove him to
distraction.

Of course, he is (or was at the time) a fairly volatile Italian, so
perhaps there was simply a clash of cultures, but he claimed that he
setup NX out of exasperation, rather than because he wanted to keep it
seperate from X.

Then again, this was before xorg, so perhaps integration into X is now a
possibility, but I have a feeling that that ship sailed long ago.

Cheers, Phil.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/
|-|  HANDS.COM Ltd.http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND


pgpPrh7mwGdb6.pgp
Description: PGP signature

Re: Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries

[Mike Gabriel]

Hi Phil,

On Fr 13 Jan 2012 12:50:37 CET Philip Hands wrote:

On Fri, 13 Jan 2012 12:35:30 +0100, Mike Gabriel  
 wrote:

...

Everything in this mail is just a guess, things in reality have very
probably been completely different.


Yes, having talked to the lead developer on NX _years_ ago (2003 IIRC),
he spent quite some time trying to persuade the X folks that he had ways
of getting rid of (largely pointless) round-trips and the like.  He said
that having his contributions consistently rejected drove him to
distraction.

Of course, he is (or was at the time) a fairly volatile Italian, so
perhaps there was simply a clash of cultures, but he claimed that he
setup NX out of exasperation, rather than because he wanted to keep it
seperate from X.

Then again, this was before xorg, so perhaps integration into X is now a
possibility, but I have a feeling that that ship sailed long ago.

Cheers, Phil.


Glad you could provide this bit of information! Thanks!

Mike


--

DAS-NETZWERKTEAM
mike gabriel, dorfstr. 27, 24245 barmissen
fon: +49 (4302) 281418, fax: +49 (4302) 281419

GnuPG Key ID 0xB588399B
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


pgplrcIiI2tJy.pgp
Description: Digitale PGP-Unterschrift

Bug#655712: ITP: template -- environment variable expander | simple template tool

[Michael Stummvoll]

Package: wnpp
Severity: wishlist
Owner: Michael Stummvoll 

I'm planning to upload this new package through a sponsor

* Package name: template
  Version : 0.1
  Upstream Author : Michael Stummvoll 
* URL : http://stuff.stummi.org/template.html
* License : GPL
  Programming Lang: C
  Description : environment variable expander and simple template tool

template is a very simple tool that reads from stdin, expands variables in the 
form ${FOO} to its according environment variables and prints this to stdout.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120113124058.21344.40361.reportbug@mysite

Re: Outstanding /dev/.udev bugs for /run migration

[Michael Tokarev]

On 13.01.2012 03:18, Roger Leigh wrote:
[]
> All are currently broken.  Whether they cause severe breakage depends
> upon the individual case.  Some are working apparently OK, e.g.
> mdadm.  Others are doing broken things to try and create device nodes

For mdadm an upstream patch is needed.  I already removed all refs to
/dev/.udev from surrounding scripts and plan to patch remaining bit
in the source.  It will still use /dev/.udev to be able to work on
older systems but will check both it and /run/udev.  FWIW.  I'd love
to assume udev is always present but for mdadm it is not a good idea
since it may be called in initramfs without udev or when udev is
somehow broken, and mdadm needs to be functioning regardless.
Besides, when mdadm detects lack of udev it merely creates /dev/md*
nodes itself, which does not do any (visible) harm - udev just
re-creates them.

This missing bit is why I didn't close the bug in question when
did initial changes (#627774 and #644319).

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f102b42.6040...@msgid.tls.msk.ru

Re: Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries

[Andreas Tille]

Hi,

On Fri, Jan 13, 2012 at 08:39:02AM +0100, Mike Gabriel wrote:
> And still, my basic (inner and outer) question is:
> 
>  1. how can we enrol other people with our endeavour
>  2. what is needed to enrol people
>  3. is there anyonr in this discussion who can point us to next possible steps
> towards acceptance of the packages

I remember I had looked into one of the first attempts to package NX
(back in 2003 or so, don't remember - never came to any relevant
result).  Since then I wonder whether somebody has really tried to
work out the following two questions:

  1. Did anybody *really* *honestly* tried to base NX protocol
 on plain X libraries?  If this is not possible
  2. Did anybody *really* *honestly* tried to push NC protocol
 into upstream X?

In other words:  Is this whole "copy of outdated X libs" issue just a
communication problem between two groups of coders?

Kind regards

Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120113135729.ge3...@an3as.eu

Re: Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries

[Andreas Tille]

On Fri, Jan 13, 2012 at 11:50:37AM +, Philip Hands wrote:
> Yes, having talked to the lead developer on NX _years_ ago (2003 IIRC),
> he spent quite some time trying to persuade the X folks that he had ways
> of getting rid of (largely pointless) round-trips and the like.  He said
> that having his contributions consistently rejected drove him to
> distraction.
> 
> Of course, he is (or was at the time) a fairly volatile Italian, so
> perhaps there was simply a clash of cultures, but he claimed that he
> setup NX out of exasperation, rather than because he wanted to keep it
> seperate from X.
> 
> Then again, this was before xorg, so perhaps integration into X is now a
> possibility, but I have a feeling that that ship sailed long ago.

Thanks for the explanation.  What about building a new ship (= try
again with xorg).  Not that I personally would do this which makes my
remark pretty useless.  Just for the sake of interest.

Kind regards

   Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120113140132.gf3...@an3as.eu

Re: [Pkg-x2go-devel] Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries

[Josselin Mouette]

Le jeudi 12 janvier 2012 à 20:22 -0500, John A. Sullivan III a écrit : 
> I am very concerned about the old X code, too and we are actively
> watching SPICE.  SPICE has extraordinary potential but it is still
> slower than NX on WAN links - not much but enough to make a user
> noticeable difference.

I am surprised NX is even considered for WAN usage. Our in-house tests
showed that NX has a noticeable usability impact as soon as the latency
reaches 10ms, while the figure goes up to 30ms for VNC - which is
currently the only serious solution for WAN links.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1326463427.3223.29.camel@pi0307572

Re: Bug#655712: ITP: template -- environment variable expander | simple template tool

[Steve McIntyre]

On Fri, Jan 13, 2012 at 02:55:06PM +0100, Michael Stummvoll wrote:
>On 13.01.2012 14:52, Steve McIntyre wrote:
>>Why do we need this? Does it need to be a separate package for a
>>very simple utility program?
>do you think it has better chances to get in a package like moreutils
>instead of as own?

That would be a better place, yes. But:

 * There's no license statement anywhere in the code or accompanying
   files

 * I don't really see how this program is more useful than a very
   simple shell (or perl, or python, or ...) loop to do the same
   thing.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Since phone messaging became popular, the young generation has lost the
 ability to read or write anything that is longer than one hundred and sixty
 characters."  -- Ignatios Souvatzis


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120113140554.gb19...@einval.com

Re: Bug#655712: ITP: template -- environment variable expander | simple template tool

[Steve McIntyre]

Michael Stummvoll wrote:
>Package: wnpp
>Severity: wishlist
>Owner: Michael Stummvoll 
>
>I'm planning to upload this new package through a sponsor
>
>* Package name: template
>  Version : 0.1
>  Upstream Author : Michael Stummvoll 
>* URL : http://stuff.stummi.org/template.html
>* License : GPL
>  Programming Lang: C
>  Description : environment variable expander and simple template tool
>
>template is a very simple tool that reads from stdin, expands variables in the 
>form ${FOO} to its according environment
>variables and prints this to stdout.

Why do we need this? Does it need to be a separate package for a very
simple utility program?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Because heaters aren't purple!" -- Catherine Pitt


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1rlhyi-0004qa...@mail.einval.com

Re: Outstanding /dev/.udev bugs for /run migration

[Roger Leigh]

On Fri, Jan 13, 2012 at 05:01:54PM +0400, Michael Tokarev wrote:
> On 13.01.2012 03:18, Roger Leigh wrote:
> []
> > All are currently broken.  Whether they cause severe breakage depends
> > upon the individual case.  Some are working apparently OK, e.g.
> > mdadm.  Others are doing broken things to try and create device nodes
> 
> For mdadm an upstream patch is needed.  I already removed all refs to
> /dev/.udev from surrounding scripts and plan to patch remaining bit
> in the source.  It will still use /dev/.udev to be able to work on
> older systems but will check both it and /run/udev.  FWIW.  I'd love
> to assume udev is always present but for mdadm it is not a good idea
> since it may be called in initramfs without udev or when udev is
> somehow broken, and mdadm needs to be functioning regardless.
> Besides, when mdadm detects lack of udev it merely creates /dev/md*
> nodes itself, which does not do any (visible) harm - udev just
> re-creates them.
> 
> This missing bit is why I didn't close the bug in question when
> did initial changes (#627774 and #644319).

Cool, thanks for doing that.  I'll go through each of the bugs in
detail for each affected package to determine if it's just for backward
compatibility, or if it does need to support /run in addition.
Probably next week sometime.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120113142730.gn9...@codelibre.net

Re: Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries

[Reinhard Tartler]

On Fr, Jan 13, 2012 at 12:10:16 (CET), Thomas Goirand wrote:

> On 01/13/2012 05:23 PM, Mike Gabriel wrote:
>> Hi Alex,
>>
>> On Fr 13 Jan 2012 10:00:29 CET Alexander Wirt wrote:
>>
 Note that we have tested loads of different build variants against
 Xorg 7. The highest stability (which is virtually no session crashes
 anymore) we ever achieved is by the way we currently build the code
 as one monolith.
>>> This is not about stability. It is about being able to distribute it.
>>> ftpmasters already said "no" to nx and I don't think anything changed
>>> since
>>> then.
>>
>> Yes, got that completely! And: I am searching for a new realm of
>> possiblities here. Somehow some non-Debian binaries made it into
>> Debian (by external download), for example. What new ways can be
>> possible here is my question?
>>
>> Mike
>>
>>
> If I may ask...
> Why isn't the NX development made directly into Xorg?

That would have been clever. However, the choice of the license, the
GPL, makes code-sharing impossible.


-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/87zkdracsv@faui43f.informatik.uni-erlangen.de

Bug#655723: ITP: stapler-adjunct-codemirror -- Codemirror javascript library for use with the stapler HTTP request handling engine

[James Page]

Package: wnpp
Severity: wishlist
Owner: James Page 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: stapler-adjunct-codemirror
  Version : 1.1
* URL : http://github.com/stapler/stapler-adjunct-codemirror
* License : MIR
  Programming Lang: Java/JavaScript
  Description : Codemirror javascript library for use with the stapler HTTP 
request handling engine

 This library provides a JavaScript based codemirror source code visualisation
 component for embedding in web applications using the stapler HTTP request 
 handling engine.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIbBAEBCAAGBQJPEEUMAAoJEL/srsug59jDMBEP93NBmoy+XyFVVDgCGxvlQDT9
8WzTPC4hqeEfiC5H40y1/XnRwMNB9IH1/8/jDr3BgYDc2NTErFuN65Hfja84aWA3
uYxITyx1eyRJL5jQtm0wB0FD+5ELThL1xf3m7HjSaM6Gcg61jSUuxnUHpxL80bu8
TZMHm9vNTPL10MKPXPLbVHjT0/Lc6GA+l5ZV+MCIOSsBTEt6W4CK2fXz53Ujo7HS
GuL6h+n71sZJrdQmQrKg0L2fffNwZoOWc3SMF4GECf7jDEO8MYbMA1pI7InHY5Pp
eJI+LstmLV1TbEvj+MlPPMhvN6asZ2LkBEJLwpRMlXx+s195AfOzW1a970wYhTkj
05feKcp02HmFgB6rSagvV9je8LM5xiQR41q3IwQOMor8EZJ9HNZGnAHUHzskp7YP
Iu8qyQjv5lb/bOb/48kxhjbp4p9Z8Km2ZakNiJ69u9dRVm7QWH8p/TJToAEClqnW
/pgBeJMcfhggMnLNBXFux5fQrPzrLX45LjZ4tmweaAZ9E7HIPgwCTK54htrgQbki
IlbzZ9sUR4UD59EqY+FGVtfzUuhJK2KnBYDBRfkjH8y445oM8pF/SokDw09CA/FL
2RO+JBVdpB/7eCMY1FhxtDdB7M0lyHP7ozW+EJLmf1FonQYHK8vzm5Vj1HkEzcc7
8rxqOoUyGaAo8bUZD3s=
=vvA3
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120113145159.6494.73027.reportbug@hendrix.shouse.local

Re: [Pkg-x2go-devel] Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries

[John A. Sullivan III]

On Fri, 2012-01-13 at 15:03 +0100, Josselin Mouette wrote:
> Le jeudi 12 janvier 2012 à 20:22 -0500, John A. Sullivan III a écrit : 
> > I am very concerned about the old X code, too and we are actively
> > watching SPICE.  SPICE has extraordinary potential but it is still
> > slower than NX on WAN links - not much but enough to make a user
> > noticeable difference.
> 
> I am surprised NX is even considered for WAN usage. Our in-house tests
> showed that NX has a noticeable usability impact as soon as the latency
> reaches 10ms, while the figure goes up to 30ms for VNC - which is
> currently the only serious solution for WAN links.

Strange - our experience is that NX is quite robust - enduring up to
about 7% packet loss usably (although anything over 2-3% has a
noticeably impact) and working quite nicely with latencies up to 100ms
or more.  It seems orders of magnitude faster than VNC.  In fact, it is
the fastest and most responsive WAN solution we have seen although RDP7
has significantly closed the gap - John


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1326465733.31393.309.ca...@denise.theartistscloset.com

Re: [Pkg-x2go-devel] Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries

[Thomas Goirand]

On 01/13/2012 10:03 PM, Josselin Mouette wrote:
> I am surprised NX is even considered for WAN usage. Our in-house tests
> showed that NX has a noticeable usability impact as soon as the latency
> reaches 10ms, while the figure goes up to 30ms for VNC - which is
> currently the only serious solution for WAN links.
>   
Then maybe you should get out of your house! :)

Seriously, have you ever tried using VNC across continents, with a
*very* slow link? It's simply too slow, it takes ages to display a simple
window.

I really don't understand why you wrote that VNC is more usable
than NX. To me, it's simply never the case.

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f1042f2.70...@debian.org

Re: Bug#655712: ITP: template -- environment variable expander | simple template tool

[Neil Williams]

On Fri, 13 Jan 2012 15:43:03 +0100
Michael Stummvoll  wrote:

> On 13.01.2012 15:36, Neil Williams wrote:
> > $ printenv|grep GDM_LANG|sed -e 's/GDM_LANG=//'
> >
> > #!/bin/sh
> > GLANG=`printenv|grep GDM_LANG|sed -e 's/GDM_LANG=//'`
> > echo $GLANG
> >
> > Why is that hard?
> >
> did you really read and understand what I wrote in the package 
> description and the upstream-website?

Then the description in the ITP needs to be improved.

The point about sed is that sed can substitute whatever you like into
whatever you like - printenv with grep and sed gets the value, then
another grep for the lines that matter and pass those lines to sed. It
really isn't hard.

> I want a tool, that reads (e.g from a file) content like
> 
> "foo ${BAR} blup"
> 
> and replaces ${BAR} here with the environment variable BAR

As Steve pointed out, then all you need is a little perl or other
language loop, not an entirely new package. Maybe it could fit into
moreutils but you'd have to convince those maintainers that it is worth
the effort.

The "problem" being solved is sufficiently trivial, common and varied
that any number of people will have already implemented their own
solutions without needing to add a dependency on another package. I've
probably got four or five slightly different versions hanging around in
various scripts and packages already. The advantage of a local
perl/python loop is that the entire thing is customised to only look
for lines which have 'foo' four characters from the start and not match
on 'bar' etc. Some need to skip blank lines, some need to collate lines
into paragraphs first , some need to handle comments, some don't,
some need to understand the content of the file to know what a comment
is...

Shells can run perl/python snippets as easily as calling anything else.
There's no reason to escalate that to a compiled tool.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpWz5dyE6mHY.pgp
Description: PGP signature

Re: [Pkg-x2go-devel] Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries

[Josselin Mouette]

Le vendredi 13 janvier 2012 à 22:42 +0800, Thomas Goirand a écrit : 
> Seriously, have you ever tried using VNC across continents, with a
> *very* slow link? It's simply too slow, it takes ages to display a simple
> window.

latency != bandwidth
VNC requires more bandwidth, but being asynchronous, it is less
susceptible to latency.

> I really don't understand why you wrote that VNC is more usable
> than NX. To me, it's simply never the case.

Maybe for your usage, yes.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1326467167.3223.42.camel@pi0307572

Re: [Pkg-x2go-devel] Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries

[Michael Hanke]

On Jan 13, 2012 3:59 PM, "Thomas Goirand"  wrote:
>
> On 01/13/2012 10:03 PM, Josselin Mouette wrote:
> > I am surprised NX is even considered for WAN usage. Our in-house tests
> > showed that NX has a noticeable usability impact as soon as the latency
> > reaches 10ms, while the figure goes up to 30ms for VNC - which is
> > currently the only serious solution for WAN links.
> >
> Then maybe you should get out of your house! :)
>
> Seriously, have you ever tried using VNC across continents, with a
> *very* slow link? It's simply too slow, it takes ages to display a simple
> window.
>
> I really don't understand why you wrote that VNC is more usable
> than NX. To me, it's simply never the case.

Hmm, I cannot claim much professional experience, but I am using tigervnc
from europe to access interactive 3d rendering apps on a maschine in the US
and I am quite happy. In fact the display delay is only little more than
the connection latency (about 120ms for me).

Michael

Re: Bug#655723: ITP: stapler-adjunct-codemirror -- Codemirror javascript library for use with the stapler HTTP request handling engine

[Jonas Smedegaard]

On 12-01-13 at 02:51pm, James Page wrote:
> Package: wnpp
> Severity: wishlist
> Owner: James Page 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> * Package name: stapler-adjunct-codemirror
>   Version : 1.1
> * URL : http://github.com/stapler/stapler-adjunct-codemirror
> * License : MIR
>   Programming Lang: Java/JavaScript
>   Description : Codemirror javascript library for use with the stapler 
> HTTP request handling engine
> 
>  This library provides a JavaScript based codemirror source code visualisation
>  component for embedding in web applications using the stapler HTTP request 
>  handling engine.

How is this different from Codemirror itself?

Upstream README.md only has the following:

> This adjunct package contains CodeMirror library with some small 
> modifications.


Codemirror is not yet in Debian as a separate package, but is shipped 
with both piwigo and ipython-notebook, and is a dependency of pending 
librdf-endpoint-perl.

Would be nice if yet another code duplication could be avoided.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries

[Stefan Lippers-Hollmann]

Hi

On Friday 13 January 2012, Andreas Tille wrote:
> Hi,
> 
> On Fri, Jan 13, 2012 at 08:39:02AM +0100, Mike Gabriel wrote:
> > And still, my basic (inner and outer) question is:
> > 
> >  1. how can we enrol other people with our endeavour
> >  2. what is needed to enrol people
> >  3. is there anyonr in this discussion who can point us to next possible 
> > steps
> > towards acceptance of the packages
> 
> I remember I had looked into one of the first attempts to package NX
> (back in 2003 or so, don't remember - never came to any relevant
> result).  Since then I wonder whether somebody has really tried to
> work out the following two questions:
> 
>   1. Did anybody *really* *honestly* tried to base NX protocol
>  on plain X libraries?  If this is not possible

FreeNX upstream tried to rebase them to X.org long time ago and claimed
that it would basically work, however that was (to the best of my 
knowledge) never published.

>   2. Did anybody *really* *honestly* tried to push NC protocol
>  into upstream X?

Not possible for license reasons, NoMachine relicenses the distribution
under the GPL2, which - even though it's license compliant - makes it
(intentionally) inacceptable for upstream X.org; their business model
depends on that.

> In other words:  Is this whole "copy of outdated X libs" issue just a
> communication problem between two groups of coders?

No, it's a very intentional decision to make them the sole contact
for commercial uses.

Regards
Stefan Lippers-Hollmann


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201201131651.12067.s@gmx.de

Re: Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries

[Stefan Lippers-Hollmann]

Hi

On Friday 13 January 2012, Stefan Lippers-Hollmann wrote:
[...]
> >   1. Did anybody *really* *honestly* tried to base NX protocol
> >  on plain X libraries?  If this is not possible
> 
> FreeNX upstream tried to rebase them to X.org long time ago and claimed

This was intended to mean modular X.org 7.0, which would have reduced
the amount of forked sources from >120 MB to something better to 
handle as a starting point (not good enough, but a start).

> that it would basically work, however that was (to the best of my 
> knowledge) never published.

Regards
Stefan Lippers-Hollmann


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201201131658.11455.s@gmx.de

Re: Bug#655723: ITP: stapler-adjunct-codemirror -- Codemirror javascript library for use with the stapler HTTP request handling engine

[James Page]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Jonas

On 13/01/12 16:12, Jonas Smedegaard wrote:
>> This library provides a JavaScript based codemirror source code
>> visualisation
>>> component for embedding in web applications using the stapler
>>> HTTP request handling engine.
> How is this different from Codemirror itself?
> 
> Upstream README.md only has the following:
> 
>>> This adjunct package contains CodeMirror library with some
>>> small modifications.

This package patches and plugs Codemirror into the Java based stapler
HTTP request handling engine; as such its not pure codemirror and is
fixed to a specific version for compatibility.

> 
> Codemirror is not yet in Debian as a separate package, but is
> shipped with both piwigo and ipython-notebook, and is a dependency
> of pending librdf-endpoint-perl.
> 
> Would be nice if yet another code duplication could be avoided.

Agreed (it would be nice is someone could pick this up - I noticed the
RFP); I did this with stapler-adjunct-timeline which picks up the
libjs-timeline package for the actual javascript components; however
this is only a build time dependency; there is not easy way to make
use of the javascript library at runtime due to the way that Java
jar/war's etc... work.

Thanks for the feedback

Cheers

James

- -- 
James Page
Ubuntu Core Developer
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJPEFCzAAoJEL/srsug59jDzJYQAM3+EtUzg/Xggn/71IWJAmZw
NArLI74K7ZA9Mlc4qqV3hZb2TV+7Iz3/O4E1V3ShOxP4mMX5tQQW7b8TMZ8bhdbb
OpzaCdGOVB+u1s5MrLYZSvPDGaaclDszpHlKN179CCuheqe2gILCHqHSXES1sMjz
Warp1O1+o4lyvzWDyLZUKdKITNzDjLMIvX7Q0HPd8x3oSCOi+3QrBMjl6fqdmgjg
ZAWW9Q7DAV6jfL2r1TbqOCel59JipJRZSGJsajaJcxd/ZMNV+H8P577UZ9H4KvSj
LpYPexqG0pCm1IlcIvLfaQ1dgoQseYVDfSTuDr4pPDHabRgWpCzH4bJCdzZ+PltS
c3WOpnNvhxEF2n3s+udC1cRzxNPEC2r0ZHyFSklRMAVhiF1rgNrn+YbfPsMY08Ju
AKtmsaBc1bvjblS228cSXx5hPbrIqLfhL3F3TpvbDR3Ry9rX5GO4ViD6hSfOniMo
R1EbEhBvl3KmlU7F5voCLLokS0qnFW54FYcQcK44LtybcQXOx1F1pxBca2le2fEi
uu22ybSie2qHcNl6ny5kSU5Qs2RFrAiV/8/cKqSkujmgyzURx2IWMaII9AO5mdEa
9hYaaDwm5rHjUcs9cvApUgKYnOnAVMiNLVOsq4UQa3Cw3+Q1kyt2nf2OIYxDBx8L
pLSWGldtpVt2PMvQrnEb
=XH0R
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f1050b3.8070...@ubuntu.com

Re: Bug#655712: ITP: template -- environment variable expander | simple template tool

[Neil Williams]

On Fri, 13 Jan 2012 16:11:50 +0100
Michael Stummvoll  wrote:

> On 13.01.2012 16:00, Neil Williams wrote:
> > The point about sed is that sed can substitute whatever you like into
> > whatever you like - printenv with grep and sed gets the value, then
> > another grep for the lines that matter and pass those lines to sed. It
> > really isn't hard.
> ok, please can you give me an example sed-command which replaces ${.*} 
> with the according environment-variables? 

Just join the dots of the sample commands already included in this bug
report (which doesn't deserve this much of my time TBH). You may need a
few judicious uses of 'eval' to expand the variables but by that stage,
you might as well just do the entire job in perl, python or whatever
else. Just not in shell.

> I couldn't find this yet and 
> nobody could point me to it yet.

What's the quote... if I wanted to do what you're describing I wouldn't
start where you are currently... I'd have done it in perl and many
others would choose python. Just don't expect shell to do this
usefully. It's much quicker in a.n.other language.

> The only way to do this I seeing atm is 
> to iterate through $(printenv) and replace all listed 
> environment-variables in the stream using sed. But this way seams very 
> "bloat" to me.

Then don't use a shell interpreter to do the job, write the entire
thing in a sensible, fast, language - not just the parser.

Any perl or python or C loop would do exactly the same - scrobble
together all the desired variables out of the environment into an array
or hash, then load the file and substitute the value wherever the key of
the hash exists in what you've read from the file.

> And when i write such a tool for myself, why does it matter if i do this 
> with python, perl, ruby, php, c or something else?

It only matters because you gave the reason for the package as needing
to do this in shell and if you are going to write the parser in
something else, why bother doing the rest of the work in shell? Any
other language wouldn't need this kind of support and would do the
entire job a lot faster than a combination of the tool and shell.

Please do write it for yourself, just don't expect to find a use for it
in Debian.

If you can't work it out, I'm sorry but I don't have the time to walk
you through it. The package proposed is still too trivial and pointless
to be useful in Debian IMHO.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpVwFiXtbKBZ.pgp
Description: PGP signature

ITP: wcstools -- Create display and manipulate the world coordinate system

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 

* Package name: wcstools
  Version : 3.8.4
  Upstream Author : Doug Mink 
* URL : http://tdc-www.harvard.edu/software/wcstools/
* License : GPLv2+
  Programming Lang: C
  Description : Create display and manipulate the world coordinate 
system

 WCSTools is a set of software utilities, written in C, which create,
 display and manipulate the world coordinate system of a FITS or IRAF
 image, using specific keywords in the image header which relate pixel
 position within the image to position on the sky.  Auxillary programs
 search star catalogs and manipulate images.

This package is built in preparation to build saods9
.
In fact, I would need only the library there which is going to be built 
as a shared library. To avoid conflicts with the "libwcs" library from 
wcslib, I intent to rename the library to "libwcstools". The wcstools 
binaries are built as a complementary gift :-)



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f0ffd8f.8080...@liska.ath.cx

Re: [Pkg-x2go-devel] Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries

[Stefan Lippers-Hollmann]

Hi

On Friday 13 January 2012, Mike Gabriel wrote:
> Hi Reinhard, dear all,
> 
> On Fr 13 Jan 2012 11:31:00 CET Reinhard Tartler wrote:
> 
> > http://anonscm.debian.org/gitweb/?p=collab-maint/x2go/nx-libs.git;a=tree
> > and, from what I see, is appropriate for being uploaded to unstable. For
> > clarity, I think we should rename the git repository from nx-libs.git to
> > nx-libs-light.git. Mike, can you please handle that?
> 
> Renamed!
> http://anonscm.debian.org/gitweb/?p=collab-maint/x2go/nx-libs-lite.git;a=tree
[...]

Thanks, this makes it a lot more reviewable (I stumbled into the full 
nx-libs in the master branch last night). nxcomp and nxproxy indeed
don't pose the problems I mentioned last night.

But I wonder, why do you need a merged source for this? The current 
versions of nxcomp and nxproxy, each built from their own upstream 
tarballs, is already at the 3.2 version state and should work (given 
that it's in the archive already) for client uses. If it's stability,
as mentioned in some other string of this thread, that would be a 
mere - fixable - bug, but the only reason I can see is making the 
server parts buildable - and that's where my concerns of massive code 
duplication of the full X.org 6.9 source tree return.

Yes, I'm aware of how well the NX protocol works over high latency and
low bandwidth links, but I also know how much of a nightmare it is to
work on that imake hell of the forked X.org 6.9, aka nx-x11, source.

Regards
Stefan Lippers-Hollmann


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201201131714.11684.s@gmx.de

Re: ITP: wcstools -- Create display and manipulate the world coordinate system

[Joachim Breitner]

Hi,

Am Freitag, den 13.01.2012, 10:46 +0100 schrieb Ole Streicher:
>Description : Create display and manipulate the world coordinate 
> system 

This should somehow mention that you are modifying picture; I would not
want a software in Debian that allows anyone to manipulate the
coordinate system of the real world, as I might not find the way home
then ;-)

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


signature.asc
Description: This is a digitally signed message part

Re: Bug#654970: ITP: drwright -- Known as typing break in GNOME 2

[Jon Dowland]

On 07/01/12 13:39, Savvas Radevic wrote:

Typing monitor to force typing breaks. It's a GNOME 3 tool that forces you to
  take regular breaks to prevent RSI (Repetitive Strain Injury).


What a blast from the past!

drwright used to be a GNOME 2 panel app that did exactly the same thing; 
it was eventually integrated into GNOME proper, and I guess
didn't survive to GNOME 3. (I used to use it, outside GNOME, and was 
mildly annoyed when that became impossible.)


--
Jon Dowland


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f106668.7050...@debian.org

Re: Outstanding /dev/.udev bugs for /run migration

[Julien Cristau]

On Thu, Jan 12, 2012 at 22:11:35 +, Roger Leigh wrote:

> There are 19 packages still using /dev/.udev after udev transitioned
> to /run/udev.  Unless there are any objections, I'd like to raise the
> severity of these bugs from important to serious, given that the /run
> migration is a release goal.
> 
I object.  If the packages are unusable as a result, these bugs are
grave.  If not, they're at most important.  In any case "serious" is
wrong.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Outstanding /dev/.udev bugs for /run migration

[Adam D. Barratt]

On Thu, 2012-01-12 at 22:11 +, Roger Leigh wrote:
> There are 19 packages still using /dev/.udev after udev transitioned
> to /run/udev.  Unless there are any objections, I'd like to raise the
> severity of these bugs from important to serious, given that the /run
> migration is a release goal.

Release goals aren't release critical by definition, so that would be
inappropriate.

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1326483959.29770.14.ca...@jacala.jungle.funky-badger.org

Re: [Pkg-x2go-devel] Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries

[Mike Gabriel]

Hi Stefan, hi all,

On Fr 13 Jan 2012 17:14:08 CET Stefan Lippers-Hollmann wrote:


Hi

On Friday 13 January 2012, Mike Gabriel wrote:

Hi Reinhard, dear all,

On Fr 13 Jan 2012 11:31:00 CET Reinhard Tartler wrote:

> http://anonscm.debian.org/gitweb/?p=collab-maint/x2go/nx-libs.git;a=tree
> and, from what I see, is appropriate for being uploaded to unstable. For
> clarity, I think we should rename the git repository from nx-libs.git to
> nx-libs-light.git. Mike, can you please handle that?

Renamed!
http://anonscm.debian.org/gitweb/?p=collab-maint/x2go/nx-libs-lite.git;a=tree

[...]

Thanks, this makes it a lot more reviewable (I stumbled into the full
nx-libs in the master branch last night). nxcomp and nxproxy indeed
don't pose the problems I mentioned last night.


:-) two different pair of shoes... Good that Reinhard cloned the  
original ITP into two (client-only and server/client).



But I wonder, why do you need a merged source for this? The current
versions of nxcomp and nxproxy, each built from their own upstream
tarballs, is already at the 3.2 version state and should work (given
that it's in the archive already) for client uses. If it's stability,
as mentioned in some other string of this thread, that would be a
mere - fixable - bug, but the only reason I can see is making the
server parts buildable - and that's where my concerns of massive code
duplication of the full X.org 6.9 source tree return.


nx-libs (LITE) is a subset of folders of nx-libs (FULL). If there was  
acceptance or a strategy or a new realm of possiblities that would  
allow us uploading nx-libs (FULL) to Debian some time in the future,  
the transition would be smooth. Apart from that: nxproxy is just one  
compilation step. nxproxy is a similar binary wrapper for libxcomp3.  
So by content the two belong together, maintaining two source projects  
is a possibility but it was not our choice here (we as in X2Go  
upstream who is redistributing the NX tarballs).


Note: the X2Go packaging team uses X2Go upstream as NX redistributor.  
And (being in a double role) X2Go upstream provides one tarball  
nx-libs lite/light (with applied patches). This is done, because the  
Debian packaging team shall have a patch-friendly upstream.



Yes, I'm aware of how well the NX protocol works over high latency and
low bandwidth links, but I also know how much of a nightmare it is to
work on that imake hell of the forked X.org 6.9, aka nx-x11, source.


Yes, it is a hell. I have been in it for the last four weeks (over  
X-mas, yeahhh...). But as I use X2Go for loads of projects from simple  
GUI based system administration to large schools with PXE X2Go boot  
environments (LDAP-based, PostgreSQL based), I really have a deep  
interest of providing that to others (i.e. to Debian).


Mike

--

DAS-NETZWERKTEAM
mike gabriel, dorfstr. 27, 24245 barmissen
fon: +49 (4302) 281418, fax: +49 (4302) 281419

GnuPG Key ID 0xB588399B
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


pgpdxvZtBDzFA.pgp
Description: Digitale PGP-Unterschrift

Ownership issue when repacking source in get-orig-source target

[Andreas Tille]

Hi,

I was concerned about an issue Charles Plessy reported in a recent
thread on Debian Med when he realised that the directories in the
unpacked tarball are featuring his UID/GID.  I simply looked into the
uscan source how it is be done there and found:

   GZIP=-9 tar --owner=root --group=root --mode=a+rX -czf  


I think this is also to weak because gzip seems to have the behaviour to
not always create byte identical results without the option --no-name
(I did not checked but trusted other DDs who reported this) and thus the
complete command should rather be

   GZIP="--best --no-name" tar --owner=root --group=root --mode=a+rX -czf 
 

I wonder whether we should rather implement a fool proof solution which
can be simply used in get-orig-source targets (and as well in uscan).
This would avoid random results and might be flexible enough to enable
changes at a single place in case further changes will be needed (so not
every single get-orig-source target needs to be touched.  So I'd suggest
something like

  /usr/bin/create_orig_tarball

  #!/bin/sh
  GZIP="--best --no-name" tar --owner=root --group=root --mode=a+rX -czf $1 $2

Well, suggestions for better names are welcome and some checking of the
arguments etc. might enhance this - but just to get the idea.  This
script could be shipped with the devscripts package.

I'd volunteer to write a bug report including patch but I want to hear
your opinion first whether I did overlooked something.

What do you think

Andreas.

[1] http://lists.debian.org/debian-med/2012/01/msg00125.html

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120113210752.ge20...@an3as.eu

Re: Ownership issue when repacking source in get-orig-source target

[Russ Allbery]

Andreas Tille  writes:

> I was concerned about an issue Charles Plessy reported in a recent
> thread on Debian Med when he realised that the directories in the
> unpacked tarball are featuring his UID/GID.

Do we care?  Most upstream distribution tarballs are likewise going to
feature random UIDs and GIDs in the tarball because that's what you get
from tar if you don't take any special precautions.  All of our software
therefore already copes with this.

The tarball already isn't reproducible without tools like pristine-tar due
to other issues with the format.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y5tb71dr@windlord.stanford.edu

Re: Ownership issue when repacking source in get-orig-source target

[Adam D. Barratt]

On Fri, 2012-01-13 at 22:07 +0100, Andreas Tille wrote:
> I was concerned about an issue Charles Plessy reported in a recent
> thread on Debian Med when he realised that the directories in the
> unpacked tarball are featuring his UID/GID.  I simply looked into the
> uscan source how it is be done there and found:
> 
>GZIP=-9 tar --owner=root --group=root --mode=a+rX -czf  
> 
> 
> I think this is also to weak because gzip seems to have the behaviour to
> not always create byte identical results without the option --no-name

fwiw, all of the calls to gzip in uscan from devscripts 2.11.3 use
"-n" (i.e. --no-name).  That's only just changed for zip re-packing but
has been used for bz2 re-packing since 2009.

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1326489533.29770.19.ca...@jacala.jungle.funky-badger.org

Re: Ownership issue when repacking source in get-orig-source target

[Andreas Tille]

On Fri, Jan 13, 2012 at 01:12:32PM -0800, Russ Allbery wrote:
> 
> Do we care?  Most upstream distribution tarballs are likewise going to
> feature random UIDs and GIDs in the tarball because that's what you get
> from tar if you don't take any special precautions.

I admit that the issue might not be very important but I personally like
reproducible results (in the sense of same MD5sums).  At least it can
not harm even if I admit that upstream does not care - in some points we
are better than upstream.  So why not doing it if it comes cheap?

Finally the author of uscan seems to have tried to code in this sense
but did not completely succeeded.

> All of our software
> therefore already copes with this.

That's correct and thus I would use severity wishlist or minor in case
it does not turn out as a completely stupid idea.
 
> The tarball already isn't reproducible without tools like pristine-tar due
> to other issues with the format.

Well, pristine-tar will not help us here (or am I missing something) because
I'm talking about *re*packaging upstream (for whatever reason).  Could you
please be more verbose about "other issues with the format"? 

Kind regards

Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120113212129.gf20...@an3as.eu

Re: Ownership issue when repacking source in get-orig-source target

[Andreas Tille]

On Fri, Jan 13, 2012 at 09:18:53PM +, Adam D. Barratt wrote:
> On Fri, 2012-01-13 at 22:07 +0100, Andreas Tille wrote:
> > I was concerned about an issue Charles Plessy reported in a recent
> > thread on Debian Med when he realised that the directories in the
> > unpacked tarball are featuring his UID/GID.  I simply looked into the
> > uscan source how it is be done there and found:
> > 
> >GZIP=-9 tar --owner=root --group=root --mode=a+rX -czf  
> > 
> > 
> > I think this is also to weak because gzip seems to have the behaviour to
> > not always create byte identical results without the option --no-name
> 
> fwiw, all of the calls to gzip in uscan from devscripts 2.11.3 use
> "-n" (i.e. --no-name).  That's only just changed for zip re-packing but
> has been used for bz2 re-packing since 2009.

Ahh, changelog of latest devscripts says:

  * uscan:
+ Use "gzip -n" when repacking zip files.  Thanks to Franz Schrober for
  the patch.  (Closes: #646691)

While #646691 says:

   [uscan] --repack from zip creates different file each time

This at least answers the question whether anybody cares.

So if this really seems to be an issue what do you think about my
suggestion to do the tarball creation in a script which besides inside
uscan could be used in get-orig-source targets?

Kind regards

Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120113215042.gh20...@an3as.eu

Re: Ownership issue when repacking source in get-orig-source target

[Russ Allbery]

Andreas Tille  writes:

> I admit that the issue might not be very important but I personally like
> reproducible results (in the sense of same MD5sums).  At least it can
> not harm even if I admit that upstream does not care - in some points we
> are better than upstream.  So why not doing it if it comes cheap?

You won't get back the same MD5 checksum after tar and gzip of the same
files, even if you set the UIDs.  pristine-tar has various additional code
to deal with all the various changes created by the tools.

> Well, pristine-tar will not help us here (or am I missing something)
> because I'm talking about *re*packaging upstream (for whatever reason).

However you generate the .orig.tar.gz file, you can then manage it with
pristine-tar, at least if you're using a VCS that pristine-tar supports.
The process when you repack upstream is really the same as when you just
download upstream from pristine-tar's perspective.

> Could you please be more verbose about "other issues with the format"?

The big one is that the timestamps will generally change (particularly on
directories), and gzip also encodes a timestamp.  There are other minor
differences generated by minor tool changes.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87lipb6z8l@windlord.stanford.edu

Re: Bug#654659: ITP: plover -- stenotype input method

[Paul Wise]

On Thu, Jan 5, 2012 at 7:32 AM, Thomas Thurman wrote:

> Plover is a stenotype input method for X11. It allows input of English text 
> using
> chords rather than letter by letter, enabling typing speeds to approach 300wpm
> for a skilled user. It can use a dedicated stenotype machine, or a standard
> QWERTY keyboard as long as it permits chords to be passed to the computer.

I would like to see this in Debian.

If you need a sponsor, I will look at the package when you post the
RFS to debian-mentors.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6fwyonncgm_8ypvvmdc5dvmxobpdb_fmy2stdeeabc...@mail.gmail.com