Re: Is there a way to subscribe to the commit messages for only ports you maintain?

[Willem Jan Withagen via freebsd-ports]

On 18-5-2021 03:56, Chris wrote:

On 2021-05-17 18:17, Julian H. Stacey wrote:

Chris wrote:

On 2021-05-17 16:30, Jan Beich wrote:
> Chris  writes:
>
>> I'd like to subscribe to the commit messages
>> ( dev-commits-ports-all )
>> but only receive messages that affect me -- the
>> ports I currently maintain. Is it possible? Or
>> am I just dreaming? ;-)
>
> No clue but I use Herald rules for something similar.
Thanks for the hints, Jan. :-)


Herald ? Nothing from
https://www.freebsd.org/cgi/ports.cgi?query=herald&stype=all&sektion=all
...
  https://en.wikipedia.org/wiki/Phabricator
...
https://cgit.freebsd.org/ports/tree/devel/phabricator/pkg-descr


I'd use /usr/ports/mail/procmail
https://lists.freebsd.org/pipermail/dev-commits-ports-all/2021-May/date.html
~/.procmailrc example:
:0 H
* ^Sender: owner-dev-commits-ports-...@freebsd.org
  {
  :0 H
  * ^Subject: git: .+ sysutils/rubygem-bolt
  | $RCVSTORE +dir_of_ports_you_might_maintain
  :0 H
  * ^Subject: git: .+ x11/xterm
  | $RCVSTORE +another_dir_of_ports_you_might_maintain
  }

or eg: # mkdir ~/Mail/your_ports
  :0 H
  * ^Sender: owner-dev-commits-ports-...@freebsd.org
  * ^Subject: git: .+
(archivers/bzip|audio/pocketsphinx|audio/snd|comms/pr|comms/sms_client|databases/pgaccess|devel/c2mdoc|devel/compiz-bcop|devel/ecgi|devel/codeville|devel/frink|dns/dnscheckengine|dns/ldapdns|graphics/gdtclft|graphics/gimmage|graphics/repng2jpeg|graphics/urt|lang/picoc|net/beacon|net/openradius|net/spread|net/wackamole|net-im/mbpurple|sysutils/cdroot|sysutils/ffs2recov|sysutils/rsyncbackup|textproc/asm2html|textproc/smi|textproc/sansi|www/spreadlogd|www/ttf2eot|x11/wmblob|x11/xvt|x11-themes/kde-icons-graphite-rade8|x11-toolkits/iwidgets|x11-wm/icewm) 


  | $RCVSTORE +your_ports


Wow! Thanks Julian. You even did all my homework for me.! ;-)
In fact I think your re would even satisfy Herald.


Yup, this is a great example.
I had been wining about the same problem in private, but dit not even 
realize that this list is available.


Perhaps this piece of code and suggestion for commits-ports-all could go 
into the porters manual?


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

Re: freebsd-ports Digest, Vol 933, Issue 7

[Willem Jan Withagen via freebsd-ports]

On 18-4-2021 16:51, Adriaan de Groot wrote:

On Sunday, 18 April 2021 14:00:01 CEST freebsd-ports-requ...@freebsd.org
wrote:

So perhaps that is the best way to avoid having to deal with ABI/API
breakage...
After that it is up to the maintainers of the dependant packages to
update their package and start using boost-1.75.

There is the implicit assumption that a patch that updates
boost for all the dependent ports should also provide fixes
if those ports fail to build after the update. That is
the major task.

There are "only" 490 ports that have boost in their Makefile.

Compare this to CMake, which has about 1900 direct consumers. While there's
less ABI-breakage and more configure- and build-time breakage, a CMake update
looks like this:
- build all the consumers with the current version of CMake
- fix the ones that don't build, or mark BROKEN
- bump CMake locally
- build everything again
- fix the ones that don't build

The actual CMake parts are the easy bits. Dealing with 15-year old C++ code
that happens to use CMake and falls over for totally unrelated reasons is the
real time sink. Ceph, too, is one of those things that eventually gets added
to my ignore list as "doesn't build in any recent ports checkout":

/usr/local/bin/ld: ../../../lib/libkv.a(LevelDBStore.cc.o):
(.data.rel.ro._ZTI17CephLevelDBLogger[_ZTI17CephLevelDBLogger]+0x10):
undefined reference to `typeinfo for leveldb::Logger'

I fix what I can, send mail to maintainers when I can't and so we hope that
progress happens

Hi Adriaan,

I understand your pain.

I'm in the squeeze that Ceph has moved to new version, which I do get to 
build/test
in my jenkins builders. But I'm/was sort of waiting for the move to git 
with ports.
And then figure out how to get things to work again with the latest 
release.

Unfortunately I got little time at the moment, so progress there is slow.

And you are right that it hard to find the cause for this, since so many 
things
have changed: Ceph source, Cmake config, llvm compiler and linker and 
leveldb.

So the permutations are plenty.

If you want to fix the above (which I also got in my builders, and have 
not found the

root cause for) you could add `-D WITH_LEVELDB=OFF` to the CMAKE options.
Hopefully I get around to submitting a patch to get ceph14 to v14.2.20 
real soon now.


--WjW

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

Re: Boost versions

[Willem Jan Withagen via freebsd-ports]

On 17-4-2021 13:09, Li-Wen Hsu wrote:

On Sat, Apr 17, 2021 at 6:58 PM Kurt Jaeger  wrote:


Hi!


Ceph has moved to Boost 1.75, so now it is build with the project.
Which is of course a pity.

Are there any plans to also get Boost 1.75 in ports?


There is this one PR which touches the topic:

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

It looks like a major undertaking!


Why is that?
If I look at what is in phabricator, the largest part is diffs on the
plist?



I don't think office@ currently has enough manpower to maintain boost
ports. I suggest we need to seek a new maintainer or form a group to
maintain it.

I am also interested in updating boost, but I don't think I can
maintain it solely. I can help on porting, allocating resource to
test, but I don't think I can fix all the issues during upgrading and
exp-run myself alone. I hope the maintenance of the  complex ports
like this can be a team work.

Is anyone interested in joining the effort?


I am importing boost 1.75 raw into Ceph, and build it there.
That seems to work for what ceph needs.

There used to be several versions of Boost in parallel.
So perhaps that is the best way to avoid having to deal with ABI/API 
breakage...

After that it is up to the maintainers of the dependant packages to
update their package and start using boost-1.75.

The report in bugzilla suggests that that is all what other maintainers ask.

Or am I too simple in thinking this?

--WjW


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

Re: Boost versions

[Willem Jan Withagen via freebsd-ports]

On 17-4-2021 14:16, Kurt Jaeger wrote:
Getting the port to build is one thing. 

Right that is probably not very complicated.
But the API/ABI changes are indeed a pain.
Reason for all kinds of trouble with Ceph as well.


There used to be several versions of Boost in parallel.

Yes. I have no idea how easy that would be.

Neither do I, it is just a vague recollection.
But there must be more libraries with that same challenge?


The bigger part is, as you described:


So perhaps that is the best way to avoid having to deal with ABI/API
breakage...
After that it is up to the maintainers of the dependant packages to
update their package and start using boost-1.75.

There is the implicit assumption that a patch that updates
boost for all the dependent ports should also provide fixes
if those ports fail to build after the update. That is
the major task.


There are "only" 490 ports that have boost in their Makefile.

Or am I too simple in thinking this?

No.

The normal way would be to provide the patch, testbuild all the
depends, list the broken ports in the PR and then a small group of
folks can try to fix them one by one.


I have no experience in that.
Keeping up with Ceph is already quite a task, since that is a very fast 
moving task.


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

Re: Boost versions

[Willem Jan Withagen via freebsd-ports]

On 17-4-2021 13:09, Li-Wen Hsu wrote:

On Sat, Apr 17, 2021 at 6:58 PM Kurt Jaeger  wrote:


Hi!


Ceph has moved to Boost 1.75, so now it is build with the project.
Which is of course a pity.

Are there any plans to also get Boost 1.75 in ports?


There is this one PR which touches the topic:

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

It looks like a major undertaking!


Why is that?
If I look at what is in phabricator, the largest part is diffs on the
plist?



I don't think office@ currently has enough manpower to maintain boost
ports. I suggest we need to seek a new maintainer or form a group to
maintain it.

I am also interested in updating boost, but I don't think I can
maintain it solely. I can help on porting, allocating resource to
test, but I don't think I can fix all the issues during upgrading and
exp-run myself alone. I hope the maintenance of the  complex ports
like this can be a team work.

Is anyone interested in joining the effort?


I am importing boost 1.75 raw into Ceph, and build it there.
That seems to work for what ceph needs.

There used to be several versions of Boost in parallel.
So perhaps that is the best way to avoid having to deal with ABI/API 
breakage...

After that it is up to the maintainers of the dependant packages to
update their package and start using boost-1.75.

The report in bugzilla suggests that that is all what other maintainers ask.

Or am I too simple in thinking this?

--WjW


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

Boost versions

[Willem Jan Withagen via freebsd-ports]

Hi,

Ceph has moved to Boost 1.75, so now it is build with the project.
Which is of course a pity.

Are there any plans to also get Boost 1.75 in ports?

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

Using Boost 1.74

[Willem Jan Withagen]

Hi,

Ceph development start using Boost 1.74, and they load the sources 
during building.
Now before I embark on the journey to "fix" that in package building and 
get

things loaded before the the actual make starts I would like to know...

Is there any work in progress to move to Boosst 1.74??

Thanx,
--WjW

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

What is: py3kplist???

[Willem Jan Withagen]

Hi,

In my ceph port one of the maintainers added this to

USE_PYTHON= cython py3kplist

But I'm trying to find out what it does?
And it is not (yet) on the USE_PYTHON page in the ports handbook.

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

cannot run make in ports directory...

[Willem Jan Withagen]

Hi,

I know that there are other ways to us...
But still this is probably just a coding error

FreeBSD 13.0-CURRENT #0 r363032: Thu Jul  9 04:13:17 UTC 2020 
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC



root@quad-a:/usr/home/wjw # cd /usr/ports/sysutils/storcli/
root@quad-a:/usr/ports/sysutils/storcli # make install
make: "/usr/ports/Mk/bsd.port.mk" line 2096: warning: String comparison 
operator should be either == or !=
make: "/usr/ports/Mk/bsd.port.mk" line 2096: Malformed conditional 
(defined(MAKE_JOBS_NUMBER_LIMIT) && ( ${MAKE_JOBS_NUMBER_LIMIT} < 
${_MAKE_JOBS_NUMBER} ))

make: Fatal errors encountered -- cannot continue
make: stopped in /usr/ports/sysutils/storcli

So I just edit/comment these lines to get allong.

But fixing this would be nice.

--WjW

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

Re: Getting dovecot to use the openssl from ports

[Willem Jan Withagen]

On 29-5-2020 11:31, Willem Jan Withagen wrote:

On 29-5-2020 00:56, Carmel NY wrote:

On Thu, 28 May 2020 23:36:46 +0200, Willem Jan Withagen stated:

On 28-5-2020 16:53, Carmel NY wrote:

On Thu, 28 May 2020 16:25:20 +0200, Willem Jan Withagen stated:

Hi,

I'm trying to get dovecot to use the openssl from ports in
/usr/local/lib. But whatever I try, en en op with cryptostuff from
/usr/lib

I think the correct way is to set
etc/make.conf
      DEFAULT_VERSIONS+=ssl=openssl

En though when making tells me:
     dovecot-2.3.10.1 depends on file:
/usr/local/lib/libcrypto.so.11 - found

I end up with:
/usr/local/libexec/dovecot/imap-login:
      libdovecot-login.so.0 =>
/usr/local/lib/dovecot/libdovecot-login.so.0 (0x80120a000)
      libdovecot.so.0 => /usr/local/lib/dovecot/libdovecot.so.0
(0x801422000)
      libc.so.7 => /lib/libc.so.7 (0x800825000)
      libssl.so.8 => /usr/lib/libssl.so.8 (0x8017c5000)
      libcrypto.so.8 => /lib/libcrypto.so.8 (0x801c0)

Which the crypto stuff from BASE

But I have available
root@mailserver:/ # ls /usr/local/lib/libcrypto.so.11
/usr/local/lib/libcrypto.so.11

What am I missing here?

How are you attempting to build the port?

I realized this after posting, but I did this by what I'm used to doing
since 1993:
 cd /usr/ports/mail/dovecot
 make install

But even if I use poudriere it still uses what is in base.

Are you sure you modified the correct "make.conf" file? Specifically:

/usr/local/etc/poudriere.d/make.conf

This is what you should have in that file:

DEFAULT_VERSIONS+=ssl=openssl

Make sure to update the ports tree in poudriere, and then try
rebuilding "dovecot". Once it rebuilds it, look at the build log and
see if it shows any obvious errors.


I have build env.s for several releases on this server
And it is always a trick to get it in the right one.
Trying yours as we speak.


Right that helped

root@test:/tmp/usr/local/lib/dovecot # ldd ./libdovecot-login.so.0.0.0
./libdovecot-login.so.0.0.0:
    libdovecot.so.0 => not found (0)
    libssl.so.11 => /usr/local/lib/libssl.so.11 (0x800683000)
    libcrypto.so.11 => /usr/local/lib/libcrypto.so.11 (0x801018000)
    libc.so.7 => /lib/libc.so.7 (0x800245000)
    libthr.so.3 => /lib/libthr.so.3 (0x800719000)

Now wait for a silent moment on the server to actually install this package
and find out if it really helps.

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

Re: Getting dovecot to use the openssl from ports

[Willem Jan Withagen]

On 29-5-2020 00:56, Carmel NY wrote:

On Thu, 28 May 2020 23:36:46 +0200, Willem Jan Withagen stated:

On 28-5-2020 16:53, Carmel NY wrote:

On Thu, 28 May 2020 16:25:20 +0200, Willem Jan Withagen stated:

Hi,

I'm trying to get dovecot to use the openssl from ports in
/usr/local/lib. But whatever I try, en en op with cryptostuff from
/usr/lib

I think the correct way is to set
etc/make.conf
      DEFAULT_VERSIONS+=ssl=openssl

En though when making tells me:
     dovecot-2.3.10.1 depends on file:
/usr/local/lib/libcrypto.so.11 - found

I end up with:
/usr/local/libexec/dovecot/imap-login:
      libdovecot-login.so.0 =>
/usr/local/lib/dovecot/libdovecot-login.so.0 (0x80120a000)
      libdovecot.so.0 => /usr/local/lib/dovecot/libdovecot.so.0
(0x801422000)
      libc.so.7 => /lib/libc.so.7 (0x800825000)
      libssl.so.8 => /usr/lib/libssl.so.8 (0x8017c5000)
      libcrypto.so.8 => /lib/libcrypto.so.8 (0x801c0)

Which the crypto stuff from BASE

But I have available
root@mailserver:/ # ls /usr/local/lib/libcrypto.so.11
/usr/local/lib/libcrypto.so.11

What am I missing here?

How are you attempting to build the port?
  

I realized this after posting, but I did this by what I'm used to doing
since 1993:
     cd /usr/ports/mail/dovecot
     make install

But even if I use poudriere it still uses what is in base.

Are you sure you modified the correct "make.conf" file? Specifically:

/usr/local/etc/poudriere.d/make.conf

This is what you should have in that file:

DEFAULT_VERSIONS+=ssl=openssl

Make sure to update the ports tree in poudriere, and then try
rebuilding "dovecot". Once it rebuilds it, look at the build log and
see if it shows any obvious errors.


I have build env.s for several releases on this server
And it is always a trick to get it in the right one.
Trying yours as we speak.

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

Re: Getting dovecot to use the openssl from ports

[Willem Jan Withagen]

On 28-5-2020 16:53, Carmel NY wrote:

On Thu, 28 May 2020 16:25:20 +0200, Willem Jan Withagen stated:

Hi,

I'm trying to get dovecot to use the openssl from ports in
/usr/local/lib. But whatever I try, en en op with cryptostuff from
/usr/lib

I think the correct way is to set
etc/make.conf
     DEFAULT_VERSIONS+=ssl=openssl

En though when making tells me:
    dovecot-2.3.10.1 depends on file: /usr/local/lib/libcrypto.so.11 -
found

I end up with:
/usr/local/libexec/dovecot/imap-login:
     libdovecot-login.so.0 =>
/usr/local/lib/dovecot/libdovecot-login.so.0 (0x80120a000)
     libdovecot.so.0 => /usr/local/lib/dovecot/libdovecot.so.0
(0x801422000)
     libc.so.7 => /lib/libc.so.7 (0x800825000)
     libssl.so.8 => /usr/lib/libssl.so.8 (0x8017c5000)
     libcrypto.so.8 => /lib/libcrypto.so.8 (0x801c0)

Which the crypto stuff from BASE

But I have available
root@mailserver:/ # ls /usr/local/lib/libcrypto.so.11
/usr/local/lib/libcrypto.so.11

What am I missing here?

How are you attempting to build the port?


I realized this after posting, but I did this by what I'm used to doing
since 1993:
    cd /usr/ports/mail/dovecot
    make install

But even if I use poudriere it still uses what is in base.

--WjW

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

Getting dovecot to use the openssl from ports

[Willem Jan Withagen]

Hi,

I'm trying to get dovecot to use the openssl from ports in /usr/local/lib.
But whatever I try, en en op with cryptostuff from /usr/lib

I think the correct way is to set
etc/make.conf
    DEFAULT_VERSIONS+=ssl=openssl

En though when making tells me:
   dovecot-2.3.10.1 depends on file: /usr/local/lib/libcrypto.so.11 - found

I end up with:
/usr/local/libexec/dovecot/imap-login:
    libdovecot-login.so.0 => 
/usr/local/lib/dovecot/libdovecot-login.so.0 (0x80120a000)
    libdovecot.so.0 => /usr/local/lib/dovecot/libdovecot.so.0 
(0x801422000)

    libc.so.7 => /lib/libc.so.7 (0x800825000)
    libssl.so.8 => /usr/lib/libssl.so.8 (0x8017c5000)
    libcrypto.so.8 => /lib/libcrypto.so.8 (0x801c0)

Which the crypto stuff from BASE

But I have available
root@mailserver:/ # ls /usr/local/lib/libcrypto.so.11
/usr/local/lib/libcrypto.so.11

What am I missing here?

--WjW

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

Re: [RFC] Adding a Rados block driver to bhyve

[Willem Jan Withagen]

On 10-3-2020 16:15, Alan Somers wrote:
On Tue, Mar 10, 2020 at 3:59 AM Willem Jan Withagen <mailto:w...@digiware.nl>> wrote:


On 9-3-2020 14:46, Alan Somers wrote:

On Mon, Mar 9, 2020 at 4:32 AM Willem Jan Withagen
mailto:w...@digiware.nl>> wrote:

Hi all,

And sorry for crosspoing three groups, but the answer
can/could be a mix
of things to do in these three areas.

I have a prototype of bhyve running on Rados/Ceph working:
https://github.com/freebsd/freebsd/pull/426


..


4) Create a bhyve-blockrbd port.
 This is much like 3) but instead of building a bhyve-rbd
executable,
 it delivers a libblockrbd.so that is dynamically
loadable by the
 standaard bhyve that comes with base.




> Great work!  I also agree that option 4 sounds like the best. 
There's precedent for ports that
> require the FreeBSD Sources.  For example, see devel/py-libzfs
or emulators/virtualbox-ose.
> You just need to define the SRC_BASE variable.
Hi Alan,

Thanx for the hint, and it made me check what is actually
available within the poudriere jail
And that does have full source, so the Makefile code is mainly for
those that build in a different way.

I've got a proto version working when compiling stuff with `make
buildworld`, but run in the
problem that libblock_rbd.so is stripped in such a way that the
symbol I need is removed.
Using the unstripped version does work.

Is there an incantation for the SRC Makefiles that builds a
dynamical loadable lib??
And I'm still looking for a PORTS example of building a dynamical
loadable lib.
Or is there no generic code for that in the PORTS Mk files?

--WjW

BTW: Still haven't worked in your AIO code :(


There are plenty of dynamic libraries built with the SRC makefiles.  
For example, 
https://svnweb.freebsd.org/base/head/lib/libbsdstat/Makefile?view=markup 
.


That looks dangerously close to what I have for libblock_rbd.
===
> cat Makefile-librbd
#
# $FreeBSD$
#

PACKAGE=lib${LIB}

.include 

LIB=    block_rbd
SHLIB_MAJOR=    1

SRCS=   block_rbd.c

CFLAGS+=-I${SRCTOP}/sys
CFLAGS+=-g -O0 -fPIC -rdynamic
LDFLAGS+=-Wl,-export-dynamic,-Bdynamic
CFLAGS+=-DWITHOUT_CAPSICUM

LOCALBASE?= /usr/local
CFLAGS+=    -I${LOCALBASE}/include
LDFLAGS+=   -L${LOCALBASE}/lib -lrados -lrbd

WARNS?= 2

===

This is the code that mk.lib.bsd runs:
objcopy --only-keep-debug libblock_rbd.so.1.full libblock_rbd.so.1.debug
objcopy --strip-debug --add-gnu-debuglink=libblock_rbd.so.1.debug 
libblock_rbd.so.1.full libblock_rbd.so.1


So still I get a stripped lib in /usr/lib. And then the one and only 
symbol I need to load

is not found. Copying libblock_rbd.so.1.full actually works for me.

So either I'm doing it the wrong way, like special options on the 
symbols oid.

Or mk.lib.bsd cannot deliver dlopen/dlsym-able files?

And there are plenty of ports that build shared libraries too, just look 
at /usr/local/lib/*.so.  However, the ports framework doesn't have much 
special code just to support building libraries.  Instead the hard work 
is always done by the ports themselves.  Some use autotools, some cmake, 
etc etc.  The simplest port I can find that uses both SRC_BASE and 
INSTALL_LIB is this one: 
https://svnweb.freebsd.org/ports/head/devel/linux_libusb/ .


Oke thanx, I'll have a look at it, and given that I can see most of the 
compile build stuff

in the SRC_BASE version I'll get it to work.

--WjW

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

Re: [RFC] Adding a Rados block driver to bhyve

[Willem Jan Withagen]

On 9-3-2020 14:46, Alan Somers wrote:
On Mon, Mar 9, 2020 at 4:32 AM Willem Jan Withagen <mailto:w...@digiware.nl>> wrote:


Hi all,

And sorry for crosspoing three groups, but the answer can/could be
a mix
of things to do in these three areas.

I have a prototype of bhyve running on Rados/Ceph working:
https://github.com/freebsd/freebsd/pull/426


..


4) Create a bhyve-blockrbd port.
 This is much like 3) but instead of building a bhyve-rbd
executable,
 it delivers a libblockrbd.so that is dynamically loadable by the
 standaard bhyve that comes with base.




> Great work!  I also agree that option 4 sounds like the best. There's 
precedent for ports that
> require the FreeBSD Sources.  For example, see devel/py-libzfs or 
emulators/virtualbox-ose.

> You just need to define the SRC_BASE variable.
Hi Alan,

Thanx for the hint, and it made me check what is actually available 
within the poudriere jail
And that does have full source, so the Makefile code is mainly for those 
that build in a different way.


I've got a proto version working when compiling stuff with `make 
buildworld`, but run in the
problem that libblock_rbd.so is stripped in such a way that the symbol I 
need is removed.

Using the unstripped version does work.

Is there an incantation for the SRC Makefiles that builds a dynamical 
loadable lib??
And I'm still looking for a PORTS example of building a dynamical 
loadable lib.

Or is there no generic code for that in the PORTS Mk files?

--WjW

BTW: Still haven't worked in your AIO code :(


___
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: [RFC] Adding a Rados block driver to bhyve

[Willem Jan Withagen]

On 9-3-2020 12:38, Miroslav Lachman wrote:

Willem Jan Withagen wrote on 2020/03/09 11:31:

[...]


3) Create a bhyve-rbd port.
 Problem with that is that it will require the FreeBSD source tree 
for the

 bhyve sources, but there is no Ports option for that?
     Or bhyve sources are manually copied into the port. And then
 try to keep these sources up to date.
 Then compile and install a bhyve-rbd into /usr/local/sbin


There are some ports (for example sysutils/lsof) which need kernel 
sources to build. So this can be a way too. I cannot say if this is the 
best way or not.


Yes, there seems a flag for kernel sources...
But not for world-sources.??

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

[RFC] Adding a Rados block driver to bhyve

[Willem Jan Withagen]

Hi all,

And sorry for crosspoing three groups, but the answer can/could be a mix
of things to do in these three areas.

I have a prototype of bhyve running on Rados/Ceph working:
    https://github.com/freebsd/freebsd/pull/426

But there are a few catches on how to get it in the FreeBSd sources...

1) Easiest would be to just compile it in with the code of the current 
bhyve.

    That will require librados/librbd libraries...
    Ceph of this purpose is LGPL2/3 and could go into contrib.
    In this case bhyve will hold the rbd-driver by default and a user 
does not

    need to do anything by himself
    But I have the feeling that this is the most unwanted scenario

2) User first installs a Ceph package and FreeBSD sources, and then 
recompiles

    bhyve with the option BHYVE_RBD.
    And then reinstalls this new version as bhyve or bhyve-rbd in /usr/sbin

3) Create a bhyve-rbd port.
    Problem with that is that it will require the FreeBSD source tree 
for the

    bhyve sources, but there is no Ports option for that?
    Or bhyve sources are manually copied into the port. And then
    try to keep these sources up to date.
    Then compile and install a bhyve-rbd into /usr/local/sbin

4) Create a bhyve-blockrbd port.
    This is much like 3) but instead of building a bhyve-rbd executable,
    it delivers a libblockrbd.so that is dynamically loadable by the
    standaard bhyve that comes with base.

    For this bhyve needs to be extended with dynamic loadable driver 
modules.
    This is reasonably doable, but is this acceptable for the bhyve 
maintainers?


    For building the port, the bhyve-blockrbd code will only need a 
limited set
    of files from /usr/src/usr.bin/bhyve thus limiting the chance of 
running out

    sequence with the bhyve from base.

Looking over these 4 options, I think that 4 is the most desirable one?
But 2 would parhaps be workable for users as well, but the project might 
think

otherwise.

Are there other options?
And/or is 4 the best way to go, with 2 as a nice intermediate?

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

Re: About protocols in openssl

[Willem Jan Withagen]

On 28-2-2020 01:32, Marcin Cieslak wrote:

On Thu, 27 Feb 2020, Willem Jan Withagen wrote:

/home/jenkins/workspace/ceph-master/src/pybind/mgr/.tox/py3/lib/python3.7/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so: 
Undefined symbol "SSLv3_client_method"


This looks to me that you are trying to build ceph in the virtualenv 
which probably

pulls required python packages on its own.

Can you make it to depend and use the existing 
security/py-cryptography port?


I don't know how exactly the ceph port is supposed to work but it 
seems to

require virtualenv for its inner workings. You might want to force
virtual env to use FreeBSD-provided libraries with --system-site-packages
but AFAIK it will no longer download anything, i.e. all dependencies
need to packaged.

Interesting, since virtualenv/tox is used during testing with Continuous 
Integration.
And there is where I need the stuff, the port/package comes without the 
testing stuff.
People that want to develop stuff for Ceph really should use what is in 
the Git repo.



I have just ran "make test" in my ports tree to test py-cryptography
and got 1 error (TestECDSACertificate.test_load_ecdsa_no_named_curve)
but nothing related to SSLv3_client_method being not there.
I guess that is because the ports one does not require SSLv3, and is not 
complaining about missing it.
Like you said, very likely virtualenv has pulled its own stuff, and that 
will require SSLv3

Which is no longer available by default  in openSSL in ports.

I'll try and see if I can get away with --system-site-packages, and 
loading tons op packages.


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

Re: About protocols in openssl

[Willem Jan Withagen]

On 27-2-2020 21:53, Mathieu Arnold wrote:

On Thu, Feb 27, 2020 at 12:45:51PM -0800, Freddie Cash wrote:

On Thu, Feb 27, 2020, 12:37 PM Willem Jan Withagen,  wrote:


Interesting, but not quite what I want
It is not for personal usage, but for ports that I have commited to the
ports collection, and want to upgrade.
And yes, fixing openssl works for this problem, but it is not only my
problem.

I maintain these Ceph ports, and now upstream uses a python module that
expects SSlv3 to be available in the openssl that encounters on the system.
And the question is how to accommodate that?
Short of embedding my own openssl libs with the ceph-libs, thus creating
a huge maintenance problem.

I could also argue that switching of SSLv3 in a generic library is sort
of impractical, even if it is a protocol that we want to erradicate.
But I guess that the maintainers of openssl have decided that this is
the smart thing to do.
And I'm in peace with that, but now require an escape from this catch-22.

--WjW


There's no mechanism in the ports tree framework for port X to depend on
feature Y being enabled in port Z.

All you can do is add a pkg-message alert to your ceph port saying the use
needs to compile the openssl port with SSLv3 enabled.

You could create a slave port for openssl that has that option enabled,
then depend on that slave port. But that might create dependency issues
elsewhere.

You can do it, but nobody will commit that kind of change.  The choice
of which OpenSSL version to use is a user facing change, and it is done
globally.

As a side note, SSLv3 is going away, anything done right now that needs
it is doomed.
I wholehartedly agree, SSLv3 is a pain that should go. I've excluded it 
on webservers

already for ages. And TLS1 and TLS1.1 going down the same path.

But none the less I run into this problem that a python module
does not want to load because the includes .so is looking for SSLv3 
stuff during.


Adding a openssl port with SSLv3 enabled would be an option, and as long 
a it

builds on the regular openssl port it would be a compatible library.
I only fear for the tantrum that `pkg install` is going to throw, when 
install

openssl-sslv3 is going to override openssl. Nothing but matching paths.
Doubt if that is going to be workable?

--WjW

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

Re: About protocols in openssl

[Willem Jan Withagen]

On 27-2-2020 20:52, Pete Wright wrote:



On 2020-02-27 11:42, Willem Jan Withagen wrote:

On 27-2-2020 20:25, Miroslav Lachman wrote:

Willem Jan Withagen wrote on 2020/02/27 20:00:

Hi,

My ceph ports uses all kinds of python stuff, and now the trouble 
is that I'm getting

an error on missing:
 SSLv3_client_method

Which i guess, is because in the current openssl libs SSLv3 is 
disabled.

And I sort of get this, SSLv3 is unsafe.

But I need it to be able to run parts of the ceph port.

So how do I get a openssl lib dependancy that has SSLv3 enabled.


You can build OpenSSL 1.1.1 from the ports where you can enable 
SSLv3 in the options dialog.


https://www.freshports.org/security/openssl/

The defaults are:
> Protocol Support
NEXTPROTONEG=on: Next Protocol Negotiation (SPDY)
SCTP=on: SCTP (Stream Control Transmission)
SSL3=off: SSLv3 (unsafe)
TLS1=on: TLSv1.0 (requires TLS1_1, TLS1_2)
TLS1_1=on: TLSv1.1 (requires TLS1_2)
TLS1_2=on: TLSv1.2


Yup, this is what I did, and that works.
But how do I do that for a port? And the make sure that the installer 
of the ceph-package gets an openssl that had SSLv3
It may be best to build an internal package with the options you need 
configured accordingly.  I do this via poudriere for some of my 
internal software.  For example I have this file on my package builder:

/usr/local/etc/poudriere.d/make.conf

which contains the following:
x11-servers_xorg-server_SET=FIXDRM

I think this matches the same format of make.conf you would use if 
building the ports tree locally.


Interesting, but not quite what I want
It is not for personal usage, but for ports that I have commited to the 
ports collection, and want to upgrade.
And yes, fixing openssl works for this problem, but it is not only my 
problem.


I maintain these Ceph ports, and now upstream uses a python module that 
expects SSlv3 to be available in the openssl that encounters on the system.

And the question is how to accommodate that?
Short of embedding my own openssl libs with the ceph-libs, thus creating 
a huge maintenance problem.


I could also argue that switching of SSLv3 in a generic library is sort 
of impractical, even if it is a protocol that we want to erradicate.
But I guess that the maintainers of openssl have decided that this is 
the smart thing to do.

And I'm in peace with that, but now require an escape from this catch-22.

--WjW

___
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: About protocols in openssl

[Willem Jan Withagen]

On 27-2-2020 20:25, Miroslav Lachman wrote:

Willem Jan Withagen wrote on 2020/02/27 20:00:

Hi,

My ceph ports uses all kinds of python stuff, and now the trouble is 
that I'm getting

an error on missing:
 SSLv3_client_method

Which i guess, is because in the current openssl libs SSLv3 is disabled.
And I sort of get this, SSLv3 is unsafe.

But I need it to be able to run parts of the ceph port.

So how do I get a openssl lib dependancy that has SSLv3 enabled.


You can build OpenSSL 1.1.1 from the ports where you can enable SSLv3 
in the options dialog.


https://www.freshports.org/security/openssl/

The defaults are:
> Protocol Support
NEXTPROTONEG=on: Next Protocol Negotiation (SPDY)
SCTP=on: SCTP (Stream Control Transmission)
SSL3=off: SSLv3 (unsafe)
TLS1=on: TLSv1.0 (requires TLS1_1, TLS1_2)
TLS1_1=on: TLSv1.1 (requires TLS1_2)
TLS1_2=on: TLSv1.2


Yup, this is what I did, and that works.
But how do I do that for a port? And the make sure that the installer of 
the ceph-package gets an openssl that had SSLv3


--WjW

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

About protocols in openssl

[Willem Jan Withagen]

Hi,

My ceph ports uses all kinds of python stuff, and now the trouble is 
that I'm getting

an error on missing:
    SSLv3_client_method

Which i guess, is because in the current openssl libs SSLv3 is disabled.
And I sort of get this, SSLv3 is unsafe.

But I need it to be able to run parts of the ceph port.

So how do I get a openssl lib dependancy that has SSLv3 enabled.

WjW

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

c = (_s=3, val='_exception: 
/home/jenkins/workspace/ceph-master/src/pybind/mgr/.to...ion 
AsyncCompletion._on_complete..run at 0x80d5613b0>, id=34580530768, 
name=_create_grafana, pr=NA, _next=None)

def raise_if_exception(c):
# type: (Completion) -> None
"""
:raises OrchestratorError: Some user error or a config error.
:raises Exception: Some internal error
"""
if c.serialized_exception is not None:
try:
e = pickle.loads(c.serialized_exception)
except (KeyError, AttributeError):
raise Exception('{}: {}'.format(type(c.exception), c.exception))

  raise e

E   ImportError: 
/home/jenkins/workspace/ceph-master/src/pybind/mgr/.tox/py3/lib/python3.7/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
 Undefined symbol "SSLv3_client_method"

orchestrator/_interface.py:701: ImportError
-- Captured log call ---
ERRORorchestrator._interface:_interface.py:391 _Promise failed
Traceback (most recent call last):
  File "/home/jenkins/workspace/ceph-master/src/pybind/mgr/cephadm/module.py", 
line 334, in do_work
res = self._on_complete_(*args, **kwargs)
  File "/home/jenkins/workspace/ceph-master/src/pybind/mgr/cephadm/module.py", 
line 398, in call_self
return f(self, *inner_args)
  File "/home/jenkins/workspace/ceph-master/src/pybind/mgr/cephadm/module.py", 
line 2352, in _create_grafana
return self._create_daemon('grafana', daemon_id, host)
  File "/home/jenkins/workspace/ceph-master/src/pybind/mgr/cephadm/module.py", 
line 1874, in _create_daemon
j = self._generate_grafana_config()
  File "/home/jenkins/workspace/ceph-master/src/pybind/mgr/cephadm/module.py", 
line 2288, in _generate_grafana_config
cert, pkey = create_self_signed_cert('Ceph', 'cephadm')
  File "/home/jenkins/workspace/ceph-master/src/pybind/mgr/mgr_util.py", line 
134, in create_self_signed_cert
from OpenSSL import crypto
  File 
"/home/jenkins/workspace/ceph-master/src/pybind/mgr/.tox/py3/lib/python3.7/site-packages/OpenSSL/__init__.py",
 line 8, in 
from OpenSSL import crypto, SSL
  File 
"/home/jenkins/workspace/ceph-master/src/pybind/mgr/.tox/py3/lib/python3.7/site-packages/OpenSSL/crypto.py",
 line 15, in 
from OpenSSL._util import (
  File 
"/home/jenkins/workspace/ceph-master/src/pybind/mgr/.tox/py3/lib/python3.7/site-packages/OpenSSL/_util.py",
 line 6, in 
from cryptography.hazmat.bindings.openssl.binding import Binding
  File 
"/home/jenkins/workspace/ceph-master/src/pybind/mgr/.tox/py3/lib/python3.7/site-packages/cryptography/hazmat/bindings/openssl/binding.py",
 line 15, in 
from cryptography.hazmat.bindings._openssl import ffi, lib
ImportError: 
/home/jenkins/workspace/ceph-master/src/pybind/mgr/.tox/py3/lib/python3.7/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
 Undefined symbol "SSLv3_client_method"

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

Bug 244099 - [PATCH] net/ceph14: upgrade to 14.2.7 with dashboard

[Willem Jan Withagen]

Can one of the commiters please pickup this update?

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

Re: Debugging build with gmake, running npm toolchain

[Willem Jan Withagen]

On 13-2-2020 15:20, Stefan Bethke wrote:



Am 13.02.2020 um 14:42 schrieb Marcin Cieslak :

On Wed, 12 Feb 2020, Stefan Bethke wrote:


The second issue is that npm install is invoked, which will most likely prevent 
the port to be built as a package. Is there a way to handle the download of the 
package-lock.json dependencies in the fetch stage?

I have some hack in my private node-sass port: 
https://github.com/saper/ports-exp/tree/master/textproc/node-sass

jrm@ has solved this in the late net-im/mastodon port by simply putting all 
JavaScript together
in one tarball: 
https://svnweb.freebsd.org/ports/head/net-im/mastodon/?pathrev=472547

https://ftfl.ca/blog/2017-05-23-mastodon-freebsd.html

The port got removed in https://svnweb.freebsd.org/ports?view=revision&revision=474751 


Thanks for the pointers!

I'm currently trying to convince upstream to package the dependencies as 
vendor-like archives (for both Go modules and npms) and deploy them alongside 
the source release archive. That would allow me to treat these as additional 
distfiles, and simply unpack them into $WRKSRC.

I'm hoping that this would make the maintenance of the port halfway reasonable.


I have the same issue in my ceph ports, where the dashboard is build 
using npm.


Tarring up the result and download that during the fetch phase is one of 
the solutions that was offered to me as well.
But then I am responsible for maintaining again another set of data to 
keep updated.
Another disadvantage of tarring is that that adds another dependency for 
the maintainer to keep.
Note that updating the tar, will require updating the port to fix the 
checksum.
(unless one really hardcore manually fetches the tar in post_fetch, 
without caring about integrity)


For now it have chosen for the following, easy way out:
    - require npm as runtime dependency
    - include the build list/json config in the package
    - explain in pkg-message how to actual let the user do it by 
him/herself.


The disadvantage of this is a large wagonload of node packages that gets 
downloaded in the code cache.
Something that is not an issue when tarring up the actual code for the 
dashboard.


--WjW



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

new update for ceph13

[Willem Jan Withagen]

Hi,

Could any of the port committers pickup:

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

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

Re: packaging a port that uses npm during build.

[Willem Jan Withagen]

On 30-10-2019 18:12, Yuri wrote:

On 2019-10-28 04:17, Willem Jan Withagen wrote:


I think I read once somewhere that there is also a "flag" that 
indicates that the port wants network access during the build. Is 
that feasible? 



No, this isn't/shouldn't be possible.


Please look at how misc/netron is done. It pre-packages NPM modules 
into a separate distfile.



CAVEAT: Please keep in mind that NodeJS downloads JS files from a 
multitude of GitHub locations, which makes this technology 
fundamentally insecure because any malicious  or otherwise harmful 
change in any of the hundreds of projects would be automatically 
propagated into the FreeBSD package and further to the users. For this 
reason NodeJS software is less secure and for example RPM and Debian 
packages often (or always) just don't include such software into their 
distributions.



misc/netron only has a few js files installed so it is okay. You can 
also do the same with more complex projects, with the above caveat.


Yes,
I know, ans sympatise with your concerns. But then this is a port
and I don't make the rules in the project.

I'll take a look.

But my project includes about a npm 62 toplevel packages. :-(
and many more getting installed as extra dependancies.
So that is not really an option.
___
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: packaging a port that uses npm during build.

[Willem Jan Withagen]

On 29-10-2019 01:41, Adam Weinberger wrote:

On Mon, Oct 28, 2019 at 6:34 AM Willem Jan Withagen  wrote:

On 28-10-2019 13:28, Adam Weinberger wrote:

On Mon, Oct 28, 2019 at 5:17 AM Willem Jan Withagen  wrote:

Hi,

The ceph ports should have a manager module called dashboard that
exists of a large bundle op JS-scripts that get installed with npm/node
during running make on the configured build.

Uptil now I've exclude that from builds, but that gets more and more
complicated. Ceph cluster status is not reported not healty if the
dashboard is not running

Apart from the fact that npm does not like to be ran as 'root',
poudriere also complains about fetching data afte the fetch fase.

There are about 1000 npm-modules included in this project.
So that would be a large set of things to maintain correctly.

Is there a way around this?
Or does anybody here have experience with this?

I think I read once somewhere that there is also a "flag" that indicates
that the port wants network access during the build. Is that feasible?

Can the modules be installed after installation? As in, does a
package.json get installed somewhere? If so, I'd put the `npm install`
instructions in pkg-message.

I'd have to dig deeper, but as far as I can now see it is a rather
convoluted part of the Cmake infra that gets called by gmake to run
several scripts and others...
But the hint is very temping if it was only like: call npm in something
like /usr/local/share/ceph/dasboard/frontend

It looks like in the tarball there is
src/pybind/mgr/dashboard/frontend/package.json. Does this have what
you're looking for?

Yup,

ATM I'm testing to see if your trick works and just cd to
    /usr/local/share/ceph/mgr/dashboard/frontend
and go
    npm ci

Question is: will this deliver a working dashboard.
It looks like it, but I'm still missing some other components.

So I guess that the plan will be an addendum to the post install text.

Note that this will delivers an incomplete setup, untill this is 
manually fixed by

the operator.


The flag you're talking about has to go in poudriere.conf, so it
wouldn't be able to help much here. It's for local control.

Bummer...
What is the latest moment a (Make)script can get access to the network?
Tried finding this in the porters manual, but could not find that detail.

The fetch phase is the only time that the network is available,
unfortunately. It's a great feature, though it does require rethinking
in situations like this.
I think I understand the rationale behind it, but now the user starts 
donwloading things

himself post install. Not per definition increasing the level of security.

--WjW

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

Re: packaging a port that uses npm during build.

[Willem Jan Withagen]

On 28-10-2019 13:28, Adam Weinberger wrote:

On Mon, Oct 28, 2019 at 5:17 AM Willem Jan Withagen  wrote:


Hi,

The ceph ports should have a manager module called dashboard that
exists of a large bundle op JS-scripts that get installed with npm/node
during running make on the configured build.

Uptil now I've exclude that from builds, but that gets more and more
complicated. Ceph cluster status is not reported not healty if the
dashboard is not running

Apart from the fact that npm does not like to be ran as 'root',
poudriere also complains about fetching data afte the fetch fase.

There are about 1000 npm-modules included in this project.
So that would be a large set of things to maintain correctly.

Is there a way around this?
Or does anybody here have experience with this?

I think I read once somewhere that there is also a "flag" that indicates
that the port wants network access during the build. Is that feasible?


Can the modules be installed after installation? As in, does a
package.json get installed somewhere? If so, I'd put the `npm install`
instructions in pkg-message.


I'd have to dig deeper, but as far as I can now see it is a rather 
convoluted part of the Cmake infra that gets called by gmake to run 
several scripts and others...

But the hint is very temping if it was only like: call npm in something
like /usr/local/share/ceph/dasboard/frontend


The flag you're talking about has to go in poudriere.conf, so it
wouldn't be able to help much here. It's for local control.


Bummer...
What is the latest moment a (Make)script can get access to the network?
Tried finding this in the porters manual, but could not find that detail.

--WjW

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

packaging a port that uses npm during build.

[Willem Jan Withagen]

Hi,

The ceph ports should have a manager module called dashboard that
exists of a large bundle op JS-scripts that get installed with npm/node 
during running make on the configured build.


Uptil now I've exclude that from builds, but that gets more and more 
complicated. Ceph cluster status is not reported not healty if the 
dashboard is not running


Apart from the fact that npm does not like to be ran as 'root', 
poudriere also complains about fetching data afte the fetch fase.


There are about 1000 npm-modules included in this project.
So that would be a large set of things to maintain correctly.

Is there a way around this?
Or does anybody here have experience with this?

I think I read once somewhere that there is also a "flag" that indicates 
that the port wants network access during the build. Is that feasible?


Thanx,
--WjW

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

Using a different linker in a CMake project

[Willem Jan Withagen]

Hi,

For building ceph14 in I need to use ld from the ports binutils.
Mainly because of versioning that I can not get to work with the llvm 
linker, and is a know difference between GNU ld en LLVM ld.


Just building in the project I was able to do that with:
  -D  CMAKE_CXX_FLAGS_DEBUG=" -fuse-ld=/usr/local/bin/ld 
-Wno-unused-command-line-argument"


So I'm trying to pass that also in the ports Makefile as a CMAKE_ARGS.
But nothing thusfar I've tried does actually work. and gets the option
on the commandline.

So is there a way to get this to work.
It is sort of tricky since CMAKE output uses cc of c++ to do linking.

A brute force hack would be to
rm /usr/bin/ld
ln -s /usr/local/bin/ld /usr/bin/ld
But I sure that that would not make it in the porst tree.

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

Trying to make a new package

[Willem Jan Withagen]

Hi,

I'm trying to release a new version of the ceph13 port.
But if I'm doing what I normally do: first test the build in
  /usr/ports/ceph13
before going to poudriere, I get:

root@zfstest:/usr/ports/net/ceph13 # make makesum
===>  ceph13-13.2.2 has known vulnerabilities:
0 problem(s) in 0 installed package(s) found.

Never had that before.

Whats up?

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

Submit of ceph12 upgrade

[Willem Jan Withagen]

Hi,

Looking for a port admin willing to take:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236004

Reason to sollicit, is to point to the svn move request to
move from net/ceph to net/ceph12

This version has gone thru `portlint -A` and `poudriere testport`

--WjW

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

Re: Renaming net/ceph to net/ceph12

[Willem Jan Withagen]

On 22-1-2019 16:45, Mathieu Arnold wrote:

On Tue, Jan 22, 2019 at 03:35:51PM +0100, Willem Jan Withagen wrote:

On 22/01/2019 15:29, Mathieu Arnold wrote:

On Tue, Jan 22, 2019 at 10:42:16AM +0100, Willem Jan Withagen wrote:

Hi,

I there a ports committer that can do that for me if it is just a mater of
`fix Makefile && svn rename` greatly appreciated.

If it needs more work, can somebody explain to me what more is needed?

After this is done, I'll submit a new ceph 12.2.11 version once it is out.
And I'll upload the first version of ceph 13.2.x


Well, there is nothing more needed, but, it would mean that until you
submit tne 13.2.x update, there would be two identical versions of ceph.


I would submit both under their own names: ceph12 or ceph13.


Well, how they end up being named does not really matter.  What matters
is history.  When ceph13 ends up being created, it will be by taking the
ceph, or ceph12 directory, running svn copy so that subversion registers
the ancestry, and by then updating that.


Sorry for all the questions, but I do not often submit to FreeBSD.
And mostly upgrades go thru a shar in bugzilla.

So I'd run
svn copy ceph ceph12
svn copy ceph ceph13
svn del ceph

And fix both to the new versions...
Then submit the `svn diff net/ceph12`

But then does that diff carry the ancestry?
Or need I submit thru arc?

--WjW


It would be preferrable to submit the 13.2.x update, asking the
committer in the PR to also copy the current version to net/ceph12.


Oke,

So I'll first get ceph13 ready, submit and ask to move net/ceph to
net/ceph12

Sort of like I did in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230432
??
I'll be more persistent this time.

--WjW




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





___
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: Renaming net/ceph to net/ceph12

[Willem Jan Withagen]

On 22/01/2019 15:29, Mathieu Arnold wrote:

On Tue, Jan 22, 2019 at 10:42:16AM +0100, Willem Jan Withagen wrote:

Hi,

I there a ports committer that can do that for me if it is just a mater of
`fix Makefile && svn rename` greatly appreciated.

If it needs more work, can somebody explain to me what more is needed?

After this is done, I'll submit a new ceph 12.2.11 version once it is out.
And I'll upload the first version of ceph 13.2.x


Well, there is nothing more needed, but, it would mean that until you
submit tne 13.2.x update, there would be two identical versions of ceph.


I would submit both under their own names: ceph12 or ceph13.


It would be preferrable to submit the 13.2.x update, asking the
committer in the PR to also copy the current version to net/ceph12.


Oke,

So I'll first get ceph13 ready, submit and ask to move net/ceph to 
net/ceph12


Sort of like I did in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230432
??
I'll be more persistent this time.

--WjW




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

Renaming net/ceph to net/ceph12

[Willem Jan Withagen]

Hi,

I there a ports committer that can do that for me if it is just a mater 
of `fix Makefile && svn rename` greatly appreciated.


If it needs more work, can somebody explain to me what more is needed?

After this is done, I'll submit a new ceph 12.2.11 version once it is out.
And I'll upload the first version of ceph 13.2.x

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

Fwd: CMake and python in ceph

[Willem Jan Withagen]

Hi,

Just tried building Ceph with the new Cmake 3.13.1, but that does not 
work because

in contrast to past builds it now requires a fixed boost_python version:

# Note that Boost Python components require a Python version suffix
# (Boost 1.67 and later), e.g. ``python36`` or ``python27`` for the
# versions built against Python 3.6 and 2.7, respectively.  This also
# applies to additional components using Python including
# ``mpi_python`` and ``numpy``.  Earlier Boost releases may use
# distribution-specific suffixes such as ``2``, ``3`` or ``2.7``.
# These may also be used as suffixes, but note that they are not
# portable.

So how does that work with all the attempts in ports to build python
version agnostic?

The catch is that I cannot get Ceph to build unless I select a ceph version
for the build. But I'm expecting that I'll fail once I get to poudriere.
(Have not tried that)

So what is the smart way out of this?

--WjW

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

Re: Bacula 9.2.1 fails on 10.4:

[Willem Jan Withagen]

On 29/08/2018 19:59, Dan Langille wrote:

On Aug 29, 2018, at 10:59 AM, Jason E. Hale  wrote:

On Mon, Aug 27, 2018 at 7:42 PM Dan Langille  wrote:



On Aug 27, 2018, at 7:26 PM, Yuri Pankov  wrote:

Dan Langille wrote:

Why would Bacula 9.2.1 compile on 11.2 but fail on 10.4?
The error is:
bsock.c:439:20: error: use of undeclared identifier 'ENODATA'
The complete build logs are at the following URLs. Can you see the cause.
11.2: 
https://services.unixathome.org/poudriere/data/112amd64-default/2018-08-27_21h15m53s/logs/bacula9-client-9.2.1.log
10.4: 
https://services.unixathome.org/poudriere/data/104amd64-default/2018-08-27_21h43m31s/logs/errors/bacula9-client-9.2.1.log
It doesn't make any sense to me.  Thanks.


I'd say it's libc++ missing its errno.h having ENODATA defined if the following 
is true:

- both builds are using clang++
- both builds are using libc++

That header defining ENODATA exists in 11.2 and doesn't exist in 10.4 
(contrib/libc++/include/errno.h).


What is a decent solution? Patch upstream? Patch the port?


I have submitted a very crude patch about 2-3 years ago, to just add it 
to /usr/include/sys/errno.h as alias for ENOATTR.


ENODATA in this file actually defines it as 9919
Which makes interoperability hard, since the call that uses it as 
err-value actually returns ENOATTR.

So for linux compatibility you'd need to match is with ENOATTR(87).

Now linux defines it to be 67, as return err-value of getattr. :(
So if you are going to push raw error values over the line, you will 
need to translate them. (and you'll find that error value sets are 2 
worlds appart)


This is what I have in the Ceph code to have it actually make sense.
ENODATA or ENOATTR is actually defined to be returned with getattr() calls.

/* Make sure that ENODATA is defined in the correct way */
#ifdef ENODATA
#if (ENODATA == 9919)
// #warning ENODATA already defined to be 9919, redefining to fix
// Silencing this warning because it fires at all files where compat.h
// is included after boost files.
//
// This value stems from the definition in the boost library
// And when this case occurs it is due to the fact that boost files
// are included before this file. Redefinition might not help in this
// case since already parsed code has evaluated to the wrong value.
// This would warrant for a definition that would actually be evaluated
// at the location of usage and report a possible conflict.
// This is left up to a future improvement
#elif (ENODATA != 87)
#warning ENODATA already defined to a value different from 87 (ENOATRR), 
refining to fix

#endif
#undef ENODATA
#endif
#define ENODATA ENOATTR


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

Building packages that need python pip to install certain python packages

[Willem Jan Withagen]

Hi,

I asked the question on the node installer, how to get things build
also packaged. And the actual answer was:
you can't do that unless in the post-fetch() and then find
a way to distribute to the correct places before the package
starts building
OR:
give the user instructions what to do post installation.
and have him do the work.

I haven't figured that on out yet.

Now I have a similar question for python packages that are not in the
ports tree, but do install and work with pip.

Is there a way to get a package dependancy on a
'pip install '
where the something atm is:
pecan and ninja2

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

Re: Installing javascript code into a port with npm...

[Willem Jan Withagen]

On 10/06/2018 19:12, Adam Weinberger wrote:

On Sun, Jun 10, 2018 at 9:45 AM Willem Jan Withagen  wrote:


Hi,

The Ceph ports has since a while started to import all kinds of
javascript code using npm. Which fetches external data and install this
in the Ceph resulting tree.

I have a question with this:

How would that work under pouderiere building, because I was under the
impression that fetching extra data whilest builing a ports is sort of
not done.

Other than that I still have errors in the building code, but I'd like
to know this before I put major effort in getting it to work the way it
now does...

Thanx,
--WjW


poudriere cannot fetch during build. (However, it can if you whitelist
it in ALLOW_NETWORKING_PACKAGES in poudriere.conf.)

The only thing you can do is fetch those dependencies as part of
do-fetch, or have the user do it after installation (pkg-message
instructions or a script or something).

Please, try *not* to create ports for the dependencies. We absolutely
do not want npm packages in ports unless there's no other option.


'mmm

Sounds like an effort.
But avoiding npm packages is waht I expected, given that none we in the 
tree.


--WjW

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

Installing javascript code into a port with npm...

[Willem Jan Withagen]

Hi,

The Ceph ports has since a while started to import all kinds of 
javascript code using npm. Which fetches external data and install this 
in the Ceph resulting tree.


I have a question with this:

How would that work under pouderiere building, because I was under the 
impression that fetching extra data whilest builing a ports is sort of 
not done.


Other than that I still have errors in the building code, but I'd like 
to know this before I put major effort in getting it to work the way it 
now does...


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

Re: Ceph Official version 12.2.0 port submitted

[Willem Jan Withagen]

On 2-9-2017 19:10, Kurt Jaeger wrote:
> Hi!
> 
>>> Could any of the interested submitters take a look at:
>>>
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221997
>>
>> I had a look, looks fine except a few portlint -AC warnings.
> 
> Oh, doesn't it need a CONFLICTS with ceph-devel ?
> 
> Or should ceph-devel be renamed ? Or ... ?

Fixed the diff, and added a new one for ceph-devel as well.

--WjW

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

Re: Ceph Official version 12.2.0 port submitted

[Willem Jan Withagen (Nefos)]

On 2-9-2017 19:10, Kurt Jaeger wrote:
> Hi!
>
>>> Could any of the interested submitters take a look at:
>>>
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221997
>> I had a look, looks fine except a few portlint -AC warnings.
> Oh, doesn't it need a CONFLICTS with ceph-devel ?
>
> Or should ceph-devel be renamed ? Or ... ?
>

Ah, that shows my lack of porting experience
I guess it would, since just about everything is equal and will be
conflicting.

I'll have to readup on this, and add it to both ports.

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

Ceph Official version 12.2.0 port submitted

[Willem Jan Withagen (Nefos)]

Could any of the interested submitters take a look at:

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

Has gone thru:
    portlint -A
    poudriere testport

Thanx,
--WjW

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

Re: Question on Amavis and ramdisk

[Willem Jan Withagen]

On 21-8-2017 15:40, RW via freebsd-ports wrote:
> On Mon, 21 Aug 2017 14:47:43 +0200
> Willem Jan Withagen wrote:
> 
>> Hi,
>>
>> In the amavis rc.d file is noted:
>> ""
>> "WARNING: using ramdisk is reported to be unstable and"
>> "thus it is highly recommended to be turned off."
>> ""
>>
>> And this warning seems there since 2012
> 
> 
> 
> Actually it came in with revision 228889 in 2009. The script at
> that point didn't allow for tmpfs and only checks for an existing md
> device before creating a malloc md device (i.e. in unswapable wired
> kernel memory).  IIRC there used to be a warning about this kind of md
> device being able to cause crashes.

Ah, oke,

That I can remember too. But I think that is no longer the case.
Perhaps now with the new rc.d stuff tmpfs is more appropriate.

--WjW


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

Re: Question on Amavis and ramdisk

[Willem Jan Withagen]

On 21-8-2017 15:23, Mark Martinec wrote:
> 2017-08-21 14:47 Willem Jan Withagen wrote:
>> In the amavis rc.d file is noted:
>> ""
>> "WARNING: using ramdisk is reported to be unstable and"
>> "thus it is highly recommended to be turned off."
>> ""
>>
>> And this warning seems there since 2012
>>
>> Is this warning still valid?
>> And if YES, could somebody try and enlighten me as to what is unstable
>> on this config?
>>   - Is the ramdisk itself unstable?
>>   - Or is it the fact that upon a crash de ramdisk is lost and email
>> might be lost?
> 
> I don't really know what was the reason for this warning, but I can
> guess that it's because the port creates a mdmfs ram disk of a fixed
> size for the %%AMAVISDIR%%/tmp file system, and any fixed size small
> disk may eventually run out of space, either during some peak mail
> traffic rush-in, of perhaps when soma stale temporary files happen
> to be left undeleted and accumulating, while this goes unnoticed
> for some time.

Oke, so these are the regular sysadmin troubles of a (too) small a disk.
Nothing a good purge can not fix
Full disk might indeed lead to a sort of DOS situation.

> Using tmpfs instead of mdmfs could avoid some of the above concerns
> if you really want to use a ram disk. In my experience with a
> modern host and file systems, especially with SSD, there is no longer
> any substantial speedup by using a ram disk instead, so I don't
> think it is worth sacrificing memory for a ram disk, which could
> better be used by file system caches etc.

' this system runs in VM on KVM in OpenStack.
And one of the bottlenecks is amavis flushing all mail to a disk. And
that pushes the virtual disk to their limit.
Switching some ramdisk on really does help in the load.
>>   - Or is it the fact that upon a crash de ramdisk is lost and email
>> might be lost?
> 
> No, mail should not be lost. Write failures would be noticed and
> a feeding mailer would receive a temporary failure (smtp status 450),
> so mail should stay in the mailer's queue for a later retry.
> But left unattended for days, this would result in mail non-delivery
> notification to the sender.

Right. As far as I know will postfix only note amavis complete if Amavis
has really reported as such, and only then tkae the file from the
waiting queue. So a crash would not result in wrong deliveries.

So perhaps the wording on that message should be less strong and
prohibitive?

--WjW

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

Question on Amavis and ramdisk

[Willem Jan Withagen]

Hi,

In the amavis rc.d file is noted:
""
"WARNING: using ramdisk is reported to be unstable and"
"thus it is highly recommended to be turned off."
""

And this warning seems there since 2012

Is this warning still valid?
And if YES, could somebody try and enlighten me as to what is unstable
on this config?
  - Is the ramdisk itself unstable?
  - Or is it the fact that upon a crash de ramdisk is lost and email
might be lost?

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

Re: Updating the net/ceph-devel port to 2017-08-05

[Willem Jan Withagen]

On 18-8-2017 18:08, Kurt Jaeger wrote:
> Hi!
> 
>> Could any of the commiters take a look at:
>>
>>   - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221569
>>
>> Both poudriere and portlint have been tested.
>>
>> Upgrade is due to some compile errors in the previous upgrade.
> 
> Done.

Hi Kurt,

Thanx for the commit.

--WjW



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

Updating the net/ceph-devel port to 2017-08-05

[Willem Jan Withagen]

Could any of the commiters take a look at:

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

Both poudriere and portlint have been tested.

Upgrade is due to some compile errors in the previous upgrade.

Thanx,
--WjW

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

Re: Updating the net/ceph-devel port

[Willem Jan Withagen]

On 11-8-2017 15:30, Kurt Jaeger wrote:
> Hi!
> 
>> Would somebody please take a look at the the update at:
>>https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218974
> 
> That PR is already committed and closed.

Ah, sorry, That was the original commit, I picked the wrong one from my
archived mails.
It should have read:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221063

>> It also went by phabricator:
>>https://reviews.freebsd.org/D11770
> 
> That's a new patch, I assume ?

Yup, it should be equal to waht is in Bugzilla under 221063.

--WjW




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

Updating the net/ceph-devel port

[Willem Jan Withagen]

Hi,

Would somebody please take a look at the the update at:
   https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218974

It also went by phabricator:
   https://reviews.freebsd.org/D11770

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

Re: Trying to get poudriere to start

[Willem Jan Withagen]

On 30-7-2017 19:59, Chris Rees wrote:
> 
> 
> On 29 July 2017 20:01:42 BST, Willem Jan Withagen  wrote:
>>
>>
>> Op 29-7-2017 om 13:34 schreef Chris Rees:
>>>
>>>
>>> On 29 Jul 2017 11:56, Willem Jan Withagen  wrote:
>>>
>>>
>>>
>>>     Op 28-7-2017 om 22:50 schreef Chris Rees:
>>>
>>>
>>>
>>> On 26 Jul 2017 23:59, Willem Jan Withagen 
>>>     <mailto:w...@digiware.nl> wrote:
>>>
>>> Op 27-7-2017 om 00:48 schreef Miroslav Lachman:
>>> > Willem Jan Withagen wrote on 2017/07/26 23:24:
>>> >> Hi,
>>> >>
>>> >> This has been working, but now the jail does not even
>>> start
>>> >> Any suggestions why the linux module is giving me
>> trouble?
>>> >>
>>> >>  >  sudo poudriere bulk -vv -j ceph -p local net/ceph
>>> >> kldload: an error occurred while loading module linux.
>>> Please check
>>> >> dmesg(8) for more details.
>>> >> [00:00:00] >> Error: Required kernel module
>> 'linux'
>>> not found
>>> >>
>>> >> The parent system has linux stuff mounted in
>>> /compat/linux/proc
>>> >>
>>> >> Running 12-CURRENT.
>>> >
>>> > Did you tried "kldload linux" in host system? Will
>>> kldstat show you
>>> > loaded kernel module "linux"?
>>> >
>>> Right,
>>> I feel rather stupid... Because I do kknow how most of
>>> this works.
>>> So indeed this is all at the upper level:
>>>
>>> Looks like a incompatability
>>> link_elf_obj: symbol freebsd32_exec_copyin_args undefined
>>> linker_load_file: /boot/kernel/linux.ko - unsupported
>> file
>>> type
>>>
>>> But why
>>>
>>> [~] w...@freetest.digiware.nl
>>> <mailto:w...@freetest.digiware.nl>> ls -asl
>>> /boot/kernel/*linux*
>>>   14 -r-xr-xr-x  1 root  wheel   13232 Jul 19 12:55
>>> /boot/kernel/amr_linux.ko*
>>>   47 -r-xr-xr-x  1 root  wheel   47480 Jul 19 12:55
>>> /boot/kernel/geom_linux_lvm.ko*
>>>   14 -r-xr-xr-x  1 root  wheel   13312 Jul 19 12:55
>>> /boot/kernel/ipmi_linux.ko*
>>> 771 -r-xr-xr-x  1 root  wheel  659248 Jul 19 12:55
>>> /boot/kernel/linux.ko*
>>> 643 -r-xr-xr-x  1 root  wheel  590328 Jul 19 12:55
>>> /boot/kernel/linux64.ko*
>>>   56 -r-xr-xr-x  1 root  wheel   55936 Jul 19 12:55
>>> /boot/kernel/linux_common.ko*
>>> 259 -r-xr-xr-x  1 root  wheel  186336 Jul 19 12:55
>>> /boot/kernel/linuxkpi.ko*
>>>   16 -r-xr-xr-x  1 root  wheel   15120 Jul 19 12:55
>>> /boot/kernel/mfi_linux.ko*
>>>   16 -r-xr-xr-x  1 root  wheel   15448 Jul 19 12:55
>>> /boot/kernel/mrsas_linux.ko*
>>> 102 -r-xr-xr-x  1 root  wheel  103416 Jul 19 12:55
>>> /boot/kernel/systrace_linux.ko*
>>> 112 -r-xr-xr-x  1 root  wheel  113416 Jul 19 12:55
>>> /boot/kernel/systrace_linux32.ko*
>>>
>>> [~] w...@freetest.digiware.nl
>>> <mailto:w...@freetest.digiware.nl>> file
>> /boot/kernel/linux.ko
>>> /boot/kernel/linux.ko: ELF 64-bit LSB relocatable,
>> x86-64,
>>> version 1
>>> (FreeBSD), not stripped
>>>
>>> Are the jail and host the same version?
>>>
>>>
>>> Nope,
>>>
>>> But if I check the jail scripts, the modules are loaded outside
>> of
>>> the jail in the host.
>>> So I would expect that not to mater.
>>>
>>> --WjW
>>>
>>>
>>> Well, depends entirely on which modules are loaded!  Are you loading 
>>> host modules?
>>>
>>

Re: Trying to get poudriere to start

[Willem Jan Withagen]

Op 29-7-2017 om 13:34 schreef Chris Rees:



On 29 Jul 2017 11:56, Willem Jan Withagen  wrote:



Op 28-7-2017 om 22:50 schreef Chris Rees:



On 26 Jul 2017 23:59, Willem Jan Withagen 
<mailto:w...@digiware.nl> wrote:

Op 27-7-2017 om 00:48 schreef Miroslav Lachman:
> Willem Jan Withagen wrote on 2017/07/26 23:24:
>> Hi,
>>
>> This has been working, but now the jail does not even
start
>> Any suggestions why the linux module is giving me trouble?
>>
>>  >  sudo poudriere bulk -vv -j ceph -p local net/ceph
>> kldload: an error occurred while loading module linux.
Please check
>> dmesg(8) for more details.
>> [00:00:00] >> Error: Required kernel module 'linux'
not found
>>
>> The parent system has linux stuff mounted in
/compat/linux/proc
>>
>> Running 12-CURRENT.
>
> Did you tried "kldload linux" in host system? Will
kldstat show you
> loaded kernel module "linux"?
>
Right,
I feel rather stupid... Because I do kknow how most of
this works.
So indeed this is all at the upper level:

Looks like a incompatability
link_elf_obj: symbol freebsd32_exec_copyin_args undefined
linker_load_file: /boot/kernel/linux.ko - unsupported file
type

But why

[~] w...@freetest.digiware.nl
<mailto:w...@freetest.digiware.nl>> ls -asl
/boot/kernel/*linux*
  14 -r-xr-xr-x  1 root  wheel   13232 Jul 19 12:55
/boot/kernel/amr_linux.ko*
  47 -r-xr-xr-x  1 root  wheel   47480 Jul 19 12:55
/boot/kernel/geom_linux_lvm.ko*
  14 -r-xr-xr-x  1 root  wheel   13312 Jul 19 12:55
/boot/kernel/ipmi_linux.ko*
771 -r-xr-xr-x  1 root  wheel  659248 Jul 19 12:55
/boot/kernel/linux.ko*
643 -r-xr-xr-x  1 root  wheel  590328 Jul 19 12:55
/boot/kernel/linux64.ko*
  56 -r-xr-xr-x  1 root  wheel   55936 Jul 19 12:55
/boot/kernel/linux_common.ko*
259 -r-xr-xr-x  1 root  wheel  186336 Jul 19 12:55
/boot/kernel/linuxkpi.ko*
  16 -r-xr-xr-x  1 root  wheel   15120 Jul 19 12:55
/boot/kernel/mfi_linux.ko*
  16 -r-xr-xr-x  1 root  wheel   15448 Jul 19 12:55
/boot/kernel/mrsas_linux.ko*
102 -r-xr-xr-x  1 root  wheel  103416 Jul 19 12:55
/boot/kernel/systrace_linux.ko*
112 -r-xr-xr-x  1 root  wheel  113416 Jul 19 12:55
/boot/kernel/systrace_linux32.ko*

[~] w...@freetest.digiware.nl
<mailto:w...@freetest.digiware.nl>> file /boot/kernel/linux.ko
/boot/kernel/linux.ko: ELF 64-bit LSB relocatable, x86-64,
version 1
(FreeBSD), not stripped

Are the jail and host the same version?


Nope,

But if I check the jail scripts, the modules are loaded outside of
the jail in the host.
So I would expect that not to mater.

--WjW


Well, depends entirely on which modules are loaded!  Are you loading 
host modules?




This is the code I commented out:

/usr/local/share/poudriere/common.sh: 1780
#   if [ -z "${NOLINUX}" ]; then
#   if [ "${arch}" = "i386" -o "${arch}" = "amd64" ]; then
#   needfs="${needfs} linprocfs"
#   needkld="${needkld} linuxelf:linux"
#   if [ "${arch}" = "amd64" ] && \
#   [ ${HOST_OSVERSION} -ge 1002507 ]; then
#   needkld="${needkld} linux64elf:linux64"
#   fi
#   fi
#   fi

Which suggest that it is the host that is loading the modules.

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

Re: Trying to get poudriere to start

[Willem Jan Withagen]

Op 28-7-2017 om 22:50 schreef Chris Rees:



On 26 Jul 2017 23:59, Willem Jan Withagen  wrote:

Op 27-7-2017 om 00:48 schreef Miroslav Lachman:
> Willem Jan Withagen wrote on 2017/07/26 23:24:
>> Hi,
>>
>> This has been working, but now the jail does not even start
>> Any suggestions why the linux module is giving me trouble?
>>
>>  >  sudo poudriere bulk -vv -j ceph -p local net/ceph
>> kldload: an error occurred while loading module linux. Please
check
>> dmesg(8) for more details.
>> [00:00:00] >> Error: Required kernel module 'linux' not found
>>
>> The parent system has linux stuff mounted in /compat/linux/proc
>>
>> Running 12-CURRENT.
>
> Did you tried "kldload linux" in host system? Will kldstat show you
> loaded kernel module "linux"?
>
Right,
I feel rather stupid... Because I do kknow how most of this works.
So indeed this is all at the upper level:

Looks like a incompatability
link_elf_obj: symbol freebsd32_exec_copyin_args undefined
linker_load_file: /boot/kernel/linux.ko - unsupported file type

But why

[~] w...@freetest.digiware.nl> ls -asl /boot/kernel/*linux*
  14 -r-xr-xr-x  1 root  wheel   13232 Jul 19 12:55
/boot/kernel/amr_linux.ko*
  47 -r-xr-xr-x  1 root  wheel   47480 Jul 19 12:55
/boot/kernel/geom_linux_lvm.ko*
  14 -r-xr-xr-x  1 root  wheel   13312 Jul 19 12:55
/boot/kernel/ipmi_linux.ko*
771 -r-xr-xr-x  1 root  wheel  659248 Jul 19 12:55
/boot/kernel/linux.ko*
643 -r-xr-xr-x  1 root  wheel  590328 Jul 19 12:55
/boot/kernel/linux64.ko*
  56 -r-xr-xr-x  1 root  wheel   55936 Jul 19 12:55
/boot/kernel/linux_common.ko*
259 -r-xr-xr-x  1 root  wheel  186336 Jul 19 12:55
/boot/kernel/linuxkpi.ko*
  16 -r-xr-xr-x  1 root  wheel   15120 Jul 19 12:55
/boot/kernel/mfi_linux.ko*
  16 -r-xr-xr-x  1 root  wheel   15448 Jul 19 12:55
/boot/kernel/mrsas_linux.ko*
102 -r-xr-xr-x  1 root  wheel  103416 Jul 19 12:55
/boot/kernel/systrace_linux.ko*
112 -r-xr-xr-x  1 root  wheel  113416 Jul 19 12:55
/boot/kernel/systrace_linux32.ko*

[~] w...@freetest.digiware.nl> file /boot/kernel/linux.ko
/boot/kernel/linux.ko: ELF 64-bit LSB relocatable, x86-64, version 1
(FreeBSD), not stripped

Are the jail and host the same version?


Nope,

But if I check the jail scripts, the modules are loaded outside of the 
jail in the host.

So I would expect that not to mater.

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

Re: Trying to get poudriere to start

[Willem Jan Withagen]

On 28-7-2017 09:21, Shane Ambler wrote:
> On 27/07/2017 09:30, Willem Jan Withagen wrote:
>> On 27-7-2017 01:43, mokhi wrote:
>>> Aha,
>>> Okay...
>>> Good if it works :)
>>>
>>
>> It is a gross hack, but it gets me going for the time being.
>>
>> Also needed to fight with ninja.
>> Turns out that somebody changed my old port to include noninja, without
>> telling me... :(
> 
> That change would be related to r444324
> http://leader/viewvc/viewvc.cgi/FreeBSD-ports?view=revision&revision=444324
> 
> Your port uses cmake, which previously would use make to build your
> port. The options to use ninja instead of make was an option but is now
> the default as speed improvements on larger projects were found. The
> addition of USES= cmake:noninja means your port failed using ninja
> during the tests of that change, which means it was left to build the
> same way it was before the change.

ninja complains about problems with $'s.
And since this project also needs to work with cmake/gmake on Linux, I'm
not even going to try to meddle with this.
Assuming that the current combo is going to stay workable?

--WjW

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

Re: Trying to get poudriere to start

[Willem Jan Withagen]

Op 27-7-2017 om 02:20 schreef Adam Weinberger:

On 26 Jul, 2017, at 17:23, Willem Jan Withagen  wrote:

Op 27-7-2017 om 01:15 schreef mokhi:

Hmm,
I don't know if it's same thing happened to me once.
But I **guess** you should kldload both of linux32 and linux64 and
also linprocfs modules


I did it the other way around.
Hacked poudriere//common.sh
And commented the kldoad for linux out...
So I can atleast check this one port.

Setting NOLINUX=yes in poudriere.conf accomplishes the same thing.

I saw variable that in the code, but could not really find anything 
about it in the manpage.

But your suggestion is of course a very logical.

Still leaves the question what kldload is complaining about, and why.
But I'll look into that once I've completed upgrading the port.

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

Re: Trying to get poudriere to start

[Willem Jan Withagen]

On 27-7-2017 01:43, mokhi wrote:
> Aha,
> Okay...
> Good if it works :)
> 

It is a gross hack, but it gets me going for the time being.

Also needed to fight with ninja.
Turns out that somebody changed my old port to include noninja, without
telling me... :(

Only when I actually started digging in my old poudriere  Makefile and
diffing it against what was in /usr/ports, it becaem clean.

But a new ceph-devel version is being tested.

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

Re: Trying to get poudriere to start

[Willem Jan Withagen]

Op 27-7-2017 om 01:15 schreef mokhi:

Hmm,
I don't know if it's same thing happened to me once.
But I **guess** you should kldload both of linux32 and linux64 and
also linprocfs modules



I did it the other way around.
Hacked poudriere//common.sh
And commented the kldoad for linux out...
So I can atleast check this one port.

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

Re: Trying to get poudriere to start

[Willem Jan Withagen]

Op 27-7-2017 om 00:48 schreef Miroslav Lachman:

Willem Jan Withagen wrote on 2017/07/26 23:24:

Hi,

This has been working, but now the jail does not even start
Any suggestions why the linux module is giving me trouble?

 >  sudo poudriere bulk -vv -j ceph -p local net/ceph
kldload: an error occurred while loading module linux. Please check
dmesg(8) for more details.
[00:00:00] >> Error: Required kernel module 'linux' not found

The parent system has linux stuff mounted in /compat/linux/proc

Running 12-CURRENT.


Did you tried "kldload linux" in host system? Will kldstat show you 
loaded kernel module "linux"?



Right,
I feel rather stupid... Because I do kknow how most of this works.
So indeed this is all at the upper level:

Looks like a incompatability
link_elf_obj: symbol freebsd32_exec_copyin_args undefined
linker_load_file: /boot/kernel/linux.ko - unsupported file type

But why

[~] w...@freetest.digiware.nl> ls -asl /boot/kernel/*linux*
 14 -r-xr-xr-x  1 root  wheel   13232 Jul 19 12:55 
/boot/kernel/amr_linux.ko*
 47 -r-xr-xr-x  1 root  wheel   47480 Jul 19 12:55 
/boot/kernel/geom_linux_lvm.ko*
 14 -r-xr-xr-x  1 root  wheel   13312 Jul 19 12:55 
/boot/kernel/ipmi_linux.ko*

771 -r-xr-xr-x  1 root  wheel  659248 Jul 19 12:55 /boot/kernel/linux.ko*
643 -r-xr-xr-x  1 root  wheel  590328 Jul 19 12:55 /boot/kernel/linux64.ko*
 56 -r-xr-xr-x  1 root  wheel   55936 Jul 19 12:55 
/boot/kernel/linux_common.ko*

259 -r-xr-xr-x  1 root  wheel  186336 Jul 19 12:55 /boot/kernel/linuxkpi.ko*
 16 -r-xr-xr-x  1 root  wheel   15120 Jul 19 12:55 
/boot/kernel/mfi_linux.ko*
 16 -r-xr-xr-x  1 root  wheel   15448 Jul 19 12:55 
/boot/kernel/mrsas_linux.ko*
102 -r-xr-xr-x  1 root  wheel  103416 Jul 19 12:55 
/boot/kernel/systrace_linux.ko*
112 -r-xr-xr-x  1 root  wheel  113416 Jul 19 12:55 
/boot/kernel/systrace_linux32.ko*


[~] w...@freetest.digiware.nl> file /boot/kernel/linux.ko
/boot/kernel/linux.ko: ELF 64-bit LSB relocatable, x86-64, version 1 
(FreeBSD), not stripped




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

Trying to get poudriere to start

[Willem Jan Withagen]

Hi,

This has been working, but now the jail does not even start
Any suggestions why the linux module is giving me trouble?

>  sudo poudriere bulk -vv -j ceph -p local net/ceph
kldload: an error occurred while loading module linux. Please check 
dmesg(8) for more details.

[00:00:00] >> Error: Required kernel module 'linux' not found

The parent system has linux stuff mounted in /compat/linux/proc

Running 12-CURRENT.

Thanx,
--WjW

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

Re: Looking for python-pecan

[Willem Jan Withagen]

On 12-6-2017 17:09, Dimitry Andric wrote:
> On 12 Jun 2017, at 13:29, Willem Jan Withagen  wrote:
>>
>> For one the Ceph port I'm doing I'm going to need python-pecan in het
>> close future.
>>
>> Not sure how this works with python-modules since it is something that
>> is only used by the ceph-ports. But my guess is that I won't be
>> able/allowed to just have a post execute like:
>>
>>  ping install python-pecan.
> 
> Normally you would use pip, ping is something entirely different. :)

8-D, yup. Some commands are an automaton. Think P, and ping comes out.


> Here is a patch to add a devel/py-pecan port, plus one of its
> dependencies that is not yet in the ports tree, devel/py-logutils.
> 
> Tested only very lightly, please take care.

It will get tested more now.
And now I do not have to make a Pecan port. :)
Did you submit this (and py-logutils) for acceptance?

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

Looking for python-pecan

[Willem Jan Withagen]

Hi,

For one the Ceph port I'm doing I'm going to need python-pecan in het
close future.

Not sure how this works with python-modules since it is something that
is only used by the ceph-ports. But my guess is that I won't be
able/allowed to just have a post execute like:

ping install python-pecan.

Suggestions...

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

Re: Xorg error 'alphasort'

[Willem Jan Withagen]

On 31/05/2017 18:21, Masachika ISHIZUKA wrote:

   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.


Right I had more or less the same with r319216.
And I was going to reinstall from a snapshot, but now I'll try and move 
forward.


--WjW

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

Nag mail..... Fwd: [package - 103amd64-quarterly][net/ceph-devel] Failed for ceph-devel-w.v2017.2.14 in build

[Willem Jan Withagen]

Hi

I'm regularly spammed by this mail.
Which I guess that it is due to the quartly snapshoted ports copy.
And that contains a missing patch that disables builing this port on 10.x

So am I going to be spammed until end of Q2, or is there actually a way
to get this port upgraded to the current Makefile? As this email suggests?

Thanx,
--WjW



 Forwarded Message 
Subject: [package - 103amd64-quarterly][net/ceph-devel] Failed for
ceph-devel-w.v2017.2.14 in build
Date: Fri, 14 Apr 2017 05:36:26 GMT
From: pkg-fall...@freebsd.org
To: w...@digiware.nl
CC: pkg-fall...@freebsd.org

You are receiving this mail as a port that you maintain
is failing to build on the FreeBSD package build server.
Please investigate the failure and submit a PR to fix
build.

Maintainer: w...@digiware.nl
Last committer: anto...@freebsd.org
Ident:  $FreeBSD: branches/2017Q2/net/ceph-devel/Makefile 437432
2017-04-01 12:00:27Z antoine $
Log URL:
http://beefy2.nyi.freebsd.org/data/103amd64-quarterly/438400/logs/ceph-devel-w.v2017.2.14.log
Build URL:
http://beefy2.nyi.freebsd.org/build.html?mastername=103amd64-quarterly&build=438400
Log:

>> Building net/ceph-devel
build started at Fri Apr 14 04:55:59 UTC 2017
port directory: /usr/ports/net/ceph-devel
building for: FreeBSD 103amd64-quarterly-job-21 10.3-RELEASE-p18 FreeBSD
10.3-RELEASE-p18 amd64
maintained by: w...@digiware.nl
Makefile ident:  $FreeBSD: branches/2017Q2/net/ceph-devel/Makefile
437432 2017-04-01 12:00:27Z antoine $
Poudriere version: 3.1.17-9-gf49c6f78
Host OSVERSION: 1200020
Jail OSVERSION: 1003000
Job Id: 21

---Begin Environment---
SHELL=/bin/csh
OSVERSION=1003000
UNAME_v=FreeBSD 10.3-RELEASE-p18
UNAME_r=10.3-RELEASE-p18
BLOCKSIZE=K
MAIL=/var/mail/root
STATUS=1
SAVED_TERM=
MASTERMNT=/usr/local/poudriere/data/.m/103amd64-quarterly/ref
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin
POUDRIERE_BUILD_TYPE=bulk
PKGNAME=ceph-devel-w.v2017.2.14
OLDPWD=/
PWD=/usr/local/poudriere/data/.m/103amd64-quarterly/ref/.p/pool
MASTERNAME=103amd64-quarterly
SCRIPTPREFIX=/usr/local/share/poudriere
USER=root
HOME=/root
POUDRIERE_VERSION=3.1.17-9-gf49c6f78
SCRIPTPATH=/usr/local/share/poudriere/bulk.sh
LIBEXECPREFIX=/usr/local/libexec/poudriere
LOCALBASE=/usr/local
PACKAGE_BUILDING=yes
POUDRIEREPATH=/usr/local/bin/poudriere
---End Environment---

---Begin OPTIONS List---
---End OPTIONS List---

--CONFIGURE_ARGS--

--End CONFIGURE_ARGS--

--CONFIGURE_ENV--
MAKE=gmake PYTHON="/usr/local/bin/python2.7"
XDG_DATA_HOME=/wrkdirs/usr/ports/net/ceph-devel/work
XDG_CONFIG_HOME=/wrkdirs/usr/ports/net/ceph-devel/work
HOME=/wrkdirs/usr/ports/net/ceph-devel/work TMPDIR="/tmp" SHELL=/bin/sh
CONFIG_SHELL=/bin/sh
--End CONFIGURE_ENV--

--MAKE_ENV--
XDG_DATA_HOME=/wrkdirs/usr/ports/net/ceph-devel/work
XDG_CONFIG_HOME=/wrkdirs/usr/ports/net/ceph-devel/work
HOME=/wrkdirs/usr/ports/net/ceph-devel/work TMPDIR="/tmp" NO_PIE=yes
WITHOUT_DEBUG_FILES=yes WITHOUT_KERNEL_SYMBOLS=yes SHELL=/bin/sh
NO_LINT=YES PREFIX=/usr/local  LOCALBASE=/usr/local  LIBDIR="/usr/lib"
CC="cc" CFLAGS="-O2 -pipe  -fstack-protector -fno-strict-aliasing"
CPP="cpp" CPPFLAGS=""  LDFLAGS=" -fstack-protector" LIBS=""  CXX="c++"
CXXFLAGS="-O2 -pipe -fstack-protector -fno-strict-aliasing "
MANPREFIX="/usr/local" BSD_INSTALL_PROGRAM="install  -s -m 555"
BSD_INSTALL_LIB="install  -s -m 0644"  BSD_INSTALL_SCRIPT="install  -m
555"  BSD_INSTALL_DATA="install  -m 0644"  BSD_INSTALL_MAN="install  -m 444"
--End MAKE_ENV--

--PLIST_SUB--
CMAKE_BUILD_TYPE="release"
PYTHON_INCLUDEDIR=include/python2.7
PYTHON_LIBDIR=lib/python2.7
PYTHON_PLATFORM=freebsd10
PYTHON_PYOEXTENSION=pyo
PYTHON_SITELIBDIR=lib/python2.7/site-packages
PYTHON_SUFFIX=27
PYTHON_VER=2.7
PYTHON_VERSION=python2.7
PYTHON2=""
PYTHON3="@comment
"
OSREL=10.3
PREFIX=%D
LOCALBASE=/usr/local
RESETPREFIX=/usr/local
PORTDOCS=""
PORTEXAMPLES=""
LIB32DIR=lib
DOCSDIR="share/doc/ceph"
EXAMPLESDIR="share/examples/ceph"
DATADIR="share/ceph"
WWWDIR="www/ceph"
ETCDIR="etc/ceph"
--End PLIST_SUB--

--SUB_LIST--
PREFIX=/usr/local
LOCALBASE=/usr/local
DATADIR=/usr/local/share/ceph
DOCSDIR=/usr/local/share/doc/ceph
EXAMPLESDIR=/usr/local/share/examples/ceph
WWWDIR=/usr/local/www/ceph
ETCDIR=/usr/local/etc/ceph
--End SUB_LIST--

---Begin make.conf---
USE_PACKAGE_DEPENDS=yes
BATCH=yes
WRKDIRPREFIX=/wrkdirs
PORTSDIR=/usr/ports
PACKAGES=/packages
DISTDIR=/distfiles
 /usr/local/etc/poudriere.d/make.conf 
# XXX: We really need this but cannot use it while 'make checksum' does not
# try the next mirror on checksum failure.  It currently retries the same
# failed mirror and then fails rather then trying another.  It *does*
# try the next if the size is mismatched though.
#MASTER_SITE_FREEBSD=yes
# Build ALLOW_MAKE_JOBS_PACKAGES with 2 jobs
MAKE_JOBS_NUMBER=2
 /usr/ports/Mk/Scripts/ports_env.sh 
ARCH=amd64
CONFIGURE_MAX_CMD_LEN=262144
HAVE_COMPAT_IA32_KERN=YES
OPSYS=FreeBSD
OSREL=10.3
OSVERSION=1003000
PYTHONBASE=/usr/local
UID=0
_JAVA_O

Re: NEW port: ceph-devel ready for submission

[Willem Jan Withagen]

On 17-3-2017 09:42, mokhi wrote:
> Hi,
> Doesn't asomers@ himself prefer to pick this up (as he reviewed)?
> 
Per words of Alan:
 He does not have te right to do so.

--WjW

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

NEW port: ceph-devel ready for submission

[Willem Jan Withagen]

Hi

Could one of the ports committers look at:
  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217046

 net/ceph-devel:
Development version for Ceph,
a distributed object, block, and file storage platform

And check this in the ports-tree?

Review details are at:
  https://reviews.freebsd.org/D9584

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

Re: The ports collection has some serious issues

[Willem Jan Withagen]

On 18-12-2016 16:00, John Marino wrote:

> [please keep me CC'd, I can't respond easily if not]

I find that sort of strange... but that could be my feeling.

Someone builds a tool, and then decides that it is not very useful to be
part of the community that he creates the tool for...

Like I said, it feels strange.
--WjW

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

Re: what is the purpose of the quarterly ports branches?

[Willem Jan Withagen]

On 16-12-2016 11:10, Julian Elischer wrote:
> On 16/12/2016 4:01 PM, Dave Cottlehuber wrote:
>>
>> On Tue, 13 Dec 2016, at 23:14, Grzegorz Junka wrote:
>>> I heard that ports' SVN is mirrored to Github. Isn't it enough to just
>>> create a branch or tag for each quarterly release? Even if quarterly
>>> packages are deleted, re-building packages from such branch/tag should
>>> allow to recreate those packages as required since the same code would
>>> give the same packages?
>> These branches already exist BTW:
>>
>> https://github.com/freebsd/freebsd-ports/tree/branches/2016Q3
> 
> the trouble is that the packages are deleted as soon as they are stable.

It is sort of amusing/depressing/hilarious of all the flavours and ways
everybody works with ports. And I've used them all, just hard core
building, postmaster, portsnap, pouderiere...
Each has its merit, but IMHO everything is not as bad as frozen in stone
CentOS packages. Where I have the feeling that I'm years behind on some
of the stuff, and the only way out is to start gathering and build
manually. Ports is way more comfortable.

For the Q-branches:
Storage could be an issue, but isn't this why we have ZFS with
snapshot/clones Just at the end of a Q freeze both ports and
distfiles in a snapshot.

--WjW


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

Re: Problems are a Curl upgrade on 12.0 current of Sun Oct 2

[Willem Jan Withagen]

On 5-12-2016 21:54, Willem Jan Withagen wrote:
> On 5-12-2016 20:21, Ed Schouten wrote:
>> Basename@FBSD_1.5 is the new symbol. Did you by any chance downgrade your
>> system?
> 
> Hi Ed,
> 
> Not that I know of. But then again things are sometimes not obvious.
> I just typed: pkg upgrade cmake, because I wanted to see if the new
> cmake had code for Boost 1.62 (But didn't)
> 
> My system is 12.0 current, which I do not really want to upgrade atm.
> since I've just completed the first consistent successful set of tests
> for Ceph. And every I upgraded, things started to unglue, and I needed
> to start fixing stuff over again.
> 
> So my guess is that I have a system that is too old to run what I
> fetched from pkg. This, because pkg-builder for 12-current actually
> builds on the newest and shiniest code that includes the version.
> 
> I could try locally rebuilding curl in the hope that it fixes itself
> because it does not (yet) have the versioning??

Right,

Manual, local, building fixes the versioning problem.

--WjW


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

Re: Problems are a Curl upgrade on 12.0 current of Sun Oct 2

[Willem Jan Withagen]

On 5-12-2016 20:21, Ed Schouten wrote:
> Basename@FBSD_1.5 is the new symbol. Did you by any chance downgrade your
> system?

Hi Ed,

Not that I know of. But then again things are sometimes not obvious.
I just typed: pkg upgrade cmake, because I wanted to see if the new
cmake had code for Boost 1.62 (But didn't)

My system is 12.0 current, which I do not really want to upgrade atm.
since I've just completed the first consistent successful set of tests
for Ceph. And every I upgraded, things started to unglue, and I needed
to start fixing stuff over again.

So my guess is that I have a system that is too old to run what I
fetched from pkg. This, because pkg-builder for 12-current actually
builds on the newest and shiniest code that includes the version.

I could try locally rebuilding curl in the hope that it fixes itself
because it does not (yet) have the versioning??

--WjW

> 
> On 5 Dec 2016 6:59 p.m., "Dimitry Andric"  wrote:
> 
>> On 05 Dec 2016, at 15:44, Willem Jan Withagen  wrote:
>>>
>>> Now some of my lining attempts give me:
>>>
>>> /usr/local/lib/libcurl.so: undefined reference to `basename@FBSD_1.5
>>> I guess that that libc has become versioned, of the version number got
>>> bumpped?
>>>
>>> So would I need to rebuild world?
>>
>> Yes, this was changed by Ed in r308264:
>>
>> https://svnweb.freebsd.org/base?view=revision&revision=308264
>>
>> Although I would think there might have been a backwards compat symbol...
>>
>> -Dimitry
>>
>>
> ___
> 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"

Problems are a Curl upgrade on 12.0 current of Sun Oct 2

[Willem Jan Withagen]

Now some of my lining attempts give me:

/usr/local/lib/libcurl.so: undefined reference to `basename@FBSD_1.5
I guess that that libc has become versioned, of the version number got
bumpped?

So would I need to rebuild world?

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

Re: running make makesum for multiple github repos

[Willem Jan Withagen]

On 27-11-2016 13:34, Mathieu Arnold wrote:
> Le 27/11/2016 à 12:57, Willem Jan Withagen a écrit :
>> On 26-11-2016 21:10, Mathieu Arnold wrote:
>>> Le 25/11/2016 à 12:46, Willem Jan Withagen a écrit :
>>>> Hi,
>>>>
>>>> I'm try in to make a port for Ceph, but it depens on a lot of github
>>>> modules.
>>> From having a quick look at the GH_TUPLE, it seems you have duplicate
>>> tags, the fourth field.  You seem to always put :ceph, but it *must* be
>>> unique.
>>>
>>> Also, you are using master at least twice, you must not use branch
>>> names, you must put tags or commit hashes.
>> Hi Mathieu,
>>
>> Your remarks pushed me in the right direction.
>> I needed to fix two things:
>> Fetching all the repos, and they needed to be IN the tree that is
>> fetched with master.
>>
>> So indeed the fourth field (which is called group) needs to be
>> different, then all the repos are fetched. Placing them in
>> subdirectories of ${WRKSRC} is done by adding the path after a / after
>> the group.
>>
>> IMHO a sort of an illogical last element of GH_TUPLE. And perhaps
>> deserves a bit/lot more explaining in the handbook.
> 
> It is all documented in the USE_GITHUB section[1] of the Porter's
> Handbook. The format of GH_TUPLE is described there too, and there are a
> few examples, including one extended one describing what you are trying
> to do.

I have reread the section, but still cannot really understand what I did
from the text... But that perhaps says more about me. :)

Perhaps it would help if the group/subdir is a more verbosely explained.
It, for one, does not tell that group needs to be exclusive for each
repo. And I still have no clue as to its function.

In the fourth field the group is required, and subdir is optional.

> The GH_TUPLE format is a bit strange, I agree, but the subdirectory
> could not be put in another place because the third field (commit or
> tag) can contain a / (there are a few examples in the tree), and the
> path can contain a : (I stumbled upon one).
> Also, GH_SUBDIR is optional, and it was a bad idea to put an optional
> part in the middle of the string.
> (And I'm not talking about the fact that GH_SUBDIR is newer than
> GH_TUPLE, and that backward compatibility needed to be kept.)

GH_TUPLE is also not very often used in the ports. So there are not that
many examples to find. And I appreciate backwards compatibility, and
starting to escape chars will not make it more ledgible.

>> It now looks like:
>> GH_TUPLE+=  ceph:xxHash:v0.5.1-2-g1f40c65:xxHash/src/xxHash
>> GH_TUPLE+=  ceph:isa-l:v2.16.0:isal/src/isa-l
>> GH_TUPLE+=  ceph:lua:lua-5.3-ceph:lua/src/lua
>> GH_TUPLE+=  ceph:Beast:999e2fa:Beast/src/Beast
>> GH_TUPLE+=  boostorg:boost:boost-1.61.0-275-g1790aff:boost/src/boost
>> GH_TUPLE+=  ceph:dpdk:a38e5ec:dpd/src/dpd
> 
> 1:
> https://www.freebsd.org/doc/en/books/porters-handbook/makefile-distfiles.html#makefile-master_sites-github
> 

That is where i got my info...

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

Re: running make makesum for multiple github repos

[Willem Jan Withagen]

On 26-11-2016 21:10, Mathieu Arnold wrote:
> Le 25/11/2016 à 12:46, Willem Jan Withagen a écrit :
>> Hi,
>>
>> I'm try in to make a port for Ceph, but it depens on a lot of github
>> modules.
> 
> From having a quick look at the GH_TUPLE, it seems you have duplicate
> tags, the fourth field.  You seem to always put :ceph, but it *must* be
> unique.
> 
> Also, you are using master at least twice, you must not use branch
> names, you must put tags or commit hashes.

Hi Mathieu,

Your remarks pushed me in the right direction.
I needed to fix two things:
Fetching all the repos, and they needed to be IN the tree that is
fetched with master.

So indeed the fourth field (which is called group) needs to be
different, then all the repos are fetched. Placing them in
subdirectories of ${WRKSRC} is done by adding the path after a / after
the group.

IMHO a sort of an illogical last element of GH_TUPLE. And perhaps
deserves a bit/lot more explaining in the handbook.

It now looks like:
GH_TUPLE+=  ceph:xxHash:v0.5.1-2-g1f40c65:xxHash/src/xxHash
GH_TUPLE+=  ceph:isa-l:v2.16.0:isal/src/isa-l
GH_TUPLE+=  ceph:lua:lua-5.3-ceph:lua/src/lua
GH_TUPLE+=  ceph:Beast:999e2fa:Beast/src/Beast
GH_TUPLE+=  boostorg:boost:boost-1.61.0-275-g1790aff:boost/src/boost
GH_TUPLE+=  ceph:dpdk:a38e5ec:dpd/src/dpd

Thanx for the help,
--WjW


> 
>> GH_TUPLE=   \
>> wjwithagen:ceph:master:ceph \
>> facebook:rocksdb:2.7.fb-4511-ge55f42f:ceph/src/rocksdb \
>>
>> ceph:ceph-erasure-code-corpus:b5c8634:ceph/ceph-erasure-code-corpus \
>> ceph:ceph-object-corpus:master:ceph/ceph-object-corpus \
>> ceph:civetweb:v1.5-1537-gcc0dfa1:ceph/src/civetweb \
>>
>> ceph:jerasure:v2-ceph:ceph/src/erasure-code/jerasure/jerasure \
>>
>> ceph:gf-complete:v3-ceph:ceph/src/erasure-code/jerasure/gf-complete \
>> ceph:googletest:ceph-release-1.7.x:ceph/src/googletest \
>> ceph:spdk:v1.2.0-39-g9322c25:ceph/src/spdk \
>> ceph:xxHash:v0.5.1-2-g1f40c65:ceph/src/xxHash \
>> ceph:isa-l:v2.16.0:ceph/src/isa-l \
>> ceph:lua:lua-5.3-ceph:ceph/src/lua \
>> ceph:Beast:999e2fa:ceph/src/Beast \
>> boostorg:boost:boost-1.61.0-275-g1790aff:ceph/src/boost \
>> ceph:dpdk:a38e5ec:ceph/src/dpdk \
>>
>> But if I want to make distinfo for this, it only generates:
>> TIMESTAMP = 1480073496
>> SHA256 (wjwithagen-ceph-master_GH0.tar.gz) =
>> b72d0f0e7c57249d144dcb4c2ecb426cb70f273be72bd587446e2d1ba71c3761
>> SIZE (wjwithagen-ceph-master_GH0.tar.gz) = 8935857
>> SHA256 (ceph-dpdk-a38e5ec_GH0.tar.gz) =
>> 2f88c1e6361c99b4525dbc524c0c56cb5a45273028045d966190e73c416a0b24
>> SIZE (ceph-dpdk-a38e5ec_GH0.tar.gz) = 16158917
>>
>> Being the main source and the last of the submodules.
>>
>> How do I get it to run makesum on all modules?
>>
>> Thanx
>> --WjW
>> ___
>> freebsd-ports@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
>> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>>
> 
> 

___
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: running make makesum for multiple github repos

[Willem Jan Withagen]

On 25-11-2016 20:43, Willem Jan Withagen wrote:
> On 25-11-2016 20:02, Kurt Jaeger wrote:
>> Hi!
>>
>>> How do I get it to run makesum on all modules?
>>
>> From what I understand, this feature is missing in make makesum
>> and for the time being, the distinfo needs some manual process
>> to update.
> 
> Auch, that is a hard one
> Guess I'm going to tweak it by adding one at the time, and keeping the sigs.
> 
> But there is going to be pain when repos upgrade ...

Tried doing it in:
/usr/ports/www/uchiwa

And there 'make makesum' does fetch all submodules, and builds distinfo

So I guess it should work.

--WjW


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

Re: running make makesum for multiple github repos

[Willem Jan Withagen]

On 25-11-2016 20:02, Kurt Jaeger wrote:
> Hi!
> 
>> How do I get it to run makesum on all modules?
> 
> From what I understand, this feature is missing in make makesum
> and for the time being, the distinfo needs some manual process
> to update.

Auch, that is a hard one
Guess I'm going to tweak it by adding one at the time, and keeping the sigs.

But there is going to be pain when repos upgrade ...

--WjW


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

running make makesum for multiple github repos

[Willem Jan Withagen]

Hi,

I'm try in to make a port for Ceph, but it depens on a lot of github
modules.

GH_TUPLE=   \
wjwithagen:ceph:master:ceph \
facebook:rocksdb:2.7.fb-4511-ge55f42f:ceph/src/rocksdb \

ceph:ceph-erasure-code-corpus:b5c8634:ceph/ceph-erasure-code-corpus \
ceph:ceph-object-corpus:master:ceph/ceph-object-corpus \
ceph:civetweb:v1.5-1537-gcc0dfa1:ceph/src/civetweb \

ceph:jerasure:v2-ceph:ceph/src/erasure-code/jerasure/jerasure \

ceph:gf-complete:v3-ceph:ceph/src/erasure-code/jerasure/gf-complete \
ceph:googletest:ceph-release-1.7.x:ceph/src/googletest \
ceph:spdk:v1.2.0-39-g9322c25:ceph/src/spdk \
ceph:xxHash:v0.5.1-2-g1f40c65:ceph/src/xxHash \
ceph:isa-l:v2.16.0:ceph/src/isa-l \
ceph:lua:lua-5.3-ceph:ceph/src/lua \
ceph:Beast:999e2fa:ceph/src/Beast \
boostorg:boost:boost-1.61.0-275-g1790aff:ceph/src/boost \
ceph:dpdk:a38e5ec:ceph/src/dpdk \

But if I want to make distinfo for this, it only generates:
TIMESTAMP = 1480073496
SHA256 (wjwithagen-ceph-master_GH0.tar.gz) =
b72d0f0e7c57249d144dcb4c2ecb426cb70f273be72bd587446e2d1ba71c3761
SIZE (wjwithagen-ceph-master_GH0.tar.gz) = 8935857
SHA256 (ceph-dpdk-a38e5ec_GH0.tar.gz) =
2f88c1e6361c99b4525dbc524c0c56cb5a45273028045d966190e73c416a0b24
SIZE (ceph-dpdk-a38e5ec_GH0.tar.gz) = 16158917

Being the main source and the last of the submodules.

How do I get it to run makesum on all modules?

I Looked in other ports on how to do this, but I see nothing out of the
ordinary.  And the makesum script is also only called with those 2
archive names.
So the collection in DISTFILES is not really what it should be.

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

running make makesum for multiple github repos

[Willem Jan Withagen]

Hi,

I'm try in to make a port for Ceph, but it depens on a lot of github
modules.

GH_TUPLE=   \
wjwithagen:ceph:master:ceph \
facebook:rocksdb:2.7.fb-4511-ge55f42f:ceph/src/rocksdb \

ceph:ceph-erasure-code-corpus:b5c8634:ceph/ceph-erasure-code-corpus \
ceph:ceph-object-corpus:master:ceph/ceph-object-corpus \
ceph:civetweb:v1.5-1537-gcc0dfa1:ceph/src/civetweb \

ceph:jerasure:v2-ceph:ceph/src/erasure-code/jerasure/jerasure \

ceph:gf-complete:v3-ceph:ceph/src/erasure-code/jerasure/gf-complete \
ceph:googletest:ceph-release-1.7.x:ceph/src/googletest \
ceph:spdk:v1.2.0-39-g9322c25:ceph/src/spdk \
ceph:xxHash:v0.5.1-2-g1f40c65:ceph/src/xxHash \
ceph:isa-l:v2.16.0:ceph/src/isa-l \
ceph:lua:lua-5.3-ceph:ceph/src/lua \
ceph:Beast:999e2fa:ceph/src/Beast \
boostorg:boost:boost-1.61.0-275-g1790aff:ceph/src/boost \
ceph:dpdk:a38e5ec:ceph/src/dpdk \

But if I want to make distinfo for this, it only generates:
TIMESTAMP = 1480073496
SHA256 (wjwithagen-ceph-master_GH0.tar.gz) =
b72d0f0e7c57249d144dcb4c2ecb426cb70f273be72bd587446e2d1ba71c3761
SIZE (wjwithagen-ceph-master_GH0.tar.gz) = 8935857
SHA256 (ceph-dpdk-a38e5ec_GH0.tar.gz) =
2f88c1e6361c99b4525dbc524c0c56cb5a45273028045d966190e73c416a0b24
SIZE (ceph-dpdk-a38e5ec_GH0.tar.gz) = 16158917

Being the main source and the last of the submodules.

How do I get it to run makesum on all modules?

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

Re: Why oh why am I getting all thes extras with Postfix

[Willem Jan Withagen]

On 9-10-2015 11:22, Matthew Seaman wrote:
> On 10/09/15 09:49, Willem Jan Withagen (ecoRacks) wrote:
>> Awkward things:
>> - my PHP is already on 5.6
>> - I explicitly try to prevent getting too much X11 stuff, so I definitly
>> don't want X-server and dri
>> - As a free bonus I also get linux_base.
>>
>> This is also the fact that weird things need to be fetched from
>> pkg.freebsd.org, instead of my own poudriere pakages
> 
> Does your own poudriere setup build all the packages you need?
> 
> In which case, you should disable the stock FreeBSD repo.  Create a file
> 
>/usr/local/etc/pkg/repos/FreeBSD.conf
> 
> containing:
> 
> FreeBSD: { enabled: no }
> 
> You also seem to have a repo labelled 'pkg.freebsd.org' -- that
> presumably comes from yet another repo.conf file under
> /usr/local/etc/pkg/repos, which I'm guessing is a duplicate of the
> default FreeBSD repo.  You probably don't need both that and the default
> FreeBSD repo configured, so rename the extra config file to something
> ending in other than .conf
> 
> Now, when you check with 'pkg -vv' you should only see your own repo.
> 
> If you do want to use a mixture of packages from the main FreeBSD repo
> and your own poudriere, then you need to make sure your own repo is
> higher priority than the FreeBSD one.  Just add 'priority: 1' lines to
> your repo.conf.  The FreeBSD repo is automatically at priority 0.
> 
> You will also need to be careful with default versions when doing this.
> php-5.6 is the default version in ports now, and it should be that in
> the recently created 2015Q4 branch which is what 10.2-RELEASE defaults
> to using.  Somewhere in your setup you have or used to have a setting
> that says to use php-5.5 as the default.  This means you have packages
> somewhere that have compiled-in dependencies on php55-foo modules, and
> that is what is causing pkg(8) to try and install them.  Find the
> setting -- look in /usr/local/etc/poudriere.d/*make.conf and chenge it
> to use php-5.6, and then do a poudriere bulk rebuild of everything (ie.
> with the '-c' flag) to remove anything that references php-5.5 from your
> repo.

This feedback was enough to review the complete poudiere/pkg setup.
And with everything rebuild, I had a lot less trouble with upgrading
postfix.

Thanx,
--WjW


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

Re: Why oh why am I getting all thes extras with Postfix

[Willem Jan Withagen]

On 9-10-2015 11:22, Matthew Seaman wrote:
> On 10/09/15 09:49, Willem Jan Withagen (ecoRacks) wrote:
>> Awkward things:
>> - my PHP is already on 5.6
>> - I explicitly try to prevent getting too much X11 stuff, so I definitly
>> don't want X-server and dri
>> - As a free bonus I also get linux_base.
>>
>> This is also the fact that weird things need to be fetched from
>> pkg.freebsd.org, instead of my own poudriere pakages
> 
> Does your own poudriere setup build all the packages you need?
> 
> In which case, you should disable the stock FreeBSD repo.  Create a file
> 
>/usr/local/etc/pkg/repos/FreeBSD.conf
> 
> containing:
> 
> FreeBSD: { enabled: no }

I'd like to use freebsd as alternative for things that I have not (yet)
included in my own packages. Or fro packages that I do not have a
modified config for.

> You also seem to have a repo labelled 'pkg.freebsd.org' -- that
> presumably comes from yet another repo.conf file under
> /usr/local/etc/pkg/repos, which I'm guessing is a duplicate of the
> default FreeBSD repo.  You probably don't need both that and the default
> FreeBSD repo configured, so rename the extra config file to something
> ending in other than .conf
> 
> Now, when you check with 'pkg -vv' you should only see your own repo.
> 
> If you do want to use a mixture of packages from the main FreeBSD repo
> and your own poudriere, then you need to make sure your own repo is
> higher priority than the FreeBSD one.  Just add 'priority: 1' lines to
> your repo.conf.  The FreeBSD repo is automatically at priority 0.

Ah, the final incantation I was looking for.
Exactly what I need.

> You will also need to be careful with default versions when doing this.
> php-5.6 is the default version in ports now, and it should be that in
> the recently created 2015Q4 branch which is what 10.2-RELEASE defaults
> to using.  Somewhere in your setup you have or used to have a setting
> that says to use php-5.5 as the default.  This means you have packages
> somewhere that have compiled-in dependencies on php55-foo modules, and
> that is what is causing pkg(8) to try and install them.  Find the
> setting -- look in /usr/local/etc/poudriere.d/*make.conf and chenge it
> to use php-5.6, and then do a poudriere bulk rebuild of everything (ie.
> with the '-c' flag) to remove anything that references php-5.5 from your
> repo.

That is one of the other problems that is hard to tackle, and probably
only can be circumvented by building all packages locally.

--WjW

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

Re: Why oh why am I getting all thes extras with Postfix

[Willem Jan Withagen (EcoRacks)]

> Op 10 okt. 2015 om 13:05 heeft Mel Pilgrim  
> het volgende geschreven:
> 
>> On 2015-10-09 01:49, Willem Jan Withagen (ecoRacks) wrote:
>> Hi,
>> 
>> Trying to upgrade Postfix, and this is what pkg suggests:
>> New packages to be INSTALLED:
>>  jpeg-turbo: 1.4.1 [zfs.digiware.nl]
>>  mozjpeg: 3.1_1 [FreeBSD]
>>  pth-hard: 2.0.7_1 [FreeBSD]
>>  pkg-devel: 1.6.99.1 [FreeBSD]
>>  php55: 5.5.30 [zfs.digiware.nl]
>>  php55-mbstring: 5.5.30 [zfs.digiware.nl]
>>  php55-zlib: 5.5.30 [zfs.digiware.nl]
>>  php55-session: 5.5.30 [zfs.digiware.nl]
>>  php55-xml: 5.5.30 [zfs.digiware.nl]
>>  php55-bz2: 5.5.30 [zfs.digiware.nl]
>>  php55-ctype: 5.5.30 [zfs.digiware.nl]
>>  php55-zip: 5.5.30 [zfs.digiware.nl]
>>  php55-filter: 5.5.30 [zfs.digiware.nl]
>>  php55-openssl: 5.5.30 [zfs.digiware.nl]
>>  php55-mcrypt: 5.5.30 [zfs.digiware.nl]
>>  php55-mysqli: 5.5.30 [zfs.digiware.nl]
>>  php55-json: 5.5.30 [zfs.digiware.nl]
>>  idnkit: 1.0_5 [pkg.freebsd.org]
>>  mysql-connector-c: 6.1.6 [FreeBSD]
>>  mysql55-client: 5.5.44_1 [FreeBSD]
>>  mariadb100-client: 10.0.21 [FreeBSD]
>>  mariadb55-client: 5.5.44 [FreeBSD]
>>  glproto: 1.4.17 [zfs.digiware.nl]
>>  xorg-server: 1.14.7_6,1 [pkg.freebsd.org]
>>  dri: 10.6.8,2 [pkg.freebsd.org]
>>  xkeyboard-config: 2.14 [pkg.freebsd.org]
>>  xkbcomp: 1.3.0 [pkg.freebsd.org]
>>  linux_base-c6: 6.6_6 [pkg.freebsd.org]
>>  gbm: 10.6.8 [zfs.digiware.nl]
>>  php55-sockets: 5.5.30 [zfs.digiware.nl]
>>  php55-mysql: 5.5.30 [zfs.digiware.nl]
>>  php55-hash: 5.5.30 [zfs.digiware.nl]
>>  php55-iconv: 5.5.30 [zfs.digiware.nl]
>>  php55-dom: 5.5.30 [zfs.digiware.nl]
>>  php55-readline: 5.5.30 [zfs.digiware.nl]
>>  ja-libslang: 1.4.5.j2_1 [FreeBSD]
>>  java-zoneinfo: 2015.f [pkg.freebsd.org]
>>  alsa-lib: 1.0.29 [pkg.freebsd.org]
>>  avahi-libdns: 0.6.31_2 [FreeBSD]
>>  avahi-app: 0.6.31_5 [FreeBSD]
>>  libdaemon: 0.14_1 [pkg.freebsd.org]
>> 
>> Awkward things:
>> - my PHP is already on 5.6
>> - I explicitly try to prevent getting too much X11 stuff, so I definitly
>> don't want X-server and dri
>> - As a free bonus I also get linux_base.
>> 
>> This is also the fact that weird things need to be fetched from
>> pkg.freebsd.org, instead of my own poudriere pakages
>> 
>> And I do not dare pressing 'Y' on the continue question to see if SAT is
>> going to change his mind once the packages have been downloaded...
>> 
>> So I'm thrown back to portinstall
> 
> What was the exact command you ran?  Was it something of the form "pkg 
> upgrade -x foo"?  I ask because pkg has a bug where providing an -x pattern 
> to pkg-upgrade results in it matching a bunch of uninstalled packages.
> 
> For a fun example, try running `pkg upgrade -x perl5`.  Even better (though 
> not for a slow machine) is `pkg upgrade -x p5-`, where it tell you it needs 
> to install ~5800 new packages. :-)
> 

Nope
Just 'pkg upgrade postfix'. 
Hoping that it would fetch for my own build packages. 
And that includes dovecot2 sasl

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

Why oh why am I getting all thes extras with Postfix

[Willem Jan Withagen (ecoRacks)]

Hi,

Trying to upgrade Postfix, and this is what pkg suggests:
New packages to be INSTALLED:
jpeg-turbo: 1.4.1 [zfs.digiware.nl]
mozjpeg: 3.1_1 [FreeBSD]
pth-hard: 2.0.7_1 [FreeBSD]
pkg-devel: 1.6.99.1 [FreeBSD]
php55: 5.5.30 [zfs.digiware.nl]
php55-mbstring: 5.5.30 [zfs.digiware.nl]
php55-zlib: 5.5.30 [zfs.digiware.nl]
php55-session: 5.5.30 [zfs.digiware.nl]
php55-xml: 5.5.30 [zfs.digiware.nl]
php55-bz2: 5.5.30 [zfs.digiware.nl]
php55-ctype: 5.5.30 [zfs.digiware.nl]
php55-zip: 5.5.30 [zfs.digiware.nl]
php55-filter: 5.5.30 [zfs.digiware.nl]
php55-openssl: 5.5.30 [zfs.digiware.nl]
php55-mcrypt: 5.5.30 [zfs.digiware.nl]
php55-mysqli: 5.5.30 [zfs.digiware.nl]
php55-json: 5.5.30 [zfs.digiware.nl]
idnkit: 1.0_5 [pkg.freebsd.org]
mysql-connector-c: 6.1.6 [FreeBSD]
mysql55-client: 5.5.44_1 [FreeBSD]
mariadb100-client: 10.0.21 [FreeBSD]
mariadb55-client: 5.5.44 [FreeBSD]
glproto: 1.4.17 [zfs.digiware.nl]
xorg-server: 1.14.7_6,1 [pkg.freebsd.org]
dri: 10.6.8,2 [pkg.freebsd.org]
xkeyboard-config: 2.14 [pkg.freebsd.org]
xkbcomp: 1.3.0 [pkg.freebsd.org]
linux_base-c6: 6.6_6 [pkg.freebsd.org]
gbm: 10.6.8 [zfs.digiware.nl]
php55-sockets: 5.5.30 [zfs.digiware.nl]
php55-mysql: 5.5.30 [zfs.digiware.nl]
php55-hash: 5.5.30 [zfs.digiware.nl]
php55-iconv: 5.5.30 [zfs.digiware.nl]
php55-dom: 5.5.30 [zfs.digiware.nl]
php55-readline: 5.5.30 [zfs.digiware.nl]
ja-libslang: 1.4.5.j2_1 [FreeBSD]
java-zoneinfo: 2015.f [pkg.freebsd.org]
alsa-lib: 1.0.29 [pkg.freebsd.org]
avahi-libdns: 0.6.31_2 [FreeBSD]
avahi-app: 0.6.31_5 [FreeBSD]
libdaemon: 0.14_1 [pkg.freebsd.org]

Awkward things:
- my PHP is already on 5.6
- I explicitly try to prevent getting too much X11 stuff, so I definitly 
don't want X-server and dri

- As a free bonus I also get linux_base.

This is also the fact that weird things need to be fetched from 
pkg.freebsd.org, instead of my own poudriere pakages


And I do not dare pressing 'Y' on the continue question to see if SAT is 
going to change his mind once the packages have been downloaded...


So I'm thrown back to portinstall

--WjW

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

Problem with the pkg datebase

[Willem Jan Withagen (EcoRacks)]

Hi,

Trying to run a 'pkg upgrade -f' which gives me:

pkg: sqlite error while executing UPDATE packages SET name=?1  WHERE
name=?2; in file pkg_jobs.c:1576: UNIQUE constraint failed: packages.name

And upgrading is not really possibe.

How do I fix the database?

--WjW



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

Why is pkg writting informational output to stderr??

[Willem Jan Withagen]

Hi,

I'm using a small tool (cronic) to reduce reporting pollution.
And one of the ways of doing it, is scanning stderr and exit-values.

But pkg emits this informational message over stderr.

Any chance of changing this line to stdout as well??

Regards,
--WjW


 Forwarded Message 
Subject: Cron  cronic /usr/sbin/pkg audit -F
Date: Sun,  8 Feb 2015 06:56:00 +0100 (CET)
From: Cron Daemon 
To: r...@smtp.digiware.nl

Cronic detected failure or error output for the command:
/usr/sbin/pkg audit -F

RESULT CODE: 0

ERROR OUTPUT:
pkg: vulnxml file up-to-date

STANDARD OUTPUT:
0 problem(s) in the installed packages found.


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

Re: [CFT] pkg 1.4.0 rc2

[Willem Jan Withagen]

On 6-12-2014 13:40, Baptiste Daroussin wrote:
> Hi,
> 
> We have released a new 1.4.0 rc2 version of pkg (available in
> ports-mgmt/pkg-devel) since first beta it has received tons of bug fixes and
> should be now way more reliable and able to handle ootb without mistakes
> upgrades like the gettext one and the perl one.
> 
> All reported issues should have been fixed since.
> 
> Please test that new version I would like to make it the final release if
> possible.

I missed the previous announcement, but this is "bothering" me for some
time already

I'm using this simple cronic script to reduce traffic from scripts with
nothing serious to report. But pkg still triggers:
-
# sudo cronic pkg audit -F
Cronic detected failure or error output for the command:
pkg audit -F

RESULT CODE: 0

ERROR OUTPUT:
pkg: vulnxml file up-to-date
--

And I wonder why this informational message is reported on STDERR, and
other real problems on STDOUT...

--
sudo cronic pkg audit
Cronic detected failure or error output for the command:
pkg audit

RESULT CODE: 1

ERROR OUTPUT:

STANDARD OUTPUT:
phpMyAdmin-4.2.13 is vulnerable:
phpMyAdmin -- XSS and DoS vulnerabilities
CVE: CVE-2014-9219
CVE: CVE-2014-9218
WWW: http://portaudit.FreeBSD.org/c9c46fbf-7b83-11e4-a96e-6805ca0b3d42.html

1 problem(s) in the installed packages found.
--

I would atleast to have case 1) also write to STDOUT.
And perhaps have case 2) report on STDERR.

--WjW



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

Re: pkg ABI empy

[Willem Jan Withagen]

On 2014-10-23 16:26, Willem Jan Withagen wrote:

Hi

I'm trying to run pkg update -F in a jail on a 8.4 host.
(8.4-STABLE FreeBSD 8.4-STABLE #222 r267755: Mon Jun 23 06:50:12 CEST 2014)

On the actual iron I get:
# pkg update -f
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100%   968 B   1.0k/s00:01
Fetching digests.txz: 100%2 MB   2.0M/s00:01
Fetching packagesite.txz: 100%5 MB   5.3M/s00:01
Processing new repository entries: 100%

The jail bombs out with:
Updating FreeBSD repository catalogue...
pkg: http://pkg.FreeBSD.org//latest/meta.txz: Not Found
pkg: repository FreeBSD has no meta file, using default settings
pkg: http://pkg.FreeBSD.org//latest/digests.txz: Not Found
pkg: Unable to update repository FreeBSD

/etc/pkg/FreeBSD.conf
FreeBSD: {
   url: "pkg+http://pkg.FreeBSD.org//latest";,
   mirror_type: "srv",
   signature_type: "fingerprints",
   fingerprints: "/usr/share/keys/pkg",
   enabled: yes
}

So I conclude that the ABI env is empty.

Short term solution to hardwire the configfile in the jail.
But why is the ABI empy? jail and parent are running the smae software


Please ignore... stupid pilot error,

The ${ABI} is eaten in the HERE-file expansion of my shellscript.

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

pkg ABI empy

[Willem Jan Withagen]

Hi

I'm trying to run pkg update -F in a jail on a 8.4 host.
(8.4-STABLE FreeBSD 8.4-STABLE #222 r267755: Mon Jun 23 06:50:12 CEST 2014)

On the actual iron I get:
# pkg update -f
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100%   968 B   1.0k/s00:01
Fetching digests.txz: 100%2 MB   2.0M/s00:01
Fetching packagesite.txz: 100%5 MB   5.3M/s00:01
Processing new repository entries: 100%

The jail bombs out with:
Updating FreeBSD repository catalogue...
pkg: http://pkg.FreeBSD.org//latest/meta.txz: Not Found
pkg: repository FreeBSD has no meta file, using default settings
pkg: http://pkg.FreeBSD.org//latest/digests.txz: Not Found
pkg: Unable to update repository FreeBSD

/etc/pkg/FreeBSD.conf
FreeBSD: {
  url: "pkg+http://pkg.FreeBSD.org//latest";,
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}

So I conclude that the ABI env is empty.

Short term solution to hardwire the configfile in the jail.
But why is the ABI empy? jail and parent are running the smae software

Regards,
--WjW


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

Re: Building subversion-1.8.10 under poudriere

[Willem Jan Withagen]

On 2014-08-27 15:09, Willem Jan Withagen wrote:

On 2014-08-27 14:41, Dimitry Andric wrote:

On 27 Aug 2014, at 14:15, Willem Jan Withagen  wrote:

Starting to use poudriere, and I'm pleasantly surprised. And even
more after the first install steps. Don't have to go to all the
different servers copy my ports-configs, and build...

So I'm trying to get subversion build in poudriere for 9.3 amd and I
keep running into:


cd subversion/svn && /bin/sh
/wrkdirs/usr/ports/devel/subversion/work/subversion-1.8.10/libtool
--tag=CC --silent --mode=link clang -all-static
-Werror=unknown-warning-option -O2 -pipe -fpic -DPIC
-fno-strict-aliasing-L/usr/local/lib -L/usr/local/lib/db5
-L/usr/local/lib  -rpath /usr/local/lib  -o svn  add-cmd.lo
blame-cmd.lo cat-cmd.lo changelist-cmd.lo checkout-cmd.lo
cl-conflicts.lo cleanup-cmd.lo commit-cmd.lo conflict-callbacks.lo
copy-cmd.lo delete-cmd.lo deprecated.lo diff-cmd.lo export-cmd.lo
file-merge.lo help-cmd.lo import-cmd.lo info-cmd.lo list-cmd.lo
lock-cmd.lo log-cmd.lo merge-cmd.lo mergeinfo-cmd.lo mkdir-cmd.lo
move-cmd.lo notify.lo patch-cmd.lo propdel-cmd.lo propedit-cmd.lo
propget-cmd.lo proplist-cmd.lo props.lo propset-cmd.lo
relocate-cmd.lo resolve-cmd.lo resolved-cmd.lo revert-cmd.lo
status-cmd.lo status.lo svn.lo switch-cmd.lo unlock-cmd.lo
update-cmd.lo upgrade-cmd.lo util.lo
../../subversion/libsvn_client/libsvn_client-1.la
../../subversion/libsvn_wc

/libsvn_wc-1.la ../../subversion/libsvn_ra/libsvn_ra-1.la
../../subversion/libsvn_delta/libsvn_delta-1.la
../../subversion/libsvn_diff/libsvn_diff-1.la
../../subversion/libsvn_subr/libsvn_subr-1.la -L/usr/local/lib
-laprutil-1 -ldb-5.3 -lgdbm -lexpat -liconv -L/usr/local/lib -lapr-1
-lcrypt -pthread -lintl

/usr/local/lib/libapr-1.a(apr_snprintf.o): In function `apr_vformatter':
strings/apr_snprintf.c:(.text+0x61c): undefined reference to `isnan'
clang: error: linker command failed with exit code 1 (use -v to see
invocation)


This is a problem in the devel/apr1 port.  It checks for modf(), finds
it in libc, then assumes isnan() also comes from libc.  However, that
does not work for static linking.

Please apply the attached patch for apr1, which I have been using for
some time now.


Hi Dimitry,

So this is due to me wanting to link things static?
Then I'll reconfig subversion to dynamic linking.
Because I don't have a clue (yet) as to how to get (and keep) custom
patches in a poudriere environment.


Right,

At least that was also the different between building via poudriere or 
just natively on the host: Static linking.

Atleast I now have a set of packesg that I can distribute.

Thanx for fixing my problem,
--WjW

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

Re: Building subversion-1.8.10 under poudriere

[Willem Jan Withagen]

On 2014-08-27 14:41, Dimitry Andric wrote:

On 27 Aug 2014, at 14:15, Willem Jan Withagen  wrote:

Starting to use poudriere, and I'm pleasantly surprised. And even more after 
the first install steps. Don't have to go to all the different servers copy my 
ports-configs, and build...

So I'm trying to get subversion build in poudriere for 9.3 amd and I keep 
running into:


cd subversion/svn && /bin/sh 
/wrkdirs/usr/ports/devel/subversion/work/subversion-1.8.10/libtool --tag=CC --silent 
--mode=link clang -all-static -Werror=unknown-warning-option -O2 -pipe -fpic -DPIC 
-fno-strict-aliasing-L/usr/local/lib -L/usr/local/lib/db5 -L/usr/local/lib  -rpath 
/usr/local/lib  -o svn  add-cmd.lo blame-cmd.lo cat-cmd.lo changelist-cmd.lo 
checkout-cmd.lo cl-conflicts.lo cleanup-cmd.lo commit-cmd.lo conflict-callbacks.lo 
copy-cmd.lo delete-cmd.lo deprecated.lo diff-cmd.lo export-cmd.lo file-merge.lo 
help-cmd.lo import-cmd.lo info-cmd.lo list-cmd.lo lock-cmd.lo log-cmd.lo merge-cmd.lo 
mergeinfo-cmd.lo mkdir-cmd.lo move-cmd.lo notify.lo patch-cmd.lo propdel-cmd.lo 
propedit-cmd.lo propget-cmd.lo proplist-cmd.lo props.lo propset-cmd.lo relocate-cmd.lo 
resolve-cmd.lo resolved-cmd.lo revert-cmd.lo status-cmd.lo status.lo svn.lo 
switch-cmd.lo unlock-cmd.lo update-cmd.lo upgrade-cmd.lo util.lo 
../../subversion/libsvn_client/libsvn_client-1.la ../../subversion/libsvn_wc

/libsvn_wc-1.la ../../subversion/libsvn_ra/libsvn_ra-1.la 
../../subversion/libsvn_delta/libsvn_delta-1.la 
../../subversion/libsvn_diff/libsvn_diff-1.la 
../../subversion/libsvn_subr/libsvn_subr-1.la -L/usr/local/lib -laprutil-1 
-ldb-5.3 -lgdbm -lexpat -liconv -L/usr/local/lib -lapr-1 -lcrypt -pthread -lintl

/usr/local/lib/libapr-1.a(apr_snprintf.o): In function `apr_vformatter':
strings/apr_snprintf.c:(.text+0x61c): undefined reference to `isnan'
clang: error: linker command failed with exit code 1 (use -v to see invocation)


This is a problem in the devel/apr1 port.  It checks for modf(), finds
it in libc, then assumes isnan() also comes from libc.  However, that
does not work for static linking.

Please apply the attached patch for apr1, which I have been using for
some time now.


Hi Dimitry,

So this is due to me wanting to link things static?
Then I'll reconfig subversion to dynamic linking.
Because I don't have a clue (yet) as to how to get (and keep) custom 
patches in a poudriere environment.


Thanx for the reply,
--WjW

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

Building subversion-1.8.10 under poudriere

[Willem Jan Withagen]

Hi,

Starting to use poudriere, and I'm pleasantly surprised. And even more 
after the first install steps. Don't have to go to all the different 
servers copy my ports-configs, and build...


So I'm trying to get subversion build in poudriere for 9.3 amd and I 
keep running into:



cd subversion/svn && /bin/sh 
/wrkdirs/usr/ports/devel/subversion/work/subversion-1.8.10/libtool 
--tag=CC --silent --mode=link clang -all-static 
-Werror=unknown-warning-option -O2 -pipe -fpic -DPIC 
-fno-strict-aliasing-L/usr/local/lib -L/usr/local/lib/db5 
-L/usr/local/lib  -rpath /usr/local/lib  -o svn  add-cmd.lo blame-cmd.lo 
cat-cmd.lo changelist-cmd.lo checkout-cmd.lo cl-conflicts.lo 
cleanup-cmd.lo commit-cmd.lo conflict-callbacks.lo copy-cmd.lo 
delete-cmd.lo deprecated.lo diff-cmd.lo export-cmd.lo file-merge.lo 
help-cmd.lo import-cmd.lo info-cmd.lo list-cmd.lo lock-cmd.lo log-cmd.lo 
merge-cmd.lo mergeinfo-cmd.lo mkdir-cmd.lo move-cmd.lo notify.lo 
patch-cmd.lo propdel-cmd.lo propedit-cmd.lo propget-cmd.lo 
proplist-cmd.lo props.lo propset-cmd.lo relocate-cmd.lo resolve-cmd.lo 
resolved-cmd.lo revert-cmd.lo status-cmd.lo status.lo svn.lo 
switch-cmd.lo unlock-cmd.lo update-cmd.lo upgrade-cmd.lo util.lo 
../../subversion/libsvn_client/libsvn_client-1.la 
../../subversion/libsvn_wc/libsvn_wc-1.la 
../../subversion/libsvn_ra/libsvn_ra-1.la 
../../subversion/libsvn_delta/libsvn_delta-1.la 
../../subversion/libsvn_diff/libsvn_diff-1.la 
../../subversion/libsvn_subr/libsvn_subr-1.la -L/usr/local/lib 
-laprutil-1 -ldb-5.3 -lgdbm -lexpat -liconv -L/usr/local/lib -lapr-1 
-lcrypt -pthread -lintl

/usr/local/lib/libapr-1.a(apr_snprintf.o): In function `apr_vformatter':
strings/apr_snprintf.c:(.text+0x61c): undefined reference to `isnan'
clang: error: linker command failed with exit code 1 (use -v to see 
invocation)

*** [subversion/svn/svn] Error code 1

Stop in /wrkdirs/usr/ports/devel/subversion/work/subversion-1.8.10.
*** [do-build] Error code 1

Stop in /usr/ports/devel/subversion.
===>  Cleaning for subversion-1.8.10_1



If I build just "by hand"  in /usr/ports it all just works fine.
Trashing the whole config and restarting does not help.

So one way or another the compiling/building oversees the fact that in 
 isnan() is a macro, and expects to link against a function to 
be supplied by a library.


Any suggestions as to how to fix this?

Normally I'd just try to whack the source into a working version, and go 
make && make install.

But how to do something like this under poudriere

Thanx,
--WjW

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

Re: Python install catch 22

[Willem Jan Withagen]

On 6-4-2014 4:22, Kubilay Kocak wrote:
> On 5/04/2014 9:12 PM, Willem Jan Withagen wrote:
>>
>>
>> Op 5 apr. 2014 om 05:48 heeft Shane Ambler  het 
>> volgende geschreven:
>>
>>> On 04/04/2014 22:42, Willem Jan Withagen wrote:
>>>> Hi,
>>>>
>>>> I've tried to upgrade my python 2.7 which did not work.
>>>> Then I deinstalled all python stuff and tried to install python3 (aka 3.3)
>>>
>>> You can install both versions of python (2.7 & 3.3) at the same time,
>>> but currently you can only install a module to one of the versions at a
>>> time.
>>
>> Sorry,
>>
>> I did not explain  the situation clear enough.
>>
>> I was at 2.7, and wanted to install a 2.7 upgrade because of a bug.
>> If memory serves me, from 2.7.3 to 2.7.6
>>
>> But that started mounting about missing db stuff, and having to install a 
>> py/db of choice.
>> That is where I ran into the catch22, installing a db required py-tools, 
>> which in turn starts to try to upgrade python from 2.7.3 to 2.7.6.
> 
> Hi Willem,
> 
> a) Can you clarify/confirm whether you tried installing/upgrading Python
> via ports or packages.
> 
> b) Tell us exactly (method & commands) how you attempted to upgrade
> Python 2.7 to Python 3.3
> 
> b) If via ports, it would be helpful to know how and why the dbm module
> fails to build for python33
> 
> Either attach a complete build log here, or join us on IRC
> #freebsd-python on freenode so we can help you isolate.
> 
> Koobs
> 
> 
>> Then I cleaned/removed al python stuff, and tried again.
>> First with 2.7 and when that did not work, I tried 3.3 with the same result.
>> I tried with portinstall/portupgrade as well as make && make install, but 
>> both fail for the same reason.
>>
>> So atm I have no python at al.
>>
>>> So far there are still many modules that don't work with 3.x so you may
>>> want to use 2.7 if you want python with more than the default modules.
>>>
>>> The default python is still 2.7, if you want to use 3.3 then you might
>>> want to add
>>> DEFAULT_VERSIONS=PYTHON=3.3 PYTHON3=3.3
>>> to your /etc/make.conf
>>>
>>>> The system everytime refuses to install because of missing a database:
>>>>
>>>> pkg-static:
>>>> lstat(/home2/usr/ports/lang/python33/work/stage/usr/local/lib/python3.3/lib-dynload/_dbm.so):
>>>> No such file or directory
>>>> *** [fake-pkg] Error code 74
>>>>
>>>> [ replace python33 by python27 te get the similar error for 2.7 ]
>>>
>>> This would indicate that the dbm module wasn't built. It should be built
>>> and is a module that gives access to others that may be installed from
>>> the list below. The db modules below don't need to be installed first
>>> for _dbm.so to be built.
>>>
>>> This is an error compiling not related to the other modules. If your
>>> using a gui then scrollback in the terminal to see the error - increase
>>> scrollback limit if needed, from cli maybe use script to keep a log of
>>> the build to look through.
>>
>> Using command line in putty.
>> I will try again, and scan de build output for more errors. So there should 
>> be an error building the part in the stage tree?
>>
>>
>>>
>>> gettext libiconv and gmake are the only things that need to be installed
>>> before python to build.
>>
>> So where does it get the DBMS stuff from?
>>
>>> Maybe there is an issue with you not building
>>> from /usr/ports ?
>>
>> That would be a first. This config is like this for about 6 years.
>> And /user/ports links to this tree.
>>
>>>
>>>> And then hints:
>>>> 
>>>> Note that some of the standard modules are provided as separate
>>>> ports since they require extra dependencies:
>>>>
>>>> gdbmdatabases/py-gdbm
>>>> sqlite3 databases/py-sqlite3
>>>> tkinter x11-toolkits/py-tkinter
>>>>
>>>> Install them as needed.
>>>> 
>>>>
>>>> Which is nasty catch22, because one needs a recent/working python to
>>>> actually be able to do this.
>>>>
>>>> How do other cope with this?
>>>>
>>>
>>> Could using pkg to install a prebuilt binary package be an option?
>>
>> That would be the alternative, but I only do 

Re: Python install catch 22

[Willem Jan Withagen]

Op 6 apr. 2014 om 04:22 heeft Kubilay Kocak  het 
volgende geschreven:

> On 5/04/2014 9:12 PM, Willem Jan Withagen wrote:
>> 
>> 
>> Op 5 apr. 2014 om 05:48 heeft Shane Ambler  het 
>> volgende geschreven:
>> 
>>> On 04/04/2014 22:42, Willem Jan Withagen wrote:
>>>> Hi,
>>>> 
>>>> I've tried to upgrade my python 2.7 which did not work.
>>>> Then I deinstalled all python stuff and tried to install python3 (aka 3.3)
>>> 
>>> You can install both versions of python (2.7 & 3.3) at the same time,
>>> but currently you can only install a module to one of the versions at a
>>> time.
>> 
>> Sorry,
>> 
>> I did not explain  the situation clear enough.
>> 
>> I was at 2.7, and wanted to install a 2.7 upgrade because of a bug.
>> If memory serves me, from 2.7.3 to 2.7.6
>> 
>> But that started mounting about missing db stuff, and having to install a 
>> py/db of choice.
>> That is where I ran into the catch22, installing a db required py-tools, 
>> which in turn starts to try to upgrade python from 2.7.3 to 2.7.6.
> 
> Hi Willem,
> 
> a) Can you clarify/confirm whether you tried installing/upgrading Python
> via ports or packages.

Ports.
To be honnest, i only considered packages, after you mentioned them.

> 
> b) Tell us exactly (method & commands) how you attempted to upgrade
> Python 2.7 to Python 3.3

Sorry that I've still not been clear.
The upgrade was needed because 'pkg audit' reported a bug.
I used 'portupgrade python27' to get to the most python27. 

The 'portinstall python33' was only to see if that would not have the same 
problem.
I first removed all dependant on python27.

> 
> b) If via ports, it would be helpful to know how and why the dbm module
> fails to build for python33
> 
> Either attach a complete build log here, or join us on IRC
> #freebsd-python on freenode so we can help you isolate.

I'll see if I have some time today to get this going, an will get you the log.

--WjW
> 
> Koobs
> 
> 
>> Then I cleaned/removed al python stuff, and tried again.
>> First with 2.7 and when that did not work, I tried 3.3 with the same result.
>> I tried with portinstall/portupgrade as well as make && make install, but 
>> both fail for the same reason.
>> 
>> So atm I have no python at al.
>> 
>>> So far there are still many modules that don't work with 3.x so you may
>>> want to use 2.7 if you want python with more than the default modules.
>>> 
>>> The default python is still 2.7, if you want to use 3.3 then you might
>>> want to add
>>> DEFAULT_VERSIONS=PYTHON=3.3 PYTHON3=3.3
>>> to your /etc/make.conf
>>> 
>>>> The system everytime refuses to install because of missing a database:
>>>> 
>>>> pkg-static:
>>>> lstat(/home2/usr/ports/lang/python33/work/stage/usr/local/lib/python3.3/lib-dynload/_dbm.so):
>>>> No such file or directory
>>>> *** [fake-pkg] Error code 74
>>>> 
>>>> [ replace python33 by python27 te get the similar error for 2.7 ]
>>> 
>>> This would indicate that the dbm module wasn't built. It should be built
>>> and is a module that gives access to others that may be installed from
>>> the list below. The db modules below don't need to be installed first
>>> for _dbm.so to be built.
>>> 
>>> This is an error compiling not related to the other modules. If your
>>> using a gui then scrollback in the terminal to see the error - increase
>>> scrollback limit if needed, from cli maybe use script to keep a log of
>>> the build to look through.
>> 
>> Using command line in putty.
>> I will try again, and scan de build output for more errors. So there should 
>> be an error building the part in the stage tree?
>> 
>> 
>>> 
>>> gettext libiconv and gmake are the only things that need to be installed
>>> before python to build.
>> 
>> So where does it get the DBMS stuff from?
>> 
>>> Maybe there is an issue with you not building
>>> from /usr/ports ?
>> 
>> That would be a first. This config is like this for about 6 years.
>> And /user/ports links to this tree.
>> 
>>> 
>>>> And then hints:
>>>> 
>>>> Note that some of the standard modules are provided as separate
>>>> ports since they require extra dependencies:
>>>> 
>>>> gd

Re: Python install catch 22

[Willem Jan Withagen]

Op 5 apr. 2014 om 05:48 heeft Shane Ambler  het volgende 
geschreven:

> On 04/04/2014 22:42, Willem Jan Withagen wrote:
>> Hi,
>> 
>> I've tried to upgrade my python 2.7 which did not work.
>> Then I deinstalled all python stuff and tried to install python3 (aka 3.3)
> 
> You can install both versions of python (2.7 & 3.3) at the same time,
> but currently you can only install a module to one of the versions at a
> time.

Sorry,

I did not explain  the situation clear enough.

I was at 2.7, and wanted to install a 2.7 upgrade because of a bug.
If memory serves me, from 2.7.3 to 2.7.6

But that started mounting about missing db stuff, and having to install a py/db 
of choice.
That is where I ran into the catch22, installing a db required py-tools, which 
in turn starts to try to upgrade python from 2.7.3 to 2.7.6.

Then I cleaned/removed al python stuff, and tried again.
First with 2.7 and when that did not work, I tried 3.3 with the same result.
I tried with portinstall/portupgrade as well as make && make install, but both 
fail for the same reason.

So atm I have no python at al.

> So far there are still many modules that don't work with 3.x so you may
> want to use 2.7 if you want python with more than the default modules.
> 
> The default python is still 2.7, if you want to use 3.3 then you might
> want to add
> DEFAULT_VERSIONS=PYTHON=3.3 PYTHON3=3.3
> to your /etc/make.conf
> 
>> The system everytime refuses to install because of missing a database:
>> 
>> pkg-static:
>> lstat(/home2/usr/ports/lang/python33/work/stage/usr/local/lib/python3.3/lib-dynload/_dbm.so):
>> No such file or directory
>> *** [fake-pkg] Error code 74
>> 
>> [ replace python33 by python27 te get the similar error for 2.7 ]
> 
> This would indicate that the dbm module wasn't built. It should be built
> and is a module that gives access to others that may be installed from
> the list below. The db modules below don't need to be installed first
> for _dbm.so to be built.
> 
> This is an error compiling not related to the other modules. If your
> using a gui then scrollback in the terminal to see the error - increase
> scrollback limit if needed, from cli maybe use script to keep a log of
> the build to look through.

Using command line in putty.
I will try again, and scan de build output for more errors. So there should be 
an error building the part in the stage tree?


> 
> gettext libiconv and gmake are the only things that need to be installed
> before python to build.

So where does it get the DBMS stuff from?

> Maybe there is an issue with you not building
> from /usr/ports ?

That would be a first. This config is like this for about 6 years.
And /user/ports links to this tree.

> 
>> And then hints:
>> 
>> Note that some of the standard modules are provided as separate
>> ports since they require extra dependencies:
>> 
>> gdbmdatabases/py-gdbm
>> sqlite3 databases/py-sqlite3
>> tkinter x11-toolkits/py-tkinter
>> 
>> Install them as needed.
>> 
>> 
>> Which is nasty catch22, because one needs a recent/working python to
>> actually be able to do this.
>> 
>> How do other cope with this?
>> 
> 
> Could using pkg to install a prebuilt binary package be an option?

That would be the alternative, but I only do that, if nothing else works.
I've grown to always build my stuff.

> 
> What FreeBSD version are you using?

I386 9.2-STABLE

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

Python install catch 22

[Willem Jan Withagen]

Hi,

I've tried to upgrade my python 2.7 which did not work.
Then I deinstalled all python stuff and tried to install python3 (aka 3.3)

The system everytime refuses to install because of missing a database:

pkg-static:
lstat(/home2/usr/ports/lang/python33/work/stage/usr/local/lib/python3.3/lib-dynload/_dbm.so):
No such file or directory
*** [fake-pkg] Error code 74

[ replace python33 by python27 te get the similar error for 2.7 ]

And then hints:

Note that some of the standard modules are provided as separate
ports since they require extra dependencies:

gdbmdatabases/py-gdbm
sqlite3 databases/py-sqlite3
tkinter x11-toolkits/py-tkinter

Install them as needed.


Which is nasty catch22, because one needs a recent/working python to
actually be able to do this.

How do other cope with this?

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