- This topic has 32 replies, 8 voices, and was last updated Jan 5-6:32 pm by marcuscf.
-
Posts
-
Anonymous
can be “challenging”
Okay, I recognize that casually typing “if suitably motivated” was probably a too-dismissive remark. I hope to inspire folks to “just try”, but sometimes fail to mention non-obvious details which can (will!) result in frustration when approaching a new task (like learning to deal with git, and/or the compiler(s), and/or the debhelper packaging software).
anecdote:
(I’ve mentioned this previously, but)
For a decade I have been waiting for, hoping for, the arrival of a suitably granular, gui, linux-native application firewall program. Finally, it’s (mostly) here ~~ and the program is named “opensnitch”. Soooooper excited, I downloaded its source code from github and, while following the provided howto I encountered a step, an instruction, to “go get suchandsuch“. So I websearch and find the suchandsuch (a separate component, dependency of opensnitch, not maintained by the opensnitch developers)… and after downloading it, upon trying to proceed with the next step of the “build”, wind up with an error message whining “get not found”. “What?!? Grrrr… it’s right THERE, you silly ass. I placed suchandsuch in the exact subdirectory, as instructed.”
-=-
Haha, funny now, but was NOT funny at the time. Part of the opensnitch source code is written in “Go” (golang)… and “get” is a Go library, containing a same-named “get” program, which was not among the base libraries (as packaged by debian). Frustration ensued because I had failed to recognize significance of the literal, and explicit — “get not found” errormessage. FWIW, ultimately, after tripping my way through a successful build-n-install, I discovered that the WIP opensnitch program is, as advertised, still “not yet ready for primetime” (is plagued by corner-case bugs and its featureset is incomplete).isn’t too difficult to build
regarding “wait for” vs “dive in, and embrace the bleeding edge”…
We should keep in mind (and I often fail to do so) that public “project git repositories” provide an over-the-shoulder and sometimes up-to-the-minute “status” of the project’s code. Not all repository maintainers “tag” releases (thereby signalling to any watchers “Hey, as of right now, the recent batch of changes incorporated into the codebase yields a solid/tested runnable program“). @BobC — when I downloaded and tried to build bbiduock’s “master” icewm branch last week (2wks?) it failed. Plenty of other puzzles on my game table in recent weeks, so I just nixed the downloaded code and moved on, toward the next shiny thing…
Brian Masinick
What you guys have shown and demonstrated is that various different applications have different levels of complexity – and therefore, vast differences in what you may have to learn and add before you achieve success. In my earlier example about GNU Emacs it wasn’t really too bad because even the specific steps were very well documented (though some of the “words” certainly require a “certain level of knowledge”.
I don’t have any idea how difficult generating a source code version of IceWM is at the present time.
From those of us who have compiled source code at ANY time, past or present, is there anyone willing to try it?
If not, I *may* give it a try, but I do not and will not *promise* or guarantee to do so.
Though I am retired, there are a surprising number of things to do in any given day, and they are more in the category of things we have always liked or wanted to do…Any venturesome people out there, novice or experienced? Everyone has to start *somewhere*.
--
Brian MasinickBobC
Marcelo, I will keep this simple so nothing is lost in translation. IceWM is a complex program and to make a fix to it requires developer tools and knowledge and skills, even if you already have all the code and it all works correctly together.
If you need the preferences fixed in the meantime, use the editor via control Centre to fix it manually.
I would guess but not promise (because we never know what problems might appear) that the fix will be implemented within a few weeks.
We could try to implement the fix ourselves, but it’s not worth the extra effort and risk just to get it sooner unless it was really critical.
That is just my opinion
Ps: what Brian said is true, but it would make sense to start learning on something simple that isn’t critical to the system functioning. Imagine if after you fix it, IceWM doesn’t work at all…
- This reply was modified 2 years, 4 months ago by BobC.
From those of us who have compiled source code at ANY time, past or present, is there anyone willing to try it?
BobC mentioned that he had successfully compiled it, in order to confirm the recent fix, right?
(at least, that was my takeaway)Probably unclear in my post… I had previously, repeatedly, compiled the icewm package. My point was:
On that particular day, when I grabbed the then current MASTER git branch (vs a tagged release) it would not successfully compile.
When it does compile, on my system the process takes < 5 minutes.
> I *may* give it a try
The prerequisites, including system specs, are probably the “limiting factor” regarding whether someone should perform a DIY build.
The “apt install git” step, that alone installs 160MB (IIRC).
The “build-essentials” package and comrades… I can’t recall, maybe another 140MB
I tend to bake those into a snapshotted, otherwise pristine ISO, then build using throwaway virtualbox instances. That (overhead of running a second OS, and building/testing in virtualbox) might exceed the specs of many older systems, so I seldom mention/recommend that detail.I noticed Xecure has picked up the task building for multiarch and providing assorted debfiles.
Currently, I’m building/testing against only antiX19 (full, stablerepos) 64bit.
Locally, all the antiX machines I support are (only) running antiX17-live (not 19).In any event, I’m not keen on the “puppylinux -ish” practice of having any ol’ JoeBlow (including me) distributing compiled software for mass distribution.
No, skidoo, I didn’t compile and test This fix. I did it once before, thanks to help from you and eugen I think. I compiled it as is first, to make sure I was doing it right, tested to make sure the problem occurred and then made the minor fix and compiled again and retested to make sure it was fixed.
My method was a bit different. I took the current antiX version of IceWM and then hand coded in the changes because I didn’t know how to do it automatically, and compiled that. I did not work from the master version. Lol, as you might guess, I don’t actually KNOW what I’m doing with all of that process, but was able to guess well enough.
doing it right
an awkward admission:
skidoo has not been coaching “howto do it right“. If one were to follow by the rules, so to speak… one would enable deb-src repos and “apt install build-depends <packagename>” and (probably) use pbuilder. My coaching mentions using dpkg-buildpackage, and occasionally tweaking and manually running automake in advance of setting loose the “debhelper” utilities, and willy-nilly downloading from a github repo and “winging it, to see what sticks”.example: How many times have I typed, unchallenged, “sudo dpkg -i yourpackage” ?
I noticed (yeah, “duh”) in a recent post by anticapitalista, the more ideal instruction:
“sudo apt install /path/to/yourpackage”hand coded in the changes because I didn’t know how to do it automatically
sudo apt install meld
(or, you may prefer kdiff3-qt or other “diff gui” program)Select 2 files (or 2 project directories!) in spaceFM, then Open}Choose}Meld
voilàalternatively, from the commandline:
meld /pathto/file1 /pathto/file2__________________________
Within a debfile source package, you may encounter a debian/patches/ subfolder.
https://www.debian.org/doc/manuals/maint-guide/modify.en.html
Those can be manually merged using “quilt” (or probably other “diff n patch” utility).
(manually merge, or cherrypicked deletion of, patches is nearly always unnecessary when you are just downloading something then running dpkg-buildpackage)FWIW, toward understanding the nuts-n-bolts significance of changes to the code I’m handling (and, arguably, contray to BestPractices) I tend to “cherrypick and hand code any changes introduced via patchfiles, even though I’m aware how to do it automatically“.
Brian Masinick
Back in my “UNIX days” I used to use a tool called mgdiff because it had a nice color scheme – it was really easy to see side-by-side differences.
While there are a lot of different tools, ones similar to this are still very useful. Mgdiff happens to have a few additional variations to use with cvs, and rmgdiff can come in handy too. All of them are based on diff, a standard differences tool, but the mg variations offer BOTH color AND side by side views, which is why several people in the UNIX group used them and there is a definite following for the tool even today.References:
https://reposcope.com/man/en/1x/mgdiff
https://reposcope.com/man/en/1x/rmgdiff
https://search.yahoo.com/search?p=mgdiff&fr=ymyy-t&fr2=p%3Amy%2Cm%3Asb--
Brian MasinickBrian Masinick
If you are “careful” in development, coding, verification, testing, etc. it’s really a matter of style. On the other hand if specific tools are available, especially if they minimize the failure rate, they make sense. Code review and more than one set of eyes examining and questioning any change are useful, but just having someone “sign off” on a change without really looking at it, comparing, reviewing, and testing it can lead to false confidence and greatly increased opportunities for errors.
My best mentors who helped me out took the time to show me my errors and also the best practices. Alas, some of the specifics are fading away, but I can tell you that rigor and careful work is more critical than the choice of tools.
--
Brian MasinickYes, I know how to use meld and have it loaded. But I see these files with + signs next to lines added and – signs next to the lines deleted. I created a github account, and today created an ssh key. I know how to clone, and can tweak something on my machine and compile it, but don’t know REALLY how to correctly contribute to a project. I am trying to learn, but its not anything similar to what I’m used to. It bothers me. On other systems, I know the systems. Here, I am learning and guessing.
Anyway, its fine to mess with things for yourself as a fun project, but I don’t want to be compiling something major that I don’t really understand and distributing it, only to find I messed something up on other people’s systems. skidoo said something similar above, and I agree.
> how to
correctlycontribute to a project
Even without git installed on their local machine, someone can have a github account (and or gitlab and or other git/cvs projecting sites) and login n browse projects, looking for typos in docs and other non “coding” fixes. They can click “clone this project” and, in the cloned copy residing in their useraccount repo… edit the files, upload images, make whatever changes… then click “submit merge request”. The upstream project maintainer(s) will be notified of the pending merge. After inspecting the proposed changes, the maintainer may post a message to ask questions or suggest alterations, or may immediately approve the merge and just_like_that… your contrib is part of the project.With the git software installed on your local system (or on a dedicated LANserver), you can “host” repositories and grant permissions for your machine and others on the LAN… or (not my cuppa tea) open a firewall port and share/host project repositories with others. If you did (host), the barebones git software is commandline only. For a user-facing gui, you could install the (very same) web-facing software that “gitlab.com” is running. Also, “gitea” (and a couple other opensource flavors) providing webgui frontends are available.
aside:
Git has a lot of features, most of which I’ve never used.After “apt install git” on your local system, you can (a “for instance” workflow):
Login to gitlab.com, navigate to the .com/antix-linux/slim-antix page
and click “clone this project”. Within a few seconds, you’ll be redirected to a freshly-created copy, owned by you, residing at .com/myuserspace/slim-antixImmediately afterward, from commandline on your local machine, you can:
cd /some/directory
git clone https://gitlab.com/myuserspace/slim-antixThat operation will mkdir /some/directory/slim-antix
and download into it, via https, a copy of the master branch of your remote slim-antix project repository.Few (very few, if any) among the antix projects have multiple “branches” (branches other than “master”)
and offhand I don’t even recall the exact syntax for cloning an alternate branch.
That’s okay “git –-help” or “man git” is always available, as needed.After editing/adding files within your directory /some/directory/slim-antix
(which, technically, is a local git repo ~~ can be made accessible to others on your LAN)
“git add *” will create a manifest of altered files and
“git commit” will (hmm, terminology?) ‘post’ them into the project, after prompting you to type a brief description of the changes in the commit. For me, the editor which pops open when I type “git commit” is nano; more often than not, I simply type a dot (anything, so that the ‘msg’ is non-blank) then Ctrl+x then “Y”.If your download via “git clone httsomeremote” intent was to just grab a copy of the software and tweak/compile for your own use, the “add” and “commit” operations are probably pointless. (Idunno — you might care to optionally install one of several a git-gui client apps which provide a view of commitlogs/branches, or print-n-grep commitlogs on the commandline). You can immediately “cp /some/directory/slim-antix /some/place” and compile. You could, alternatively, compile right in the downloaded directory (and discard that dir afterward) but I recommend against doing so.
When you are ready to share/publish to the remotely-hosted copy of the project you are working on:
git push https://gitlab.com/myuserspace/slim-antixThe remote server (or the local git software, in advance of contacting the remote server)
will present a commandline username+password prompt, then will upload the freshly-edited files.
Immediately afterward, by refreshing you web browser page, you can note the changes are now reflected in the remote copy.Next (and finally), click “send merge request” button on your gitlab project page.
-=-
Caveat: some users have (via preferences at gitlab site) email alert notifications enabled, others don’t. I have sent merge requests which have sat unnoticed for well over a year. Conversely, some of my projects have received merge requests (or “issue ticket” messages) which have remained unnoticed (by me) for several months.
-=-
Via your account page on gitlab, you can track the status (pending/merged/rejected) of merge requests you’ve sent (as well as tickets you’ve opened, or participated in, etc.)
-=-
You know (but others reading this may not) gitlab.com is a separate entity from github.com, requires a separate account. While logged in at the gitlab site, you can clone or import projects hosted at github URLs or hosted at salsa.debian.org or git.devuan.dev or any other publicly accessible githosting server.Most people are used to receiving binary packages and very complete systems, but I can tell you that MANY software components (in fact, ALL GNU software components) ARE available and MUST be available somewhere in source code form.
I used to routinely compile my own instances of GNU Emacs back when I had a UNIX workstation.
The quoted post reminds me:
Beyond the “satisfaction, from self-sufficiency” aspect, there is a potentially huge performance benefit to be gained by compiling a given program “natively”, on your own hardware. The compiler directives specified for “software packaged-for-mass-distribution” are only a best guess ~~ a guess toward “hmm, which one size will best fit all?” (or, “hmm, which permutation will result in the fewest ‘plz help. it dont work‘ bug reports”)
IceWM 2.0.1 has been released and includes the fix.
commit 2be556424a8985278a363a009fea1ea4a985a463
Author: Bert Gijsbers <gijsbers@science.uva.nl>
Date: Thu Dec 31 22:37:27 2020 +0100Fix setting option values for #535.
src/wmprog.cc | 6 ++++–
1 file changed, 4 insertions(+), 2 deletions(-)
anticapitalista
Already built, packaged and in antiX repos.
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
- You must be logged in to reply to this topic.
