Re: Problems using OpenMP

[Pedro Giffuni]

On 05/31/17 21:45, Steve Kargl wrote:

On Wed, May 31, 2017 at 08:56:18PM -0500, Pedro Giffuni wrote:

FWIW, I tried using OpenMP in a port (hypre) and I thought the option
would be something as simple as this:

OPENMP_CONFIGURE_WITH=openmp
OPENMP_CONFIGURE_USES=compiler:openmp

Unfortunately that is not enough:

...

In file included from ./_hypre_utilities.h:16:
./HYPRE_utilities.h:29:10: fatal error: 'omp.h' file not found
#include 
   ^~~
--- amg_linklist.o ---
...

And the file is here:

/usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include/omp.h
/usr/local/llvm39/lib/clang/3.9.1/include/omp.h

Which is not really clean to include :(. Any suggestion?


This is similar to the problem with having to find -Wl,-L/usr/local/... to
find gfortran's shared libraries.  For gfortran you can do

#! /bin/sh
LD_LIBRARY_PATH=$HOME/work/lib
export LD_LIBRARY_PATH
LD_RUN_PATH=$HOME/work/lib
export LD_RUN_PATH
PATH=$HOME/work/bin:$PATH
gfortran $@

gcc has a C_INCLUDE_PATH environmental variable.  Don't know if this
works with gfortran or if there is a GFORTRAN_INCLUDE_PATH.

This is C, the fortran interface is used for external libraries. OK.. it's
interesting to know that, I didn't want to include it in the CFLAGS.
What I am finding is that all these packages are in early stages of
OpenMP adoption and generally prefer MPI.

For now I am trying to use threads whenever it is an option.



This does not work with flang as she does not support LD_LIBRARY_PATH or
LD_RUN_PATH.  For openmp, and in particularly for the old fashion omp.h
file, you'll need to add an appropriate -I/path/to/omp... stuff to your
FFLAGS.  You can add -I/usr/local/flang/include to /usr/local/bin/flang
as it is a simple Bourne shell script.


The packages I am porting were created by the labs that sponsored
flang so I guess they will figure it out ;).

Thanks!

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

Sylpheed bug?

[Waitman Gobble]

Rececently installed Sylpheed Port on FreeBSD-11.0, everything works unless I 
press 'Get' or 'Get All' buttons at the top, if i do that it instally kills 
everything running from /usr/local and restarts xorg. Seconds flat. Maybe it's 
good for a bug report? I haven't done much on this machine and I don't think I 
dicked it up. But maybe I did?

Muchas Gracias,

-- 
Waitman Gobble 
+1 650 900 8557 Los Altos
+1 829 946 1616 Santo Domingo
+52 335 350 11741 Michoacán
___
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: Problems using OpenMP

[Steve Kargl]

On Wed, May 31, 2017 at 08:56:18PM -0500, Pedro Giffuni wrote:
> 
> FWIW, I tried using OpenMP in a port (hypre) and I thought the option 
> would be something as simple as this:
> 
> OPENMP_CONFIGURE_WITH=openmp
> OPENMP_CONFIGURE_USES=compiler:openmp
> 
> Unfortunately that is not enough:
> 
> ...
> 
> In file included from ./_hypre_utilities.h:16:
> ./HYPRE_utilities.h:29:10: fatal error: 'omp.h' file not found
> #include 
>   ^~~
> --- amg_linklist.o ---
> ...
> 
> And the file is here:
> 
> /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include/omp.h
> /usr/local/llvm39/lib/clang/3.9.1/include/omp.h
> 
> Which is not really clean to include :(. Any suggestion?
> 

This is similar to the problem with having to find -Wl,-L/usr/local/... to 
find gfortran's shared libraries.  For gfortran you can do

#! /bin/sh
LD_LIBRARY_PATH=$HOME/work/lib
export LD_LIBRARY_PATH
LD_RUN_PATH=$HOME/work/lib
export LD_RUN_PATH
PATH=$HOME/work/bin:$PATH
gfortran $@

gcc has a C_INCLUDE_PATH environmental variable.  Don't know if this
works with gfortran or if there is a GFORTRAN_INCLUDE_PATH.


This does not work with flang as she does not support LD_LIBRARY_PATH or
LD_RUN_PATH.  For openmp, and in particularly for the old fashion omp.h
file, you'll need to add an appropriate -I/path/to/omp... stuff to your
FFLAGS.  You can add -I/usr/local/flang/include to /usr/local/bin/flang
as it is a simple Bourne shell script.

-- 
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow
___
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"

Problems using OpenMP

[Pedro Giffuni]

Hello guys;

FWIW, I tried using OpenMP in a port (hypre) and I thought the option 
would be something as simple as this:


OPENMP_CONFIGURE_WITH=openmp
OPENMP_CONFIGURE_USES=compiler:openmp

Unfortunately that is not enough:

...

In file included from ./_hypre_utilities.h:16:
./HYPRE_utilities.h:29:10: fatal error: 'omp.h' file not found
#include 
 ^~~
--- amg_linklist.o ---
...

And the file is here:

/usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include/omp.h
/usr/local/llvm39/lib/clang/3.9.1/include/omp.h

Which is not really clean to include :(. Any suggestion?

Pedro.

___
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: Hosting distfiles on HTTPS w/Let's Encrypt - how?

[Jov]

can you dowload the file distfiles/INIT.2014-12-24.tgz
 using
browser such as chrome？

be sure to use full chain cert file，I rember I had similar problem and use
full chain cert fixed.

2017年6月1日 8:01 AM，"Marcin Cieslak" 写道：

Hello,

I have posted my port's local distfiles to a machine
that is serving them with SSL behind the Let's Encrypt
certificate (https://distfile.net). This is SSL-only.

However, poudriere fails on certificate check when trying
to fetch it:

===
===>  License EPL accepted by the user
===
===
===>   ksh93-20160716 depends on file: /usr/local/sbin/pkg - not found
===>   Installing existing package /packages/All/pkg-1.10.1.txz
[ksh-test-amd64-exp-job-01] Installing pkg-1.10.1...
[ksh-test-amd64-exp-job-01] Extracting pkg-1.10.1: .. done
===>   ksh93-20160716 depends on file: /usr/local/sbin/pkg - found
===>   Returning to build of ksh93-20160716
===
===
===
===
===>  License EPL accepted by the user
=> INIT.2014-12-24.tgz doesn't seem to exist in /portdistfiles/ksh93.
=> Attempting to fetch https://distfile.net/local-
ports-distfiles/INIT.2014-12-24.tgz
Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt
Authority X3
34374329736:error:14090086:SSL routines:ssl3_get_server_certificate:certificate
verify failed:/usr/src/secure/lib/libssl/../../../crypto/
openssl/ssl/s3_clnt.c:1264:
fetch: https://distfile.net/local-ports-distfiles/INIT.2014-12-24.tgz:
Authentication error
=> Attempting to fetch http://distcache.FreeBSD.org/
ports-distfiles/ksh93/INIT.2014-12-24.tgz
fetch: http://distcache.FreeBSD.org/ports-distfiles/ksh93/INIT.
2014-12-24.tgz: Not Found
=> Couldn't fetch it - please try to retrieve this
=> port manually into /portdistfiles/ksh93 and try again.
*** Error code 1

What is the best solution here?

so I really have to add security/ca_root_nss (... and perl)
as a fetch dependency? Any other solution?

A quick look at bsd.sites.mk shows that we have some https-only distfile
sources.

Marcin Cieślak
___
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: The future of portmaster

[Thomas Mueller]

> On Wed, 2017-05-31 at 12:47 +, Gerard Seibert wrote:
> > I would just like a clarification here. For the record, synth is
> > broken
> > on FreeBSD-11 and above with amd64. Is that correct?

> My understanding was that the breakage is in gcc6-aux on 12-CURRENT
> with 64 bit inodes.

> I may be wrong...

> Jim Ohlstein

That was my understanding too, both gcc5-aux and gcc6-aux being broken on 
CURRENT with 64-bit inodes.

Now I feel like I can upgrade with 11.0-STABLE but not CURRENT.

My recent CURRENT installation seems too unstable to use as a build host.

I would rebuild 11.0-STABLE first and later use that as a host to rebuild 
CURRENT.

I would want gcc(5 or 6)-aux not only for synth but also (gcc5) to try to 
cross-compile Haiku and (gcc5 or 6) to try to cross-compile a Linux toolchain.

I would also want an updated FreeBSD system that ports would support as opposed 
to something like

FreeBSD amelia 11.0-CURRENT FreeBSD 11.0-CURRENT #10 r294248: Mon Jan 18 
11:28:40 UTC 2016 root@amelia:/usr/obj/usr/src/sys/SANDY11NC  amd64

Regarding portmaster, when something on which a lot of other ports depend is 
upgraded, such as a major version update of png, it takes many runs of 
portmaster before everything is successfully updated.

Tom

___
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: Firefox (and other Mozilla products) after ino64

[Jeffrey Bouquet]

On Wed, 31 May 2017 23:27:16 +0200, Dimitry Andric  wrote:

> Hi,
> 
> Due to the recent ino64 update in 12.0-CURRENT, there have been some
> reports by Firefox port users about crashes.  While I personally have
> not experienced these crashes, as I immediately rebuilt all my ports
> from scratch after the ino64 update, I think can explain why the
> following combination is very likely to have problems:
> 
> * kernel+world after ino64
> * www/firefox package from before ino64
> 
> It is because Firefox's JavaScript engine is doing tricks to get at libc
> structures and functions (via an FFI mechanism), and several structure
> layouts and offsets are hardcoded into its engine at build time.
> 
> For instance, here is the place where the engine determines the offset
> of struct dirent's d_name field:
> 
>   
> https://hg.mozilla.org/mozilla-central/file/tip/dom/system/OSFileConstants.cpp#l648
> 
> Further down in the file, several offsets of fields in struct stats are
> similarly determined:
> 
>   
> https://hg.mozilla.org/mozilla-central/file/tip/dom/system/OSFileConstants.cpp#l677
> 
> Now, since ino64 changed quite a number of structure layouts, including
> struct dirent, struct stat, and others, such offsets determined in the
> past will no longer be valid!
> 
> It is pretty likely that Firefox will attempt to access these fields,
> finding bogus values, or simply reading invalid memory, and crashing
> because of this.  Or at the least, the behavior will be unstable.
> 
> This also applies to other Mozilla products, such as Thunderbird,
> SeaMonkey, and so on.  These should all be rebuilt from scratch under
> ino64.
> 
> -Dimitry


What of machines where for some reason ports do not always build? [ for 
instance, 
ones with past workarounds for a
failed installworld...  ]  that still are in critical use daily? And,or where 
the
system has been installed for so long without reinstall that some ports 
segfault unless 'pkg lock'  ... and not usually upgraded... and/or thus using
binaries from backup... 

  Are upstream repositories to have those [ browser, email]  ports?  For 
instance, here iridium I cannot get to build... 
___
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"

Hosting distfiles on HTTPS w/Let's Encrypt - how?

[Marcin Cieslak]

Hello,

I have posted my port's local distfiles to a machine
that is serving them with SSL behind the Let's Encrypt
certificate (https://distfile.net). This is SSL-only.

However, poudriere fails on certificate check when trying
to fetch it:

===
===>  License EPL accepted by the user
===
===
===>   ksh93-20160716 depends on file: /usr/local/sbin/pkg - not found
===>   Installing existing package /packages/All/pkg-1.10.1.txz
[ksh-test-amd64-exp-job-01] Installing pkg-1.10.1...
[ksh-test-amd64-exp-job-01] Extracting pkg-1.10.1: .. done
===>   ksh93-20160716 depends on file: /usr/local/sbin/pkg - found
===>   Returning to build of ksh93-20160716
===
===
===
===
===>  License EPL accepted by the user
=> INIT.2014-12-24.tgz doesn't seem to exist in /portdistfiles/ksh93.
=> Attempting to fetch 
https://distfile.net/local-ports-distfiles/INIT.2014-12-24.tgz
Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt 
Authority X3
34374329736:error:14090086:SSL routines:ssl3_get_server_certificate:certificate 
verify 
failed:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_clnt.c:1264:
fetch: https://distfile.net/local-ports-distfiles/INIT.2014-12-24.tgz: 
Authentication error
=> Attempting to fetch 
http://distcache.FreeBSD.org/ports-distfiles/ksh93/INIT.2014-12-24.tgz
fetch: http://distcache.FreeBSD.org/ports-distfiles/ksh93/INIT.2014-12-24.tgz: 
Not Found
=> Couldn't fetch it - please try to retrieve this
=> port manually into /portdistfiles/ksh93 and try again.
*** Error code 1

What is the best solution here?

so I really have to add security/ca_root_nss (... and perl)
as a fetch dependency? Any other solution?

A quick look at bsd.sites.mk shows that we have some https-only distfile
sources.

Marcin Cieślak


smime.p7s
Description: S/MIME Cryptographic Signature

Re: The future of portmaster [and of ports-mgmt/synth]

[Dave Horsfall]

On Wed, 31 May 2017, Per olof Ljungmark wrote:

> Let me just say that I would really, really appriciate if we could keep 
> such a simple tool. Why does it suit us? Because we have a limited 
> number of systems, [...]

And the sytems we do have can be somewhat limited; I mean, Ada, FFS?

-- 
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: The future of portmaster [and of ports-mgmt/synth]

[Jim Trigg]

If you can give me access to a development system, I'll help.

(I only have a production server for the domains I host for a few 
not-for-profit organizations, and my home server is currently out of service 
with a bad power supply.)

Jim Trigg


On May 30, 2017 8:10:17 PM EDT, Kevin Oberman  wrote:
>On Tue, May 30, 2017 at 2:53 PM, Mark Linimon 
>wrote:
>
>> On Tue, May 30, 2017 at 11:46:46PM +0200, Per olof Ljungmark wrote:
>> > Hello, I have not followed this thread before but just wanted to
>say
>> > that I use portmaster extensively, it works for us and I would miss
>> > it if it went.  Are there actually plans to retire it?
>>
>> To reiterate the status:
>>
>>  * some extensive changes to the ports framework are coming;
>>  * these will require large changes to all the port upgrade tools;
>>  * no one has stepped forwards to offer to do the work for anything
>>other than poudriere AFAIK.
>>
>> If no one does the work, at the time the large changes come, the
>> other tools will break.
>>
>> People have been wanting subpackages (aka flavors) for many years;
>> IIUC these are parts of the changes that are coming.
>>
>> Someone needs to step forwards and say "yes, I will do the work."
>>
>> mcl
>
>
>Since portmaster is still popult and since the only solutions that
>looks to
>be available in the near term are pouderiere or raw make, neither
>terribly
>viable for many, I will look into updating portmaster to deal with
>'flavors'. This looks fairly straight forward and I my have the sh
>capability to manage it. (And then again, I am far from a great shell
>person, so I may well be wrong.) I have looked at Doug's script and it
>is
>pretty readable, but writing may require help.
>
>Can someone point me where to look for documentation on flavors? I have
>poked around the wiki, but to no avail. Unless there is documentation
>on
>what needs to be done, doing it will be hopeless and waiting for the
>packaging system to updated means portmaster WILL be broken for some
>period
>of time.
>--
>Kevin Oberman, Part time kid herder and retired Network Engineer
>E-mail: rkober...@gmail.com
>PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>___
>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"

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
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"

Firefox (and other Mozilla products) after ino64

[Dimitry Andric]

Hi,

Due to the recent ino64 update in 12.0-CURRENT, there have been some
reports by Firefox port users about crashes.  While I personally have
not experienced these crashes, as I immediately rebuilt all my ports
from scratch after the ino64 update, I think can explain why the
following combination is very likely to have problems:

* kernel+world after ino64
* www/firefox package from before ino64

It is because Firefox's JavaScript engine is doing tricks to get at libc
structures and functions (via an FFI mechanism), and several structure
layouts and offsets are hardcoded into its engine at build time.

For instance, here is the place where the engine determines the offset
of struct dirent's d_name field:

  
https://hg.mozilla.org/mozilla-central/file/tip/dom/system/OSFileConstants.cpp#l648

Further down in the file, several offsets of fields in struct stats are
similarly determined:

  
https://hg.mozilla.org/mozilla-central/file/tip/dom/system/OSFileConstants.cpp#l677

Now, since ino64 changed quite a number of structure layouts, including
struct dirent, struct stat, and others, such offsets determined in the
past will no longer be valid!

It is pretty likely that Firefox will attempt to access these fields,
finding bogus values, or simply reading invalid memory, and crashing
because of this.  Or at the least, the behavior will be unstable.

This also applies to other Mozilla products, such as Thunderbird,
SeaMonkey, and so on.  These should all be rebuilt from scratch under
ino64.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: freebsd-ports Digest, Vol 732, Issue 4

[Aric Gregson]

> Since portmaster is still popult and since the only solutions that
> looks to be available in the near term are pouderiere or raw make,
> neither terribly viable for many, I will look into updating
> portmaster to deal with 'flavors'. 

Thank you so very much for attempting this. I too am dependent upon
portmaster, which 70% of the time works just fine. It is frustrating
when builds fail, or in the case of rust, when it can never update
properly. Despite its flaws and the lack of consistently reporting
work-arounds in UPDATING, portmaster is easy to set-up and run and in
combination with portsnap simplifies port management. 

Poudriere may work extremely well, but it remains poorly documented. I
gave it a go about six months ago. To set it up I relied on 1.5 blog
posts and hoped that they were accurate. In my first attempt at building
my ports tree, it failed to build R. I was not able to find
documentation of how to accomplish what poudriere was asking of me. It
was simple to delete the jail and move back to portmaster.

If it is the decision of the FreeBSD community is to ditch everything
but poudriere (and maybe synth?) then a very concerted effort must be
made to improve the documentation for setting up, migrating, using and
debugging poudriere for the casual user, much like has been done for
portmaster up until now.

Thanks to everyone for their continued contributions to make FreeBSD
awesome.
Aric
___
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: The future of portmaster [and of ports-mgmt/synth]

[Adam Weinberger]

> On 31 May, 2017, at 11:28, Per olof Ljungmark  wrote:
> 
> 
> 
> On 2017-05-31 02:10, Kevin Oberman wrote:
>> On Tue, May 30, 2017 at 2:53 PM, Mark Linimon > > wrote:
>>On Tue, May 30, 2017 at 11:46:46PM +0200, Per olof Ljungmark wrote:
>>> Hello, I have not followed this thread before but just wanted to say
>>> that I use portmaster extensively, it works for us and I would miss
>>> it if it went.  Are there actually plans to retire it?
>>To reiterate the status:
>>  * some extensive changes to the ports framework are coming;
>>  * these will require large changes to all the port upgrade tools;
>>  * no one has stepped forwards to offer to do the work for anything
>>other than poudriere AFAIK.
>>If no one does the work, at the time the large changes come, the
>>other tools will break.
>>People have been wanting subpackages (aka flavors) for many years;
>>IIUC these are parts of the changes that are coming.
>>Someone needs to step forwards and say "yes, I will do the work."
>>mcl
>> Since portmaster is still popult and since the only solutions that looks to 
>> be available in the near term are pouderiere or raw make, neither terribly 
>> viable for many, I will look into updating portmaster to deal with 
>> 'flavors'. This looks fairly straight forward and I my have the sh 
>> capability to manage it. (And then again, I am far from a great shell 
>> person, so I may well be wrong.) I have looked at Doug's script and it is 
>> pretty readable, but writing may require help.
>> Can someone point me where to look for documentation on flavors? I have 
>> poked around the wiki, but to no avail. Unless there is documentation on 
>> what needs to be done, doing it will be hopeless and waiting for the 
>> packaging system to updated means portmaster WILL be broken for some period 
>> of time.
> 
> Let me just say that I would really, really appriciate if we could keep such 
> a simple tool. Why does it suit us? Because we have a limited number of 
> systems, and they are all different meaning that we custom build for almost 
> every task. Portmaster makes very easy to build what we need on each host. 
> Yes, it brakes sometimes but it is not that hard to figure out how to get 
> around.

I want to reiterate that nobody is taking portmaster away from you. It simply 
has not been actively developed for years. In all likelihood, somebody will 
patch portmaster eventually. Poudriere is a safer, more capable tool than 
portmaster, and it's better to migrate when there's no immediate time pressure 
or breakage.

The changes are not about to drop. Portmaster is not going to stop working 
tomorrow. We are bringing it up now so that you have time to consider migrating 
to poudriere or synth. If your system(s) and workflow make poudriere a viable 
option, we want to encourage and help you to migrate while there's no time 
pressure.

Sending emails to this list about why you prefer portmaster doesn't change the 
underlying problem, though: portmaster will only be long-term viable if 
somebody actively develops it again.

# Adam


-- 
Adam Weinberger
ad...@adamw.org
https://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: The future of portmaster [and of ports-mgmt/synth]

[Steve Kargl]

On Wed, May 31, 2017 at 07:28:38PM +0200, Per olof Ljungmark wrote:
> 
> On 2017-05-31 02:10, Kevin Oberman wrote:
> > On Tue, May 30, 2017 at 2:53 PM, Mark Linimon  > > wrote:
> > 
> > On Tue, May 30, 2017 at 11:46:46PM +0200, Per olof Ljungmark wrote:
> > > Hello, I have not followed this thread before but just wanted to say
> > > that I use portmaster extensively, it works for us and I would miss
> > > it if it went.  Are there actually plans to retire it?
> > 
> > To reiterate the status:
> > 
> >   * some extensive changes to the ports framework are coming;
> >   * these will require large changes to all the port upgrade tools;
> >   * no one has stepped forwards to offer to do the work for anything
> > other than poudriere AFAIK.
> > 
> > If no one does the work, at the time the large changes come, the
> > other tools will break.
> > 
> > People have been wanting subpackages (aka flavors) for many years;
> > IIUC these are parts of the changes that are coming.
> > 
> > Someone needs to step forwards and say "yes, I will do the work."
> > 
> > mcl
> > 
> > Since portmaster is still popult and since the only solutions that looks 
> > to be available in the near term are pouderiere or raw make, neither 
> > terribly viable for many, I will look into updating portmaster to deal 
> > with 'flavors'. This looks fairly straight forward and I my have the sh 
> > capability to manage it. (And then again, I am far from a great shell 
> > person, so I may well be wrong.) I have looked at Doug's script and it 
> > is pretty readable, but writing may require help.
> > 
> > Can someone point me where to look for documentation on flavors? I have 
> > poked around the wiki, but to no avail. Unless there is documentation on 
> > what needs to be done, doing it will be hopeless and waiting for the 
> > packaging system to updated means portmaster WILL be broken for some 
> > period of time.
> 
> Let me just say that I would really, really appriciate if we could keep 
> such a simple tool. Why does it suit us? Because we have a limited 
> number of systems, and they are all different meaning that we custom 
> build for almost every task. Portmaster makes very easy to build what we 
> need on each host. Yes, it brakes sometimes but it is not that hard to 
> figure out how to get around.

+1

I have one i386 system (a laptop) with 1.5 GB of memory, at any
given time between 3-8 GB free diskspace, and a slow USB2 port.  
Poudriere and synth are simply overkill for maintaining ports 
for that laptop.

-- 
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow
___
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: The future of portmaster [and of ports-mgmt/synth]

[Per olof Ljungmark]

On 2017-05-31 02:10, Kevin Oberman wrote:
On Tue, May 30, 2017 at 2:53 PM, Mark Linimon > wrote:


On Tue, May 30, 2017 at 11:46:46PM +0200, Per olof Ljungmark wrote:
> Hello, I have not followed this thread before but just wanted to say
> that I use portmaster extensively, it works for us and I would miss
> it if it went.  Are there actually plans to retire it?

To reiterate the status:

  * some extensive changes to the ports framework are coming;
  * these will require large changes to all the port upgrade tools;
  * no one has stepped forwards to offer to do the work for anything
other than poudriere AFAIK.

If no one does the work, at the time the large changes come, the
other tools will break.

People have been wanting subpackages (aka flavors) for many years;
IIUC these are parts of the changes that are coming.

Someone needs to step forwards and say "yes, I will do the work."

mcl


Since portmaster is still popult and since the only solutions that looks 
to be available in the near term are pouderiere or raw make, neither 
terribly viable for many, I will look into updating portmaster to deal 
with 'flavors'. This looks fairly straight forward and I my have the sh 
capability to manage it. (And then again, I am far from a great shell 
person, so I may well be wrong.) I have looked at Doug's script and it 
is pretty readable, but writing may require help.


Can someone point me where to look for documentation on flavors? I have 
poked around the wiki, but to no avail. Unless there is documentation on 
what needs to be done, doing it will be hopeless and waiting for the 
packaging system to updated means portmaster WILL be broken for some 
period of time.


Let me just say that I would really, really appriciate if we could keep 
such a simple tool. Why does it suit us? Because we have a limited 
number of systems, and they are all different meaning that we custom 
build for almost every task. Portmaster makes very easy to build what we 
need on each host. Yes, it brakes sometimes but it is not that hard to 
figure out how to get around.

___
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: The future of portmaster [and of ports-mgmt/synth]

[Matthew Seaman]

On 2017/05/31 17:11, Roger Marquis wrote:
> Mark Linimon wrote:
>> * some extensive changes to the ports framework are coming;
> 
> Is there a URL (other than svnweb) where we can see a project plan for
> these changes?  As in the recent past (i.e., since 8-REL) the FreeBSD
> end-user community has reason to be worried that:
> 
>  * popular tools that were broken in the last major ports update (to
>  pkgng) will again not be considered part of the update,
> 
>  * developers and users of those tools will suffer the pain of
>  significant refactoring (again) and their Linux-advocating co-engineers
>  will be even more effective in reducing or eliminating FreeBSD in their
>  environments,
> 
>  * little discussion and few details will (again) be available before
>  the transition, and
> 
>  * it will (again) not occur exclusively on a major revision boundary.
> 
>  ** These concerns are not so much workload-related as much as they are
>  planning-related.
> 
> The lack of planning in previous ports/pkg updates was destructive and
> unnecessary.  Has anything changed?
> 
> Considering the delays in implementing base packages, pkg_audit that
> ignores base or recently deprecated ports and yet another major upgrade
> to the ports framework it should not need to be pointed out that our
> favorite OS has become far more difficult to update and maintain than
> any version of Linux.

Core has some proposals around planning for such changes that they will
be talking about during the BSDCan devsummit next week.  These should
also be published internally fairly soon afterwards for the benefit of
people not at BSDCan.

Cheers,

Matthew




signature.asc
Description: OpenPGP digital signature

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
+-+
biology/phyml   | 3.2.0   | 
v3.3.20170530
+-+
emulators/mame  | 0.166   | mame0186
+-+
emulators/mess  | 0.166   | mame0186
+-+
graphics/opencollada| 1.6.47  | v1.6.50
+-+
net/yaz | 5.21.1  | 5.22.0
+-+


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: The future of portmaster [and of ports-mgmt/synth]

[Gerard Seibert]

On Wed, 31 May 2017 09:11:23 -0700, Roger Marquis stated:

>Mark Linimon wrote:
>> * some extensive changes to the ports framework are coming;  
>
>Is there a URL (other than svnweb) where we can see a project plan for
>these changes?  As in the recent past (i.e., since 8-REL) the FreeBSD
>end-user community has reason to be worried that:
>
>  * popular tools that were broken in the last major ports update (to
>  pkgng) will again not be considered part of the update,
>
>  * developers and users of those tools will suffer the pain of
>  significant refactoring (again) and their Linux-advocating
> co-engineers will be even more effective in reducing or eliminating
> FreeBSD in their environments,
>
>  * little discussion and few details will (again) be available before
>  the transition, and
>
>  * it will (again) not occur exclusively on a major revision boundary.
>
>  ** These concerns are not so much workload-related as much as they
> are planning-related.
>
>The lack of planning in previous ports/pkg updates was destructive and
>unnecessary.  Has anything changed?
>
>Considering the delays in implementing base packages, pkg_audit that
>ignores base or recently deprecated ports and yet another major upgrade
>to the ports framework it should not need to be pointed out that our
>favorite OS has become far more difficult to update and maintain than
>any version of Linux.
>
>> * these will require large changes to all the port upgrade tools;
>> * no one has stepped forwards to offer to do the work for anything
>>   other than poudriere AFAIK.  
>
>Perhaps this is because many of us have not heard of the extensive
>changes coming to the ports framework until now much less had the
>opportunity to contribute to discussion much less policies that should
>guide it.
>
>> If no one does the work, at the time the large changes come, the
>> other tools will break.  
>
>Bottom line, these are not just tools breaking, this is FreeBSD
>breaking.
>
>IMO,
>Roger

I would like to add that I agree with Roger, especially the “major
revision boundary” statement. Many times in the past, I have done fresh
installs of new versions of FreeBSD only to have a significant change
in that version made, forcing me to recompile ports, etcetera. I now
see that “synth” is broken on FreeBSD-12. If history repeats itself, 12
will be released, then a significant change to the ports system
initiated forcing a recompilation of the ports, etcetera to get “synth”
working again. I am sure that there are lots of other programs in the
same predicament. This is just not acceptable. Before the next release
of FreeBSD, all the base programs should be updated to their newest
versions, the “default” versions of “perl,” “python,” etcetera should
be updated as required.

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

Re: Xorg error 'alphasort'

[Masachika ISHIZUKA]

  Hi.

  I was using 12-current r318249 and did 'pkg upgrade', and
could not start xorg with alphasort error.
  After updating r319315, xorg works again.
-- 
Masachika ISHIZUKA
___
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: The future of portmaster [and of ports-mgmt/synth]

[Roger Marquis]

Mark Linimon wrote:

* some extensive changes to the ports framework are coming;


Is there a URL (other than svnweb) where we can see a project plan for
these changes?  As in the recent past (i.e., since 8-REL) the FreeBSD
end-user community has reason to be worried that:

 * popular tools that were broken in the last major ports update (to
 pkgng) will again not be considered part of the update,

 * developers and users of those tools will suffer the pain of
 significant refactoring (again) and their Linux-advocating co-engineers
 will be even more effective in reducing or eliminating FreeBSD in their
 environments,

 * little discussion and few details will (again) be available before
 the transition, and

 * it will (again) not occur exclusively on a major revision boundary.

 ** These concerns are not so much workload-related as much as they are
 planning-related.

The lack of planning in previous ports/pkg updates was destructive and
unnecessary.  Has anything changed?

Considering the delays in implementing base packages, pkg_audit that
ignores base or recently deprecated ports and yet another major upgrade
to the ports framework it should not need to be pointed out that our
favorite OS has become far more difficult to update and maintain than
any version of Linux.


* these will require large changes to all the port upgrade tools;
* no one has stepped forwards to offer to do the work for anything
  other than poudriere AFAIK.


Perhaps this is because many of us have not heard of the extensive
changes coming to the ports framework until now much less had the
opportunity to contribute to discussion much less policies that should
guide it.


If no one does the work, at the time the large changes come, the
other tools will break.


Bottom line, these are not just tools breaking, this is FreeBSD
breaking.

IMO,
Roger
___
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: texinfo build failure

[Oleg V. Nauman]

On Tuesday 30 May 2017 16:09:56 Michael Butler wrote:
> Anyone care to address this?

 There is some really cryptic issue. texinfo port build completed successfully 
after both devel/libuv and lang/perl5.24 rebuild.

> 
> On 5/26/17 2:41 PM, Michael Butler wrote:
> > Is anyone else seeing this failure to build texinfo on -CURRENT?
> > 
> > cd doc && gmake TEXMF=/usr/local/share/texmf install-tex
> > gmake[3]: Entering directory
> > '/usr/ports/print/texinfo/work/texinfo-6.3/doc' test -n
> > "/usr/local/share/texmf" || (echo "TEXMF must be set." >&2; exit 1)
> > /bin/sh /usr/ports/print/texinfo/work/texinfo-6.3/build-aux/install-sh -d
> > /usr/ports/print/texinfo/work/stage/usr/local/share/texmf/tex/texinfo
> > /usr/ports/print/texinfo/work/stage/usr/local/share/texmf/tex/generic/eps
> > f install  -m 0644 ./texinfo.tex
> > /usr/ports/print/texinfo/work/stage/usr/local/share/texmf/tex/texinfo/texi
> > nfo.tex install  -m 0644 ./epsf.tex
> > /usr/ports/print/texinfo/work/stage/usr/local/share/texmf/tex/generic/epsf
> > /epsf.tex for f in txi-ca.tex txi-cs.tex txi-de.tex txi-en.tex txi-es.tex
> > txi-fr.tex txi-hu.tex txi-is.tex txi-it.tex txi-ja.tex txi-nb.tex
> > txi-nl.tex txi-nn.tex txi-pl.tex txi-pt.tex txi-ru.tex txi-sr.tex
> > txi-tr.tex txi-uk.tex; do \
> > 
> >install  -m 0644 ./$f
> > 
> > /usr/ports/print/texinfo/work/stage/usr/local/share/texmf/tex/texinfo/$f;
> > done
> > gmake[3]: Leaving directory
> > '/usr/ports/print/texinfo/work/texinfo-6.3/doc'
> > gmake[2]: Leaving directory '/usr/ports/print/texinfo/work/texinfo-6.3'
> > install  -m 0644 /usr/ports/distfiles/texinfo/6.3/htmlxref.cnf
> > /usr/ports/print/texinfo/work/stage/usr/local/share/texinfo
> > /bin/rmdir /usr/ports/print/texinfo/work/stage/usr/local/lib/texinfo
> > rmdir: /usr/ports/print/texinfo/work/stage/usr/local/lib/texinfo: No
> > such file or directory
> > *** Error code 1
> > 
> > Stop.
> > make[1]: stopped in /usr/ports/print/texinfo
> > *** Error code 1
> > 
> > Stop.
> > make: stopped in /usr/ports/print/texinfo
> > ** Command failed [exit code 1]: /usr/bin/script -qa
> > /tmp/portupgrade20170526-91663-1k3i9m0 env UPGRADE_TOOL=portupgrade
> > UPGRADE_PORT=texinfo-6.3_1,1 UPGRADE_PORT_VER=6.3_1,1 make
> > ** Fix the problem and try again.

___
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: The future of portmaster [and of ports-mgmt/synth]

[Jim Ohlstein]

On Wed, 2017-05-31 at 12:47 +, Gerard Seibert wrote:
> I would just like a clarification here. For the record, synth is
> broken
> on FreeBSD-11 and above with amd64. Is that correct?

My understanding was that the breakage is in gcc6-aux on 12-CURRENT
with 64 bit inodes.

I may be wrong...

-- 
Jim Ohlstein
Professional Mailman Hosting
https://mailman-hosting.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: The future of portmaster [and of ports-mgmt/synth]

[Gerard Seibert]

I would just like a clarification here. For the record, synth is broken
on FreeBSD-11 and above with amd64. Is that correct?

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

Re: The future of portmaster

[Torsten Zuehlsdorff]

On 30.05.2017 16:00, Adam Weinberger wrote:

On 30 May, 2017, at 7:51, Anton Shterenlikht 
wrote:


when portmaster have gone away?


What? WHAT?

portmaster going away???

I hope not

Anton


The ports tree continues to evolve. Major new features are planned
and in the process of being implemented. These changes will break all
the port-building tools.

poudriere and synth are actively developed, so they will quickly
support the new changes. portmaster and portupgrade are no longer
being actively developed, so it is anticipated that they will stop
working until somebody fixes them (if at all).


While i'm the maintainer of portmaster i want to emphasize this. Keeping 
portmaster up to date is very hard. Even small changes which are double 
checked already broke something. Its a little frustrating.


BUT: there is an ongoing attempt to rewrite portmaster with an 
test-driven approach to make live much easier. But this will take time.


When having a decent hardware poudriere and synth are a good choice, you 
should definitely check out!


Greetings,
Torsten


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