Committer needed for #224904 - x11-toolkits/qwt6: Add qt flavors and update all dependent ports

[L.Bartoletti]

Hi,

Can someone check and commit this PR 
 ?

Thanks in advance.

Regards.

Loï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"

Re: Committer needed for #221810 - converters/osm2pgrouting, Import OSM data into pgRouting Database

[L.Bartoletti]

Thanks yuri@ !


On 12.01.2018 06:33, L.Bartoletti wrote:

Hi,

Can someone check and commit this PR 
?


Thanks in advance.

Regards.

Loï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"


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Mailman has mismatched checksums

[Matthias Andree]

Am January 16, 2018 9:00:09 PM UTC schrieb Dave Horsfall :
>When trying to get Mailman going (and seeing what looked like several 
>updates in quick succession), I completely cleaned it out, waited a bit
>
>for any more updates, installed the package, waited a bit for any more 
>updates, and I was hoping that this would go away:
>
> Checking for packages with mismatched checksums:
> mailman-2.1.25: /usr/local/mailman/Mailman/Defaults.py
> mailman-2.1.25: /usr/local/mailman/Mailman/Defaults.pyc
>
>No configuration whatsoever was done; I merely installed the package
>and 
>waited for any more updates to arrive.
>
>So, what can I do about it?
>
>-- 
>Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
>suffer."
>___
>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"

Greetings, 

There is nothing you could do for now; the postinstall script patches the 
hostname into Defaults.py, which is needed to not place the build host's 
hostname as mail or web server, and as a consequence of the patch, the 
complaint will remain. I need to find another way for writing down the install 
host's name. 

Sorry about that checksum nuisance.

Regards,
Matthias (mail/mailman port and package maintainer) 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Mailman has mismatched checksums

[Dave Horsfall]

On Tue, 16 Jan 2018, Ted Hatfield wrote:

My best guess is that some time in the past I changed the variables 
DEFAULT_EMAIL_HOST and DEFAULT_URL_HOST in the Defaults.py file rather 
than mm_cfg.py, and the files Defaults.py and Defaults.pyc didn't change 
when I did a pkg update.


After further investigation (a complete removal of Mailman, updated the 
"locate" database, and confirmed that not a skerrick of Mailman was left 
on the server), I did another installation of the package (not the port), 
and stood back and waited for the overnight check.


And...

Checking for packages with mismatched checksums:
mailman-2.1.25: /usr/local/mailman/Mailman/Defaults.py
mailman-2.1.25: /usr/local/mailman/Mailman/Defaults.pyc

Suspicious (since *I* hadn't touched anything), I looked further, and 
found:


DEFAULT_EMAIL_HOST = 'aneurin.horsfall.org'
DEFAULT_URL_HOST = 'aneurin.horsfall.org'
DEFAULT_URL_PATTERN = 'http://%s/mailman/'

In other words, the installation gratuitously changes a file that by its 
own admission should not be changed, and then the system has the hide to 
complain that it has been changed i.e. it installs itself as 
pre-corrupted...


I'm surprised that this breakage hasn't been noted until now.

--
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Help with versioning scheme

[Martin Waschbüsch]

Hi Adam,

> Am 17.01.2018 um 19:49 schrieb Adam Weinberger :
> 
> In general, I recommend against doing clever things. It's too easy to 
> outsmart yourself.
> 
> It's not terribly difficult to edit the plist and increase a number. I 
> recommend clear over clever every time.
> 
> # Adam

Yeah, I guess that is the sanest approach. Thanks!
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Help with versioning scheme

[Freddie Cash]

On Wed, Jan 17, 2018 at 10:40 AM, Martin Waschbüsch 
wrote:

> Thanks, Freddie,
>
> Am 17.01.2018 um 19:35 schrieb Freddie Cash :
>
> On Wed, Jan 17, 2018 at 10:29 AM, Martin Waschbüsch  > wrote:
>
>> Hi Adam,
>> > Am 17.01.2018 um 19:19 schrieb Adam Weinberger :
>> > Hi Martin,
>> >
>> > You don't want to use the upstream version to represent PORTREVISION.
>> PORTREVISION is for when you need to force rebuilds of the port itself, and
>> so tying it to upstream would make it impossible to bump it ourselves.
>> >
>> > Why do you need to ignore the fourth digit? It's perfectly valid for
>> our purposes.
>>
>> So far, I had (because it coincided with their version number) used it to
>> provide SO_VER. But that breaks now:
>>
>> ---
>> # Created by: adamw
>> # $FreeBSD: head/archivers/liblz4/Makefile 448415 2017-08-20 12:30:25Z
>> sunpoet $
>>
>> PORTNAME=   lz4
>> PORTVERSION=1.8.1
>> DISTVERSIONPREFIX=  v
>> PORTEPOCH=  1
>> CATEGORIES= archivers
>> PKGNAMEPREFIX=  lib
>>
>> MAINTAINER= mar...@waschbuesch.de
>> COMMENT=LZ4 compression library, lossless and very fast
>>
>> LICENSE=BSD2CLAUSE GPLv2
>> LICENSE_COMB=   multi
>>
>> USES=   gmake pathfix pkgconfig
>> USE_GITHUB= yes
>> USE_LDCONFIG=   yes
>> #PATHFIX_MAKEFILEIN=Makefile
>>
>> ALL_TARGET= default # don't remove this
>> SO_VER= ${PORTVERSION}
>> PLIST_SUB+= SO_VER=${SO_VER} SO_VER_MAJ=${SO_VER:R:R}
>>
>
> ​Why can't you do something like the above to get SO_VER?
>
> PORTVERSION=1.8.1.2
> SO_VER=${PORTVERSION:R:R:R)
>
> Similar to how you get SO_VER_MAJ out of SO_VER.​
>
>
> That is true. Do you think this is a robust solution, though?
> Or is the whole relying on upstream variables idea problematic?
>

​So long as they continue to have ​4 digit version numbers (meaning 1.9.0.0
and not just 1.9), then everything will be fine.

If upstream does weird things with their version numbers (1.8.1.2 --> 1.8.2
--> 1.9 --> 2 --> 2.1 --> 2.1.1 --> 2.1.1.1), then you'll have to manually
massage things in the port Makefile with each update.

Hopefully, they don't do that, and keep things logical (1.8.1.2 --> 1.8.2.0
--> 1.9.0.0 --> 2.0.0.0 --> 2.1.0.0 --> 2.1.1.0 --> 2.1.1.1) which would
make things simpler on your end.  :)


-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Help with versioning scheme

[Adam Weinberger]

On 17 Jan, 2018, at 11:40, Martin Waschbüsch  wrote:

Thanks, Freddie,

Am 17.01.2018 um 19:35 schrieb Freddie Cash :

On Wed, Jan 17, 2018 at 10:29 AM, Martin Waschbüsch  
mailto:mar...@waschbuesch.de>> wrote:

Hi Adam,
Am 17.01.2018 um 19:19 schrieb Adam Weinberger >:

Hi Martin,

You don't want to use the upstream version to represent PORTREVISION.  
PORTREVISION is for when you need to force rebuilds of the port itself,  
and so tying it to upstream would make it impossible to bump it  
ourselves.


Why do you need to ignore the fourth digit? It's perfectly valid for  
our purposes.


So far, I had (because it coincided with their version number) used it  
to provide SO_VER. But that breaks now:


---
# Created by: adamw
# $FreeBSD: head/archivers/liblz4/Makefile 448415 2017-08-20 12:30:25Z  
sunpoet $


PORTNAME=   lz4
PORTVERSION=1.8.1
DISTVERSIONPREFIX=  v
PORTEPOCH=  1
CATEGORIES= archivers
PKGNAMEPREFIX=  lib

MAINTAINER= mar...@waschbuesch.de 
COMMENT=LZ4 compression library, lossless and very fast

LICENSE=BSD2CLAUSE GPLv2
LICENSE_COMB=   multi

USES=   gmake pathfix pkgconfig
USE_GITHUB= yes
USE_LDCONFIG=   yes
#PATHFIX_MAKEFILEIN=Makefile

ALL_TARGET= default # don't remove this
SO_VER= ${PORTVERSION}
PLIST_SUB+= SO_VER=${SO_VER} SO_VER_MAJ=${SO_VER:R:R}

​Why can't you do something like the above to get SO_VER?

PORTVERSION=1.8.1.2
SO_VER=${PORTVERSION:R:R:R)

Similar to how you get SO_VER_MAJ out of SO_VER.​


That is true. Do you think this is a robust solution, though?
Or is the whole relying on upstream variables idea problematic?


In general, I recommend against doing clever things. It's too easy to  
outsmart yourself.


It's not terribly difficult to edit the plist and increase a number. I  
recommend clear over clever every time.


# Adam


--
Adam Weinberger
ad...@adamw.org
http://www.adamw.org

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Help with versioning scheme

[Martin Waschbüsch]

Thanks, Freddie,
> Am 17.01.2018 um 19:35 schrieb Freddie Cash :
> 
> On Wed, Jan 17, 2018 at 10:29 AM, Martin Waschbüsch  > wrote:
> Hi Adam,
> > Am 17.01.2018 um 19:19 schrieb Adam Weinberger  > >:
> > Hi Martin,
> >
> > You don't want to use the upstream version to represent PORTREVISION. 
> > PORTREVISION is for when you need to force rebuilds of the port itself, and 
> > so tying it to upstream would make it impossible to bump it ourselves.
> >
> > Why do you need to ignore the fourth digit? It's perfectly valid for our 
> > purposes.
> 
> So far, I had (because it coincided with their version number) used it to 
> provide SO_VER. But that breaks now:
> 
> ---
> # Created by: adamw
> # $FreeBSD: head/archivers/liblz4/Makefile 448415 2017-08-20 12:30:25Z 
> sunpoet $
> 
> PORTNAME=   lz4
> PORTVERSION=1.8.1
> DISTVERSIONPREFIX=  v
> PORTEPOCH=  1
> CATEGORIES= archivers
> PKGNAMEPREFIX=  lib
> 
> MAINTAINER= mar...@waschbuesch.de 
> COMMENT=LZ4 compression library, lossless and very fast
> 
> LICENSE=BSD2CLAUSE GPLv2
> LICENSE_COMB=   multi
> 
> USES=   gmake pathfix pkgconfig
> USE_GITHUB= yes
> USE_LDCONFIG=   yes
> #PATHFIX_MAKEFILEIN=Makefile
> 
> ALL_TARGET= default # don't remove this
> SO_VER= ${PORTVERSION}
> PLIST_SUB+= SO_VER=${SO_VER} SO_VER_MAJ=${SO_VER:R:R}
> 
> ​Why can't you do something like the above to get SO_VER?
> 
> PORTVERSION=1.8.1.2
> SO_VER=${PORTVERSION:R:R:R)
> 
> Similar to how you get SO_VER_MAJ out of SO_VER.​

That is true. Do you think this is a robust solution, though?
Or is the whole relying on upstream variables idea problematic?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Help with versioning scheme

[Adam Weinberger]

On 17 Jan, 2018, at 11:29, Martin Waschbüsch  wrote:

Hi Adam,

Am 17.01.2018 um 19:19 schrieb Adam Weinberger :
Hi Martin,

You don't want to use the upstream version to represent PORTREVISION.  
PORTREVISION is for when you need to force rebuilds of the port itself,  
and so tying it to upstream would make it impossible to bump it  
ourselves.


Why do you need to ignore the fourth digit? It's perfectly valid for our  
purposes.


So far, I had (because it coincided with their version number) used it to  
provide SO_VER. But that breaks now:


---
# Created by: adamw
# $FreeBSD: head/archivers/liblz4/Makefile 448415 2017-08-20 12:30:25Z  
sunpoet $


PORTNAME=   lz4
PORTVERSION=1.8.1
DISTVERSIONPREFIX=  v
PORTEPOCH=  1
CATEGORIES= archivers
PKGNAMEPREFIX=  lib

MAINTAINER= mar...@waschbuesch.de
COMMENT=LZ4 compression library, lossless and very fast

LICENSE=BSD2CLAUSE GPLv2
LICENSE_COMB=   multi

USES=   gmake pathfix pkgconfig
USE_GITHUB= yes
USE_LDCONFIG=   yes
#PATHFIX_MAKEFILEIN=Makefile

ALL_TARGET= default # don't remove this
SO_VER= ${PORTVERSION}
PLIST_SUB+= SO_VER=${SO_VER} SO_VER_MAJ=${SO_VER:R:R}
LIBDIR= ${PREFIX}/lib

post-patch:
@${FIND} ${WRKSRC} -name Makefile | ${XARGS} ${REINPLACE_CMD} \
-e '/^MANDIR :=/s|share/||'
@${REINPLACE_CMD} -e '/^all:/s/$$/ liblz4.pc/' \
${WRKSRC}/lib/Makefile
@${REINPLACE_CMD} -e '/^all:/s|fullbench.*||' \
${WRKSRC}/programs/Makefile

post-install:
${STRIP_CMD} ${STAGEDIR}${PREFIX}/bin/lz4*
${STRIP_CMD} ${STAGEDIR}${PREFIX}/lib/liblz4.so.${SO_VER}

.include 
---

Manually specifying the SO_VER seems also very weird.

I am sorry if these questions seem clumsy - I am not terribly experienced  
with porting stuff, but eager to learn.


You can still use them---just add an extra :R.

PLIST_SUB+= SO_VER=${SO_VER:R} SO_VER_MAJ=${SO_VER:R:R}

# Adam


--
Adam Weinberger
ad...@adamw.org
http://www.adamw.org

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Help with versioning scheme

[Freddie Cash]

On Wed, Jan 17, 2018 at 10:29 AM, Martin Waschbüsch 
wrote:

> Hi Adam,
> > Am 17.01.2018 um 19:19 schrieb Adam Weinberger :
> > Hi Martin,
> >
> > You don't want to use the upstream version to represent PORTREVISION.
> PORTREVISION is for when you need to force rebuilds of the port itself, and
> so tying it to upstream would make it impossible to bump it ourselves.
> >
> > Why do you need to ignore the fourth digit? It's perfectly valid for our
> purposes.
>
> So far, I had (because it coincided with their version number) used it to
> provide SO_VER. But that breaks now:
>
> ---
> # Created by: adamw
> # $FreeBSD: head/archivers/liblz4/Makefile 448415 2017-08-20 12:30:25Z
> sunpoet $
>
> PORTNAME=   lz4
> PORTVERSION=1.8.1
> DISTVERSIONPREFIX=  v
> PORTEPOCH=  1
> CATEGORIES= archivers
> PKGNAMEPREFIX=  lib
>
> MAINTAINER= mar...@waschbuesch.de
> COMMENT=LZ4 compression library, lossless and very fast
>
> LICENSE=BSD2CLAUSE GPLv2
> LICENSE_COMB=   multi
>
> USES=   gmake pathfix pkgconfig
> USE_GITHUB= yes
> USE_LDCONFIG=   yes
> #PATHFIX_MAKEFILEIN=Makefile
>
> ALL_TARGET= default # don't remove this
> SO_VER= ${PORTVERSION}
> PLIST_SUB+= SO_VER=${SO_VER} SO_VER_MAJ=${SO_VER:R:R}
>

​Why can't you do something like the above to get SO_VER?

PORTVERSION=1.8.1.2
SO_VER=${PORTVERSION:R:R:R)

Similar to how you get SO_VER_MAJ out of SO_VER.​

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Help with versioning scheme

[Martin Waschbüsch]

Hi Adam,
> Am 17.01.2018 um 19:19 schrieb Adam Weinberger :
> Hi Martin,
> 
> You don't want to use the upstream version to represent PORTREVISION. 
> PORTREVISION is for when you need to force rebuilds of the port itself, and 
> so tying it to upstream would make it impossible to bump it ourselves.
> 
> Why do you need to ignore the fourth digit? It's perfectly valid for our 
> purposes.

So far, I had (because it coincided with their version number) used it to 
provide SO_VER. But that breaks now:

---
# Created by: adamw
# $FreeBSD: head/archivers/liblz4/Makefile 448415 2017-08-20 12:30:25Z sunpoet $

PORTNAME=   lz4
PORTVERSION=1.8.1
DISTVERSIONPREFIX=  v
PORTEPOCH=  1
CATEGORIES= archivers
PKGNAMEPREFIX=  lib

MAINTAINER= mar...@waschbuesch.de
COMMENT=LZ4 compression library, lossless and very fast

LICENSE=BSD2CLAUSE GPLv2
LICENSE_COMB=   multi

USES=   gmake pathfix pkgconfig
USE_GITHUB= yes
USE_LDCONFIG=   yes
#PATHFIX_MAKEFILEIN=Makefile

ALL_TARGET= default # don't remove this
SO_VER= ${PORTVERSION}
PLIST_SUB+= SO_VER=${SO_VER} SO_VER_MAJ=${SO_VER:R:R}
LIBDIR= ${PREFIX}/lib

post-patch:
@${FIND} ${WRKSRC} -name Makefile | ${XARGS} ${REINPLACE_CMD} \
-e '/^MANDIR :=/s|share/||'
@${REINPLACE_CMD} -e '/^all:/s/$$/ liblz4.pc/' \
${WRKSRC}/lib/Makefile
@${REINPLACE_CMD} -e '/^all:/s|fullbench.*||' \
${WRKSRC}/programs/Makefile

post-install:
${STRIP_CMD} ${STAGEDIR}${PREFIX}/bin/lz4*
${STRIP_CMD} ${STAGEDIR}${PREFIX}/lib/liblz4.so.${SO_VER}

.include 
---

Manually specifying the SO_VER seems also very weird.

I am sorry if these questions seem clumsy - I am not terribly experienced with 
porting stuff, but eager to learn.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Help with versioning scheme

[Adam Weinberger]

On 17 Jan, 2018, at 11:08, Martin Waschbüsch  wrote:

Hi there,

I am preparing a patch for a port (archivers/libz4) that I am maintaining.
The versioning scheme upstream originally used was for instance:

rXXX
e.g. r123

When they changed to

vX.Y.Z
e.g. v1.8.1

I had to up PORTEPOCH in order not to get wrong warnings about new  
versions available.


Now, they added a fourth digit to that.

vV.X.Y.Z
e.g. v1.8.1.2

So far so good. Now, the last digit is equivalent to our port revisions.  
E.g. the version of the library as declared in the source is still 1.8.1.


How do I adapt the Makefile that the correct tarball will be downloaded  
from git (which contains v1.8.1.2) but either ignore the fourth digit or  
use it to represent the port revision?


Also, would you consider it impolite to (humbly) ask upstream to  
(carefully) choose a versioning scheme and stick with it (longterm)? ;-)


Hi Martin,

You don't want to use the upstream version to represent PORTREVISION.  
PORTREVISION is for when you need to force rebuilds of the port itself, and  
so tying it to upstream would make it impossible to bump it ourselves.


Why do you need to ignore the fourth digit? It's perfectly valid for our  
purposes.


# Adam


--
Adam Weinberger
ad...@adamw.org
http://www.adamw.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"

Help with versioning scheme

[Martin Waschbüsch]

Hi there,

I am preparing a patch for a port (archivers/libz4) that I am maintaining.
The versioning scheme upstream originally used was for instance:

rXXX
e.g. r123

When they changed to 

vX.Y.Z
e.g. v1.8.1

I had to up PORTEPOCH in order not to get wrong warnings about new versions 
available.

Now, they added a fourth digit to that.

vV.X.Y.Z
e.g. v1.8.1.2

So far so good. Now, the last digit is equivalent to our port revisions. E.g. 
the version of the library as declared in the source is still 1.8.1.

How do I adapt the Makefile that the correct tarball will be downloaded from 
git (which contains v1.8.1.2) but either ignore the fourth digit or use it to 
represent the port revision?

Also, would you consider it impolite to (humbly) ask upstream to (carefully) 
choose a versioning scheme and stick with it (longterm)? ;-)

Best,

Martin
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: CLANG6, java/openjdk[7|8] compiler error: atomic.inline.hpp:70 error: unknown token in expression __asm__ volatile

[Dimitry Andric]

On 17 Jan 2018, at 12:01, O. Hartmann  wrote:
> 
> On recent CURRENT (FreeBSD 12.0-CURRENT #0 r328002: Mon Jan 15 15:28:18 CET
> 2018 amd64) both ports java/openjdk7 and java/openjdk8 fail to compile with
> devel/openjdk8's error as follows:
> 
> 
> [...]
> In file included
> from 
> /usr/ports/java/openjdk8/work/openjdk/hotspot/src/share/vm/runtime/atomic.inline.hpp:70:
>  
> /usr/ports/java/openjdk8/work/openjdk/hotspot/src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp:95:21:
> error: unknown token in expression __asm__ volatile (LOCK_IF_MP(%4) "cmpxchgl
> %1,(%3)"

I had the idea this was worked around already, but I am planning on
committing an upstream fix for this very soon.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Committer needed for sysutils/gdisk

[Walter Schwarzenfeld]

Please would someone commit

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198518

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