Re: Porting Practice
Please be aware that this port is maintained by x...@freebsd.org and anyone who is subscribed to the x11 mailing list will get the portscout messaged. This does not mean it is intended that aloof those who subscribe to x11 are responsible for making repaired. If you have not done so, check bugzilla for any existing PR and, if there is one, check it in case it is already being worked. If not, attach your patch to that PR with a description of the fix. If there is no PR, you should open a ticket in the bugzilla with a subject "[patch] x11/nvidea-settings Fix compilation errors". Attach the patch and select "Maintainer approval requested". Include a description of the problem and how you patch fixes it. The leader of the x11 project Nicklas Zeising, is responsible for approving it. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 On Sat, Jul 4, 2020 at 10:33 PM Jonathan Chen wrote: > On Sun, 5 Jul 2020 at 14:06, Brandon helsley > wrote: > [...] > > > > Yes it does, I understand how it works now, I just needed an example, > and I can compare this with other methods to figure it out. How do you get > the port working in your directory? > > In general: > 1. extract the original sources elsewhere > 2. hack it to compile > 3. compare the hacks against the original sources again to generate diffs. > 4. put the diffs into the files/ directory of the port > 5. Tweak the Makefile for all targets (fetch, extract, build, stage, etc) > > Cheers. > -- > Jonathan Chen > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: why does pkg try to install an older version of pkg ?
Hi! > > You could grab packagesite.txz from your repo, untar that and then > > grep '"name":"pkg"' packagesite.yaml > > Any brokenness in /var/db/pkg/ ? > > How would I recognize brokenness ? The files that should be there > are there. > > > There's a per-repo sqlite3 database which you could query like this: > > select name, origin, version from packages where name = 'pkg'; > I've tried, and it showed pkg-1.14.6 as it should be. So, had a second system, same pkg-version before, and it has the same problem. sqlite> select name, origin, version from packages where name = 'pkg'; pkg|ports-mgmt/pkg|1.14.6 > Status-update: Our package builder (repo.nepustil.net) finished > build for a new pkg-repo, and now the upgrade went through without > regression to pkg-1.10.5_1 8-} Well, this did not help for the second system with that problem 8-( -- p...@opsec.eu+49 171 3101372Now what ? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: why does pkg try to install an older version of pkg ?
Hi! > So, had a second system, same pkg-version before, and > it has the same problem. Found a fix with: pkg update -f Then pkg upgrade does the necessary stuff. -- p...@opsec.eu+49 171 3101372Now what ? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Porting Practice
> On 5 Jul 2020, at 02:46, Brandon helsley wrote: […] > The documentation for (diff -u) says "To create a suitable diff for a single > patch, copy the file that needs patching to something.orig, save the changes > to something and then create the patch:" > % diff -u something.orig something > something.diff > > Im not sure really the meaning of this documentation. What file needs > patching, which file to copy, where to save changes to exactly, and how and > why the svn method is different. Which method should I choose? I know it says > that unified diff and svn are preffered but since I am new maybe the (diff > -u) command would be easier to begin with? Please help and include anything > that's relevant even if i didn't mention it. I'm really excited to get > started and will absorb like a sponge any know how that's offered!!! For making changes to a port, I find ’svn diff’ to be the easiest way by far. I tend to do this: 1. svn up my work-in-progress ports tree 2. Make the changes and run tests (portlint, poudriere testport etc) 3. cd /ports; svn diff thecategory/theport > /portpatches/thecategory_theport_version.diff (change the paths to the dirs of your choice) 4. Upload the .diff file to Bugzilla Since I use svn in step 1, svn takes care of tracking the changes so I don’t need to keep .orig files and run diff by hand. The diffing that Jonathan mentioned is more applicable if you have to make changes to the upstream code itself in order for it to work on FreeBSD. I personally do that in the port’s ‘work’ dir and create the patches with ‘make makepatch’, and there I need to create .orig files (cp file.c file.c.orig before making changes). Hope this helps, Vidar Karlsen ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: set_rcvar() function use?
сб, 4 июл. 2020 г. в 08:11, Hiroki Sato : > Mateusz Piotrowski <0...@freebsd.org> wrote > in <34921b6e-ce3a-13e4-0cc1-3ca47b5a9...@freebsd.org>: > > 0m> > I am planning to revisit the multi-instance support shortly because > I > 0m> > am using it for a long time and I think it is useful. While I did > 0m> > not receive a strong objection to it so far, it is also true that > 0m> > adopting the set_rcvar() style was not discussed properly. I would > 0m> > like more feedback before moving forward. > 0m> > 0m> AFAIR, manu@ was concerned at some point that using set_rcvar() > extensively > 0m> might result in slowdowns on embedded systems. > > A discussion in the past about the performance was an additional > fork(2) when using set_rcvar() for rc_var=`set_rcvar`. The use case > of the resurrected one is "set_rcvar A B" as a replacement of "A=B", > and it does not involve a subshell. > > I agree that the performance perspective should also be discussed, > though. The current rc.subr and network.subr already have more > expensive operations, so we might want to gather profiling > information. > > Thanks a lot for the answers! It's great that the only existed concern is not a problem anymore for the resurrected "set_rcvar A B" form. IMO features like setting variable description and ability to "ask" rc script what variables/options are available are really great even without multi-instance support. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Updating py27-* ports
On Sat, 4 Jul 2020 10:23:09 -0600, @lbutlr stated: >On 04 Jul 2020, at 08:30, Carmel wrote: >> I see that you are putting it all on one line. That is probably >> easier. I like the separate entries technique simply because I find >> it easier to read myself or quickly comment out an entry. > >I agree that separate lines have advantages. When making changes I >tend to go to multiple lines, then collapse back to a single line when >I have a stable set. > >> What I have never been able to get a definitive answer to is exactly >> what the "+" does or if it is even needed, I have seen >> 'default_versions" both with and without it. > >+= adds the option, = set it. > >DEFAULT_VERSIONS=foo bar sing >$DEFAULT_VERSIONS foo bar sing > >DEFAULT_VERSIONS+=max >$DEFAULT_VERSIONS foo bar sing max > >DEFAULT_VERSIONS=sam >$DEFAULT_VERSIONS sam Thanks -- Carmel I never slept with an ugly woman, although I certainly woke up with a few. pgpimKP5rOkhg.pgp Description: OpenPGP digital signature
latest Makefile breaks compilation of security/clamav if base is lacking sendmail
Hi,
I am running 12.1-STABLE (r362940), ports head (541271) and compile all my
ports with poudriere-devel
My /etc/src.conf contains …
WITHOUT_SENDMAIL=yes
… thus I do not have /usr/lib/libmilter.so in base.
The recent modification of security/clamav/Makefile breaks my setup (again [1],
see
https://lists.freebsd.org/pipermail/freebsd-ports/2018-December/115116.html).
Error message ...
checking for mi_stop in -lmilter… no
configure: error: Cannot find libmilter
...
*** Error code 1
… and after having that fixed another error:
checking for mi_stop in -lmilter… yes
checking libmilter/mfapi.h usability… no
checking libmilter/mfapi.h presence… no
checking for libmilter/mfapi.h… no
configure: error: Please install mfapi.h from the sendmail distribution
===> Script "configure" failed unexpectedly.
...
*** Error code 1
I managed to get compilation working with the attached, surely crude and dirty
hack (due to my lack of knowledge regarding ports Makefiles), by adding
'MILTER_LDFLAGS= -L${LOCALBASE}/lib' and 'MILTER_CFLAGS=
-I${LOCALBASE}/include' in order to help finding relevant files from port
mail/libmilter.
What worries my somehow, although clamav is working as usual, is the following
part in poudrier's log:
checking for mi_stop in -lmilter… yes
checking libmilter/mfapi.h usability… yes
checking libmilter/mfapi.h presence… no
configure: WARNING: libmilter/mfapi.h: accepted by the compiler,
rejected by the preprocessor!
configure: WARNING: libmilter/mfapi.h: proceeding with the compiler's
result
checking for libmilter/mfapi.h... yes
Here my question: Is this the right way to fix this issue?
Thanks and regards,
Michael
[1] no pun intended
patch
Description: Binary data
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
RE: Porting Practice
In general: 1. extract the original sources elsewhere 2. hack it to compile 3. compare the hacks against the original sources again to generate diffs. 4. put the diffs into the files/ directory of the port 5. Tweak the Makefile for all targets (fetch, extract, build, stage, etc) Im not sure what "original sources" means or "hack it to compile". Really would you please go into more detail about the first three steps and explain the targets in step five? I understood your first message well and can get the nvidia-settings.patch placed in /tmp/ but before that step when I am supposed to... get the port working in my working directory I get stuck. From: Jonathan Chen [j...@chen.org.nz] Sent: Saturday, July 4, 2020 7:07 PM To: Brandon helsley Cc: freebsd-ports Subject: Re: Porting Practice On Sun, 5 Jul 2020 at 12:47, Brandon helsley wrote: > > I have gotten a couple of emails from portscout about ports that need updated > and maintained. Before I go about updating and maintaining these ports I > wanted to do some practice on a couple that I use like x11/nvidia-settings. I > have recieved alot of help on the forums and from the documentation, but i'm > still at a loss as to how the diff process works. [...] This is my personal workflow: 1. Take a simple copy of the port into my working directory 2. Get the port working in my working directory. 3. cd my-working-directory 4. diff -ruN /usr/ports/x11/nvidia-settings . > /tmp/nvidia-settings.patch 5. submit patch onto bugs.freebsd.org Hope that helps. -- Jonathan Chen ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
RE: Porting Practice
For making changes to a port, I find ’svn diff’ to be the easiest way by far. I tend to do this: 1. svn up my work-in-progress ports tree 2. Make the changes and run tests (portlint, poudriere testport etc) 3. cd /ports; svn diff thecategory/theport > /portpatches/thecategory_theport_version.diff (change the paths to the dirs of your choice) 4. Upload the .diff file to Bugzilla Since I use svn in step 1, svn takes care of tracking the changes so I don’t need to keep .orig files and run diff by hand. The diffing that Jonathan mentioned is more applicable if you have to make changes to the upstream code itself in order for it to work on FreeBSD. I personally do that in the port’s ‘work’ dir and create the patches with ‘make makepatch’, and there I need to create .orig files (cp file.c file.c.orig before making changes). Could you please go into more detail about what you mean in step one and three, I am getting really close to figuring out how this works. In step three I don't understand "cd /ports" or "portpatches/thecategory_theport_version.diff" From: owner-freebsd-po...@freebsd.org [owner-freebsd-po...@freebsd.org] on behalf of Vidar Karlsen [vi...@karlsen.tech] Sent: Sunday, July 5, 2020 2:18 AM To: Brandon helsley Cc: freebsd-ports Subject: Re: Porting Practice > On 5 Jul 2020, at 02:46, Brandon helsley wrote: […] > The documentation for (diff -u) says "To create a suitable diff for a single > patch, copy the file that needs patching to something.orig, save the changes > to something and then create the patch:" > % diff -u something.orig something > something.diff > > Im not sure really the meaning of this documentation. What file needs > patching, which file to copy, where to save changes to exactly, and how and > why the svn method is different. Which method should I choose? I know it says > that unified diff and svn are preffered but since I am new maybe the (diff > -u) command would be easier to begin with? Please help and include anything > that's relevant even if i didn't mention it. I'm really excited to get > started and will absorb like a sponge any know how that's offered!!! For making changes to a port, I find ’svn diff’ to be the easiest way by far. I tend to do this: 1. svn up my work-in-progress ports tree 2. Make the changes and run tests (portlint, poudriere testport etc) 3. cd /ports; svn diff thecategory/theport > /portpatches/thecategory_theport_version.diff (change the paths to the dirs of your choice) 4. Upload the .diff file to Bugzilla Since I use svn in step 1, svn takes care of tracking the changes so I don’t need to keep .orig files and run diff by hand. The diffing that Jonathan mentioned is more applicable if you have to make changes to the upstream code itself in order for it to work on FreeBSD. I personally do that in the port’s ‘work’ dir and create the patches with ‘make makepatch’, and there I need to create .orig files (cp file.c file.c.orig before making changes). Hope this helps, Vidar Karlsen ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Porting Practice
> On 5 Jul 2020, at 16:42, Brandon helsley wrote: > >> For making changes to a port, I find ’svn diff’ to be the easiest way by >> far. I tend to do this: >> 1. svn up my work-in-progress ports tree >> 2. Make the changes and run tests (portlint, poudriere testport etc) >> 3. cd /ports; svn diff thecategory/theport > >> /portpatches/thecategory_theport_version.diff (change the paths to the dirs >> of your choice) >> 4. Upload the .diff file to Bugzilla >> >> Since I use svn in step 1, svn takes care of tracking the changes so I don’t >> need to keep .orig files and run diff by hand. >> >> The diffing that Jonathan mentioned is more applicable if you have to make >> changes to the upstream code itself in order for it to work on FreeBSD. I >> personally do that in the port’s ‘work’ dir and create the patches with >> ‘make makepatch’, and there I need to create .orig files (cp file.c >> file.c.orig before making changes). > > > Could you please go into more detail about what you mean in step one and > three, I am getting really close to figuring out how this works. In step > three I don't understand "cd /ports" or > "portpatches/thecategory_theport_version.diff" Absolutely! In step 1 I use svn to download the latest revision of the ports tree into a location I use for this purpose. In many cases for me this has been /ports because I like to keep /usr/ports “clean”/uncluttered by my own fiddling. I’m not sure if you have been doing it this way. In case not, it’s as simple as doing: # mkdir /ports # svn co https://svn.freebsd.org/ports/head /ports To update this copy of the tree later on (next time), run ’svn up’ in the same dir. For a real-ish example for step 3, let’s assume I’m upgrading sysutils/toybox. When it’s ready to be submitted, I would do this: # cd /ports (or whichever dir you choose to checkout the ports tree) # svn diff sysutils/toybox > /home/vidar/portdiffs/sysutils_toybox-0.8.4.diff And then create a PR and upload the diff file. You don’t have to specify the category/port for 'svn diff', but it makes it go faster as it won’t have to scan for changes in any other places than what you specify. Hope this cleared it up, Vidar Karlsen ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Porting Practice
# svn diff sysutils/toybox > /home/vidar/portdiffs/sysutils_toybox-0.8.4.diff Yes the whole message cleared it up. But right here now I see /home/vidar/portdiffs/sysutils_toybox-0.8.4.diff is where you keep the diff before submiting it. > > On Jul 5, 2020 at 9:09 AM, Vidar Karlsenwrote: > > > > On 5 Jul 2020, at 16:42, Brandon helsley > wrote: > >> For making changes to a port, I find ’svn diff’ to be the > easiest way by far. I tend to do this: >> 1. svn up my work-in-progress > ports tree >> 2. Make the changes and run tests (portlint, poudriere > testport etc) >> 3. cd /ports; svn diff thecategory/theport > > /portpatches/thecategory_theport_version.diff (change the paths to the dirs > of your choice) >> 4. Upload the .diff file to Bugzilla >> >> Since I > use svn in step 1, svn takes care of tracking the changes so I don’t need to > keep .orig files and run diff by hand. >> >> The diffing that Jonathan > mentioned is more applicable if you have to make changes to the upstream code > itself in order for it to work on FreeBSD. I personally do that in the port’s > ‘work’ dir and create the patches with ‘make makepatch’, and there I need to > create .orig files (cp file.c file.c.orig before making changes). > > > > Could you please go into more detail about what you mean in step one and > three, I am getting really close to figuring out how this works. In step > three I don't understand "cd /ports" or > "portpatches/thecategory_theport_version.diff" Absolutely! In step 1 I use > svn to download the latest revision of the ports tree into a location I use > for this purpose. In many cases for me this has been /ports because I like to > keep /usr/ports “clean”/uncluttered by my own fiddling. I’m not sure if you > have been doing it this way. In case not, it’s as simple as doing: # mkdir > /ports # svn co https://svn.freebsd.org/ports/head /ports To update this > copy of the tree later on (next time), run ’svn up’ in the same dir. For a > real-ish example for step 3, let’s assume I’m upgrading sysutils/toybox. When > it’s ready to be submitted, I would do this: # cd /ports (or whichever dir > you choose to checkout the ports tree) # svn diff sysutils/toybox > > /home/vidar/portdiffs/sysutils_toybox-0.8.4.diff And then create a PR and > upload the diff file. You don’t have to specify the category/port for 'svn > diff', but it makes it go faster as it won’t have to scan for changes in any > other places than what you specify. Hope this cleared it up, Vidar Karlsen > ___ freebsd-ports@freebsd.org > mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To > unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: latest Makefile breaks compilation of security/clamav if base is lacking sendmail
Hello Michael,
Thank you for bug report and patch. I confirmed your patch fixes the
problem with 12.1-RELEASE.
From: Michael Grimm
Subject: latest Makefile breaks compilation of security/clamav if base is
lacking sendmail
Date: Sun, 5 Jul 2020 15:37:13 +0200
> I managed to get compilation working with the attached, surely crude and
> dirty hack (due to my lack of knowledge regarding ports Makefiles), by adding
> 'MILTER_LDFLAGS= -L${LOCALBASE}/lib' and 'MILTER_CFLAGS=
> -I${LOCALBASE}/include' in order to help finding relevant files from port
> mail/libmilter.
>
> What worries my somehow, although clamav is working as usual, is the
> following part in poudrier's log:
>
> checking for mi_stop in -lmilter… yes
> checking libmilter/mfapi.h usability… yes
> checking libmilter/mfapi.h presence… no
> configure: WARNING: libmilter/mfapi.h: accepted by the compiler,
> rejected by the preprocessor!
> configure: WARNING: libmilter/mfapi.h: proceeding with the compiler's
> result
> checking for libmilter/mfapi.h... yes
>
>
> Here my question: Is this the right way to fix this issue?
I'm not sure why configure script produces such warning messages. But
mail/libmilter surely installs ${PREFIX}/lib/libmilter/mfapi.h and
configure script correctly detects it anyway. Therefore I don't think
this warning message is of much concern.
And I submitted a bit modified patch as following bug report.
security/clamav: Fix build after r541115 when base system is build
with 'WITHOUT_SENDMAIL=yes'
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247792
Best Regards.
---
Yasuhiro KIMURA
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Anyone building Seamonkey locally?
Hello.
This is from my notes on the build of my Wed May 27 13:16:29 2020 JST
installation.
svnlite update -r 502567 www/seamonkey
svnlite update -r 505639 Mk/bsd.gecko.mk
svnlite update -r 505746 MOVED
svnlite update -r 491972 www/firefox/Makefile.options
svnlite update -r 509662 www/firefox/files/patch-bug1575876
svnlite update -r 528312 www/firefox/files/patch-bug1594027
Set llvm=60 (or 70) in DEFAULT_VERSIONS.
sed -e '/^CATEGORIES/s,ipv6,,' www/seamonkey/Makefile
Edit .if ${MOZILLA_VER:R:R} >= 56 in Mk/bsd.gecko.mk to always be true.
Edit the difference (e.g. +++ xxx -> +++ mozilla/xxx) in PATCH_WRKSRC in
www/firefox/files/patch-* and copy it to www/seamonkey/files.
Perhaps that makes it possible.
And I think my unfamiliar English text will return to understandable
Japanese in the DeepL translation :)
Regards.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
