Re: Request for help: remove bundler from ruby 2.6 port

2018-12-29 Thread Yasuhiro KIMURA
From: Adam Weinberger 
Subject: Re: Request for help: remove bundler from ruby 2.6 port
Date: Sat, 29 Dec 2018 15:34:17 -0700

> I think perhaps it's worth considering doing the opposite and,
> beginning with 2.6, install the entire standard library by default.
> Gems and stdlib exist side-by-side without problem, and many of the
> gems that are deleted are generally kept up-to-date.
> 
> Even if we don't want to install the entire standard library, I'd at
> least strongly argue for including the most important gems (rake, gem,
> minitest, and bundler) by default. They are basic components of ruby
> itself, and ports should provide //optional// newer versions of them.

From: Pete Wright 
Subject: Re: Request for help: remove bundler from ruby 2.6 port
Date: Sat, 29 Dec 2018 16:41:32 -0800

> +1 from me on this.
> 
> i think the benefits of lowering the porting overhead combined with
> the fact that most ruby envs i've supported (and currently support)
> are built around the expectation that rake, gem and bundler are all
> available - so this would lower my administrative overhead as well.

Thank you for reply. Then I'm going to create full port and post here
again. But I'm away from this evening to next Saturday and can't
access development environment during that time. So if someone else
want to try it, please don't hesitate.

Best Regards.

---
Yasuhiro KIMURA
___
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: Maia Mailgaurd / PHP 7 support

2018-12-29 Thread Miroslav Lachman

Janketh Jay wrote on 2018/12/30 01:03:

Hi All,

On 03/12/2018 2:17 pm, Reko Turja via freebsd-ports wrote:

Hello Janky Jay!

-Original Message- Sent: Monday, December 3, 2018 4:17 PM
Subject: Re: Maia Mailgaurd


Okay. No sweat. I'll work on getting a port patch going as that seems
it would be the easiest way to push this out. I'll provide a download as
soon as I have something available for testing.


Sounds good, thank you for your work on ports!

-Reko



   So, after a bit of testing (and not being able to update the port 
for PHP7 due to Smarty issues), below is a simple patch that will keep 
the current port version of Maia (1.0.4_3) working with PHP7 (testing 
with PHP 7.2). Please let me know if this does not work or if there is 
anything else that needs to be added or changed. Hopefully, I'll get the 
Smarty issue(s) sorted out soon and have a new port submitted.


[...]

   Also, if you're interested in seeing/testing the new port (from 
the latest Github commit for technion's maia_mailguard), you can 
download the patch from the link below [1] and let me know if it's 
successful for you. Everything seems to work except for the WebUI due to 
a fatal call to Smarty which I cannot figure out (I'm not a PHP 
developer). However, once that is sorted, I should be ready to submit 
the new port so Maia can be updated to the latest version.


I forgot about this in my previous message - I guess there is an old 
version of Smarty not supporting PHP 7. It would be probably better to 
replace it with newer version of Smarty with PHP 7 support but there can 
be some syntax changes in Smarty config / initialisation. I remember 
something about it about a year ago when I was upgrading one of our own 
(very old) project to newer Smarty templates. There are some differences 
between Smarty 2 and Smarty 3. But as I read now on their website, the 
latest Smarty 2 version 2.6.31 supports PHP 7.2 so it should be painless 
to replace old noncompatible version with this one.


Kind regards
Miroslav Lachman

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


Re: Maia Mailgaurd

2018-12-29 Thread Miroslav Lachman

Janketh Jay wrote on 2018/12/30 01:03:

[...]


diff -Naur maia.orig/cache.php maia/cache.php
--- maia.orig/cache.php 2015-02-15 15:19:45.0 -0700
+++ maia/cache.php  2018-10-14 20:25:30.27896 -0600
@@ -554,7 +554,7 @@
  $rectmp = "";
  foreach ($to_list as $recipient) {
  if (isset($personal_addresses[$recipient]) || 
$domain_default) {

-  $rectmp[] = $recipient;
+  $rectmp = $recipient;
  }
  }
  $rows[$count]['recipient_email'] = $rectmp;


   Essentially, you just need to remove the "[]" from "rectmp" on 
line 558 in your /usr/local/www/maia/cache.php file.


I don't use Maia Mailguard and I didn't read the source code but I think 
your patch is wrong. It changed the function. Original code assigned all 
recipient addresses (appending) in to an array (hash) $rectmp in a 
foreach loop and then assign this array to $rows[$count]['recipient_email'].
But now you are using it as variable so if there are more than one 
recipient this variable is overwritten on each iteration and then just 
the last recipient is assigned to $rows[$count]['recipient_email'].


My very wild guess is that it should be like this

-$rectmp = "";
+$rectmp = array();
 foreach ($to_list as $recipient) {
 if (isset($personal_addresses[$recipient]) || 
$domain_default) {

  $rectmp[] = $recipient;
 }
 }
 $rows[$count]['recipient_email'] = $rectmp;

I guess you want to fix some PHP 7 warning / syntax error with $rectmp 
created ass plain variable and later used as an array so I defined as an 
array first.


But maybe I am totally wrong :)

I just made similar fix few days ago in an old version of PostfixAdmin 
after upgrade from PHP 5.6 to 7.1.



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


Re: Request for help: remove bundler from ruby 2.6 port

2018-12-29 Thread Pete Wright




On 12/29/18 2:34 PM, Adam Weinberger wrote:

On Sat, Dec 29, 2018 at 6:20 AM Yasuhiro KIMURA  wrote:

Hello all,

Ruby 2.6.0 is released and I tried porting it.

After creating start point by 'svn copy lang/ruby25 lang/ruby26', I
made following changes.

https://www.utahime.org/FreeBSD/ports/lang_ruby26.patch

It is build successfully and works fine on 12.0-RELEASE amd64. But
there is still one issue left.

 From 2.6.0 ruby includes 'bundler'. But according to the convention of
ruby port it should be removed from ruby core port in the same way as
'gem' and 'rake'. I learned from Makefile that it is achieved by
removing related files from source tree at post-patch target. However
I don't know enough about what files need to be removed to cleanly
remove bundler from ruby 2.6 port.

So would someone please help me about it?

I think perhaps it's worth considering doing the opposite and,
beginning with 2.6, install the entire standard library by default.
Gems and stdlib exist side-by-side without problem, and many of the
gems that are deleted are generally kept up-to-date.

Even if we don't want to install the entire standard library, I'd at
least strongly argue for including the most important gems (rake, gem,
minitest, and bundler) by default. They are basic components of ruby
itself, and ports should provide //optional// newer versions of them.

+1 from me on this.

i think the benefits of lowering the porting overhead combined with the 
fact that most ruby envs i've supported (and currently support) are 
built around the expectation that rake, gem and bundler are all 
available - so this would lower my administrative overhead as well.


i will hopefully have time to give your patch a test on my end this 
weekend and send some feedback.


cheers,
-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
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: Maia Mailgaurd

2018-12-29 Thread Janketh Jay

Hi All,

On 03/12/2018 2:17 pm, Reko Turja via freebsd-ports wrote:

Hello Janky Jay!

-Original Message- Sent: Monday, December 3, 2018 4:17 PM
Subject: Re: Maia Mailgaurd


Okay. No sweat. I'll work on getting a port patch going as that seems
it would be the easiest way to push this out. I'll provide a download 
as

soon as I have something available for testing.


Sounds good, thank you for your work on ports!

-Reko



  So, after a bit of testing (and not being able to update the port 
for PHP7 due to Smarty issues), below is a simple patch that will keep 
the current port version of Maia (1.0.4_3) working with PHP7 (testing 
with PHP 7.2). Please let me know if this does not work or if there is 
anything else that needs to be added or changed. Hopefully, I'll get the 
Smarty issue(s) sorted out soon and have a new port submitted.


diff -Naur maia.orig/cache.php maia/cache.php
--- maia.orig/cache.php 2015-02-15 15:19:45.0 -0700
+++ maia/cache.php  2018-10-14 20:25:30.27896 -0600
@@ -554,7 +554,7 @@
 $rectmp = "";
 foreach ($to_list as $recipient) {
 if (isset($personal_addresses[$recipient]) || 
$domain_default) {

-  $rectmp[] = $recipient;
+  $rectmp = $recipient;
 }
 }
 $rows[$count]['recipient_email'] = $rectmp;


  Essentially, you just need to remove the "[]" from "rectmp" on 
line 558 in your /usr/local/www/maia/cache.php file.


  Also, if you're interested in seeing/testing the new port (from 
the latest Github commit for technion's maia_mailguard), you can 
download the patch from the link below [1] and let me know if it's 
successful for you. Everything seems to work except for the WebUI due to 
a fatal call to Smarty which I cannot figure out (I'm not a PHP 
developer). However, once that is sorted, I should be ready to submit 
the new port so Maia can be updated to the latest version.


1. https://www.purplehat.org/downloads/maia/maia-1.0.4-g20181202.diff

Regards,
Janky Jay, III
___
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: Request for help: remove bundler from ruby 2.6 port

2018-12-29 Thread Adam Weinberger
On Sat, Dec 29, 2018 at 6:20 AM Yasuhiro KIMURA  wrote:
>
> Hello all,
>
> Ruby 2.6.0 is released and I tried porting it.
>
> After creating start point by 'svn copy lang/ruby25 lang/ruby26', I
> made following changes.
>
> https://www.utahime.org/FreeBSD/ports/lang_ruby26.patch
>
> It is build successfully and works fine on 12.0-RELEASE amd64. But
> there is still one issue left.
>
> From 2.6.0 ruby includes 'bundler'. But according to the convention of
> ruby port it should be removed from ruby core port in the same way as
> 'gem' and 'rake'. I learned from Makefile that it is achieved by
> removing related files from source tree at post-patch target. However
> I don't know enough about what files need to be removed to cleanly
> remove bundler from ruby 2.6 port.
>
> So would someone please help me about it?

I think perhaps it's worth considering doing the opposite and,
beginning with 2.6, install the entire standard library by default.
Gems and stdlib exist side-by-side without problem, and many of the
gems that are deleted are generally kept up-to-date.

Even if we don't want to install the entire standard library, I'd at
least strongly argue for including the most important gems (rake, gem,
minitest, and bundler) by default. They are basic components of ruby
itself, and ports should provide //optional// newer versions of them.

# Adam


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


net/kea: Update 1.5.0

2018-12-29 Thread Andrey Pevnev
Hi guys!

 Can someone look at and possibly commit this one please? 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234032 


 Release Notes: https://ftp.isc.org/isc/kea/1.5.0/Kea150ReleaseNotes.txt 


 koobs@ did some updates to the bug report but it’s currently assigned to hrs@ 
and I doubt he’ll look at it any time soon (2 weeks passed).

Thanks and Happy Holidays!


P.S.
As “sysrepo” does not seem to be available in the FreeBSD ports - I did not 
include that option with KEA, but that can be easily added if there is enough 
interest in sysrepo/YANG stuff.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


FreeBSD ports you maintain which are out of date

2018-12-29 Thread portscout
Dear port maintainer,

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

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

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


Port| Current version | New version
+-+
graphics/xmedcon| 0.15.0  | 0.16.1
+-+


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

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

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


Request for help: remove bundler from ruby 2.6 port

2018-12-29 Thread Yasuhiro KIMURA
Hello all,

Ruby 2.6.0 is released and I tried porting it.

After creating start point by 'svn copy lang/ruby25 lang/ruby26', I
made following changes.

https://www.utahime.org/FreeBSD/ports/lang_ruby26.patch

It is build successfully and works fine on 12.0-RELEASE amd64. But
there is still one issue left.

>From 2.6.0 ruby includes 'bundler'. But according to the convention of
ruby port it should be removed from ruby core port in the same way as
'gem' and 'rake'. I learned from Makefile that it is achieved by
removing related files from source tree at post-patch target. However
I don't know enough about what files need to be removed to cleanly
remove bundler from ruby 2.6 port.

So would someone please help me about it?

Best Regards.

---
Yasuhiro KIMURA
___
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: lang/python36 port problem

2018-12-29 Thread Scott Bennett
Kubilay Kocak  wrote:

> On 23/12/2018 8:11 pm, Scott Bennett wrote:
> >   The last time lang/python36 was updated, something got messed up, so 
> > that
> > now "portmaster -a" wants to reinstall it every time it is run, even if it 
> > is
> > run as "portmaster -x Python36 -x python36 -a".  It's a nuisance, a waste of
> > time, and it increases the size of incremental backups.
> > 
>
> Hi Scott,
>
> What what the exact port version/revision that the issue you observe 
> first started?
>
 I'm not sure because it was going on for a while before I noticed it.
However, I found a way to make it stop.  Searching back through the logs,
I found an example of portmaster reinstalling as an *upgrade* from python34,
which I no longer have installed.  There is no python34 binary or other files
as far as I can see, nor is there anything in /usr/ports/distfiles for
[Pp]ython34*, nor is there a /usr/ports/lang/python34 directory.  My pkg data
base appears to have an entry for it that says it *is* installed.  I have no
clue how this situation came about.  I don't know sqlite (or whichever data
base system is used by pkg(8)), so I have no idea how to delete the bad entry.
Meanwhile, adding "-x Python34 -x python34" has stopped the reinstallations.

> What is the FreeBSD version (uname -a) of the system?

 It's 11.2-STABLE at r341329, but that probably is irrelevant now, given
the problem in my pkg data base.
>
> Is the ports system portsnap based, or svn based? If the latter, is the 
> tree up to date and free of conflicts/local updates?

 The FreeBSD ports tree, in my experience, has *never* been free of
conflicts.  I maintain a one-line file of my portmaster -a command that shows
all the -x parameters for the many installed ports that no longer build for
one reason or another.  But, yes, the tree is rarely more than a day or two
out of date.
>
> Does pkg version show the port as out of date? What is the output of pkg 
> version -v |grep -i python?

 Given that the package is not installed, pkg info python34 output is:

python34-3.4.9_1
Name   : python34
Version: 3.4.9_1
Installed on   : Mon Aug  6 10:57:21 2018 CDT
Origin : lang/python34
Architecture   : FreeBSD:11:amd64
Prefix : /usr/local
Categories : python lang ipv6
Licenses   : PSFL
Maintainer : pyt...@freebsd.org
WWW: https://www.python.org/
Comment: Interpreted object-oriented programming language
Options:
DEBUG  : off
FNV: off
IPV6   : on
LIBFFI : on
NLS: on
PYMALLOC   : on
SIPHASH: off
THREADS: on
TSC: off
Shared Libs required:
libcrypto.so.9
libintl.so.8
libreadline.so.7
libncursesw.so.6
libtinfow.so.6
libpanelw.so.6
libssl.so.9
libffi.so.6
Shared Libs provided:
libpython3.4m.so.1
Annotations:
FreeBSD_version: 1101512
cpe: cpe:2.3:a:python:python:3.4.9:freebsd11:x64:1
Flat size  : 80.0MiB
Description:
Python is an interpreted object-oriented programming language, and is
often compared to Tcl, Perl or Scheme.

WWW: https://www.python.org/

>
 FWIW, I will be off-line for email until late Wednesday night, so it
may be a while before I get to anything you may post in reply.
 Thanks for responding.


  Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
**
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."   *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
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: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)

2018-12-29 Thread Mark Millard via freebsd-ports


On 2018-Dec-28, at 12:12, Mark Millard  wrote:

> On 2018-Dec-28, at 05:13, Michal Meloun  wrote:
> 
>> Mark,
>> this is known problem with qemu-user-static.
>> Emulation of every single interruptible syscall is broken by design (it
>> have signal related races). Theses races cannot be solved without major
>> rewrite of syscall emulation code.
>> Unfortunately, nobody actively works on this, I think.
>> 
> 
> Thanks for the note setting some expectations.
> 
> On the evidence that I have I expect that more is going on than that:
> 
> A) The hang-up always happens and always in the same place. So
> it would appear that no race is involved.
> 
> B) (A) is true even for varying the number of builders in parallel
> (so other builds also happening) and the number of jobs allowed per
> builder. It also fails for only one builder allowed only one process.
> (I get traces from that last kind of context.)
> 
> C) The problem started on the package-building servers for armv7
> and armv6 without qemu-user-static having an update (FreeBSD and
> cmake had updates, for example).
> 
> D) The problem is only observed for targeting armv7 and armv6 as
> far as I can tell. I've never seen it for aarch64, neither my
> own builds nor when I looked at the package-building server
> history.
> 
> At least that is what got me started. (I've since learned that
> qemu-user-static uses fork in place of a requested vfork.)
> 
> My ktrace/kdump experiment yesterday showed something odd for the
> kevent that hangs in cmake:
> 
> 93172 qemu-arm-static CALL  
> kevent(0x3,0x7ffe7d40,0x2,0x7ffd7d40,0x400,0)
> 93172 qemu-arm-static STRU  struct kevent[] = { { ident=6, 
> filter=EVFILT_READ, flags=0x1, fflags=0, data=0, udata=0x0 }
> { ident=0x0, filter=, flags=0, fflags=0x8, 
> data=0x1, udata=0x0 } }
> 
> Note the 0x2 argument to kevent and the apparently-odd 2nd entry in the struct
> kevent[]. The kevent use is from cmake.
> 
> So far I've not identified a signal being delivered at a time that would seem
> to me to be likely to contribute. (But this is not familiar code so my 
> judgment
> is likely not the best.)
> 
> Note: I normally run FreeBSD using a non-debug kernel, even when using
> head. (The kernel does have symbols.)


The detail of the signal usage involved leading up to the hang-up,
starting from just before the "press return" for the "make FLAVOR=qt5"
command that I had entered:

The only "Interrupted system call" prior to my killing the hung cmake
process was (kdump -H -r -S output):

 93172 100717 qemu-arm-static CALL  execve[59](0x10392,0x8605051a0,0x860cf5400)
 93172 101706 qemu-arm-static RET   nanosleep[240] -1 errno 4 Interrupted 
system call
 93172 100717 qemu-arm-static NAMI  "/bin/sh"
 93172 100717 sh   RET   execve[59] JUSTRETURN
 93172 100717 sh   CALL  readlink[58](0x207a65,0x7fffccc0,0x400)

This is where ninja (via qemu-arm-static) execve's the amd64-native /bin/sh (to
in turn later run cmake via qemu-arm-static). (This was after the fork [for the
requested vfork].) So it is for the close-down of the thread that was in
nanosleep.

There were no PSIG's and no sigreturn's prior to the kill according to the
kdump output.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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: lang/python36 port problem

2018-12-29 Thread Kubilay Kocak

On 23/12/2018 8:11 pm, Scott Bennett wrote:

  The last time lang/python36 was updated, something got messed up, so that
now "portmaster -a" wants to reinstall it every time it is run, even if it is
run as "portmaster -x Python36 -x python36 -a".  It's a nuisance, a waste of
time, and it increases the size of incremental backups.



Hi Scott,

What what the exact port version/revision that the issue you observe 
first started?


What is the FreeBSD version (uname -a) of the system?

Is the ports system portsnap based, or svn based? If the latter, is the 
tree up to date and free of conflicts/local updates?


Does pkg version show the port as out of date? What is the output of pkg 
version -v |grep -i python?


Could you please include the following in a compressed log:

- pkg version -v output
- make.conf contents
- portmaster log




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