Debian Bug report logs - #454478
ltspfsd should not recommends ldm

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: "Mario Izquierdo \(mariodebian\)" <mariodebian@gmail.com>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: ltspfsd should not recommends ldm

Date: Wed, 05 Dec 2007 16:09:50 +0100

Package: ltspfsd
Version: 0.5+debian1
Severity: normal

lstpfsd is used only in LTSP chroot and Recomends ldm package.

I'm working on new thin client implementation and try to put into Debian
officially. I don't need ldm login manager, only ltspfsd daemon.

Since some time, apt recommended packages are installed and
without extra configuration can install ltspfsd without ldm.



# LC_ALL=C apt-get install ltspfsd
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
  ldm
The following NEW packages will be installed:
  ldm ltspfsd
0 upgraded, 2 newly installed, 0 to remove and 4 not upgraded.
Need to get 0B/193kB of archives.
After unpacking 463kB of additional disk space will be used.
Do you want to continue [Y/n]?


# LC_ALL=C apt-get -o "APT::Install-Recommends=false" install ltspfsd
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Recommended packages:
  ldm
The following NEW packages will be installed:
  ltspfsd
0 upgraded, 1 newly installed, 0 to remove and 4 not upgraded.
Need to get 0B/16.0kB of archives.
After unpacking 131kB of additional disk space will be used.
(Reading database ... 260825 files and directories currently installed.)
Unpacking ltspfsd (from .../ltspfsd_0.5+debian1_i386.deb) ...
Setting up ltspfsd (0.5+debian1) ...


Can you move ldm to suggests?


Thanks


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-3-686 (SMP w/2 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages ltspfsd depends on:
ii  libc6                      2.7-3         GNU C Library: Shared libraries
ii  lsof                       4.78.dfsg.1-3 List open files
ii  python                     2.4.4-6       An interactive high-level object-o

Versions of packages ltspfsd recommends:
pn  ldm                           <none>     (no description available)

-- no debconf information

Message #10 received at 454478@bugs.debian.org (full text, mbox, reply):

From: Oliver Grawert <ogra@ubuntu.com>

To: 454478@bugs.debian.org

Subject: Re: [Pkg-ltsp-devel] Bug#454478: ltspfsd should not recommends ldm

Date: Wed, 05 Dec 2007 16:42:17 +0100

[Message part 1 (text/plain, inline)]

hi,
On Mi, 2007-12-05 at 16:09 +0100, Mario Izquierdo (mariodebian) wrote:
> Package: ltspfsd
> Version: 0.5+debian1
> Severity: normal
> 
> lstpfsd is used only in LTSP chroot and Recomends ldm package.
> 
> I'm working on new thin client implementation and try to put into Debian
> officially. I don't need ldm login manager, only ltspfsd daemon.
> 
> Since some time, apt recommended packages are installed and
> without extra configuration can install ltspfsd without ldm.
well, i think ltspfsd will not work without the proper mcookie thats set
by ldm anymore you will need any similar implementation in whatever you
use instead, between the 4 and 5 series a lot of security changes were
made that you will need to take into account, ldm brings parts of these
in. 
i dont see a reason why we shouldnt split the binary into ltspfsd-core
and ltspfsd-scripts and an ltspfsd metapackage that depends on both. 

that way you could use the ltspfsd-core package which contains only the
binary. it has the advantage that the scripts can be arch: all

any opinions ? 

ciao
	oli

[signature.asc (application/pgp-signature, inline)]

Message #15 received at 454478@bugs.debian.org (full text, mbox, reply):

From: mariodebian <mariodebian@gmail.com>

To: Oliver Grawert <ogra@ubuntu.com>, 454478@bugs.debian.org

Subject: Re: [Pkg-ltsp-devel] Bug#454478: Bug#454478: ltspfsd should not recommends ldm

Date: Wed, 05 Dec 2007 21:20:22 +0100

[Message part 1 (text/plain, inline)]

Hi Oli.

> well, i think ltspfsd will not work without the proper mcookie thats set
> by ldm anymore you will need any similar implementation in whatever you
> use instead, between the 4 and 5 series a lot of security changes were
> made that you will need to take into account, ldm brings parts of these
> in. 

In TCOS I'm using ltspfs 0.2 cvs20060920 (i know that is an very old
version)


Investigating in lstp 5 sources I found that you save a mcookie
in /var/run/ltspfs_token and set in Xorg with:

xprop -root -f LTSPFS_TOKEN 8s -set LTSPFS_TOKEN
$(cat /var/run/ltspfs_token)

I have patched some scripts and TCOS works ok with new version of ltspfs
(0.5)



> i dont see a reason why we shouldnt split the binary into ltspfsd-core
> and ltspfsd-scripts and an ltspfsd metapackage that depends on both. 
> 
> that way you could use the ltspfsd-core package which contains only the
> binary. it has the advantage that the scripts can be arch: all
> 
> any opinions ? 
> 
> ciao
> 	oli

I fully agree.

I don't know when TCOS wiull enter in Debian but this could be a
important step to keep depends more simple.

Thanks.

--
Mario 
http://soleup.eup.uva.es/mariodebian

[signature.asc (application/pgp-signature, inline)]

Message #20 received at 454478@bugs.debian.org (full text, mbox, reply):

From: Otavio Salvador <otavio@debian.org>

To: mariodebian <mariodebian@gmail.com>

Cc: 454478@bugs.debian.org, Oliver Grawert <ogra@ubuntu.com>

Subject: Re: [Pkg-ltsp-devel] Bug#454478: Bug#454478: Bug#454478: ltspfsd should not recommends ldm

Date: Thu, 06 Dec 2007 14:18:51 -0200

mariodebian <mariodebian@gmail.com> writes:

>> i dont see a reason why we shouldnt split the binary into ltspfsd-core
>> and ltspfsd-scripts and an ltspfsd metapackage that depends on both. 
>> 
>> that way you could use the ltspfsd-core package which contains only the
>> binary. it has the advantage that the scripts can be arch: all
>> 
>> any opinions ? 
>> 
>> ciao
>> 	oli
>
> I fully agree.

I agree on it too. It makes more easy for others to use it in advanced
ways even that it looks strange from an outsider POV.

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."

Message #25 received at 454478@bugs.debian.org (full text, mbox, reply):

From: vagrant@freegeek.org

To: 454478@bugs.debian.org

Subject: Re: Bug#454478: ltspfsd should not recommends ldm

Date: Thu, 6 Dec 2007 14:47:22 -0800

On Wed, Dec 05, 2007 at 04:42:17PM +0100, Oliver Grawert wrote:
> On Mi, 2007-12-05 at 16:09 +0100, Mario Izquierdo (mariodebian) wrote:
> > lstpfsd is used only in LTSP chroot and Recomends ldm package.
> > 
> > I'm working on new thin client implementation and try to put into Debian
> > officially. I don't need ldm login manager, only ltspfsd daemon.
> > 
> > Since some time, apt recommended packages are installed and
> > without extra configuration can install ltspfsd without ldm.

i would think changing the recommends to a suggests would be the most
appropriate thing here. maybe also an "enhances" field.

> well, i think ltspfsd will not work without the proper mcookie thats set
> by ldm anymore you will need any similar implementation in whatever you
> use instead, between the 4 and 5 series a lot of security changes were
> made that you will need to take into account, ldm brings parts of these
> in. 

that doesn't really change the nature of the bug report, only
implementation for other projects wishing to use ltspfsd.

> i dont see a reason why we shouldnt split the binary into ltspfsd-core
> and ltspfsd-scripts and an ltspfsd metapackage that depends on both.

> that way you could use the ltspfsd-core package which contains only the
> binary. it has the advantage that the scripts can be arch: all

i don't see a reason why we should split it really.

the ltspfsd package is quite small, so i wouldn't justify making an arch
all package on those grounds.

the udev scripts are essentially harmless now, even if there are some
cases where they wouldn't do anything useful.

i definitely don't see a need for splitting ltspfsd into three packages,
and don't support the idea of splitting out ltspfsd-core.

i'd be open to hearing more on the matter, particularly use cases where
the current layout doesn't work.

live well,
  vagrant

Message #30 received at 454478@bugs.debian.org (full text, mbox, reply):

From: Oliver Grawert <ogra@ubuntu.com>

To: 454478@bugs.debian.org

Subject: Re: [Pkg-ltsp-devel] Bug#454478: ltspfsd should not recommends ldm

Date: Fri, 07 Dec 2007 10:18:54 +0100

[Message part 1 (text/plain, inline)]

hi,
On Do, 2007-12-06 at 14:47 -0800, vagrant@freegeek.org wrote:

> i'd be open to hearing more on the matter, particularly use cases where
> the current layout doesn't work.
you mean more like: ltspfsd is a no-op without the xprop set by ldm or
that we install our rc scripts into /usr/share/ldm/rc.d ? 
or the fact that even if the udev scripts are harmless, making it
possible to install them in a normal system which is more vulnerable to
security leaks forces us to put more ressources into security ? 
it think the recommends is totally justified here, at the current state
ltspfsd wont work at all without ldm installed i'd even turn it into a
dependency ... 
the split would allow developers to develop their own solutions without
the udev and ldm overhead installed using ltspfsd-core, while i dont see
a reason to enable normal users to install a non-functional ltspfsd
package ...

note that in ubuntu ltspfsd even depends on ltsp-client to prevent the
udev scripts being installed in normal systems (no matter if they are
harmful or not, i just dont want them there since nobody ever tested how
or if they interfere with existing rules and you can get unpredictable
results)

imho the split is a good compromise for us all, i could keep the dep
tree in place i want, you could install without the metapackage if you
urgently want the scripts in normal workstations, mario could work with
only the core package and users would not be able to break ther systems
accidentially.

ciao
	oli

[signature.asc (application/pgp-signature, inline)]

Message #35 received at 454478@bugs.debian.org (full text, mbox, reply):

From: Otavio Salvador <otavio@debian.org>

To: Oliver Grawert <ogra@ubuntu.com>

Cc: 454478@bugs.debian.org

Subject: Re: [Pkg-ltsp-devel] Bug#454478: Bug#454478: ltspfsd should not recommends ldm

Date: Fri, 07 Dec 2007 10:26:47 -0200

Oliver Grawert <ogra@ubuntu.com> writes:

> imho the split is a good compromise for us all, i could keep the dep
> tree in place i want, you could install without the metapackage if you
> urgently want the scripts in normal workstations, mario could work with
> only the core package and users would not be able to break ther systems
> accidentially.

Yes. I personally agree on that too. It makes more sense to me the
split then downgrading it.

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."

Message #40 received at 454478@bugs.debian.org (full text, mbox, reply):

From: vagrant@freegeek.org

To: 454478@bugs.debian.org

Subject: Bug#454478: ltspfsd should not recommends ldm

Date: Fri, 7 Dec 2007 09:47:10 -0800

On Fri, Dec 07, 2007 at 10:18:54AM +0100, Oliver Grawert wrote:
> On Do, 2007-12-06 at 14:47 -0800, vagrant@freegeek.org wrote:
> > i'd be open to hearing more on the matter, particularly use cases where
> > the current layout doesn't work.
> you mean more like: ltspfsd is a no-op without the xprop set by ldm or
> that we install our rc scripts into /usr/share/ldm/rc.d ? 

i'm having trouble understanding you here (mostly because i think i
mis-read it at first)... what i think you mean is that ltspfsd should
continue to recommend ldm because ldm is the only thing that has
actually implemented hooks to make ltspfsd work?

ok, sure.

but i think soon there will be other things that also work with ltspfsd
that don't use ldm.  the very reason this bug report was filed is
because someone is exploring an alternative way to use ltspfsd without
LDM.  at that point, i think a suggests and/or enhances relationship is
more appropriate.

> or the fact that even if the udev scripts are harmless, making it
> possible to install them in a normal system which is more vulnerable to
> security leaks forces us to put more ressources into security ? 

i don't see any reason to be sloppy with security in any case.

> it think the recommends is totally justified here, at the current state
> ltspfsd wont work at all without ldm installed i'd even turn it into a
> dependency ... 

the request to lower it from recommends to a dependency clearly
indicates to me that there is interest in using ltspfsd without LDM.

the ltspfs/ldm interaction is not very complicated. 5 lines of patches
to sdm allow it to be used instead.

> the split would allow developers to develop their own solutions without
> the udev and ldm overhead installed using ltspfsd-core, 

> while i dont see a reason to enable normal users to install a
> non-functional ltspfsd package ...

the reason is that it would be trivial to implement the needed
functionality and there is expressed interest in doing so.

people have demonstrated and implemented systems using ltspfsd without
ldm.  i believe gadi at one point had actually used it as an automounter
to support local devices with rdesktop, if i remember correctly.

> note that in ubuntu ltspfsd even depends on ltsp-client to prevent the
> udev scripts being installed in normal systems 

yes, and ubuntu is much more focused on a single option for a single
purpose, which is excellent for defaults. 

i don't believe having a good default is a reason to make it more
difficult to implement alternatives, which making it a hard dependency
does. i do not want to see that in debian.

> (no matter if they are harmful or not, i just dont want them there
> since nobody ever tested how or if they interfere with existing rules
> and you can get unpredictable results)

this is the most convincing reason i have heard for the split- that the
udev rules *may* cause problems, though i have no indication that they
*do* cause problems.

if the udev rules are demonstrated to be probably or definitely harmful,
i see that as a valid reason for the split.

> imho the split is a good compromise for us all, i could keep the dep
> tree in place i want, you could install without the metapackage if you
> urgently want the scripts in normal workstations, mario could work with
> only the core package and users would not be able to break ther systems
> accidentially.

i see two possible packages:

 * ltspfsd-core, which contains the ltspfsd binary (maybe other scripts
that make sense to distribute with it)

 * ltspfsd, which contains the scripts, udev rules and such that are
currently in ltspfsd, minus whatever parts are moved to the ltspfsd-core
package. maybe keep the recommends on ldm.

i would rather keep a single package if at all possible- there are
already many thousands of packages in debian, and would only want to add
more if it really addressed problems or made the software more useful.

live well,
  vagrant

Message #45 received at 454478@bugs.debian.org (full text, mbox, reply):

From: Vagrant Cascadian <vagrant@freegeek.org>

To: 454478@bugs.debian.org

Cc: 454478-submitter@bugs.debian.org

Subject: splitting ltspfsd into two packages

Date: Fri, 3 Apr 2009 23:05:40 -0700

i've been looking into splitting ltspfsd into two packages, one with all the
binaries (ltspfsd-core), and one with all the udev and other scripts(ltspfsd).

the two binaries are "ltspfsd" and "cdpinger", though both of them call other
scripts, so those also need be included in the ltspfsd-core package.  so that
doesn't leave a whole lot of content for the ltspfsd package- just the ldm
hooks and other generic hooks for X sessions.

though, with the switch to call cdpinger from udev, splitting the package seems
more important now.

ltspfsd-core would be able to no longer recommend ldm (the original reason for
this bug report), while ltspfsd would continue to do so.

i've got most of the packaging done... so i guess i'll try and get a sponsor to
upload it soon.

live well,
  vagrant

Message #53 received at 454478@bugs.debian.org (full text, mbox, reply):

From: mariodebian <mariodebian@gmail.com>

To: 454478@bugs.debian.org

Cc: 454478-submitter@bugs.debian.org

Subject: Re: [Pkg-ltsp-devel] Bug#454478: splitting ltspfsd into two packages

Date: Sat, 04 Apr 2009 15:29:34 +0200

[Message part 1 (text/plain, inline)]

El vie, 03-04-2009 a las 23:05 -0700, Vagrant Cascadian escribió:
> i've been looking into splitting ltspfsd into two packages, one with all the
> binaries (ltspfsd-core), and one with all the udev and other scripts(ltspfsd).
> 
> the two binaries are "ltspfsd" and "cdpinger", though both of them call other
> scripts, so those also need be included in the ltspfsd-core package.  so that
> doesn't leave a whole lot of content for the ltspfsd package- just the ldm
> hooks and other generic hooks for X sessions.
> 
> though, with the switch to call cdpinger from udev, splitting the package seems
> more important now.
> 
> ltspfsd-core would be able to no longer recommend ldm (the original reason for
> this bug report), while ltspfsd would continue to do so.
> 
> i've got most of the packaging done... so i guess i'll try and get a sponsor to
> upload it soon.
> 
> live well,
>   vagrant

Very good news, thanks for spliting ltspfsd package.

Can I will install ltspfsd-core (without other depends) in a Desktop
computer?


I'm working on TCOS upload, roadmap here:
http://wiki.tcosproject.org/Tcos_Into_Debian

Last week I have uploaded p910nd to Debian, this package can replace
LTSP python script (jectdirect?? don't remember name) that redirect 9100
port to /dev/lp0:

http://packages.debian.org/source/sid/p910nd


Greetings
-- 
http://soleup.eup.uva.es/mariodebian

[signature.asc (application/pgp-signature, inline)]

Message #63 received at 454478-close@bugs.debian.org (full text, mbox, reply):

From: Vagrant Cascadian <vagrant@freegeek.org>

To: 454478-close@bugs.debian.org

Subject: Bug#454478: fixed in ltspfs 0.5.11-2

Date: Wed, 08 Apr 2009 22:27:33 +0000

Source: ltspfs
Source-Version: 0.5.11-2

We believe that the bug you reported is fixed in the latest version of
ltspfs, which is due to be installed in the Debian FTP archive:

ltspfs_0.5.11-2.diff.gz
  to pool/main/l/ltspfs/ltspfs_0.5.11-2.diff.gz
ltspfs_0.5.11-2.dsc
  to pool/main/l/ltspfs/ltspfs_0.5.11-2.dsc
ltspfs_0.5.11-2_amd64.deb
  to pool/main/l/ltspfs/ltspfs_0.5.11-2_amd64.deb
ltspfsd-core_0.5.11-2_amd64.deb
  to pool/main/l/ltspfs/ltspfsd-core_0.5.11-2_amd64.deb
ltspfsd_0.5.11-2_all.deb
  to pool/main/l/ltspfs/ltspfsd_0.5.11-2_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 454478@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Vagrant Cascadian <vagrant@freegeek.org> (supplier of updated ltspfs package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Sun, 05 Apr 2009 13:34:26 -0700
Source: ltspfs
Binary: ltspfs ltspfsd ltspfsd-core
Architecture: source amd64 all
Version: 0.5.11-2
Distribution: experimental
Urgency: low
Maintainer: LTSP Debian/Ubuntu Maintainers <pkg-ltsp-devel@lists.alioth.debian.org>
Changed-By: Vagrant Cascadian <vagrant@freegeek.org>
Description: 
 ltspfs     - Fuse based remote filesystem for LTSP thin clients
 ltspfsd    - Fuse based remote filesystem daemon for LTSP thin clients
 ltspfsd-core - Fuse based remote filesystem daemon for LTSP thin clients
Closes: 454478
Changes: 
 ltspfs (0.5.11-2) experimental; urgency=low
 .
   * split ltspfsd and cdpinger into ltspfsd-core package, making it possible to
     install ltspfsd-core without having to install udev rules, or pull in
     recommends on ldm. (Closes: #454478)
Checksums-Sha1: 
 0e769e2cf450be6860d1198072d725d9fda5283d 1542 ltspfs_0.5.11-2.dsc
 bd83fdc2b1a68b5a4c444cdb4e3165c1b4e7bb49 6886 ltspfs_0.5.11-2.diff.gz
 84fcac54ea4f2a7a13c206d32ccd39fbcccf1c4a 26572 ltspfs_0.5.11-2_amd64.deb
 66404c27114f818201d366b443379bb4fa5432ef 28526 ltspfsd-core_0.5.11-2_amd64.deb
 b3c5ddec40a37ec2e0d824785ba3ced33ab4be8c 12712 ltspfsd_0.5.11-2_all.deb
Checksums-Sha256: 
 e4b427ff9f017661f8e2e6295770e68b7bc62e21aff47542afe4dcc78daa0b2c 1542 ltspfs_0.5.11-2.dsc
 c39b91b9de840a0cd784ea10cec2692a65fb9f1caf80fec70ccb66ed8ff64b94 6886 ltspfs_0.5.11-2.diff.gz
 192e77c6490b5c10e86053d768320dfddc04ca19f196c550a17863117c6ef5c9 26572 ltspfs_0.5.11-2_amd64.deb
 ced72c7fb61c945b8bbd3dc0ee468e44c445e29e5082186c24b90f63f4af0a46 28526 ltspfsd-core_0.5.11-2_amd64.deb
 ca8192378cf1a3f92681a385a3cc3f1cd73bf91dc7daa82fc351c4e0525fdf7a 12712 ltspfsd_0.5.11-2_all.deb
Files: 
 1b94e6d03afc76065f46019ae2119312 1542 net optional ltspfs_0.5.11-2.dsc
 0983424a37718939e2b486427c8f65c9 6886 net optional ltspfs_0.5.11-2.diff.gz
 fbb92c5b488ffcab48498f876b0c36e3 26572 net optional ltspfs_0.5.11-2_amd64.deb
 b24fdffbfe4a9707097edb94604ec3ce 28526 net optional ltspfsd-core_0.5.11-2_amd64.deb
 1d140d8a7517eac0762c3142f02a6e21 12712 net optional ltspfsd_0.5.11-2_all.deb

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

iEYEARECAAYFAknZUzsACgkQLqiZQEml+FUveACgpzYx8lZyZ1yX4KRoor/Uo1cg
yY8An2QG/LPYrVTQbmKvvOS/uBwKiXoX
=eNDP
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.