Package requests: fortune, gifsicle, inxi, uncrustify, unrar, vsftp, xss-lock

Package requests: fortune, gifsicle, inxi, uncrustify, unrar, vsftp, xss-lock

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]


I'm missing the following packages in Guix.  If no one has planned to
package them yet, I'll give it a go.

fortune: 	The Fortune Cookie Program from BSD games
Upstream URL: 	http://www.shlomifish.org/open-source/projects/fortune-mod/

gifsicle: 	A powerful command-line program for creating, editing, manipulating and getting information about GIF images and animations
Upstream URL: 	http://www.lcdf.org/gifsicle/

inxi: 	script to get system information
Upstream URL: 	https://github.com/smxi/inxi

uncrustify: 	A source code beautifier
Upstream URL: 	http://uncrustify.sourceforge.net/

Description: 	The RAR uncompression program
Upstream URL: 	http://www.rarlab.com/rar_add.htm
(Not sure about the licensing of this one: does not look free.  Is there
any free way to extract RAR?)

vsftp: 	Very Secure FTP daemon
Upstream URL: 	https://security.appspot.com/vsftpd.html
(It seems that there is not a single FTP server on Guix.  Strange... Can anyone
recommend anything better than vsftp for file sharing?  Not necessarily
FTP.)

xss-lock: 	Use external locker as X screen saver
Upstream URL: 	https://bitbucket.org/raymonad/xss-lock

-- 
Pierre Neidhardt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Package request inxi

[Oleg Pykhalov]

[-- Attachment #1: Type: text/plain, Size: 401 bytes --]

Hello Pierre,

Pierre Neidhardt <ambrevar@gmail.com> writes:

> inxi: 	script to get system information
> Upstream URL: 	https://github.com/smxi/inxi

You could take a package recipe [1].  I don't think it's ready to push
to Guix package collection, because it requires more ‘(substitute* …)’.

[1]  https://notabug.org/wigust/guix-wigust/src/master/wigust/packages/inxi.scm

Oleg.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Package request inxi

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 332 bytes --]


Oleg Pykhalov <go.wigust@gmail.com> writes:

> You could take a package recipe [1].  I don't think it's ready to push
> to Guix package collection, because it requires more ‘(substitute* …)’.
>
> [1]  https://notabug.org/wigust/guix-wigust/src/master/wigust/packages/inxi.scm

Nice, thanks!

-- 
Pierre Neidhardt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Package request inxi

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 295 bytes --]


I'm trying to package inxi.  Does guix support optional dependencies?
Or is it that I should just include them in the description?

-- 
Pierre Neidhardt

I think that's easier to read.  Pardon me.  Less difficult to read.
             -- Larry Wall in <199710120226.TAA06867@wall.org>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Package request inxi

[Oleg Pykhalov]

[-- Attachment #1: Type: text/plain, Size: 632 bytes --]

Hello Pierre,

Pierre Neidhardt <ambrevar@gmail.com> writes:

> I'm trying to package inxi.

Thank you for working on this!  Let us know if you have more questions.

> Does guix support optional dependencies?

Unfortunately Guix doesn't.

Instead you could use ‘(inputs …)’ and ‘(native-inputs …)’ which will
not be installed to a user's profile but available in build phases.

> Or is it that I should just include them in the description?

‘(package (description #;…) #;…)’ is not a good place to list and track
dependencies, because a package could include more or less in future.

Oleg.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Package request inxi

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 409 bytes --]


Oleg Pykhalov <go.wigust@gmail.com> writes:

> Instead you could use ‘(inputs …)’ and ‘(native-inputs …)’ which will
> not be installed to a user's profile but available in build phases.

But those dependencies won't be used during the build phase: it's
unnecessary load for the builder.

-- 
Pierre Neidhardt

He is a man capable of turning any colour into grey.
		-- John LeCarre

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Package request inxi

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1132 bytes --]


I'm running into a strange issue:
Line 4506:

	$item =~ s/chipset|components|computing|computer|corporation|communications|electronics|electrical|electric|gmbh|group|incorporation|industrial|international|nee|revision|semiconductor|software|technologies|technology|ltd\.|<ltd>|\bltd\b|inc\.|<inc>|\binc\b|intl\.|co\.|<co>|corp\.|<corp>|\(tm\)|\(r\)|®|\(rev ..\)|\'|\"|\sinc\s*$|\?//gi;

gets replace by


	$item =~ s/chipset|components|computing|computer|corporation|communications|electronics|electrical|electric|gmbh|group|incorporation|industrial|international|nee|revision|semiconductor|software|technologies|technology|ltd\.|<ltd>|\bltd\b|inc\.|<inc>|\binc\b|intl\.|co\.|<co>|corp\.|<corp>|\(tm\)|\(r\)|??|\(rev ..\)|\'|\"|\sinc\s*$|\?//gi;

More precisely,

	®

into

  ??

I use the trivial build system and the only substitute (for now) is

           (substitute* "inxi"
             (("/usr/bin/env perl")
              (string-append (assoc-ref %build-inputs "perl") "/bin/perl")))

-- 
Pierre Neidhardt

There's no real need to do housework -- after four years it doesn't get
any worse.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Package request inxi

[Oleg Pykhalov]

[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]

Pierre Neidhardt <ambrevar@gmail.com> writes:

> I'm running into a strange issue:
> Line 4506:
>
> 	$item =~ s/chipset|components|computing|computer|corporation|communications|electronics|electrical|electric|gmbh|group|incorporation|industrial|international|nee|revision|semiconductor|software|technologies|technology|ltd\.|<ltd>|\bltd\b|inc\.|<inc>|\binc\b|intl\.|co\.|<co>|corp\.|<corp>|\(tm\)|\(r\)|®|\(rev ..\)|\'|\"|\sinc\s*$|\?//gi;
>
> gets replace by
>
>
> 	$item =~ s/chipset|components|computing|computer|corporation|communications|electronics|electrical|electric|gmbh|group|incorporation|industrial|international|nee|revision|semiconductor|software|technologies|technology|ltd\.|<ltd>|\bltd\b|inc\.|<inc>|\binc\b|intl\.|co\.|<co>|corp\.|<corp>|\(tm\)|\(r\)|??|\(rev ..\)|\'|\"|\sinc\s*$|\?//gi;
>
> More precisely,
>
> 	®
>
> into
>
>   ??
>
> I use the trivial build system and the only substitute (for now) is
>
>            (substitute* "inxi"
>              (("/usr/bin/env perl")
>               (string-append (assoc-ref %build-inputs "perl") "/bin/perl")))

Please, could you try to wrap a ‘substitute*’ procedure with:

    (with-fluids ((%default-port-encoding #f)) (substitute* #;…))

Oleg.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Package request inxi

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 324 bytes --]


Oleg Pykhalov <go.wigust@gmail.com> writes:

> Please, could you try to wrap a ‘substitute*’ procedure with:
>
>     (with-fluids ((%default-port-encoding #f)) (substitute* #;…))

It worked.

-- 
Pierre Neidhardt

Research is to see what everybody else has seen, and think what nobody
else has thought.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Package request inxi

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1517 bytes --]


Going on with the package, I think we only need this patch beside the
shabang adjustment:

	 ## System
	 my ($bsd_type,$language,$os) = ('','','');
	 my ($cpu_sleep,$dl_timeout,$limit,$ps_count,$usb_level) = (0.35,4,10,5,0);
	-my @paths = qw(/sbin /bin /usr/sbin /usr/bin /usr/X11R6/bin /usr/local/sbin /usr/local/bin);
	-$ENV{'PATH'} = 'sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin';
	+my @paths = qw(/sbin /bin /run/setuid-programs /run/current-system/profile/bin /run/current-system/profile/sbin);
	+push (@paths, "$ENV{'HOME'}/.guix-profile/bin");
	+push (@paths, "$ENV{'HOME'}/.guix-profile/sbin");
	+$ENV{'PATH'} = '/sbin:/bin:/run/setuid-programs:/run/current-system/profile/bin:/run/current-system/profile/sbin';
	+$ENV{'PATH'} = '$ENV:$ENV{'HOME'}/.guix-profile/bin";
	+$ENV{'PATH'} = '$ENV:$ENV{'HOME'}/.guix-profile/sbin";
	 my $sensors_cpu_nu = 0;

Basically inxi sets a 'paths' variable with the usual Unix paths and
then forces the environment PATH to the same value.

My suggestion instead: set 'paths' to /run/current-system/* and
~/.guix-profile/{sbin,bin}.

What do you think?  Is this generic enough?  Is ~/.guix-profile a
guaranteed location for the user profile?

Last but not least, what's the better approach between
- a patch,
- a substitute,
- a snippet?

I only know very little about Perl so the above code might look very clumsy.

-- 
Pierre Neidhardt

There is very little future in being right when your boss is wrong.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Package request inxi

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 2134 bytes --]

Pierre Neidhardt <ambrevar@gmail.com> writes:

> Basically inxi sets a 'paths' variable with the usual Unix paths and
> then forces the environment PATH to the same value.
>
> My suggestion instead: set 'paths' to /run/current-system/* and
> ~/.guix-profile/{sbin,bin}.
>
> What do you think?  Is this generic enough?  Is ~/.guix-profile a
> guaranteed location for the user profile?

No, ~/.guix-profile is not guaranteed.  Users can and do create profiles
in various places, e.g. with "guix package -p my-profile -i hello".  In
addition, /run/current-system/* would not work on foreign distros.

Is inxi a program, or a library?  If it's a program, then a better
solution is to bind PATH to the required dependencies at build time.  An
easy way to accomplish that would be to use the wrap-program procedure
from (guix build utils).  Read its docstring and grep for wrap-program
in the gnu/packages directories to see how it's used.  The basic idea is
that we can create a wrapper script for inxi which launches inxi in an
environment where PATH is set to exactly the things it needs.

There are other ways to accomplish the same thing.  For example, we
could replace references in the source code with references that point
to precisely the things required.  Generally we would add or modify a
build phase to accomplish this; read the docstring for the substitute*
procedure (also defined in (guix build utils) and grep for it in the
gnu/packages directories to see this technique in action.

Inxi has been written, like much software, to be composed with other
software at runtime; the composition is normally achieved via
environment variables.  The techniques above allow us to compose inxi
with its dependencies at build time, which is desirable because it means
that the built program will behave the same on my machine as it does on
yours, regardless of how my environment is configured.  This is known as
"static composition" of software components (see Section 7.1.1,
"Principles", in the Nix thesis [1]).

Footnotes: 
[1]  https://nixos.org/~eelco/pubs/phd-thesis.pdf

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Package request inxi

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]


See https://github.com/smxi/inxi: it's a Perl script that calls various
programs (if it finds them) _at runtime_.

Basically inxi makes a number of `system PROGRAM` calls, where PROGRAM
is found in the PATH environment variable.

Because most of those dependencies are optional, it could be nice not
depend on them.  Which means no input at build-time.  But then we cannot
substitute the relative paths by the static full path to the store.

Another approach would be to _not_ have optional dependencies are go
more Nix-y as you suggest with including all the required programs as
input and storing their full path inside the inxi script.

This is hard though, because it implies parsing a huge Perl script...


We could also go the dead-simple way: leave PATH and paths to their
current values: the only downside I see is that inxi could pententially
call programs of the same name installed in user-specific folders
(e.g. ~/.local/bin).

--
Pierre Neidhardt

To save a single life is better than to build a seven story pagoda.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Package request inxi

[Oleg Pykhalov]

[-- Attachment #1: Type: text/plain, Size: 486 bytes --]

Pierre Neidhardt <ambrevar@gmail.com> writes:

> Oleg Pykhalov <go.wigust@gmail.com> writes:
>
>> Instead you could use ‘(inputs …)’ and ‘(native-inputs …)’ which will
>> not be installed to a user's profile but available in build phases.
>
> But those dependencies won't be used during the build phase

Yes, unfortunately ‘inxi’ doens't provide like a ‘./configure’ thing to
discover and use inputs.  But we could patch paths to input binaries.

Oleg.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Package request inxi

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]


Oleg Pykhalov <go.wigust@gmail.com> writes:

> Yes, unfortunately ‘inxi’ doens't provide like a ‘./configure’ thing to
> discover and use inputs.  But we could patch paths to input binaries.

My point that the dependencies are not _needed_ during the build phase,
so getting all the inputs induces extra load for nothing for the builder.


-- 
Pierre Neidhardt

My way of joking is to tell the truth.  That's the funniest joke in the world.
		-- Muhammad Ali

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Package request inxi

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 1424 bytes --]

Pierre Neidhardt <ambrevar@gmail.com> writes:

> I'm trying to package inxi.  Does guix support optional dependencies?

Can you describe the "optional dependencies" in a little more detail?
Will certain features of inxi be available or unavailable depending on
whether or not a specific dependency is present during the build?  Or
perhaps at when running inxi after it has been built?

If by "optional dependency" you meant "an item of software that, when
present during the build, will enable a certain feature of inxi," then
the answer is: you should probably just write a package definition that
choose a reasonable set of inputs and configure flags as the default.
In Guix, it is possible to define a second package that "inherits"
attributes from the first but also has customized attributes.  Since
this is scheme, it is also possible to define a procedure that generates
a customized package.  Those are two popular ways to deal with this kind
of "optional dependency."

It's also worth mentioning that even if you accidentally specify an
input that isn't actually used, it isn't all bad.  Such inputs will
clutter up places like the package graph, and they will increase the
build time because they need to be built first (even though they are not
used).  However, they won't show up in the package's output, so they
will not contribute to the total size of the built package.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Package request inxi

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 775 bytes --]


I was using "optional dependencies" in the sense Arch Linux uses it:
they don't impact the build, they are only used at runtime.

From a package declaration perspective, they are merely hint for the
user.

The main advantage over simply adding them to the description is that
the package manager can tell about "optional reverse dependencies".
When removing a package that is optionally needed by others, it
makes it possible to warn the users if they are going to lose some
functionnality for some specified packages.

None of `inputs`, `native-inputs` or `propagated-inputs` allow us to do
that.

--
Pierre Neidhardt

Flying is the second greatest feeling you can have.  The greatest feeling?
Landing...  Landing is the greatest feeling you can have.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

inxi and inxi-full

[Oleg Pykhalov]

[-- Attachment #1: Type: text/plain, Size: 249 bytes --]

Pierre Neidhardt <ambrevar@gmail.com> writes:

What do you think about ‘inxi’ package with inputs, which are only
required to run it,
and another ‘inxi-full’ package, which will inherit ‘inxi’, but with
additional inputs?

Oleg.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: inxi and inxi-full

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 698 bytes --]


Oleg Pykhalov <go.wigust@gmail.com> writes:

> Pierre Neidhardt <ambrevar@gmail.com> writes:
>
> What do you think about ‘inxi’ package with inputs, which are only
> required to run it,
> and another ‘inxi-full’ package, which will inherit ‘inxi’, but with
> additional inputs?

My first thought is that it sounds like a good alternative to the
concept of optional dependencies.

I like the idea.

It also means that the `inxi` package cannot patch inxi with full store
paths.

Any suggestion other than making leaving ENV{'PATH'} untouched and
setting @paths to it?

-- 
Pierre Neidhardt

There is more to life than increasing its speed.
		-- Mahatma Gandhi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: inxi and inxi-full

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 4363 bytes --]

Pierre Neidhardt <ambrevar@gmail.com> writes:

> Oleg Pykhalov <go.wigust@gmail.com> writes:
>
>> Pierre Neidhardt <ambrevar@gmail.com> writes:
>>
>> What do you think about ‘inxi’ package with inputs, which are only
>> required to run it,
>> and another ‘inxi-full’ package, which will inherit ‘inxi’, but with
>> additional inputs?

If we make two package definitions, I would prefer the name
"inxi-minimal" for the version that is statically composed with the bare
minimum of its runtime dependencies.  This is similar to how we have
named other "minimal" packages in the past (e.g., qemu-minimal).

> My first thought is that it sounds like a good alternative to the
> concept of optional dependencies.
>
> I like the idea.
>
> It also means that the `inxi` package cannot patch inxi with full store
> paths.
>
> Any suggestion other than making leaving ENV{'PATH'} untouched and
> setting @paths to it?

I've taken a peek at inxi.  I assume it's this:

https://github.com/smxi/inxi

I see that it's a single perl script.  It runs various programs via
Perl's "system" function in order to collate information about the
system, and it then reports the results.  These programs - the runtime
dependencies - are found via the PATH environment variable.  The script
also embeds paths in some places that might need to be fixed.  For
example, it looks like the get_gcc_data subroutine searches for gcc
executables in the /usr/bin directory, which will not exist on GuixSD.

Let's suppose that we go ahead and create an "inxi-minimal" package that
only contains just enough inputs to get the tool to run, and we also
allow it to dynamically find tools at runtime via the PATH environment
variable.  Will inxi-minimal be useful for someone who wants to run
inxi?  Or is it more likely that someone will install inxi-minimal, run
it, find out that it didn't report all the info they expected it to
print (because they happened to not have some of the tools available in
their PATH), and then they will eventually realize they need to install
more packages in order for inxi to make use of them?

If inxi-minimal can provide genuinely useful information without
requiring the user to install additional packages, then I think it's
reasonable to add a package definition for it.  However, if almost
everyone is going to need to install additional packages into their
profile just to get the output from inxi-minimal that they wanted, then
I think we should not add it.  In any case, we should definitely have an
"inxi" package that is statically composed with as many of its runtime
dependencies as are required to make the tool useful by default.  Maybe
we can even add an "inxi-full" package that is statically composed with
as many of its runtime dependencies as possible, for those who need inxi
to report even more information.

I believe that whenever we can avoid it, we should not require a user of
Guix to manually compose software together at runtime by manually
installing additional packages.  I believe this is true even when the
software in question assumes (like inxi tacitly does) that that is how
most people will want to compose the software with its runtime
dependencies.  This sort of runtime composition may be useful or even
unavoidable in certain cases (e.g., when a program uses the EDITOR
environment variable to run the user's preferred text editor), but it
can result in incomplete or incorrect deployment, so we should avoid it
when we can.

In any case, I can think of a few ways to package inxi:

* Wrap the inxi program with wrap-program, setting its PATH, PERL5LIB,
  and so forth appropriately.  This seems like the easiest way to me.
  
* Patch the absolute paths in the source with a patch file, a snippet,
  or an extra build phase.

* Ask the maintainer (or submit a patch to them) to provide a mechanism
  to explicitly tell inxi where its dependencies live (e.g., some kind
  of configure script), and then use that mechanism.  This seems like
  the hardest way to me, but it is also the most ideal.

I would be happy with any of those approaches.  I just want to make sure
that whatever we add, we don't burden most users by requiring them to
install additional packages just to make inxi work the way they wanted.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: inxi and inxi-full

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 3242 bytes --]


Chris Marusich <cmmarusich@gmail.com> writes:

> If we make two package definitions, I would prefer the name
> "inxi-minimal" for the version that is statically composed with the bare
> minimum of its runtime dependencies.  This is similar to how we have
> named other "minimal" packages in the past (e.g., qemu-minimal).

OK.

> I've taken a peek at inxi.  I assume it's this:
>
> https://github.com/smxi/inxi

Yes, sorry for not providing the link earlier.

> I see that it's a single perl script.  It runs various programs via
> Perl's "system" function in order to collate information about the
> system, and it then reports the results.  These programs - the runtime
> dependencies - are found via the PATH environment variable.  The script
> also embeds paths in some places that might need to be fixed.  For
> example, it looks like the get_gcc_data subroutine searches for gcc
> executables in the /usr/bin directory, which will not exist on GuixSD.

Thank you for the pointer to get_gcc_data.

The runtime dependencies are not exactly found by the PATH environment
variable: ENV{'PATH'} is set manually and explicitly in the source.
This is what I was discussing before (sorry if this was unclear).  Look
at the diff I mentioned earlier.  (Or look at line ~100 in the source.)

> If inxi-minimal can provide genuinely useful information without
> requiring the user to install additional packages, then I think it's
> reasonable to add a package definition for it.  However, if almost
> everyone is going to need to install additional packages into their
> profile just to get the output from inxi-minimal that they wanted, then
> I think we should not add it.

inxi-minimal would work.  It does provide some information.  The crucial
part here is that the set of optional dependencies is not bound to stop,
it could grow indefinitely.  inxi is sort of a platform for hardware
information.

Tracking them all could be hard.  Besides it might make inxi's closure
much bigger.  This needs testing though.

My suggestion: let's give inxi-minimal and inxi a try, compare their
closure size.  If it's not significant, then let's just have one single
package.


> In any case, I can think of a few ways to package inxi:
>
> * Wrap the inxi program with wrap-program, setting its PATH, PERL5LIB,
>   and so forth appropriately.  This seems like the easiest way to me.

That would not work, see my comment above.  PATH is hardwired in the program.

> * Patch the absolute paths in the source with a patch file, a snippet,
>   or an extra build phase.

This would be a lot of hard work: the file is 16k+ lines, `system` calls
are all over the place and lots of variable names contain the program
names in question (e.g. `my @xdpyinfo`), which prevents global substitutions.

> * Ask the maintainer (or submit a patch to them) to provide a mechanism
>   to explicitly tell inxi where its dependencies live (e.g., some kind
>   of configure script), and then use that mechanism.  This seems like
>   the hardest way to me, but it is also the most ideal.

Or ask the maintainer not to manually set the PATH variable.
I'll report the issue on GitHub.

--
Pierre Neidhardt

Five bicycles make a volkswagen, seven make a truck.
		-- Adolfo Guzman

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: inxi and inxi-full

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 3261 bytes --]

Pierre Neidhardt <ambrevar@gmail.com> writes:

> The runtime dependencies are not exactly found by the PATH environment
> variable: ENV{'PATH'} is set manually and explicitly in the source.
> This is what I was discussing before (sorry if this was unclear).  Look
> at the diff I mentioned earlier.  (Or look at line ~100 in the source.)

Ah, I see that you mentioned this earlier.  Sorry for missing it!  To
resolve this issue, we could do a few things:

* Ask upstream not to manually set the PATH environment variable, which
  you mentioned in your email.

* In the meantime, can't we just remove the offending line from the
  source?  This one:

  $ENV{'PATH'} = 'sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin';

None of those paths are guaranteed to exist on GuixSD.  If we remove
that line, then won't Perl's "system" function use whatever PATH is set
in the environment?  If, in addition to removing that line, we wrap the
script with our wrap-program procedure, then we will have full control
over the PATH, and inxi should work.

>> If inxi-minimal can provide genuinely useful information without
>> requiring the user to install additional packages, then I think it's
>> reasonable to add a package definition for it.  However, if almost
>> everyone is going to need to install additional packages into their
>> profile just to get the output from inxi-minimal that they wanted, then
>> I think we should not add it.
>
> inxi-minimal would work.  It does provide some information.  The crucial
> part here is that the set of optional dependencies is not bound to stop,
> it could grow indefinitely.  inxi is sort of a platform for hardware
> information.
>
> Tracking them all could be hard.  

I don't think it would be too hard if we use wrap-program.  In the best
case, somebody who cares about maintaining our inxi package would just
need to add a new input to the package definition every now and then.
The benefit is that inxi installed via Guix is complete and correct.

> Besides it might make inxi's closure much bigger.  This needs testing
> though.

The system, and users on the system, may have a lot of these programs
installed already.  For example, coreutils is certainly installed
somewhere.  It is likely that inxi's closure overlaps with some of those
already-installed tools.  Thanks to the functional software deployment
model that Guix follows, such overlap will automatically be
de-duplicated in the store.

So, I'm not too concerned about it.  But it would be good to check.

> My suggestion: let's give inxi-minimal and inxi a try, compare their
> closure size.  If it's not significant, then let's just have one single
> package.

Sounds good to me!

>> In any case, I can think of a few ways to package inxi:
>>
>> * Wrap the inxi program with wrap-program, setting its PATH, PERL5LIB,
>>   and so forth appropriately.  This seems like the easiest way to me.
>
> That would not work, see my comment above.  PATH is hardwired in the program.

If we remove from the source code the offending line that sets the PATH,
then I think wrap-program will probably work.

Thank you for taking the time to work on this.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: inxi and inxi-full

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1606 bytes --]


I've reported the issue upstream:

	https://github.com/smxi/inxi/issues/143

> * In the meantime, can't we just remove the offending line from the
>   source?  This one:
>
>   $ENV{'PATH'} = 'sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin';

As I initially suggested, this would work but we also need to change
@paths to the Guix PATH values.

> None of those paths are guaranteed to exist on GuixSD.  If we remove
> that line, then won't Perl's "system" function use whatever PATH is set
> in the environment?  If, in addition to removing that line, we wrap the
> script with our wrap-program procedure, then we will have full control
> over the PATH, and inxi should work.

Why would we need to wrap the program?  With the above fix, then we are
all good, aren't we?

Or is it to ensure that inxi does not see any other binary than the one
in its wrapped environment?  Then that would prevent inxi-minimal to be
"extended" by installing more programs.

> The system, and users on the system, may have a lot of these programs
> installed already.  For example, coreutils is certainly installed
> somewhere.  It is likely that inxi's closure overlaps with some of those
> already-installed tools.  Thanks to the functional software deployment
> model that Guix follows, such overlap will automatically be
> de-duplicated in the store.

Take for instance headless systems: those won't need the full mesa stack
to get information around their graphics capabilities.

--
Pierre Neidhardt

I hold it, that a little rebellion, now and then, is a good thing...
		-- Thomas Jefferson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: inxi and inxi-full

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 2980 bytes --]

Pierre Neidhardt <ambrevar@gmail.com> writes:

> I've reported the issue upstream:
>
> 	https://github.com/smxi/inxi/issues/143
>
>> * In the meantime, can't we just remove the offending line from the
>>   source?  This one:
>>
>>   $ENV{'PATH'} = 'sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin';
>
> As I initially suggested, this would work but we also need to change
> @paths to the Guix PATH values.

I see.  I think we should do that if upstream takes too long or if they
are not interested in changing their software.  It shouldn't be too hard
to surgically patch these lines of code - that's all we need to do,
right?

>> None of those paths are guaranteed to exist on GuixSD.  If we remove
>> that line, then won't Perl's "system" function use whatever PATH is set
>> in the environment?  If, in addition to removing that line, we wrap the
>> script with our wrap-program procedure, then we will have full control
>> over the PATH, and inxi should work.
>
> Why would we need to wrap the program?  With the above fix, then we are
> all good, aren't we?

If we do what you suggest, then all the "system" invocations should work
fine, but we'll still need to wrap the script so that it finds the
required Perl libraries.  For an example of how to do that, see the
definition of perl-image-exiftool in (gnu packages photo).

I'm actually a little surprised that the perl-build-system doesn't take
care of this automatically for us; we might want to fix that.  If you're
feeling ambitious, maybe you could submit a patch to add a phase to the
perl-build-system's %standard-phases that finds executable perl scripts
and wraps them automatically.

> Or is it to ensure that inxi does not see any other binary than the one
> in its wrapped environment?  Then that would prevent inxi-minimal to be
> "extended" by installing more programs.
>
>> The system, and users on the system, may have a lot of these programs
>> installed already.  For example, coreutils is certainly installed
>> somewhere.  It is likely that inxi's closure overlaps with some of those
>> already-installed tools.  Thanks to the functional software deployment
>> model that Guix follows, such overlap will automatically be
>> de-duplicated in the store.
>
> Take for instance headless systems: those won't need the full mesa stack
> to get information around their graphics capabilities.

If the average inxi user expects that they can add and remove programs
from their environment in order to get more or less info from inxi's
reports, then I wouldn't have much of a problem with letting inxi find
the programs dynamically at runtime.  However, if that isn't the case,
I'd still prefer a static composition over a dynamic one, for the
reasons I explained earlier.

You probably know about what inxi users expect than I do, since I've
never used inxi, so ultimately I'll defer to your judgment here.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: inxi and inxi-full

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]


Chris Marusich <cmmarusich@gmail.com> writes:

>> Why would we need to wrap the program?  With the above fix, then we are
>> all good, aren't we?
>
> If we do what you suggest, then all the "system" invocations should work
> fine, but we'll still need to wrap the script so that it finds the
> required Perl libraries.  For an example of how to do that, see the
> definition of perl-image-exiftool in (gnu packages photo).

OK.

> I'm actually a little surprised that the perl-build-system doesn't take
> care of this automatically for us; we might want to fix that.  If you're
> feeling ambitious, maybe you could submit a patch to add a phase to the
> perl-build-system's %standard-phases that finds executable perl scripts
> and wraps them automatically.

Sadly, I know next to nothing about Perl.  I'd rather leave this to
someone with some Perl knowledge.

> You probably know about what inxi users expect than I do, since I've
> never used inxi, so ultimately I'll defer to your judgment here.

Yes, inxi makes it very clear that it can be composed dynamically.
This is precisely how it's used on most major distributions I think.

	https://aur.archlinux.org/packages/inxi/

Cf. the documentation and the `inxi --recommends` output.

--
Pierre Neidhardt

Mirrors should reflect a little before throwing back images.
-- Jean Cocteau

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: inxi and inxi-full

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 245 bytes --]


Upstream turns out to be much more complicated than expected:

	https://github.com/smxi/inxi/issues/143

If anyone wants to chime in and try to convince the maintainer...

Otherwise we will have to go ahead and patch inxi.

--
Pierre Neidhardt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: inxi and inxi-full

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 6417 bytes --]

Pierre Neidhardt <ambrevar@gmail.com> writes:

> Upstream turns out to be much more complicated than expected:
>
> 	https://github.com/smxi/inxi/issues/143

I'm glad the maintainer responded so quickly!  It sounds like their
concerns can be summarized as follows:

1) It is a bad idea for GuixSD (and NixOS) not to follow the FHS [1].

2) The PATH environment variable does not reliably allow inxi to find
   the programs it needs at runtime, so inxi does not use it.  That's
   why inxi stores an explicit list of directories such as "/bin" in
   @paths and then calls check_program to find the (absolute, I think)
   path of a given program in that list of directories.

I respect their opinion, but I think that (1) is a red herring, and (2)
is incorrect.

Regarding (1), I don't think it's relevant whether GuixSD and NixOS
follow the FHS, but I'll voice my opinion here about why I think it
makes sense for us not to do so.  GuixSD follows the purely functional
software deployment model.  Distributions that use package managers like
dpkg or rpm do not.  For them, the FHS is helpful because their entire
system is built on the assumption that in order to achieve correct
deployment of software, their only option is to rely on the presence of
impurities from the environment.  The FHS is an attempt to ensure
correct deployment by getting everyone to agree to install the
dependencies in agreed-upon locations.  In a world where relying on
impurities is the norm, the FHS is certainly helpful.  I would do it,
too!

However, because we follow the functional model, a standard like the FHS
is unnecessary for us.  We exercise total control over our entire
dependency graph at (almost) all times.  Indeed, one could even argue
that a standard like the FHS is undesirable precisely because it
encourages the user to rely entirely on the presence of impurities
(which are not reliable!).  The functional model gives us a strong
guarantee for correct software deployment that we simply cannot get by
following a file system hierarchy standard like the FHS.  If you or the
author of inxi are willing to learn more about this, then I highly
encourage you to read at least the introduction (only 17 pages) of Eelco
Dolstra's Ph. D. thesis [2].  The introduction succinctly outlines the
problems that non-functional package managers like dpkg and rpm fail to
solve, and it outlines how Nix (and thus Guix) solve those problems.
After reading the introduction, I hope it will be clear why a standard
like the FHS is insufficient (and even possibly an impediment) for
ensuring correct deployment.

Regarding (2), regardless of whether or not a distribution follows the
FHS, I think any well written software should provide a mechanism to
allow its users to tell it where to find the programs that it needs.
It's fine for inxi to guess those locations when a user doesn't provide
them, but it shouldn't deny users the ability to give it hints.  The
PATH environment variable is one way that a user can tell a program
where its dependencies live.  Users put various directories on the PATH,
and then programs will find other programs by looking them up at runtime
via the PATH.

The author of inxi said that inxi does not rely on the PATH at all, but
that is not true.  Every time inxi runs Perl's "system" function to
execute a program by name only (not an absolute path), it is relying on
the PATH.  Here's a simple example from line 292 of the script:

	$b_irc = ( system('tty >/dev/null') ) ? 1 : 0;

Here, the "tty" program gets looked up in the PATH.  The author
mentioned that they are concerned that (a) PATH might not contain system
programs, (b) PATH might contain irrelevant user-defined programs, and
(c) PATH is sometimes not set.  To each of these concerns, I would say:

(a) If PATH does not contain system programs, then sure, you can try to
    find them by looking them up in well-known locations from the FHS.
    That would be a very reasonable thing to do.
    
(b) If PATH contains user-defined programs, that's great.  Some users
    might prefer to install their own copy of "tty" or "lspci" in a
    custom path.  The inxi script should use that copy if the user wants
    it to.  The PATH environment variable is one way to allow the user
    to do that, which is good.

(c) If PATH is not set, then inxi should set it to a reasonable default
    (e.g., the list that is currently being used for @paths).  That
    would be a very reasonable thing to do.

In any case, in GuixSD, all we need is a way to tell inxi where it's
programs live.  For many programs, this is accomplished by putting the
programs in PATH.  If inxi wants to provide a different way for us to
tell it where its programs live, that's fine.  For example, if they want
to provide an environment variable like "INXI_PATH", that's fine.  If
they want to use the Autotools to provide a "configure" script to allow
us to run something like "./configure --with-lspci=path/to/my/lspci",
that's fine, too.  Whatever works.  But it should be possible.

In the world of GuixSD, we have total control over all dependencies at
all times because we follow the purely functional software deployment
model.  As long as we define the inxi package correctly, we will never
be in a situation where inxi does not find its programs.  If inxi
provides us a way to easily tell it where its dependencies live (e.g.,
PATH), then we will use it.  Even if it doesn't provide an easy
mechanism, we can just patch the source with explicit paths to the
programs that it needs.  Most software provides a mechanism for users to
tell it what dependencies it should use (the PATH variable, a
./configure script, etc.), and it would be nice if inxi made it easy for
its users by doing the same.

> If anyone wants to chime in and try to convince the maintainer...

Since you're the inxi user, I'll leave that to you.  I hope I've helped
by giving enough information to clarify why GuixSD departs from the FHS,
and why inxi ought to let its users tell it where its dependencies live.

> Otherwise we will have to go ahead and patch inxi.

That is always an option.  We do it all the time, so it's nothing new.

Footnotes: 
[1]  https://refspecs.linuxfoundation.org/fhs.shtml

[2]  https://nixos.org/~eelco/pubs/phd-thesis.pdf

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: inxi and inxi-full

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1107 bytes --]


Chris Marusich <cmmarusich@gmail.com> writes:

> If you or the
> author of inxi are willing to learn more about this,

I hope you did not think I was on the inxi's maintainer's side!  :p

I understand and agree with all your points.

>> If anyone wants to chime in and try to convince the maintainer...
>
> Since you're the inxi user, I'll leave that to you.  I hope I've helped
> by giving enough information to clarify why GuixSD departs from the FHS,
> and why inxi ought to let its users tell it where its dependencies live.

Considering the maintainer's latest comments, I don't think he/she is
open to discussion.

It's too bad because I do not know any good alternative to inxi.  Maybe
it's time to solve this conky/i3status/inxi mess and roll out a
Lisp-programmable/extensible monitor/reporter.  What do you people think?

>> Otherwise we will have to go ahead and patch inxi.
>
> That is always an option.  We do it all the time, so it's nothing new.

I'll go ahead then.

-- 
Pierre Neidhardt

Nonsense.  Space is blue and birds fly through it.
		-- Heisenberg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

gnu: Add inxi (old Shell script version).

[Oleg Pykhalov]

[-- Attachment #1: Type: text/plain, Size: 506 bytes --]

Chris Marusich <cmmarusich@gmail.com> writes:

[…]

> In any case, in GuixSD, all we need is a way to tell inxi where it's
> programs live.  For many programs, this is accomplished by putting the
> programs in PATH.

It should be easy to accomplish with a wrapper for an old version of
‘inxi’, which is a Shell script.

I think we could use old version until a Perl version will be ready.
WDYT?

Patch is available https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31176

[…]

Oleg.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: gnu: Add inxi (old Shell script version).

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 362 bytes --]


Oleg Pykhalov <go.wigust@gmail.com> writes:

> I think we could use old version until a Perl version will be ready.
> WDYT?

From the last conversation with the developer, it does not look like the
Perl version of inxi will change much with regard to the PATH issue.

-- 
Pierre Neidhardt

Love means having to say you're sorry every five minutes.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Package requests: fortune, gifsicle, inxi, uncrustify, unrar, vsftp, xss-lock

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]


Pierre Neidhardt <ambrevar@gmail.com> writes:

> vsftp: 	Very Secure FTP daemon
> Upstream URL: 	https://security.appspot.com/vsftpd.html
> (It seems that there is not a single FTP server on Guix.  Strange... Can anyone
> recommend anything better than vsftp for file sharing?  Not necessarily
> FTP.)

Correction: There is an FTP server in the inetutils package.

-- 
Pierre Neidhardt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Package requests: fortune, gifsicle, inxi, uncrustify, unrar, vsftp, xss-lock

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1895 bytes --]


Pierre Neidhardt <ambrevar@gmail.com> writes:

>> vsftp: 	Very Secure FTP daemon
>> Upstream URL: 	https://security.appspot.com/vsftpd.html
>> (It seems that there is not a single FTP server on Guix.  Strange... Can anyone
>> recommend anything better than vsftp for file sharing?  Not necessarily
>> FTP.)
>
> Correction: There is an FTP server in the inetutils package.

And here is a system configuration to get an FTP server up and running
with inetutils:

(use-modules (GNU)
             ; ...
             (gnu services networking)
             (gnu packages admin))

(operating-system
 ; ...
 (users (cons* (user-account
                (name "ambrevar")
                (group "users")
                (supplementary-groups '("wheel" "netdev"
                                        "audio" "video"))
                (home-directory "/home/ambrevar"))
               (user-account
                (name "ftp")
                (group "nogroup")
                (home-directory "/home/ftp"))
               %base-user-accounts))

 (services (cons* (service
                   inetd-service-type
                   (inetd-configuration
                    (entries
                     (list
                      (inetd-entry
                       (node "127.0.0.1")
                       (name "ftp")
                       (socket-type 'stream)
                       (protocol "tcp")
                       (wait? #f)
                       (user "root")
                       (program (file-append inetutils "/libexec/ftpd"))
                       (arguments
                        '("ftpd" "--anonymous-only" "-l"))
                       )))))
                  %my-services)))


I'm now trying to figure out how to declare a service without starting
it when booting.  In the case of inetd, I want to start it manually:

  > sudo herd start inetd

Anyone?

--
Pierre Neidhardt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Package requests: fortune, gifsicle, inxi, uncrustify, unrar, vsftp, xss-lock

[Ricardo Wurmus]

Hi Pierre,

> Description: 	The RAR uncompression program
> Upstream URL: 	http://www.rarlab.com/rar_add.htm
> (Not sure about the licensing of this one: does not look free.  Is there
> any free way to extract RAR?)

This is not free software.  There was an unrar package, but it is no
longer maintained and it had accumulated a few security problems, so we
decided to remove it.

-- 
Ricardo

Re: Package requests: fortune, gifsicle, inxi, uncrustify, unrar, vsftp, xss-lock

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 615 bytes --]

On Thu, Apr 12, 2018 at 03:04:59PM +0200, Ricardo Wurmus wrote:
> 
> Hi Pierre,
> 
> > Description: 	The RAR uncompression program
> > Upstream URL: 	http://www.rarlab.com/rar_add.htm
> > (Not sure about the licensing of this one: does not look free.  Is there
> > any free way to extract RAR?)
> 
> This is not free software.  There was an unrar package, but it is no
> longer maintained and it had accumulated a few security problems, so we
> decided to remove it.

This discussion was in bug #28972:

https://bugs.gnu.org/28972

Apparently file-roller can handle some RAR files via libarchive.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Package requests: fortune, gifsicle, inxi, uncrustify, unrar, vsftp, xss-lock

[Clément Lassieur]

Pierre Neidhardt <ambrevar@gmail.com> writes:

> vsftp: 	Very Secure FTP daemon
> Upstream URL: 	https://security.appspot.com/vsftpd.html
> (It seems that there is not a single FTP server on Guix.  Strange... Can anyone
> recommend anything better than vsftp for file sharing?  Not necessarily
> FTP.)

There is SFTP, which is secure, and supported by GuixSD.  It's not FTP,
and it runs over SSH.

Re: Package requests: fortune, gifsicle, inxi, uncrustify, unrar, vsftp, xss-lock

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]


Clément Lassieur <clement@lassieur.org> writes:

> Pierre Neidhardt <ambrevar@gmail.com> writes:
>
>> vsftp: 	Very Secure FTP daemon
>> Upstream URL: 	https://security.appspot.com/vsftpd.html
>> (It seems that there is not a single FTP server on Guix.  Strange... Can anyone
>> recommend anything better than vsftp for file sharing?  Not necessarily
>> FTP.)
>
> There is SFTP, which is secure, and supported by GuixSD.  It's not FTP,
> and it runs over SSH.

My use-case is the following: share files with random people with
zero-configuration on their end.  Because FTP is supported by most web
browsers it is one of the most available options I think.

Any other suggestion?  There is Samba, but I'm not sure I'd like to dive
into that...

-- 
Pierre Neidhardt

The brain is a wonderful organ; it starts working the moment you get up
in the morning, and does not stop until you get to work.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Package requests: fortune, gifsicle, inxi, uncrustify, unrar, vsftp, xss-lock

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]

Pierre Neidhardt <ambrevar@gmail.com> writes:

> Clément Lassieur <clement@lassieur.org> writes:
>
>> Pierre Neidhardt <ambrevar@gmail.com> writes:
>>
>>> vsftp: 	Very Secure FTP daemon
>>> Upstream URL: 	https://security.appspot.com/vsftpd.html
>>> (It seems that there is not a single FTP server on Guix.  Strange... Can anyone
>>> recommend anything better than vsftp for file sharing?  Not necessarily
>>> FTP.)
>>
>> There is SFTP, which is secure, and supported by GuixSD.  It's not FTP,
>> and it runs over SSH.
>
> My use-case is the following: share files with random people with
> zero-configuration on their end.  Because FTP is supported by most web
> browsers it is one of the most available options I think.
>
> Any other suggestion?  There is Samba, but I'm not sure I'd like to dive
> into that...

I often start a HTTP server with `guix environment` for quick and dirty
network sharing of the current directory:

$ guix environment -C -N --ad-hoc python -- python3 -m http.server

I suppose "wget" would be able to mass-download.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Package requests: fortune, gifsicle, inxi, uncrustify, unrar, vsftp, xss-lock

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 458 bytes --]


Marius Bakke <mbakke@fastmail.com> writes:

> I often start a HTTP server with `guix environment` for quick and dirty
> network sharing of the current directory:
>
> $ guix environment -C -N --ad-hoc python -- python3 -m http.server
>
> I suppose "wget" would be able to mass-download.

This is absolutely fantastic!  Thank you so much for this!

Bye-bye FTP then :p

-- 
Pierre Neidhardt

Finster's Law:
	A closed mouth gathers no feet.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Package requests: fortune, gifsicle, inxi, uncrustify, unrar, vsftp, xss-lock

[Clément Lassieur]

Marius Bakke <mbakke@fastmail.com> writes:

> Pierre Neidhardt <ambrevar@gmail.com> writes:
>
>> Clément Lassieur <clement@lassieur.org> writes:
>>
>>> Pierre Neidhardt <ambrevar@gmail.com> writes:
>>>
>>>> vsftp: 	Very Secure FTP daemon
>>>> Upstream URL: 	https://security.appspot.com/vsftpd.html
>>>> (It seems that there is not a single FTP server on Guix.  Strange... Can anyone
>>>> recommend anything better than vsftp for file sharing?  Not necessarily
>>>> FTP.)
>>>
>>> There is SFTP, which is secure, and supported by GuixSD.  It's not FTP,
>>> and it runs over SSH.
>>
>> My use-case is the following: share files with random people with
>> zero-configuration on their end.  Because FTP is supported by most web
>> browsers it is one of the most available options I think.
>>
>> Any other suggestion?  There is Samba, but I'm not sure I'd like to dive
>> into that...
>
> I often start a HTTP server with `guix environment` for quick and dirty
> network sharing of the current directory:
>
> $ guix environment -C -N --ad-hoc python -- python3 -m http.server
>
> I suppose "wget" would be able to mass-download.

And there is 'woof' (packaged by Guix), it's a small HTTP server too,
very handy.  I use it very often at work to share files with my
collegues.  It serves the file only once unless specifed otherwise, and
'woof -U' provides an upload form, so that users can upload files
without having to install anything.  And it auto-tar directories.

Re: Package requests: fortune, gifsicle, inxi, uncrustify, unrar, vsftp, xss-lock

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 150 bytes --]


Woof seems even better!  Thanks for the suggestion!
Can't believe I never ran into this before...

-- 
Pierre Neidhardt

We are not a clone.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

File sharing with GNU Guix (was: Re: Package requests: fortune, gifsicle, inxi, uncrustify, unrar, vsftp, xss-lock)

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 2032 bytes --]

Pierre Neidhardt <ambrevar@gmail.com> writes:

> Clément Lassieur <clement@lassieur.org> writes:
>
>> Pierre Neidhardt <ambrevar@gmail.com> writes:
>>
>>> vsftp: 	Very Secure FTP daemon
>>> Upstream URL: 	https://security.appspot.com/vsftpd.html
>>> (It seems that there is not a single FTP server on Guix.  Strange... Can anyone
>>> recommend anything better than vsftp for file sharing?  Not necessarily
>>> FTP.)
>>
>> There is SFTP, which is secure, and supported by GuixSD.  It's not FTP,
>> and it runs over SSH.
>
> My use-case is the following: share files with random people with
> zero-configuration on their end.  Because FTP is supported by most web
> browsers it is one of the most available options I think.
>
> Any other suggestion?  There is Samba, but I'm not sure I'd like to dive
> into that...

Some people have already mentioned simple HTTP servers, which are an
easy ad-hoc option.  Other potentially interesting ways of sharing
files that seem to be available in Guix today include:

* scp
* rsync
* syncthing
* onionshare
* linuxdcpp
* nfs (see: nfs-utils)
* cifs (see: cifs-utils and samba)
* gnunet

I found some of these via:

  guix package --search='file.*shar|shar.*file' | recsel -p name,synopsis,description | less

All methods of sharing, even FTP, require some amount of configuration
on the client end, but obviously the question of what tools require
effectively "zero configuration" on the client end depends on the
situation.  If you've both got accounts on all the servers in question,
then scp is dead simple.

It would certainly be nice if somebody packaged an FTP server.  Until
then, I usually just use scp.  If you want to go super low tech, you can
even email large files by compressing them and splitting them with split
and cat (from coreutils).  I've done this in the past to get around
email size limitations; it's fun but a little tedious, and it depends on
the recipient knowing how to cat the parts back together.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: File sharing with GNU Guix (was: Re: Package requests: fortune, gifsicle, inxi, uncrustify, unrar, vsftp, xss-lock)

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 668 bytes --]


Chris Marusich <cmmarusich@gmail.com> writes:

> Some people have already mentioned simple HTTP servers, which are an
> easy ad-hoc option.  Other potentially interesting ways of sharing
> files that seem to be available in Guix today include:
>
> * onionshare
> * gnunet

I did not know those two!  While they don't really answer my needs, they
look fascinating!  I'll definitely explore more in that direction.

>
> I found some of these via:

>   guix package --search='file.*shar|shar.*file' | recsel -p name,synopsis,description | less

True so, guix search capabilities combined with recutils are enormously helpful!

-- 
Pierre Neidhardt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]