Re: Is there a way to subscribe to the commit messages for only ports you maintain?
On Mon, May 17, 2021 at 03:44:15PM -0700, Chris wrote: > I'd like to subscribe to the commit messages > ( dev-commits-ports-all ) > but only receive messages that affect me -- the > ports I currently maintain. Is it possible? Or > am I just dreaming? ;-) > > Thanks in advance for any insight into this. The easiest way to do this is to register on freshports[1], there is an "automatic" watchlist for ports you maintain, I don't remember how it works exactly. 1: https://www.freshports.org/ -- Mathieu Arnold signature.asc Description: PGP signature
Re: Preferred way of repocopy in terms of git
On Mon, May 10, 2021 at 11:21:43AM +0200, Tijl Coosemans wrote: > On Mon, 10 May 2021 09:30:56 +0200 Mathieu Arnold > wrote: > > On Fri, May 07, 2021 at 11:32:48PM +0600, Muhammad Moinur Rahman wrote: > >> What is the preferred way of doing ports repocopy in git? In the hard > >> way I can see moving it into two locations and merging them. But is > >> there any easier way of doing it? > > > > Well, here is what I did when I added lang/perl5.34: > > > > cp -R lang/perl5-devel lang/perl5.34 > > # change stuff > > git add lang/perl5.34 > > git commit > > > > I don't really see any other way to do this, Git has absolutely no clue > > about copies or moves. > > It might still be useful to do the copy and changes as two separate > commits. Even if git doesn't do anything with that, our next vcs might > and reconstructing copy history is faster and less error prone with > unmodified copies. Well, the next VCS will probably be in more than ten years, and we have no idea what it would be. When that time comes, and unless we migrate to it from subversion up to the point where we switched to git, and migrate to it from git from there, all the previous copies/moves information is already lost. So, I don't think there is a point in making it harder on people. Making a note in the commit message, like, "I copied the files from xxx/yyy" is enough, maybe adding the commit hash if it is a resurrection. But Having two commits to "record" something that git cannot possibly know about is just not interesting, all it will do is add useless commits and blobs to the repository. -- Mathieu Arnold signature.asc Description: PGP signature
Re: Preferred way of repocopy in terms of git
On Fri, May 07, 2021 at 11:32:48PM +0600, Muhammad Moinur Rahman wrote: > Hi, > > What is the preferred way of doing ports repocopy in git? In the hard way I > can see moving it into two locations and merging them. But is there any > easier way of doing it? Well, here is what I did when I added lang/perl5.34: cp -R lang/perl5-devel lang/perl5.34 # change stuff git add lang/perl5.34 git commit I don't really see any other way to do this, Git has absolutely no clue about copies or moves. -- Mathieu Arnold signature.asc Description: PGP signature
Re: [SOLVED?] Recovery of deleted ports fails due to pre-commit checks
On Tue, May 04, 2021 at 12:12:50PM +0200, Stefan Esser wrote: > Am 04.05.21 um 11:46 schrieb Mathieu Arnold: > > On Mon, May 03, 2021 at 09:54:36PM +0200, Stefan Esser wrote: > >> Am 03.05.21 um 09:01 schrieb Mathieu Arnold: > >>> On Sat, May 01, 2021 at 09:01:02PM +0200, Stefan Esser wrote: > >>>> The recovery of deleted ports in their previous form is rejected > >>>> by the pre-commit checks on the repository server: > >>>> > >>>> remote: > >>>> remote: > >>>> remote: Do not commit ports without TIMESTAMP in their distinfo files. > >>>> remote: Rerun make makesum to add it. > >>>> remote: > >>>> remote: > >>>> > >>>> I have tried to revert the deletion with unchanged files and then > >>>> updated the ports' Makefiles and distinfo files in a later commit. > >>>> > >>>> Pushing those commits all together fails with the message above, > >>>> and in order to not confuse GIT, deleted files should be committed > >>>> first, before applying any changes. > >>> > >>> This is not needed at all, Git cannot get confused by something it has > >>> no knowledge of. Once a file is deleted, or moved, the history tracking > >>> stops. > >> > >> I wanted to re-connect the resurrected files to the history of the port. > >> And that works best, if unmodified files are committed first, changes > >> applied and committed thereafter. > >> > >> Did you try "git log multimedia/transcode"? > >> > >> The history is there, back to 2002. > > > > Yeah, but this has nothing to do with you commiting unmodified files. > > Git does not track file renames or moves (or resurrection), it blindly > > looks at what you told it and goes as far as it can find things. > > Yes, sure, but the general advice when moving around files in GIT > repositories is: First move and commit unchanged, then modify in > place and commit again. And I was under the impression that the > same advice applies to files that have been deleted and are brought > back - GIT can identify and reconnect them in a way that preserves > history only by guessing, and I wanted to make it as easy as possible > for GIT, since I have watched GIT to get trivial operations of that > kind wrong in grotesque ways ... > > https://github.blog/2020-12-17-commits-are-snapshots-not-diffs/#since-commits-arent-diffs-how-does-git-track-renames Note that there are two caveats. Git will only look for files to compare to in the parent of the commit where the files are added, so if it is a resurrection, Git will never find out where the file came from. Git will only look around for a few files, like a few thousands, see diff.renameLimit in git-config(1), as we have something like 140k files in the tree, there is no chance for Git to actually find the original file you moved the new file from. So, let me say it once again, if you want to record where a file was moved/resurrected from, describe it in the commit message. Don't try to be clever with special commits, Git won't care and won't find where the file came from. -- Mathieu Arnold signature.asc Description: PGP signature
Re: [SOLVED?] Recovery of deleted ports fails due to pre-commit checks
On Mon, May 03, 2021 at 09:54:36PM +0200, Stefan Esser wrote: > Am 03.05.21 um 09:01 schrieb Mathieu Arnold: > > On Sat, May 01, 2021 at 09:01:02PM +0200, Stefan Esser wrote: > >> The recovery of deleted ports in their previous form is rejected > >> by the pre-commit checks on the repository server: > >> > >> remote: > >> remote: > >> remote: Do not commit ports without TIMESTAMP in their distinfo files. > >> remote: Rerun make makesum to add it. > >> remote: > >> remote: > >> > >> I have tried to revert the deletion with unchanged files and then > >> updated the ports' Makefiles and distinfo files in a later commit. > >> > >> Pushing those commits all together fails with the message above, > >> and in order to not confuse GIT, deleted files should be committed > >> first, before applying any changes. > > > > This is not needed at all, Git cannot get confused by something it has > > no knowledge of. Once a file is deleted, or moved, the history tracking > > stops. > > I wanted to re-connect the resurrected files to the history of the port. > And that works best, if unmodified files are committed first, changes > applied and committed thereafter. > > Did you try "git log multimedia/transcode"? > > The history is there, back to 2002. Yeah, but this has nothing to do with you commiting unmodified files. Git does not track file renames or moves (or resurrection), it blindly looks at what you told it and goes as far as it can find things. -- Mathieu Arnold signature.asc Description: PGP signature
Re: Warning: (misc/mc-nox11): Error: Duplicated origin for mc-nox11-4.8.26: misc/mc-nox11 AND misc/mc
On Mon, May 03, 2021 at 01:36:18PM +0100, tech-lists wrote: > Hi, not sure where this goes. Seems to be a ports tree error, so posting > here. > > full error from poudriere: > > [00:00:24] Warning: (misc/mc-nox11): Error: Duplicated origin for > mc-nox11-4.8.26: misc/mc-nox11 AND misc/mc. Rerun with -v to see which > ports are depending on these. > [00:00:41] Error: Fatal errors encountered gathering initial ports > metadata > [00:00:41] Cleaning up > [00:00:41] Unmounting file systems > > This is from a fresh tree as of 3rd March @1230 UTC and the poudriere > jail is 12.2-p6 The problem was in misc/mc, fixed in commit 614b5da0cb87. -- Mathieu Arnold signature.asc Description: PGP signature
Re: [SOLVED?] Recovery of deleted ports fails due to pre-commit checks
On Sat, May 01, 2021 at 09:01:02PM +0200, Stefan Esser wrote: > The recovery of deleted ports in their previous form is rejected > by the pre-commit checks on the repository server: > > remote: > remote: > remote: Do not commit ports without TIMESTAMP in their distinfo files. > remote: Rerun make makesum to add it. > remote: > remote: > > I have tried to revert the deletion with unchanged files and then > updated the ports' Makefiles and distinfo files in a later commit. > > Pushing those commits all together fails with the message above, > and in order to not confuse GIT, deleted files should be committed > first, before applying any changes. This is not needed at all, Git cannot get confused by something it has no knowledge of. Once a file is deleted, or moved, the history tracking stops. -- Mathieu Arnold signature.asc Description: PGP signature
Re: How to make 'named' rc script invokded earlier at boot time
On Fri, Apr 30, 2021 at 04:30:54PM +0900, Yasuhiro Kimura wrote: > Then is there any way to make 'named' rc script invoked earlier at > boot time on 13.0-RELEASE? There is an option in the port to have named start later, but up to now, it was starting early enough. The only way I can see is modify the named rc script and add the services that needs named to be started on the BEFORE line at the beginning of the script. Mind you, it really needs to start after syslog (unless you log directly to files and do not use syslog.) -- Mathieu Arnold signature.asc Description: PGP signature
Re: @sample surprises (dns/knot-resolver)
On Mon, Apr 12, 2021 at 11:34:11AM +0200, Adriaan de Groot wrote: > As prep-work for CMake updates I locally "exp-run" all the ports that use > CMake. I use poudriere for this, with the `-t` flag to test each port. > > dns/knot-resolver fails to package like that, with this error: > > === > ===> Building package for knot-resolver-5.3.0 > @sample with 1 single argument expect ".sample" extension > pkg-static: Fail to apply keyword 'sample' > *** Error code 1 > > > The same failure occurs on the build cluster. I checked the porter's handbook > and it describes 1- and 2-argument forms of @sample, but neither seemed > applicable here without digging into the port itself to rename the installed > configuration file. What's the right approach here? > > (CC'ed maintainer and last committer; I'm going to locally stop building this > one in preparation of a CMake update) The best is probably to fix the plist and use two arguments. -- Mathieu Arnold signature.asc Description: PGP signature
Re: No update for a day on ports?
On Thu, Apr 01, 2021 at 09:54:16AM +0200, Milan Obuch wrote: > On Thu, 1 Apr 2021 09:47:04 +0200, Mathieu Arnold > wrote: > > > On Thu, Apr 01, 2021 at 09:16:15AM +0200, Milan Obuch wrote: > > > Also, what about svn mirror, as is done for src repository, for 11 > > > and 12 branches at least? I did not tried it recently, but it used > > > to work. For some boxes, adding git to the mix would be big PITA. > > > > There will be no Git to Subversion conversion for ports, like for > > docs. The only reason there is for the base system on 11 and 12 is > > because Subversion was the source control software used when they > > were released. > > > > This is unpleasant move for me. This means git or equivalent (and > dependencies) must be installed on any box where tracking ports tree is > planned/needed... and no tool like svnlite could be expected in base > system for some time. > > So I need some work on my local infrastructure to adjust to this move. > C'est la vie... If you actually need a repository, and not just the latest files, all you need is run pkg install git on the machines you are actually using a ports tree on, if you have more than one machine, you should probably be using binary packages anyway, either the ones provided by FreeBSD, or ones built yourself using ports-mgmt/poudriere. If you only need the latest files, you can probably use something like net/gitup. -- Mathieu Arnold signature.asc Description: PGP signature
Re: No update for a day on ports?
On Thu, Apr 01, 2021 at 09:16:15AM +0200, Milan Obuch wrote: > Also, what about svn mirror, as is done for src repository, for 11 and > 12 branches at least? I did not tried it recently, but it used to work. > For some boxes, adding git to the mix would be big PITA. There will be no Git to Subversion conversion for ports, like for docs. The only reason there is for the base system on 11 and 12 is because Subversion was the source control software used when they were released. -- Mathieu Arnold signature.asc Description: PGP signature
Re: bogus warning from pkg
On Tue, Feb 16, 2021 at 07:46:05AM +0900, Tatsuki Makino wrote: > There is a difference between the pkg in /usr/sbin and the pkg in > /usr/local/sbin. > The manual for /usr/sbin/pkg is man 7 pkg. pkg in /usr/sbin does two things: - if /usr/local/sbin/pkg exists, exec it. - else bootstrap pkg. -- Mathieu Arnold signature.asc Description: PGP signature
Re: MASTER_SITES=GH? like SF
On Mon, Jan 18, 2021 at 07:32:46AM +, Nuno Teixeira wrote:
> Hello,
>
> I will use graphics/glfw port as an example:
>
> MASTER_SITES= SF
>
> The project moved to github so I will prefer use GH releases instead of SF:
>
> MASTER_SITES=https://github.com/glfw/glfw/releases/download/${PORTVERSION}/
> works ok.
>
> MASTER_SITES= GH:
Remove the `:`. Also, GH should never be used by itself, it is only
there as an artefact of the way USE_GITHUB works. But if there is a
released tarball as you indicate up there, you should use it.
> => glfw-3.3.2.zip doesn't seem to exist in /work/DISTFILES/.
> ===> /!\ Error /!\
> The :DEFAULT group used for glfw-3.3.2.zip is missing
> from MASTER_SITES. Check for typos, or errors.
> *** Error code 1
>
> Thanks,
>
> Nuno Teixeira
> ___
> 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"
>
--
Mathieu Arnold
signature.asc
Description: PGP signature
Re: GitHub: size of remote file is not known
On Mon, Jan 04, 2021 at 08:04:32PM -0800, Chris wrote: > I don't use Github. So I'm not familiar with their service(s). > But ports using source fetched from them always return: > size of remote file is not known > Is it that their servers simply refuse to return size/content-length > or is this something else? > I can see where this might turn into a problem for those attempting > to build ports on a system with limited resources -- especially > during a meta-port build, and even more so for newcomers. > > Is anyone familiar with why this is so? I'd like to change this. USE_GITHUB is using a GitHub (and a git) feature to have git-archive(1) files generated and served on the fly. So, the server has no idea how small or large the file will be, as it does not exist yet, so it cannot report the size to the http client. Once one is generated it gets cached for a while, so if the file has been requested not too far back, the server will have it cached and will know the size, but it only happens for files that are requested frequently. -- Mathieu Arnold signature.asc Description: PGP signature
Re: How to fix/patch hardcoded values
On Sun, Dec 27, 2020 at 09:58:13PM +, Nuno Teixeira wrote:
> Hello I've just submited a new port net/gitup
> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252220> and I used a
> simple workaround to help program find its config in /usr/local/etc instead
> of (hardcoded) ./
>
> --- gitup.c.orig 2020-12-27 21:16:22 UTC
> +++ gitup.c
> @@ -2030,7 +2030,7 @@ main(int argc, char **argv)
> ...
> - const char *configuration_file = "./gitup.conf";
> + const char *configuration_file = "/usr/local/etc/gitup.conf";
>
> Now I'm thinking that this might not be the best fix in case PREFIX is a
> different one.
>
> Could I have an opinion on this?
You need to change the patch to use %%PREFIX%% or %%LOCALBASE%%
depending on whether this is a reference to a path/file installed by the
software or by one of its dependency. Then, in a post-patch target, you
need to use REINPLACE_CMD to replace those to by they variables
equivalent, something like:
post-patch:
${REINPLACE_CMD} -e 's,%%PREFIX%%,${PREFIX}' ${WRKSRC}/githup.c
--
Mathieu Arnold
signature.asc
Description: PGP signature
Re: Poudriere/PREFIX breakage?
On Mon, Oct 05, 2020 at 11:30:36PM -0400, Mason Loring Bliss wrote: > Hi, all. I just spun up a Poudriere build server, building 2020Q4 for 12.1 > amd64. I set PREFIX=/opt in /usr/local/etc/poudriere.d/make.conf and a > number of things broke, but a number didn't. When I killed the build, as > clearly there's something wrong, I had 29 successful builds and 19 > failures, and a number of skips given that gettext-tools was one of the > failures. What problem are you trying to fix by setting PREFIX=/opt ? If it is to test what breaks with a non standard prefix, you need to use poudriere testport with the `-P` argument. If the goal is to have what is usually in /usr/local in /opt, then you do not need to set PREFIX, but you must set LOCALBASE instead. -- Mathieu Arnold signature.asc Description: PGP signature
Re: TEST_DEPENDS on itself?
On Mon, Sep 14, 2020 at 10:07:06PM +0200, Christian Weisgerber wrote: > Mathieu Arnold: > > > > Is a port allowed to depend on the installed version of itself for > > > running "make test"? > > > > Nope. Tests are run after the port is installed, so, it should already > > That is not true. "test" depends on "stage". It does not install > the port. Oh, you are right, I don't know why my brain made the shortcut staged == installed. > > be ok. What problem are you trying to solve. > > I'm working on a port that can't run its regression tests out of > the build or stage areas. The command to be tested will call > submodules with compiled in absolute paths (/usr/local/libexec/...). > So this port bla/foo would require to be already installed for > testing: > > TEST_DEPENDS= foo:bla/foo > > The foo command will call /usr/local/libexec/foo/foo-helper. If > the latter isn't there, foo won't run. Well, you cannot have recursive dependencies, so a port cannot depend on itself. What about if you chroot in STAGEDIR to run the tests? -- Mathieu Arnold signature.asc Description: PGP signature
Re: TEST_DEPENDS on itself?
On Mon, Sep 14, 2020 at 02:26:17PM -, Christian Weisgerber wrote: > Is a port allowed to depend on the installed version of itself for > running "make test"? Nope. Tests are run after the port is installed, so, it should already be ok. What problem are you trying to solve. -- Mathieu Arnold signature.asc Description: PGP signature
Re: [HEADS UP] Planned deprecation of portsnap
On Thu, Aug 06, 2020 at 02:11:10PM +0200, Michael Gmelin wrote: > > > > On 6. Aug 2020, at 13:58, Mathieu Arnold wrote: > > > > On Thu, Aug 06, 2020 at 12:17:37AM +0200, Michael Gmelin wrote: > >>> We welcome any constructive feedback. All input would be heard, and if > >>> the plans need to be amended, we will come back to you with the amended > >>> plan in a couple of weeks. This process will take some time and hopefully > >>> won't be too disruptive to anyone's usual workflow. > >> > >> What will be the process to bootstrap git? > > > > pkg install git comes to mind. > > > > I obviously meant bootstrapping without relying on binary packages (for > multiple reasons) >_< > > E.g., pulling a tarball (from a github mirror or some other place) using > “fetch” to populate an intermediate ports tree to build git/other > dependencies. Shouldn’t be hard to do and easy to document. Well, you can download the head of the main branch, https://cgit-beta.freebsd.org/ports/snapshot/main.tar.gz and extract it wherever you like. -- Mathieu Arnold signature.asc Description: PGP signature
Re: [HEADS UP] Planned deprecation of portsnap
On Thu, Aug 06, 2020 at 12:17:37AM +0200, Michael Gmelin wrote: > > We welcome any constructive feedback. All input would be heard, and if the > > plans need to be amended, we will come back to you with the amended plan in > > a couple of weeks. This process will take some time and hopefully won't be > > too disruptive to anyone's usual workflow. > > What will be the process to bootstrap git? pkg install git comes to mind. -- Mathieu Arnold signature.asc Description: PGP signature
Re: [HEADS UP] Planned deprecation of portsnap
On Thu, Aug 06, 2020 at 01:57:41PM +0700, Eugene Grosbein wrote: > 06.08.2020 13:23, Doug Hardie wrote: > > >> On 5 August 2020, at 21:30, Eugene Grosbein wrote: > >> > >> 06.08.2020 6:02, Tatsuki Makino wrote > >> : > >>> Is there any command other than "rm -rf /usr/ports ; portsnap extract" > >>> that can be easily repaired? > >> > >> svnlite revert -R /usr/ports > > > > > > master# svnlite revert -R /usr/ports > > svn: E155007: '/usr/ports' is not a working copy > > master# > > master# rm -rf /usr/ports/* > > master# svnlite revert -R /usr/ports > > svn: E155007: '/usr/ports' is not a working copy > > If portsnap's deprecated, one uses "svnlite checkout" to replace portsnap's > data > with data of Subversion, then "svnlite revert" would work. Depending on the damage, you may also want to `svnlite cleanup --remove-unversioned` and maybe a plain rm -rf followed by a svnlite checkout. -- Mathieu Arnold signature.asc Description: PGP signature
Re: [HEADS UP] Planned deprecation of portsnap
On Wed, Aug 05, 2020 at 12:40:26PM +0100, Bob Eager wrote: > On Wed, 5 Aug 2020 13:32:10 +0200 > Mathieu Arnold wrote: > > > On Wed, Aug 05, 2020 at 12:59:18PM +0200, Hans Petter Selasky wrote: > > > On 2020-08-04 20:43, Steve Wills wrote: > > > > > > > > We are planning to deprecate use of portsnap in ports. > > > > > > > > The reasons are as follows (in no particular order): > > > > > > > > * Portsnap doesn't support quarterly branches, even years after > > > > quarterly branches were created and changed to the default for > > > > non-HEAD packages. > > > > > > Hi, > > > > > > Maybe some silly questions already answered: > > > > > > 1) portsnap is populating /usr/ports . Is this location still > > > hardcoded for ports tree installations, or can it be installed > > > anywhere? > > > > > > 3) Should /usr/ports be removed from any mtree files? > > > > The default location for the ports tree is taken from the PORTSDIR > > environment variable, and it defaults to /usr/ports. > > > > Is that true for installation __of the tree__, as asked? If so, how is > it set? Well, portsnap has a default value hardcoded, otherwise, the value is taken from /usr/share/mk, like most default values. -- Mathieu Arnold signature.asc Description: PGP signature
Re: [HEADS UP] Planned deprecation of portsnap
On Wed, Aug 05, 2020 at 12:59:18PM +0200, Hans Petter Selasky wrote: > On 2020-08-04 20:43, Steve Wills wrote: > > > > We are planning to deprecate use of portsnap in ports. > > > > The reasons are as follows (in no particular order): > > > > * Portsnap doesn't support quarterly branches, even years after > > quarterly branches were created and changed to the default for non-HEAD > > packages. > > Hi, > > Maybe some silly questions already answered: > > 1) portsnap is populating /usr/ports . Is this location still hardcoded for > ports tree installations, or can it be installed anywhere? > > 3) Should /usr/ports be removed from any mtree files? The default location for the ports tree is taken from the PORTSDIR environment variable, and it defaults to /usr/ports. -- Mathieu Arnold signature.asc Description: PGP signature
Re: [HEADS UP] Planned deprecation of portsnap
On Tue, Aug 04, 2020 at 09:51:23PM -0700, Chris wrote: > This is very bad news for us. I can make so many arguments against > dropping subversion. It's really not (needn't be) a matter of either/or. In this sentence, who is "us"? Also, can you elaborate? -- Mathieu Arnold signature.asc Description: PGP signature
Re: Can not add port with name "py3c" (which is name of project!)
On Mon, Jun 01, 2020 at 01:13:15AM +0200, Christoph Moench-Tegeder wrote: > ## Lev Serebryakov (l...@freebsd.org): > > > svn: E165001: Commit failed (details follow): > > svn: E165001: Commit blocked by pre-commit hook (exit code 1) with output: > > Adding new py3- ports is forbidden. > > The Python ports have flavors and do not need the py3- ports. > > https://svnweb.freebsd.org/ports/svnadmin/hooks/scripts/detect-filename.sh?revision=455211=markup#l20 > > There it is. That grep seems overly broad, it needs a -. > Ping mat and/or portmgr. It is overly broad on purpose, so that someone does not add a py38-foo either. There is a shortcut though, ask for portmgr, and get approval for the commit, it is 3 lines above in that script ;-) -- Mathieu Arnold signature.asc Description: PGP signature
Re: USE_GITHUB=nodefault w/o github
On Wed, May 27, 2020 at 03:28:52AM +0300, Sergei Vyhenski wrote: > Hi, > > Some ports (e.g.: www/nginx) are declaring > USE_GITHUB=nodefault, > while they seem to fetch none of its distfiles from github. > > What is the idea behind this combination? From https://www.freebsd.org/doc/en/books/porters-handbook/makefile-distfiles.html#makefile-master_sites-github-multiple : When fetching multiple files from GitHub, sometimes the default distribution file is not fetched from GitHub. To disable fetching the default distribution, set: USE_GITHUB= nodefault If you set USE_GITHUB=yes it means the software you are porting has no distribution file and only a github repository from which you can get a git-archive extract. If the software actually does release distribution files, but for some reason, you need to fetch something from github, you use USE_GITHUB=nodefault. -- Mathieu Arnold signature.asc Description: PGP signature
Re: Port OPTIONS advice
On Wed, May 20, 2020 at 07:25:00PM +0200, SirDice wrote:
> What's a good way to deal with this sort of architecture dependent option?
If the feature is architecture dependant but also needs to be disabled
on architectures where it does not work, a naive way that I can see to
do it is probably to do something like this:
OPTIONS_DEFINE= JIT
OPTIONS_EXCLUDE_aarch64= JIT
OPTIONS_EXCLUDE_armv6= JIT
But you have to do it for all architectures, so it may not be the best
way, a way that would be a bit more convoluted, but still readable would
be:
OPTIONS_DEFINE= JIT
OPTIONS_EXCLUDE= ${ARCH:Ni386:Namd64:C/.+/JIT/}
What it does is take ARCH, remove i386 and amd64 from it, and there is
still something, replace it with JIT.
--
Mathieu Arnold
signature.asc
Description: PGP signature
Re: How to change PATH setting of poudriere
Hi, On Thu, May 14, 2020 at 05:04:14PM +0900, Yasuhiro KIMURA wrote: > Hello. > > I would like to test non-default LOCALBASE build with poudriere and > add 'LOCALBASE=/opt' in /usr/local/etc/poudriere.d/make.conf. But > build of some ports fails because /opt/bin is not included in value of > PATH environment variable. How do I change PATH setting of poudriere? I am not sure it is possible to set /opt precisely. If you simply want to test with a non standard LOCALBASE and PREFIX, you can use `poudriere testport -P` which will build with a non default PREFIX. -- Mathieu Arnold signature.asc Description: PGP signature
Re: Poudriere - Compile ALL Ports
On Thu, May 07, 2020 at 08:39:41PM +0200, Leander Schaefer wrote: > Hello Chris, > > Hello List, > > I have checked out ports-mgmt/synth unfortunately it would be a massive > downgrade compared to poudriere. Does anyone have the right clue about how > the FreeBSD package managment team provides a complete repository without > having these conflicts? There must be a way to do this with poudriere since > I am most certainly sure they also use poudriere. I do not understand, which port are you trying to build that fails because of those conflicts? -- Mathieu Arnold signature.asc Description: PGP signature
Re: Building a port with debug symbols using poudriere
On Wed, May 06, 2020 at 07:52:45PM -0500, Greg Rivers wrote:
> On Wednesday, 6 May 2020 17:49:06 CDT Matthias Andree wrote:
> > Am 06.05.20 um 18:05 schrieb Greg Rivers:
> > > I need to build bind916 with debug symbols. According to the Makefile,
> > > defining "WITH_DEBUG" will accomplish that. Where and how would I set
> > > that inside a basic poudriere configuration?
> > >
> > Either in the port, or you can set WITH_DEBUG_PORTS=dns/bind916 here:
> >
> > /usr/local/etc/poudriere.d/make.conf - see CUSOTMISATION and then
> > further down "Create optional make.conf" in man poudriere
> >
> Thank you Matthias. I had read your manual page reference prior to posting,
> but it didn't specify the variable name format or how to set its value. Is it
> a general rule that one can set any variable for any port by specifying:
>
> ANY_VARIABLE_PORTS=category/portname
>
> If a variable needs to have a specific value (vs simply being defined or
> undefined) is it done like this:
>
> ANY_VARIABLE_PORTS= category/portname=7
No, this is specific to WITH_DEBUG. There are very few user facing
variables in the ports tree, WITH_DEBUG being one of them, for ease of
use, and because using it will usually tremendously increase the size of
generated packages, there is a WITH_DEBUG_PORTS variable available so
that you can easily build one port with debugging symbols and nothing
else.
If you need to set some variable for a specific port you can:
1) edit the Makefile directly
2) put a Makefile.local in the port's directory with whatever you need
3) Add something like this to make.conf (The one Matthias told you
about):
.if ${.CURDIR:M*/category/portname}
SOME_VARIABLE=yes
.endif
There are probably other convoluted ways to do it, but those are the
easier ones.
--
Mathieu Arnold
signature.asc
Description: PGP signature
Re: creating a new port from github: "_GH0" suffix in the filename
On Thu, Apr 16, 2020 at 01:20:20PM +0200, Marco Beishuizen wrote: > GH_TAGNAME= g0de4b1c ^ There is an extra g here, commit hash only use hexadecimals. > The name of the file is correct, except for the added "_GH0". > How can I download the file without the "_GH0" suffix? The _GH0 suffix is fine :) -- Mathieu Arnold signature.asc Description: PGP signature
Re: BIND 9.16.2 failing on RPI3 running 12.1-STABLE
On Thu, Apr 16, 2020 at 05:57:07PM +1200, Jonathan Chen wrote: > Hi, > > I'm currently running BIND on an RPI3, and the latest update to > bind-9.16.2 currently fails to with: > > Apr 16 17:39:26 topaz named[64497]: starting BIND 9.16.2 (Stable > Release) > Apr 16 17:39:26 topaz named[64497]: running on FreeBSD arm64 > 12.1-STABLE FreeBSD 12.1-STABLE #0 r358927: Sun Mar 15 22:24:30 NZDT > 2020 jo > n...@onyx.inside.chen.org.nz:/xbuilds/rpi3/obj/usr/src/arm64.aarch64/sys/GENERIC > Apr 16 17:39:26 topaz named[64497]: built with '--disable-linux-caps' > '--localstatedir=/var' '--sysconfdir=/usr/local/etc/namedb' > '--with-dlo > pen=yes' '--with-libxml2' '--with-openssl=/usr' > '--with-readline=-L/usr/local/lib -ledit' '--with-dlz-filesystem=yes' > '--disable-dnstap' '--d > isable-fixed-rrset' '--disable-geoip' '--without-maxminddb' > '--without-gssapi' '--with-libidn2=/usr/local' '--with-json-c' > '--disable-largefi > le' '--with-lmdb=/usr/local' '--disable-native-pkcs11' > '--without-python' '--disable-querytrace' > 'STD_CDEFINES=-DDIG_SIGCHASE=1' '--enable-tc > p-fastopen' '--with-tuning=default' '--disable-symtable' > '--prefix=/usr/local' '--mandir=/usr/local/man' > '--infodir=/usr/local/share/info/' ' > --build=aarch64-portbld-freebsd12.1' > 'build_alias=aarch64-portbld-freebsd12.1' 'CC=cc' 'CFLAGS=-O2 -pipe > -DLIBICONV_PLUG -fstack-protector-st > rong -isystem /usr/local/include -fno-strict-aliasing ' 'LDFLAGS= > -L/usr/local/lib -ljson-c -fstack-protector-strong ' > 'LIBS=-L/usr/local/lib > ' 'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp' > 'PKG_CONFIG=pkgconf' > Apr 16 17:39:26 topaz named[64497]: running as: named -4 -t /var/named > -u bind -c /usr/local/etc/namedb/named.conf > Apr 16 17:39:26 topaz named[64497]: compiled by CLANG FreeBSD Clang > 9.0.1 (g...@github.com:llvm/llvm-project.git > c1a0a213378a458fbea1a5c77b315 > c7dce08fd05) > Apr 16 17:39:26 topaz named[64497]: compiled with OpenSSL version: > OpenSSL 1.1.1d-freebsd 10 Sep 2019 > Apr 16 17:39:26 topaz named[64497]: linked to OpenSSL version: OpenSSL > 1.1.1d-freebsd 10 Sep 2019 > Apr 16 17:39:26 topaz named[64497]: compiled with libxml2 version: 2.9.10 > Apr 16 17:39:26 topaz named[64497]: linked to libxml2 version: 20910 > Apr 16 17:39:26 topaz named[64497]: compiled with json-c version: 0.13.1 > Apr 16 17:39:26 topaz named[64497]: linked to json-c version: 0.13.1 > Apr 16 17:39:26 topaz named[64497]: compiled with zlib version: 1.2.11 > Apr 16 17:39:26 topaz named[64497]: linked to zlib version: 1.2.11 > Apr 16 17:39:26 topaz named[64497]: > > Apr 16 17:39:26 topaz named[64497]: BIND 9 is maintained by Internet > Systems Consortium, > Apr 16 17:39:26 topaz named[64497]: Inc. (ISC), a non-profit 501(c)(3) > public-benefit > Apr 16 17:39:26 topaz named[64497]: corporation. Support and training > for BIND 9 are > Apr 16 17:39:26 topaz named[64497]: available at https://www.isc.org/support > Apr 16 17:39:26 topaz named[64497]: > > Apr 16 17:39:26 topaz named[64497]: command channel listening on 127.0.0.1#953 > Apr 16 17:39:26 topaz named[64497]: netmgr.c:995: > REQUIRE(worker->recvbuf_inuse) failed > Apr 16 17:39:26 topaz named[64497]: exiting (due to assertion failure) > Apr 16 17:39:26 topaz kernel: pid 64497 (named), jid 0, uid 53: exited > on signal 6 > > The last version of bind916 that works is bind916-9.16.0_2.txz. 9.16.1 > also fails with an assertion error on netmgr.c. https://gitlab.isc.org/isc-projects/bind9/-/issues/1761 It seems the problem is libuv 1.36. -- Mathieu Arnold signature.asc Description: PGP signature
Re: openssl problem after 11 -> 12
On Tue, Apr 14, 2020 at 11:58:05AM +0200, Per olof Ljungmark wrote: > Hello, > > After upgrading our Nagios host, I can no longer get status from our older > HP servers with iLO3. > > Using a perl script, check_ilo2_health.pl, this stopped working due to lack > of support of older ciphers in base openssl. > > So far, I installed openssl from ports and enabled the weak ciphers, > adjusted /etc/make.conf for DEFAULT_VERSIONS+= ssl=openssl, have rebuilt > perl and perl modules, curl and a few more. > > Still, I get > > curl -v --insecure --tlsv1.1 -v https:// > * Trying :443... > * Connected to port 443 (#0) > * ALPN, offering http/1.1 > * successfully set certificate verify locations: > * CAfile: /usr/local/share/certs/ca-root-nss.crt > CApath: none > * TLSv1.3 (OUT), TLS handshake, Client hello (1): > * TLSv1.3 (IN), TLS alert, handshake failure (552): > * error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure > * Closing connection 0 > curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake > failure > > I am at loss right now on how I could teach the FBSD-12 system to use the > older ciphers, it still works fine from 11. Ok, so, let me tell you how I handled something similar a couple of months back with some ruby scripts that needed to talk to an old appliance with an old ssl but where ssl was mandatory. I installed openssl-unsafe (which is a 1.0.2-something with everything enabled) and I locally rebuilt every bits that needed that old SSL. This included installing RVM to build a local ruby, and use that ruby to build the bits those scripts needed... Now it works, and that machine has a "do not touch" sign. ^^ -- Mathieu Arnold signature.asc Description: PGP signature
Re: Should 'Reported by' reflect who/which system reported the port to be out-of-date?
On Sat, Mar 07, 2020 at 12:49:14PM -0800, Yuri wrote: > I got a feedback that such use of 'Reported by' might be incorrect. I just saw that reported by was missing from: https://www.freebsd.org/doc/en/articles/committers-guide/commit-log-message.html You fill this field with the name of the person who reported the problem without submitting a fix. (If they provide a fix, they go in submitted by.) -- Mathieu Arnold signature.asc Description: PGP signature
Re: When to use TMPPLIST instead of pkg-plist?
On Sat, Feb 29, 2020 at 11:29:18AM -0800, Chris wrote: > On Sat, 29 Feb 2020 11:02:23 +0100 Mateusz Piotrowski 0...@freebsd.org said > > > On 2/29/20 12:15 AM, Mathieu Arnold wrote: > > > On Fri, Feb 28, 2020 at 10:06:19PM +0100, Mateusz Piotrowski wrote: > > >> Do we have any (perhaps unwritten) policy for when to use TMPPLIST? And > > > when > > >> should a port maintainer stick to pkg-plist? > > > We do not. A port maintainer should stick to pkg-plist. > > > > That's what I thought. > > > > Is there a reason for it? Does it all boil down to that fact that > > pkg-plist is much more explicit and easier to debug/review? Or there is > > another reason? > TMPPLIST is an artifact of the QA process when making a port. It is used So, I stopped reading there because as this is wrong, all that comes afterwards was also ;-) TMPPLIST is the file where all of PLIST_FILES/DIR go after being processsed for %%FOO%% placeholders, it is where pkg-plist ends up, also after being processed for placeholders. It is also where stuff get added, like .info files from the INFO variable, @ldconfig calls from USE_LDCONFIG, rc file from USE_RC_SUBR, docs and examples from PORTDOCS and PORTEXAMPLES, and probably a few other things pile up in there. All in all, TMPPLIST is the temporary file where every file, directory, keyword... utimately every part of the framework, end up putting what needs to end up in the package. It is also used in the QA process, to tell the user if stuff is wrong wrt what is really installed, but it is not the other way round. -- Mathieu Arnold signature.asc Description: PGP signature
Re: When to use TMPPLIST instead of pkg-plist?
On Fri, Feb 28, 2020 at 10:06:19PM +0100, Mateusz Piotrowski wrote: > Hello ports@, > > recently I saw TMPPLIST being used for a relatively simple fonts port > instead of pkg-plist to keep track of files to be installed by a port. I am > quite surprised because I've always thought that this mechanism is reserved > for special cases such as autoplist for Python packages. > > Do we have any (perhaps unwritten) policy for when to use TMPPLIST? And when > should a port maintainer stick to pkg-plist? We do not. A port maintainer should stick to pkg-plist. -- Mathieu Arnold signature.asc Description: PGP signature
Re: About protocols in openssl
On Thu, Feb 27, 2020 at 12:45:51PM -0800, Freddie Cash wrote: > On Thu, Feb 27, 2020, 12:37 PM Willem Jan Withagen, wrote: > > > > > Interesting, but not quite what I want > > It is not for personal usage, but for ports that I have commited to the > > ports collection, and want to upgrade. > > And yes, fixing openssl works for this problem, but it is not only my > > problem. > > > > I maintain these Ceph ports, and now upstream uses a python module that > > expects SSlv3 to be available in the openssl that encounters on the system. > > And the question is how to accommodate that? > > Short of embedding my own openssl libs with the ceph-libs, thus creating > > a huge maintenance problem. > > > > I could also argue that switching of SSLv3 in a generic library is sort > > of impractical, even if it is a protocol that we want to erradicate. > > But I guess that the maintainers of openssl have decided that this is > > the smart thing to do. > > And I'm in peace with that, but now require an escape from this catch-22. > > > > --WjW > > > > There's no mechanism in the ports tree framework for port X to depend on > feature Y being enabled in port Z. > > All you can do is add a pkg-message alert to your ceph port saying the use > needs to compile the openssl port with SSLv3 enabled. > > You could create a slave port for openssl that has that option enabled, > then depend on that slave port. But that might create dependency issues > elsewhere. You can do it, but nobody will commit that kind of change. The choice of which OpenSSL version to use is a user facing change, and it is done globally. As a side note, SSLv3 is going away, anything done right now that needs it is doomed. > Sub-packages might (eventually) allow you to work around this. As probably the only one who knows the subpackages implementation, I don't see how it possibly could. -- Mathieu Arnold signature.asc Description: PGP signature
Re: llvm80-8.0.1_3 needs Python 3.6 at least, but 2.7 was specified.
On Thu, Feb 27, 2020 at 07:52:23PM +, Brooks Davis wrote: > On Thu, Feb 27, 2020 at 08:44:59AM -0800, Chris wrote: > > I'm testing modifications of ports I maintain in > > a jail. I have nothing in make.conf(5) except > > DEVELOPER=true > > But I get messages regarding python versions like: > > llvm80-8.0.1_3 needs Python 3.6 at least, but 2.7 was specified. > > But I make no demands on versions. > > What causes this, and how can I stop it. :) > > Is your set of packages fully up to date? IIRC other have had issues > when they tried to install LLVM with out of date dependencies. It was fixed on r522485. -- Mathieu Arnold signature.asc Description: PGP signature
Re: What is the actual syntax used to FLAVOR ports?
On Mon, Feb 10, 2020 at 09:02:34PM -0500, Ernie Luzar wrote: > Kevin Oberman wrote: > > On Sat, Feb 8, 2020 at 1:27 PM Chris wrote: > > > > > OK I know FLAVOR is an evolving concept. But I can not find > > > the FLAVOR documentation. Only references in the porters > > > handbook. What I think needs to be available is an entire > > > list of flavor tags for all (port) categories. > > > For example; > > > make FLAVOR=python27 returns the error use py27. > > > OK now I know how to flavor, and build python flavors. > > > But what of Perl? > > > make FLAVOR=perl2.8. Nope. How about make FLAVOR=p5-28, > > > and so it goes... > > > Does there exist a definitive list of flavors? It'd > > > also be valuable for defining defaults in make.conf(5) > > > > > > Thanks! > > > > > > --Chris > > > > > > The problem is not having a clear understanding of what a FLAVOR is and > > when it is used. > > > > FLAVORS are generally a way to deal with the problem of incompatible > > versions and Python is the poster child. Python2 and Python3 are two > > version of a VERY popular language that have significant syntax > > incompatibilities. While a program written for gcc-4.2 should work fine > > when compiled with gcc-7, it is VERY unlikely that a program written for > > Python2 will work with Python3. While the changes needed are often fairly > > straight forward, they have to be made. The result is a requirement of > > having both interpreters installed and two packages of of most Python > > libraries built from a single source. > > > > Adding FLAVORS for a port is an expensive operation and is never lightly > > approved by the ports management team as it adds a great deal of complexity > > and both human and machine overhead. Requests to FLAVOR a port are > > carefully reviewed and will only be approved with adequate justification. > > > > In the case of Perl, no attempt to flavor it has been needed. Most Perl > > packages (p5-*) will work with any of the three available ports. In most > > cases they may be installed and continue to work across versions with no > > changes. Python (py-) ports MUST be reinstalled to move from Python2 to > > Python3. Some have not had required changes to work with Python3 made and, > > initially, almost none did. Some have now been written with no support for > > Python2. All of this has to be properly handled by the package building > > system and it is not at all trivial. > > > > As of today, I believe the only FLAVORed ports are those using emacs, > > lazarus, php, and, of course, python. By "using", I mean that the port > > Makefile includes "USE_PYTHON" or similar USE_ definitions of the other > > languages. (Yes, emacs is not a language, but elisp, the core of emacs, is > > and lazarus is an IDE for Pascal.) > > > > I'm sorry of this is not entirely clear, but I hope it helps and I hope it > > is all correct. I may have worded some of it poorly. > > -- > > Kevin Oberman, Part time kid herder and retired Network Engineer > > E-mail: rkober...@gmail.com > > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > wow the above reply is not how I remember how things were envisioned when > this flavor function was first talked about. Having to get permission first > and being limited to languages was never talked about and not at all a > requirement. Having to get permissions was never envisioned, and we will stop having it as a requirement when people stop trying to forcefully do very silly things, it will probably be relaxed when we have subpackages. It is not at all limited to languages, I have no idea where that came from. You only have to grep for '^FLAVORS=' to see that. > It was envisioned as a way to per can a set of different > defaults so a package with pre canned defaults would be auto built in the > ports system that is different from the basic defaults. ON the subject of > documentation about how to set up flavors for a port is totally lacking at > this point. You know the old saying, developers are good programmers but are > terrible at documenting their work if they do it at all. So with that in > mind do your own thing following what you see for flavored languages as a > loosely followed guide. Flavors have been documented from day one. https://www.freebsd.org/doc/en/books/porters-handbook/flavors.html (I kinda know because I wrote (most of) the flavors code, and I also write (most of) the documentation.) -- Mathieu Arnold signature.asc Description: PGP signature
Re: sed failed: backup file same as original
On Fri, Jan 10, 2020 at 08:07:40PM +0100, w.schwarzenfeld wrote:
> Ok, got my wires crossed. I understand it.
Just to be sure you get it right, it tells you that these files have
REINPLACE_CMD on them that do nothing. It may be because it is only
replacing /usr/local with ${LOCALBASE} which is also /usr/local, it can
also be because it used to be useful but is no longer.
--
Mathieu Arnold
signature.asc
Description: PGP signature
Re: breakage in "make index"
On Thu, Jan 09, 2020 at 08:36:05AM -0500, Robert Huff wrote: > > [I'm posting this here because "ports@" is the listed > maintainer.] > > On a system running: > > FreeBSD 13.0-CURRENT #0 r354131: Mon Oct 28 17:27:33 EDT 2019 amd64 > > with the ports tree updated every night, for about the last week > "make index" has failed because: > > --- describe.x11-wm --- > make_index: /usr/ports/astro/google-earth: no entry for > /usr/ports/graphics/linux-c6-dri > Done. > > and therefore "pkg version" also fails. > This is beyond my skill set; would someone who knows how please > make the appropriate adjustment? I fear nobody can make the adjustment but you, the default linux switched to c7 a last summer, and the linux-c6-* ports were a eek ago. You probably have DEFAULT_VERSIONS=linux=c6 somewhere. -- Mathieu Arnold signature.asc Description: PGP signature
Re: PKGSUFFIX for poudriere Help needed
On Wed, Jan 08, 2020 at 12:37:55PM -0500, Nick Wolff wrote: > I'm trying to get zstd packages built locally with poudriere but something > is failing. I've set PKGSUFFIX=.tzst in my make.conf for the branch and it > shows up in poudriere logs > ( /usr/local/etc/poudriere.d/ixlab-master-make.conf ) > > But I'm still getting txz packages. > I've successfully used PKG_NOCOMPRESS in make.conf. and not sure what I'm > doing wrong here. PKG_NOCOMPRESS is the knob used to swtich from .txz to .tar, so that it is not compressed. If you want to change the compression, you probably have to do this, in make.conf: PKG_SUFX= .tzst in poudriere.conf: PKG_REPO_META_FILE=/usr/local/etc/poudriere.d/meta And create that file with this content: version = 1; packing_format = "tzst"; You may have to fiddle with the packing_format, I don't know what the exact string is. -- Mathieu Arnold signature.asc Description: PGP signature
Re: GL_xx tags fail when GL_SITE=https://git.zrythm.org
On Thu, Oct 31, 2019 at 01:23:15AM -0700, Yuri wrote: > On 2019-10-31 00:57, Tobias Kortkamp wrote: > > GL_* is for GitLab instances andhttps://git.zrythm.org does not > > appear to be one anymore. > > > It worked as a GitLab in the previous versions, but now it doesn't any more? > > Did it morph somehow? Are you asking us to guess? Because right now, like, you know, if you actually try to fetch the current version, well, it does not work: $ make checksum MASTER_SITE_BACKUP= IGNORE_MASTER_SITE_LOCAL= /!\ zrythm-0.5.097_1: Makefile warnings, please consider fixing /!\ Using USE_XORG alone is deprecated, please use USES=xorg ===> License GPLv3 accepted by the user ===> zrythm-0.5.097_1 depends on file: /usr/local/sbin/pkg - found => zrythm-zrythm-5b1f4efa53ca33090ef7795204dfc387072f58f5_GL0.tar.gz doesn't seem to exist in /home/mat/work/freebsd/distfiles/. => Attempting to fetch https://git.zrythm.org/zrythm/zrythm/repository/5b1f4efa53ca33090ef7795204dfc387072f58f5/archive.tar.gz?dummy=/zrythm-zrythm-5b1f4efa53ca33090ef7795204dfc387072f58f5_GL0.tar.gz fetch: https://git.zrythm.org/zrythm/zrythm/repository/5b1f4efa53ca33090ef7795204dfc387072f58f5/archive.tar.gz?dummy=/zrythm-zrythm-5b1f4efa53ca33090ef7795204dfc387072f58f5_GL0.tar.gz: Not Found => Couldn't fetch it - please try to retrieve this => port manually into /home/mat/work/freebsd/distfiles/ and try again. *** Error code 1 Stop. $ So, if it worked before, and as it does not work any more, well, yes, the web site probably changed. -- Mathieu Arnold signature.asc Description: PGP signature
Re: dns/bind911 and 2019Q4 branch
On Sun, Oct 20, 2019 at 11:01:31AM +0200, Andrea Venturoli wrote: > Hello. > > I'm currently testing using the ports quarterly branch. > > I see dns/bind911 was updated from 9.11.11 to 9.11.12 in head. > AFAICT this fixes a security vulnerability. > > Shouldn't this be merged in the 2019Q4 branch? > Will it? The ISC was very clear in that this update[1] is not a security related release, so I have absolutely no plan to merge it. 1: https://lists.isc.org/pipermail/bind-announce/2019-October/001139.html -- Mathieu Arnold signature.asc Description: PGP signature
Re: FLAVORS for Ruby
On Tue, Sep 17, 2019 at 01:16:50AM +0900, Koichiro Iwao wrote: > On Mon, Sep 16, 2019 at 08:54:17AM -0600, Adam Weinberger wrote: > > On Mon, Sep 16, 2019 at 8:39 AM Koichiro Iwao wrote: > > > > > > On Sat, Sep 14, 2019 at 10:52:45AM -0600, Adam Weinberger wrote: > > > > The issue is that FLAVORS has added a substantial (and painful) > > > > complexity to python ports and python.mk. It means that a number of > > > > people have had to be hyper-vigilant and watch commits closely to catch > > > > errors introduced when people utilize the paradigm incorrectly. It’s a > > > > bitter pill, but it’s accepted because the use-case for multiple > > > > concurrent python versions is essential. > > > > > > > > As Antoine said, inconsistency isn’t a strong enough use case. Which > > > > brings us back to the original question: is there a specific use-case > > > > for concurrent ruby that makes the substantial increase in cognitive > > > > load, complexity, and monitoring worth it? > > > > > > PHP also have FLAVORS. What about PHP? Multiple concurrent PHP versions > > > is essential? > > > > We're going in circles here. I've for the third time now that what > > we'd need to get on board is a use case, a description of the end-user > > problem that we're trying to solve. > > > > What you've provided (for the fourth time in this thread) is a straw > > man argument. What other languages have is irrelevant. We are much > > less concerned with "consistency" than with solving end-user problems > > in a way that fits the specific use case. > > > > Steve seemed interested in the idea. I'd explore it with him, and I > > hope you are able to make it happen. I'm done here. > > Thanks. I see a gap between you and me but I'll give it a try anyway > with swills. > > You: If there's no valid reasons, don't do it. > Me: If there's no invalid reasons, try it. > > I believe that the reason Ruby don't have FLAVORS is just nobody worked > on that. In fact, swills worked on that a little. > > BTW, if I can do something only necessary, what a boring life. What we are all trying to say is that adding flavors for ruby will have a big impact on build time and ressources required for building. If all you want is to have ruby flavors for the kicks of it, then I am glad to tell you that no, it will not be done. Now, the question is, why would someone need to have ruby flavors? The answer cannot be "because it should be fun" or "there is no reason there should not be". Give us a real reason about why it would be required. -- Mathieu Arnold signature.asc Description: PGP signature
Re: git submodule
On Wed, Aug 28, 2019 at 10:55:20PM -0700, Cy Schubert wrote: > 2) Have the port download two tarballs from github. But, how, elegantly? I'm going to say something strange, but, read the doc? https://www.freebsd.org/doc/en/books/porters-handbook/makefile-distfiles.html#makefile-master_sites-github-submodules -- Mathieu Arnold signature.asc Description: PGP signature
Re: 12.0-RELEASE-p7 doesn't contain std::filesystem that has been added to 12.0-STABLE some time later
On Tue, Jul 09, 2019 at 12:51:52PM -0700, Yuri wrote: > On 2019-07-08 23:54, Mathieu Arnold wrote: > > On Mon, Jul 08, 2019 at 03:48:25PM -0700, Yuri wrote: > > > Maybe the patch level should be updated, because any port using > > > std::filesystem fails in the current poudriere 12.0-RELEASE-p7 VM. > > 12.0-RELEASE-p* is a different branch than 12.0-STABLE. releng/12.0 vs > > stable/12. Only security fixes and critical fixes get applied to the > > releng branches. > > When releng/12.0 was branched, OSVERSION of the branch was 1200086, and > > it has not changed on that branch. Just after releng/12.0 was branched, > > the stable/12 branch OSVERSION was bumped to 1200500, to show it is > > ahead. Details are available here (some OSVERSION bumps may be missing): > > https://www.freebsd.org/doc/en/books/porters-handbook/versions-12.html > > > > Thanks for this information. > > This means that ports using std::filesystem can never be built in poudriere > on 12 because std::filesystem is not a security feature and it will not be > included in the patches. I'm not sure I follow what you are talking about. It can be built on stable/12, which is 12.0-STABLE, and on 12.1 when it gets released in November. -- Mathieu Arnold signature.asc Description: PGP signature
Re: 12.0-RELEASE-p7 doesn't contain std::filesystem that has been added to 12.0-STABLE some time later
On Mon, Jul 08, 2019 at 03:48:25PM -0700, Yuri wrote: > Maybe the patch level should be updated, because any port using > std::filesystem fails in the current poudriere 12.0-RELEASE-p7 VM. 12.0-RELEASE-p* is a different branch than 12.0-STABLE. releng/12.0 vs stable/12. Only security fixes and critical fixes get applied to the releng branches. When releng/12.0 was branched, OSVERSION of the branch was 1200086, and it has not changed on that branch. Just after releng/12.0 was branched, the stable/12 branch OSVERSION was bumped to 1200500, to show it is ahead. Details are available here (some OSVERSION bumps may be missing): https://www.freebsd.org/doc/en/books/porters-handbook/versions-12.html -- Mathieu Arnold signature.asc Description: PGP signature
Re: force github file extension for fetch? (tar.bz2 instead of tar.gz)
On Mon, Jun 03, 2019 at 11:03:18AM -0600, Gary Aitken wrote: > In attempting to build a new port (prusa3d slicer) I need another new > port (wxWidgets). The original distfile fetch of wxWidgets was a .tar.gz. > The configure phase had an error; a search for the source of the error > turned up a bug (old) which claimed the error was solved by fetching the > distfile as a .tar.bz2. > .tar.bz2 is the github *nix distfile for the port. > > Is it possible to force fetching of .tar.bz2 instead of .tar.gz if both are > available? Or how does one get around the problem? > > 11.2-RELEASE-p4 > relevant Makefile details: > > PORTNAME= wxwidgets > DISTVERSIONPREFIX= v > DISTVERSION=3.1.2 > USE_GITHUB= yes > GH_ACCOUNT= wxWidgets > GH_PROJECT= wxWidgets GitHub only supports extracts using .tar.gz or .zip file formats. Any other format DOES NOT use USE_GITHUB but manually uploaded releases files. If you look at https://github.com/wxWidgets/wxWidgets/releases/tag/v3.1.2 what USE_GITHUB allows you to download is the very last link, that they call "Source code (tar.gz)", there is also a "Source code (zip)" that we never used because tar.gz was more conveninent for us. All other files on that page have been manually uploaded by the maintainer, and cannot be fetched using USE_GITHUB. -- Mathieu Arnold signature.asc Description: PGP signature
Re: The hs-* issue
On Sun, May 12, 2019 at 04:48:43PM -0600, The Doctor via freebsd-ports wrote: > On Sun, May 12, 2019 at 11:20:21PM +0400, Gleb Popov wrote: > > On Sun, May 12, 2019 at 10:11 PM The Doctor > > wrote: > > > > > On Sat, May 11, 2019 at 09:20:29PM +0400, Gleb Popov wrote: > > > > On Sat, May 11, 2019 at 4:07 PM The Doctor > > > wrote: > > > > > > > > > On Sat, May 11, 2019 at 10:47:37AM +0400, Gleb Popov wrote: > > > > > > On Sat, May 11, 2019 at 12:49 AM The Doctor < > > > doc...@doctor.nl2k.ab.ca> > > > > > > wrote: > > > > > > > > > > > > > On Fri, May 10, 2019 at 11:25:20PM +0400, Gleb Popov wrote: > > > > > > > > On Fri, May 10, 2019 at 8:54 PM The Doctor via freebsd-ports < > > > > > > > > freebsd-ports@freebsd.org> wrote: > > > > > > > > > > > > > > > > > > > > > > > > Can't reproduce this locally. What FreeBSD version are you > > > running, > > > > > and > > > > > > > > what SVN revision are you on? > > > > > > > > > > > > > > > > > > > > > > FreeBSD 12.0 > > > > > > > > > > > > > > svn, version 1.12.0 (r1857323) > > > > > > >compiled Apr 26 2019, 08:07:07 on amd64-portbld-freebsd12.0 > > > > > > > > > > > > > > > > > > > I meant FreeBSD ports tree revision. Or are you using portsnap to > > > obtain > > > > > > ports tree? > > > > > > > > > > > > > > > > portsnap! > > > > > > > > > > > > > I'm puzzled what's wrong with your system. Things to try: > > > > > > > > 1. Do another `portsnap fetch update`. > > > > 2. make -C /usr/ports/devel/hs-cabal-install clean > > > > 3. Use binary package for hs-cabal-install. > > > > > > Where can I find a binary? > > > > > > > pkg install hs-cabal-install > > > > Too many packages to cancel. Only one, pkg delete hs-cabal-install; pkg autoremove. -- Mathieu Arnold signature.asc Description: PGP signature
Re: ports r500205 generates extraneous "make describe"
On Thu, May 02, 2019 at 05:41:45PM -0600, Adam Weinberger wrote: > On Thu, May 2, 2019 at 3:36 PM Peter Jeremy wrote: > > > > Doing a "make describe" (part of "make index") in > > /usr/ports/science/ALPSCore > > now generates extraneous output as below. Could you please look into this. > > > > server% make describe > > sh: /usr/local/mpi/openmpi2/bin/mpicc: not found > > make: "/usr/ports/Mk/Uses/compiler.mk" line 78: warning: > > "/usr/local/mpi/openmpi2/bin/mpicc --version" returned non-zero status > > make: "/usr/ports/Mk/Uses/compiler.mk" line 133: warning: > > "/usr/local/mpi/openmpi2/bin/mpicxx -### /dev/null 2>&1" returned non-zero > > status > > ALPSCore-2.2.0_7|/usr/ports/science/ALPSCore|/usr/local|Generic algorithms > > and utilities for condensed matter > > physics|/usr/ports/science/ALPSCore/pkg-descr|po...@freebsd.org|science/usr/ports/devel/boost-libs > > /usr/ports/devel/cmake /usr/ports/devel/ninja /usr/ports/math/eigen3 > > /usr/ports/net/openmpi2 /usr/ports/science/hdf5 > > /usr/ports/science/szip|/usr/ports/devel/boost-libs /usr/ports/net/openmpi2 > > /usr/ports/science/hdf5 > > /usr/ports/science/szip|https://github.com/ALPSCore/ALPSCore > > > > -- > > Peter Jeremy > > I was wondering about this too. Perhaps instead of _VARS, this should be using > OPENMPI2_CONFIGURE_ENV= cc=... cxx=... > OPENMPI2_MAKE_ENV= cc=... cxx=... You can only change CC/CXX after bsd.port.pre.mk otherwise it breaks bits of the framework like compiler.mk. This should probably be changed to a .if PORT_OPTIONS:M test after includ'ing bsd.port.pre.mk. -- Mathieu Arnold signature.asc Description: PGP signature
Re: Bind914 conficts with bind-tools
On Wed, May 01, 2019 at 11:08:47AM +0200, Xavier wrote: > Hello, > > I wanted to portupgrad bind914, ran into a conflict : > > > [root@numenor bind914]# make all > > ===> Staging for bind914-9.14.1 > > ===> bind914-9.14.1 depends on package: bind-tools>0 - not found > > ===> Installing for bind-tools-9.14.1 > > ===> Checking if bind-tools is already installed > > ===> Registering installation for bind-tools-9.14.1 as automatic > > Installing bind-tools-9.14.1... > > pkg-static: bind-tools-9.14.1 conflicts with bind914-9.14.0 (installs files > > into the same place). Problematic file: /usr/local/bin/arpaname > > I ran make clean before > > Thanks for ideas, You need to remove bind914-9.14.0 first. -- Mathieu Arnold signature.asc Description: PGP signature
Re: poudriere and flavours? php73 pecl-pthreads
On Tue, Apr 30, 2019 at 04:21:52PM +0200, Philippe Maechler wrote: > Hello Mathieu > > > > >On Tue, Apr 30, 2019 at 02:23:31PM +0200, Mathieu Arnold wrote: > > > > >> It seems that devel/pecl-pthreads's Makefile has not been updated in the > > >> last 6 years to account for how packages are built. I'll try to fiddle > > >> with it. > > > > Thank you very much for your efforts! > > > > >So I "fixed" it, now it will let you try and build it. Not that > > >pecl-phreads currently *only* builds for PHP 7.0. (Yes, PHP 7.0 has been > > >removed months ago.) > > > > Ok… > > > > When building pecl-pthreads without the @php73 in poudriere, it tries to > build it for php72. After that I create a make.conf for php72 with ZTS > enabled and get the same error. > > I guess this is what you meant by “only builds for PHP 7.0” > > > > Is this a pecl-pthreads issue or something in the ports tree that’s not > “fine” yet? If it is the ports tree, are you or someone else working on this? > > I’m not really good at ports management and compiling stuff, but if there is > something I can help with, please let me now I have a ports tree with PHP from 5.3 to 7.3 (for internal purposes because customers), and pecl-pthreads only builds with 7.0. So it is most probably broken for any other version, and the latest update is years old anyway. -- Mathieu Arnold signature.asc Description: PGP signature
Re: poudriere and flavours? php73 pecl-pthreads
Hi again, On Tue, Apr 30, 2019 at 02:23:31PM +0200, Mathieu Arnold wrote: > Hi, > > On Tue, Apr 30, 2019 at 10:17:07AM +0200, Philippe Maechler wrote: > > Hello freebsd-ports, it's me again > > > > > > > > Once more I have troubles building ports on FreeBSD 11.2 and 12.0. The last > > time I could build those "problemativ" ports in my poudriere installation > > and used the package from there. > > > > But this time, even poudriere won't build the port. > > It seems that devel/pecl-pthreads's Makefile has not been updated in the > last 6 years to account for how packages are built. I'll try to fiddle > with it. So I "fixed" it, now it will let you try and build it. Not that pecl-phreads currently *only* builds for PHP 7.0. (Yes, PHP 7.0 has been removed months ago.) -- Mathieu Arnold signature.asc Description: PGP signature
Re: poudriere and flavours? php73 pecl-pthreads
Hi, On Tue, Apr 30, 2019 at 10:17:07AM +0200, Philippe Maechler wrote: > Hello freebsd-ports, it's me again > > > > Once more I have troubles building ports on FreeBSD 11.2 and 12.0. The last > time I could build those "problemativ" ports in my poudriere installation > and used the package from there. > > But this time, even poudriere won't build the port. It seems that devel/pecl-pthreads's Makefile has not been updated in the last 6 years to account for how packages are built. I'll try to fiddle with it. -- Mathieu Arnold signature.asc Description: PGP signature
Re: What is procedure to add new USES makefile (Mk/Uses/name.mk)?
On Thu, Apr 25, 2019 at 09:40:37PM +0300, Lev Serebryakov wrote: > > I want to swtich subversion port selection from custom variable to > DEFAULT_VERSIONS and USES infrastructure. Now it is broken for at least > two ports, and may be for more. > > Does I need additional review for my changes, as it touches not only > personal port(s) but infrastructure makefiles? Everything in Mk must be reviewed, create reviews on phabricator, portmgr will be poked about it. -- Mathieu Arnold signature.asc Description: PGP signature
Re: PHP 7.2: SIGSEGV in OpenSSL
On Wed, Apr 24, 2019 at 06:34:06PM +0200, Stefan Bethke wrote: > > Am 23.04.2019 um 18:01 schrieb Kurt Jaeger : > > > > Hi! > > > >> Did you find a solution? Please let me know. > > > > There's a well-known problem in the sequence in which php modules > > are loaded. I don't know if this is the case here as well, > > but that's what we do: > > > > fetch -o fixphpextorder \ > >https://people.freebsd.org/~ohauer/scripts/fixphpextorder.sh > > chmod 755 fixphpextorder > > > > cd /usr/local/etc/php > > cat ext-*ini > extensions.ini > > fixphpextorder > > mv extensions.ini.new extensions.ini > > rm ext-*ini > > > > Please test and report if it fixes the problem. > > Thanks Kurt, it appears to fix (or at least work around) the problem. > > Why is the default load order broken? Why does it not affect everyone? > > I moved all the individual inis into a bak subdir, and now only have an > extensions.ini. > > If I understand correctly, mod_php/PHP reads the individual inis in order. > Why aren’t they in the right order? Can this be fixed in the ports for the > PHP modules? Could you give the order that works for you, so that we can try to figure out which module is making it break ? Because there is no "right" order, there is an order that can work for most people, and from time to time, two libs have conflicting symbols, but it is not possible to detect that. So I made up an order that should be ok, but some time is not. -- Mathieu Arnold signature.asc Description: PGP signature
Re: How to use @preexec to test for installed packages
On Fri, Apr 19, 2019 at 02:36:38PM +0200, Matthias Fechner wrote: > Am 06.04.2019 um 20:59 schrieb Adam Weinberger: > > Especially since www/gitea does the same thing (and probably a number > > of others as well). > > I did now a lot of tests and came to the conclusion that I will add > these checks into the startup script of gitlab-ce. > > Maybe this problem will be fixed in a future version of pkg to be able > to use the CONFLICTS_ definition from the Makefile. Please do not. Let the admin decide what they want to use. -- Mathieu Arnold signature.asc Description: PGP signature
Re: depends blacklist qa check
On Mon, Apr 08, 2019 at 01:55:19PM -0400, Dan Langille wrote: > re: https://reviews.freebsd.org/D19562 > > I understand the purpose of the blacklist is to restrict the use of certain > meta ports to end-users only. That is, the meta-ports in question should not > be used as a depends in the FreeBSD ports tree. > > For example, do not use lang/python as a depends. Let the user install that > install. > > With my user hat on, who has a in-house meta-port which includes lang/python2 > as a depends, because we want it, and list of other stuff installed. > > We can't do that now. Our meta-port is broken and can no longer be used. Is > there another way? The list appears hardcoded and no way for the end user to > configure. Well, that is not correct. QA checks are only run when using poudriere testport or bulk -t, or when DEVELOPER=yes. So, while it is true that such meta port will no longer pass testing, it will not impact a normal poudriere bulk. -- Mathieu Arnold signature.asc Description: PGP signature
Re: category for VPN softwares?
On Tue, Apr 02, 2019 at 03:34:57PM +0200, Baptiste Daroussin wrote: > On Tue, Apr 02, 2019 at 06:29:09AM -0600, Adam Weinberger wrote: > > On Tue, Apr 2, 2019 at 6:24 AM Diane Bruce wrote: > > > > > > On Tue, Apr 02, 2019 at 06:13:58AM -0600, Adam Weinberger wrote: > > > > On Tue, Apr 2, 2019 at 3:37 AM Mateusz Piotrowski <0...@freebsd.org> > > > > wrote: > > > > > > > > > > On Tue, 2 Apr 2019 at 10:58, Stefan Esser wrote: > > > > > > > > > > > Am 02.04.19 um 07:42 schrieb Koichiro Iwao: > > > > > > > On Tue, Apr 02, 2019 at 06:41:51AM +0200, Kurt Jaeger wrote: > > > > > > >> Create a real category vpn and move everything to it ? > > > > > > > > > > > > > > Sounds better! Gentoo has net-vpn category. Just FYI, Gentoo also > > > > > > > have > > > > > > > net-dialup category. PPP/PPPoE/L2TP softwares are put under > > > > > > > net-dialup > > > > > > > but I feel that classification is too fine. At least creating vpn > > > > > > > or > > > > > > > net-vpn souds good. > > > > > > > > > > > > How about a new "real" category vpn > > > > > > > > > > > > > > > I am not sure if it should be vpn or net-vpn. I feel net-vpn is > > > > > more suitable. > > > > > > > > > > > > > > > > and preserving the current categories > > > > > > of the ports as their additional categories (assuming that they are > > > > > > in net > > > > > > vs. security for a reason). > > > > > > > > > > > > > > > > I like the idea. > > > > > > > > Creating new categories is absolutely doable! However, we have a > > > > pretty high bar for justifying it. There's no magic number, but our > > > > (portmgr's) precedent is that the new category must, at the time of > > > > creation, be as full as other categories like it. > > > > > > > > The most important thing in the new category proposal is a > > > > comprehensive list of ports that will be moved to it. Put that into a > > > > review or a PR and we can move forward. Fair warning though, if it's > > > > only about a dozen ports, it most likely will not be approved. > > > > > > > > My approach here is that new categories should be virtual unless the > > > > evidence for hard category is incontrovertible. > > > > > > It's far easier making a virtual category and easier to count ports. > > > e.g. https://www.freshports.org/hamradio > > > > > > We have 101 hamradio related ports with more coming... > > > korean has 43,portuguese has 15,russian has 42 although languages are a > > > special case palm has 15 ports but whatever. ;) > > > > > > I'd be surprised if there weren't more vpn ports than 101 so why not > > > go with a virtual ports category to start with? > > > > Hi Diane, > > > > That's a great approach to it! AFAIK we haven't explicitly used > > virtual categories as a staging ground for hard categories, but that > > seems like a really pragmatic approach; no matter the outcome, the > > ports tree comes out ahead. > > > > # Adam > > Just to say, having a new "real" category will force people to rework their > entry list for poudriere, reinstall things if they are using portmaster etc. For poudriere, it is transparent as it parses MOVED, and new physical categories add entries in there. I think it will tell you something about it too. -- Mathieu Arnold signature.asc Description: PGP signature
Re: category for VPN softwares?
On Tue, Apr 02, 2019 at 06:13:58AM -0600, Adam Weinberger wrote: > On Tue, Apr 2, 2019 at 3:37 AM Mateusz Piotrowski <0...@freebsd.org> wrote: > > > > On Tue, 2 Apr 2019 at 10:58, Stefan Esser wrote: > > > > > Am 02.04.19 um 07:42 schrieb Koichiro Iwao: > > > > On Tue, Apr 02, 2019 at 06:41:51AM +0200, Kurt Jaeger wrote: > > > >> Create a real category vpn and move everything to it ? > > > > > > > > Sounds better! Gentoo has net-vpn category. Just FYI, Gentoo also have > > > > net-dialup category. PPP/PPPoE/L2TP softwares are put under net-dialup > > > > but I feel that classification is too fine. At least creating vpn or > > > > net-vpn souds good. > > > > > > How about a new "real" category vpn > > > > > > I am not sure if it should be vpn or net-vpn. I feel net-vpn is > > more suitable. > > > > > > > and preserving the current categories > > > of the ports as their additional categories (assuming that they are in net > > > vs. security for a reason). > > > > > > > I like the idea. > > Creating new categories is absolutely doable! However, we have a > pretty high bar for justifying it. There's no magic number, but our > (portmgr's) precedent is that the new category must, at the time of > creation, be as full as other categories like it. > > The most important thing in the new category proposal is a > comprehensive list of ports that will be moved to it. Put that into a > review or a PR and we can move forward. Fair warning though, if it's > only about a dozen ports, it most likely will not be approved. > > My approach here is that new categories should be virtual unless the > evidence for hard category is incontrovertible. And in any case, see our documentation: https://www.freebsd.org/doc/en/articles/committers-guide/ports.html#ports-qa-new-category -- Mathieu Arnold signature.asc Description: PGP signature
New 2019Q2 branch
Hi, The 2019Q2 branch has been created. It means that the next update on the quarterly packages will be on the 2019Q2 branch. A lot of things happened in the last three months: - New USES: azurepy, sdl (from bsd.sdl.mk) - Removed USES: gecko - Default version of lazarus switched to 2.0.0 - Default version of llvm switched to 8.0 - Firefox 66.0.2 - Firefox-esr 60.6.1 - Chromium 72.0.3626.121 - Ruby 2.5.3 -> 2.5.5 (2.3 was removed) - gcc 8.2.0 -> 8.3.0 - Qt5 5.12.1 These were removed: - Qt4 being EOL and unsupported for years. - PHP 5.6 was EOL. - Postgresql 9.3 was EOL - The various webkit-* ports were EOL, had security issues. Next quarterly package builds will start on Wednesday April 3rd and should be available on your closest mirrors few days later. For those stat nerds out there, here's what happened during the last 3 months on head: Number of commits: 8205 Number of committers: 167 Most active committers: 1742 sunpoet 490 jbeich 449 yuri 445 tobik 381 swills 288 tcberner 270 amdmi3 249 antoine 229 linimon 227 dbaio Diffstat: 19541 files changed, 361847 insertions(+), 77 deletions(-) and on the 2019Q1 branch: Number of commits: 398 Number of committers: 61 Most active committers: 95 jbeich 33 tobik 21 riggs 17 sunpoet 17 joneum 16 tcberner 15 tz 14 mfechner 10 pi 10 linimon Diffstat: 1063 files changed, 13781 insertions(+), 8854 deletions(-) Regards, -- Mathieu Arnold signature.asc Description: PGP signature
Re: Changes to USE_GNOME to USES=gnome
On Thu, Mar 28, 2019 at 08:16:56PM -0700, Ultima wrote: > Why was the change made to add additional requirements for > using USE_GNOME? I'm not seeing what value this provides. > Is this to make the use of USES followed by USE_* more > standardized? No change was made to add requirements. The old Mk/bsd.gnome.mk was converted to Mk/Uses/gnome.mk to help standardize things. So, like all USES, you have to say USES=gnome before you can say USE_GNOME=foo. It is the same for every other old thing that was converted. USES gives you one place to declare which component you will be using in the port, so one can know at once what they will find in there. -- Mathieu Arnold signature.asc Description: PGP signature
Re: Request for commit approval virtual_oss_ctl 1.2.0
On Thu, Mar 28, 2019 at 09:44:50PM +0100, Hans Petter Selasky wrote: > Restore virtual_oss_ctl to version 1.2.0. > > This version adds support for FIR filters. > > Approved by: > Approved. -- Mathieu Arnold signature.asc Description: PGP signature
Re: Changes to USE_GNOME to USES=gnome
On Thu, Mar 28, 2019 at 03:44:45PM -0700, Ultima wrote: > Hello ports, > > USE_GNOME has been deprecated in favor of USES=gnome. > My question is that when removing USE_GNOME, USES=gnome > takes no arguments, so how do you select which components to > use when using USES=gnome, is USE_GNOME still used for this > part? What is deprecated is using USE_GNOME without USES=gnome. Of course you still need USE_GNOME to bring in the components that are required. -- Mathieu Arnold signature.asc Description: PGP signature
Re: PORTREVISION bump on lang/perl5.26
On Wed, Mar 20, 2019 at 04:34:36PM -0400, Dan Langille wrote: > Mat, > > I think we should do a PORTREVISION bump on lang/perl5.26 because of > DEPRECATED. > > 5.26.3 came in on 4 Dec with > https://svnweb.freebsd.org/ports?view=revision=486599 > > DEPRECATED was commented out. > > DEPRECATED came back in on 17 Dec with > https://svnweb.freebsd.org/ports/head/lang/perl5.26/Makefile?r1=487685=487686; > > This affects me, and probably others. > > I have multiple hosts with perl5-5.26.3, some deprecated, some not, depending > on when perl was built. > > [dan@pg11:~] $ pkg annotate -a -S expiration_date > perl5-5.26.3: Tag: expiration_date Value: 2020-05-31 > > [dan@pg10:~] $ pkg annotate -a -S expiration_date > [dan@pg10:~] $ pkg info -x perl > perl5-5.26.3 > [dan@pg10:~] $ > > I'm happy to do the bump. We do not bump PORTREVISION for metadata changes, like when port get deprecated, so, no, this will not happen. -- Mathieu Arnold signature.asc Description: PGP signature
Re: How to alert committer?
On Tue, Feb 05, 2019 at 11:08:01AM +, Bob Eager wrote: > I have a PR on one of my ports, and I agree with the patch provided. > > I'm not sure how to signal to have the port committed. I can obviously > ask here (and am now doing so) but is there an automated way of doing > that please? > > Port: math/rexx-regmath > PR: 235512 > > This is a fix to the Makefile to allow compilation on non-Clang systems. All you need to do is set the "maintainer feedback" thing to a +, it then should appears in the "maintainer approved" search. Maybe you need to set the "maintainer approval" thing on the patch though, and not on the PR itself. -- Mathieu Arnold signature.asc Description: PGP signature
Re: Renaming net/ceph to net/ceph12
On Tue, Jan 22, 2019 at 07:13:54PM +0100, Willem Jan Withagen wrote: > On 22-1-2019 16:45, Mathieu Arnold wrote: > > On Tue, Jan 22, 2019 at 03:35:51PM +0100, Willem Jan Withagen wrote: > > > On 22/01/2019 15:29, Mathieu Arnold wrote: > > > > On Tue, Jan 22, 2019 at 10:42:16AM +0100, Willem Jan Withagen wrote: > > > > > Hi, > > > > > > > > > > I there a ports committer that can do that for me if it is just a > > > > > mater of > > > > > `fix Makefile && svn rename` greatly appreciated. > > > > > > > > > > If it needs more work, can somebody explain to me what more is needed? > > > > > > > > > > After this is done, I'll submit a new ceph 12.2.11 version once it is > > > > > out. > > > > > And I'll upload the first version of ceph 13.2.x > > > > > > > > Well, there is nothing more needed, but, it would mean that until you > > > > submit tne 13.2.x update, there would be two identical versions of ceph. > > > > > > I would submit both under their own names: ceph12 or ceph13. > > > > Well, how they end up being named does not really matter. What matters > > is history. When ceph13 ends up being created, it will be by taking the > > ceph, or ceph12 directory, running svn copy so that subversion registers > > the ancestry, and by then updating that. > > Sorry for all the questions, but I do not often submit to FreeBSD. > And mostly upgrades go thru a shar in bugzilla. > > So I'd run > svn copy ceph ceph12 > svn copy ceph ceph13 > svn del ceph > > And fix both to the new versions... > Then submit the `svn diff net/ceph12` > > But then does that diff carry the ancestry? > Or need I submit thru arc? https://www.freebsd.org/doc/en/books/porters-handbook/port-upgrading.html Note: If some files have been added, copied, moved, or removed, add this information to the problem report so that the committer picking up the patch will know what svn(1) commands to run. -- Mathieu Arnold signature.asc Description: PGP signature
Re: Renaming net/ceph to net/ceph12
On Tue, Jan 22, 2019 at 03:35:51PM +0100, Willem Jan Withagen wrote: > On 22/01/2019 15:29, Mathieu Arnold wrote: > > On Tue, Jan 22, 2019 at 10:42:16AM +0100, Willem Jan Withagen wrote: > > > Hi, > > > > > > I there a ports committer that can do that for me if it is just a mater of > > > `fix Makefile && svn rename` greatly appreciated. > > > > > > If it needs more work, can somebody explain to me what more is needed? > > > > > > After this is done, I'll submit a new ceph 12.2.11 version once it is out. > > > And I'll upload the first version of ceph 13.2.x > > > > Well, there is nothing more needed, but, it would mean that until you > > submit tne 13.2.x update, there would be two identical versions of ceph. > > I would submit both under their own names: ceph12 or ceph13. Well, how they end up being named does not really matter. What matters is history. When ceph13 ends up being created, it will be by taking the ceph, or ceph12 directory, running svn copy so that subversion registers the ancestry, and by then updating that. > > It would be preferrable to submit the 13.2.x update, asking the > > committer in the PR to also copy the current version to net/ceph12. > > Oke, > > So I'll first get ceph13 ready, submit and ask to move net/ceph to > net/ceph12 > > Sort of like I did in > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230432 > ?? > I'll be more persistent this time. > > --WjW > > > > > ___ > 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" > -- Mathieu Arnold signature.asc Description: PGP signature
Re: Renaming net/ceph to net/ceph12
On Tue, Jan 22, 2019 at 10:42:16AM +0100, Willem Jan Withagen wrote: > Hi, > > I there a ports committer that can do that for me if it is just a mater of > `fix Makefile && svn rename` greatly appreciated. > > If it needs more work, can somebody explain to me what more is needed? > > After this is done, I'll submit a new ceph 12.2.11 version once it is out. > And I'll upload the first version of ceph 13.2.x Well, there is nothing more needed, but, it would mean that until you submit tne 13.2.x update, there would be two identical versions of ceph. It would be preferrable to submit the 13.2.x update, asking the committer in the PR to also copy the current version to net/ceph12. -- Mathieu Arnold signature.asc Description: PGP signature
Re: dns/bind911 - statistics-file
On Sat, Jan 19, 2019 at 07:50:45PM -0500, Dan Langille wrote: > Mat, > > I encountered an odd situation where my stats file kept changing permissions. > With every reinstall of bind911, > the permissions on var/run/named/stats change to chown root:bind which > prevents bind from updating the file. > > This is what I need: > > $ ls -l /var/run/named/stats > -rw-r--r-- 1 bind bind 11507 Jan 20 00:45 /var/run/named/stats > > Could that change be carried out by this file? > > > https://svnweb.freebsd.org/ports/head/dns/bind911/files/BIND.chroot.dist?view=markup#l24 > > I don't see a reference to /var/run/named/stats in BIND.chroot.dist but can't > help but wonder if it's something similar. > > I have been using these options: > > directory "/usr/local/etc/namedb/working"; > pid-file"/var/run/named/pid"; > dump-file "/var/dump/named_dump.db"; > statistics-file "/var/run/named/stats"; > zone-statistics yes; > > When researching this tonight, I noticed the sample configuration uses > /var/run/named.stats. Perhaps I'm doing this wrong. > I am happy to change my configuration, but first I write in case the script > is doing something unexpected. I do not think anything in the BIND9 ports would change the file permissions. The mtree file only touches the directories to make sure they have the correct permissions, so it is not it. Moreover the mtree file is ONLY used when using named_chrootdir to chroot named, which does not appear to be your case. The BIND9 ports have not had a pkg-install script for years, so it's not it either. The rc file does not chown anything, so it's not it doing it either. Side note, the sample configuration uses /var/stats/named.stats, not /var/run/named.stats. And it was ever since it was added to the base system named.conf file back in 2004 (in src r135918). So I'd say something else on your system "fixes" the file's permissions. -- Mathieu Arnold signature.asc Description: PGP signature
Re: py27 ./. py3 version of ports
On Fri, Jan 11, 2019 at 02:40:02PM +0100, Matthias Apitz wrote: > El día viernes, enero 11, 2019 a las 11:53:09a. m. +0100, Mathieu Arnold > escribió: > > > > > The background for my question is: I'm porting an AI system > > > > https://community.mycroft.ai/t/mycroft-on-freebsd/5119/8 > > > > to CURRENT which is written for Linux and make excessive use of Python3. > > > > > > > > What I have to set in poudriere to get some required py3 packages built > > > > as > > > > well, but WITHOUT changing the dependency for my ~2000 packages which > > > > pulled > > > > somehow in the standard py27 ports? > > > > > > Sure. You can build the py36 ports you want in addition to the regular > > > py27 > > > ones. Just add the port name(s) to your build list appended with '@py36'. > > > It's generally safe to have both python27 and python36 packages of the > > > same > > > module installed simultaneously -- just remember to use 'python3' on the > > > command line or in shebangs. > > > > python3.6. python3 is only there if you install the lang/python3 port. > > (Which you probably should not.) > > The above software in question needs python3 which I do have installed. > Why I should not? If it is only on your local machine, it is absolutely not a problem. On the other hand, if you are porting an application, python3 is not a valid shebang, and you must use USES=shebangfix to fix the offending files. -- Mathieu Arnold signature.asc Description: PGP signature
Re: py27 ./. py3 version of ports
On Thu, Jan 10, 2019 at 01:00:27PM +, Matthew Seaman wrote: > On 10/01/2019 11:58, Matthias Apitz wrote: > > El día jueves, enero 10, 2019 a las 11:14:19a. m. +, Matthew Seaman > > escribió: > > > > > On 10/01/2019 10:04, Matthias Apitz wrote: > > > > I've compiled on CURRENT the ports of December 23 from SVN with my > > > > poudriere oven. ANd I have nothing set about FLAVOR in make.conf for > > > > python. Why d I habe now some 157 py27 ports and only 4 py3: > > > > > > > > $ ls -l /usr/PKGDIR.20181223/py27* | wc -l > > > >157 > > > > $ ls -l /usr/PKGDIR.20181223/py3* | wc -l > > > > 4 > > > > > > > > in my local repository? Perhaps I did something stupid wrong. > > > > > > > > > > Python 2.7 is still the default in ports -- that's the flavour you're > > > going to get unless you say otherwise. You'ld get py36 flavours if you > > > had something that was python36 specific on your build list, or you'ld > > > configured some ports to build that way in the list of what you want > > > poudriere to build by appending @py36 to the port name. > > > > > > You can get poudriere to generate packages for all of the different > > > standard(*) flavours by appending '@all' to the port name you give as > > > input to poudriere, or to build absolutely all standard flavours for > > > everything by adding FLAVOR_DEFAULT_ALL=yes to poudriere.conf > > > > Thanks for the explanation and I'm fine with the py27 ports. > > > > The background for my question is: I'm porting an AI system > > https://community.mycroft.ai/t/mycroft-on-freebsd/5119/8 > > to CURRENT which is written for Linux and make excessive use of Python3. > > > > What I have to set in poudriere to get some required py3 packages built as > > well, but WITHOUT changing the dependency for my ~2000 packages which pulled > > somehow in the standard py27 ports? > > Sure. You can build the py36 ports you want in addition to the regular py27 > ones. Just add the port name(s) to your build list appended with '@py36'. > It's generally safe to have both python27 and python36 packages of the same > module installed simultaneously -- just remember to use 'python3' on the > command line or in shebangs. python3.6. python3 is only there if you install the lang/python3 port. (Which you probably should not.) -- Mathieu Arnold signature.asc Description: PGP signature
Re: Add conflicts to port
On Tue, Jan 08, 2019 at 11:48:42PM +0100, Matthias Fechner wrote: > Hi Franco, > > Am 08.01.2019 um 15:58 schrieb Franco Fichtner: > > Explicit CONFLICTS only exist within the ports tree > > during builds. > > > > pkg detects conflicts simply when files are attempted > > to be installed in the same place -- i.e. a file already > > belongs to another installed package. > > hm, this will not help, as the conflicting file is created at runtime > and not by the installation of the package and can therefor not be > detected by pkg. > > I do not understand why the CONFLICTS_INSTALL does exist: > http://www.si.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/conflicts.html > > if it does not work. > Maybe a bug or has the documentation to be updated? CONFLICTS, CONFLICTS_BUILD and CONFLICTS_INSTALL exist to tell the user building the port that the port they are trying to install cannot be built-or-installed/build/installed while this other port is installed. -- Mathieu Arnold signature.asc Description: PGP signature
Re: category qt?
On Mon, Dec 24, 2018 at 11:06:56AM +0100, Walter Schwarzenfeld wrote: > The qt* ports spreads around in the whole portstree. > > It is reasonable to concentrate all these ports in a qt category? I think it > is easier to find (and also easier to maintain). While a virtual category could easily be added (by having USES=qt add it automatically) a physical category makes little sense. It would be like having all the p5- ports put in a perl directory. -- Mathieu Arnold signature.asc Description: PGP signature
Re: devel/jsoncpp and staging?
On Mon, Dec 17, 2018 at 07:25:10PM -0800, Steve Kargl wrote:
> On Mon, Dec 17, 2018 at 05:48:57PM -0800, Steve Kargl wrote:
> > I must be missing a change in how staging works.
> >
> > % cd /usr/ports/devel/jsoncpp
> > % make
> >
> > ===> Staging for jsoncpp-1.8.1_5
> > ===> Generating temporary packing list
> > (cd /usr/ports/devel/jsoncpp/work/jsoncpp-1.8.1/include/ && /bin/sh -c
> > '(/usr/bin/find -Ed $1 $3 | /usr/bin/cpio -dumpl $2 >/dev/null 2>&1) &&
> > /usr/bin/find -Ed $1 $3 \( -type d -exec /bin/sh -c '\''cd '\''$2'\'' &&
> > chmod 755 "$@"'\'' . {} + -o -type f -exec /bin/sh -c '\''cd '\''$2'\'' &&
> > chmod 0644 "$@"'\'' . {} + \)' COPYTREE_SHARE json/
> > /usr/ports/devel/jsoncpp/work/stage/usr/local/include/jsoncpp/)
> > chmod: json/allocator.h: No such file or directory
> > chmod: json/assertions.h: No such file or directory
> > chmod: json/autolink.h: No such file or directory
> > chmod: json/config.h: No such file or directory
> > chmod: json/features.h: No such file or directory
> > chmod: json/forwards.h: No such file or directory
> > chmod: json/json.h: No such file or directory
> > chmod: json/reader.h: No such file or directory
> > chmod: json/value.h: No such file or directory
> > chmod: json/version.h: No such file or directory
> > chmod: json/writer.h: No such file or directory
> >
> > % ls work/stage/usr/local/include/jsoncpp/json
> >
> >
> > Now, let's re-run make
> >
> > % make
>
> Same problem with news/xpn, except running make multiple
> times does not correct the missing files problem. So,
> is there away to use the ports collection with staging
> disabled? src.conf documents WITHOUT_STAGING, but the
> port collections seems to ignore this varible.
src.conf is about the source tree, it has absolutely nothing to do with
ports. Staging is a mandatory feature of every port.
I cannot reproduce the error you encounter, what version of FreeBSD are
you running?
--
Mathieu Arnold
signature.asc
Description: PGP signature
Re: Massive PORTREVSION bump for gcc8
On Wed, Dec 12, 2018 at 10:29:59AM -0800, Kevin Oberman wrote: > This morning the PORTREVISION on at least hundreds of ports was bumped > because gcc8 was declared as the "canonical" version. As a result, I will > have about 300 ports to rebuild which will take many hours. > Why? Because they need to be rebuilt so that they use the new default of gcc8. > If a port is built and running properly with gcc7, I see no reason to force > the rebuild of all of the ports that are built with gcc7. If you do not want to upgrade, do not upgrade. Now, if you want to keep up-to-date, well, you do have to rebuild everything with the new gcc default. -- Mathieu Arnold signature.asc Description: PGP signature
Re: Best way to deal with .pyc files?
On Mon, Dec 10, 2018 at 11:22:49AM -0800, John Baldwin wrote:
> On 12/7/18 10:17 AM, John Baldwin wrote:
> > On 12/6/18 11:17 AM, Michael Gmelin wrote:
> >>
> >>
> >>> On 6. Dec 2018, at 19:21, John Baldwin wrote:
> >>>
> >>> The devel/gdb port installs python scripts into
> >>> /usr/local/share/gdb/python.
> >>> If you then run kgdb as root (not that unusual), it will generate .pyc
> >>> files in
> >>> those directories that are not deleted by 'pkg delete'. What is the best
> >>> way to
> >>> handle this case? Should the pkg-plist include @rmtry entries for each
> >>> pyc
> >>> file or is there a better way?
> >>>
> >>
> >> Pre-generate the pyc files on package build and install them with the
> >> port, so they become part of plist (there are examples of that in the
> >> ports tree, whenever possible for both py27 and py3x).
> >
> > Ok. One follow-up question. GDB's python bindings work with both py2 and
> > py3, but the bindings are optional. Right now PYTHON is a port option
> > (but on by default). If I wanted to add flavors I would probably want them
> > to be conditional on the option, so the results would be 'gdb' and
> > 'gdb-py3' packages by default, but if someone was using poudriere locally
> > and disabled python, I would only want to build a single 'gdb' without
> > python. So, can I make the flavors conditional on an option or is it too
> > late to define flavors after including bsd.ports.options.mk?
> >
> > That is, can I do something this:
> >
> > OPTIONS_DEFINE= PYTHON
> > OPTIONS_DEFAULT= PYTHON
> >
> > .include
> >
> > .if ${PORT_OPTIONS:MPYTHON}
> > USES_PYTHON= flavors
> > .endif
>
> FYI, this worked:
All things considered, it does not matter when you set
USE_PYTHON=flavors because it does nothing if USES does not contain python.
--
Mathieu Arnold
signature.asc
Description: PGP signature
Re: 12.0-RC1: unifi5 can't be installed due to mongodb34 build failure
The patch in that PR is wrong, please do not use it. On Mon, Nov 26, 2018 at 03:56:25PM +0900, 김종성 wrote: > Tested Kurt's suggestion. Built, installed okay, and looked working (days > ago). But with some warning/error messages about dlopen-ing libcrypto. And > pkg wanted to remove mongodb34 and unifi5 whenever I tried to install > something. > For Ronald's suggestion, unifi5(or any port maybe?) can't be built with > openssl-related problem: > > /!\ WARNING /!\ > > You have security/openssl installed but do not have > DEFAULT_VERSIONS+=ssl=openssl set in your make.conf > > pkg-static: unable to open vulnxml file (null): Invalid argument > > However, is the dataset created by mongodb34 compatible with mongodb36? No > lost data after moving to mongodb36? > > > 2018년 11월 25일 (일) 오후 4:34, Ronald Klop 님이 작성: > > > On Sat, 24 Nov 2018 04:59:50 +0100, Andrey Pevnev > > wrote: > > > > > Or you can install mongodb36 and it would probably work. Works fine for > > > me (I know Ubnt says they want 3.4). > > > > I asked for this in a PR. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233482 > > > > Regards, > > Ronald. > > > > > > > > > >> On Nov 23, 2018, at 11:35 AM, Kurt Jaeger wrote: > > >> > > >> Hi! > > >> > > >>> After upgrading my FreeBSD machine to 12.0-RC1, unifi5 can't be > > >>> installed > > >>> due to mongodb34 build failure. It looks like caused by openssl change. > > >>> Is there anything in progress? > > >> > > >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230698 > > >> > > >> has a patch. If you find the time, can you build and test it ? > > >> > > >> -- > > >> p...@freebsd.org +49 171 3101372 2 years to go ! > > >> ___ > > >> 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" > > ___ > > 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" -- Mathieu Arnold signature.asc Description: PGP signature
Re: ssl=base
On Sun, Nov 25, 2018 at 03:12:43PM +0700, Eugene Grosbein wrote:
> Hi!
>
> As maintainer of the net/mpd5 port, I wonder why our ports/Mk/Uses/ssl.mk
> prevents building this port using FreeBSD 12 and base system libssl
> when libressl is installed?
>
> While building with ssl=base, the port itself does not include headers
> from ${LOCALBASE}/include and it does not include ${LOCALBASE}/lib to search
> path for linking stage.
>
> I see no way to override noted (wrong) check-depends restriction, and that's
> not good.
Because you either use OpenSSL from the base system, or you install an
*SSL variant from ports and use it. You cannot mix half of the stuff
from the base system and half of the stuff from a port version of *SSL.
--
Mathieu Arnold
signature.asc
Description: PGP signature
Re: r479405 ("PLIST_SUB must be appended to") missing lang/gcc8 ?
Hi,
On Sun, Nov 18, 2018 at 07:21:08AM -0700, Gerald Pfeifer wrote:
> Hi Mat,
>
> I noticed that
>
> r479405 | mat | 2018-09-10 13:11:23 + (Mo., 10 Sep. 2018) | 9 lines
>
> After an include, PLIST_SUB must be appended to, not overwritten.
>
> If it is overwritten, many values will be clobbered, and
> pain will ensue.
>
> PR: 230864
> Submitted by: mat
> exp-runs by:antoine
>
> did not cover lang/gcc8 (nor lang/gcc9-devel).
>
>
> OTOH `diff lang/gcc7/Makefile lang/gcc8` shows this as nearly the only
> difference between the two versions, short of version-specific lines.
>
>
> Does this look like an small omission I should address? I have this
> locally and tested, but figured I'd double check before committing.
Yes, it should be fixed, thanks for finding It. I'm not sure why I did
not picked those two ports at the time, maybe I was working on the patch
for too long and missed the ports being added.
> Gerald
>
>
> Index: lang/gcc8/Makefile
> ===
> --- lang/gcc8/Makefile(revision 485224)
> +++ lang/gcc8/Makefile(working copy)
> @@ -95,7 +95,7 @@
> --with-system-zlib
> MAKE_ARGS+= MAKEINFOFLAGS="--no-split"
> USE_LDCONFIG=${TARGLIB}
> -PLIST_SUB= GCC_VERSION=${GCC_VERSION} \
> +PLIST_SUB+= GCC_VERSION=${GCC_VERSION} \
> GNU_HOST=${CONFIGURE_TARGET} \
> SUFFIX=${SUFFIX}
> INFO=gcc${SUFFIX}/cpp \
> Index: lang/gcc9-devel/Makefile
> ===
> --- lang/gcc9-devel/Makefile (revision 485224)
> +++ lang/gcc9-devel/Makefile (working copy)
> @@ -97,7 +97,7 @@
> --with-system-zlib
> MAKE_ARGS+= MAKEINFOFLAGS="--no-split"
> USE_LDCONFIG=${TARGLIB}
> -PLIST_SUB= GCC_VERSION=${GCC_VERSION} \
> +PLIST_SUB+= GCC_VERSION=${GCC_VERSION} \
> GNU_HOST=${CONFIGURE_TARGET} \
> SUFFIX=${SUFFIX}
> INFO=gcc${SUFFIX}/cpp \
>
--
Mathieu Arnold
signature.asc
Description: PGP signature
Re: BIND update gone bad
On Wed, Nov 14, 2018 at 10:44:49AM +0100, Andrea Venturoli wrote: > On 11/14/18 7:35 AM, Matthias Fechner wrote: > > > maybe an OPTION problem. > > Make sure you disable the GOST option (in bind and openssl), I faced a > > similar problem, but I thing this option was removed, but I think it is > > a try worth. > > Hello. > > Just to say I've been hit by the same problem: fortunately I was building > from ports, so I could easily move to the previous SVN revision, which fixed > this. > > I don't find any GOST option in the latest dns/bind911; I'm using > GSS_API_NONE and SSL is turned on. > Also, I'm using openssl from base, so I've got no GOST option there either. > > Maybe a bug report should be filled about this? Fixed in r484916. -- Mathieu Arnold signature.asc Description: PGP signature
Re: BIND update gone bad
On Tue, Nov 13, 2018 at 09:15:12PM -0500, Kevin P. Neal wrote: > Before anyone panics on my behalf, I did a zfs rollback to avoid the new > named problem. But something needs to be fixed somewhere. > > I just did an svn update of /usr/ports, ran poudriere and then did pkg > upgrade, which includes updates to bind911-9.11.5. My base system is > 11.2-p4. When I restarted named it failed to start. When run "by hand" as > shown below it prints errors that may help someone solve this issue: > > > [root@gunsight1 ~]# /usr/local/sbin/named -g -t /var/named -u bind -c > /etc/namedb/named.conf > 13-Nov-2018 21:00:30.955 starting BIND 9.11.5 (Extended Support Version) > > 13-Nov-2018 21:00:30.955 running on FreeBSD amd64 11.2-RELEASE-p4 FreeBSD > 11.2-RELEASE-p4 #0: Thu Sep 27 08:16:24 UTC 2018 > r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC > 13-Nov-2018 21:00:30.955 built with '--localstatedir=/var' > '--disable-linux-caps' '--disable-symtable' '--with-randomdev=/dev/random' > '--with-libxml2=/usr/local' '--with-readline=-L/usr/local/lib -ledit' > '--with-dlopen=yes' '--sysconfdir=/usr/local/etc/namedb' > '--with-dlz-filesystem=yes' '--disable-dnstap' '--disable-filter-' > '--disable-fixed-rrset' '--without-geoip' '--without-gssapi' > '--with-libidn2=/usr/local' '--enable-ipv6' '--with-libjson=/usr/local' > '--disable-largefile' '--with-lmdb=/usr/local' '--disable-native-pkcs11' > '--with-python=/usr/local/bin/python2.7' '--disable-querytrace' > '--enable-rpz-nsdname' '--enable-rpz-nsip' 'STD_CDEFINES=-DDIG_SIGCHASE=1' > '--with-openssl=/usr' '--enable-threads' '--with-tuning=default' > '--prefix=/usr/local' '--mandir=/usr/local/man' > '--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd11.2' > 'build_alias=amd64-portbld-freebsd11.2' 'CC=cc' 'CFLAGS=-O2 -pipe > -DLIBICONV_PLUG -fstack-protector -isystem /usr/local/include -fno-stri > ct-aliasing ' 'LDFLAGS= -fstack-protector ' 'LIBS=-L/usr/local/lib' > 'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp' > 13-Nov-2018 21:00:30.955 running as: named -g -t /var/named -u bind -c > /etc/namedb/named.conf > 13-Nov-2018 21:00:30.955 compiled by CLANG 4.2.1 Compatible FreeBSD Clang > 6.0.0 (tags/RELEASE_600/final 326565) > 13-Nov-2018 21:00:30.955 compiled with OpenSSL version: OpenSSL > 1.0.2o-freebsd 27 Mar 2018 > 13-Nov-2018 21:00:30.955 linked to OpenSSL version: OpenSSL 1.0.2o-freebsd > 27 Mar 2018 > 13-Nov-2018 21:00:30.955 compiled with libxml2 version: 2.9.7 > 13-Nov-2018 21:00:30.955 linked to libxml2 version: 20907 > 13-Nov-2018 21:00:30.955 compiled with libjson-c version: 0.13.1 > 13-Nov-2018 21:00:30.955 linked to libjson-c version: 0.13.1 > 13-Nov-2018 21:00:30.955 compiled with zlib version: 1.2.11 > 13-Nov-2018 21:00:30.955 linked to zlib version: 1.2.11 > 13-Nov-2018 21:00:30.955 threads support is enabled > 13-Nov-2018 21:00:30.955 > 13-Nov-2018 21:00:30.955 BIND 9 is maintained by Internet Systems Consortium, > 13-Nov-2018 21:00:30.955 Inc. (ISC), a non-profit 501(c)(3) public-benefit > 13-Nov-2018 21:00:30.955 corporation. Support and training for BIND 9 are > 13-Nov-2018 21:00:30.955 available at https://www.isc.org/support > 13-Nov-2018 21:00:30.955 > 13-Nov-2018 21:00:30.955 found 16 CPUs, using 16 worker threads > 13-Nov-2018 21:00:30.955 using 15 UDP listeners per interface > 13-Nov-2018 21:00:30.956 using up to 4096 sockets > 13-Nov-2018 21:00:30.959 ENGINE_by_id failed (crypto failure) > 13-Nov-2018 21:00:30.959 error:25066067:DSO support routines:DLFCN_LOAD:could > not load the shared > library:/usr/src/crypto/openssl/crypto/dso/dso_dlfcn.c:187:filename(/usr/lib/engines/libgost.so): > Cannot open "/usr/lib/engines/libgost.so" > 13-Nov-2018 21:00:30.959 error:25070067:DSO support routines:DSO_load:could > not load the shared library:/usr/src/crypto/openssl/crypto/dso/dso_lib.c:233: > 13-Nov-2018 21:00:30.959 error:260B6084:engine routines:DYNAMIC_LOAD:dso not > found:/usr/src/crypto/openssl/crypto/engine/eng_dyn.c:467: > 13-Nov-2018 21:00:30.959 error:2606A074:engine routines:ENGINE_by_id:no such > engine:/usr/src/crypto/openssl/crypto/engine/eng_list.c:390:id=gost > 13-Nov-2018 21:00:30.959 initializing DST: crypto failure > 13-Nov-2018 21:00:30.959 exiting (due to fatal error) M, I removed the GOST option from 9.11 because it was removed in later version and never used, but it seems BIND9 is picking up the fact that base OpenSSL still has GOST support on 11. I'll fix. -- Mathieu Arnold signature.asc Description: PGP signature
Re: USE_PACKAGE_DEPENDS failed at meson-0.48.0
On Fri, Nov 09, 2018 at 07:30:41AM +0900, KIRIYAMA Kazuhiko wrote: > Hi all, > > At Wed, 07 Nov 2018 08:05:46 +0900, > 私 wrote: > > > > Hi lists, > > > > I've upgraded to 13.0-CURRENT and ports (revision 482838) > > then build all stuffs but failed at installing > > meson-0.48.0.txz package: > > > > ===> atk-2.28.1 depends on executable: g-ir-scanner - found > > ===> Returning to build of atk-2.28.1 > > ===> atk-2.28.1 depends on executable: meson - not found > > ===> Installing existing package /var/ports/packages/All/meson-0.48.0.txz > > Installing meson-0.48.0... > > `-- Installing ninja-1.8.2,2... > > `-- Extracting ninja-1.8.2,2: ... done > > pkg-static: Missing dependency 'py36-setuptools' > > > > Failed to install the following 1 package(s): > > /var/ports/packages/All/meson-0.48.0.txz > > *** Error code 70 > > I've built py36-setuptools with python-3.6: > > # make DEFAULT_VERSIONS='python=3.6' PYTHON_PKGNAMEPREFIX='py36-' -C > /var/ports/jdtpkx/devel/py-setuptools > > and then trying to build ohter package (at-spi2-core-2.28.0): > > ===> at-spi2-core-2.28.0 depends on executable: g-ir-scanner - found > ===> Returning to build of at-spi2-core-2.28.0 > ===> at-spi2-core-2.28.0 depends on executable: meson - not found > ===> Installing existing package /var/ports/packages/All/meson-0.48.0.txz > Installing meson-0.48.0... > `-- Installing py36-setuptools-40.4.3... > pkg-static: py36-setuptools-40.4.3 conflicts with py27-setuptools-40.4.3 > (installs files into the sa > me place). Problematic file: /usr/local/bin/easy_install You cannot have both py27-setuptools and py36-setuptools built with two different default python versions. The default python version is UNIQUE and MUST NOT be changed mid flight. If you want the Python 3.6 flavor if that port, you run: make FLAVOR=py36 -C /var/ports/jdtpkx/devel/py-setuptools -- Mathieu Arnold signature.asc Description: PGP signature
Re: HOWTO automatically follow PHP default versions switches?
On Sun, Nov 04, 2018 at 05:40:35PM +0100, Michael Grimm wrote:
> Hi,
>
> I am using poudriere for compiling ports, and I do have the following setting
> in my corresponding make.conf:
>
> DEFAULT_VERSIONS+=php=72
>
> In addition I do have two local meta-ports with PHP definitions installed in
> order to provide PHP and PHP depending ports in service jails:
>
> PORTNAME= local-www
> CATEGORIES= local
> [snip]
> RUN_DEPENDS+= roundcube-php72>0:${PORTSDIR}/mail/roundcube@php72
> RUN_DEPENDS+=
> roundcube-sieverules-php72>0:${PORTSDIR}/mail/roundcube-sieverules@php72
>
> and
>
> PORTNAME= local-www2
> CATEGORIES= local
> [snip]
> RUN_DEPENDS+= php72-extensions>0:${PORTSDIR}/lang/php72-extensions
>
>
> Question: Is there a way to automatically follow default version switches of
> PHP without having to touch those definitions above?
>
> I cannot find something like meta-ports of lang/php-default and
> land/php-extensions-default, thus I do believe that it cannot be done.
> Correct?
It would not be appropriate for a port inside the ports tree, but you
can simply replace all occurrences of 72 by ${PHP_DEFAULT}.
--
Mathieu Arnold
signature.asc
Description: PGP signature
Re: options DOCS + EXAMPLES
On Fri, Nov 02, 2018 at 11:33:11AM +0100, Harry Schmalzbauer wrote: > Am 02.11.2018 um 11:24 schrieb Mathieu Arnold: > > On Fri, Nov 02, 2018 at 10:49:52AM +0100, Harry Schmalzbauer wrote: > > > Hello, > > > > > > found out that the need to define DOCS and EXAMPLES in OPTIONS_DEFINE was > > > made mandatory some time ago, which ports-mgmt/portlint isn't aware about > > > yet (found https://reviews.freebsd.org/D13036). > > > > > > I intentionally haven't defined it, because I want to make use of the > > > bsd.ports.mk handling of PORTDOCS and PORTEXAMPLES, but don't want to spam > > > the UI. EXAMPLES and DOCS shall stay mandatory for my port, as long as > > > the > > > user changes the corresponding defaults. > > > > > > How do I hide the user selection for EXAMPLES and DOCS after the change > > > (which I wasn't able to find by reading commit logs)? > > > > I am not sure what you are asking. > > > > To be able to use PORTDOCS or PORTEXAMPLES, you must define a DOCS or an > > EXAMPLES option. > > > > The users must be allowed to choose if they want documentation or > > examples to be installed. If you personnaly do not want the options > > dialog to show up when you build ports, you can set BATCH in your > > environment. > > Thank you for your answer. > In my case, I have additional options, so I can't use BATCH. > Please see my opinion about the DOCS/EXAMPLES selection in the reply to > myself, where I reference the commit introducing this change and where I If you want to hide them, you can always set in your make.conf: OPTIONS_SLAVE= DOCS EXAMPLES (or OPTIONS_EXCLUDE to disable the options.) > explain why in many/most cases, I consider these DOCS/EXAMPLES/NLS options > as spam. Thank you for your input. -- Mathieu Arnold signature.asc Description: PGP signature
Re: FreeBSD Port: firefox-63.0.1,1 multiple errors build
On Thu, Nov 01, 2018 at 08:54:16AM +0100, Stefan Esser wrote: > Am 01.11.18 um 03:38 schrieb Jonathan Chen: > > On Thu, 1 Nov 2018 at 15:35, Montgomery-Smith, Stephen > > wrote: > > [...] > >> I only started using portupgrade recently. I find it rather unreliable. > >> I think the problem is that some ports need to be deleted before they > >> can be built successfully. > > > > For reliable port builds, you need use port builders that use clean > > environments; ie poudriere or synth > > True, but we used to make ports build with a previous version installed, > whenever possible. The problems are generally caused by the build process > picking up include files or libraries from LOCALBASE instead of from the > port's source directory. > > I'd expect a port maintainer to check for easy fixes to such build problems. > > Maybe we should add a port variable that is true if a port conflicts with > earlier versions of itself. That would indicate to port build tools like > portmaster or portupgrade that the old version should be deleted before > starting the build of the new version (and to re-install the old version > if the build of the new one fails). > > E.g.: > > CONFLICTS_WITH_ITSELF=yes You can already set CONFLICT_BUILD= firefox-62.* -- Mathieu Arnold signature.asc Description: PGP signature
Re: libdl.so missing after "pkg upgrade" - firefox, python27...
On Sun, Oct 14, 2018 at 10:13:44PM +, Marcin Cieslak wrote: > Hello, > > during preparations to upgrade 11.1-RELEASE p15 system I got firefox-esr > upgraded to > > Oct 14 22:18:30 radziecki pkg: pkg upgraded: 1.10.5_1 -> 1.10.5_3 > > Oct 14 22:44:51 radziecki pkg: firefox-esr upgraded: 52.8.0,1 -> 60.2.2_1,1 > > Oct 14 22:54:37 radziecki pkg: python27 upgraded: 2.7.14_1 -> 2.7.15 > > However, both python2 and firefox fail due to a missing "libdl.so", > which as I understand got introduced in 12.0. > > Why this happens? What am I doing wrong? 11.1 is no longer supported, you must have set IGNORE_OSVERSION, which is why pkg was happy to break your system at your request. You will need to update to 11.2. -- Mathieu Arnold signature.asc Description: PGP signature
Re: How to exclude some sparse files from LICENSE_DISTFILES
On Sun, Oct 07, 2018 at 12:24:54PM +, Lorenzo Salvadore via freebsd-ports wrote: > Hello. > > I am trying to adopt and update a port which has no license specified. > Almost all files are under public domain, but there are some exceptions, not > all > in the same directories, so I would need to assign to LICENSE_DISTFILES_PD > a value that means "all files are under public domain unless otherwise > stated". > > I thought I could use something like LICENSE_DISTFILES_PD!=$(find ... ), but > I know > that != is discouraged ( > https://lists.freebsd.org/pipermail/freebsd-ports/2008-July/049777.html ). > > Is there some nice solution to this problem? Maybe just not defining > LICENSE_DISTFILES_PD? > Defining an ALMOSTPD license? LICENSE_DISTFILES* is about distfiles, the things in /usr/ports/distfiles, not about the files in the work directory. You can say "this tar.gz is PD, and this tar.gz is GPL" but not more than that. What you want is LICENSE= PD OTHER LICENSE_COMB= multi (Note if the other license is not defined, you have to define it further.) -- Mathieu Arnold signature.asc Description: PGP signature
Re: RUN_DEPENDS and portmaster
On Mon, Sep 10, 2018 at 06:54:19AM +0200, Matthias Fechner wrote:
> Dear all,
>
> I have a questions reagarding the RUN_DEPENDS and at which step
> dependencies should be installed.
Reading Mk/bsd.port.mk at line 5274, run-depends are installed before
do-install runs.
> I'm the maintainer of gitlab-ce port and I added a feature that checks
> in the install target:
> do-install:
> (cd ${WRKSRC} && ${RM} Gemfile.lock && bundle install --local)
> ${FIND} ${WRKSRC} -name '*.orig' -delete
> ...
>
> that all gems available in the system do match the version required by
> the Gemfile.
> Poudriere works fine with this, but portmaster fails.
> Regarding the documentation RUN_DEPENDS packages should be installed
> before the install is happening.
> Is this install related to the do-install target or the installation of
> the package itself?
>
> Is this maybe a problem with portmaster as poudiere handles this correctly?
It's probably a problem with portmaster not doing clean builds.
--
Mathieu Arnold
signature.asc
Description: PGP signature
Re: workflow question: how do you maintain the port in sync with upstream?
On Sun, Aug 19, 2018 at 02:02:42AM -0300, Helen Koike wrote:
>
>
> On 08/14/2018 01:09 PM, blubee blubeeme wrote:
> >
> >
> > On Tue, Aug 14, 2018 at 11:33 PM Mathieu Arnold > <mailto:m...@freebsd.org>> wrote:
> >
> > On Tue, Aug 14, 2018 at 10:41:43PM +0800, blubee blubeeme wrote:
> > > This one is fairly straight forward, you can simply replace that
> > string
> > > with a regex command;
> > > This is an example of running a replace command for strings after
> > the patch
> > > phase of the build;
> > >
> > > post-patch:
> > > @${REINPLACE_CMD} -e 's|for Linux|for FreeBSD|g'
> > ${WRKSRC}/README
> >
> > Patching files in post-patch using sed SHOULD only be used to replace
> > dynamic content, never static content.
>
> I am not sure I understand what dynamic content means here in the
> post-patch (as nothing was built, so no new file should be created). Is
> the replacement used by mail/lbdb wrong?
>
> from mail/lbdb/Makefile
> post-patch:
> ${REINPLACE_CMD} -e 's/sed/gsed/' ${WRKSRC}/m_muttalias.sh.in
>
> is it ok if I do the same?
> It is not clear to me when I can use REINPLACE_CMD in the Makefile and
> when I should do a patch.
Patching using sed in post-patch is for cases when you need to replace a
variable "thing". For example, changing /usr/local into ${PREFIX} or
${LOCALBASE}. Here, for the sed -> gsed change, you should use a patch
file.
--
Mathieu Arnold
signature.asc
Description: PGP signature
Re: workflow question: how do you maintain the port in sync with upstream?
On Tue, Aug 14, 2018 at 10:41:43PM +0800, blubee blubeeme wrote:
> This one is fairly straight forward, you can simply replace that string
> with a regex command;
> This is an example of running a replace command for strings after the patch
> phase of the build;
>
> post-patch:
> @${REINPLACE_CMD} -e 's|for Linux|for FreeBSD|g' ${WRKSRC}/README
Patching files in post-patch using sed SHOULD only be used to replace
dynamic content, never static content.
--
Mathieu Arnold
signature.asc
Description: PGP signature
Re: workflow question: how do you maintain the port in sync with upstream?
On Tue, Aug 14, 2018 at 11:20:59AM -0300, Helen Koike wrote:
>
>
> On 08/14/2018 12:05 AM, Adam Weinberger wrote:
> > On Mon, Aug 13, 2018 at 4:28 PM Helen Koike
> > wrote:
> >>
> >> Hello,
> >>
> >> I am new to the community, I am maintaining two packages and I would
> >> like to check with you if there is a better workflow to do this.
> >>
> >> The upstream project of the port I am maintaining is held in github, and
> >> I also have patches in the /usr/ports/sysutils/myport/file/ folder.
> >>
> >> So I keep a fork of the upstream project with a branch containing a
> >> commit with the patches from the /usr/ports/sysutils/myport/file/.
> >>
> >> Every time I need to update the port to a newer version, I do a git pull
> >> in this branch, then I run a script [1] to re-generate the patches in
> >> the /usr/ports/sysutils/myport/file/
> >>
> >> This script basically generates a file.orig of all modified files in
> >> git, then copy the modified file to WORK_DIR, then run make makepatch.
> >>
> >>
> >> for file in ${CHANGES}; do
> >> mv ${WORK_DIR}/${file} ${WORK_DIR}/${file}.orig
> >> cp ${PROJECT_PATH}/${file} ${WORK_DIR}/${file}
> >> done
> >> make makepatch
> >>
> >>
> >> I would like to know if there is a better way to do this (some tool that
> >> I am not aware of?).
> >
> > IIUC, the process you're describing seems to be rebasing your changes
> > and then generating diffs. You might have an easier time if you just
> > do that: rebase, and then generate a diff (see the last point here)>
> > Your script automates some of the routine Makefile changes, and while
> > there are some tools in ports-mgmt/ that can automate that, we don't
> > generally recommend them.
> >
> > It's common for Makefiles to have a maintainer-update: target that
> > keeps the repetitive update tasks in the Makefile (which also helps
> > the next person to maintain the port).
>
> I didn't know about this target, I'll take a look. Thanks.
>
> >
> > Also, where many files are modified on a continually-changing basis,
> > it's acceptable (though less systemically desirable) to put all your
> > patches into one file. The benefit is that you can generate that one
> > file with a single git diff, and it makes PR submission far, far
> > simpler.
>
> Is there a way to easily transform a git patch to the FreeBSD
> file/*.patch format? Because I use make makepatch, and it will generate
> several patches anyway.
> Once I used "diff -Nur", but it doesn't seem to be the same exact format
> as the one generated by make makepatch.
make makepatch generates cleaned-up patches. So there is no single
command to generate them.
There may be other ways to do what you do.
You said you maintain your local "patch" on github, so instead of adding
the commits to PATCHDIR, you could use PATCH_SITES and PATCHFILES, to
see an example, you could have a look at audio/rubberband
You could also point the port to your fork with the local commits and
use that, it would alleviate the need of patches.
--
Mathieu Arnold
signature.asc
Description: PGP signature
Re: Stage-qa doesn't complain about unstripped elfs in many cases
On Tue, Aug 07, 2018 at 11:29:39PM -0700, Yuri wrote: > For example, on the misc/orange3 port: > > > $ make stage-qa > > > Running Q/A tests (stage-qa) > > [yuri@yv /usr/ports/misc/orange3]$ file > > ./work-py36/stage/usr/local/lib/python3.6/site-packages/Orange/widgets/utils/_grid_density.so > > ./work-py36/stage/usr/local/lib/python3.6/site-packages/Orange/widgets/utils/_grid_density.so: > ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically > linked, not stripped > > > This is because the stage-qa check only looks at .debug sections, and > file(1) looks at more sections. > > My proposed partial fix was rejected: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230371 on the grounds that > it goes against some other commit. So stage-qa doesn't check what it is > supposed to check, and this is somehow ok. > > > Should this stage-qa check be changed to just run file(1) and check if the > output contains "not stripped" in it? What would be the downside of this? I > also don't understand what is the downside of the rejected patch in > bug#230371 that expands the list of sections. I do not understand the point of this email. I already told you that this was going against our policy. The QA check does exactly what it needs to do. -- Mathieu Arnold signature.asc Description: PGP signature
Re: porting project with large files (git-lfs) from github
On Fri, Jul 27, 2018 at 04:31:03PM -0700, Robert wrote: > Thanks, which file hosting is most preferred for large freebsd ports? I do not think we have any preference, or recommendations. Maybe someone else will have an idea. > On 07/27/18 06:22, Mathieu Arnold wrote: > > On Thu, Jul 26, 2018 at 08:42:59AM -0700, Robert wrote: > > > Hi, you can find it here: > > > https://github.com/rayrapetyan/daal/tree/FreeBSD_support > > > All files in e.g. > > > https://github.com/rayrapetyan/daal/tree/FreeBSD_support/externals/mklfpk/lnx/lib/intel64 > > > are "large files" they are fetching normally when doing git pull, but when > > > downloading from "codeload" (this is what FreeBSD does) - they contain > > > just > > > text hashes... > > Well, yeah, like I said, this repository is using git-lfs, which is not > > part of the Git distribution, but an extension. Doing a clone works for > > you because you have it installed, but it does not work for me because I > > do not, It ends up saying: > > > > $ git clone https://github.com/rayrapetyan/daal.git > > Cloning into 'daal'... > > remote: Counting objects: 35068, done. > > remote: Compressing objects: 100% (20/20), done. > > remote: Total 35068 (delta 3), reused 7 (delta 2), pack-reused 35044 > > Receiving objects: 100% (35068/35068), 583.32 MiB | 2.71 MiB/s, done. > > Resolving deltas: 100% (27544/27544), done. > > git-lfs filter-process: git-lfs: not found > > fatal: The remote end hung up unexpectedly > > warning: Clone succeeded, but checkout failed. > > You can inspect what was checked out with 'git status' > > and retry the checkout with 'git checkout -f HEAD' > > > > > > It seems the servers running codeload.g.o do not have git-lfs installed, > > so when they run git-archive(1) you end up with the pointers to the > > large files. > > > > You will have to run git-archive yourself on a machine where git-lfs is > > installed. Something along the lines of: > > > > git archive --format tar.gz --prefix daal- -o daal- > hash>.tar.gz > > > > And then host that file somewhere, and use it for your port. > > > > > On 07/26/18 01:10, Mathieu Arnold wrote: > > > > On Wed, Jul 25, 2018 at 11:04:41PM -0700, Robert wrote: > > > > > Hi, I'm porting something hosted on github using GH_... options in > > > > > Makefile. > > > > > > > > > > FreeBSD tries to fetch a tar.gz archive from > > > > > https://codeload.github.com and > > > > > within such archive there are "large files" which contain something > > > > > like: > > > > > > > > > > version https://git-lfs.github.com/spec/v1 > > > > > oid > > > > > sha256:e8f293258e38e9689cb87ffbb91c3de2c339a6c074c77115ca86d50b5a48bc64 > > > > > size 20413048 > > > > > > > > > > instead of a real data, so build fails. > > > > > > > > > > What's the best way to resolve this issue? > > > > Mmmm, I never tried a repository using git-lfs, I am not surprised > > > > git-archive(1) does not work with it though. What is the project so I > > > > can have a look? > > > > > > > ___ > > > 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" > -- Mathieu Arnold signature.asc Description: PGP signature
Re: porting project with large files (git-lfs) from github
On Thu, Jul 26, 2018 at 08:42:59AM -0700, Robert wrote: > Hi, you can find it here: > https://github.com/rayrapetyan/daal/tree/FreeBSD_support > All files in e.g. > https://github.com/rayrapetyan/daal/tree/FreeBSD_support/externals/mklfpk/lnx/lib/intel64 > are "large files" they are fetching normally when doing git pull, but when > downloading from "codeload" (this is what FreeBSD does) - they contain just > text hashes... Well, yeah, like I said, this repository is using git-lfs, which is not part of the Git distribution, but an extension. Doing a clone works for you because you have it installed, but it does not work for me because I do not, It ends up saying: $ git clone https://github.com/rayrapetyan/daal.git Cloning into 'daal'... remote: Counting objects: 35068, done. remote: Compressing objects: 100% (20/20), done. remote: Total 35068 (delta 3), reused 7 (delta 2), pack-reused 35044 Receiving objects: 100% (35068/35068), 583.32 MiB | 2.71 MiB/s, done. Resolving deltas: 100% (27544/27544), done. git-lfs filter-process: git-lfs: not found fatal: The remote end hung up unexpectedly warning: Clone succeeded, but checkout failed. You can inspect what was checked out with 'git status' and retry the checkout with 'git checkout -f HEAD' It seems the servers running codeload.g.o do not have git-lfs installed, so when they run git-archive(1) you end up with the pointers to the large files. You will have to run git-archive yourself on a machine where git-lfs is installed. Something along the lines of: git archive --format tar.gz --prefix daal- -o daal-.tar.gz And then host that file somewhere, and use it for your port. > On 07/26/18 01:10, Mathieu Arnold wrote: > > On Wed, Jul 25, 2018 at 11:04:41PM -0700, Robert wrote: > > > Hi, I'm porting something hosted on github using GH_... options in > > > Makefile. > > > > > > FreeBSD tries to fetch a tar.gz archive from https://codeload.github.com > > > and > > > within such archive there are "large files" which contain something like: > > > > > > version https://git-lfs.github.com/spec/v1 > > > oid > > > sha256:e8f293258e38e9689cb87ffbb91c3de2c339a6c074c77115ca86d50b5a48bc64 > > > size 20413048 > > > > > > instead of a real data, so build fails. > > > > > > What's the best way to resolve this issue? > > Mmmm, I never tried a repository using git-lfs, I am not surprised > > git-archive(1) does not work with it though. What is the project so I > > can have a look? > > > > ___________ > 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" > -- Mathieu Arnold signature.asc Description: PGP signature
Re: porting project with large files (git-lfs) from github
On Wed, Jul 25, 2018 at 11:04:41PM -0700, Robert wrote: > Hi, I'm porting something hosted on github using GH_... options in Makefile. > > FreeBSD tries to fetch a tar.gz archive from https://codeload.github.com and > within such archive there are "large files" which contain something like: > > version https://git-lfs.github.com/spec/v1 > oid sha256:e8f293258e38e9689cb87ffbb91c3de2c339a6c074c77115ca86d50b5a48bc64 > size 20413048 > > instead of a real data, so build fails. > > What's the best way to resolve this issue? Mmmm, I never tried a repository using git-lfs, I am not surprised git-archive(1) does not work with it though. What is the project so I can have a look? -- Mathieu Arnold signature.asc Description: PGP signature
Re: Automake creation error.. generic or just me?
On Wed, Jul 25, 2018 at 06:38:07PM +0200, Tijl Coosemans wrote: > On Wed, 25 Jul 2018 22:43:05 +0800 Julian Elischer wrote: > > I'm not exactly sure where the error come from.. possibly the find, if > > stderr and stdout are not synchronous. > > > > Has anyone else seen this? or understand it? > > > > > > ===> Building for automake-1.16.1 > > --- doc/aclocal.1 --- > > --- doc/automake.1 --- > > --- bin/automake --- > > > > [...]ls pkg/All > > > > /usr/bin/make install-data-hook > > chmod +x > > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/config.guess' > > chmod +x > > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/config.sub' > > chmod +x > > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/install-sh' > > chmod +x > > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/mdate-sh' > > chmod +x > > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/missing' > > chmod +x > > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/mkinstalldirs' > > chmod +x > > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/ylwrap' > > chmod +x > > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/depcomp' > > chmod +x > > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/compile' > > chmod +x > > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/py-compile' > > chmod +x > > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/ar-lib' > > chmod +x > > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/test-driver' > > chmod +x > > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/tap-driver.sh' > > find: > > /usr/ports/devel/automake/work/stage/usr/local/lib/perl5/site_perl: No > > such file or directory > > > Compressing man pages (compress-man) > > ===> Installing for automake-1.16.1 > > ===> Registering installation for automake-1.16.1 as automatic > > *** Error code 70 > > Possibly caused by > https://svnweb.freebsd.org/ports?view=revision=473539 Does this https://reviews.freebsd.org/D16440 fix the error? -- Mathieu Arnold signature.asc Description: PGP signature
Re: LibreSSL CVE-2018-0732 correction
On Mon, Jul 23, 2018 at 09:14:48PM +0200, Franco Fichtner wrote: > Hi, > > What's the policy for picking these up? Is there the same > kind of maintainer timeout at play here? Feedback welcome. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229037 security/vuxml is maintained by ports-secteam@, so it's their turf. Or the maintainer of the offending port, or the person who did the first commit to vuln.xml file about this entry. In any way, the vuln.xml file is open to anyone to commit, so anyone can do it. -- Mathieu Arnold signature.asc Description: PGP signature
Re: conflicts with packages on install
On Tue, Jul 03, 2018 at 11:29:05AM +0800, blubee blubeeme wrote:
> I'm working on updating a port it currently installs in a
> ${PREFIX}/${PORTNAME}/bin and I'd like to create symlinks t ${PREFIX}/bin
>
> The issue i'm running into is that there's a binary file "terrain" this
> conflicts with graphics/mesa-demos/terrain.
>
> I'm looking for options on resolving this conflict, any suggestions?
Change the name of the file?
--
Mathieu Arnold
signature.asc
Description: PGP signature
