Re: development best practices
Your i3status problem with an out-of-ports build is probably because the configure script runs "make" with a file that has GNU make syntax. Running it with "MAKE=gmake" in the environment fixes this (this is one of many things that are set automatically by the ports infrastructure). On 2020-11-28, Hannu Vuolasaho wrote: > la 28. marrask. 2020 klo 16.11 Stefan Sperling (s...@stsp.name) kirjoitti: > >> You can then extract your fix and apply it to an upstream development tree. >> If additional patches are required to get the software to compile, you >> might as well attempt to upstream those changes, too, while at it. >> > Is there a way to follow the development repository within the ports tree? Not directly. Point MASTER_SITES/DISTNAME to a tar, if it's on github you can use their on-the-fly tar generation like this GH_ACCOUNT= i3 GH_PROJECT= i3status GH_COMMIT= 3f27399d730bb9a66bebfed6aff2660828687ca5 DISTNAME= i3status-2.13pl20201009 and remove MASTER_SITES and EXTRACT_SUFX. "make makesum" to download and update distinfo. "make patch", if there are conflicts fix them up and "make update-patches", "make clean", and "make patch" again. Assuming you get it to build successfully you'll need "make plist" to update pkg/PLIST. When you use GH_* variables, DISTNAME is used to set the name of the file the tar is written to locally, and the default name for the package created - the format I showed above avoids interfering with possible future releases (ports has some checks to avoid a version number "going backwards" and avoid some changes being made to the port without changing the version or revision number - it can be cleaned separately but it's easier to avoid it in the first place). > The scenario is that I write some patch which fixes something and then > gets to the project tree. Then the testing and fixing cycle starts again. > > I know a few programs which are easy to compile in ~/src but writing a > port is PITA. There are some things like this, but once you're familiar with ports it's usually less of a PITA to write a port rather than figure out what the build/install has done to your system if/when you want to remove it.
Re: development best practices
la 28. marrask. 2020 klo 16.11 Stefan Sperling (s...@stsp.name) kirjoitti: > You can then extract your fix and apply it to an upstream development tree. > If additional patches are required to get the software to compile, you > might as well attempt to upstream those changes, too, while at it. > Is there a way to follow the development repository within the ports tree? The scenario is that I write some patch which fixes something and then gets to the project tree. Then the testing and fixing cycle starts again. I know a few programs which are easy to compile in ~/src but writing a port is PITA. Naturally that kind of port won't ever get to CVS but for testing and development. Best regards, Hannu Vuolasaho
Re: development best practices
On Sat, Nov 28, 2020 at 12:27:47PM +, björn gohla wrote: > hi all, > > i'm fairly new to openbsd. and i've run into the following problem, > where i want to hack a project (most recently trying to fix a possible > issue with i3status), but building the from the git source > tree fails. > > now, in the specific case, i'm trying to build a version that, > also exists in ports, so we know it can be built on openbsd; and i > presume the various patches included with the port are what makes it > work. > > i could of course try to apply those patches and fix my issue. but then > when i submit a PR upstream i'd have to remove them again. that seems > cumbersome, expecially if done repeatedly. > > so what is the best practice in this situation? should i just upstream > the ports patches? You could edit the source files which are extracted to /usr/ports/pobj/ when the port is built. If you modify a file the port has not patched yet, create a copy of this file with a .orig filename extension first. 'make update-patches' in the port's directory will diff files against their .orig versions and update patches the port's patches directory. You can then extract your fix and apply it to an upstream development tree. If additional patches are required to get the software to compile, you might as well attempt to upstream those changes, too, while at it.
Re: development best practices
Hi Bjoern, bjoern gohla wrote on Sat, Nov 28, 2020 at 12:27:47PM +: > i'm fairly new to openbsd. and i've run into the following problem, > where i want to hack a project (most recently trying to fix a possible > issue with i3status), but building the from the git source > tree fails. > > now, in the specific case, i'm trying to build a version that, > also exists in ports, so we know it can be built on openbsd; and i > presume the various patches included with the port are what makes it > work. > > i could of course try to apply those patches and fix my issue. but then > when i submit a PR upstream i'd have to remove them again. that seems > cumbersome, expecially if done repeatedly. > > so what is the best practice in this situation? should i just upstream > the ports patches? It really depends on the case at hand. Some patches can be upstreamed, only nobody did the work yet. Some patches cannot be upstreamed because upstream never makes releases. Some patches cannot be upstreamed because OpenBSD developers disagree with upstream about whether they are needed/useful/right. Some (few) patches cannot be upstreamed because they deliberately change functionality in the OpenBSD port only. So, let's assume you end up with some patches that will have to stay or at least to stay for now. Some of those may be required in the port, but the upstream build system may at least be able to do builds without them. Sometimes, development for upstream purposes can be done without having such patches in your upstream development tree. But you may well end up in a situation where a small number of patches may be required in your checkout of the upstream code to do upstream-style builds at all. In that case, you just need to be careful to not include these patches when sending patches upstream. And whenever sending patches upstream, you should of course consider whether those are indeed independent of any other patches you can't help having in your tree. Nobody can save you from the work of understanding every single patch you use before trying to send anything upstream... These ideas are good enough for a port with moderate amounts of patches (like textproc/groff). The x11/i3status port might be of a similar category. I have no idea whether working on a behemoth of the www/chromium kind (which has over 750 patches) and submitting patches upstream without causing mixups would be feasible on OpenBSD. There is certainly a limit to practicality, somewhere. Yours, Ingo
development best practices
hi all, i'm fairly new to openbsd. and i've run into the following problem, where i want to hack a project (most recently trying to fix a possible issue with i3status), but building the from the git source tree fails. now, in the specific case, i'm trying to build a version that, also exists in ports, so we know it can be built on openbsd; and i presume the various patches included with the port are what makes it work. i could of course try to apply those patches and fix my issue. but then when i submit a PR upstream i'd have to remove them again. that seems cumbersome, expecially if done repeatedly. so what is the best practice in this situation? should i just upstream the ports patches? thanks. -- cheers, björn
