From llvm: Fwd: [Bug 26970] clang 3.8.0 for powerpc64 vs. FreeBSD buildworld: error: invalid float ABI 'soft float is not supported for ppc64' [llvm r283060/r283061 are a fix]

[Mark Millard]

llvm's bugzilla reports that as of llvm's -r283060/-r283061 
TARGET_ARCH=powerpc64 (in FreeBSD  terms) has soft-float available in clang 
(probably this is on/from trunk). See the forward below.

This was another of the items blocking use of clang 3.8.0 for buildworld and 
the like for powerpc64.

This is another fix by Hal Finkel, one of the two people that have recently 
been working on things that block clang's use as the system compiler for 
TARGET_ARCH=powerpc64 and TARGET_ARCH=powerpc for FreeBSD.

[Note: Lots of the fixes made so far would be required for clang's that are 
from ports and target powerpc64 and/or powerpc as well, especially for powerpc 
since clang produces code that has (SVR4) ABI violations for stack handling. 
(so-called "red-zone" on stack for signal handling required to protect that 
stack --but the ABI says such should not be required and the standard kernel 
does not provide such.)]


With the prior llvm -r282174 completing the SVR4 stack handling ABI fixes for 
TARGE_ARCH=powerpc plus the work before that I expect this leaves only some of 
the C++ exception handling defects from what I'd submitted as bugzilla reports 
to llvm, for powerpc64 and for powerpc.

If projects/clang390-import also picks up these latest fixes ( -r282174 , 
-r283060 , -r283061 ) some interesting powerpc64 and powerpc experiments should 
be possible. (But it will be around a couple of weeks before I've got access to 
the powerpc64 and powerpc machines again.)

===
Mark Millard
markmi at dsl-only.net

Begin forwarded message:

> From: bugzilla-daemon[ at ]llvm.org
> Subject: [Bug 26970] clang 3.8.0 for powerpc64 vs. FreeBSD buildworld: error: 
> invalid float ABI 'soft float is not supported for ppc64'
> Date: October 1, 2016 at 7:12:07 PM PDT
> To: 
> 
> Hal Finkel changed bug 26970 
> What  Removed Added
> StatusNEW RESOLVED
> Resolution--- FIXED
> 
> Comment # 1 on bug 26970 from Hal Finkel
> r283060/r283061 enables soft-float for PPC64.
> 
> You are receiving this mail because:
>   • You reported the bug.
> 
___
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: www/mod_authnz_external24 replacement repo?

[Eugene M. Zheganin]

Hi.

On 01.10.2016 14:38, Stefan Bethke wrote:

I’ve been a long time user of mod_authnz_external.  I didn’t pay much attention 
to the Google Code retirement, so when I tried updating ports today, I was 
surprised by the IGNORE on the port.

I did a little research: mod-auth-external is not archived on Google Code (at 
least I can’t find it there), so it’s hard to ascertain what the actual code 
base was the last time it was available.

There’s a number of Github repos that have been imported from Google Code; none 
of them seem to have been created by the original maintainer.  That’s not 
really surprising, since the original maintainer was looking for someone to 
take over from him a year and a half ago.

I think I will try to prepare an update to the port to use 
https://github.com/phokz/mod-auth-external, since that comes up first in the 
search, and according to the commit history, has not been changed from the 
original source (yet).

If anyone has a better suggestion, I’d be happy to hear it!

I'm the maintainer of the port www/mod_authnz_external24. Disclaimer: 
I'm just a guy who needs this module since I use it for a long time. 
Once I discovered that the FreeBSD ports version is apache22-only, so I 
quicly made a port and asked one of the FreeBSD big guys to commit it. 
As a [temporary ?] solution I can easily rehost the tarball, I think 
this is what I should do for now (unfortunately, I was simple not aware 
about the fact that the port is marked unfetcheable may be I've even got 
the email about it, but for last year maintaining this ports meant 
receiving periodically some mail with false positive building errorso 
may be this is why I missed it). As for the port future... well, I'm 
concerned about it too, because I suppose I will continue to use it. So 
if anyone wants to take it over to maintain - I'm not insisting on my 
maintainership at all.


Eugene.

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

Re: Updating Readline

[Gerard Seibert]

On Sat, 1 Oct 2016 00:59:40 +, Klaus Kaisersberger stated:

>You might contact the maintainer regarding that (joh...@freebsd.org).

He was CC'd on the original post.

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

www/mod_authnz_external24 replacement repo?

[Stefan Bethke]

I’ve been a long time user of mod_authnz_external.  I didn’t pay much attention 
to the Google Code retirement, so when I tried updating ports today, I was 
surprised by the IGNORE on the port.

I did a little research: mod-auth-external is not archived on Google Code (at 
least I can’t find it there), so it’s hard to ascertain what the actual code 
base was the last time it was available.

There’s a number of Github repos that have been imported from Google Code; none 
of them seem to have been created by the original maintainer.  That’s not 
really surprising, since the original maintainer was looking for someone to 
take over from him a year and a half ago.

I think I will try to prepare an update to the port to use 
https://github.com/phokz/mod-auth-external, since that comes up first in the 
search, and according to the commit history, has not been changed from the 
original source (yet).

If anyone has a better suggestion, I’d be happy to hear it!


Cheers,
Stefan

-- 
Stefan Bethke    Fon +49 151 14070811




___
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: dependency explosions

[Miroslav Lachman]

Julian Elischer wrote on 10/01/2016 04:35:

Hi ports people.

It seems to me that there has been an explosion in ports dependencies
recently.
Things that used to need a few dependencies are now pulling in things
one would never imagine.
We just had to add the openjdk7 port to something and the number of
dependencies is at 120 and rising still.
(mostly due to an *undocumented* dependency on a cups include file).

I needed to add glib2 and I got over 20 dependencies. (and then it
failed to compile).

12 ports I've been adding to my systems for years have now resulted in
135 unexpected ports being built.
Some issues I've noted:

There is a need for a "minimum" install of a lot of packages.

Such a 'minimum' install should probably be the default when coming in
as a dependency, as
there is an increasing tendency to configure things with all the bells
and whistles.

anyone have any thought as to 1/ why the recent explosion, and 2/ what
to do about it?


Yes I have similar experience with last version of VirtualBox. We are 
using VirtualBox for a long time in headless mode.

We have following unset in poudriers make.conf
OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS

VirtualBox was always built without GUI but new version has new option 
QT5 and this pulls many tens of unwanted dependency libraries.


I don't understand why it pull anything for GUI if X11 is unset.

I found that even QT5 radio box must be unset which is really 
unintuitive for me:


│ │ [ ] X11 X11 (graphics) support
│ │── GUI (Graphical User Interface) support
│ │ ( ) QT4 Build with QT4 Frontend
│ │+(*) QT5 Build with QT5 Frontend

Radios are normally used for "choose one of them" especially in case one 
is preselected.


So usually trivial update costs me a lot of time to solve this.

Miroslav Lachman
___
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: Google Code as an upstream is gone

[Matthias Andree]

Am 01.10.2016 um 10:03 schrieb Grzegorz Junka:
> The fact that some source is hosted at a provider that doesn't close
> their services, like Google does (aka GitHub), doesn't make it
> "maintained". Is that your definition of "maintained", that the "the
> code could be updated if needed"? If yes, then I am happy to upload
> all "unmaintained" sources to my GitHub account where you can fork the
> repository for free and update "if needed". 

I don't see that Peter was suggesting that holding the abandonware from
Google Code Archives makes it maintained per se (because in the
archives, they cannot) - but there are two aspects of being maintained:
the upstream maintainer, and the FreeBSD port. Be sure not to talk past
each other.

I will suggest that the author's activity in the software's surroundings
(support mailing lists, web site, forums, ...) should also be considered.

Matthias

___
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 you maintain which are out of date

[portscout]

Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
lang/sbcl   | 1.3.1   | 1.3.10
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

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: ca_root_nss compile failure

[Matthias Andree]

Am 01.10.2016 um 03:43 schrieb Carlos J. Puga Medina:
> Hi Matthias, > >> Am 28.09.2016 um 10:36 schrieb Carlos J. Puga Medina:  
> Sorry,
I >> wasn't clear enough in my first reply: I set ssl=3Dopenssl as 
>> default version in make.conf to pick openssl from ports instead >>
from  base because the openssl port was previously updated and >>
fixed.  Later I updated my system with all patches applied and >>
reverted the  previous change in /etc/make.conf. >> >> You still
need to deinstall the ports openssl and then make sure >> to rebuild all
ports that depend on it. > > Yes, I did :) > > I had this issue with
poudriere. Everything works smoothly again. > > Regards,

Carlos,

good to see it works for you.

For the records, to update the poudriere jail, that would be:

  poudriere jail -j 103amd64 -u

where the "103amd64" needs to be replaced by whatever the jail's name
is; "poudriere jail -l" will print a list.

Regards,
Matthias

___
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: Google Code as an upstream is gone

[Grzegorz Junka]

On 30/09/2016 23:59, Peter Jeremy wrote:

On 2016-Sep-29 16:33:12 -0700, Kevin Oberman  wrote:

On Thu, Sep 29, 2016 at 9:57 AM, Christian Weisgerber 
wrote:


Mathieu Arnold:


If the software has not been moved to some other place, (it takes about
30 seconds to click the automatic migration to github thing, and it is
usually done within the hour,) since march 2015, it is most likely
abandoned and should not be kept in the ports tree.

That seems a very reasonable policy.  Unmaintained software is a danger to
the Internet community as a whole and if, after 18 months, a "maintainer"
hasn't bothered to take action to move the software to somewhere where it
can be supported then it rates as "unmaintained".


In the past, if the upstream was gone and the maintainer judged the
software still useful (at their discretion, not based on a cut-off
date), they would even fall back to providing the distfile at
people.freebsd.org.

The maintainer is still free to do so.  "Maintainership" includes responding
to changes within a reasonable period (hence "maintainer timeout").


This was simply a terrible idea and I would hope that the ports team would
clearly so state and back out the "BROKEN" from those ports. As others are
pointing out, lot of very old and stable code has gone over a year without
updating.

I think globally marking all ports that fetch from code.google.com as
BROKEN is an excellent idea.  There's a massive difference between "old and
stable" and "unmaintained".  The latter means that no-one cares if the code
has security vulnerabilities.  Just because code is "old and stable" doesn't
mean the code is completely bug-free and a reasonable maintainer would take
steps to ensure that the code could be updated if needed.


One case of import to me was mp4v2, a library for making MP4v2 formatted

...

source library for version 2 of the MP4 spec. Yet, because it had Google
Code as it's repo and had not been updated in just over a year, BROKEN.

The last commit to mp4v2 in code.google.com was 2015-Jan-06 - nearly 21
months ago.


(That has now been fixed sue to several people yelling loudly about its
import.

That is an issue you should take up with the port's maintainer.


I am sure that ports contains many old, buggy, insecure ports that should
go away, but a standard of "over  year without a commit" should not be a
metric for determining what goes away.

IMO, "over 18 months without a commit and not able to be updated if required"
seems a quite reasonable metric for deeming code "abandonware".



The fact that some source is hosted at a provider that doesn't close 
their services, like Google does (aka GitHub), doesn't make it 
"maintained". Is that your definition of "maintained", that the "the 
code could be updated if needed"? If yes, then I am happy to upload all 
"unmaintained" sources to my GitHub account where you can fork the 
repository for free and update "if needed".


Grzegorz

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