Discussion, talk and tips
https://forum.puppylinux.com/
@fredx181 That is exactly the plan! I found making the xbps package and then simply installing it during the build works best. I can remove any config files before installation to insure the new custom configs will be written to the system and replace the default ones.
Odd occurrence...but maybe not.....after running a KLV build and booting up fine and using the OS for a day, I used a xbps-install -Suy and it deleted some of the xlunch package as obsolete plus some other custom packages that are registered and installed. I had to --force install xLunch to fix it!
Considering trying the package hold and or repo lock after all of the custom packages are installed.
Otherwise the PLUG and @wiak's build script are running very well and the PLUG is producing an OS almost equally outfitted as beta14 or 15 (still in test) except brand new.
Once I have the xfce4 desktop customization tweaks in place the PLUG should be caught up to about the level beta14 finds itself.
Still busy with business-related installs, but most of my IT work related to that is now 'close' to being well-organised (for the first time...), but still to improve my backup procedures. In a couple of weeks time my partner is away on business trip and I have a laptop I need to make full install of Zorin on plus all apps and configs related to the business needs. I find full install easier when it comes to upgrades to glibc and so on, albeit with some disadvantages. Everything I use is open source and beats ms windows business rubbish hands down (in fact some business friends of my partner have asked if I could do same for them, but tricky when they live half the world away). I also include pretty much all weedog/puppy scripts like filemnt, gtkdialog, wd_mount and so on, since these are key to easy admin work. And I include KLV and fossapup frugal installs since either of these make maintenance of whole system a breeze.
Once the business trip begins I plan to get back to some maintenance on build_weedog_initrd and build_firstrib_rootfs scripts and tidy up associated gitlab site.
@wiak,
Another test run of the build script and PLUG file to construct a KLV-Airedale with the components called by script and sets up
for a "pseudo full" install type of setup.
Code: Select all
#!/bin/sh
echo "start KLV-Airedale build....."
wget https://rockedge.org/kernels/data/Kernels/64bit/5.16.14-KLV-no_AUFS/5.16.14-KLV/vmlinuz
wget https://rockedge.org/kernels/data/Kernels/64bit/5.16.14-KLV-no_AUFS/5.16.14-KLV/01firmware-5.16.14-KLV.sfs
wget https://rockedge.org/kernels/data/Kernels/64bit/5.16.14-KLV-no_AUFS/5.16.14-KLV/00modules-5.16.14-KLV.sfs
wget https://rockedge.org/kernels/data/KLV-initrd/initrd.gz
wget https://rockedge.org/kernels/data/KLV-initrd/w_init
mkdir 07dummy_rootfs
./build_firstrib_rootfs_401rc1.sh void rolling amd64 f_00_Void_KLV_XFCE_no-kernel_WDLteam-RC5.plug
sleep 1
mv firstrib_rootfs upper_changes
echo "KLV-Airedale build finished......"@wiak Once again hit a snag after a good period of time with out a hassle, but since last night my time there is some sort of certificate problem causing SSL failure to update or reach the Void repos.
in a terminal:
Code: Select all
SSL_NO_VERIFY_PEER=true xbps-install -y micro
SSL_NO_VERIFY_PEER=true xbps-install -Suyor for example needs this format in a terminal to work:
Code: Select all
export SSL_NO_VERIFY_PEER=1
xbps-install -Sy micro cherrytreeNot sure yet on how to proceed. Do we need to do something? I have sync'ed the time but no change.
I will need to boot into another version and try it but I have doubts that reaching the repo's with SSL will work there either.
fixed for now by changing the configuration files for XBPS. These are also used by OctoXBPS.
/usr/share/xbps.d/00-repository-main.conf
Code: Select all
#repository=https://mirror.clarkson.edu/voidlinux/current
repository=http://mirror.clarkson.edu/voidlinux/current/usr/share/xbps.d/10-repository-main.conf
Code: Select all
#repository=https://mirror.clarkson.edu/voidlinux/current/nonfree
repository=http://mirror.clarkson.edu/voidlinux/current/nonfree@rockedge Updating went well for me on latest beta
Code: Select all
root# xbps-install -Suy
[*] Updating repository `https://repo-default.voidlinux.org/current/x86_64-repodata' ...
x86_64-repodata: 1756KB [avg rate: 4881KB/s]
[*] Updating repository `https://mirror.clarkson.edu/voidlinux/current/nonfree/x86_64-repodata' ...
x86_64-repodata: 14KB [avg rate: 261MB/s]
111 packages will be downloaded:
8 packages will be installed:
libjbig2dec-0.19_2 libpaper-1.1.28_1 libgs-9.55.0_1
libspectre-0.2.9_2 libdav1d6-1.0.0_1 mbedtls-2.16.12_1
librist-0.2.7_1 libsrt-1.5.0_1
103 packages will be updated:
NetworkManager (1.38.0_1 -> 1.38.2_1) alsa-lib (1.2.6.1_1 -> 1.2.7.1_1)
alsa-plugins-pulseaudio (1.2.6_1 -> 1.2.7.1_1)
alsa-utils (1.2.6_1 -> 1.2.7_1)
ca-certificates (20211016+3.77_1 -> 20211016+3.80_1)
....
....Seems that the repo in '/usr/share/xbps.d/00-repository-main.conf' for me is different from yours: https://repo-default.voidlinux.org/current .
rockedge wrote: ↑Sat Jul 02, 2022 2:26 pm@wiak Once again hit a snag after a good period of time with out a hassle, but since last night my time there is some sort of certificate problem causing SSL failure to update or reach the Void repos.
Screenshot_2022-07-02_10-12-08.jpgin a terminal:
Code: Select all
SSL_NO_VERIFY_PEER=true xbps-install -y micro SSL_NO_VERIFY_PEER=true xbps-install -Suyor for example needs this format in a terminal to work:
Code: Select all
export SSL_NO_VERIFY_PEER=1 xbps-install -Sy micro cherrytreeNot sure yet on how to proceed. Do we need to do something? I have sync'ed the time but no change.
I will need to boot into another version and try it but I have doubts that reaching the repo's with SSL will work there either.
@rockedge
A few questions regarding how you are doing the build:
1. What distro are you using when doing the build?
2. What version of build_firstrib_rootfs are you using?
In the latest that I put as source in the cherrytree notepad (version="4.0.1"; revision="-rc1"), I notice I commented out lines 235 and 236 (probably on purpose - not wanting to use sslcerts any more).
Code: Select all
# wget -c https://gitlab.com/weedog/weedoglinux/-/raw/master/build_resources/sslcerts.tar.xz
# tar xJf sslcerts.tar.xz && rm sslcerts.tar.xzI can't remember why or how these sslcerts were no longer needed(?) However I note that at line 239 (in the chroot) I use:
Code: Select all
SSL_NO_VERIFY_PEER=1 xbps-install -Suy xbps-triggers base-files xbpsThat line installs full xbps, and I think why I decided I didn't need sslcerts.tar.xz anymore (which would need updated sometimes if was needed) is that dependencies of xbps includes ca-certificates/
I can see that dependency in: https://github.com/void-linux/void-pack ... s/template
Hence my asking what version of build_firstrib_rootfs you are using. If you are using an older version my above plan won't be working and sslcerts.tar.xz might be getting used by older build script and that sslcerts might be out of date. That earlier sslcerts way of doing things was a bit of a fudge and not I think to be recommended. Rather the later method of using SSL_NO_VERIFY_PEER to fetch certificates would be correct.
I haven't tried a build myself, so above is just what I 'think'. If you are using same latest build_firstrib_rootfs script then the problem must be something else. I have a feeling I have had trouble with that tier two mirror regarding certificates before (so maybe it is their fault...?):
Code: Select all
https://mirror.clarkson.edu/voidlinux/ USA: New YorkBetter maybe to use tier one mirror during main build, such as:
Code: Select all
https://repo-us.voidlinux.org/ USA: Kansas CityFor mirrors that can be put into build_firstrib_rootfs see: https://docs.voidlinux.org/xbps/reposit ... index.html
but
Code: Select all
2 https://repo-us.voidlinux.org USA: centralUSAis already there.
If problem still not resolved I'll look into it tomorrow. Very much still bedtime here...
and see if some mod to the program (or your f00_plugin) regarding openssl/certificates is the best solution.
Just saw fredx181 post. Seems to be related to what I just said.
So main thing for me is to check you are using that latest build_firstrib_rootfs script (version="4.0.1"; revision="-rc1" with wget sslcerts commented out as I said - shouldn't be used/needed) and to suggest you use the tier 1 mirror for the build and not that clarkson one.
The problem just popped up in a already built and has been running for days version of KLV-Airedale. It was built using the 401 build script with no problems at all in another KLV.
One hour before no issue reaching the repos with SSL, but later on went to run xbps-install -y micro and the problem started.
Just out of the blue. I managed to get the install and then a system update done with the workarounds.
So it went from working great since it was built to the SSL cert issue all of a sudden. Works with the no SSL check workaround.
@fredx181 I booted in a KLV-Airedale-beta14/15 that updated the system with no problems.
I don't really understand why the cert problem suddenly appeared in the KLV-Test-D I have been running for a few days. The workaround fixes it, but perhaps the system clock? I booted into KLV-Airedale-beta14 and it updated no problems on the same system though it is designed to auto-sysnc the clocks.
I did reboot the KLV-Test-D that is having the problem to see if the clock sync at startup would fix it, but it did not.
But have you tried simply adjusting the distro to use tier one repo-usa rather than that tier 2 clarkson one? (without workaround)
I made a /etc/xbps.d directory and have these 2 files in it, which works. still a work around though it seems
/etc/xbps.d/00-repository-main.conf
Code: Select all
#repository=https://mirror.clarkson.edu/voidlinux/current
repository=http://mirror.clarkson.edu/voidlinux/current/etc/xbps.d/10-repository-nonfree.conf
Code: Select all
#repository=https://mirror.clarkson.edu/voidlinux/current/nonfree
repository=http://mirror.clarkson.edu/voidlinux/current/nonfreeI commented out the repo's listed in /usr/share/xbps.d and I synced the clocks by rebooting. This now happened in beta15 and the above fixed it for now there also.
rockedge wrote: ↑Sun Jul 03, 2022 2:31 amI made a /etc/xbps.d directory and have these 2 files in it, which works. still a work around though it seems
/etc/xbps.d/00-repository-main.conf
Code: Select all
#repository=https://mirror.clarkson.edu/voidlinux/current repository=http://mirror.clarkson.edu/voidlinux/current/etc/xbps.d/10-repository-nonfree.conf
Code: Select all
#repository=https://mirror.clarkson.edu/voidlinux/current/nonfree repository=http://mirror.clarkson.edu/voidlinux/current/nonfreeI commented out the repo's listed in /usr/share/xbps.d and I synced the clocks by rebooting. This now happened in beta15 and the above fixed it for now there also.
Yes, that is a workaround since not wanting to use http rather than https, but I still think you should change repo altogether to repo-default or repo-us, which are tier one repos. I've seen trouble with clarkson repo in similar way in the past - i.e. I suspect that clarkson repo is not updating its certificates quick enough and not an issue with KLV per se. I may be wrong... 
I need to check build_firstrib_rootfs more thoroughly. At least a couple of minor changes required.
This line 227 seems no longer valid (they have changed the file name to just actual version numbers, which is a pity since makes harder to maintain):
wget -c ${repo}/static/xbps-static-latest.i686-musl.tar.xz
I like 'latest' instead of keep having to look it up!
I think it now needs changed to:
Code: Select all
wget -c ${repo}/static/xbps-static-static-0.59_5.i686-musl.tar.xz
tar xJvf xbps-static-static-0.59_5.i686-musl.tar.xz && rm xbps-static-static-0.59_5.i686-musl.tar.xzLooking here it seems that "latest" and 0.59_5 are the same https://alpha.de.repo.voidlinux.org/static/
fredx181 wrote: ↑Sun Jul 03, 2022 12:28 pmLooking here it seems that "latest" and 0.59_5 are the same https://alpha.de.repo.voidlinux.org/static/
Yes, seems to depend on repo... Oh, no, looks like you are correct. Late here... I just didn't see 'latest' any more when I looked... sigh. Ah, no, it does depend on the repo... how on earth?...
For example, see: https://repo-us.voidlinux.org/static/
I have been trying all of the tier 1 repos all so far with the same result.
Code: Select all
repository=https://repo-us.voidlinux.org/voidlinux/current
repository=https://repo-us.voidlinux.org/voidlinux/current/nonfreeCode: Select all
root# xbps-install -Suy
[*] Updating repository `https://repo-us.voidlinux.org/voidlinux/current/x86_64-repodata' ...
Certificate verification failed for /C=US/O=Internet Security Research Group/CN=ISRG Root X1
SSL_connect returned 1
ERROR: [reposync] failed to fetch file `https://repo-us.voidlinux.org/voidlinux/current/x86_64-repodata': Operation not permitted
[*] Updating repository `https://repo-us.voidlinux.org/voidlinux/current/nonfree/x86_64-repodata' ...
Certificate verification failed for /C=US/O=Internet Security Research Group/CN=ISRG Root X1
SSL_connect returned 1
ERROR: [reposync] failed to fetch file `https://repo-us.voidlinux.org/voidlinux/current/nonfree/x86_64-repodata': Operation not permitted
root# Then I switched those to http and it failed again:
Code: Select all
root# xbps-install -Suy
[*] Updating repository `http://repo-us.voidlinux.org/voidlinux/current/x86_64-repodata' ...
Certificate verification failed for /C=US/O=Internet Security Research Group/CN=ISRG Root X1
SSL_connect returned 1
ERROR: [reposync] failed to fetch file `http://repo-us.voidlinux.org/voidlinux/current/x86_64-repodata': Operation not permitted
[*] Updating repository `http://repo-us.voidlinux.org/voidlinux/current/nonfree/x86_64-repodata' ...
Certificate verification failed for /C=US/O=Internet Security Research Group/CN=ISRG Root X1
SSL_connect returned 1
ERROR: [reposync] failed to fetch file `http://repo-us.voidlinux.org/voidlinux/current/nonfree/x86_64-repodata': Operation not permitted
root# Returned to the http
Code: Select all
repository=http://mirror.clarkson.edu/voidlinux/current
repository=http://mirror.clarkson.edu/voidlinux/current/nonfreeresulted in:
Code: Select all
root# xbps-install -Suy
[*] Updating repository `http://mirror.clarkson.edu/voidlinux/current/x86_64-repodata' ...
x86_64-repodata: 1756KB [avg rate: 2540MB/s]
[*] Updating repository `http://mirror.clarkson.edu/voidlinux/current/nonfree/x86_64-repodata' ...
root# Now something odd......I booted into a laptop that has a recent PLUG built KLV-Airedale on it. Started smoothly and quickly.
changing nothing I ran the repo update and it worked flawlessly!
This is confusing since it is using https and the Clarkson uni repos 
wiak wrote: ↑Sun Jul 03, 2022 12:53 pmfredx181 wrote: ↑Sun Jul 03, 2022 12:28 pmLooking here it seems that "latest" and 0.59_5 are the same https://alpha.de.repo.voidlinux.org/static/
Yes, seems to depend on repo... Oh, no, looks like you are correct. Late here... I just didn't see 'latest' any more when I looked... sigh. Ah, no, it does depend on the repo... how on earth?...
For example, see: https://repo-us.voidlinux.org/static/
This should work to get latest using repo-us.voidlinux.org:
Code: Select all
LATEST=$(wget -q -O - https://repo-us.voidlinux.org/static/ | grep -o -E "[^<>]*?.i686-musl.tar.xz" | sort -V | tail -1)
echo $LATEST
wget "https://repo-us.voidlinux.org/static/$LATEST"EDIT: @rockedge very mysterious 
hopefully wiak has an answer, I have no clue.
I built a quick WDL_void64 without bothering with a plug and used repo-us, and I found no certificate-related issues. I did use one change to the build_firstrib_rootfs since I built on nvme drive: I used:
line 16:
busybox_url="https://busybox.net/downloads/binaries/ ... sl/busybox"
since needed that 1.35 musl build of busybox to work with my nvme drive.
Would it effect your builds - I doubt it. But certainly, after mount_chroot.sh I can successfully do: xbps-install -Syu without issue.
@wiak I can't seem to pinpoint what is happening! Some seem to be okay and then testing in almost the same thing it isn't.
It doesn't seem to be a clock sync issue. And the beta15-base I generate those beta's from is working with no changes to the repos. On a DELL laptop I built with the PLUG and that went fine and the updates in a just built version done 4 days ago I call Test-D, also upgraded with no changes made to the repo URL's.
I am getting a bit mystified and struggle now to find a place to start to look. AHHHHHHHHHHHHHHH............ 
UPDATE: I am starting a fresh build with script 401 and the PLUG from GitHub on this DELL laptop right now.......
selected repo's #3 and going as smooth as glass so far.............ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh...........
It finished quickly, error free and boots right up to KLV-Airedale...........the update repo fail is happening on one machine so far.....what is this DELL PowerEdge R210 II doing differently? Clock seems fine. Puppy's running great on it
Just finished a 15 minute build of KLV-AIredale using build_firstrib_rootfs_401rc1.sh and f_00_Void_KLV_XFCE_no-kernel_WDLteam-RC5.plug
bound together with this script
make_KLV.sh
Code: Select all
#!/bin/sh
echo "start KLV-Airedale build....."
wget --continue https://rockedge.org/kernels/data/Kernels/64bit/5.16.14-KLV-no_AUFS/5.16.14-KLV/vmlinuz
wget --continue https://rockedge.org/kernels/data/Kernels/64bit/5.16.14-KLV-no_AUFS/5.16.14-KLV/01firmware-5.16.14-KLV.sfs
wget --continue https://rockedge.org/kernels/data/Kernels/64bit/5.16.14-KLV-no_AUFS/5.16.14-KLV/00modules-5.16.14-KLV.sfs
wget --continue https://rockedge.org/kernels/data/KLV-initrd/initrd.gz
wget --continue https://rockedge.org/kernels/data/KLV-initrd/w_init
wget --continue https://rockedge.org/kernels/data/KLV-initrd/10gtkdialogGTK3_filemnt64.sfs
mkdir 07dummy_rootfs
./build_firstrib_rootfs_401rc1.sh void rolling amd64 f_00_Void_KLV_XFCE_no-kernel_WDLteam-RC5.plug
sleep 1
mv firstrib_rootfs upper_changes
echo "KLV-Airedale build finished......"and the build went smoothly all the way through. Booted straight up to desktop as a "frugal pseudo full install". And updated the repos successfully.
No modification and using SSL. I don't know what is going wrong on those 2 particular KLV systems other than a time sync issue which it doesn't appear to be....... 
fredx181 wrote: ↑Sun Jul 03, 2022 2:41 pmThis should work to get latest using repo-us.voidlinux.org:
Code: Select all
LATEST=$(wget -q -O - https://repo-us.voidlinux.org/static/ | grep -o -E "[^<>]*?.i686-musl.tar.xz" | sort -V | tail -1) echo $LATEST wget "https://repo-us.voidlinux.org/static/$LATEST"EDIT: @rockedge very mysterious
Good idea Fred. I'll use sed magic to sort that out (or grep and sort -V fine too; nice tricks to strip the html by the way).
I tried to do the match with awk, but that grep -o is the trick is basically what I couldn't manage (myself) in awk. Must be possible of course. I wanted awk in case I wanted to use a function that could handle more complicated cases and thought awk program lines might be easier, but I haven't managed with awk so far...
grep -o is certainly much easier... But I have to say, that line LATEST= etc etc, is really weird; no way I would have got that! I still can't work out how exactly it does it. Take out the tail -1 and all seems on one line - I suppose the wget outputs one line at a time with \n at the end and that's how tail 'sees' each line separately? Oh well, I'll just use it...
As for rockedge certificate issue, I have no idea either sorry.
wiak wrote:.....But I have to say, that line LATEST= etc etc, is really weird; no way I would have got that! I still can't work out how exactly it does it......
Well, honestly I don't understand exactly either, somehow the grep command splits the lines, got it from here: https://stackoverflow.com/questions/150 ... -directory and modified.
fredx181 wrote: ↑Mon Jul 04, 2022 10:09 amwiak wrote:.....But I have to say, that line LATEST= etc etc, is really weird; no way I would have got that! I still can't work out how exactly it does it......
Well, honestly I don't understand exactly either, somehow the grep command splits the lines, got it from here: https://stackoverflow.com/questions/150 ... -directory and modified.
Very handy. I'm modifying some other parts of build_firstrib_rootfs to get latest version of a few files similarly. I failed with awk version attempt - I'm just not expert enough with awk and grep -o construct is very powerful (I believe needs loop in awk and basically found how to do it, but got tired trying to make it work and decided that grep -o method is more sensible anyway).
I'd say this one is more basic, using simple grep and cut (found similar as this in my notes now, explored web-directory index listing some time ago) without the grep and tail it just shows all files.
wget -q -O - https://repo-us.voidlinux.org/static/ | grep "i686-musl.tar.xz" | cut -d ">" -f 2 | cut -d "<" -f 1 | tail -1
KLV-Airedale-beta16 is ready for download and testing!
This is an upgraded beta14 with some small tweaks and improvements.
Using the most recent packages, including Firefox v102
Download from usual place -> https://rockedge.org/kernels
And from the first post of this topic -> https://forum.puppylinux.com/viewtopic. ... 139#p50139
The latest PLUG file at this time comes close to building an equivalent distro to beta16!
Only thing missing is the actual desktop "look" itself being pre-configured.
@wiak and @fredx181 have you tried a run with the build_firstribfs script and the PLUG to make a KLV-Airedale from scratch?
Not for a long while, though I did study the plug. I'll try and build soon though since I am working on a new built_firstrib_roots script at the moment (doesn't change much, since why waste what works..., but tidies a few things up).
fredx181 wrote: ↑Mon Jul 04, 2022 2:18 pmI'd say this one is more basic, using simple grep and cut (found similar as this in my notes now, explored web-directory index listing some time ago) without the grep and tail it just shows all files.
wget -q -O - https://repo-us.voidlinux.org/static/ | grep "i686-musl.tar.xz" | cut -d ">" -f 2 | cut -d "<" -f 1 | tail -1
Yes, that works for that case, but that other one also works (with minimum tweaking) for finding most recent version of debootstrap, whereas above simple one doesn't as stands. That's the thing with piped filters; I never trust they will always work if unexpected files suddenly appear in the listing and so on, but first method does a good job of removing html tags, and I just add an extra grep -v line into the pipe for additional unwanted cases, for example: grep -vE (nmu|ubuntu).
One of the problems with regular expressions is that there are Basic, and Extended (and also Perl-type) and aside from extra features Basic sometimes need character escaped to make it act as a metacharacter, whilst Extended treats same character as a metacharacter when it isn't escaped... nightmare really. If I'm not using re's often (which I'm not) I forget a lot of it and rely on these regular expression online tester programs at the best of times.
@rockedge
I noticed that when doing xbps-install -Suy, the custom xlunch package gets replaced by the one from Void (v4.7).
Didn't realize that Void has it in the repo, my bad.
Probably it's possible to mark the older xlunch v4.1_3 as "hold", but anyway, here's a different package "xluncher" (the Void xlunch hasn't got some of the features like the custom package has)
It has dependency xlunch, so v4.7 will be installed and the v4.1_3 will be removed, for the rest it contains the same scripts as v4.1_3 (e.g. Xlunch1, Xlunch2 etc..).
Not sure if I said it before, installing "devilspie2" will provide that e.g. Xlunch1, Xlunch2 or Logout show undecorated.
One advantage is that it doesn't depend on GTK2 (as v4.1_3 is for generating the entries file by "xlunch-menu")
Disadvantage is that only at install an entries file will be generated, then need to update entries file from Menu "Update entries for xlunch (convert .svg to .png)" everytime a new applcation gets installed.
(the v4.1_3 has startup script calling xlunch-menu that automatically keeps track of new installed applications).
Other disadvantage may be that generating entries is slower (depends on the amount of applications).
Just offering this new package, choice what to include is yours of course.
xluncher-1.0_0.noarch.xbps :
https://dl.dropboxusercontent.com/s/ukk ... .xbps?dl=1
@fredx181 Thanks for the xLunch package! That will take care of the upgrade mix-up. I also expereinced this several times and watched as "obsolete entries" got removed but just re-installed the custom package to replace those deleted components.
I am glad that you've updated the package because it's now included in KLV-Airedale including the most recent PLUG file build. I have uploaded it to https://rockedge.org/kernels