Re: MASTER_SITES=GH? like SF

[Martin Neubauer]

Maybe try

USE_GITHUB= yes

instead.

On 18/01/2021 08:32, 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:

=> 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"





OpenPGP_signature
Description: OpenPGP digital signature

Re: How to fix/patch hardcoded values

[Martin Neubauer]

In that case you might try an appropriate invocation of REINPLACE_CMD in 
post-patch.


On 27/12/2020 22:58, Nuno Teixeira wrote:

Hello I've just submited a new port net/gitup
 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?

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"





OpenPGP_signature
Description: OpenPGP digital signature

print/lilypond-devel: build failure on 13.0-CURRENT

[Martin Neubauer]

Hello all,

A few days ago I started getting reports of build failures for
print/lilypod-devel (e.g.
http://beefy18.nyi.freebsd.org/data/head-amd64-default/p546132_s364744/logs/lilypond-devel-2.21.5.log)


Due to lack of time at the moment I wasn't able to set up a FreeBSD 13
system in order to perform a more thorough analysis of the issue.
However, I think I found a workaround, shown at:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248946

Maybe someone can test the proposed patch on a recent 13.0-CURRENT
system and, hopefully, have it committed to the ports tree.

Best regards,
Martin

-- 
Estimated total size Original: 1004 bytes Compressed: 41.2 KB



signature.asc
Description: OpenPGP digital signature

Re: stable postgresql11 appears to have issues

[Martin Neubauer]

There is already an outstanding issue for quite some time:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244403
There seems not to be a proper fix yet, but at least for me the
workaround mentioned might work for you as well. Just add

DEFAULT_VERSIONS+=llvm=10

to make.conf

Good luck,
Martin

On 26/06/2020 16:04, Donald Wilde wrote:
> In attempting to set up a stable PostgreSQL system, I chose to go back
> to the pg11 series, as there are more tools and ports available to
> support it than there are yet for pg12.
> 
> I ran into an issue, documented in the attachments, that seems to
> point to some quantity that does not include version 8 of the port,
> only 1 - 7. Being a tidy soul, I used make clean first and that
> resulted in a rebuild of LLVM90 as well.
> 
> As I've said in other posts on the FreeBSD lists, I tend to add more
> options than strictly necessary, but it seems to have bit me. LLVM90
> by itself builds, but when I try to build postgresql11-server, I get a
> crash related to something in LLVM:
> 
> ===>  Staging for postgresql11-server-11.8_2
> ===>   postgresql11-server-11.8_2 depends on executable: llvm-config90 - found
> ===>   Generating temporary packing list
> ===> Creating groups.
> ===> Creating users
> [snip]
> cd 
> '/usr/ports/databases/postgresql11-server/work/stage/usr/local/lib/postgresql/bitcode'
> && /usr/local/llvm90/bin/llvm-lto -thinlto -thinlto-action=thinlink -o
> postgres.index.bc postgres/access
> [snip]
> error: can't create module summary index for buffer: Invalid summary
> version 8. Version should be in the range [1-7].
> LLVM ERROR: ThinLink didn't create an index
> gmake: *** [Makefile:220: install-postgres-bitcode] Error 1
> *** Error code 2
> 
> Stop.
> 
> I've started rebuilding my system due to another motheaten issue, but
> I stashed the entire working directories of both llvm90 and
> postgresql11-server in a tarball if needed.
> 
> 
> ___
> 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"
> 

-- 
There are green splotches on the black void on the outside of Willie's
house in one of the lake putt-putt scenes.



signature.asc
Description: OpenPGP digital signature

Re: Port OPTIONS advice

[Martin Neubauer]

On 20/05/2020 20:07, SirDice wrote:
> On Wed, May 20, 2020 at 7:45 PM Martin Neubauer  wrote:
> 
>> How about something like:
>>
>> 
>> OPTIONS_DEFINE_amd64=   JIT
>> OPTIONS_DEFINE_i386=JIT
>>
>> JIT_CONFIGURE_ENABLE=   jit
>> 
>>
>> That's what I had originally. The problem is that JIT_CONFIGURE_ENABLE is
> only parsed on amd64/i386. So it never passes --without-jit to  ./configure
> on other architectures.
> 
>> JIT_CONFIGURE_OFF=  --without-jit
> 
> Haven't tried that yet. But won't that  suffer from the same  effect, only
> getting parsed if on amd64/i386?

Honestly, I haven't tried it myself either, but judging from the usage
of this method (eg. in /usr/ports/biology/mrbayes/Makefile) it at least
seems to do just what you need.

-- 
Shipwrecked by the laughter of the gods.



signature.asc
Description: OpenPGP digital signature

Re: Port OPTIONS advice

[Martin Neubauer]

On 20/05/2020 19:45, Martin Neubauer wrote:
> JIT_CONFIGURE_ENABLE= jit

Sorry,

JIT_CONFIGURE_OFF=  --without-jit



-- 
Mrs. Peacock in the study with a knife.



signature.asc
Description: OpenPGP digital signature

Re: Port OPTIONS advice

[Martin Neubauer]

How about something like:


OPTIONS_DEFINE_amd64=   JIT
OPTIONS_DEFINE_i386=JIT

JIT_CONFIGURE_ENABLE=   jit


On 20/05/2020 19:25, SirDice wrote:
> Hi,
> 
> Some time ago I took over maintainership of fs-uae. Port itself is doing
> great but I wanted to enable the JIT option to experiment with (it builds
> but crashes the application; that's an entirely different issue though). To
> enable it I had added this:
> 
> OPTIONS_DEFINE_i386=JIT
> OPTIONS_DEFINE_amd64=   JIT
> 
> Because the option is only available for i386/amd64 I wanted the port
> option to only show up on x86. Unfortunately the brain-dead ./configure
> script simply assumes --with-jit on all architectures. As these OPTIONS
> were only available on x86, any other ARCH never passes --without-jit to
> ./configure and thus it fails to build.
> 
> The quick solution was to use OPTIONS_DEFINE= JIT and make the port option
> available everywhere.  However, if you try to enable it you will run into
> build failures on Powerpc or ARM for example.
> 
> I could do this:
> -
> OPTIONS_DEFINE_i386=JIT
> OPTIONS_DEFINE_amd64=   JIT
> 
> .include 
> 
> # JIT is not supported on non-x86
> .if ${ARCH} != amd64 && ${ARCH} != i386
> CONFIGURE_ARGS+= --without-jit
> .endif
> 
> 
> Or do something like this:
> 
> OPTIONS_DEFINE= JIT
> 
> .include 
> 
> .if ${PORT_OPTIONS:MJIT}
> ONLY_FOR_ARCHS= i386 amd64
> .endif
> 
> 
> 
> The JIT OPTION is off by default in all cases. But I would  like to only
> have it appear on supported architectures or have some sort of sanity check
> so it doesn't get enabled on unsupported architectures. As I need to update
> the port (new version came out) I would like to fix this OPTION issue too.
> 
> What's a good way to deal with this sort of architecture dependent option?
> 
> Thanks for your time,
> 
> Remko C.
> ___
> 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"
> 
-- 
Any environmental problem can be solved by a good Ice Age.



signature.asc
Description: OpenPGP digital signature

Re: python 2.7 marked as deprecated and EOL while 2.7.18 RC is available

[Martin Neubauer]

On 18/04/2020 11:57, D'Arcy Cain wrote:
> I tried building lilypond with python2.7 removed from USES but its
> configure script failed due to Python < 3.0.  I couldn't find any
> discussion about upgrading the version of Python but WikipediA says that
> it has 120,000 lines Python code.  As far as I can tell there is nothing
> as good as Lilypond for engraving music.  It would be quite a blow to
> musicians if that was removed.
I think I can reassure you that lilypond isn't going away (at least not
because of the Python 2 vs. 3 issue.) Currently I'm maintaining
lilypond-devel and have already created a patch updating to 2.21.0 not
depending on Python 2 any more. I've already planned to take care of
updating lilypond to 2.20.0 as soon as I'll be able to. Maybe that would
mean backporting the upstream changeset switching to Python 3. (The
change was done well before the 2.20.0 release, but it seems to only be
present in the 2.21 branch. Luckily the changes are fairly trivial, but
because so many files are touched still would mean quite some legwork.)

Regards,
Martin

-- 
X is a large contribution.



signature.asc
Description: OpenPGP digital signature

Re: ports-mgmt/poudriere-devel does not follow options

[Martin Neubauer]

On 01/03/2020 10:06, Miroslav Lachman wrote:
> I migrated from "poudriere" to "poudriere-devel" about week ago that's
> when I noticed this problem. That's why I suspect poudriere-devel.
> Everything worked for me for years with poudriere.
> 
> I search my command history and I never called poudriere options with -j
> 
> It was like
> poudriere options -z php71m103 -p default -c mail/dovecot
> graphics/py-pillow www/nginx
> poudriere options -z php71m103 -p default -c ports-mgmt/poudriere-devel
> poudriere options -z php71m103 -p default -f
> /usr/local/etc/poudriere.d/pkglists/php71m103
> poudriere bulk -j 11_3_amd64 -z php71m103 -p default -c -f
> /usr/local/etc/poudriere.d/pkglists/php71m103
> 
> I don't know when / what command exactly created
> 11_3_amd64-default-php71m103-options in disk.
I admit that's looking odd, but even if the exact command that led to
the presence of that directory can't be reconstructed, it should at
least be possible to gather some information regarding the time that
happened. "ls -lU" should give at least some starting point.



signature.asc
Description: OpenPGP digital signature

Re: ports-mgmt/poudriere-devel does not follow options

[Martin Neubauer]

On 01/03/2020 00:29, Miroslav Lachman wrote:
> Martin Neubauer wrote on 2020/02/29 23:44:
>>
>>
>> On 28/02/2020 17:20, Miroslav Lachman wrote:
>>> I am using Poudriere for a long time. I switched to poudriere-devel few
>>> days ago because I want to test ports overlay.
>>> I run
>>>     poudriere options -z php71m103 -p default -f
>>> /usr/local/etc/poudriere.d/pkglists/php71m103
>>> just to be sure everything is set. No options dialog appeared because
>>> all options was set few week ago on regular update.
>>>
>>> Now I am running
>>>     poudriere bulk -j 11_3_amd64 -z php71m103 -p default -c -f
>>> /usr/local/etc/poudriere.d/pkglists/php71m103
>>
>> [snip]
>>
>>> I tried to find what is going on and I found that all ports are built
>>> with default options instead of what I have stored in
>>> /usr/local/etc/poudriere.d/default-php71m103-options
>>>
>>> Just a wild guess... "poudriere options" read options from
>>> default-php71m103-options but "poudriere bulk" are trying to read
>>> 11_3_amd64-default-php71m103-options.
>>> Is it possible?
>> It isn't such a wild guess at all, considering that documentation does
>> state that the most specific set of options gets used with higher
>> priority. More details at:
> 
> But I am talking about "poudriere options" taking different saved
> options than "poudriere bulk".
> The "poudriere options" does not show me any dialog because they are all
> set in "default-php71m103-options" and then "poudriere bulk" ignore
> settings in "default-php71m103-options".
> That is a bug from my point of view. Both commands should work with the
> same set of stored options. Otherwise if "poudriere bulk" wants options
> from "11_3_amd64-default-php71m103-options" I am not able to set those
> options by calling "poudriere options".
If the issued command lines were in fact those from your earlier mail,
then you did in fact request two different option sets. If you also add
"-j 11_3_amd64" to the "poudriere options" call, you should access the
same option set the "poudriere bulk" run did.

Good luck,
Martin



signature.asc
Description: OpenPGP digital signature

Re: ports-mgmt/poudriere-devel does not follow options

[Martin Neubauer]

On 28/02/2020 17:20, Miroslav Lachman wrote:
> I am using Poudriere for a long time. I switched to poudriere-devel few
> days ago because I want to test ports overlay.
> I run
>    poudriere options -z php71m103 -p default -f
> /usr/local/etc/poudriere.d/pkglists/php71m103
> just to be sure everything is set. No options dialog appeared because
> all options was set few week ago on regular update.
> 
> Now I am running
>    poudriere bulk -j 11_3_amd64 -z php71m103 -p default -c -f
> /usr/local/etc/poudriere.d/pkglists/php71m103

[snip]

> I tried to find what is going on and I found that all ports are built
> with default options instead of what I have stored in
> /usr/local/etc/poudriere.d/default-php71m103-options
> 
> Just a wild guess... "poudriere options" read options from
> default-php71m103-options but "poudriere bulk" are trying to read
> 11_3_amd64-default-php71m103-options.
> Is it possible?
It isn't such a wild guess at all, considering that documentation does
state that the most specific set of options gets used with higher
priority. More details at:
https://github.com/freebsd/poudriere/wiki/poudriere.8-devel#custom--build-options





signature.asc
Description: OpenPGP digital signature

Re: [Bug 215076] print/lilypond-devel: update to 2.19.52

[Martin Neubauer]

Eww, forgot to upload the patch.

On 05/12/2016 19:02, bugzilla-nore...@freebsd.org wrote:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215076
> 
> Bug ID: 215076
>Summary: print/lilypond-devel: update to 2.19.52
>Product: Ports & Packages
>Version: Latest
>   Hardware: Any
> OS: Any
> Status: New
>   Severity: Affects Some People
>   Priority: ---
>  Component: Individual Port(s)
>   Assignee: freebsd-ports-b...@freebsd.org
>   Reporter: m...@gmx.net
> CC: freebsd-ports@FreeBSD.org
>  Flags: maintainer-feedback+
> 
> Update print/lilypond-devel to latest version
> 

-- 
The introduction of a new kind of music should be shunned as
imperiling the whole state.



signature.asc
Description: OpenPGP digital signature

Request for commit

[Martin Neubauer]

Hello everyone,

If there is a committer out there with a little time to spare, I would
be grateful if they would take a look here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213656

Best regards,
Martin

-- 
All of the above.



signature.asc
Description: OpenPGP digital signature

Re: Maintainership for print/lilypond-devel

[Martin Neubauer]

Hi everyone,

I have fixed a few embarrassing issues with the previous path and am now
sufficiently confident about it to submit e PR:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212435

Best regards,
Martin

On 05/09/2016 14:51, Martin Neubauer wrote:
> Hi everyone,
> 
> I would like to offer maintaining the print/lilypond-devel port.
> Attached you'll find a patch bringing the port to the current version
> 2.19.47. A few more tests might still be necessary, but as the port is
> already marked for deletion I wanted to put the work I've done into the
> open as soon as possible. A short summary of the patch:
> 
> - Update to version 2.19.47
> 
> - Import fix for pkgconfig detection in configure script from print/lilypond
> 
> - Use gcc for building as newer versions (2.19.42+) don't build with
> clang anymore
> 
> - Re-generate the patches with `make makepatch` to make portlint happy
> and bring the patches back in sync with the patched files.
> 
> Best regards,
> Martin
> 
-- 
Frodo nearly didn't escape, but with one less finger.



signature.asc
Description: OpenPGP digital signature

Maintainership for print/lilypond-devel

[Martin Neubauer]

Hi everyone,

I would like to offer maintaining the print/lilypond-devel port.
Attached you'll find a patch bringing the port to the current version
2.19.47. A few more tests might still be necessary, but as the port is
already marked for deletion I wanted to put the work I've done into the
open as soon as possible. A short summary of the patch:

- Update to version 2.19.47

- Import fix for pkgconfig detection in configure script from print/lilypond

- Use gcc for building as newer versions (2.19.42+) don't build with
clang anymore

- Re-generate the patches with `make makepatch` to make portlint happy
and bring the patches back in sync with the patched files.

Best regards,
Martin

-- 
Press the # key for more options.
diff -Nur lilypond-devel.orig/distinfo lilypond-devel/distinfo
--- lilypond-devel.orig/distinfo2016-09-01 22:42:51.129658000 +0200
+++ lilypond-devel/distinfo 2016-09-05 14:25:54.362645000 +0200
@@ -1,2 +1,3 @@
-SHA256 (lilypond-2.19.11.tar.gz) = 
5245aba230ccc0a217d25079eca44cea637c6897d99ff094f4145cacef70bbb0
-SIZE (lilypond-2.19.11.tar.gz) = 16304635
+TIMESTAMP = 1472857204
+SHA256 (lilypond-2.19.47.tar.gz) = 
842312813a9144b6b54a33f13fb19addbfc779d7bbfe3b2075be1235287de08c
+SIZE (lilypond-2.19.47.tar.gz) = 16926783
diff -Nur lilypond-devel.orig/files/patch-config.make.in 
lilypond-devel/files/patch-config.make.in
--- lilypond-devel.orig/files/patch-config.make.in  2016-09-01 
22:40:20.018546000 +0200
+++ lilypond-devel/files/patch-config.make.in   2016-09-05 14:25:54.363283000 
+0200
@@ -1,8 +1,8 @@
 config.make.in.origSun Apr 11 10:26:32 2004
-+++ config.make.in Sun Apr 11 10:26:46 2004
-@@ -41,7 +41,7 @@
+--- config.make.in.orig2016-08-30 10:23:53 UTC
 config.make.in
+@@ -67,7 +67,7 @@ sharedstatedir = @sharedstatedir@
+ stepmake = @stepmake@
  
- # move out of config.make.in?
  package_datadir = $(datadir)/$(package)
 -package_infodir = $(infodir)/$(package)
 +package_infodir = $(infodir)
diff -Nur lilypond-devel.orig/files/patch-configure 
lilypond-devel/files/patch-configure
--- lilypond-devel.orig/files/patch-configure   1970-01-01 01:00:00.0 
+0100
+++ lilypond-devel/files/patch-configure2016-09-05 14:25:54.36350 
+0200
@@ -0,0 +1,78 @@
+--- configure.orig 2016-08-30 10:23:53 UTC
 configure
+@@ -11412,74 +11412,7 @@ test -n "$PKG_CONFIG" || PKG_CONFIG="no"
+ 
+ if test $? -eq 0 -a -n "0.9.0"; then
+ 
+-r="`eval echo '$'"PKG_CONFIG"`"
+-{ $as_echo "$as_me:$LINENO: checking $r version" >&5
+-$as_echo_n "checking $r version... " >&6; }
+-exe=`
+-## which doesn't work in ash, if /usr/bin/which isn't installed
+-## type -p doesn't work in ash
+-## command -v doesn't work in zsh
+-## command -v "$r" 2>&1
+-## this test should work in ash, bash, pdksh (ksh), zsh
+-type -p $r 2>/dev/null | tail -n 1 | awk '{print $NF}'
+-`
+-if test -n ""; then
+-ver=""
+-else
+-ver=`
+-## "$exe" --version 2>&1 | grep -v '^$' | head -n 1 | awk '{print $NF}'
+-##
+-## ARG.
+-## Workaround for broken Debian gcc version string:
+-## gcc (GCC) 3.1.1 20020606 (Debian prerelease)
+-##
+-## -V: Workaround for python
+-
+-#dnl
+-
+-## Assume and hunt for dotted version multiplet.
+-## use eval trickery, because we cannot use multi-level $() instead of ``
+-## for compatibility reasons.
+-
+-## grab the first version number in  --version output.
+-eval _ver=\"\`("$exe" --version || "$exe" -V) 2>&1 |
+-  grep -E '(^| )[0-9][0-9]*\.[0-9]' |
+-  head -n 1 |
+-  tr ' ' '\n' |
+-  sed 's/\([0-9][0-9]*\.[0-9][0-9.]*\).*/\1/g' |
+-  grep -E '(^| )[0-9][0-9]*\.[0-9]' |
+-  head -n 1\`\"
+-
+-if test -z "$_ver"; then
+-## If empty, try date [fontforge]
+-eval _ver=\"\`("$exe" --version || "$exe" -V) 2>&1 \
+-  | grep '\(^\|[^0-9a-f]\)[0-9]\{6,8\}\([^0-9a-f]\|$\)' \
+-  | head -n 1 \
+-  | sed -e 's/^[^.0-9]*//' -e 's/[^.0-9]*$//'\`\"
+-fi
+-echo "$_ver"
+-#dnl
+-`
+-fi
+-num=`
+-echo "$ver" | awk -F. '
+-{
+-  if ($3) {three = $3}
+-  else {three = 0}
+-}
+-{printf "%.0f\n", $1*100 + $2*1000 + three}'
+-`
+-req=`
+-echo "0.9.0" | awk -F. '
+-{
+-  if ($3) {three = $3}
+-  else {three = 0}
+-}
+-{printf "%.0f\n", $1*100 + $2*1000 + three}'
+-`
+-{ $as_echo "$as_me:$LINENO: result: $ver" >&5
+-$as_echo "$ver" >&6; }
+-if test "$num" -lt "$req"; then
++if $exe --atleast-pkgconfig-version 0.9.0; then
+ 
+ eval "REQUIRED"=\"`eval echo \"'$'REQUIRED\" \""$r >= 0.9.0 (installed: 
$ver)"\"`\"
+ 
diff -Nur lilypond-devel.orig/files/patch-Documentation_GNUmakefile 
lilypond-devel/files/patch-Documentation_GNUmakefile
--- lilypond-devel.orig/files/patch-Documentation_GNUmakefile   2016-09-01 
22:39:37.625401000 +0200
+++