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

Helena Campsite and Speedster Stove test

Last weekend, went for a hike. Usual stamping ground, Mundaring locality. Caught train then bus to the town of Mundaring, which is in the hills just outside the Perth metropolitan area. Then walked south on the Mundabiddi Trail to the Mundaring Weir Hotel -- as usual, had lunch there. Then walked approximately East, on the Bibbulmun Track, and camped overnight at the Helena Campsite. Next morning, ambled back along old fire trails, to the Mundaring town, then public transport back to Perth.

Lovely Spring weather, a couple of sunny days, though the nights were cold. I was surprised, about 20 people stayed overnight at the Helena Campsite. Some used the internal bedding provision, some, me included, pitched tents. Yeah, we did the sitting-around-the-campfire thing at night. Even somewhat-anti-social-me sat there for awhile.

Here is a photo just after 6.00am, before the sun has appeared on the horizon, but is starting to light the sky:

When I arrived at the campsite on Saturday evening, my legs were knackered, so the walking had degenerated to a slow shamble. Don't have an app for measuring distance, but it would have been about 23km.

Chatted with one young fellow who had run all the way from the Mundaring Weir Discovery Centre, he said it took him about 1 hour. The trail is up and down rocky terrain, and I took about 4 hours to walk that same path. Oh well.

Next morning, followed lovely old fire-trails, here is a photo:

Legs were knackered, but walked slowly and it was very pleasant.

Main reason for this post, is want to report on using the Speedster Stove, and the new "kitchen kit". I used it on the hike, to rehydrate a veggie & couscous packet for the evening meal. Firstly, about the stove, this is it:

https://speedsterstoves.co.uk/30ml-spill-proof-meths/alcohol-burner.html

...oh, the site is currently offline, say they are off backpacking and will be online in 4 days.

Anyway, that's what I bought, 30ml spill-proof methylated-spirit (alcohol) stove, with a matching folding stand. They hardly weigh anything. The stove burns for about 18 minutes. No priming required, immediately usable. It won't spill, just screw on the lid and fuel can be left in the stove.

I had great fun putting together the "kitchen kit". I own a Toaks 1000ml titanium pot, and was able to put everything into the pot, including the meths. Here is the pot, total weight with everything inside is 498g:

Toaks do not sell the 1000ml size any more, they do have a 900ml and a 1200ml. But there are other manufacturers, look on eBay and Aliexpress. Open the lid, everything packed neatly inside:

The bottles are each 50ml, to hold the meths. Some meths can also be held in the stove, so potentially can carry 230ml. The weight that I measured, 498g, was with all bottles filled and the stove partly filled.

The big question is, how many days will 230ml of meths last? Hold that thought, for now, presenting everything packed into the pot:

...on the left is a collapsible silicone cup, a funnel, matches, sponge, folding knife, pill-holder, titanium wind-shield, folding titanium spoon, and the Speedster Stove and folding stand.

All of these items are available on eBay and Aliexpress. The bottles are these:

https://www.aliexpress.com/item/4001079924366.html

They allow precise application of the meths, with a narrow opening, see this photo of the 100ml bottle:

The titanium windshield is readily available also. Mine was originally 110mm wide, but I cut it down slightly so as to fit underneath the pot handles. It is extremely thin and can be cut with scissors. Weight, after cutting, is only 11g. I use a paper-clip to hold it in place around the stove.

The titanium folding spoon is Keith brand, which I chose as it is slightly wider (41mm) than other brands. Got it from Aliexpress.

Here is the stove and stand:

The windshield is absolutely essential. It shelters the flame from breezes, but also acts with the chimney-effect, drawing air from holes at the bottom and focussing the flame onto the pot. With the windshield in place and the pot on the stand, the flame is hardly seen:

If the pot is removed, the flame is quite yellow, and high:

I would never have thought that this is efficient combustion, but it is. With the pot on the stand, there is hardly any tar residue deposited on the pot, and water is boiled remarkably fast.

In fact, side-by-side tests with other meths stoves, the Speedster boils the water faster. There are some comparisons on YouTube, such as this one, using the smaller 20ml Speedster:

https://www.youtube.com/watch?v=vTRrt1OltRk

...3 minutes versus 4½ minutes, the Speedster won. Also, the Mini Trangia stove has to be primed, which wastes more fuel and time -- he did not include the priming-time in that 4½ minutes.

As can be seen in the above stove, I set it up on top of my kitchen stove (with ceiling extractor fan running). I also tested the boil time. 400ml took 6 minutes.

My "cooking" on the trail is really just heating up food then eat, such as baked beans, or boil water to rehydrate a meal. And, boil water for coffee. Prolonged cooking is not required, as if required can use my insulated pouch to complete the cooking process. I have one of these, weighs just 43g:

https://bigskyinternational.com/collections/insulite-products/products/big-sky-insulite-insulated-food-pouch-freezer-bag-cooking-cozy

So, back on that question, how many days can I hike with 230ml of meths? According to the Speedster Stoves website, the 30ml stove will burn for 18 minutes. I would probably only need to boil about 600ml per day, which will take 9 minutes -- pour some out for the coffee, the rest to rehydrate a meal. That would mean 15ml per day, so the meths will last for 15 days!

Others might have heavier usage, such as make coffee in the morning, but even if the meths lasts for only 7 days, that is pretty good.

It would be interesting to compare with a gas setup. A 230g gas canister weighs 230g plus the steel container, a small gas screw-on burner is about 75g. They would probably fit in the pot OK. All-up weight is probably going to be higher, plus those gas canisters are not environmentally-friendly.

The motivation behind checking out this meths stove, is previously had used a wood-burning stove, but there are fire restrictions for much of the year here in Western Australia. Gas and meths stoves are allowed all-year round.

EDIT:
A few years ago, I was camping on the South Coast of WA, at a CALM campsite, and was cooking in a camp kitchen. I had a Vargo alcohol stove, and was cooking on a stainless steel bench. This stove:

https://vargooutdoors.com/triad-stove.html

...it is not very stable, and I accidentally tipped it over. Meths ran over the benchtop, and the flame followed it.

The Speedster Stove, on the otherhand, really is spill proof, see this video:

https://www.youtube.com/watch?v=e_K9DxZ-hAk

...he is showing the carbon one, I have the "normal" one, presume that is also just as spill proof.

I was wondering what the weight would be if went for a gas canister solution, instead of a meths stove...

Looked up the calorific value (heating power) of butane gas versus ethanol, and it is about 50Mj/kg versus 29.7Mj/kg. However, that is for 100% ethanol. Methylated Spirits sold in Australia is 95% ethanol and 5% water, with a bittering agent to render it undrinkable. So meths is going to have lower calorific value -- let's estimate around 25Mj/kg.

What that means is half the weight of butane to get the same amount of heating power as meths.

Very roughly then a 100g butane gas canister will be the same heating power as my 200ml bottles of meths.

OK, a 100g gas canister from MacPac weighs 190g, costs AU$10.99. A screw-on burner is $67.46, weighs 72g.
4 litres of methylated spirits from Bunnings is $15.72, which is $1.58 for 200ml.

So from a cost point of view, the meths is far cheaper. What about weight?

My kitchen kit, without the meths parts, packed with a 100g gas canister and screw-on burner, will weigh 488g. This is the base weight of 226g, +190g, +72g

Very similar from a weight perspective. So the choice really comes down to cost and environmental impact. Well, not entirely -- if you are only going hiking for a couple of days, then only one 50ml meths bottle is needed, so can reduce the carrying weight: 498g, take off three bottles at 58g each, the total weight of the kitchen kit becomes 324g.

Another consideration: how do you know how much gas is left? You might have to carry a spare canister just in case.

Just remembered something: if you buy the Diggers brand of methylated spirits here in AU, there is a warning on the label not to use it in alcohol stoves. The reason for this is the company is covering themselves legally, see this forum thread:

https://bushwalk.com/forum/viewtopic.php?f=5&t=37593

Interesting topic, gas versus alcohol!    

Tags: light

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