KLV-Airedale-beta+ Released, Ready for Download

[geo_c]

putting in sip-distutils-dev was the right move. Have you run a ldconfigin a terminal lately?

no, I can do that though.

I ran it, with no verbose output, so I don't know what it did.

[geo_c]

I ran it, with no verbose output, so I don't know what it did.

This time I ran it verbose, and it gives a long list of libraries with I guess with more detailed version numbers assigned.

[geo_c]

This time I ran it verbose, and it gives a long list of libraries with I guess with more detailed version numbers assigned.

libpoppler.so.111 is in there along with libpoppler-glib.so.8 and they are reflecting precise version numbers libpoppler.so.111.0.0 and liboppler-glib.so.8.21.0

added: I just ran the python setup.py build command again and got the same messge about 'no package poppler-qt5 fournd.

[geo_c]

added: I just ran the python setup.py build command again and got the same messge about 'no package poppler-qt5 found.

Code: Select all

root# python setup.py build
Package poppler-qt5 was not found in the pkg-config search path.
Perhaps you should add the directory containing `poppler-qt5.pc'
to the PKG_CONFIG_PATH environment variable
No package 'poppler-qt5' found
/usr/lib/python3.10/site-packages/setuptools/dist.py:738: UserWarning: Usage of dash-separated 'force-manifest' will not be supported in future versions. Please use the underscore name 'force_manifest' instead
  warnings.warn(
running build
running build_ext
Failed to determine Qt version ([Errno 2] No such file or directory: 'qmake').

Well I was giving you irrelevant information, but in fact the libpoppler-qt5.so.1 -> libpoppler-qt5.so.1.29.0 is also listed in the ldconfig output.

In addition the build script is having difficulty determining the qt5 version for some reason, which I installed from XBPS too.

[wiak]

@geo_c

re: frescobaldi

You picked a very difficult package apparently.

Personally I think you are kicking a dead horse at the moment since upstream void linux developers (and also from some other distros) are currently having trouble getting frescobaldi to install - nothing installing any part alone will fix, but patches needed to frescobaldi itself apparently. DISCLAIMER: I could be completely wrong about this. Just going by what I read below and I am unfamiliar with Void packaging details generally.

There is hope soonish maybe via Void Linux xbps-scr, which is similar to Arch AUR facility:

https://github.com/void-linux/void-packages/pull/33279

Another link documenting issues with frescobaldi elsewhere: https://github.com/frescobaldi/frescobaldi/issues/1398

EDIT: But maybe frescobaldi can be installed using xbps-src from above void-packages poster's github clone of void-packages: https://github.com/chili-b/void-packages

I am trying that and will report back. Seems to be working thus far, but a huge xbps install since lilypond apparently lots of big dependencies too. Hope I have enough space on my computer!!! As I said, geo_c, you picked an extremely difficult package to install... I'll post what I did whether it succeeds or fails since looking promising despite taking forever... patience will be required. Mind you, if it works, I will end up with xbps package - though that will no doubt require lots of dependencies, which I assume xbps-install will auto-install when the time comes... EDIT2: my system currently compiling lilypond it seems as part of the overall process.

EDIT3: It continues its huge long compile. Here is what it has done thus far...

Code: Select all

-bash-5.1$ pwd
/home/weedog/void-packages/hostdir/binpkgs
-bash-5.1$ ls
lilypond-2.23.6_1.x86_64.xbps  python3-ly-0.9.7_1.x86_64.xbps  x86_64-repodata
-bash-5.1$

Yes, I know that lilypond is already available in Void Linux repos and I don't know why it compiles it again (and even seems to be slightly older version). I guess lilypond is just a dependency of frescobaldi and that user chili-b's github has a slightly old void-packages github clone. Life will be easier if his frescobaldi patches end up merged into official void-packages, then a trivial install. It may work better to git clone official void-packages and simply copy chili-b's frescobaldi src

Error, Drat...

Code: Select all

qt5-host-tools-5.15.3+20220222_3.x86_64.xbps: 11MB [avg rate: 1928KB/s]
ERROR: [trans] failed to download `qt5-devel-5.15.3+20220222_3' signature from `https://repo-default.voidlinux.org/current': Transient resolver failure
Transaction failed! see above for errors.
qt5-host-tools-5.15.3+20220222_3: verifying RSA signature...
=> ERROR: Please see above for the real error, exiting..

Maybe my internet connection dropped, or maybe just failed. Was looking very promising though. I've run out of time alas, but here is what to try on your own:

From KLV-Airedale root terminal do the following:

Code: Select all

su - weedog
(don't worry about the error messages above gives), then do:
git clone https://github.com/chili-b/void-packages
cd void-packages
./xbps-src binary-bootstrap
./xbps-src pkg frescobaldi

The above process places the built binary package(s) in the path void-packages/hostdir/binpkgs directory.

Use the complete frescobaldi ... xbps filename assuming you get successful compile from above:

Code: Select all

sudo xbps-install --repository=hostdir/binpkgs frescobaldi

Might well need to first install all the other .xbps packages, but mayby any created frescobaldi will handle the dependencies okay. I don't know since my overall above compile failed as I said above.
If above doesn't work, frankly I'd forget about that package for now unless you can get a flatpak version of it working.

EDIT4: I just re-run the command: ./xbps-src pkg frescobaldi
and it completed the compile quite quickly from where above error occurred so must have just my Internet connection temporarily dropped. I am now doing:

Code: Select all

sudo xbps-install --repository=hostdir/binpkgs frescobaldi

and waiting for that to complete... SUCCESS

Code: Select all

Byte-compiling python3.10 code for module frescobaldi_app...
Updating ldconfig(8) cache...
frescobaldi-3.2_1: installed successfully.

[wiak]

I have made a (7 MB) tar.xz archive of all the frescogalbi/lilypond xbps files my above xbps-src compile created (frescobaldi_lilypond_archive.tar.xz)

You can download it from here (it is a real tar.xz so you should uncompress it with tar xvf command): https://owncloud.rockedge.org/index.php ... X5to4bbayS

Once you have clicked on the xbps files to install them, you should remember to run the following command as root user:

Code: Select all

frescobaldi

Worked for me (except that I have no idea how to use the application...).
BIG EDIT: Not so simple it turns out... you will need to install the missing dependencies, and get things in the right order. I suggest you look at the template files for what they are... so some work to do there...

By the way, I was thereafter able to update lilypond to newer version from official Void repos (seemed to also work anyway), so that compiled version probably not required...

Code: Select all

xi -Sy lilypond

where xi is an usable shorthand for xbps-install

Hopefully, that tortuous xbps-src work is a useful example of how to build Void package from source (assuming suitable package template can be found via googling or made for whatever the required package is...). Fact is, it was simple once I located that cloned github repo that contained template for frescobaldi. NOTE: it 'might' have been better if I had git cloned the official void src packages repo and simply added in the srcpkgs buld-template for frescobaldi from that users personal github, but I'm not sure if that would have caused issues with unfound versions. I expect it would have worked though and maybe used that existing latest lilypond - I won't be trying...

[geo_c]

@wiak, Huge thanks!

I'm working all day until 5pm, so I won't get to it until tonight. I was getting the sense that frescobaldi's latest version had some fatal issues.

Frescobaldi was the really the first big application that I was able to get running in Fossapup without using pets and complete debian's in the puppy package manager. So this attempt was a great learning experience, in that I now know a lot more about grabbing source packages from github and python builds, etc.

I was about to say, I can blow this package off, as I can still use lilypond by editing files in Geany and running lilypond in the terminal, however what Frescobaldi allows me to do is in import music.mxl files from other scoring applications like Musescore and then create lilypond files. Frescobaldi is part of my daily work load, as I use it to create 3 or 4 scores per week.

With this package installed in KLV I can get through a basic work week without having to boot up another distro. So your efforts are greatly appreciated.

[wiak]

Here is what the frescobaldi build template looks like. Note that I believe xbps-src builds these dependencies from source, and that is the difference to what you were (quite correctly otherwise) doing before. Some of these source-files provided by that cloned github archive have been specially patched I believe and that is why these versions then worked, but the pre-made previous alternatives had problems (that's what I think anyway...):

Code: Select all

# Template file for 'frescobaldi'
pkgname=frescobaldi
version=3.2
revision=1
build_style=python3-module
make_check_target="check"
hostmakedepends="python3-setuptools gettext"
depends="python3-PyQt5 python3-PyQt5-svg poppler-qt5 portmidi
 python3-cups python3-ly lilypond python3-qpageview"
short_desc="Powerful, lightweight and easy to use LilyPond sheet music text editor"
maintainer="chili-b <dexter.gaonshatford@gmail.com>"
license="GPL-2.0-or-later"
homepage="https://frescobaldi.org/"
changelog="https://github.com/frescobaldi/frescobaldi/blob/master/ChangeLog"
distfiles="https://github.com/frescobaldi/frescobaldi/archive/v${version}.tar.gz"
checksum=f7bb9b5f708f902f8f512ab6f0de1a6272d9e176f678027e576b06e5ceec8fe8

pre_build() {
	make -C linux
}

chili-b's git pushes to official void repos are documented here (but not accepted yet it seems): https://github.com/void-linux/void-packages/pull/33279

Actually, looking at the above link, maybe no actual source patches were needed and just these dependencies done, for the four templates overall involved (in which case you should be able to work out where your attempt went wrong by looking at the four templates involved). I'm not sure, and haven't checked further. I'm no expert at all with xbps-src; just getting some practice using it. xbps-src certainly makes things a lot easier than trying to do everything manually, though it does of course compile (or recompile) from sources and that takes ages (and always amazes me when it ends up without error - I wish it always did...). I do suspect its original source was patched first though.

Just as a maybe final matter of interest. Here, from the templates, are all the various dependencies that seem to have been required:

Code: Select all

pkgname=frescobaldi
hostmakedepends="python3-setuptools gettext"
depends="python3-PyQt5 python3-PyQt5-svg poppler-qt5 portmidi python3-cups python3-ly lilypond python3-qpageview"
pre_build() {
  make -C linux
}

pkgname=python3-ly
hostmakedepends="python3-setuptools"

pkgname=python3-poppler-qt5
hostmakedepends="python3-sip-devel pkg-config qt5-devel poppler-qt5-devel python3-PyQt5-devel python3-devel"
makedepends="python3-sip-devel pkg-config qt5-devel poppler-qt5-devel python3-PyQt5-devel python3-devel"
depends="poppler-qt5 python3-PyQt5"
python setup.py build_ext --pyqt-sip-dir=/${py3_sitelib}/PyQt5/bindings

pkgname=python3-qpageview
hostmakedepends="python3 python3-PyQt5-devel python3-PyQt5-svg"
makedepends="qt5-devel"
depends="qt5 python3-PyQt5-svg python3-poppler-qt5"

A lot of relevant PyQt5 stuff ends up as here: /usr/lib/python3.10/site-packages/PyQt5

[wiak]

BIG EDIT: Not so simple it turns out... you will need to install the missing dependencies, and get things in the right order. I suggest you look at the template files in my above post for what they are... so some work to do there... Too late at night for me to try it. Easiest, once worked out, would be to have short script with the details.
BIGGER EDIT: NOPE. The following didn't work for me - got transaction breaks installed pkg errors when I tried this, so my next post seems to be most reliable way (using xbps-src, which is not a tiny job). However it is not too bad, and did work for me.
--------------------------------------------

FOLLOWING using the archive of xbps packages I uploaded didn't work for me (though maybe there is a way...?). See my next post instead.

I'm sure there may be an easier way involving local repo, but maybe not... and I don't know it since haven't worked much with xbps actually.

Best I could manage from pristine KLV-Airedale install was this (from terminal commandline run just outside the extracted archive):

Code: Select all

xbps-rindex -a frescobaldi_lilypond_archive/*.xbps
index: added `frescobaldi-3.2_1' (x86_64).
index: added `lilypond-2.23.6_1' (x86_64).
index: added `python3-ly-0.9.7_1' (x86_64).
index: added `python3-poppler-qt5-0.75.0_1' (x86_64).
index: added `python3-qpageview-0.6.2_1' (x86_64).
index: 5 packages registered.

followed by:

Code: Select all

xbps-install --repository=frescobaldi_lilypond_archive frescobaldi
MISSING: ghostscript>=0
MISSING: guile1.8>=1.8.8_1
MISSING: poppler-qt5>=0
MISSING: portmidi>=0
MISSING: python3-PyQt5-svg>=0
MISSING: python3-PyQt5>=0
MISSING: python3-cups>=0
MISSING: python3-PyQt5-svg>=0
MISSING: poppler-qt5>=0
MISSING: poppler-qt5>=0.31.0_1
MISSING: python3-PyQt5>=0
MISSING: qt5>=0
Transaction aborted due to unresolved dependencies.

Then I manually went through these starting with:

Code: Select all

xi -Sy ghostscript

until all are installed... DIDN'T WORK (next post method did work)

If anyone knows easier way, please let me know.

[wiak]

This link may help you to understand the xbps-src method better: https://linuxiac.com/void-linux-xbps-package-manager/

Here, summarised, are the steps I used for frescobaldi installation via xbps-src (which is my METHOD 1).

From KLV-Airedale root terminal do the following (be patient, some of this stuff takes a long time to complete; large compiles are involved):

Code: Select all

su - weedog
(don't worry about the error messages above gives), then do:
git clone https://github.com/chili-b/void-packages
cd void-packages
./xbps-src binary-bootstrap
./xbps-src pkg frescobaldi

The above process places the built binary package(s) in the path void-packages/hostdir/binpkgs directory.

Then, from that same void-packages directory, install the frescobaldi package with command:

Code: Select all

sudo xbps-install --repository=hostdir/binpkgs frescobaldi

(in practice I lost my internet connection whilst doing the final install but re-running the above xbps-install --repository... command completed the install with no issues).

Then changed back to root terminal and entered command:

Code: Select all

frescobaldi

and the app started up okay.

I still think I should be able to use the xbps packages that were made without re-doing this xbps-src stuff, but I don't know how. As I said, it might have been better to use official void-packages and just copy chili-b's frescobaldi folder into srcpkgs of that prior to doing above, but might not have worked and I haven't had time to try that.

EDIT: Okay, I now managed with the archive of packages I uploaded... see next post...

[wiak]

Method 2. Easier.

Download the archive of frescobaldi xbps packages I made from: https://owncloud.rockedge.org/index.php ... X5to4bbayS

uncompress that with command: tar xcf blahblahblahfilename

cd into the extracted archive folder where the xbps files are

run command:

Code: Select all

xbps-rindex -a *.xbps

EDIT: I think you don't need all the xbps-install lines below now. Maybe all you need is:

xi -Sy poppler-qt5
xi -R $PWD frescobaldi

and that sorts out the other dependencies I think.
--------------------------------------------------------------------------------

Run the following commands from same location. (I think I have this order correct, as far as I recall...) Some of these will say already installed - so must be dependencies of python3-qpageview:

Code: Select all

xi -Sy poppler-qt5
xbps-install -R $PWD python3-qpageview
xbps-install -R $PWD python3-poppler-qt5
xbps-install -R $PWD python3-ly
xbps-install -R $PWD frescobaldi

Hmmm... still not right. I got SSL error with guile (on xi -R $PWD frescobaldi) so maybe have to use xbps-src method for now (EDIT: no... worked in the end - see below).

Hmmm2: I tried:

Code: Select all

xi -Sy guiile
followed by
xbps-install -R $PWD frescobaldi

and (making no sense) frescobaldi correctly then installed. Now it is almost 4am here and I am definitely sleepy. Finished.

I must say I like xbps-src, and that xbps-rindex -a stuff is new to me but seems to work well (thank goodness).

[geo_c]

This link may help you to understand the xbps-src method better: https://linuxiac.com/void-linux-xbps-package-manager/

Thanks, that's a very simple and informative link.

[geo_c]

So I'm trying to piece together the sum of all your installs. Let's see if this is close:

Method 2. Easier.

• Download the archive of frescobaldi xbps packages I made from: https://owncloud.rockedge.org/index.php ... X5to4bbayS

• uncompress that with command: tar xvf blahblahblahfilename

• cd into the extracted archive folder where the xbps files are

• run command:

  Code: Select all

  xbps-rindex -a *.xbps
  xi -Sy poppler-qt5
  xi -R $PWD frescobaldi
  

[geo_c]

@wiak

Man, you're a genius, you made a KLV package! It's running!

THANKS! KLV is a finished product for me now, for the time being, I can do a day's work on it.

I'm curious as to why after doing the index, that poppler-qt5 has it's own install command, while the other dependencies don't need it.

these lilypond files are about the closest I get to coding. It's a lua based script language, that's why if Geany is set to Lua formatting the lilypond file displays pretty well. I have config files for Frescobaldi 3.1.3 that really look nice and are high contrast.

THE 3.1.3 theme.xml FILE IMPORTS AND THE .ly FILE LOOKS LIKE THIS:

[wiak]

I'm curious as to why after doing the index, that poppler-qt5 has it's own install command, while the other dependencies don't need it.

Yes, I added that just because it had a problem with popper-qt5 when I tried it, but may be that the version changed upstream whilst I was working or something - I have no idea. It shouldn't need it if all the dependencies are correctly recorded in the frescogalbi xbps package, so may or may not be okay without that extra install line and I didn't have time to try it again.

[rockedge]

@wiak Nice work! and @geo_c good motivator/tester....outstanding results.

@fredx181 I have a KLV-Boxer-alpha2 with Zoneminder and servers installed and running. I am adding the technology from KLV-Airedale-beta15 (soon to be uploaded) to this Boxer version that uses JWM 2.4.1 and Rox pinboard for the desktop.
I accidentally installed mime-add-1.0_0.noarch.xbps which broke Rox-filer as we discovered earlier and I fixed Rox by scrolling further through the topic's posts and finding mime-add-1.1_0.noarch.xbps which after being installed fixed Rox-filer again.

We should consider taking mime-add-1.0_0.noarch.xbps out of circulation from this post -> https://forum.puppylinux.com/viewtopic. ... 387#p50387

or replacing it with mime-add-1.1_0.noarch.xbps

[wiak]

@fredx181 I have a KLV-Boxer-alpha2 with Zoneminder and servers installed and running. I am adding the technology from KLV-Airedale-beta15 (soon to be uploaded) to this Boxer version that uses JWM 2.4.1 and Rox pinboard for the desktop.
I accidentally installed mime-add-1.0_0.noarch.xbps which broke Rox-filer as we discovered earlier and I fixed Rox by scrolling further through the topic's posts and finding mime-add-1.1_0.noarch.xbps which after being installed fixed Rox-filer again.
We should consider taking mime-add-1.0_0.noarch.xbps out of circulation from this post -> https://forum.puppylinux.com/viewtopic. ... 387#p50387
or replacing it with mime-add-1.1_0.noarch.xbps

KLV-Airedale is definitely getting there in terms of functionality. We are definitely reaching the stage where polishing up the build plugin because the major task since easy to then work on it and further polish. I am happy to help with modifying existing earlier plugin but need manual command steps sent to me regarding parts that need added.

One little touch that could be improved is clicking on iso or sfs doesn't use filemnt out of the box - instead needing to right-click and select filemnt. I presume Open With and making filemnt the default for these extensions will do the job though, but if that association done in the build plugin that would be nice in terms of first use.

One excellent thing about KLV-Airedale is that it never gets out of date since Void a rolling release repo so once polished it could be stable distro for years! and gradually polished and refined, without continuous work needing done development-wise everytime upstream makes a new release (with rolling-release Void there is no such problem and apps get updated regularly by default). The choice of different desktop managers adds to its attractiveness overall too so users can select what they prefer and what is best to match the resource capabilities of their systems. Easy enough, on the whole, to make a 32bit build too (except some apps no longer available in 32bit form), so KLV-Airedale can be considered as a distro for any and all needs (of course we all distro hop and have our own favourites but good to have a distro that can be used or available for any purpose/situation. Only drawback is that Void Linux repos are medium sized only, but have most apps people want; for other apps we can gradually build up our own repo of packages in the future I think and that is also good for forum contributions and activity.

[fredx181]

We should consider taking mime-add-1.0_0.noarch.xbps out of circulation from this post -> https://forum.puppylinux.com/viewtopic. ... 387#p50387

or replacing it with mime-add-1.1_0.noarch.xbps

I attached v1.1 instead of v1.0 there.

[rockedge]

We are definitely reaching the stage where polishing up the build plugin because the major task since easy to then work on it and further polish. I am happy to help with modifying existing earlier plugin but need manual command steps sent to me regarding parts that need added.

Totally agree! I say we start with the WDLTeam RC4 PLUG file. It's as close as it gets to having all of the basics to build a KLV-Airedale but still without the polish and those manual steps setting the configurations.

Should we make it a GitHub project? Do the push and pull like reputable dev's? I'm still kind of a novice with Git though but willing to learn enough to get it going if I can.

Making the WeeDog-Void's with the jwm-rox desktops I injected the configurations by using configuration files included in the PLUG file and using remove and copy to replace them. Sometimes I used SED but being no expert at it, there is room for improvement.

Also some of the configuration files need to be found and understood on where they reside and how they work so we can effectively modify them during the build script run.

[geo_c]

While you guys are working on the final push, I'm wondering what the best options for printing might be. Should I go for CUPS in XBPS?

[Clarity]

... Should we make it a GitHub project? ...

There are 4 names that come to mind for a NEW GIT Project's guidance: @01micko, @jamesbond, @666philb, and/or @dimkr for initial setup and guidance. Each of these forum members KNOW the "ins and outs" for any new Puppy GIT projects. And should be able to help to provide any consistency this project would benefit from.

[wiak]

While you guys are working on the final push, I'm wondering what the best options for printing might be. Should I go for CUPS in XBPS?

Personally, I would use xbps since CUPS can be important system component and xbps is most reliable way to upgrade. In WDL distro Arch64 I certainly used official package manager for that (did use it since was for business). I haven't checked how big cups is to install though; may or may not swell the iso, and I think some official printer driver packages may be large, but I'm not sure. It may or may not therefore be good to build in for iso, but I do think xbps would do the job since official Void repo way of organising/customising major system components is usually good.

[rockedge]

@geo_c I would go with CUPS and see how it goes. There are also printer driver packages for example, Canon PIXA printer driver collection plus others for CUPS in the Void Linux repos

@wiak I'm on the verge of adding a KLV-PLUGS repo to my Github world........with perhaps a few variants to start with. I ran across a PLUG that had some newer additions and I will search for it again, but RC4 is a solid start.

[wiak]

Should we make it a GitHub project? Do the push and pull like reputable dev's? I'm still kind of a novice with Git though but willing to learn enough to get it going if I can.

There are definitely pros and cons to using git upstream site in formal way for a project like this. Advantages are known, but so is the huge (in practice) disadvantage of locking out all but the experts; aside from being able to raise 'issues' there (but requiring git site registration), which is yet another site to login in to and away from this forum. I don't myself like that at all in the sense that I think we do better from a community point of view to take 'issues' for discussion and implementation here on the forum. Git is already used, as you know, rockedge, as an archive site for WDL-specific core development work, but I avoid having to deal with issues and pull requests, which would simply complicate matters for me personally and be a pain. I wouldn't want another off-forum woof-CE type site if you see what I mean, despite that being the preference of Puppy devs. Rather I'll continue to publish the WDL components (WDL initrd, build_firstrib_rootfs, and build_weedog_initrd, and small WDL utilities such as wd_mount) via this forum (constantly updated WeeDog section thread post), but personally store these components on upstream git site. One of the points of WeeDog is to make its development and use simple and open to all, via simple and relatively short assessible and readable shell scripts (w_init making the whole thing particularly open to all for experimentation, suggestions, and individuality since acts as an external-to-initrd accessible plugin). It is simple enough, it doesn't need git to arrange simple collaborative work, and I don't want to create another woof-CE-like situation, despite that enthusiasm of Clarity and the discourse of 'dev professionalism'. Personally I feel forum activity/collaboration should be the focus of the 'dev professionalism' with a view to making the dev process involved more simply accessible to as many as possible.

WDL components will continue to be maintained by myself in the simplest way for myself and my own convenience, but build plugins, and addon system components being developed for KLV are entirely up to yourself and the rest of the forum community as to how you want to handle their development of course, but please try and keep the dev process as accessible to all - not everyone wants to register for any github site and learn that somewhat complex methodology, but of course some do. I'll contribute myself best I can either way or both ways but this forum site needs more activity here, not less. There is no extra status to be gained from using git! - but less regular forum members likely then to be involved (so less likely new dev blood) if that is the main mechanism unless we are careful to prioritise forum-thread-led-dev-channels.

Of course you may desire to learn that git-related process, which is understandable and good and fine, and I would encourage you to go ahead and develop the plug part there, but would suggest you also regularly publish the being-developed plugin here in a single forum thread location. Again, it is a single script (usually) so easy to publish here for examination and suggestions of addon code by others, without needing anyone to formally make pull requests to git site. So I suggest doing a bit of both, but keep it simple from forum activity perspective. I vote against a bigger git site approach - it isn't needed IMO. Note that DebianDog development also uses some git archive/resources, but seems to me that most of its development discussion/feedback/work occurs in forum threads here, unlike Puppy, where only a very very few 'experts' beaver away on woof-CE far away really from this forum community world. If key Puppy devs feel the urge to contribute to KLV developments here in the related forum threads they already also have every opportunity to do so of course, but I haven't seen much of that though most of us here have also actively contributed to Puppy Linux too one way or another.

[wiak]

@wiak I'm on the verge of adding a KLV-PLUGS repo to my Github world........with perhaps a few variants to start with. I ran across a PLUG that had some newer additions and I will search for it again, but RC4 is a solid start.

Missed your post prior to my last comment. Above is good, though as I said I hope we keep forum dev threads as main location/process for others to read and see the dev work going on so it is also accessible to everyone. Certainly we urgently need a reliable archive! Not so sure about the collaborative side of git being so useful to us, but the archive nature an essential to address our organisational mess!

[geo_c]

My fresh experience with xbps cups can be found here: https://forum.puppylinux.com/viewtopic.php?t=6099

[rockedge]

@wiak It's mostly about having the files in one place to work on. Instead of drifting out of sync versions scattered around. Most of the work will take place here in the forum. But as I add in the pieces having a centralized file will make it easier to keep track of.

Like I "lost" the plug file that had the most up to date additions and will have to start with a version significantly less sophisticated. So to avoid that again I am going to try to use GitHub and the forum. Even though here on the forum it becomes at times difficult to track additions and changes. As topics grow posts and spawn other threads.

Insuring the correct versions of the additions are included and not a broken example.

https://github.com/techrockedge/KLV-PLUGS

[wiak]

@wiak It's mostly about having the files in one place to work on. Instead of drifting out of sync versions scattered around. Most of the work will take place here in the forum. But as I add in the pieces having a centralized file will make it easier to keep track of.

Like I "lost" the plug file that had the most up to date additions and will have to start with a version significantly less sophisticated. So to avoid that again I am going to try to use GitHub and the forum. Even though here on the forum it becomes at times difficult to track additions and changes. As topics grow posts and spawn other threads.

Insuring the correct versions of the additions are included and not a broken example.

https://github.com/techrockedge/KLV-PLUGS

Yes, I understand and agree with your reasoning, but for me, recent work and these matters highlight another issue. We only have one KLV-Airedale thread and Users totally valid and important questions about installation of particular apps and system facilities on it (e.g. CUPS) can involve significant work and deserve a thread of their own most often. That way main KLV thread can concentrate on release usability issues and found bugs. One thread is fine when new distro in early development, but once it has a userbase, wider/bigger issues, questions and comments, naturally come in, so where in the forum structure is best for users to start such new issue-solving threads?

It is certainly very useful and excellent that you've created that new centralised plugin archive - otherwise losing major build files a major disaster! Also perfectly possible for those with git experience to make pull requests with code improvements, but I hope such requests and any issues raised also appears more directly on the forum here since adding to that plugin is not really so difficult and plenty of forum members could easily contribute in terms of the basic shell scripting understanding and related code-writing skills often involved; some of it is tricky of course, but more hands make lighter work! Simply reading the relatively simple plugin is very informative in terms of showing how things are put together, and even a shell scripting beginner could understand a lot of it with some online research study. The more a user understands the plugin, the more capable they become in getting the most out of the system (not required to use it of course, but great for those who like to modify and customise things), and so simple being just a relatively short single plugin script! That's the power of this simple build system - most anyone can contribute to it.

I will soon fix up the WDL git-related site again to make sue the build_firstrib_rootfs and other core build scripts are indeed the recommended latest. I think they already are but I have to check since I did get a bit slack with that. I note that github has moved away from allowing user/password authentication when pushing to the upstream site (okay via web interface I think, but generally I git clone to my local system, make edits, and then git push up again). I'll have to look into that OAuth or whatever it is called methodology (I have been using it for rclone access to my gdrive, but it was annoying and tricky to set up for that I found):
https://github.blog/changelog/2021-08-1 ... ting-down/

https://github.blog/2020-12-15-token-au ... perations/

Workflows affected
Command line Git access
Desktop applications using Git (GitHub Desktop is unaffected)
Any apps/services that access Git repositories on GitHub.com directly using your password

For mere mortals, I am going to open a new thread whose first post will contain download for a single cherrytree notepad that contains copies of all core WDL scripts and utilities (and probably some archived older ones too). Since I will be using that myself I will keep that first post resource updated regularly in line with any of my own WDL git related edits - which comes first, the chicken or the egg: in practice most likely my cherrytree file will be completed first and git resource a slight lag behind - I prefer that since I find cherrytree so useful and easy to manipulate - I'm so amateur in my approaches, I know! It will include the related weedogit script. Yes, you will need cherrytree installed for that but I can also publish an html copy of that notebook (since cherrytree can export to that format at the push of a button, or to pdf for that matter, and all linkable). I won't be merging in other people's cherrytree notebooks though!... it will just be my way of delivering a lot of information and files in one immediately usable blob.

[dimkr]

Uploading and downloading files with modifications to a forum is not a good way to collaborate on something. Most Puppy releases cannot be reproduced by users, and cannot be rebuilt with zero changes except an additional fix or two (= no updates, no maintenance releases), because they were built with a modified woof-CE version that was never published, and contain manually-built packages that are no longer available or cannot be rebuilt.

If you want to learn from Puppy's mistakes, use a discussion forum for discussion, and development tools for development.

[wiak]

Uploading and downloading files with modifications to a forum is not a good way to collaborate on something. Most Puppy releases cannot be reproduced by users, and cannot be rebuilt with zero changes except an additional fix or two (= no updates, no maintenance releases), because they were built with a modified woof-CE version that was never published, and contain manually-built packages that are no longer available or cannot be rebuilt.

If you want to learn from Puppy's mistakes, use a discussion forum for discussion, and development tools for development.

Point taken. But it is not easy to collaborate with as wide an audience as possible. Git sites are terrific for expert team collaborations, but if carefully managed by lead devs I believe other simpler systems can be used and be more inclusive to interested, not-always-so-expert contributors who do understand shell scripts quite well but are unlikely to bother with registration and login to git site involving also learning that often new to them, somewhat complex, procedure.

For me, important thing is to avoid a proliferation of copies of key files, or at least to make sure everyone knows where definitive versions can be reliably found. Git site can usefully be used even just as that archive and any alternative delivery methods must simply be kept in sync by those managing that resource - this project is not complicated to manage and inclusivity is more important to me at the end of the day. Majority of forum regulars, I suspect, are not likely to bother with git site (even when I used Puppy I rarely myself ever looked at that, except when I was playing around making makepup script for own fun) so catering for their interests in dev work here is what I strive for (despite any possible pitfalls - advantages of simplicity outweigh these in such simple project work in my opinion). Of course I do my own thing anyway. What methodologies rockedge adopts for the work he does and manages is up to him and other members of this forum contributing to these KLV-Airedale endeavours, but I don't see any issues with his plans from my point of view anyway.

By the way, sorry @rockedge, my related github and gitlab sites are out-of-date, which demonstrates in practice that even the most relied on dev sites are only as reliable as their maintainers! I'm more reliable, in that sense, when I'm adopting simpler (supposedly less reliable) mechanisms - this is just a hobby for me. I'll maintain my simple cherrytree WDL notepad though (which - simple/intuitive resource again - I'll shortly start publishing); like I said, that's what I myself use in practice most, so I have no choice but to maintain it reliably... That will only be published in one single forum thread first post however (and updated regularly by me when my local copy changes), so if you use an old version that will not be my fault (unlike the recent out-of-date WDL github/gitlab material...). Yes, there will be pitfalls, but overall, the notepad should prove useful and particularly accessible as a resource I find easy to maintain, to anyone interested in WDL.