Puppy Linux Discussion Forum

EDIT: I've created a How-To for this installation here:
https://forum.puppylinux.com/viewtopic.php?t=6782
-------------------------------------------------------------------------------

I'm making an attempt to get Xrdp with sound on the Bullseye Iso just posted by Fred a few days ago. This time using the Griffon Xrdp Installation script version 1.4.3. This script is thought to be compatible with Debian 11, though still offered as experimental for that. Intended OS is Ubuntu.

I did a fresh frugal install of DD Bullseye on hd, using sg2d (thanks Clarity) from USB.

I downloaded the Installation Script and chose Custom install and Sound as options.

 ./xrdp-installer-1.4.3.sh -c -s

It needs to be run as a non-root user. I su'd to puppy.

Script aborted -I read through it and I found It also seems to expect to be run from the user's Downloads directory and uses that directory during compilation.

I created that directory in /home/puppy/. Tried again. Script aborted.

Ownership of Downloads folder was root, I changed it to puppy.

The script checks the version of OS and desktop version. Reading through the script again, it uses lsb_release as the discovery method with options. This wasn't aboard on DD Bullseye, so I

apt install lsb_release

Running the script again it gave options for desktop of openbox and jwm. I chose openbox, and it errored out as and unsupported OS and or desktop.

Reading the script again I figured out that the problem was that the two window managers were unsupported.

Finding stanzas referencing several desktop versions (gnome preferred, xfce cinnamon, etc), which I assumed were supported, I decided on LXQT as compact for a desktop, and one, which uses openbox and was already aboard.

I installed LXQTwith Synaptic.

Script ran extensively after those changes and I believe successfully created xrdp and xorgxrdp but stopped in the sound redirection option compilation with the following relevant errors:

[b]XDG_RUNTIME_DIR (/run/user/0) is not owned by us (uid 1000), but by uid 0! (This could e.g. happen if you try to connect to a non-root PulseAudio as a root user, over the native protocol. Don't do that.)
Connection failure: Connection refused
pa_context_connect() failed: Connection refused[/b]

   |-| Enabling Sound Redirection....    

       |-| Install additional packages..     
       	|-| Install dev tools used to compile sound modules..     

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
libconfig-dev is already the newest version (1.5-0.4).
0 upgraded, 0 newly installed, 0 to remove and 20 not upgraded.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'libsndfile1-dev' instead of 'libsndfile-dev'
autoconf is already the newest version (2.69-14).
build-essential is already the newest version (12.9).
dpkg-dev is already the newest version (1.20.12).
git is already the newest version (1:2.30.2-1).
intltool is already the newest version (0.51.0-6).
libjson-c-dev is already the newest version (0.15-2).
libcap-dev is already the newest version (1:2.44-1).
libsndfile1-dev is already the newest version (1.0.31-2).
libtool is already the newest version (2.4.6-15).
m4 is already the newest version (1.4.18-5).
libpulse-dev is already the newest version (14.2-2).
0 upgraded, 0 newly installed, 0 to remove and 20 not upgraded.
Reading package lists... Done
[b]E: Unable to find a source package for pulseaudio

       |-| Download pulseaudio sources files..     
Reading package lists... Done
E: Unable to find a source package for pulseaudio
       |-| Compile pulseaudio sources files..     
./xrdp-installer-1.4.3.sh: line 831: cd: /tmp/pulseaudio-14.2*: No such file or directory[/b]
       |-| Compiling and building xRDP Sound modules...     
fatal: destination path 'pulseaudio-module-xrdp' already exists and is not an empty directory.
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
libtoolize: copying file 'build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:12: installing 'build-aux/compile'
configure.ac:13: installing 'build-aux/missing'
src/Makefile.am: installing 'build-aux/depcomp'
autoreconf: Leaving directory `.'
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for ar... ar
checking the archiver (ar) interface... ar
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports the include directive... yes (GNU style)
checking whether make supports nested variables... yes
checking dependency style of gcc... gcc3
checking whether make supports nested variables... (cached) yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking whether make supports nested variables... (cached) yes
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-pc-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for mt... mt
checking if mt is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /usr/bin/ld -m elf_x86_64
checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking for gawk... (cached) gawk
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking how to run the C preprocessor... gcc -E
checking whether ln -s works... yes
checking whether make sets $(MAKE)... (cached) yes
checking for libpulse... yes
[b]configure: WARNING: PULSE_DIR may not be valid - can't find expected file
configure: PULSE_CONFIG_DIR not defined
checking Searching for config.h under PULSE_DIR... find: '/tmp/Temp-5238e34c-f4ff-45c2-89ed-e99d74eb44b9': Permission denied
no
configure: error: Can't find config.h under PULSE_DIR. Define PULSE_CONFIG_DIR?
make: *** No targets specified and no makefile found.  Stop.
make: *** No rule to make target 'install'.  Stop.[/b]

   !---------------------------------------------!
   !   Error while Executing compilation         !
   !   Sound Redirection failed...               !
   !   The Script is exiting....                 !
   !---------------------------------------------!

Hi vtpup, I have no experience with XDRP, probably cannot really help, so take below with a grain of salt.
I'm not surprised that you're having trouble with this as DD is not a full featured distro with all the bells and whistles, like e.g. Ubuntu.

The output of ./xrdp-installer seems to indicate that pulseaudio is required, install it with apt install pulseaudio. (and perhaps pavucontrol)
EDIT: or if you have pulseaudio already, it' may no be not properly started yet ? (as user puppy ?)

Also it *may* be required that you are logged in as "normal" user, e.g. puppy (or create new, and add to 'pulse' group). (pulseaudio can run as root, but not OOTB)
If still things aren't working as expected, you could try to make a build with option XFCE with mklive script (and add pulseaudio (and more perhaps) to the packages choice).

Thanks Fred, sounds like a plan!

I knew this was an iffy attempt, but I don't think it's impossible -- just have to figure out what is needed. I thought the script pulled in pulse audio if needed, but apparently didn't manage to. I'll do it as user puppy externally and see if that works. Your compile option for DD Bullseye is also a possibility, but I'll try getting this working on the ISO version first.

Looks like Pulse Audio was installed already to latest by script. I think the problem might be that it can't find sources for it.

I'm doing some further checking on the error messages....

vtpup wrote:

It needs to be run as a non-root user. I su'd to puppy.

Some more thoughts (as I said earlier, untested):
Probably you got the point already, but just saying, could be that pulseaudio should be started and configured as 'puppy' (if su'd to puppy).
May be needed to add puppy to the pulse group usermod -a -G pulse puppy and login (and start the Desktop) as user 'puppy' (or other unprivileged user). (Exit X > type 'login' > type 'puppy' and type password (= puppy by default).
(EDIT: not sure if pulseaudio is started (when doing above) on Openbox, if not, you can run pulseaudio --start)

Got it fixed!

Problem was that sources repos were commented out in /etc/apt/sources.list uncommented and the compile script ran to completion.

vtpup wrote: ↑Sat Sep 10, 2022 4:31 pm

Got it fixed!

Problem was that sources repos were commented out in /etc/apt/sources.list uncommented and the compile script ran to compltion.

Okay, great, I assume you mean the commented deb-src lines in /etc/apt/sources.list.
So do you have xdrp working now as expected ? (or just a start of fixing problems).
EDIT; Asking too soon probably, take your time!

Thanks Fred! Just tested.

I had to shut down and reboot cold
instead of systemctl status I had to use service to start

service xrdp start

xrdp started and I ran peasyport on client for 3389 to discover. It was on 192.168.1.16
So I started remmina on my bionic64 client and successfully connected
ran pupradio and had sound.

Works!

vtpup wrote: ↑Sat Sep 10, 2022 4:48 pm

Thanks Fred! Just tested.

I had to shut down and reboot cold
instead of systemctrl status I had to use service to start

Code: Select all

service xrdp start

xrdp started and I ran peasyport on client for 3389 to discover. It was on 192.168.1.16
So I started remmina on my bionic64 client and successfully connected
ran pupradio and had sound.

Works!

Very nice I think @Clarity will like this too, as he asked me through PM about the progress of running xrdp on DD.
EDIT: Would you mind writing a small how-to in new topic about the steps you did to accomplish running XRDP ?

Okay Fred will do.

How-To located here:

https://forum.puppylinux.com/viewtopic.php?t=6782

@vtpup, @wizard and @fredx181 I think together we can bring this technology to this community and it will be enormously appreciated for those of us who see so much value in using these powerful PCs we have in a home while not needing to run multiple OSes of individual PCs.

I foresee doing, in the home, what has been done in classrooms by MS and business using MS products to serve multiple users with 1 single OS as if each PC was running its own OS. The users wont know any difference if implemented smartly.

There are multiple thin-clients OSes available that are loadable on every PC since 2000. And preconfigured thin-client terminals that can be had for as little BTW:as $25 (ca) if not given away for the asking.

I think this is the making of "Admin Heaven" for some who reimpementedcognize the advantage of this on a PUP.

I have a 9 year-old dual-processor multi-threaded 16GB Xeon that I will be relegating to a DD (DevLive)/KLV "Terminal Server" sometime in the coming weeks when the TV-monitor arrives to replace the one that died.

Further, I wonder if the base serving could be "PET'ed"/packaged for use or implemented in an OOTB ISO..

Will post as soon as it can be setup.

BTW: For the couple of us who have MS Server solutions, this means with this, they are replaceable with this Puppy Forum Linux solution for home use. Additionally, with this solution, SSH could be avoided as well.

Lastly, once testing is complete, with a write-up, this could/should be announced to the XRDP community as it may attract users to this forum to increase Puppy membership and participation.

Quite frankly Clarity I'm seeing an unfortunate disconnect on this forum between "Puppy Linux" and "Dog Linux" I think that is problematic and artificial, the issue came up last night when my how-to was moved from the How-To>networking section to here in the Debian Dog section. Without request, I should add.

The reason offered was that Dog discussion was not allowed in the How To section. As 13+ year user of Puppy linux, I find this distinction artificial and counterproductive to the entire Puppy community. To me (and I use it) Fossapup bears relatively little resemblance to Barry Kauler's Puppy Linux, and no greater claim to legitimacy than the recent DD varieties.

Consider: Puppy Linux -- I started with a late 3 series Puppy and stayed true to BK versions right through Racy, which I used for many years. These versions were specifically designed to be sized at under 100 megabytes, strove to be compaible with much older equipment, maintained a connection with Slackware apps but featured standard puppy adapted apps including Seamonkey browser, used .pups or .pets, and later .sfs specifically developed for Puppy.

Fossapup: Supposedly the "flagship" Puppy Linux. For the record I use it now occasionally, and Bionicpup64 is my daily driver. I used Tahr pup for years. But NONE of these included Seamonkey as default maintaine slackware connection, was under 100 megabytes, and Fossapup is hardly an OS for 32 bit, much less older computers.

These Ubuntu related "mainline Puppies" supposedly use Ubuntu repositories for additional apps, but this function is tenuous, and the number of appimages and portable apps now in use attest to the partial connection to Ubuntu, which itself now relies on Debian for apps. One of the major difficulties in the translation is that Fossapup is (sort of) a single user OS with very different permissions and ownership structures than Ubuntu, so translation from one system to the other is often flawed, or impossible, as is the case with Xrdp.

Supposedly the one consideration that makes an OS a "Puppy" is using Woof (now WoofCE, further removed) as an originating construction tool. Otherwise anything goes. You can use any other OS's source, and add in any other apps you care to, and still call it a "puppy." Well that's a relatively new concept. Why should Woof be the only characteristic and definition of completely unrelaated and incompatible operating systems? By that inflexible definition early puppies are not puppies.

To me, the recent DDs (and I have used them for 2 days only!) are no less related to the early puppies in their overall philosophy than Fossapup now is. The DDs are small, efficient, use similar if not the same puppy applications, are live, can run in RAM, use an overlay structure, and depend on Debian repositories (and DDs to a greater level of compatibility). They can be produced by a similar construction tool to WoofCE (though more easily for the less experienced) They are adaptable to sfs, .pet. apps, and can run portables and appimages like Fossa.pup.

The ONLY real practical difference between what mainline Ubuntu based puppies have evolved into (away from the original puppy line), and DD "Dogs" is that Fossapup is a single user system and DD's are multi-user.

To me this IS an important distinction, but not one that should fundamentally divide forum users. I think our concepts should be re-formulated into thinking of Single-User Puppies, and Multi-User Puppies. In fact back in the old days Pizzasgood was working toward a multi-user puppy, and I'm sure it would have been called a puppy.

I don't think the forum How-To section should be limited to ONLY entries by any Woof created mongrel OS, and blocked from providing How-Tos from what I see as multi-user puppies like DD Bullseye. I think forum users actually appreciate a diversity of implementation that maintains basic Puppy philosophy and structure, rather than insisting on one single production tool to define what is and isn't a puppy. I think a change in perception would be healthier and encourage more newcomers and and fresh impetus and new developments.

I see no conflict between maintaining single-user puppies and multi-user puppies under the same puppy banner, and I think each could (and even now does) benefit from developments in the other. Neither will replace the other -- it's not a competition between rivals. There are reasons to run single user puppies -- I know I will probably always do that as a daily driver for its simplicity and power. And reasons to use multi user-puppies -- in server environments especially, where ONLY they are suitable (as is the case of Xrdp). Many pieces of software REQUIRE a multi user OS, and the full fledged mainline Linux distros simply don't offer what multi-user puppies can -- simplicity, efficiency, speed, low resource use, and adaptability

Well, long post, but I was pretty frustrated last evening by the apparent territoriality that I think is counterproductive to the advancement of the OS I care about: Puppy Linux. I hope there will be a change rather then further division as a result. Creating sides in an issue is NOT my intent. I want to see true community return.

I agree. And I don't know why the topic was moved from the How-To since it made perfect sense to be there because it's a How-To.

I see waning interest in Puppy Linux which seems stuck at Fossapup64. Even the main "stewards" do not participate in the community that often if at all
Facts are facts and I see all of the statistics and those signal that Puppy Linux forum is not attracting many users to Puppy Linux distro's as it once did. Puppy is stuck basically at Fossapup64. The VoidPup is strong but not worked on as much and not so polished. I have not even booted anything Puppy newer than Fossapup or VoidPup.