Rolled back to gtk2 version of yad

EasyOS is staying with the gtk2 version of 'gtkdialog', in fact, I am hanging onto gtk2 apps indefinitely.

Today it was brought to my attention that 'yad', as compiled in OpenEmbedded, is linked with gtk3. There are some issues, for example here:

http://forum.puppylinux.com/viewtopic.php?p=36923#p36923

It was a pleasant surprise that although yad now links with gtk3. the gtk2 version is still maintained, for Fatdog64:

https://github.com/step-/yad

So, I have created a recipe for it in my EasyOS layer in OpenEmbedded, and named the package 'yad0'. Compiled it for amd64 and aarch64, and changed the package-list in woofQ to build with 'yad0' instead of 'yad'.

The maintainer is "step-", don't know who that is. Will have to send him/her a message that his/her maintenance project is now in EasyOS, from version 3.0.   

Tags: easy

Chromium SFS runs as user chromium in EasyOS 3.0

Yay, works great!

I downloaded one of peebee's Chromium SFSs, and copied the contents to a folder named 'chromium_93.0.4577.63-bk1_amd64'. I changed usr/lib64 to usr/lib, usr/bin/chromium to a symlink to usr/lib/chromium/chromium, and made sure that usr/share/pixmaps/chromium.png (48x48) exists. Then ran 'dir2sfs':

# dir2sfs chromium_93.0.4577.63-bk1_amd64

...this has to be done in EasyOS 3.0, which is not yet released.

A few GUI windows popup, including asks if want to default to run chromium as a non-root client -- I clicked the "YES" button, and a SFS was created. Copied it to /mnt/wkg/sfs/easyos/oe/dunfell, then from the menu "Filesystem -> Easy BootManager", chose to add the Chromium SFS at bootup. Then rebooted.

Some notes, with pictures, on using 'dir2sfs' can be found here:

https://easyos.org/dev/how-to-run-a-linux-distribution-in-a-container.html

...though in this case we aren't interested in the container parts of that page.

After rebooting, looked in /clients:

And looked in /clients/chromium:

...Chromium will only be able to save files inside /clients/chromium, and defaults to /clients/chromium/Downloads.

I chose "Internet -> Chromium web browser" from the menu, and Chromium works. Chromium can also be launched by typing "chromium" in a terminal window, or by clicking on the icon in the above window.

I haven't checked, but sc0ttman's "Default Applications Chooser" is in the "Setup" menu, and it should be possible to choose Chromium as the default web browser, so when you click on the "www" icon on the desktop, Chromium will run.

This is good. For those who haven't followed earlier blog posts, this has nothing to do with containers. Chromium SFS is running on the main desktop, as non-root user 'chromium' and group 'chromium'. This provides excellent security.

However, Chromium could also be run in a container, and I will investigate this next.

The Chromium SFS requires EasyOS 3.0 or later, so those who are keen to use Chromium in the Dunfell-series will have to wait a little while! It will of course be available via the "sfsget" icon on the desktop.    

Tags: easy

Infrastructure in place to run each app as a separate user

The 'spot' user was broken in EasyOS, for the situation in which a password is entered at bootup and folders in the working-partition are encrypted. After some experimenting and lucky guesses, this problem was solved, see previous blog post:

https://bkhome.org/news/202109/fscrypt-now-works-in-user-spot.html

I have now embarked on a significant change in how EasyOS works: run any app that accesses the Internet as a non-root user. Not 'spot', but each app will run as its own user.

I got this idea a couple of years ago, when reading how Android works. This is how Android works, each app runs as a separate user. This then can be the basic mechanism for access permissions. For example, if file /etc/group has a group for "camera", like this:

camera::118:root,spot

...on the end is a comma-delimited list of users allowed to access the "camera" group.

Running an app as a non-root user also means that it can't write just anywhere in the filesystem, can be constrained to only write in its own home folder. And if required, can be prevented from reading critical files.

Of course Easy already has "crippled root" in containers, so running, say, SeaMonkey, on the main desktop as a non-root user would have to be seen as an alternative security strategy. SeaMonkey will run a little bit faster, and won't have the issues that some people have reported with running SM in a container, such as problem with network connectivity.

If each app is run as its own user, this means that EasyOS can implement a permissions management GUI like in Android. Like, do you want this app to be able to access the camera, network, audio, folders outside the "home" folder? ...etc.

So, have started to setup the infrastructure to support this. The idea is that top-level /clients folder will have these non-root users, though I would like to refer to them as "clients".

WoofQ is now defaulting to run SeaMonkey as a client. That is, it will run as user "seamonkey" and group "seamonkey". So, in woofQ, have built EasyOS, and running it, this is what is seen under /clients folder:

...'rover' and 'zeus' were experiments, they may get removed. 'spot' is deprecated, may also get removed.

The idea is that each client app will have a folder under /clients, which is actually the home-folder for that app. Clicking on 'seamonkey' will show what that client has to "offer":

The 'Downloads' folder is SeaMonkey's default file download and open location. Clicking on the 'seamonkey' icon will run SeaMonkey. I don't know what 'Desktop' folder is for, SeaMonkey created that automatically.

Of course, SM can still be launched in the usual way, from the "www" icon on the desktop, or via the menu. And it will run as a client, that is, as user 'seamonkey'.

As before, SeaMonkey can be changed to run either as a root user, or client 'seamonkey', via the menu "System -> Login & Security Manager". Just like before, with 'spot'.

There is a file that shows what apps are running as a client, it is file /root/.clients-status. Here it what it has on my currenly running EasyOS:

seamonkey=true

Which means that SM will run as a client. If it had "seamonkey=false", or seamonkey completely missing from the file, then SM will run as root. The "Login & Security Manager" writes to this file.

Scripts for client management are now grouped under /usr/local/clients. WoofQ runs one of these, 'setup-client', when building EasyOS, if it is chosen to run SM as a client. The main thing that the script does is create a special script for running SM, /usr/bin/seamonkey (and the original is renamed to seamonkey.bin). Here is the script:

#!/bin/sh
APPbin='/usr/bin/seamonkey.bin'
APPname='seamonkey'
DISPLAY=:0
[ -f /clients/seamonkey/.mozilla/seamonkey/a2bvafqx.default/places.sqlite ] && ln -snf /usr/lib/seamonkey/seamonkey /usr/bin/seamonkey.bin
#script to run $APPbin as a client...
ARGS=""
if [ $1 ];then
 while [ "$1" ]
 do
  #do not put quotes around if a single word. example is "-edit" for seamonkey, the quotes stuff it up entirely...
  if [ "${1/ /}" == "${1}" ];then
   ARGS="${ARGS} ${1}"
  else
   ARGS="${ARGS} \"${1}\""
  fi
  shift
 done
fi

if [ $(id -u) -ne 0 ]; then
 exec "$APPbin" $ARGS
fi
#if inside a container, do not run as client...
if [ -f /INSIDE_* ];then
 exec "$APPbin" ${ROOTOPTS} ${ARGS}
fi

#this is a method to authorize x server to run by user. works when server running.
#note: this setting does not seem to be stored in a file. it affects the currently
#      running x server and will be lost when x quits.
ALLOWflg="$(xhost | grep -o ":${APPname}$")"
if [ ! "$ALLOWflg" ];then
 xhost +SI:localuser:${APPname}
fi

[ $XAUTHORITY ] && cp $XAUTHORITY -f /clients/${APPname}/.Xauthority 2>/dev/null
touch /clients/${APPname}/.Xauthority
#following line is mostly there to catch any root:root files that may have got copied in...
chown -R ${APPname}:${APPname} /clients/${APPname} &
sleep 0.1
export XAUTHORITY=/clients/${APPname}/.Xauthority  
export XDG_CONFIG_HOME=/clients/${APPname}/.config
export XDG_CACHE_HOME=/clients/${APPname}/.cache
export XDG_DATA_HOME=/clients/${APPname}/.local/share

#20210912 need to allow write inside encrypted fs...
which keyctl >/dev/null
if [ $? -eq 0 ];then
 IDflg="$(grep -o " logon " /proc/keys)"
else
 IDflg=""
fi
if [ "$IDflg" ];then
 exec su -l ${APPname} -s /bin/sh -c "DISPLAY=${DISPLAY} /usr/local/clients/run-client-indirect \"$APPbin\" $ARGS"
else
 exec su -l ${APPname} -s /bin/sh -c "DISPLAY=${DISPLAY} \"$APPbin\" $ARGS"
fi

This is the content of /usr/local/clients/run-client-indirect:

#!/bin/sh
#when running in fscrypt encrypted folder, need to run this so as
#to enable write-permission when logged into a non-root client.

APP="$1"; shift
ARGS=""
#[ $1 ] && while [ "$1" ]; do ARGS="$ARGS \"$1\""; shift; done
if [ $1 ];then
 while [ "$1" ]
 do
  #do not put quotes around if a single word. example is "-edit" for seamonkey, the quotes stuff it up entirely...
  if [ "${1/ /}" == "${1}" ];then
   ARGS="${ARGS} ${1}"
  else
   ARGS="${ARGS} \"${1}\""
  fi
  shift
 done
fi

ID="$(grep " logon " /proc/keys | head -n 1 | cut -f 1 -d " ")"
if [ "$ID" ];then
 keyctl link 0x${ID} @us #link fscrypt key to user-session.
fi

exec ${APP} ${ARGS}
###end###

Have posted these technical details for whoever is interested, but from the user perspective, you just want it to work, and be easy to use.

Well, it should be easy. SeaMonkey works as normal, except that cannot save files outside its home, /clients/seamonkey. Not by default anyway.

By means of the "Login & Security Manager", you should be able to select any app to run as a client.

Testing with SeaMonkey, all is good, except for the Composer module. I use this regularly, and want to be able to edit html files anywhere. Not quite sure how to handle this -- might setup SeaMonkey-Composer to run as root only.

There are some issues to resolve, so it will be awhile before the next release. It is likely that the next release of EasyOS will have a version bump to 3.0.

I have got Chromium SFS running as a non-root user. This was a problem, see earlier posts. Will probably have it default to run as a client, so there will be a folder /clients/chromium, just like have for SM.

So, what to choose? Do you run SM as a client on the main desktop, or as "crippled root" in a container. Or... this is a possibility, run SM as a non-root client inside a container -- I don't yet know if that will work, but it sure would be the ultimate in security.  

Tags: easy

Fscrypt now works in user spot

Continuing from yesterday:

https://bkhome.org/news/202109/fscrypt-broken-in-user-spot.html

Analysed it a bit more. In the 'init' script in the initrd, /proc is getting mounted like this:

mount -o hidepid=1 -t proc none /proc #20210407

That "hidepid=1" is a security feature, which seemed like a good idea at the time. I think a repercussion is, when login as spot, it won't see all of root's /proc.

To get around this, I have created a new group, in /etc/group:

fscryptgrp::118:root,spot

Then I changed the mounting of /proc in the 'init' script:

mount -o hidepid=1,gid=118 -t proc none /proc #20210407 20210912

...this disables the "hidepid=1" for any users belonging to group "fscryptgrp".

I now have fscrypt working, but had to do a few more things... writing it down here, as just got it working, and want to record exactly what I did! Here we go...

As root, did this:

# keyctl show
Session Keyring
   5898855 --alswrv      0 65534  keyring: _uid_ses.0
 382717390 --alswrv      0 65534   \_ keyring: _uid.0
 448736447 --alsw-v      0     0   \_ logon: ext4:6db5ac6afa4a5042
# keyctl setperm 448736447 0x3f3f3f3f
# keyctl chgrp 448736447 118

...I don't know if changing the permissions to "0x3f3f3f3f", which means everything enabled, is necessary.

Now login as spot:

# su -l spot
# cat /proc/keys
02547b7e I--Q---     1 perm 1f3f0000   502 65534 keyring   _uid_ses.502: 1
1abf2cbf I--Q---     1 perm 3f3f3f3f     0   118 logon     ext4:6db5ac6afa4a5042: 72
341d39dd I--Q---     2 perm 1f3f0000   502 65534 keyring   _uid.502: empty
# keyctl link 0x1abf2cbf @us
# ls -a
.   .cache   .didiwiki  Downloads  .local      spot.png   .Xauthority
..  .config  .DirIcon   .history   README.txt
# echo 'abc' > testfile1
# cat testfile1
abc

...yay!    

Tags: easy

Fscrypt broken in user spot

I have posted about being unable to get Chromium and Chrome to run as user spot:

https://bkhome.org/news/202109/cannot-run-chromium-browser-as-user-spot.html

It turns out that there is a fundamental problem in EasyOS. If a person entered a password at the very first bootup, Easy creates encrypted folders in the ext4 working-partition. So, if anyone steals your usb-stick or hard drive, they won't be able to access the files in those folders.

The encryption mechanism works on a per-folder basis, and the init script in the initrd will unlock those folders when the correct password is entered at bootup. It works great, however, falls apart if login as a non-root user...

I have a utility, 'keyctl', from the 'keyutils' package. I have today compiled that in OE and added it to the package list, so it will be in future releases of EasyOS. It is for managing the kernel keys. I know hardly anything about this topic, but let's explore...

# keyctl show
Session Keyring
1025593870 --alswrv      0 65534  keyring: _uid_ses.0
 668976992 --alswrv      0 65534   \_ keyring: _uid.0
 291187953 --alsw-v      0     0   \_ logon: ext4:6db5ac6afa4a5041
# ls -a /root/spot
.   .cache   .didiwiki  Downloads  .local      spot.png
..  .config  .DirIcon   .history   README.txt  .Xauthority

That highlighted entry looks like the encryption of the ext4 filesystem. OK, now let's login as spot:

# su -l spot
# keyctl show
Session Keyring
 766538552 --alswrv    502 65534  keyring: _uid_ses.502
 676258719 --alswrv    502 65534   \_ keyring: _uid.502
# pwd
/root/spot
# echo 'abc' > testfile1
-sh: testfile1: Required key not available
# ls
6rW37WId+lKMnweIIvtagzdl6yDbnlwV  oqjFdCBsfmOhji42Vcl25rPB11d8rQhm
8njV2L9wUPwq00z9kbB9h5gewrv31HGY  README.txt
adx4yf4hAOVnM2cVKKvWawXQLPXCBMOz  spot.png
cTXh+5oKTshqUql5A30nVWaCWTLObsx2  UCUPdY5gOs0rEYI,6tpi9Ap,n7nh4ppB
Downloads                         Y09MYYqmfJzqU7sPrUbUDnuZV55Dctsp
E3lquNhL1RiXxPvFoSUWSW87Q77hnI8A  yCXJJnoom8XbLB65uNAZ,anhMcUHIV+W
k9ve6dS0fixgrADNHU,eS9YMXJpljvCt
# 

Now isn't that interesting!

It seems that the ext4 filesystem key is not available when logged into spot.

Note that "ls" does list some files and one folder correctly. The others are encrypted.

So, the big question, how do I activate that "ext4:6db5ac6afa4a5041" key when logged in as spot?

I haven't solved this yet, as don't know much about kernel keys, how they work and how to manage.

EDIT:
Progress! Was reading the 'e4crypt' man page:

https://man7.org/linux/man-pages/man8/e4crypt.8.html

 e4crypt add_key [-vq] [-S salt ] [-k keyring ] [ -p pad ] [ path
       ... ]
              Prompts the user for a passphrase and inserts it into the
              specified keyring.  If no keyring is specified, e4crypt
              will use the session keyring if it exists or the user
              session keyring if it does not.

'e4crypt' is a utility in the 'e2fsprogs' package. It is compiled statically and used in the initrd to create the encrypted folders. What turned on the lights for me is this: "e4crypt will use the session keyring if it exists or the user session keyring if it does not".

"user session" is the root user. The 'keyctl' utility has names for these: "@s" and "@us". The session keyring should be available if I login later on as spot. Let's find out...

# keyctl link @s @us
# su -l spot
# pwd
/root/spot# keyctl show
Session Keyring
 766538552 --alswrv    502 65534  keyring: _uid_ses.502
 676258719 --alswrv    502 65534   \_ keyring: _uid.502
# echo 'abc' > testfile1
-sh: testfile1: Required key not available
# whoami
spot
# ls -a
.   .cache   .didiwiki  Downloads  .local      spot.png
..  .config  .DirIcon   .history   README.txt  .Xauthority
# 

The improvement is that the folders are now unencrypted, but still cannot write a file.

EDIT 2021-09-12:
Ignore that "keyctl link @s @us", I was just learning, don't think that does anything.

Have got fscrypt to work in spot, see next blog post:

https://bkhome.org/news/202109/fscrypt-now-works-in-user-spot.html       

Tags: easy

Xarchive now extracts DEBIAN control folder

Jon (scsijon in the Puppy Forum) is helping me to get Chrome and Chromium working non-root. This has resulted in me making a discovery yesterday, about the Xarchive archiver and extraction GUI tool.

Jon downloaded a Chrome 64-bit DEB file, and clicked on it, in a running EasyOS 2.9, to install it. The PETget installer, if sees a post-install script, will execute it. Then he got it working as user 'spot'.

He emailed instructions to me, including to edit script /usr/bin/google-chrome.

I downloaded the same DEB, opened it up using Xarchive to examine its contents, then manually copied the files to install it. It did not have script /usr/bin/google-chrome.

The penny dropped. Xarchive does not extract the 'DEBIAN' control folder. This has a post-install script that creates /usr/bin/google-chrome.

I want to use Xarchive to view and extract exactly what is inside a archive file!

I have modified /usr/lib/xarchive/wrappers/deb-wrap.sh, inserted a line:

    -e) # extract: from archive passed files 
        # convert deb to a temporary tar file
        tmptar="$(mktemp -t tartmp.XXXXXX)"
        $DEB_PROG $CONVERT_OPTS "$archive" > "$tmptar"
        # extract files from the temporary tar
        $TAR_PROG $TAR_EXTRACT_OPTS "$tmptar" "$@"
        wrapper_status=$?
        #20210911 BK include control info in extraction...
        $DEB_PROG -e $archive DEBIAN
        # remove temporary tar
        rm "$tmptar"
        exit $wrapper_status
        ;;

...where DEB_PROG=dpkg-deb

Unfortunately, the DEBIAN folder is not listed when viewing the .deb file contents in Xarchive. Probably could be done, but complicates the deb-wrap.sh script immensely.

At least now, when extract a .deb file, will get the DEBIAN folder and can examine what is in it. Not a perfect solution, but passable.

Note, some other pups are using Xarchiver, which is a different project, does the same thing. Xarchive is a dead project, last release in 2006:

http://xarchive.sourceforge.net/

However, Puppy developers have worked on it since, and it has been internationalized. There are also posts about additional wrapper scripts. Here is one old post:

https://oldforum.puppylinux.com/viewtopic.php?t=56651

Here is the source that I use:

http://distro.ibiblio.org/easyos/source/oe/dunfell/xarchive-0.2.8-6-i18n.tar.bz2    

Tags: easy

Attempted compile Firefox in EasyOS

Some applications, over the years, have become more bloated and more difficult to compile. Firefox included.

The Linux From Scratch people have instructions, for example:

https://www.linuxfromscratch.org/blfs/view/svn/xsoft/firefox.html

Rust and clang (LLVM) are required to compile Firefox. This is how to install Rust:

# curl -4 --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Choose custom install, and type in "1.51.0" for Default toolchain.

Installs to /root/.cargo

A dependency is 'cbindgen', a rust package, install:

# cargo install cbindgen

Another dependency is 'nodejs', obtain from here, the LTS package, doesn't need to be compiled:

https://nodejs.org/en/

Python3 is also required, unlike SeaMonkey that is still stuck on needing Python2. Python3 is already in EasyOS, with the "devx" SFS loaded of course, for the full Python3.

I compiled the LLVM package in OpenEmbedded, which includes 'clang'. I was shocked that the binary package, xz-compressed, is 2GB, but that includes a lot of ".a" files. The library "libllvm*so" on its own is 60MB, and prior to now did not have it in the OE Dunfell build -- even though it means some GPU drivers in the 'mesa' package could not be built.

It really does go against the grain for me, to include such a huge library in EasyOS, and I won't. I have compiled it in OE only for the purpose of compiling Firefox (in a running EasyOS), with the intention that Firefox will be an SFS, not builtin to EasyOS.

So, LLVM and clang, compiled in OE, binary package now installed in running EasyOS 2.9, getting ready to compile Firefox...

Actually, it is not Firefox itself that needs clang and libllvm, it is 'cbindgen', the rust package. Cross fingers that won't need libllvm in the final firefox executable.

Final steps to getting ready for the compile, set some variables:

# export PATH="/root/.cargo/bin:${PATH}"
# export SHELL=/bin/sh
# export CC=gcc
# export CXX=g++
# export MACH_USE_SYSTEM_PYTHON=1

Here is the 'mozconfig' file, that needs to be in the Firefox source folder:

mk_add_options MOZ_OBJDIR=obj-x86_64-pc-linux-gnu
ac_add_options --enable-application=browser
ac_add_options --prefix=/usr
ac_add_options --host=x86_64-unknown-linux-gnu
ac_add_options --disable-dbus
ac_add_options --disable-accessibility
ac_add_options --disable-updater
ac_add_options --disable-parental-controls
ac_add_options --enable-strip
ac_add_options --with-system-jpeg
ac_add_options --with-system-zlib
ac_add_options --disable-tests
ac_add_options --disable-crashreporter
ac_add_options --with-system-libvpx
ac_add_options --disable-necko-wifi
ac_add_options --without-system-nspr
ac_add_options --without-system-nss
ac_add_options --without-system-icu
ac_add_options --disable-pulseaudio
ac_add_options --enable-alsa
ac_add_options --enable-system-ffi
ac_add_options --enable-system-pixman
ac_add_options --disable-debug
ac_add_options --with-system-libevent
ac_add_options --enable-optimize='-O2'
ac_add_options --enable-ffmpeg
ac_add_options --disable-webrtc
ac_add_options --enable-printing
ac_add_options --disable-jack
ac_add_options --without-system-webp
ac_add_options --disable-elf-hack
unset MOZ_TELEMETRY_REPORTING

I downloaded the latest source, version 92.0, from here:

http://ftp.mozilla.org/pub/firefox/releases/92.0/source/

Copied 'mozconfig' into it, then ran:

# ./mach configure

Then:

# ./mach build

...it compiled for a couple of hours, then compile fail.

Tried the legacy ESR version 78.x, see here:

https://www.linuxfromscratch.org/blfs/view/svn/xsoft/firefox-legacy.html

Source package:

https://archive.mozilla.org/pub/firefox/releases/78.14.0esr/source/firefox-78.14.0esr.source.tar.xz

...compile also failed, different place, in "netwerk/dns/mdns".

What requires mdns? WebRTC does, and I have "--disable-webrtc" in mozconfig. Worth a punt, have taken that out, trying again...

# rm -rf obj-x86_64-pc-linux-gnu/
# ./mach configure
# ./mach build

...failed again, this time in "modules/libjar/zipwriter".

Haven't given up yet! Downloaded the Firefox source from Debian:

https://packages.debian.org/bullseye/firefox-esr

http://deb.debian.org/debian/pool/main/f/firefox-esr/firefox-esr_78.12.0esr.orig.tar.xz

http://deb.debian.org/debian/pool/main/f/firefox-esr/firefox-esr_78.12.0esr-1.debian.tar.xz

Expanded the "debian" package inside the Firefox source, then applied the patches:

#!/bin/sh
P='fixes/Allow-.js-preference-files-to-set-locked-prefs-with-.patch
fixes/Bug-1526653-Include-struct-definitions-for-user_vfp-.patch
fixes/Bug-1650299-Unify-the-inclusion-of-the-ICU-data-file.patch
fixes/Bug-1264836-Automatically-convert-the-little-endian-.patch
porting/Add-xptcall-support-for-SH4-processors.patch
porting/NSS-Fix-FTBFS-on-Hurd-because-of-MAXPATHLEN.patch
porting/Work-around-Debian-bug-844357.patch
porting/Use-NEON_FLAGS-instead-of-VPX_ASFLAGS-for-libaom-neo.patch
porting/Work-around-GCC-ICE-on-mips-i386-and-s390x.patch
porting/Work-around-another-GCC-ICE-on-arm.patch
porting/Add-missing-bindings-for-mips-in-the-authenticator-c.patch
prefs/Set-javascript.options.showInConsole.patch
prefs/Set-DPI-to-system-settings.patch
prefs/Don-t-auto-disable-extensions-in-system-directories.patch
debian-hacks/Avoid-wrong-sessionstore-data-to-keep-windows-out-of.patch
debian-hacks/Add-another-preferences-directory-for-applications-p.patch
debian-hacks/Don-t-register-plugins-if-the-MOZILLA_DISABLE_PLUGIN.patch
debian-hacks/Add-a-2-minutes-timeout-on-xpcshell-tests.patch
debian-hacks/Add-debian-extra-stuff-to-upstream-build-system-dire.patch
debian-hacks/Don-t-build-image-gtests.patch
debian-hacks/Set-program-name-from-the-remoting-name.patch
debian-hacks/Use-the-Mozilla-Location-Service-key-when-the-Google.patch
debian-hacks/Avoid-using-vmrs-vmsr-on-armel.patch
debian-hacks/Use-remoting-name-for-call-to-gdk_set_program_class.patch
debian-hacks/Use-build-id-as-langpack-version-for-reproducibility.patch
debian-hacks/Don-t-build-ICU-in-parallel.patch
debian-hacks/Allow-to-build-with-older-versions-of-nodejs-10.patch'
for aP in $P
do
 patch -p1 --dry-run < debian/patches/${aP} >/dev/null 2>&1
 if [ $? -eq 0 ];then
  echo "PATCH: ${aP}"
  patch -p1 < debian/patches/${aP} >/dev/null 2>&1
 else
  echo "FAILED: ${aP}"
 fi
done

Off we go again...

...failed again. Oh well, will just use an already-compiled package to create a Firefox SFS.    

Tags: easy