No way to generate patches? Reliability and convenience issue.

[ghost]

Hi!

I need to port openal-soft and to make it work properly with sndio I need to take 3 commits since 1.19.0 release, but it adds changes to other backend files. It's a tedious work for me to manually run diff -uNp file.orig file > patches/patch-file, there should be some other way. Chapter 7 mentions nothing about this and I don't get what exactly ravenadm dev repatch does (can it do the equivalent what I describe below)?

For example, in OpenBSD experience I have to cd to WRKSRC directory, backup every file I need to modify with .orig extension (cp main.c{,.orig}), modify the file/files (vi main.c), cd back to ports directory and run make update-patches.

In this example I'd like to checkout upstream repository, run git diff ... > openal.patch, then cd into ports directory, fetch and extract release tarball, cd into WRKSRC directory, run patch -i openal.patch, cd back into ports directory and run ravenadm dev update-patches or something like that to generate all patch files in the patch directory.

[jrmarino]

yes, install the "genpatch" package. it comes with a man page and 3 programs: dupe, genpatch, and portfix, the latter of which calls the first 2 in order. It's provided in the build environment. I often create patches in test mode interactive, copy the patch to the /distfiles directory, leave the test environment and move it back to the /patches directories of the port. But you can use genpatch externally.

[jrmarino]

"dev repatch" just automatically regenerates patches that already apply to remove fuzz and offset lines.

[ghost]

@jrmarino I'll mention that tool in wiki after I finish the work with ports in PR.

[ghost]

Hm, I'll need to write a script which will find all .orig files and call a genpatch at every modified file, doing that manully is still tedious :)

[jrmarino]

i guess I don't understand what you are trying to accomplish, or what your starting point is.

[jrmarino]

At first this sounded like a generic question, but it seems you're doing something unusual here.

[ghost]

@jrmarino look, in convenient way it should detect all .orig files and automatically place all patch- files into patches directory. In this case I ran genpatch over and over again and then made `mv patch- path-to-port-directory/patches/`

[jrmarino]

i guess you need a small script to iterate over a list of filenames. distfiles are untrustworthy. It's very common for them to have .orig files packaged, just garbage left over that gets in there. Plus the .orig files have to come from somewhere, meaning there was an original patch. "dev repatch" basically does this, but it assumes the patches in the /patches directory apply fully. The other thing to consider, if the port in question has dozens of patches, it's obviously not designed for the platform in question which means it's basically nature of the beast.

[jrmarino]

if the changes come from a git repository, what is often done is to take the git patch (which may change many files) and just use that, by remove "/a" and "/b" text to make it apply. If there is more than one of these, the patch has to be renamed so it applies in order. That's sometimes an easy way to get forward port commits.

[kraileth]

This is certainly no longer relevant.

[ghost]

@kraileth no, this is still relevant, furthermore I want to complain about vi fascism, because I use ed as my text editor, but chroot only offers vi, but I prefer ed

[kraileth]

Well, just copy ed over into your sysroot, then you'll have it available. I still have to read Lucas' "Ed mastery". Should I also fall in love with the tool, I'll probably support adding the default editor by default. g

But seriously: I closed this after you disappeared from GH. I'm ok with re-opening the issue, but you should probably try to describe the issue in other words again.

[ghost]

@kraileth hm, time to close this issue, because trying it differently I now have a convenient workflow:

% ENTERAFTER=extract ravenadm test portname

then outside of chroot (this is not the productive usage of Acme, but whatever):

% cd /var/ravenports/builders/SLXX/construction/portname/distname
% su
% chown -R myname .
% exit
% export EDITOR=/raven/plan9/bin/acme
% export WORKHERE=y
% portfix path/to/file
% portfix path/to/file2
% mkdir /home/myname/ravensource/bucket_AB/portname/patches
% mv patch-* /home/myname/ravensource/bucket_AB/portname/patches/

and as @jrmarino mentioned, if I was working inside fossil/git/darcs/pijul/hg/cvs/snv repository and generated patch with anyvcs diff > mess.patch, I can place it inside patches directory and run ravenadm dev repatch

initially this issue was about me used to OpenBSD's workflow and not having Ravenports's convenient equivalent (but it's not true now as you see above):

% make extract
% cd /path/to/wrksrc
% su
% chgrp -R mygrp .
% chmod -R g+w .
% exit
% patch < path/to/patch/file/which/modifies/multiple/files
% cp path/to/file{,.orig}
% ed path/to/file
% cp path/to/file2{,.orig}
% ed path/to/file2
% cd -
% make update-patches

OpenBSD's convenience is that make update-patches locates all *.orig files and generates patches into patches directory (which is not a subdirectory of wrkscr), Ravenports's convenience is that it creates *.orig files, opens my favorite editor and then generates patch-* files. just thinking about it now I finally find Ravenports's workflow much better and more convenient than OpenBSD's one and the lack of feature to detect *.orig files and automatically place patch files into ports's patches directory is not important at all, fuck OpenBSD :)

yes, I've read "Ed Mastery" book before I disappeared from github and recommend to read it too, then I recommend you to use Plan 9's IDE called Acme, it understands ed's commands and makes you really productive, but if you are in environment where it's impossible to use Acme, then using ed is the best option (I can use both vi and emacs, but they are harmful inconvenient shit and using keyboard instead of mouse to move cursor is really ridiculous)

also I disappeared from github because I was simply angry on open source in general (it's shit, really), so 6-7 months ago I removed my e-mail and github accounts and switched to windows 10 just to live in peace, I had real peace first 3 months, but then windows 10 started to annoy me and you know what? I hate literally every software (especially windows, linux and bsd) around me except Plan 9 (it's genius)

[ghost]

@jrmarino speaking about that, the two ports that I broke by removing my github account and OrangeGrayCyan organization are warsow and opencvs (unfetchable distfiles), I recommend to prune warsow and warsow-data ports because this game is dead, almost all players moved to fork of this game called warfork, I am community advisor there (I am surprised their leader was looking for me all this time after I disappeared) and there is a branch which includes my patches to make warfork work at every bsd, now talking about opencvs there are commits made to it recently, but I am going to do nothing about this port because cvs itself is no longer relevant to me and I simply don't want to take responsibility for hosting distfiles, but if somebody is willing to host actual distfiles (it's as easy as cvs -d anoncvs@anoncvs.openbsd.org:/cvs checkout src/usr.bin/cvs && cd src/usr.bin && tar zcf opencvs-xxxxxxxx.tar.gz cvs), then I am willing to unbreak this port

[jrmarino]

Okay, I removed warsow* ports. opencvs isn't actually broken -- we cached the distfile.

On Fri, Jan 24, 2020 at 4:51 PM Leonid Bobrov notifications@github.com wrote:

@jrmarino https://github.com/jrmarino speaking about that, the two ports that I broke by removing my github account and OrangeGrayCyan organization are warsow and opencvs (unfetchable distfiles), I recommend to prune warsow and warsow-data ports because this game is dead, almost all players moved to fork of this game called warfork, I am community advisor there (I am surprised their leader was looking for me all this time after I disappeared) and there is a branch which includes my patches to make warfork work at every bsd, now talking about opencvs there are commits made to it recently, but I am going to do nothing about this port because cvs itself is no longer relevant to me and I simply don't want to take responsibility for hosting distfiles, but if somebody is willing to host actual distfiles (it's as easy as cvs -d anoncvs@anoncvs.openbsd.org:/cvs checkout src/usr.bin/cvs && cd src/usr.bin && tar zcf opencvs-xxxxxxxx.tar.gz cvs), then I am willing to unbreak this port

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jrmarino/ravensource/issues/116?email_source=notifications&email_token=AAISZ5TIRLE3MXD52RGUUL3Q7NWH3A5CNFSM4FYEKWA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ4KT6Q#issuecomment-578333178, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAISZ5TJ6R63TIZY67TRQK3Q7NWH3ANCNFSM4FYEKWAQ .

[ghost]

please close this issue, I already stated above that I finally understand how it works and that is really convenient

[kraileth]

Closing as this has been sorted out.

(@goleo108 interesting story, BTW. While I kind of agree with you, I'm not going as far as actually hating them all, but they sure have flaws. My view on this is that while things in Linux land things tend to get worse, in BSD they at least get better. Still I'm hoping for a modern newcomer like Redox to become usable. Because while it of course has been modernized, the stuff that we work with every day simply has its foundations in another age. And in the case of Linux, it's also the big players are getting their hands on it and push it in the direction of their needs, not the user's. Commercializing ruined what the internet once was and now they are about to ruin the penguin. Probably it's not such a bad idea to go for a niche like DF.)

[ghost]

@kraileth the only reason I even take a look at bsd is because on linux both audio (alsa is shit), networking (wtf?) and static linking (I just shouldn't use glibc?) are broken, but bsd is not better than linux (but linux is still a large mess), furthermore historically bsd started to ruin Unix, making it slow, inconvenient and overcomplicated, miserable, then we have assholes from gnu who made things worse than they already are, making the whole world miserable (but that doesn't make bsd angels)

every current Unix implementation (reimplementation) is overcomplicated shit which simply follows ridiculous standards, there is no real innovation, it's impossible to make innovations by reimplementing existing things and following standards, it's just now you have a fuckton of Unixes and the choice is tough because you end up tolerating ridiculous issues mostly specific to concrete implementation and then a fuckton of issues specific to every fucking implementation, openbsd folks mock everyone for not helping to solve problems and for not respecting the hard work theo de raadt and others are doing 25 years, but fuck that hard work, because their hard work aims bullshit from the beginning and a shit result, but I finally can solve my problems by simply removing openbsd from my hdd, openbsd is a problem, not a solution, just like every other bsd and fuckton of linux distros

I take a look at Plan 9 because it's different, it is not Unix and it doesn't follow standards, but in the same time it is what Unix is meant to be, full of tools which are simple, powerful and convenient

9front is a fork of Plan 9, I counted that it has 3 million lines of code (because there is necessary shit like mercurial, python, ghostscript and their dependencies) and you know what? on one 3.5 GHz CPU core it takes fucking 90 seconds to compile entire operating system, just to make a comparison somewhat fair dragonflybsd has 12 million lines of code and it takes more than 2 fucking hours to compile entire system on four 3.5 GHz CPU cores

I ran dragonflybsd this month because I wanted to completely get rid of linux by porting wine (because I use steam and play team fortress 2 with my family, but steam and tf2 don't natively support dragonly) after codeweavers will merge their patches into wine (allowing to run 32 bit apps on 64 bit system without operating system's support) for macos catalina, I didn't see openbsd as an option because its bullshit mitigations will make most windows programs crash, but I changed changed my mind, I don't believe I'll avoid crashes on dragonfly, so I decided to have 9front and linux on my two machines, I don't want to fix and improve any Unix implementation, instead I want to develop on Plan 9, I want to improve Plan 9

[ghost]

please note that I am still working on cleaning warfork's code, I already made sure it runs on bsd, so I'll port it to ravenports using linux because it's simply impossible to unintentionally break game's engine crossplatformability I achieved by removing 41 thousands lines of code