I don't know if this is supposed to be an exclusive "announce" thread or not, but I do have a support request and I think this is the best place to put it.  If it needs to be in a thread of its own, please move it.

I have a webscript that requres the package php-recode.  When I try to install php-recode, I get this:

root@FC-srv:/home/nixer# apt install php-recode
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 php-recode : Depends: php7.4-recode but it is not installable
E: Unable to correct problems, you have held broken packages.
root@FC-srv:/home/nixer# apt policy php7.4-recode
php7.4-recode:
  Installed: (none)
  Candidate: (none)
  Version table:
root@FC-srv:/home/nixer# 

The package php7.4 is missing.  Can it be created or am I not finding it?  I am using the tdrnetworks php builds.
The package php7.3 is present, but I am not running php version 7.3.  I did a web search and I don't see any mention of "recode" being deprecated in version 7.4.

At the request of the site owner, it was taken down a few months ago after being online for about four years.

But here is the photo that I used to get the site colors from.

I don't even have a screenshot of the site before I took it offline, sorry.  I even checked a few web archive sites to see if they had it, but can't find it, nor does google have it.

Nice to know and thanks again.  My friends install was originally a jessie install from 2016, updated to ascii, and now to beowulf.  His system is powered by an amd processor, hence, this is why I installed that firmware on it. 

I use the refractasnapshot script on other amd and intel powered cpus with and without the amd64-firmware package, and I have never had this problem.  I do not know why he has it, yet.  Maybe something will show later on, but I don't know now.

Appreciate your help!

I was hoping it would be an easy fix, but not yet.  xz-utils is already installed

I got it working.  The major problem that I had was that the entry in both the sshd_config file on the remote system and the ssh_config file on the local system had the entry as the default:

XAuthLocation $HOME/.Xauthority

It would not work with this entry in either file.

So I changed this entry in both files to:

XAuthLocation /usr/bin/xauth

And it works.

So for anyone that runs across this thread, I will put the config entries in both the files that are working now.

On the remote sshd_config file, I have:

X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
AllowTcpForwarding yes
XAuthLocation /usr/bin/xauth

On the local system and its ssh_config file, I have in the  ~/.ssh/config  file:

Host IP_ADDR
    ForwardAgent yes
    ForwardX11 yes
    ForwardX11Trusted yes
    XAuthLocation /usr/bin/xauth 

To use, I open a terminal window and enter the Xephyr command to open a blank and black window:

Next, enter the command to ssh into the remote box and forward the xsession to display two on the local machine:

Lastly, in the same terminal window which is now showing connected to the remote machine, I entered

startxfce4

And it works.

Thanks for responding rr.  I have never needed xvfb before and up until now I have never seen it mentioned as being a dependency or needed for nested xsessions. 

This is an example of what I have used in the past:
https://nek0.eu/posts/2014-10-25-Deskto … ephyr.html
or
https://www.dedoimedo.com/computers/xephyr.html

But this depends on Xforwarding successfully working, which I am getting errors on at the moment.  Thanks again.

Just throwing an idea or two out, if you want it to refer to Devuan hacks

If you want it to refer to systemd hacks or workarounds,

IMHO, this does not deserve a capital "D"... (-;

Perhaps,

"KISS Hacking"
"Simple Hacks"

FWIW - for what it's worth, I just migrated from Kali to Beowulf using the kali netinstall.iso.

Using the instructions on this page, I only slightly deviated from these instructions.

To keep it short and sweet, I -
- updated the kali install, added devuan's sources in sources.list, commented out the kali sources

(will get errors, do not reboot)

This is the extra step not noted on the link above.  sysvinit-core did not get pulled in

- alter /etc/network/interfaces to rename en0ps (??) to eth0

- check with command

Returns nothing, so sysd here.

I downloaded the kali virtualbox file and will try this out on it now.  Will report back.

Edit:
While the netinstall.iso worked, the full kali install did not.  At least I got a dead end.  Now I see above why the recommendation above was to start at ceres and see what broke. 
A current kali to beowulf migration was not successful in large part because kali uses a newer version of dbus.  An attempt to use ceres or chimaera may be more successful.

And trying to downgrade dbus to devuan's version resulted in 934mb of packages to be removed.  Oh well, it was fun trying.

+1

Start with a minimal build, customize it, rebuild with refracta-tools, and you have your server OS ready to install wherever you want it.  Servers usually don't use that many installed programs, so a few apt commands to install what you need is not much work.  For me, it takes longer to configure what I install than to install what I need.  I do save my configuration files though, naturally.

tdrnetworks,

With jessie support scheduled to end June 30, 2020 (5 days from now), what is your plan for the jessie php builds?  Will you continue to build them after this date?

Do you have any plans to build php for Chimaera (current testing) any time soon?

I, and others, appreciate you building and offering your php builds to devuan.  Thank you.

Try it with http:// instead of https://.  I don't know this but I think there may be a problem with the ssl cert.

I saw this error yesterday and used the above workaround, and it worked.

+1

From reading about gocryptfs, it was started by a person who assisted with EncFS, who wanted to address the security vulnerabilities in it.  Thus, gocryptfs was born.  A couple of additional facts about it:

First, it pulls in no dependencies.  I can pin a particular version and run it in Ascii, Beowulf, Chimaera, and Ceres and mount/use the same remote nextcloud instance in all versions.
Second, with the -config option, you can use gocryptfs to mount a remotely encrypted folder which is decrypted locally, then the files will be automatically stored encrypted in the mounted remote location.  EncFS did this, and so does gocryptfs.

I have been using it a while now, and really like it.